From mmusic-bounces@ietf.org Sun Apr 01 09:01:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzfN-00021E-L5; Sun, 01 Apr 2007 09:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzfF-0001z6-O8 for mmusic@ietf.org; Sun, 01 Apr 2007 09:00:09 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXzfE-0001Z3-38 for mmusic@ietf.org; Sun, 01 Apr 2007 09:00:09 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61562 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HXzfC-0002fp-FF; Sun, 01 Apr 2007 14:00:06 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93981843-54DF-4233-8167-02E6F640C81F@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Sun, 1 Apr 2007 14:00:03 +0100 To: Jean-Francois Mule X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mmusic@ietf.org, Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org [Not as chair] On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote: > This is to announce a Working Group Last Call on ICE > draft-ietf-mmusic-ice-15.txt. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > This WGLC will end on Friday April 20. > > Please mail all your final comments to the author and the mmusic > mailing > list. I notice that there are a number of IPR claims against ICE: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=799 (Cisco) https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=727 (Tandberg) https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=728 (Tandberg) https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=729 (Tandberg) The license terms offered for the Cisco IPR are reasonable, and not problematic. The license terms offered by Tandberg are more of a concern. While the intent to grant a royalty free license is greatly appreciated, the requirement to negotiate the license, rather than explicitly granting a royalty free license to anyone to implement the standard, is a barrier for open-source implementers. I would hope Tandberg will revise these terms, before ICE is considered for publication. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 02 10:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNuz-0001f8-8x; Mon, 02 Apr 2007 10:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNux-0001eo-0r for mmusic@ietf.org; Mon, 02 Apr 2007 10:53:59 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNut-00049p-Je for mmusic@ietf.org; Mon, 02 Apr 2007 10:53:59 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JFV004A9LDAX8@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 02 Apr 2007 15:53:34 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 02 Apr 2007 15:53:38 +0100 Content-return: allowed Date: Mon, 02 Apr 2007 15:53:36 +0100 From: "Elwell, John" To: mmusic@ietf.org, Jonathan Rosenberg Message-id: <50B1CBA96870A34799A506B2313F26670B7813A6@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [MMUSIC] ICE micro-lite for support of IPv6 transition X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org There was strong consensus at IETF68 to deprecate ANAT and use ICE as the sole way of negotiating between IPv4 and IPv6 for media. However, there was some concern about this raising the bar too high for those who require to support IPv6 ahead of full ICE. While many markets may require ICE for NAT traversal before they require IPv6, there are certain customers demanding IPv6 transition capabilities at an early stage, and needing to do a full ICE implementation to satisfy these customers can be undesirable. To satisfy this market, the requirement is for an offer to include two candidates, one IPv4 and the other IPv6. For backwards compatibility with IPv4 non-ICE implementations, the IPv4 candidate would be the default. The answerer should be able to select one of these and the call should be able to continue without a connectivity check. Removal of connectivity checks would considerably simplify the implementation of ICE for IPv4/IPV6 negotiation in these environments. Compatibility with full or lite ICE implementations would have to be provided, of course. Thus we would really only use the SDP enhancements of ICE, and not the rest. Compared with ANAT it has the advantages of better backward compatibility with existing IPv4 devices and being a step on the path towards full ICE. ICE lite goes some way to lowering the bar for implementing ICE, but it does not solve the present problem for two reasons: 1) An ICE lite implementation cannot propose two candidates. 2) An ICE lite implementation is still required to support connectivity checks as a server. It seems that the requirements above could be supported by a fairly small change to ICE, along the following lines. I will call this an ICE "micro-lite" implementation. When sending an offer, a dual stack ICE "micro-lite" implementation would include two candidates, one based on IPv4 (the default candidate) and the other based on IPv6. It would also include a flag (e.g., an option tag) to indicate that it supports only "micro-lite" and therefore will not do connectivity checks. The answerer would choose the IP protocol and respond with an IP address for that protocol in the c-line. If IPv6 is chosen, the offerer would need to do a further offer to promote its IPv6 address and port to the m/c line. If the answerer is a full (or lite) implementation, it would use the received "micro-lite" indicator to behave as above and suppress testing. If the offerer is a full implementation, it sees that the answerer does not support full or lite ICE (because it does not return any candidate lines) but would use the fact that the c-line contains an IPv6 address to select its IPv6 host candidate, use it in the m/c line of a new offer, and suppress testing. The above would represents quite a small change to ICE and could probably be accommodated in the ICE RFC rather than a separate RFC. In this way it would be easier to force support of micro-lite by all ICE implementations. As a further enhancement, perhaps ICE-lite could allow the inclusion of two candidates, where one is IPv4 and the other is IPv6. ICE micro-lite would then be a subset of ICE-lite. There would then be a natural evolution path for implementations, from micro-lite, via lite to full ICE. John _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 02 12:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPNJ-0007w2-DR; Mon, 02 Apr 2007 12:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPNH-0007vw-Pj for mmusic@ietf.org; Mon, 02 Apr 2007 12:27:19 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPNF-0001tG-MJ for mmusic@ietf.org; Mon, 02 Apr 2007 12:27:18 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l32GQXJc008649; Mon, 2 Apr 2007 10:26:33 -0600 (MDT) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Mon, 2 Apr 2007 10:26:32 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2007 10:22:00 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review team formed for RTSP/2.0 Thread-Index: Acd1QxUckB+IlBPsQSqqb8bOHUZGlQ== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Colin Perkins , Joerg Ott Subject: [MMUSIC] Review team formed for RTSP/2.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Folks, Based on our open calls during the mmusic wg meetings at IETF 67 & 68, we have formed a review team for RTSP with the main goal of resolving open issues and getting new revisions out. The following people have signed up to be on the review team: - Martin Stiemerling (new editor) - Chris Steck - Dave Singer - Henning Schulzrinne - Jamie Gordon - Magnus Westerlund=20 - Reinaldo Penno - Sean Sheedy - Magnus Westerlund - Jean-Francois Mule We plan to have regular calls and will post meeting notes/updates on spec issues, etc. Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 02 17:26:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYU2G-0004mr-8W; Mon, 02 Apr 2007 17:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYU2E-0004kQ-Te for mmusic@ietf.org; Mon, 02 Apr 2007 17:25:54 -0400 Received: from stewe.org ([85.214.23.117] helo=h665227.serverkompetenz.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYU2D-0002xi-FE for mmusic@ietf.org; Mon, 02 Apr 2007 17:25:54 -0400 Received: (qmail 23211 invoked by uid 60000); 2 Apr 2007 20:12:51 -0000 Received: from 67.101.145.160 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:0(67.101.145.160):SA:0(0.0/20.0):. Processed in 0.302753 secs); 02 Apr 2007 20:12:51 -0000 X-Spam-Status: No, hits=0.0 required=20.0 X-Envelope-From: stewe@stewe.org Received: from h-67-101-145-160.snfccasy.dynamic.covad.net (HELO ?192.168.1.220?) (stewe@stewe.org@67.101.145.160) by stewe.org with SMTP; 2 Apr 2007 20:12:50 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stephan Wenger Subject: Re: [MMUSIC] Review team formed for RTSP/2.0 Date: Mon, 2 Apr 2007 14:25:33 -0700 To: Jean-Francois Mule X-Mailer: Apple Mail (2.752.3) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on h665227.serverkompetenz.net X-Spam-Level: X-Qmail-Scanner-MOVED-X-Spam-Status: No, hits=0.0 required=20.0 tests=none autolearn=no version=2.64 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mmusic@ietf.org, Joerg Ott , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org It's good to see Magnus Westerlund twice on this list -- that should ensure quality. But I wonder: when did the cloning happen? :-) Stephan On Apr 2, 2007, at 9:22 AM, Jean-Francois Mule wrote: > Folks, > > Based on our open calls during the mmusic wg meetings at IETF 67 & > 68, we have formed a review team for RTSP with the main goal of > resolving open issues and getting new revisions out. > > The following people have signed up to be on the review team: > - Martin Stiemerling (new editor) > - Chris Steck > - Dave Singer > - Henning Schulzrinne > - Jamie Gordon > - Magnus Westerlund > - Reinaldo Penno > - Sean Sheedy > - Magnus Westerlund > - Jean-Francois Mule > > We plan to have regular calls and will post meeting notes/ > updates on > spec issues, etc. > > Jean-Francois. > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 03 05:06:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYexf-0002uI-RO; Tue, 03 Apr 2007 05:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYexf-0002uA-CG for mmusic@ietf.org; Tue, 03 Apr 2007 05:05:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYexX-0008GI-RU for mmusic@ietf.org; Tue, 03 Apr 2007 05:05:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4EB3420A37; Tue, 3 Apr 2007 11:05:47 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-8f-461218eb409b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3638320672; Tue, 3 Apr 2007 11:05:47 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:05:47 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:05:46 +0200 Message-ID: <461218EA.5000409@ericsson.com> Date: Tue, 03 Apr 2007 11:05:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Stephan Wenger Subject: Re: [MMUSIC] Review team formed for RTSP/2.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2007 09:05:46.0925 (UTC) FILETIME=[446135D0:01C775CF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Jean-Francois Mule , mmusic@ietf.org, Joerg Ott , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Stephan Wenger skrev: > It's good to see Magnus Westerlund twice on this list -- that should > ensure quality. But I wonder: when did the cloning happen? :-) Who has talked about cloning? Dual cores, isn't the latest trends. But I don't think I ever committed the second instance to this task ;-). Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 03 05:06:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYexm-000341-5n; Tue, 03 Apr 2007 05:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYexk-00032Q-KD for mmusic@ietf.org; Tue, 03 Apr 2007 05:06:00 -0400 Received: from prix.tandberg.no ([194.196.35.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYexh-0008HZ-SB for mmusic@ietf.org; Tue, 03 Apr 2007 05:06:00 -0400 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.11.20060308/8.12.10) with ESMTP id l3395WiI004091; Tue, 3 Apr 2007 11:05:54 +0200 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by 47mail.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:05:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Tue, 3 Apr 2007 11:05:39 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB187A25@oslexcp1.eu.tandberg.int> In-Reply-To: <93981843-54DF-4233-8167-02E6F640C81F@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Thread-Index: Acd0XdaT7Y2c22RHQYu5Q5rYEjVNIwBcUeBA From: "Geir Arne Sandbakken" To: "Colin Perkins" , "Jean-Francois Mule" X-OriginalArrivalTime: 03 Apr 2007 09:05:40.0358 (UTC) FILETIME=[40772A60:01C775CF] X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mmusic@ietf.org, Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Colin, The part of the IPR concerning negotiation of a license is adopted from the standard ITU patent policy statement. We understand you concern, and it is now under revision. Cheers, Geir Arne > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 01 April 2007 15:00 > To: Jean-Francois Mule > Cc: mmusic@ietf.org; Joerg Ott > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 > [Not as chair] >=20 > On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote: > > This is to announce a Working Group Last Call on ICE > > draft-ietf-mmusic-ice-15.txt. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > > > This WGLC will end on Friday April 20. > > > > Please mail all your final comments to the author and the mmusic > > mailing > > list. >=20 > I notice that there are a number of IPR claims against ICE: >=20 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D799 > (Cisco) > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D727 > (Tandberg) > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D728 > (Tandberg) > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D729 > (Tandberg) >=20 > The license terms offered for the Cisco IPR are reasonable, and not > problematic. >=20 > The license terms offered by Tandberg are more of a concern. While > the intent to grant a royalty free license is greatly appreciated, > the requirement to negotiate the license, rather than explicitly > granting a royalty free license to anyone to implement the standard, > is a barrier for open-source implementers. I would hope Tandberg will > revise these terms, before ICE is considered for publication. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 03 13:45:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYn3f-0004Up-Lz; Tue, 03 Apr 2007 13:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYn3e-0004Ud-5Z for mmusic@ietf.org; Tue, 03 Apr 2007 13:44:38 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYn3a-00084a-RJ for mmusic@ietf.org; Tue, 03 Apr 2007 13:44:38 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E8446519CF for ; Tue, 3 Apr 2007 13:44:33 -0400 (EDT) Message-ID: <4612927F.2060300@pjsip.org> Date: Tue, 03 Apr 2007 18:44:31 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [MMUSIC] ICE 15: Triggered check clarification X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I'd like to propose clarification for triggered check. Please see Section 7.2.1.4. Triggered Checks for reference. Background 1) " Next, the agent constructs a pair whose local candidate is equal to the transport address on which the STUN request was received, and .. " A typical application doesn't normally have access on the destination address of an incoming packet (it only has access to source address), so in the situation where a base address is associated with more than one candidates (for example, host and server reflexive), it wouldn't be possible to find which local candidate to choose. Background 2) " This pair is then looked up in the check list. There can be one of several outcomes: o If the pair is not already on the check list: * The pair is inserted into the check list based on its priority " A pair might not be found in the checklist because it might have been pruned, so inserting a new pair here might just add an unnecessary check. I propose to clarify the local candidate finding process when handling triggered check by modifying the text to something like this: " Next, the agent constructs a pair of a local candidate and a remote candidate which address is equal to the source transport address where the request came from (which may be peer-reflexive remote candidate that was just learned). The local candidate is selected by searching in the checklist, starting from the highest priority, for a local candidate which base address is equal to the transport address where the request is received. " Comments? -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 03 14:23:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYneZ-0007Aa-EE; Tue, 03 Apr 2007 14:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYneX-00078w-Mg for mmusic@ietf.org; Tue, 03 Apr 2007 14:22:45 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYneU-0004UQ-9W for mmusic@ietf.org; Tue, 03 Apr 2007 14:22:45 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l33IMbP0017000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 11:22:37 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l33IMaaC016059; Tue, 3 Apr 2007 11:22:36 -0700 Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:22:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Review team formed for RTSP/2.0 Date: Tue, 3 Apr 2007 11:22:34 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02AF262D@NAEX01.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Review team formed for RTSP/2.0 Thread-Index: Acd1QxUckB+IlBPsQSqqb8bOHUZGlQA2a/YQ References: From: "Desineni, Harikishan" To: "Jean-Francois Mule" , X-OriginalArrivalTime: 03 Apr 2007 18:22:35.0953 (UTC) FILETIME=[0DB65210:01C7761D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Colin Perkins , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I was under the (wrong?) impression that 2.0 is close to becoming an RFC. Can somebody please post the list of open issues on this thread? -Hari > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Monday, April 02, 2007 9:22 AM > To: mmusic@ietf.org > Cc: Colin Perkins; Joerg Ott > Subject: [MMUSIC] Review team formed for RTSP/2.0 >=20 > Folks, >=20 > Based on our open calls during the mmusic wg meetings at IETF 67 & > 68, we have formed a review team for RTSP with the main goal of > resolving open issues and getting new revisions out. >=20 > The following people have signed up to be on the review team: > - Martin Stiemerling (new editor) > - Chris Steck > - Dave Singer > - Henning Schulzrinne > - Jamie Gordon > - Magnus Westerlund > - Reinaldo Penno > - Sean Sheedy > - Magnus Westerlund > - Jean-Francois Mule >=20 > We plan to have regular calls and will post meeting notes/updates on > spec issues, etc. >=20 > Jean-Francois. >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 04 04:17:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ0fh-0005EH-Bb; Wed, 04 Apr 2007 04:16:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ0fg-0005BC-3F for mmusic@ietf.org; Wed, 04 Apr 2007 04:16:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZ0fY-0007qj-Hf for mmusic@ietf.org; Wed, 04 Apr 2007 04:16:48 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A4E87204A5; Wed, 4 Apr 2007 10:16:35 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-f3-46135ee304a4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 82EFC20511; Wed, 4 Apr 2007 10:16:35 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:16:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:16:34 +0200 Message-ID: <46135EE2.705@ericsson.com> Date: Wed, 04 Apr 2007 10:16:34 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Desineni, Harikishan" Subject: Re: [MMUSIC] Review team formed for RTSP/2.0 References: <2CA3E1B6CEC064449CAA7D0FAB46079B02AF262D@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02AF262D@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2007 08:16:34.0507 (UTC) FILETIME=[8F03B9B0:01C77691] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Jean-Francois Mule , mmusic@ietf.org, Joerg Ott , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Desineni, Harikishan skrev: > I was under the (wrong?) impression that 2.0 is close to becoming an > RFC. Can somebody please post the list of open issues on this thread? > This review team is an effort to finish it up. This effort has been lingering due to lack of editor and reviewer work. But I have great hope that we will be able to make reasonable progress. But I am not willing to even make a public guess when we actually will have finished. The official but not completely up to date list of open issues are available at: https://sourceforge.net/projects/rtspspec/ Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 04 07:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3Kp-0008S8-LY; Wed, 04 Apr 2007 07:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3Ko-0008S3-UQ for mmusic@ietf.org; Wed, 04 Apr 2007 07:07:26 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ3Kn-000303-MH for mmusic@ietf.org; Wed, 04 Apr 2007 07:07:26 -0400 Received: from vpn8.dcs.gla.ac.uk ([130.209.254.8]:50880) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HZ3Kl-0005nG-1C for mmusic@ietf.org; Wed, 04 Apr 2007 12:07:23 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mmusic WG From: Colin Perkins Date: Wed, 4 Apr 2007 12:07:15 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [MMUSIC] IPR statement on draft-ietf-mmusic-sdp-media-capabilities-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The secretariat informs us that an IPR disclosure has been submitted pertaining to the SDP media capabilities draft: https:// datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=829 Colin (as chair) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 04 07:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3Tu-00012g-Pb; Wed, 04 Apr 2007 07:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3Tt-00011L-N8 for mmusic@ietf.org; Wed, 04 Apr 2007 07:16:49 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ3Ts-0004sL-Dp for mmusic@ietf.org; Wed, 04 Apr 2007 07:16:49 -0400 Received: from vpn8.dcs.gla.ac.uk ([130.209.254.8]:50909) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HZ3Ts-0006cw-1p for mmusic@ietf.org; Wed, 04 Apr 2007 12:16:48 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mmusic WG From: Colin Perkins Date: Wed, 4 Apr 2007 12:16:40 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [MMUSIC] IPR statement on draft-ietf-mmusic-ice-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The secretariat informs us that updated IPR disclosures have been submitted pertaining to ICE: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=825 https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=826 https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=827 Colin (as chair) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 04 16:38:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCFK-00031Y-9K; Wed, 04 Apr 2007 16:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCFJ-0002zU-GQ for mmusic@ietf.org; Wed, 04 Apr 2007 16:38:21 -0400 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCFF-0005rb-ND for mmusic@ietf.org; Wed, 04 Apr 2007 16:38:21 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l34KcEK7020383; Wed, 4 Apr 2007 16:38:14 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l34KcCeM001014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 16:38:14 -0400 In-Reply-To: <46088071.3020905@cisco.com> References: <46088071.3020905@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS Date: Wed, 4 Apr 2007 16:38:43 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 26-Mar-07, at 22:24 , Jonathan Rosenberg wrote: > During the Prague IETF, an issue was raised with ICE-tcp that we > didn't resolve. > > The question is, if you are using TLS with ICE, do you perform the > TCP setup, then TLS handshake, and then STUN checks or do the TCP > setup, then STUN checks, then TLS handshake? > > There are some pros/cons that were discussed: > > STUN then TLS > ------------- > > + avoids doing TLS handshakes except on connections that are > selected by ICE > + consistent with how we are doing DTLS where the STUN is clearly > not protected by SRTP and would happen prior to the DTLS handshaking > - Likely to be really hard to implement since most TLS stacks > probably won't let you interleave data like this > - will lose the TLS protection on STUN itself, introducing possible > framing attacks whereby a MITM modifies the STUN lengths to disrupt > frame sync > > TLS then STUN > ------------- > > + easier to implement > + protects STUN messages > - will do TLS handshake even for candidates that are not selected; > but can you perhaps reuse the TLS session? > - different from how UDP works > > > I'm inclined towards TLS then STUN (which is the assumption in the > current draft), mostly because I don't think the alternative will > be easily implementable. I don't know a lot about TLS, so please correct me if I am wrong, but it seems to be that TLS is best viewed as a layer that runs on top of TCP. For that reason, it seems to me to be best to do STUN outside of TLS (in other words, "STUN then TLS"). Doing the reverse seems to me to be a mixing of layers that will come back to hurt us later. However, if I am wrong, then it seems to me that we should consider TLS/TCP to be the transport protocol, in other words we need to talk about ICE-TLS as distinct from ICE-TCP. One other question: If someone was to invent a different type of security layer on top of TCP, would you recommend that STUN run inside that layer as well? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 04 17:55:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDRB-0001l9-EM; Wed, 04 Apr 2007 17:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDRA-0001kz-A8 for mmusic@ietf.org; Wed, 04 Apr 2007 17:54:40 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDR9-0007Fa-2G for mmusic@ietf.org; Wed, 04 Apr 2007 17:54:40 -0400 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l34LsYIh015794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Apr 2007 17:54:34 -0400 (EDT) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l34LsYjE038602 for ; Wed, 4 Apr 2007 17:54:34 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l34LsYYW038593; Wed, 4 Apr 2007 17:54:34 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17940.7833.822061.888913@cnr.cs.columbia.edu> Date: Wed, 4 Apr 2007 17:54:33 -0400 To: In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.3.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, all -- ICE-15 (section 8.2, bullet 3, sub-bullet 2) says that even after a media stream enters the Completed state, an agent MUST still respond to any checks it receives, and perform the corresponding triggered checks. The question is, when can it *stop* doing this? In particular, when is it safe to stop listening on unselected ports, release unused TURN relays, stop STUN keepalives, and the like? Clearly it's not desirable to keep using all these resources for the entire duration of a multimedia session. For a controlling endpoint doing regular nomination, as soon as you send a request containing USE-CANDIDATE, it's safe to close your other local candidates. However, for a controlled endpoint, or a controlling endpoint doing aggressive nomination, this won't work. One option might be to close unused ports after you receive the updated offer or answer. However, the updated offer/answer is only used if when the default candidates weren't selected, so you can't necessarily always count on that, unless we want to make an updated offer/answer mandatory for aggressive nominators; and even then things are unclear for the controlled endpoint. Thoughts? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 04 18:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDlM-0002Qv-C7; Wed, 04 Apr 2007 18:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDlL-0002Qq-I6 for mmusic@ietf.org; Wed, 04 Apr 2007 18:15:31 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDlK-0002xD-Ad for mmusic@ietf.org; Wed, 04 Apr 2007 18:15:31 -0400 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l34MFTpl028460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Apr 2007 18:15:29 -0400 (EDT) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l34MFTAg037615 for ; Wed, 4 Apr 2007 18:15:29 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l34MFSLt037611; Wed, 4 Apr 2007 18:15:28 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17940.9088.826718.530635@cnr.cs.columbia.edu> Date: Wed, 4 Apr 2007 18:15:28 -0400 To: In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.3.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [MMUSIC] ICE-15: pair priorities with 3PCC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The ICE pair-priority formula (defined in section 5.7.2) takes as its parameters the priority of the offerer's candidate and that of the answerer's candidate. However, in 3PCC scenarios, the two endpoints can disagree about which of them is the offerer. This was the reason for the introduction of the ICE-CONTROLLING and ICE-CONTROLLED attributes in ICE-15. In this case, the two endpoints would calculate different pair priorities, and thus start their periodic checks in a different order. As I understand it, the order of the periodic checks is important to the protocol, so that "suicide packets" hit firewalls at roughly the same time; this is why the prioritization algorithm is normative. As such, a disagreement about which party is the offerer would cause a problem. My suggestion would be to change the formula of 5.7.2. Rather than having its parameters be the offerer's priority and the answerer's priority, the parameters would instead be the controlling endpoint's priority and the controlled endpoint's priority. Thus, if an endpoint switches its role after "losing" a role conflict, following the procedures of 7.2.1.1, it needs to re-calculate its pair priorities and re-sort its check lists. This change to the formula won't cause a compatibility problems with ICE-14 or earlier, or with ICE-15 if there hasn't been a role conflict, because the only case in which the offerer is not the controller is if the offerer is using ICE-lite. Since an ICE-lite endpoint can list only a single candidate, the order of the check list will be the same either way, and anyway doesn't matter since the lite endpoint isn't sending any checks. Thoughts? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 01:01:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZK5N-0002MA-PE; Thu, 05 Apr 2007 01:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZK5M-0002BL-1s for mmusic@ietf.org; Thu, 05 Apr 2007 01:00:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZK5K-0004ii-La for mmusic@ietf.org; Thu, 05 Apr 2007 01:00:36 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 04 Apr 2007 22:00:35 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3550Yf7021787; Wed, 4 Apr 2007 22:00:34 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3550XA8029455; Thu, 5 Apr 2007 05:00:33 GMT From: "Dan Wing" To: "'Adam Roach'" , "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" Subject: RE: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS Date: Wed, 4 Apr 2007 22:00:33 -0700 Message-ID: <3b0d01c7773f$578b9940$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <460EEDB6.2000707@nostrum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acdz7TEBjMk0/oL/SyyfCluO2ZN9UwDUfVGg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3068; t=1175749234; x=1176613234; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20ICE-tcp=3A=20TLS=20then=20STUN=20or=20STUN =20then=20TLS |Sender:=20; bh=mysFd0jlpVKDrgi+RGB+dkqxeLADur1kU01lXc0hAfU=; b=X8T9CqT2TBxMNs0INkL5Q8CQJK9UNeC4p0Dt81FxOrIhnn6AT3YlXr+TeEf1/PWATZTTbalK 7utw39AF4AILv6Y+Zgq/P4gqKfHs+RZbkcsFtE+wNYKd/dwefIL0l62n; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org And TLS session resumption should be useful to avoid doing a=20 public key or DH against each ICE candidate. -d =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Saturday, March 31, 2007 4:25 PM > To: R=E9mi Denis-Courmont > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS >=20 > Given EKR and R=E9mi's analysis of the situation, it sounds to=20 > me like we=20 > get to choose between making implementors work harder and making CPUs=20 > work harder. >=20 > I would argue that the key to a successful protocol is a low=20 > implementation complexity. Even for low-end mobile devices, CPUs are=20 > relatively fast (133 MHz is the low-low-low end nowadays) and getting=20 > faster all the time -- so the extra TLS handshakes, while a=20 > waste of CPU=20 > time, are going to be rather insignificant in the grand scheme of=20 > things. (As to battery life: consider that these wasted cycles will=20 > typically occur only at the start of a session, so there should be=20 > negligible impact on total power used). >=20 > Finally, given that ICE-TCP is being considered for=20 > applications other=20 > than TCP (cf. Aki's ICE-MSRP draft), I'd want to stay away from any=20 > solution that assumes the use of RTP TCP framing. >=20 > /a >=20 > R=E9mi Denis-Courmont wrote: > > On Thursday 29 March 2007 17:25:41 ext EKR wrote: > > =20 > >>> Well, one idea on the demux is if we are using the=20 > contrans framing, > >>> the TLS runs ONTOP of the framing so the demux is trivial. > >>> =20 > > > > My memory might be failing, but I thought RTP/TCP framing=20 > only adds a bytes=20 > > length word. That is sufficient to differenciate RTP from=20 > STUN, sure... but=20 > > does it work for TLS vs STUN at all? > > > > =20 > >>> One thing I wasnt sure of is whether the stacks allow=20 > these shimes to > >>> exist only prior to the handshake completing or through the entire > >>> duration of the tls connection? > >>> =20 > >> At least with OpenSSL, all the time. If people want, I=20 > could do a survey > >> of the relevant stacks and see what they do. It won't be=20 > this week or > >> next, though... > >> =20 > > > > At least, OpenSSL, GnuTLS and DotNet=20 > System.Net.Security.SslStream. Not very=20 > > confident about the other ones. And in any case, this=20 > requires a bunch of=20 > > extra custom code because they all assume a socket handle=20 > by default, so you=20 > > end up writing new I/O callbacks and re-assembling buffers.=20 > I am not very=20 > > fond of that idea. > > > > I would rather go for STUN then TLS then (proto-specific=20 > keep-alives OR=20 > > STUNoTLS). As far as I can tell, it would be faster and=20 > slightly less=20 > > disruptive to application developpers. > > > > Regards, > > > > =20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 03:17:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMDa-0007lV-IL; Thu, 05 Apr 2007 03:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMDZ-0007lQ-CM for mmusic@ietf.org; Thu, 05 Apr 2007 03:17:13 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZMDX-0000cF-Tp for mmusic@ietf.org; Thu, 05 Apr 2007 03:17:13 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l357GGPT003621; Thu, 5 Apr 2007 10:16:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:16:15 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:16:15 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:16:14 +0300 Received: from esdhcp04179.research.nokia.com (esdhcp04179.research.nokia.com [172.21.41.79]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l357G84q012880; Thu, 5 Apr 2007 10:16:09 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS Date: Thu, 5 Apr 2007 10:16:20 +0300 User-Agent: KMail/1.9.6 References: <46088071.3020905@cisco.com> <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> In-Reply-To: <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704051016.21190.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Apr 2007 07:16:14.0867 (UTC) FILETIME=[4BF43E30:01C77752] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070405101701-0C531BB0-1FFD4A40/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ext Philip Matthews X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Wednesday 04 April 2007 23:38:43 ext Philip Matthews wrote: > I don't know a lot about TLS, so please correct me if I am wrong, but > it seems to be that TLS is best viewed as a layer that runs on top of > TCP. TLS runs on top of a reliable, ordered, bytes stream. This is typically TCP= ,=20 but can be something else (I see no reason why TLS would not work on top of= =20 SCTP or even IPX/SPX ;-) ). It definitely can theoretically run on top of STUN/TCP. The issue is whethe= r=20 this is practical or not: Most TLS stacks are biased toward using a BSD=20 socket or equivalent, and it is either intricate, or maybe impossible with= =20 some stacks, to use something else (without rewriting the stack). > One other question: If someone was to invent a different type of > security layer on top of TCP, would you recommend that STUN run > inside that layer as well? I think nobody wants to reinvent TLS here :) =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 03:20:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMGw-0002B0-8S; Thu, 05 Apr 2007 03:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMGv-0002As-5k for mmusic@ietf.org; Thu, 05 Apr 2007 03:20:41 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZMGt-0001YQ-MN for mmusic@ietf.org; Thu, 05 Apr 2007 03:20:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l357JjEx000665; Thu, 5 Apr 2007 10:20:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:20:02 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:20:02 +0300 Received: from esdhcp04179.research.nokia.com (esdhcp04179.research.nokia.com [172.21.41.79]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l357K0GM017386; Thu, 5 Apr 2007 10:20:00 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS Date: Thu, 5 Apr 2007 10:20:14 +0300 User-Agent: KMail/1.9.6 References: <3b0d01c7773f$578b9940$c4f0200a@amer.cisco.com> In-Reply-To: <3b0d01c7773f$578b9940$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704051020.14305.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Apr 2007 07:20:02.0232 (UTC) FILETIME=[D3796380:01C77752] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Thursday 05 April 2007 08:00:33 ext Dan Wing wrote: > And TLS session resumption should be useful to avoid doing a > public key or DH against each ICE candidate. This raises two questions (sorry if they were already addressed, I might ha= ve=20 missed it): 1/ Does ICE-TCP only ever maintains one candidate active TCP connection at = a=20 time? 2/ What are the requirement for TLS to allow resumption if you change from = one=20 TCP connection to another one (I vaguely recall that some error cases stall= ed=20 the session for security reasons)? there may be a need to close extra ICE-T= CP=20 connection in some particular way, maybe... Anyone? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 08:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQsE-0004xI-44; Thu, 05 Apr 2007 08:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQsC-0004xD-TZ for mmusic@ietf.org; Thu, 05 Apr 2007 08:15:28 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZQsA-0004wo-Gy for mmusic@ietf.org; Thu, 05 Apr 2007 08:15:28 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 05 Apr 2007 05:15:26 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l35CFQIj007834; Thu, 5 Apr 2007 05:15:26 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l35CFLEi008280; Thu, 5 Apr 2007 12:15:25 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 08:15:20 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 08:15:20 -0400 Message-ID: <4614E858.9080107@cisco.com> Date: Thu, 05 Apr 2007 08:15:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE 15: Triggered check clarification References: <4612927F.2060300@pjsip.org> In-Reply-To: <4612927F.2060300@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 12:15:20.0532 (UTC) FILETIME=[14676940:01C7777C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2813; t=1175775326; x=1176639326; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE=2015=3A=20Triggered=20check=20clarific ation |Sender:=20; bh=LRwRZaG3Vb5jYm+4eK+OfN8geCAvaPrID3oKkS/jMIo=; b=q4IrORxsmWRS3h6k/HVDLcgf70O+mcLmYB8Kzd2lQmLBZtAXXMHgb7S5xWfT0KNVTQ3SrQI+ P5ZfYu6qE3/s4nxUQb9A3u1BSO4APD/LxRuMqbfcy2/K2qiEYSs6tv8c; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Benny Prijono wrote: > Hi, > > I'd like to propose clarification for triggered check. Please see > Section 7.2.1.4. Triggered Checks for reference. > > > Background 1) > > " > Next, the agent constructs a pair whose local candidate is equal to > the transport address on which the STUN request was received, and > .. > " > > A typical application doesn't normally have access on the > destination address of an incoming packet (it only has access to > source address), so in the situation where a base address is associated > with more than one candidates (for example, host and server reflexive), > it wouldn't be possible to find which local candidate to choose. Sure, though it would know the IP address and port of the local socket when it had initially bound to it. So you wouldn't need to make this determination dynamically when a packet is received. > > > Background 2) > > " > This pair is then looked up in the check list. There can be one of > several outcomes: > o If the pair is not already on the check list: > > * The pair is inserted into the check list based on its > priority > " > > A pair might not be found in the checklist because it might have > been pruned, so inserting a new pair here might just add an > unnecessary check. It would not have been pruned. The pruning will remove pairs whose local candidates have the same base. THis is done by replacing the local candidate with its base and then removing redundancies. THis means that every pair in the check list has a local candidate that is either host or relayed - never server reflexive. For triggerered checks, the local candidate will always be host or relayed, and so it will never have been one that was pruned. > > I propose to clarify the local candidate finding process when handling > triggered check by modifying the text to something like this: > > > " > Next, the agent constructs a pair of a local candidate and a > remote candidate which address is equal to the source transport > address where the request came from (which may be peer-reflexive > remote candidate that was just learned). The local candidate > is selected by searching in the checklist, starting from the > highest priority, for a local candidate which base address is > equal to the transport address where the request is received. > " > I disagree with this change, per above. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 08:22:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQyO-00019N-Va; Thu, 05 Apr 2007 08:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQyN-00019H-Ah for mmusic@ietf.org; Thu, 05 Apr 2007 08:21:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZQyL-000694-Rq for mmusic@ietf.org; Thu, 05 Apr 2007 08:21:51 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2007 05:21:51 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l35CLnQg031228; Thu, 5 Apr 2007 05:21:49 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l35CLmA8009370; Thu, 5 Apr 2007 12:21:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 08:21:47 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 08:21:46 -0400 Message-ID: <4614E9DA.7040100@cisco.com> Date: Thu, 05 Apr 2007 08:21:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670B7813A6@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B7813A6@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 12:21:46.0521 (UTC) FILETIME=[FA78A890:01C7777C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4512; t=1175775709; x=1176639709; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20ICE=20micro-lite=20for=20support=20of=20IPv6=20transi tion |Sender:=20; bh=ZdqqtG6lMY9nmgUYYniGVVBDtFr3hTkFqQuBxP+Vgo8=; b=Z4x2iYX/4hT0LXBGBu6pjWZ27QMQR78tMMO5ERHlRwZWG83QMDeHnKwf6AUQ4M6jwUkKjoRQ qrY53k0PKHdICIDYXcKu9rE5a6J7VHyedBr4RmhS7fXhaXRSbp9rNcmL; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org John, I think this defeats the entire purpose of why we had selected ICE to deprecate ANAT. What you are proposing below is nothing more than a syntactic transformation of ANAT into ICE. This loses all of the benefits ICE brings (dynamic path selection, ability to run RFC 3484, etc.), and also introduces a mode that will not interoperate properly with regular ICE endpoints. Remember, the reason ice-lite requires an implementation to receive checks and respond to them, is that this is necessary for the full ice implementation to achieve nat traversal. With your proposal, a full ICE implementation would get no NAT traversal benefits when communicating with an ice micro-lite endpoint. -Jonathan R. Elwell, John wrote: > There was strong consensus at IETF68 to deprecate ANAT and use ICE as the > sole way of negotiating between IPv4 and IPv6 for media. However, there was > some concern about this raising the bar too high for those who require to > support IPv6 ahead of full ICE. While many markets may require ICE for NAT > traversal before they require IPv6, there are certain customers demanding > IPv6 transition capabilities at an early stage, and needing to do a full ICE > implementation to satisfy these customers can be undesirable. > > To satisfy this market, the requirement is for an offer to include two > candidates, one IPv4 and the other IPv6. For backwards compatibility with > IPv4 non-ICE implementations, the IPv4 candidate would be the default. The > answerer should be able to select one of these and the call should be able > to continue without a connectivity check. Removal of connectivity checks > would considerably simplify the implementation of ICE for IPv4/IPV6 > negotiation in these environments. Compatibility with full or lite ICE > implementations would have to be provided, of course. > > Thus we would really only use the SDP enhancements of ICE, and not the rest. > Compared with ANAT it has the advantages of better backward compatibility > with existing IPv4 devices and being a step on the path towards full ICE. > > ICE lite goes some way to lowering the bar for implementing ICE, but it does > not solve the present problem for two reasons: > 1) An ICE lite implementation cannot propose two candidates. > 2) An ICE lite implementation is still required to support connectivity > checks as a server. > > It seems that the requirements above could be supported by a fairly small > change to ICE, along the following lines. I will call this an ICE > "micro-lite" implementation. > > When sending an offer, a dual stack ICE "micro-lite" implementation would > include two candidates, one based on IPv4 (the default candidate) and the > other based on IPv6. It would also include a flag (e.g., an option tag) to > indicate that it supports only "micro-lite" and therefore will not do > connectivity checks. The answerer would choose the IP protocol and respond > with an IP address for that protocol in the c-line. If IPv6 is chosen, the > offerer would need to do a further offer to promote its IPv6 address and > port to the m/c line. > > If the answerer is a full (or lite) implementation, it would use the > received "micro-lite" indicator to behave as above and suppress testing. If > the offerer is a full implementation, it sees that the answerer does not > support full or lite ICE (because it does not return any candidate lines) > but would use the fact that the c-line contains an IPv6 address to select > its IPv6 host candidate, use it in the m/c line of a new offer, and suppress > testing. > > The above would represents quite a small change to ICE and could probably be > accommodated in the ICE RFC rather than a separate RFC. In this way it would > be easier to force support of micro-lite by all ICE implementations. > > As a further enhancement, perhaps ICE-lite could allow the inclusion of two > candidates, where one is IPv4 and the other is IPv6. ICE micro-lite would > then be a subset of ICE-lite. There would then be a natural evolution path > for implementations, from micro-lite, via lite to full ICE. > > John > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRdV-0002nV-9Y; Thu, 05 Apr 2007 09:04:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRdU-0002nM-9i for mmusic@ietf.org; Thu, 05 Apr 2007 09:04:20 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRdQ-0003Jc-0i for mmusic@ietf.org; Thu, 05 Apr 2007 09:04:20 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id DB4305193F; Thu, 5 Apr 2007 09:04:12 -0400 (EDT) Message-ID: <4614F3CA.2090003@pjsip.org> Date: Thu, 05 Apr 2007 14:04:10 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE 15: Triggered check clarification References: <4612927F.2060300@pjsip.org> <4614E858.9080107@cisco.com> In-Reply-To: <4614E858.9080107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for the reply, Jonathan. Please see my comments inline. Jonathan Rosenberg wrote: > inline. > > Benny Prijono wrote: >> A typical application doesn't normally have access on the >> destination address of an incoming packet (it only has access to >> source address), so in the situation where a base address is >> associated with more than one candidates (for example, host and server >> reflexive), it wouldn't be possible to find which local candidate to >> choose. > > Sure, though it would know the IP address and port of the local socket > when it had initially bound to it. So you wouldn't need to make this > determination dynamically when a packet is received. Yeah, I just realized this. Basically I've got my implementation "wrong" and I create one socket for one component instead of one per candidate, that's why I couldn't figure out which candidate to choose when an incoming request arrives. I said "wrong", because I think I can make my implementation work too. Let me argue about this on another thread. >> Background 2) >> >> " >> This pair is then looked up in the check list. There can be one of >> several outcomes: >> o If the pair is not already on the check list: >> >> * The pair is inserted into the check list based on its >> priority >> " >> >> A pair might not be found in the checklist because it might have >> been pruned, so inserting a new pair here might just add an >> unnecessary check. > > It would not have been pruned. The pruning will remove pairs whose local > candidates have the same base. THis is done by replacing the local > candidate with its base and then removing redundancies. THis means that > every pair in the check list has a local candidate that is either host > or relayed - never server reflexive. For triggerered checks, the local > candidate will always be host or relayed, and so it will never have been > one that was pruned. I disagree that local checklist can never have (local) server reflexive candidate. In my implementation, if STUN is configured in the agent, I put server reflexive candidate type preference to have larger value then host candidate type, so it will appear first in the checklist than the host. Because of this, it's the checks with local host candidates that will be pruned. The reason why I put srflx type with higher preference value is for optimization reason. If STUN is configured, then most likely the agent will communicate with other agent over Internet, so server reflexive candidate will likely to be used. Putting srflx with higher type on this case will make ICE complete faster. But anyway this is not related to the original question. The current text is fine. thanks, -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:21:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRuI-0003P4-1O; Thu, 05 Apr 2007 09:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRuF-0003Ow-OE for mmusic@ietf.org; Thu, 05 Apr 2007 09:21:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRuD-0006EX-Ck for mmusic@ietf.org; Thu, 05 Apr 2007 09:21:39 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 05 Apr 2007 06:21:37 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l35DLarY024803; Thu, 5 Apr 2007 06:21:36 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l35DLTx3002849; Thu, 5 Apr 2007 13:21:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:21:34 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:21:33 -0400 Message-ID: <4614F7DD.5020902@cisco.com> Date: Thu, 05 Apr 2007 09:21:33 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Lennox Subject: Re: [MMUSIC] ICE-15: pair priorities with 3PCC References: <17940.9088.826718.530635@cnr.cs.columbia.edu> In-Reply-To: <17940.9088.826718.530635@cnr.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 13:21:33.0670 (UTC) FILETIME=[54942860:01C77785] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2228; t=1175779296; x=1176643296; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20pair=20priorities=20with=203PC C |Sender:=20; bh=5WAe+rLAgHSk1GQpR07kJmvSg/BJ61XpC5dxSA37R50=; b=st4fSk31Xan8fopL/Mq/rVPj7hrwnOljcWFkPOTPtri9dV9XRaakRgdP6Pl5GZPCgdzpzTG4 6XPMvjtZcMoS18HM/9HW8ItnYwrtHULYSt9tHuqW8O9q6RKemkc7pP8L; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I think this is a good suggestion and I've made the change in my working -16. Thanks, Jonathan R. Jonathan Lennox wrote: > The ICE pair-priority formula (defined in section 5.7.2) takes as its > parameters the priority of the offerer's candidate and that of the > answerer's candidate. > > However, in 3PCC scenarios, the two endpoints can disagree about which of > them is the offerer. This was the reason for the introduction of the > ICE-CONTROLLING and ICE-CONTROLLED attributes in ICE-15. In this case, the > two endpoints would calculate different pair priorities, and thus start > their periodic checks in a different order. > > As I understand it, the order of the periodic checks is important to the > protocol, so that "suicide packets" hit firewalls at roughly the same time; > this is why the prioritization algorithm is normative. As such, a > disagreement about which party is the offerer would cause a problem. > > My suggestion would be to change the formula of 5.7.2. Rather than having > its parameters be the offerer's priority and the answerer's priority, the > parameters would instead be the controlling endpoint's priority and the > controlled endpoint's priority. > > Thus, if an endpoint switches its role after "losing" a role conflict, > following the procedures of 7.2.1.1, it needs to re-calculate its pair > priorities and re-sort its check lists. > > This change to the formula won't cause a compatibility problems with ICE-14 > or earlier, or with ICE-15 if there hasn't been a role conflict, because the > only case in which the offerer is not the controller is if the offerer is > using ICE-lite. Since an ICE-lite endpoint can list only a single > candidate, the order of the check list will be the same either way, and > anyway doesn't matter since the lite endpoint isn't sending any checks. > > Thoughts? > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRxu-0005be-BZ; Thu, 05 Apr 2007 09:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRxs-0005bS-4r for mmusic@ietf.org; Thu, 05 Apr 2007 09:25:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRxp-0006mX-Ra for mmusic@ietf.org; Thu, 05 Apr 2007 09:25:24 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2007 09:25:22 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l35DPLSu013891; Thu, 5 Apr 2007 09:25:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l35DPCGn028935; Thu, 5 Apr 2007 13:25:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:25:15 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:25:15 -0400 Message-ID: <4614F8BA.2060007@cisco.com> Date: Thu, 05 Apr 2007 09:25:14 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE 15: Triggered check clarification References: <4612927F.2060300@pjsip.org> <4614E858.9080107@cisco.com> <4614F3CA.2090003@pjsip.org> In-Reply-To: <4614F3CA.2090003@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 13:25:15.0056 (UTC) FILETIME=[D888FB00:01C77785] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1727; t=1175779521; x=1176643521; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE=2015=3A=20Triggered=20check=20clarific ation |Sender:=20 |To:=20Benny=20Prijono=20; bh=RV+SbNztXCEGsSgYt5UUWztII4cly1vyy2wQ6ATa5Vg=; b=P3ZZV3/hytEEwGw2458LnFHkrK6gJCspKnla+9nIOIYZMcibwHiqy6SBVsZNOFWb/LRup8mo Uk+9GV5FZwCOL5oMG7hD78H+ELeNQuBg/toZRjpVsmcBnsOl3YOezERW; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Benny Prijono wrote: >>> A pair might not be found in the checklist because it might have >>> been pruned, so inserting a new pair here might just add an >>> unnecessary check. >> >> >> It would not have been pruned. The pruning will remove pairs whose >> local candidates have the same base. THis is done by replacing the >> local candidate with its base and then removing redundancies. THis >> means that every pair in the check list has a local candidate that is >> either host or relayed - never server reflexive. For triggerered >> checks, the local candidate will always be host or relayed, and so it >> will never have been one that was pruned. > > > I disagree that local checklist can never have (local) server reflexive > candidate. In my implementation, if STUN is configured in the agent, I > put server reflexive candidate type preference to have larger value then > host candidate type, so it will appear first in the checklist than the > host. Because of this, it's the checks with local host candidates that > will be pruned. Sure, but the check lists always have the local candidate replaced with its base. So if it was server reflexive, it would be replaced by its corresponding host candidate. So, irregardless of priority, there is NEVER a check on the check list whose local candidate is server reflexive. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:31:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZS3z-0002yw-V0; Thu, 05 Apr 2007 09:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZS3y-0002yD-4q for mmusic@ietf.org; Thu, 05 Apr 2007 09:31:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZS3w-0007mQ-Rv for mmusic@ietf.org; Thu, 05 Apr 2007 09:31:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2007 09:31:40 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l35DVeOP016953; Thu, 5 Apr 2007 09:31:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l35DUTH1000482; Thu, 5 Apr 2007 13:31:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:31:38 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:31:38 -0400 Message-ID: <4614FA39.30403@cisco.com> Date: Thu, 05 Apr 2007 09:31:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Lennox Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> In-Reply-To: <17940.7833.822061.888913@cnr.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 13:31:38.0213 (UTC) FILETIME=[BCEA1950:01C77786] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2267; t=1175779900; x=1176643900; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=20waiti ng=20for=20an=20aggressive=09nomination? |Sender:=20 |To:=20Jonathan=20Lennox=20; bh=44E/6Yvna9UKmUklCBNJBYljk3eldNTqG8uF/Y2n6ZI=; b=GZlZxs9FmpKdeMRyK0xAWUXPWum7Djm6hv5c8vT7MqkmoQ/piKz4TRxVM8gbL+Y9+1t+gZiV zkaTqeFL2pbLOR+nZAsBaL+yrA1cl33Taq2HF7fE6gYL97FFYCkxmoqU; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Jonathan Lennox wrote: > Hi, all -- > > ICE-15 (section 8.2, bullet 3, sub-bullet 2) says that even after a media > stream enters the Completed state, an agent MUST still respond to any checks > it receives, and perform the corresponding triggered checks. > > The question is, when can it *stop* doing this? In particular, when is it > safe to stop listening on unselected ports, release unused TURN relays, > stop STUN keepalives, and the like? Clearly it's not desirable to keep > using all these resources for the entire duration of a multimedia session. > > For a controlling endpoint doing regular nomination, as soon as you send a > request containing USE-CANDIDATE, it's safe to close your other local > candidates. However, for a controlled endpoint, or a controlling endpoint > doing aggressive nomination, this won't work. Right. If the controlled endpoint knew that the controller was using regular nomination, it could also free things up upon completed. The main issue is the agressive mode. > > One option might be to close unused ports after you receive the updated > offer or answer. However, the updated offer/answer is only used if when the > default candidates weren't selected, so you can't necessarily always count > on that, unless we want to make an updated offer/answer mandatory for > aggressive nominators; and even then things are unclear for the controlled > endpoint. Well, much as a hate timers, its probably the only option here. With agressive nomination, if you wair one STUN transaction lifetime after you've entered completed, you can free up resources since there shouldn't be any further changes after that. Signaling whether agreessive or regular nomination is in use doesn't really help, since you'll still need the timer for agressive mode. Other choice is to eliminate agressive mode and I don't want to do that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:40:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSCI-0007c9-S4; Thu, 05 Apr 2007 09:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSCI-0007c4-9K for mmusic@ietf.org; Thu, 05 Apr 2007 09:40:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSCG-0000kK-VL for mmusic@ietf.org; Thu, 05 Apr 2007 09:40:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2007 09:40:18 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l35DeGjP021010; Thu, 5 Apr 2007 09:40:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l35DeAlM009080; Thu, 5 Apr 2007 13:40:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:39:55 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:39:55 -0400 Message-ID: <4614FC2A.5000305@cisco.com> Date: Thu, 05 Apr 2007 09:39:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS References: <20070327130229.AB26F1CC22@delta.rtfm.com> <460BC1CB.1090401@cisco.com> <86abxwp1ne.fsf@delta.rtfm.com> <200703301656.51311.remi.denis-courmont@nokia.com> <460EEDB6.2000707@nostrum.com> In-Reply-To: <460EEDB6.2000707@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Apr 2007 13:39:55.0338 (UTC) FILETIME=[E5395AA0:01C77787] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3125; t=1175780416; x=1176644416; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-tcp=3A=20TLS=20then=20STUN=20or=20STUN =20then=20TLS |Sender:=20 |To:=20Adam=20Roach=20; bh=QEiSGIFb3jbDZvkx5G9OoKP7baApzLrv/nwzgXR98kU=; b=MtXPAiZffFTfCzlOMKigVykhj2mPY2I5QgRcOXrM50xmH5Yusu2+jwH9ivRHOXYAT+4fiO5B r2iUSPAdGJKHl3OfL7MzKmq34DgIDNbxifKUsQc4ksN/LscSAi5HOyt8; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org one clarification, Adam. ICE-tcp currently REQURIES that every application protocol using ice-tcp, utilize the cotrans framing, even if its not RTP. I understand this is an issue with MSRP because its framing works differently, but I think it ought to be work using some basic buffering and timeout techniques, just like TCP uses to decide when to send something. -Jonathan R. Adam Roach wrote: > Given EKR and Rémi's analysis of the situation, it sounds to me like we > get to choose between making implementors work harder and making CPUs > work harder. > > I would argue that the key to a successful protocol is a low > implementation complexity. Even for low-end mobile devices, CPUs are > relatively fast (133 MHz is the low-low-low end nowadays) and getting > faster all the time -- so the extra TLS handshakes, while a waste of CPU > time, are going to be rather insignificant in the grand scheme of > things. (As to battery life: consider that these wasted cycles will > typically occur only at the start of a session, so there should be > negligible impact on total power used). > > Finally, given that ICE-TCP is being considered for applications other > than TCP (cf. Aki's ICE-MSRP draft), I'd want to stay away from any > solution that assumes the use of RTP TCP framing. > > /a > > Rémi Denis-Courmont wrote: > >> On Thursday 29 March 2007 17:25:41 ext EKR wrote: >> >> >>>> Well, one idea on the demux is if we are using the contrans framing, >>>> the TLS runs ONTOP of the framing so the demux is trivial. >>>> >> >> >> My memory might be failing, but I thought RTP/TCP framing only adds a >> bytes length word. That is sufficient to differenciate RTP from STUN, >> sure... but does it work for TLS vs STUN at all? >> >> >> >>>> One thing I wasnt sure of is whether the stacks allow these shimes to >>>> exist only prior to the handshake completing or through the entire >>>> duration of the tls connection? >>>> >>> >>> At least with OpenSSL, all the time. If people want, I could do a survey >>> of the relevant stacks and see what they do. It won't be this week or >>> next, though... >>> >> >> >> At least, OpenSSL, GnuTLS and DotNet System.Net.Security.SslStream. >> Not very confident about the other ones. And in any case, this >> requires a bunch of extra custom code because they all assume a socket >> handle by default, so you end up writing new I/O callbacks and >> re-assembling buffers. I am not very fond of that idea. >> >> I would rather go for STUN then TLS then (proto-specific keep-alives >> OR STUNoTLS). As far as I can tell, it would be faster and slightly >> less disruptive to application developpers. >> >> Regards, >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:42:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSEB-0008LP-Rn; Thu, 05 Apr 2007 09:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSEA-0008LJ-ES for mmusic@ietf.org; Thu, 05 Apr 2007 09:42:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSE9-0000uU-3l for mmusic@ietf.org; Thu, 05 Apr 2007 09:42:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2007 06:42:12 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l35DgC0k028608; Thu, 5 Apr 2007 09:42:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l35DgBGd003945; Thu, 5 Apr 2007 13:42:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:42:11 -0400 Received: from [192.168.1.104] ([10.86.242.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:42:11 -0400 Message-ID: <4614FCB3.8090309@cisco.com> Date: Thu, 05 Apr 2007 09:42:11 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS References: <46088071.3020905@cisco.com> <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> In-Reply-To: <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 13:42:11.0478 (UTC) FILETIME=[365EAB60:01C77788] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1688; t=1175780532; x=1176644532; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-tcp=3A=20TLS=20then=20STUN=20or=20STUN =20then=20TLS |Sender:=20 |To:=20Philip=20Matthews=20; bh=Br4h3L+7PN3y2ZOluPOphSBrvaSYiPAF3WOCxZWGTwo=; b=h+fkzg3e5VmiaEm5VjdAredi0UgI2J5QYHe/QsCQjT6xNHRPsli02k6O8jFsk0LB6lymLs8W 4y6popEcyFQUKaocEYEVlDljrxXd5kUcQgeQw++er+qzffH6C63rQkV9; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org So far, we're nicely split on this issue in list discussions. More inline: Philip Matthews wrote: >> >> I'm inclined towards TLS then STUN (which is the assumption in the >> current draft), mostly because I don't think the alternative will be >> easily implementable. > > > > I don't know a lot about TLS, so please correct me if I am wrong, but > it seems to be that TLS is best viewed as a layer that runs on top of > TCP. For that reason, it seems to me to be best to do STUN outside of > TLS (in other words, "STUN then TLS"). Doing the reverse seems to me to > be a mixing of layers that will come back to hurt us later. > > However, if I am wrong, then it seems to me that we should consider > TLS/TCP to be the transport protocol, in other words we need to talk > about ICE-TLS as distinct from ICE-TCP. > > One other question: If someone was to invent a different type of > security layer on top of TCP, would you recommend that STUN run inside > that layer as well? To answer a different question, with UDP, we are assuming that DTLS and STUN are 'peers' so that STUN is run outside of DTLS (not protected by it), and that the stun checks happen prior to the DTLS handshakes. One argument in favor of "STUN then TLS" for TCP is to make the UDP and TCP designs equivalent. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 09:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSUS-0002mK-Qt; Thu, 05 Apr 2007 09:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSUR-0002mF-QD for mmusic@ietf.org; Thu, 05 Apr 2007 09:59:03 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSUP-00038m-Km for mmusic@ietf.org; Thu, 05 Apr 2007 09:59:03 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l35Dww2i003721; Thu, 5 Apr 2007 09:58:58 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l35Dwu6A016530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2007 09:58:58 -0400 In-Reply-To: <200704051016.21190.remi.denis-courmont@nokia.com> References: <46088071.3020905@cisco.com> <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> <200704051016.21190.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <89FE093C-9815-4D71-BB8E-0AC98869BDCD@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS Date: Thu, 5 Apr 2007 09:59:30 -0400 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 5-Apr-07, at 03:16 , R=E9mi Denis-Courmont wrote: > On Wednesday 04 April 2007 23:38:43 ext Philip Matthews wrote: >> I don't know a lot about TLS, so please correct me if I am wrong, but >> it seems to be that TLS is best viewed as a layer that runs on top of >> TCP. > > TLS runs on top of a reliable, ordered, bytes stream. This is =20 > typically TCP, > but can be something else (I see no reason why TLS would not work =20 > on top of > SCTP or even IPX/SPX ;-) ). > Is a TLS session bound to a pair of transport addresses, or can it be =20= moved from one pair to another? That is, if I have an connection up on one =20 valid candidate pair, and later want to move it to another valid candidate pair, do I have =20 to start a new TLS session, or is there someway to move the existing session to the new =20 candidate pair? If a TLS session can be moved from one pair to another, then I think =20 this is an argument for doing STUN outside of TLS. If it cannot, then things are not as clear-cut. Also, what is the right way to do DTLS over UDP? Should we run STUN =20 inside or outside the DTLS session? It seems to be that we should have a consistent =20 decision here. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 10:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSmr-0005Oy-4V; Thu, 05 Apr 2007 10:18:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSmp-0005Oa-75 for mmusic@ietf.org; Thu, 05 Apr 2007 10:18:03 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSmn-00068e-Vq for mmusic@ietf.org; Thu, 05 Apr 2007 10:18:03 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E54C151931; Thu, 5 Apr 2007 10:18:00 -0400 (EDT) Message-ID: <46150516.5080308@pjsip.org> Date: Thu, 05 Apr 2007 15:17:58 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> In-Reply-To: <4614FA39.30403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: > Well, much as a hate timers, its probably the only option here. With > agressive nomination, if you wair one STUN transaction lifetime after > you've entered completed, you can free up resources since there > shouldn't be any further changes after that. Can't we use the arrival of RTP packets for this purpose? We know that once we receive an RTP packet, each component in peer for this stream has a valid pair. This wouldn't work perfectly when peer is using aggressive mode though, since some checks may still be running in peer even if it has begun sending RTP packets, so if we close the unused ports now those checks will fail. But on the other hand, by closing these unused ports now, it ensures that there will be no change in the selected candidate in peer. -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 10:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTE6-0004Po-Ac; Thu, 05 Apr 2007 10:46:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTE5-0004Oi-7x for mmusic@ietf.org; Thu, 05 Apr 2007 10:46:13 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTAc-0001FJ-FS for mmusic@ietf.org; Thu, 05 Apr 2007 10:42:39 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9DD19519DB; Thu, 5 Apr 2007 10:42:37 -0400 (EDT) Message-ID: <46150ADB.5040903@pjsip.org> Date: Thu, 05 Apr 2007 15:42:35 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE 15: Triggered check clarification References: <4612927F.2060300@pjsip.org> <4614E858.9080107@cisco.com> <4614F3CA.2090003@pjsip.org> <4614F8BA.2060007@cisco.com> In-Reply-To: <4614F8BA.2060007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: > Sure, but the check lists always have the local candidate replaced with > its base. So if it was server reflexive, it would be replaced by its > corresponding host candidate. So, irregardless of priority, there is > NEVER a check on the check list whose local candidate is server reflexive. Ah right, it seems that I misunderstood this phrase in 5.7.5 Pruning the Pairs: For each pair where the local candidate is server reflexive, the server reflexive candidate MUST be replaced by its base. Silly as it is, I thought base means the base address, not the host candidate representing this base address. Never mind, my mistake. Thanks, -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 12:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUkN-0002AV-JE; Thu, 05 Apr 2007 12:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUkM-0002AK-O8 for mmusic@ietf.org; Thu, 05 Apr 2007 12:23:38 -0400 Received: from sd-green-bigip-83.dreamhost.com ([208.97.132.83] helo=randymail-a2.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZUkL-0005yU-Ej for mmusic@ietf.org; Thu, 05 Apr 2007 12:23:38 -0400 Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id C114FEEB8C; Thu, 5 Apr 2007 09:23:36 -0700 (PDT) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9ABEF1CC69; Thu, 5 Apr 2007 09:22:07 -0700 (PDT) Date: Thu, 05 Apr 2007 09:22:07 -0700 From: Eric Rescorla To: Philip Matthews Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS In-Reply-To: <89FE093C-9815-4D71-BB8E-0AC98869BDCD@magma.ca> References: <46088071.3020905@cisco.com> <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> <200704051016.21190.remi.denis-courmont@nokia.com> <89FE093C-9815-4D71-BB8E-0AC98869BDCD@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20070405162207.9ABEF1CC69@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At Thu, 5 Apr 2007 09:59:30 -0400, Philip Matthews wrote: >=20 >=20 > On 5-Apr-07, at 03:16 , R=E9mi Denis-Courmont wrote: >=20 > > On Wednesday 04 April 2007 23:38:43 ext Philip Matthews wrote: > >> I don't know a lot about TLS, so please correct me if I am wrong, but > >> it seems to be that TLS is best viewed as a layer that runs on top of > >> TCP. > > > > TLS runs on top of a reliable, ordered, bytes stream. This is =20 > > typically TCP, > > but can be something else (I see no reason why TLS would not work =20 > > on top of > > SCTP or even IPX/SPX ;-) ). > > >=20 > Is a TLS session bound to a pair of transport addresses, or can it be =20 > moved > from one pair to another? That is, if I have an connection up on one =20 > valid candidate pair, > and later want to move it to another valid candidate pair, do I have =20 > to start a new TLS > session, or is there someway to move the existing session to the new =20 > candidate pair? Well, TLS doesn't know one way or another. It just assumes it has a reliable bytestream. But What you're suggesting pretty seriously violated TLS metaphor, so I would advise against it. > Also, what is the right way to do DTLS over UDP? Should we run STUN =20 > inside or outside > the DTLS session? It seems to be that we should have a consistent =20 > decision here. I think the right thing is the current thing: to demux DTLS versus STUN. I.e. run them in parallel. -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 12:24:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUlZ-0002It-9R; Thu, 05 Apr 2007 12:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUlX-0002Ij-U1 for mmusic@ietf.org; Thu, 05 Apr 2007 12:24:51 -0400 Received: from mailbigip.dreamhost.com ([208.97.132.5] helo=randymail-a2.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZUlW-00067J-Lo for mmusic@ietf.org; Thu, 05 Apr 2007 12:24:51 -0400 Received: from delta.rtfm.com (unknown [74.95.2.169]) by randymail-a2.g.dreamhost.com (Postfix) with ESMTP id 1A682EEBAB; Thu, 5 Apr 2007 09:24:50 -0700 (PDT) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1A0A01CC69; Thu, 5 Apr 2007 09:23:21 -0700 (PDT) Date: Thu, 05 Apr 2007 09:23:21 -0700 From: Eric Rescorla To: =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS In-Reply-To: <200704051016.21190.remi.denis-courmont@nokia.com> References: <46088071.3020905@cisco.com> <9D75B103-A02E-453F-9D8B-64D42194E02C@magma.ca> <200704051016.21190.remi.denis-courmont@nokia.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20070405162321.1A0A01CC69@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mmusic@ietf.org, ext Philip Matthews X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At Thu, 5 Apr 2007 10:16:20 +0300, R=E9mi Denis-Courmont wrote: >=20 > On Wednesday 04 April 2007 23:38:43 ext Philip Matthews wrote: > > I don't know a lot about TLS, so please correct me if I am wrong, but > > it seems to be that TLS is best viewed as a layer that runs on top of > > TCP. >=20 > TLS runs on top of a reliable, ordered, bytes stream. This is typically T= CP,=20 > but can be something else (I see no reason why TLS would not work on top = of=20 > SCTP or even IPX/SPX ;-) ). In fact it's already been bound to SCTP. > It definitely can theoretically run on top of STUN/TCP. The issue is whet= her=20 > this is practical or not: Most TLS stacks are biased toward using a BSD=20 > socket or equivalent, and it is either intricate, or maybe impossible wit= h=20 > some stacks, to use something else (without rewriting the stack). Hmm... As far as I know, most stacks have pluggable IO abstractions. Certainly OpenSSL does and the Java stacks I know of are built on Socket which can be subclassed... -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 14:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZX9D-0005Bv-Sr; Thu, 05 Apr 2007 14:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZX9D-0005A1-5s for mmusic@ietf.org; Thu, 05 Apr 2007 14:57:27 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZX98-0003oC-Un for mmusic@ietf.org; Thu, 05 Apr 2007 14:57:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 5 Apr 2007 14:57:23 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D52F@m5tmail1.m5t.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Thread-Index: Acd3tD5joyWfI0rOQHeJWuCrugB2OQ== From: "Eric Tremblay" To: , , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, John, I have read the (detailled) transcripts from MMUSIC where no concensus was achieved on this and the Friday sipping meeting notes where this was finally approved.=20 I think John wants to have a light mechanism that dual IP stack hosts can easily implement, and I have to fully agree with him. Simply put, my feeling is that ICE is too heavy weight on many accounts when someone just wants to run SIP on a dual IP stack: - Increased licensing costs: Need to buy an ICE component (more money for the company I work for!) - Increased development costs: Need to properly integrate ICE, complex interations with RTP stack, much more complex to test. - Increased hardware costs: Added functionality requires additional rom and ram ICE-lite, which is a lot less complex, is still too complex when all that is required is dual stack support. But, it is useless to talk about ICE-lite if it does not support the addition of multiple host candidates for a single component. An implementation of ICE-lite would not solve this problem and we have to resort to an ICE-full implementation. Something that in my opinion is too much to ask. Thus, my feeling as a protocol stack developer is that our customers will not buy ICE if they plan to develop simple dual IP stack devices. They will thus most probably rely on ANAT. We need to somehow define an evolutionary path towards ICE, and I wonder which path is the easiest for overall interop: ICE interop with ANAT or ICE interop with ICE micro-lite Collectively our 5 cents, Eric Tremblay & Guylain Lavoie ----------------------------------------------------- Eric Tremblay, Guylain Lavoie Technical Product Managers www.M5T.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 15:50:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXyd-0002k2-Cc; Thu, 05 Apr 2007 15:50:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXyV-0002i9-4s; Thu, 05 Apr 2007 15:50:27 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXyK-0004dJ-CC; Thu, 05 Apr 2007 15:50:27 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AEE0826F54; Thu, 5 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZXy6-00046J-Is; Thu, 05 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) for Media Loopback Author(s) : K. Hedayat, et al. Filename : draft-ietf-mmusic-media-loopback-06.txt Pages : 23 Date : 2007-4-5 The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-media-loopback-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-media-loopback-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-5141624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-media-loopback-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-media-loopback-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-5141624.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Apr 05 18:24:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZaN1-0007Td-6T; Thu, 05 Apr 2007 18:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZaMz-0007TX-Ua for mmusic@ietf.org; Thu, 05 Apr 2007 18:23:53 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZaMw-0005AX-K1 for mmusic@ietf.org; Thu, 05 Apr 2007 18:23:53 -0400 Received: from [192.168.0.66] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 5B5EA5190F for ; Thu, 5 Apr 2007 18:23:46 -0400 (EDT) Message-ID: <461576F6.8060706@pjsip.org> Date: Thu, 05 Apr 2007 23:23:50 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [MMUSIC] ICE-15: handling check list that completes early X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org All, I came across this scenario which I couldn't find the answer in the draft. Apologies if this has been discussed before. What should answerer do when it completes all the check lists before receiving any checks from offerer? This happens on this scenario. The answerer starts the check as soon as it sends answer. The offerer receives this check before SDP, and it responds with successful response. The answerer receives the response, starts other checks, gets the successful response again, and so on until finally all check lists are exhausted. And all of these happens before offerer receives the SDP answer, or in other words, the offerer can't send checks yet. But although the check lists have completed, the answerer still hasn't got a nominated pair yet, since it hasn't received Binding request with USE-CANDIDATE yet. So what should the answerer do here? I think probably it should do something like this: - it should wait until it receives check with USE-CANDIDATE set (what if it never receives this?) - when a check with USE-CANDIDATE arrives, it needs to scan the valid list for matching pair and set the nominated flag to true, and do section 8.2 again. Comments? thanks, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 20:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZc1S-0003YU-5I; Thu, 05 Apr 2007 20:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZc1Q-0003YP-VD for mmusic@ietf.org; Thu, 05 Apr 2007 20:09:44 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZc1O-00053I-6p for mmusic@ietf.org; Thu, 05 Apr 2007 20:09:44 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3609Wm01288; Fri, 6 Apr 2007 00:09:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 5 Apr 2007 19:09:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEA6627@zrc2hxm0.corp.nortel.com> In-Reply-To: <4614E9DA.7040100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition thread-index: Acd3fSV926yfo6leQ7CMU+EqFIll3wAYaIPA References: <50B1CBA96870A34799A506B2313F26670B7813A6@ntht201e.siemenscomms.co.uk> <4614E9DA.7040100@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, This proposal would NOT attempt to solve NAT traversal problem. In order to work, the "default" would be to use FULL ICE. Only if both sides indicate support for Microlite would it be used. Otherwise, Normal ICE would be done. In order to advertize Microlite, you'd have to know that you are not behind a NAT (and so would the other side). That proposal would support RFC 3484 fine. Again, it would only be applicable when there is no NAT. It is indeed semantically equivalent to ANAT, but it has=20 the advantage that it is compatible with full-ICE (i.e, if the other side doesn't support microlite).=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, April 05, 2007 05:22 > To: Elwell, John > Cc: mmusic@ietf.org > Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition >=20 > John, >=20 > I think this defeats the entire purpose of why we had=20 > selected ICE to deprecate ANAT. What you are proposing below=20 > is nothing more than a syntactic transformation of ANAT into=20 > ICE. This loses all of the benefits ICE brings (dynamic path=20 > selection, ability to run RFC 3484, etc.), and also=20 > introduces a mode that will not interoperate properly with=20 > regular ICE endpoints. Remember, the reason ice-lite requires=20 > an implementation to receive checks and respond to them, is=20 > that this is necessary for the full ice implementation to=20 > achieve nat traversal. With your proposal, a full ICE=20 > implementation would get no NAT traversal benefits when=20 > communicating with an ice micro-lite endpoint. >=20 > -Jonathan R. >=20 > Elwell, John wrote: >=20 > > There was strong consensus at IETF68 to deprecate ANAT and=20 > use ICE as=20 > > the sole way of negotiating between IPv4 and IPv6 for=20 > media. However,=20 > > there was some concern about this raising the bar too high=20 > for those=20 > > who require to support IPv6 ahead of full ICE. While many=20 > markets may=20 > > require ICE for NAT traversal before they require IPv6, there are=20 > > certain customers demanding > > IPv6 transition capabilities at an early stage, and needing to do a=20 > > full ICE implementation to satisfy these customers can be=20 > undesirable. > >=20 > > To satisfy this market, the requirement is for an offer to=20 > include two=20 > > candidates, one IPv4 and the other IPv6. For backwards=20 > compatibility=20 > > with > > IPv4 non-ICE implementations, the IPv4 candidate would be=20 > the default.=20 > > The answerer should be able to select one of these and the=20 > call should=20 > > be able to continue without a connectivity check. Removal of=20 > > connectivity checks would considerably simplify the=20 > implementation of=20 > > ICE for IPv4/IPV6 negotiation in these environments. Compatibility=20 > > with full or lite ICE implementations would have to be=20 > provided, of course. > >=20 > > Thus we would really only use the SDP enhancements of ICE,=20 > and not the rest. > > Compared with ANAT it has the advantages of better backward=20 > > compatibility with existing IPv4 devices and being a step=20 > on the path towards full ICE. > >=20 > > ICE lite goes some way to lowering the bar for implementing=20 > ICE, but=20 > > it does not solve the present problem for two reasons: > > 1) An ICE lite implementation cannot propose two candidates. > > 2) An ICE lite implementation is still required to support=20 > > connectivity checks as a server. > >=20 > > It seems that the requirements above could be supported by a fairly=20 > > small change to ICE, along the following lines. I will call this an=20 > > ICE "micro-lite" implementation. > >=20 > > When sending an offer, a dual stack ICE "micro-lite" implementation=20 > > would include two candidates, one based on IPv4 (the default=20 > > candidate) and the other based on IPv6. It would also=20 > include a flag=20 > > (e.g., an option tag) to indicate that it supports only=20 > "micro-lite"=20 > > and therefore will not do connectivity checks. The answerer would=20 > > choose the IP protocol and respond with an IP address for that=20 > > protocol in the c-line. If IPv6 is chosen, the offerer=20 > would need to=20 > > do a further offer to promote its IPv6 address and port to=20 > the m/c line. > >=20 > > If the answerer is a full (or lite) implementation, it=20 > would use the=20 > > received "micro-lite" indicator to behave as above and suppress=20 > > testing. If the offerer is a full implementation, it sees that the=20 > > answerer does not support full or lite ICE (because it does=20 > not return=20 > > any candidate lines) but would use the fact that the c-line=20 > contains=20 > > an IPv6 address to select its IPv6 host candidate, use it=20 > in the m/c=20 > > line of a new offer, and suppress testing. > >=20 > > The above would represents quite a small change to ICE and could=20 > > probably be accommodated in the ICE RFC rather than a=20 > separate RFC. In=20 > > this way it would be easier to force support of micro-lite=20 > by all ICE implementations. > >=20 > > As a further enhancement, perhaps ICE-lite could allow the=20 > inclusion=20 > > of two candidates, where one is IPv4 and the other is IPv6. ICE=20 > > micro-lite would then be a subset of ICE-lite. There would=20 > then be a=20 > > natural evolution path for implementations, from=20 > micro-lite, via lite to full ICE. > >=20 > > John > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 21:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZcs9-00006x-DY; Thu, 05 Apr 2007 21:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZcs7-00006s-Rh for mmusic@ietf.org; Thu, 05 Apr 2007 21:04:11 -0400 Received: from bay0-omc2-s10.bay0.hotmail.com ([65.54.246.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZcs6-00076X-94 for mmusic@ietf.org; Thu, 05 Apr 2007 21:04:11 -0400 Received: from bayc1-pasmtp08.bayc1.hotmail.com ([65.54.191.168]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 5 Apr 2007 18:04:10 -0700 X-Originating-IP: [70.51.208.25] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([70.51.208.25]) by bayc1-pasmtp08.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 18:04:08 -0700 Message-ID: <027301c777e7$79035240$65500a0a@ronin> From: "Eric Cooper" To: "Francois Audet" , "Jonathan Rosenberg" , "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670B7813A6@ntht201e.siemenscomms.co.uk><4614E9DA.7040100@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FEA6627@zrc2hxm0.corp.nortel.com> Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 5 Apr 2007 21:02:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 06 Apr 2007 01:04:09.0802 (UTC) FILETIME=[7B976AA0:01C777E7] X-Spam-Score: 2.1 (++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I guess I'm missing something here... When a micro-lite ICE implementation makes an offer, is it prepared to = perform full ICE processing if the answer doesn't indicate support for = micro-lite? I would have thought not, because I thought the whole point of = micro-lite was that full ICE or even ICE-lite was too complicated. = However, I can't reconcile that guess with your statement below that = full ICE is the default. What did I miss? Thanks, Eric. ----- Original Message -----=20 From: "Francois Audet" To: "Jonathan Rosenberg" ; "Elwell, John" = Cc: Sent: Thursday, April 05, 2007 8:09 PM Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Jonathan, This proposal would NOT attempt to solve NAT traversal problem. In order to work, the "default" would be to use FULL ICE. Only if both sides indicate support for Microlite would it be used. Otherwise, Normal ICE would be done. In order to advertize Microlite, you'd have to know that you are not behind a NAT (and so would the other side). That proposal would support RFC 3484 fine. Again, it would only be applicable when there is no NAT. It is indeed semantically equivalent to ANAT, but it has=20 the advantage that it is compatible with full-ICE (i.e, if the other side doesn't support microlite).=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, April 05, 2007 05:22 > To: Elwell, John > Cc: mmusic@ietf.org > Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition >=20 > John, >=20 > I think this defeats the entire purpose of why we had=20 > selected ICE to deprecate ANAT. What you are proposing below=20 > is nothing more than a syntactic transformation of ANAT into=20 > ICE. This loses all of the benefits ICE brings (dynamic path=20 > selection, ability to run RFC 3484, etc.), and also=20 > introduces a mode that will not interoperate properly with=20 > regular ICE endpoints. Remember, the reason ice-lite requires=20 > an implementation to receive checks and respond to them, is=20 > that this is necessary for the full ice implementation to=20 > achieve nat traversal. With your proposal, a full ICE=20 > implementation would get no NAT traversal benefits when=20 > communicating with an ice micro-lite endpoint. >=20 > -Jonathan R. >=20 > Elwell, John wrote: >=20 > > There was strong consensus at IETF68 to deprecate ANAT and=20 > use ICE as=20 > > the sole way of negotiating between IPv4 and IPv6 for=20 > media. However,=20 > > there was some concern about this raising the bar too high=20 > for those=20 > > who require to support IPv6 ahead of full ICE. While many=20 > markets may=20 > > require ICE for NAT traversal before they require IPv6, there are=20 > > certain customers demanding > > IPv6 transition capabilities at an early stage, and needing to do a=20 > > full ICE implementation to satisfy these customers can be=20 > undesirable. > >=20 > > To satisfy this market, the requirement is for an offer to=20 > include two=20 > > candidates, one IPv4 and the other IPv6. For backwards=20 > compatibility=20 > > with > > IPv4 non-ICE implementations, the IPv4 candidate would be=20 > the default.=20 > > The answerer should be able to select one of these and the=20 > call should=20 > > be able to continue without a connectivity check. Removal of=20 > > connectivity checks would considerably simplify the=20 > implementation of=20 > > ICE for IPv4/IPV6 negotiation in these environments. Compatibility=20 > > with full or lite ICE implementations would have to be=20 > provided, of course. > >=20 > > Thus we would really only use the SDP enhancements of ICE,=20 > and not the rest. > > Compared with ANAT it has the advantages of better backward=20 > > compatibility with existing IPv4 devices and being a step=20 > on the path towards full ICE. > >=20 > > ICE lite goes some way to lowering the bar for implementing=20 > ICE, but=20 > > it does not solve the present problem for two reasons: > > 1) An ICE lite implementation cannot propose two candidates. > > 2) An ICE lite implementation is still required to support=20 > > connectivity checks as a server. > >=20 > > It seems that the requirements above could be supported by a fairly=20 > > small change to ICE, along the following lines. I will call this an=20 > > ICE "micro-lite" implementation. > >=20 > > When sending an offer, a dual stack ICE "micro-lite" implementation=20 > > would include two candidates, one based on IPv4 (the default=20 > > candidate) and the other based on IPv6. It would also=20 > include a flag=20 > > (e.g., an option tag) to indicate that it supports only=20 > "micro-lite"=20 > > and therefore will not do connectivity checks. The answerer would=20 > > choose the IP protocol and respond with an IP address for that=20 > > protocol in the c-line. If IPv6 is chosen, the offerer=20 > would need to=20 > > do a further offer to promote its IPv6 address and port to=20 > the m/c line. > >=20 > > If the answerer is a full (or lite) implementation, it=20 > would use the=20 > > received "micro-lite" indicator to behave as above and suppress=20 > > testing. If the offerer is a full implementation, it sees that the=20 > > answerer does not support full or lite ICE (because it does=20 > not return=20 > > any candidate lines) but would use the fact that the c-line=20 > contains=20 > > an IPv6 address to select its IPv6 host candidate, use it=20 > in the m/c=20 > > line of a new offer, and suppress testing. > >=20 > > The above would represents quite a small change to ICE and could=20 > > probably be accommodated in the ICE RFC rather than a=20 > separate RFC. In=20 > > this way it would be easier to force support of micro-lite=20 > by all ICE implementations. > >=20 > > As a further enhancement, perhaps ICE-lite could allow the=20 > inclusion=20 > > of two candidates, where one is IPv4 and the other is IPv6. ICE=20 > > micro-lite would then be a subset of ICE-lite. There would=20 > then be a=20 > > natural evolution path for implementations, from=20 > micro-lite, via lite to full ICE. > >=20 > > John > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 23:05:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZeka-0005Yo-K3; Thu, 05 Apr 2007 23:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZekZ-0005Nm-4O for mmusic@ietf.org; Thu, 05 Apr 2007 23:04:31 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZekX-0006hb-UR for mmusic@ietf.org; Thu, 05 Apr 2007 23:04:31 -0400 Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l3634Q4T025816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Apr 2007 23:04:26 -0400 (EDT) Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l3634Qxn019724 for ; Thu, 5 Apr 2007 23:04:26 -0400 (EDT) Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l3634PI7019721; Thu, 5 Apr 2007 23:04:25 -0400 (EDT) X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to lennox@cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17941.47289.862013.55076@metro-north.cs.columbia.edu> Date: Thu, 5 Apr 2007 23:04:25 -0400 To: mmusic@ietf.org In-Reply-To: <4614FA39.30403@cisco.com> References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> X-Mailer: VM 7.19 under Emacs 20.7.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [MMUSIC] ICE-15: What happens if a connectivity check gets 300 Try Alternate? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org How should an ICE endpoint handle receiving a 300 Try Alternate STUN error response to a connectivity check request? Should it actually send a connectivity check to the ALTERNATE-SERVER address listed in the 300, and if so should it treat the alternate server as a new remote peer-reflexive candidate? Or should it just consider the connectivity check to have failed, as with other error responses to the check request? Other than 300, I think the rest of the STUN error response codes defined by 3489bis (i.e., other than 487 Role Conflict) should indeed cause a connectivity check to fail. (The only other potential case in which different behavior might be useful would be 500 Server Error, but I don't think retrying a failing connectivity check is a good idea.) -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 05 23:18:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZey7-0006Q6-V3; Thu, 05 Apr 2007 23:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZey6-0006IA-QQ for mmusic@ietf.org; Thu, 05 Apr 2007 23:18:30 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZey4-0000IH-9x for mmusic@ietf.org; Thu, 05 Apr 2007 23:18:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 5 Apr 2007 23:18:30 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D569@m5tmail1.m5t.com> In-Reply-To: <027301c777e7$79035240$65500a0a@ronin> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Thread-Index: Acd359md3EcJubTeRMOXQHEFI7lpigAAJpAg From: "Guylain Lavoie" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi everyone, If I may comment, here is how I see this. An endpoint that sends an offer with ICE-micro-lite indicates that he wants to perform the micro-lite variation of the protocol and that it will not perform ICE-lite or ICE-full. He is only proposing two candidates that he knows are always be accessible. ICE-micro-lite is so easy compared to ICE-lite or ICE-full that I think its support must be mandated in the specification. An endpoint supporting ICE-full or ICE-lite that receives an ICE-micro-lite offer needs to understand that the offerer will not do advance ICE processing. The answerer will then choose between the two proposed candidates (IPv4 and IPv6). He must act somewhat like the offerer only supported ANAT, not ICE. He must then send back the answer. The answerer may indicate support for ICE-micro-lite or ICE-lite or nothing if ICE-full is supported. This is only an indication of its capabilities to the offerer (like when the answerer can add additional supported payload type not present in the offer as permitted by rfc3264). An endpoint supporting only ICE-micro-lite that receives an ICE-lite or ICE-full offer will choose one of the proposed candidates and then send back the answer with the indication that he is only doing ICE-micro-lite. This is all based on the assumption that endpoints which support ICE-lite or ICE-full always support ICE-micro-lite. In the end, it is all about making sure that ANAT is deprecated as soon as possible and that a common and better syntax (ICE) is used by all providers. I would rather prefer to support an additional ICE method than have to support both ANAT and ICE at the same time. By the way, can someone more knowledgeable than me explain why ICE-lite cannot include more than one host candidate per component when he knows that both are always accessible? Is this an arbitrary decision or is there something that does not allow this? Regards, Guylain Lavoie -----Original Message----- From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca]=20 Sent: April 5, 2007 9:03 PM To: Francois Audet; Jonathan Rosenberg; Elwell, John Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition I guess I'm missing something here... When a micro-lite ICE implementation makes an offer, is it prepared to perform full ICE processing if the answer doesn't indicate support for micro-lite? I would have thought not, because I thought the whole point of micro-lite was that full ICE or even ICE-lite was too complicated. However, I can't reconcile that guess with your statement below that full ICE is the default. What did I miss? Thanks, Eric. ----- Original Message ----- From: "Francois Audet" To: "Jonathan Rosenberg" ; "Elwell, John" Cc: Sent: Thursday, April 05, 2007 8:09 PM Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Jonathan, This proposal would NOT attempt to solve NAT traversal problem. In order to work, the "default" would be to use FULL ICE. Only if both sides indicate support for Microlite would it be used. Otherwise, Normal ICE would be done. In order to advertize Microlite, you'd have to know that you are not behind a NAT (and so would the other side). That proposal would support RFC 3484 fine. Again, it would only be applicable when there is no NAT. It is indeed semantically equivalent to ANAT, but it has=20 the advantage that it is compatible with full-ICE (i.e, if the other side doesn't support microlite).=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, April 05, 2007 05:22 > To: Elwell, John > Cc: mmusic@ietf.org > Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition >=20 > John, >=20 > I think this defeats the entire purpose of why we had=20 > selected ICE to deprecate ANAT. What you are proposing below=20 > is nothing more than a syntactic transformation of ANAT into=20 > ICE. This loses all of the benefits ICE brings (dynamic path=20 > selection, ability to run RFC 3484, etc.), and also=20 > introduces a mode that will not interoperate properly with=20 > regular ICE endpoints. Remember, the reason ice-lite requires=20 > an implementation to receive checks and respond to them, is=20 > that this is necessary for the full ice implementation to=20 > achieve nat traversal. With your proposal, a full ICE=20 > implementation would get no NAT traversal benefits when=20 > communicating with an ice micro-lite endpoint. >=20 > -Jonathan R. >=20 > Elwell, John wrote: >=20 > > There was strong consensus at IETF68 to deprecate ANAT and=20 > use ICE as=20 > > the sole way of negotiating between IPv4 and IPv6 for=20 > media. However,=20 > > there was some concern about this raising the bar too high=20 > for those=20 > > who require to support IPv6 ahead of full ICE. While many=20 > markets may=20 > > require ICE for NAT traversal before they require IPv6, there are=20 > > certain customers demanding > > IPv6 transition capabilities at an early stage, and needing to do a=20 > > full ICE implementation to satisfy these customers can be=20 > undesirable. > >=20 > > To satisfy this market, the requirement is for an offer to=20 > include two=20 > > candidates, one IPv4 and the other IPv6. For backwards=20 > compatibility=20 > > with > > IPv4 non-ICE implementations, the IPv4 candidate would be=20 > the default.=20 > > The answerer should be able to select one of these and the=20 > call should=20 > > be able to continue without a connectivity check. Removal of=20 > > connectivity checks would considerably simplify the=20 > implementation of=20 > > ICE for IPv4/IPV6 negotiation in these environments. Compatibility=20 > > with full or lite ICE implementations would have to be=20 > provided, of course. > >=20 > > Thus we would really only use the SDP enhancements of ICE,=20 > and not the rest. > > Compared with ANAT it has the advantages of better backward=20 > > compatibility with existing IPv4 devices and being a step=20 > on the path towards full ICE. > >=20 > > ICE lite goes some way to lowering the bar for implementing=20 > ICE, but=20 > > it does not solve the present problem for two reasons: > > 1) An ICE lite implementation cannot propose two candidates. > > 2) An ICE lite implementation is still required to support=20 > > connectivity checks as a server. > >=20 > > It seems that the requirements above could be supported by a fairly=20 > > small change to ICE, along the following lines. I will call this an=20 > > ICE "micro-lite" implementation. > >=20 > > When sending an offer, a dual stack ICE "micro-lite" implementation=20 > > would include two candidates, one based on IPv4 (the default=20 > > candidate) and the other based on IPv6. It would also=20 > include a flag=20 > > (e.g., an option tag) to indicate that it supports only=20 > "micro-lite"=20 > > and therefore will not do connectivity checks. The answerer would=20 > > choose the IP protocol and respond with an IP address for that=20 > > protocol in the c-line. If IPv6 is chosen, the offerer=20 > would need to=20 > > do a further offer to promote its IPv6 address and port to=20 > the m/c line. > >=20 > > If the answerer is a full (or lite) implementation, it=20 > would use the=20 > > received "micro-lite" indicator to behave as above and suppress=20 > > testing. If the offerer is a full implementation, it sees that the=20 > > answerer does not support full or lite ICE (because it does=20 > not return=20 > > any candidate lines) but would use the fact that the c-line=20 > contains=20 > > an IPv6 address to select its IPv6 host candidate, use it=20 > in the m/c=20 > > line of a new offer, and suppress testing. > >=20 > > The above would represents quite a small change to ICE and could=20 > > probably be accommodated in the ICE RFC rather than a=20 > separate RFC. In=20 > > this way it would be easier to force support of micro-lite=20 > by all ICE implementations. > >=20 > > As a further enhancement, perhaps ICE-lite could allow the=20 > inclusion=20 > > of two candidates, where one is IPv4 and the other is IPv6. ICE=20 > > micro-lite would then be a subset of ICE-lite. There would=20 > then be a=20 > > natural evolution path for implementations, from=20 > micro-lite, via lite to full ICE. > >=20 > > John > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 06 09:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZoQT-0004La-Gb; Fri, 06 Apr 2007 09:24:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZoQS-0004LV-04 for mmusic@ietf.org; Fri, 06 Apr 2007 09:24:24 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZoQQ-0003R6-ID for mmusic@ietf.org; Fri, 06 Apr 2007 09:24:23 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l36DOLZQ000602 for ; Fri, 6 Apr 2007 07:24:21 -0600 (MDT) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Fri, 6 Apr 2007 07:24:21 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Notes from RTSP Review team, Tuesday April 3rd Date: Fri, 6 Apr 2007 07:24:20 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Notes from RTSP Review team, Tuesday April 3rd Thread-Index: Acd4TuuylUYu4sbBTmqoCsptLgdkJg== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Folks, Below are the meeting notes from the RTSP Review Team conference call we had on Tuesday April 3. Our next call is scheduled for Wednesday April 18. Jean-Francois. --- RTSP/2.0 Review Team=20 Tuesday April 3, 9am-10am Pacific, 12noon-1pm Eastern, and 6-7pm Western Europe. --- Participants Magnus Westerlund Dave Singer Jamie Gordon Sean Sheedy Reinaldo Penno Colin Perkins Henning Schulzrinne Jean-Francois Mule --- Agenda 1/ Introductions 2/ Objectives for the RTSP review team 3/ Open issue list and logistics 4/ Timeline for ID updates --- Materials http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-14.txt https://sourceforge.net/projects/rtspspec mmusic list for rtsp threads --- Brief Notes=20 1/ Intros 2/ Objectives for the RTSP review team A few folks commented on the objectives for the next round of updates of the RTSP/2.0 draft: - Jean-Francois: the main objectives are to resolve technical issues, improve the readability of the document, get more reviews from RTSP implementers and get the Internet-Draft ready for publication. - Henning: having co-authored RTSP/1.0, Henning insisted on a document update that reflect best current practices and experiences. It should also ties in with other work in SIP arena, like NAT and firewall traversal in particular. - Magnus: has been working too far long on this update, just wants to get it done. Magnus indicated we should be open to document re-organization to get the spec shorter (split some things into other documents as appropriate if necessary). - Magnus: what is in the field now is not based on RTSP/1.0 so it would be nice to see an upgrade path to 2.0 for what is currently implemented. We should consider one or two good feature additions, may be things like: - session setup establishment enhancements, - NAT traversal (separate document?) Dave, Jamie and Magnus had a brief chat about the list of what's in the 2.0 draft vs. 1.0 (see the Appendix for details). Jamie indicated that this section needs review as it may not be complete. It was agreed that the Internet-Draft document should be converted to xml to use the IETF tools like xml2rfc. Henning will take a first stab at it and provide a rough xml draft to the review team by April 10 or so. We will then split up the spec into sections (more manageable documents given the size) and folks on the review team will fix things manually in the converted xml (e.g. some tags may not get closed properly, figures, etc.). The Tex sources are available on sourceforge. 3/ Open issue list and logistics We will use the sourceforge project page as our base: https://sourceforge.net/projects/rtspspec Colin reminded everyone that the mmusic list must be used for all technical discussions, and that meeting notes from the review meetings will be posted to the mmusic list. We also agreed to create a new email reflector for the members of the review team to facilitate discussions among the reviewers and for editorial stuff: https://lists.sourceforge.net/lists/listinfo/rtspspec-reviewers The open issue list below is based on the sourceforge's bugs: 1692711 Clarify when RTCP is needed RTSP context 1605339 Clarify the meaing of a=3Drecvonly and sendonly 1601668 Clarify what the Server may send in Range compared with SDP 1600409 Resolve EKR's Security comments 1599785 Proposal to create range of private error codes 1599774 Resolve Sec comments 1599730 Session ID is not providing real security 1599715 Clarify Section B.2.2 on when TCP connection estbl happens 1599707 Clarify Independent TCP (Section B.2.2) Jean-Francois will split EKR's security comments into multiple issues. It was agreed to allow more time for folks to prepare so we did not go through the open issues in detail. 4/ Timeline for ID updates It would be good to have at least 2 updates prior to the next IETF meeting. We concluded the call by setting up the date and time for the next call: Wednesday April 18, 9am-10am Pacific, 12noon-1pm Eastern, and 6-7pm Western Europe. > end. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 06 10:59:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZptz-00079a-Ot; Fri, 06 Apr 2007 10:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpty-00079U-Qd for mmusic@ietf.org; Fri, 06 Apr 2007 10:58:58 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZptx-00045H-CR for mmusic@ietf.org; Fri, 06 Apr 2007 10:58:58 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l36Ewru03723; Fri, 6 Apr 2007 14:58:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Fri, 6 Apr 2007 09:58:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FEA6929@zrc2hxm0.corp.nortel.com> In-Reply-To: <027301c777e7$79035240$65500a0a@ronin> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition thread-index: Acd3534lSoT/cvn0SOC+7QDzGYizowAdGWHw References: <50B1CBA96870A34799A506B2313F26670B7813A6@ntht201e.siemenscomms.co.uk><4614E9DA.7040100@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FEA6627@zrc2hxm0.corp.nortel.com> <027301c777e7$79035240$65500a0a@ronin> From: "Francois Audet" To: "Eric Cooper" , "Jonathan Rosenberg" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org You could do what you said, but then you wouldn't be able to do NAT traversal.=20 And, more importantly, the other end wouldn't either. > -----Original Message----- > From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca]=20 > Sent: Thursday, April 05, 2007 18:03 > To: Audet, Francois (SC100:3055); Jonathan Rosenberg; Elwell, John > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6=20 > transition >=20 > I guess I'm missing something here... >=20 > When a micro-lite ICE implementation makes an offer, is it=20 > prepared to perform full ICE processing if the answer doesn't=20 > indicate support for micro-lite? >=20 > I would have thought not, because I thought the whole point=20 > of micro-lite was that full ICE or even ICE-lite was too=20 > complicated. However, I can't reconcile that guess with your=20 > statement below that full ICE is the default. >=20 > What did I miss? >=20 > Thanks, >=20 > Eric. >=20 >=20 >=20 > ----- Original Message ----- > From: "Francois Audet" > To: "Jonathan Rosenberg" ; "Elwell, John"=20 > > Cc: > Sent: Thursday, April 05, 2007 8:09 PM > Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6=20 > transition >=20 >=20 > Jonathan, >=20 > This proposal would NOT attempt to solve NAT traversal problem. >=20 > In order to work, the "default" would be to use FULL ICE. Only if > both sides indicate support for Microlite would it be used. Otherwise, > Normal ICE would be done. >=20 > In order to advertize Microlite, you'd have to know that you are not > behind a NAT (and so would the other side). >=20 > That proposal would support RFC 3484 fine. >=20 > Again, it would only be applicable when there is no NAT. >=20 > It is indeed semantically equivalent to ANAT, but it has=20 > the advantage that it is compatible with full-ICE (i.e, > if the other side doesn't support microlite).=20 >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > > Sent: Thursday, April 05, 2007 05:22 > > To: Elwell, John > > Cc: mmusic@ietf.org > > Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition > >=20 > > John, > >=20 > > I think this defeats the entire purpose of why we had=20 > > selected ICE to deprecate ANAT. What you are proposing below=20 > > is nothing more than a syntactic transformation of ANAT into=20 > > ICE. This loses all of the benefits ICE brings (dynamic path=20 > > selection, ability to run RFC 3484, etc.), and also=20 > > introduces a mode that will not interoperate properly with=20 > > regular ICE endpoints. Remember, the reason ice-lite requires=20 > > an implementation to receive checks and respond to them, is=20 > > that this is necessary for the full ice implementation to=20 > > achieve nat traversal. With your proposal, a full ICE=20 > > implementation would get no NAT traversal benefits when=20 > > communicating with an ice micro-lite endpoint. > >=20 > > -Jonathan R. > >=20 > > Elwell, John wrote: > >=20 > > > There was strong consensus at IETF68 to deprecate ANAT and=20 > > use ICE as=20 > > > the sole way of negotiating between IPv4 and IPv6 for=20 > > media. However,=20 > > > there was some concern about this raising the bar too high=20 > > for those=20 > > > who require to support IPv6 ahead of full ICE. While many=20 > > markets may=20 > > > require ICE for NAT traversal before they require IPv6, there are=20 > > > certain customers demanding > > > IPv6 transition capabilities at an early stage, and=20 > needing to do a=20 > > > full ICE implementation to satisfy these customers can be=20 > > undesirable. > > >=20 > > > To satisfy this market, the requirement is for an offer to=20 > > include two=20 > > > candidates, one IPv4 and the other IPv6. For backwards=20 > > compatibility=20 > > > with > > > IPv4 non-ICE implementations, the IPv4 candidate would be=20 > > the default.=20 > > > The answerer should be able to select one of these and the=20 > > call should=20 > > > be able to continue without a connectivity check. Removal of=20 > > > connectivity checks would considerably simplify the=20 > > implementation of=20 > > > ICE for IPv4/IPV6 negotiation in these environments.=20 > Compatibility=20 > > > with full or lite ICE implementations would have to be=20 > > provided, of course. > > >=20 > > > Thus we would really only use the SDP enhancements of ICE,=20 > > and not the rest. > > > Compared with ANAT it has the advantages of better backward=20 > > > compatibility with existing IPv4 devices and being a step=20 > > on the path towards full ICE. > > >=20 > > > ICE lite goes some way to lowering the bar for implementing=20 > > ICE, but=20 > > > it does not solve the present problem for two reasons: > > > 1) An ICE lite implementation cannot propose two candidates. > > > 2) An ICE lite implementation is still required to support=20 > > > connectivity checks as a server. > > >=20 > > > It seems that the requirements above could be supported=20 > by a fairly=20 > > > small change to ICE, along the following lines. I will=20 > call this an=20 > > > ICE "micro-lite" implementation. > > >=20 > > > When sending an offer, a dual stack ICE "micro-lite"=20 > implementation=20 > > > would include two candidates, one based on IPv4 (the default=20 > > > candidate) and the other based on IPv6. It would also=20 > > include a flag=20 > > > (e.g., an option tag) to indicate that it supports only=20 > > "micro-lite"=20 > > > and therefore will not do connectivity checks. The answerer would=20 > > > choose the IP protocol and respond with an IP address for that=20 > > > protocol in the c-line. If IPv6 is chosen, the offerer=20 > > would need to=20 > > > do a further offer to promote its IPv6 address and port to=20 > > the m/c line. > > >=20 > > > If the answerer is a full (or lite) implementation, it=20 > > would use the=20 > > > received "micro-lite" indicator to behave as above and suppress=20 > > > testing. If the offerer is a full implementation, it sees=20 > that the=20 > > > answerer does not support full or lite ICE (because it does=20 > > not return=20 > > > any candidate lines) but would use the fact that the c-line=20 > > contains=20 > > > an IPv6 address to select its IPv6 host candidate, use it=20 > > in the m/c=20 > > > line of a new offer, and suppress testing. > > >=20 > > > The above would represents quite a small change to ICE and could=20 > > > probably be accommodated in the ICE RFC rather than a=20 > > separate RFC. In=20 > > > this way it would be easier to force support of micro-lite=20 > > by all ICE implementations. > > >=20 > > > As a further enhancement, perhaps ICE-lite could allow the=20 > > inclusion=20 > > > of two candidates, where one is IPv4 and the other is IPv6. ICE=20 > > > micro-lite would then be a subset of ICE-lite. There would=20 > > then be a=20 > > > natural evolution path for implementations, from=20 > > micro-lite, via lite to full ICE. > > >=20 > > > John > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 06 13:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZs7A-0007sA-VF; Fri, 06 Apr 2007 13:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZs79-0007nx-Hm for mmusic@ietf.org; Fri, 06 Apr 2007 13:20:43 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZs77-0005L9-Se for mmusic@ietf.org; Fri, 06 Apr 2007 13:20:43 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JG300L4X6UCOG@siemenscomms.co.uk> for mmusic@ietf.org; Fri, 06 Apr 2007 18:20:36 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 06 Apr 2007 18:20:41 +0100 Content-return: allowed Date: Fri, 06 Apr 2007 18:20:39 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition To: Guylain Lavoie , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B7D7816@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Guylain, Yes, that is exactly the intention of micro-lite. John > -----Original Message----- > From: Guylain Lavoie [mailto:glavoie@m5t.com] > Sent: 06 April 2007 04:19 > To: mmusic@ietf.org > Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 > transition > > Hi everyone, > > If I may comment, here is how I see this. > > An endpoint that sends an offer with ICE-micro-lite indicates that he > wants to perform the micro-lite variation of the protocol and that it > will not perform ICE-lite or ICE-full. He is only proposing two > candidates that he knows are always be accessible. > ICE-micro-lite is so > easy compared to ICE-lite or ICE-full that I think its support must be > mandated in the specification. > > An endpoint supporting ICE-full or ICE-lite that receives an > ICE-micro-lite offer needs to understand that the offerer will not do > advance ICE processing. The answerer will then choose between the two > proposed candidates (IPv4 and IPv6). He must act somewhat like the > offerer only supported ANAT, not ICE. He must then send back > the answer. > The answerer may indicate support for ICE-micro-lite or ICE-lite or > nothing if ICE-full is supported. This is only an indication of its > capabilities to the offerer (like when the answerer can add additional > supported payload type not present in the offer as permitted by > rfc3264). > > An endpoint supporting only ICE-micro-lite that receives an > ICE-lite or > ICE-full offer will choose one of the proposed candidates and > then send > back the answer with the indication that he is only doing > ICE-micro-lite. > > This is all based on the assumption that endpoints which support > ICE-lite or ICE-full always support ICE-micro-lite. > > In the end, it is all about making sure that ANAT is > deprecated as soon > as possible and that a common and better syntax (ICE) is used by all > providers. I would rather prefer to support an additional ICE method > than have to support both ANAT and ICE at the same time. > > By the way, can someone more knowledgeable than me explain > why ICE-lite > cannot include more than one host candidate per component > when he knows > that both are always accessible? Is this an arbitrary decision or is > there something that does not allow this? > > Regards, > Guylain Lavoie > > -----Original Message----- > From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] > Sent: April 5, 2007 9:03 PM > To: Francois Audet; Jonathan Rosenberg; Elwell, John > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 > transition > > I guess I'm missing something here... > > When a micro-lite ICE implementation makes an offer, is it prepared to > perform full ICE processing if the answer doesn't indicate support for > micro-lite? > > I would have thought not, because I thought the whole point of > micro-lite was that full ICE or even ICE-lite was too complicated. > However, I can't reconcile that guess with your statement below that > full ICE is the default. > > What did I miss? > > Thanks, > > Eric. > > > > ----- Original Message ----- > From: "Francois Audet" > To: "Jonathan Rosenberg" ; "Elwell, John" > > Cc: > Sent: Thursday, April 05, 2007 8:09 PM > Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 > transition > > > Jonathan, > > This proposal would NOT attempt to solve NAT traversal problem. > > In order to work, the "default" would be to use FULL ICE. Only if > both sides indicate support for Microlite would it be used. Otherwise, > Normal ICE would be done. > > In order to advertize Microlite, you'd have to know that you are not > behind a NAT (and so would the other side). > > That proposal would support RFC 3484 fine. > > Again, it would only be applicable when there is no NAT. > > It is indeed semantically equivalent to ANAT, but it has > the advantage that it is compatible with full-ICE (i.e, > if the other side doesn't support microlite). > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, April 05, 2007 05:22 > > To: Elwell, John > > Cc: mmusic@ietf.org > > Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition > > > > John, > > > > I think this defeats the entire purpose of why we had > > selected ICE to deprecate ANAT. What you are proposing below > > is nothing more than a syntactic transformation of ANAT into > > ICE. This loses all of the benefits ICE brings (dynamic path > > selection, ability to run RFC 3484, etc.), and also > > introduces a mode that will not interoperate properly with > > regular ICE endpoints. Remember, the reason ice-lite requires > > an implementation to receive checks and respond to them, is > > that this is necessary for the full ice implementation to > > achieve nat traversal. With your proposal, a full ICE > > implementation would get no NAT traversal benefits when > > communicating with an ice micro-lite endpoint. > > > > -Jonathan R. > > > > Elwell, John wrote: > > > > > There was strong consensus at IETF68 to deprecate ANAT and > > use ICE as > > > the sole way of negotiating between IPv4 and IPv6 for > > media. However, > > > there was some concern about this raising the bar too high > > for those > > > who require to support IPv6 ahead of full ICE. While many > > markets may > > > require ICE for NAT traversal before they require IPv6, there are > > > certain customers demanding > > > IPv6 transition capabilities at an early stage, and > needing to do a > > > full ICE implementation to satisfy these customers can be > > undesirable. > > > > > > To satisfy this market, the requirement is for an offer to > > include two > > > candidates, one IPv4 and the other IPv6. For backwards > > compatibility > > > with > > > IPv4 non-ICE implementations, the IPv4 candidate would be > > the default. > > > The answerer should be able to select one of these and the > > call should > > > be able to continue without a connectivity check. Removal of > > > connectivity checks would considerably simplify the > > implementation of > > > ICE for IPv4/IPV6 negotiation in these environments. > Compatibility > > > with full or lite ICE implementations would have to be > > provided, of course. > > > > > > Thus we would really only use the SDP enhancements of ICE, > > and not the rest. > > > Compared with ANAT it has the advantages of better backward > > > compatibility with existing IPv4 devices and being a step > > on the path towards full ICE. > > > > > > ICE lite goes some way to lowering the bar for implementing > > ICE, but > > > it does not solve the present problem for two reasons: > > > 1) An ICE lite implementation cannot propose two candidates. > > > 2) An ICE lite implementation is still required to support > > > connectivity checks as a server. > > > > > > It seems that the requirements above could be supported > by a fairly > > > small change to ICE, along the following lines. I will > call this an > > > ICE "micro-lite" implementation. > > > > > > When sending an offer, a dual stack ICE "micro-lite" > implementation > > > would include two candidates, one based on IPv4 (the default > > > candidate) and the other based on IPv6. It would also > > include a flag > > > (e.g., an option tag) to indicate that it supports only > > "micro-lite" > > > and therefore will not do connectivity checks. The answerer would > > > choose the IP protocol and respond with an IP address for that > > > protocol in the c-line. If IPv6 is chosen, the offerer > > would need to > > > do a further offer to promote its IPv6 address and port to > > the m/c line. > > > > > > If the answerer is a full (or lite) implementation, it > > would use the > > > received "micro-lite" indicator to behave as above and suppress > > > testing. If the offerer is a full implementation, it sees > that the > > > answerer does not support full or lite ICE (because it does > > not return > > > any candidate lines) but would use the fact that the c-line > > contains > > > an IPv6 address to select its IPv6 host candidate, use it > > in the m/c > > > line of a new offer, and suppress testing. > > > > > > The above would represents quite a small change to ICE and could > > > probably be accommodated in the ICE RFC rather than a > > separate RFC. In > > > this way it would be easier to force support of micro-lite > > by all ICE implementations. > > > > > > As a further enhancement, perhaps ICE-lite could allow the > > inclusion > > > of two candidates, where one is IPv4 and the other is IPv6. ICE > > > micro-lite would then be a subset of ICE-lite. There would > > then be a > > > natural evolution path for implementations, from > > micro-lite, via lite to full ICE. > > > > > > John > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 06 15:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtje-0004zb-GH; Fri, 06 Apr 2007 15:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZtjb-0004uN-Iq for mmusic@ietf.org; Fri, 06 Apr 2007 15:04:31 -0400 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZtja-0003ap-0V for mmusic@ietf.org; Fri, 06 Apr 2007 15:04:31 -0400 Received: from cm-84.209.225.083.chello.no ([84.209.225.83] helo=[10.0.0.4]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HZtjU-0006nw-A2 for mmusic@ietf.org; Fri, 06 Apr 2007 19:04:24 +0000 Message-ID: <461699B6.40109@db.org> Date: Fri, 06 Apr 2007 21:04:22 +0200 From: "Alfred E. Heggestad" User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [MMUSIC] ICE-15: definition of ice-lite syntax X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org hi ICE-15 defines a session level SDP attribute "ice-lite" which indicates that the agent is a lite implementation, i.e. if this attritbute is omitted it indicates a full implementation. perhaps it is too late to suggest any changes to the ICE draft now, but what about changing the syntax to e.g. "ice-mode" instead, which gives greater flexibility for future extensions such as a "third" mode. My suggestion would then be: a=ice-mode:full Full ICE implementation a=ice-mode:lite Lite ICE implementation a=ice-mode:foo Future ICE mode (currently not invented..) In case people are worried about huge SDP payloads, we could also specify that the full mode is default, and if the ice-mode SDP attribute is not present, this means Full ICE implementation. /alfred _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 07 01:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3Bo-00058m-W0; Sat, 07 Apr 2007 01:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha3Bn-00058h-EZ for mmusic@ietf.org; Sat, 07 Apr 2007 01:10:15 -0400 Received: from ns.live555.com ([4.79.217.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha3Bm-00020k-4t for mmusic@ietf.org; Sat, 07 Apr 2007 01:10:15 -0400 Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.13.8/8.13.8) with ESMTP id l375AlPk033421 for ; Fri, 6 Apr 2007 22:10:48 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.13.8/8.13.8/Submit) id l375Allk033420; Fri, 6 Apr 2007 22:10:47 -0700 (PDT) (envelope-from rsf) Mime-Version: 1.0 Message-Id: In-Reply-To: <461699B6.40109@db.org> References: <461699B6.40109@db.org> Date: Fri, 6 Apr 2007 22:07:12 -0700 To: mmusic@ietf.org From: Ross Finlayson Subject: Re: [MMUSIC] ICE-15: definition of ice-lite syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > a=ice-mode:lite Lite ICE implementation Have we all forgotten that the English word is actually spelled "light"? :-) Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 07 07:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha8eC-0003WC-E0; Sat, 07 Apr 2007 06:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha8eB-0003VU-2l for mmusic@ietf.org; Sat, 07 Apr 2007 06:59:55 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha8e9-00042p-JI for mmusic@ietf.org; Sat, 07 Apr 2007 06:59:55 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 98E07A89F8; Sat, 7 Apr 2007 11:59:38 +0100 (BST) In-Reply-To: References: <461699B6.40109@db.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0FB1A9D1-FE43-4C0F-AAF1-948C5E47C96A@insensate.co.uk> From: lconroy Subject: Re: [MMUSIC] ICE-15: definition of ice-lite syntax Date: Sat, 7 Apr 2007 11:59:38 +0100 To: Ross Finlayson X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1790507707==" Errors-To: mmusic-bounces@ietf.org --===============1790507707== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-67883130; protocol="application/pkcs7-signature" --Apple-Mail-1-67883130 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Ross, folks, No - however, is it appropriate? Are you suggesting that the many-faceted ICE specifications are written in English? atb, Lawrence On 7 Apr 2007, at 06:07, Ross Finlayson wrote: >> a=ice-mode:lite Lite ICE implementation > Have we all forgotten that the English word is actually spelled > "light"? :-) > Ross. --Apple-Mail-1-67883130 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEojCCBJ4w ggKGoAMCAQICAQkwDQYJKoZIhvcNAQEFBQAwZjELMAkGA1UEBhMCR0IxDzANBgNVBAcTBkxvbmRv bjETMBEGA1UEChMKVGVsbmljIEx0ZDEUMBIGA1UECxMLRGV2ZWxvcG1lbnQxGzAZBgNVBAMTElRl bG5pYyBJbnRlcm5hbCBDQTAeFw0wNzA0MDUxMzE1NTNaFw0wODA0MDQxMzE1NTNaMEIxGDAWBgNV BAMMD0xhd3JlbmNlIENvbnJveTEmMCQGCSqGSIb3DQEJAQwXbGNvbnJveUBpbnNlbnNhdGUuY28u dWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Mn/wYB87g10uakYhm+GIo3/WKXdJ dt27rrWIiIfN8oZ1kvtcAQ34HbkC5nZiYmBTHIaKUnDshGwJvEOJRjVT3z2/gEiGgjrN5IdgHmkF 6VV6C/8XqI/3OTe4cwWMYCFiZzsQEYswg1vbBQGpxiuGCnjF22KbYsDnmQEmfo9reMmmBhONwD7I aK3YnwvcaznrTAFGrSWvI/dgVJ5GnYYLI3pIvf0qqxJOu0Qi/ObdAb810YDfj+1wOMgqVTQE9dqR Z2GGRGRV8v2Xyw5XG1U9+BfwE6DK+VWjR+2+205yN4LPAxLtI4clV7JfuKfIPfITt0Na0uVwsSl9 1grSl6PzAgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJh dGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBRBbex3TpzqrZ0euTjzo1tmeGO/VTAfBgNVHSMEGDAW gBQckHl1oJndO8ROadFuGtwIrPM9xTANBgkqhkiG9w0BAQUFAAOCAgEAgkBPWBcoEi3Ex4NgpG0P aRwMDaOF2zR1igFe4G8wMBbLKZDRGNE+aizayhWRaxR/zApmgV4HdYPjRxJuoOwQlrJbfaRvUSPE ShJlgSZf4ZRXHS2I1qBXYMbezDvcZIbBBzix/66v20BOY9pZkJNjrfCMofYCZO5FcbXr+af+6GFs UdImkC8aRjP/0SNl0iwG9iV6//fVEfTCqpiPfDbN7qkvDTZtGaIHrovz7WX4ENW0soA9nndEUQ/d oW8LXtJYsHYwSAbrjwZdUHUTfQsM7TYpdeRFfOFwel/5rytSIfv7T1SARW2/IIktKV5RYCmQSza/ etVpcPHJg3NG7xq0jwyUzt/LqepyNR7F/yNh5UolaVWPCyH0irlfD/OwvPfHYGmNEnnSt6jHK1v0 cUaMY6DpIvM/I9PB12xFPkIQE+1iKtu6FABUehYfG9HtZz0OD8udo71jGg6Y2xyN1sDgkteJSKgu kF6W/9zKQ6bBtXPp+c0bwfrTFhQxgie5xuSgQsrNsEfCARFG+jjS/hVDTLDFMu35QnawhVXAI2gF 8r+9SEmKbOCoE0SuSFUIgXpbhzByghpQiZnJ1UPVd0ubK1lDIDDpX1YlBnJ9CfaqHSU0tzgQEwJa B0qWIbEShaGbuoh+6/KUFoPVYx9f5SfXcoJOWyGusrEmI1FpwZU50/QxggLtMIIC6QIBATBrMGYx CzAJBgNVBAYTAkdCMQ8wDQYDVQQHEwZMb25kb24xEzARBgNVBAoTClRlbG5pYyBMdGQxFDASBgNV BAsTC0RldmVsb3BtZW50MRswGQYDVQQDExJUZWxuaWMgSW50ZXJuYWwgQ0ECAQkwCQYFKw4DAhoF AKCCAVcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNDA3MTA1 OTM5WjAjBgkqhkiG9w0BCQQxFgQUfT3DRsvu9w5oGW19gMELjfs1dzgwegYJKwYBBAGCNxAEMW0w azBmMQswCQYDVQQGEwJHQjEPMA0GA1UEBxMGTG9uZG9uMRMwEQYDVQQKEwpUZWxuaWMgTHRkMRQw EgYDVQQLEwtEZXZlbG9wbWVudDEbMBkGA1UEAxMSVGVsbmljIEludGVybmFsIENBAgEJMHwGCyqG SIb3DQEJEAILMW2gazBmMQswCQYDVQQGEwJHQjEPMA0GA1UEBxMGTG9uZG9uMRMwEQYDVQQKEwpU ZWxuaWMgTHRkMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEbMBkGA1UEAxMSVGVsbmljIEludGVybmFs IENBAgEJMA0GCSqGSIb3DQEBAQUABIIBAHsTo381bXmT+WTDHkSSQkh/pgjKSHzYbAuC6ArPxUOS dj0cLHecpJPq2TCWZg1eyLTBmL1OGRVTbow7o12evzsqDsqNsFS6XS/Grqat3rg8WHCSCyIWDNTH nAaZolQqPeVyJ+nV5wKiuCLdPivds6/Dmpwox2HICooEaxsJUDhcg7PVjFec98d7dPBKJQ8BOFsH 9s8quoMWFBql1XN4s7XjsQcaKK6g316MvgtppcJkPcLmmfWvIwtIFmpW43HLKMfnrMhDtmj/A3Gf lUAYMDem5cl3dKa9H2XEvNwgBFhnLAtyyxjcDLuGIJc32PRGl3AWMs1NP1+i46xoWACkDeEAAAAA AAA= --Apple-Mail-1-67883130-- --===============1790507707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1790507707==-- From mmusic-bounces@ietf.org Sat Apr 07 15:54:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaGz3-0005KA-7T; Sat, 07 Apr 2007 15:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaGz2-0005FV-3r for mmusic@ietf.org; Sat, 07 Apr 2007 15:54:00 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaGz0-00046W-KZ for mmusic@ietf.org; Sat, 07 Apr 2007 15:54:00 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JG500A7F8LTDE@siemenscomms.co.uk> for mmusic@ietf.org; Sat, 07 Apr 2007 20:53:53 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Sat, 07 Apr 2007 20:53:57 +0100 Content-return: allowed Date: Sat, 07 Apr 2007 20:53:47 +0100 From: "Elwell, John" To: Jonathan Rosenberg Message-id: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: mmusic@ietf.org Subject: [MMUSIC] RE: ICE micro-lite for support of IPv6 transition X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 05 April 2007 13:22 > To: Elwell, John > Cc: mmusic@ietf.org > Subject: Re: ICE micro-lite for support of IPv6 transition > > John, > > I think this defeats the entire purpose of why we had selected ICE to > deprecate ANAT. What you are proposing below is nothing more than a > syntactic transformation of ANAT into ICE. [JRE] I a sense, yes. However, a syntactic transformation with a couple of benefits. First, it should be backwards compatible with plain vanilla IPv4 implementations. Remember ANAT uses two m-lines and requires an option tag in the Require header field to ensure the UAS understands. This leads to some nasty interactions with 3PCC. The ICE syntax neatly gets around this problem. The second benefit is that this is a step on the path towards full ice. > This loses all of the > benefits ICE brings (dynamic path selection, ability to run RFC 3484, > etc.), and also introduces a mode that will not interoperate properly > with regular ICE endpoints. [JRE] My proposal is to mandate that regular ice endpoints support micro-lite. > Remember, the reason ice-lite requires an > implementation to receive checks and respond to them, is that this is > necessary for the full ice implementation to achieve nat > traversal. With > your proposal, a full ICE implementation would get no NAT traversal > benefits when communicating with an ice micro-lite endpoint. [JRE] Indeed, and that is because micro-lite would be employed in non-NAT environments (or SBC environments) where IPv4/IPv6 transition is needed. > > -Jonathan R. > > Elwell, John wrote: > > > There was strong consensus at IETF68 to deprecate ANAT and > use ICE as the > > sole way of negotiating between IPv4 and IPv6 for media. > However, there was > > some concern about this raising the bar too high for those > who require to > > support IPv6 ahead of full ICE. While many markets may > require ICE for NAT > > traversal before they require IPv6, there are certain > customers demanding > > IPv6 transition capabilities at an early stage, and needing > to do a full ICE > > implementation to satisfy these customers can be undesirable. > > > > To satisfy this market, the requirement is for an offer to > include two > > candidates, one IPv4 and the other IPv6. For backwards > compatibility with > > IPv4 non-ICE implementations, the IPv4 candidate would be > the default. The > > answerer should be able to select one of these and the call > should be able > > to continue without a connectivity check. Removal of > connectivity checks > > would considerably simplify the implementation of ICE for IPv4/IPV6 > > negotiation in these environments. Compatibility with full > or lite ICE > > implementations would have to be provided, of course. > > > > Thus we would really only use the SDP enhancements of ICE, > and not the rest. > > Compared with ANAT it has the advantages of better backward > compatibility > > with existing IPv4 devices and being a step on the path > towards full ICE. > > > > ICE lite goes some way to lowering the bar for implementing > ICE, but it does > > not solve the present problem for two reasons: > > 1) An ICE lite implementation cannot propose two candidates. > > 2) An ICE lite implementation is still required to support > connectivity > > checks as a server. > > > > It seems that the requirements above could be supported by > a fairly small > > change to ICE, along the following lines. I will call this an ICE > > "micro-lite" implementation. > > > > When sending an offer, a dual stack ICE "micro-lite" > implementation would > > include two candidates, one based on IPv4 (the default > candidate) and the > > other based on IPv6. It would also include a flag (e.g., an > option tag) to > > indicate that it supports only "micro-lite" and therefore > will not do > > connectivity checks. The answerer would choose the IP > protocol and respond > > with an IP address for that protocol in the c-line. If IPv6 > is chosen, the > > offerer would need to do a further offer to promote its > IPv6 address and > > port to the m/c line. > > > > If the answerer is a full (or lite) implementation, it would use the > > received "micro-lite" indicator to behave as above and > suppress testing. If > > the offerer is a full implementation, it sees that the > answerer does not > > support full or lite ICE (because it does not return any > candidate lines) > > but would use the fact that the c-line contains an IPv6 > address to select > > its IPv6 host candidate, use it in the m/c line of a new > offer, and suppress > > testing. > > > > The above would represents quite a small change to ICE and > could probably be > > accommodated in the ICE RFC rather than a separate RFC. In > this way it would > > be easier to force support of micro-lite by all ICE implementations. > > > > As a further enhancement, perhaps ICE-lite could allow the > inclusion of two > > candidates, where one is IPv4 and the other is IPv6. ICE > micro-lite would > > then be a subset of ICE-lite. There would then be a natural > evolution path > > for implementations, from micro-lite, via lite to full ICE. > > > > John > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 07 16:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHMw-00016W-FA; Sat, 07 Apr 2007 16:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHMw-00016R-2C for mmusic@ietf.org; Sat, 07 Apr 2007 16:18:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaHMt-0007S4-Qe for mmusic@ietf.org; Sat, 07 Apr 2007 16:18:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2007 16:18:40 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l37KIdPM031794; Sat, 7 Apr 2007 16:18:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l37KIZGd018127; Sat, 7 Apr 2007 20:18:39 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 16:18:34 -0400 Received: from [10.86.242.12] ([10.86.242.12]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 16:18:34 -0400 Message-ID: <4617FC99.4010904@cisco.com> Date: Sat, 07 Apr 2007 16:18:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ross Finlayson Subject: Re: [MMUSIC] ICE-15: definition of ice-lite syntax References: <461699B6.40109@db.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2007 20:18:34.0406 (UTC) FILETIME=[EAECFC60:01C77951] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=325; t=1175977119; x=1176841119; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20definition=20of=20ice-lite=20s yntax |Sender:=20 |To:=20Ross=20Finlayson=20; bh=otNPkVq08k3vMxEnOkm2tUIn2tJPohYQWQKppRPXVwE=; b=DrVelm8dPMT6N+Himbn17V0RaaffEZHwHFXZzjhLTenU2sgFqUKn4zkTqyzuZmjJ0QfakJwS njwFzKPVUp81Y2n2OcY30jh+HTQFRsUisApuNxMEMf3B4Qx5lO/65Ykk; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ross Finlayson wrote: >> a=ice-mode:lite Lite ICE implementation > > Have we all forgotten that the English word is actually spelled "light"? > :-) Nah! Remember, this is *English* we are talking about. "Lite" is now a word in its own right, similar in meaning to "light", but "lighter". :-) Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 08:59:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatS8-0007Ez-7I; Mon, 09 Apr 2007 08:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatS7-0007Et-7S for mmusic@ietf.org; Mon, 09 Apr 2007 08:58:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatS4-0000Y3-TC for mmusic@ietf.org; Mon, 09 Apr 2007 08:58:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2007 08:58:32 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39CwWQK028265; Mon, 9 Apr 2007 08:58:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39Cw4la011988; Mon, 9 Apr 2007 12:58:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 08:58:27 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 08:58:27 -0400 Message-ID: <461A3872.6020208@cisco.com> Date: Mon, 09 Apr 2007 08:58:26 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] ICE-15: definition of ice-lite syntax References: <461699B6.40109@db.org> <4617FC99.4010904@cisco.com> In-Reply-To: <4617FC99.4010904@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 12:58:27.0149 (UTC) FILETIME=[C3CCD7D0:01C77AA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1591; t=1176123512; x=1176987512; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20definition=20of=20ice-lite=20s yntax |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=AjrKdfS22O/sDyJCJcl/4tC/L7bW8Qn+89TNfOg617Y=; b=Aj1zw8WtGPhFcG9O9qYA2ou1eaKJNnL5t4F4z7gf0wXJQicDtc5SVy3dYh54ml+PRBH6OvkM D6ADlYj0a+NvzuAjmZYicPgzJty1D8SjeA7IIqNSgkzQCdE8u+MRcLnc; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Ross Finlayson , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Indeed, it appears in the american heritage dictionary now. But to address the bigger issue here, of multiple modes, I think this is NOT a good idea. I think it is a mistake for ICE to go down these paths of lots of modes that need to be signaled and understood. You end up with a combinatoric explosion of complexity considering behavior when an agent of one mode hits an agent of another mode. ICE was designed to be extensible through other means, primarily through additional candidate attributes and through new localized algorithms for candidate selection (allowed by the regular nomination process). The latter requires no signaling support whatsoever. So, I oppose the proposed change. -Jonathan R. Paul Kyzivat wrote: > > > Ross Finlayson wrote: > >>> a=ice-mode:lite Lite ICE implementation >> >> >> Have we all forgotten that the English word is actually spelled >> "light"? :-) > > > Nah! Remember, this is *English* we are talking about. "Lite" is now a > word in its own right, similar in meaning to "light", but "lighter". :-) > > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 09:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatZR-00048e-2B; Mon, 09 Apr 2007 09:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatZP-00048Z-BZ for mmusic@ietf.org; Mon, 09 Apr 2007 09:06:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatZN-00021k-0n for mmusic@ietf.org; Mon, 09 Apr 2007 09:06:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2007 09:06:05 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39D64Ug031858; Mon, 9 Apr 2007 09:06:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39D5klg014552; Mon, 9 Apr 2007 13:06:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:05:58 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:05:57 -0400 Message-ID: <461A3A35.8090200@cisco.com> Date: Mon, 09 Apr 2007 09:05:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 13:05:57.0790 (UTC) FILETIME=[D06733E0:01C77AA7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3188; t=1176123964; x=1176987964; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20ICE=20micro-lite=20for=20support=20of=20IPv6=20transi tion |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=ette0yvL5mffWyGjD6CzcmAInN6mieJ/UD73zthgniU=; b=JyZgmiaRRhq3kKJiw0ZwwexkKGk5umnMLV6DCEQFsl39vYpAK7II123Jc9yfMkBMnavu9kmZ UQlGvBq0iI11EXaLt5gnmM3wgP8tf0j3GXEmst94L4aRsHGYAmLk4+5d; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Elwell, John wrote: > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 05 April 2007 13:22 >>To: Elwell, John >>Cc: mmusic@ietf.org >>Subject: Re: ICE micro-lite for support of IPv6 transition >> >>John, >> >>I think this defeats the entire purpose of why we had selected ICE to >>deprecate ANAT. What you are proposing below is nothing more than a >>syntactic transformation of ANAT into ICE. > > [JRE] I a sense, yes. However, a syntactic transformation with a couple of > benefits. First, it should be backwards compatible with plain vanilla IPv4 > implementations. Remember ANAT uses two m-lines and requires an option tag > in the Require header field to ensure the UAS understands. This leads to > some nasty interactions with 3PCC. The ICE syntax neatly gets around this > problem. The second benefit is that this is a step on the path towards full > ice. Not really. There is nothing here that resembles ICE except a piece of syntax. > > >>This loses all of the >>benefits ICE brings (dynamic path selection, ability to run RFC 3484, >>etc.), and also introduces a mode that will not interoperate properly >>with regular ICE endpoints. > > [JRE] My proposal is to mandate that regular ice endpoints support > micro-lite. Which, if that endpoint is behind a NAT, doesn't help them one drop. With ice-lite as defined today, this is not so. With ice-lite, the agent on the public network that is doing ice-lite, is still allowing its peer to be full ICE, and for that peer to be behind a NAT, and get the full benefits of ICE. With your proposal, the endpoint behind a NAT would be out of luck entirely. So, with your 'ice-micro-lite', basically both agents do ice-micro-lite, or nothing. So, lets not kid ourselves. What you are proposing is to undo the consensus decision at IETF 68, and instead, define something that is basically the same as ANAT, but uses the ICE syntax instead. I am opposed to that. I understand that ICE adds complexity, there is no dispute that it is more complex than ANAT. However, the view was that this complexity was worth the benefits. > > >>Remember, the reason ice-lite requires an >>implementation to receive checks and respond to them, is that this is >>necessary for the full ice implementation to achieve nat >>traversal. With >>your proposal, a full ICE implementation would get no NAT traversal >>benefits when communicating with an ice micro-lite endpoint. > > [JRE] Indeed, and that is because micro-lite would be employed in non-NAT > environments (or SBC environments) where IPv4/IPv6 transition is needed. Which only underscores the point - this is not ICE, this is something entirely orthogonal. Its ANAT with ICE syntax. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 09:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hathz-0000xg-MO; Mon, 09 Apr 2007 09:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hatht-0000sf-9v for mmusic@ietf.org; Mon, 09 Apr 2007 09:14:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Haths-0003bN-0g for mmusic@ietf.org; Mon, 09 Apr 2007 09:14:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2007 09:14:52 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39DEpVw003503; Mon, 9 Apr 2007 09:14:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39DEglQ017159; Mon, 9 Apr 2007 13:14:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:14:14 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:14:14 -0400 Message-ID: <461A3C25.2070502@cisco.com> Date: Mon, 09 Apr 2007 09:14:13 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guylain Lavoie Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition References: <6EF4CC794ECF2B409390605FDEA9012218D569@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D569@m5tmail1.m5t.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 13:14:14.0360 (UTC) FILETIME=[F861C580:01C77AA8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2227; t=1176124491; x=1176988491; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20ICE=20micro-lite=20for=20support=2 0of=20IPv6=20transition |Sender:=20 |To:=20Guylain=20Lavoie=20; bh=H7gx/0pUXPoIsIdvtAAJ9Dj7vHxQWYnBLURwOhQYOkQ=; b=ObOh6Mc4zal4HGEMapeHEmaZseOKGqBf5/8SXhWap39N20BAqq7LK3OMb8UOqDL/DPRHA7US hHQoBi40v+I1H/D0S3zgymsRXlDGgE7K81kWf2IrpLyrY9gQAQ4xVCol; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Guylain Lavoie wrote: > By the way, can someone more knowledgeable than me explain why ICE-lite > cannot include more than one host candidate per component when he knows > that both are always accessible? Is this an arbitrary decision or is > there something that does not allow this? It is most certainly NOT arbitrary. ICE-lite falls apart when you do this. The reason is as follows. Remember that an important part of ICE processing is this 'fix-up' operation, whereby, if the candidate selected by ICE is not matching the m/c-line, the controlling agent does an updated offer to make them match. This was deemed important for backwards compatibility with lots of middleboxes that want to see media sent to the target of the m/c-line. With ice-lite, since there is only ever one candidate, it always matches the m/c-line, and so the agent never needs to do fix-ups. Now, if you allow multiple candidates, what happens if both sides are ice-lite, but a candidate is selected that does NOT match the m/c-line? Well, now you need to do the fix-up re-invite. So, you'd now lose the property that, when both sides are ice-lite, you basically don't do ICE at all. You'd have to do some third subset of ICE. So, let us continue down this line of thought. What if we specify that? What if, with ice-lite, you still do some kind of third mode when both sides are ice-lite, so that the fix-up reinvite is done? Well, to do the fix-up, you need to select a controlling and controlled node. Folks will recall that, in certain 3pcc cases, it is possible for both agents to think they are controlled, or both to think they are controlling. THe fix for this in ice-15 is to use flags in the STUN checks themselves to sort out this ambiguity. However, we wouldn't be having any checks here, so we'd have an unresolved ambiguity. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 09:17:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hatka-00039h-9S; Mon, 09 Apr 2007 09:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatkY-00032x-Q2 for mmusic@ietf.org; Mon, 09 Apr 2007 09:17:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatkX-0003vF-F5 for mmusic@ietf.org; Mon, 09 Apr 2007 09:17:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2007 09:17:37 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39DHbaq030135; Mon, 9 Apr 2007 09:17:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39DH7lW017983; Mon, 9 Apr 2007 13:17:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:17:25 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:17:25 -0400 Message-ID: <461A3CE4.3020800@cisco.com> Date: Mon, 09 Apr 2007 09:17:24 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> <46150516.5080308@pjsip.org> In-Reply-To: <46150516.5080308@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 13:17:25.0237 (UTC) FILETIME=[6A274A50:01C77AA9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1892; t=1176124657; x=1176988657; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=20waiti ng=20for=20an=09aggressive=09nomination? |Sender:=20 |To:=20Benny=20Prijono=20; bh=SK6XWQMsAGE/h2jXrvFX50gfBptM7AJwEZXcNCiGcIo=; b=wHkw9p6p4PWSSmYOw31Y0bDpiYaKKr18UxFGVy5sxt7PHjdiDFAz5RK4fQu6Y4dFK5uaYIu2 mD4U/ykFaWGI/VfL+DsM1R2bJDHgVhdl5ZnmMUvwpQ8PhVYsJhr7ic2c; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Benny Prijono wrote: > Jonathan Rosenberg wrote: > >> Well, much as a hate timers, its probably the only option here. With >> agressive nomination, if you wair one STUN transaction lifetime after >> you've entered completed, you can free up resources since there >> shouldn't be any further changes after that. > > > Can't we use the arrival of RTP packets for this purpose? We know that > once we receive an RTP packet, each component in peer for this stream > has a valid pair. No, that doesn't work. With agressive mode, you are allowed to send media to what you THINK is the selected pair, but then a higher priority check completes and there is a new selected pair. So you then begin using that. > > This wouldn't work perfectly when peer is using aggressive mode though, > since some checks may still be running in peer even if it has begun > sending RTP packets, so if we close the unused ports now those checks > will fail. But on the other hand, by closing these unused ports now, it > ensures that there will be no change in the selected candidate in peer. The whole issue here is what to do with agressive mode. Closing ports early is likely to lead to ambiguity in the selected pairs, since checks might be completing just as the allocations are freed; there are definitely race conditions here. I think its just easier to use a timer for this. We are talking about 'clean-up' kind of operations, so I don't see the drawback. Setting this to a few seconds is a safe number. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 09:18:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatlQ-0003yL-Dn; Mon, 09 Apr 2007 09:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatlP-0003yD-9d for mmusic@ietf.org; Mon, 09 Apr 2007 09:18:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatlO-00040B-1D for mmusic@ietf.org; Mon, 09 Apr 2007 09:18:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2007 09:18:30 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39DITV3030503; Mon, 9 Apr 2007 09:18:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39DIPlM018269; Mon, 9 Apr 2007 13:18:29 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:18:27 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:18:26 -0400 Message-ID: <461A3D22.9020002@cisco.com> Date: Mon, 09 Apr 2007 09:18:26 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Lennox Subject: Re: [MMUSIC] ICE-15: What happens if a connectivity check gets 300 Try Alternate? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> <17941.47289.862013.55076@metro-north.cs.columbia.edu> In-Reply-To: <17941.47289.862013.55076@metro-north.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 13:18:26.0665 (UTC) FILETIME=[8EC47590:01C77AA9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1342; t=1176124709; x=1176988709; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20What=20happens=20if=20a=20conn ectivity=20check=20gets=20300=0A=20Try=09Alternate? |Sender:=20 |To:=20Jonathan=20Lennox=20; bh=2JGCJ+xCtE/Se1hEQ8gAdbTEQeTzjbF900KuVGMKp2g=; b=G9PdrcJIudfKrZwf6r+auJ6Pm0cLEVZKwzMCXX/YkRgMwg796XfLExSPBTxBaGjj8x27BVLl VoSP31RFcvDlIhIX2v3fzRcLM5hPa191LEmkxDAq62ShosWYqvPi1kyP; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I don't think 300 is meaningful for the connectivity usage. Its easier to just disallow this case. I'll add a note that says a server MUST NOT send it. -Jonathan R. Jonathan Lennox wrote: > How should an ICE endpoint handle receiving a 300 Try Alternate STUN error > response to a connectivity check request? > > Should it actually send a connectivity check to the ALTERNATE-SERVER address > listed in the 300, and if so should it treat the alternate server as a new > remote peer-reflexive candidate? Or should it just consider the > connectivity check to have failed, as with other error responses to the > check request? > > Other than 300, I think the rest of the STUN error response codes defined by > 3489bis (i.e., other than 487 Role Conflict) should indeed cause a > connectivity check to fail. (The only other potential case in which > different behavior might be useful would be 500 Server Error, but I don't > think retrying a failing connectivity check is a good idea.) > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 09:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatxG-0001HR-J7; Mon, 09 Apr 2007 09:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HatxF-0001H5-LA for mmusic@ietf.org; Mon, 09 Apr 2007 09:30:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HatxE-000615-Bc for mmusic@ietf.org; Mon, 09 Apr 2007 09:30:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2007 09:30:44 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39DUhfh003596; Mon, 9 Apr 2007 09:30:43 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39DUelO021825; Mon, 9 Apr 2007 13:30:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:30:20 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 09:30:20 -0400 Message-ID: <461A3FEC.4020300@cisco.com> Date: Mon, 09 Apr 2007 09:30:20 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE-15: handling check list that completes early References: <461576F6.8060706@pjsip.org> In-Reply-To: <461576F6.8060706@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 13:30:20.0549 (UTC) FILETIME=[38468350:01C77AAB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2465; t=1176125443; x=1176989443; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20handling=20check=20list=20that =20completes=20early |Sender:=20 |To:=20Benny=20Prijono=20; bh=1oChjz66Bx4qLdwnfuX13+bXvePNjlGl2f+7aanVlHk=; b=CMdeZl4CKimUimHsXVuctfeaBDl+Vn45dsb0flpzvS9u5F6yDdSG8yEt8ygtm5aWGV9AM8lm AZ1noYZ2M9gTIgK51kyIDqyrn4UrWUEif/NFBt3LeR42I4yrZtp1lFMR; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I don't think this case is explicitly called out in the spec, but the logic certainly covers it. Once the checks in the check list are exhausted, the timer is terminated (section 5.8). This will also cause this check list to no longer be active (section 5.7 definition). Other than that, there is nothing more to do. THe state of the check list is NOT completed, since there have not been nominated pairs yet. So, once the request shows up with the USE-CANDIDATE attribute, section 7.2 is followed, and 8.2 continues to apply. 8.2 will cause the state to eventually move to completed, and then you are done. So, I do not see that any clarifications are needed. What aspects of the above processing rules do you think are unclear? -Jonathan R. Benny Prijono wrote: > All, > > I came across this scenario which I couldn't find the answer in the > draft. Apologies if this has been discussed before. > > What should answerer do when it completes all the check lists before > receiving any checks from offerer? > > This happens on this scenario. The answerer starts the check as soon as > it sends answer. The offerer receives this check before SDP, and it > responds with successful response. The answerer receives the response, > starts other checks, gets the successful response again, and so on until > finally all check lists are exhausted. And all of these happens before > offerer receives the SDP answer, or in other words, the offerer can't > send checks yet. > > But although the check lists have completed, the answerer still hasn't > got a nominated pair yet, since it hasn't received Binding request with > USE-CANDIDATE yet. > > So what should the answerer do here? I think probably it should do > something like this: > > - it should wait until it receives check with USE-CANDIDATE set > (what if it never receives this?) > > - when a check with USE-CANDIDATE arrives, it needs to scan the > valid list for matching pair and set the nominated flag to > true, and do section 8.2 again. > > Comments? > > thanks, > -benny > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 11:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavsB-000465-7V; Mon, 09 Apr 2007 11:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavsA-00045v-S5 for mmusic@ietf.org; Mon, 09 Apr 2007 11:33:38 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Havs6-00061S-I9 for mmusic@ietf.org; Mon, 09 Apr 2007 11:33:38 -0400 Received: from [192.168.0.66] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 56FE551944; Mon, 9 Apr 2007 11:33:29 -0400 (EDT) Message-ID: <461A5CC7.60801@pjsip.org> Date: Mon, 09 Apr 2007 16:33:27 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-15: handling check list that completes early References: <461576F6.8060706@pjsip.org> <461A3FEC.4020300@cisco.com> In-Reply-To: <461A3FEC.4020300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: > THe state of the check list is NOT completed, > since there have not been nominated pairs yet. So, once > the request shows up with the USE-CANDIDATE attribute, section 7.2 is > followed, and 8.2 continues to apply. 8.2 will cause the state to > eventually move to completed, and then you are done. > > > So, I do not see that any clarifications are needed. What aspects of the > above processing rules do you think are unclear? Hmm.. I think the confusion primarily came from the check list state definition, because page 35 says that the check list is said to be Completed when all checks have been completed, not when it's got a nominated pair (although the processing in 8.2 explains this correctly). So when running 8.2, the processing will make ICE processing completes, but no nominated pair was found, hence my program concluded that ICE had failed. Other than this, perhaps we can also clarify in 7.1.2.2.2. Updating Pair States (item 2, first bullet), some sort of "if there is no Frozen or Waiting checks in the active checklist, then don't try to do anything clever, just wait". thanks, -benny > -Jonathan R. > > > > Benny Prijono wrote: > >> All, >> >> I came across this scenario which I couldn't find the answer in the >> draft. Apologies if this has been discussed before. >> >> What should answerer do when it completes all the check lists before >> receiving any checks from offerer? >> >> This happens on this scenario. The answerer starts the check as soon >> as it sends answer. The offerer receives this check before SDP, and it >> responds with successful response. The answerer receives the response, >> starts other checks, gets the successful response again, and so on >> until finally all check lists are exhausted. And all of these happens >> before offerer receives the SDP answer, or in other words, the offerer >> can't send checks yet. >> >> But although the check lists have completed, the answerer still hasn't >> got a nominated pair yet, since it hasn't received Binding request >> with USE-CANDIDATE yet. >> >> So what should the answerer do here? I think probably it should do >> something like this: >> >> - it should wait until it receives check with USE-CANDIDATE set >> (what if it never receives this?) >> >> - when a check with USE-CANDIDATE arrives, it needs to scan the >> valid list for matching pair and set the nominated flag to >> true, and do section 8.2 again. >> >> Comments? >> >> thanks, >> -benny >> >> > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 11:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Havre-0003LU-HY; Mon, 09 Apr 2007 11:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Havrd-0003LP-JG for mmusic@ietf.org; Mon, 09 Apr 2007 11:33:05 -0400 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Havra-0005wU-HX for mmusic@ietf.org; Mon, 09 Apr 2007 11:33:05 -0400 Received: from cm-84.209.225.083.chello.no ([84.209.225.83] helo=[10.0.0.8]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1Havr6-0001Jt-Iu; Mon, 09 Apr 2007 15:32:32 +0000 Message-ID: <461A5CE7.3000405@db.org> Date: Mon, 09 Apr 2007 17:33:59 +0200 From: "Alfred E. Heggestad" User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-15: definition of ice-lite syntax References: <461699B6.40109@db.org> <4617FC99.4010904@cisco.com> <461A3872.6020208@cisco.com> In-Reply-To: <461A3872.6020208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Paul Kyzivat , Ross Finlayson , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, OK agreed, the number of combinations is already high enough ;) /alfred Jonathan Rosenberg wrote: > Indeed, it appears in the american heritage dictionary now. > > But to address the bigger issue here, of multiple modes, I think this is > NOT a good idea. I think it is a mistake for ICE to go down these paths > of lots of modes that need to be signaled and understood. You end up > with a combinatoric explosion of complexity considering behavior when an > agent of one mode hits an agent of another mode. ICE was designed to be > extensible through other means, primarily through additional candidate > attributes and through new localized algorithms for candidate selection > (allowed by the regular nomination process). The latter requires no > signaling support whatsoever. > > So, I oppose the proposed change. > > -Jonathan R. > > Paul Kyzivat wrote: > >> >> >> Ross Finlayson wrote: >> >>>> a=ice-mode:lite Lite ICE implementation >>> >>> >>> Have we all forgotten that the English word is actually spelled >>> "light"? :-) >> >> >> Nah! Remember, this is *English* we are talking about. "Lite" is now a >> word in its own right, similar in meaning to "light", but "lighter". :-) >> >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 12:53:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hax70-0006hY-Eq; Mon, 09 Apr 2007 12:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hax6z-0006hN-0l for mmusic@ietf.org; Mon, 09 Apr 2007 12:53:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hax6w-0006ZO-NH for mmusic@ietf.org; Mon, 09 Apr 2007 12:53:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2007 12:53:00 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l39GqwHc007621; Mon, 9 Apr 2007 12:52:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l39GqwGd011676; Mon, 9 Apr 2007 16:52:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 12:52:57 -0400 Received: from [192.168.1.104] ([10.86.243.71]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 12:52:57 -0400 Message-ID: <461A6F68.5010608@cisco.com> Date: Mon, 09 Apr 2007 12:52:56 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE-15: handling check list that completes early References: <461576F6.8060706@pjsip.org> <461A3FEC.4020300@cisco.com> <461A5CC7.60801@pjsip.org> In-Reply-To: <461A5CC7.60801@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 16:52:57.0101 (UTC) FILETIME=[862523D0:01C77AC7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2011; t=1176137578; x=1177001578; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20handling=20check=20list=20that =20completes=20early |Sender:=20 |To:=20Benny=20Prijono=20; bh=OOiSv17X4p5h0ZGq/FSM9GOJ9uoFsqr4/tLZjMVZeGc=; b=gV2lMil2Zd2g8VFnVEQ8Um0yrja9UsuFjPdQXo2mRCgZni2zz+PZr9m/yFs43sni/eQ3W0GA QtAGJKdzYc4JPbRUxy03L8QSj6Sechx8/UErWQll1KhnO7EeBk8cF+vj; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Benny Prijono wrote: > Jonathan Rosenberg wrote: > >> THe state of the check list is NOT completed, >> since there have not been nominated pairs yet. So, once the request >> shows up with the USE-CANDIDATE attribute, section 7.2 is followed, >> and 8.2 continues to apply. 8.2 will cause the state to eventually >> move to completed, and then you are done. > >> >> So, I do not see that any clarifications are needed. What aspects of >> the above processing rules do you think are unclear? > > > > Hmm.. I think the confusion primarily came from the check list state > definition, because page 35 says that the check list is said to be > Completed when all checks have been completed, not when it's got a > nominated pair (although the processing in 8.2 explains this correctly). Yes, OK. Good point. I'll adjust the definition to match the logic. It now says: In this state, ICE checks have produced nominated pairs for each component of the media stream. Consequently, ICE has succeeded and media can be sent. > > So when running 8.2, the processing will make ICE processing completes, > but no nominated pair was found, hence my program concluded that ICE had > failed. > > Other than this, perhaps we can also clarify in 7.1.2.2.2. Updating > Pair States (item 2, first bullet), some sort of "if there is no Frozen > or Waiting checks in the active checklist, then don't try to do anything > clever, just wait". Well, this section really deals with the frozen algorithm. I think with the above clarification in the definition of Completed we are fine. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 14:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayRA-0000vY-WA; Mon, 09 Apr 2007 14:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayRA-0000vQ-Gy for mmusic@ietf.org; Mon, 09 Apr 2007 14:17:56 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HayR6-00018N-5E for mmusic@ietf.org; Mon, 09 Apr 2007 14:17:56 -0400 Received: from [192.168.0.66] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 1DD67519EA; Mon, 9 Apr 2007 14:17:50 -0400 (EDT) Message-ID: <461A834A.7090504@pjsip.org> Date: Mon, 09 Apr 2007 19:17:46 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-15: handling check list that completes early References: <461576F6.8060706@pjsip.org> <461A3FEC.4020300@cisco.com> <461A5CC7.60801@pjsip.org> <461A6F68.5010608@cisco.com> In-Reply-To: <461A6F68.5010608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: >> Hmm.. I think the confusion primarily came from the check list state >> definition, because page 35 says that the check list is said to be >> Completed when all checks have been completed, not when it's got a >> nominated pair (although the processing in 8.2 explains this correctly). > > Yes, OK. Good point. I'll adjust the definition to match the logic. It > now says: > > In this state, ICE checks have produced > nominated pairs for each component of the media stream. Consequently, > ICE has succeeded and media can be sent. > That's good. It also clears up my other doubt, that is when a check list is Completed, how many nominated pairs are there in the check list. One (per check list), or one per component. Of course it's the later, but some other parts of the document may sound to suggest the former: 8.1.1 Consequently, there will be only a single nominated pair in the valid list, and when the state of the check list moves to completed, that exact pair is selected by ICE for sending and receiving media. I think that should be clarified as: Consequently, there will be only a single nominated pair in the valid list *for each component*, and when the state of the check list moves to completed, that exact pair is selected by ICE for sending and receiving media *for that component*. And similarly 8.1.2: With aggressive nomination, the controlling agent includes the USE-CANDIDATE attribute in every check it sends. Once the first check for a component succeeds, it will be added to the valid list, have its nominated flag set, and then cause ICE processing to cease for this check list. I think the last fragment should say: .. and when all components in the check list have a nominated pair, it will cause ICE processing to cease for this check list. thanks, -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 15:12:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazHq-0007rA-NO; Mon, 09 Apr 2007 15:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazHp-0007lo-99 for mmusic@ietf.org; Mon, 09 Apr 2007 15:12:21 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HazHo-00050k-0D for mmusic@ietf.org; Mon, 09 Apr 2007 15:12:21 -0400 Received: from [192.168.0.66] (unknown [81.178.58.134]) by smtp.mxes.net (Postfix) with ESMTP id 04386519A4; Mon, 9 Apr 2007 15:12:18 -0400 (EDT) Message-ID: <461A900E.3070909@pjsip.org> Date: Mon, 09 Apr 2007 20:12:14 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> <46150516.5080308@pjsip.org> <461A3CE4.3020800@cisco.com> In-Reply-To: <461A3CE4.3020800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: >> Can't we use the arrival of RTP packets for this purpose? We know that >> once we receive an RTP packet, each component in peer for this stream >> has a valid pair. > > No, that doesn't work. With agressive mode, you are allowed to send > media to what you THINK is the selected pair, but then a higher priority > check completes and there is a new selected pair. So you then begin > using that. Sure, I understand that. >> This wouldn't work perfectly when peer is using aggressive mode >> though, since some checks may still be running in peer even if it has >> begun sending RTP packets, so if we close the unused ports now those >> checks will fail. But on the other hand, by closing these unused ports >> now, it ensures that there will be no change in the selected candidate >> in peer. > > The whole issue here is what to do with agressive mode. Closing ports > early is likely to lead to ambiguity in the selected pairs, since checks > might be completing just as the allocations are freed; there are > definitely race conditions here. I can't see the race condition here. If a socket is closed, then that's it, you can't send response. Although, thinking about it again, that's not exactly true for relay candidate. Okay, I can see what you mean. But yeah, there is another drawback for RTP approach, as it relies on peer sending RTP as soon as ICE completes, which may not be the case when VAD/DTX is used (or when media is sendonly). > I think its just easier to use a timer for this. We are talking about > 'clean-up' kind of operations, so I don't see the drawback. Setting this > to a few seconds is a safe number. Timer looks like the only solution indeed. Although there is another problem. Suppose agent A has one media stream, one component, and two candidates, relay and srflx. The relay candidate has lower priority than the srflx candidate. Agent A is doing aggressive nomination, and sends check using srflx candidate to agent B. Agent B receives the check fine, sends response, and set the nominated pair. But for some strange reason, the response never gets to agent A (perhaps the NAT in agent A's premises messes up with the Binding response). Next agent A sends the second check using the relayed candidate, and this time it gets the response fine. So at this time, both agents have different nominated pair to use. Agent A uses the relay candidate, since it's the only one that's successful, while agent B uses the srflx candidate, since it has higher priority, and as far as it concerns, it has sent response successfully. Is this possible at all? thanks, -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 09 17:06:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb13k-0006WZ-Ac; Mon, 09 Apr 2007 17:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb13j-0006UT-GP; Mon, 09 Apr 2007 17:05:55 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hb13h-0007v5-Jn; Mon, 09 Apr 2007 17:05:55 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc461b1bca; Tue, 10 Apr 2007 05:16:37 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm73461612e5; Fri, 06 Apr 2007 11:11:33 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 06 Apr 2007 11:11:33 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXyc-0002jc-VP; Thu, 05 Apr 2007 15:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZXyV-0002i9-4s; Thu, 05 Apr 2007 15:50:27 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZXyK-0004dJ-CC; Thu, 05 Apr 2007 15:50:27 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id AEE0826F54; Thu, 5 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZXy6-00046J-Is; Thu, 05 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-06.txt X-BeenThere: mmusic@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) for Media Loopback Author(s) : K. Hedayat, et al. Filename : draft-ietf-mmusic-media-loopback-06.txt Pages : 23 Date : 2007-4-5 The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-media-loopback-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-media-loopback-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-5141624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-media-loopback-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-media-loopback-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-5141624.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Mon Apr 09 21:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4jH-0000RB-DR; Mon, 09 Apr 2007 21:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4jG-0000Qx-61 for mmusic@ietf.org; Mon, 09 Apr 2007 21:01:02 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4jE-0001tp-Tk for mmusic@ietf.org; Mon, 09 Apr 2007 21:01:02 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3A10RR11434; Tue, 10 Apr 2007 01:00:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Mon, 9 Apr 2007 20:00:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> In-Reply-To: <461A3A35.8090200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition thread-index: Acd6p/Z7Iz0r6x/cSBqnrSB9JqWt6wAYtk5w References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > > > [JRE] Indeed, and that is because micro-lite would be employed in=20 > > non-NAT environments (or SBC environments) where IPv4/IPv6=20 > transition is needed. >=20 > Which only underscores the point - this is not ICE, this is=20 > something entirely orthogonal. Its ANAT with ICE syntax. Or you could say it's ICE with a possibility of bypassing the connectivity check WHEN APPROPRIATE. In my mind, BOTH sides would have to explicitly indicate that they wish to use=20 ice-microlite for the bypass to happen. If either end is behind a NAT, it will therefore end-up using full-ice because it will not include the microlite flag. In fact, wouldn't this be useful even for ice-lite (not microlite, just lite), where if both PSTN gateways are on the public internet, they know right away they can skip the connectivity check? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 09:25:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGKh-0001bC-Ie; Tue, 10 Apr 2007 09:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGKg-0001ar-IF for mmusic@ietf.org; Tue, 10 Apr 2007 09:24:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbGKf-00087V-6e for mmusic@ietf.org; Tue, 10 Apr 2007 09:24:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Apr 2007 06:24:25 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3ADOOZv005440; Tue, 10 Apr 2007 06:24:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3ADO1Ak022351; Tue, 10 Apr 2007 13:24:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:24:18 -0400 Received: from [172.17.155.169] ([10.82.216.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:24:18 -0400 Message-ID: <461B9001.9080402@cisco.com> Date: Tue, 10 Apr 2007 09:24:17 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 13:24:18.0444 (UTC) FILETIME=[8ADB6CC0:01C77B73] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1822; t=1176211464; x=1177075464; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20ICE=20micro-lite=20for=20support=2 0of=20IPv6=20transition |Sender:=20; bh=Qxa0D4Hrq7I0NsH5fet4wVeL6IqbdwX7ruKKhQX5lHw=; b=vlsmQ2ggsDY/cDXO0saq0qHTL8yWPvH7wIdj3eP8PRvuO/VdwxmKjh1uzfB+PlDwrI4uYvRx jfY9dCOD12MrN/pfj65m+HWqUxxL+tBKRbHNGEC0C7Etw8eD1e7pltii; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Francois Audet wrote: > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> >> >>>[JRE] Indeed, and that is because micro-lite would be employed in >>>non-NAT environments (or SBC environments) where IPv4/IPv6 >> >>transition is needed. >> >>Which only underscores the point - this is not ICE, this is >>something entirely orthogonal. Its ANAT with ICE syntax. > > > Or you could say it's ICE with a possibility of bypassing the > connectivity check > WHEN APPROPRIATE. > > In my mind, BOTH sides would have to explicitly indicate that they wish > to use > ice-microlite for the bypass to happen. > > If either end is behind a NAT, it will therefore end-up using full-ice > because it > will not include the microlite flag. No, it won't. The problem is that if the offeror sends 'ice-micro-lite' and the answerer is behind a NAT and wants full ICE, the answerer is out of luck. ICE-lite has this really important property that, if one side is ice-lite, and the other is full, the full side still gets the entire complete benefits of ICE for NAT traversal. > > In fact, wouldn't this be useful even for ice-lite (not microlite, just > lite), where > if both PSTN gateways are on the public internet, they know right away > they can skip the > connectivity check? That already happens. If both agents are ICE lite, there are no connectivity checks that get utilized. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 09:33:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGTO-0006FZ-1g; Tue, 10 Apr 2007 09:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGTM-0006FU-1h for mmusic@ietf.org; Tue, 10 Apr 2007 09:33:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbGTK-0002oi-Nh for mmusic@ietf.org; Tue, 10 Apr 2007 09:33:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2007 09:33:22 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3ADXMcV023677; Tue, 10 Apr 2007 09:33:22 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3ADWxGl014897; Tue, 10 Apr 2007 13:33:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:33:02 -0400 Received: from [172.17.155.169] ([10.82.216.112]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:33:01 -0400 Message-ID: <461B920C.3060401@cisco.com> Date: Tue, 10 Apr 2007 09:33:00 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> <46150516.5080308@pjsip.org> <461A3CE4.3020800@cisco.com> <461A900E.3070909@pjsip.org> In-Reply-To: <461A900E.3070909@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 13:33:01.0738 (UTC) FILETIME=[C2C3C0A0:01C77B74] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3470; t=1176212002; x=1177076002; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=20waiti ng=20for=20an=09aggressive=09nomination? |Sender:=20 |To:=20Benny=20Prijono=20; bh=4U7sbT9s1qNHA6v91+H0O6eM8NymmR1gBWqB7uRwcJ0=; b=ceRMUEvzXYGkqaoT5X4zxCbSg0WH1M0MTL6l8rJgBuuZzDREisp9oZ3elgS1pq494NlWEDEM yuQAlwcAiEQgtUU8QrsQW2vqRMiIQENlsJqusWiGEwC426GyrqjH6gcR; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Benny Prijono wrote: >> >> The whole issue here is what to do with agressive mode. Closing ports >> early is likely to lead to ambiguity in the selected pairs, since >> checks might be completing just as the allocations are freed; there >> are definitely race conditions here. > > > I can't see the race condition here. If a socket is closed, then that's > it, you can't send response. Although, thinking about it again, that's > not exactly true for relay candidate. Okay, I can see what you mean. Yes, relayed was exactly the case. If the relayed candidate is freed while the connectivity check is in flight between the relay and the client, this will fail. > > But yeah, there is another drawback for RTP approach, as it relies on > peer sending RTP as soon as ICE completes, which may not be the case > when VAD/DTX is used (or when media is sendonly). Right, another good point. > > >> I think its just easier to use a timer for this. We are talking about >> 'clean-up' kind of operations, so I don't see the drawback. Setting >> this to a few seconds is a safe number. > > > Timer looks like the only solution indeed. Yup. I will add that to ICE-16. > > Although there is another problem. > > Suppose agent A has one media stream, one component, and two candidates, > relay and srflx. The relay candidate has lower priority than the srflx > candidate. > > Agent A is doing aggressive nomination, and sends check using srflx > candidate to agent B. Agent B receives the check fine, sends response, > and set the nominated pair. But for some strange reason, the response > never gets to agent A (perhaps the NAT in agent A's premises messes up > with the Binding response). A relies on a reverse check to succeed before it sets the nominated flag. Read carefully section 7.2.1.5. It talks about the state of the pair generated as a result of the processing in 7.2.1.4 - that is the pair generated from the triggered check. So if the response from B to A is never received due to firewall, a reverse check won't succeed either and so B will not set the nominated flag. > > Next agent A sends the second check using the relayed candidate, and > this time it gets the response fine. > > So at this time, both agents have different nominated pair to use. Agent > A uses the relay candidate, since it's the only one that's successful, > while agent B uses the srflx candidate, since it has higher priority, > and as far as it concerns, it has sent response successfully. > > Is this possible at all? Inconsistent view on the selected pair is possible, but it is very unlikely. It would require a transaction to succeed in one direction, but to fail completely (timeout) in the reverse direction. This would not occur as a consequence of any firewalling or NATting, but rather, some really bad packet loss that persists for many seconds. This error would be detected from the a=remote-candidates in the re-invite (see section 9.2.2.3) and will cause an ICE restart for that media stream. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 09:37:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGXD-0001Uu-Ke; Tue, 10 Apr 2007 09:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbGXC-0001Uj-Hu for mmusic@ietf.org; Tue, 10 Apr 2007 09:37:22 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbGXB-0003NR-8b for mmusic@ietf.org; Tue, 10 Apr 2007 09:37:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2007 09:37:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3ADbLJA025352; Tue, 10 Apr 2007 09:37:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3ADb6lk025094; Tue, 10 Apr 2007 13:37:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:37:15 -0400 Received: from [172.17.155.169] ([10.82.216.112]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:37:15 -0400 Message-ID: <461B930A.30407@cisco.com> Date: Tue, 10 Apr 2007 09:37:14 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE-15: handling check list that completes early References: <461576F6.8060706@pjsip.org> <461A3FEC.4020300@cisco.com> <461A5CC7.60801@pjsip.org> <461A6F68.5010608@cisco.com> <461A834A.7090504@pjsip.org> In-Reply-To: <461A834A.7090504@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 13:37:15.0319 (UTC) FILETIME=[59E92470:01C77B75] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2583; t=1176212241; x=1177076241; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20handling=20check=20list=20that =20completes=20early |Sender:=20 |To:=20Benny=20Prijono=20; bh=QczVW2vr2y/oE7UqVlHgGonVD5PpFIPR+RYr4PzQdcM=; b=cObggDpMhLK2pfnRyAD65CDoj7Dx4SE2ZpBbIKe3dl9//VNP1sBqF1aAI1PF7Yua6JRaT5XO aMtYFe2YDihpEvrBCbUif2nhaPkZQ+JCLBJfH3skRmtC6Z5kEixRzoAQ; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Benny Prijono wrote: > Jonathan Rosenberg wrote: > >>> Hmm.. I think the confusion primarily came from the check list state >>> definition, because page 35 says that the check list is said to be >>> Completed when all checks have been completed, not when it's got a >>> nominated pair (although the processing in 8.2 explains this correctly). >> >> >> Yes, OK. Good point. I'll adjust the definition to match the logic. It >> now says: >> >> In this state, ICE checks have produced >> nominated pairs for each component of the media stream. Consequently, >> ICE has succeeded and media can be sent. >> > > > That's good. > > It also clears up my other doubt, that is when a check list is > Completed, how many nominated pairs are there in the check list. One > (per check list), or one per component. Per component. Note that these are on the valid list, not the check list. > > Of course it's the later, but some other parts of the document may sound > to suggest the former: > > 8.1.1 > Consequently, there will be only a single nominated pair in the > valid list, and when the state of the check list moves to > completed, that exact pair is selected by ICE for sending and > receiving media. > > > I think that should be clarified as: > > Consequently, there will be only a single nominated pair in the > valid list *for each component*, and when the state of the check > list moves to completed, that exact pair is selected by ICE for > sending and receiving media *for that component*. Yes, fixed. > > > And similarly 8.1.2: > > With aggressive nomination, the controlling agent includes the > USE-CANDIDATE attribute in every check it sends. Once the first > check for a component succeeds, it will be added to the valid > list, have its nominated flag set, and then cause ICE processing > to cease for this check list. > > I think the last fragment should say: > > .. and when all components in the check list have a nominated > pair, it will cause ICE processing to cease for this check list. s/check list/valid list, but yes. Thanks for catching these, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 11:00:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHpk-0001Ou-SX; Tue, 10 Apr 2007 11:00:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHpj-0001Oi-51 for mmusic@ietf.org; Tue, 10 Apr 2007 11:00:35 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHpd-0003Pe-H3 for mmusic@ietf.org; Tue, 10 Apr 2007 11:00:35 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 1AD8A519DB; Tue, 10 Apr 2007 11:00:27 -0400 (EDT) Message-ID: <461BA689.6080109@pjsip.org> Date: Tue, 10 Apr 2007 16:00:25 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> <46150516.5080308@pjsip.org> <461A3CE4.3020800@cisco.com> <461A900E.3070909@pjsip.org> <461B920C.3060401@cisco.com> In-Reply-To: <461B920C.3060401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: >> Timer looks like the only solution indeed. > > Yup. I will add that to ICE-16. Sounds good. Just to be sure, we don't need to make the procedure normative as not all implementations have this problem. In my case, for example, I use one socket for one component (that's one socket and one STUN "session" for all candidates, including multiple host candidates, srflx, and potentially relay), and I recycle media transports between calls. So if for one particular call some of the resources are not used, I just keep them alive, because anyway they may still need to send keep-alives to their STUN/TURN server. >> >> Although there is another problem. >> >> Suppose agent A has one media stream, one component, and two >> candidates, relay and srflx. The relay candidate has lower priority >> than the srflx candidate. >> >> Agent A is doing aggressive nomination, and sends check using srflx >> candidate to agent B. Agent B receives the check fine, sends response, >> and set the nominated pair. But for some strange reason, the response >> never gets to agent A (perhaps the NAT in agent A's premises messes up >> with the Binding response). > > A relies on a reverse check to succeed before it sets the nominated > flag. Read carefully section 7.2.1.5. It talks about the state of the > pair generated as a result of the processing in 7.2.1.4 - that is the > pair generated from the triggered check. I'm a bit confused here. Section 7.2.1.5 is about controlled agent (that is agent B). Agent A is in controlling role (implied by it doing aggressive nomination), so it doesn't have to wait for a reverse check before it sets the nominated flag. But anyway, I was trying to describe the very unlikely scenario that you explained below, where STUN transactions only succeed in one direction. Glad to hear that this has been covered in Chapter 9 (which I haven't implemented, so I haven't read it very closely :) ). So you may close this "ticket" now. Sorry for the false alarm. thanks, -benny > Inconsistent view on the selected pair is possible, but it is very > unlikely. It would require a transaction to succeed in one direction, > but to fail completely (timeout) in the reverse direction. This would > not occur as a consequence of any firewalling or NATting, but rather, > some really bad packet loss that persists for many seconds. This error > would be detected from the a=remote-candidates in the re-invite (see > section 9.2.2.3) and will cause an ICE restart for that media stream. > > -Jonathan R. > > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 11:44:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIVa-0005F1-Jl; Tue, 10 Apr 2007 11:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIVY-0005Ev-Si for mmusic@ietf.org; Tue, 10 Apr 2007 11:43:48 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIVX-0004wU-K2 for mmusic@ietf.org; Tue, 10 Apr 2007 11:43:48 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3AFhfY07979; Tue, 10 Apr 2007 15:43:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Tue, 10 Apr 2007 10:43:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FF71F26@zrc2hxm0.corp.nortel.com> In-Reply-To: <461B9001.9080402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition thread-index: Acd7c5NCY6DqmL6uQLSLaVIXh3/vYAAEu6JQ References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 > > If either end is behind a NAT, it will therefore end-up=20 > using full-ice=20 > > because it will not include the microlite flag. >=20 > No, it won't. The problem is that if the offeror sends=20 > 'ice-micro-lite'=20 > and the answerer is behind a NAT and wants full ICE, the=20 > answerer is out of luck. ICE-lite has this really important=20 > property that, if one side is ice-lite, and the other is=20 > full, the full side still gets the entire complete benefits=20 > of ICE for NAT traversal. Wouldn't that work here then? Wouldn't we want the "full side" to get the benefits here, i.e., the ice-micro-lite MUST respond to connectivity checks? > >=20 > > In fact, wouldn't this be useful even for ice-lite (not=20 > microlite, just > > lite), where > > if both PSTN gateways are on the public internet, they know=20 > right away > > they can skip the > > connectivity check? >=20 > That already happens. If both agents are ICE lite, there are no=20 > connectivity checks that get utilized. Ok, good. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 12:12:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIxL-0007RN-3w; Tue, 10 Apr 2007 12:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIxI-0007R7-Oy for mmusic@ietf.org; Tue, 10 Apr 2007 12:12:28 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIxG-00043H-RD for mmusic@ietf.org; Tue, 10 Apr 2007 12:12:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Date: Tue, 10 Apr 2007 12:12:25 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D6D5@m5tmail1.m5t.com> In-Reply-To: <461BA689.6080109@pjsip.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Thread-Index: Acd7gXNpswiAmA1vRcW4Bh70x7hV/AABqCbQ From: "Guylain Lavoie" To: "Benny Prijono" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Benny, I am wondering how you plan on demultiplexing ICMP errors if a single socket is shared for all candidate of a component? How will you associate a received ICMP errors with a specific Connectivity Checks or even a Binding Discovery Request used to keep server reflexive candidate alive (keepalive)? Normally, at least, on BSD like stack, you must connect the UDP socket to be able to reliably receive ICMP errors. For example,=20 from rfc3489bis-06, 7.1, "A STUN transaction over UDP is also considered failed if there has been a transport failure of some sort, such as a fatal ICMP error." from ICE-15, 7.1.2.1, "If the STUN transaction generates an ICMP error, or..." Not connecting the socket would not allow you to fully comply with the specification (your implementation would end up waiting for the full timeout when such thing happens). Thanks, Guylain -----Original Message----- From: Benny Prijono [mailto:bennylp@pjsip.org]=20 Sent: April 10, 2007 11:00 AM To: Jonathan Rosenberg Cc: Jonathan Lennox; mmusic@ietf.org Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Jonathan Rosenberg wrote: >> Timer looks like the only solution indeed. >=20 > Yup. I will add that to ICE-16. Sounds good. Just to be sure, we don't need to make the procedure normative as not all implementations have this problem. In my case, for example, I use one socket for one component (that's one socket and one STUN "session" for all candidates, including multiple host candidates, srflx, and potentially relay), and I recycle media transports between calls. So if for one particular call some of the resources are not used, I just keep them alive, because anyway they may still need to send keep-alives to their STUN/TURN server. ... _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 13:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbK60-0003W7-KA; Tue, 10 Apr 2007 13:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbK5y-0003Vz-Ri for mmusic@ietf.org; Tue, 10 Apr 2007 13:25:30 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbK5s-0002W8-GK for mmusic@ietf.org; Tue, 10 Apr 2007 13:25:30 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id AE2325191F; Tue, 10 Apr 2007 13:25:23 -0400 (EDT) Message-ID: <461BC87F.5080909@pjsip.org> Date: Tue, 10 Apr 2007 18:25:19 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Guylain Lavoie Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? References: <6EF4CC794ECF2B409390605FDEA9012218D6D5@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D6D5@m5tmail1.m5t.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Guylain, Guylain Lavoie wrote: > Hi Benny, > > I am wondering how you plan on demultiplexing ICMP errors if a single > socket is shared for all candidate of a component? > How will you associate a received ICMP errors with a specific > Connectivity Checks or even a Binding Discovery Request used to keep > server reflexive candidate alive (keepalive)? Normally, at least, on BSD > like stack, you must connect the UDP socket to be able to reliably > receive ICMP errors. Even if you use one socket for each candidate, I'm not sure if you can do UDP connect() on each of them, as ICE requires you to send connectivity checks to multiple destinations. > Not connecting the socket would not allow you to fully comply with the > specification (your implementation would end up waiting for the full > timeout when such thing happens). I view ICMP handling as "if you can and want to handle it, then do it, if not, then you know the risk" kind of thing, so I would disagree that we should call these implementations not fully comply just because they don't/can't handle ICMP. cheers, -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 13:34:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKEx-0001yP-6g; Tue, 10 Apr 2007 13:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKEv-0001yG-JH for mmusic@ietf.org; Tue, 10 Apr 2007 13:34:45 -0400 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKEq-0004SX-7a for mmusic@ietf.org; Tue, 10 Apr 2007 13:34:45 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3AHYc7i015106; Tue, 10 Apr 2007 13:34:38 -0400 Received: from [192.168.1.97] ([216.13.42.66]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l3AHYb7p004539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Apr 2007 13:34:38 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 10 Apr 2007 10:52:10 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF MMUSIC WG Subject: [MMUSIC] Question on Verifying ICE Support X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan: ICE-15 says: 5.1. Verifying ICE Support The answerer will proceed with the ICE procedures defined in this specification if the following are all true: o For each media stream, the default destination for at least one component of the media stream appears in a candidate attribute. For example, in the case of RTP, the IP address and port in the c and m line, respectively, appears in a candidate attribute, or the value in the rtcp attribute appears in a candidate attribute. Why the "at least one component"? I don't understand why you do not require that there to be an a=candidate attribute for each component? In what non-SBC or similar situations do you expect that one component might match but not the other? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 14:31:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbL7G-0004i1-RG; Tue, 10 Apr 2007 14:30:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbL7F-0004hp-Tv for mmusic@ietf.org; Tue, 10 Apr 2007 14:30:53 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbL7E-0000Sf-MD for mmusic@ietf.org; Tue, 10 Apr 2007 14:30:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Date: Tue, 10 Apr 2007 14:30:48 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D712@m5tmail1.m5t.com> In-Reply-To: <461BC87F.5080909@pjsip.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Thread-Index: Acd7lW2cG2DcHn7ERS6Lxsw+amCCswAAEBtA From: "Guylain Lavoie" To: "Benny Prijono" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Benny, Optional support of ICMP reception is perfectly fine for me because it is much more easier to implement. However, if it is mandated, we would basically need to allocate one socket for each candidate pair plus one for each server reflexive candidate and relayed candidate. That's a lot of sockets, but that way you can do a connect on all of them. This solution would work fine on some operating systems, but on others, it would not because the socket option SO_REUSEPORT is not available and it is needed so that all socket may be bound to the same address and port. From what I read, this is not available on Linux. This might be true for other operating systems as well. You would also need an non connected socket to be able to support reception of connectivity checks before the SDP answer arrives. This would also be required to receive a connectivity check from a peer reflexive candidate (which is unknown and thus cannot be connected to). NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are needed for an implementation of TCP with ICE because all TCP sockets are inherently connected and must be bound to the same address and port. Like with UDP, this would probably no work on all operating systems. This is mentioned in some NAT hole punching technique papers. Thanks Guylain -----Original Message----- From: Benny Prijono [mailto:bennylp@pjsip.org]=20 Sent: April 10, 2007 1:25 PM To: Guylain Lavoie Cc: mmusic@ietf.org Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Hi Guylain, Guylain Lavoie wrote: > Hi Benny, >=20 > I am wondering how you plan on demultiplexing ICMP errors if a single=20 > socket is shared for all candidate of a component? > How will you associate a received ICMP errors with a specific=20 > Connectivity Checks or even a Binding Discovery Request used to keep=20 > server reflexive candidate alive (keepalive)? Normally, at least, on=20 > BSD like stack, you must connect the UDP socket to be able to reliably > receive ICMP errors. Even if you use one socket for each candidate, I'm not sure if you can do UDP connect() on each of them, as ICE requires you to send connectivity checks to multiple destinations. > Not connecting the socket would not allow you to fully comply with the > specification (your implementation would end up waiting for the full=20 > timeout when such thing happens). I view ICMP handling as "if you can and want to handle it, then do it, if not, then you know the risk" kind of thing, so I would disagree that we should call these implementations not fully comply just because they don't/can't handle ICMP. cheers, -benny _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 15:42:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMEG-0004V3-VE; Tue, 10 Apr 2007 15:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMEF-0004Ux-L1 for mmusic@ietf.org; Tue, 10 Apr 2007 15:42:11 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMEB-0007NI-A1 for mmusic@ietf.org; Tue, 10 Apr 2007 15:42:11 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CA8FD5193F; Tue, 10 Apr 2007 15:42:05 -0400 (EDT) Message-ID: <461BE88B.5020509@pjsip.org> Date: Tue, 10 Apr 2007 20:42:03 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Guylain Lavoie Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? References: <6EF4CC794ECF2B409390605FDEA9012218D712@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D712@m5tmail1.m5t.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Guylain, I can't speak for ICE standards or best practices, having learned it only in the past few weeks, but I think creating one socket for each candidate *pair* is not the way ICE is supposed to be done, because that needs one heck a lot of sockets and it doesn't work on most platforms, as you said, especially if this is only needed just to get the benefit of ICMP. So I don't think ICMP would need to be mandated at all by ICE, CMIIW. I don't think this issue would matter for ICE TCP, since with ICE TCP the source address of the connection does not matter, so they don't need to be bound to the same address/port. -benny Guylain Lavoie wrote: > Hi Benny, > > Optional support of ICMP reception is perfectly fine for me because it > is much more easier to implement. > > However, if it is mandated, we would basically need to allocate one > socket for each candidate pair plus one for each server reflexive > candidate and relayed candidate. That's a lot of sockets, but that way > you can do a connect on all of them. This solution would work fine on > some operating systems, but on others, it would not because the socket > option SO_REUSEPORT is not available and it is needed so that all socket > may be bound to the same address and port. From what I read, this is not > available on Linux. This might be true for other operating systems as > well. You would also need an non connected socket to be able to support > reception of connectivity checks before the SDP answer arrives. This > would also be required to receive a connectivity check from a peer > reflexive candidate (which is unknown and thus cannot be connected to). > > NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are needed for an > implementation of TCP with ICE because all TCP sockets are inherently > connected and must be bound to the same address and port. Like with UDP, > this would probably no work on all operating systems. This is mentioned > in some NAT hole punching technique papers. > > Thanks > Guylain > > -----Original Message----- > From: Benny Prijono [mailto:bennylp@pjsip.org] > Sent: April 10, 2007 1:25 PM > To: Guylain Lavoie > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive > nomination? > > Hi Guylain, > > Guylain Lavoie wrote: >> Hi Benny, >> >> I am wondering how you plan on demultiplexing ICMP errors if a single >> socket is shared for all candidate of a component? >> How will you associate a received ICMP errors with a specific >> Connectivity Checks or even a Binding Discovery Request used to keep >> server reflexive candidate alive (keepalive)? Normally, at least, on >> BSD like stack, you must connect the UDP socket to be able to reliably > >> receive ICMP errors. > > Even if you use one socket for each candidate, I'm not sure if you can > do UDP connect() on each of them, as ICE requires you to send > connectivity checks to multiple destinations. > >> Not connecting the socket would not allow you to fully comply with the > >> specification (your implementation would end up waiting for the full >> timeout when such thing happens). > > I view ICMP handling as "if you can and want to handle it, then do it, > if not, then you know the risk" kind of thing, so I would disagree that > we should call these implementations not fully comply just because they > don't/can't handle ICMP. > > cheers, > -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 15:43:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMFa-0004zF-QJ; Tue, 10 Apr 2007 15:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMFa-0004zA-6A for mmusic@ietf.org; Tue, 10 Apr 2007 15:43:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMFY-0007YC-QO for mmusic@ietf.org; Tue, 10 Apr 2007 15:43:34 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 Apr 2007 12:43:32 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3AJhWIG021340; Tue, 10 Apr 2007 12:43:32 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3AJhOwn022174; Tue, 10 Apr 2007 19:43:27 GMT From: "Dan Wing" To: "'Guylain Lavoie'" , "'Benny Prijono'" Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive nomination? Date: Tue, 10 Apr 2007 12:43:22 -0700 Message-ID: <000001c77ba8$84dd8260$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D712@m5tmail1.m5t.com> Thread-Index: Acd7lW2cG2DcHn7ERS6Lxsw+amCCswAAEBtAAANRG4A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3507; t=1176234212; x=1177098212; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=20waiti ngforan=09aggressive=09nomination? |Sender:=20; bh=h4jpoUXeghLA+Nm7KYORt4KN1LohXi1cZ7WjcqJqUxY=; b=LPNxHrc5+lK2HM8bztjjTpFF5HxYoY3oouCVPtBc1AUFa+zWypiyyEgcYxoJdRxfO7Qeo+Dh msFU+C3f2btrRjGLnZ181ONgYGO5ufq8kKwODVZa5ZBfsrw5n/64ZFNy; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Guylain Lavoie [mailto:glavoie@m5t.com] > Sent: Tuesday, April 10, 2007 11:31 AM > To: Benny Prijono > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan > aggressive nomination? > > Hi Benny, > > Optional support of ICMP reception is perfectly fine for me because it > is much more easier to implement. > > However, if it is mandated, ICMP can't be mandated by ICE. ICMP is often filtered due to incompetence, overzealous administrators, or insufficient configuration granularity in firewalls and NATs. -d > we would basically need to allocate one > socket for each candidate pair plus one for each server reflexive > candidate and relayed candidate. That's a lot of sockets, but that way > you can do a connect on all of them. This solution would work fine on > some operating systems, but on others, it would not because the socket > option SO_REUSEPORT is not available and it is needed so that > all socket > may be bound to the same address and port. From what I read, > this is not > available on Linux. This might be true for other operating systems as > well. You would also need an non connected socket to be able > to support > reception of connectivity checks before the SDP answer arrives. This > would also be required to receive a connectivity check from a peer > reflexive candidate (which is unknown and thus cannot be > connected to). > > NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are > needed for an > implementation of TCP with ICE because all TCP sockets are inherently > connected and must be bound to the same address and port. > Like with UDP, > this would probably no work on all operating systems. This is > mentioned > in some NAT hole punching technique papers. > > Thanks > Guylain > > -----Original Message----- > From: Benny Prijono [mailto:bennylp@pjsip.org] > Sent: April 10, 2007 1:25 PM > To: Guylain Lavoie > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran > aggressive > nomination? > > Hi Guylain, > > Guylain Lavoie wrote: > > Hi Benny, > > > > I am wondering how you plan on demultiplexing ICMP errors > if a single > > socket is shared for all candidate of a component? > > How will you associate a received ICMP errors with a specific > > Connectivity Checks or even a Binding Discovery Request > used to keep > > server reflexive candidate alive (keepalive)? Normally, at > least, on > > BSD like stack, you must connect the UDP socket to be able > to reliably > > > receive ICMP errors. > > Even if you use one socket for each candidate, I'm not sure if you can > do UDP connect() on each of them, as ICE requires you to send > connectivity checks to multiple destinations. > > > Not connecting the socket would not allow you to fully > comply with the > > > specification (your implementation would end up waiting for > the full > > timeout when such thing happens). > > I view ICMP handling as "if you can and want to handle it, then do it, > if not, then you know the risk" kind of thing, so I would > disagree that > we should call these implementations not fully comply just > because they > don't/can't handle ICMP. > > cheers, > -benny > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 16:06:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMax-0001ta-DM; Tue, 10 Apr 2007 16:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMav-0001tV-I8 for mmusic@ietf.org; Tue, 10 Apr 2007 16:05:37 -0400 Received: from bay0-omc1-s14.bay0.hotmail.com ([65.54.246.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMau-0005IW-3s for mmusic@ietf.org; Tue, 10 Apr 2007 16:05:37 -0400 Received: from bayc1-pasmtp07.bayc1.hotmail.com ([65.54.191.167]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 10 Apr 2007 13:05:35 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp07.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668); Tue, 10 Apr 2007 13:05:40 -0700 Message-ID: <04d301c77bab$99053d70$65500a0a@ronin> From: "Eric Cooper" To: "Geir Arne Sandbakken" References: <9F6ACAE02B6DD040A1E259977622CFDB187A25@oslexcp1.eu.tandberg.int> Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Tue, 10 Apr 2007 16:05:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 10 Apr 2007 20:05:40.0203 (UTC) FILETIME=[9CB43BB0:01C77BAB] X-Spam-Score: 2.1 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Jean-Francois Mule , mmusic@ietf.org, Joerg Ott , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Geir Arne, I am not a patent lawyer but I have been discussing Tandberg's = ICE-related IPR statements with someone who is. He has provided the = following analysis: "The Patent Holder is prepared to grant, on the basis of reciprocity in = accordance with the above IETF specification, a license to an = unrestricted number of applicants. Such licenses shall be on a = worldwide, non-discriminatory basis and on reasonable terms and = conditions permitting licensee to make, use and sell implementations of = the above IETF specification." This part refers to parties who do not have patent protection on = something considered "essential" to practice the standard. These people = will have to pay a royalty to Tandberg for complying with the standard = (to the extent a Tandberg patent is essential to compliance). "The Patent Holder is prepared to grant a "free" license to any = prospective licensee if such prospective licensee will commit to license = its own essential patent(s) or essential patent claim(s) for = implementation of any IETF specification for "free"." This part says that to the extent a party that has something that is = essential to ANY IETF specification, a "free" license can be obtained. = Then they give a definition of free which means only no money will be = demanded - they can still demand a royalty free license to an entire = product portfolio, restrict the field of use, etc.=20 Can you comment on this analysis? =20 If the above analysis is correct, I think these terms would hinder ICE's = adoption. Would Tandberg agree to terms similar to these: http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-mpls-interas-lspping-0= 0.txt ? Best Regards, Eric. ----- Original Message -----=20 From: "Geir Arne Sandbakken" To: "Colin Perkins" ; "Jean-Francois Mule" = Cc: ; "Joerg Ott" Sent: Tuesday, April 03, 2007 5:05 AM Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Colin, The part of the IPR concerning negotiation of a license is adopted from the standard ITU patent policy statement. We understand you concern, and it is now under revision. Cheers, Geir Arne > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 01 April 2007 15:00 > To: Jean-Francois Mule > Cc: mmusic@ietf.org; Joerg Ott > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 > [Not as chair] >=20 > On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote: > > This is to announce a Working Group Last Call on ICE > > draft-ietf-mmusic-ice-15.txt. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > > > This WGLC will end on Friday April 20. > > > > Please mail all your final comments to the author and the mmusic > > mailing > > list. >=20 > I notice that there are a number of IPR claims against ICE: >=20 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D799 > (Cisco) > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D727 > (Tandberg) > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D728 > (Tandberg) > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D729 > (Tandberg) >=20 > The license terms offered for the Cisco IPR are reasonable, and not > problematic. >=20 > The license terms offered by Tandberg are more of a concern. While > the intent to grant a royalty free license is greatly appreciated, > the requirement to negotiate the license, rather than explicitly > granting a royalty free license to anyone to implement the standard, > is a barrier for open-source implementers. I would hope Tandberg will > revise these terms, before ICE is considered for publication. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 16:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMrB-0004wB-4P; Tue, 10 Apr 2007 16:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMrA-0004w5-Ok for mmusic@ietf.org; Tue, 10 Apr 2007 16:22:24 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMr9-0001l2-Eo for mmusic@ietf.org; Tue, 10 Apr 2007 16:22:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Date: Tue, 10 Apr 2007 16:22:26 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D740@m5tmail1.m5t.com> In-Reply-To: <461BE88B.5020509@pjsip.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Thread-Index: Acd7qFOcDWfIDqfFToOnBIGLb1PUrwAAnAKw From: "Guylain Lavoie" To: "Benny Prijono" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hello Benny, If someone else does not comment on this ICMP issue, I will assume from now on that multiple sockets (for a component) are not required since recevied ICMP can just be discarded. Concerning the TCP extension of the specification, IMHO, the source address of the connection DOES matter. At least, for Passive and Simultaneous Open TCP candidate. This is because the agent must allocate both an host candidate and its associated server reflexive candidate. Both candidates must share the same source address and port. So, effectively, we must be able to bind at least two sockets at the same location. And as stated before, this does not seems to be possible on all platforms. Can you explain why you say that the same source address is not important? Regards, Guylain -----Original Message----- From: Benny Prijono [mailto:bennylp@pjsip.org]=20 Sent: April 10, 2007 3:42 PM To: Guylain Lavoie Cc: mmusic@ietf.org Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Hi Guylain, I can't speak for ICE standards or best practices, having learned it only in the past few weeks, but I think creating one socket for each candidate *pair* is not the way ICE is supposed to be done, because that needs one heck a lot of sockets and it doesn't work on most platforms, as you said, especially if this is only needed just to get the benefit of ICMP. So I don't think ICMP would need to be mandated at all by ICE, CMIIW. I don't think this issue would matter for ICE TCP, since with ICE TCP the source address of the connection does not matter, so they don't need to be bound to the same address/port. -benny Guylain Lavoie wrote: > Hi Benny, >=20 > Optional support of ICMP reception is perfectly fine for me because it > is much more easier to implement. >=20 > However, if it is mandated, we would basically need to allocate one=20 > socket for each candidate pair plus one for each server reflexive=20 > candidate and relayed candidate. That's a lot of sockets, but that way > you can do a connect on all of them. This solution would work fine on=20 > some operating systems, but on others, it would not because the socket > option SO_REUSEPORT is not available and it is needed so that all=20 > socket may be bound to the same address and port. From what I read,=20 > this is not available on Linux. This might be true for other operating > systems as well. You would also need an non connected socket to be=20 > able to support reception of connectivity checks before the SDP answer > arrives. This would also be required to receive a connectivity check=20 > from a peer reflexive candidate (which is unknown and thus cannot be connected to). >=20 > NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are needed for=20 > an implementation of TCP with ICE because all TCP sockets are=20 > inherently connected and must be bound to the same address and port.=20 > Like with UDP, this would probably no work on all operating systems.=20 > This is mentioned in some NAT hole punching technique papers. >=20 > Thanks > Guylain >=20 > -----Original Message----- > From: Benny Prijono [mailto:bennylp@pjsip.org] > Sent: April 10, 2007 1:25 PM > To: Guylain Lavoie > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran=20 > aggressive nomination? >=20 > Hi Guylain, >=20 > Guylain Lavoie wrote: >> Hi Benny, >> >> I am wondering how you plan on demultiplexing ICMP errors if a single >> socket is shared for all candidate of a component? >> How will you associate a received ICMP errors with a specific=20 >> Connectivity Checks or even a Binding Discovery Request used to keep=20 >> server reflexive candidate alive (keepalive)? Normally, at least, on=20 >> BSD like stack, you must connect the UDP socket to be able to=20 >> reliably >=20 >> receive ICMP errors. >=20 > Even if you use one socket for each candidate, I'm not sure if you can > do UDP connect() on each of them, as ICE requires you to send=20 > connectivity checks to multiple destinations. >=20 >> Not connecting the socket would not allow you to fully comply with=20 >> the >=20 >> specification (your implementation would end up waiting for the full=20 >> timeout when such thing happens). >=20 > I view ICMP handling as "if you can and want to handle it, then do it, > if not, then you know the risk" kind of thing, so I would disagree=20 > that we should call these implementations not fully comply just=20 > because they don't/can't handle ICMP. >=20 > cheers, > -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 19:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQ90-0000SS-PR; Tue, 10 Apr 2007 19:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQ8z-0000S9-Kv for mmusic@ietf.org; Tue, 10 Apr 2007 19:53:01 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQ8t-0002NO-UF for mmusic@ietf.org; Tue, 10 Apr 2007 19:53:01 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3ANqqQ22820; Tue, 10 Apr 2007 23:52:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Tue, 10 Apr 2007 18:52:36 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371139D1315@zrc2hxm2.corp.nortel.com> In-Reply-To: <461B9001.9080402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition thread-index: Acd7c/hF8ceRqMfyT0G2xI5e6PZfcAAVotgw References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> From: "Brian Stucker" To: "Jonathan Rosenberg" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, please see below. I'm not sure your response meshes with what's in the draft. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, April 10, 2007 8:24 AM > To: Audet, Francois (SC100:3055) > Cc: Elwell, John; mmusic@ietf.org > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6=20 > transition >=20 > inline. >=20 > Francois Audet wrote: >=20 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> > >> > >>>[JRE] Indeed, and that is because micro-lite would be employed in=20 > >>>non-NAT environments (or SBC environments) where IPv4/IPv6 > >> > >>transition is needed. > >> > >>Which only underscores the point - this is not ICE, this is=20 > something=20 > >>entirely orthogonal. Its ANAT with ICE syntax. > >=20 > >=20 > > Or you could say it's ICE with a possibility of bypassing the=20 > > connectivity check WHEN APPROPRIATE. > >=20 > > In my mind, BOTH sides would have to explicitly indicate that they=20 > > wish to use ice-microlite for the bypass to happen. > >=20 > > If either end is behind a NAT, it will therefore end-up=20 > using full-ice=20 > > because it will not include the microlite flag. >=20 > No, it won't. The problem is that if the offeror sends=20 > 'ice-micro-lite'=20 > and the answerer is behind a NAT and wants full ICE, the=20 > answerer is out of luck. ICE-lite has this really important=20 > property that, if one side is ice-lite, and the other is=20 > full, the full side still gets the entire complete benefits=20 > of ICE for NAT traversal. >=20 > >=20 > > In fact, wouldn't this be useful even for ice-lite (not=20 > microlite, just > > lite), where > > if both PSTN gateways are on the public internet, they know=20 > right away > > they can skip the > > connectivity check? >=20 > That already happens. If both agents are ICE lite, there are no=20 > connectivity checks that get utilized. >=20 Jonathan, I don't understand what you mean by if both agents are ICE lite, there are no connectivity checks. Looking at section 5 and 5.1 of ICE-15, I see the following text: --- 5. Receiving the Initial Offer When an agent receives an initial offer, it will check if the offeror supports sufficient ICE functionality to proceed (i.e., if both offeror and answerer are lite implementations, ICE cannot proceed), determine its own role, gather candidates, prioritize them, choose default candidates, encode and send an answer, and for full implementations, form the check lists and begin connectivity checks. 5.1. Verifying ICE Support The answerer will proceed with the ICE procedures defined in this specification if the following are all true: o For each media stream, the default destination for at least one component of the media stream appears in a candidate attribute. For example, in the case of RTP, the IP address and port in the c and m line, respectively, appears in a candidate attribute, or the value in the rtcp attribute appears in a candidate attribute. o The offer omitted an a=3Dice-lite attribute or the answerer is a full implementation. In other words, if both agents are lite implementations, the agent does not proceed with ICE. If any of these conditions are not met, the agent MUST process the SDP based on normal RFC 3264 procedures, without using any of the ICE mechanisms described in the remainder of this specification with the following exceptions: 1. The agent MUST follow the rules of Section 10, which describe keepalive procedures for all agents. 2. If the agent is not proceeding with ICE because there were a=3Dcandidate attributes, but none that matched the default destination of the media stream, the agent MUST include an = a=3Dice- mismatch attribute in its answer. --- I read this as saying that if both the offerer and answerer specify ice-lite, then you drop back to 3264, meaning that there's not just no connectivity checks, there's no candidate lines either because there's no ICE. Regards, Brian > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 10 20:11:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQQi-0001Fa-4R; Tue, 10 Apr 2007 20:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQQg-0001FR-VW for mmusic@ietf.org; Tue, 10 Apr 2007 20:11:18 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQQf-0008Jn-Np for mmusic@ietf.org; Tue, 10 Apr 2007 20:11:18 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3B0BEm00532; Wed, 11 Apr 2007 00:11:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Tue, 10 Apr 2007 19:11:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> In-Reply-To: <461B9001.9080402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition thread-index: Acd7c5NCY6DqmL6uQLSLaVIXh3/vYAAVlkHA References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org =20 > > In fact, wouldn't this be useful even for ice-lite (not=20 > microlite, just > > lite), where > > if both PSTN gateways are on the public internet, they know=20 > right away > > they can skip the > > connectivity check? >=20 > That already happens. If both agents are ICE lite, there are no=20 > connectivity checks that get utilized. Jonathan, I'm reading your section 5 of ICE-15, and I think we have almost what is requested. We probably don't even need anything beyond ice-lite. A sends offer to B. It is not behind a NAT, but it is dual stack and supports IPv4 and IPv6, so it has: Offer: m=3DIPv4 <- Assumption is that IPv4 is more likely to succeed than IPv6 candidate 1=3DIPv6 candidate 2=3DIPv4 a=3Dice-lite B receives the offer, it is also dual stack and NOT behind a NAT. It sends an answer: m=3DIPv4 candidate 1=3DIPv6 candidate 2=3DIPv4 a=3Dice-lite According to your section 5 it would result in having "NO CONNECTIVITY CHECK". (PS: your wording says "ICE cannot proceed", which I think is innacurate since=20 the candidates have already been sent, so I think you need to clarify that it means "does not proceed with the connectivity check). According to section 5 again, it would result in having the IPv4 selected instead of the IPv6 (i.e., the m line). That's NOT the behavior we want. What we want is in this case to have both sides use the candidates and the RFC XXXX procedures (the selection thing: I don't have the number). One easy way to do this is to have B responding with this answer instead: m=3DIPv6 <- i.e., forcing the other side to use the IPv6 address candidate 1=3DIPv6 <- I'm not sure we actually need this line a=3Dice-lite <- This is to tell A that it understood ICE And B would just use the candidate 1=3DIPv6 from the offer anyways to = send media. I think this solves the problem, no? Isn't this trivial? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 11 03:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXO3-0007ya-Ce; Wed, 11 Apr 2007 03:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXO2-0007yI-9H for mmusic@ietf.org; Wed, 11 Apr 2007 03:37:02 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXNz-0000X1-MY for mmusic@ietf.org; Wed, 11 Apr 2007 03:37:02 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JGB00I5QP5IRL@siemenscomms.co.uk> for mmusic@ietf.org; Wed, 11 Apr 2007 08:36:54 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Apr 2007 08:36:58 +0100 Content-return: allowed Date: Wed, 11 Apr 2007 08:36:57 +0100 From: "Elwell, John" Subject: Tie breaker (was RE: [MMUSIC] Re: ICE micro-lite for support of I Pv6 transition) To: Jonathan Rosenberg , Guylain Lavoie Message-id: <50B1CBA96870A34799A506B2313F26670B862095@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, Looking again at ice-15, it doesn't really explain why we need the tie breaker - it just says "in unusual cases". The basic rule is that the controlling role is assigned to the sender of the offer. This is true also for 3PCC. Well, OK, I could imagine there are some 3PCC implementations that break this, but I think there are other things in SDP that are broken if you start mixing up offers and answers. For example, embedded MIKEY using a=key-mgmt, or the recent SDP capability negotiation. We have not built anything into those mechanisms to help cater for rogue 3PCC implementations, so why is it necessary to do so for ICE? John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 09 April 2007 14:14 > To: Guylain Lavoie > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 > transition > > inline. > > Guylain Lavoie wrote: > > > > By the way, can someone more knowledgeable than me explain > why ICE-lite > > cannot include more than one host candidate per component > when he knows > > that both are always accessible? Is this an arbitrary decision or is > > there something that does not allow this? > > It is most certainly NOT arbitrary. ICE-lite falls apart when > you do this. > > The reason is as follows. Remember that an important part of ICE > processing is this 'fix-up' operation, whereby, if the candidate > selected by ICE is not matching the m/c-line, the controlling > agent does > an updated offer to make them match. This was deemed important for > backwards compatibility with lots of middleboxes that want to > see media > sent to the target of the m/c-line. > > With ice-lite, since there is only ever one candidate, it > always matches > the m/c-line, and so the agent never needs to do fix-ups. > > Now, if you allow multiple candidates, what happens if both sides are > ice-lite, but a candidate is selected that does NOT match the > m/c-line? > Well, now you need to do the fix-up re-invite. So, you'd now lose the > property that, when both sides are ice-lite, you basically > don't do ICE > at all. You'd have to do some third subset of ICE. > > So, let us continue down this line of thought. What if we > specify that? > What if, with ice-lite, you still do some kind of third mode > when both > sides are ice-lite, so that the fix-up reinvite is done? > Well, to do the > fix-up, you need to select a controlling and controlled node. > Folks will > recall that, in certain 3pcc cases, it is possible for both agents to > think they are controlled, or both to think they are controlling. THe > fix for this in ice-15 is to use flags in the STUN checks > themselves to > sort out this ambiguity. However, we wouldn't be having any > checks here, > so we'd have an unresolved ambiguity. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 11 08:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbcKQ-0008QL-9H; Wed, 11 Apr 2007 08:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbcKO-0008I7-JJ for mmusic@ietf.org; Wed, 11 Apr 2007 08:53:36 -0400 Received: from prix.tandberg.no ([194.196.35.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbcKM-0004NI-V7 for mmusic@ietf.org; Wed, 11 Apr 2007 08:53:36 -0400 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.11.20060308/8.12.10) with ESMTP id l3BCr9IX001904; Wed, 11 Apr 2007 14:53:30 +0200 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by 47mail.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 14:53:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Wed, 11 Apr 2007 14:53:28 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB188158@oslexcp1.eu.tandberg.int> In-Reply-To: <04d301c77bab$99053d70$65500a0a@ronin> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Thread-Index: Acd7q6UUjl2K5NvYQJWF/GHGfG+CwgAigTkg From: "Geir Arne Sandbakken" To: "Eric Cooper" X-OriginalArrivalTime: 11 Apr 2007 12:53:30.0504 (UTC) FILETIME=[67CFE880:01C77C38] X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Jean-Francois Mule , mmusic@ietf.org, Joerg Ott , Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Eric, Not being a lawyer myself I can not verify the analysis, but I will forward this mail to someone who can. It is still under revision as more comments have been presented on the latest version of the IPR. Geir Arne > -----Original Message----- > From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] > Sent: 10 April 2007 22:05 > To: Geir Arne Sandbakken > Cc: mmusic@ietf.org; Joerg Ott; Jean-Francois Mule; Colin Perkins > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 > Hi Geir Arne, >=20 > I am not a patent lawyer but I have been discussing Tandberg's ICE-related > IPR statements with someone who is. He has provided the following > analysis: >=20 > "The Patent Holder is prepared to grant, on the basis of reciprocity in > accordance with the above IETF specification, a license to an unrestricted > number of applicants. Such licenses shall be on a worldwide, non- > discriminatory basis and on reasonable terms and conditions permitting > licensee to make, use and sell implementations of the above IETF > specification." >=20 > This part refers to parties who do not have patent protection on something > considered "essential" to practice the standard. These people will have > to pay a royalty to Tandberg for complying with the standard (to the > extent a Tandberg patent is essential to compliance). >=20 > "The Patent Holder is prepared to grant a "free" license to any > prospective licensee if such prospective licensee will commit to license > its own essential patent(s) or essential patent claim(s) for > implementation of any IETF specification for "free"." >=20 > This part says that to the extent a party that has something that is > essential to ANY IETF specification, a "free" license can be obtained. > Then they give a definition of free which means only no money will be > demanded - they can still demand a royalty free license to an entire > product portfolio, restrict the field of use, etc. >=20 > Can you comment on this analysis? >=20 > If the above analysis is correct, I think these terms would hinder ICE's > adoption. Would Tandberg agree to terms similar to these: >=20 > http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-mpls-interas-lspping- > 00.txt ? >=20 > Best Regards, >=20 > Eric. >=20 >=20 > ----- Original Message ----- > From: "Geir Arne Sandbakken" > To: "Colin Perkins" ; "Jean-Francois Mule" > > Cc: ; "Joerg Ott" > Sent: Tuesday, April 03, 2007 5:05 AM > Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 >=20 > Colin, >=20 > The part of the IPR concerning negotiation of a license is adopted from > the standard ITU patent policy statement. We understand you concern, > and it is now under revision. >=20 > Cheers, > Geir Arne >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: 01 April 2007 15:00 > > To: Jean-Francois Mule > > Cc: mmusic@ietf.org; Joerg Ott > > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > > > > [Not as chair] > > > > On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote: > > > This is to announce a Working Group Last Call on ICE > > > draft-ietf-mmusic-ice-15.txt. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > > > > > This WGLC will end on Friday April 20. > > > > > > Please mail all your final comments to the author and the mmusic > > > mailing > > > list. > > > > I notice that there are a number of IPR claims against ICE: > > > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D799 > > (Cisco) > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D727 > > (Tandberg) > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D728 > > (Tandberg) > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D729 > > (Tandberg) > > > > The license terms offered for the Cisco IPR are reasonable, and not > > problematic. > > > > The license terms offered by Tandberg are more of a concern. While > > the intent to grant a royalty free license is greatly appreciated, > > the requirement to negotiate the license, rather than explicitly > > granting a royalty free license to anyone to implement the standard, > > is a barrier for open-source implementers. I would hope Tandberg will > > revise these terms, before ICE is considered for publication. > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 11 09:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbd9T-0003J7-A8; Wed, 11 Apr 2007 09:46:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbd9R-0003Iv-Rq for mmusic@ietf.org; Wed, 11 Apr 2007 09:46:21 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbd9L-0001Iw-Un for mmusic@ietf.org; Wed, 11 Apr 2007 09:46:21 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JGC00N3U68O34@siemenscomms.co.uk> for mmusic@ietf.org; Wed, 11 Apr 2007 14:46:00 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Apr 2007 14:46:05 +0100 Content-return: allowed Date: Wed, 11 Apr 2007 14:46:02 +0100 From: "Elwell, John" To: Jonathan Rosenberg , mmusic@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670B86257D@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [MMUSIC] Further comments on ICE-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, Yet more comments from myself and a colleague. Apologies if any have already been discussed. "Candidate: A transport address that is to be tested by ICE procedures in order to determine its suitability for usage for receipt of media." A candidate will not necessarily be tested, because it may not be compatible (e.g., an IPv6 candidate will not be acceptable to an IPv4-only endpoint) or because aggressive mode has already found a suitable candidate-pair. Perhaps it should say "A transport address that requires testing by ICE procedures in order...." "The process for selecting default candidates at the answerer is identical to the process followed by the offerer, as described in Section 4.1.3 for full implementations and Section 4.2 for lite implementations." I would suggest that each default candidate of the answerer MUST be compatible with the corresponding default candidate of the offerer. Otherwise it may happen, that the default candidates of the offerer are v4 addresses and the default candidates of the answerer v6 ones. That makes little sense. "If this happens, the number of components for that media stream is effectively reduced, and considered to be equal to the minimum across both agents of the maximum component ID provided by each agent across all components for the media stream." Maybe this works for RTP/RTCP, but is it sufficiently general? What if for some reason in future there are 3 components for a media stream and that R has included candidates for all components (1,2,3) but L includes candidates only for 1 and 3? "The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are two states:" In fact three states are listed. "This state is equal to Running while checks are in progress. The state is Completed when all checks have been completed." There should be a corresponding statement for Failed. "Once the agent has computed the check lists as described in Section 5.7, it sets a timer for each active check list." In fact, there will only be one active check list at this stage. "The first timer for each active check list fires immediately" There will only be one active check list initially. "5.8. Performing Periodic Checks" Should it be mentioned somewhere in this section when a frozen check list should become active? "(as defined in [12]," Closing bracket missing. "If the check list is frozen, and there is at least one pair in the check list whose foundation matches a pair in the valid list under consideration, the state of all pairs in the check list whose foundation matches a pair in the valid list under consideration are set to Waiting." Do we need to say anything about starting the timer for periodic checks? "This flag indicates that this valid pair should be used for media if it is the highest priority one amongst those whose nominated flag is set." Since the formula for computing priorities produces unique priorities only "in most cases", we should have some statement here about how to deal with equal priorities. "In cases where multiple STUN requests are received before the answer, this may cause several triggered notifications to all be sent at the same time," Incomplete sentence. Or maybe the comma should be a period. "In unusual cases it is possible for both agents to mistakenly believe they are controlled or controlling. To deal with such cases, at the time an agent determines its role, it MUST select a random number, called the tie-breaker, uniformly distributed between 0 and (2**64) - 1 (that is, a 64 bit positive integer)." Notwithstanding the comment I made in a separate email about the need for a tie-breaker, if we really do need a tie-breaker why can't the ice-pwd be used instead, because that has a similar amount of randomness? "9.1.1.1. ICE Restarts" If an endpoint receives a SIP re-INVITE without an SDP offer, and as a result has to send an SDP offer in a SIP 2xx response, should this be treated as an ICE restart or a new session. It could be as a result of a 3PCC transfer, so effectively it would need to be a new session, but the endpoint has no way of knowing that. So it would have to treat it as a new session to be safe. This then means that existing media cannot continue to flow, which would be a disadvantage if it isn't really a new session. We should make some statement about this situation. Furthermore, if the peer rejects the offer, what should happen? "The only difference between an ICE restart and a brand new media session is that, during the restart, media can continue to be sent to the previously validated pair." Presumably with a restart, if the offer gets rejected, existing media will still continue. Furthermore existing period connectivity checking will continue using the old password. Should clarify. "In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS using an A or AAAA record, and the resulting IP address is used for the remainder of ICE processing." What if the DNS look-up yields both an IPv4 and an IPv6 address? "Consequently, ICE serves to repair the brittleness introduced in other UNSAF mechanisms, and does not introduce any additional brittleness into the system." Probably true, but isn't it worth mentioning the performance impact, i.e., potentially longer call set-up time? "A full implementation will reduce call setup times." Why would a full implementation reduce call set up times compared to lite? Some explanation would be appropriate. The only reason I can think of is the fact that lite prevents use of aggressive mode. John _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 11 13:48:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbgvT-0007hg-VQ; Wed, 11 Apr 2007 13:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbgvT-0007hb-9y for mmusic@ietf.org; Wed, 11 Apr 2007 13:48:11 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbgvQ-0000Vy-TK for mmusic@ietf.org; Wed, 11 Apr 2007 13:48:11 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l3BHltJ1029677; Wed, 11 Apr 2007 13:47:55 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l3BHlsPM023426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Apr 2007 13:47:55 -0400 In-Reply-To: <4614F7DD.5020902@cisco.com> References: <17940.9088.826718.530635@cnr.cs.columbia.edu> <4614F7DD.5020902@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A308EBB-D37F-4159-97A9-1BF9149D44B1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE-15: pair priorities with 3PCC Date: Wed, 11 Apr 2007 13:48:40 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org If I understand this comment correctly, then the only question is which end is the offerer and which end is the answerer. Given that the formula is: pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0) the value of the priority differs by at most one if the roles of the offerer and answerer are reversed. So how important is this really? - Philip On 5-Apr-07, at 09:21 , Jonathan Rosenberg wrote: > I think this is a good suggestion and I've made the change in my > working -16. > > Thanks, > Jonathan R. > > > Jonathan Lennox wrote: > >> The ICE pair-priority formula (defined in section 5.7.2) takes as its >> parameters the priority of the offerer's candidate and that of the >> answerer's candidate. >> However, in 3PCC scenarios, the two endpoints can disagree about >> which of >> them is the offerer. This was the reason for the introduction of the >> ICE-CONTROLLING and ICE-CONTROLLED attributes in ICE-15. In this >> case, the >> two endpoints would calculate different pair priorities, and thus >> start >> their periodic checks in a different order. >> As I understand it, the order of the periodic checks is important >> to the >> protocol, so that "suicide packets" hit firewalls at roughly the >> same time; >> this is why the prioritization algorithm is normative. As such, a >> disagreement about which party is the offerer would cause a problem. >> My suggestion would be to change the formula of 5.7.2. Rather >> than having >> its parameters be the offerer's priority and the answerer's >> priority, the >> parameters would instead be the controlling endpoint's priority >> and the >> controlled endpoint's priority. >> Thus, if an endpoint switches its role after "losing" a role >> conflict, >> following the procedures of 7.2.1.1, it needs to re-calculate its >> pair >> priorities and re-sort its check lists. >> This change to the formula won't cause a compatibility problems >> with ICE-14 >> or earlier, or with ICE-15 if there hasn't been a role conflict, >> because the >> only case in which the offerer is not the controller is if the >> offerer is >> using ICE-lite. Since an ICE-lite endpoint can list only a single >> candidate, the order of the check list will be the same either >> way, and >> anyway doesn't matter since the lite endpoint isn't sending any >> checks. >> Thoughts? > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 11 19:32:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbmIx-00072J-LM; Wed, 11 Apr 2007 19:32:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbmIv-00072B-UM for mmusic@ietf.org; Wed, 11 Apr 2007 19:32:45 -0400 Received: from maildialog.com ([195.159.98.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbmIt-0005IY-0g for mmusic@ietf.org; Wed, 11 Apr 2007 19:32:45 -0400 Received: from [84.209.225.83] (helo=[10.0.0.4]) by maildialog.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51-maildialog) id 1HbmIq-0002Ar-EU; Wed, 11 Apr 2007 23:32:40 +0000 Message-ID: <461D7014.1000900@db.org> Date: Thu, 12 Apr 2007 01:32:36 +0200 From: "Alfred E. Heggestad" User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Guylain Lavoie Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? References: <6EF4CC794ECF2B409390605FDEA9012218D740@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D740@m5tmail1.m5t.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Guylain Lavoie wrote: > > Concerning the TCP extension of the specification, IMHO, the source > address of the connection DOES matter. At least, for Passive and > Simultaneous Open TCP candidate. This is because the agent must allocate > both an host candidate and its associated server reflexive candidate. > Both candidates must share the same source address and port. So, > effectively, we must be able to bind at least two sockets at the same > location. And as stated before, this does not seems to be possible on > all platforms. > Guylain, can you explain why you need 2 sockets for host+srflx candidate? my understanding is that first you open one socket for a particular network interface, which is used as a host candidate, and then send a STUN Binding Request from the *same* socket to obtain a server reflexive candidate, with the corresponding host socket as base.. i.e. you would only need 1 socket. /alfred _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 03:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbtNf-0002qN-Qx; Thu, 12 Apr 2007 03:06:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbtNd-0002qD-MJ for mmusic@ietf.org; Thu, 12 Apr 2007 03:06:05 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbtNc-0002RA-81 for mmusic@ietf.org; Thu, 12 Apr 2007 03:06:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3C75lQV024357; Thu, 12 Apr 2007 10:06:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:06:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:06:01 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:06:01 +0300 Received: from esdhcp04062.research.nokia.com (esdhcp04062.research.nokia.com [172.21.40.62]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3C75x0M011850; Thu, 12 Apr 2007 10:05:59 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org Subject: Re: [MMUSIC] ICE-15: when do you stop waiting =?iso-8859-1?q?foran=09aggressive=09nomination=3F?= Date: Thu, 12 Apr 2007 10:06:23 +0300 User-Agent: KMail/1.9.6 References: <6EF4CC794ECF2B409390605FDEA9012218D6D5@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D6D5@m5tmail1.m5t.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704121006.23570.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Apr 2007 07:06:01.0310 (UTC) FILETIME=[07231FE0:01C77CD1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Tuesday 10 April 2007 19:12:25 ext Guylain Lavoie wrote: > I am wondering how you plan on demultiplexing ICMP errors if a single > socket is shared for all candidate of a component? > How will you associate a received ICMP errors with a specific > Connectivity Checks or even a Binding Discovery Request used to keep > server reflexive candidate alive (keepalive)? Normally, at least, on BSD > like stack, you must connect the UDP socket to be able to reliably > receive ICMP errors. This is a common issue with UDP applications. FYI, if you really want to=20 handle ICMP errors on an unconnected UDP socket, you can usually dequeue=20 error messages separately through recvmsg(). Most people simply ignore the= =20 errors, which should be OK for ICE, since it has fairly low packets sending= =20 rate until a pair is confirmed. Another possibility consists of creating as= =20 many connected UDP sockets as you may need, possibly bound to the same port= =20 (with SO_REUSEADDR, SO_REUSEPORT or whatever, most BSD stacks allow this=20 somehow). =20 > from ICE-15, 7.1.2.1, "If the STUN transaction generates an ICMP error, > or..." > > Not connecting the socket would not allow you to fully comply with the > specification (your implementation would end up waiting for the full > timeout when such thing happens). Good point. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 03:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbteQ-0003ub-9j; Thu, 12 Apr 2007 03:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbteO-0003uV-6x for mmusic@ietf.org; Thu, 12 Apr 2007 03:23:24 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbteN-0007up-O2 for mmusic@ietf.org; Thu, 12 Apr 2007 03:23:24 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3C7NJnI025613 for ; Thu, 12 Apr 2007 10:23:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:22:58 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:22:57 +0300 Received: from esdhcp04062.research.nokia.com (esdhcp04062.research.nokia.com [172.21.40.62]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3C7Mumg021807 for ; Thu, 12 Apr 2007 10:22:56 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 12 Apr 2007 10:23:20 +0300 User-Agent: KMail/1.9.6 References: <6EF4CC794ECF2B409390605FDEA9012218D52F@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D52F@m5tmail1.m5t.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704121023.20915.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 12 Apr 2007 07:22:58.0028 (UTC) FILETIME=[6525FAC0:01C77CD3] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070412102321-62809BB0-55F7D7DF/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Thursday 05 April 2007 21:57:23 ext Eric Tremblay wrote: > I think John wants to have a light mechanism that dual IP stack hosts > can easily implement, and I have to fully agree with him. In a closed deployment, you may use ANAT if you like - the protocol police= =20 won't put you to jail. In any other case, you need at least ICE-Lite: even if you can warrant that= =20 your agent has no firewall, no NAT, etc, and does not need ICE... the other= =20 side might well need it because it might have a firewall and/or a NAT on it= s=20 side. The whole point is that you cannot assume some third party will not=20 need you to have at least ICE-Lite because of hir/her network contraints,=20 regardless of yours. As an aside, back to closed deployments, it is fairly likely that you won't= =20 need dual-stack either. > ICE-lite, which is a lot less complex, is still too complex when all > that is required is dual stack support. But, it is useless to talk about > ICE-lite if it does not support the addition of multiple host candidates > for a single component. An implementation of ICE-lite would not solve > this problem and we have to resort to an ICE-full implementation. > Something that in my opinion is too much to ask. There should not be any issues with allowing ICE-Lite to advertise one addr= ess=20 per network protocol rather than only one address. The ICE peer will have t= o=20 peer matching network protocol anyway, if it's dual-stack. > Thus, my feeling as a protocol stack developer is that our customers > will not buy ICE if they plan to develop simple dual IP stack devices. > They will thus most probably rely on ANAT. We need to somehow define an > evolutionary path towards ICE, and I wonder which path is the easiest > for overall interop: ICE interop with ANAT or ICE interop with ICE > micro-lite You cannot make ICE interop with ANAT as far as some of ICE's features may = be=20 required for the connection to work. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 10:47:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0a3-0000rK-1r; Thu, 12 Apr 2007 10:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0a1-0000pf-5G for mmusic@ietf.org; Thu, 12 Apr 2007 10:47:21 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc0Zz-0002tn-Tn for mmusic@ietf.org; Thu, 12 Apr 2007 10:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Date: Thu, 12 Apr 2007 10:47:17 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D88D@m5tmail1.m5t.com> In-Reply-To: <461D7014.1000900@db.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Thread-Index: Acd8kbPtIszQzRWDS+qiCnFXf+KWowAef3Mg From: "Guylain Lavoie" To: "Alfred E. Heggestad" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Alfred, In don't really understand what you mean. How can you send Binding Request to a STUN server without ever connecting the socket? Remember, it is TCP that we are talking about, not UDP. For a passive candidate, you really need to allocate at least two TCP sockets and bind them at the same address and port. One will be a TCP server socket and will be used to receive TCP connection requests associated with peer initialited connectivity checks from its Active candidates (Reception of a connection request will effectively create a entirely new socket, also bound at the same address and port). The other will be a TCP client socket connected to the STUN server to gather a server reflexive candidate and periodically, it will also send Binding Request to keep alive the NAT binding. For SO, it is a bit different. You need to allocate at least two TCP client sockets and also bind them at the same address and port. One will be connected to the STUN server to gather a server reflexive candidate and periodically send Binding Request to keep alive the NAT binding. The other, or others, are used to send connectivity checks to the peer SO candidates. Each one of them must be connected to peer SO candidate before sending its connecitivity checks. The situation becomes even more complex if you think that you may have more than one STUN server. Note however, that the specification does not encourage this. Regards, Guylain -----Original Message----- From: Alfred E. Heggestad [mailto:aeh@db.org]=20 Sent: April 11, 2007 7:33 PM To: Guylain Lavoie Cc: Benny Prijono; mmusic@ietf.org Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Guylain Lavoie wrote: >=20 > Concerning the TCP extension of the specification, IMHO, the source=20 > address of the connection DOES matter. At least, for Passive and=20 > Simultaneous Open TCP candidate. This is because the agent must=20 > allocate both an host candidate and its associated server reflexive candidate. > Both candidates must share the same source address and port. So,=20 > effectively, we must be able to bind at least two sockets at the same=20 > location. And as stated before, this does not seems to be possible on=20 > all platforms. >=20 Guylain, can you explain why you need 2 sockets for host+srflx candidate? my understanding is that first you open one socket for a particular network interface, which is used as a host candidate, and then send a STUN Binding Request from the *same* socket to obtain a server reflexive candidate, with the corresponding host socket as base.. i.e. you would only need 1 socket. /alfred _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 11:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0xE-0005tt-H9; Thu, 12 Apr 2007 11:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc0xD-0005tn-S4 for mmusic@ietf.org; Thu, 12 Apr 2007 11:11:19 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc0xB-0005bn-H7 for mmusic@ietf.org; Thu, 12 Apr 2007 11:11:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive nomination? Date: Thu, 12 Apr 2007 11:11:17 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218D89A@m5tmail1.m5t.com> In-Reply-To: <000001c77ba8$84dd8260$c4f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-15: when do you stop waitingforan aggressive nomination? Thread-Index: Acd7lW2cG2DcHn7ERS6Lxsw+amCCswAAEBtAAANRG4AAW+0zsA== From: "Guylain Lavoie" To: "Dan Wing" , "Benny Prijono" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Dan, Although ICMP may be lost in transit for multiple reasons like the one you stated I would really like to know, from an ICE implementer perspective, what exactly are we required to implement. Must an implementation be able to receive these ICMP errors and correctly associate them, without ambiguity, to the correct STUN usage which triggered them in the first place? Or, is an implementation allowed to ignore them with the consequence of having to wait until the full timeout. Having the correctly manage ICMP adds a lot of complexity to the implementation. Do we have to resort to this added complexity (lot of connected UDP sockets) or can we just ignore ICMP and use only a non connected UDP socket for all operations. Benny has indicated that he would ignore ICMP reception. Should we all do that? Thanks, Guylain=20 -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: April 10, 2007 3:43 PM To: Guylain Lavoie; 'Benny Prijono' Cc: mmusic@ietf.org Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive nomination? =20 > -----Original Message----- > From: Guylain Lavoie [mailto:glavoie@m5t.com] > Sent: Tuesday, April 10, 2007 11:31 AM > To: Benny Prijono > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive > nomination? >=20 > Hi Benny, >=20 > Optional support of ICMP reception is perfectly fine for me because it > is much more easier to implement. >=20 > However, if it is mandated, ICMP can't be mandated by ICE. ICMP is often filtered due to incompetence, overzealous administrators, or insufficient configuration granularity in firewalls and NATs. -d > we would basically need to allocate one socket for each candidate pair > plus one for each server reflexive candidate and relayed candidate.=20 > That's a lot of sockets, but that way you can do a connect on all of=20 > them. This solution would work fine on some operating systems, but on=20 > others, it would not because the socket option SO_REUSEPORT is not=20 > available and it is needed so that all socket may be bound to the same > address and port. From what I read, this is not available on Linux.=20 > This might be true for other operating systems as well. You would also > need an non connected socket to be able to support reception of=20 > connectivity checks before the SDP answer arrives. This would also be=20 > required to receive a connectivity check from a peer reflexive=20 > candidate (which is unknown and thus cannot be connected to). >=20 > NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are needed for=20 > an implementation of TCP with ICE because all TCP sockets are=20 > inherently connected and must be bound to the same address and port. > Like with UDP, > this would probably no work on all operating systems. This is=20 > mentioned in some NAT hole punching technique papers. >=20 > Thanks > Guylain >=20 > -----Original Message----- > From: Benny Prijono [mailto:bennylp@pjsip.org] > Sent: April 10, 2007 1:25 PM > To: Guylain Lavoie > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran=20 > aggressive nomination? >=20 > Hi Guylain, >=20 > Guylain Lavoie wrote: > > Hi Benny, > >=20 > > I am wondering how you plan on demultiplexing ICMP errors > if a single > > socket is shared for all candidate of a component? > > How will you associate a received ICMP errors with a specific=20 > > Connectivity Checks or even a Binding Discovery Request > used to keep > > server reflexive candidate alive (keepalive)? Normally, at > least, on > > BSD like stack, you must connect the UDP socket to be able > to reliably >=20 > > receive ICMP errors. >=20 > Even if you use one socket for each candidate, I'm not sure if you can > do UDP connect() on each of them, as ICE requires you to send=20 > connectivity checks to multiple destinations. >=20 > > Not connecting the socket would not allow you to fully > comply with the >=20 > > specification (your implementation would end up waiting for > the full > > timeout when such thing happens). >=20 > I view ICMP handling as "if you can and want to handle it, then do it, > if not, then you know the risk" kind of thing, so I would disagree=20 > that we should call these implementations not fully comply just=20 > because they don't/can't handle ICMP. >=20 > cheers, > -benny >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 11:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1Yz-0004GT-Ra; Thu, 12 Apr 2007 11:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1Yy-0004Dz-MN for mmusic@ietf.org; Thu, 12 Apr 2007 11:50:20 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc1Yu-0007fW-Du for mmusic@ietf.org; Thu, 12 Apr 2007 11:50:20 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l3CFo98T018563; Thu, 12 Apr 2007 11:50:09 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l3CFo7Ix002404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Apr 2007 11:50:09 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 12 Apr 2007 11:50:01 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mmusic@ietf.org Subject: [MMUSIC] Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan: ICE-15 allows the address of a candidate to be specified using a FQDN rather than an IP address: : is taken from RFC 4566 [10]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses and FQDNs. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS using an A or AAAA record, and the resulting IP address is used for the remainder of ICE processing. What is the motivation for allowing this? I am concerned that this makes an implementation more complex, and I would like to know why we think this is important. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 13:04:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2iy-0001kx-Jl; Thu, 12 Apr 2007 13:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2ix-0001jt-Hh for mmusic@ietf.org; Thu, 12 Apr 2007 13:04:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc2iv-0005eA-Ur for mmusic@ietf.org; Thu, 12 Apr 2007 13:04:43 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2007 10:04:41 -0700 X-IronPort-AV: i="4.14,403,1170662400"; d="scan'208"; a="410825035:sNHT55716272" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3CH4fUl009759; Thu, 12 Apr 2007 10:04:41 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3CH4RA8004280; Thu, 12 Apr 2007 17:04:32 GMT From: "Dan Wing" To: "'Guylain Lavoie'" , "'Benny Prijono'" Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive nomination? Date: Thu, 12 Apr 2007 10:04:27 -0700 Message-ID: <00cc01c77d24$a8f2d650$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D89A@m5tmail1.m5t.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd7lW2cG2DcHn7ERS6Lxsw+amCCswAAEBtAAANRG4AAW+0zsAAEUzZA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5330; t=1176397481; x=1177261481; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=20waiti ngforan=09aggressive=09nomination? |Sender:=20; bh=+OYwcnr2Q8x4YraaXUTNtF9hU0PYvxM24CSAPDvUQ90=; b=cbePti31fqXQAoT/5LPDBpdkRVFz5wNzv/cfN2MOdA2gFsTFDCM6UV0JPBmJW2ssslw2Fs34 +eqz1b2Ql/laPOYMbTvpy7Rslq5loMsKohqiZcr9aQC+pR0x6T9krDXh; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org You can ignore them -- it just means you'll hit the timeouts. It can't be a MUST requirement in -16, and I recall Jonathan said it would be a MAY? -d > -----Original Message----- > From: Guylain Lavoie [mailto:glavoie@m5t.com] > Sent: Thursday, April 12, 2007 8:11 AM > To: Dan Wing; Benny Prijono > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan > aggressive nomination? > > Hi Dan, > > Although ICMP may be lost in transit for multiple reasons like the one > you stated I would really like to know, from an ICE implementer > perspective, what exactly are we required to implement. Must an > implementation be able to receive these ICMP errors and correctly > associate them, without ambiguity, to the correct STUN usage which > triggered them in the first place? Or, is an implementation allowed to > ignore them with the consequence of having to wait until the full > timeout. Having the correctly manage ICMP adds a lot of complexity to > the implementation. Do we have to resort to this added complexity (lot > of connected UDP sockets) or can we just ignore ICMP and use > only a non > connected UDP socket for all operations. > > Benny has indicated that he would ignore ICMP reception. Should we all > do that? > > Thanks, > Guylain > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: April 10, 2007 3:43 PM > To: Guylain Lavoie; 'Benny Prijono' > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive > nomination? > > > > > -----Original Message----- > > From: Guylain Lavoie [mailto:glavoie@m5t.com] > > Sent: Tuesday, April 10, 2007 11:31 AM > > To: Benny Prijono > > Cc: mmusic@ietf.org > > Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan > aggressive > > > nomination? > > > > Hi Benny, > > > > Optional support of ICMP reception is perfectly fine for me > because it > > > is much more easier to implement. > > > > However, if it is mandated, > > ICMP can't be mandated by ICE. ICMP is often filtered due to > incompetence, overzealous administrators, or insufficient > configuration > granularity in firewalls and NATs. > > -d > > > > we would basically need to allocate one socket for each > candidate pair > > > plus one for each server reflexive candidate and relayed candidate. > > That's a lot of sockets, but that way you can do a connect > on all of > > them. This solution would work fine on some operating > systems, but on > > others, it would not because the socket option SO_REUSEPORT is not > > available and it is needed so that all socket may be bound > to the same > > > address and port. From what I read, this is not available on Linux. > > This might be true for other operating systems as well. You > would also > > > need an non connected socket to be able to support reception of > > connectivity checks before the SDP answer arrives. This > would also be > > required to receive a connectivity check from a peer reflexive > > candidate (which is unknown and thus cannot be connected to). > > > > NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are > needed for > > an implementation of TCP with ICE because all TCP sockets are > > inherently connected and must be bound to the same address and port. > > Like with UDP, > > this would probably no work on all operating systems. This is > > mentioned in some NAT hole punching technique papers. > > > > Thanks > > Guylain > > > > -----Original Message----- > > From: Benny Prijono [mailto:bennylp@pjsip.org] > > Sent: April 10, 2007 1:25 PM > > To: Guylain Lavoie > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran > > aggressive nomination? > > > > Hi Guylain, > > > > Guylain Lavoie wrote: > > > Hi Benny, > > > > > > I am wondering how you plan on demultiplexing ICMP errors > > if a single > > > socket is shared for all candidate of a component? > > > How will you associate a received ICMP errors with a specific > > > Connectivity Checks or even a Binding Discovery Request > > used to keep > > > server reflexive candidate alive (keepalive)? Normally, at > > least, on > > > BSD like stack, you must connect the UDP socket to be able > > to reliably > > > > > receive ICMP errors. > > > > Even if you use one socket for each candidate, I'm not sure > if you can > > > do UDP connect() on each of them, as ICE requires you to send > > connectivity checks to multiple destinations. > > > > > Not connecting the socket would not allow you to fully > > comply with the > > > > > specification (your implementation would end up waiting for > > the full > > > timeout when such thing happens). > > > > I view ICMP handling as "if you can and want to handle it, > then do it, > > > if not, then you know the risk" kind of thing, so I would disagree > > that we should call these implementations not fully comply just > > because they don't/can't handle ICMP. > > > > cheers, > > -benny > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 12 17:50:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7BY-0007a2-Ds; Thu, 12 Apr 2007 17:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc7BX-0007Yc-2d for mmusic@ietf.org; Thu, 12 Apr 2007 17:50:31 -0400 Received: from hu-out-0506.google.com ([72.14.214.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc7BV-0007DP-ON for mmusic@ietf.org; Thu, 12 Apr 2007 17:50:31 -0400 Received: by hu-out-0506.google.com with SMTP id 38so600827huc for ; Thu, 12 Apr 2007 14:50:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=eZbRlbsx7XNc6ecXxCMAIh07jd0jFWASOe5wBcNEsLBAkxzNpavS+hQ5zk3rjrFnHHvbcnulxm+D30DBMUNEK2ayY8AjGP9uONpnhZLJFBuMhQlqOpj2OuLGUw/bcMLnwQghnnID/+fRujVPu6Yyo3K7CV87PAXofj+hnPOuy0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=IdccMByVxy7fAWnd7tURYDru98awDWCrFCh0ZiNwhIUeJNFA9iqLMQNbURuQQ15qe3iTLKDB0ZsZ+r7f0V3m2JEKyX/gssyfu3fV2gGyMYBnZF0PL4EEj5rSvu2wlDN4VH0VxZxac54oH3Qsu/y6Nyvnoyg9neF7r39uf9T4bmc= Received: by 10.78.123.4 with SMTP id v4mr528268huc.1176414628811; Thu, 12 Apr 2007 14:50:28 -0700 (PDT) Received: by 10.78.43.3 with HTTP; Thu, 12 Apr 2007 14:50:28 -0700 (PDT) Message-ID: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com> Date: Thu, 12 Apr 2007 14:50:28 -0700 From: "Greg Shepherd" To: fecframe@ietf.org, rmt@ietf.org, mmusic@ietf.org, avt@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [MMUSIC] Request For FEC Schemes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1067113871==" Errors-To: mmusic-bounces@ietf.org --===============1067113871== Content-Type: multipart/alternative; boundary="----=_Part_30859_12924349.1176414628761" ------=_Part_30859_12924349.1176414628761 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Greetings, >From the 68th IETF meeting in Prague, the FECFrame working group came away with some action items which we need to get to in order stay on track with our milestones: 1) Streaming Content Delivery Protocol Define specific protocol elements for signalling the use of FEC SDP, in particular, requires coordination with mmusic, avt and rmt - thus the current distribution. Call for volunteers to participate as the part of a Design Team. 2) Call for FEC Schemes: Like the RMT FEC Building Block, we should define the requirements that FECFRAME FEC Schemes should meet; Data elements that must be defined Procedures that must be defined Format for FEC Scheme specifications If you're interested enough to be on this list, and/or interested enough to attend the WG meetings, then you must be interested enough to see this through to functional result - please step-up. Thanks, Greg ------=_Part_30859_12924349.1176414628761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Greetings,

From the 68th IETF meeting in Prague, the FECFrame working group came away with some action items which we need to get to in order stay on track with our milestones:

1) Streaming Content Delivery Protocol
       Define specific protocol elements for signalling the use of FEC
       SDP, in particular, requires coordination with mmusic, avt and rmt - thus the current distribution.
       Call for volunteers to participate as the part of a Design Team.


2) Call for FEC Schemes:

     Like the RMT FEC Building Block, we should define the requirements that FECFRAME FEC Schemes should meet;
          Data elements that must be defined
          Procedures that must be defined
          Format for FEC Scheme specifications

If you're interested enough to be on this list, and/or interested enough to attend the WG meetings, then you must be interested enough to see this through to functional result - please step-up.

Thanks,
Greg

------=_Part_30859_12924349.1176414628761-- --===============1067113871== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1067113871==-- From mmusic-bounces@ietf.org Thu Apr 12 22:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBxY-0004Lc-W7; Thu, 12 Apr 2007 22:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBxX-0004LX-N1 for mmusic@ietf.org; Thu, 12 Apr 2007 22:56:23 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBxW-0004Iu-7j for mmusic@ietf.org; Thu, 12 Apr 2007 22:56:23 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3D2uL9c019372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 19:56:21 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3D2uJBX006713 for ; Thu, 12 Apr 2007 19:56:20 -0700 Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 19:56:19 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Apr 2007 19:56:23 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signaling End of media Stream in RTSP Thread-Index: Acd9d1JG8k/L8DrbRtGPmlpusxCR/Q== From: "Desineni, Harikishan" To: X-OriginalArrivalTime: 13 Apr 2007 02:56:19.0952 (UTC) FILETIME=[4FF70F00:01C77D77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [MMUSIC] Signaling End of media Stream in RTSP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1393153625==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1393153625== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D77.4FE8902D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D77.4FE8902D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I heard that this topic was discussed long time ago.=20 =20 I strongly felt the need for such a feature when doing VOD streaming of clips with unequal track durations. I am curious to know if the END_OF_STREAM has been proposed on the control path (RTSP). Another choice is RTCP BYE in the media path may not work if RTCP BYE is dropped over unreliable UDP.=20 =20 Using END_OF_STREAM (in S->C direction), it is also important to know the to detect how much track duration is left for a given media stream. This would avoid depending on the wrong range header information in the SDP (many servers screw up range header values in SDP). =20 Would like to know if there was any standards work performed since the time this discussion started in the past and what was the outcome? =20 ------_=_NextPart_001_01C77D77.4FE8902D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
I heard that this topic was discussed long =
time ago. 
 
I =
strongly felt the need for such a feature when doing VOD streaming of =
clips with unequal track durations. I am curious to know if the =
END_OF_STREAM<Track id, Seq No, TS> has been proposed on the =
control path (RTSP). Another choice is RTCP BYE in the media path may =
not work if RTCP BYE is dropped over unreliable UDP. =

 
Using =
END_OF_STREAM (in S->C direction), it is also important to know the =
<last Seq no, Timestamp> to detect how much track duration is left =
for a given media stream. This would avoid depending on the wrong range =
header information in the SDP (many servers screw up range header values =
in SDP).
 
Would =
like to know if there was any standards work performed since the time =
this discussion started in the past and what was the =
outcome?

 

------_=_NextPart_001_01C77D77.4FE8902D-- --===============1393153625== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1393153625==-- From mmusic-bounces@ietf.org Fri Apr 13 03:03:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcFoc-0006Wq-VJ; Fri, 13 Apr 2007 03:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcFob-0006WY-Kf for mmusic@ietf.org; Fri, 13 Apr 2007 03:03:25 -0400 Received: from lon-del-01.spheriq.net ([195.46.50.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcFob-0003ZP-5q for mmusic@ietf.org; Fri, 13 Apr 2007 03:03:25 -0400 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-01.spheriq.net with ESMTP id l3D73KFI008271 for ; Fri, 13 Apr 2007 07:03:20 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-03.spheriq.net with ESMTP id l3D73IAN020051 for ; Fri, 13 Apr 2007 07:03:19 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id l3D73Fm5004338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 13 Apr 2007 07:03:16 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 750BADB19; Fri, 13 Apr 2007 07:03:14 +0000 (GMT) Received: from mail4.agr.st.com (mail4.agr.st.com [164.130.4.70]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BAAC14726D; Fri, 13 Apr 2007 07:03:13 +0000 (GMT) Received: from [10.50.13.10] (agr2261.agr.st.com [10.50.13.10]) by mail4.agr.st.com (MOS 3.7.5a-GA) with ESMTP id BEG96178 (AUTH "andrea vitali"); Fri, 13 Apr 2007 09:03:12 +0200 (CEST) Message-ID: <461F2B30.80905@st.com> Date: Fri, 13 Apr 2007 09:03:12 +0200 From: Andrea Lorenzo VITALI User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Greg Shepherd References: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com> In-Reply-To: <38c19b540704121450k611cfa11ic3ff20deee967849@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.2.04 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: avt@ietf.org, mmusic@ietf.org, fecframe@ietf.org, rmt@ietf.org Subject: [MMUSIC] Re: [AVT] Request For FEC Schemes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I am interested. Please let me know the next step. Andrea Vitali (STMicroelectronics) > 1) Streaming Content Delivery Protocol > Define specific protocol elements for signalling the use of FEC > SDP, in particular, requires coordination with mmusic, avt and > rmt - thus the current distribution. > Call for volunteers to participate as the part of a Design Team. > > > 2) Call for FEC Schemes: > > Like the RMT FEC Building Block, we should define the requirements > that FECFRAME FEC Schemes should meet; > Data elements that must be defined > Procedures that must be defined > Format for FEC Scheme specifications > > If you're interested enough to be on this list, and/or interested enough > to attend the WG meetings, then you must be interested enough to see > this through to functional result - please step-up. > > Thanks, > Greg > > > ------------------------------------------------------------------------ > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- ______________________________________________________________ Andrea VITALI andrea.vitali@st.com tel (+39) 039 603 7244 mobile (+39) 347 93 08 433 fax (+39) 039 603 6129 STMicroelectronics Centro Direzionale COLLEONI - Palazzo "DIALETTICA" 20041 Agrate Brianza (MI) ITALY ______________________________________________________________ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 13 05:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHim-0005Zq-Ms; Fri, 13 Apr 2007 05:05:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHil-0005Yw-CY for mmusic@ietf.org; Fri, 13 Apr 2007 05:05:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcHih-0006mn-Mu for mmusic@ietf.org; Fri, 13 Apr 2007 05:05:30 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D3E1220930; Fri, 13 Apr 2007 11:05:26 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-a5-461f47d61678 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDDF020994; Fri, 13 Apr 2007 11:05:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:05:26 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:05:26 +0200 Message-ID: <461F47D6.3040203@ericsson.com> Date: Fri, 13 Apr 2007 11:05:26 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Desineni, Harikishan" Subject: Re: [MMUSIC] Signaling End of media Stream in RTSP References: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 09:05:26.0359 (UTC) FILETIME=[E0409670:01C77DAA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org There is the now expired WG draft on this: http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-announce-01 /Magnus Desineni, Harikishan skrev: > > > I heard that this topic was discussed long time ago. > > > > I strongly felt the need for such a feature when doing VOD streaming of clips with unequal track durations. I am curious to know if the END_OF_STREAM has been proposed on the control path (RTSP). Another choice is RTCP BYE in the media path may not work if RTCP BYE is dropped over unreliable UDP. > > > > Using END_OF_STREAM (in S->C direction), it is also important to know the to detect how much track duration is left for a given media stream. This would avoid depending on the wrong range header information in the SDP (many servers screw up range header values in SDP). > > > > Would like to know if there was any standards work performed since the time this discussion started in the past and what was the outcome? > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 13 05:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHpI-0002PR-Pt; Fri, 13 Apr 2007 05:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHpH-0002JV-K7 for mmusic@ietf.org; Fri, 13 Apr 2007 05:12:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcHpF-00017n-UW for mmusic@ietf.org; Fri, 13 Apr 2007 05:12:15 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6857521603; Fri, 13 Apr 2007 11:12:13 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-70-461f496dc7d5 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5AADA21600; Fri, 13 Apr 2007 11:12:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:12:13 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 11:12:12 +0200 Message-ID: <461F496C.3020903@ericsson.com> Date: Fri, 13 Apr 2007 11:12:12 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Desineni, Harikishan" Subject: Re: [MMUSIC] Signaling End of media Stream in RTSP References: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 09:12:12.0479 (UTC) FILETIME=[D25194F0:01C77DAB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org (As individual contributor) I forgot to comment a thing about the email. Desineni, Harikishan skrev: > > > I heard that this topic was discussed long time ago. > I strongly felt the need for such a feature when doing > VOD streaming of clips with unequal track durations. I am > curious to know if the END_OF_STREAM > has been proposed on the control path (RTSP). Another > choice is RTCP BYE in the media path may not work if > RTCP BYE is dropped over unreliable UDP. RTCP BYE is definitely the wrong tool for this. The semantics for RTCP BYE means that a receiver should mark the SSRC as leaving the session. This would mean that if the client request another play on the same stream the server should use a new SSRC. Thus resulting in the loss of all synchronization information between streams. Needing to re-establish this. If the server doesn't chose a new SSRC (more likely) then a client can interpret this as being late packet for a source having left. It may also screw around with the SSRC collision rules. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 13 08:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKfP-0005QB-QH; Fri, 13 Apr 2007 08:14:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKfP-0005Q6-A6 for mmusic@ietf.org; Fri, 13 Apr 2007 08:14:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKfN-0001Tj-8n for mmusic@ietf.org; Fri, 13 Apr 2007 08:14:15 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9FA0221658; Fri, 13 Apr 2007 14:14:12 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-5c-461f74141623 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7F03021625; Fri, 13 Apr 2007 14:14:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:14:12 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:14:11 +0200 Message-ID: <461F7413.5020805@ericsson.com> Date: Fri, 13 Apr 2007 14:14:11 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 12:14:11.0812 (UTC) FILETIME=[3EBF9240:01C77DC5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: mmusic@ietf.org, Lars Eggert X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I have reviewed the draft and have some comments. I will start with all the real issues. Then I a also have some nits. But let me say that I am impressed how good this document has become. Issues: I1. Section 7.2.1.1: Why isn't this section applicable for lite implementation. If there exist possibilities that the two peer in case of full implementations are confused about their roles, why can't a full peer be similar confused and think it is talking to a controlling full when it in reality talks to a lite. I have a hard time determining if that can happen at all or not when you think two full peers can be confused about their roles. It seems a simple fix to tell a lite server to always do tiebreaking as the loosing side. I2. Section 7.2.1.1, first bullet: "o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the request, there is no conflict." When does this happen? To my understanding all ICE peers sending connectivity checks will indicate if they are controlling or controlled. I3. Section 7.2.1.4: * If the state of that pair is Waiting or Frozen, its state is changed to In-Progress and a check for that pair is performed immediately. This is called a triggered check. I am a bit concerned with the immediately part here. I do understand that the check should happen as soon as possible. However by stepping away from the pacing in these replies you further increases the burstiness of the connectivity checks. To be slightly more conservative. Why not simply bump the triggered checks to the top of the queue. The alternative I see if you like to keep the quick response (and potential bunching together of response and the triggered check request) is to delay the next scheduled check an extra Ta interval. That way the triggered check does not increase the consumed bit-rate. I4. Section 10. "Examples of formats which readily meet this goal are RTP No-Op [31] and RTP comfort noise [25]." I would argue that RTP comfort noise does not readily meet it. It works in some cases, like for an audio stream where the peers both support it. Two solutions, a) remove comfort noise as an example. b) clarify the main limitations. I5. Section 15.1: There are a number of cases where one uses 1* in the ABNF. Can these please be changed to a upper limit on the number of characters. With the current definition I could use a 5000 digit long priority number from parsing perspective. This is likely to lead to overflow. In the case of priority as this is limited to 2^32-1 as largest number then using 1*10DIGIT seems to be without risk. I guess that also component-ID and foundation can be limited to a reasonable upper limit. Making it easier to separate the cases of potentially valid numbers and plain errors. This comment also applies to section 15.4 and the password and ufrag definitions. I6. Pacing of connectivity checks. I need to think a bit more about this and how ICE relates to the UDP usage guidelines (http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-guidelines-02.txt) we are working on getting accepted in the transport area. Ice with the current parameters are rather aggressive in its bandwidth usage in worst case. I understand in most cases it would not consume close to as much. The biggest problem with this bloody protocol is its purpose resulting in that basically all STUN request packets could be dropped by NAT filtering rather than congestion. Or it could be the other way around. We have no way of knowing. This also causes the connectivity checks themselves some problem. As all checks easily can congest themselves thus causing worse performance then the correct rate limited sending would have. I think we need to at least consider putting some further limitation or adaptation of the pacing timers in some cases. At least when you have knowledge about link speeds. I know we have had quite some discussion on this topic earlier and the algorithm has clearly been made to try as few checks as possible thanks to the freezing of some checklist etc. But in my current role I need to take this even more serious than before. NITS: N1. Section 2.6, third paragraph: Last sentence starts with what appears with an stray "A". N2. Figure 4 and 5. Lack of directional arrows for the requests from L. N3. section 5.7.1, page 30, first paragraph: "As another example, the offerer can multiplex RTP and RTCP on the same port and signals it can do that in the SDP through some new attribute." I think an informative reference to the RTP and RTCP MUXing draft (draft-ietf-avt-rtp-and-rtcp-mux-04) is needed in this sentence to make it clear what is being talked about. N4. Section 5.7.2, second paragraph: "Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is greater than A-P, and 0 otherwise." As the (O-P) part isn't used in the above formula, maybe using the actual (O>A?1:0) is better in this context. N5. Section 7.1: Isn't "STUN Client Procedures" a better section title than "Client Procedures"? Similar for 7.2. N6. Section 8.1.1: "This check will succeed (since the previous did), causing the nominated flag of that and only that pair to be set." I think this sentence is more correct if you change "will" to "should" or "is expected to". There are no guarantees that something else causes a failure of the path. N7. Section 12.1.1: "With this optimization, provisional responses containing an SDP answer that begins ICE processing for one or more media streams can be sent reliably without RFC 3264." Isn't the reference to RFC 3264 wrong? Shouldn't it be to RFC 3262? N8. Section 16. The line breaks in the SDP example are bad and looks strange. N9. The following references needs update: == Outdated reference: A later version (-03) exists of draft-ietf-behave-turn-02 == Outdated reference: A later version (-01) exists of draft-ietf-sip-ice-option-tag-00 == Outdated reference: A later version (-01) exists of draft-ietf-avt-rtp-no-op-00 == Outdated reference: A later version (-08) exists of draft-ietf-sip-outbound-07 N10. Section B.2 Use of 192.168.1.1 and 10.0.1.1 as end-host addresses. As these addresses usually will be assigned the gateway/NAT in respective network isn't using them for end-host a bad choice. N11. Section B.8: "That section requires that the type preference for peer reflexive candidates always be lower than server reflexive. " I think "lower" is supposed to be "higher". Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 13 19:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcV8g-0001Z7-JB; Fri, 13 Apr 2007 19:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcV8f-0001Yy-A7 for mmusic@ietf.org; Fri, 13 Apr 2007 19:25:09 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcV8d-0001gE-UT for mmusic@ietf.org; Fri, 13 Apr 2007 19:25:09 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3DNP2gs026314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Apr 2007 16:25:04 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3DNP2Tv008712; Fri, 13 Apr 2007 16:25:02 -0700 Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:25:02 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Signaling End of media Stream in RTSP Date: Fri, 13 Apr 2007 16:25:06 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1F7C@NAEX01.na.qualcomm.com> In-Reply-To: <461F496C.3020903@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Signaling End of media Stream in RTSP Thread-Index: Acd9q9nnUn8ztVGHR+OuKleq2tINXQAdlx2w References: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> <461F496C.3020903@ericsson.com> From: "Desineni, Harikishan" To: "Magnus Westerlund" X-OriginalArrivalTime: 13 Apr 2007 23:25:02.0133 (UTC) FILETIME=[F5CF2650:01C77E22] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Magnus, I agree that RTCP BYE is not the correct tool to solve this problem. The solution proposed in the draft appears to be in correct direction. Any reason why the draft did not progress? Was it purely due to author's lack of interest to move it forward or any other technical reasons?=20 Does RTSP 2.0 provide any support to solve this problem? Thanks, Hari > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, April 13, 2007 2:12 AM > To: Desineni, Harikishan > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Signaling End of media Stream in RTSP >=20 > (As individual contributor) >=20 > I forgot to comment a thing about the email. >=20 > Desineni, Harikishan skrev: > > > > > > I heard that this topic was discussed long time ago. > > I strongly felt the need for such a feature when doing > > VOD streaming of clips with unequal track durations. I am > > curious to know if the END_OF_STREAM > > has been proposed on the control path (RTSP). Another > > choice is RTCP BYE in the media path may not work if > > RTCP BYE is dropped over unreliable UDP. >=20 > RTCP BYE is definitely the wrong tool for this. The semantics for RTCP > BYE means that a receiver should mark the SSRC as leaving the session. > This would mean that if the client request another play on the same > stream the server should use a new SSRC. Thus resulting in the loss of > all synchronization information between streams. Needing to re-establish > this. If the server doesn't chose a new SSRC (more likely) then a client > can interpret this as being late packet for a source having left. It may > also screw around with the SSRC collision rules. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 13 19:29:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVCt-0004S6-C4; Fri, 13 Apr 2007 19:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVCs-0004S1-L1 for mmusic@ietf.org; Fri, 13 Apr 2007 19:29:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVCr-0002xw-BE for mmusic@ietf.org; Fri, 13 Apr 2007 19:29:30 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 13 Apr 2007 16:29:28 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="53572512:sNHT45180639" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3DNTSxQ029536; Fri, 13 Apr 2007 16:29:28 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3DNTRA8027068; Fri, 13 Apr 2007 23:29:28 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , "'Jonathan Rosenberg'" Date: Fri, 13 Apr 2007 16:29:27 -0700 Message-ID: <034201c77e23$948f6890$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <461F7413.5020805@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9xUtgTxsb6HEiTQezkD86HKei7gAXVwAA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1240; t=1176506968; x=1177370968; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20non-STUN=20keepalive=20discussion=20in=20ICE=20(was=20WGLC=3A =20draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=ZeFH3ijD1SPRHKtbZGSCwDjGmV0piAklCRtFWrVo57o=; b=srqIu+iv3777teU8bjWLoAHjxAIzZZGJaE0c8oSEom2QGyW6XmBM4RkE5XCSaBhrVZD3ROEW f+kZndNotLZVmMXf2nJ9lGRoAN54vD8iz8Xubv9uZwF4D41jQQekIfKZ; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mmusic@ietf.org, 'Lars Eggert' Subject: [MMUSIC] non-STUN keepalive discussion in ICE (was WGLC: draft-ietf-mmusic-ice-15.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, April 13, 2007 5:14 AM > To: Jonathan Rosenberg > Cc: mmusic@ietf.org; Lars Eggert > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt ... > I4. Section 10. > "Examples of formats which readily meet this > goal are RTP No-Op [31] and RTP comfort noise [25]." > > I would argue that RTP comfort noise does not readily meet > it. It works in some cases, like for an audio stream where > the peers both support it. Two solutions, a) remove comfort > noise as an example. b) clarify the main limitations. Describing other, non-STUN techniques for performing keepalives seems out of scope for ICE. It is interesting information. There is another technique, too (RTP/RTCP muxing), which Colin pointed out: http://www1.ietf.org/mail-archive/web/avt/current/msg08248.html I suggested in a followup to Colin's post that perhaps draft-marjou-behave-app-rtp-keepalive-01.txt should become an AVT working group document. This might well be the best way to discuss all of the various keepalive techniques in one place and compare/contrast the benefits and drawbacks of each technique. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 13 19:41:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVOc-0003lP-FY; Fri, 13 Apr 2007 19:41:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVOb-0003ja-5V for mmusic@ietf.org; Fri, 13 Apr 2007 19:41:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVOZ-0006wj-Qz for mmusic@ietf.org; Fri, 13 Apr 2007 19:41:37 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 13 Apr 2007 16:41:35 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="53572940:sNHT46697112" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3DNfZk0023347; Fri, 13 Apr 2007 16:41:35 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3DNfYwn027371; Fri, 13 Apr 2007 23:41:34 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , "'Jonathan Rosenberg'" Subject: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Fri, 13 Apr 2007 16:41:34 -0700 Message-ID: <034301c77e25$45a4dab0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <461F7413.5020805@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9xUtgTxsb6HEiTQezkD86HKei7gAXk3uQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2094; t=1176507695; x=1177371695; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20ICE=20pacing=20connectivity=20checks=20(was=20RE=3A=20[MMUSIC ]=20WGLC=3A=20draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=B564kueTN5XJeNLNi0fHNhHo+BjOHjum70QFr2yS0C4=; b=LD/K06qYO0tHaMKCf1Lu2CsRwpYRxkd/Q3jWppDOpDjwnn9V5TRMXxzK5RCn8iggNSLVJme0 cbJ66DiGQCsaTLhakveEoe7NG95Fp+XVsk+FYVeoY7qzWTSX62e6S561; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mmusic@ietf.org, 'Lars Eggert' X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, April 13, 2007 5:14 AM > To: Jonathan Rosenberg > Cc: mmusic@ietf.org; Lars Eggert > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt ... > I6. Pacing of connectivity checks. I need to think a bit more about > this and how ICE relates to the UDP usage guidelines > (http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-gu > idelines-02.txt) we are working on getting accepted in the > transport area. Ice with the current parameters are rather > aggressive in its bandwidth usage in worst case. I understand > in most cases it would not consume close to as much. > > The biggest problem with this bloody protocol is its purpose > resulting in that basically all STUN request packets could be > dropped by NAT filtering rather than congestion. Or it could be the > other way around. We have no way of knowing. This also causes the > connectivity checks themselves some problem. As all checks easily > can congest themselves thus causing worse performance then the > correct rate limited sending would have. I think we need to at > least consider putting some further limitation or adaptation of the > pacing timers in some cases. At least when you have knowledge about > link speeds. > > I know we have had quite some discussion on this topic earlier and > the algorithm has clearly been made to try as few checks as possible > thanks to the freezing of some checklist etc. But in my current role > I need to take this even more serious than before. Right now, the "Ta" timer in ICE is suggested to be 20ms. Would it be reasonable to make "Ta" be the greater of 20ms or the "ptime" for the associated media line? That is, if the ptime is 50ms, then ICE's "Ta" would also be 50ms. In this way, ICE is no worse than the RTP flow itself. Using the link speed, if you know it, could be helpful, too, but you seldom know it. For example I have a DSL uplink at home but my local network is all 100mb Ethernet. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 04:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMMP-0005fx-7v; Mon, 16 Apr 2007 04:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMMO-0005fY-7f for mmusic@ietf.org; Mon, 16 Apr 2007 04:14:52 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdMMM-0000Cn-I5 for mmusic@ietf.org; Mon, 16 Apr 2007 04:14:52 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB9722119E; Mon, 16 Apr 2007 10:14:49 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-e3-46233079cb11 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC9F6200CB; Mon, 16 Apr 2007 10:14:49 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:14:49 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:14:49 +0200 Message-ID: <46233079.30105@ericsson.com> Date: Mon, 16 Apr 2007 10:14:49 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Desineni, Harikishan" Subject: Re: [MMUSIC] Signaling End of media Stream in RTSP References: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1E73@NAEX01.na.qualcomm.com> <461F496C.3020903@ericsson.com> <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1F7C@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD1F7C@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 08:14:49.0540 (UTC) FILETIME=[4D680840:01C77FFF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Desineni, Harikishan skrev: > > > Magnus, > > I agree that RTCP BYE is not the correct tool to solve this problem. The > solution proposed in the draft appears to be in correct direction. Any > reason why the draft did not progress? Was it purely due to author's > lack of interest to move it forward or any other technical reasons? > To my knowledge this is part of the lack of interest in RTSP standardization work. Which I think come around for two reasons. 1) our failure to conclude RTSP 2.0 and 2) the fact that a number of active people changed positions and moved into other work areas. > Does RTSP 2.0 provide any support to solve this problem? No, I at least was expecting that the WG draft would provide that solution for RTSP 2.0. All MMUSIC WG's RTSP extensions has been based on RTSP 2.0 due to the problem of not having a spec that one could really trust for RTSP 1.0. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 04:21:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMTA-0000d9-IV; Mon, 16 Apr 2007 04:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMT9-0000ZG-3p for mmusic@ietf.org; Mon, 16 Apr 2007 04:21:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdMT7-0002Ny-V6 for mmusic@ietf.org; Mon, 16 Apr 2007 04:21:50 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6FAC021288; Mon, 16 Apr 2007 10:21:49 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-d2-4623321d5844 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 52C11203F7; Mon, 16 Apr 2007 10:21:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:21:48 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:21:48 +0200 Message-ID: <4623321C.1090008@ericsson.com> Date: Mon, 16 Apr 2007 10:21:48 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <034301c77e25$45a4dab0$c4f0200a@amer.cisco.com> In-Reply-To: <034301c77e25$45a4dab0$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 08:21:48.0298 (UTC) FILETIME=[47016EA0:01C78000] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Lars Eggert , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan Wing skrev: > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Friday, April 13, 2007 5:14 AM > > To: Jonathan Rosenberg > > Cc: mmusic@ietf.org; Lars Eggert > > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > ... > > I6. Pacing of connectivity checks. I need to think a bit more about > > this and how ICE relates to the UDP usage guidelines > > (http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-gu > > idelines-02.txt) we are working on getting accepted in the > > transport area. Ice with the current parameters are rather > > aggressive in its bandwidth usage in worst case. I understand > > in most cases it would not consume close to as much. > > > > The biggest problem with this bloody protocol is its purpose > > resulting in that basically all STUN request packets could be > > dropped by NAT filtering rather than congestion. Or it could be the > > other way around. We have no way of knowing. This also causes the > > connectivity checks themselves some problem. As all checks easily > > can congest themselves thus causing worse performance then the > > correct rate limited sending would have. I think we need to at > > least consider putting some further limitation or adaptation of the > > pacing timers in some cases. At least when you have knowledge about > > link speeds. > > > > I know we have had quite some discussion on this topic earlier and > > the algorithm has clearly been made to try as few checks as possible > > thanks to the freezing of some checklist etc. But in my current role > > I need to take this even more serious than before. > > Right now, the "Ta" timer in ICE is suggested to be 20ms. Would it > be reasonable to make "Ta" be the greater of 20ms or the "ptime" for > the associated media line? That is, if the ptime is 50ms, then > ICE's "Ta" would also be 50ms. In this way, ICE is no worse than > the RTP flow itself. Actually ICE is much worse. Because you have no way of determining if the lost connectivity checks are being filtered by a NAT or are congestion losses. When running RTP you know that losses are most likely to be congestion losses. And you have RTCP to tell you as a sender that something is happening. At least on a medium time scale. That way an RTP + RTCP implementation can at least avoid persistent congestion. Maybe what I am looking for is better guidance on how to tune the parameters when you know something. And in addition maybe some more conservative default values. But what is needed is discussion on this. > > Using the link speed, if you know it, could be helpful, too, but > you seldom know it. For example I have a DSL uplink at home but > my local network is all 100mb Ethernet. > Yes, that is the big problem. -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 10:27:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSBP-0007YD-Q0; Mon, 16 Apr 2007 10:27:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSBO-0007XF-LN for mmusic@ietf.org; Mon, 16 Apr 2007 10:27:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSBL-0007Hq-17 for mmusic@ietf.org; Mon, 16 Apr 2007 10:27:54 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 41ED12043B for ; Mon, 16 Apr 2007 16:27:50 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-45-462387e63f1c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B6A7200C0 for ; Mon, 16 Apr 2007 16:27:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:27:49 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:27:49 +0200 Message-ID: <462387E3.20600@ericsson.com> Date: Mon, 16 Apr 2007 16:27:47 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 14:27:49.0041 (UTC) FILETIME=[68A0E210:01C78033] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [MMUSIC] RTSP: Speed header X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, I while back received an email with some questions on how the Speed header works in RTSP. There where also the issue how it interacts with the Scale header and with bandwidth adaptation and buffer management. Lets do a recap of what the different mechanisms do. Scale: Changes the rate at which media is presented to the user. So Scale=0.5 would mean slow motion, while Scale=5 would be fast forward in the stream. Speed: Changes the media delivery rate. Speed=2 would mean that for each second a client would receive media that takes it 2 seconds to play back to the user. It would also mean that using RTP with a 90kHz timestamp clock the RTP streams timestamp values would increase with 180k ticks per second. Bit-rate adaptation: A way of ensuring that the media traffic does not use more bandwidth then what is available. Which means that the server would need to change the media bit-rate sent if there isn't enough available for the current media stream. This could be done in a number of ways but most commonly are done by bit-stream switching. Going from a stored/delivered media stream in one quality to another lower quality that requires less bit-rate. Buffer Management: An attempt to keep the clients buffer in a healthy state, aiming at keeping a certain amount of media time present in buffer to safeguard against temporary or longer term changes of bit-rate capacity available to the streaming session. Thus giving the server time to react to the change before an buffer-underrun situation occurs. At the same time safe-guard against overflowing buffers. This is for example done in 3GPP Packet-based Streaming Service (26.234 Rel6) where additional feedback and configuration information is provided for the buffer status. Thus allowing a server to change media transmission rate on the fly. Which is equivalent to a client using Speed. However it also needs to be able to perform bit-rate adaptation so that one can lower the quality but increase the speed to refill the buffer. The interactions between the different behaviors are interesting but can become quite complex. For example the total bit-rate is speed x normal bit-rate. It might also be influenced by the Scale used as fast forwarding could be accomplished by simple turning up the frame-rate for video and rewriting the timestamps compared to scale 1. Slow motion could also mean that the bit-rate gets lower. However if trans-coding is done to handle Scale then bit-rate may not change at all. If there are a limited amount of bit-rate this means that bit-rate adaptation needs to step in and do what it can to keep bit-rate within limitations. If that can only operate on the media stream or can also contradict speed or influence how scale is handled is quite undefined. I do have a few question due to this: 1. Are people implementing Speed? 2. If you are using Speed, how are you doing that, as I have described or otherwise? 3. Should we remove speed from base specification? 4. If not, what do you think needs to be clarified and do you have text proposal? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 11:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTAs-0006x9-Id; Mon, 16 Apr 2007 11:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTAq-0006vl-OI for mmusic@ietf.org; Mon, 16 Apr 2007 11:31:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdT9H-0007Cv-1x for mmusic@ietf.org; Mon, 16 Apr 2007 11:29:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 77703211F2; Mon, 16 Apr 2007 17:29:46 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-bd-4623966ada73 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 60AF8211C4; Mon, 16 Apr 2007 17:29:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 17:29:46 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 17:29:45 +0200 Message-ID: <46239668.4030603@ericsson.com> Date: Mon, 16 Apr 2007 17:29:44 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Joe Pallas Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc2326bis-14.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 15:29:45.0939 (UTC) FILETIME=[10128230:01C7803C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Joe, Thanks for the comments. Sorry I haven't responded before. But now that we actually are going somewhere with RTSP it seemed a good time to actually respond. Joe Pallas skrev: > A few remarks on the changes in this draft: > > Section 2.2 doesn't have any major changes, but, to complement the > change to the description of "Live" in section 1.4, it may be useful to > add something about seekable live content, such as: > > In some cases, the server providing live content may be saving some > or all > of the material to allow clients to pause the stream and resume it > from the paused > point, or to "rewind" and play continuously from a point earlier > than the live point. > Hence, this use case does not necessarily exclude playing from other > than the > live point of the stream, playing with scales other than 1.0, etc. I agree that there are servers that has this functionality. However I think we may need to consider how we indicate the properties of streams. We maybe need at least three categories: On-demand, Live, Recorded-Live. > > Section 2.5 seems to mostly say that RTSP 2.0 is not likely to be useful > in this case without extensions. Perhaps it shouldn't say much more > than that. > I am not agreeing with that classification. There is primarily a warning about some serious security issues. However they do not apply in all deployements. > Section C.1.5 on SDP attributes sendrecv, recvonly, and sendonly is > confusing. In particular, the mention of '"PLAY" mode' is odd, since > RECORD mode is explicitly undefined, so PLAY mode is the only mode > defined. I think we need to consider how these rules apply for "PLAY" mode. However not being clear that we are talking about "PLAY" seems a bit strange. But I am on the other hand convinced that the text can be improved as this is the first shot at the text. > For that matter, why isn't "RECORD" removed from the grammar > for mode -- is there some value to making it reserved but undefined? This should be fixed. The "mode" parameter anyway need an extension so keeping something for the future when it can easily be re-instate when the rest of the definition exist seems fine. > Also, section 13.4.2 mentions the RECORD request, which no longer exists. Needs to be fixed. > > Section F introduces new language on the interpretation of CR and LF for > backward compatibility. The language in RFC2326 was a bad idea, since > it can be paraphrased as "Receivers should be prepared for senders to > violate this specification." While this is always true, putting it into > the specification itself is unwise, as it appears to give license to > violators. That said, the language that was added to section F uses the > word "should" in a dangerous way. The new instruction raises doubts > about the correct interpretation of sequences like CR LF LF, LF CR, and > CR CR LF. If there are, in fact, any RTSP 1.0 clients still extant that > take such liberties, maybe it would be best to pretend they don't exist. > I don't know how common it is these violations are. It might be easier to leave this alone by removing the paragraph. > Hope this is useful. Definitely Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 11:44:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTNJ-0003Sj-Pj; Mon, 16 Apr 2007 11:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTNI-0003Ql-K3 for mmusic@ietf.org; Mon, 16 Apr 2007 11:44:16 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTNH-0005aE-St for mmusic@ietf.org; Mon, 16 Apr 2007 11:44:16 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 27EFC20429; Mon, 16 Apr 2007 17:44:15 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-69-462399cf3ad4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 14C1420412; Mon, 16 Apr 2007 17:44:15 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 17:44:15 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 17:44:14 +0200 Message-ID: <462399CD.8000301@ericsson.com> Date: Mon, 16 Apr 2007 17:44:13 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Chris Steck Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment References: <001401c72f9e$cf783b90$8d81a8c0@m24947> In-Reply-To: <001401c72f9e$cf783b90$8d81a8c0@m24947> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 15:44:14.0876 (UTC) FILETIME=[15FFC5C0:01C7803E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "'mmusic \(E-mail\)'" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Chris Steck skrev: > Is there any reason MMUSIC can't define the pipelining mechanism so it can > be backported to work with RTSP 1.0 as well? > > We would like to leverage pipelining in 3GPP Rel 7 PSSe work, but are > reluctant to have a dependency on RTSP 2.0. It would be great if this > proposal could account for this backport so that there is no need to extract > pipelining from RTSP 2.0 to define a superset of 1.0 in SA4, where we > reference the pipelining section of 2.0, as we all know how those things > tend to fall out of sync easily. > Hi Chris, The reason we avoid doing anything with RTSP 1.0 is due to that the protocol and what points of extensibility that exist isn't well defined. If you actually look on what is used in RTSP 1.0 that is far from the required functionality from the specification. Secondly it only works because people have spent weeks in different interoperability events fixing their implementations to handle different variations to different servers or clients. Trying to do specification work from that has been impossible. That is why we quite sometime ago decided to go for a new version that we could specify such that we can build extension on it. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 11:55:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTXq-0007Mn-Mt; Mon, 16 Apr 2007 11:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTXp-0007Mg-Sv for mmusic@ietf.org; Mon, 16 Apr 2007 11:55:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTXp-0002c2-Ii for mmusic@ietf.org; Mon, 16 Apr 2007 11:55:09 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Apr 2007 08:55:09 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="136406980:sNHT47382318" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3GFt8Vr001063; Mon, 16 Apr 2007 08:55:08 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GFt8MF018556; Mon, 16 Apr 2007 15:55:08 GMT From: "Dan Wing" To: "'Magnus Westerlund'" Subject: RE: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Mon, 16 Apr 2007 08:55:08 -0700 Message-ID: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4623321C.1090008@ericsson.com> Thread-Index: AceAAEk2tvnRkt5tSR6JQdShmkoLLgAPV6hQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2984; t=1176738909; x=1177602909; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20ICE=20pacing=20connectivity=20checks=20(was=20RE=3A=2 0[MMUSIC]=20WGLC=3A=20draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=FZoPEUbU5equSuvHB8tQOyfNqrmOF7fXE0QIKNbSwD0=; b=a60ykYlTwO46HEiVVJo9sUH76DGMYhj29OqclSolPoDLiz98z+Bvln3TuiWkbSzYQNnGADgA Pp8N+r8gVpFRnGF3ykls0qEVGTvg3YUG9PfiJzOWbikj7TdKyZR5NrZ7; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'Lars Eggert' , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > > Right now, the "Ta" timer in ICE is suggested to be 20ms. Would it > > be reasonable to make "Ta" be the greater of 20ms or the "ptime" for > > the associated media line? That is, if the ptime is 50ms, then > > ICE's "Ta" would also be 50ms. In this way, ICE is no worse than > > the RTP flow itself. > > Actually ICE is much worse. Because you have no way of determining if > the lost connectivity checks are being filtered by a NAT or are > congestion losses. When running RTP you know that losses are > most likely to be congestion losses. I don't understand. With RTP, you're going to transmit a packet every 10ms (or 20ms) into the network, with no built-in backoff (no initial RTT estimate, and no requirement that RTCP indicates successful packet reception until the first RTCP receiver report is sent, which is approximately every 5 seconds). In the meantime, the sender is sending a packet every 10ms (or 20ms or so) into the network. ICE is going to transmit a packet every 20ms (per its current recommendation in ice-16), wait for a response, and has built-in exponential backoff for its retransmits. This is more gentle to the network than the RTP flow that needs to start soon. In fact, if the network is dropping so many packets that a connectivity check can't complete (even with its retransmits), the RTP flow won't be started; without ICE, the new RTP flow would start and further contribute to network congestion. > And you have RTCP to tell you as a sender that something is > happening. At least on a medium time scale. That > way an RTP + RTCP implementation can at least avoid > persistent congestion. As can ICE, with ICE's exponential backoff of the STUN transaction retransmission timers. > Maybe what I am looking for is better guidance on how to tune the > parameters when you know something. And in addition maybe some more > conservative default values. > > But what is needed is discussion on this. Ok. What is the best venue for such discussion? Would the TSVWG or perhaps the e2e-interest mailing list be better? I expect MMUSIC isn't usually read by folks interested in network congestion. -d > > Using the link speed, if you know it, could be helpful, too, but > > you seldom know it. For example I have a DSL uplink at home but > > my local network is all 100mb Ethernet. > > > > Yes, that is the big problem. > > > -- > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > -------------------------------------------------------------- > -------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 11:55:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTYY-0007Xl-Nm; Mon, 16 Apr 2007 11:55:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTYX-0007Xe-Ol for mmusic@ietf.org; Mon, 16 Apr 2007 11:55:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTYV-0002w7-1u for mmusic@ietf.org; Mon, 16 Apr 2007 11:55:53 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8F4FB2066E; Mon, 16 Apr 2007 17:55:50 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-e0-46239c8665b7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6AA3920475; Mon, 16 Apr 2007 17:55:50 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 17:55:50 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 17:55:49 +0200 Message-ID: <46239C84.7050600@ericsson.com> Date: Mon, 16 Apr 2007 17:55:48 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jamie Gordon Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment References: <458ABFA6.8030107@ericsson.com> <459C4999.5050106@real.com> In-Reply-To: <459C4999.5050106@real.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 15:55:49.0923 (UTC) FILETIME=[B4478730:01C7803F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Jamie, See inline: Jamie Gordon skrev: > Magnus Westerlund wrote: > >> >> My proposal for this mechanism would be to add two new header: >> Pipe-Hdr = "Pipe-Lined-Requests" HCOLON random-id >> random-id = 12*(Digit / Alpha) >> SeqNr = 1*DIGIT > > What is the purpose of the "SeqNr"? I don't see it described or used > and don't see why it would be necessary. > >> The Pipe-Lined-Requests header is used to identify which requests that >> shall be treated together and needs to be included in each request >> that are pipe-lined within the same context. That way the server will >> when handling the first one know that the context will need to be >> saved and for how many future requests. The random-ID is one part of a >> mechanism to avoid collisions between requests and allow multiple >> ongoing pipelining sequences to happen at the same time. This is >> necessary to allow for proxies to aggregate multiple interactions over >> the same connection. The ID shall be freshly generated in a >> cryptographically random way (RFC 4086) for each sequence of pipelined >> requests. This intends to satisfy the requirement to have little risk >> of collision and provide an identifier for binding the requests to the >> context being generated. > > It should not be required to be random, this seems overly complex. A > pipeline session initiation ID applies to exactly one session on one > connection. A client controlling multiple sessions over the same RTSP > control channel need only ensure that each session is given a different > ID, it does not need to worry about conflicting with any others. A proxy > aggregating requests for multiple clients over a single RTSP control > channel will clearly need to be able to handle collisions and modify > the IDs either way, there's not reason to add complexity to the client > just so aggregating proxies have to exercise that code less frequently. > You seem to be right that one can skip using a random number, and rely on the sending part on the transport connection to keep unique numbers. What I am not certain is completely without issues would be connection less transport of RTSP messages. But we have no such transport defined and it seems unlikely that we can get UDP into a workable order. >> The server shall timeout the temporary context to prevent an attack >> after 60 seconds. In case of someone attack the server by creating a >> large number of contexts then the server can refuse to save the >> context and instead provide an error message that the context is not >> available for any request after the first one. However in this case >> the server is more likely to run out of room for session states anyway. > > This seems again to be going overboard. It's just an ID, it shouldn't > really create anything and be used to attack the server. The ID doesn't' > create a session or anything, the SETUP does. An attempt to initiate a > pipelining ID with a method that does not initiate a session would just > fail, it should not create a session on the server. And attempts to > attack a server via repeated SETUPs is not unique to setups using this > ID. > > It identifies a single session on a single connection and therefore > stops being valid if either the RTSP connection is closed or the Session > ends. It could also considered removed/no longer valid once a request > has been received on the session using the actual server generated > session ID, as any subsequent message clearly also can contain the > session ID. > > Sessions should be timed out in the normal manner at the server's > discretion, there should be no need to define a separate time-out. > Okay, you seem to be assuming that the SETUP comes first. Which I think is fine, but needs to be included in the rules. Then having the pipelining ID connected to the created session seems to avoid state creation except for the binding case. Something that maybe also needs to be considered is what happens if the client closes the TCP connection while have the RTSP session in place. To me that would mean that one delete the pipelining ID as it would be a combination of the TCP connection and the ID in the RTSP message. But that shouldn't have any negative impact as at this time one knows the session ID. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 12:01:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTeG-0001Nn-4c; Mon, 16 Apr 2007 12:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTeE-0001Ni-Jf for mmusic@ietf.org; Mon, 16 Apr 2007 12:01:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTeD-0005GT-Sz for mmusic@ietf.org; Mon, 16 Apr 2007 12:01:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50364201E4; Mon, 16 Apr 2007 18:01:45 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-3f-46239de9e8fb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3AEBD200D2; Mon, 16 Apr 2007 18:01:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 18:01:45 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 18:01:43 +0200 Message-ID: <46239DE6.80506@ericsson.com> Date: Mon, 16 Apr 2007 18:01:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Imed.Bouazizi@nokia.com Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 16:01:43.0665 (UTC) FILETIME=[87204610:01C78040] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Imed.Bouazizi@nokia.com skrev: > Hi David, > > The problems I see with the other 3 proposals: > > 1) Magnus's proposal: if one of the SETUP fails, one of the streams > might already be playing out and a PAUSE, SETUP, PLAY will cause the > playout to start from a position other than the requested one. The > server will also need to seek again to locate a RAP. Yes, but as this only should happen in error cases I don't see the problem. And in most common cases we are talking about seeking to the beginning of the stream. How often are you actually seeing that SETUP fails? There are already mechanisms in RTSP that is built around being fast when things go right and slower when there are errors. [snip] > > Regarding my proposal: the embedded requests are identical to normal > requests. The transaction request is simply an envelope that is used as > delimiter. It is also used to signal options about the transaction. E.g. > if any SETUP request fails, PLAY should not be performed (or should fail > as well). > Imed, I still doesn't see how embedding the request in an envelope helps anyone. You would get the same responses from the individual messages. The roleback would probably require more. And the only thing you have saved is the amount of resources required to perform the playback during the time. And if that is really you desire I have a solution on how to make the PLAY conditional on earlier request being successful. In that case I would introduce a header that indicate which sequence number that needs to have completed successfully before performing the request. However I removed it because it requires more state in the server, would very seldom be exercised, and that there existed good ways of cleaning up if something went wrong. I would also like to point out that the minute we start using ICE style NAT traversal we are likely to end up doing pipelined SETUP and then wait with PLAY until we have confirmed that the connectivity checks have completed. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 12:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTic-0003dL-LD; Mon, 16 Apr 2007 12:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTib-0003d4-6g for mmusic@ietf.org; Mon, 16 Apr 2007 12:06:17 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTiZ-0006Cp-GX for mmusic@ietf.org; Mon, 16 Apr 2007 12:06:17 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08C1320743; Mon, 16 Apr 2007 18:06:15 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-c8-46239ef6ee18 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DCFF6206C6; Mon, 16 Apr 2007 18:06:14 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 18:06:14 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 18:06:14 +0200 Message-ID: <46239EF5.9080705@ericsson.com> Date: Mon, 16 Apr 2007 18:06:13 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: EKR Subject: Re: [MMUSIC] RTSP: Upgrade to TLS References: <458AA14E.30609@ericsson.com> <86hcvpatu0.fsf@raman.networkresonance.com> <458BA503.6030107@ericsson.com> <86hcvo809r.fsf@raman.networkresonance.com> In-Reply-To: <86hcvo809r.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2007 16:06:14.0492 (UTC) FILETIME=[288D31C0:01C78041] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: "mmusic \(E-mail\)" , Stephen Farrell X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Eric Rescorla skrev: > Magnus Westerlund writes: > >> Eric Rescorla skrev: >>> Magnus Westerlund writes: >>> >>>> Hi, >>>> >>>> Some months ago Stephen Farrel made a review of the TLS related parts >>>> of the RTSP 2.0 spec. One of the comments he had was: >>>> >>>> "1. I guess there's no point in arguing this, but I thought the >>>> START_TLS approach was favoured over stuff like "rtsps:". If there's a >>>> specific reason here for this then maybe it'd be worth stating (even >>>> if its only historic)." >>>> >>>> I have looked at this and reviewed how this is done in HTTP. >>>> ftp://ftp.rfc-editor.org/in-notes/rfc2817.txt >>> Despite being PS, RFC2817 isn't really how things are mostly >>> done in HTTP. Rather, RFC 2818 (HTTPS) is how things are done. >>> >> Okay, but that doesn't prevent us in RTSP 2.0 to adopt this way as the >> primary way of doing TLS. RTSP over TLS hasn't really been defined and >> it seems reasonable to define the possibilities to do this over a >> single port and avoid the need to reopen a TCP connection if one >> wasn't aware of the need for TLS from the start. > > Right. I was just providing context. > > >>> 2. Signalling to the server that the client would like TLS. >>> This can be done either via a separate port or via an >>> upgrade-type mechanism. >> And that is what I am proposing to be done using a upgrade type >> mechanism instead of using a separate port. As I see we have three >> alternatives on how to accomplish this. >> >> A. Require the usage of a separate port (332) when using TLS. It is >> already registered and I assume that this is how any old RTSP 1.0 >> implementations does it. >> >> B. Use a upgrade mechanism similar to RFC 2817. >> >> C. Require servers to implement both A and B. Let the clients choose >> mechanism. > > If you've already defined a separate port, I don't see a lot of > virtue in moving to an upgrade mechanism. Note that there > are two types of mechanism here: > > 1. A demux. The client sends some message that says "TLS coming > next" and the server better accept it. This is a simple > port-sharing scheme. > 2. Opportunistic upgrade. The client and the server detect that > they jointly support TLS and auto-upgrade to it. This is > what (e.g., SMTP STARTTLS is basically intended to do). > > If you already have a special URL and so you're not doing opportunistic > (which seems like the case) the only reason for demux scheme is > to save ports. And if you've already got a port allocated... > So the simple solution (from work perspective) to this problem is to use the different ports and not define anything new. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 12:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTjr-0004Mn-U0; Mon, 16 Apr 2007 12:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTjq-0004Mi-SA for mmusic@ietf.org; Mon, 16 Apr 2007 12:07:34 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdTjq-0006UD-E7 for mmusic@ietf.org; Mon, 16 Apr 2007 12:07:34 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Apr 2007 09:07:30 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3GG6pD1000646; Mon, 16 Apr 2007 09:06:51 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3GG7N0c020760; Mon, 16 Apr 2007 09:07:23 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 09:07:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC:draft-ietf-mmusic-ice-15.txt) Date: Mon, 16 Apr 2007 09:06:54 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226B3199@namail5.corp.adobe.com> In-Reply-To: <4623321C.1090008@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC:draft-ietf-mmusic-ice-15.txt) Thread-Index: AceAAFCrF7bbYDQITI2QOUuMomPpGgAQD2/g References: <034301c77e25$45a4dab0$c4f0200a@amer.cisco.com> <4623321C.1090008@ericsson.com> From: "Henry Sinnreich" To: "Magnus Westerlund" , "Dan Wing" X-OriginalArrivalTime: 16 Apr 2007 16:07:22.0460 (UTC) FILETIME=[511049C0:01C78041] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mmusic@ietf.org, Lars Eggert X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Magnus Westerlund writes: > Actually ICE is much worse. ---snip--- >That way an RTP + RTCP implementation can at least avoid persistent >congestion. I don't understand this. The only way to avoid persistent congestion is to change to another ISP that is not oversubscribed.=20 Since when can an application level protocol avoid oversubscription :-) Thanks, Henry -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, April 16, 2007 1:22 AM To: Dan Wing Cc: Lars Eggert; mmusic@ietf.org Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC:draft-ietf-mmusic-ice-15.txt) Dan Wing skrev: >=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Friday, April 13, 2007 5:14 AM > > To: Jonathan Rosenberg > > Cc: mmusic@ietf.org; Lars Eggert > > Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > ... > > I6. Pacing of connectivity checks. I need to think a bit more about > > this and how ICE relates to the UDP usage guidelines > > (http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-gu > > idelines-02.txt) we are working on getting accepted in the > > transport area. Ice with the current parameters are rather > > aggressive in its bandwidth usage in worst case. I understand > > in most cases it would not consume close to as much. > > > > The biggest problem with this bloody protocol is its purpose > > resulting in that basically all STUN request packets could be > > dropped by NAT filtering rather than congestion. Or it could be the > > other way around. We have no way of knowing. This also causes the > > connectivity checks themselves some problem. As all checks easily > > can congest themselves thus causing worse performance then the > > correct rate limited sending would have. I think we need to at > > least consider putting some further limitation or adaptation of the > > pacing timers in some cases. At least when you have knowledge about > > link speeds. > > > > I know we have had quite some discussion on this topic earlier and > > the algorithm has clearly been made to try as few checks as possible > > thanks to the freezing of some checklist etc. But in my current role > > I need to take this even more serious than before. >=20 > Right now, the "Ta" timer in ICE is suggested to be 20ms. Would it > be reasonable to make "Ta" be the greater of 20ms or the "ptime" for > the associated media line? That is, if the ptime is 50ms, then > ICE's "Ta" would also be 50ms. In this way, ICE is no worse than > the RTP flow itself. Actually ICE is much worse. Because you have no way of determining if=20 the lost connectivity checks are being filtered by a NAT or are=20 congestion losses. When running RTP you know that losses are most likely to be congestion losses. And you have RTCP to tell you as a sender that=20 something is happening. At least on a medium time scale. That way an RTP + RTCP implementation can at least avoid persistent congestion. Maybe what I am looking for is better guidance on how to tune the=20 parameters when you know something. And in addition maybe some more=20 conservative default values. But what is needed is discussion on this. >=20 > Using the link speed, if you know it, could be helpful, too, but > you seldom know it. For example I have a DSL uplink at home but > my local network is all 100mb Ethernet. >=20 Yes, that is the big problem. --=20 Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 16 23:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdeK0-0007oZ-2C; Mon, 16 Apr 2007 23:25:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdeJy-0007oO-3k for mmusic@ietf.org; Mon, 16 Apr 2007 23:25:34 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdeJw-0002fU-Pd for mmusic@ietf.org; Mon, 16 Apr 2007 23:25:34 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id ED7D733C23; Mon, 16 Apr 2007 20:25:54 -0700 (PDT) Date: Mon, 16 Apr 2007 20:25:54 -0700 From: Eric Rescorla To: Magnus Westerlund Subject: Re: [MMUSIC] RTSP: Upgrade to TLS In-Reply-To: <46239EF5.9080705@ericsson.com> References: <458AA14E.30609@ericsson.com> <86hcvpatu0.fsf@raman.networkresonance.com> <458BA503.6030107@ericsson.com> <86hcvo809r.fsf@raman.networkresonance.com> <46239EF5.9080705@ericsson.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070417032554.ED7D733C23@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Stephen Farrell , "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org At Mon, 16 Apr 2007 18:06:13 +0200, Magnus Westerlund wrote: > Eric Rescorla skrev: > > Magnus Westerlund writes: > > > >> Eric Rescorla skrev: > >>> Magnus Westerlund writes: > >>> > >>>> Hi, > >>>> > >>>> Some months ago Stephen Farrel made a review of the TLS related parts > >>>> of the RTSP 2.0 spec. One of the comments he had was: > >>>> > >>>> "1. I guess there's no point in arguing this, but I thought the > >>>> START_TLS approach was favoured over stuff like "rtsps:". If there's a > >>>> specific reason here for this then maybe it'd be worth stating (even > >>>> if its only historic)." > >>>> > >>>> I have looked at this and reviewed how this is done in HTTP. > >>>> ftp://ftp.rfc-editor.org/in-notes/rfc2817.txt > >>> Despite being PS, RFC2817 isn't really how things are mostly > >>> done in HTTP. Rather, RFC 2818 (HTTPS) is how things are done. > >>> > >> Okay, but that doesn't prevent us in RTSP 2.0 to adopt this way as the > >> primary way of doing TLS. RTSP over TLS hasn't really been defined and > >> it seems reasonable to define the possibilities to do this over a > >> single port and avoid the need to reopen a TCP connection if one > >> wasn't aware of the need for TLS from the start. > > > > Right. I was just providing context. > > > > > >>> 2. Signalling to the server that the client would like TLS. > >>> This can be done either via a separate port or via an > >>> upgrade-type mechanism. > >> And that is what I am proposing to be done using a upgrade type > >> mechanism instead of using a separate port. As I see we have three > >> alternatives on how to accomplish this. > >> > >> A. Require the usage of a separate port (332) when using TLS. It is > >> already registered and I assume that this is how any old RTSP 1.0 > >> implementations does it. > >> > >> B. Use a upgrade mechanism similar to RFC 2817. > >> > >> C. Require servers to implement both A and B. Let the clients choose > >> mechanism. > > > > If you've already defined a separate port, I don't see a lot of > > virtue in moving to an upgrade mechanism. Note that there > > are two types of mechanism here: > > > > 1. A demux. The client sends some message that says "TLS coming > > next" and the server better accept it. This is a simple > > port-sharing scheme. > > 2. Opportunistic upgrade. The client and the server detect that > > they jointly support TLS and auto-upgrade to it. This is > > what (e.g., SMTP STARTTLS is basically intended to do). > > > > If you already have a special URL and so you're not doing opportunistic > > (which seems like the case) the only reason for demux scheme is > > to save ports. And if you've already got a port allocated... > > > > So the simple solution (from work perspective) to this problem is to use > the different ports and not define anything new. Pretty much, yeah... -Ekr _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 17 11:05:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpFl-0007Qs-7I; Tue, 17 Apr 2007 11:05:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpFj-0007Qj-J9 for mmusic@ietf.org; Tue, 17 Apr 2007 11:05:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpFj-0003ml-31 for mmusic@ietf.org; Tue, 17 Apr 2007 11:05:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C55B208E2; Tue, 17 Apr 2007 17:05:54 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-14-4624e252e437 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58361208D0; Tue, 17 Apr 2007 17:05:54 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:05:54 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:05:53 +0200 Message-ID: <4624E251.4090903@ericsson.com> Date: Tue, 17 Apr 2007 17:05:53 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> In-Reply-To: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2007 15:05:53.0758 (UTC) FILETIME=[E4D6C7E0:01C78101] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 'Lars Eggert' , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Dan Wing skrev: >>> Right now, the "Ta" timer in ICE is suggested to be 20ms. Would it >>> be reasonable to make "Ta" be the greater of 20ms or the "ptime" for >>> the associated media line? That is, if the ptime is 50ms, then >>> ICE's "Ta" would also be 50ms. In this way, ICE is no worse than >>> the RTP flow itself. >> Actually ICE is much worse. Because you have no way of determining if >> the lost connectivity checks are being filtered by a NAT or are >> congestion losses. When running RTP you know that losses are >> most likely to be congestion losses. > > I don't understand. > > With RTP, you're going to transmit a packet every 10ms (or 20ms) into > the network, with no built-in backoff (no initial RTT estimate, and no > requirement that RTCP indicates successful packet reception until the > first RTCP receiver report is sent, which is approximately every 5 > seconds). In the meantime, the sender is sending a packet every 10ms > (or 20ms or so) into the network. Yes, if you are the common congestion problem ignoring implementation then there are no difference. However for RTP you can do a number of things to make it much more responsive. First you can reconfigure your RTCP reporting using AVPF to be sending at least every 0.5 second or even faster depending on your general bit-rate. But the main point is that you do have a feedback mechanism. Which you really should take into account. > > ICE is going to transmit a packet every 20ms (per its current > recommendation in ice-16), wait for a response, and has built-in > exponential backoff for its retransmits. Yes, but the problem is that it is starting new transmissions every Ta seconds. And you have no idea when the sum of these transmissions on any of your local interfaces are reaching the capacity of that path. It is far from obvious that your paths can handle the 180 kbps max rate the draft talks about. What if your outgoing link is 30 kbps. > > This is more gentle to the network than the RTP flow that needs > to start soon. In fact, if the network is dropping so many > packets that a connectivity check can't complete (even with its > retransmits), the RTP flow won't be started; without ICE, the > new RTP flow would start and further contribute to network > congestion. If that RTP flow is at least having some adaptation which it really should have then it will react to the congestion. More for the sake of the application then anything else. And I do not consider ICE being gentle. It is still spewing out packets in the worst case after 2 seconds. > >> And you have RTCP to tell you as a sender that something is >> happening. At least on a medium time scale. That >> way an RTP + RTCP implementation can at least avoid >> persistent congestion. > > As can ICE, with ICE's exponential backoff of the STUN > transaction retransmission timers. > >> Maybe what I am looking for is better guidance on how to tune the >> parameters when you know something. And in addition maybe some more >> conservative default values. >> >> But what is needed is discussion on this. > > Ok. What is the best venue for such discussion? Would the TSVWG > or perhaps the e2e-interest mailing list be better? I expect > MMUSIC isn't usually read by folks interested in network > congestion. I think TSV-Area is a good list to discuss this. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 17 11:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpHQ-0007mH-Kh; Tue, 17 Apr 2007 11:07:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpHP-0007lV-CC for mmusic@ietf.org; Tue, 17 Apr 2007 11:07:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpHO-0004kx-19 for mmusic@ietf.org; Tue, 17 Apr 2007 11:07:39 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7F4DE213A3; Tue, 17 Apr 2007 17:07:37 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-49-4624e2b948bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6B13D211A5; Tue, 17 Apr 2007 17:07:37 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:07:37 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:07:36 +0200 Message-ID: <4624E2B8.4050202@ericsson.com> Date: Tue, 17 Apr 2007 17:07:36 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt) References: <034301c77e25$45a4dab0$c4f0200a@amer.cisco.com><4623321C.1090008@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D226B3199@namail5.corp.adobe.com> <62D92A9A02BCC845B202323D49A48426E1D084@0591-ITS-EXMP02.us.saic.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1D084@0591-ITS-EXMP02.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2007 15:07:36.0785 (UTC) FILETIME=[223F7410:01C78102] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Lars Eggert , mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Roy, Radhika R. skrev: > > Probably, Magnus is saying about the time-scale that RTP + RTCP provides > to measure the persistent congestion in the network. Exactly, if you are seeing congestion that continue to be present during a few seconds you better react to it if you are a sending application. We do prefer that transmitters are reacting within an RTT. But reacting on time scale of seconds are still better than not reacting at all. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 17 14:40:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsbB-000841-FS; Tue, 17 Apr 2007 14:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsbA-00083v-BG for mmusic@ietf.org; Tue, 17 Apr 2007 14:40:16 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdsb9-0002os-Ld for mmusic@ietf.org; Tue, 17 Apr 2007 14:40:16 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3HIe9TJ006297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 11:40:10 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3HIe8eM004639; Tue, 17 Apr 2007 11:40:08 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 11:40:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Proposal to modify RFC3890 TIAS in offer/answer Was RE: [MMUSIC] Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Date: Tue, 17 Apr 2007 11:40:04 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD20FA@NAEX01.na.qualcomm.com> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02A354A3@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to modify RFC3890 TIAS in offer/answer Was RE: [MMUSIC] Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Thread-Index: Acdn6mV7RvdCSEKsS5ew8hdKBSP3egAeU+fgBd+tG7A= References: <2CA3E1B6CEC064449CAA7D0FAB46079B02A35033@NAEX01.na.qualcomm.com><45FAAC25.8010902@ericsson.com><2CA3E1B6CEC064449CAA7D0FAB46079B02A353C4@NAEX01.na.qualcomm.com><45FAC96C.4090308@ericsson.com> <2CA3E1B6CEC064449CAA7D0FAB46079B02A354A3@NAEX01.na.qualcomm.com> From: "Desineni, Harikishan" To: X-OriginalArrivalTime: 17 Apr 2007 18:40:08.0492 (UTC) FILETIME=[D2DB86C0:01C7811F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Magnus Westerlund , roni.even@polycom.co.il, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Some issues with the offer/answer usage of TIAS (defined in RFC3890) came out while discussing draft-hdesinen-mmusic-oa-send-bw-attr-02.txt. RFC3890 has incorrectly defined TIAS and maxprate as 'recv' direction attributes in offer/answer model. As 'recv' attributes, TIAS and maxprate do not solve the bandwidth negotiation problem. For offer/answer bw negotiation to work properly, the correct direction in rfc3890 should have been 'send', probably with the help of few new 'recv' direction attributes (like PO - per packet overhead at layer X, RB- receive BW at layer X) under discussion. A sender would choose (TIAS,maxprate) which satisfy the following formula TIAS + (maxprate * PO) <=3D RB (PO and RB are signaled by the receiver) One approach to handle this is changing the direction of (TIAS,maxprate) to 'send' and prevent the incorrect ('recv') usage of (TIAS,maxprate) in offer/answer model. While this appears to be the desired direction, I am interested to know the impact of such a change on (any) existing implementations of TIAS in offer/answer. Please comment if you are aware of any existing implementations of TIAS in offer/answer and also describe how exactly TIAS was used in that particular implementation. Thanks, Hari > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > Sent: Saturday, March 17, 2007 12:26 AM > To: Magnus Westerlund; roni.even@polycom.co.il > Cc: Mahendran, AC; Dondeti, Lakshminath; mmusic@ietf.org; avt@ietf.org > Subject: RE: [MMUSIC] Comments on draft-hdesinen-mmusic-oa-send-bw-attr- > 02.txt >=20 > I copied a post (from AVT list) from Roni which states that TIAS was > actually used in his implementation. I am not sure if it is an > implementation in offer/answer model. >=20 > [CCed AVT as TIAS was also recently discussed on AVT list] >=20 > " > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Monday, January 08, 2007 7:35 AM > To: Randell Jesup > Cc: Stephan Wenger; avt@ietf.org > Subject: RE: [AVT] CCM draft review -- should "bandwidth" include > theheaderoverhead >=20 > Randell, > RFC 4890 recommends sending both TIAS and AS for backward compatibility > with systems that do not support TIAS. This RFC gives a good explanation > why to use TIAS. This is what we do in our implementation. > " >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Friday, March 16, 2007 9:44 AM > > To: Desineni, Harikishan > > Cc: mmusic@ietf.org > > Subject: Re: [MMUSIC] Comments on > draft-hdesinen-mmusic-oa-send-bw-attr- > > 02.txt > > > > Desineni, Harikishan skrev: > > > > > > > > > Magnus, > > > > > > Thanks for the comments. > > > > > > In the initial version, I captured the current understanding of > (TIAS > > > ,maxprate) based on RFC3890. > > > > > > Based on the current RFCs, majority of the community interprets TIAS > as > > > receive only direction attribute. Instead of updating RFC3890 to > modify > > > TIAS as a send direction only attribute, it is better to use a new > > > attribute 'MSR' proposed in this draft. This would also avoid any > > > backward compatibility/inter-op issues that can arise with current > > > implementations which (correctly) interpret TIAS as receive > direction > > > only attribute in offer/answer. > > > > Well, I wonder how there can be backwards compatibility issues with > > something that clearly doesn't work if you actually try to use it. > There > > might be implementations but I can't really understand how they could > > work. Do you know of implementations? > > > > > > > > Another approach is to add directionality to TIAS. By default, TIAS > is > > > receive only (not much useful) and "TIAS/sendonly" will be send only > > > direction. "maxprate/send" will be packet rate in send direction. > > > > > > What you are proposing is the following > > > Send direction attributes: RTP Payload rate and maxpacket rate > > > Receive direction attributes: AS (or a new one), packet overhead > > > > Okay, here I think the more important question is, are we expecting to > > be able to specify a value on another level than IP? If not I think AS > > works fine. > > > > > > > > In this draft I am proposing that 'MSR' be used for signaling RTP > > > payload rate in 'send' direction. IMO, it is not a clean approach to > > > redefine TIAS to be a 'send' direction attribute. > > > > We disagree on this. TIAS was specified as a send direction attribute. > I > > made an error in the offer/answer usage because I didn't consider the > > implications. And no one picked up on it. > > > > As I can see it in regards to RFC 3890 we have two alternatives: > > > > 1. Fix the offer/answer section to correctly define it to apply in the > > sending direction. > > > > 2. Obsolete usage of TIAS in Offer/Answer exchanges and only use it > for > > declarative usage, like in RTSP. > > > > If there are implementations i any numbers that interpret TIAS as a > > receiver direction attribute then I agree alternative 2 will be best. > > However I would like to have some positive acknowledgments of this > > first. This was after all revealed in the attempt to apply TIAS to > > offer/answer in the 3GPP MTSI standardization work. Resulting in that > > TIAS was only included in the draft spec for a while. I don't know if > > some other umbrella standard has included TIAS combined with > offer/answer. > > > > > > > > I am OK with signaling packet rate in send direction. But we need to > > > consider whether to reuse maxprate for this or add directionality to > > > maxprate (maxprate/send) to avoid any inter-op issues with current > > > implementations. > > > > > > > Cheers > > > > Magnus Westerlund > > > > IETF Transport Area Director & TSVWG Chair > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 18 10:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBUI-0005rv-3S; Wed, 18 Apr 2007 10:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBUG-0005pM-KT for mmusic@ietf.org; Wed, 18 Apr 2007 10:50:24 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBUF-0002z3-Ar for mmusic@ietf.org; Wed, 18 Apr 2007 10:50:24 -0400 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l3IEoLSB030116; Wed, 18 Apr 2007 10:50:21 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l3IEoJiO014700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 10:50:20 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Wed, 18 Apr 2007 10:50:19 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mmusic@ietf.org Subject: [MMUSIC] Concerned about role conflict resolution procedure in ICE-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan: I am concerned about the conflict resolution procedure for Controlling-End/Controlled-End that has been added in ICE-15. I haven't seen the 3PCC cases where this problem supposedly exists, and under my assumptions for when one can use ICE, I don't see how the problem can arise. In my mind, the document is very clear that one agent is the initial offerer and the other agent is the initial answerer, and with those assumptions, the conflict resolution procedure is not needed. All this means that I cannot evaluate whether the proposed mechanism actually works or is even needed. I think the document: 1) Needs to be explicit about the assumptions on when ICE can be used wrt. the offer/answer procedure. 2) Needs to give a reference to examples when the conflict resolution is needed. If you or anyone else could give me details on a specific use case where this problem arises, that would be very helpful. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 18 11:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBe9-0002Nv-FZ; Wed, 18 Apr 2007 11:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBe6-0002Nq-8W for mmusic@ietf.org; Wed, 18 Apr 2007 11:00:34 -0400 Received: from jor-el.real.com ([207.188.23.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBe5-0005wP-PQ for mmusic@ietf.org; Wed, 18 Apr 2007 11:00:34 -0400 Received: from [192.168.1.106] ([::ffff:82.163.58.149]) (AUTH: PLAIN jgordon, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by jor-el.real.com with esmtp; Wed, 18 Apr 2007 08:00:31 -0700 id 00094012.4626328F.000021D6 Message-ID: <46263288.8040306@real.com> Date: Wed, 18 Apr 2007 16:00:24 +0100 From: Jamie Gordon User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment References: <458ABFA6.8030107@ericsson.com> <459C4999.5050106@real.com> <46239C84.7050600@ericsson.com> In-Reply-To: <46239C84.7050600@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Magnus Westerlund wrote: >> It should not be required to be random, this seems overly complex. A >> pipeline session initiation ID applies to exactly one session on one >> connection. A client controlling multiple sessions over the same RTSP >> control channel need only ensure that each session is given a different >> ID, it does not need to worry about conflicting with any others. A proxy >> aggregating requests for multiple clients over a single RTSP control >> channel will clearly need to be able to handle collisions and modify >> the IDs either way, there's not reason to add complexity to the client >> just so aggregating proxies have to exercise that code less frequently. >> > > You seem to be right that one can skip using a random number, and rely > on the sending part on the transport connection to keep unique numbers. > > What I am not certain is completely without issues would be connection > less transport of RTSP messages. But we have no such transport defined > and it seems unlikely that we can get UDP into a workable order. Yes that's true, I was assuming pipelined messages sent in connected transport (or pipelined in a single packet on a non-connected transport). Pipelining seems to be defined only for connected transports (see section 9.2), though I can't think of any obvious need for that to be required in general. >> It identifies a single session on a single connection and therefore >> stops being valid if either the RTSP connection is closed or the Session >> ends. It could also considered removed/no longer valid once a request >> has been received on the session using the actual server generated >> session ID, as any subsequent message clearly also can contain the >> session ID. >> >> Sessions should be timed out in the normal manner at the server's >> discretion, there should be no need to define a separate time-out. >> > > Okay, you seem to be assuming that the SETUP comes first. Which I think > is fine, but needs to be included in the rules. Then having the > pipelining ID connected to the created session seems to avoid state > creation except for the binding case. I suppose I am. Since this only makes sense for messages that need to be carried on a session that has not been created, I don't really see any valid use case without a session-initiating message (SETUP) coming first. Perhaps I have preconceived notions of the feature, but it seems the only sensible use case is messages pipelined after the session- initiating SETUP which are intended to be carried on the session which is being initiated. > Something that maybe also needs to be considered is what happens if the > client closes the TCP connection while have the RTSP session in place. > To me that would mean that one delete the pipelining ID as it would be a > combination of the TCP connection and the ID in the RTSP message. But > that shouldn't have any negative impact as at this time one knows the > session ID. Yeah, I suppose there is some impact if this happens prior to the client's reception of the session ID (the client would then have to wait for the first response). Seems like a very small corner case. Mostly I am reluctant to have client side requirements to generate IDs that can be considered unique at the server when it seems that expected realistic use cases are far simpler. Thanks, Jamie > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 18 11:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCRK-00086B-6R; Wed, 18 Apr 2007 11:51:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCRI-0007xf-Un for mmusic@ietf.org; Wed, 18 Apr 2007 11:51:24 -0400 Received: from kal-el.real.com ([207.188.23.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeCRF-00039j-2n for mmusic@ietf.org; Wed, 18 Apr 2007 11:51:24 -0400 Received: from [192.168.1.106] ([::ffff:82.163.58.149]) (AUTH: PLAIN jgordon, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by kal-el.real.com with esmtp; Wed, 18 Apr 2007 08:51:17 -0700 id 000800B5.46263E75.00004E79 Message-ID: <46263E72.20405@real.com> Date: Wed, 18 Apr 2007 16:51:14 +0100 From: Jamie Gordon User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [MMUSIC] RTSP/2.0 RTP-Info changes (draft-ietf-mmusic-rfc2326bis-14.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I have some concerns about the changes made to the syntax of RTP-Info in the RTSP 2.0 draft. In RTSP/1.0 it is a simple standard semi-colon separated list of values concerning the identified URL parameter. The newer draft changes it considerably, and I do not see any reason given or examples illustrating the need. Since it is far more complex, requires very specific parsers, and completely separate code path (in case of a server supporting both 1.0 and 2.0, which one would assume will be rather common if 2.0 is to take hold), I would like to understand the reasoning for this change, and whether there is a simpler alternative. Thanks, Jamie Gordon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 18 11:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCSe-0000Lp-7f; Wed, 18 Apr 2007 11:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCSa-0000LM-SS for mmusic@ietf.org; Wed, 18 Apr 2007 11:52:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCSa-0001lw-3V for mmusic@ietf.org; Wed, 18 Apr 2007 11:52:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8838F207DE; Wed, 18 Apr 2007 17:52:43 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-57-46263ecb4179 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 637002042E; Wed, 18 Apr 2007 17:52:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 17:52:42 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 17:52:42 +0200 Message-ID: <46263ECA.3060706@ericsson.com> Date: Wed, 18 Apr 2007 17:52:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jamie Gordon Subject: Re: [MMUSIC] RTSP: Improved pipelining to speed up session establishment References: <458ABFA6.8030107@ericsson.com> <459C4999.5050106@real.com> <46239C84.7050600@ericsson.com> <46263288.8040306@real.com> In-Reply-To: <46263288.8040306@real.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 15:52:42.0658 (UTC) FILETIME=[997CA820:01C781D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jamie Gordon skrev: > Magnus Westerlund wrote: >>> It should not be required to be random, this seems overly complex. A >>> pipeline session initiation ID applies to exactly one session on one >>> connection. A client controlling multiple sessions over the same RTSP >>> control channel need only ensure that each session is given a different >>> ID, it does not need to worry about conflicting with any others. A proxy >>> aggregating requests for multiple clients over a single RTSP control >>> channel will clearly need to be able to handle collisions and modify >>> the IDs either way, there's not reason to add complexity to the client >>> just so aggregating proxies have to exercise that code less frequently. >>> >> >> You seem to be right that one can skip using a random number, and rely >> on the sending part on the transport connection to keep unique numbers. >> >> What I am not certain is completely without issues would be connection >> less transport of RTSP messages. But we have no such transport defined >> and it seems unlikely that we can get UDP into a workable order. > > Yes that's true, I was assuming pipelined messages sent in connected > transport (or pipelined in a single packet on a non-connected > transport). Pipelining seems to be defined only for connected > transports (see section 9.2), though I can't think of any obvious > need for that to be required in general. Well, currently if we look at the specification we will not define anything else than connection oriented transports. But you are probably right that the MAY used in the last sentence in section 9.2 is not needed and can be cleaned away. > >>> It identifies a single session on a single connection and therefore >>> stops being valid if either the RTSP connection is closed or the Session >>> ends. It could also considered removed/no longer valid once a request >>> has been received on the session using the actual server generated >>> session ID, as any subsequent message clearly also can contain the >>> session ID. >>> >>> Sessions should be timed out in the normal manner at the server's >>> discretion, there should be no need to define a separate time-out. >>> >> >> Okay, you seem to be assuming that the SETUP comes first. Which I >> think is fine, but needs to be included in the rules. Then having the >> pipelining ID connected to the created session seems to avoid state >> creation except for the binding case. > > I suppose I am. Since this only makes sense for messages that need to be > carried on a session that has not been created, I don't really see any > valid use case without a session-initiating message (SETUP) coming > first. Perhaps I have preconceived notions of the feature, but it seems > the only sensible use case is messages pipelined after the session- > initiating SETUP which are intended to be carried on the session which > is being initiated. Yes, I think you are right. You need to create some session state to operate on to make pipelining at all useful. And if you are manipulating server wide state prior to the SETUP then you anyway don't need to pipelining solution proposed. > >> Something that maybe also needs to be considered is what happens if >> the client closes the TCP connection while have the RTSP session in >> place. To me that would mean that one delete the pipelining ID as it >> would be a combination of the TCP connection and the ID in the RTSP >> message. But that shouldn't have any negative impact as at this time >> one knows the session ID. > > Yeah, I suppose there is some impact if this happens prior to the > client's reception of the session ID (the client would then have to wait > for the first response). Seems like a very small corner case. Mostly I > am reluctant to have client side requirements to generate IDs that can > be considered unique at the server when it seems that expected realistic > use cases are far simpler. > If the connection closes prior to getting response, then anyway the client have no knowledge about what happened. And can only restart from the beginning. Thus I think there should be no problem here. Thanks for helping simplify the proposal. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 18 12:46:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDIU-0005fw-PH; Wed, 18 Apr 2007 12:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUzg-0001MX-95 for mmusic@ietf.org; Mon, 16 Apr 2007 13:28:00 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUzc-0004m5-Au for mmusic@ietf.org; Mon, 16 Apr 2007 13:28:00 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Mon, 16 Apr 2007 13:27:50 -0400 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007041613275112043 ; Mon, 16 Apr 2007 13:27:51 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:27:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: ICE pacing connectivity checks (was RE: [MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt) Date: Mon, 16 Apr 2007 13:23:04 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D084@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE pacing connectivity checks (was RE: [MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt) Thread-Index: AceAAFCrF7bbYDQITI2QOUuMomPpGgAQD2/gAALVbC8= References: <034301c77e25$45a4dab0$c4f0200a@amer.cisco.com><4623321C.1090008@ericsson.com> <24CCCC428EFEA2469BF046DB3C7A8D226B3199@namail5.corp.adobe.com> From: "Roy, Radhika R." To: "Henry Sinnreich" , "Magnus Westerlund" , "Dan Wing" X-OriginalArrivalTime: 16 Apr 2007 17:27:50.0885 (UTC) FILETIME=[8F077950:01C7804C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-Mailman-Approved-At: Wed, 18 Apr 2007 12:46:22 -0400 Cc: mmusic@ietf.org, Lars Eggert X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0440918840==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0440918840== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7804C.8EAB92E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7804C.8EAB92E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Probably, Magnus is saying about the time-scale that RTP + RTCP provides = to measure the persistent congestion in the network. =20 Best regards, Radhika =20 PS: Of course, people have to change ISP, but it take some time to = decide it is due to oversubscriptions of the ISP. ________________________________ From: mmusic-bounces@ietf.org on behalf of Henry Sinnreich Sent: Mon 4/16/2007 12:06 PM To: Magnus Westerlund; Dan Wing Cc: mmusic@ietf.org; Lars Eggert Subject: RE: ICE pacing connectivity checks (was RE: = [MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt) Magnus Westerlund writes: > Actually ICE is much worse. ---snip--- >That way an RTP + RTCP implementation can at least avoid persistent >congestion. I don't understand this. The only way to avoid persistent congestion is to change to another ISP that is not oversubscribed. Since when can an application level protocol avoid oversubscription :-) Thanks, Henry ------_=_NextPart_001_01C7804C.8EAB92E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ICE pacing connectivity checks (was RE: = [MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt)=0A= =0A= =0A= =0A=
=0A=
Probably, = Magnus is saying about the time-scale that RTP + RTCP provides to = measure the persistent congestion in the network.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=
 
=0A=
PS: Of course, people have to = change ISP, but it take some time to decide it is due to = oversubscriptions of the ISP.
=0A=

=0A=
=0A= From: mmusic-bounces@ietf.org on = behalf of Henry Sinnreich
Sent: Mon 4/16/2007 12:06 = PM
To: Magnus Westerlund; Dan Wing
Cc: = mmusic@ietf.org; Lars Eggert
Subject: RE: ICE pacing = connectivity checks (was RE: = [MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt)

=0A=

=0A=

Magnus Westerlund writes:

> Actually ICE is = much worse.
---snip---
>That way an RTP + RTCP implementation = can at least avoid persistent
>congestion.

I don't = understand this. The only way to avoid persistent congestion is
to = change to another ISP that is not oversubscribed.

Since when can = an application level protocol avoid oversubscription :-)

Thanks, = Henry

------_=_NextPart_001_01C7804C.8EAB92E0-- --===============0440918840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0440918840==-- From mmusic-bounces@ietf.org Wed Apr 18 14:01:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeESq-0001Om-P2; Wed, 18 Apr 2007 14:01:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeESq-0001Oh-D8 for mmusic@ietf.org; Wed, 18 Apr 2007 14:01:08 -0400 Received: from mail44.opentransfer.com ([76.162.254.44]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeESp-0000dv-QS for mmusic@ietf.org; Wed, 18 Apr 2007 14:01:08 -0400 Received: (qmail 3493 invoked by uid 399); 18 Apr 2007 18:00:43 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 18 Apr 2007 18:00:43 -0000 Message-ID: <46265C9D.4050609@sipstation.com> Date: Wed, 18 Apr 2007 12:59:57 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> In-Reply-To: <4624E251.4090903@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'Lars Eggert' , Dan Wing , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Do we have any running code and actual deployment experience here? If not, I'd suggest adding further congestion avoidance in ICE would likely only have the effect of increasing the time taken to complete connectivity checks. This could be a significant problem for ICE in the real world. Thanks, Alan Magnus Westerlund wrote: > Dan Wing skrev: >>>> Right now, the "Ta" timer in ICE is suggested to be 20ms. Would it >>>> be reasonable to make "Ta" be the greater of 20ms or the "ptime" for >>>> the associated media line? That is, if the ptime is 50ms, then >>>> ICE's "Ta" would also be 50ms. In this way, ICE is no worse than >>>> the RTP flow itself. >>> Actually ICE is much worse. Because you have no way of determining >>> if the lost connectivity checks are being filtered by a NAT or are >>> congestion losses. When running RTP you know that losses are most >>> likely to be congestion losses. >> >> I don't understand. >> >> With RTP, you're going to transmit a packet every 10ms (or 20ms) into >> the network, with no built-in backoff (no initial RTT estimate, and no >> requirement that RTCP indicates successful packet reception until the >> first RTCP receiver report is sent, which is approximately every 5 >> seconds). In the meantime, the sender is sending a packet every 10ms >> (or 20ms or so) into the network. > > Yes, if you are the common congestion problem ignoring implementation > then there are no difference. However for RTP you can do a number of > things to make it much more responsive. First you can reconfigure your > RTCP reporting using AVPF to be sending at least every 0.5 second or > even faster depending on your general bit-rate. But the main point is > that you do have a feedback mechanism. Which you really should take > into account. > >> >> ICE is going to transmit a packet every 20ms (per its current >> recommendation in ice-16), wait for a response, and has built-in >> exponential backoff for its retransmits. > > Yes, but the problem is that it is starting new transmissions every Ta > seconds. And you have no idea when the sum of these transmissions on > any of your local interfaces are reaching the capacity of that path. > It is far from obvious that your paths can handle the 180 kbps max > rate the draft talks about. What if your outgoing link is 30 kbps. > >> >> This is more gentle to the network than the RTP flow that needs >> to start soon. In fact, if the network is dropping so many packets >> that a connectivity check can't complete (even with its >> retransmits), the RTP flow won't be started; without ICE, the new RTP >> flow would start and further contribute to network congestion. > > If that RTP flow is at least having some adaptation which it really > should have then it will react to the congestion. More for the sake of > the application then anything else. And I do not consider ICE being > gentle. It is still spewing out packets in the worst case after 2 > seconds. > >> >>> And you have RTCP to tell you as a sender that something is >>> happening. At least on a medium time scale. That way an RTP + RTCP >>> implementation can at least avoid persistent congestion. >> >> As can ICE, with ICE's exponential backoff of the STUN transaction >> retransmission timers. >> >>> Maybe what I am looking for is better guidance on how to tune the >>> parameters when you know something. And in addition maybe some more >>> conservative default values. >>> >>> But what is needed is discussion on this. >> >> Ok. What is the best venue for such discussion? Would the TSVWG >> or perhaps the e2e-interest mailing list be better? I expect MMUSIC >> isn't usually read by folks interested in network congestion. > > I think TSV-Area is a good list to discuss this. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 18 18:03:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIFU-0001S8-3V; Wed, 18 Apr 2007 18:03:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIFS-0001Rw-Tf for mmusic@ietf.org; Wed, 18 Apr 2007 18:03:34 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeIFR-0000K0-EG for mmusic@ietf.org; Wed, 18 Apr 2007 18:03:34 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3IM2oq18828; Wed, 18 Apr 2007 22:02:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Wed, 18 Apr 2007 17:03:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10170FF5@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt thread-index: AcdyE/OWnQfYTwALS9CjtEPt+fPC2AP7jJ3w X-Priority: 1 Priority: Urgent Importance: high References: From: "Francois Audet" To: "Jean-Francois Mule" , , "Jonathan Rosenberg" X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Colin Perkins , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org My comments for WGLC are included below: In order to be able to use ICE as the mechanism for supporting a dual-stack IPv4/IPv6 implementation, some minor changes need to be made to ICE-15. Specifically,=20 for the case where BOTH sides are using ICE-lite. The procedures when one or both sides are NOT using ICE-lite are OK as is in ICE-15. Using section 5 of ICE-15 as a basis. A sends offer to B. A uses ICE-lite, but it is dual stack, so the offer looks like=20 this: Offer: m=3DIPv4 <- Assumption is that IPv4 is morelikely to succeed than IPv6 candidate 1=3DIPv6 candidate 2=3DIPv4 a=3Dice-lite B receives the offer, it is also using ice-lite and is also dual stack. It sends an answer: m=3DIPv4 candidate 1=3DIPv6 candidate 2=3DIPv4 a=3Dice-lite According to section 5 today it would result in having "NO CONNECTIVITY CHECK". The current wording says "ICE cannot proceed", which I think is innacurate since the=20 candidates have already been sent, so ICE has already proceeded to a certain point. I think it=20 needs to be clarified is that it "ICE does not proceed with the connectivity check". According to section 5 again, it would result in having the IPv4 selected instead of the=20 IPv6 (i.e., the m line). That's NOT the behavior we want. What we want is in this case to have both sides use the candidates=20 and the RFC 3484 procedures. I would like to see some guidance around using RFC 3484 procedures. One easy way for B to ensure that it's choice is selected, is to respond with this answer instead: m=3DIPv6 <- i.e., forcing the other side to use the IPv6 address candidate 1=3DIPv6 <- I'm not sure we actually need this line? a=3Dice-lite <- This is to tell A that it understood ICE It might also be useful in this case, for the second offer answer (normal in ICE) to proceed to "lock" on the IPv6 address and help middleboxes. Therefore, the second offer answer would look like: Offer: m=3DIPv6 =20 Answer:=20 m=3DIPV6 I believe that if we do this, we will have addressed the requirements for dual-stack. > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Thursday, March 29, 2007 08:07 > To: mmusic@ietf.org > Cc: Colin Perkins; Joerg Ott > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 >=20 > This is to announce a Working Group Last Call on ICE=20 > draft-ietf-mmusic-ice-15.txt. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt >=20 > This WGLC will end on Friday April 20. >=20 > Please mail all your final comments to the author and the=20 > mmusic mailing list. >=20 > Jean-Francois -- As WG co-chair > jfm@cablelabs.com=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 01:04:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeOoa-00005x-Qv; Thu, 19 Apr 2007 01:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeOoZ-00005W-DD for mmusic@ietf.org; Thu, 19 Apr 2007 01:04:15 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeOoZ-0002GM-01 for mmusic@ietf.org; Thu, 19 Apr 2007 01:04:15 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3J549nA012748; Wed, 18 Apr 2007 23:04:10 -0600 (MDT) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Wed, 18 Apr 2007 23:04:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Apr 2007 23:04:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Wed, 18 Apr 2007 23:04:08 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C63A85@srvxchg3.cablelabs.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10170FF5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Thread-Index: AcdyE/OWnQfYTwALS9CjtEPt+fPC2AP7jJ3wAA7eCUA= References: <1ECE0EB50388174790F9694F77522CCF10170FF5@zrc2hxm0.corp.nortel.com> From: "Kevin Johns" To: "Francois Audet" , "Jean-Francois Mule" , , "Jonathan Rosenberg" X-OriginalArrivalTime: 19 Apr 2007 05:04:09.0200 (UTC) FILETIME=[29ABEF00:01C78240] X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Colin Perkins , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Francois email prompted me to pay special attention to section 4.2 while doing a detailed read of ice-15 as I was under the impression that ICE-lite only allowed for a single candidate. Reading section 4.2 a few times seems to provide mixed direction. The section starts off indicating that "for each media stream, the agent allocates a single candidate for each component of the media stream from one of its interfaces. If an agent has multiple interfaces it MUST choose one for each component of a particular media stream." I read this text to indicate a lite implementation can only have a single candidate per component? Further on in section 4.2 (the 3rd paragraph) it states "if an agent has included two candidates for a component, the v4 candidate SHOULD be selected as the default. Since a lite implementation has a single candidate for a component, each of these candidates is considered to be default." I find these two sentence a bit contradictory? Can someone clarify the intent of the text in section 4.2 and whether an ice-lite implementation can include multiple candidates for a single component? If multiple candidates are allowed then what Francois is proposing seems reasonable (along with some text clean up in section 4.2 of ICE). Thanks Kevin -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, April 18, 2007 4:03 PM To: Jean-Francois Mule; mmusic@ietf.org; Jonathan Rosenberg Cc: Colin Perkins; Joerg Ott Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Importance: High My comments for WGLC are included below: In order to be able to use ICE as the mechanism for supporting a dual-stack IPv4/IPv6 implementation, some minor changes need to be made to ICE-15. Specifically,=20 for the case where BOTH sides are using ICE-lite. The procedures when one or both sides are NOT using ICE-lite are OK as is in ICE-15. Using section 5 of ICE-15 as a basis. A sends offer to B. A uses ICE-lite, but it is dual stack, so the offer looks like=20 this: Offer: m=3DIPv4 <- Assumption is that IPv4 is morelikely to succeed than IPv6 candidate 1=3DIPv6 candidate 2=3DIPv4 a=3Dice-lite B receives the offer, it is also using ice-lite and is also dual stack. It sends an answer: m=3DIPv4 candidate 1=3DIPv6 candidate 2=3DIPv4 a=3Dice-lite According to section 5 today it would result in having "NO CONNECTIVITY CHECK". The current wording says "ICE cannot proceed", which I think is innacurate since the=20 candidates have already been sent, so ICE has already proceeded to a certain point. I think it=20 needs to be clarified is that it "ICE does not proceed with the connectivity check". According to section 5 again, it would result in having the IPv4 selected instead of the=20 IPv6 (i.e., the m line). That's NOT the behavior we want. What we want is in this case to have both sides use the candidates=20 and the RFC 3484 procedures. I would like to see some guidance around using RFC 3484 procedures. One easy way for B to ensure that it's choice is selected, is to respond with this answer instead: m=3DIPv6 <- i.e., forcing the other side to use the IPv6 address candidate 1=3DIPv6 <- I'm not sure we actually need this line? a=3Dice-lite <- This is to tell A that it understood ICE It might also be useful in this case, for the second offer answer (normal in ICE) to proceed to "lock" on the IPv6 address and help middleboxes. Therefore, the second offer answer would look like: Offer: m=3DIPv6 =20 Answer:=20 m=3DIPV6 I believe that if we do this, we will have addressed the requirements for dual-stack. > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 > Sent: Thursday, March 29, 2007 08:07 > To: mmusic@ietf.org > Cc: Colin Perkins; Joerg Ott > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 >=20 > This is to announce a Working Group Last Call on ICE=20 > draft-ietf-mmusic-ice-15.txt. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt >=20 > This WGLC will end on Friday April 20. >=20 > Please mail all your final comments to the author and the=20 > mmusic mailing list. >=20 > Jean-Francois -- As WG co-chair > jfm@cablelabs.com=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 02:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQ8d-0006mO-Ki; Thu, 19 Apr 2007 02:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQ8b-0006m0-Vr for mmusic@ietf.org; Thu, 19 Apr 2007 02:29:01 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeQ8a-0004nV-PL for mmusic@ietf.org; Thu, 19 Apr 2007 02:29:01 -0400 Received: by wr-out-0506.google.com with SMTP id 71so441331wri for ; Wed, 18 Apr 2007 23:29:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZPo8V9oPjy0hChaVTay4CQpbcy3KBVAqQznaAQfdqL8ShzwnOwmL7lidKe9t8O6UQIn9zBoENtBvSV1VbZoJ8TS3adN6zIPYOxR3J/Q09IMHGBtBNre+r2Whzx5uL5CX0Hyo8OSXXGeslPQ9oyulYZpixkPJ+nrFMWgNdJIAnyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iIfbFrbmlG3N44kEXjDqr5Rouh5yNz0Z2MGV6Y4UsGEzIpv1+A63dBGwKoxT9y8laUUZObj+sC0AqBUJjUyFp4qtmh1taCrviWTQTWpB7BZOcmViFr8X0SfmRknDlRTfI7rKMcuEfkf604DQClnmDqSn9nS7M2zQcJNi2rF0cxw= Received: by 10.70.21.8 with SMTP id 8mr2611491wxu.1176964140488; Wed, 18 Apr 2007 23:29:00 -0700 (PDT) Received: by 10.100.189.14 with HTTP; Wed, 18 Apr 2007 23:29:00 -0700 (PDT) Message-ID: <458913680704182329i56c1277vc6027fd4d83952a3@mail.gmail.com> Date: Thu, 19 Apr 2007 08:29:00 +0200 From: "Xavier Marjou" To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 3ed08e9732867b74 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Here are some comments: Title: - Replace "Methodology" by "Protocol", since "protocol" is used in introduction. Section 5.7.3 "Pruning the Pairs" - Why is a local relayed candidate not also replaced by its base, as well as for a local reflexive candidate? Section 7.2 "Server Procedures" - What happens if the credential is unknown? Is the request silently discarded? Section 12.1.1 "Offer in INVITE": - My opinion is to keep a single one with RFC3262 and not to add a 2nd mechanism for doing it. - Typo: replace "3264" by "3262", "th exponential" by "the exponential", and "transmission of a 2XX response" by "transmission of the answer in a 2XX response". Other: - Replace 3 instances of "offeror" by "offerer" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 07:05:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeURj-0000DG-M2; Thu, 19 Apr 2007 07:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeURh-0000D7-Q8 for mmusic@ietf.org; Thu, 19 Apr 2007 07:05:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeURg-0005I3-3y for mmusic@ietf.org; Thu, 19 Apr 2007 07:05:01 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8134520A80; Thu, 19 Apr 2007 13:04:59 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-f7-46274cdbeb1c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7096D20989; Thu, 19 Apr 2007 13:04:59 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 13:04:59 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 13:04:59 +0200 Message-ID: <46274CDB.70500@ericsson.com> Date: Thu, 19 Apr 2007 13:04:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jamie Gordon Subject: Re: [MMUSIC] RTSP/2.0 RTP-Info changes (draft-ietf-mmusic-rfc2326bis-14.txt) References: <46263E72.20405@real.com> In-Reply-To: <46263E72.20405@real.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 11:04:59.0232 (UTC) FILETIME=[9218A600:01C78272] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jamie Gordon skrev: > I have some concerns about the changes made to the syntax of RTP-Info > in the RTSP 2.0 draft. In RTSP/1.0 it is a simple standard semi-colon > separated list of values concerning the identified URL parameter. The > newer draft changes it considerably, and I do not see any reason given > or examples illustrating the need. > > Since it is far more complex, requires very specific parsers, and > completely separate code path (in case of a server supporting both 1.0 > and 2.0, which one would assume will be rather common if 2.0 is to take > hold), I would like to understand the reasoning for this change, and > whether there is a simpler alternative. > Hi Jamie, The problem with the RTSP 1.0 RTP-Info header is that it doesn't indicate at all for which SSRC the information applies. Thus to address this and allow for synchronization information from multiple SSRCs in an RTP session the syntax format in the draft was specified. This as we need scoping in the following way. For each media stream (identified by URL) there can be multiple SSRCs and for each SSRC there can be multiple different parts of synchronization information. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 07:11:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUXj-0006m5-LM; Thu, 19 Apr 2007 07:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeUXi-0006lp-DH for mmusic@ietf.org; Thu, 19 Apr 2007 07:11:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeUXf-0000E4-M2 for mmusic@ietf.org; Thu, 19 Apr 2007 07:11:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0D8C2204C8; Thu, 19 Apr 2007 13:11:11 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-31-46274e4eade5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E8B8D20100; Thu, 19 Apr 2007 13:11:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 13:11:10 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 13:11:10 +0200 Message-ID: <46274E4E.7020201@ericsson.com> Date: Thu, 19 Apr 2007 13:11:10 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alan Johnston Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> In-Reply-To: <46265C9D.4050609@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 11:11:10.0481 (UTC) FILETIME=[6F60C010:01C78273] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Dan Wing , 'Lars Eggert' , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Alan Johnston skrev: > Do we have any running code and actual deployment experience here? > A very good question. And I am also interested in real-world experience. But stating that it works is not sufficient as I am convinced that ICE will end up finding the cases that works eventually. However in a number of cases it might be after having first induced congestion and the checks that gets through are the ones that are in later when the exponential retransmission back-off has reduced the load below the congestion threshold. > If not, I'd suggest adding further congestion avoidance in ICE would > likely only have the effect of increasing the time taken to complete > connectivity checks. This could be a significant problem for ICE in the > real world. > I have no doubts that this is a difficult problem with very contradicting requirements. 1. One wants the checks to complete as quickly as possible. 2. While doing that do not congest the network. However I think you might be a bit short sighted if you at least do not acknowledge that in cases where the connectivity checks do result in congestion loss you are actually delaying the completion of the checks. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 08:46:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeW1V-0006YU-K6; Thu, 19 Apr 2007 08:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeW1U-0006YO-Rj for mmusic@ietf.org; Thu, 19 Apr 2007 08:46:04 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeW1Q-0000t8-H4 for mmusic@ietf.org; Thu, 19 Apr 2007 08:46:04 -0400 Received: from [61.94.220.152] (unknown [61.94.220.152]) by smtp.mxes.net (Postfix) with ESMTP id 819B65191A; Thu, 19 Apr 2007 08:45:55 -0400 (EDT) Message-ID: <46276414.7050703@pjsip.org> Date: Thu, 19 Apr 2007 13:44:04 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> In-Reply-To: <46274E4E.7020201@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Alan Johnston , 'Lars Eggert' , Dan Wing , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Magnus Westerlund wrote: > Alan Johnston skrev: >> Do we have any running code and actual deployment experience here? >> > > A very good question. And I am also interested in real-world experience. In my experience, live testing results have been good, ICE does work as it says in the tin and the process completes quickly (thanks to triggered check). But what has it got to do with the topic here? IMO congestion would depend on the number of connectivity checks to be performed, and therefore the number of candidates that agents put in SDP. If we keep the number of candidates low, I believe should be fine. Lets consider an example. Suppose two agents are running similar configuration. Each agent only has one component (RTP only), and each component has three candidates (two multihomed interface and one server mapped). This is a fair example, IMO. Each agent will end up having six connectivity checks to perform, and they will be performed according to these schedule (using Ta=20 ms): Time period Number of STUN packets --------------------------------------------------- 0.000 - 0.200 12 (avg= 1 packet every ~20 ms) 0.300 - 0.400 6 (avg= 1 packet every 20 ms) 0.700 - 0.800 6 1.500 - 1.600 6 3.100 - 3.200 6 etc.. (according to STUN retransmission rule) I think that's acceptable. Now add RTCP, and the number of checks is doubled (twelve), and the checks will be scheduled like these: Time period Number of STUN packets -------------------------------------- 0.000 - 0.520 36 0.700 - 0.920 12 1.500 - 1.720 12 3.100 - 3.320 12 etc.. (according to STUN retransmission rule) Drilling down what's happening in t=0 - t=0.520, we'll see that packets are transmitted like this: Time Nb of packet transmitted at this time and total number of packets transmitted so far ---------------------------------------------------------------- 00.000 1 (total=1) 00.020 1 (total=2) 00.040 1 (total=3) 00.060 1 (total=4) 00.080 1 (total=5) 00.100 2 (total=7) 00.120 2 (total=9) 00.140 2 (total=11) 00.160 2 (total=13) 00.180 2 (total=15) 00.200 2 (total=17) 00.220 2 (total=19) 00.240 1 (total=20) 00.260 1 (total=21) 00.280 1 (total=22) 00.300 2 (total=24) 00.320 2 (total=26) 00.340 1 (total=27) 00.360 1 (total=28) 00.380 1 (total=29) 00.400 1 (total=30) 00.420 1 (total=31) 00.440 1 (total=32) 00.460 1 (total=33) 00.480 1 (total=34) 00.500 1 (total=35) 00.520 1 (total=36) Granted that the numbers look less amusing now, and this probably qualifies as congestion situation, but looking at the brighter side, at least it's only happening for the first 520 msec; subsequent burst of 12 packets (paced at Ta=20ms) will happen at STUN retransmit time (t=700, t=1500, t=3100, etc). I wouldn't like putting any congestion avoidance mechanism in ICE (and btw, how?). ICE as now is complicated already; adding more rules will just make it more difficult to implement and make it less attractive. What about "if you're worried about congestion, then keep the number of candidates low" kind of approach? cheers, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 09:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWsI-00009O-VW; Thu, 19 Apr 2007 09:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWsI-00009J-68 for mmusic@ietf.org; Thu, 19 Apr 2007 09:40:38 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWsF-0002Ih-El for mmusic@ietf.org; Thu, 19 Apr 2007 09:40:38 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A7FD42055D; Thu, 19 Apr 2007 15:40:01 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-fd-46277131508c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C1182053D; Thu, 19 Apr 2007 15:40:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:40:01 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:40:01 +0200 Message-ID: <46277130.5000804@ericsson.com> Date: Thu, 19 Apr 2007 15:40:00 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Lars Eggert Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 13:40:01.0086 (UTC) FILETIME=[3A6EEDE0:01C78288] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Alan Johnston , mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Lars Eggert skrev: > Sounds like a good suggestion, but doesn't really help, because an end > should always be worried about congestion, it's unclear what "low" > means, and what do you do if "1" isn't low enough, since a single > connectivity check can eat 180Kb/s? > The figure for 180 kbps was to my understanding the aggregated worst case bit-rate for 50 checks all failing to get any response. However which time scale that is measured over I don't know. It comes from the security consideration section in the ICE draft: 17.4.2. STUN Amplification Attack The STUN amplification attack is similar to the voice hammer. However, instead of voice packets being directed to the target, STUN connectivity checks are directed to the target. The attacker sends an offer with a large number of candidates, say 50. The answerer receives the offer, and starts its checks, which are directed at the target, and consequently, never generate a response. The answerer will start a new connectivity check every 20ms, and each check is a STUN transaction consisting of 7 transmissions of a message 65 bytes in length (plus 28 bytes for the IP/UDP header) that runs for 7.9 seconds, for a total of 58 bytes/second per transaction on average. In the worst case, there can be 395 transactions in progress at once (7.9 seconds divided by 20ms), for a total of 182 kbps, just for STUN requests. It is impossible to eliminate the amplification, but the volume can be reduced through a variety of heuristics. Agents SHOULD limit the total number of connectivity checks they perform to 100. Additionally, agents MAY limit the number of candidates they'll accept in an offer or answer. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 09:43:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWus-0002VN-BX; Thu, 19 Apr 2007 09:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWuq-0002Uw-F9 for mmusic@ietf.org; Thu, 19 Apr 2007 09:43:16 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWum-0002qn-6a for mmusic@ietf.org; Thu, 19 Apr 2007 09:43:16 -0400 Received: from [61.94.220.152] (unknown [61.94.220.152]) by smtp.mxes.net (Postfix) with ESMTP id 4E94151944; Thu, 19 Apr 2007 09:43:07 -0400 (EDT) Message-ID: <462771F1.9010302@pjsip.org> Date: Thu, 19 Apr 2007 14:43:13 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Lars Eggert Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Magnus Westerlund , Alan Johnston , mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Lars Eggert wrote: > Since you seem to have a simulation setup ready to go, can you pick a > suitably interesting bandwidth limit, add some TCP connections to your > experiment and see what happens to them when the ICE connectivity checks > fire? Nah, I don't have simulation setup whatsoever. The time schedules were generated by this silly program: http://www.pjsip.org/tmp/icecount.c It just prints out _when_ STUN Binding requests will be sent according to the number of connectivity checks to be performed. > If ICE ends up significantly ipacting concurrent flows, that'd really > make it unattractive. (And I'm not saying it necessarily will, but it is > important to investigate this.) But that won't happen if you keep the candidate number low! >> What about "if you're worried about congestion, then keep the number >> of candidates low" kind of approach? > > Sounds like a good suggestion, but doesn't really help, because an end > should always be worried about congestion, it's unclear what "low" > means, and what do you do if "1" isn't low enough, since a single > connectivity check can eat 180Kb/s? No, that's not true. A single connectivity check in one agent consists of sending STUN Binding request, and retransmitting it according to STUN rule until a response is received, or the STUN transaction has timed out. In my application, a STUN Binding request is approx 108 bytes long, and a response is about the same. Since STUN is (re)transmitted at t=0, t=100, t=300, t=700, t=1500, t=3100, etc., that gives the bandwidth (for each connectivity check): for t=0s to t=1s: 4x108 == 432 bytes/s == 3.4 Kbps for t=1s to t=2s: 108 bytes/s == 0.8 Kbps for t=2s to t=3s: 0 Kbps for t=3s to t=4s: 0.8 Kbps again. It's the first one second that takes the most bandwidth, but then again it's not as much as what you quoted, and it will only take that amount if connectivity checks failed and the STUN requests get retransmitted. In my ADSL to ADSL test, the whole ICE can complete in between 100 to 200 ms, so in this case there should be less bandwidth taken. > ICE can be a really powerful tool, but it does need to play nice with > other traffic in the Internet. True. cheers, -benny > Lars > > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 09:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWzc-0000BH-V7; Thu, 19 Apr 2007 09:48:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWzb-0000Ax-Gh for mmusic@ietf.org; Thu, 19 Apr 2007 09:48:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWza-0003Qj-RI for mmusic@ietf.org; Thu, 19 Apr 2007 09:48:11 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5019C20AB7; Thu, 19 Apr 2007 15:48:10 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-4c-4627731ac6e8 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 27C5C20A8C; Thu, 19 Apr 2007 15:48:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:48:09 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:48:09 +0200 Message-ID: <46277319.4050101@ericsson.com> Date: Thu, 19 Apr 2007 15:48:09 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Benny Prijono Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> In-Reply-To: <46276414.7050703@pjsip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2007 13:48:09.0390 (UTC) FILETIME=[5D7C34E0:01C78289] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Alan Johnston , 'Lars Eggert' , Dan Wing , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Many thanks Benny for the good illustration of how things happen. I think one of the major problems with ICE currently is how the relatively short Ta quickly builds up the number of packets sent. If one increases Ta to the double you get a longer but less quickly growing burst. This is still quite aggressive. It actually sends more packets than most speech codecs does during half a second averaged out. And the worst part is from 300 ms until 460 ms into the transfer for Ta=40 ms where 75 packets per second are sent. The Ta=20 ms has its worst part at 100 to 200 ms when it runs along at a whooping 100 packets per second. Compare the left using Ta=40 and the right columns using Ta=20. 00.000 1 (total=1) 00.000 1 (total=1) 00.020 0 00.020 1 (total=2) 00.040 1 (total=2) 00.040 1 (total=3) 00.060 0 00.060 1 (total=4) 00.080 1 (total=3) 00.080 1 (total=5) 00.100 1 (total=4) 00.100 2 (total=7) 00.120 1 (total=5) 00.120 2 (total=9) 00.140 1 (total=6) 00.140 2 (total=11) 00.160 1 (total=7) 00.160 2 (total=13) 00.180 1 (total=8) 00.180 2 (total=15) 00.200 1 (total=9) 00.200 2 (total=17) 00.220 1 (total=10) 00.220 2 (total=19) 00.240 1 (total=11) 00.240 1 (total=20) 00.260 1 (total=12) 00.260 1 (total=21) 00.280 1 (total=13) 00.280 1 (total=22) 00.300 2 (total=15) 00.300 2 (total=24) 00.320 1 (total=16) 00.320 2 (total=26) 00.340 2 (total=18) 00.340 1 (total=27) 00.360 1 (total=19) 00.360 1 (total=28) 00.380 2 (total=21) 00.380 1 (total=29) 00.400 1 (total=22) 00.400 1 (total=30) 00.420 2 (total=24) 00.420 1 (total=31) 00.440 1 (total=25) 00.440 1 (total=32) 00.460 2 (total=27) 00.460 1 (total=33) 00.480 0 (total=27) 00.480 1 (total=34) 00.500 2 (total=29) 00.500 1 (total=35) 00.520 0 (total=29) 00.520 1 (total=36) 00.540 1 (total=30) What actually is interesting in this situation is if you actually need to be this quick at all. The above performs 12 connectivity checks. With Ta=40 it takes until 440 ms until all checks has been sent at least once. At that point 4 of the checks has been retransmitted twice and 5 more has been retransmitted once. So if you have prioritized right and have a reasonable RTT your checks may have completed for the most interesting base pairs. Allowing one to start unfreeze checks for other components and medias and then actually prioritize them over other checks. What I going for is what we need is to see how the distribution for completion times actually varies with different policies and values. Something that isn't really considered in the above is that some checks actually get responded to. And then stops retransmitting, that way reducing the number of packets being sent. That is one thing that make me want to introduce something like a token bucket rate limiter for transmission in general, delaying both new checks and retransmissions if need to keep a reasonable rate. I think one token bucket per local interface would make sense. The only issue with this would be multihomed hosts. cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 11:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYii-0003k5-VH; Thu, 19 Apr 2007 11:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXEp-0002uO-58 for mmusic@ietf.org; Thu, 19 Apr 2007 10:03:55 -0400 Received: from nucleon.liquidweb.com ([64.91.224.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXEm-0006NV-Tp for mmusic@ietf.org; Thu, 19 Apr 2007 10:03:55 -0400 Received: from c-69-136-253-7.hsd1.de.comcast.net ([69.136.253.7]:24513 helo=Oana2) by nucleon.liquidweb.com with esmtpa (Exim 4.52) id 1HeXEe-0003kh-6N for mmusic@ietf.org; Thu, 19 Apr 2007 10:03:44 -0400 Message-ID: <15093250.1176991437875.JavaMail.Onitza@Oana2> Date: Thu, 19 Apr 2007 10:03:57 -0400 (EDT) From: IARIA Invitation To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nucleon.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iaria.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Thu, 19 Apr 2007 11:38:50 -0400 Subject: [MMUSIC] UBICOMM 2007 || SEMAPRO 2007 || ADVCOMP 2007 || (November 4-9, 2007 - Papeete) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS Submission deadline: May 15, 2007 Conference date:: November 4-9, 2007 - Papeete, French Polynesia (Tahiti) UBICOMM 2007: International Conference on Mobile Ubiquitous Computing, Systems, Services, and Technologies Site: http://www.iaria.org/conferences2007/UBICOMM07.html Call: http://www.iaria.org/conferences2007/CfPUBICOMM07.html SEMAPRO 2007: International Conference on Advances in Semantic Processing Site: http://www.iaria.org/conferences2007/SEMAPRO07.html Call: http://www.iaria.org/conferences2007/CfPSEMAPRO07.html ADVCOMP 2007: The International Conference on Advanced Engineering Computing and Applications in Sciences Site: http://www.iaria.org/conferences2007/ADVCOMP07.html Call: http://www.iaria.org/conferences2007/CfPADVCOMP07.html ============ To be removed from this announcement list, please reply with UNSUBSCRIBE in the subject field. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 11:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYii-0003jY-Cz; Thu, 19 Apr 2007 11:38:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeVNS-0001Xt-G2 for mmusic@ietf.org; Thu, 19 Apr 2007 08:04:42 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeVNR-0002j2-Vb for mmusic@ietf.org; Thu, 19 Apr 2007 08:04:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JC4W9E010744; Thu, 19 Apr 2007 15:04:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:04:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:04:08 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 15:04:08 +0300 Received: from [172.21.35.232] (esdhcp035232.research.nokia.com [172.21.35.232]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JC4655021982; Thu, 19 Apr 2007 15:04:06 +0300 In-Reply-To: <46274E4E.7020201@ericsson.com> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14623339-B0FF-46DA-9B89-60C779490684@nokia.com> Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Thu, 19 Apr 2007 15:03:51 +0300 To: ext Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Apr 2007 12:04:08.0205 (UTC) FILETIME=[D572F3D0:01C7827A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070419150435-2758ABB0-77EEC6F4/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Thu, 19 Apr 2007 11:38:50 -0400 Cc: Alan Johnston , mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 2007-4-19, at 14:11, ext Magnus Westerlund wrote: >> If not, I'd suggest adding further congestion avoidance in ICE >> would likely only have the effect of increasing the time taken to >> complete connectivity checks. This could be a significant problem >> for ICE in the real world. > > I have no doubts that this is a difficult problem with very > contradicting requirements. 1. One wants the checks to complete as > quickly as possible. 2. While doing that do not congest the network. > > However I think you might be a bit short sighted if you at least do > not acknowledge that in cases where the connectivity checks do > result in congestion loss you are actually delaying the completion > of the checks. I agree. One issue is that the bandwidth use of ICE could interfere with its own efficient operation in bandwidth-limited scenarios. RFC2914 (the current BCP for congestion control principles) identifies two additional concerns: (1) whether a protocol can cause congestion collapse and (2) whether it is able to reasonably fairly share path capacity with concurrent traffic. For the health of the Internet, those are both critical questions to answer for any new protocol. (1) typically involves having a mechanism that causes a reduction in bandwidth use when congestion occurs, and does so on reasonable timescales. I haven't read the whole ICE draft yet, but a quick look tells me that something along those lines is in the specification, which is promising. (2) is usually the harder question to answer. Has there been any experimentation with ICE in bandwidth-constrained scenarios and with concurrent flows? From what Magnus has written, ICE can generate up to 180Kb/s of traffic, which far exceeds modem speeds and approaches the typical uplink capacity of some "broadband" offers, so I'd like to stress that finding out how ICE behaves in such cases (especially if it shares capacity with other flows) seems vital. Lars _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 11:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYij-0003kL-8B; Thu, 19 Apr 2007 11:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXNz-00026x-Uw for mmusic@ietf.org; Thu, 19 Apr 2007 10:13:23 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXNy-0007fa-FJ for mmusic@ietf.org; Thu, 19 Apr 2007 10:13:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JECqjJ000715; Thu, 19 Apr 2007 17:13:16 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:13:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:13:04 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:13:03 +0300 Received: from [172.21.35.232] (esdhcp035232.research.nokia.com [172.21.35.232]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JED1Ou000388; Thu, 19 Apr 2007 17:13:01 +0300 In-Reply-To: <462771F1.9010302@pjsip.org> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <462771F1.9010302@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A694ED1-C291-45F6-A883-504A65AE1808@nokia.com> Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: ICE pacing connectivity checks (was RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Thu, 19 Apr 2007 17:12:46 +0300 To: ext Benny Prijono X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Apr 2007 14:13:03.0859 (UTC) FILETIME=[D8421430:01C7828C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070419171317-027FDBB0-668357E0/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Thu, 19 Apr 2007 11:38:50 -0400 Cc: Magnus Westerlund , Alan Johnston , mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, On 2007-4-19, at 16:43, ext Benny Prijono wrote: > No, that's not true. > > A single connectivity check in one agent consists of sending STUN > Binding request, and retransmitting it according to STUN rule until > a response is received, or the STUN transaction has timed out. ... Ah. I obviously misunderstood things, and will shut up until I have actually read the whole draft - apologies. Lars _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 11:49:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYtR-0006zs-JR; Thu, 19 Apr 2007 11:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYtQ-0006zn-Do for mmusic@ietf.org; Thu, 19 Apr 2007 11:49:56 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYtM-0006ck-5L for mmusic@ietf.org; Thu, 19 Apr 2007 11:49:56 -0400 Received: from [61.94.220.232] (unknown [61.94.220.232]) by smtp.mxes.net (Postfix) with ESMTP id 83F605191A; Thu, 19 Apr 2007 11:49:48 -0400 (EDT) Message-ID: <46278FA2.2010709@pjsip.org> Date: Thu, 19 Apr 2007 16:49:54 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Magnus Westerlund References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> In-Reply-To: <46277319.4050101@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Alan Johnston , 'Lars Eggert' , Dan Wing , mmusic@ietf.org Subject: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Magnus Westerlund wrote: > Many thanks Benny for the good illustration of how things happen. And thanks for providing the analytical comments. I didn't bother since I've never been too good with numbers. ..snip.. > Something that isn't really considered in the above is that some checks > actually get responded to. And then stops retransmitting, that way > reducing the number of packets being sent. That is one thing that make > me want to introduce something like a token bucket rate limiter for > transmission in general, delaying both new checks and retransmissions if > need to keep a reasonable rate. I think one token bucket per local > interface would make sense. The only issue with this would be multihomed > hosts. That's one solution alright, although we still need to analyze the bucket limiter impact to ICE performance (it would slow it down I suspect). I have different solution, and mine is directed towards reducing the number of checks. And I believe this one not only help congestion problem, but it could also ICE performance significantly. The idea is to use one socket for all candidates in one component. During pruning process, we know that srflx candidate will be pruned and be replaced by its base candidate. But since we use one socket for all candidates, the host candidates can be pruned as well, leaving just one host candidate in the check list for the component (note: this currently is not in ICE). If an agent is using this approach (and assuming only host and srflx candidates are used), the number of checks that the agent performs would be M for each component, where M is the number of candidates in that component in the remote agent. Compare this to current ICE where the number of checks will be "(N-1) x M" (the N-1 reflects the pruning of srflx candidate). I think this could work (would be interested to hear Jonathan's comment on this). Unfortunately it seems that the use of one socket per component has been deprecated long ago and it would be quite a big editing work to adapt the text this way. But I've been using one socket approach and it seems to work. cheers, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 12:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZFo-0007YV-Ju; Thu, 19 Apr 2007 12:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZFm-0007Y4-GL for mmusic@ietf.org; Thu, 19 Apr 2007 12:13:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZFl-0004la-7K for mmusic@ietf.org; Thu, 19 Apr 2007 12:13:02 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 19 Apr 2007 09:13:00 -0700 X-IronPort-AV: i="4.14,428,1170662400"; d="scan'208"; a="54658943:sNHT44712675" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3JGD0Ra010647; Thu, 19 Apr 2007 09:13:00 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3JGCxwn010687; Thu, 19 Apr 2007 16:13:00 GMT From: "Dan Wing" To: "'Lars Eggert'" , "'Magnus Westerlund'" Subject: RE: ICE pacing connectivity checks (was RE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Thu, 19 Apr 2007 09:12:59 -0700 Message-ID: <00e201c7829d$99cf1430$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <14623339-B0FF-46DA-9B89-60C779490684@nokia.com> Thread-Index: AceCmOYTyAWMEsXOTcySp9+m8ZV0YgAAdgbg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=956; t=1176999180; x=1177863180; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20ICE=20pacing=20connectivity=20checks=20(was=20RE=3A[M MUSIC]=09WGLC=3A=09draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=MiqLus3S96ilFysWaQe/zxE1sRYAoj91A1PpPDetuOA=; b=MaWJC5CNUgYlqgL7qD8BycjsIqYF+eGAdddsY2ukpakBk6Tiq7SpJF2EpPd4akpUsJIqzlzb bTRcUQ3PASN++YI0TkEEEDuODMjW/Aasa3V1MTQ34Z8B1hgkO/wYLjet; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I have created an Excel spreadsheet analyzing ICE's behavior compared to RTP's behavior. I am tweaking this spreadsheet and expect it to be useful in helping us tune ICE's algorithms. I want to make this a more useful spreadsheet before sharing it; it doesn't quite do everything I like yet. I expect it will remain awkward to use, as I'm not an excel wizard. In my initial analysis using this spreadsheet, I do agree that ICE's default 20ms pacing and STUN's default 100ms retransmit timers are too aggressive if we assume severely bandwidth-constrained links. I expect that adjusting these values based on the ptime, RTP packet size, STUN Request packet size, and number of candidates will result in ICE behaving as well as RTP (with RTCP feedback) in all cases, and better than RTP (with RTCP feedback) in some cases. The drawback of such tuning, however, is that ICE will take longer to complete if there are many candidates. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 12:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZXk-0002eb-KI; Thu, 19 Apr 2007 12:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZXj-0002e3-II for mmusic@ietf.org; Thu, 19 Apr 2007 12:31:35 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZXf-0001zU-80 for mmusic@ietf.org; Thu, 19 Apr 2007 12:31:35 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3JGVQCT000374; Thu, 19 Apr 2007 12:31:27 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l3JGVOse031421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 12:31:26 -0400 In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C63A85@srvxchg3.cablelabs.com> References: <1ECE0EB50388174790F9694F77522CCF10170FF5@zrc2hxm0.corp.nortel.com> <9AAEDF491EF7CA48AB587781B8F5D7C63A85@srvxchg3.cablelabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <742F291C-FC47-4434-95DA-7748167CEF3A@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Thu, 19 Apr 2007 12:31:28 -0400 To: Kevin Johns X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org [trimming the CC list] On 19-Apr-07, at 01:04 , Kevin Johns wrote: > > Can someone clarify the intent of the text in section 4.2 and > whether an > ice-lite implementation can include multiple candidates for a single > component? If multiple candidates are allowed then what Francois is > proposing seems reasonable (along with some text clean up in > section 4.2 > of ICE). > I was also confused by this, since it is my understanding that a "lite" implementation can currently advertise only one candidate per media stream. However, I don't see any solid reason for this limitation. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 19 14:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heb2X-0001QN-PL; Thu, 19 Apr 2007 14:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heb2V-0001Pg-Vt for mmusic@ietf.org; Thu, 19 Apr 2007 14:07:27 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heb2U-0004bp-Jw for mmusic@ietf.org; Thu, 19 Apr 2007 14:07:27 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3JI7OpD009454; Thu, 19 Apr 2007 12:07:24 -0600 (MDT) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 19 Apr 2007 12:07:24 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Apr 2007 12:07:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Thu, 19 Apr 2007 12:07:23 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C63B1A@srvxchg3.cablelabs.com> In-Reply-To: <742F291C-FC47-4434-95DA-7748167CEF3A@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Thread-Index: AceCoC9JXrwoHi7FT0mxqWhxn4ZnXgADPMsA References: <1ECE0EB50388174790F9694F77522CCF10170FF5@zrc2hxm0.corp.nortel.com> <9AAEDF491EF7CA48AB587781B8F5D7C63A85@srvxchg3.cablelabs.com> <742F291C-FC47-4434-95DA-7748167CEF3A@magma.ca> From: "Kevin Johns" To: "Philip Matthews" X-OriginalArrivalTime: 19 Apr 2007 18:07:23.0757 (UTC) FILETIME=[949C41D0:01C782AD] X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Philip, Thinking about it some more, the issue with having multiple candidates in the lite implementation is when you hit two lite implementations, the non-default candidate is ignored forcing the use of the default candidate. Jonathan provided some further context to this issue in his email to the list on 4/9 subject Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Kevin -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Thursday, April 19, 2007 10:31 AM To: Kevin Johns Cc: mmusic@ietf.org; Jonathan Rosenberg Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt [trimming the CC list] On 19-Apr-07, at 01:04 , Kevin Johns wrote: > > Can someone clarify the intent of the text in section 4.2 and whether=20 > an ice-lite implementation can include multiple candidates for a=20 > single component? If multiple candidates are allowed then what=20 > Francois is proposing seems reasonable (along with some text clean up=20 > in section 4.2 of ICE). > I was also confused by this, since it is my understanding that a "lite" implementation can currently advertise only one candidate per media stream. =20 However, I don't see any solid reason for this limitation. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 20 00:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hekff-0005Ld-JB; Fri, 20 Apr 2007 00:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hekfd-0005LV-QO for mmusic@ietf.org; Fri, 20 Apr 2007 00:24:29 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hekfd-0000KT-8p for mmusic@ietf.org; Fri, 20 Apr 2007 00:24:29 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3K4OSr8007880 for ; Thu, 19 Apr 2007 22:24:28 -0600 (MDT) Received: from srvxchg.cablelabs.com (10.5.0.20) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 19 Apr 2007 22:24:27 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) Received: from srvxchg3.cablelabs.com ([10.5.0.25]) by srvxchg.cablelabs.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Apr 2007 22:24:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Apr 2007 22:24:21 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6045F90@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-15 WGLC Comments Thread-Index: AceDA8T3EXEfATl9RC+Lukxe/6pZ6g== From: "Kevin Johns" To: X-OriginalArrivalTime: 20 Apr 2007 04:24:27.0507 (UTC) FILETIME=[C87C2C30:01C78303] X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Subject: [MMUSIC] ICE-15 WGLC Comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1189452892==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1189452892== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78303.C8813D8C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78303.C8813D8C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jonathan, =20 Please find my comments on ICE-15 below for your consideration. I tried to avoid nit picking, hopefully I was successful. I did not include any editorial issues I found (spaces in the middle of words, missing closing parenthesis, etc.) as I figure those will be caught by the editor before publication. If you want them I will gladly forward. =20 Let me know if you have any questions. =20 Kevin =20 =20 Section 2.4 (Frozen Candidate) 1st paragraph, 1st sentence at the end of the parenthetical statement - 'each of which has to work for the media stream as a whole to be work' I think 'be' should be deleted =20 Section 4.2 (Lite Implementation) Per my previous email this section is unclear as to whether a lite implementation can include multiple candidates. Given my understanding that it cannot, I think removing the first sentence of the last paragraph would help clarify the section. =20 Section 5.7.2 Computing Pair Priority and Ordering Pairs The formula ends with (O>A?1:0) but the text after the formula defines it as (O-P>A-P?1:0). The formula should probably be updated to align with the textual description. =20 Also, given the procedures in section 5.8 (performing periodic checks) rely on the pair priority to determine the next pair to unfreeze are we sure that the pair priority will results in pairs with the lower component ID being checked first? Meaning if we have two component IDs we want to check all the pairs for component ID 1 first before starting any checks for component ID 2 pairs in order to get the optimizations ICE provides by using the info learned from component ID 1 to quickly find the best valid pair for component ID 2. =20 Section 5.7.4 (computing states) 2nd paragraph after step 2 indicates there are two states but three are actually defined (running, completed, and failed). =20 Sections 7.1.1.1 (PRIORITY and USE-CANDIDATE) and 7.1.1.2 (ICE-CONTROLLED AND ICE-CONTROLLING) Both sections discuss the ICE defined STUN attributes. It would be helpful to provide a reference back to their respective sections where they are defined (18.5) =20 Section 8.1.1 (Regular Nomination) The 2nd paragraph discusses repeating the check with the USE-CANDIDATE flag set. There is no discussion as to how the agent behaves if this check is lost for some reason. While unlikely, it is possible that this check could be lost in the network and would need to be retransmitted. It might be worth while to provide some guidance on this scenario. =20 I read section 9.2.1.1 (detecting ICE restarts) and 9.2.2 (procedures for full implementations) to be contradictory. 9.2.1.1 states that if ICE is restarting for a media stream the agent MUST change the a=3Dice-ufrag and a=3Dice-pwd attributes in the answer. However, 9.2.2 states the username fragments, password, and implementation level MUST remain the same as previously. If an agent needs to change one of these it MUST restart ICE for that media stream by generating an offer; ICE cannot be restarted in an answer. I am I miss-reading these two sub-sections?=20 =20 Section 12.1.1 (offer in INVITE) The 2nd paragraph discusses a mechanism for ensuring reliable delivery of a response. However, if the target of the response is an ICE-lite implementation it will never send a stun request and the agent is forced to keep retransmitting its response needlessly. Would it make sense to call this out, or let it be as it will resolve once the agent sends the 200 OK? =20 =20 ------_=_NextPart_001_01C78303.C8813D8C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jonathan,
 
Please = find my=20 comments on ICE-15 below for your consideration. I tried to avoid nit = picking,=20 hopefully I was successful. I did not include any editorial issues I = found=20 (spaces in the middle of words, missing closing parenthesis, etc.) as I = figure=20 those will be caught by the editor before publication. If you want them = I will=20 gladly forward.
 
Let me = know if you=20 have any questions.
 
Kevin
 
 

Section 2.4 (Frozen=20 Candidate)

1st = paragraph,=20 1st sentence at the end of the parenthetical statement = – 'each of=20 which has to work for the media stream as a whole to be work' I think = 'be'=20 should be deleted

 

Section 4.2 (Lite=20 Implementation)

Per my previous email = this=20 section is unclear as to whether a lite implementation can include = multiple=20 candidates. Given my = understanding=20 that it cannot, I think removing the first sentence of the last = paragraph would=20 help clarify the section.

 

Section 5.7.2 = Computing Pair=20 Priority and Ordering Pairs

The formula ends with = (O>A?1:0) but the text after the formula defines it as = (O-P>A-P?1:0). The=20 formula should probably be updated to align with the textual = description.

 

Also, given the = procedures in=20 section 5.8 (performing periodic checks) rely on the pair priority to = determine=20 the next pair to unfreeze are we sure that the pair priority will = results in=20 pairs with the lower component ID being checked first? Meaning if we = have two=20 component IDs we want to check all the pairs for component ID 1 first = before=20 starting any checks for component ID 2 pairs in order to get the = optimizations=20 ICE provides by using the info learned from component ID 1 to quickly = find the=20 best valid pair for component ID 2.

 

Section 5.7.4 = (computing=20 states)

2nd = paragraph after=20 step 2 indicates there are two states but three are actually defined = (running,=20 completed, and failed).

 

Sections 7.1.1.1 = (PRIORITY and=20 USE-CANDIDATE) and 7.1.1.2 (ICE-CONTROLLED AND ICE-CONTROLLING)

Both sections discuss = the ICE=20 defined STUN attributes. It would be helpful to provide a reference back = to=20 their respective sections where they are defined (18.5)

 

Section 8.1.1 = (Regular=20 Nomination)

The 2nd = paragraph=20 discusses repeating the check with the USE-CANDIDATE flag set. There is = no=20 discussion as to how the agent behaves if this check is lost for some = reason.=20 While unlikely, it is possible that this check could be lost in the = network and=20 would need to be retransmitted. It might be worth while to provide some = guidance=20 on this scenario.

 

I read section = 9.2.1.1 (detecting=20 ICE restarts) and 9.2.2 (procedures for full implementations) to be=20 contradictory. 9.2.1.1 states that if ICE is restarting for a media = stream the=20 agent MUST change the a=3Dice-ufrag and a=3Dice-pwd attributes in the = answer.=20 However, 9.2.2 states the username fragments, password, and = implementation level=20 MUST remain the same as previously. If an agent needs to change one of = these it=20 MUST restart ICE for that media stream by generating an offer; ICE = cannot be=20 restarted in an answer. I am I miss-reading these two sub-sections?

 

Section 12.1.1 (offer = in=20 INVITE)

The 2nd = paragraph=20 discusses a mechanism for ensuring reliable delivery of a response. = However, if=20 the target of the response is an ICE-lite implementation it will never = send a=20 stun request and the agent is forced to keep retransmitting its response = needlessly. Would it make sense to call this out, or let it be as it = will=20 resolve once the agent sends the 200 OK?

 

 

------_=_NextPart_001_01C78303.C8813D8C-- --===============1189452892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1189452892==-- From mmusic-bounces@ietf.org Fri Apr 20 04:09:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeoBM-0006xp-Cq; Fri, 20 Apr 2007 04:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeoBK-0006xc-Cd for mmusic@ietf.org; Fri, 20 Apr 2007 04:09:26 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeoBJ-0007a6-RX for mmusic@ietf.org; Fri, 20 Apr 2007 04:09:26 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JGS00DBTENIVZ@siemenscomms.co.uk> for mmusic@ietf.org; Fri, 20 Apr 2007 09:09:19 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <202YSBNF>; Fri, 20 Apr 2007 09:09:23 +0100 Content-return: allowed Date: Fri, 20 Apr 2007 09:09:13 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt To: Francois Audet , Jean-Francois Mule , mmusic@ietf.org, Jonathan Rosenberg Message-id: <50B1CBA96870A34799A506B2313F26670B9C9959@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Colin Perkins , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Francois, I think something along these lines would be useful, but see comments below. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 18 April 2007 23:03 > To: Jean-Francois Mule; mmusic@ietf.org; Jonathan Rosenberg > Cc: Colin Perkins; Joerg Ott > Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > Importance: High > > My comments for WGLC are included below: > > In order to be able to use ICE as the mechanism for supporting a > dual-stack > IPv4/IPv6 implementation, some minor changes need to be made > to ICE-15. > Specifically, > for the case where BOTH sides are using ICE-lite. > > The procedures when one or both sides are NOT using ICE-lite are OK as > is in ICE-15. > > Using section 5 of ICE-15 as a basis. > > A sends offer to B. A uses ICE-lite, but it is dual stack, so > the offer > looks like > this: > > Offer: > > m=IPv4 <- Assumption is that IPv4 is morelikely to > succeed than IPv6 > candidate 1=IPv6 > candidate 2=IPv4 > a=ice-lite [JRE] ICE-15 is ambiguous as to whether multiple candidates are allowed with ice-lite. I believe the intention is to clarify this by saying that only one candidate is allowed, which would then invalidate this example. However, I do agree that it could be useful to have this capability and the procedures you describe below. > > B receives the offer, it is also using ice-lite and is also > dual stack. > > It sends an answer: > > m=IPv4 > candidate 1=IPv6 > candidate 2=IPv4 > a=ice-lite > > According to section 5 today it would result in having "NO > CONNECTIVITY > CHECK". > > The current wording says "ICE cannot proceed", which I think is > innacurate since the > candidates have already been sent, so ICE has already proceeded to a > certain point. I think it > needs to be clarified is that it "ICE does not proceed with the > connectivity check". > > According to section 5 again, it would result in having the IPv4 > selected instead of the > IPv6 (i.e., the m line). > > That's NOT the behavior we want. What we want is in this case to have > both sides use the candidates > and the RFC 3484 procedures. I would like to see some guidance around > using RFC 3484 procedures. > > One easy way for B to ensure that it's choice is selected, is > to respond > with this answer > instead: > > m=IPv6 <- i.e., forcing the other side to use the > IPv6 address > candidate 1=IPv6 <- I'm not sure we actually need this > line? > a=ice-lite <- This is to tell A that it understood > ICE > > It might also be useful in this case, for the second offer answer > (normal in ICE) to > proceed to "lock" on the IPv6 address and help middleboxes. Therefore, > the second offer > answer would look like: > > Offer: > m=IPv6 > > Answer: > m=IPV6 > > I believe that if we do this, we will have addressed the requirements > for dual-stack. > > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Thursday, March 29, 2007 08:07 > > To: mmusic@ietf.org > > Cc: Colin Perkins; Joerg Ott > > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > > > > > > This is to announce a Working Group Last Call on ICE > > draft-ietf-mmusic-ice-15.txt. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > > > This WGLC will end on Friday April 20. > > > > Please mail all your final comments to the author and the > > mmusic mailing list. > > > > Jean-Francois -- As WG co-chair > > jfm@cablelabs.com > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 20 11:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heucx-00062A-B4; Fri, 20 Apr 2007 11:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heucv-000621-G9 for mmusic@ietf.org; Fri, 20 Apr 2007 11:02:21 -0400 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heucv-0002hs-5Z for mmusic@ietf.org; Fri, 20 Apr 2007 11:02:21 -0400 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3KF2I3i008355; Fri, 20 Apr 2007 11:02:18 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l3KF2Gfg021409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 11:02:17 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02F28BFC-1A57-4D81-8A9E-DC924CF20590@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 20 Apr 2007 11:02:12 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mmusic@ietf.org Subject: [MMUSIC] Comments on ICE-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Here are some comments on ICE-15. *) When there are multiple check lists, there is nothing that requires that the various check timers be spaced out. As it currently stands, all the check timers could expire at the same time. I suggest creating just one check timer, and serve round-robin- ing between the check lists. *) I think the document needs to be more explicit about how the transport addresses of an incoming binding request gets matched to a candidate pair. There is text scattered through sections 7.2.1.3, and .4 and .5 which is vague and confusing. Moreover, it doesn't make the point that none of this can be done until the offerer receives the answer. I think a new section needs to be inserted between sections 7.2.1.2 and 7.2.1.3. This section would say roughly - The processing at this point pauses until an answer is received from the far end. Then once un-paused ... - The destination transport address is matched to a local candidate using the local UFRAG in the received binding request. - The source transport address is matched to a remote candidate using the remote UFRAG. If there is no such candidate, a new peer-reflexive candidate is created. This would replace the vague text in the next few sections that talk about determining the candidate pair and the remote password, etc. *) The text says: o If there is at least one nominated pair in the valid list for a media stream and the state of the check list is Running: * The agent MUST remove all Waiting and Frozen pairs in the check list for the same component as the nominated pairs for that media stream Do we remove ALL checks, or just checks of lower priority? In aggressive nomination mode, the latter seems to be the better choice, since it gives the chance for higher priority checks to find a better path, which seems to be in the spirit of aggressive nomination. *) Not long afterwards it says: o Once there is at least one nominated pair in the valid list for every component of at least one media stream and the state of the check list is Running: * The agent MUST change the state of processing for its check list for that media stream to Completed. What about checks that are currently "in-progress"? Do these continue to run? It seems in keeping with "aggressive nomination" to have them continue, but it seems weird to consider the check list to be "Completed" (and even weirder to think of ICE as being "Completed", which is what happens if this is the only check list). *) Most of the presentation in the document assumes a single offerer and single answerer. However, we know that SIP supports forking, and thus ICE must support an offer being delivered to multiple answerers, and there are occasional hints about this in the document. It would be nice if this was clearly stated early on. I am worried that we have not paid enough attention to this case. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 20 11:12:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heun0-0007Kf-CS; Fri, 20 Apr 2007 11:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heumz-0007KU-24 for mmusic@ietf.org; Fri, 20 Apr 2007 11:12:45 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heumy-0004ez-NN for mmusic@ietf.org; Fri, 20 Apr 2007 11:12:45 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3KFCcC01785; Fri, 20 Apr 2007 15:12:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Fri, 20 Apr 2007 10:12:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF101BFD03@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670B9C9959@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt thread-index: AceDIzkfsnDvxemgSmmzru1X5C+TTAAOv3ag References: <50B1CBA96870A34799A506B2313F26670B9C9959@ntht201e.siemenscomms.co.uk> From: "Francois Audet" To: "Elwell, John" , "Jean-Francois Mule" , , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Colin Perkins , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Agree. I am proposing that we make the change to allow multiple candidates for IPv4/IPv6.=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Friday, April 20, 2007 01:09 > To: Audet, Francois (SC100:3055); Jean-Francois Mule;=20 > mmusic@ietf.org; Jonathan Rosenberg > Cc: Colin Perkins; Joerg Ott > Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt >=20 > Francois, >=20 > I think something along these lines would be useful, but see=20 > comments below. >=20 > John=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 18 April 2007 23:03 > > To: Jean-Francois Mule; mmusic@ietf.org; Jonathan Rosenberg > > Cc: Colin Perkins; Joerg Ott > > Subject: RE: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > > Importance: High > >=20 > > My comments for WGLC are included below: > >=20 > > In order to be able to use ICE as the mechanism for supporting a=20 > > dual-stack > > IPv4/IPv6 implementation, some minor changes need to be made to=20 > > ICE-15. > > Specifically, > > for the case where BOTH sides are using ICE-lite. > >=20 > > The procedures when one or both sides are NOT using=20 > ICE-lite are OK as=20 > > is in ICE-15. > >=20 > > Using section 5 of ICE-15 as a basis. > >=20 > > A sends offer to B. A uses ICE-lite, but it is dual stack, so the=20 > > offer looks like > > this: > >=20 > > Offer: > >=20 > > m=3DIPv4 <- Assumption is that IPv4 is morelikely to > > succeed than IPv6 > > candidate 1=3DIPv6 > > candidate 2=3DIPv4 > > a=3Dice-lite > [JRE] ICE-15 is ambiguous as to whether multiple candidates=20 > are allowed with ice-lite. I believe the intention is to=20 > clarify this by saying that only one candidate is allowed,=20 > which would then invalidate this example. However, I do agree=20 > that it could be useful to have this capability and the=20 > procedures you describe below. >=20 > >=20 > > B receives the offer, it is also using ice-lite and is also dual=20 > > stack. > >=20 > > It sends an answer: > >=20 > > m=3DIPv4 > > candidate 1=3DIPv6 > > candidate 2=3DIPv4 > > a=3Dice-lite > >=20 > > According to section 5 today it would result in having "NO=20 > > CONNECTIVITY CHECK". > >=20 > > The current wording says "ICE cannot proceed", which I think is=20 > > innacurate since the candidates have already been sent, so ICE has=20 > > already proceeded to a certain point. I think it needs to=20 > be clarified=20 > > is that it "ICE does not proceed with the connectivity check". > >=20 > > According to section 5 again, it would result in having the IPv4=20 > > selected instead of the > > IPv6 (i.e., the m line). > >=20 > > That's NOT the behavior we want. What we want is in this=20 > case to have=20 > > both sides use the candidates and the RFC 3484 procedures. I would=20 > > like to see some guidance around using RFC 3484 procedures. > >=20 > > One easy way for B to ensure that it's choice is selected, is to=20 > > respond with this answer > > instead: > >=20 > > m=3DIPv6 <- i.e., forcing the other side to use the > > IPv6 address > > candidate 1=3DIPv6 <- I'm not sure we actually need this > > line? > > a=3Dice-lite <- This is to tell A that it understood > > ICE > >=20 > > It might also be useful in this case, for the second offer answer=20 > > (normal in ICE) to proceed to "lock" on the IPv6 address and help=20 > > middleboxes. Therefore, the second offer answer would look like: > >=20 > > Offer: > > m=3DIPv6 =20 > >=20 > > Answer:=20 > > m=3DIPV6 > >=20 > > I believe that if we do this, we will have addressed the=20 > requirements=20 > > for dual-stack. > >=20 > > > -----Original Message----- > > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > > Sent: Thursday, March 29, 2007 08:07 > > > To: mmusic@ietf.org > > > Cc: Colin Perkins; Joerg Ott > > > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt > > >=20 > > >=20 > > > This is to announce a Working Group Last Call on ICE=20 > > > draft-ietf-mmusic-ice-15.txt. > > >=20 > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > >=20 > > > This WGLC will end on Friday April 20. > > >=20 > > > Please mail all your final comments to the author and the mmusic=20 > > > mailing list. > > >=20 > > > Jean-Francois -- As WG co-chair > > > jfm@cablelabs.com > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 20 11:42:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevFL-0006Vi-BG; Fri, 20 Apr 2007 11:42:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevFJ-0006Vd-HR for mmusic@ietf.org; Fri, 20 Apr 2007 11:42:01 -0400 Received: from mx2-7.spamtrap.magma.ca ([209.217.78.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HevFI-0003IC-Lo for mmusic@ietf.org; Fri, 20 Apr 2007 11:42:01 -0400 Received: from mail4.magma.ca (mail4.internal.magma.ca [10.0.10.14]) by mx2-7.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3KFfvnw013661; Fri, 20 Apr 2007 11:41:57 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail4.magma.ca (Magma's Mail Server) with ESMTP id l3KFfuSq010361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 11:41:57 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 20 Apr 2007 11:41:50 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 3.2 (+++) X-Scan-Signature: b656e85d4d33f5403d96bac6146425d9 Cc: mmusic@ietf.org Subject: [MMUSIC] Minor comments on ICE-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan: Below are some more comments on ICE-15. Most of them are minor editorial comments. I have extracted text from ICE-15, and then put in comments marked with "PM:". - Philip ---------------- The basic idea behind ICE is as follows: each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port) it could use to communicate with the other agent. These might include: o A transport address on a directly attached network interface or interfaces PM: s/or interfaces// (since a given transport address can only be on one interface) ---- Next, the agent uses STUN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED CANDIDATES). The relationship of these candidates to the host candidate is shown in Figure 2. Both types of candidates are PM: s/in Figure 2/in Figure 2 (here the notation "X:x" means IP address X and port x)./ discovered using STUN. ---- To find a server reflexive candidate, the agent sends a STUN Binding Request, using the Binding Discovery Usage [12] from each host candidate, to its STUN server. It is assumed that the address of the STUN server is manually configured or learned in some unspecified way. It is RECOMMENDED that when an agent has a choice of STUN servers (when, for example, they are learned through DNS records and multiple results are returned), an agent uses a single STUN server (based on its IP address) for all candidates for a particular session. This improves the performance of ICE. PM: First of all, I suggest NOT placing normative text in the Overview section. More fundamentally, there are topologies where one absolutely wants to use multiple STUN servers. After all, this is the main point of the draft that you co-authored with Dan Wing on discovering STUN servers. ---- Each candidate is associated with a property called its FOUNDATION. Two candidates have the same foundation when they are "similar" - of the same type and obtained from the same interfaces and STUN servers. PM: s/interfaces/interface/ and s/servers/server/. Otherwise, their foundation is different. A candidate pair has a foundation too, which is just the concatenation of the foundations of its two candidates. Initially, only the candidate pairs with unique foundations are tested. The other candidate pairs are marked "frozen". When the connectivity checks for a candidate pair succeed, the candidate pairs with the same foundation are unfrozen. This PM: s/the candidate pairs/other candidate pairs/ ? avoids repeated checking of components which are superficially more attractive but in fact are likely to fail. ---- With regular nomination, the controlling agent lets the checks continue until at least one valid candidate pair for each media stream is found. Then, it picks amongst those that are valid, and sends a second STUN request on its NOMINATED candidate pair, but this time with a flag set to tell the peer that this pair has been nominated for use. A This is shown in Figure 4. PM: s/A This/This/ ---- 2.7. Lite Implementations In order for ICE to be used in a call, both agents need to support it. However, certain agents will always be connected to the public Internet and have a public IP address at which it can receive packets from any correspondent. To make it easier for these devices to support ICE, ICE defines a special type of implementation called LITE (in contrast to the normal FULL implementation). A lite implementation doesn't gather candidates; it includes only host candidates for any media stream. When a lite implementation connects with a full implementation, the full agent takes the role of the controlling agent, and the lite agent takes on the controlled role. In addition, lite agents do not need to generate connectivity checks, run the state machines, or compute candidate pairs. Additional PM: s/Additional/For/ guidance on when a lite implementation is appropriate, see the discussion in Appendix A. ---- Default Destination/Candidate: The default destination for a component of a media stream is the transport address that would be used by an agent that is not ICE aware. For the RTP component, the default IP address is in the c line of the SDP, and the port in the m line. For the RTCP component it is in the rtcp attribute when present, and when not present, the IP address in the c line and 1 plus the port in the m line. A default candidate for a component is one whose transport address matches the default destination for that component. PM: The term "default" doesn't work very well when you talk about a re-offer that specifies a new "default" value. ---- The agent will receive a STUN Binding or Allocate response. A successful Allocate Response will provide the agent with a server reflexive candidate (obtained from the mapped address) and a relayed candidate in the RELAY-ADDRESS attribute. If the Allocate request is rejected because the server lacks resources to fulfill it, the agent SHOULD instead send a Binding Request to obtain a server reflexive candidate. A Binding Response will provide the agent with only a server reflexive candidate (also obtained from the mapped address). The base of the server reflexive candidate is the host candidate from which the Allocate or Binding request was sent. The base of a relayed candidate is that candidate itself. If a relayed candidate is identical to a host candidate (which can happen in rare cases), the relayed candidate MUST be discarded. Proper operation of ICE depends on candidate having a unique base when their transport addresses are identical. PM: You are mixing singular and plural in this sentence. PM: The operation implied by the last two sentences seems to be the same as that described in the next section. ---- 4.1.1.3. Eliminating Redundant Candidates Next, the agent eliminates redundant candidates. A candidate is redundant if its transport address equals another candidate, and its base equals the base of that other candidate. Note that two candidates can have the same transport address yet have different bases, and these would not be considered redundant. PM: Which candidate should be kept? The highest priority candidate? 4.1.1.4. Computing Foundations Finally, the agent assigns each candidate a foundation. The foundation is an identifier, scoped within a session. Two candidates MUST have the same foundation ID when all of the following are true: o they are of the same type (host, relayed, server reflexive, peer reflexive or relayed) PM: "relayed" appears twice ---- Each candidate is assigned a foundation. The foundation MUST be different for two candidates from different interfaces, and MUST be the same otherwise. A simple integer that increments for each interface will suffice. In addition, each candidate MUST be assigned a unique priority amongst all candidates for the same media stream. PM: s/all candidates/all local candidates/ This priority SHOULD be equal to 2^24*(126) + 2^8*(65535) + 256 minus the component ID, which is 2130706432 minus the component ID. If an agent has included two candidates for a component, the v4 candidate SHOULD be selected as the default. Since a lite PM: How can a lite agent include two candidates for a component. ??? implementation has a single candidate for a component, each of these candidates is considered to be default. ---- STUN connectivity checks between agents make use of a short term credential that is exchanged in the offer/answer process. The username part of this credential is formed by concatenating a username fragment from each agent, separated by a colon. Each agent also provides a password, used to compute the message integrity for requests it receives. The username fragment and password are PM: s/receives/sends/ exchanged in the ice-ufrag and ice-pwd attributes, respectively. In addition to providing security, the username provides disambiguation and correlation of checks to media streams. See Appendix B.4 for motivation. ---- v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 PM: How are these priority value computed? I would have expected a value of 2,130,706,431 and 1,694,498,815 respectively. ---- o For each media stream, the default destination for at least one component of the media stream appears in a candidate attribute. For example, in the case of RTP, the IP address and port in the c and m line, respectively, appears in a candidate attribute, or the value in the rtcp attribute appears in a candidate attribute. PM: Why just "at least one component"? Why not all components? ---- Once roles are determined for a session, they persist unless ICE is restarted. A ICE restart (Section 9.1 causes a new selection of roles and tie-breakers. PM: s/9.1/9.1)/ ---- 5.7.2. Computing Pair Priority and Ordering Pairs Once the pairs are formed, a candidate pair priority is computed. Let O be the priority for the candidate provided by the offerer. Let A be the priority for the candidate provided by the answerer. The priority for a pair is computed as: pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0) Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is greater than A-P, and 0 otherwise. This formula ensures a unique priority PM: Do you mean "O" rather than "O-P" and "A" rather than "A-P"? for each pair in most cases. Once the priority is assigned, the agent sorts the candidate pairs in decreasing order of priority. If two pairs have identical priority, the ordering amongst them is arbitrary. ---- 5.7.3. Pruning the Pairs This sorted list of candidate pairs is used to determine a sequence of connectivity checks that will be performed. Each check involves sending a request from a local candidate to a remote candidate. Since an agent cannot send requests directly from a reflexive candidate, but only from its base, the agent next goes through the sorted list of candidate pairs. For each pair where the local candidate is server reflexive, the server reflexive candidate MUST be replaced by its base. Once this has been done, the agent MUST prune PM: A candidate is replaced by its corresponding base candidate. In other words, all the associated information about the candidate (e.g., its foundation) is replaced by the associated information for its base. the list. This is done by removing a pair if its local and remote candidates are identical to the local and remote candidates of a pair higher up on the priority list. The result is a sequence of ordered candidate pairs, called the check list for that media stream. PM: Do we need to talk about what happens when the default candidate pair gets pruned? In addition, in order to limit the attacks described in Section 17.4.2, an agent SHOULD limit the total number of connectivity checks they perform across all check lists to 100, by discarding the lower priority candidate pairs until there are less than 100. ---- The initial states for each pair in the check list are computed by PM: s/the check list/a check list/ performing the following sequence of steps: ---- One of the check lists will have some number of pairs in the Waiting state, and the other check lists will have all of their pairs in the Frozen state. A check list with at least one pair that is Waiting is called an active check list, and a check list with all pairs frozen is called a frozen check list. PM: "active" and "frozen" look like check list states to me. Could we make them explicit states? The check list itself is associated with a state, which captures the state of ICE checks for that media stream. There are two states: PM: s/two states/three states/ Running: In this state, ICE checks are still in progress for this media stream. Completed: In this state, ICE checks have completed successfully for this media stream. Failed: In this state, the ICE checks have not completed successfully for this media stream. ---- Once the agent has computed the check lists as described in Section 5.7, it sets a timer for each active check list. The timer fires every Ta*N seconds, where N is the number of active check lists (initially, there is only one active check list). Implementations MAY set the timer to fire less frequently than this. Ta is the same value used to pace the gathering of candidates, as described in Section 4.1.1. Multiplying by N allows this aggregate check throughput to be split between all active check lists. The first timer for each active check list fires immediately, so that the agent performs a connectivity check the moment the offer/answer exchange has been done, followed by the next periodic check Ta seconds later. PM: There is nothing here that requires all these timers to be spaced out. As it stands, once every Ta*N seconds, all the timers could fire at once. I am wondering if it is better to have just one timer and round-robin between the check lists? When the timer fires, the agent MUST: o Find the highest priority pair in that check list that is in the Waiting state. o If there is such a pair: * Send a STUN check from the local candidate of that pair to the remote candidate of that pair. The procedures for forming the STUN request for this purpose are described in Section 7.1.1. PM: Move state of pair to "In-Progress"? ---- 2. If there is a pair in the valid list for every component of this media stream (where this is the actual number of components being used, in cases where the number of components signaled in the SDP differs from offerer to answerer), the success of this check may unfreeze checks for other media streams. Note that this step is PM: Following the procedures as laid out here, the pair which has just transitioned to Succeeded is NOT YET on the valid list, because that step doesn't happen until the next section. followed not just the first time the valid list under consideration has a pair for every component, but every subsequent time a check succeeds and adds yet another pair to that valid list. The agent examines the check list for each other media stream in turn: ---- If the agent is the controlled agent, the response may result in the valid pair having its nominated flag set. See Section 7.2.1.5 for the procedure. PM: I don't see how this could be the case, since this is a binding response. ---- Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several triggered notifications to all be sent at the same time, PM: s/,/./ ? PM: Can the response include a NONCE, as the STUN spec says it can? ---- 7.2.1.1. Detecting and Repairing Role Conflicts Normally, the rules for selection of a role in Section 5.2 will result in each agent selecting a different role - one controlling, and one controlled. However, in unusual call flows, typically utilizing third party call control, it is possible for both agents to select the same role. This section describes procedures for checking for this case and repairing it. PM: Can we see examples of 3PCC cases where this problem comes up? I am worried that no one but Jonathan understands these cases. An agent MUST examine the Binding Request for either the ICE- CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these procedures: o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the request, there is no conflict. PM: Isn't this a malformed binding request, since 7.1.1.2. requires one of these to be included? ---- 7.2.1.4. Triggered Checks Next, the agent constructs a pair whose local candidate is equal to PM: This is a transport address pair, not a candidate pair. Then we are trying to match this transport address pair to a candidate pair on a check list. We use the local and remote UFRAGs to do this. In fact, I claim all this processing happens just before section 7.2.1.3. ---- If a triggered check is to be generated, it is constructed and processed as described in Section 7.1.1. These procedures require the agent to know the transport address, username fragment and password for the peer. The username fragment for the remote candidate is equal to the part after the colon of the USERNAME in the Binding Request that was just received. Using that username PM: Why do I have to extract the username fragment in this manner? I know the local and remote candidate pair -- why can't I just used the username fragment and password associated with it? fragment, the agent can check the SDP messages received from its peer Rosenberg Expires September 27, 2007 [Page 46] Internet-Draft ICE March 2007 (there may be more than one in cases of forking), and find this username fragment. The corresponding password is then selected. If agent has not yet received the username in an SDP (a likely case for the offerer in the initial offer/answer exchange), it MUST wait for the SDP to be received (since it won't have its peer's ICE password without it), and then proceed with the triggered check. PM: You already said this above. ---- o If there is at least one nominated pair in the valid list for a media stream and the state of the check list is Running: * The agent MUST remove all Waiting and Frozen pairs in the check list for the same component as the nominated pairs for that media stream PM: Do we remove ALL, or only those of lower priority? ---- o Once there is at least one nominated pair in the valid list for every component of at least one media stream and the state of the check list is Running: * The agent MUST change the state of processing for its check list for that media stream to Completed. PM: What about checks that are "In-Progress"? Do these continue to run? If they do, then the stuff below about changing the state of ICE processing overall to Completed seems wrong. (Or is this why it is possible in Aggressive Nomination, for the default candidate to change multiple times?) * The agent MUST continue to respond to any checks it may still receive for that media stream, and MUST perform triggered checks if required by the processing of Section 7.2. ---- : is taken from RFC 4566 [10]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses and FQDNs. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS using an A or AAAA record, and the resulting IP address is used for the remainder of ICE processing. PM: What is the motivation for allowing an FQDN in this position? I think this just makes the implementation more complex, for no good reason. ---- 15.5. "ice-options> Attribute PM: s/>/"/ ---- 17.5. Interactions with Application Layer Gateways and SIP Application Layer Gateways (ALGs) are functions present in a NAT device which inspect the contents of packets and modify them, in order to facilitate NAT traversal for application protocols. Session Border Controllers (SBC) are close cousins of ALGs, but are less transparent since they actually exist as application layer SIP intermediaries. ICE has interactions with SBCs and ALGs. If an ALG is SIP aware but not ICE aware, ICE will work through it as long as the ALG correctly modifies the SDP. In this case, correctly means that the ALG does not modify the m and c lines or the rtcp attribute if they contain external addresses. If they contain internal addresses, the modification depends on the state of the ALG. If the ALG already has a binding established that maps an external port to an internal IP address and port in m and c lines or rtcp attribute , the ALG uses that binding instead of creating a new one. PM: I think these last two sentences are meant to be descriptions of a correctly operating ALG, but this is not obvious from the wording. ---- B.1. Pacing of STUN Transactions STUN transactions used to gather candidates and to verify connectivity are paced out at an approximate rate of one new transaction every Ta milliseconds, where Ta has a default of 20ms. Why are these transactions paced, and why was 20ms chosen as default? PM: Below you describe why transactions are paced, but do not explain why 20ms was chosen as the default. Perhaps add a sentence that says that 20ms was chosen after an experiments with a number of NATs showed that they could all handle 20ms but could not handle significantly higher rates? ---- B.2. Candidates with Multiple Bases Section 4.1.1 talks about merging together candidates that are identical but have different bases. When can an agent have two candidates that have the same IP address and port, but different bases? Consider the topology of Figure 23: PM: There is no discussion in section 4.1.1 about "merging" candidates. Are you referring here to section 4.1.1.3 on eliminating duplicate candidates, and in particular to the last sentence? If so, perhaps reword this as follows: "Section 4.1.1.3 talks about eliminating duplicate candidates, and states that a candidate can be eliminated only if there is another candidate with the same transport address and base. This leads to the question: How two candidates can have the same transport addresses, but different bases? Consider the topology of Figure 23:". PM: Also, I think it would be useful to add a paragraph motivating why one wants to eliminate duplicate candidates. I suggest mentioning the common case of obtaining a server reflexive candidate for a host candidate, and discovering that the two candidates are the same. Perhaps you can think of other common cases? --- B.5. The Candidate Pair Sequence Number Formula The sequence number for a candidate pair has an odd form. It is: pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P? 1:0) Why is this? When the candidate pairs are sorted based on this value, the resulting sorting has the MAX/MIN property. This means that the pairs are first sorted based on decreasing value of the maximum of the two sequence numbers. For pairs that have the same value of the maximum sequence number, the minimum sequence number is used to sort amongst them. If the max and the min sequence numbers are the same, the offerers priority is used as the tie breaker in the last part of the expression. The factor of 2*32 is used since the priority of a single candidate is always less than 2*32, resulting in the pair priority being a "concatenation" of the two component priorities. This creates the desired sorting property. PM: Perhaps add a paragraph on why this particular sorting algorithm was chosen? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 21 02:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf8yr-0006N0-IH; Sat, 21 Apr 2007 02:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf8yq-0006Ms-8N for mmusic@ietf.org; Sat, 21 Apr 2007 02:21:56 -0400 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hf8yl-00026m-TC for mmusic@ietf.org; Sat, 21 Apr 2007 02:21:56 -0400 Received: (qmail 9068 invoked by uid 89); 21 Apr 2007 15:21:46 +0900 Received: from unknown (HELO IBM-T42) (218.225.198.74) by 0 with SMTP; 21 Apr 2007 15:21:46 +0900 Date: Sat, 21 Apr 2007 15:21:47 +0900 From: "Jia Hu" To: "mmusic" Organization: WICI X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Subject: [MMUSIC] CFP: IEEE/WIC/ACM IAT 2007 - Silicon Valley, USA, DL: June 1 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wiiat@kis-lab.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Message-Id: [Apologies if you receive this more than once] ##################################################################### IEEE/WIC/ACM Intelligent Agent Technology 2007 CALL FOR PAPERS ##################################################################### 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07) Silicon Valley, USA, November 2-5, 2007 Official: http://www.cs.sjsu.edu/wi07/iat/ Mirror: http://www.maebashi-it.org/wi07/iat/ (to be collocated with WI'07, BIBM'07 and GrC'07) Sponsored By IEEE Computer Society Web Intelligence Consortium (WIC) Association for Computing Machinery (ACM) ##################################################################### # Conference Chair # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research # # Program Chair and Co-Chairs # T.Y. Lin, San Jose State University/UC Berkeley, USA # Jeffrey M. Bradshaw, UWF/Institute for Human and Machine Cognition, USA # Matthias Klusch, German Research Center for AI, Germany # Chengqi Zhang, University of Technology, Sydney, Australia # # Organizing Chair # Howard Ho, Manager, IBM Almaden Research Center # # IAT-WI Joint Keynote Speakers (Tentative) # # Vinton G. Cerf, Turing Award Winner, # VP and Chief Internet Evangelist, Google # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory # # (More IAT Invited Speakers will be announced) # # (Papers Due: ** June 1 **, 2007) # Accepted papers will be published in the conference proceedings # by the IEEE Computer Society Press, which are indexed by EI. ###################################################################### The 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07) will be jointly held with the 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07), the 2007 IEEE International Conference on Bioinformatics and Biomedicine (BIBM'07), and the 2007 IEEE International Conference on Granular Computing (GrC'07) for providing synergism among the four research areas. It will provide opportunities for technical collaboration beyond that of previous conferences. The four conferences will have a joint opening, keynote, reception, and banquet. Attendees only need to register for one conference and can attend workshops, sessions and tutorials across the four conferences. We are also planning a joint panel and joint paper sessions that discuss common problems in the four areas. IAT 2007 provides a leading international forum to bring together researchers and practitioners from diverse fields, such as computer science, information technology, business, education, human factors, systems engineering, and robotics, to (1) examine the design principles and performance characteristics of various approaches in intelligent agent technology, and (2) increase the cross-fertilization of ideas on the development of autonomous agents and multi-agent systems among different domains. By encouraging idea-sharing and discussions on the underlying logical, cognitive, physical, and sociological foundations as well as the enabling technologies of intelligent agents, IAT 2007 will foster the development of novel paradigms and advanced solutions in agent-based computing. +++++++++++ Highlights +++++++++++ The conference will be held in Silicon Valley, California. Many high-tech companies and three distinguished universities (Stanford, UC Berkely and UCSC) are just around the corner. The highlight of the conference is that a unique forum consisting of a half-day demo session and free discussion will be organized to link industries and academics. Leading IT companies like IBM, Google, and Yahoo etc will present at the conference. The area now known as Silicon Valley has been a center of technological development since the 1950's. The name Silicon Valley stems from the early 1970's, when the area had become the center for many semiconductor companies. While still hosting semiconductor and microprocessor companies, the region now hosts the headquarters of high tech companies of every kind, including many of the best known and most prestigious names in personal computers, Web search, Internet auctions, networking, storage, databases, etc. +++++++++++++++++++ Topics of Interest +++++++++++++++++++ The topics and areas include, but not limited to: * Autonomy-Oriented Computing (AOC) - Agent-Based Complex Systems Modeling and Development - Agent-Based Simulation - Autonomy-Oriented Modeling and Computation Methods - Behavioral Self-Organization - Complex Behavior Characterization and Engineering - Emergent Behavior - Hard Computational Problem Solving - Nature-Inspired Paradigms - Self-Organized Criticality - Self-Organized Intelligence - Swarm Intelligence * Autonomous Knowledge and Information Agents - Agent-Based Distributed Data Mining - Agent-Based Knowledge Discovery And Sharing - Autonomous Information Services - Distributed Knowledge Systems - Emergent Natural Law Discovery in Multi-Agent Systems - Evolution of Knowledge Networks - Human-Agent Interaction - Information Filtering Agents - Knowledge Aggregation - Knowledge Discovery - Ontology-Based Information Services * Agent Systems Modeling and Methodology - Agent Interaction Protocols - Cognitive Architectures - Cognitive Modeling of Agents - Emotional Modeling - Fault-Tolerance in Multi-Agent Systems - Formal Framework for Multi-Agent Systems - Information Exchanges in Multi-Agent Systems - Learning and Self-Adaptation in Multi-Agent Systems - Mobile Agent Languages and Protocols - Multi-Agent Autonomic Architectures - Multi-Agent Coordination Techniques - Multi-Agent Planning and Re-Planning - Peer-to-Peer Models for Multi-Agent Systems - Reinforcement Learning - Social Interactions in Multi-Agent Systems - Task-Based Agent Context - Task-Oriented Agents * Distributed Problem Solving - Agent-Based Grid Computing - Agent Networks in Distributed Problem Solving - Collective Group Behavior - Coordination and Cooperation - Distributed Intelligence - Distributed Search - Dynamics of Agent Groups and Populations - Efficiency and Complexity Issues - Market-Based Computing - Problem-Solving in Dynamic Environments * Autonomous Auctions and Negotiation - Agent-Based Marketplaces - Auction Markets - Combinatorial Auctions - Hybrid Negotiation - Integrative Negotiation - Mediating Agents - Pricing Agents - Thin Double Auctions * Applications - Agent-Based Assistants - Agent-Based Virtual Enterprise - Embodied Agents and Agent-Based Systems Applications - Interface Agents - Knowledge and Data Intensive Systems - Perceptive Animated Interfaces - Scalability - Social Simulation - Socially Situated Planning - Software and Pervasive Agents - Tools and Standards - Ubiquitous Systems and E-Technology Agents - Ubiquitous Software Services - Virtual Humans - XML-Based Agent Systems ++++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication ++++++++++++++++++++++++++++++++++++ High-quality papers in all IAT related areas are solicited. Paper submissions should be limited to a maximum of 7 pages in the IEEE 2-column format, the same as the camera-ready format (see the Author Guidelines of last year at http://www.computer.org/portal/pages/cscps/cps/final/iat06.xml). All submitted papers will be reviewed by the Program Committee on the basis of technical quality, relevance, significance, and clarity. Note that IAT'07 will accept ONLY on-line submissions, containing PDF versions. Please use the Submission Form on the IAT'07 website to submit your paper. Accepted papers will be published in the conference proceedings by the IEEE Computer Society Press that are indexed by EI. Submissions accepted as regular papers will be allocated 7 pages in the proceedings and accorded oral presentation times in the main conference. Submissions accepted as short papers will be allocated 4 pages in the proceedings and will have a shorter presentation time at the conference than regular papers. All co-authors will be notified at all time, for the submission, notification, and confirmation on the attendance. Submitting a paper to the conference and workshops means that, if the paper is accepted, at least one author should attend the conference to present the paper. The acceptance list and no-show list will be openly published on-line. For no-show authors, their affiliations will receive a notification. A selected number of IAT'07 accepted papers will be expanded and revised for inclusion in Web Intelligence and Agent Systems: An International Journal (http://wi-consortium.org/journal.html) and in Annual Review of Intelligent Informatics (http://www.wi-consortium.org/annual.html) More detailed instructions and the On-Line Submission Form can be found from the IAT'07 homepage: http://www.cs.sjsu.edu/wi07/iat/. +++++++++++++++++++++++++ IAT'07 Best Paper Awards +++++++++++++++++++++++++ The best paper awards will be conferred at the conference on the authors of (1) the best research paper and (2) the best application paper. Application-oriented submissions will be considered for the best application paper award. The full author list and paper title will be announced on the Web Intelligence Consortium homepage: http://wi-consortium.org/html/wicawards.html ++++++++++++++++++++ Industry/Demo-Track ++++++++++++++++++++ We solicit Industry/Demo-Track papers by the following methods. (1) Industry papers of 4 pages can be submitted on the same schedule as the research track. (2) Separate 2 page demo proposals can submitted at a later schedule. (3) Full regular paper submissions can include a demo option. That is, a full paper submissions will be asked to specify if they would like to give a demonstration; choice of demonstrations (while utilizing information from the regular reviewing process) will be selected based on value as a demonstration. For options (1) and (2), please find more detailed instructions at the homepage: http://www.cs.sjsu.edu/wi07/wi/ We are planning to arrange the Industry/Demo track in the afternoon of November 3 (before and during the conference reception), jointly with the IAT'07 Demo sessions. Leading IT companies in Silicon Valley will be invited to attend this track. ++++++++++ Workshops ++++++++++ As an important part of the conference, the workshop program will focus on new research challenges and initiatives. All papers accepted for workshops will be included in the Workshop Proceedings published by the IEEE Computer Society Press that are indexed by EI, and will be available at the workshops. Detailed information is available at the conference homepage. Note: we will not have a separate workshop registration fee (i.e., only one conference registration covers everything). ------------------- IAT 2007 Workshops: ------------------- Title: Second International Workshop on Communication between Human and Artificial Agents (CHAA-07) Organisers: Christel Kemke Email: ckemke@cs.umanitoba.ca Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ Title: Rational, Robust, and Secure Negotiations in Multi-Agent Systems (RRS2007) Organisers: Takayuki Ito Email: ito.takayuki@nitech.ac.jp Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ Title: P2P Computing and Autonomous Agents Organisers: Tarek Helmy, Khaled Ragab Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html Title: Multiagent systems in E-business: concepts, technologies and applications Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl; marcin.parzycki@swps.edu.pl Web page: http://software.ucv.ro/~badica_costin/maseb2007/ Title: Agent & Data Mining Interaction Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir Gorodetsky, Justin Zhan Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: http://issel.ee.auth.gr/ADMI ------------------ WI 2007 Workshops: ------------------ Title: Educating the Web-Generation Organisers: Elisabeth Heinemann Email: elisabeth.heinemann@googlemail.com Web page: http://www.effactory.com/Edu4WebGen/ Title: Collective Intelligence on Semantic Web Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl Web page: http://intelligent.pe.kr/CISW07/ Title: New Computing Paradigms for Web Intelligence and Brain Informatics Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: Title: Web Personalization and Recommender Systems Organisers: Yue Xu Email: yue.xu@qut.edu.au Web page: http://www.wprs07.fit.qut.edu.au/ Title: Service Composition Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web site: http://events.deri.at/sercomp2007/ Title: Biomedicine applications of Web technologies Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; whlu@mail.ncku.edu.tw Web page: http://chunnan.iis.sinica.edu.tw/BMWT2007.html Title: Intelligent Web Interaction Workshop 2007 1st Organiser: Prof. Seiji YAMADA Email: seiji@nii.ac.jp Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ Title: Cyberinfrastucture for e-Science Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page: http://www.cild.iastate.edu/events/CyIneS2007/ Title: 2007 International Workshop on Social Media Analysis Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu Email: sma@comp.hkbu.edu.hk Web page: http://www.comp.hkbu.edu.hk/~sma/ Title: Web Security, Integrity, Privacy and Trust Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof. Yong Zhang Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; zhangyong076@gmail.com Web page: For more information, please visit the conference website at http://www.maebashi-it.org/wi07/iat/?index=workshop. ++++++++++ Tutorials ++++++++++ IAT'07 also welcomes Tutorial proposals. IAT'07 will include tutorials providing in-depth background on subjects that are of broad interest to the intelligent agent community. Both short (2 hours) and long (half day) tutorials will be considered. The tutorials will be part of the main conference technical program. Detailed information is available at the conference homepage. Note: we will not have a separate tutorials registration fee (i.e., only one conference registration covers everything). ++++++++++++++++ Important Dates ++++++++++++++++ Workshop proposal submission: March 20, 2007 Electronic submission of full papers: ** June 1, 2007 ** Tutorial proposal submission: June 15, 2007 Notification of paper acceptance: July 22, 2007 Camera-ready copies of accepted papers: August 17, 2007 Conference: November 2-5, 2007 ++++++++++++++++++++++++ Conference Organization ++++++++++++++++++++++++ Conference Chair: * Andrei Broder, Yahoo! Research, USA Program Chair: * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA IAT Program Co-Chairs: * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Matthias Klusch, German Research Center for AI, Germany * Chengqi Zhang, University of Technology, Sydney, Australia WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev Motwani, Stanford University, USA Organizing Chair: * Howard Ho, IBM Almaden Research Center, USA Workshop Co-Chairs: * Vijay Raghavan, University of Louisiana, USA * Yuefeng Li, Queensland University of Technology, Australia Tutorial Chair: * Pawan Lingras, Saint Mary's University, Canada Industry/Demo-Track Chair: * Jianchang Mao, Yahoo! Inc., USA Local Accommodations Co-Chairs: * David Scot Taylor, San Jose State University, USA * Tom Qi Zhang, Google, USA Publicity Chair: * James Wang, Clemson University, USA (chair) Publicity Co-Chairs: * Martine De Cock, Ghent University, Belgium * Jia Hu, International WIC Institute, China * Debajyoti Mukhopadhyay, West Bengal University of Technology, India IEEE-CS-TCII Chair: * Ning Zhong, Maebashi Institute of Technology, Japan ACM-SIGART Chair * Maria Gini, University of Minnesota, USA WIC Co-Chairs/Directors: * Ning Zhong, Maebashi Institute of Technology, Japan * Jiming Liu, University of Windsor, Canada WIC Advisory Board: * Edward A. Feigenbaum, Stanford University, USA * Setsuo Ohsuga, Waseda University, Japan * Benjamin Wah, University of Illinois, Urbana-Champaign, USA * Philip Yu, IBM Thomas J. Watson Research Center, USA * L.A. Zadeh, University of California Berkeley, USA WIC Tech. Committee & WI/IAT Steering Committee: * Jeffrey Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Nick Cercone, Dalhousie University, Canada * Dieter Fensel, National University of Ireland, Ireland * Georg Gottlob, Oxford University, UK * Lakhmi Jain, University of South Australia, Australia * Jianchang Mao, Yahoo! Inc., USA * Pierre Morizet-Mahoudeaux, Compiegne University of Technology, France * Hiroshi Motoda, Osaka University, Japan * Toyoaki Nishida, Kyoto University, Japan * Andrzej Skowron, Warsaw University, Poland * Jinglong Wu, Kagawa University, Japan * Xindong Wu, University of Vermont, USA * Yiyu Yao, University of Regina, Canada Webmaster: * Albert Sutojo, San Jose State University, USA Abbreviation: IAT 2007, IAT2007, IAT'2007, IAT'07, IAT07, IAT 07, IAT-07, IAT-2007, WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, WI-2007, WI-IAT 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07, WI-IAT 07, WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007, WI/IAT'2007, WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 *** Contact Information *** Jia Hu International WIC Institute, China E-mail: hujia@kis-lab.com Keywords: WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 23 13:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg269-0008Ks-4n; Mon, 23 Apr 2007 13:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg267-0008Kh-Qr for mmusic@ietf.org; Mon, 23 Apr 2007 13:13:07 -0400 Received: from mail-out4.apple.com ([17.254.13.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg266-0004QG-DV for mmusic@ietf.org; Mon, 23 Apr 2007 13:13:07 -0400 Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l3NHD3ig023195; Mon, 23 Apr 2007 10:13:03 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 6CF2229C004; Mon, 23 Apr 2007 10:13:03 -0700 (PDT) X-AuditID: 11807123-9ebe7bb000000b42-b0-462ce91fc4c9 Received: from [10.0.1.3] (unknown [17.219.210.19]) by relay5.apple.com (Apple SCV relay) with ESMTP id 1FD1630400B; Mon, 23 Apr 2007 10:13:03 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <462387E3.20600@ericsson.com> References: <462387E3.20600@ericsson.com> Date: Mon, 23 Apr 2007 10:12:15 -0700 To: Magnus Westerlund , "mmusic (E-mail)" From: Dave Singer Subject: Re: [MMUSIC] RTSP: Speed header Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I have to confess I find both the existing text and what you write below quite confusing. e.g. If I am trying to play back at normal rate, why would I ask for the data to be delivered at say half or double rate? I think I read it that scale (roughly) tells the server what rate I want to play at, and speed seems to have an effect on the bandwidth the server can use. I know of no-one implementing these, partly because, I think, that there is some doubt over the meaning. I have to say that I find even the names rather odd! So, I would read, perhaps? scale=2, speed=1 -- send it to me for double-speed playback, but don't use any more bandwidth than normal scale=2, speed=2 -- you can also use twice the normal bandwidth scale=-1, speed=1 -- send to me in normal speed reverse order I'm not sure. Can someone give us some background? -- David Singer Apple Computer/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 23 16:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5We-00037h-FB; Mon, 23 Apr 2007 16:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5Wd-00036H-Lv for mmusic@ietf.org; Mon, 23 Apr 2007 16:52:43 -0400 Received: from mx1-3.spamtrap.magma.ca ([209.217.78.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5Wc-0004IA-43 for mmusic@ietf.org; Mon, 23 Apr 2007 16:52:43 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx1-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3NKqfdv020180; Mon, 23 Apr 2007 16:52:41 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l3NKqdud003267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 16:52:40 -0400 In-Reply-To: <46278FA2.2010709@pjsip.org> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) Date: Mon, 23 Apr 2007 16:52:35 -0400 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 19-Apr-07, at 11:49 , Benny Prijono wrote: > > I have different solution, and mine is directed towards reducing > the number of checks. And I believe this one not only help > congestion problem, but it could also ICE performance significantly. > > The idea is to use one socket for all candidates in one component. > During pruning process, we know that srflx candidate will be pruned > and be replaced by its base candidate. > > But since we use one socket for all candidates, the host candidates > can be pruned as well, leaving just one host candidate in the check > list for the component (note: this currently is not in ICE). > > If an agent is using this approach (and assuming only host and > srflx candidates are used), the number of checks that the agent > performs would be M for each component, where M is the number of > candidates in that component in the remote agent. Compare this to > current ICE where the number of checks will be "(N-1) x M" (the > N-1 reflects the pruning of srflx candidate). > > I think this could work (would be interested to hear Jonathan's > comment on this). Unfortunately it seems that the use of one socket > per component has been deprecated long ago and it would be quite a > big editing work to adapt the text this way. But I've been using > one socket approach and it seems to work. I don't understand your proposal. Say I have an application that needs M components, and is running on a box with N interfaces. Then for each interface and component, I allocate one local port number (socket) -- these are my host candidates. Then I use STUN to determine server-reflexive and relay candidates that correspond to each of these host candidates. I don't see how I can reduce anything. Can you clarify? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 23 18:02:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6cF-00076j-PT; Mon, 23 Apr 2007 18:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6cE-00076e-ME for mmusic@ietf.org; Mon, 23 Apr 2007 18:02:34 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6cD-00022h-C3 for mmusic@ietf.org; Mon, 23 Apr 2007 18:02:34 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61649 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Hg6cA-00007p-Fk; Mon, 23 Apr 2007 23:02:30 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36A80F09-0848-402F-89A0-061E0D4AD125@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt Date: Mon, 23 Apr 2007 23:02:24 +0100 To: mmusic@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Jean-Francois Mule , Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 29 Mar 2007, at 16:06, Jean-Francois Mule wrote: > This is to announce a Working Group Last Call on ICE > draft-ietf-mmusic-ice-15.txt. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > This WGLC will end on Friday April 20. > > Please mail all your final comments to the author and the mmusic > mailing > list. The working group last call period has ended, with approximately 100 comments received. An updated draft should be submitted, at which time we will reissue the working group last call, to ensure the comments have been satisfactorily addressed. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 23 22:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgAi1-0007Q7-42; Mon, 23 Apr 2007 22:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgAi0-0007Q2-Nt for mmusic@ietf.org; Mon, 23 Apr 2007 22:24:48 -0400 Received: from ns.live555.com ([4.79.217.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgAhy-0007r3-DF for mmusic@ietf.org; Mon, 23 Apr 2007 22:24:48 -0400 Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.1/8.13.8) with ESMTP id l3O2Omk4054728 for ; Mon, 23 Apr 2007 19:24:48 -0700 (PDT) (envelope-from rsf@ns.live555.com) Received: (from rsf@localhost) by ns.live555.com (8.14.1/8.13.8/Submit) id l3O2OmhW054727; Mon, 23 Apr 2007 19:24:48 -0700 (PDT) (envelope-from rsf) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <462387E3.20600@ericsson.com> Date: Mon, 23 Apr 2007 19:23:52 -0700 To: mmusic@ietf.org From: Ross Finlayson Subject: Re: [MMUSIC] RTSP: Speed header Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org One of the strengths of the IETF is that we prefer not to standardize protocol features that are not being used. With that in mind, perhaps the "Speed" header should be removed from the RTSP 2.0 specification, especially since - as Dave makes clear - its purpose appears unclear. (I had always assumed that this header was intended to be used for 'fast downloading' - e.g., downloading a 1 hour movie in 30 minutes (assuming sufficient bandwidth). But if that's what you want, then why not just download the movie as a file?) Do we have any reason to keep the "Speed" header in the RTSP 2.0 specification? Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 23 22:33:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgAqh-0004f6-EB; Mon, 23 Apr 2007 22:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgAqg-0004Zy-ED for mmusic@ietf.org; Mon, 23 Apr 2007 22:33:46 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgAqf-0000yD-6A for mmusic@ietf.org; Mon, 23 Apr 2007 22:33:46 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3O2XZeV003594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 22:33:40 -0400 (EDT) In-Reply-To: References: <462387E3.20600@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <641B816F-E430-48AB-B259-D5314A6FCB11@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [MMUSIC] RTSP: Speed header Date: Mon, 23 Apr 2007 22:33:34 -0400 To: Ross Finlayson X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The original motivation was to have a more controlled, but higher- bandwidth, download, particularly in environments where TCP was inappropriate (say, multicast). That said, if there's no current usage of that feature, it should be relegated to an extension. On Apr 23, 2007, at 10:23 PM, Ross Finlayson wrote: > One of the strengths of the IETF is that we prefer not to > standardize protocol features that are not being used. With that > in mind, perhaps the "Speed" header should be removed from the RTSP > 2.0 specification, especially since - as Dave makes clear - its > purpose appears unclear. > > (I had always assumed that this header was intended to be used for > 'fast downloading' - e.g., downloading a 1 hour movie in 30 minutes > (assuming sufficient bandwidth). But if that's what you want, then > why not just download the movie as a file?) > > Do we have any reason to keep the "Speed" header in the RTSP 2.0 > specification? > > Ross. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 02:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgElp-0003mL-Eh; Tue, 24 Apr 2007 02:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgElo-0003mF-2n for mmusic@ietf.org; Tue, 24 Apr 2007 02:45:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgEln-0002DD-DE for mmusic@ietf.org; Tue, 24 Apr 2007 02:45:00 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C7D93212D7; Tue, 24 Apr 2007 08:44:58 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-f9-462da76a61d5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B914121121; Tue, 24 Apr 2007 08:44:58 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 08:44:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP: Speed header Date: Tue, 24 Apr 2007 08:44:57 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0504D56AAE@esealmw109.eemea.ericsson.se> In-Reply-To: <641B816F-E430-48AB-B259-D5314A6FCB11@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP: Speed header Thread-Index: AceGGQX6Qk3r2NzHRiCcZ48bccwgVgAIZP+A References: <462387E3.20600@ericsson.com> <641B816F-E430-48AB-B259-D5314A6FCB11@cs.columbia.edu> From: "Ingemar Johansson S \(LU/EAB\)" To: "Henning Schulzrinne" , "Ross Finlayson" X-OriginalArrivalTime: 24 Apr 2007 06:44:58.0615 (UTC) FILETIME=[13782870:01C7863C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Reading this makes me think of many of the sites out there that allows the user watch video clips, to me it seems like the download speed is faster than the actual playout speed.=20 One such example is YouTube, the benefit is that one can quite easily fastforward in the videoclip with very little extra delay.=20 Cannot tell if it is implemented as streaming or file download or how YouTube works on a technical level but anyway the functionality as seen by the user is there. =20 Ingemar > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: den 24 april 2007 04:34 > To: Ross Finlayson > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] RTSP: Speed header >=20 > The original motivation was to have a more controlled, but=20 > higher- bandwidth, download, particularly in environments=20 > where TCP was inappropriate (say, multicast). >=20 > That said, if there's no current usage of that feature, it=20 > should be relegated to an extension. >=20 > On Apr 23, 2007, at 10:23 PM, Ross Finlayson wrote: >=20 > > One of the strengths of the IETF is that we prefer not to=20 > standardize=20 > > protocol features that are not being used. With that in=20 > mind, perhaps=20 > > the "Speed" header should be removed from the RTSP 2.0=20 > specification,=20 > > especially since - as Dave makes clear - its purpose=20 > appears unclear. > > > > (I had always assumed that this header was intended to be used for=20 > > 'fast downloading' - e.g., downloading a 1 hour movie in 30 minutes=20 > > (assuming sufficient bandwidth). But if that's what you want, then=20 > > why not just download the movie as a file?) > > > > Do we have any reason to keep the "Speed" header in the RTSP 2.0=20 > > specification? > > > > Ross. > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 04:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFzs-00030u-Sg; Tue, 24 Apr 2007 04:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFzq-00030m-QG for mmusic@ietf.org; Tue, 24 Apr 2007 04:03:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFzp-00052B-0K for mmusic@ietf.org; Tue, 24 Apr 2007 04:03:34 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6352421347; Tue, 24 Apr 2007 10:03:32 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-b2-462db9d43b70 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5406F21187; Tue, 24 Apr 2007 10:03:32 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 10:03:31 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 10:03:31 +0200 Message-ID: <462DB9D3.80707@ericsson.com> Date: Tue, 24 Apr 2007 10:03:31 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] RTSP: Speed header References: <462387E3.20600@ericsson.com> <641B816F-E430-48AB-B259-D5314A6FCB11@cs.columbia.edu> <026F8EEDAD2C4342A993203088C1FC0504D56AAE@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0504D56AAE@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 08:03:31.0785 (UTC) FILETIME=[0CBCD390:01C78647] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Ross Finlayson , mmusic@ietf.org, Henning Schulzrinne X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ingemar Johansson S (LU/EAB) skrev: > Hi > > Reading this makes me think of many of the sites out there that allows > the user watch video clips, to me it seems like the download speed is > faster than the actual playout speed. > One such example is YouTube, the benefit is that one can quite easily > fastforward in the videoclip with very little extra delay. > Cannot tell if it is implemented as streaming or file download or how > YouTube works on a technical level but anyway the functionality as seen > by the user is there. > downloading at slightly faster than media speed or even at full fair share is fine for media file. However for streaming there are to some degree not necessary to buffer enormous amounts because you loose the interactivity, or at least you will be forced to flush you buffer at time you change your playback point or so. Lets wait and see a few more days, but so far there seem to be little real interest for speed. Especially its problematic relation to congestion control makes it difficult to use. Because the request can only be fulfilled if the actual bandwidth is available. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 04:43:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGco-0008Bt-9f; Tue, 24 Apr 2007 04:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGcm-0008Bf-RJ for mmusic@ietf.org; Tue, 24 Apr 2007 04:43:48 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgGcj-0004ZN-8p for mmusic@ietf.org; Tue, 24 Apr 2007 04:43:48 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l3O8hiLP020619; Tue, 24 Apr 2007 10:43:44 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l3O8hhr1007844; Tue, 24 Apr 2007 10:43:43 +0200 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 10:43:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP: Speed header Date: Tue, 24 Apr 2007 10:43:42 +0200 Message-ID: <397436DD55E397458853EA8367A30E6F01DB720B@MCHP7R5A.ww002.siemens.net> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0504D56AAE@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP: Speed header Thread-Index: AceGGQX6Qk3r2NzHRiCcZ48bccwgVgAIZP+AAARddFA= References: <462387E3.20600@ericsson.com><641B816F-E430-48AB-B259-D5314A6FCB11@cs.columbia.edu> <026F8EEDAD2C4342A993203088C1FC0504D56AAE@esealmw109.eemea.ericsson.se> From: "Heiles, Juergen" To: "ext Ingemar Johansson S \(LU/EAB\)" X-OriginalArrivalTime: 24 Apr 2007 08:43:43.0970 (UTC) FILETIME=[AA830C20:01C7864C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Such Internet video sides usually use http based Progressive Download instead of streaming. See http://www.streamingmedia.com/article.asp?id=3D8456&page=3D1 for the difference. Regards Juergen =20 >-----Original Message----- >From: ext Ingemar Johansson S (LU/EAB)=20 >[mailto:ingemar.s.johansson@ericsson.com]=20 >Sent: Tuesday, April 24, 2007 8:45 AM >To: Henning Schulzrinne; Ross Finlayson >Cc: mmusic@ietf.org >Subject: RE: [MMUSIC] RTSP: Speed header > >Hi > >Reading this makes me think of many of the sites out there that allows >the user watch video clips, to me it seems like the download speed is >faster than the actual playout speed.=20 >One such example is YouTube, the benefit is that one can quite easily >fastforward in the videoclip with very little extra delay.=20 >Cannot tell if it is implemented as streaming or file download or how >YouTube works on a technical level but anyway the functionality as seen >by the user is there. >=20 >Ingemar > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 >> Sent: den 24 april 2007 04:34 >> To: Ross Finlayson >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] RTSP: Speed header >>=20 >> The original motivation was to have a more controlled, but=20 >> higher- bandwidth, download, particularly in environments=20 >> where TCP was inappropriate (say, multicast). >>=20 >> That said, if there's no current usage of that feature, it=20 >> should be relegated to an extension. >>=20 >> On Apr 23, 2007, at 10:23 PM, Ross Finlayson wrote: >>=20 >> > One of the strengths of the IETF is that we prefer not to=20 >> standardize=20 >> > protocol features that are not being used. With that in=20 >> mind, perhaps=20 >> > the "Speed" header should be removed from the RTSP 2.0=20 >> specification,=20 >> > especially since - as Dave makes clear - its purpose=20 >> appears unclear. >> > >> > (I had always assumed that this header was intended to be used for=20 >> > 'fast downloading' - e.g., downloading a 1 hour movie in=20 >30 minutes=20 >> > (assuming sufficient bandwidth). But if that's what you=20 >want, then=20 >> > why not just download the movie as a file?) >> > >> > Do we have any reason to keep the "Speed" header in the RTSP 2.0=20 >> > specification? >> > >> > Ross. >> > >> > _______________________________________________ >> > mmusic mailing list >> > mmusic@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >>=20 > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 13:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgP0Y-00014j-Tn; Tue, 24 Apr 2007 13:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgP0X-00014Y-4y for mmusic@ietf.org; Tue, 24 Apr 2007 13:40:53 -0400 Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgP0V-0007dS-Oo for mmusic@ietf.org; Tue, 24 Apr 2007 13:40:53 -0400 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.13.8/8.13.8) with ESMTP id l3OHeppx023478 for ; Tue, 24 Apr 2007 10:40:51 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 188DF404DE for ; Tue, 24 Apr 2007 10:40:51 -0700 (PDT) X-AuditID: 11807126-9f54ebb0000007ff-ec-462e412204e6 Received: from [172.28.172.64] (unknown [17.219.198.218]) by relay8.apple.com (Apple SCV relay) with ESMTP id C50B5404DF for ; Tue, 24 Apr 2007 10:40:50 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <397436DD55E397458853EA8367A30E6F01DB720B@MCHP7R5A.ww002.siemens.net> References: <462387E3.20600@ericsson.com> <641B816F-E430-48AB-B259-D5314A6FCB11@cs.columbia.edu> <026F8EEDAD2C4342A993203088C1FC0504D56AAE@esealmw109.eemea.ericsson.se> <397436DD55E397458853EA8367A30E6F01DB720B@MCHP7R5A.ww002.siemens.net> Date: Tue, 24 Apr 2007 10:39:45 -0700 To: mmusic@ietf.org From: Dave Singer Subject: RE: [MMUSIC] RTSP: Speed header Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree that if you want download, at the rate that the network/server/client can support, a, um, download protocol is generally better. TCP provides all the flow control and so on. I do think that an RTSP 2.0 should clarify trick modes. I don't think that download needs to be in there, but data-rate management does need to be. -- David Singer Apple Computer/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 14:38:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPtm-0004S6-Rx; Tue, 24 Apr 2007 14:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPtl-0004S0-6N for mmusic@ietf.org; Tue, 24 Apr 2007 14:37:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgPtj-0004Cg-TH for mmusic@ietf.org; Tue, 24 Apr 2007 14:37:57 -0400 Received: by ug-out-1314.google.com with SMTP id 72so205979ugd for ; Tue, 24 Apr 2007 11:37:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=KYDYz/HGA/YWuAjls6ykLv2mzW5LhBGPhKvnayiV/nLjKoWN4nfTt4HqFM3nvUYEtXO9KlcCBS1eOd8X8Su/+SfUCPXQOh+AWkGRiGgZCBfrgaQEihf6/2+Ukp3YZaPPn9WswF3kpgAioYVB3+yhLcONofFkSkUAhCqw4jkh4Xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=AEbECjTzvP5Xf/GeSYIt6mRUjP/JgMvODbs3mEzWGr/vi9Lsb0qUXAfcnaskQtXTE0P2FtKuoEwCQu30jLZdOQ+N9+cL47crOo/xDek5uIo9uqOQSuyRzcy8oGe1+8rNLGRyVFs1ETnbwOXOCme8+jo+FKErtwEnRmC4yyXRLJ0= Received: by 10.78.200.3 with SMTP id x3mr1557482huf.1177439874701; Tue, 24 Apr 2007 11:37:54 -0700 (PDT) Received: by 10.78.39.17 with HTTP; Tue, 24 Apr 2007 11:37:54 -0700 (PDT) Message-ID: <4d0605c20704241137g3a2af1bfq389b317d551b17da@mail.gmail.com> Date: Tue, 24 Apr 2007 11:37:54 -0700 From: "Joseph Pallas" To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: Speed header MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: aea23bea3d5db546 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org It sounds like there is some consensus here. I want to chime in because Ross's comment aligns well with recent remarks by Magnus. RTSP 1.0 has not been as useful a standard as we would like. It includes some things that no one uses, it omits some things that many users want, and in a few areas it actually prohibits desirable practices (unintentionally). The result has been poor interoperability. I wasn't active in this community at the time RTSP 1.0 was being drafted, but it seems to contain features that were deemed "nice to have" without any implementation experience. I think Ross is suggesting that's part of the problem, and I agree. Anything we can do to minimize this problem for RTSP 2.0 will make it a better document. joe _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 15:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgR6j-0005TJ-G5; Tue, 24 Apr 2007 15:55:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgR6g-0005Ea-2d for mmusic@ietf.org; Tue, 24 Apr 2007 15:55:22 -0400 Received: from kal-el.real.com ([207.188.23.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgR6b-0004Kp-Uv for mmusic@ietf.org; Tue, 24 Apr 2007 15:55:21 -0400 Received: from [172.23.125.220] ([::ffff:172.23.125.220]) (AUTH: PLAIN acolwell, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by kal-el.real.com with esmtp; Tue, 24 Apr 2007 12:55:17 -0700 id 00080030.462E60A5.000065C0 Message-ID: <462E609B.1040905@real.com> Date: Tue, 24 Apr 2007 12:55:07 -0700 From: Aaron Colwell User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dave Singer Subject: Re: [MMUSIC] RTSP: Speed header References: <462387E3.20600@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Magnus Westerlund , "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org We've used something similar to Speed in the Real/HelixServer for client controlled rate adaptation. The client used our "Speed" equivalent to slightly increase the delivery rate to see if there was bandwidth to switch up to the next higher bitrate. Depending on how often it increases the rate above the clip rate, the client may also need to lower the delivery rate below the clip rate to prevent buffering too much data. We do not switch the RTP sample rate when we increase the delivery rate like Magnus' original email suggests. I'm not making a case whether Speed should stay or not, just providing an example of where such functionality has been used in an existing implementation. Aaron Dave Singer wrote: > I have to confess I find both the existing text and what you write below > quite confusing. e.g. If I am trying to play back at normal rate, why > would I ask for the data to be delivered at say half or double rate? > > I think I read it that scale (roughly) tells the server what rate I want > to play at, and speed seems to have an effect on the bandwidth the > server can use. > > I know of no-one implementing these, partly because, I think, that there > is some doubt over the meaning. I have to say that I find even the > names rather odd! > > > So, I would read, perhaps? > scale=2, speed=1 -- send it to me for double-speed playback, but don't > use any more bandwidth than normal > scale=2, speed=2 -- you can also use twice the normal bandwidth > scale=-1, speed=1 -- send to me in normal speed reverse order > > I'm not sure. Can someone give us some background? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 16:08:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRJW-0006S3-1g; Tue, 24 Apr 2007 16:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRJT-0006Rx-VS for mmusic@ietf.org; Tue, 24 Apr 2007 16:08:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRJP-0000IH-L3 for mmusic@ietf.org; Tue, 24 Apr 2007 16:08:35 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2007 13:08:29 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="140105713:sNHT44887338" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3OK8Vr1029821; Tue, 24 Apr 2007 13:08:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3OK8SEo004527; Tue, 24 Apr 2007 20:08:30 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:08:08 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:08:07 -0700 Message-ID: <462E639D.9050301@cisco.com> Date: Tue, 24 Apr 2007 16:07:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE-15: when do you stop waiting for an aggressive nomination? References: <17940.7833.822061.888913@cnr.cs.columbia.edu> <4614FA39.30403@cisco.com> <46150516.5080308@pjsip.org> <461A3CE4.3020800@cisco.com> <461A900E.3070909@pjsip.org> <461B920C.3060401@cisco.com> <461BA689.6080109@pjsip.org> In-Reply-To: <461BA689.6080109@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 20:08:07.0922 (UTC) FILETIME=[4688DD20:01C786AC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1288; t=1177445311; x=1178309311; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=20waiti ng=20for=20an=09aggressive=09nomination? |Sender:=20; bh=8Br35UBVBdKb/swvAGc39Gf0w/fQRetvOUtP+6YQm+Q=; b=kZ3b2awc72Bauye6dBs6mFC+6rJM/uqtVdOhfWtSLTA01qS0fYnAnX//yg/7SeWoOd6FqPzr 4m7Mk6N6xpgBCVlm8v5nMjTtNB7fY2w5fFuQg5ciG3juXdl+E8bNpfzk; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Benny Prijono wrote: > Jonathan Rosenberg wrote: > >>> Timer looks like the only solution indeed. >> >> >> Yup. I will add that to ICE-16. > > > Sounds good. Just to be sure, we don't need to make the procedure > normative as not all implementations have this problem. > > In my case, for example, I use one socket for one component (that's one > socket and one STUN "session" for all candidates, including multiple > host candidates, srflx, and potentially relay), and I recycle media > transports between calls. So if for one particular call some of the > resources are not used, I just keep them alive, because anyway they may > still need to send keep-alives to their STUN/TURN server. The text will say something like, "SHOULD free resources if they are no longer in use". THat would cover your case. Also something similar happens in forking, where a set of candidates gets used in many sessions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 16:38:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRmL-0005Dv-E4; Tue, 24 Apr 2007 16:38:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRmK-0005Dq-7m for mmusic@ietf.org; Tue, 24 Apr 2007 16:38:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRmH-0007sF-9D for mmusic@ietf.org; Tue, 24 Apr 2007 16:38:24 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 13:37:57 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="415195378:sNHT1241913318" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3OKbuau028702; Tue, 24 Apr 2007 13:37:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3OKbuA8018181; Tue, 24 Apr 2007 20:37:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:37:55 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:37:55 -0700 Message-ID: <462E6AA1.20101@cisco.com> Date: Tue, 24 Apr 2007 16:37:53 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] ICE-15: when do you stop waitingforan aggressive nomination? References: <00cc01c77d24$a8f2d650$c4f0200a@amer.cisco.com> In-Reply-To: <00cc01c77d24$a8f2d650$c4f0200a@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 20:37:55.0321 (UTC) FILETIME=[6FE84E90:01C786B0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7045; t=1177447076; x=1178311076; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=09waiti ngforan=09aggressive=09nomination? |Sender:=20; bh=ZddmMH/mDCJRuQkpTfCI0sdqfEHgrUkEVoL9cnRhG8g=; b=LQC3lt9celQmh1/PSyUz5OoLQV9uufMnkO7QlTbql2VVGGhTtY13efQxohkLoCFCOaKPu5WU 3E8Ro/avwdIVpzk3onanGlFXLsXkyIeqcjQQqOUE3FWPWRVDS/Je8PF5; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Right now, there is just one sentence on ICMP in ICE: If the STUN transaction generates an ICMP error, or generates a STUN error response that is unrecoverable (as defined in , or times out, the agent sets the state of the pair to Failed. Nothing in here is saying you HAVE to process iCMP, it only says what to do when you get one. I'm fine to add a sentence that endpoints MAY implement ICMP. On a related note, there is actually a problem with the current ICE spec and ICMP. In the case of clients, both behind a NAT, both agents will generate STUN checks to the other. One of these is likely to hit the far end NAT first. If that NAT generates ICMP on its public interface since no permission exists, the STUN transaction will fail if the agent is waiting for ICMP. WIth the current wording, the agent will receive the incoming STUN request, and find that its transaction in the reverse direction failed, and thats the end. I actually need to fix this, so that if the transaction failed due to ICMP, you retry the check. -Jonathan R. Dan Wing wrote: > You can ignore them -- it just means you'll hit the timeouts. It > can't be a MUST requirement in -16, and I recall Jonathan said it > would be a MAY? > > -d > > > >>-----Original Message----- >>From: Guylain Lavoie [mailto:glavoie@m5t.com] >>Sent: Thursday, April 12, 2007 8:11 AM >>To: Dan Wing; Benny Prijono >>Cc: mmusic@ietf.org >>Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan >>aggressive nomination? >> >>Hi Dan, >> >>Although ICMP may be lost in transit for multiple reasons like the one >>you stated I would really like to know, from an ICE implementer >>perspective, what exactly are we required to implement. Must an >>implementation be able to receive these ICMP errors and correctly >>associate them, without ambiguity, to the correct STUN usage which >>triggered them in the first place? Or, is an implementation allowed to >>ignore them with the consequence of having to wait until the full >>timeout. Having the correctly manage ICMP adds a lot of complexity to >>the implementation. Do we have to resort to this added complexity (lot >>of connected UDP sockets) or can we just ignore ICMP and use >>only a non >>connected UDP socket for all operations. >> >>Benny has indicated that he would ignore ICMP reception. Should we all >>do that? >> >>Thanks, >>Guylain >> >>-----Original Message----- >>From: Dan Wing [mailto:dwing@cisco.com] >>Sent: April 10, 2007 3:43 PM >>To: Guylain Lavoie; 'Benny Prijono' >>Cc: mmusic@ietf.org >>Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan aggressive >>nomination? >> >> >> >> >>>-----Original Message----- >>>From: Guylain Lavoie [mailto:glavoie@m5t.com] >>>Sent: Tuesday, April 10, 2007 11:31 AM >>>To: Benny Prijono >>>Cc: mmusic@ietf.org >>>Subject: RE: [MMUSIC] ICE-15: when do you stop waitingforan >> >>aggressive >> >> >>>nomination? >>> >>>Hi Benny, >>> >>>Optional support of ICMP reception is perfectly fine for me >> >>because it >> >> >>>is much more easier to implement. >>> >>>However, if it is mandated, >> >>ICMP can't be mandated by ICE. ICMP is often filtered due to >>incompetence, overzealous administrators, or insufficient >>configuration >>granularity in firewalls and NATs. >> >>-d >> >> >> >>>we would basically need to allocate one socket for each >> >>candidate pair >> >> >>>plus one for each server reflexive candidate and relayed candidate. >>>That's a lot of sockets, but that way you can do a connect >> >>on all of >> >>>them. This solution would work fine on some operating >> >>systems, but on >> >>>others, it would not because the socket option SO_REUSEPORT is not >>>available and it is needed so that all socket may be bound >> >>to the same >> >> >>>address and port. From what I read, this is not available on Linux. >>>This might be true for other operating systems as well. You >> >>would also >> >> >>>need an non connected socket to be able to support reception of >>>connectivity checks before the SDP answer arrives. This >> >>would also be >> >>>required to receive a connectivity check from a peer reflexive >>>candidate (which is unknown and thus cannot be connected to). >>> >>>NOTE: The socket option SO_REUSEPORT and SO_REUSEADDR are >> >>needed for >> >>>an implementation of TCP with ICE because all TCP sockets are >>>inherently connected and must be bound to the same address and port. >>>Like with UDP, >>>this would probably no work on all operating systems. This is >>>mentioned in some NAT hole punching technique papers. >>> >>>Thanks >>>Guylain >>> >>>-----Original Message----- >>>From: Benny Prijono [mailto:bennylp@pjsip.org] >>>Sent: April 10, 2007 1:25 PM >>>To: Guylain Lavoie >>>Cc: mmusic@ietf.org >>>Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran >>>aggressive nomination? >>> >>>Hi Guylain, >>> >>>Guylain Lavoie wrote: >>> >>>>Hi Benny, >>>> >>>>I am wondering how you plan on demultiplexing ICMP errors >>> >>>if a single >>> >>>>socket is shared for all candidate of a component? >>>>How will you associate a received ICMP errors with a specific >>>>Connectivity Checks or even a Binding Discovery Request >>> >>>used to keep >>> >>>>server reflexive candidate alive (keepalive)? Normally, at >>> >>>least, on >>> >>>>BSD like stack, you must connect the UDP socket to be able >>> >>>to reliably >>> >>> >>>>receive ICMP errors. >>> >>>Even if you use one socket for each candidate, I'm not sure >> >>if you can >> >> >>>do UDP connect() on each of them, as ICE requires you to send >>>connectivity checks to multiple destinations. >>> >>> >>>>Not connecting the socket would not allow you to fully >>> >>>comply with the >>> >>> >>>>specification (your implementation would end up waiting for >>> >>>the full >>> >>>>timeout when such thing happens). >>> >>>I view ICMP handling as "if you can and want to handle it, >> >>then do it, >> >> >>>if not, then you know the risk" kind of thing, so I would disagree >>>that we should call these implementations not fully comply just >>>because they don't/can't handle ICMP. >>> >>>cheers, >>> -benny >>> >>> >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 16:45:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRtS-0005OF-Qa; Tue, 24 Apr 2007 16:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRtR-0005O7-La for mmusic@ietf.org; Tue, 24 Apr 2007 16:45:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRtR-0001CS-Ak for mmusic@ietf.org; Tue, 24 Apr 2007 16:45:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 24 Apr 2007 13:45:45 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="371934261:sNHT49197296" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3OKjiFV030316; Tue, 24 Apr 2007 13:45:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OKjbMJ017215; Tue, 24 Apr 2007 20:45:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:45:37 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:45:37 -0700 Message-ID: <462E6C70.1070601@cisco.com> Date: Tue, 24 Apr 2007 16:45:36 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guylain Lavoie Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? References: <6EF4CC794ECF2B409390605FDEA9012218D88D@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012218D88D@m5tmail1.m5t.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 20:45:37.0116 (UTC) FILETIME=[8328A1C0:01C786B1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2453; t=1177447544; x=1178311544; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20when=20do=20you=20stop=09waiti ng=09foran=09aggressive=09nomination? |Sender:=20; bh=SeEp3MZ4RsjUEOLbKEGCr1Q18Ghz6SWmrYXF32vj3f4=; b=nR16ZiY98xB4nlWkGPFQ59zrZXQC0HDMRkjrRDRkvUU557dxb8sCcwq5GmaQPtjObftbOblH p1HaRPLD0AFx6OM/PN0AHiZW/T2ythKuWj0xiXd6PniUQfmYz8uysSUf; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Guylain Lavoie wrote: > Alfred, > > In don't really understand what you mean. How can you send Binding > Request to a STUN server without ever connecting the socket? Remember, > it is TCP that we are talking about, not UDP. > > For a passive candidate, you really need to allocate at least two TCP > sockets and bind them at the same address and port. One will be a TCP > server socket and will be used to receive TCP connection requests > associated with peer initialited connectivity checks from its Active > candidates (Reception of a connection request will effectively create a > entirely new socket, also bound at the same address and port). The other > will be a TCP client socket connected to the STUN server to gather a > server reflexive candidate and periodically, it will also send Binding > Request to keep alive the NAT binding. I had in mind that there would be one socket. You'd first call socket() to allocate. THen you'd do a listen() on that socket to bind to a local port, and then connect() on the same socket to connect to the STUN server. I have not tried to see that BSD sockets will let you both listen() and connect() on the same socket. Certainly from a TCP protocol perspective this is allowed. Have you tried it? > > For SO, it is a bit different. You need to allocate at least two TCP > client sockets and also bind them at the same address and port. One will > be connected to the STUN server to gather a server reflexive candidate > and periodically send Binding Request to keep alive the NAT binding. The > other, or others, are used to send connectivity checks to the peer SO > candidates. Each one of them must be connected to peer SO candidate > before sending its connecitivity checks. Again, I think its more like the above. > > The situation becomes even more complex if you think that you may have > more than one STUN server. Note however, that the specification does not > encourage this. Its not that it doesn't encourage it; it just doesn't specify it. Its quite a fine idea as a general rule. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 16:47:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRvJ-000672-Qy; Tue, 24 Apr 2007 16:47:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRvI-00066x-Ie for mmusic@ietf.org; Tue, 24 Apr 2007 16:47:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRvI-0001VN-0y for mmusic@ietf.org; Tue, 24 Apr 2007 16:47:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 24 Apr 2007 13:47:25 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="415199318:sNHT1847444168" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3OKlOC5001931; Tue, 24 Apr 2007 13:47:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OKlBMT018542; Tue, 24 Apr 2007 20:47:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:47:20 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:47:19 -0700 Message-ID: <462E6CD6.3000309@cisco.com> Date: Tue, 24 Apr 2007 16:47:18 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE-15: pair priorities with 3PCC References: <17940.9088.826718.530635@cnr.cs.columbia.edu> <4614F7DD.5020902@cisco.com> <9A308EBB-D37F-4159-97A9-1BF9149D44B1@magma.ca> In-Reply-To: <9A308EBB-D37F-4159-97A9-1BF9149D44B1@magma.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 20:47:19.0523 (UTC) FILETIME=[C032B330:01C786B1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3516; t=1177447644; x=1178311644; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE-15=3A=20pair=20priorities=20with=203PC C |Sender:=20; bh=0cgiIe1kv5/uMGUY1g+yf/GMi7ebPTQm5os8KwlXNCA=; b=Q36ovU1PmuuVcKmRwW6gEfH8fQ/3Dij5DJaFG32MYnwH7FwLVVxDLgwL6/NQAiCLXVcYY8+8 maigx7iuO7dk3OV/Cw8cF/Z56mvFhn+O9dlh9icqA84lipzKYCToydG/; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Jonathan Lennox , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Its not hugely important; it'll affect the last component of the formula below. I see no reason why not to specify this to work correctly however. -Jonathan R. Philip Matthews wrote: > If I understand this comment correctly, then the only question is which > end is > the offerer and which end is the answerer. > > Given that the formula is: > pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0) > the value of the priority differs by at most one if the roles of the > offerer and answerer > are reversed. > > So how important is this really? > > - Philip > > > On 5-Apr-07, at 09:21 , Jonathan Rosenberg wrote: > >> I think this is a good suggestion and I've made the change in my >> working -16. >> >> Thanks, >> Jonathan R. >> >> >> Jonathan Lennox wrote: >> >>> The ICE pair-priority formula (defined in section 5.7.2) takes as its >>> parameters the priority of the offerer's candidate and that of the >>> answerer's candidate. >>> However, in 3PCC scenarios, the two endpoints can disagree about >>> which of >>> them is the offerer. This was the reason for the introduction of the >>> ICE-CONTROLLING and ICE-CONTROLLED attributes in ICE-15. In this >>> case, the >>> two endpoints would calculate different pair priorities, and thus start >>> their periodic checks in a different order. >>> As I understand it, the order of the periodic checks is important to >>> the >>> protocol, so that "suicide packets" hit firewalls at roughly the >>> same time; >>> this is why the prioritization algorithm is normative. As such, a >>> disagreement about which party is the offerer would cause a problem. >>> My suggestion would be to change the formula of 5.7.2. Rather than >>> having >>> its parameters be the offerer's priority and the answerer's >>> priority, the >>> parameters would instead be the controlling endpoint's priority and the >>> controlled endpoint's priority. >>> Thus, if an endpoint switches its role after "losing" a role conflict, >>> following the procedures of 7.2.1.1, it needs to re-calculate its pair >>> priorities and re-sort its check lists. >>> This change to the formula won't cause a compatibility problems with >>> ICE-14 >>> or earlier, or with ICE-15 if there hasn't been a role conflict, >>> because the >>> only case in which the offerer is not the controller is if the >>> offerer is >>> using ICE-lite. Since an ICE-lite endpoint can list only a single >>> candidate, the order of the check list will be the same either way, and >>> anyway doesn't matter since the lite endpoint isn't sending any checks. >>> Thoughts? >> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 18:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgT63-0003rb-Mb; Tue, 24 Apr 2007 18:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgT62-0003rW-Ty for mmusic@ietf.org; Tue, 24 Apr 2007 18:02:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgT61-0008DY-JH for mmusic@ietf.org; Tue, 24 Apr 2007 18:02:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2007 15:02:48 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="140150010:sNHT53071425" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3OM2mVa032399; Tue, 24 Apr 2007 15:02:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OM2cMN021328; Tue, 24 Apr 2007 22:02:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 15:02:46 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 15:02:45 -0700 Message-ID: <462E7E81.2090203@cisco.com> Date: Tue, 24 Apr 2007 18:02:41 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews References: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> In-Reply-To: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 22:02:45.0807 (UTC) FILETIME=[4A12D3F0:01C786BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1525; t=1177452168; x=1178316168; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Question=20on=20Verifying=20ICE=20Support |Sender:=20; bh=fHzFQvFK0sqgNqPHi+w/RRWVWqyMIck7Ung4Rc9c/Cg=; b=yiBN9/qLTMXyU8JyFzvuCvW2sd7lOgolrWyOnLBqqZNlna9PC8YY/gdf1upfbQWcg6Q+H17q iEwDyKaeQAhvoXW1X20/dWSD5SpYSI5drH2NWgF1Y4Q6yXWAM4oJPKoa; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF MMUSIC WG Subject: [MMUSIC] Re: Question on Verifying ICE Support X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hmm. This is one of these cases where, I vaguely recall there was a reason for this, but I cannot remember what it is. Thinking about it now I would have to agree with you, it certainly seems more logical that it should be all of them. Unless I can remember why I did it this way, I will change it. -Jonathan R. Philip Matthews wrote: > Jonathan: > > ICE-15 says: > > 5.1. Verifying ICE Support > > The answerer will proceed with the ICE procedures defined in this > specification if the following are all true: > > o For each media stream, the default destination for at least one > component of the media stream appears in a candidate attribute. > For example, in the case of RTP, the IP address and port in the c > and m line, respectively, appears in a candidate attribute, or the > value in the rtcp attribute appears in a candidate attribute. > > > Why the "at least one component"? I don't understand why you do not > require that there to be an a=candidate attribute for each component? > In what non-SBC or similar situations do you expect that one component > might match but not the other? > > - Philip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 18:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgTAL-0006he-Cp; Tue, 24 Apr 2007 18:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgTAG-0006fI-8e for mmusic@ietf.org; Tue, 24 Apr 2007 18:07:12 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgTAF-0000nj-RH for mmusic@ietf.org; Tue, 24 Apr 2007 18:07:12 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Apr 2007 15:07:10 -0700 X-IronPort-AV: i="4.14,448,1170662400"; d="scan'208"; a="140151955:sNHT54750105" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3OM7B4I007600; Tue, 24 Apr 2007 15:07:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OM7AMb025327; Tue, 24 Apr 2007 22:07:11 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 15:07:09 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 15:07:08 -0700 Message-ID: <462E7F8B.7020405@cisco.com> Date: Tue, 24 Apr 2007 18:07:07 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 22:07:08.0698 (UTC) FILETIME=[E6C4CFA0:01C786BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1800; t=1177452431; x=1178316431; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Question=20on=20ICE=3A=20Why=20allow=20FQDNs=20for=20 candidate=20addresses? |Sender:=20; bh=BhIvX0xhjHWxffL/JK9u0LSKOjngBUAcrnQwsKYNUDs=; b=FHcdTMPqnerOzbqRJbclDhHBWVrUyPgQBblwh6sEZ8EwSJFXbw3jv4jJmMa4xB2eBgvZ/1YX dIwZwLuJa20QbIt/Th0ZLd2Xy7mUo7YOGOEL7vU7KYZuTGphOB8bte8I; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I added this a long time back to address some concerns around privacy. The idea was if an enterprise, say, didn't want to reveal its private addresses to the outside world, the agent could use dynDNS or something similar in conjunction with somewhat randomized hostnames, i.e., f7asff.enterprise.com. In the outgoing offer, this would be unresolvable by anyone except someone within the same enterprise. Furthermore, if the agent used a different hostname for every call, things would be uncorrelatable to the outside world (beyond coming from the same enterprise). -Jonathan R. Philip Matthews wrote: > Jonathan: > > ICE-15 allows the address of a candidate to be specified using a FQDN > rather than an IP address: > > : is taken from RFC 4566 [10]. It is the IP > address of the candidate, allowing for IPv4 addresses, IPv6 > addresses and FQDNs. An IP address SHOULD be used, but an FQDN > MAY be used in place of an IP address. In that case, when > receiving an offer or answer containing an FQDN in an a=candidate > attribute, the FQDN is looked up in the DNS using an A or AAAA > record, and the resulting IP address is used for the remainder of > ICE processing. > > What is the motivation for allowing this? > I am concerned that this makes an implementation more complex, > and I would like to know why we think this is important. > > - Philip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Apr 24 22:28:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXEz-0001mj-KR; Tue, 24 Apr 2007 22:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXEy-0001mZ-P8 for mmusic@ietf.org; Tue, 24 Apr 2007 22:28:20 -0400 Received: from web52106.mail.re2.yahoo.com ([206.190.48.109]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgXEy-0005t4-9P for mmusic@ietf.org; Tue, 24 Apr 2007 22:28:20 -0400 Received: (qmail 71206 invoked by uid 60001); 25 Apr 2007 02:28:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Cf/IUBpHYT+7r7/5mAppmmmzJY6fzcqtnD4rKg8xCL/7NrJSxwhVKxk6Y7zbEzsgZM/CkwQqLKilLsXD2ZYul0DiPZqeV9wcfEln3unJvnDFZ0CyhipSpPE7j1Xza6BHsB7/giVoS4DYxNwtaWdSIGoHdAf405Qe1b1ERj8CKTI=; X-YMail-OSG: SAVmqeAVM1m5HHBqxjlgYvut9rLKhVGKj8xAWWjIZIdNlVe2pGdjzt_2K64FcpXgsE49h4hOWj8PDOT.cRjHlZhTQue.R2XGAJH.1ubYkrWBPCHGke2EmtHySmAEHY5ejAOczMlIq33c01l9IodVGQ-- Received: from [209.220.171.100] by web52106.mail.re2.yahoo.com via HTTP; Tue, 24 Apr 2007 19:28:20 PDT Date: Tue, 24 Apr 2007 19:28:20 -0700 (PDT) From: sunil bhargo Subject: Re: [MMUSIC] RTSP: Speed header To: Magnus Westerlund , "Ingemar Johansson S \(LU/EAB\)" In-Reply-To: <462DB9D3.80707@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <75366.70779.qm@web52106.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Ross Finlayson , mmusic@ietf.org, Henning Schulzrinne X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Though there are other methods but if the client wants to initially start the playback quickly/fill the initial buffers faster then Scale=1 and Speed=2 (greater than bitrate) can be used. Also these headers can help a proxy(case of reverse proxy) to maintain the connections to the server for a lesser duration of time as it can ask the server to stream the data at a higher rate and then satisfy the request locally. These headers can help though basically only if the player/client has a way to intelligently detect the available bandwidth either through some packet-pair algorithm or some equivalent of that. Most of the clients i think have a variation of these headers if not the same headers. regards, sunil bhargo --- Magnus Westerlund wrote: > Ingemar Johansson S (LU/EAB) skrev: > > Hi > > > > Reading this makes me think of many of the sites > out there that allows > > the user watch video clips, to me it seems like > the download speed is > > faster than the actual playout speed. > > One such example is YouTube, the benefit is that > one can quite easily > > fastforward in the videoclip with very little > extra delay. > > Cannot tell if it is implemented as streaming or > file download or how > > YouTube works on a technical level but anyway the > functionality as seen > > by the user is there. > > > > downloading at slightly faster than media speed or > even at full fair > share is fine for media file. However for streaming > there are to some > degree not necessary to buffer enormous amounts > because you loose the > interactivity, or at least you will be forced to > flush you buffer at > time you change your playback point or so. > > Lets wait and see a few more days, but so far there > seem to be little > real interest for speed. Especially its problematic > relation to > congestion control makes it difficult to use. > Because the request can > only be fulfilled if the actual bandwidth is > available. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 04:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcuR-0008E5-IL; Wed, 25 Apr 2007 04:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgcuQ-0008Dl-5r for mmusic@ietf.org; Wed, 25 Apr 2007 04:31:30 -0400 Received: from prix.tandberg.no ([194.196.35.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgcuO-00014J-Dy for mmusic@ietf.org; Wed, 25 Apr 2007 04:31:30 -0400 Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25]) by prix.tandberg.no (8.12.11.20060308/8.12.10) with ESMTP id l3P8VGe4008163; Wed, 25 Apr 2007 10:31:17 +0200 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by 47mail.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 10:31:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was RE: [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Date: Wed, 25 Apr 2007 10:31:15 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB268CC3@oslexcp1.eu.tandberg.int> In-Reply-To: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD20FA@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to modify RFC3890 TIAS in offer/answer Was RE: [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Thread-Index: Acdn6mV7RvdCSEKsS5ew8hdKBSP3egAeU+fgBd+tG7ABy+/cUA== From: "Geir Arne Sandbakken" To: "Desineni, Harikishan" , X-OriginalArrivalTime: 25 Apr 2007 08:31:16.0873 (UTC) FILETIME=[179ED790:01C78714] X-Scanned-By: MIMEDefang 2.45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: Magnus Westerlund , roni.even@polycom.co.il, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Harikishan, We have been using TIAS in the 'recv' direction for quite a while, and I know of multiple other implementations. Think we have been promoting the usage in the last 3 SIPit's, and changing the direction will lead to serious interoperability issues.=20 I do agree that a 'send' direction attribute is desirable as additional bandwidth information, and I hope it can be done without breaking existing implementations. Cheers, Geir Arne > -----Original Message----- > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > Sent: 17 April 2007 20:40 > To: mmusic@ietf.org > Cc: Magnus Westerlund; roni.even@polycom.co.il; Colin Perkins > Subject: Proposal to modify RFC3890 TIAS in offer/answer Was RE: > [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt >=20 > Some issues with the offer/answer usage of TIAS (defined in RFC3890) > came out while discussing draft-hdesinen-mmusic-oa-send-bw-attr-02.txt. >=20 > RFC3890 has incorrectly defined TIAS and maxprate as 'recv' direction > attributes in offer/answer model. As 'recv' attributes, TIAS and > maxprate do not solve the bandwidth negotiation problem. For > offer/answer bw negotiation to work properly, the correct direction in > rfc3890 should have been 'send', probably with the help of few new > 'recv' direction attributes (like PO - per packet overhead at layer X, > RB- receive BW at layer X) under discussion. >=20 > A sender would choose (TIAS,maxprate) which satisfy the following > formula > TIAS + (maxprate * PO) <=3D RB (PO and RB are signaled by the = receiver) >=20 > One approach to handle this is changing the direction of (TIAS,maxprate) > to 'send' and prevent the incorrect ('recv') usage of (TIAS,maxprate) in > offer/answer model. While this appears to be the desired direction, I am > interested to know the impact of such a change on (any) existing > implementations of TIAS in offer/answer. >=20 > Please comment if you are aware of any existing implementations of TIAS > in offer/answer and also describe how exactly TIAS was used in that > particular implementation. >=20 > Thanks, > Hari >=20 >=20 > > -----Original Message----- > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > Sent: Saturday, March 17, 2007 12:26 AM > > To: Magnus Westerlund; roni.even@polycom.co.il > > Cc: Mahendran, AC; Dondeti, Lakshminath; mmusic@ietf.org; avt@ietf.org > > Subject: RE: [MMUSIC] Comments on > draft-hdesinen-mmusic-oa-send-bw-attr- > > 02.txt > > > > I copied a post (from AVT list) from Roni which states that TIAS was > > actually used in his implementation. I am not sure if it is an > > implementation in offer/answer model. > > > > [CCed AVT as TIAS was also recently discussed on AVT list] > > > > " > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Monday, January 08, 2007 7:35 AM > > To: Randell Jesup > > Cc: Stephan Wenger; avt@ietf.org > > Subject: RE: [AVT] CCM draft review -- should "bandwidth" include > > theheaderoverhead > > > > Randell, > > RFC 4890 recommends sending both TIAS and AS for backward > compatibility > > with systems that do not support TIAS. This RFC gives a good > explanation > > why to use TIAS. This is what we do in our implementation. > > " > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Friday, March 16, 2007 9:44 AM > > > To: Desineni, Harikishan > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Comments on > > draft-hdesinen-mmusic-oa-send-bw-attr- > > > 02.txt > > > > > > Desineni, Harikishan skrev: > > > > > > > > > > > > Magnus, > > > > > > > > Thanks for the comments. > > > > > > > > In the initial version, I captured the current understanding of > > (TIAS > > > > ,maxprate) based on RFC3890. > > > > > > > > Based on the current RFCs, majority of the community interprets > TIAS > > as > > > > receive only direction attribute. Instead of updating RFC3890 to > > modify > > > > TIAS as a send direction only attribute, it is better to use a new > > > > attribute 'MSR' proposed in this draft. This would also avoid any > > > > backward compatibility/inter-op issues that can arise with current > > > > implementations which (correctly) interpret TIAS as receive > > direction > > > > only attribute in offer/answer. > > > > > > Well, I wonder how there can be backwards compatibility issues with > > > something that clearly doesn't work if you actually try to use it. > > There > > > might be implementations but I can't really understand how they > could > > > work. Do you know of implementations? > > > > > > > > > > > Another approach is to add directionality to TIAS. By default, > TIAS > > is > > > > receive only (not much useful) and "TIAS/sendonly" will be send > only > > > > direction. "maxprate/send" will be packet rate in send direction. > > > > > > > > What you are proposing is the following > > > > Send direction attributes: RTP Payload rate and maxpacket rate > > > > Receive direction attributes: AS (or a new one), packet overhead > > > > > > Okay, here I think the more important question is, are we expecting > to > > > be able to specify a value on another level than IP? If not I think > AS > > > works fine. > > > > > > > > > > > In this draft I am proposing that 'MSR' be used for signaling RTP > > > > payload rate in 'send' direction. IMO, it is not a clean approach > to > > > > redefine TIAS to be a 'send' direction attribute. > > > > > > We disagree on this. TIAS was specified as a send direction > attribute. > > I > > > made an error in the offer/answer usage because I didn't consider > the > > > implications. And no one picked up on it. > > > > > > As I can see it in regards to RFC 3890 we have two alternatives: > > > > > > 1. Fix the offer/answer section to correctly define it to apply in > the > > > sending direction. > > > > > > 2. Obsolete usage of TIAS in Offer/Answer exchanges and only use it > > for > > > declarative usage, like in RTSP. > > > > > > If there are implementations i any numbers that interpret TIAS as a > > > receiver direction attribute then I agree alternative 2 will be > best. > > > However I would like to have some positive acknowledgments of this > > > first. This was after all revealed in the attempt to apply TIAS to > > > offer/answer in the 3GPP MTSI standardization work. Resulting in > that > > > TIAS was only included in the draft spec for a while. I don't know > if > > > some other umbrella standard has included TIAS combined with > > offer/answer. > > > > > > > > > > > I am OK with signaling packet rate in send direction. But we need > to > > > > consider whether to reuse maxprate for this or add directionality > to > > > > maxprate (maxprate/send) to avoid any inter-op issues with current > > > > implementations. > > > > > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > IETF Transport Area Director & TSVWG Chair > > > > ---------------------------------------------------------------------- > > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > > > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 04:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdCd-0007A5-4w; Wed, 25 Apr 2007 04:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdCb-00079y-Uf for mmusic@ietf.org; Wed, 25 Apr 2007 04:50:17 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdCV-0000PD-VS for mmusic@ietf.org; Wed, 25 Apr 2007 04:50:17 -0400 Received: from [61.94.220.210] (unknown [61.94.220.210]) by smtp.mxes.net (Postfix) with ESMTP id DF9E95194F; Wed, 25 Apr 2007 04:50:08 -0400 (EDT) Message-ID: <462F1644.3050401@pjsip.org> Date: Wed, 25 Apr 2007 09:50:12 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] Re: Question on Verifying ICE Support References: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> <462E7E81.2090203@cisco.com> In-Reply-To: <462E7E81.2090203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Philip Matthews , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: > Hmm. This is one of these cases where, I vaguely recall there was a > reason for this, but I cannot remember what it is. > > Thinking about it now I would have to agree with you, it certainly seems > more logical that it should be all of them. Unless I can remember why I > did it this way, I will change it. I disagree. IMO the text is correct as it is (although probably it's a bit confusing). This is what I understood from the text: To verify that ICE should be supported for the session, *either* of these conditions must be met: o the transport address (the default destination) of each media stream must be listed as one of the candidate in that media stream, OR o if rtcp attribute is present, the RTCP address must be listed as one of the candidate for the second component for each media stream. IMO requiring that all components must be listed may not work. An SBC may modify the media stream address but it leaves RTCP attribute unchanged because it doesn't support it. >> Why the "at least one component"? I don't understand why you do not >> require that there to be an a=candidate attribute for each component? If I understood correctly, of course there will be a=candidate for each component, or otherwise there will be no component! -benny > -Jonathan R. > > Philip Matthews wrote: > >> Jonathan: >> >> ICE-15 says: >> >> 5.1. Verifying ICE Support >> >> The answerer will proceed with the ICE procedures defined in this >> specification if the following are all true: >> >> o For each media stream, the default destination for at least one >> component of the media stream appears in a candidate attribute. >> For example, in the case of RTP, the IP address and port in the c >> and m line, respectively, appears in a candidate attribute, or the >> value in the rtcp attribute appears in a candidate attribute. >> >> >> Why the "at least one component"? I don't understand why you do not >> require that there to be an a=candidate attribute for each component? >> In what non-SBC or similar situations do you expect that one component >> might match but not the other? >> >> - Philip >> > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 10:53:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgirw-0001Cd-4c; Wed, 25 Apr 2007 10:53:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgiru-0001CX-Qk for mmusic@ietf.org; Wed, 25 Apr 2007 10:53:18 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgirp-00023N-AV for mmusic@ietf.org; Wed, 25 Apr 2007 10:53:18 -0400 Received: from [61.94.220.202] (unknown [61.94.220.202]) by smtp.mxes.net (Postfix) with ESMTP id EC5AE519A5; Wed, 25 Apr 2007 10:53:10 -0400 (EDT) Message-ID: <462F6B5A.3030000@pjsip.org> Date: Wed, 25 Apr 2007 15:53:14 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> In-Reply-To: <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Philip Matthews wrote: > > On 19-Apr-07, at 11:49 , Benny Prijono wrote: > >> >> I have different solution, and mine is directed towards reducing the >> number of checks. And I believe this one not only help congestion >> problem, but it could also ICE performance significantly. >> >> The idea is to use one socket for all candidates in one component. >> During pruning process, we know that srflx candidate will be pruned >> and be replaced by its base candidate. >> >> But since we use one socket for all candidates, the host candidates >> can be pruned as well, leaving just one host candidate in the check >> list for the component (note: this currently is not in ICE). >> >> If an agent is using this approach (and assuming only host and srflx >> candidates are used), the number of checks that the agent performs >> would be M for each component, where M is the number of candidates in >> that component in the remote agent. Compare this to current ICE where >> the number of checks will be "(N-1) x M" (the N-1 reflects the >> pruning of srflx candidate). >> >> I think this could work (would be interested to hear Jonathan's >> comment on this). Unfortunately it seems that the use of one socket >> per component has been deprecated long ago and it would be quite a big >> editing work to adapt the text this way. But I've been using one >> socket approach and it seems to work. > > I don't understand your proposal. > > Say I have an application that needs M components, and is running on a > box with N interfaces. Then for each interface and component, I allocate > one local port number (socket) -- No (and that is where the difference is). We only allocate *one* socket for all host and srflx candidates in one component. So even though we have N interfaces (and N host candidates), they all share the same port number. The N host candidates (of the same component) thus only differ in their IP addresses. The socket is of course bound to INADDR_ANY. So now, for host candidates, since it doesn't matter from which interface the connectivity check is sent *from*, the host candidates can be pruned, leaving only one host candidate to be used for all host candidates and server-reflexive checks. The benefit can be massive with this approach. Say a box has four interfaces (I've seen this in real life -- virtual interfaces are quite common in Windows), the agent will have 4 host candidates plus 1 srflx candidate for one component. Add RTCP, we'll have 10 candidates. If the other agent also has four interfaces, each agent will end up with 40 connectivity checks (!) to perform. Compared to if one agent use one socket, it will only have 10 connectivity checks to perform. Assuming of course if my approach works. There will be a problem with finding out which candidate to use for triggered check, I can explain my solution (if you're still interested). cheers, -benny > these are my host candidates. Then I > use STUN to determine server-reflexive and relay candidates that > correspond to each of these host candidates. > > I don't see how I can reduce anything. Can you clarify? > > - Philip > > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 11:02:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgj16-0006I5-9Q; Wed, 25 Apr 2007 11:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgj15-0006I0-V2 for mmusic@ietf.org; Wed, 25 Apr 2007 11:02:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgj14-0005e5-JJ for mmusic@ietf.org; Wed, 25 Apr 2007 11:02:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 25 Apr 2007 08:02:46 -0700 X-IronPort-AV: i="4.14,451,1170662400"; d="scan'208"; a="56140305:sNHT61825770" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3PF2kBZ012308; Wed, 25 Apr 2007 08:02:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3PF2jZT028760; Wed, 25 Apr 2007 15:02:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 08:02:45 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 08:02:45 -0700 Message-ID: <462F6D94.9050605@cisco.com> Date: Wed, 25 Apr 2007 11:02:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> In-Reply-To: <462F6B5A.3030000@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 15:02:45.0129 (UTC) FILETIME=[C7B64790:01C7874A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2711; t=1177513366; x=1178377366; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE=20reducing=20number=20of=20checks=20(w as=20Re=3A=20ICE=20pacing=09connectivity=0A=20checks) |Sender:=20; bh=T0StSc2AGv3x5MpQfJ9q4R1WLPGoSKrjmkAaOG/wXK8=; b=OzhosYzhs5C03nbrgJqr93j3uAnoEmgYEZMrTJy+N7qC4aZ1LcvGUnULs0L8BSykeo1hA4u+ itfWyWrfeACfhH6peGcZgLugqU6Axy6azRGrzvvjh9j9fR55e6EIjnRL3AGC7fWPyEzVJ2Q0bQ iv8BplUgN48ViBVvDhQnU+ezM=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Philip Matthews , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I don't see how this can possibly work. The reason why you have a separate candidate for each interface is that a check from one might succeed, but not from the other. This is because of topological issues that provide connectivity to your peer from one, but not the other. Having a single candidate for all interfaces means that ICE would only do the check from one actual interface, and thus you won't even try the others. -Jonathan R. Benny Prijono wrote: >> I don't understand your proposal. >> >> Say I have an application that needs M components, and is running on a >> box with N interfaces. Then for each interface and component, I >> allocate one local port number (socket) -- > > > No (and that is where the difference is). > > We only allocate *one* socket for all host and srflx candidates in one > component. So even though we have N interfaces (and N host candidates), > they all share the same port number. The N host candidates (of the same > component) thus only differ in their IP addresses. > > The socket is of course bound to INADDR_ANY. So now, for host > candidates, since it doesn't matter from which interface the > connectivity check is sent *from*, the host candidates can be pruned, > leaving only one host candidate to be used for all host candidates and > server-reflexive checks. > > The benefit can be massive with this approach. Say a box has four > interfaces (I've seen this in real life -- virtual interfaces are quite > common in Windows), the agent will have 4 host candidates plus 1 srflx > candidate for one component. Add RTCP, we'll have 10 candidates. If the > other agent also has four interfaces, each agent will end up with 40 > connectivity checks (!) to perform. > > Compared to if one agent use one socket, it will only have 10 > connectivity checks to perform. > > Assuming of course if my approach works. There will be a problem with > finding out which candidate to use for triggered check, I can explain my > solution (if you're still interested). > > cheers, > -benny > > > >> these are my host candidates. Then I use STUN to determine >> server-reflexive and relay candidates that correspond to each of these >> host candidates. >> >> I don't see how I can reduce anything. Can you clarify? >> >> - Philip >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 11:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjWh-0001LP-MW; Wed, 25 Apr 2007 11:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjWh-0001LK-4B for mmusic@ietf.org; Wed, 25 Apr 2007 11:35:27 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgjWf-00069X-Oj for mmusic@ietf.org; Wed, 25 Apr 2007 11:35:27 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HgjWf-0000Q4-0y; Wed, 25 Apr 2007 11:35:25 -0400 In-Reply-To: <462F6D94.9050605@cisco.com> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) Date: Wed, 25 Apr 2007 11:35:24 -0400 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I totally agree with Jonathan. It matters very much which IP address a connectivity check is sent from, and if you have 4 different interface addresses, checks must be sent from all four addresses, otherwise you are only checking the connectivity from the interfaces you are actually sending from. For example, say one interface is a WiFi interface and the other interface is an Ethernet interface. If you only send checks from the WiFi interface, and the cable connecting the WiFi access point to the internet is disconnected, then your checks will fail, but checks via the Ethernet interface might actually work. - Philip On 25-Apr-07, at 11:02 , Jonathan Rosenberg wrote: > I don't see how this can possibly work. > > The reason why you have a separate candidate for each interface is > that a check from one might succeed, but not from the other. This > is because of topological issues that provide connectivity to your > peer from one, but not the other. > > Having a single candidate for all interfaces means that ICE would > only do the check from one actual interface, and thus you won't > even try the others. > > -Jonathan R. > > > > Benny Prijono wrote: > > >>> I don't understand your proposal. >>> >>> Say I have an application that needs M components, and is running >>> on a box with N interfaces. Then for each interface and >>> component, I allocate one local port number (socket) -- >> No (and that is where the difference is). >> We only allocate *one* socket for all host and srflx candidates in >> one component. So even though we have N interfaces (and N host >> candidates), they all share the same port number. The N host >> candidates (of the same component) thus only differ in their IP >> addresses. >> The socket is of course bound to INADDR_ANY. So now, for host >> candidates, since it doesn't matter from which interface the >> connectivity check is sent *from*, the host candidates can be >> pruned, leaving only one host candidate to be used for all host >> candidates and server-reflexive checks. >> The benefit can be massive with this approach. Say a box has four >> interfaces (I've seen this in real life -- virtual interfaces are >> quite common in Windows), the agent will have 4 host candidates >> plus 1 srflx candidate for one component. Add RTCP, we'll have 10 >> candidates. If the other agent also has four interfaces, each >> agent will end up with 40 connectivity checks (!) to perform. >> Compared to if one agent use one socket, it will only have 10 >> connectivity checks to perform. >> Assuming of course if my approach works. There will be a problem >> with finding out which candidate to use for triggered check, I can >> explain my solution (if you're still interested). >> cheers, >> -benny >>> these are my host candidates. Then I use STUN to determine server- >>> reflexive and relay candidates that correspond to each of these >>> host candidates. >>> >>> I don't see how I can reduce anything. Can you clarify? >>> >>> - Philip >>> >>> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 12:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgkou-0005kr-Os; Wed, 25 Apr 2007 12:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgkot-0005km-L0 for mmusic@ietf.org; Wed, 25 Apr 2007 12:58:19 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgkop-0008CO-4L for mmusic@ietf.org; Wed, 25 Apr 2007 12:58:19 -0400 Received: from [61.94.220.106] (unknown [61.94.220.106]) by smtp.mxes.net (Postfix) with ESMTP id E0036519D8; Wed, 25 Apr 2007 12:58:11 -0400 (EDT) Message-ID: <462F8876.80201@pjsip.org> Date: Wed, 25 Apr 2007 17:57:26 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> In-Reply-To: <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org No, I think that's not true (or did I completely miss something?). But first of all, let me clarify. The candidates don't get removed; so if there are N interfaces, there will still be N host candidates being advertised in SDP. Only the checks that originates from the remaining host candidates are being removed, during pruning process. So even though there is only one (UDP) socket and with some more checks pruned, connectivity checks will be sent from *all* interfaces. Let me illustrate with an example. (please see this table with fixed width font) Agent A | Agent B candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host With usual ICE, these checks will be created on agent A: #1) 1.1.1.1:1 --> 3.3.3.3:3 #2) 1.1.1.1:1 --> 4.4.4.4:4 #3) 2.2.2.2:2 --> 3.3.3.3:3 #4) 2.2.2.2:2 --> 4.4.4.4:4 Now, if agent A uses a single socket for all host candidates, AFAIK check #3 will produce the same result as check #1, and check #4 will produce the same result as check #2. So we can prune the checks further, leaving the check list in agent A to: #1) 1.1.1.1:1 --> 3.3.3.3:3 #2) 1.1.1.1:1 --> 4.4.4.4:4 or #1) 2.2.2.2:2 --> 3.3.3.3:3 #2) 2.2.2.2:2 --> 4.4.4.4:4 (it doesn't really matter which local host candidate to use, they will produce the same result using this approach) It doesn't matter what type of interfaces are for interface 1.1.1.1 and 2.2.2.2, all that matters is the routing table in the box (remember that the socket is bound to INADDR_ANY), and the OS will decide for us which interface to use to contact 3.3.3.3 and 4.4.4.4, if the routing table says that destination 3.3.3.3 and 4.4.4.4 are indeed reachable through one of its interfaces. AFAIK this will produce *mostly* the same result as normal ICE for both successful and failed scenario. The only situation that I can think of where the result may differ is when a remote candidate may be reachable from more than one local interfaces (maybe two interfaces are configured in load balance mode?). But with ICE it's very hard to predict which interface is likely to win anyway (depending on how the implementation sets the priorities among host candidates, whether normal/aggressive mode is being used, and which response comes earlier), so I don't think it's that important. Well at least not for my use case. -benny Philip Matthews wrote: > I totally agree with Jonathan. > It matters very much which IP address a connectivity check is sent from, > and if you have 4 different interface addresses, checks must be sent > from all four addresses, otherwise you are only checking the > connectivity from the interfaces you are actually sending from. For > example, say one interface is a WiFi interface and the other interface > is an Ethernet interface. If you only send checks from the WiFi > interface, and the cable connecting the WiFi access point to the > internet is disconnected, then your checks will fail, but checks via the > Ethernet interface might actually work. > > - Philip > > On 25-Apr-07, at 11:02 , Jonathan Rosenberg wrote: > >> I don't see how this can possibly work. >> >> The reason why you have a separate candidate for each interface is >> that a check from one might succeed, but not from the other. This is >> because of topological issues that provide connectivity to your peer >> from one, but not the other. >> >> Having a single candidate for all interfaces means that ICE would only >> do the check from one actual interface, and thus you won't even try >> the others. >> >> -Jonathan R. >> >> >> >> Benny Prijono wrote: >> >> >>>> I don't understand your proposal. >>>> >>>> Say I have an application that needs M components, and is running on >>>> a box with N interfaces. Then for each interface and component, I >>>> allocate one local port number (socket) -- >>> No (and that is where the difference is). >>> We only allocate *one* socket for all host and srflx candidates in >>> one component. So even though we have N interfaces (and N host >>> candidates), they all share the same port number. The N host >>> candidates (of the same component) thus only differ in their IP >>> addresses. >>> The socket is of course bound to INADDR_ANY. So now, for host >>> candidates, since it doesn't matter from which interface the >>> connectivity check is sent *from*, the host candidates can be pruned, >>> leaving only one host candidate to be used for all host candidates >>> and server-reflexive checks. >>> The benefit can be massive with this approach. Say a box has four >>> interfaces (I've seen this in real life -- virtual interfaces are >>> quite common in Windows), the agent will have 4 host candidates plus >>> 1 srflx candidate for one component. Add RTCP, we'll have 10 >>> candidates. If the other agent also has four interfaces, each agent >>> will end up with 40 connectivity checks (!) to perform. >>> Compared to if one agent use one socket, it will only have 10 >>> connectivity checks to perform. >>> Assuming of course if my approach works. There will be a problem with >>> finding out which candidate to use for triggered check, I can explain >>> my solution (if you're still interested). >>> cheers, >>> -benny >>>> these are my host candidates. Then I use STUN to determine >>>> server-reflexive and relay candidates that correspond to each of >>>> these host candidates. >>>> >>>> I don't see how I can reduce anything. Can you clarify? >>>> >>>> - Philip >>>> >>>> >> >> --Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 15:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnFA-0003Wt-Cl; Wed, 25 Apr 2007 15:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnF7-0003Wn-RU for mmusic@ietf.org; Wed, 25 Apr 2007 15:33:34 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgnF7-0007sv-IG for mmusic@ietf.org; Wed, 25 Apr 2007 15:33:33 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HgnF7-00064J-H5; Wed, 25 Apr 2007 15:33:33 -0400 In-Reply-To: <462F8876.80201@pjsip.org> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) Date: Wed, 25 Apr 2007 15:33:35 -0400 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 25-Apr-07, at 12:57 , Benny Prijono wrote: > > No, I think that's not true (or did I completely miss something?). > > But first of all, let me clarify. The candidates don't get removed; > so if there are N interfaces, there will still be N host candidates > being advertised in SDP. Only the checks that originates from the > remaining host candidates are being removed, during pruning process. > > So even though there is only one (UDP) socket and with some more > checks pruned, connectivity checks will be sent from *all* > interfaces. Let me illustrate with an example. > > (please see this table with fixed width font) > > Agent A | Agent B > candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host > candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host > > With usual ICE, these checks will be created on agent A: > > #1) 1.1.1.1:1 --> 3.3.3.3:3 > #2) 1.1.1.1:1 --> 4.4.4.4:4 > #3) 2.2.2.2:2 --> 3.3.3.3:3 > #4) 2.2.2.2:2 --> 4.4.4.4:4 > > Now, if agent A uses a single socket for all host candidates, AFAIK > check #3 will produce the same result as check #1, and check #4 > will produce the same result as check #2. This is where I disagree. In my opinion, check #1 and check #3 are not the same (and nor are checks #2 and #4). Let me illustrate by elaborating more on my previous example. On Agent A, - say the interface with address 1.1.1.1 is a 802.11 interface that connects to an access point which then connects via ethernet to a router that connects to the Internet; and - say the interface with address 2.2.2.2 is an ethernet interface that connects to the same router. Say static/default routing is used throughout. So if someone unplugs the ethernet cable leading to the wireless access point, the box on which Agent A runs will not see any routing updates or similar. However, packets sent out the wireless interface will just be dropped (hopefully with an ICMP Destination Unreachable reply, but even that is not certain). In this case, check #1 and #2 will fail, but check #3 and check #4 will succeed. However, your comment does point that you have to force the packets out the correct interface. If you just say "send to 3.3.3.3", and let the box choose the outgoing interface, then you are not implementing ICE properly. You have to tell the box "send to 3.3.3.3 via interface 1.1.1.1" or "send to 3.3.3.3 via interface 2.2.2.2". Is this making any sense? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 16:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgnry-0008Lc-Uk; Wed, 25 Apr 2007 16:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgnrw-0008Ke-Uw for mmusic@ietf.org; Wed, 25 Apr 2007 16:13:40 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgnru-0006z6-LL for mmusic@ietf.org; Wed, 25 Apr 2007 16:13:40 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hgnru-0001rN-0r; Wed, 25 Apr 2007 16:13:38 -0400 In-Reply-To: <462E7F8B.7020405@cisco.com> References: <462E7F8B.7020405@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Wed, 25 Apr 2007 16:13:37 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I can vaguely see how this might work. But are there people who actually want to do this? Moreover, are there not other ways to achieve the same effect? 1) Use an SBC to remove host candidates when signaling outside the enterprise, OR 2) Look at the AoR that you are signaling -- if the domain part does not match your domain (or perhaps a short list of domains), then remove all the host candidates from the SDP. [I believe that, from ICE-10 onwards, the need to include host candidates to "support" other candidates has gone away -- e.g., ICE-08 required you to include the host candidate that generated a peer-reflexive candidate] Anyway, if we decide this is a good feature, then I think it should be described in the security considerations section and/or Appendix B. - Philip On 24-Apr-07, at 18:07 , Jonathan Rosenberg wrote: > I added this a long time back to address some concerns around > privacy. The idea was if an enterprise, say, didn't want to reveal > its private addresses to the outside world, the agent could use > dynDNS or something similar in conjunction with somewhat randomized > hostnames, i.e., f7asff.enterprise.com. In the outgoing offer, this > would be unresolvable by anyone except someone within the same > enterprise. Furthermore, if the agent used a different hostname for > every call, things would be uncorrelatable to the outside world > (beyond coming from the same enterprise). > > -Jonathan R. > > Philip Matthews wrote: > >> Jonathan: >> ICE-15 allows the address of a candidate to be specified using a >> FQDN rather than an IP address: >> : is taken from RFC 4566 [10]. It is the IP >> address of the candidate, allowing for IPv4 addresses, IPv6 >> addresses and FQDNs. An IP address SHOULD be used, but an FQDN >> MAY be used in place of an IP address. In that case, when >> receiving an offer or answer containing an FQDN in an >> a=candidate >> attribute, the FQDN is looked up in the DNS using an A or AAAA >> record, and the resulting IP address is used for the >> remainder of >> ICE processing. >> What is the motivation for allowing this? >> I am concerned that this makes an implementation more complex, >> and I would like to know why we think this is important. >> - Philip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 16:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgo3I-0002Bh-Uh; Wed, 25 Apr 2007 16:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgo3G-0002Bc-VL for mmusic@ietf.org; Wed, 25 Apr 2007 16:25:22 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgo3F-0000Fw-Mg for mmusic@ietf.org; Wed, 25 Apr 2007 16:25:22 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1Hgo3N-0004U2-Cw; Wed, 25 Apr 2007 16:25:29 -0400 In-Reply-To: <462F1644.3050401@pjsip.org> References: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> <462E7E81.2090203@cisco.com> <462F1644.3050401@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Re: Question on Verifying ICE Support Date: Wed, 25 Apr 2007 16:25:21 -0400 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I think all three of us have the same idea, and it is only a question of finding a wording that expresses this idea. The wording must take into account that the "default destination" for a particular component can be indicated either in the m and c lines, or in other attributes in the SDP. - Philip On 25-Apr-07, at 04:50 , Benny Prijono wrote: > Jonathan Rosenberg wrote: >> Hmm. This is one of these cases where, I vaguely recall there was >> a reason for this, but I cannot remember what it is. >> Thinking about it now I would have to agree with you, it certainly >> seems more logical that it should be all of them. Unless I can >> remember why I did it this way, I will change it. > > > I disagree. IMO the text is correct as it is (although probably > it's a bit confusing). This is what I understood from the text: > > To verify that ICE should be supported for the session, *either* of > these conditions must be met: > o the transport address (the default destination) of each media > stream must be listed as one of the candidate in that media > stream, OR > o if rtcp attribute is present, the RTCP address must be listed as > one of the candidate for the second component for each media > stream. > > IMO requiring that all components must be listed may not work. An > SBC may modify the media stream address but it leaves RTCP > attribute unchanged because it doesn't support it. > >>> Why the "at least one component"? I don't understand why you do not >>> require that there to be an a=candidate attribute for each >>> component? > > If I understood correctly, of course there will be a=candidate for > each component, or otherwise there will be no component! > > > -benny > > > >> -Jonathan R. >> Philip Matthews wrote: >>> Jonathan: >>> >>> ICE-15 says: >>> >>> 5.1. Verifying ICE Support >>> >>> The answerer will proceed with the ICE procedures defined in this >>> specification if the following are all true: >>> >>> o For each media stream, the default destination for at least >>> one >>> component of the media stream appears in a candidate >>> attribute. >>> For example, in the case of RTP, the IP address and port in >>> the c >>> and m line, respectively, appears in a candidate attribute, >>> or the >>> value in the rtcp attribute appears in a candidate attribute. >>> >>> >>> Why the "at least one component"? I don't understand why you do not >>> require that there to be an a=candidate attribute for each >>> component? >>> In what non-SBC or similar situations do you expect that one >>> component >>> might match but not the other? >>> >>> - Philip >>> > > > -- > Benny Prijono > http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 19:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgqTf-0006lb-N9; Wed, 25 Apr 2007 19:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgqTe-0006lS-6x for mmusic@ietf.org; Wed, 25 Apr 2007 19:00:46 -0400 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgqTd-0007ri-LS for mmusic@ietf.org; Wed, 25 Apr 2007 19:00:46 -0400 Received: by an-out-0708.google.com with SMTP id d30so28218and for ; Wed, 25 Apr 2007 16:00:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Nv0nyZA9X8U14OeNbLDfFVnQNrF+iLZyh/YBJGD+9QyqKtxBQtCtsdYujKGso5cisp9+ssg5vN+GIAuoHqLAYbujBGzWhTfxBx+9TQe/4HRfPND+JzSCGqMxztE1dvEq2s0Ab2YSQhErC8kjdJ5jZg8i9/hl2ZZ9K+07r7O1hm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lbwrK9EocsI4dOf6LIvIcAFsRwrpwjH5jaEC723k2rgvYpKCT6febwdr7dDHXcoN7bjeI34A9njc0J1s5khQUh5gyigyYiNkpGRkHS6AgpJQbSbhTZ+qgAtCGafYhyxDueL8J77diemYp4UjpIEnWR0zgXJODu1vOjzbLnpSHvU= Received: by 10.100.119.14 with SMTP id r14mr647169anc.1177542045109; Wed, 25 Apr 2007 16:00:45 -0700 (PDT) Received: by 10.100.173.16 with HTTP; Wed, 25 Apr 2007 16:00:45 -0700 (PDT) Message-ID: <5e6e0f30704251600g67df60fblfd7b3bb233985a93@mail.gmail.com> Date: Wed, 25 Apr 2007 17:00:45 -0600 From: Darren To: "Magnus Westerlund" Subject: Re: [MMUSIC] RTSP: Speed header In-Reply-To: <462387E3.20600@ericsson.com> MIME-Version: 1.0 References: <462387E3.20600@ericsson.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992246119==" Errors-To: mmusic-bounces@ietf.org --===============0992246119== Content-Type: multipart/alternative; boundary="----=_Part_244505_27138055.1177542045007" ------=_Part_244505_27138055.1177542045007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We have implemented a scale capability and bit rate adaptation ability on top of RTSP 1.0. It would be great to have something standard in that area. Regarding "speed", one can improve the user experience when fast-forwarding and fast-rewinding video when there is a lot of bandwidth available, such as on a local LAN. ie: 150Kbps stream sent at 2 or 3x fast forward looks really good if the 150Kbps stream is sent at 750Kbps. It allows a user to more easily scan and find a specific moment in a video stream. Having "speed" would allow one to specify exactly the behavior desired. But I'm not sure it's required given the other capabilities out there. -Darren On 4/16/07, Magnus Westerlund wrote: > > Hi, > > I while back received an email with some questions on how the Speed > header works in RTSP. There where also the issue how it interacts with > the Scale header and with bandwidth adaptation and buffer management. > > Lets do a recap of what the different mechanisms do. > > Scale: Changes the rate at which media is presented to the user. So > Scale=0.5 would mean slow motion, while Scale=5 would be fast forward in > the stream. > > Speed: Changes the media delivery rate. Speed=2 would mean that for each > second a client would receive media that takes it 2 seconds to play back > to the user. It would also mean that using RTP with a 90kHz timestamp > clock the RTP streams timestamp values would increase with 180k ticks > per second. > > Bit-rate adaptation: A way of ensuring that the media traffic does not > use more bandwidth then what is available. Which means that the server > would need to change the media bit-rate sent if there isn't enough > available for the current media stream. This could be done in a number > of ways but most commonly are done by bit-stream switching. Going from a > stored/delivered media stream in one quality to another lower quality > that requires less bit-rate. > > Buffer Management: An attempt to keep the clients buffer in a healthy > state, aiming at keeping a certain amount of media time present in > buffer to safeguard against temporary or longer term changes of bit-rate > capacity available to the streaming session. Thus giving the server time > to react to the change before an buffer-underrun situation occurs. At > the same time safe-guard against overflowing buffers. This is for > example done in 3GPP Packet-based Streaming Service (26.234 Rel6) where > additional feedback and configuration information is provided for the > buffer status. Thus allowing a server to change media transmission rate > on the fly. Which is equivalent to a client using Speed. However it also > needs to be able to perform bit-rate adaptation so that one can lower > the quality but increase the speed to refill the buffer. > > The interactions between the different behaviors are interesting but can > become quite complex. For example the total bit-rate is speed x normal > bit-rate. It might also be influenced by the Scale used as fast > forwarding could be accomplished by simple turning up the frame-rate for > video and rewriting the timestamps compared to scale 1. Slow motion > could also mean that the bit-rate gets lower. However if trans-coding is > done to handle Scale then bit-rate may not change at all. If there are a > limited amount of bit-rate this means that bit-rate adaptation needs to > step in and do what it can to keep bit-rate within limitations. If that > can only operate on the media stream or can also contradict speed or > influence how scale is handled is quite undefined. > > I do have a few question due to this: > > 1. Are people implementing Speed? > > 2. If you are using Speed, how are you doing that, as I have described > or otherwise? > > 3. Should we remove speed from base specification? > > 4. If not, what do you think needs to be clarified and do you have text > proposal? > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > ------=_Part_244505_27138055.1177542045007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We have implemented a scale capability and bit rate adaptation ability on top of RTSP 1.0.  It would be great to have something standard in that area.

Regarding "speed", one can improve the user experience when fast-forwarding and fast-rewinding video when there is a lot of bandwidth available, such as on a local LAN.

ie: 150Kbps stream sent at 2 or 3x fast forward looks really good if the 150Kbps stream is sent at 750Kbps.  It allows a user to more easily scan and find a specific moment in a video stream.

Having "speed" would allow one to specify exactly the behavior desired.  But I'm not sure it's required given the other capabilities out there.

-Darren

On 4/16/07, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

I while back received an email with some questions on how the Speed
header works in RTSP. There where also the issue how it interacts with
the Scale header and with bandwidth adaptation and buffer management.

Lets do a recap of what the different mechanisms do.

Scale: Changes the rate at which media is presented to the user. So
Scale=0.5 would mean slow motion, while Scale=5 would be fast forward in
the stream.

Speed: Changes the media delivery rate. Speed=2 would mean that for each
second a client would receive media that takes it 2 seconds to play back
to the user. It would also mean that using RTP with a 90kHz timestamp
clock the RTP streams timestamp values would increase with 180k ticks
per second.

Bit-rate adaptation: A way of ensuring that the media traffic does not
use more bandwidth then what is available. Which means that the server
would need to change the media bit-rate sent if there isn't enough
available for the current media stream. This could be done in a number
of ways but most commonly are done by bit-stream switching. Going from a
stored/delivered media stream in one quality to another lower quality
that requires less bit-rate.

Buffer Management: An attempt to keep the clients buffer in a healthy
state, aiming at keeping a certain amount of media time present in
buffer to safeguard against temporary or longer term changes of bit-rate
capacity available to the streaming session. Thus giving the server time
to react to the change before an buffer-underrun situation occurs. At
the same time safe-guard against overflowing buffers. This is for
example done in 3GPP Packet-based Streaming Service (26.234 Rel6) where
additional feedback and configuration information is provided for the
buffer status. Thus allowing a server to change media transmission rate
on the fly. Which is equivalent to a client using Speed. However it also
needs to be able to perform bit-rate adaptation so that one can lower
the quality but increase the speed to refill the buffer.

The interactions between the different behaviors are interesting but can
become quite complex. For example the total bit-rate is speed x normal
bit-rate. It might also be influenced by the Scale used as fast
forwarding could be accomplished by simple turning up the frame-rate for
video and rewriting the timestamps compared to scale 1. Slow motion
could also mean that the bit-rate gets lower. However if trans-coding is
done to handle Scale then bit-rate may not change at all. If there are a
limited amount of bit-rate this means that bit-rate adaptation needs to
step in and do what it can to keep bit-rate within limitations. If that
can only operate on the media stream or can also contradict speed or
influence how scale is handled is quite undefined.

I do have a few question due to this:

1. Are people implementing Speed?

2. If you are using Speed, how are you doing that, as I have described
or otherwise?

3. Should we remove speed from base specification?

4. If not, what do you think needs to be clarified and do you have text
proposal?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

------=_Part_244505_27138055.1177542045007-- --===============0992246119== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0992246119==-- From mmusic-bounces@ietf.org Wed Apr 25 22:17:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtXh-0005ML-U8; Wed, 25 Apr 2007 22:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtXg-0005MG-7K for mmusic@ietf.org; Wed, 25 Apr 2007 22:17:08 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgtXb-0006gF-Oq for mmusic@ietf.org; Wed, 25 Apr 2007 22:17:08 -0400 Received: from [61.94.220.212] (unknown [61.94.220.212]) by smtp.mxes.net (Postfix) with ESMTP id 57D0651947; Wed, 25 Apr 2007 22:16:30 -0400 (EDT) Message-ID: <46300B72.1010906@pjsip.org> Date: Thu, 26 Apr 2007 03:16:18 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> In-Reply-To: <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Philip Matthews wrote: >> (please see this table with fixed width font) >> >> Agent A | Agent B >> candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host >> candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host >> >> With usual ICE, these checks will be created on agent A: >> >> #1) 1.1.1.1:1 --> 3.3.3.3:3 >> #2) 1.1.1.1:1 --> 4.4.4.4:4 >> #3) 2.2.2.2:2 --> 3.3.3.3:3 >> #4) 2.2.2.2:2 --> 4.4.4.4:4 >> >> Now, if agent A uses a single socket for all host candidates, AFAIK >> check #3 will produce the same result as check #1, and check #4 will >> produce the same result as check #2. > > This is where I disagree. In my opinion, check #1 and check #3 are not > the same (and nor are checks #2 and #4). > Let me illustrate by elaborating more on my previous example. > On Agent A, > - say the interface with address 1.1.1.1 is a 802.11 interface that > connects to an access point which then connects via ethernet to a router > that connects to the Internet; and > - say the interface with address 2.2.2.2 is an ethernet interface > that connects to the same router. > Say static/default routing is used throughout. So if someone unplugs the > ethernet cable leading to the wireless access point, the box on which > Agent A runs will not see any routing updates or similar. However, > packets sent out the wireless interface will just be dropped (hopefully > with an ICMP Destination Unreachable reply, but even that is not certain). > In this case, check #1 and #2 will fail, but check #3 and check #4 will > succeed. Let me come back to this after I explain more about my approach below, since there seem to be a misunderstanding. > However, your comment does point that you have to force the packets out > the correct interface. No, that is exactly what you MUST NOT do when using my approach! Using my approach, socket MUST ALWAYS be bound to INADDR_ANY (0.0.0.0), to allow the OS to choose the appropriate interface when sending the request. There seems to be a misunderstanding. When I said that the agent perform this connectivity check (using my approach): 1.1.1.1:1 --> 3.3.3.3:3 It doesn't mean that the agent must somehow force the socket to send from interface 1.1.1.1:1. No, that's not what I meant. What I meant is that the agent should choose local host candidate 1.1.1.1:1 as the local candidate of the check. But as I said, it doesn't really matter which local candidate to use as the local part of the check, since all candidates shares the same socket. The socket itself is still bound to INADDR_ANY, to allow the OS to choose which interface to send the packet from. We don't need to care what interface is chosen for the packet. If the connectivity is successful the peer will tell us what it is in XOR-MAPPED-ADDRESS attribute in the response. I hope I'm making myself clear. Now back to the examples. Case 1: ============= Suppose an agent has these connectivity checks as the result of pairing process with normal ICE: #1) 1.1.1.1:1 --> 3.3.3.3:3 #2) 1.1.1.1:1 --> 4.4.4.4:4 #3) 2.2.2.2:2 --> 3.3.3.3:3 #4) 2.2.2.2:2 --> 4.4.4.4:4 And it has this routing table: 1.1.1.0/24 use interface 1.1.1.1 2.2.2.0/24 use interface 2.2.2.2 0.0.0.0/0 (default) use interface 2.2.2.2 Now even if interface 1.1.1.1 is up, check #1 and #2 will always fail (immediately with ENETUNREACH/EHOSTUNREACH error, at least on Windows and Linux) if you use standard ICE, so the question is why bother creating these checks in the first place? With my approach, these checks will be created instead: #1) 0.0.0.0:0 --> 3.3.3.3:3 #2) 0.0.0.0:0 --> 4.4.4.4:4 (I put 0.0.0.0:0 as the local part to make it clearer that the application does not specify which interface to use). With this approach, the OS will choose for us which interface to use for sending the request, and in this case it will choose interface 2.2.2.2. So both approaches yield the same result. Case 2: =========== Another example, suppose two agents are interconnected like this: Agent A Agent B +-----------------+ +-----------------+ | wifi: 1.1.1.A | <--------------------->| 1.1.1.B/wifi | | | | | | eth: 2.2.2.A | <--------------------->| 2.2.2.B/eth | +-----------------+ +-----------------+ Routing table in agent A is like this: 1.1.1.0/24 use interface 1.1.1.A 2.2.2.0/24 use interface 2.2.2.A With normal ICE, agent A will have these checks: #1) 1.1.1.A --> 1.1.1.B #2) 1.1.1.A --> 2.2.2.B #3) 2.2.2.A --> 1.1.1.B #4) 2.2.2.A --> 2.2.2.B Running the checks, check #2 and #3 will fail immediately with EHOSTUNREACH/ENETUNREACH error generated by the OS (well at least this is true with Windows and Linux). So only check #1 and #4 will succeed, and these valid pairs will be generated: pair (1.1.1.A, 1.1.1.B) pair (2.2.2.A, 2.2.2.B) Using my approach, agent A will have these checks: #1) 0.0.0.0:0 --> 1.1.1.B #2) 0.0.0.0:0 --> 2.2.2.B This will produce the same valid pair as normal ICE, but savings of two connectivity checks *not* performed. Case 3: ============= Using configuration in case 2 above, suppose the WiFi connection failed. With normal ICE, checks #1, #2, and #3 will fail, so only one pair will be generated in valid list: pair (2.2.2.A, 2.2.2.B) With my approach check #1 will fail too, and it will also produce the same, one pair in the valid list. > If you just say "send to 3.3.3.3", and let the > box choose the outgoing interface, then you are not implementing ICE > properly. You have to tell the box "send to 3.3.3.3 via interface > 1.1.1.1" or "send to 3.3.3.3 via interface 2.2.2.2". > > Is this making any sense? IMO, for all practical purposes, there is absolutely no difference between explicitly choosing which interface to use and letting the OS choose which interface to use. They will produce the same result, but my approach is more optimized! And anyway, we will not use this local interface as the local part of our valid list, but rather the address in the XOR-MAPPED-ADDRESS. So I failed to see why we should call this "not a proper ICE implementation". The way I see it, it's even cooler than ICE! -benny > - Philip > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 22:18:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtYw-0005r5-G3; Wed, 25 Apr 2007 22:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtYu-0005qw-PT for mmusic@ietf.org; Wed, 25 Apr 2007 22:18:25 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgtYq-00077a-Qm for mmusic@ietf.org; Wed, 25 Apr 2007 22:18:24 -0400 Received: from [61.94.220.212] (unknown [61.94.220.212]) by smtp.mxes.net (Postfix) with ESMTP id A26FC51950; Wed, 25 Apr 2007 22:18:00 -0400 (EDT) Message-ID: <46300B72.1010906@pjsip.org> Date: Thu, 26 Apr 2007 03:16:18 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> In-Reply-To: <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Philip Matthews wrote: >> (please see this table with fixed width font) >> >> Agent A | Agent B >> candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host >> candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host >> >> With usual ICE, these checks will be created on agent A: >> >> #1) 1.1.1.1:1 --> 3.3.3.3:3 >> #2) 1.1.1.1:1 --> 4.4.4.4:4 >> #3) 2.2.2.2:2 --> 3.3.3.3:3 >> #4) 2.2.2.2:2 --> 4.4.4.4:4 >> >> Now, if agent A uses a single socket for all host candidates, AFAIK >> check #3 will produce the same result as check #1, and check #4 will >> produce the same result as check #2. > > This is where I disagree. In my opinion, check #1 and check #3 are not > the same (and nor are checks #2 and #4). > Let me illustrate by elaborating more on my previous example. > On Agent A, > - say the interface with address 1.1.1.1 is a 802.11 interface that > connects to an access point which then connects via ethernet to a router > that connects to the Internet; and > - say the interface with address 2.2.2.2 is an ethernet interface > that connects to the same router. > Say static/default routing is used throughout. So if someone unplugs the > ethernet cable leading to the wireless access point, the box on which > Agent A runs will not see any routing updates or similar. However, > packets sent out the wireless interface will just be dropped (hopefully > with an ICMP Destination Unreachable reply, but even that is not certain). > In this case, check #1 and #2 will fail, but check #3 and check #4 will > succeed. Let me come back to this after I explain more about my approach below, since there seem to be a misunderstanding. > However, your comment does point that you have to force the packets out > the correct interface. No, that is exactly what you MUST NOT do when using my approach! Using my approach, socket MUST ALWAYS be bound to INADDR_ANY (0.0.0.0), to allow the OS to choose the appropriate interface when sending the request. There seems to be a misunderstanding. When I said that the agent perform this connectivity check (using my approach): 1.1.1.1:1 --> 3.3.3.3:3 It doesn't mean that the agent must somehow force the socket to send from interface 1.1.1.1:1. No, that's not what I meant. What I meant is that the agent should choose local host candidate 1.1.1.1:1 as the local candidate of the check. But as I said, it doesn't really matter which local candidate to use as the local part of the check, since all candidates shares the same socket. The socket itself is still bound to INADDR_ANY, to allow the OS to choose which interface to send the packet from. We don't need to care what interface is chosen for the packet. If the connectivity is successful the peer will tell us what it is in XOR-MAPPED-ADDRESS attribute in the response. I hope I'm making myself clear. Now back to the examples. Case 1: ============= Suppose an agent has these connectivity checks as the result of pairing process with normal ICE: #1) 1.1.1.1:1 --> 3.3.3.3:3 #2) 1.1.1.1:1 --> 4.4.4.4:4 #3) 2.2.2.2:2 --> 3.3.3.3:3 #4) 2.2.2.2:2 --> 4.4.4.4:4 And it has this routing table: 1.1.1.0/24 use interface 1.1.1.1 2.2.2.0/24 use interface 2.2.2.2 0.0.0.0/0 (default) use interface 2.2.2.2 Now even if interface 1.1.1.1 is up, check #1 and #2 will always fail (immediately with ENETUNREACH/EHOSTUNREACH error, at least on Windows and Linux) if you use standard ICE, so the question is why bother creating these checks in the first place? With my approach, these checks will be created instead: #1) 0.0.0.0:0 --> 3.3.3.3:3 #2) 0.0.0.0:0 --> 4.4.4.4:4 (I put 0.0.0.0:0 as the local part to make it clearer that the application does not specify which interface to use). With this approach, the OS will choose for us which interface to use for sending the request, and in this case it will choose interface 2.2.2.2. So both approaches yield the same result. Case 2: =========== Another example, suppose two agents are interconnected like this: Agent A Agent B +-----------------+ +-----------------+ | wifi: 1.1.1.A | <--------------------->| 1.1.1.B/wifi | | | | | | eth: 2.2.2.A | <--------------------->| 2.2.2.B/eth | +-----------------+ +-----------------+ Routing table in agent A is like this: 1.1.1.0/24 use interface 1.1.1.A 2.2.2.0/24 use interface 2.2.2.A With normal ICE, agent A will have these checks: #1) 1.1.1.A --> 1.1.1.B #2) 1.1.1.A --> 2.2.2.B #3) 2.2.2.A --> 1.1.1.B #4) 2.2.2.A --> 2.2.2.B Running the checks, check #2 and #3 will fail immediately with EHOSTUNREACH/ENETUNREACH error generated by the OS (well at least this is true with Windows and Linux). So only check #1 and #4 will succeed, and these valid pairs will be generated: pair (1.1.1.A, 1.1.1.B) pair (2.2.2.A, 2.2.2.B) Using my approach, agent A will have these checks: #1) 0.0.0.0:0 --> 1.1.1.B #2) 0.0.0.0:0 --> 2.2.2.B This will produce the same valid pair as normal ICE, but savings of two connectivity checks *not* performed. Case 3: ============= Using configuration in case 2 above, suppose the WiFi connection failed. With normal ICE, checks #1, #2, and #3 will fail, so only one pair will be generated in valid list: pair (2.2.2.A, 2.2.2.B) With my approach check #1 will fail too, and it will also produce the same, one pair in the valid list. > If you just say "send to 3.3.3.3", and let the > box choose the outgoing interface, then you are not implementing ICE > properly. You have to tell the box "send to 3.3.3.3 via interface > 1.1.1.1" or "send to 3.3.3.3 via interface 2.2.2.2". > > Is this making any sense? IMO, for all practical purposes, there is absolutely no difference between explicitly choosing which interface to use and letting the OS choose which interface to use. They will produce the same result, but my approach is more optimized! And anyway, we will not use this local interface as the local part of our valid list, but rather the address in the XOR-MAPPED-ADDRESS. So I failed to see why we should call this "not a proper ICE implementation". The way I see it, it's even cooler than ICE! -benny > - Philip > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Apr 25 22:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtbM-0008Eg-0N; Wed, 25 Apr 2007 22:20:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtbK-0008Eb-SG for mmusic@ietf.org; Wed, 25 Apr 2007 22:20:54 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgtbJ-0007Na-Af for mmusic@ietf.org; Wed, 25 Apr 2007 22:20:54 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 25 Apr 2007 19:20:52 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3Q2K6D1017529; Wed, 25 Apr 2007 19:20:06 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3Q2KII9027453; Wed, 25 Apr 2007 19:20:18 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 19:20:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidateaddresses? Date: Wed, 25 Apr 2007 19:20:42 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D227573D8@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidateaddresses? Thread-Index: AceHdmH9Bk0+tQRVRqC0RT2BDi6a4AAMXjeQ References: <462E7F8B.7020405@cisco.com> From: "Henry Sinnreich" To: "Philip Matthews" , "Jonathan Rosenberg" X-OriginalArrivalTime: 26 Apr 2007 02:20:44.0391 (UTC) FILETIME=[7E710F70:01C787A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org >1) Use an SBC to remove host candidates when signaling outside the =20 >enterprise, I hope not :-) Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, April 25, 2007 3:14 PM To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidateaddresses? I can vaguely see how this might work. But are there people who =20 actually want to do this? Moreover, are there not other ways to achieve the same effect? 1) Use an SBC to remove host candidates when signaling outside the =20 enterprise, OR 2) Look at the AoR that you are signaling -- if the domain part does =20 not match your domain (or perhaps a short list of domains), then remove all the host =20 candidates from the SDP. [I believe that, from ICE-10 onwards, the need to include host =20 candidates to "support" other candidates has gone away -- e.g., ICE-08 required you to include the =20 host candidate that generated a peer-reflexive candidate] Anyway, if we decide this is a good feature, then I think it should =20 be described in the security considerations section and/or Appendix B. - Philip On 24-Apr-07, at 18:07 , Jonathan Rosenberg wrote: > I added this a long time back to address some concerns around =20 > privacy. The idea was if an enterprise, say, didn't want to reveal =20 > its private addresses to the outside world, the agent could use =20 > dynDNS or something similar in conjunction with somewhat randomized =20 > hostnames, i.e., f7asff.enterprise.com. In the outgoing offer, this =20 > would be unresolvable by anyone except someone within the same =20 > enterprise. Furthermore, if the agent used a different hostname for =20 > every call, things would be uncorrelatable to the outside world =20 > (beyond coming from the same enterprise). > > -Jonathan R. > > Philip Matthews wrote: > >> Jonathan: >> ICE-15 allows the address of a candidate to be specified using a =20 >> FQDN rather than an IP address: >> : is taken from RFC 4566 [10]. It is the IP >> address of the candidate, allowing for IPv4 addresses, IPv6 >> addresses and FQDNs. An IP address SHOULD be used, but an FQDN >> MAY be used in place of an IP address. In that case, when >> receiving an offer or answer containing an FQDN in an =20 >> a=3Dcandidate >> attribute, the FQDN is looked up in the DNS using an A or AAAA >> record, and the resulting IP address is used for the =20 >> remainder of >> ICE processing. >> What is the motivation for allowing this? >> I am concerned that this makes an implementation more complex, >> and I would like to know why we think this is important. >> - Philip > > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ =20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 03:03:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgy0N-0005TP-9U; Thu, 26 Apr 2007 03:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgy0M-0005OQ-9H for mmusic@ietf.org; Thu, 26 Apr 2007 03:03:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgy0L-0005Yh-3E for mmusic@ietf.org; Thu, 26 Apr 2007 03:03:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DE29321641; Thu, 26 Apr 2007 09:02:52 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-83-46304e9c3532 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BDDB921635; Thu, 26 Apr 2007 09:02:52 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 09:02:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] RTSP: Speed header Date: Thu, 26 Apr 2007 09:02:51 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0504DA3464@esealmw109.eemea.ericsson.se> In-Reply-To: <5e6e0f30704251600g67df60fblfd7b3bb233985a93@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP: Speed header Thread-Index: AceHjby7ANina9i+R664TmkubepuCwAQG2+A References: <462387E3.20600@ericsson.com> <5e6e0f30704251600g67df60fblfd7b3bb233985a93@mail.gmail.com> From: "Ingemar Johansson S \(LU/EAB\)" To: "Darren" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 26 Apr 2007 07:02:52.0561 (UTC) FILETIME=[E86AD010:01C787D0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465207345==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1465207345== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C787D0.E8038552" This is a multi-part message in MIME format. ------_=_NextPart_001_01C787D0.E8038552 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I too beleive that from a user perspective "speed" can be quite useful. 80 year old grandma probably has all time in the world to watch an entire news clip while the "busy bee" probaly only have 20 minutes in the cummuter train to watch the same 30 minute news clip, and therefore wish to fastforward though the news headline about the flower exhibition. =20 One argument I read is that it is better then to use (progressive) download in the latter case instead but the result is then that depending on e.g the user behavior you will have to switch between protocols. To me it is better to use the same protocol (not a firm though though as there is always a possibility that the "busy bee" has has already subscribed to some download service instead).=20 =20 Also, as Magnus pointed out there is always the possibility to trade bitrate for speed if bandwidth is scarce. It may of course be complex interactions but if the mechanisms exists the possibilities are there. =20 Ingemar ________________________________ From: Darren [mailto:dplore@gmail.com]=20 Sent: den 26 april 2007 01:01 To: Magnus Westerlund (KI/EAB) Cc: mmusic (E-mail) Subject: Re: [MMUSIC] RTSP: Speed header =09 =09 We have implemented a scale capability and bit rate adaptation ability on top of RTSP 1.0. It would be great to have something standard in that area. =09 Regarding "speed", one can improve the user experience when fast-forwarding and fast-rewinding video when there is a lot of bandwidth available, such as on a local LAN.=20 =09 ie: 150Kbps stream sent at 2 or 3x fast forward looks really good if the 150Kbps stream is sent at 750Kbps. It allows a user to more easily scan and find a specific moment in a video stream.=20 =09 Having "speed" would allow one to specify exactly the behavior desired. But I'm not sure it's required given the other capabilities out there.=20 =09 -Darren =09 =09 On 4/16/07, Magnus Westerlund wrote:=20 Hi, =09 I while back received an email with some questions on how the Speed header works in RTSP. There where also the issue how it interacts with the Scale header and with bandwidth adaptation and buffer management.=20 =09 Lets do a recap of what the different mechanisms do. =09 Scale: Changes the rate at which media is presented to the user. So Scale=3D0.5 would mean slow motion, while Scale=3D5 would be fast forward in the stream.=20 =09 Speed: Changes the media delivery rate. Speed=3D2 would mean that for each second a client would receive media that takes it 2 seconds to play back to the user. It would also mean that using RTP with a 90kHz timestamp=20 clock the RTP streams timestamp values would increase with 180k ticks per second. =09 Bit-rate adaptation: A way of ensuring that the media traffic does not use more bandwidth then what is available. Which means that the server=20 would need to change the media bit-rate sent if there isn't enough available for the current media stream. This could be done in a number of ways but most commonly are done by bit-stream switching. Going from a=20 stored/delivered media stream in one quality to another lower quality that requires less bit-rate. =09 Buffer Management: An attempt to keep the clients buffer in a healthy state, aiming at keeping a certain amount of media time present in=20 buffer to safeguard against temporary or longer term changes of bit-rate capacity available to the streaming session. Thus giving the server time to react to the change before an buffer-underrun situation occurs. At=20 the same time safe-guard against overflowing buffers. This is for example done in 3GPP Packet-based Streaming Service (26.234 Rel6) where additional feedback and configuration information is provided for the buffer status. Thus allowing a server to change media transmission rate on the fly. Which is equivalent to a client using Speed. However it also needs to be able to perform bit-rate adaptation so that one can lower the quality but increase the speed to refill the buffer. =09 The interactions between the different behaviors are interesting but can become quite complex. For example the total bit-rate is speed x normal bit-rate. It might also be influenced by the Scale used as fast=20 forwarding could be accomplished by simple turning up the frame-rate for video and rewriting the timestamps compared to scale 1. Slow motion could also mean that the bit-rate gets lower. However if trans-coding is=20 done to handle Scale then bit-rate may not change at all. If there are a limited amount of bit-rate this means that bit-rate adaptation needs to step in and do what it can to keep bit-rate within limitations. If that=20 can only operate on the media stream or can also contradict speed or influence how scale is handled is quite undefined. =09 I do have a few question due to this: =09 1. Are people implementing Speed? =09 2. If you are using Speed, how are you doing that, as I have described=20 or otherwise? =09 3. Should we remove speed from base specification? =09 4. If not, what do you think needs to be clarified and do you have text proposal? =09 Cheers =09 Magnus Westerlund =09 IETF Transport Area Director & TSVWG Chair=20 =09 ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M =09 ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287=20 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com =09 ----------------------------------------------------------------------=20 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic=20 =09 ------_=_NextPart_001_01C787D0.E8038552 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I too=20 beleive that from a user perspective "speed" can be quite useful. = 80 year=20 old grandma probably has all time in the world to watch an entire news = clip=20 while the "busy bee" probaly only have 20 minutes in the cummuter train = to watch=20 the same 30 minute news clip, and therefore wish to fastforward=20 though the news headline about the flower=20 exhibition.
 
One=20 argument I read is that it is better then to use (progressive) download = in the=20 latter case instead but the result is then that depending on e.g the = user=20 behavior you will have to switch between protocols. To me it is better = to use=20 the same protocol (not a firm though though as there is always a = possibility=20 that the "busy bee" has has already subscribed to some = download=20 service instead). 
 
Also,=20 as Magnus pointed out there is always the possibility to trade bitrate = for=20 speed if bandwidth is scarce. It may of course be complex = interactions but=20 if the mechanisms exists the possibilities are = there.
 
Ingemar

From: Darren = [mailto:dplore@gmail.com]=20
Sent: den 26 april 2007 01:01
To: Magnus = Westerlund=20 (KI/EAB)
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] = RTSP:=20 Speed header

We have implemented a scale capability and bit rate = adaptation=20 ability on top of RTSP 1.0.  It would be great to have something = standard=20 in that area.

Regarding "speed", one can improve the user = experience=20 when fast-forwarding and fast-rewinding video when there is a lot of = bandwidth=20 available, such as on a local LAN.

ie: 150Kbps stream sent at = 2 or 3x=20 fast forward looks really good if the 150Kbps stream is sent at = 750Kbps. =20 It allows a user to more easily scan and find a specific moment in a = video=20 stream.

Having "speed" would allow one to specify exactly the = behavior=20 desired.  But I'm not sure it's required given the other = capabilities out=20 there.

-Darren

On 4/16/07, Magnus=20 Westerlund <magnus.westerlund@ericsson= .com>=20 wrote:
Hi,

I=20 while back received an email with some questions on how the = Speed
header=20 works in RTSP. There where also the issue how it interacts = with
the Scale=20 header and with bandwidth adaptation and buffer management. =

Lets do=20 a recap of what the different mechanisms do.

Scale: Changes = the rate=20 at which media is presented to the user. So
Scale=3D0.5 would = mean slow=20 motion, while Scale=3D5 would be fast forward in
the stream. =

Speed:=20 Changes the media delivery rate. Speed=3D2 would mean that for = each
second=20 a client would receive media that takes it 2 seconds to play = back
to the=20 user. It would also mean that using RTP with a 90kHz timestamp =
clock the=20 RTP streams timestamp values would increase with 180k ticks
per=20 second.

Bit-rate adaptation: A way of ensuring that the media = traffic=20 does not
use more bandwidth then what is available. Which means = that the=20 server
would need to change the media bit-rate sent if there = isn't=20 enough
available for the current media stream. This could be done = in a=20 number
of ways but most commonly are done by bit-stream = switching. Going=20 from a
stored/delivered media stream in one quality to another = lower=20 quality
that requires less bit-rate.

Buffer Management: An = attempt=20 to keep the clients buffer in a healthy
state, aiming at keeping = a=20 certain amount of media time present in
buffer to safeguard = against=20 temporary or longer term changes of bit-rate
capacity available = to the=20 streaming session. Thus giving the server time
to react to the = change=20 before an buffer-underrun situation occurs. At
the same time = safe-guard=20 against overflowing buffers. This is for
example done in 3GPP=20 Packet-based Streaming Service (26.234 Rel6) where
additional = feedback=20 and configuration information is provided for the
buffer status. = Thus=20 allowing a server to change media transmission rate
on the fly. = Which is=20 equivalent to a client using Speed. However it also
needs to be = able to=20 perform bit-rate adaptation so that one can lower
the quality but = increase the speed to refill the buffer.

The interactions = between the=20 different behaviors are interesting but can
become quite complex. = For=20 example the total bit-rate is speed x normal
bit-rate. It might = also be=20 influenced by the Scale used as fast
forwarding could be = accomplished by=20 simple turning up the frame-rate for
video and rewriting the = timestamps=20 compared to scale 1. Slow motion
could also mean that the = bit-rate gets=20 lower. However if trans-coding is
done to handle Scale then = bit-rate may=20 not change at all. If there are a
limited amount of bit-rate this = means=20 that bit-rate adaptation needs to
step in and do what it can to = keep=20 bit-rate within limitations. If that
can only operate on the = media=20 stream or can also contradict speed or
influence how scale is = handled is=20 quite undefined.

I do have a few question due to = this:

1. Are=20 people implementing Speed?

2. If you are using Speed, how are = you=20 doing that, as I have described
or otherwise?

3. Should = we remove=20 speed from base specification?

4. If not, what do you think = needs to=20 be clarified and do you have = text
proposal?

Cheers

Magnus=20 Westerlund

IETF Transport Area Director & TSVWG Chair=20 =
---------------------------------------------------------------------= -
Multimedia=20 Technologies, Ericsson Research=20 = EAB/TVM/M
------------------------------------------------------------= ----------
Ericsson=20 = AB            = ;    |=20 Phone +46 8 4048287
Torshamsgatan=20 23           |=20 Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | = mailto: magnus.westerlund@ericsson= .com
-------------------------------------------------------------= ---------=20

_______________________________________________
mmusic = mailing=20 list
mmusic@ietf.org
https://www1.ietf.= org/mailman/listinfo/mmusic=20

------_=_NextPart_001_01C787D0.E8038552-- --===============1465207345== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1465207345==-- From mmusic-bounces@ietf.org Thu Apr 26 07:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1vX-0001H5-UM; Thu, 26 Apr 2007 07:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1vW-0001H0-UA for mmusic@ietf.org; Thu, 26 Apr 2007 07:14:18 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh1vT-0005PK-Iu for mmusic@ietf.org; Thu, 26 Apr 2007 07:14:18 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hh1vS-0007s4-2w; Thu, 26 Apr 2007 07:14:15 -0400 In-Reply-To: <46300B72.1010906@pjsip.org> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> <46300B72.1010906@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E86095C-3C83-4FA4-98AC-F3A8D9570049@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) Date: Thu, 26 Apr 2007 07:14:17 -0400 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org See inline. -- Philip On 25-Apr-07, at 22:16 , Benny Prijono wrote: > Philip Matthews wrote: >>> (please see this table with fixed width font) >>> >>> Agent A | Agent B >>> candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host >>> candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host >>> >>> With usual ICE, these checks will be created on agent A: >>> >>> #1) 1.1.1.1:1 --> 3.3.3.3:3 >>> #2) 1.1.1.1:1 --> 4.4.4.4:4 >>> #3) 2.2.2.2:2 --> 3.3.3.3:3 >>> #4) 2.2.2.2:2 --> 4.4.4.4:4 >>> >>> Now, if agent A uses a single socket for all host candidates, >>> AFAIK check #3 will produce the same result as check #1, and >>> check #4 will produce the same result as check #2. >> This is where I disagree. In my opinion, check #1 and check #3 are >> not the same (and nor are checks #2 and #4). >> Let me illustrate by elaborating more on my previous example. >> On Agent A, >> - say the interface with address 1.1.1.1 is a 802.11 interface >> that connects to an access point which then connects via ethernet >> to a router that connects to the Internet; and >> - say the interface with address 2.2.2.2 is an ethernet >> interface that connects to the same router. >> Say static/default routing is used throughout. So if someone >> unplugs the ethernet cable leading to the wireless access point, >> the box on which Agent A runs will not see any routing updates or >> similar. However, packets sent out the wireless interface will >> just be dropped (hopefully with an ICMP Destination Unreachable >> reply, but even that is not certain). >> In this case, check #1 and #2 will fail, but check #3 and check #4 >> will succeed. > > Let me come back to this after I explain more about my approach > below, since there seem to be a misunderstanding. > > >> However, your comment does point that you have to force the >> packets out the correct interface. > > No, that is exactly what you MUST NOT do when using my approach! > > Using my approach, socket MUST ALWAYS be bound to INADDR_ANY > (0.0.0.0), to allow the OS to choose the appropriate interface when > sending the request. > > There seems to be a misunderstanding. When I said that the agent > perform this connectivity check (using my approach): > > 1.1.1.1:1 --> 3.3.3.3:3 > > It doesn't mean that the agent must somehow force the socket to > send from interface 1.1.1.1:1. No, that's not what I meant. > > What I meant is that the agent should choose local host candidate > 1.1.1.1:1 as the local candidate of the check. But as I said, it > doesn't really matter which local candidate to use as the local > part of the check, since all candidates shares the same socket. > > The socket itself is still bound to INADDR_ANY, to allow the OS to > choose which interface to send the packet from. We don't need to > care what interface is chosen for the packet. If the connectivity > is successful the peer will tell us what it is in XOR-MAPPED- > ADDRESS attribute in the response. > > I hope I'm making myself clear. > > Now back to the examples. > > > Case 1: > ============= > > > Suppose an agent has these connectivity checks as the result of > pairing process with normal ICE: > > #1) 1.1.1.1:1 --> 3.3.3.3:3 > #2) 1.1.1.1:1 --> 4.4.4.4:4 > #3) 2.2.2.2:2 --> 3.3.3.3:3 > #4) 2.2.2.2:2 --> 4.4.4.4:4 > > And it has this routing table: > > 1.1.1.0/24 use interface 1.1.1.1 > 2.2.2.0/24 use interface 2.2.2.2 > 0.0.0.0/0 (default) use interface 2.2.2.2 > > Now even if interface 1.1.1.1 is up, check #1 and #2 will always > fail (immediately with ENETUNREACH/EHOSTUNREACH error, at least on > Windows and Linux) if you use standard ICE, so the question is why > bother creating these checks in the first place? > > With my approach, these checks will be created instead: > > #1) 0.0.0.0:0 --> 3.3.3.3:3 > #2) 0.0.0.0:0 --> 4.4.4.4:4 > > (I put 0.0.0.0:0 as the local part to make it clearer that the > application does not specify which interface to use). > > With this approach, the OS will choose for us which interface to > use for sending the request, and in this case it will choose > interface 2.2.2.2. > > So both approaches yield the same result. Let's change your example to have the default route point out interface 1.1.1.1 rather than interface 2.2.2.2 (this could easily happen, after all). Then let's merge this with my example where 1.1.1.1 is a 802.11 interface which leads to an Access Point whose cable in unplugged (so packets are dropped at the Access Point rather than being forwarded), while 2.2.2.2 is an Ethernet interface and has proper Internet connectivity. Under these conditions, your approach will always send out interface 1.1.1.1 (in effect, only doing checks #1 and #2), and both of these checks will fail. However, assuming other things are OK, a working path could be found using interface 2.2.2.2, but your implementation will never find this path. Remember that, in my example, the OS on which Agent A is running is only using static routing, so it doesn't have any way to discover that packets sent out interface 1.1.1.1 get dropped before they reach the Internet. Does this help? - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 08:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2gb-0003OX-Au; Thu, 26 Apr 2007 08:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh2ga-0003OM-8n for mmusic@ietf.org; Thu, 26 Apr 2007 08:02:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh2gX-0005bX-72 for mmusic@ietf.org; Thu, 26 Apr 2007 08:02:56 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A06992055A; Thu, 26 Apr 2007 14:02:52 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-43-463094ec54e4 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 82E7F20496; Thu, 26 Apr 2007 14:02:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:02:52 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:02:52 +0200 Message-ID: <463094EB.10608@ericsson.com> Date: Thu, 26 Apr 2007 14:02:51 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] RTSP: Speed header References: <462387E3.20600@ericsson.com> <5e6e0f30704251600g67df60fblfd7b3bb233985a93@mail.gmail.com> <026F8EEDAD2C4342A993203088C1FC0504DA3464@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0504DA3464@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 12:02:52.0278 (UTC) FILETIME=[D115A960:01C787FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Ingemar Johansson S (LU/EAB) skrev: > > I too beleive that from a user perspective "speed" can be quite useful. > 80 year old grandma probably has all time in the world to watch an > entire news clip while the "busy bee" probaly only have 20 minutes in > the cummuter train to watch the same 30 minute news clip, and therefore > wish to fastforward though the news headline about the flower exhibition. But for that you don't need speed. you need scale unless you actually like to buffer and do the speedup locally. Which will consume more decoding resources etc. > > One argument I read is that it is better then to use (progressive) > download in the latter case instead but the result is then that > depending on e.g the user behavior you will have to switch between > protocols. To me it is better to use the same protocol (not a firm > though though as there is always a possibility that the "busy bee" has > has already subscribed to some download service instead). There are some cases where progressive download is a simple solution to the problem. However, progressive download are in many cases lousy for fast forward, jumping etc unless you download the file very fast and then do all these tricks locally. When you like to utilize available bit-rate fully and still be able to manipulate the playback then RTSP has some great benefits. > > Also, as Magnus pointed out there is always the possibility to trade > bitrate for speed if bandwidth is scarce. It may of course be complex > interactions but if the mechanisms exists the possibilities are there. > As I see it the problem with speed is how one use it. A client can use it for buffer management. Another usage is related to flow/congestion control. But that I think second is definitely the wrong decision. We need have congestion control of the media stream sent from RTSP. For all protocols that can be used. This would be much easier if RTP over DCCP was commonly available. If one runs RTP over TCP the congestion control part is well taken care of, but one loose some of the benefits of RTP over datagrams. I think we need to split this discussion into two topics: a) How to solve client buffer management? b) How to solve adaptation to available bit-rate And in relation to both these topics have discussion on how one uses Scale=x where X!=1.0 And when we actually agree on how to do the different topics then we can see if the RTSP Speed header is still part of the discussion. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 09:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3yn-0000kB-P1; Thu, 26 Apr 2007 09:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3ym-0000k6-OU for mmusic@ietf.org; Thu, 26 Apr 2007 09:25:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh3yj-0003gI-PV for mmusic@ietf.org; Thu, 26 Apr 2007 09:25:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2007 06:25:44 -0700 X-IronPort-AV: i="4.14,454,1170662400"; d="scan'208"; a="415881390:sNHT51630734" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3QDPiSN010602; Thu, 26 Apr 2007 06:25:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3QDPiZT028386; Thu, 26 Apr 2007 13:25:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 06:25:44 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 06:25:43 -0700 Message-ID: <4630A856.6060501@cisco.com> Date: Thu, 26 Apr 2007 09:25:42 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 13:25:43.0725 (UTC) FILETIME=[644C45D0:01C78806] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2892; t=1177593944; x=1178457944; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Concerned=20about=20role=20conflict=20resolution=20pr ocedure=20in=20ICE-15 |Sender:=20; bh=34dLoaVxH/w3nPPWuODz5Dr0BvrAS6+Li3u0m6p8WHQ=; b=psVkAcb0brjJwyeQzttxUobXCSp+zO27DnOlkzslxff4BWX9FoM5/zUjfSQQ9wDXgTOOqO1Z 7SxL2KJf8wNtMqNhLUOUfjkSMA2mgiU8QLJM+H/+G3cmQKTrQU+1dZ58iQu3HsICIUrjBSIj6R RqdN4QEI5gmCN81+44RCTai0c=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Concerned about role conflict resolution procedure in ICE-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Here is a 3pcc use case where both sides are controller: A Controller B |(1) INV() | | |<-------------| | |(2) 200(SDP1) | | |------------->| | | |(3) INV() | | |------------->| | |(4) 200(SDP2) | | |<-------------| |(5) ACK(SDP2')| | |<-------------| | | |(6) ACK(SDP1')| | |------------->| INV() means an INVITE with no SDP. This is actually a variant on 3pcc flow III, but with fewer messages. Its not one of the currently documented flows in RFC 3725 but it is in use. There are many further variations on this flow as well. In this model, both A and B will believe they are controlling. Interestingly, the cases I had thought of for both sides thinking they were controlled, doesn't work at all. So at the moment, the only real cases I have are for both sides being controlling. Thats good, since it means the proposal in another note I am about to post will work. Per your comment, I'd suggest that we add an appendix section on 'Why is the conflict resoltuion needed?' which describes this use case, and describes limitations. I don't want to beef up the main body text with what is just explanatory material. Thanks, Jonathan R. Philip Matthews wrote: > Jonathan: > > I am concerned about the conflict resolution procedure for > Controlling-End/Controlled-End that has been added in ICE-15. > I haven't seen the 3PCC cases where this problem supposedly exists, > and under my assumptions for when one can use ICE, I don't see how > the problem can arise. In my mind, the document is very clear that one > agent is the initial offerer and the other agent is the initial > answerer, and > with those assumptions, the conflict resolution procedure is not needed. > > All this means that I cannot evaluate whether the proposed mechanism > actually works or is even needed. > > I think the document: > 1) Needs to be explicit about the assumptions on when ICE can be used > wrt. the offer/answer procedure. > 2) Needs to give a reference to examples when the conflict resolution > is needed. > > If you or anyone else could give me details on a specific use case where > this problem arises, that would be very helpful. > > - Philip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 09:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4GM-0007jV-88; Thu, 26 Apr 2007 09:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4GK-0007i8-G9 for mmusic@ietf.org; Thu, 26 Apr 2007 09:43:56 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh4GI-0007Io-12 for mmusic@ietf.org; Thu, 26 Apr 2007 09:43:56 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hh4GH-0007le-2H; Thu, 26 Apr 2007 09:43:53 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D227573D8@namail5.corp.adobe.com> References: <462E7F8B.7020405@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D227573D8@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0261D27F-783E-4646-A189-B4DF15E24933@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidateaddresses? Date: Thu, 26 Apr 2007 07:56:39 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I agree. Solution 2 is nicer. But the real question is: who cares in the first place? After all, there is a NAT (or a NAT/FW) in front of the network. - Philip On 25-Apr-07, at 22:20 , Henry Sinnreich wrote: >> 1) Use an SBC to remove host candidates when signaling outside the >> enterprise, > > I hope not :-) > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, April 25, 2007 3:14 PM > To: Jonathan Rosenberg > Cc: mmusic@ietf.org > Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for > candidateaddresses? > > I can vaguely see how this might work. But are there people who > actually want to do this? > Moreover, are there not other ways to achieve the same effect? > 1) Use an SBC to remove host candidates when signaling outside the > enterprise, OR > 2) Look at the AoR that you are signaling -- if the domain part does > not match your domain > (or perhaps a short list of domains), then remove all the host > candidates from the SDP. > [I believe that, from ICE-10 onwards, the need to include host > candidates to "support" other > candidates has gone away -- e.g., ICE-08 required you to include the > host candidate that > generated a peer-reflexive candidate] > > Anyway, if we decide this is a good feature, then I think it should > be described in the security > considerations section and/or Appendix B. > > - Philip > > > On 24-Apr-07, at 18:07 , Jonathan Rosenberg wrote: > >> I added this a long time back to address some concerns around >> privacy. The idea was if an enterprise, say, didn't want to reveal >> its private addresses to the outside world, the agent could use >> dynDNS or something similar in conjunction with somewhat randomized >> hostnames, i.e., f7asff.enterprise.com. In the outgoing offer, this >> would be unresolvable by anyone except someone within the same >> enterprise. Furthermore, if the agent used a different hostname for >> every call, things would be uncorrelatable to the outside world >> (beyond coming from the same enterprise). >> >> -Jonathan R. >> >> Philip Matthews wrote: >> >>> Jonathan: >>> ICE-15 allows the address of a candidate to be specified using a >>> FQDN rather than an IP address: >>> : is taken from RFC 4566 [10]. It is the IP >>> address of the candidate, allowing for IPv4 addresses, IPv6 >>> addresses and FQDNs. An IP address SHOULD be used, but an >>> FQDN >>> MAY be used in place of an IP address. In that case, when >>> receiving an offer or answer containing an FQDN in an >>> a=candidate >>> attribute, the FQDN is looked up in the DNS using an A or AAAA >>> record, and the resulting IP address is used for the >>> remainder of >>> ICE processing. >>> What is the motivation for allowing this? >>> I am concerned that this makes an implementation more complex, >>> and I would like to know why we think this is important. >>> - Philip >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 09:45:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4Hi-0001AF-2f; Thu, 26 Apr 2007 09:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4Hf-00011Z-W6 for mmusic@ietf.org; Thu, 26 Apr 2007 09:45:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh4Hf-0007dO-E7 for mmusic@ietf.org; Thu, 26 Apr 2007 09:45:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2007 06:45:19 -0700 X-IronPort-AV: i="4.14,454,1170662400"; d="scan'208"; a="140886559:sNHT53504901" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3QDjIb5015640; Thu, 26 Apr 2007 06:45:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3QDjAEu024533; Thu, 26 Apr 2007 13:45:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 06:45:14 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 06:45:14 -0700 Message-ID: <4630ACE9.6020607@cisco.com> Date: Thu, 26 Apr 2007 09:45:13 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 13:45:14.0460 (UTC) FILETIME=[1E1C41C0:01C78809] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5799; t=1177595118; x=1178459118; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20ICE=20micro-lite=20for=20support=2 0of=20IPv6=20transition |Sender:=20; bh=SvzWY3iSjySg1OC+aBAB/2x3u7ap2O340JRsDgucYM4=; b=C1JA8DN3hEb4B2Xmj3ncjmaYFNUYPwMABa3SV1gZcLbFg5EWqsdKqGJWZ2gdkJIUysTliuPN Cf8jcNh0WerBq+iQZ+6TkxlXqgVzW4kFptOqVqsK6VhhT6dKZzwlWui0; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: "Elwell, John" , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Francois, I have considered this issue, and I have a proposal which I believe works. I think the following are important properties of a solution here: 1. it not be yet another mode; it should be ICE lite or minor orthogonal behavior or something 2. absolutely, positively, MUST MUST MUST allow nat traversal for a peer that is full. This was our fundamental requirement when designing ICE-lite. Anything else and our result is NOT ICE. 3. be much simpler than ICE-full for dual-stack endpoints that are not natted 4. maintain the property that the final m/c-line reflects what is really used So, your proposal below is not bad, but fails on requirement 4. I believe we still need a 'fix-up' reinvite if the finally selected pair doesn't match the m/c-line. So, here is my suggested variant on your proposal which meets all four. We enhance ICE-lite a bit, so that it works for dual-stack hosts that are not natted or firewalled. As you suggested, when two ICE-lite endpoints meet, we don't say that we proceed as if there was no ICE. We do proceed. The answerer will send back its candidates (one v4 and a few v6), with the a=ice-lite flag. Now, neither side will send checks. However, we will do role-selection. Offerer is controller. The controller, being ICE-lite, will run RFC3484 to select the IP address pairs, rather than running checks to do so. This will be a totally static step. Once it selects, the controller sends a re-INVITE or update with the fix-up in the m/c-line, and includes only the candidate for its selected IP address. It also includes a=remote-candidates telling the other side which IP address/port to use. As for media cut-through, the answerer (as controlled node) can run rfc3484 also, pick what it thinks is the winner, and send immediately. If it turns out that the controller used a variation on rfc3484 or something, and picked a different address, the controlled agent will find out when the re-invite comes. So, what this means is, ice-lite gets a little more complicated. Its not any more complicated than it is today if you have a single IP. If you are dual-stack, the complexity would be current ICE-lite, plus the ability to send the fix-up re-INVITE with a=remote-candidates. This does mean that a dual-stack host that is not natted would need to be able to respond to STUN requests. This would happen when that dual-stack host calls a full implementation. I think this is absolutely essential and with fight with great vigor any attempts to have a different mode of ICE which does not require even responding to STUN checks. Big big mistake IMHO. Now, what about this role conflict bit? Well, per my other note, I actually only have cases where both sides are controlling. In that case, both would run RFC3484, both would re-INVITE. We'd get glare, but it would be resolved by standard RFC3261 techniques. So, it works. Not optimally, since we end up with two re-invites where one would do. But it still works. I have glanced through the text, and believe this change is actually not hard to make. Note further that, even with this change, ice-13 and onwards would still be compatible with ice-16 (if anyone cares). Does this work for people? -Jonathan R. Francois Audet wrote: > > >>>In fact, wouldn't this be useful even for ice-lite (not >> >>microlite, just >> >>>lite), where >>>if both PSTN gateways are on the public internet, they know >> >>right away >> >>>they can skip the >>>connectivity check? >> >>That already happens. If both agents are ICE lite, there are no >>connectivity checks that get utilized. > > > Jonathan, > > I'm reading your section 5 of ICE-15, and I think > we have almost what is requested. We probably don't even need > anything beyond ice-lite. > > A sends offer to B. It is not behind a NAT, but it is dual > stack and supports IPv4 and IPv6, so it has: > > Offer: > > m=IPv4 <- Assumption is that IPv4 is more > likely to succeed than IPv6 > candidate 1=IPv6 > candidate 2=IPv4 > a=ice-lite > > > B receives the offer, it is also dual stack and NOT behind a NAT. > > It sends an answer: > > m=IPv4 > candidate 1=IPv6 > candidate 2=IPv4 > a=ice-lite > > According to your section 5 it would result in having "NO CONNECTIVITY > CHECK". > > (PS: your wording says "ICE cannot proceed", which I think is innacurate > since > the candidates have already been sent, so I think you need to clarify > that it means > "does not proceed with the connectivity check). > > According to section 5 again, it would result in having the IPv4 > selected instead > of the IPv6 (i.e., the m line). > > That's NOT the behavior we want. What we want is in this case to have > both sides use > the candidates and the RFC XXXX procedures (the selection thing: I don't > have the number). > > One easy way to do this is to have B responding with this answer > instead: > > m=IPv6 <- i.e., forcing the other side to use the > IPv6 address > candidate 1=IPv6 <- I'm not sure we actually need this line > a=ice-lite <- This is to tell A that it understood > ICE > > And B would just use the candidate 1=IPv6 from the offer anyways to send > media. > > I think this solves the problem, no? > > Isn't this trivial? > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 10:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4ZJ-0001Wd-B2; Thu, 26 Apr 2007 10:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh4ZI-0001VY-SE for mmusic@ietf.org; Thu, 26 Apr 2007 10:03:32 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh4ZG-0002Om-JB for mmusic@ietf.org; Thu, 26 Apr 2007 10:03:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Date: Thu, 26 Apr 2007 10:03:28 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012218E1D6@m5tmail1.m5t.com> In-Reply-To: <462E6C70.1070601@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? Thread-Index: AceGsYtKCQeoz1agRFWHvwXKfrvnawBV7Lgg From: "Guylain Lavoie" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Jonathan, Yes, I have tried it. It seems that you cannot do a listen and then do a connect on the same socket. It does not work. At least on the platforms I tested (Linux and Windows). The only way to achieve this is by binding two sockets to the exact same address/port and this required special support from the OS (SO_REUSEPORT and/or SO_REUSEADDR combinason). From what I read, the needed fonctionality is not available on Linux. You are right that at the TCP level, nothing should prevent us from doing this. However, it's the API level that does not follow. Maybe someone else will bring some light over this. Best Regards, Guylain -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: April 24, 2007 4:46 PM To: Guylain Lavoie Cc: Alfred E. Heggestad; mmusic@ietf.org Subject: Re: [MMUSIC] ICE-15: when do you stop waiting foran aggressive nomination? inline. Guylain Lavoie wrote: > Alfred, >=20 > In don't really understand what you mean. How can you send Binding=20 > Request to a STUN server without ever connecting the socket? Remember, > it is TCP that we are talking about, not UDP. >=20 > For a passive candidate, you really need to allocate at least two TCP=20 > sockets and bind them at the same address and port. One will be a TCP=20 > server socket and will be used to receive TCP connection requests=20 > associated with peer initialited connectivity checks from its Active=20 > candidates (Reception of a connection request will effectively create=20 > a entirely new socket, also bound at the same address and port). The=20 > other will be a TCP client socket connected to the STUN server to=20 > gather a server reflexive candidate and periodically, it will also=20 > send Binding Request to keep alive the NAT binding. I had in mind that there would be one socket. You'd first call socket() to allocate. THen you'd do a listen() on that socket to bind to a local port, and then connect() on the same socket to connect to the STUN server. I have not tried to see that BSD sockets will let you both listen() and connect() on the same socket. Certainly from a TCP protocol perspective this is allowed. Have you tried it? >=20 > For SO, it is a bit different. You need to allocate at least two TCP=20 > client sockets and also bind them at the same address and port. One=20 > will be connected to the STUN server to gather a server reflexive=20 > candidate and periodically send Binding Request to keep alive the NAT=20 > binding. The other, or others, are used to send connectivity checks to > the peer SO candidates. Each one of them must be connected to peer SO=20 > candidate before sending its connecitivity checks. Again, I think its more like the above. >=20 > The situation becomes even more complex if you think that you may have > more than one STUN server. Note however, that the specification does=20 > not encourage this. Its not that it doesn't encourage it; it just doesn't specify it. Its quite a fine idea as a general rule. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 11:25:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5qk-00058R-FR; Thu, 26 Apr 2007 11:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5qj-00058M-Q1 for mmusic@ietf.org; Thu, 26 Apr 2007 11:25:37 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5qh-0000Ai-7Y for mmusic@ietf.org; Thu, 26 Apr 2007 11:25:37 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JH4002AR2UFY8@siemenscomms.co.uk> for mmusic@ietf.org; Thu, 26 Apr 2007 16:25:27 +0100 (BST) Date: Thu, 26 Apr 2007 16:25:34 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 In-reply-to: <4630A856.6060501@cisco.com> To: Jonathan Rosenberg , Philip Matthews Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00AF9F1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 Thread-Index: AceIBoi753gbKuSkQpGqtXf/BjCreQAEE5vg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4630A856.6060501@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, This use case breaks as soon as you include in the SDP offer anything that is asymmetrical in nature, such as capability negotiation or MIKEY. You would receive in an answer something you expect only in an offer. Do we really want to spend effort trying to fix such broken implementations? John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 26 April 2007 14:26 > To: Philip Matthews > Cc: mmusic@ietf.org > Subject: [MMUSIC] Re: Concerned about role conflict > resolution procedure inICE-15 > > Here is a 3pcc use case where both sides are controller: > > > > A Controller B > |(1) INV() | | > |<-------------| | > |(2) 200(SDP1) | | > |------------->| | > | |(3) INV() | > | |------------->| > | |(4) 200(SDP2) | > | |<-------------| > |(5) ACK(SDP2')| | > |<-------------| | > | |(6) ACK(SDP1')| > | |------------->| > > INV() means an INVITE with no SDP. > > This is actually a variant on 3pcc flow III, but with fewer messages. > Its not one of the currently documented flows in RFC 3725 but > it is in > use. There are many further variations on this flow as well. > > In this model, both A and B will believe they are controlling. > > Interestingly, the cases I had thought of for both sides > thinking they > were controlled, doesn't work at all. So at the moment, the only real > cases I have are for both sides being controlling. > > Thats good, since it means the proposal in another note I am about to > post will work. > > Per your comment, I'd suggest that we add an appendix section > on 'Why is > the conflict resoltuion needed?' which describes this use case, and > describes limitations. I don't want to beef up the main body > text with > what is just explanatory material. > > Thanks, > Jonathan R. > > > Philip Matthews wrote: > > > Jonathan: > > > > I am concerned about the conflict resolution procedure for > > Controlling-End/Controlled-End that has been added in ICE-15. > > I haven't seen the 3PCC cases where this problem supposedly exists, > > and under my assumptions for when one can use ICE, I don't see how > > the problem can arise. In my mind, the document is very > clear that one > > agent is the initial offerer and the other agent is the initial > > answerer, and > > with those assumptions, the conflict resolution procedure > is not needed. > > > > All this means that I cannot evaluate whether the proposed mechanism > > actually works or is even needed. > > > > I think the document: > > 1) Needs to be explicit about the assumptions on when ICE > can be used > > wrt. the offer/answer procedure. > > 2) Needs to give a reference to examples when the conflict > resolution > > is needed. > > > > If you or anyone else could give me details on a specific > use case where > > this problem arises, that would be very helpful. > > > > - Philip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 11:42:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh675-0000ZC-Fd; Thu, 26 Apr 2007 11:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh674-0000Z2-1D for mmusic@ietf.org; Thu, 26 Apr 2007 11:42:30 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh673-0002fX-9y for mmusic@ietf.org; Thu, 26 Apr 2007 11:42:30 -0400 Received: from w15.irbs.net (w15.irbs.net [205.237.194.59]) by smtp.mxes.net (Postfix) with ESMTP id 01BD751981 for ; Thu, 26 Apr 2007 11:42:28 -0400 (EDT) Received: from cm50.delta186.maxonline.com.sg (cm50.delta186.maxonline.com.sg [59.189.186.50]) by webmail.tuffmail.net (Horde MIME library) with HTTP; Thu, 26 Apr 2007 11:42:28 -0400 Message-ID: <20070426114228.z2hwm9o9ickksk80@webmail.tuffmail.net> Date: Thu, 26 Apr 2007 11:42:28 -0400 From: Benny Prijono To: mmusic@ietf.org Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.5) X-Spam-Score: 0.6 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org also inline. > See inline. > -- Philip > On 25-Apr-07, at 22:16 , Benny Prijono wrote: > >> Philip Matthews wrote: >>>> (please see this table with fixed width font) >>>> >>>> Agent A | Agent B >>>> candidate=3D1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host >>>> candidate=3D2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host >>>> >>>> With usual ICE, these checks will be created on agent A: >>>> >>>> #1) 1.1.1.1:1 --> 3.3.3.3:3 >>>> #2) 1.1.1.1:1 --> 4.4.4.4:4 >>>> #3) 2.2.2.2:2 --> 3.3.3.3:3 >>>> #4) 2.2.2.2:2 --> 4.4.4.4:4 >>>> >>>> Now, if agent A uses a single socket for all host candidates, >>>> AFAIK check #3 will produce the same result as check #1, and >>>> check #4 will produce the same result as check #2. >>> This is where I disagree. In my opinion, check #1 and check #3 are >>> not the same (and nor are checks #2 and #4). >>> Let me illustrate by elaborating more on my previous example. >>> On Agent A, >>> - say the interface with address 1.1.1.1 is a 802.11 interface >>> that connects to an access point which then connects via ethernet >>> to a router that connects to the Internet; and >>> - say the interface with address 2.2.2.2 is an ethernet >>> interface that connects to the same router. >>> Say static/default routing is used throughout. So if someone >>> unplugs the ethernet cable leading to the wireless access point, >>> the box on which Agent A runs will not see any routing updates or >>> similar. However, packets sent out the wireless interface will >>> just be dropped (hopefully with an ICMP Destination Unreachable >>> reply, but even that is not certain). >>> In this case, check #1 and #2 will fail, but check #3 and check #4 >>> will succeed. >> >> Let me come back to this after I explain more about my approach >> below, since there seem to be a misunderstanding. >> >> >>> However, your comment does point that you have to force the >>> packets out the correct interface. >> >> No, that is exactly what you MUST NOT do when using my approach! >> >> Using my approach, socket MUST ALWAYS be bound to INADDR_ANY >> (0.0.0.0), to allow the OS to choose the appropriate interface when >> sending the request. >> >> There seems to be a misunderstanding. When I said that the agent >> perform this connectivity check (using my approach): >> >> 1.1.1.1:1 --> 3.3.3.3:3 >> >> It doesn't mean that the agent must somehow force the socket to >> send from interface 1.1.1.1:1. No, that's not what I meant. >> >> What I meant is that the agent should choose local host candidate >> 1.1.1.1:1 as the local candidate of the check. But as I said, it >> doesn't really matter which local candidate to use as the local >> part of the check, since all candidates shares the same socket. >> >> The socket itself is still bound to INADDR_ANY, to allow the OS to >> choose which interface to send the packet from. We don't need to >> care what interface is chosen for the packet. If the connectivity >> is successful the peer will tell us what it is in XOR-MAPPED- >> ADDRESS attribute in the response. >> >> I hope I'm making myself clear. >> >> Now back to the examples. >> >> >> Case 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> Suppose an agent has these connectivity checks as the result of >> pairing process with normal ICE: >> >> #1) 1.1.1.1:1 --> 3.3.3.3:3 >> #2) 1.1.1.1:1 --> 4.4.4.4:4 >> #3) 2.2.2.2:2 --> 3.3.3.3:3 >> #4) 2.2.2.2:2 --> 4.4.4.4:4 >> >> And it has this routing table: >> >> 1.1.1.0/24 use interface 1.1.1.1 >> 2.2.2.0/24 use interface 2.2.2.2 >> 0.0.0.0/0 (default) use interface 2.2.2.2 >> >> Now even if interface 1.1.1.1 is up, check #1 and #2 will always >> fail (immediately with ENETUNREACH/EHOSTUNREACH error, at least on >> Windows and Linux) if you use standard ICE, so the question is why >> bother creating these checks in the first place? >> >> With my approach, these checks will be created instead: >> >> #1) 0.0.0.0:0 --> 3.3.3.3:3 >> #2) 0.0.0.0:0 --> 4.4.4.4:4 >> >> (I put 0.0.0.0:0 as the local part to make it clearer that the >> application does not specify which interface to use). >> >> With this approach, the OS will choose for us which interface to >> use for sending the request, and in this case it will choose >> interface 2.2.2.2. >> >> So both approaches yield the same result. > > Let's change your example to have the default route point out > interface 1.1.1.1 rather than interface 2.2.2.2 (this could easily > happen, after all). Then let's merge this with my example where > 1.1.1.1 is a 802.11 interface which leads to an Access Point whose > cable in unplugged (so packets are dropped at the Access Point rather > than being forwarded), while 2.2.2.2 is an Ethernet interface and > has proper Internet connectivity. > > Under these conditions, your approach will always send out interface > 1.1.1.1 (in effect, only doing checks #1 and #2), and both of these > checks will fail. However, assuming other things are OK, a working > path could be found using interface 2.2.2.2, but your implementation > will never find this path. You're assuming that just because you bind() your socket to a specific interface, you can force the OS to spit packets out of that interface, bypassing the routing table. It won't work. The OS will return ENETUNREACH/EHOSTUNREACH error if you try to do this. So you can't send packet to 3.3.3.3 or 4.4.4.4 using interface 2.2.2.2, if the default route points to interface 1.1.1.1. Your connectivity checks will always fail. And so are mine, in this case, because 1.1.1.1 is down. So both approaches produce the same result, again. -benny > Remember that, in my example, the OS on which Agent A is running is > only using static routing, so it doesn't have any way to discover > that packets sent out interface 1.1.1.1 get dropped before they reach > the Internet. > > Does this help? > > - Philip > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 12:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6f5-0004wt-8K; Thu, 26 Apr 2007 12:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6f3-0004wn-M9 for mmusic@ietf.org; Thu, 26 Apr 2007 12:17:37 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6f3-0007tc-C4 for mmusic@ietf.org; Thu, 26 Apr 2007 12:17:37 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2007 09:17:37 -0700 X-IronPort-AV: i="4.14,455,1170662400"; d="scan'208"; a="770882134:sNHT44631136" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3QGHaFC013992; Thu, 26 Apr 2007 09:17:36 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3QGHaEi009355; Thu, 26 Apr 2007 16:17:36 GMT From: "Dan Wing" To: Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Thu, 26 Apr 2007 09:17:36 -0700 Message-ID: <080c01c7881e$6755a150$05716b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceCmOYTyAWMEsXOTcySp9+m8ZV0YgAAdgbgAWAcIdA= In-Reply-To: <00e201c7829d$99cf1430$c4f0200a@amer.cisco.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1963; t=1177604256; x=1178468256; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20ICE=20pacing=20connectivity=20checks=20(wasRE=3A[MMUS IC]=09WGLC=3A=09draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=UDCj3rzvZIrakvBkL0Nlw4plgBYeQeyS4N84boXKg6c=; b=g4KSeDqt7wknxu9Cznr2YKDSTrrk3NAKEEpBpcBQLIiFvwr29gj+MDoP1mw50G2r+OWz4tPw Yx+H6hWz6dep112VDa4CbGVdbD36b+WUSmBCDHX8E1snrMuCybIFoTUn; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org (Jonathan had also listed this as ICE issue #11.) I have moved discussion of ICE pacing to the tsv-area mailing list , as the tsv-area list is more appropriate for discussing TCP friendliness. My post to tsv-area proposed new calculations for ICE's Ta and STUN's RTO. These changes prevent ICE from exceeding the bandwidth RTP would have consumed. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, April 19, 2007 9:13 AM > To: 'Lars Eggert'; 'Magnus Westerlund' > Cc: mmusic@ietf.org > Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] > WGLC: draft-ietf-mmusic-ice-15.txt) > > I have created an Excel spreadsheet analyzing ICE's behavior > compared to > RTP's behavior. I am tweaking this spreadsheet and expect it > to be useful > in helping us tune ICE's algorithms. I want to make this a > more useful > spreadsheet before sharing it; it doesn't quite do everything > I like yet. I > expect it will remain awkward to use, as I'm not an excel wizard. > > In my initial analysis using this spreadsheet, I do agree > that ICE's default > 20ms pacing and STUN's default 100ms retransmit timers are > too aggressive if > we assume severely bandwidth-constrained links. I expect > that adjusting > these values based on the ptime, RTP packet size, STUN > Request packet size, > and number of candidates will result in ICE behaving as well > as RTP (with > RTCP feedback) in all cases, and better than RTP (with RTCP > feedback) in > some cases. The drawback of such tuning, however, is that > ICE will take > longer to complete if there are many candidates. > > -d > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 12:18:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6gC-0006F1-83; Thu, 26 Apr 2007 12:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6gA-0006EI-Iw for mmusic@ietf.org; Thu, 26 Apr 2007 12:18:46 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6g9-00088P-4W for mmusic@ietf.org; Thu, 26 Apr 2007 12:18:46 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3QGIbi21291; Thu, 26 Apr 2007 16:18:37 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 26 Apr 2007 11:18:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1032A43B@zrc2hxm0.corp.nortel.com> In-Reply-To: <4630ACE9.6020607@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Thread-Index: AceICSsVG9nOKD3tQHefPB23wVko+wAE+Aow References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> <4630ACE9.6020607@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: "Elwell, John" , mmusic@ietf.org, John Rutledge X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Jonathan, I'm 100% happy with what you are proposing here (including your 4 requirements). In fact, that's exactly what I was thinking too: i.e., that we'd need to have the second offer/answer to correct the m lines, and that we'd=20 need to use the RFC 3484 rules. Even the fact that it's not a new mode, but it IS ice-lite (with a minor fix-up) is covered in that posting. In fact, I had re-submitted formally the email you quote as WGLC comments on=20 4/18 (http://www1.ietf.org/mail-archive/web/mmusic/current/msg05592.html), adding=20 a paragraph at the end stating this, as well as a reference to RFC 3484. So, basically we were thinking exactly the same thing. Good. This completely addresses my WGLC comment.=20 I also believe that ICE now truely, absolutely, removes any need for ANAT. This solution will be very clean, efficient and simple for non-NATed devices. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, April 26, 2007 06:45 > To: Audet, Francois (SC100:3055) > Cc: Elwell, John; mmusic@ietf.org > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6=20 > transition >=20 > Francois, >=20 > I have considered this issue, and I have a proposal which I=20 > believe works. >=20 > I think the following are important properties of a solution here: >=20 > 1. it not be yet another mode; it should be ICE lite or minor=20 > orthogonal behavior or something >=20 > 2. absolutely, positively, MUST MUST MUST allow nat traversal=20 > for a peer that is full. This was our fundamental requirement=20 > when designing ICE-lite. Anything else and our result is NOT ICE. >=20 > 3. be much simpler than ICE-full for dual-stack endpoints=20 > that are not natted >=20 > 4. maintain the property that the final m/c-line reflects=20 > what is really used >=20 >=20 > So, your proposal below is not bad, but fails on requirement 4. I=20 > believe we still need a 'fix-up' reinvite if the finally=20 > selected pair=20 > doesn't match the m/c-line. >=20 > So, here is my suggested variant on your proposal which meets=20 > all four. >=20 > We enhance ICE-lite a bit, so that it works for dual-stack hosts that=20 > are not natted or firewalled. As you suggested, when two ICE-lite=20 > endpoints meet, we don't say that we proceed as if there was=20 > no ICE. We=20 > do proceed. The answerer will send back its candidates (one=20 > v4 and a few=20 > v6), with the a=3Dice-lite flag. Now, neither side will send checks.=20 > However, we will do role-selection. Offerer is controller. The=20 > controller, being ICE-lite, will run RFC3484 to select the IP address=20 > pairs, rather than running checks to do so. This will be a totally=20 > static step. Once it selects, the controller sends a=20 > re-INVITE or update=20 > with the fix-up in the m/c-line, and includes only the=20 > candidate for its=20 > selected IP address. It also includes a=3Dremote-candidates telling = the=20 > other side which IP address/port to use. >=20 > As for media cut-through, the answerer (as controlled node) can run=20 > rfc3484 also, pick what it thinks is the winner, and send=20 > immediately.=20 > If it turns out that the controller used a variation on rfc3484 or=20 > something, and picked a different address, the controlled agent will=20 > find out when the re-invite comes. >=20 > So, what this means is, ice-lite gets a little more=20 > complicated. Its not=20 > any more complicated than it is today if you have a single IP. If you=20 > are dual-stack, the complexity would be current ICE-lite, plus the=20 > ability to send the fix-up re-INVITE with a=3Dremote-candidates. >=20 > This does mean that a dual-stack host that is not natted=20 > would need to=20 > be able to respond to STUN requests. This would happen when that=20 > dual-stack host calls a full implementation. I think this is=20 > absolutely=20 > essential and with fight with great vigor any attempts to have a=20 > different mode of ICE which does not require even responding to STUN=20 > checks. Big big mistake IMHO. >=20 > Now, what about this role conflict bit? Well, per my other note, I=20 > actually only have cases where both sides are controlling. In=20 > that case,=20 > both would run RFC3484, both would re-INVITE. We'd get glare, but it=20 > would be resolved by standard RFC3261 techniques. So, it works. Not=20 > optimally, since we end up with two re-invites where one=20 > would do. But=20 > it still works. >=20 > I have glanced through the text, and believe this change is=20 > actually not=20 > hard to make. >=20 > Note further that, even with this change, ice-13 and onwards=20 > would still=20 > be compatible with ice-16 (if anyone cares). >=20 > Does this work for people? >=20 > -Jonathan R. >=20 >=20 >=20 >=20 >=20 >=20 > Francois Audet wrote: >=20 > > =20 > >=20 > >>>In fact, wouldn't this be useful even for ice-lite (not=20 > >> > >>microlite, just > >> > >>>lite), where > >>>if both PSTN gateways are on the public internet, they know=20 > >> > >>right away > >> > >>>they can skip the > >>>connectivity check? > >> > >>That already happens. If both agents are ICE lite, there are no=20 > >>connectivity checks that get utilized. > >=20 > >=20 > > Jonathan, > >=20 > > I'm reading your section 5 of ICE-15, and I think > > we have almost what is requested. We probably don't even need > > anything beyond ice-lite. > >=20 > > A sends offer to B. It is not behind a NAT, but it is dual > > stack and supports IPv4 and IPv6, so it has: > >=20 > > Offer: > >=20 > > m=3DIPv4 <- Assumption is that IPv4 is more > > likely to succeed than IPv6 > > candidate 1=3DIPv6 > > candidate 2=3DIPv4 > > a=3Dice-lite > >=20 > >=20 > > B receives the offer, it is also dual stack and NOT behind a NAT. > >=20 > > It sends an answer: > >=20 > > m=3DIPv4 > > candidate 1=3DIPv6 > > candidate 2=3DIPv4 > > a=3Dice-lite > >=20 > > According to your section 5 it would result in having "NO=20 > CONNECTIVITY > > CHECK". > >=20 > > (PS: your wording says "ICE cannot proceed", which I think=20 > is innacurate > > since=20 > > the candidates have already been sent, so I think you need=20 > to clarify > > that it means > > "does not proceed with the connectivity check). > >=20 > > According to section 5 again, it would result in having the IPv4 > > selected instead > > of the IPv6 (i.e., the m line). > >=20 > > That's NOT the behavior we want. What we want is in this=20 > case to have > > both sides use > > the candidates and the RFC XXXX procedures (the selection=20 > thing: I don't > > have the number). > >=20 > > One easy way to do this is to have B responding with this answer > > instead: > >=20 > > m=3DIPv6 <- i.e., forcing the other side to use the > > IPv6 address > > candidate 1=3DIPv6 <- I'm not sure we actually need this line > > a=3Dice-lite <- This is to tell A that it understood > > ICE > >=20 > > And B would just use the candidate 1=3DIPv6 from the offer=20 > anyways to send > > media. > >=20 > > I think this solves the problem, no? > >=20 > > Isn't this trivial? > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 12:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6u8-0001SM-FW; Thu, 26 Apr 2007 12:33:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6u7-0001SH-5q for mmusic@ietf.org; Thu, 26 Apr 2007 12:33:11 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6u4-0002HA-P9 for mmusic@ietf.org; Thu, 26 Apr 2007 12:33:11 -0400 Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l3QGX6xb007798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 09:33:07 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lazzaro Date: Thu, 26 Apr 2007 09:33:05 -0700 To: mmusic@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: lazzaro Subject: [MMUSIC] Re: RTSP: Speed header X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Apr 26, 2007, at 6:45 AM, Magnus Westerlund wrote: > There are some cases where progressive download is a simple > solution to the problem. However, progressive download are in many > cases lousy for fast forward, jumping etc unless you download the > file very fast and then do all these tricks locally. One nice solution here is to: (1) require content creators to specify "chapters" in the content. (2) Using TCP, pre-buffer the first few RTTs of each chapter in the client, as a background process (or perhaps during startup). (3) Present a UI to the user that permits skipping to chapter start positions, as opposed to an arbitrary point in the stream. When implemented, when a user skips to a new chapter, the program material starts playing immediately from the pre-buffered start of the chapter. By the time the buffer has been exhausted the stream of the chapter is flowing from the server. Musical instrument designers might recognize this architecture from hard-disk based sample playback. Of course, actually bringing this concept to RTSP 2.0 would require a lot of work ... personally, I wouldn't trust a protocol design for this that didn't have a working prototype, this is the sort of thing that is hard to get right on paper, you have to write code. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 12:38:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6zj-0002dR-5p; Thu, 26 Apr 2007 12:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6zh-0002dE-Ma for mmusic@ietf.org; Thu, 26 Apr 2007 12:38:57 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6zg-0003Y4-3N for mmusic@ietf.org; Thu, 26 Apr 2007 12:38:57 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JH400LAA68OEC@siemenscomms.co.uk> for mmusic@ietf.org; Thu, 26 Apr 2007 17:38:48 +0100 (BST) Date: Thu, 26 Apr 2007 17:38:55 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition In-reply-to: <1ECE0EB50388174790F9694F77522CCF1032A43B@zrc2hxm0.corp.nortel.com> To: Francois Audet , Jonathan Rosenberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00AFA02@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Thread-Index: AceICSsVG9nOKD3tQHefPB23wVko+wAE+AowAAEMO6A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> <4630ACE9.6020607@cisco.com> <1ECE0EB50388174790F9694F77522CCF1032A43B@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: mmusic@ietf.org, John Rutledge X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, Yes, I believe this would be beneficial. Thanks. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 26 April 2007 17:19 > To: Jonathan Rosenberg > Cc: Elwell, John; mmusic@ietf.org; John Rutledge > Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 > transition > > Hi Jonathan, > > I'm 100% happy with what you are proposing here (including your 4 > requirements). > > In fact, that's exactly what I was thinking too: i.e., that > we'd need to > have the second offer/answer to correct the m lines, and that we'd > need to use the RFC 3484 rules. Even the fact that it's not a > new mode, > but it > IS ice-lite (with a minor fix-up) is covered in that posting. > > In fact, I had re-submitted formally the email you quote as WGLC > comments on > 4/18 > (http://www1.ietf.org/mail-archive/web/mmusic/current/msg05592.html), > adding > a paragraph at the end stating this, as well as a reference > to RFC 3484. > > So, basically we were thinking exactly the same thing. Good. > > This completely addresses my WGLC comment. > > I also believe that ICE now truely, absolutely, removes any need for > ANAT. This > solution will be very clean, efficient and simple for > non-NATed devices. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, April 26, 2007 06:45 > > To: Audet, Francois (SC100:3055) > > Cc: Elwell, John; mmusic@ietf.org > > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 > > transition > > > > Francois, > > > > I have considered this issue, and I have a proposal which I > > believe works. > > > > I think the following are important properties of a solution here: > > > > 1. it not be yet another mode; it should be ICE lite or minor > > orthogonal behavior or something > > > > 2. absolutely, positively, MUST MUST MUST allow nat traversal > > for a peer that is full. This was our fundamental requirement > > when designing ICE-lite. Anything else and our result is NOT ICE. > > > > 3. be much simpler than ICE-full for dual-stack endpoints > > that are not natted > > > > 4. maintain the property that the final m/c-line reflects > > what is really used > > > > > > So, your proposal below is not bad, but fails on requirement 4. I > > believe we still need a 'fix-up' reinvite if the finally > > selected pair > > doesn't match the m/c-line. > > > > So, here is my suggested variant on your proposal which meets > > all four. > > > > We enhance ICE-lite a bit, so that it works for dual-stack > hosts that > > are not natted or firewalled. As you suggested, when two ICE-lite > > endpoints meet, we don't say that we proceed as if there was > > no ICE. We > > do proceed. The answerer will send back its candidates (one > > v4 and a few > > v6), with the a=ice-lite flag. Now, neither side will send checks. > > However, we will do role-selection. Offerer is controller. The > > controller, being ICE-lite, will run RFC3484 to select the > IP address > > pairs, rather than running checks to do so. This will be a totally > > static step. Once it selects, the controller sends a > > re-INVITE or update > > with the fix-up in the m/c-line, and includes only the > > candidate for its > > selected IP address. It also includes a=remote-candidates > telling the > > other side which IP address/port to use. > > > > As for media cut-through, the answerer (as controlled node) can run > > rfc3484 also, pick what it thinks is the winner, and send > > immediately. > > If it turns out that the controller used a variation on rfc3484 or > > something, and picked a different address, the controlled > agent will > > find out when the re-invite comes. > > > > So, what this means is, ice-lite gets a little more > > complicated. Its not > > any more complicated than it is today if you have a single > IP. If you > > are dual-stack, the complexity would be current ICE-lite, plus the > > ability to send the fix-up re-INVITE with a=remote-candidates. > > > > This does mean that a dual-stack host that is not natted > > would need to > > be able to respond to STUN requests. This would happen when that > > dual-stack host calls a full implementation. I think this is > > absolutely > > essential and with fight with great vigor any attempts to have a > > different mode of ICE which does not require even > responding to STUN > > checks. Big big mistake IMHO. > > > > Now, what about this role conflict bit? Well, per my other note, I > > actually only have cases where both sides are controlling. In > > that case, > > both would run RFC3484, both would re-INVITE. We'd get > glare, but it > > would be resolved by standard RFC3261 techniques. So, it works. Not > > optimally, since we end up with two re-invites where one > > would do. But > > it still works. > > > > I have glanced through the text, and believe this change is > > actually not > > hard to make. > > > > Note further that, even with this change, ice-13 and onwards > > would still > > be compatible with ice-16 (if anyone cares). > > > > Does this work for people? > > > > -Jonathan R. > > > > > > > > > > > > > > Francois Audet wrote: > > > > > > > > > > >>>In fact, wouldn't this be useful even for ice-lite (not > > >> > > >>microlite, just > > >> > > >>>lite), where > > >>>if both PSTN gateways are on the public internet, they know > > >> > > >>right away > > >> > > >>>they can skip the > > >>>connectivity check? > > >> > > >>That already happens. If both agents are ICE lite, there are no > > >>connectivity checks that get utilized. > > > > > > > > > Jonathan, > > > > > > I'm reading your section 5 of ICE-15, and I think > > > we have almost what is requested. We probably don't even need > > > anything beyond ice-lite. > > > > > > A sends offer to B. It is not behind a NAT, but it is dual > > > stack and supports IPv4 and IPv6, so it has: > > > > > > Offer: > > > > > > m=IPv4 <- Assumption is that IPv4 is more > > > likely to succeed than IPv6 > > > candidate 1=IPv6 > > > candidate 2=IPv4 > > > a=ice-lite > > > > > > > > > B receives the offer, it is also dual stack and NOT behind a NAT. > > > > > > It sends an answer: > > > > > > m=IPv4 > > > candidate 1=IPv6 > > > candidate 2=IPv4 > > > a=ice-lite > > > > > > According to your section 5 it would result in having "NO > > CONNECTIVITY > > > CHECK". > > > > > > (PS: your wording says "ICE cannot proceed", which I think > > is innacurate > > > since > > > the candidates have already been sent, so I think you need > > to clarify > > > that it means > > > "does not proceed with the connectivity check). > > > > > > According to section 5 again, it would result in having the IPv4 > > > selected instead > > > of the IPv6 (i.e., the m line). > > > > > > That's NOT the behavior we want. What we want is in this > > case to have > > > both sides use > > > the candidates and the RFC XXXX procedures (the selection > > thing: I don't > > > have the number). > > > > > > One easy way to do this is to have B responding with this answer > > > instead: > > > > > > m=IPv6 <- i.e., forcing the other side to use the > > > IPv6 address > > > candidate 1=IPv6 <- I'm not sure we actually need this line > > > a=ice-lite <- This is to tell A that it understood > > > ICE > > > > > > And B would just use the candidate 1=IPv6 from the offer > > anyways to send > > > media. > > > > > > I think this solves the problem, no? > > > > > > Isn't this trivial? > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 13:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7jc-0000eE-Hx; Thu, 26 Apr 2007 13:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7jb-0000e9-81 for mmusic@ietf.org; Thu, 26 Apr 2007 13:26:23 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7jZ-0004S5-K0 for mmusic@ietf.org; Thu, 26 Apr 2007 13:26:23 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3QHQIQ09917; Thu, 26 Apr 2007 17:26:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Thu, 26 Apr 2007 12:26:16 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437113DF3A07@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1032A43B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Thread-Index: AceICSsVG9nOKD3tQHefPB23wVko+wAE+AowAAKpW0A= References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk> <461A3A35.8090200@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com> <461B9001.9080402@cisco.com> <1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> <4630ACE9.6020607@cisco.com> <1ECE0EB50388174790F9694F77522CCF1032A43B@zrc2hxm0.corp.nortel.com> From: "Brian Stucker" To: "Francois Audet" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: "Elwell, John" , mmusic@ietf.org, John Rutledge X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi Jonathan, This works for me as well, and I think addresses the exact pattern I was looking for from the ANAT deprecation discussion.=20 Looking forward to the updated document. Regards, Brian=20 > -----Original Message----- > From: Audet, Francois (SC100:3055)=20 > Sent: Thursday, April 26, 2007 11:19 AM > To: Jonathan Rosenberg > Cc: Elwell, John; mmusic@ietf.org; Rutledge, John (NGD:X260);=20 > Stucker, Brian (RICH1:AR00) > Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6=20 > transition >=20 > Hi Jonathan, >=20 > I'm 100% happy with what you are proposing here (including=20 > your 4 requirements). >=20 > In fact, that's exactly what I was thinking too: i.e., that=20 > we'd need to have the second offer/answer to correct the m=20 > lines, and that we'd need to use the RFC 3484 rules. Even the=20 > fact that it's not a new mode, but it IS ice-lite (with a=20 > minor fix-up) is covered in that posting. >=20 > In fact, I had re-submitted formally the email you quote as=20 > WGLC comments on > 4/18=20 > (http://www1.ietf.org/mail-archive/web/mmusic/current/msg05592 .html), adding a paragraph at the end stating this, as well as a > reference to RFC 3484. >=20 > So, basically we were thinking exactly the same thing. Good. >=20 > This completely addresses my WGLC comment.=20 >=20 > I also believe that ICE now truely, absolutely, removes any=20 > need for ANAT. This solution will be very clean, efficient=20 > and simple for non-NATed devices. >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Thursday, April 26, 2007 06:45 > > To: Audet, Francois (SC100:3055) > > Cc: Elwell, John; mmusic@ietf.org > > Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6=20 > > transition > >=20 > > Francois, > >=20 > > I have considered this issue, and I have a proposal which I believe=20 > > works. > >=20 > > I think the following are important properties of a solution here: > >=20 > > 1. it not be yet another mode; it should be ICE lite or minor=20 > > orthogonal behavior or something > >=20 > > 2. absolutely, positively, MUST MUST MUST allow nat traversal for a=20 > > peer that is full. This was our fundamental requirement=20 > when designing=20 > > ICE-lite. Anything else and our result is NOT ICE. > >=20 > > 3. be much simpler than ICE-full for dual-stack endpoints=20 > that are not=20 > > natted > >=20 > > 4. maintain the property that the final m/c-line reflects what is=20 > > really used > >=20 > >=20 > > So, your proposal below is not bad, but fails on requirement 4. I=20 > > believe we still need a 'fix-up' reinvite if the finally=20 > selected pair=20 > > doesn't match the m/c-line. > >=20 > > So, here is my suggested variant on your proposal which meets all=20 > > four. > >=20 > > We enhance ICE-lite a bit, so that it works for dual-stack=20 > hosts that=20 > > are not natted or firewalled. As you suggested, when two ICE-lite=20 > > endpoints meet, we don't say that we proceed as if there=20 > was no ICE.=20 > > We do proceed. The answerer will send back its candidates (one > > v4 and a few > > v6), with the a=3Dice-lite flag. Now, neither side will send checks. = > > However, we will do role-selection. Offerer is controller. The=20 > > controller, being ICE-lite, will run RFC3484 to select the=20 > IP address=20 > > pairs, rather than running checks to do so. This will be a totally=20 > > static step. Once it selects, the controller sends a re-INVITE or=20 > > update with the fix-up in the m/c-line, and includes only the=20 > > candidate for its selected IP address. It also includes=20 > > a=3Dremote-candidates telling the other side which IP address/port = to=20 > > use. > >=20 > > As for media cut-through, the answerer (as controlled node) can run > > rfc3484 also, pick what it thinks is the winner, and send=20 > immediately. > > If it turns out that the controller used a variation on rfc3484 or=20 > > something, and picked a different address, the controlled=20 > agent will=20 > > find out when the re-invite comes. > >=20 > > So, what this means is, ice-lite gets a little more=20 > complicated. Its=20 > > not any more complicated than it is today if you have a=20 > single IP. If=20 > > you are dual-stack, the complexity would be current=20 > ICE-lite, plus the=20 > > ability to send the fix-up re-INVITE with a=3Dremote-candidates. > >=20 > > This does mean that a dual-stack host that is not natted=20 > would need to=20 > > be able to respond to STUN requests. This would happen when that=20 > > dual-stack host calls a full implementation. I think this is=20 > > absolutely essential and with fight with great vigor any=20 > attempts to=20 > > have a different mode of ICE which does not require even=20 > responding to=20 > > STUN checks. Big big mistake IMHO. > >=20 > > Now, what about this role conflict bit? Well, per my other note, I=20 > > actually only have cases where both sides are controlling. In that=20 > > case, both would run RFC3484, both would re-INVITE. We'd get glare,=20 > > but it would be resolved by standard RFC3261 techniques.=20 > So, it works.=20 > > Not optimally, since we end up with two re-invites where=20 > one would do.=20 > > But it still works. > >=20 > > I have glanced through the text, and believe this change is=20 > actually=20 > > not hard to make. > >=20 > > Note further that, even with this change, ice-13 and onwards would=20 > > still be compatible with ice-16 (if anyone cares). > >=20 > > Does this work for people? > >=20 > > -Jonathan R. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Francois Audet wrote: > >=20 > > > =20 > > >=20 > > >>>In fact, wouldn't this be useful even for ice-lite (not > > >> > > >>microlite, just > > >> > > >>>lite), where > > >>>if both PSTN gateways are on the public internet, they know > > >> > > >>right away > > >> > > >>>they can skip the > > >>>connectivity check? > > >> > > >>That already happens. If both agents are ICE lite, there are no=20 > > >>connectivity checks that get utilized. > > >=20 > > >=20 > > > Jonathan, > > >=20 > > > I'm reading your section 5 of ICE-15, and I think we have almost=20 > > > what is requested. We probably don't even need anything beyond=20 > > > ice-lite. > > >=20 > > > A sends offer to B. It is not behind a NAT, but it is=20 > dual stack and=20 > > > supports IPv4 and IPv6, so it has: > > >=20 > > > Offer: > > >=20 > > > m=3DIPv4 <- Assumption is that IPv4 is more > > > likely to succeed than IPv6 > > > candidate 1=3DIPv6 > > > candidate 2=3DIPv4 > > > a=3Dice-lite > > >=20 > > >=20 > > > B receives the offer, it is also dual stack and NOT behind a NAT. > > >=20 > > > It sends an answer: > > >=20 > > > m=3DIPv4 > > > candidate 1=3DIPv6 > > > candidate 2=3DIPv4 > > > a=3Dice-lite > > >=20 > > > According to your section 5 it would result in having "NO > > CONNECTIVITY > > > CHECK". > > >=20 > > > (PS: your wording says "ICE cannot proceed", which I think > > is innacurate > > > since > > > the candidates have already been sent, so I think you need > > to clarify > > > that it means > > > "does not proceed with the connectivity check). > > >=20 > > > According to section 5 again, it would result in having the IPv4=20 > > > selected instead of the IPv6 (i.e., the m line). > > >=20 > > > That's NOT the behavior we want. What we want is in this > > case to have > > > both sides use > > > the candidates and the RFC XXXX procedures (the selection > > thing: I don't > > > have the number). > > >=20 > > > One easy way to do this is to have B responding with this answer > > > instead: > > >=20 > > > m=3DIPv6 <- i.e., forcing the other side to use = the > > > IPv6 address > > > candidate 1=3DIPv6 <- I'm not sure we actually need this = line > > > a=3Dice-lite <- This is to tell A that it understood > > > ICE > > >=20 > > > And B would just use the candidate 1=3DIPv6 from the offer > > anyways to send > > > media. > > >=20 > > > I think this solves the problem, no? > > >=20 > > > Isn't this trivial? > > >=20 > >=20 > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 13:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7kS-00017T-Fy; Thu, 26 Apr 2007 13:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7kR-00017O-Sg for mmusic@ietf.org; Thu, 26 Apr 2007 13:27:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7kQ-0004XB-8O for mmusic@ietf.org; Thu, 26 Apr 2007 13:27:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2007 10:27:13 -0700 X-IronPort-AV: i="4.14,456,1170662400"; d="scan'208"; a="372380889:sNHT60644924" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3QHRCAT016611; Thu, 26 Apr 2007 10:27:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3QHR2FG004830; Thu, 26 Apr 2007 17:27:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:27:09 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:27:09 -0700 Message-ID: <4630E0EC.90209@cisco.com> Date: Thu, 26 Apr 2007 13:27:08 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 References: <4630A856.6060501@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D00AF9F1@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00AF9F1@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 17:27:09.0226 (UTC) FILETIME=[1E5450A0:01C78828] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4861; t=1177608432; x=1178472432; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20Concerned=20about=20role=20conflic t=20resolution=20procedure=0A=20inICE-15 |Sender:=20; bh=4qvr27qC+YNICP0fR1RZglneM99DUR13e0t3uJhFSIg=; b=TcJCZNrkvXIljbiXn1Hp7g3okwbQCklSTp1rZFLGpLrneEfEMb+zORVpYiFZ3vN6OXsNOvYP 27I1fD1RwyLYk1ZZfwWUwCPHLf2ivFKMzIWr0AwW5WuilB78k5Qmugjo; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Philip Matthews , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Nothing is black and white here. Is it worth a lot of effort? No. Fixing this however is relatively easy, and already done in -15. We have, all along, been making ongoing and concious decisions to make changes to ICE to make it as broadly deployable as possible. Real, pragmatic issues - SBCs that munge things, gateways that don't want to implement too much, detection of ALG. This has also included supporting as many 3pcc flows as possible, though many of them (and arguably all) are 'ugly'. This, to me, is another 3pcc flow to support, and being one that has seen some usage, I'd like to make ICE attractive there too. -Jonathan R. Elwell, John wrote: > Jonathan, > > This use case breaks as soon as you include in the SDP offer anything > that is asymmetrical in nature, such as capability negotiation or MIKEY. > You would receive in an answer something you expect only in an offer. Do > we really want to spend effort trying to fix such broken > implementations? > > John > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 26 April 2007 14:26 >>To: Philip Matthews >>Cc: mmusic@ietf.org >>Subject: [MMUSIC] Re: Concerned about role conflict >>resolution procedure inICE-15 >> >>Here is a 3pcc use case where both sides are controller: >> >> >> >> A Controller B >> |(1) INV() | | >> |<-------------| | >> |(2) 200(SDP1) | | >> |------------->| | >> | |(3) INV() | >> | |------------->| >> | |(4) 200(SDP2) | >> | |<-------------| >> |(5) ACK(SDP2')| | >> |<-------------| | >> | |(6) ACK(SDP1')| >> | |------------->| >> >>INV() means an INVITE with no SDP. >> >>This is actually a variant on 3pcc flow III, but with fewer messages. >>Its not one of the currently documented flows in RFC 3725 but >>it is in >>use. There are many further variations on this flow as well. >> >>In this model, both A and B will believe they are controlling. >> >>Interestingly, the cases I had thought of for both sides >>thinking they >>were controlled, doesn't work at all. So at the moment, the only real >>cases I have are for both sides being controlling. >> >>Thats good, since it means the proposal in another note I am about to >>post will work. >> >>Per your comment, I'd suggest that we add an appendix section >>on 'Why is >>the conflict resoltuion needed?' which describes this use case, and >>describes limitations. I don't want to beef up the main body >>text with >>what is just explanatory material. >> >>Thanks, >>Jonathan R. >> >> >>Philip Matthews wrote: >> >> >>>Jonathan: >>> >>>I am concerned about the conflict resolution procedure for >>>Controlling-End/Controlled-End that has been added in ICE-15. >>>I haven't seen the 3PCC cases where this problem supposedly exists, >>>and under my assumptions for when one can use ICE, I don't see how >>>the problem can arise. In my mind, the document is very >> >>clear that one >> >>>agent is the initial offerer and the other agent is the initial >>>answerer, and >>>with those assumptions, the conflict resolution procedure >> >>is not needed. >> >>>All this means that I cannot evaluate whether the proposed mechanism >>>actually works or is even needed. >>> >>>I think the document: >>>1) Needs to be explicit about the assumptions on when ICE >> >>can be used >> >>> wrt. the offer/answer procedure. >>>2) Needs to give a reference to examples when the conflict >> >>resolution >> >>> is needed. >>> >>>If you or anyone else could give me details on a specific >> >>use case where >> >>>this problem arises, that would be very helpful. >>> >>>- Philip >>> >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Cisco Fellow Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 13:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7qh-0002jM-Fi; Thu, 26 Apr 2007 13:33:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7qf-0002b0-CC for mmusic@ietf.org; Thu, 26 Apr 2007 13:33:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7qf-0005gF-1V for mmusic@ietf.org; Thu, 26 Apr 2007 13:33:41 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2007 10:33:40 -0700 X-IronPort-AV: i="4.14,456,1170662400"; d="scan'208"; a="770889919:sNHT46792282" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3QHXeNY011729; Thu, 26 Apr 2007 10:33:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3QHXOa1008018; Thu, 26 Apr 2007 17:33:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:33:26 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:33:25 -0700 Message-ID: <4630E265.5040501@cisco.com> Date: Thu, 26 Apr 2007 13:33:25 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews References: <462E7F8B.7020405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 17:33:26.0008 (UTC) FILETIME=[FEE8AF80:01C78828] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2203; t=1177608820; x=1178472820; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Question=20on=20ICE=3A=20Why=20allow=20FQDNs=20for=20 candidate=20addresses? |Sender:=20; bh=/Jxr57Zr9ejO3CyFXiA6fT/m8J/9oJZRNVREWaAt+2o=; b=tRb4QnUCa8EWeEL0dwi4Gb7vLKnn7jCEVSGsr1JT4fD/6NOto+uCMIe4O3nHfvbcp6eTKhCW vu4s/hQ279p9nvgvTjl1xlb+9dpxkpcHbcTolthucTby+hlHqIjfzweBmrMfdSVwjX3d1sTeQY 8HtH/uhVVhF7oBv4pZHI2AFsU=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Philip Matthews wrote: > I can vaguely see how this might work. But are there people who > actually want to do this? Not sure. It was one of those things where, it seemed like it could be useful, and wasn't much harm in having it there. We already allow hostnames in SDP. > Moreover, are there not other ways to achieve the same effect? > 1) Use an SBC to remove host candidates when signaling outside the > enterprise, OR Henry commented on this one ;) > 2) Look at the AoR that you are signaling -- if the domain part does > not match your domain > (or perhaps a short list of domains), then remove all the host > candidates from the SDP. Not so easy to do. Doesn't work with phone numbers. Doesn't work with call forwarding (I call joe@outside that forwards to bob@inside). It makes an assumption, and ICE tries to avoid those. > [I believe that, from ICE-10 onwards, the need to include host > candidates to "support" other > candidates has gone away -- e.g., ICE-08 required you to include the > host candidate that > generated a peer-reflexive candidate] Right. > > Anyway, if we decide this is a good feature, then I think it should be > described in the security > considerations section and/or Appendix B. I'm not sure its useful for this 'feature' (preventing private addresses from departing the enterprise). Not even sure anyone needs it. Its never been clear what attack it actually mitigates. Hostname in the candidate line was more a placeholder for future work. Also, as I said, it was consistent with SDP overall which allows hostnames, even in the c line. As such, I'd rather just leave it as is, rather than guess at how it might get used for an enterprise use case. All the justification we really need is that this is how SDP already works. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 13:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7uy-0005Bb-IC; Thu, 26 Apr 2007 13:38:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7ux-0005BW-EZ for mmusic@ietf.org; Thu, 26 Apr 2007 13:38:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7uv-00071Y-BV for mmusic@ietf.org; Thu, 26 Apr 2007 13:38:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2007 10:38:04 -0700 X-IronPort-AV: i="4.14,456,1170662400"; d="scan'208"; a="372382984:sNHT49836376" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3QHc47a001528; Thu, 26 Apr 2007 10:38:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3QHc4MJ028044; Thu, 26 Apr 2007 17:38:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:37:56 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:37:55 -0700 Message-ID: <4630E372.8000704@cisco.com> Date: Thu, 26 Apr 2007 13:37:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] Re: Question on Verifying ICE Support References: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> <462E7E81.2090203@cisco.com> <462F1644.3050401@pjsip.org> In-Reply-To: <462F1644.3050401@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 17:37:56.0008 (UTC) FILETIME=[9FD76A80:01C78829] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2224; t=1177609084; x=1178473084; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20Question=20on=20Verifying=20ICE=20 Support |Sender:=20; bh=F1e5rkTEYO7tnn8jHbigDVqpZAzY5QlJXCwAnjd/QnQ=; b=R25xjcxt0ryf9BqU80RAt7qNvtfBLD3Qc5hjIfqRK0yroqGzs7ATW6DSCxAPtj45WHJcZ1Rw oXQLVecM1/1kS7C4WNRNNDTaNT8vlE65j6JSSplNkj4dWz2k0EqqYmkF; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Philip Matthews , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Benny Prijono wrote: > Jonathan Rosenberg wrote: > >> Hmm. This is one of these cases where, I vaguely recall there was a >> reason for this, but I cannot remember what it is. >> >> Thinking about it now I would have to agree with you, it certainly >> seems more logical that it should be all of them. Unless I can >> remember why I did it this way, I will change it. > > > > I disagree. IMO the text is correct as it is (although probably it's a > bit confusing). This is what I understood from the text: > > To verify that ICE should be supported for the session, *either* of > these conditions must be met: > o the transport address (the default destination) of each media > stream must be listed as one of the candidate in that media > stream, OR > o if rtcp attribute is present, the RTCP address must be listed as > one of the candidate for the second component for each media > stream. > > IMO requiring that all components must be listed may not work. An SBC > may modify the media stream address but it leaves RTCP attribute > unchanged because it doesn't support it. > >>> Why the "at least one component"? I don't understand why you do not >>> require that there to be an a=candidate attribute for each component? > > > If I understood correctly, of course there will be a=candidate for each > component, or otherwise there will be no component! Sure - but they may not match, since someone has mucked with the SDP but didnt adjust the candidate lines. That is the case we are trying to detect. Interestingly, with the current wording, if an SBC modifies the m/c-line but NOT the a=rtcp line, ICE will in fact proceed. So, the question is, is that what we want? I suspect not. So I am leaning towards changing this back to say that there must be a candidate line for each default. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 13:45:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh81o-0004Uk-5V; Thu, 26 Apr 2007 13:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh81m-0004UX-VE for mmusic@ietf.org; Thu, 26 Apr 2007 13:45:10 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh81k-00088q-SQ for mmusic@ietf.org; Thu, 26 Apr 2007 13:45:10 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hh81k-00010e-0r; Thu, 26 Apr 2007 13:45:08 -0400 In-Reply-To: <3122.59.189.186.50.1177601734.squirrel@webmail.tuffmail.net> References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> <46300B72.1010906@pjsip.org> <5E86095C-3C83-4FA4-98AC-F3A8D9570049@magma.ca> <3122.59.189.186.50.1177601734.squirrel@webmail.tuffmail.net> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <917A8F48-070F-4478-8F33-07E177B4A069@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) Date: Thu, 26 Apr 2007 13:45:09 -0400 To: benny@tmbox.com, Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 26-Apr-07, at 11:35 , benny@tmbox.com wrote: > > You're assuming that just because you bind() your socket to a specific > interface, you can force the OS to spit packets out of that interface, > bypassing the routing table. It won't work. The OS will return > ENETUNREACH/EHOSTUNREACH error if you try to do this. > > So you can't send packet to 3.3.3.3 or 4.4.4.4 using interface > 2.2.2.2, if > the default route points to interface 1.1.1.1. Your connectivity > checks > will fail. > > And so are mine (because 1.1.1.1 is down). > > So both approaches produce the same result, again. Now the discussion is moving from the realm of specification to the realm of implementation. That is, given that we WANT to force the packets to be sent out a specific interface, how do we achieve this under Y, where Y is some specific OS? Since much of my coding experience at this level has been on a proprietary embedded operating system that has a "send packet out interface X" call, I am not the best person to discuss this with, but perhaps others on the list can provide their insights. Has anyone else on this list figured out how to force packets out a specific interface under some popular OS? - Philip PS. And BTW, I have downloaded your STUN/TURN/ICE implementation to take a look at. I haven't had much chance to poke around yet, but I like what I have seen so far. I am glad to see an open-source implementation of ICE. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 14:06:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8MU-0003aT-MC; Thu, 26 Apr 2007 14:06:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8MT-0003aJ-BM for mmusic@ietf.org; Thu, 26 Apr 2007 14:06:33 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hh8MR-0002Hg-NY for mmusic@ietf.org; Thu, 26 Apr 2007 14:06:33 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1Hh8MR-0001sQ-7H; Thu, 26 Apr 2007 14:06:31 -0400 In-Reply-To: <4630E0EC.90209@cisco.com> References: <4630A856.6060501@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D00AF9F1@GBNTHT12009MSX.gb002.siemens.net> <4630E0EC.90209@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F304E71-33CC-4037-AF4C-6E8D6FA7EF8A@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 Date: Thu, 26 Apr 2007 14:06:33 -0400 To: Jonathan Rosenberg , "Elwell, John" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org A comment here. Back at the Montreal meeting in summer 2006, there was a discussion on which network topologies we wanted to support. As some may recall, I had some example topologies that broke ICE-09, and wanted to extend ICE to handle them. We decided at that meeting that we would not support EVERY possible topology, but only ones that seemed more popular/reasonable. (I still claim that my topologies were not unreasonable, but I lost that argument). In fact, ICE-15 will support some of those topologies, but the controlling end has to do some stuff not described in the specification. I am wondering if we are getting to the same point with call flows? It seems that this call flow violates some basic assumptions about how the offer/'answer works. ICE assumes that one agent sends an offer and the other sends an answer. From what I understand about the call flow below (correct me if I am wrong), both ends send offers, and this is the problem. Personally, I think we should restrict ICE to offer/answer scenarios unless others think that offer/offer scenarios are important to support (in which case we need to carefully rethink things). - Philip On 26-Apr-07, at 13:27 , Jonathan Rosenberg wrote: > Nothing is black and white here. Is it worth a lot of effort? No. > Fixing this however is relatively easy, and already done in -15. We > have, all along, been making ongoing and concious decisions to make > changes to ICE to make it as broadly deployable as possible. Real, > pragmatic issues - SBCs that munge things, gateways that don't want > to implement too much, detection of ALG. This has also included > supporting as many 3pcc flows as possible, though many of them (and > arguably all) are 'ugly'. This, to me, is another 3pcc flow to > support, and being one that has seen some usage, I'd like to make > ICE attractive there too. > > -Jonathan R. > > Elwell, John wrote: > >> Jonathan, >> This use case breaks as soon as you include in the SDP offer anything >> that is asymmetrical in nature, such as capability negotiation or >> MIKEY. >> You would receive in an answer something you expect only in an >> offer. Do >> we really want to spend effort trying to fix such broken >> implementations? >> John >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: 26 >>> April 2007 14:26 >>> To: Philip Matthews >>> Cc: mmusic@ietf.org >>> Subject: [MMUSIC] Re: Concerned about role conflict resolution >>> procedure inICE-15 >>> >>> Here is a 3pcc use case where both sides are controller: >>> >>> >>> >>> A Controller B >>> |(1) INV() | | >>> |<-------------| | >>> |(2) 200(SDP1) | | >>> |------------->| | >>> | |(3) INV() | >>> | |------------->| >>> | |(4) 200(SDP2) | >>> | |<-------------| >>> |(5) ACK(SDP2')| | >>> |<-------------| | >>> | |(6) ACK(SDP1')| >>> | |------------->| >>> >>> INV() means an INVITE with no SDP. >>> >>> This is actually a variant on 3pcc flow III, but with fewer >>> messages. Its not one of the currently documented flows in RFC >>> 3725 but it is in use. There are many further variations on this >>> flow as well. >>> >>> In this model, both A and B will believe they are controlling. >>> >>> Interestingly, the cases I had thought of for both sides thinking >>> they were controlled, doesn't work at all. So at the moment, the >>> only real cases I have are for both sides being controlling. >>> >>> Thats good, since it means the proposal in another note I am >>> about to post will work. >>> >>> Per your comment, I'd suggest that we add an appendix section on >>> 'Why is the conflict resoltuion needed?' which describes this use >>> case, and describes limitations. I don't want to beef up the main >>> body text with what is just explanatory material. >>> >>> Thanks, >>> Jonathan R. >>> >>> >>> Philip Matthews wrote: >>> >>> >>>> Jonathan: >>>> >>>> I am concerned about the conflict resolution procedure for >>>> Controlling-End/Controlled-End that has been added in ICE-15. >>>> I haven't seen the 3PCC cases where this problem supposedly exists, >>>> and under my assumptions for when one can use ICE, I don't see how >>>> the problem can arise. In my mind, the document is very >>> >>> clear that one >>> >>>> agent is the initial offerer and the other agent is the initial >>>> answerer, and >>>> with those assumptions, the conflict resolution procedure >>> >>> is not needed. >>> >>>> All this means that I cannot evaluate whether the proposed >>>> mechanism >>>> actually works or is even needed. >>>> >>>> I think the document: >>>> 1) Needs to be explicit about the assumptions on when ICE >>> >>> can be used >>> >>>> wrt. the offer/answer procedure. >>>> 2) Needs to give a reference to examples when the conflict >>> >>> resolution >>> >>>> is needed. >>>> >>>> If you or anyone else could give me details on a specific >>> >>> use case where >>> >>>> this problem arises, that would be very helpful. >>>> >>>> - Philip >>>> >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Cisco Fellow Parsippany, NJ >>> 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 14:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8VK-0005Gv-LC; Thu, 26 Apr 2007 14:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8VJ-0005Gm-GR for mmusic@ietf.org; Thu, 26 Apr 2007 14:15:41 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8VH-0000XK-7p for mmusic@ietf.org; Thu, 26 Apr 2007 14:15:41 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1Hh8VH-0007vg-4A; Thu, 26 Apr 2007 14:15:39 -0400 In-Reply-To: <4630E265.5040501@cisco.com> References: <462E7F8B.7020405@cisco.com> <4630E265.5040501@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AF71420-FC01-49BD-AECA-55A8806E95E3@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 26 Apr 2007 14:15:41 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Cullen Jennings , IETF MMUSIC WG Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 26-Apr-07, at 13:33 , Jonathan Rosenberg wrote: > > > I'm not sure its useful for this 'feature' (preventing private > addresses from departing the enterprise). Not even sure anyone > needs it. Its never been clear what attack it actually mitigates. > Hostname in the candidate line was more a placeholder for future > work. Also, as I said, it was consistent with SDP overall which > allows hostnames, even in the c line. > > As such, I'd rather just leave it as is, rather than guess at how > it might get used for an enterprise use case. All the justification > we really need is that this is how SDP already works. > Cullen posted a message to the BEHAVE list today which seems relevant to this discussion. I have copied it below. It seems to argue in favor of what you are suggesting. I remain uncertain about this, but I have not yet read the draft he references. However, I would still argue that IF we do think we should do this, it should warrant a mention in the Security Considerations section. Perhaps Cullen would like to comment on this? - Philip ==== Message from BEHAVE list below ==== > On Apr 24, 2007, at 6:06 AM, Philip Matthews wrote: > > >> Does anyone see a good reason why a NAT _should not_ decrement the >> TTL field >> (other than the "try to be invisible" argument)? >> Are there security implications to this question? >> > > I think so - an important security property is the properties > described in the "Privacy and Topology Hiding" section of draft- > ietf-v6ops-nap-06 (note this draft has been approved and will be an > RFC soon). Requiring decrement of TTL would reveal internal > topology information which is a big deal in cases where you are > trying to hide if you are currently in europe of US for privacy > reasons. Obviously lots of NATs are deployed where people don't > care about topology hiding but this is a big concern in some > deployments. > > I can't imagine how requiring that NATs do, or don't, decrement the > TTL will help the P2PSIP stuff much but perhaps I am just not > seeing the importance. > > Cullen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 15:19:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9VT-0004KE-UR; Thu, 26 Apr 2007 15:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9VS-0004K9-Os for mmusic@ietf.org; Thu, 26 Apr 2007 15:19:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9VS-0006PL-Ee for mmusic@ietf.org; Thu, 26 Apr 2007 15:19:54 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2007 12:19:54 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="416017830:sNHT71986204" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l3QJJrJO031160; Thu, 26 Apr 2007 12:19:53 -0700 Received: from [128.107.139.43] (dhcp-128-107-139-43.cisco.com [128.107.139.43]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJJrA8002714; Thu, 26 Apr 2007 19:19:53 GMT In-Reply-To: <3AF71420-FC01-49BD-AECA-55A8806E95E3@magma.ca> References: <462E7F8B.7020405@cisco.com> <4630E265.5040501@cisco.com> <3AF71420-FC01-49BD-AECA-55A8806E95E3@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2013F974-49E2-4F4B-9FE6-196D5478284F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 26 Apr 2007 12:19:46 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2804; t=1177615194; x=1178479194; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Question=20on=20ICE=3A=20Why=20allow=20FQDNs=20for=20 candidate=20addresses? |Sender:=20; bh=nwcxWCKg3OfnlYVCnbBbw8ycLPJd3Y7bxTutmzqDRFE=; b=D/P7qxCBn3L+FmTGp0ovqTPKHf4RQSiyibV6XCx2SPuq1Mc0ZKY4AyURL5kceUUJfoh2vGSt yHJWPkWlxPvPsW80PZGwSL1QUr3SOrpNMnIe39/VFx4AzI79xxRl1rdD; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: IETF MMUSIC WG Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I'm a bit behind on my ICE reading but I sort of assumed that ICE would not be saying anything about IP packet level TTLs. Anyways - the approach of using a DNS name that resolves differently inside the enterprise vs outside as a privacy mechanism always seemed fraught with danger and I've never been a big fan of it but I don't really care one way or the other about FQDN in the SDP. Does seem like it would give us a nice place holder for future extensibility. Cullen On Apr 26, 2007, at 11:15 AM, Philip Matthews wrote: > > On 26-Apr-07, at 13:33 , Jonathan Rosenberg wrote: >> >> >> I'm not sure its useful for this 'feature' (preventing private >> addresses from departing the enterprise). Not even sure anyone >> needs it. Its never been clear what attack it actually mitigates. >> Hostname in the candidate line was more a placeholder for future >> work. Also, as I said, it was consistent with SDP overall which >> allows hostnames, even in the c line. >> >> As such, I'd rather just leave it as is, rather than guess at how >> it might get used for an enterprise use case. All the justification >> we really need is that this is how SDP already works. >> > > Cullen posted a message to the BEHAVE list today which seems relevant > to this discussion. I have copied it below. It seems to argue in > favor of what you are suggesting. I remain uncertain about this, but > I have not yet read the draft he references. However, I would still > argue that IF we do think we should do this, it should warrant a > mention in the Security Considerations section. > > Perhaps Cullen would like to comment on this? > > - Philip > > ==== Message from BEHAVE list below ==== > >> On Apr 24, 2007, at 6:06 AM, Philip Matthews wrote: >> >> >>> Does anyone see a good reason why a NAT _should not_ decrement the >>> TTL field >>> (other than the "try to be invisible" argument)? >>> Are there security implications to this question? >>> >> >> I think so - an important security property is the properties >> described in the "Privacy and Topology Hiding" section of draft- >> ietf-v6ops-nap-06 (note this draft has been approved and will be an >> RFC soon). Requiring decrement of TTL would reveal internal >> topology information which is a big deal in cases where you are >> trying to hide if you are currently in europe of US for privacy >> reasons. Obviously lots of NATs are deployed where people don't >> care about topology hiding but this is a big concern in some >> deployments. >> >> I can't imagine how requiring that NATs do, or don't, decrement the >> TTL will help the P2PSIP stuff much but perhaps I am just not >> seeing the importance. >> >> Cullen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 15:36:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9lL-00014F-Q4; Thu, 26 Apr 2007 15:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9lL-000147-C9 for mmusic@ietf.org; Thu, 26 Apr 2007 15:36:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9lJ-0001xd-Lt for mmusic@ietf.org; Thu, 26 Apr 2007 15:36:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2007 12:36:17 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="141047683:sNHT61263081" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3QJaHv2021732; Thu, 26 Apr 2007 12:36:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJaGMN005027; Thu, 26 Apr 2007 19:36:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:36:16 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:36:16 -0700 Message-ID: <4630FF2F.8060002@cisco.com> Date: Thu, 26 Apr 2007 15:36:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt References: <461F7413.5020805@ericsson.com> In-Reply-To: <461F7413.5020805@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 19:36:16.0226 (UTC) FILETIME=[27E6B420:01C7883A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9775; t=1177616177; x=1178480177; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20WGLC=3A=20draft-ietf-mmusic-ice-15.txt |Sender:=20; bh=IgTWAksvCx/JypoOd4y8ehQIs4Ir4AJP07/TvDTIKM0=; b=RwZDJn5NrckBS64Jw1vUaiBqgy1p+36Pab721yVuGLYK8p+SiPGvrtTFSlCnm8Qzp6NLwqrd ORhFuvsyP4AoFB1TOJaBWBVfNV9sN3bXmeeDMGQiD9726CiCojcekqROqWJbVFLEUD+/G2lvgq LRb/4395AapEcAlJCiwTtIYyw=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: mmusic@ietf.org, Lars Eggert X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org thanks for the comments. responses below. Magnus Westerlund wrote: > Hi, > > I have reviewed the draft and have some comments. I will start with all > the real issues. Then I a also have some nits. But let me say that I am > impressed how good this document has become. Thanks. It has been a long road. This document has had more effort put into it (by me at least) than any document I have done since RFC 3261 itself. > > Issues: > > I1. Section 7.2.1.1: Why isn't this section applicable for lite > implementation. If there exist possibilities that the two peer in case > of full implementations are confused about their roles, why can't a full > peer be similar confused and think it is talking to a controlling full > when it in reality talks to a lite. I have a hard time determining if > that can happen at all or not when you think two full peers can be > confused about their roles. It seems a simple fix to tell a lite server > to always do tiebreaking as the loosing side. Based on whats in ICE-15, if one side is lite, they can never be controlling. In the use case for the conflict, on which I have just posted, if one side were lite and the other full, there would be no conflict. It exists only when both are full. However, based on this lengthy ANAT discussion and the proposed enhancement to the lite mode, we can now have a case where two lite implementations talk to each other, and there is a conflict. However in that mode, there is also no STUN, so supporting the resolution through the STUN messages doesn't help. I hope that clarifies. > > I2. Section 7.2.1.1, first bullet: > "o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the > request, there is no conflict." > > When does this happen? To my understanding all ICE peers sending > connectivity checks will indicate if they are controlling or controlled. Correct. THis was an attempt to preserve compatibility with anyone that decided to go ahead and implement -13 or onwards, where they weren't sending this. We agreed at the ietf meeting IIRC to allow that. I can clarify. Text now reads: If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the request, the peer agent may have implemented a previous version of this specification. There may be a conflict, but it cannot be detected. > > I3. Section 7.2.1.4: > > * If the state of that pair is Waiting or Frozen, its state is > changed to In-Progress and a check for that pair is performed > immediately. This is called a triggered check. > > I am a bit concerned with the immediately part here. I do understand > that the check should happen as soon as possible. However by stepping > away from the pacing in these replies you further increases the > burstiness of the connectivity checks. To be slightly more conservative. > Why not simply bump the triggered checks to the top of the queue. The > alternative I see if you like to keep the quick response (and potential > bunching together of response and the triggered check request) is to > delay the next scheduled check an extra Ta interval. That way the > triggered check does not increase the consumed bit-rate. I'm going to send a separate note on this issue of congestion. Its a big issue. > > I4. Section 10. > "Examples of formats which readily meet this > goal are RTP No-Op [31] and RTP comfort noise [25]." > > I would argue that RTP comfort noise does not readily meet it. It works > in some cases, like for an audio stream where the peers both support it. > Two solutions, a) remove comfort noise as an example. b) clarify the > main limitations. I'll add, "and in cases where both sides support it, RTP comfort noise". > > I5. Section 15.1: > > There are a number of cases where one uses 1* in the ABNF. Can these > please be changed to a upper limit on the number of characters. With the > current definition I could use a 5000 digit long priority number from > parsing perspective. This is likely to lead to overflow. In the case of > priority as this is limited to 2^32-1 as largest number then using > 1*10DIGIT seems to be without risk. I guess that also component-ID and > foundation can be limited to a reasonable upper limit. Making it easier > to separate the cases of potentially valid numbers and plain errors. > This comment also applies to section 15.4 and the password and ufrag > definitions. I havent done this so far in protocol specs, but its not an unreasonable request. Here is what I propose: foundation: 1*32ice-char (this is a counter, unique for each interface and/or stun server/interface combo. 32 chars is way more than enough) component-ID: 1*3DIGIT (it can't be more than 256) priority: 1*10DIGIT (this is 32 bits max anyway, so it only needs 10 digits) password: 22*1024ice-char ufrag: 4*1024ice-char these ones, I wanted to make really big. They are for security. I want to leave lots of breathing room for huge random numbers, if needed. > > I6. Pacing of connectivity checks. I need to think a bit more about this > and how ICE relates to the UDP usage guidelines > (http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-guidelines-02.txt) > we are working on getting accepted in the transport area. Ice with the > current parameters are rather aggressive in its bandwidth usage in worst > case. I understand in most cases it would not consume close to as much. > > The biggest problem with this bloody protocol is its purpose resulting > in that basically all STUN request packets could be dropped by NAT > filtering rather than congestion. Or it could be the other way around. > We have no way of knowing. This also causes the connectivity checks > themselves some problem. As all checks easily can congest themselves > thus causing worse performance then the correct rate limited sending > would have. I think we need to at least consider putting some further > limitation or adaptation of the pacing timers in some cases. At least > when you have knowledge about link speeds. > > I know we have had quite some discussion on this topic earlier and the > algorithm has clearly been made to try as few checks as possible thanks > to the freezing of some checklist etc. But in my current role I need to > take this even more serious than before. As above, I'll treat this separately. > > NITS: > > N1. Section 2.6, third paragraph: Last sentence starts with what appears > with an stray "A". > fixed. > N2. Figure 4 and 5. Lack of directional arrows for the requests from L. fixed. > > N3. section 5.7.1, page 30, first paragraph: > "As another example, the > offerer can multiplex RTP and RTCP on the same port and signals it > can do that in the SDP through some new attribute." > > I think an informative reference to the RTP and RTCP MUXing draft > (draft-ietf-avt-rtp-and-rtcp-mux-04) is needed in this sentence to make > it clear what is being talked about. OK. > > N4. Section 5.7.2, second paragraph: "Where O-P>A-P?1:0 is an expression > whose value is 1 if O-P is greater than A-P, and 0 otherwise." As the > (O-P) part isn't used in the above formula, maybe using the actual > (O>A?1:0) is better in this context. Yeah, bug. Fixed. > > N5. Section 7.1: Isn't "STUN Client Procedures" a better section title > than "Client Procedures"? Similar for 7.2. ok. > > N6. Section 8.1.1: > "This check will succeed (since the previous did), causing > the nominated flag of that and only that pair to be set." > > I think this sentence is more correct if you change "will" to "should" > or "is expected to". There are no guarantees that something else causes > a failure of the path. ok. > > N7. Section 12.1.1: > "With this optimization, provisional responses containing an SDP > answer that begins ICE processing for one or more media streams can > be sent reliably without RFC 3264." > > Isn't the reference to RFC 3264 wrong? Shouldn't it be to RFC 3262? oops. fixed. > > N8. Section 16. The line breaks in the SDP example are bad and looks > strange. I have no control over it. rfc-ed will need to fix manually i suspect. > > N9. The following references needs update: > > == Outdated reference: A later version (-03) exists of > draft-ietf-behave-turn-02 > > == Outdated reference: A later version (-01) exists of > draft-ietf-sip-ice-option-tag-00 > > == Outdated reference: A later version (-01) exists of > draft-ietf-avt-rtp-no-op-00 > > == Outdated reference: A later version (-08) exists of > draft-ietf-sip-outbound-07 OK. I refresh my local copies of the I-D bibliography prior to each submission. > > N10. Section B.2 > Use of 192.168.1.1 and 10.0.1.1 as end-host addresses. As these > addresses usually will be assigned the gateway/NAT in respective network > isn't using them for end-host a bad choice. OK, will change. > > N11. Section B.8: > "That section > requires that the type preference for peer reflexive candidates > always be lower than server reflexive. " > > I think "lower" is supposed to be "higher". fixed. THanks for the comments! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 15:41:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9qV-0004uc-UB; Thu, 26 Apr 2007 15:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9qV-0004uX-2R for mmusic@ietf.org; Thu, 26 Apr 2007 15:41:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9qU-0003SM-2H for mmusic@ietf.org; Thu, 26 Apr 2007 15:41:39 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2007 12:41:38 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="416023912:sNHT53531256" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3QJfb9M011942; Thu, 26 Apr 2007 12:41:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJfJMf008509; Thu, 26 Apr 2007 19:41:37 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:41:30 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:41:29 -0700 Message-ID: <46310068.30700@cisco.com> Date: Thu, 26 Apr 2007 15:41:28 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: <462E7F8B.7020405@cisco.com> <4630E265.5040501@cisco.com> <3AF71420-FC01-49BD-AECA-55A8806E95E3@magma.ca> <2013F974-49E2-4F4B-9FE6-196D5478284F@cisco.com> In-Reply-To: <2013F974-49E2-4F4B-9FE6-196D5478284F@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 19:41:29.0398 (UTC) FILETIME=[E290F560:01C7883A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3654; t=1177616497; x=1178480497; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Question=20on=20ICE=3A=20Why=20allow=20FQDNs=20for=20 candidate=20addresses? |Sender:=20; bh=g5scQE55ihfunc74pe53UsqYMLwkT1ARH+BQaVWQwN4=; b=s+A1wmCqYmaITyVkxgAh/OAYNu6KciC9fWH5bmteLbwY0ukDR1isQRMMIWqFeD1kKNeUME27 78oTeYiz4uJlFAQWoCep6kRQRH94pDuhLDVc6Tq1TMJWCnCab5wxG5c7; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Philip Matthews , IETF MMUSIC WG Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Right - this is my point. So I still don't want to mention anything in security considerations since thats just a potential use for it. The main point I am saying is that this is just consistent with SDP. I don't want to open a massive can of worms with fancy DNS usages in a security considerations section. That would be a guaranteed DISCUSS and it would be for no reason. -Jonathan R. Cullen Jennings wrote: > > I'm a bit behind on my ICE reading but I sort of assumed that ICE would > not be saying anything about IP packet level TTLs. Anyways - the > approach of using a DNS name that resolves differently inside the > enterprise vs outside as a privacy mechanism always seemed fraught with > danger and I've never been a big fan of it but I don't really care one > way or the other about FQDN in the SDP. Does seem like it would give us > a nice place holder for future extensibility. > > Cullen > > > > On Apr 26, 2007, at 11:15 AM, Philip Matthews wrote: > >> >> On 26-Apr-07, at 13:33 , Jonathan Rosenberg wrote: >> >>> >>> >>> I'm not sure its useful for this 'feature' (preventing private >>> addresses from departing the enterprise). Not even sure anyone >>> needs it. Its never been clear what attack it actually mitigates. >>> Hostname in the candidate line was more a placeholder for future >>> work. Also, as I said, it was consistent with SDP overall which >>> allows hostnames, even in the c line. >>> >>> As such, I'd rather just leave it as is, rather than guess at how >>> it might get used for an enterprise use case. All the justification >>> we really need is that this is how SDP already works. >>> >> >> Cullen posted a message to the BEHAVE list today which seems relevant >> to this discussion. I have copied it below. It seems to argue in >> favor of what you are suggesting. I remain uncertain about this, but >> I have not yet read the draft he references. However, I would still >> argue that IF we do think we should do this, it should warrant a >> mention in the Security Considerations section. >> >> Perhaps Cullen would like to comment on this? >> >> - Philip >> >> ==== Message from BEHAVE list below ==== >> >>> On Apr 24, 2007, at 6:06 AM, Philip Matthews wrote: >>> >>> >>>> Does anyone see a good reason why a NAT _should not_ decrement the >>>> TTL field >>>> (other than the "try to be invisible" argument)? >>>> Are there security implications to this question? >>>> >>> >>> I think so - an important security property is the properties >>> described in the "Privacy and Topology Hiding" section of draft- >>> ietf-v6ops-nap-06 (note this draft has been approved and will be an >>> RFC soon). Requiring decrement of TTL would reveal internal >>> topology information which is a big deal in cases where you are >>> trying to hide if you are currently in europe of US for privacy >>> reasons. Obviously lots of NATs are deployed where people don't >>> care about topology hiding but this is a big concern in some >>> deployments. >>> >>> I can't imagine how requiring that NATs do, or don't, decrement the >>> TTL will help the P2PSIP stuff much but perhaps I am just not >>> seeing the importance. >>> >>> Cullen > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 15:47:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9w2-0001YE-Am; Thu, 26 Apr 2007 15:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9w0-0001Y6-KA for mmusic@ietf.org; Thu, 26 Apr 2007 15:47:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9vy-0004qm-IA for mmusic@ietf.org; Thu, 26 Apr 2007 15:47:20 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Apr 2007 12:47:18 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="56524605:sNHT59493573" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3QJlHu0032262; Thu, 26 Apr 2007 12:47:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJlHwp029807; Thu, 26 Apr 2007 19:47:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:47:17 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:47:16 -0700 Message-ID: <463101C3.2080309@cisco.com> Date: Thu, 26 Apr 2007 15:47:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 References: <4630A856.6060501@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D00AF9F1@GBNTHT12009MSX.gb002.siemens.net> <4630E0EC.90209@cisco.com> <4F304E71-33CC-4037-AF4C-6E8D6FA7EF8A@magma.ca> In-Reply-To: <4F304E71-33CC-4037-AF4C-6E8D6FA7EF8A@magma.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 19:47:16.0759 (UTC) FILETIME=[B19C0A70:01C7883B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2412; t=1177616837; x=1178480837; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20Concerned=20about=20role=20conflic t=20resolution=20procedure=0A=20inICE-15 |Sender:=20; bh=URt5xKaNIrgT6EW+aFna6y2mPgvcg2tcesRGjH/98as=; b=MIMoUD1ODIPjyZ+CP7QaMgeofJFZftet4i1Yy6FBx686SIlDnduE/M0z/xBcOj3J+hh73b+U iJaLEhFgpJ80OJIjnaASc8f2JR3CxH6W8A8PSA5dtuS4lRva2t/dHgOP; Authentication-Results: sj-dkim-8; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Elwell, John" , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Philip Matthews wrote: > A comment here. > > Back at the Montreal meeting in summer 2006, there was a discussion on > which network topologies we wanted to support. As some may recall, I > had some example topologies that broke ICE-09, and wanted to extend ICE > to handle them. We decided at that meeting that we would not support > EVERY possible topology, but only ones that seemed more > popular/reasonable. (I still claim that my topologies were not > unreasonable, but I lost that argument). In fact, ICE-15 will support > some of those topologies, but the controlling end has to do some stuff > not described in the specification. That was a case for a lot of extra work to cover them. This is really no extra work. > > I am wondering if we are getting to the same point with call flows? It > seems that this call flow violates some basic assumptions about how the > offer/'answer works. ICE assumes that one agent sends an offer and the > other sends an answer. From what I understand about the call flow below > (correct me if I am wrong), both ends send offers, and this is the > problem. Actually careful here; this does in fact happen in some of the legitimate call flows in RFC 3725 also (flow III, which ICE supports). It just so happens that ICE doesn't kick in until the subsequent re-invite in that flow. However it is common practice to do this kind of thing and then fixup the offer to make it a matching answer. That is the meaning of the prime (offer2') in the call flows in flow III. I'd also note that, as I said, I'm aware of deployments with this flow, so its not a corner case. What I don't understand is, why are we reopening this. We more or less concluded on this at the last meeting. We agreed on an approach. I put it in. There was a concern that this might make a simpler ANAT solution impossible, but it turns out not to be the case. I don't understand why we need to overturn this. I'm really eager to keep churn to the spec to a minimum. -JOnathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 15:57:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhA5U-0000db-E6; Thu, 26 Apr 2007 15:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhA5T-0000dU-2Z for mmusic@ietf.org; Thu, 26 Apr 2007 15:57:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhA5R-0007g6-CX for mmusic@ietf.org; Thu, 26 Apr 2007 15:57:06 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2007 12:57:02 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="481775202:sNHT54883924" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3QJv1Hc013357; Thu, 26 Apr 2007 12:57:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJuiZb003944; Thu, 26 Apr 2007 19:57:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:56:58 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 12:56:56 -0700 Message-ID: <46310407.5080505@cisco.com> Date: Thu, 26 Apr 2007 15:56:55 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benny Prijono Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> In-Reply-To: <462F8876.80201@pjsip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 19:56:56.0541 (UTC) FILETIME=[0B2FC0D0:01C7883D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3840; t=1177617421; x=1178481421; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE=20reducing=20number=20of=20checks=20(w as=20Re=3A=20ICE=20pacing=09connectivity=0A=20checks) |Sender:=20; bh=YojkHIdCGYNQWvi55w+yFXhUFq9mgiJp3YGRvtFOXp8=; b=aOgICKjSYQq8+TD4O3g2MkMqS0c+hSBd7rsl8pCghZ9GdL05HMf+b1P9deVJJfJPYpyBi1WL GmItz24Q3vn4Vy/PjDHlMpiuwXX2VH2iGzO8QZPdxXSBtdwZxudkcVUt; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Philip Matthews , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org This most definitely does not work. Forget about APIs, thats the software abstraction layer. Lets talk about networking. See below. Benny Prijono wrote: > > No, I think that's not true (or did I completely miss something?). > > But first of all, let me clarify. The candidates don't get removed; so > if there are N interfaces, there will still be N host candidates being > advertised in SDP. Only the checks that originates from the remaining > host candidates are being removed, during pruning process. > > So even though there is only one (UDP) socket and with some more checks > pruned, connectivity checks will be sent from *all* interfaces. Let me > illustrate with an example. > > (please see this table with fixed width font) > > Agent A | Agent B > candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host > candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host > > With usual ICE, these checks will be created on agent A: > > #1) 1.1.1.1:1 --> 3.3.3.3:3 > #2) 1.1.1.1:1 --> 4.4.4.4:4 > #3) 2.2.2.2:2 --> 3.3.3.3:3 > #4) 2.2.2.2:2 --> 4.4.4.4:4 > > Now, if agent A uses a single socket for all host candidates, AFAIK > check #3 will produce the same result as check #1, and check #4 will > produce the same result as check #2. > > So we can prune the checks further, leaving the check list in agent A to: > > #1) 1.1.1.1:1 --> 3.3.3.3:3 > #2) 1.1.1.1:1 --> 4.4.4.4:4 > > or > > #1) 2.2.2.2:2 --> 3.3.3.3:3 > #2) 2.2.2.2:2 --> 4.4.4.4:4 > > (it doesn't really matter which local host candidate to use, they will > produce the same result using this approach) Not if the networks are not mutually connected. If nets 2 and 3 are connected, and nets 1 and 4 are connected, but there is no connection between 2 and 1, or 2 and 4, and no connection between 3 and 1 or 3 and 4, then your approach fails. And indeed, this is a common problem when you have one interface on a totally private network, another on a public one. Or one on a public access WiFI, and another on a wired corporate network. The whole idea with ICE is NOT to make assumptions on topology. > > > It doesn't matter what type of interfaces are for interface 1.1.1.1 and > 2.2.2.2, all that matters is the routing table in the box (remember that > the socket is bound to INADDR_ANY), and the OS will decide for us which > interface to use to contact 3.3.3.3 and 4.4.4.4, if the routing table > says that destination 3.3.3.3 and 4.4.4.4 are indeed reachable through > one of its interfaces. > > AFAIK this will produce *mostly* the same result as normal ICE for both > successful and failed scenario. > > The only situation that I can think of where the result may differ is > when a remote candidate may be reachable from more than one local > interfaces (maybe two interfaces are configured in load balance mode?). Its the opposite. It won't work when a particular destination is ROUTABLE from both interfaces (meaning your local routing tables assume there is a route from each) but it turns out that there is only CONNECTIVITY from one. Almost all private networks make use of default routes. This choice about using all interfaces was carefully considered for this reason. If you wish to implement this using just one, be my guest, but you are taking risks and I think its a bad idea to put this into the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 16:09:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAHS-0004J9-PL; Thu, 26 Apr 2007 16:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAHR-0004IT-Lh for mmusic@ietf.org; Thu, 26 Apr 2007 16:09:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhAHR-0001km-5m for mmusic@ietf.org; Thu, 26 Apr 2007 16:09:29 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2007 13:09:27 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="141058740:sNHT49440024" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3QK9S4Y026848 for ; Thu, 26 Apr 2007 13:09:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3QK9FMX025635 for ; Thu, 26 Apr 2007 20:09:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:09:15 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:09:15 -0700 Message-ID: <463106EA.3030505@cisco.com> Date: Thu, 26 Apr 2007 16:09:14 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <080c01c7881e$6755a150$05716b80@amer.cisco.com> In-Reply-To: <080c01c7881e$6755a150$05716b80@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 20:09:15.0306 (UTC) FILETIME=[C38658A0:01C7883E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3881; t=1177618168; x=1178482168; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20ICE=20pacing=20connectivity=20checks=20(wasRE=3A[MMUS IC]=09WGLC=3A=09draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=y7KageBGBrFViCcU1TlIfMJyjj1jEugzeRYvTQwJh0U=; b=gxNRRIE24rKsdAjd9LzvY+Eyclr1BjMVs72nS5aLRPYEXTz7+pnaYsZnAU8y3tzrBPgEcW6Q JQWhxSKUuS6djXUFQMy/ZBlFQKbQqUA2h7IDjFBkVkYPvSYSCkHH93UY; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org My proposal for ICE is to document Dan's proposal as the RECOMMENDED algorithm for computing Ta in a way that makes it as good as RTP. As Magnus has indicated, there are many conflicting requirements here. ICE completing switfly is important. I think it is unreasonable to ask ICE to be more responsive, more cautious, than even RTP itself is. An additional question/consideration is what about multiple media streams. With the frozen algorithm, we only start checks for one stream at a time. So if that stream is audio, this means that the checks get paced at the audio pace, and once video is unfrozen, we'll speed quickly through the video checks. That doesnt make a lot of sense either. I'm thinking that the Ta and RTO computation would use an aggregate Ta that is 1/(SUM_i_from_1_to_N(1/Ta_i)) when there are N streams, each of which has a Ta_i computed using Dan's formula. With the existing frozen algorithm, this means that the total media bandwidth is utilized for the checks when we start, and as more streams get unfrozen, that bandwidth is split equally amongst them. I think this works better. In response to Magnus' question around triggered checks, they are excluded from the formula and I think that makes sense. If there is congestion then the initial checks themselves get lost and so the triggering doesn't happen. Furthermore with agressive mode, you'll only see a small number of triggered checks get sent, regardless of the number of candidates. -Jonathan R. Dan Wing wrote: > (Jonathan had also listed this as ICE issue #11.) > > I have moved discussion of ICE pacing to the tsv-area mailing list > , as the tsv-area list is > more appropriate for discussing TCP friendliness. > > My post to tsv-area > > proposed new calculations for ICE's Ta and STUN's RTO. These changes > prevent ICE from exceeding the bandwidth RTP would have consumed. > > -d > > > >>-----Original Message----- >>From: Dan Wing [mailto:dwing@cisco.com] >>Sent: Thursday, April 19, 2007 9:13 AM >>To: 'Lars Eggert'; 'Magnus Westerlund' >>Cc: mmusic@ietf.org >>Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] >>WGLC: draft-ietf-mmusic-ice-15.txt) >> >>I have created an Excel spreadsheet analyzing ICE's behavior >>compared to >>RTP's behavior. I am tweaking this spreadsheet and expect it >>to be useful >>in helping us tune ICE's algorithms. I want to make this a >>more useful >>spreadsheet before sharing it; it doesn't quite do everything >>I like yet. I >>expect it will remain awkward to use, as I'm not an excel wizard. >> >>In my initial analysis using this spreadsheet, I do agree >>that ICE's default >>20ms pacing and STUN's default 100ms retransmit timers are >>too aggressive if >>we assume severely bandwidth-constrained links. I expect >>that adjusting >>these values based on the ptime, RTP packet size, STUN >>Request packet size, >>and number of candidates will result in ICE behaving as well >>as RTP (with >>RTCP feedback) in all cases, and better than RTP (with RTCP >>feedback) in >>some cases. The drawback of such tuning, however, is that >>ICE will take >>longer to complete if there are many candidates. >> >>-d >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 16:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAqm-00074z-Pu; Thu, 26 Apr 2007 16:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhAql-00074s-C0 for mmusic@ietf.org; Thu, 26 Apr 2007 16:45:59 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhAqj-0001lC-OX for mmusic@ietf.org; Thu, 26 Apr 2007 16:45:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2007 13:45:56 -0700 X-IronPort-AV: i="4.14,457,1170662400"; d="scan'208"; a="372418246:sNHT62624808" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3QKjuWF012072; Thu, 26 Apr 2007 13:45:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3QKjmEk027552; Thu, 26 Apr 2007 20:45:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:45:52 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:45:51 -0700 Message-ID: <46310F7F.8020802@cisco.com> Date: Thu, 26 Apr 2007 16:45:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews References: <02F28BFC-1A57-4D81-8A9E-DC924CF20590@magma.ca> In-Reply-To: <02F28BFC-1A57-4D81-8A9E-DC924CF20590@magma.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 20:45:51.0976 (UTC) FILETIME=[E0D79680:01C78843] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7101; t=1177620356; x=1178484356; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Comments=20on=20ICE-15 |Sender:=20; bh=Y1Pm5e+kCOlxjmofU8fbLoK5v2gWZ8dRQX/wCU6Xj44=; b=GSpaVLM7jRmgt5BveRTEj0S2Mrp+MaTk6+H+r48nn9GMmz2khIdS7ynIPx1K5FC1EHAtQFSH HM30y/UE7GhJ+B82UlYcSt9wUoSV6kVv7SILfZ6QbR19oztS2s8WAPoL; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Comments on ICE-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for the comments. Responses inline. Philip Matthews wrote: > Here are some comments on ICE-15. > > > *) When there are multiple check lists, there is nothing that requires > that the various check timers > be spaced out. As it currently stands, all the check timers could > expire at the same time. > I suggest creating just one check timer, and serve round-robin- ing > between the check lists. I don't want to require that; the reason is that in distributed systems where the audio, video and call control pieces are in different boxes/agents, this kind of tight coordination of timers is hard. I'd rather say that,"care should be taken to roughly space out these timers". In a single box solution, you could round-robin, randomize or whatever. In a distributed system it'd probably be more or less randomized anyway. > > *) I think the document needs to be more explicit about how the > transport addresses of an > incoming binding request gets matched to a candidate pair. There is > text scattered through > sections 7.2.1.3, and .4 and .5 which is vague and confusing. > Moreover, it doesn't make the > point that none of this can be done until the offerer receives the > answer. Actually, 7.2 is quite explicit about this. It says: It is possible (and in fact very likely) that an offeror will receive a Binding Request prior to receiving the answer from its peer. If this happens, the agent MUST generate a response (including computation of the mapped address as described in Section 7.2.1.2. Once the answer is received, it MUST proceed with the remaining steps required, namely Section 7.2.1.3, Rosenberg Expires September 27, 2007 [Page 43] Internet-Draft ICE March 2007 Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several triggered notifications to all be sent at the same time, > I think a new section needs to be inserted between sections 7.2.1.2 > and 7.2.1.3. > This section would say roughly > - The processing at this point pauses until an answer is received > from the far end. > Then once un-paused ... > - The destination transport address is matched to a local > candidate using the local UFRAG in the received binding request. No - matching is always done based on IP/port. Never on ufrags. THose will typically be the same for all candidates. > - The source transport address is matched to a remote candidate > using the remote UFRAG. > If there is no such candidate, a new peer-reflexive candidate is > created. > This would replace the vague text in the next few sections that talk > about determining the > candidate pair and the remote password, etc. None of the text seems vague to me. Can you please point to specific places where you find it unclear? > > *) The text says: > o If there is at least one nominated pair in the valid > list for a > media stream and the state of the check list is Running: > * The agent MUST remove all Waiting and Frozen > pairs in the check > list for the same component as the nominated > pairs for that > media stream > Do we remove ALL checks, or just checks of lower priority? In > aggressive nomination mode, > the latter seems to be the better choice, since it gives the chance > for higher priority checks > to find a better path, which seems to be in the spirit of aggressive > nomination. THe text talks about removing *WAITING* and *FROZEN* checks. This, by definition, are not checks that have not yet begun. This means that, you don't need to wait for them to complete. They never started. > > *) Not long afterwards it says: > o Once there is at least one nominated pair in the valid > list for > every component of at least one media stream and the > state of the > check list is Running: > * The agent MUST change the state of processing > for its check > list for that media stream to Completed. > What about checks that are currently "in-progress"? Do these > continue to run? > It seems in keeping with "aggressive nomination" to have them > continue, but > it seems weird to consider the check list to be "Completed" (and > even weirder > to think of ICE as being "Completed", which is what happens if this > is the only > check list). THe previous bullet list would also apply; these top level if statements are not if..else; they are just if(). I'll clarify that. WHat it means is that you will stop transmissions on lower priority in progress checks. It is a bit misleading to claim ICE is completed; though it will be definitively true for regular nomination. For aggressive; there is a race here that you might flip selected pairs a couple of times while stabilizing. However you cannot tell which mode an entity is in and so there is no way to add another state. Anyway the desired behavior is right as currently specified. > > *) Most of the presentation in the document assumes a single offerer > and single answerer. > However, we know that SIP supports forking, and thus ICE must > support an offer being > delivered to multiple answerers, and there are occasional hints > about this in the document. > It would be nice if this was clearly stated early on. I am worried > that we have not paid > enough attention to this case. I added a paragraph in section 6, mentioned that you'll proceed with each offer/answer pair independently: When ICE is used with SIP, forking may result in a single offer generating a multiplicity of answers. In that each, ICE proceeds completely in parallel and independently for each answer, treating the combination of its offer and each answer as an independent offer/answer exchange, with its own set of pairs, check lists, states, and so on. The only case in which processing of one pair impacts another is freeing of candidates, discussed below in . The only interaction I'm aware of across branches is freeing of turn or stun candidates. THis is because everywhere in ICE talks about operations on PAIRS and not on individual candidates, except there. But if you see something please advise. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Apr 26 18:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCqK-0005UZ-JA; Thu, 26 Apr 2007 18:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhCqJ-0005UU-CT for mmusic@ietf.org; Thu, 26 Apr 2007 18:53:39 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhCqH-0001GM-4u for mmusic@ietf.org; Thu, 26 Apr 2007 18:53:38 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3QMrY8d003627; Thu, 26 Apr 2007 16:53:34 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Thu, 26 Apr 2007 16:53:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP: Speed header Date: Thu, 26 Apr 2007 16:53:26 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C607A42D@srvxchg3.cablelabs.com> In-Reply-To: <4d0605c20704241137g3a2af1bfq389b317d551b17da@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP: Speed header Thread-Index: AceGoA/8RhlH5BEfT+OETMrR2LgBRwBtO4hg References: <4d0605c20704241137g3a2af1bfq389b317d551b17da@mail.gmail.com> From: "Jean-Francois Mule" To: "Joseph Pallas" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Joseph Pallas wrote: > RTSP 1.0 has not been as useful a standard as we would like. It > includes some things that no one uses, it omits some things that many > users want, and in a few areas it actually prohibits desirable > practices (unintentionally). The result has been poor > interoperability. Some of this was discussed back then when the 2.0 draft was started. It would be nice to get some specific details based on the current 2.0 drafts, especially the "things [in the current 2.0 draft] that no one uses", and what results in "poor [1.0] interoperability". Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 03:04:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKVV-0001k2-0J; Fri, 27 Apr 2007 03:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKVT-0001ef-Sb for mmusic@ietf.org; Fri, 27 Apr 2007 03:04:39 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhKVS-00087b-CH for mmusic@ietf.org; Fri, 27 Apr 2007 03:04:39 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JH500237ABI1P@siemenscomms.co.uk> for mmusic@ietf.org; Fri, 27 Apr 2007 08:04:30 +0100 (BST) Date: Fri, 27 Apr 2007 08:04:36 +0100 From: "Elwell, John" Subject: RE: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 In-reply-to: <463101C3.2080309@cisco.com> To: Jonathan Rosenberg , Philip Matthews Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00AFA33@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [MMUSIC] Re: Concerned about role conflict resolution procedure inICE-15 Thread-Index: AceIO7uEqzakc9r9Qo+hbWZIDgljgAAXlZLA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4630A856.6060501@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D00AF9F1@GBNTHT12009MSX.gb002.siemens.net> <4630E0EC.90209@cisco.com> <4F304E71-33CC-4037-AF4C-6E8D6FA7EF8A@magma.ca> <463101C3.2080309@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, Whilst I don't think this is a case we really NEED to solve, I can live with the simple solution as already documented in ICE-15. John > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 26 April 2007 20:47 > To: Philip Matthews > Cc: Elwell, John; IETF MMUSIC WG > Subject: Re: [MMUSIC] Re: Concerned about role conflict > resolution procedure inICE-15 > > inline. > > Philip Matthews wrote: > > > A comment here. > > > > Back at the Montreal meeting in summer 2006, there was a > discussion on > > which network topologies we wanted to support. As some may > recall, I > > had some example topologies that broke ICE-09, and wanted > to extend ICE > > to handle them. We decided at that meeting that we would > not support > > EVERY possible topology, but only ones that seemed more > > popular/reasonable. (I still claim that my topologies were not > > unreasonable, but I lost that argument). In fact, ICE-15 > will support > > some of those topologies, but the controlling end has to do > some stuff > > not described in the specification. > > That was a case for a lot of extra work to cover them. This > is really no > extra work. > > > > > > I am wondering if we are getting to the same point with > call flows? It > > seems that this call flow violates some basic assumptions > about how the > > offer/'answer works. ICE assumes that one agent sends an > offer and the > > other sends an answer. From what I understand about the > call flow below > > (correct me if I am wrong), both ends send offers, and > this is the > > problem. > > Actually careful here; this does in fact happen in some of the > legitimate call flows in RFC 3725 also (flow III, which ICE > supports). > It just so happens that ICE doesn't kick in until the subsequent > re-invite in that flow. However it is common practice to do > this kind of > thing and then fixup the offer to make it a matching answer. > That is the > meaning of the prime (offer2') in the call flows in flow III. > > I'd also note that, as I said, I'm aware of deployments with > this flow, > so its not a corner case. > > What I don't understand is, why are we reopening this. We > more or less > concluded on this at the last meeting. We agreed on an > approach. I put > it in. There was a concern that this might make a simpler > ANAT solution > impossible, but it turns out not to be the case. I don't > understand why > we need to overturn this. I'm really eager to keep churn to > the spec to > a minimum. > > -JOnathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 04:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMBB-0000QK-6q; Fri, 27 Apr 2007 04:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMB9-0000QA-Ew for mmusic@ietf.org; Fri, 27 Apr 2007 04:51:47 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhMB7-0002p8-15 for mmusic@ietf.org; Fri, 27 Apr 2007 04:51:47 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3R8phBI009338; Fri, 27 Apr 2007 02:51:43 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Fri, 27 Apr 2007 02:51:42 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Date: Fri, 27 Apr 2007 02:51:36 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C607A44E@srvxchg3.cablelabs.com> In-Reply-To: <4630ACE9.6020607@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition Thread-Index: AceICTLvYVoLIvgYSYCpoFKYPNJHlQAmMmfw References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk><461A3A35.8090200@cisco.com><1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com><461B9001.9080402@cisco.com><1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> <4630ACE9.6020607@cisco.com> From: "Jean-Francois Mule" To: "Jonathan Rosenberg" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi all, Jonathan wrote: > 1. it not be yet another mode; it should be ICE lite or minor > orthogonal behavior or something I agree that we should not have more profiles of ICE (no micro/ultra-lite version). But let's not think that ICE-lite is it, even the proposed solution below. I think there is value in connectivity checks given the known shortcomings of 3484 and the fact that ICE provides an application-level selection mechanism which by essence should guarantee "Internet *Connectivity Establishment*". > 3. be much simpler than ICE-full for dual-stack endpoints that are not > natted After reading a few drafts and archives in the v6ops group (old and current), there are known limitations of 3484 and many proposals on how the address selection mechanism should be updated or improved to ultimately guarantee connectivity. This goes beyond the NAT cases, and it is sometimes applicable to multi-homed v6 nodes, etc. References: http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03 http://tools.ietf.org/html/draft-arifumi-v6ops-addr-select-ps-01 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-req-01. txt http://www.ops.ietf.org/lists/v6ops/v6ops.2004/msg01072.html When I read your proposal trying to connect the dots between this thread and the above v6ops references (looking at it as someone deciding what to implement in a dual-stack host given the current state of the art), it seems to me that with ICE, we have a mechanism to resolve those potential 3484 issues by doing connectivity checks. Yet, we're about to say, no, just do ICE-lite+ and no connectivity checks. > So, what this means is, ice-lite gets a little more complicated. Its > not > any more complicated than it is today if you have a single IP. If you > are dual-stack, the complexity would be current ICE-lite, plus the > ability to send the fix-up re-INVITE with a=3Dremote-candidates. And why not add connectivity checks too given the above references? At a minimum, there should be a strong statement made in the draft that dual-stack hosts using 3484 SHOULD consider full implementation of ICE. > This does mean that a dual-stack host that is not natted would need to > be able to respond to STUN requests. This would happen when that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This begs the question of why not bite the bullet and mandate connectivity checks in this case? What is happening here is folks trying to lower the bar on the level of requirements for ICE by putting ICE-lite, yet some others raising it to cover more use cases. I think the draft must contain a warning in the ICE-lite definition that ICE-lite does not guarantee connectivity establishment. > dual-stack host calls a full implementation. I think this is > absolutely > essential and with fight with great vigor any attempts to have a > different mode of ICE which does not require even responding to STUN > checks. Big big mistake IMHO. >=20 > Now, what about this role conflict bit? Well, per my other note, I > actually only have cases where both sides are controlling. In that > case, > both would run RFC3484, both would re-INVITE. We'd get glare, but it > would be resolved by standard RFC3261 techniques. So, it works. Not > optimally, since we end up with two re-invites where one would do. But > it still works. >=20 > I have glanced through the text, and believe this change is actually > not > hard to make. >=20 > Note further that, even with this change, ice-13 and onwards would > still > be compatible with ice-16 (if anyone cares). >=20 > Does this work for people? This scenario continues to pose the question of what is ICE-lite useful for without connectivity checks and what guidance is provided to implementers. Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 05:02:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMLa-0004PU-K9; Fri, 27 Apr 2007 05:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMLZ-0004PL-7B for mmusic@ietf.org; Fri, 27 Apr 2007 05:02:33 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhMLX-0006bj-UW for mmusic@ietf.org; Fri, 27 Apr 2007 05:02:33 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l3R92UDx012771; Fri, 27 Apr 2007 03:02:30 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com); Fri, 27 Apr 2007 03:02:30 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/488/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2007 03:02:24 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C607A44F@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-15 and SHOULD in 4.1.1.2. Thread-Index: AceIqsWzdL2EGan4SF+IVcRkbfstjA== From: "Jean-Francois Mule" To: "Jonathan Rosenberg" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: mmusic@ietf.org Subject: [MMUSIC] ICE-15 and SHOULD in 4.1.1.2. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan, I must say that the ICE-15 draft is well written and that it shows the considerable efforts you made to improve the text - thank you. I had no comments in the WGLC period as I did not find any technical issues with the proposed solution in the limited time I spent to review the draft. Here is one comment though for your consideration (based on re-reading a few sections in the context of the micro-lite thread). --- Use of SHOULD in 4.1.1.2.=20 Section 4.1.1.2. must distinguish between=20 - what a developer must implement to have a compliant agent of full ICE (independent of the agent's deployment usage), and,=20 - what the agent is allowed to disable during the protocol operations due to "provider variations". Reading the text, you spend time explaining the SHOULD relaxation due to the latter. This section must clearly state that a compliant agent of full ICE MUST implement "this and that", e.g. STUN and both the STUN Allocate tand Binding requests. Then the conditional MUST you have in paragraph 2 of 4.1.1.2 can stress the usage. I note WGLC is over however, ignore as you wish or use as you see fit. Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 07:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOtu-0002uO-VL; Fri, 27 Apr 2007 07:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOtt-0002tN-Eu for mmusic@ietf.org; Fri, 27 Apr 2007 07:46:09 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOtr-0001av-Vw for mmusic@ietf.org; Fri, 27 Apr 2007 07:46:09 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RBjkbc018078 for ; Fri, 27 Apr 2007 14:46:06 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:45:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:45:59 +0300 Received: from [172.21.59.57] ([172.21.59.57]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:45:59 +0300 Message-ID: <4631E276.1000906@nsn.com> Date: Fri, 27 Apr 2007 14:45:58 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 11:45:59.0101 (UTC) FILETIME=[9F98DED0:01C788C1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [MMUSIC] File transfer draft, version -01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi: I have just submitted version -01 of the file transfer draft. This version closes all the known open issues and in the authors' opinion, it is ready for WGLC. It would be nice if people can review it and post comments. Latest version: http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-01.txt http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-01.html Diff changes: http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-01-from-00.html List of changes: * Usage with a capability query (OPTIONS request in SIP) is described. An example of the SDP usage of capability query is added. * Added text encouraging applications to sanitize the name selector to avoid that special characters are (/\*:) are interpreted by the operating system. * Examples changed so that the SDP request MSRP messages to contain a message/cpim wrapper, as the text requires. * Text added indicating that one file equals one MSRP message (e.g., one message/cpim body). This wasn't clear in previous versions. * Text added indicating that if you chunk, you don't need to wait for a 200 OK before sending the next chunk. An example has been changed to reflect this behavior. /Miguel -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 09:32:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQYI-0000kS-PX; Fri, 27 Apr 2007 09:31:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQYH-0000kK-W9 for mmusic@ietf.org; Fri, 27 Apr 2007 09:31:58 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQYG-00030r-87 for mmusic@ietf.org; Fri, 27 Apr 2007 09:31:57 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B60F218CB; Fri, 27 Apr 2007 15:31:55 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-0c-4631fb4b8267 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 71B8521879; Fri, 27 Apr 2007 15:31:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 15:31:55 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 15:31:54 +0200 Message-ID: <4631FB4A.1080000@ericsson.com> Date: Fri, 27 Apr 2007 15:31:54 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <080c01c7881e$6755a150$05716b80@amer.cisco.com> <463106EA.3030505@cisco.com> In-Reply-To: <463106EA.3030505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 13:31:54.0840 (UTC) FILETIME=[6BE9AD80:01C788D0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg skrev: > My proposal for ICE is to document Dan's proposal as the RECOMMENDED > algorithm for computing Ta in a way that makes it as good as RTP. As > Magnus has indicated, there are many conflicting requirements here. ICE > completing switfly is important. I think it is unreasonable to ask ICE > to be more responsive, more cautious, than even RTP itself is. I think Dan's proposal points at at least on important factor. That ICE scales to the planned used bit-rate that way not making it worse than a planned RTP stream. However, the basic fact is that RTP is no wonder of congestion control and network friendly behavior. And the issue is that a wrongly configured media bit-rate may create congestion issues. But having some binding to session negotiated bit-rate is better than none. I would also like to consider if there should be some upper limit on this, independent of the bit-rate of the media stream. Are there some bit-rate where ICE works well enough and making it use more and converge quicker isn't wort it. That way at least serious configuration errors will not result in extended periods of problems. > > An additional question/consideration is what about multiple media > streams. With the frozen algorithm, we only start checks for one stream > at a time. So if that stream is audio, this means that the checks get > paced at the audio pace, and once video is unfrozen, we'll speed quickly > through the video checks. That doesnt make a lot of sense either. > > I'm thinking that the Ta and RTO computation would use an aggregate Ta > that is 1/(SUM_i_from_1_to_N(1/Ta_i)) when there are N streams, each of > which has a Ta_i computed using Dan's formula. With the existing frozen > algorithm, this means that the total media bandwidth is utilized for the > checks when we start, and as more streams get unfrozen, that bandwidth > is split equally amongst them. I think this works better. Yes, sounds reasonable. > > In response to Magnus' question around triggered checks, they are > excluded from the formula and I think that makes sense. If there is > congestion then the initial checks themselves get lost and so the > triggering doesn't happen. Furthermore with agressive mode, you'll only > see a small number of triggered checks get sent, regardless of the > number of candidates. > > My question is what do you win with that rather than moving the triggered checks to the top of the paced list. That way you keep the rate and avoid hurting yourself more than what you would by instantly initiate the triggered checks. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 09:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQeT-0007bH-1t; Fri, 27 Apr 2007 09:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQeR-0007b6-EM for mmusic@ietf.org; Fri, 27 Apr 2007 09:38:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQeQ-000506-Qt for mmusic@ietf.org; Fri, 27 Apr 2007 09:38:19 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 336E321843; Fri, 27 Apr 2007 15:38:18 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-76-4631fccad361 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CF05201E3; Fri, 27 Apr 2007 15:38:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 15:38:17 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 15:38:17 +0200 Message-ID: <4631FCC9.50002@ericsson.com> Date: Fri, 27 Apr 2007 15:38:17 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt References: <461F7413.5020805@ericsson.com> <4630FF2F.8060002@cisco.com> In-Reply-To: <4630FF2F.8060002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 13:38:17.0854 (UTC) FILETIME=[5034F9E0:01C788D1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mmusic@ietf.org, Lars Eggert X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Hi, Issues I1 and I2 are fine with clarification and proposed text. We leave the congestion issue to other threads. Jonathan Rosenberg skrev: > Magnus Westerlund wrote: >> >> >> I4. Section 10. >> "Examples of formats which readily meet this >> goal are RTP No-Op [31] and RTP comfort noise [25]." >> >> I would argue that RTP comfort noise does not readily meet it. It >> works in some cases, like for an audio stream where the peers both >> support it. Two solutions, a) remove comfort noise as an example. b) >> clarify the main limitations. > > I'll add, "and in cases where both sides support it, RTP comfort noise". > Okay, sounds good. > >> >> I5. Section 15.1: >> >> There are a number of cases where one uses 1* in the ABNF. Can these >> please be changed to a upper limit on the number of characters. With >> the current definition I could use a 5000 digit long priority number >> from parsing perspective. This is likely to lead to overflow. In the >> case of priority as this is limited to 2^32-1 as largest number then >> using 1*10DIGIT seems to be without risk. I guess that also >> component-ID and foundation can be limited to a reasonable upper >> limit. Making it easier to separate the cases of potentially valid >> numbers and plain errors. This comment also applies to section 15.4 >> and the password and ufrag definitions. > > I havent done this so far in protocol specs, but its not an unreasonable > request. Here is what I propose: > > foundation: 1*32ice-char (this is a counter, unique for each interface > and/or stun server/interface combo. 32 chars is way more than enough) > > component-ID: 1*3DIGIT (it can't be more than 256) > > priority: 1*10DIGIT (this is 32 bits max anyway, so it only needs 10 > digits) > > password: 22*1024ice-char > ufrag: 4*1024ice-char > > these ones, I wanted to make really big. They are for security. I want > to leave lots of breathing room for huge random numbers, if needed. > I found the numbers reasonable. I don't see a problem with the 1024 characters. It is simple better to know that if there are more than 1024 characters then there is an error. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 12:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTQS-0001Vn-4l; Fri, 27 Apr 2007 12:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTQR-0001Vh-0n for mmusic@ietf.org; Fri, 27 Apr 2007 12:36:03 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTQP-0003iF-D3 for mmusic@ietf.org; Fri, 27 Apr 2007 12:36:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2007 09:36:00 -0700 X-IronPort-AV: i="4.14,462,1170662400"; d="scan'208"; a="372553405:sNHT57509504" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3RGa0hw014772; Fri, 27 Apr 2007 09:36:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3RGZdMf029228; Fri, 27 Apr 2007 16:36:00 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:35:53 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:35:52 -0700 Message-ID: <46322667.6070602@cisco.com> Date: Fri, 27 Apr 2007 12:35:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 transition References: <50B1CBA96870A34799A506B2313F26670B7D7828@ntht201e.siemenscomms.co.uk><461A3A35.8090200@cisco.com><1ECE0EB50388174790F9694F77522CCF0FF719F2@zrc2hxm0.corp.nortel.com><461B9001.9080402@cisco.com><1ECE0EB50388174790F9694F77522CCF0FFBBB88@zrc2hxm0.corp.nortel.com> <4630ACE9.6020607@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C607A44E@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C607A44E@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 16:35:52.0805 (UTC) FILETIME=[1F0D7950:01C788EA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5899; t=1177691760; x=1178555760; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20ICE=20micro-lite=20for=20support=2 0of=20IPv6=20transition |Sender:=20; bh=chxA/AKd5EXW7ZfkZXIwx5UNu62OIbL6RkisZ89MDSI=; b=hB7j/waqzWiRFwtgx2db1vcgvarhKqL8xIRVcBNRpc/CgtNc2Z/PGcwU0OM6Rf8MgP10o9xU s5SMCJowiUhP1MkWCw4AQoI8S+KLK3bVQZ+Fvar3BbNYHkSf2HkHlJ8B; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Jean-Francois Mule wrote: > Hi all, > > Jonathan wrote: > >>1. it not be yet another mode; it should be ICE lite or minor >>orthogonal behavior or something > > I agree that we should not have more profiles of ICE (no > micro/ultra-lite version). But let's not think that ICE-lite is it, even > the proposed solution below. > I think there is value in connectivity checks given the known > shortcomings of 3484 and the fact that ICE provides an application-level > selection mechanism which by essence should guarantee "Internet > *Connectivity Establishment*". Agree. THis is true generally; the doc has warnings about ICE-lite. > > >>3. be much simpler than ICE-full for dual-stack endpoints that are not >>natted > > After reading a few drafts and archives in the v6ops group (old and > current), there are known limitations of 3484 and many proposals on how > the address selection mechanism should be updated or improved to > ultimately guarantee connectivity. This goes beyond the NAT cases, and > it is sometimes applicable to multi-homed v6 nodes, etc. > > References: > http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03 > http://tools.ietf.org/html/draft-arifumi-v6ops-addr-select-ps-01 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-req-01. > txt > http://www.ops.ietf.org/lists/v6ops/v6ops.2004/msg01072.html > > When I read your proposal trying to connect the dots between this thread > and the above v6ops references (looking at it as someone deciding what > to implement in a dual-stack host given the current state of the art), > it seems to me that with ICE, we have a mechanism to resolve those > potential 3484 issues by doing connectivity checks. Yet, we're about to > say, no, just do ICE-lite+ and no connectivity checks. No, I'm not saying that. I'm saying, if you think you can deal with the following limitations A,B, and C, then use ice-lite. Otherwise, use full, and full is always better. In the case of dual-stack, I don't follow v6ops, so if you could provide some text that I could include in ICE, summarizing limitations, giving some guidance for when to use full, that would be great. > > >>So, what this means is, ice-lite gets a little more complicated. Its >>not >>any more complicated than it is today if you have a single IP. If you >>are dual-stack, the complexity would be current ICE-lite, plus the >>ability to send the fix-up re-INVITE with a=remote-candidates. > > > And why not add connectivity checks too given the above references? > At a minimum, there should be a strong statement made in the draft that > dual-stack hosts using 3484 SHOULD consider full implementation of ICE. I think that this is true in general, not just for dual stack. The introduction, section 2.7, says this: It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation. Even for devices that are always connected to the public Internet, a full implementation is preferable if achievable. and later in the appendix: It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation. Even for devices that are always connected to the public Internet, a full implementation is preferable if achievable. A full implementation will reduce call setup times. Full implementations also obtain the security benefits of ICE unrelated to NAT traversal; in particular, the voice hammer attack described in Section 17 is prevented only for full implementations, not lite. Finally, it is often the case that a device which finds itself with a public address today will be placed in a network tomorrow where it will be behind a NAT. It is difficult to definitively know, over the lifetime of a device or product, that it will always be used on the public Internet. Full implementation provides assurance that communications will always work. so, it would be appropriate to add more here for dual-stack. > > > >>This does mean that a dual-stack host that is not natted would need to >>be able to respond to STUN requests. This would happen when that > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This begs the question of why not bite the bullet and mandate > connectivity checks in this case? > What is happening here is folks trying to lower the bar on the level of > requirements for ICE by putting ICE-lite, yet some others raising it to > cover more use cases. If it were just as easy as 'just send them too', I would agree. But its not. IMHO the hard part of ICE is all the state machinery. Its the check lists, the timers, the frozen algorithm, sending updates, computing remote-candidate, dealing with priority and peer reflexive candidates, all of that. All of which are necessary when you are sending checks too. So I think the bar for ice-lite is quite a bit lower than full ICE. > > I think the draft must contain a warning in the ICE-lite definition that > ICE-lite does not guarantee connectivity establishment. OK. >>Does this work for people? > > > This scenario continues to pose the question of what is ICE-lite useful > for without connectivity checks and what guidance is provided to > implementers. Please take a look at the intro and appendix A, and see if you feel more needs to be said. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 13:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUZI-0004Vc-8f; Fri, 27 Apr 2007 13:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUZG-0004VS-M7 for mmusic@ietf.org; Fri, 27 Apr 2007 13:49:14 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUZD-0004zC-S3 for mmusic@ietf.org; Fri, 27 Apr 2007 13:49:13 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HhUZD-0006MX-1E; Fri, 27 Apr 2007 13:49:11 -0400 In-Reply-To: <46310068.30700@cisco.com> References: <462E7F8B.7020405@cisco.com> <4630E265.5040501@cisco.com> <3AF71420-FC01-49BD-AECA-55A8806E95E3@magma.ca> <2013F974-49E2-4F4B-9FE6-196D5478284F@cisco.com> <46310068.30700@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? Date: Fri, 27 Apr 2007 13:49:16 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Cullen Jennings , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org OK. My concern was simply over the additional implementation complexity. However, if no one else is concerned about this, then I am OK with it. However, if there is someone who has an ICE implementation that does not support an FQDN instead of an IP address in this position, it would be useful for them to speak up. Otherwise, I am willing to let this go. - Philip On 26-Apr-07, at 15:41 , Jonathan Rosenberg wrote: > Right - this is my point. > > So I still don't want to mention anything in security > considerations since thats just a potential use for it. The main > point I am saying is that this is just consistent with SDP. I don't > want to open a massive can of worms with fancy DNS usages in a > security considerations section. That would be a guaranteed DISCUSS > and it would be for no reason. > > -Jonathan R. > > Cullen Jennings wrote: > >> I'm a bit behind on my ICE reading but I sort of assumed that ICE >> would not be saying anything about IP packet level TTLs. Anyways >> - the approach of using a DNS name that resolves differently >> inside the enterprise vs outside as a privacy mechanism always >> seemed fraught with danger and I've never been a big fan of it >> but I don't really care one way or the other about FQDN in the >> SDP. Does seem like it would give us a nice place holder for >> future extensibility. >> Cullen >> On Apr 26, 2007, at 11:15 AM, Philip Matthews wrote: >>> >>> On 26-Apr-07, at 13:33 , Jonathan Rosenberg wrote: >>> >>>> >>>> >>>> I'm not sure its useful for this 'feature' (preventing private >>>> addresses from departing the enterprise). Not even sure anyone >>>> needs it. Its never been clear what attack it actually mitigates. >>>> Hostname in the candidate line was more a placeholder for future >>>> work. Also, as I said, it was consistent with SDP overall which >>>> allows hostnames, even in the c line. >>>> >>>> As such, I'd rather just leave it as is, rather than guess at how >>>> it might get used for an enterprise use case. All the justification >>>> we really need is that this is how SDP already works. >>>> >>> >>> Cullen posted a message to the BEHAVE list today which seems >>> relevant >>> to this discussion. I have copied it below. It seems to argue in >>> favor of what you are suggesting. I remain uncertain about this, but >>> I have not yet read the draft he references. However, I would still >>> argue that IF we do think we should do this, it should warrant a >>> mention in the Security Considerations section. >>> >>> Perhaps Cullen would like to comment on this? >>> >>> - Philip >>> >>> ==== Message from BEHAVE list below ==== >>> >>>> On Apr 24, 2007, at 6:06 AM, Philip Matthews wrote: >>>> >>>> >>>>> Does anyone see a good reason why a NAT _should not_ decrement the >>>>> TTL field >>>>> (other than the "try to be invisible" argument)? >>>>> Are there security implications to this question? >>>>> >>>> >>>> I think so - an important security property is the properties >>>> described in the "Privacy and Topology Hiding" section of draft- >>>> ietf-v6ops-nap-06 (note this draft has been approved and will be an >>>> RFC soon). Requiring decrement of TTL would reveal internal >>>> topology information which is a big deal in cases where you are >>>> trying to hide if you are currently in europe of US for privacy >>>> reasons. Obviously lots of NATs are deployed where people don't >>>> care about topology hiding but this is a big concern in some >>>> deployments. >>>> >>>> I can't imagine how requiring that NATs do, or don't, decrement the >>>> TTL will help the P2PSIP stuff much but perhaps I am just not >>>> seeing the importance. >>>> >>>> Cullen > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 14:35:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVIJ-0004D4-Mg; Fri, 27 Apr 2007 14:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVIH-0004Cz-Tx for mmusic@ietf.org; Fri, 27 Apr 2007 14:35:45 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVIH-0008A5-IK for mmusic@ietf.org; Fri, 27 Apr 2007 14:35:45 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HhVIH-0006dx-0z; Fri, 27 Apr 2007 14:35:45 -0400 In-Reply-To: <46310F7F.8020802@cisco.com> References: <02F28BFC-1A57-4D81-8A9E-DC924CF20590@magma.ca> <46310F7F.8020802@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FA864A4-34C2-42BE-8A0E-5518A9D0C7F9@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Re: Comments on ICE-15 Date: Fri, 27 Apr 2007 14:35:49 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 26-Apr-07, at 16:45 , Jonathan Rosenberg wrote: > Thanks for the comments. Responses inline. > > Philip Matthews wrote: > >> Here are some comments on ICE-15. >> *) When there are multiple check lists, there is nothing that >> requires that the various check timers >> be spaced out. As it currently stands, all the check timers >> could expire at the same time. >> I suggest creating just one check timer, and serve round- >> robin- ing between the check lists. > > I don't want to require that; the reason is that in distributed > systems where the audio, video and call control pieces are in > different boxes/agents, this kind of tight coordination of timers > is hard. I'd rather say that,"care should be taken to roughly space > out these timers". In a single box solution, you could round-robin, > randomize or whatever. In a distributed system it'd probably be > more or less randomized anyway. I am OK with saying "care should be taken to roughly space out these timers". > > >> *) I think the document needs to be more explicit about how the >> transport addresses of an >> incoming binding request gets matched to a candidate pair. >> There is text scattered through >> sections 7.2.1.3, and .4 and .5 which is vague and confusing. >> Moreover, it doesn't make the >> point that none of this can be done until the offerer receives >> the answer. > > Actually, 7.2 is quite explicit about this. It says: > > It is possible (and in fact > very likely) that an offeror will receive a Binding Request > prior to > receiving the answer from its peer. If this happens, the agent > MUST > generate a response (including computation of the mapped address as > described in Section 7.2.1.2. Once the answer is received, it MUST > proceed with the remaining steps required, namely Section 7.2.1.3, > > > > Rosenberg Expires September 27, 2007 > [Page 43] > Internet-Draft ICE March > 2007 > > > Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In > cases where multiple STUN requests are received before the answer, > this may cause several triggered notifications to all be sent at > the > same time, > > >> I think a new section needs to be inserted between sections >> 7.2.1.2 and 7.2.1.3. >> This section would say roughly >> - The processing at this point pauses until an answer is >> received from the far end. >> Then once un-paused ... >> - The destination transport address is matched to a local >> candidate using the local UFRAG in the received binding >> request. > > No - matching is always done based on IP/port. Never on ufrags. > THose will typically be the same for all candidates. To be more precise, this is what I think happens: a) Using the local UFRAG in the received binding request, locate the set of candidates with that UFRAG. These candidates will all be associated with the same offer. b) With the IP and port in the received binding request, select the subset of (a) that has this address and port as its base. The result will be a set of candidates that all share the same ufrag and base, and thus share the same password. These candidates will all have been sent is the same offer and be associated with a single media stream. Use this tuple (local base, local ufrag, local password) in sections 7.2.1.3, 7.2.1.4, and 7.2.1.5. >> - The source transport address is matched to a remote >> candidate using the remote UFRAG. >> If there is no such candidate, a new peer-reflexive >> candidate is created. >> This would replace the vague text in the next few sections >> that talk about determining the >> candidate pair and the remote password, etc. > > None of the text seems vague to me. Can you please point to > specific places where you find it unclear? My concern was over the text in section 7.2.1.4 that read: If a triggered check is to be generated, it is constructed and processed as described in Section 7.1.1. These procedures require the agent to know the transport address, username fragment and password for the peer. The username fragment for the remote candidate is equal to the part after the colon of the USERNAME in the Binding Request that was just received. Using that username fragment, the agent can check the SDP messages received from its peer (there may be more than one in cases of forking), and find this username fragment. The corresponding password is then selected. ... I was thinking that this section could be replaced with: use the ufrag, password, and base determined above. > >> *) The text says: >> o If there is at least one nominated pair in the >> valid list for a >> media stream and the state of the check list is >> Running: >> * The agent MUST remove all Waiting and >> Frozen pairs in the check >> list for the same component as the >> nominated pairs for that >> media stream >> Do we remove ALL checks, or just checks of lower priority? In >> aggressive nomination mode, >> the latter seems to be the better choice, since it gives the >> chance for higher priority checks >> to find a better path, which seems to be in the spirit of >> aggressive nomination. > > THe text talks about removing *WAITING* and *FROZEN* checks. This, > by definition, are not checks that have not yet begun. This means > that, you don't need to wait for them to complete. They never started. This is a topic we have discussed before. Due to triggered checks and other things, with Aggressive Nomination, lower-priority checks can complete before higher priority checks even start. So the question is: Do we try to improve the quality of the path found by Aggressive Nomination by allowing these higher-priority checks to run, or is Aggressive Nomination totally optimized towards finishing as fast as possible? With Regular Nomination, which is more focused on path quality, these higher-priority checks WILL be allowed to run, and thus a higher- quality path will be found it it exists. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 15:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSO-0002fo-Nl; Fri, 27 Apr 2007 15:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSC-0002ZE-NQ; Fri, 27 Apr 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhWSA-00049y-Ng; Fri, 27 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 99A9826EF5; Fri, 27 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhWSA-0002Qo-EV; Fri, 27 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 27 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-file-transfer-mech-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Author(s) : M. Garcia-Martin, et al. Filename : draft-ietf-mmusic-file-transfer-mech-01.txt Pages : 38 Date : 2007-4-27 This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-file-transfer-mech-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-file-transfer-mech-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-27113517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-file-transfer-mech-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-file-transfer-mech-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-27113517.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Fri Apr 27 16:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXKp-0000Ev-UB; Fri, 27 Apr 2007 16:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXKp-0000D0-5s for mmusic@ietf.org; Fri, 27 Apr 2007 16:46:31 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXKn-00057f-US for mmusic@ietf.org; Fri, 27 Apr 2007 16:46:31 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1080535wri for ; Fri, 27 Apr 2007 13:46:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IFzDWf9KtOL1+mjH9RvDbSlpJqa7xv1w+RqoMZHAglWpVw1h6TIqyH81aZ/t5rK7xxF/PZ8zZ498kLmblDJK6EM0xd34Y/XLo4WPTBeDO0TEHY4H+qlWqvn8yPqxKoQ35ZvHkUmY67XrwX1b+WmFwaMKJUSVe8Bn/vUv+/VOE04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Om7WXxu6ldM5Fwh0itxId8BozPx8UvDu7eNOmsq+rz4jEbqZUsgTnTOGE9UkCg7qYCI7j92WSZs1Ma+nMYVhh8+bdhDzgKhS8i1oa5yYK01ivNBa7tLTVNg+HjlQpsElGJ6Po/2RRWVupRGhVcVTKx6SDBylamQ+cMCpMhA4znM= Received: by 10.78.157.19 with SMTP id f19mr1148745hue.1177706788987; Fri, 27 Apr 2007 13:46:28 -0700 (PDT) Received: by 10.78.39.17 with HTTP; Fri, 27 Apr 2007 13:46:28 -0700 (PDT) Message-ID: <4d0605c20704271346nf4c3875ycbdcbb284322c2c1@mail.gmail.com> Date: Fri, 27 Apr 2007 13:46:28 -0700 From: "Joseph Pallas" To: "Jean-Francois Mule" Subject: Re: [MMUSIC] RTSP: Speed header In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C607A42D@srvxchg3.cablelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d0605c20704241137g3a2af1bfq389b317d551b17da@mail.gmail.com> <9AAEDF491EF7CA48AB587781B8F5D7C607A42D@srvxchg3.cablelabs.com> X-Google-Sender-Auth: 1a62bf398521fb4c X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 4/26/07, Jean-Francois Mule wrote: > Some of this was discussed back then when the 2.0 draft was started. It > would be nice to get some specific details based on the current 2.0 > drafts, especially the "things [in the current 2.0 draft] that no one > uses", and what results in "poor [1.0] interoperability". I think the 2.0 draft is much better than 1.0 in these respects; I won't bother to enumerate problems with 1.0. For 2.0, we've already identified the Speed header as one issue. I think the lingering references to connection-less transports are unnecessary, although probably harmless. There is no means to negotiate a content type for GET_PARAMETER and SET_PARAMETER, so their interoperability remain dubious. (And I've already complained that there is no specification for "text/parameters" despite its usage both in the field and in the examples.) I do not know whether any implementations are using the cache-related features. I'd be interested to hear what use is being made of them. I think it would be quite challenging to implement a caching proxy that supports independently-developed clients. Having stated my concern about unused features, I would add this. I think it is telling that the ANNOUNCE method from RTSP 1.0 may have never been used as specified (for unsolicited session descriptions) but was "repurposed" by some implementations to provide a way to signal various asynchronous stream events. I agree with the decision to remove RTSP 1.0's ANNOUNCE from RTSP 2.0, but I'm concerned that failing to include that notification functionality in RTSP 2.0 simply means that incompatible extensions will be created. (I would be especially sad to see ANNOUNCE-as-it-is-used re-introduced as an RTSP 2.0 extension.) joe _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Apr 27 19:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hha4X-00012t-QH; Fri, 27 Apr 2007 19:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hha4W-00012j-Mc for mmusic@ietf.org; Fri, 27 Apr 2007 19:41:52 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hha4V-0000XT-20 for mmusic@ietf.org; Fri, 27 Apr 2007 19:41:52 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2007 16:41:51 -0700 X-IronPort-AV: i="4.14,463,1170662400"; d="scan'208"; a="482111574:sNHT54483748" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3RNfoJO002138; Fri, 27 Apr 2007 16:41:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3RNfoMF000440; Fri, 27 Apr 2007 23:41:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 16:41:50 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 16:41:49 -0700 Message-ID: <46328A3C.7070803@cisco.com> Date: Fri, 27 Apr 2007 19:41:48 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] Re: Question on ICE: Why allow FQDNs for candidate addresses? References: <462E7F8B.7020405@cisco.com> <4630E265.5040501@cisco.com> <3AF71420-FC01-49BD-AECA-55A8806E95E3@magma.ca> <2013F974-49E2-4F4B-9FE6-196D5478284F@cisco.com> <46310068.30700@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 23:41:49.0449 (UTC) FILETIME=[9FFFDF90:01C78925] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4876; t=1177717310; x=1178581310; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Re=3A=20Question=20on=20ICE=3A=20Why=20all ow=20FQDNs=20for=20candidate=20addresses? |Sender:=20; bh=6jULHIZaYnUS5qppRoVEUxfOUDAL9xsTqYg37fsWyPM=; b=Tnpv8DDlkTxaqEZBIzEAqkDPYYXpQHIbgb9wt4odfD6AtOu6+Gikfz5cRTqwJ3BSyBnlrSjI dCy8bULb/RU6MYs6raHe2VlVrRdQSNoztzkk4foyUja80nQvaOUaaYtbzGOXZbBCVyt8x/8SUe 7un1bTJYgXAbGIQ9XzFRtql9I=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Cullen Jennings , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org OK, thanks. I'll consider this one closed unless someone objects. -Jonathan R. Philip Matthews wrote: > OK. > My concern was simply over the additional implementation complexity. > However, if no one else is concerned about this, then I am OK with it. > However, if there is someone who has an ICE implementation that does not > support an FQDN instead of an IP address in this position, it would be > useful for them to speak up. > Otherwise, I am willing to let this go. > - Philip > > On 26-Apr-07, at 15:41 , Jonathan Rosenberg wrote: > >> Right - this is my point. >> >> So I still don't want to mention anything in security considerations >> since thats just a potential use for it. The main point I am saying >> is that this is just consistent with SDP. I don't want to open a >> massive can of worms with fancy DNS usages in a security >> considerations section. That would be a guaranteed DISCUSS and it >> would be for no reason. >> >> -Jonathan R. >> >> Cullen Jennings wrote: >> >>> I'm a bit behind on my ICE reading but I sort of assumed that ICE >>> would not be saying anything about IP packet level TTLs. Anyways - >>> the approach of using a DNS name that resolves differently inside >>> the enterprise vs outside as a privacy mechanism always seemed >>> fraught with danger and I've never been a big fan of it but I don't >>> really care one way or the other about FQDN in the SDP. Does seem >>> like it would give us a nice place holder for future extensibility. >>> Cullen >>> On Apr 26, 2007, at 11:15 AM, Philip Matthews wrote: >>> >>>> >>>> On 26-Apr-07, at 13:33 , Jonathan Rosenberg wrote: >>>> >>>>> >>>>> >>>>> I'm not sure its useful for this 'feature' (preventing private >>>>> addresses from departing the enterprise). Not even sure anyone >>>>> needs it. Its never been clear what attack it actually mitigates. >>>>> Hostname in the candidate line was more a placeholder for future >>>>> work. Also, as I said, it was consistent with SDP overall which >>>>> allows hostnames, even in the c line. >>>>> >>>>> As such, I'd rather just leave it as is, rather than guess at how >>>>> it might get used for an enterprise use case. All the justification >>>>> we really need is that this is how SDP already works. >>>>> >>>> >>>> Cullen posted a message to the BEHAVE list today which seems relevant >>>> to this discussion. I have copied it below. It seems to argue in >>>> favor of what you are suggesting. I remain uncertain about this, but >>>> I have not yet read the draft he references. However, I would still >>>> argue that IF we do think we should do this, it should warrant a >>>> mention in the Security Considerations section. >>>> >>>> Perhaps Cullen would like to comment on this? >>>> >>>> - Philip >>>> >>>> ==== Message from BEHAVE list below ==== >>>> >>>>> On Apr 24, 2007, at 6:06 AM, Philip Matthews wrote: >>>>> >>>>> >>>>>> Does anyone see a good reason why a NAT _should not_ decrement the >>>>>> TTL field >>>>>> (other than the "try to be invisible" argument)? >>>>>> Are there security implications to this question? >>>>>> >>>>> >>>>> I think so - an important security property is the properties >>>>> described in the "Privacy and Topology Hiding" section of draft- >>>>> ietf-v6ops-nap-06 (note this draft has been approved and will be an >>>>> RFC soon). Requiring decrement of TTL would reveal internal >>>>> topology information which is a big deal in cases where you are >>>>> trying to hide if you are currently in europe of US for privacy >>>>> reasons. Obviously lots of NATs are deployed where people don't >>>>> care about topology hiding but this is a big concern in some >>>>> deployments. >>>>> >>>>> I can't imagine how requiring that NATs do, or don't, decrement the >>>>> TTL will help the P2PSIP stuff much but perhaps I am just not >>>>> seeing the importance. >>>>> >>>>> Cullen >> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 28 04:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhi0C-0001ar-2I; Sat, 28 Apr 2007 04:09:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhi0B-0001am-4d for mmusic@ietf.org; Sat, 28 Apr 2007 04:09:55 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhi09-0006BJ-JX for mmusic@ietf.org; Sat, 28 Apr 2007 04:09:55 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id A6FAF5191F; Sat, 28 Apr 2007 04:09:51 -0400 (EDT) Message-ID: <46330146.6030502@pjsip.org> Date: Sat, 28 Apr 2007 09:09:42 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> <46310407.5080505@cisco.com> In-Reply-To: <46310407.5080505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Philip Matthews , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Thanks for the reply, Jonathan. I still can't see why it shouldn't work, please see below. Jonathan Rosenberg wrote: > This most definitely does not work. Forget about APIs, thats the > software abstraction layer. Lets talk about networking. See below. > > Benny Prijono wrote: > >> >> No, I think that's not true (or did I completely miss something?). >> >> But first of all, let me clarify. The candidates don't get removed; so >> if there are N interfaces, there will still be N host candidates being >> advertised in SDP. Only the checks that originates from the remaining >> host candidates are being removed, during pruning process. >> >> So even though there is only one (UDP) socket and with some more >> checks pruned, connectivity checks will be sent from *all* interfaces. >> Let me illustrate with an example. >> >> (please see this table with fixed width font) >> >> Agent A | Agent B >> candidate=1.1.1.1 1 typ host | candidate 1: 3.3.3.3 3 typ host >> candidate=2.2.2.2 2 typ host | candidate 2: 4.4.4.4 4 typ host >> >> With usual ICE, these checks will be created on agent A: >> >> #1) 1.1.1.1:1 --> 3.3.3.3:3 >> #2) 1.1.1.1:1 --> 4.4.4.4:4 >> #3) 2.2.2.2:2 --> 3.3.3.3:3 >> #4) 2.2.2.2:2 --> 4.4.4.4:4 >> >> Now, if agent A uses a single socket for all host candidates, AFAIK >> check #3 will produce the same result as check #1, and check #4 will >> produce the same result as check #2. >> >> So we can prune the checks further, leaving the check list in agent A to: >> >> #1) 1.1.1.1:1 --> 3.3.3.3:3 >> #2) 1.1.1.1:1 --> 4.4.4.4:4 >> >> or >> >> #1) 2.2.2.2:2 --> 3.3.3.3:3 >> #2) 2.2.2.2:2 --> 4.4.4.4:4 >> >> (it doesn't really matter which local host candidate to use, they will >> produce the same result using this approach) > > Not if the networks are not mutually connected. > > If nets 2 and 3 are connected, and nets 1 and 4 are connected, but there > is no connection between 2 and 1, or 2 and 4, and no connection between > 3 and 1 or 3 and 4, then your approach fails. I can't see why it should fail. If I understood your case correctly, then my approach should find two valid pairs too (2 and 3, and 1 and 4). I pointed out in another mail that when I said to do this connectivity check: 1.1.1.1:3 --> 3.3.3.3:3 It doesn't mean that the agent will send the check from interface 1.1.1.1, but rather to send the check from any interface (0.0.0.0) according to the host's routing table. The 1.1.1.1 represents the host candidate instance that is selected in the agent's software to represent this check, and it has nothing to do with the source address of the actual packet. >> AFAIK this will produce *mostly* the same result as normal ICE for >> both successful and failed scenario. >> >> The only situation that I can think of where the result may differ is >> when a remote candidate may be reachable from more than one local >> interfaces (maybe two interfaces are configured in load balance mode?). > > Its the opposite. It won't work when a particular destination is > ROUTABLE from both interfaces (meaning your local routing tables assume > there is a route from each) but it turns out that there is only > CONNECTIVITY from one. Almost all private networks make use of default > routes. Okay, that's a valid case not involving API here that my approach may not find the connectivity. Just for clarification and future reference, I think this is what you meant, routing table wise: net 1 via 1.1.1.1 net 3 via net 1 metric=X net 2 via 2.2.2.2 net 3 via net 2 metric=Y default route via 1.1.1.1 So net 3 is ROUTABLE via both interfaces, but it happens that the route via net 1 is down somewhere down the line and the host routing table is not updated. In this case, yeah, ICE will find connectivity, and my approach won't. > This choice about using all interfaces was carefully considered for this > reason. If you wish to implement this using just one, be my guest, but > you are taking risks and I think its a bad idea to put this into the spec. Okay since my approach won't work in all topologies, I'll rest my case. Thanks for pointing this out. -benny > -Jonathan R. > > -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 28 04:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhi4g-0003lY-48; Sat, 28 Apr 2007 04:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhi4e-0003lJ-JO for mmusic@ietf.org; Sat, 28 Apr 2007 04:14:32 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhi4d-00071j-B5 for mmusic@ietf.org; Sat, 28 Apr 2007 04:14:32 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 779E55191F; Sat, 28 Apr 2007 04:14:30 -0400 (EDT) Message-ID: <4633025E.6040108@pjsip.org> Date: Sat, 28 Apr 2007 09:14:22 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [MMUSIC] ICE reducing number of checks (was Re: ICE pacing connectivity checks) References: <025401c7803f$9bc6f1f0$c4f0200a@amer.cisco.com> <4624E251.4090903@ericsson.com> <46265C9D.4050609@sipstation.com> <46274E4E.7020201@ericsson.com> <46276414.7050703@pjsip.org> <46277319.4050101@ericsson.com> <46278FA2.2010709@pjsip.org> <9E94C6F0-F0DF-41DC-A592-B50127BE3BED@magma.ca> <462F6B5A.3030000@pjsip.org> <462F6D94.9050605@cisco.com> <71EAECB6-0F37-4E41-90BC-7A916AF6D6D4@magma.ca> <462F8876.80201@pjsip.org> <38B26728-F132-4EE0-9F64-642FB5A1B507@magma.ca> <46300B72.1010906@pjsip.org> <5E86095C-3C83-4FA4-98AC-F3A8D9570049@magma.ca> <3122.59.189.186.50.1177601734.squirrel@webmail.tuffmail.net> <917A8F48-070F-4478-8F33-07E177B4A069@magma.ca> In-Reply-To: <917A8F48-070F-4478-8F33-07E177B4A069@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Philip Matthews wrote: > > On 26-Apr-07, at 11:35 , benny@tmbox.com wrote: >> >> You're assuming that just because you bind() your socket to a specific >> interface, you can force the OS to spit packets out of that interface, >> bypassing the routing table. It won't work. The OS will return >> ENETUNREACH/EHOSTUNREACH error if you try to do this. >> >> So you can't send packet to 3.3.3.3 or 4.4.4.4 using interface >> 2.2.2.2, if >> the default route points to interface 1.1.1.1. Your connectivity checks >> will fail. >> >> And so are mine (because 1.1.1.1 is down). >> >> So both approaches produce the same result, again. > > Now the discussion is moving from the realm of specification to the > realm of implementation. That is, given that we WANT to force the > packets to be sent out a specific interface, how do we achieve this > under Y, where Y is some specific OS? Actually there is another case not involving API where my approach fails, so yeah, my approach doesn't work in *all* cases. I'll rest my case. > > PS. And BTW, I have downloaded your STUN/TURN/ICE > implementation to take a look at. I haven't had much chance to poke around > yet, but I like what I have seen so far. I am glad to see an open-source > implementation of ICE. Thanks. :) -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Apr 28 04:16:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhi6a-0004dR-Jc; Sat, 28 Apr 2007 04:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhi6Z-0004cm-0Q for mmusic@ietf.org; Sat, 28 Apr 2007 04:16:31 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhi6X-0007Nf-Pa for mmusic@ietf.org; Sat, 28 Apr 2007 04:16:30 -0400 Received: from [192.168.0.7] (unknown [81.178.58.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CB35951937; Sat, 28 Apr 2007 04:16:28 -0400 (EDT) Message-ID: <463302D5.3090808@pjsip.org> Date: Sat, 28 Apr 2007 09:16:21 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] Re: Question on Verifying ICE Support References: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> <462E7E81.2090203@cisco.com> <462F1644.3050401@pjsip.org> <4630E372.8000704@cisco.com> In-Reply-To: <4630E372.8000704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Philip Matthews , IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg wrote: > Interestingly, with the current wording, if an SBC modifies the m/c-line > but NOT the a=rtcp line, ICE will in fact proceed. So, the question is, > is that what we want? I suspect not. So I am leaning towards changing > this back to say that there must be a candidate line for each default. I think that makes sense, and I agree. -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Apr 29 22:44:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiLsX-0006mC-Nl; Sun, 29 Apr 2007 22:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiLsW-0006m4-Bo for mmusic@ietf.org; Sun, 29 Apr 2007 22:44:40 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiLsS-0001jK-4v for mmusic@ietf.org; Sun, 29 Apr 2007 22:44:40 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HiLsR-0000hg-2D; Sun, 29 Apr 2007 22:44:35 -0400 In-Reply-To: <463302D5.3090808@pjsip.org> References: <2A858D2A-BC44-4F4D-9284-EC4ECFFCF8DE@magma.ca> <462E7E81.2090203@cisco.com> <462F1644.3050401@pjsip.org> <4630E372.8000704@cisco.com> <463302D5.3090808@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83DFDD14-ACCB-4D49-9BD6-7BF4C6D3D865@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [MMUSIC] Re: Question on Verifying ICE Support Date: Sun, 29 Apr 2007 22:44:33 -0400 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 28-Apr-07, at 04:16 , Benny Prijono wrote: > Jonathan Rosenberg wrote: >> Interestingly, with the current wording, if an SBC modifies the m/ >> c-line but NOT the a=rtcp line, ICE will in fact proceed. So, the >> question is, is that what we want? I suspect not. So I am leaning >> towards changing this back to say that there must be a candidate >> line for each default. > > I think that makes sense, and I agree. This also makes sense to me. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 30 07:13:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTov-0006QS-Ec; Mon, 30 Apr 2007 07:13:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTou-0006Gs-FP for mmusic@ietf.org; Mon, 30 Apr 2007 07:13:28 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiTop-0006Uf-Ia for mmusic@ietf.org; Mon, 30 Apr 2007 07:13:28 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3UBDHwW025279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Apr 2007 04:13:17 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3UBDFwK027986; Mon, 30 Apr 2007 04:13:15 -0700 Received: from NAEX01.qualcomm.com ([129.46.51.60]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 04:13:15 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was RE: [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Date: Mon, 30 Apr 2007 04:13:14 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD2AEF@NAEX01.na.qualcomm.com> In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB268CC3@oslexcp1.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to modify RFC3890 TIAS in offer/answer Was RE: [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Thread-Index: Acdn6mV7RvdCSEKsS5ew8hdKBSP3egAeU+fgBd+tG7ABy+/cUAEBgCNw References: <2CA3E1B6CEC064449CAA7D0FAB46079B02BD20FA@NAEX01.na.qualcomm.com> <9F6ACAE02B6DD040A1E259977622CFDB268CC3@oslexcp1.eu.tandberg.int> From: "Desineni, Harikishan" To: "Geir Arne Sandbakken" , X-OriginalArrivalTime: 30 Apr 2007 11:13:15.0564 (UTC) FILETIME=[8C7A26C0:01C78B18] X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: Magnus Westerlund , roni.even@polycom.co.il, Colin Perkins X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Geir, Thanks for your feedback.=20 Can you elaborate on how exactly this attribute is used in the implementations known to you? I'd like to understand how closely or differently it is used from the way it is documented in rfc3890. Thanks, Hari > -----Original Message----- > From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.com] > Sent: Wednesday, April 25, 2007 1:31 AM > To: Desineni, Harikishan; mmusic@ietf.org > Cc: Magnus Westerlund; roni.even@polycom.co.il; Colin Perkins > Subject: RE: Proposal to modify RFC3890 TIAS in offer/answer Was RE: > [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt >=20 > Harikishan, >=20 > We have been using TIAS in the 'recv' direction for quite a while, and I > know of multiple other implementations. Think we have been promoting > the usage in the last 3 SIPit's, and changing the direction will lead to > serious interoperability issues. >=20 > I do agree that a 'send' direction attribute is desirable as additional > bandwidth information, and I hope it can be done without breaking > existing implementations. >=20 > Cheers, > Geir Arne >=20 > > -----Original Message----- > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > Sent: 17 April 2007 20:40 > > To: mmusic@ietf.org > > Cc: Magnus Westerlund; roni.even@polycom.co.il; Colin Perkins > > Subject: Proposal to modify RFC3890 TIAS in offer/answer Was RE: > > [MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt > > > > Some issues with the offer/answer usage of TIAS (defined in RFC3890) > > came out while discussing > draft-hdesinen-mmusic-oa-send-bw-attr-02.txt. > > > > RFC3890 has incorrectly defined TIAS and maxprate as 'recv' direction > > attributes in offer/answer model. As 'recv' attributes, TIAS and > > maxprate do not solve the bandwidth negotiation problem. For > > offer/answer bw negotiation to work properly, the correct direction in > > rfc3890 should have been 'send', probably with the help of few new > > 'recv' direction attributes (like PO - per packet overhead at layer X, > > RB- receive BW at layer X) under discussion. > > > > A sender would choose (TIAS,maxprate) which satisfy the following > > formula > > TIAS + (maxprate * PO) <=3D RB (PO and RB are signaled by the receiver) > > > > One approach to handle this is changing the direction of > (TIAS,maxprate) > > to 'send' and prevent the incorrect ('recv') usage of (TIAS,maxprate) > in > > offer/answer model. While this appears to be the desired direction, I > am > > interested to know the impact of such a change on (any) existing > > implementations of TIAS in offer/answer. > > > > Please comment if you are aware of any existing implementations of > TIAS > > in offer/answer and also describe how exactly TIAS was used in that > > particular implementation. > > > > Thanks, > > Hari > > > > > > > -----Original Message----- > > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > > Sent: Saturday, March 17, 2007 12:26 AM > > > To: Magnus Westerlund; roni.even@polycom.co.il > > > Cc: Mahendran, AC; Dondeti, Lakshminath; mmusic@ietf.org; > avt@ietf.org > > > Subject: RE: [MMUSIC] Comments on > > draft-hdesinen-mmusic-oa-send-bw-attr- > > > 02.txt > > > > > > I copied a post (from AVT list) from Roni which states that TIAS was > > > actually used in his implementation. I am not sure if it is an > > > implementation in offer/answer model. > > > > > > [CCed AVT as TIAS was also recently discussed on AVT list] > > > > > > " > > > -----Original Message----- > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: Monday, January 08, 2007 7:35 AM > > > To: Randell Jesup > > > Cc: Stephan Wenger; avt@ietf.org > > > Subject: RE: [AVT] CCM draft review -- should "bandwidth" include > > > theheaderoverhead > > > > > > Randell, > > > RFC 4890 recommends sending both TIAS and AS for backward > > compatibility > > > with systems that do not support TIAS. This RFC gives a good > > explanation > > > why to use TIAS. This is what we do in our implementation. > > > " > > > > > > > -----Original Message----- > > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > > Sent: Friday, March 16, 2007 9:44 AM > > > > To: Desineni, Harikishan > > > > Cc: mmusic@ietf.org > > > > Subject: Re: [MMUSIC] Comments on > > > draft-hdesinen-mmusic-oa-send-bw-attr- > > > > 02.txt > > > > > > > > Desineni, Harikishan skrev: > > > > > > > > > > > > > > > Magnus, > > > > > > > > > > Thanks for the comments. > > > > > > > > > > In the initial version, I captured the current understanding of > > > (TIAS > > > > > ,maxprate) based on RFC3890. > > > > > > > > > > Based on the current RFCs, majority of the community interprets > > TIAS > > > as > > > > > receive only direction attribute. Instead of updating RFC3890 to > > > modify > > > > > TIAS as a send direction only attribute, it is better to use a > new > > > > > attribute 'MSR' proposed in this draft. This would also avoid > any > > > > > backward compatibility/inter-op issues that can arise with > current > > > > > implementations which (correctly) interpret TIAS as receive > > > direction > > > > > only attribute in offer/answer. > > > > > > > > Well, I wonder how there can be backwards compatibility issues > with > > > > something that clearly doesn't work if you actually try to use it. > > > There > > > > might be implementations but I can't really understand how they > > could > > > > work. Do you know of implementations? > > > > > > > > > > > > > > Another approach is to add directionality to TIAS. By default, > > TIAS > > > is > > > > > receive only (not much useful) and "TIAS/sendonly" will be send > > only > > > > > direction. "maxprate/send" will be packet rate in send > direction. > > > > > > > > > > What you are proposing is the following > > > > > Send direction attributes: RTP Payload rate and maxpacket rate > > > > > Receive direction attributes: AS (or a new one), packet overhead > > > > > > > > Okay, here I think the more important question is, are we > expecting > > to > > > > be able to specify a value on another level than IP? If not I > think > > AS > > > > works fine. > > > > > > > > > > > > > > In this draft I am proposing that 'MSR' be used for signaling > RTP > > > > > payload rate in 'send' direction. IMO, it is not a clean > approach > > to > > > > > redefine TIAS to be a 'send' direction attribute. > > > > > > > > We disagree on this. TIAS was specified as a send direction > > attribute. > > > I > > > > made an error in the offer/answer usage because I didn't consider > > the > > > > implications. And no one picked up on it. > > > > > > > > As I can see it in regards to RFC 3890 we have two alternatives: > > > > > > > > 1. Fix the offer/answer section to correctly define it to apply in > > the > > > > sending direction. > > > > > > > > 2. Obsolete usage of TIAS in Offer/Answer exchanges and only use > it > > > for > > > > declarative usage, like in RTSP. > > > > > > > > If there are implementations i any numbers that interpret TIAS as > a > > > > receiver direction attribute then I agree alternative 2 will be > > best. > > > > However I would like to have some positive acknowledgments of this > > > > first. This was after all revealed in the attempt to apply TIAS to > > > > offer/answer in the 3GPP MTSI standardization work. Resulting in > > that > > > > TIAS was only included in the draft spec for a while. I don't know > > if > > > > some other umbrella standard has included TIAS combined with > > > offer/answer. > > > > > > > > > > > > > > I am OK with signaling packet rate in send direction. But we > need > > to > > > > > consider whether to reuse maxprate for this or add > directionality > > to > > > > > maxprate (maxprate/send) to avoid any inter-op issues with > current > > > > > implementations. > > > > > > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > IETF Transport Area Director & TSVWG Chair > > > > > > ---------------------------------------------------------------------- > > > > Multimedia Technologies, Ericsson Research EAB/TVM/M > > > > > > ---------------------------------------------------------------------- > > > > Ericsson AB | Phone +46 8 4048287 > > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > > > > > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 30 15:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibxz-0004xF-61; Mon, 30 Apr 2007 15:55:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibxx-0004w2-DN for mmusic@ietf.org; Mon, 30 Apr 2007 15:55:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hibxv-0005ZO-6v for mmusic@ietf.org; Mon, 30 Apr 2007 15:55:21 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 30 Apr 2007 12:55:18 -0700 X-IronPort-AV: i="4.14,471,1170662400"; d="scan'208"; a="57108056:sNHT54044523" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3UJtImA018596; Mon, 30 Apr 2007 12:55:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3UJtIZT018519; Mon, 30 Apr 2007 19:55:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 12:55:18 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 12:55:17 -0700 Message-ID: <463649A0.5010807@cisco.com> Date: Mon, 30 Apr 2007 15:55:12 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <080c01c7881e$6755a150$05716b80@amer.cisco.com> <463106EA.3030505@cisco.com> <4631FB4A.1080000@ericsson.com> In-Reply-To: <4631FB4A.1080000@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 19:55:18.0232 (UTC) FILETIME=[7A3DFD80:01C78B61] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3787; t=1177962918; x=1178826918; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20ICE=20pacing=20connectivity=20checks=09(wasRE=3A[MMUS IC]=09WGLC=3A=09draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=35aogfiS9xVwcOafLlVI04lGprYrlzECMZjHGJumzK0=; b=iNvYtqUZaUXBx8uC3/Jh9GYaz0ZZiHZo1fFFORAckRiIHxdDrQmyv2HwwWZ5YSbJzsPQmHNP WytPybfdYc1qm22aWFVpreELPcWBPPtKSBd272tzjNPn41IjVhDBUGyw9diX8lEwU6QaCP6KnB 5tsUjBha2jMb7o50iF8OcT2sM=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org inline. Magnus Westerlund wrote: > Jonathan Rosenberg skrev: > >> My proposal for ICE is to document Dan's proposal as the RECOMMENDED >> algorithm for computing Ta in a way that makes it as good as RTP. As >> Magnus has indicated, there are many conflicting requirements here. >> ICE completing switfly is important. I think it is unreasonable to ask >> ICE to be more responsive, more cautious, than even RTP itself is. > > > I think Dan's proposal points at at least on important factor. That ICE > scales to the planned used bit-rate that way not making it worse than a > planned RTP stream. However, the basic fact is that RTP is no wonder of > congestion control and network friendly behavior. And the issue is that > a wrongly configured media bit-rate may create congestion issues. But > having some binding to session negotiated bit-rate is better than none. I think its important to mention that ICE doesn't run for the duration of the session. We are talking about what happens within the first few seconds of what may be a very long overall session. Consequently, I think energy is far better spent in dealing with RTP congestion issues than ICE. > > I would also like to consider if there should be some upper limit on > this, independent of the bit-rate of the media stream. Are there some > bit-rate where ICE works well enough and making it use more and converge > quicker isn't wort it. That way at least serious configuration errors > will not result in extended periods of problems. OK, that is fair. I will work out a min Ta. > > >> >> An additional question/consideration is what about multiple media >> streams. With the frozen algorithm, we only start checks for one >> stream at a time. So if that stream is audio, this means that the >> checks get paced at the audio pace, and once video is unfrozen, we'll >> speed quickly through the video checks. That doesnt make a lot of >> sense either. >> >> I'm thinking that the Ta and RTO computation would use an aggregate Ta >> that is 1/(SUM_i_from_1_to_N(1/Ta_i)) when there are N streams, each >> of which has a Ta_i computed using Dan's formula. With the existing >> frozen algorithm, this means that the total media bandwidth is >> utilized for the checks when we start, and as more streams get >> unfrozen, that bandwidth is split equally amongst them. I think this >> works better. > > > Yes, sounds reasonable. > >> >> In response to Magnus' question around triggered checks, they are >> excluded from the formula and I think that makes sense. If there is >> congestion then the initial checks themselves get lost and so the >> triggering doesn't happen. Furthermore with agressive mode, you'll >> only see a small number of triggered checks get sent, regardless of >> the number of candidates. >> >> > > My question is what do you win with that rather than moving the > triggered checks to the top of the paced list. That way you keep the > rate and avoid hurting yourself more than what you would by instantly > initiate the triggered checks. Its not just new transactions; in most cases a triggered check is a retransmit of a transaction already in progress. Pacing those along with periodic checks requires me to mix both of those things into a single mechanism, which I don't like. I prefer a cleaner separation of ICE and STUN. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 30 19:16:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hif6W-0008IC-Ne; Mon, 30 Apr 2007 19:16:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hif6W-0008I6-2k for mmusic@ietf.org; Mon, 30 Apr 2007 19:16:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hif6V-0000FQ-QL for mmusic@ietf.org; Mon, 30 Apr 2007 19:16:24 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 30 Apr 2007 16:16:23 -0700 X-IronPort-AV: i="4.14,472,1170662400"; d="scan'208"; a="57160508:sNHT66966399" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3UNGNmv030800; Mon, 30 Apr 2007 16:16:23 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3UNGMA8028172; Mon, 30 Apr 2007 23:16:22 GMT From: "Dan Wing" To: "'Jonathan Rosenberg'" , "'Magnus Westerlund'" Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) Date: Mon, 30 Apr 2007 16:16:22 -0700 Message-ID: <029d01c78b7d$91976720$c4f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceLYXoa4ulkERSJQKqpC9wUhR5RyQAGcbNA In-Reply-To: <463649A0.5010807@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1835; t=1177974983; x=1178838983; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20ICE=20pacing=20connectivity=20checks=09(wasRE=3A[MMUS IC]=09WGLC=3A=09draft-ietf-mmusic-ice-15.txt) |Sender:=20; bh=G7EWfL+GYlH03aWtZWitCR/nHjU+UIumsd69Sn3XhqU=; b=IA7LdPdXCtEGo48zFJdqYzbmD29wx8bWJ/Ij0avPPX/pmTUYglh4k16NByUG0oSNk6fGr7rU 0SdXJSblME/C4+cDgUFL9wG1y5oAt+D7aRAt/8qqAudg2HmqqFLBb82n; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org > > I would also like to consider if there should be some upper limit > > on this, independent of the bit-rate of the media stream. Are > > there some bit-rate where ICE works well enough and making it use > > more and converge quicker isn't wort it. That way at least > > serious configuration errors will not result in extended periods > > of problems. > > OK, that is fair. I will work out a min Ta. The original reason for Ta was to prevent killing some NATs which couldn't deal with a bunch of new UDP translations close together. This text justifying Ta's value is still in ICE, as you know. But Magnus is looking at the overall bit rate, so I think we need a minimum value for both Ta (initial delay) and for RTO (STUN retransmit interval). I played with the spreadsheet a bit and Ta=20ms and RTO=100ms cause ICE to converge quickly and might well be good minimum values (those are the values in ice-15). With 10 candidate pairs and those values you get: time ICE activity ---- ------------ 0 STUN Binding Request (C1) 20 STUN Binding Request (C2) 40 STUN Binding Request (C3) 60 STUN Binding Request (C4) 80 STUN Binding Request (C5) 100 STUN Binding Request (C6), retransmit of C1 120 STUN Binding Request (C7), retransmit of C2 140 STUN Binding Request (C8), retransmit of C3 160 STUN Binding Request (C9), retransmit of C4 180 STUN Binding Request (C10), retransmit of C5 200 retransmit of C6 220 retransmit of C7 240 retransmit of C8 260 retransmit of C9 280 retransmit of C10 STUN's retransmit timer doubles after that (300ms, 500ms), so you'll get continual grouping of those retransmits until the client gives up or until an ICE candidate gets a response. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Apr 30 20:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HighZ-000372-SW; Mon, 30 Apr 2007 20:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HighY-00036u-7r for mmusic@ietf.org; Mon, 30 Apr 2007 20:58:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HighX-0006rv-EC for mmusic@ietf.org; Mon, 30 Apr 2007 20:58:44 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BD2DF20432; Tue, 1 May 2007 02:58:42 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-8f-463690c21529 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A2E0E203A1; Tue, 1 May 2007 02:58:42 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 02:58:42 +0200 Received: from [153.88.12.35] ([153.88.12.35]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 02:58:37 +0200 Message-ID: <463690BF.3020500@ericsson.com> Date: Tue, 01 May 2007 02:58:39 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt) References: <080c01c7881e$6755a150$05716b80@amer.cisco.com> <463106EA.3030505@cisco.com> <4631FB4A.1080000@ericsson.com> <463649A0.5010807@cisco.com> In-Reply-To: <463649A0.5010807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2007 00:58:42.0281 (UTC) FILETIME=[DCB36D90:01C78B8B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mmusic@ietf.org, Dan Wing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Jonathan Rosenberg skrev: > inline. > > Magnus Westerlund wrote: > >> Jonathan Rosenberg skrev: >> >>> My proposal for ICE is to document Dan's proposal as the RECOMMENDED >>> algorithm for computing Ta in a way that makes it as good as RTP. As >>> Magnus has indicated, there are many conflicting requirements here. >>> ICE completing switfly is important. I think it is unreasonable to >>> ask ICE to be more responsive, more cautious, than even RTP itself is. >> >> >> I think Dan's proposal points at at least on important factor. That >> ICE scales to the planned used bit-rate that way not making it worse >> than a planned RTP stream. However, the basic fact is that RTP is no >> wonder of congestion control and network friendly behavior. And the >> issue is that a wrongly configured media bit-rate may create >> congestion issues. But having some binding to session negotiated >> bit-rate is better than none. > > I think its important to mention that ICE doesn't run for the duration > of the session. We are talking about what happens within the first few > seconds of what may be a very long overall session. Consequently, I > think energy is far better spent in dealing with RTP congestion issues > than ICE. > There are two issues here as I see it. First, that ICE will congest itself if you run it over low-bandwidth paths. Secondly, that it doesn't do serious harm to other traffic. It is a very hard problem to congestion control ICE. That as why I at least like to have some real numbers on what it does, and put in the right nobs for a max rate and lower rate when you know you have slow interfaces. But I agree that having adaptive RTP traffic is actually more important. However, ICE is protocol here and now that we can affect and ensure that we done the most reasonable solution for congestion control. That means that we actually need some fair understanding for how the dynamics of ICE is. Which do requires that one do some simulations and studies. >> >> My question is what do you win with that rather than moving the >> triggered checks to the top of the paced list. That way you keep the >> rate and avoid hurting yourself more than what you would by instantly >> initiate the triggered checks. > > Its not just new transactions; in most cases a triggered check is a > retransmit of a transaction already in progress. I had forgotten this. And the reason for doing that is that it is quite likely that the previous transmission was dropped in the NAT where now a binding exist? > Pacing those along with > periodic checks requires me to mix both of those things into a single > mechanism, which I don't like. I prefer a cleaner separation of ICE and > STUN. I can, understand that. You still have an interface question for the triggered checks, where ICE needs to tell an ongoing STUN transaction that the check should be retransmitted. Not complicating that case is fine. However for all the other cases from the list in section 7.2.1.4 using pacing to start the triggered checks seems easy to implement. It also appears there is a good reason for pacing as it prevents multiple triggered checks to significantly increase the bit-rate consumed. But I would appreciate more data how this actually play out in a case where there is multiple medias in a session. Because to me it appears that when a peer finds the combination of interfaces that works, it will start unfreezing a lot of candidates that will get through and triggered checks. I would really appreciate some simulation data for cases that are a bit more extreme when it comes to the number of candidates and medias. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic