From mmusic-bounces@ietf.org Mon Jul 02 02:32: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 1I5FSE-0004nk-1u; Mon, 02 Jul 2007 02:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FSC-0004nJ-IB for mmusic@ietf.org; Mon, 02 Jul 2007 02:32:08 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5FS7-0006ec-9d for mmusic@ietf.org; Mon, 02 Jul 2007 02:32:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes Date: Mon, 2 Jul 2007 09:33:12 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04AFCE9B@IsrExch01.israel.polycom.com> In-Reply-To: <467FF7A8.6040303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes Thread-Index: Ace3TEnjxV6JsivVSkmpPStGi5hoMgEnORBg From: "Even, Roni" To: "Flemming Andreasen" , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Flemming, I reviewed the draft and from the option I think I prefer B but am not = sure what it will mean. My preference is described here. My view is that the replace problem can be solved by implied behavior. = The delete cases are more problematic. The replace - if you have in the potential configuration the same = payload type in the fmpt or rtpmap as in the SDP than if using an actual = configuration from the potential configuration it implies that it = replaces the fmtp and rtpmap from the SDP.=20 This means that if in the SDP there is fmtp and rtpmap while in the = actual configuration there is only rtpmap for the same payload type than = both attributes from the SDP are replaced by only rtpmap. The general case is that same attribute in the SDP and in the actual = configuration are implicitly replaced. In the case of delete, your example shows the difficult part when the = attributes do not have the same name or a using the same payload type. = The duplication is based on similar semantics. It may be enough to leave = it as you suggest in section 4 of your contribution but I would not = object to real delete. =20 As for the point about if both should be addressed in the core document. = I suggest yes since we will need it and I think that the replace problem = is easier based on my description. Roni > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Monday, June 25, 2007 8:13 PM > To: mmusic > Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace > Attributes >=20 > Probably the biggest open issue we have in the SDP Capability > Negotiation Framework at this point is the ability to replace and = delete > attributes from an actual configuration SDP when generating a = potential > configuration. At the Prague IETF, people asked for some more > motiviation and use cases for this feature before deciding whether we > should include it in the core capability negotiation framework or not. = I > have written a short I-D in the subject, which you can find at: >=20 >=20 > = http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-= > del-00.txt >=20 > Please take a look at this and let me know how you think we should > resolve this issue. Options include: >=20 > A) Remove the ability to delete and replace attributes completely. > B) Remove the ability to delete and replace individual attributes, but > allow for complete removal of all attributes (clean slate) > C) Keep the current ability to delete and remove individual and all > attributes. >=20 > My personal preference is for option A, however in the interest of > moving forward and making a reasonable compromise between = functionality > and complexity, my recommendation is option B. >=20 > Thanks >=20 > -- Flemming >=20 >=20 >=20 >=20 >=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 Mon Jul 02 02:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FSN-0005PT-Kn; Mon, 02 Jul 2007 02:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FSL-0005JP-KR for mmusic@ietf.org; Mon, 02 Jul 2007 02:32:17 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5FSD-0006ec-69 for mmusic@ietf.org; Mon, 02 Jul 2007 02:32:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg Issue #3: Inconsistent media-level selection of session-level attribute capabilities Date: Mon, 2 Jul 2007 09:33:12 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04AFCE9C@IsrExch01.israel.polycom.com> In-Reply-To: <467FF7D9.1030702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #3: Inconsistent media-level selection of session-level attribute capabilities Thread-Index: Ace3TGQ6yNLa+odtQ0an7ZJ6FuwpHAEpkQDg From: "Even, Roni" To: "Flemming Andreasen" , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 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: , Content-Type: multipart/mixed; boundary="===============0951735106==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0951735106== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BC72.DD243599" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BC72.DD243599 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Flemming, I am OK with the suggestion. This does not prevent addressing the = problem for specific media cases in the media extensions to this work = and using grouping. The examples are suing multiple media streams that have relationship, = this is not only an issue for this work and is discussed in the contents = of adding grouping attributes. Roni =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Monday, June 25, 2007 8:14 PM To: mmusic Subject: [MMUSIC] SDPCapNeg Issue #3: Inconsistent media-level selection = of session-level attribute capabilities =20 The SDP Capability Negotiation framework allows attribute capabilities = to be defined at the session-level and at the media-level. When a = session-level attribute capability is used by a potential configuration, = the session-level attribute is effectively added to the SDP. The = capability negotiation framework however does not provide for any = coordination between potential configurations chosen by media stream A = and media stream B. Thus, it is possible that media stream A selects a = potential configuration that uses session-level attribute A, and media = stream B selects a potential configuration that uses session-level (or = media-level) attribute B, where attribute A and B conflict or interact = with each other.=20 The design team discussed two different solutions to this issue in = Prague: 1) Explain the issue in the document as outlined above and recommend = that people avoid using session-level capabilities for cases where such = inconsistencies may occur. 2) On the offering side, make sure that we generate sane offers where = this issue is not present in the actual configuration SDP to begin with. = On the answering side, the answerer will need to look at the resulting = potential configuration SDPs. If a potential configuration SDP doesn't = make sense (e.g. as a result of the above), the answerer must discard it = and move on to the next. Note that the above is only a problem if we have one or more = session-level attributes that can interact or conflict with another = session-level or media-level attribute. This is related to SDPCapNeg = Issue #1, where we recognized this as a general issue, but didn't find a = lot of examples with existing SDP attributes. The primary example we = found in terms of conflicts was with a session-level "keymgt" attribute = and a media level "crypto" attribute (or potentially multiple "keymgt" = attributes at the session-level), however this particular interaction is = well-known. A slightly different set of problems related to this issue is when we = need *coordination* between session-level attributes from multiple media = streams in order for a particular functionality to actually work. The = grouping framework (RFC 3388) is an example of this. If we use the SDP = capability negotiation framework to select a session-level group = attribute (provided as an attribute capability), and we require two = media streams to do this consistently, we could have a problem. The FEC = grouping semantics is at least in theory one example where this could = cause problems, however in practice, it is unclear that this poses a = significant problem with the currently defined grouping semantics.=20 In terms of a solution to this CapNeg issue, I believe it is difficult = to rely on the answerer to determine what does and does not make sense, = at least if we want to have consistent operation between different = implementations. Since there doesn't seem to be a huge problem here in = practice anyway, the recommended solution is option 1, i.e. explain the = issue in the document and avoid using session-level capabilities where = this may pose a problem. If you disagree with this, please let me know.=20 Thanks=20 -- Flemming=20 =20 ------_=_NextPart_001_01C7BC72.DD243599 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Flemming,

I am OK with the suggestion. This = does not prevent addressing the problem for specific media cases in the media = extensions to this work and using grouping.

The examples are suing multiple = media streams that have relationship, this is not only an issue for this work = and is discussed in the contents of adding grouping = attributes.

Roni

 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Monday, June 25, = 2007 8:14 PM
To: mmusic
Subject: [MMUSIC] = SDPCapNeg Issue #3: Inconsistent media-level selection of session-level attribute = capabilities

 

The SDP = Capability Negotiation framework allows attribute capabilities to be defined at the session-level and at the media-level. When a session-level attribute = capability is used by a potential configuration, the session-level attribute is effectively added to the SDP. The capability negotiation framework = however does not provide for any coordination between potential configurations chosen = by media stream A and media stream B. Thus, it is possible that media = stream A selects a potential configuration that uses session-level attribute A, = and media stream B selects a potential configuration that uses session-level = (or media-level) attribute B, where attribute A and B conflict or interact = with each other.

The design team discussed two different solutions to this issue in = Prague:
1) Explain the issue in the document as outlined above and recommend = that people avoid using session-level capabilities for cases where such inconsistencies may occur.
2) On the offering side, make sure that we generate sane offers where = this issue is not present in the actual configuration SDP to begin with. On = the answering side, the answerer will need to look at the resulting = potential configuration SDPs. If a potential configuration SDP doesn't make sense = (e.g. as a result of the above), the answerer must discard it and move on to = the next.


Note that the above is only a problem if we have one or more = session-level attributes that can interact or conflict with another session-level or media-level attribute. This is related to SDPCapNeg Issue #1, where we recognized this as a general issue, but didn't find a lot of examples = with existing SDP attributes. The primary example we found in terms of = conflicts was with a session-level "keymgt" attribute and a media level = "crypto" attribute (or potentially multiple "keymgt" attributes at the session-level), however this particular interaction is well-known.


A slightly different set of problems related to this issue is when we = need *coordination* between session-level attributes from multiple media = streams in order for a particular functionality to actually work. The grouping = framework (RFC 3388) is an example of this. If we use the SDP capability = negotiation framework to select a session-level group attribute (provided as an = attribute capability), and we require two media streams to do this consistently, = we could have a problem. The FEC grouping semantics is at least in theory one = example where this could cause problems, however in practice, it is unclear that = this poses a significant problem with the currently defined grouping = semantics.


In terms of a solution to this CapNeg issue, I believe it is difficult = to rely on the answerer to determine what does and does not make sense, at least = if we want to have consistent operation between different implementations. = Since there doesn't seem to be a huge problem here in practice anyway, the recommended solution is option 1, i.e. explain the issue in the document = and avoid using session-level capabilities where this may pose a problem. If = you disagree with this, please let me know.

Thanks

-- Flemming




 



















------_=_NextPart_001_01C7BC72.DD243599-- --===============0951735106== 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 --===============0951735106==-- From mmusic-bounces@ietf.org Mon Jul 02 09:02: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 1I5LY7-00050Z-MR; Mon, 02 Jul 2007 09:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LY6-00050O-G4 for mmusic@ietf.org; Mon, 02 Jul 2007 09:02:38 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5LXk-0003uM-O1 for mmusic@ietf.org; Mon, 02 Jul 2007 09:02: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 l62D2EN7002820; Mon, 2 Jul 2007 07:02:14 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 2 Jul 2007 07:02:14 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/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] Few comments on ICE-16 Date: Mon, 2 Jul 2007 07:02:25 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9985@srvxchg3.cablelabs.com> In-Reply-To: <090f01c7bada$9cfd20a0$a296150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Few comments on ICE-16 Thread-Index: Ace6k3Y2c0PgTroMR32lOSs5qdzGyAARhatwAHKqKAA= References: <9AAEDF491EF7CA48AB587781B8F5D7C62E9951@srvxchg3.cablelabs.com> <090f01c7bada$9cfd20a0$a296150a@amer.cisco.com> From: "Jean-Francois Mule" To: "Dan Wing" X-Approved: ondar 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 Dan Wing wrote: > > - re: the new formula for Ta: > > I understand that this came out of the ICE pacing discussion and > Dan's > > proposal on the TSVWG list and following discussions but > > nonetheless, it adds significant complexity. >=20 > I don't believe it does; it merely defines a formula to calculate > Ta and RTO, rather than using hard-coded values. The STUN state > machine stays the same, and ICE and ICE's operation do not interfere > with the STUN state machine or STUN timers due to this change. Ok, it is better than the hard-coded value given the intended benefits but, as the ID is written, my understanding is that for each media stream, the agent takes all the potential codecs to be offered, and for all the associated ptimes, calculate the size of the RTP packet/stun to compute Ta_i and for the sum. May this is not "significant" given the benefits, but it still looks more complex.=20 > > 1) nit - while you point folks to read section B.1 for more > > details, it > > is a bit opaque as presented. Adding one sentence around this > > formula's > > goals (same bandwidth as RTP) or risks if implementers choose to > > hardcode this as 20ms may help. > > 2) what happens when you have a media stream being offered > > with a codec > > and different ptimes supported (e.g. G.711, ptime=3D10, 20)? Should = an > > implementation should the default ptime for the codec or the > > ptime that will result in the greater sum value? >=20 > It's impossible for the offerer to send a connectivity check until > it receives the SDP answer (because until the answer arrives, it > doesn't know the IP address and UDP port to send its connectivity > checks to). When the answer arrives, the offerer will know which > ptime to use. =20 Yes. > The RTO and Ta formulas are calculated at the time > the answer is received (not when the offer is generated). Well, nothing says so for Ta. The text in section 5.8 for RTO may suggest that indeed but not for Ta. =20 May be it was my sequential reading of the ID that made me believe that at this point in the ICE text(4.1.x), the requirements are only about gathering candidates. In section 5.8 (about scheduling checks), some text even says: | Ta is the same value used to | pace the gathering of candidates, as described in Section 4.1.1. But no text actually forbids an agent to compute the Ta_i before SDP negotiation as candidates are gathered. May be the text for Ta should be moved or referenced elsewhere too (section 6 and/or 9?). Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 02 09:29: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 1I5Lxl-00053M-Qc; Mon, 02 Jul 2007 09:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Lxj-00053G-Uz for mmusic@ietf.org; Mon, 02 Jul 2007 09:29:07 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Lxf-0003w2-KS for mmusic@ietf.org; Mon, 02 Jul 2007 09:29:07 -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 l62DT0tX010479; Mon, 2 Jul 2007 07:29:00 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 2 Jul 2007 07:29:00 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/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: Mon, 2 Jul 2007 07:29:13 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62E9989@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 69 - call for agenda items for mmusic Thread-Index: Ace8rPrUVPfkLFQKTlKc1uUopO/2NA== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Colin Perkins , Joerg Ott Subject: [MMUSIC] IETF 69 - call for agenda items for mmusic 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 MMUSIC working group is scheduled to meet twice at IETF#69 in Chicago: - TUESDAY, July 24, 2007, 15:20-17:20 (Afternoon Session II) - WEDNESDAY, July 25, 2007, 13:00-15:00 (Afternoon Session I) This time around, the goal is to address topics other than ICE & cap. negotiation first, and schedule some time for ICE/cap. neg. in the second slot as necessary. Please contact the chairs if you would like to request agenda time during the IETF meeting. Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 02 13:21: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 1I5Pa2-0006yT-Vh; Mon, 02 Jul 2007 13:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Pa1-0006yI-9K for mmusic@ietf.org; Mon, 02 Jul 2007 13:20:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5PZv-0003bM-2g for mmusic@ietf.org; Mon, 02 Jul 2007 13:20:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Jul 2007 13:20:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABnRiEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,487,1175486400"; d="scan'208"; a="125059589:sNHT6712616730" 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 l62HKSQH018982; Mon, 2 Jul 2007 13:20:28 -0400 Received: from dwingwxp ([10.32.240.194]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l62HKR6a008531; Mon, 2 Jul 2007 17:20:27 GMT From: "Dan Wing" To: "'Jean-Francois Mule'" Subject: RE: [MMUSIC] Few comments on ICE-16 Date: Mon, 2 Jul 2007 10:20:28 -0700 Message-ID: <057f01c7bccd$49f68a00$2014590a@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.3138 In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9985@srvxchg3.cablelabs.com> Thread-Index: Ace6k3Y2c0PgTroMR32lOSs5qdzGyAARhatwAHKqKAAAChdhMA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2778; t=1183396828; x=1184260828; c=relaxed/simple; s=rtpdkim1001; 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]=20Few=20comments=20on=20ICE-16 |Sender:=20 |To:=20=22'Jean-Francois=20Mule'=22=20; bh=xEz5heUrUfolHzwpFUE4KROOyQ+L8UkUHCYhy0sVZ9k=; b=Dw6M7wGRJ1cCAf10BXB6xO4LxsrMVFQsmvH4wA9rC67WQyEQO+A8f51UsTQ64mBWLmdLhr9w XAgrGm8XkoBWrJPjlti5sBqorkzX4Q/ylusKZjd7OHq93ItPMi9x/EjN; Authentication-Results: rtp-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 > Ok, it is better than the hard-coded value given the intended benefits > but, as the ID is written, my understanding is that for each media > stream, the agent takes all the potential codecs to be > offered, and for all the associated ptimes, It doesn't use the codecs or ptimes from the offer; rather, it uses the most-preferred codec and its ptime that was chosen by the answerer for its calculation. > calculate the size of the RTP packet/stun to > compute Ta_i and for the sum. > May this is not "significant" given the benefits, but it still looks > more complex. > > > > 1) nit - while you point folks to read section B.1 for more > > > details, it > > > is a bit opaque as presented. Adding one sentence around this > > > formula's > > > goals (same bandwidth as RTP) or risks if implementers choose to > > > hardcode this as 20ms may help. > > > 2) what happens when you have a media stream being offered > > > with a codec > > > and different ptimes supported (e.g. G.711, ptime=10, > 20)? Should an > > > implementation should the default ptime for the codec or the > > > ptime that will result in the greater sum value? > > > > It's impossible for the offerer to send a connectivity check until > > it receives the SDP answer (because until the answer arrives, it > > doesn't know the IP address and UDP port to send its connectivity > > checks to). When the answer arrives, the offerer will know which > > ptime to use. > Yes. > > > The RTO and Ta formulas are calculated at the time > > the answer is received (not when the offer is generated). > Well, nothing says so for Ta. The text in section 5.8 for RTO may > suggest that indeed but not for Ta. > > May be it was my sequential reading of the ID that made me > believe that > at this point in the ICE text(4.1.x), the requirements are only about > gathering candidates. In section 5.8 (about scheduling checks), some > text even says: > | Ta is the same value used to > | pace the gathering of candidates, as described in Section 4.1.1. > > But no text actually forbids an agent to compute the Ta_i before SDP > negotiation as candidates are gathered. Right, but there's no harm in doing it before -- you'll just not be able to complete ICE faster if the answer chose a high-bandwidth codec. It's an implmentation decision on where you want to do the calculation. I don't see any advantage to doing it when you build the offer (the Ta and RTO values aren't needed at that point, anyway), and there are disadvantages to doing the calculation at that point in the call flow. > May be the text for Ta should be moved or referenced elsewhere too > (section 6 and/or 9?). That might help; I'll leave that to Jonathan. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 02 17:56: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 1I5Tt9-0004VM-Ib; Mon, 02 Jul 2007 17:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Tt8-0004VE-2O for mmusic@ietf.org; Mon, 02 Jul 2007 17:56:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Tsy-0003ty-Ex for mmusic@ietf.org; Mon, 02 Jul 2007 17:56:54 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2007 14:56:43 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUoABYRiUarR7MV/2dsb2JhbACCZ4Vwg2KfOg X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208,217"; a="6105027:sNHT34082118" 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 l62LuhfC010000; Mon, 2 Jul 2007 14:56:43 -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 l62LuZXN006232; Mon, 2 Jul 2007 21:56:43 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); Mon, 2 Jul 2007 14:56:25 -0700 Received: from [10.21.83.42] ([10.21.83.42]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 14:56:24 -0700 Message-ID: <46897488.3010700@cisco.com> Date: Mon, 02 Jul 2007 17:56:24 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Belling, Thomas" Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <00c301c7b806$44dd0b00$b978150a@amer.cisco.com><46813243.6090807@cisco.com><1ECE0EB50388174790F9694F77522CCF110A9241@zrc2hxm0.corp.nortel.com><46819193.3070109@cisco.com> <1ECE0EB50388174790F9694F77522CCF110A93D9@zrc2hxm0.corp.nortel.com> <3C1BD8897E747D46B6F037E1CABB9FFFE26FA1@MCHP7IEA.ww002.siemens.net> In-Reply-To: <3C1BD8897E747D46B6F037E1CABB9FFFE26FA1@MCHP7IEA.ww002.siemens.net> X-OriginalArrivalTime: 02 Jul 2007 21:56:24.0733 (UTC) FILETIME=[D5704CD0:01C7BCF3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14783; t=1183413403; x=1184277403; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#5=3A=20Media=20before =20answer |Sender:=20; bh=+pSu7DZZYkoew6In8Hgg0CVM4xilknEaShdxtEBEN3I=; b=MsqgHASaKE5MKl4jQNUMsiCnLnMBb3ICaKlwaFucQvmFN9UzlNVAxpYhio4ugur1O9Rg0xqp k/sjJfNQpfQGNIonAwNxmHx71XUHNaqy2TtMaji39rnphYeBInEtyRyi+6SBh7lz0X7bdRmb5r Zryn9oSo1WNVWVyQajEI738wo=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: Francois Audet , mmusic , 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: , Content-Type: multipart/mixed; boundary="===============1622303904==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1622303904== Content-Type: multipart/alternative; boundary="------------040606010206070801010609" This is a multi-part message in MIME format. --------------040606010206070801010609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Belling, Thomas wrote: > Hi all, > > in my understanding including an answer in an unreliable provisional > response is not allowed by RFC 3261 even it you repeat the answer in > the 200 OK, see top of page 79: > "If the initial offer is in an INVITE, the answer MUST be in > a reliable non-failure message from UAS back to UAC which > is correlated to that INVITE." > Note that this quotations speaks about "the" answer, and I read that > as a requirement that there is only one answer. You need to read the whole bullet: o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. Clearly, an answer can be provided in unreliable provisional responses as well, but then needs to be repeated in a reliable response. > > Even if you might argue there is a bit of ambiguity in the quotation, > I suspect that there may be interoperabilty issues with clients either > not beeing prepared to handle the answer in an unreliable provisional > response (e.g. if they do not support 100rel), or getting confused if > obtaining the same answer both in a provisional response and the 200 OK. > > So I would recommend that you use at least 100rel for option 1 - > preconditions is not really related and indeed not required for this > issue. I think RFC 3261 is pretty clear on this, and we also have call flow documents showing this kind of operation (see e.g. BCP 76/RFC 3666), so I don't see a problem here. Thanks -- Flemming > Regards, Thomas > > > ---------------------------------- > Dr. Thomas Belling > Nokia Siemens Networks GmbH & Co. KG. > > > > Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ > Registered office: München (Munich) - Registergericht /Commercial > register: München (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. > Persönlich haftende Gesellschafterin /General Partner: Nokia Siemens > Networks Management GmbH - Geschäftsführer /Board of Directors: > Christian Unterberger, Joachim Malterer, Roland Meinzer - Sitz der > Gesellschaft / Registered office: München (Munich) - Registergericht > /Commercial register: München (Munich), HRB 163416 > > > ------------------------------------------------------------------------ > *From:* Francois Audet [mailto:audet@nortel.com] > *Sent:* Wednesday, June 27, 2007 2:14 AM > *To:* Flemming Andreasen > *Cc:* mmusic; Dan Wing > *Subject:* RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer > > > > Francois Audet wrote: >> The preconditions approach to me seems like the least likely >> approach to be used in the real world. >> >> I really see only two practical way forward: >> >> 1. >> You have to wait for the answer before playing >> anything. For this to work, we'd effectively have to >> rely on provisional responses including the SDP-answer >> (and not include the answer in the 200, since it would >> cause clipping). That in itself would be a change for >> many SIP clients who never tought it necessary to >> provide an answer before 200 before (at least, they >> didn't think they needed it). >> > You'd have to include the answer in both the provisional > response and the 200, unless you use reliable provisional > responses. > > > Yes, agreed. Both cases are valid. > >> 1. >> Use the different payload type as per our kaplan draft. >> >> My take is that option 1 is the more likely to have wide >> support. But we should explain it a bit. >> Option 2 is interesting, in a geeky way, and probaly better >> than pre-conditions. But if people can live with 1, it seems >> much simpler. > > I'll include an explanation of all of them (there's already some > text on the above, however I'll elaborate on the points you made). > > Excellent. Thanks. > --------------040606010206070801010609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Belling, Thomas wrote:
Hi all,
 
in my understanding including an answer in an unreliable provisional response is not allowed by RFC 3261 even it you repeat the answer in the 200 OK, see top of page 79:
"If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE."
Note that this quotations speaks about "the" answer, and I read that as a requirement that there is only one answer.
You need to read the whole bullet:
<quote>
      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.
</quote>

Clearly, an answer can be provided in unreliable provisional responses as well, but then needs to be repeated in a reliable response.

 
Even if you might argue there is a bit of ambiguity in the quotation, I suspect that there may be interoperabilty issues with clients either not beeing prepared to handle the answer in an unreliable provisional response (e.g. if they do not support 100rel), or getting confused if obtaining the same answer both in a provisional response and the 200 OK.
 
So I would recommend that you use at least 100rel for option 1 - preconditions is not really related and indeed not required for this issue.
I think RFC 3261 is pretty clear on this, and we also have call flow documents showing this kind of operation (see e.g. BCP 76/RFC 3666), so I don't see a problem here.

Thanks

-- Flemming

Regards, Thomas
 

----------------------------------
Dr. Thomas Belling
Nokia Siemens Networks  GmbH & Co. KG.        

 

Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft/ Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRA 88537 - WEEE-Reg.-No. DE 52984304. Persönlich haftende Gesellschafterin /General Partner: Nokia Siemens Networks Management GmbH - Geschäftsführer /Board of Directors: Christian Unterberger, Joachim Malterer, Roland Meinzer - Sitz der Gesellschaft / Registered office: München (Munich) - Registergericht /Commercial register: München (Munich), HRB 163416


From: Francois Audet [mailto:audet@nortel.com]
Sent: Wednesday, June 27, 2007 2:14 AM
To: Flemming Andreasen
Cc: mmusic; Dan Wing
Subject: RE: [MMUSIC] SDPCapNeg Issue #5: Media before answer

 

Francois Audet wrote:
The preconditions approach to me seems like the least likely approach to be used in the real world.
 
I really see only two practical way forward:
  1. You have to wait for the answer before playing anything. For this to work, we'd effectively have to rely on provisional responses including the SDP-answer (and not include the answer in the 200, since it would cause clipping). That in itself would be a change for many SIP clients who never tought it necessary to provide an answer before 200 before (at least, they didn't think they needed it).
You'd have to include the answer in both the provisional response and the 200, unless you use reliable provisional responses. 
 
Yes, agreed. Both cases are valid. 
  1. Use the different payload type as per our kaplan draft.
My take is that option 1 is the more likely to have wide support. But we should explain it a bit.
Option 2 is interesting, in a geeky way, and probaly better than pre-conditions. But if people can live with 1, it seems much simpler.
I'll include an explanation of all of them (there's already some text on the above, however I'll elaborate on the points you made). 

 Excellent. Thanks. 
--------------040606010206070801010609-- --===============1622303904== 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 --===============1622303904==-- From mmusic-bounces@ietf.org Mon Jul 02 17:58: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 1I5TuG-0000Hy-MW; Mon, 02 Jul 2007 17:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5TuF-0000Ht-H6 for mmusic@ietf.org; Mon, 02 Jul 2007 17:58:03 -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 1I5Tu2-00041n-81 for mmusic@ietf.org; Mon, 02 Jul 2007 17:58:03 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2007 14:57:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRABYRiUarR7O6/2dsb2JhbACIV6Mc X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208"; a="499535054:sNHT31560200" 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 l62LvnCW015779; Mon, 2 Jul 2007 14:57:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l62Lvnka000391; Mon, 2 Jul 2007 21:57:49 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); Mon, 2 Jul 2007 14:57:48 -0700 Received: from [10.21.83.42] ([10.21.83.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 14:57:48 -0700 Message-ID: <468974DC.10801@cisco.com> Date: Mon, 02 Jul 2007 17:57:48 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes References: <467FF7A8.6040303@cisco.com> <4682A2A7.8000606@bbn.com> In-Reply-To: <4682A2A7.8000606@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2007 21:57:48.0626 (UTC) FILETIME=[07715B20:01C7BCF4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3091; t=1183413469; x=1184277469; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#1=3A=20To=20Add, =20De lete=20and=20Replace=20Attributes |Sender:=20; bh=nWiLwNJ2aXuAqj7X1Lu3y1A4JmrRohcmFrK0OywteyY=; b=lA3Oh4vy5DUVgiiaMp6ASZaMqzcG+tFA8S56sZNXZfcOjQfqvPml8KpauWiiwVxeIiE4N8nS aVWz1QQ5X282b47WENYYjfX2sGDLw8NUe38aVU7pa2WyIYcbYzD9fI/+; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mmusic 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 Matt Lepinski wrote: > Flemming, > > Thanks for producing a draft that captures the motivation for deletion > of attributes in capability negotiation. > > I also think that Option (B) is a good comprise that solves the > problem without the perception of unnecessary complexity which seems > to burden Option (A). > > The only downside of Option (B) seems to be that, unlike in Option > (C), if deletion is used then one needs an a=acap line for attribute > for every attribute, even those present in all potential configurations. Right. > > For example: > > v=0 > o=alice 2890844526 2890842807 IN IP4 10.0.0.1 > s=Example SDP > t=0 0 > c=IN IP4 10.0.0.1 > m=audio 51000 RTP/SAVP 0 99 > a=crypto:1 AES_CM_128_HMAC_SHA1_32... > a=ptime:30 > a=rtpmap:99 L16/8000 > a=tcap:1 RTP/AVP > a=acap:1 a=ptime:30 > a=acap:2 a=rtpmap:99 L16/8000 > a=pcfg:1 t=1 a=-m:1,2 > > The above is an offer indicating a preference for RTP, and a > willingness to accept an S-RTP audio stream. Since we need to delete > the crypto attribute from the potential RTP configuration (and since > in Option B we have only clean-slate delete-all-attributes available) > we need to add a=acap lines for the a=ptime and a=rtpmap attributes. > > Adding these additional lines is a bit inefficient, but it doesn't > seem like a serious problem to me. However, if someone has a use-case > where deletion is required and yet the inefficiency of option (B) is > unacceptable, then I'd be willing to support Option (C). OK - thanks -- Flemming > > - Matt Lepinski :-> > > Flemming Andreasen wrote: > >> Probably the biggest open issue we have in the SDP Capability >> Negotiation Framework at this point is the ability to replace and >> delete attributes from an actual configuration SDP when generating a >> potential configuration. At the Prague IETF, people asked for some >> more motiviation and use cases for this feature before deciding >> whether we should include it in the core capability negotiation >> framework or not. I have written a short I-D in the subject, which >> you can find at: >> >> >> http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-del-00.txt >> >> >> Please take a look at this and let me know how you think we should >> resolve this issue. Options include: >> >> A) Remove the ability to delete and replace attributes completely. >> B) Remove the ability to delete and replace individual attributes, >> but allow for complete removal of all attributes (clean slate) >> C) Keep the current ability to delete and remove individual and all >> attributes. >> >> My personal preference is for option A, however in the interest of >> moving forward and making a reasonable compromise between >> functionality and complexity, my recommendation is option B. >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Jul 02 18:05: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 1I5U1d-0000XH-Gq; Mon, 02 Jul 2007 18:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5U1b-0000Pc-Ni for mmusic@ietf.org; Mon, 02 Jul 2007 18:05:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5U1W-0007D4-VB for mmusic@ietf.org; Mon, 02 Jul 2007 18:05:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2007 15:05:34 -0700 X-IronPort-AV: i="4.16,489,1175497200"; d="scan'208,217"; a="175756232:sNHT91404513" 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 l62M5YIr028004; Mon, 2 Jul 2007 15:05:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l62M5Jl8005777; Mon, 2 Jul 2007 22:05:34 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); Mon, 2 Jul 2007 15:05:25 -0700 Received: from [10.21.83.42] ([10.21.83.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 15:05:25 -0700 Message-ID: <468976A5.1060608@cisco.com> Date: Mon, 02 Jul 2007 18:05:25 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Even, Roni" Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes References: <144ED8561CE90C41A3E5908EDECE315C04AFCE9B@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04AFCE9B@IsrExch01.israel.polycom.com> X-OriginalArrivalTime: 02 Jul 2007 22:05:25.0401 (UTC) FILETIME=[17B3B090:01C7BCF5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9706; t=1183413934; x=1184277934; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#1=3A=20To=20Add, =20De lete=20and=20Replace=20Attributes |Sender:=20; bh=iGe7OQUXgZCSKGCIG7YV6/NdMx6tYF6uSK5cPovqfgc=; b=weWhxTr/mfM1koINnbuNxJ6bEqzliCduLprzzVG1/mRqdz/9TAE1ycjQIWBXRBEJFlhc3YR8 O+ZHczG2ofieNGK6g2cd/6v2+LbuGRl3wDJHZiB2IALlBzO0mvf9J+md; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: mmusic 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="===============0579339902==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0579339902== Content-Type: multipart/alternative; boundary="------------040606030906080704090803" This is a multi-part message in MIME format. --------------040606030906080704090803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Even, Roni wrote: > Flemming, > I reviewed the draft and from the option I think I prefer B but am not sure what it will mean. My preference is described here. > > My view is that the replace problem can be solved by implied behavior. The delete cases are more problematic. > > The replace - if you have in the potential configuration the same payload type in the fmpt or rtpmap as in the SDP than if using an actual configuration from the potential configuration it implies that it replaces the fmtp and rtpmap from the SDP. > This means that if in the SDP there is fmtp and rtpmap while in the actual configuration there is only rtpmap for the same payload type than both attributes from the SDP are replaced by only rtpmap. > Doing so requires logic and processing that is really outside the scope of core capability negotiation framework, which I believe is why we have seen pushback on these kinds of features. It may be more sensible to adopt what you describe above as an enhancement that can be used by the media capabilities extension. > The general case is that same attribute in the SDP and in the actual configuration are implicitly replaced. > The problem is that "same attribute" is too vague and also doesn't quite do what you want some times. For example, you are not replacing all "rtpmap" attributes in your example above, only the ones with the same payload type and you then furthermore couple if with corresponding "fmtp" attributes. We have other potential examples with different attribute names (think about direction attributes, comedia, etc.). > In the case of delete, your example shows the difficult part when the attributes do not have the same name or a using the same payload type. The duplication is based on similar semantics. It may be enough to leave it as you suggest in section 4 of your contribution but I would not object to real delete. > Me neither, but we don't seem to have consensus to go that far in the core document. > > > As for the point about if both should be addressed in the core document. I suggest yes since we will need it and I think that the replace problem is easier based on my description. > See above - again, I think we need to address these as part of a more sophisticated extension (e.g. media capabilities). Thanks -- Flemming > Roni > > >> -----Original Message----- >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: Monday, June 25, 2007 8:13 PM >> To: mmusic >> Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace >> Attributes >> >> Probably the biggest open issue we have in the SDP Capability >> Negotiation Framework at this point is the ability to replace and delete >> attributes from an actual configuration SDP when generating a potential >> configuration. At the Prague IETF, people asked for some more >> motiviation and use cases for this feature before deciding whether we >> should include it in the core capability negotiation framework or not. I >> have written a short I-D in the subject, which you can find at: >> >> >> http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att- >> del-00.txt >> >> Please take a look at this and let me know how you think we should >> resolve this issue. Options include: >> >> A) Remove the ability to delete and replace attributes completely. >> B) Remove the ability to delete and replace individual attributes, but >> allow for complete removal of all attributes (clean slate) >> C) Keep the current ability to delete and remove individual and all >> attributes. >> >> My personal preference is for option A, however in the interest of >> moving forward and making a reasonable compromise between functionality >> and complexity, my recommendation is option B. >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > --------------040606030906080704090803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Even, Roni wrote: 
Flemming,
I reviewed the draft and from the option I think I prefer B but am not sure what it will mean. My preference is described here.

My view is that the replace problem can be solved by implied behavior. The delete cases are more problematic.

The replace - if you have in the potential configuration the same payload type in the fmpt or rtpmap as in the SDP than if using an actual configuration from the potential configuration it implies that it replaces the fmtp and rtpmap from the SDP. 
This means that if in the SDP there is fmtp and rtpmap while in the actual configuration there is only rtpmap for the same payload type than both attributes from the SDP are replaced by only rtpmap.
Doing so requires logic and processing that is really outside the scope of core capability negotiation framework, which I believe is why we have seen pushback on these kinds of features. It may be more sensible to adopt what you describe above as an enhancement that can be used by the media capabilities extension. 

The general case is that same attribute in the SDP and in the actual configuration are implicitly replaced.
The problem is that "same attribute" is too vague and also doesn't quite do what you want some times. For example, you are not replacing all "rtpmap" attributes in your example above, only the ones with the same payload type and you then furthermore couple if with corresponding "fmtp" attributes. We have other potential examples with different attribute names (think about direction attributes, comedia, etc.). 

In the case of delete, your example shows the difficult part when the attributes do not have the same name or a using the same payload type. The duplication is based on similar semantics. It may be enough to leave it as you suggest in section 4 of your contribution but I would not object to real delete.
Me neither, but we don't seem to have consensus to go that far in the core document. 
 

As for the point about if both should be addressed in the core document. I suggest yes since we will need it and I think that the replace problem is easier based on my description.
See above - again, I think we need to address these as part of a more sophisticated extension (e.g. media capabilities).

Thanks

-- Flemming 

Roni

  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Monday, June 25, 2007 8:13 PM
To: mmusic
Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace
Attributes

Probably the biggest open issue we have in the SDP Capability
Negotiation Framework at this point is the ability to replace and delete
attributes from an actual configuration SDP when generating a potential
configuration. At the Prague IETF, people asked for some more
motiviation and use cases for this feature before deciding whether we
should include it in the core capability negotiation framework or not. I
have written a short I-D in the subject, which you can find at:


http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-
del-00.txt

Please take a look at this and let me know how you think we should
resolve this issue. Options include:

A) Remove the ability to delete and replace attributes completely.
B) Remove the ability to delete and replace individual attributes, but
allow for complete removal of all attributes (clean slate)
C) Keep the current ability to delete and remove individual and all
attributes.

My personal preference is for option A, however in the interest of
moving forward and making a reasonable compromise between functionality
and complexity, my recommendation is option B.

Thanks

-- Flemming








_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--------------040606030906080704090803-- --===============0579339902== 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 --===============0579339902==-- From mmusic-bounces@ietf.org Tue Jul 03 03:10: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 1I5cWW-0004KT-56; Tue, 03 Jul 2007 03:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5cWT-0004KF-VJ for mmusic@ietf.org; Tue, 03 Jul 2007 03:10:05 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5cVI-0005SU-2G for mmusic@ietf.org; Tue, 03 Jul 2007 03:10:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes Date: Tue, 3 Jul 2007 10:09:54 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04AFD06B@IsrExch01.israel.polycom.com> In-Reply-To: <468976A5.1060608@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes Thread-Index: Ace89ULIDsk9RBWoRfW67hU3Ik+n/wASkIRA From: "Even, Roni" To: "Flemming Andreasen" X-Spam-Score: 0.1 (/) X-Scan-Signature: 92bf9d0448089f15cee3c3c378c3e25d Cc: mmusic 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="===============1928025737==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1928025737== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BD41.287326F3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BD41.287326F3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Flemming, I see no problem in describing the behavior of rtpmap and fmtp in the = media draft but it will require that the core document will not define = any policy that is contradictory.=20 That will mean that the core document will explicitly leave potential = m-line support for the media document. This is true if option A is = selected. =20 If the consensus will be to option B for full delete it will mean that = you will have to repeat the rtpmap and fmtp in potential configuration = like Matt mentioned in his email so it is not even a question of = replace. =20 My personal view is to use option A for delete based on your suggestion = in section 4 of your draft and to leave the replace option to the media = document. It looks to me that this is also your view. =20 Roni =20 ________________________________ From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Tuesday, July 03, 2007 1:05 AM To: Even, Roni Cc: mmusic Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace = Attributes =20 Even, Roni wrote:=20 Flemming, I reviewed the draft and from the option I think I prefer B but am not = sure what it will mean. My preference is described here. =20 My view is that the replace problem can be solved by implied behavior. = The delete cases are more problematic. =20 The replace - if you have in the potential configuration the same = payload type in the fmpt or rtpmap as in the SDP than if using an actual = configuration from the potential configuration it implies that it = replaces the fmtp and rtpmap from the SDP.=20 This means that if in the SDP there is fmtp and rtpmap while in the = actual configuration there is only rtpmap for the same payload type than = both attributes from the SDP are replaced by only rtpmap. =20 Doing so requires logic and processing that is really outside the scope = of core capability negotiation framework, which I believe is why we have = seen pushback on these kinds of features. It may be more sensible to = adopt what you describe above as an enhancement that can be used by the = media capabilities extension.=20 The general case is that same attribute in the SDP and in the actual = configuration are implicitly replaced. =20 The problem is that "same attribute" is too vague and also doesn't quite = do what you want some times. For example, you are not replacing all = "rtpmap" attributes in your example above, only the ones with the same = payload type and you then furthermore couple if with corresponding = "fmtp" attributes. We have other potential examples with different = attribute names (think about direction attributes, comedia, etc.).=20 In the case of delete, your example shows the difficult part when the = attributes do not have the same name or a using the same payload type. = The duplication is based on similar semantics. It may be enough to leave = it as you suggest in section 4 of your contribution but I would not = object to real delete. =20 Me neither, but we don't seem to have consensus to go that far in the = core document.=20 =20 =20 As for the point about if both should be addressed in the core document. = I suggest yes since we will need it and I think that the replace problem = is easier based on my description. =20 See above - again, I think we need to address these as part of a more = sophisticated extension (e.g. media capabilities).=20 Thanks -- Flemming=20 =20 Roni =20 =20 -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Monday, June 25, 2007 8:13 PM To: mmusic Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes =20 Probably the biggest open issue we have in the SDP Capability Negotiation Framework at this point is the ability to replace and = delete attributes from an actual configuration SDP when generating a potential configuration. At the Prague IETF, people asked for some more motiviation and use cases for this feature before deciding whether we should include it in the core capability negotiation framework or not. = I have written a short I-D in the subject, which you can find at: =20 =20 = http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-= del-00.txt =20 Please take a look at this and let me know how you think we should resolve this issue. Options include: =20 A) Remove the ability to delete and replace attributes completely. B) Remove the ability to delete and replace individual attributes, but allow for complete removal of all attributes (clean slate) C) Keep the current ability to delete and remove individual and all attributes. =20 My personal preference is for option A, however in the interest of moving forward and making a reasonable compromise between functionality and complexity, my recommendation is option B. =20 Thanks =20 -- Flemming =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =20 =20 =20 ------_=_NextPart_001_01C7BD41.287326F3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Flemming,

I see no problem in describing the behavior of rtpmap and fmtp in the media draft but it will require that = the core document will not define any policy that is contradictory. =

That will mean that the core = document will explicitly leave potential m-line support for the media document. This = is true if option A is selected.

 

If the consensus will be to option = B for full delete it will mean that you will have to repeat the rtpmap and = fmtp in potential configuration like Matt mentioned in his email so it is not = even a question of replace.

 

My personal view is to use option A = for delete based on your suggestion in section 4 of your draft and to leave = the replace option to the media document.

It looks to me that this is also = your view.

 

Roni

 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, July 03, = 2007 1:05 AM
To: Even, Roni
Cc: mmusic
Subject: Re: [MMUSIC] = SDPCapNeg Issue #1: To Add, Delete and Replace Attributes

 



Even, Roni wrote: 

Flemming,
<=
font
size=3D2 color=3Dblack face=3D"Courier New">I reviewed the draft and from the option I =
think I prefer B but am not sure what it will mean. My preference is =
described here.
 
My view is that the replace problem can be =
solved by implied behavior. The delete cases are more =
problematic.
 
The replace - if you have in the potential =
configuration the same payload type in the fmpt or rtpmap as in the SDP =
than if using an actual configuration from the potential configuration =
it implies that it replaces the fmtp and rtpmap from the SDP. =

This means that if in the SDP there is fmtp =
and rtpmap while in the actual configuration there is only rtpmap for =
the same payload type than both attributes from the SDP are replaced by =
only rtpmap.
=A0

Doing so requires logic and processing that = is really outside the scope of core capability negotiation framework, which I = believe is why we have seen pushback on these kinds of features. It may be more = sensible to adopt what you describe above as an enhancement that can be used by = the media capabilities extension. 


The general case is that same attribute in =
the SDP and in the actual configuration are implicitly =
replaced.
=A0

The problem is that "same = attribute" is too vague and also doesn't quite do what you want some times. For example, = you are not replacing all "rtpmap" attributes in your example above, = only the ones with the same payload type and you then furthermore couple if with corresponding "fmtp" attributes. We have other potential = examples with different attribute names (think about direction attributes, = comedia, etc.). 


In the case of delete, your example shows the =
difficult part when the attributes do not have the same name or a using =
the same payload type. The duplication is based on similar semantics. It =
may be enough to leave it as you suggest in section 4 of your =
contribution but I would not object to real =
delete.
=A0

Me neither, but we don't seem to have = consensus to go that far in the core document. 

=A0
 
As for the point about if both should be =
addressed in the core document. I suggest yes since we will need it and =
I think that the replace problem is easier based on my =
description.
=A0

See above - again, I think we need to address = these as part of a more sophisticated extension (e.g. media capabilities).

Thanks

-- Flemming 


 
Roni
 
=A0 
-----Original =
Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Monday, June 25, 2007 8:13 =
PM
To: =
mmusic
Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, =
Delete and Replace
Attributes
=
 
Probably the biggest open issue we have in =
the SDP Capability
Negotiation Framework at this point is the =
ability to replace and delete
attributes from an actual configuration SDP =
when generating a potential
configuration. At the Prague IETF, people =
asked for some more
motiviation and use cases for this feature =
before deciding whether we
should include it in the core capability =
negotiation framework or not. I
have written a short I-D in the subject, =
which you can find at:
 
 
http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpca=
pneg-att-
del-00.txt
=
 
Please take a look at this and let me know =
how you think we should
resolve this issue. Options =
include:
 
A) Remove the ability to delete and replace =
attributes completely.
B) Remove the ability to delete and replace =
individual attributes, but
allow for complete removal of all attributes =
(clean slate)
C) Keep the current ability to delete and =
remove individual and all
attributes.
 
My personal preference is for option A, =
however in the interest of
moving forward and making a reasonable =
compromise between =
functionality
and complexity, my recommendation is option =
B.
 
Thanks
 
-- =
Flemming
 
 
 
 
 
 
 
 
______________________________________________=
_
mmusic mailing =
list
mmusic@ietf.org
https://www1.ietf.=
org/mailman/listinfo/mmusic
=A0=A0=A0 =

 
=A0
------_=_NextPart_001_01C7BD41.287326F3-- --===============1928025737== 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 --===============1928025737==-- From mmusic-bounces@ietf.org Tue Jul 03 08:52: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 1I5hrh-0002rJ-22; Tue, 03 Jul 2007 08:52:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hrf-0002rE-UI for mmusic@ietf.org; Tue, 03 Jul 2007 08:52:19 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5hrI-0008KU-Va for mmusic@ietf.org; Tue, 03 Jul 2007 08:52:19 -0400 Received: from [192.168.1.2] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4DA2B13CF81; Tue, 3 Jul 2007 14:51:56 +0200 (CEST) In-Reply-To: <4d0605c20706271154q54476ffk10aef075944cb50f@mail.gmail.com> References: <4d0605c20706271154q54476ffk10aef075944cb50f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4A6C5FA3-B33E-42CF-BF74-611AAD66C613@netlab.nec.de> From: Martin Stiemerling Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-15.txt Date: Tue, 3 Jul 2007 14:51:55 +0200 To: Joseph Pallas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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="===============2130581573==" Errors-To: mmusic-bounces@ietf.org --===============2130581573== Content-Type: multipart/alternative; boundary=Apple-Mail-4--998514822 --Apple-Mail-4--998514822 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Am 27.06.2007 um 20:54 schrieb Joseph Pallas: >> The new version of draft-ietf-mmusic-rfc2326bis is just an XML- >> lized version >> of draft-ietf-mmusic-rfc2326bis-14.txt. >> >> draft-ietf-mmusic-rfc2326bis-14.txt was using tex sources >> and the first step was to convert the old draft sources to the >> newer xml >> format used by xml2rfc. >> >> Magnus and me have done a check of this version, but it would be >> good if >> other people could also take a look, whether the -14 and -15 are >> the same in >> terms of contents of the draft. > > I couldn't spot any content differences, so I'm glad to know there > weren't supposed to be any. On the formatting front, there are a > couple of places where references are rendered oddly, as in > > The URI scheme "rtsp" requires that commands are issued via a > reliable protocol (within the Internet, TCP), while the scheme > "rtsps" identifies a reliable transport using secure transport (TLS > [RFC4346], see Section (Section 18). Ok, I will check the references. Thanks a lot! Martin > > There are also some places where SET_PARAMETER and GET_PARAMETER are > missing the underscore. I'm not sure if that's new. > > joe > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-4--998514822 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

Am = 27.06.2007 um 20:54 schrieb Joseph Pallas:

The new version of = draft-ietf-mmusic-rfc2326bis is just an XML-lized version
of draft-ietf-mmusic-rfc2326bis-14.txt.

and the first step was to convert the old draft = sources to the newer xml
format used = by xml2rfc.

Magnus and me have done a check of this version, but = it would be good if
other people could also = take a look, whether the -14 and -15 are the same in
terms of contents of the draft.
=

I couldn't spot any content differences, so I'm glad = to know there
weren't supposed to be any.=A0 On the formatting front, = there are a
couple of places where = references are rendered oddly, as in

=A0 The URI scheme "rtsp" = requires that commands are issued via a
=A0 reliable protocol (within the = Internet, TCP), while the scheme
=A0 "rtsps" identifies a reliable = transport using secure transport (TLS
=A0 [RFC4346], see Section = (Section 18).

Ok, I will check the = references.=A0

Thanks a lot!

=A0 = Martin


There are also some places where = SET_PARAMETER and GET_PARAMETER are
missing the = underscore.=A0 I'm not sure = if that's new.

joe

mmusic mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-4--998514822-- --===============2130581573== 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 --===============2130581573==-- From mmusic-bounces@ietf.org Tue Jul 03 10:24: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 1I5jIN-00026d-T2; Tue, 03 Jul 2007 10:23:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jIL-0001xk-7h for mmusic@ietf.org; Tue, 03 Jul 2007 10:23:57 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5jIK-0001PE-SA for mmusic@ietf.org; Tue, 03 Jul 2007 10:23:57 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I5jHo-0004L2-4n for mmusic@ietf.org; Tue, 03 Jul 2007 10:23:24 -0400 Message-ID: <468A5BDC.8080801@bbn.com> Date: Tue, 03 Jul 2007 10:23:24 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 Flemming, Thanks for the reply, I now see where the problem is with solution (2). Solution (4) seems like the best solution. (I guess it's more convenient to mark my crypto attributes as mandatory than to mark all of my rtpmaps as optional). It seems that in implementing Solution (4) there are two possibilities: A) Mark the attributes as "optional" in the a=acap line B) Mark the attributes as "optional" in the a=pcfg line Both of these options seem reasonable me. I guess (B) is probably perferred because it's more expressive. (Although I'm not sure when you'd want an attribute to be optional in one a=pcfg line and mandatory in another a=pcfg line). - Matt Lepinski :-> Flemming Andreasen wrote: > > > Matt Lepinski wrote: > >> Flemming, >> >> I'm concerned that marking individual attributes within a potential >> configuration as mandatory or optional will increase the perception >> of complexity for SDP capability negotiation. Therefore, my >> preference would be to avoid Options (3) and (4). >> >> Personally, I can't think of a use-case where the lack of flexibility >> in Option (2) would cause signficant problems. > > > How about rtpmaps mapping to an unsupported codec (which codec > negotiation/standard 3264 procedures would have taken care of) ? It > will be a quite common use case for the media capabilities extension. > >> Therefore, I'd favor Option (2). >> > Per the above, I think there are important use cases that will make > this option problematic. > > -- Flemming > >> - Matt Lepinski :-> >> >> Flemming Andreasen wrote: >> >>> Jonathan Lennox had noted that the current potential configurationa >>> algorithm combined with the standard SDP rules of ignoring unknown >>> attributes, may lead an answerer to select a potential configuration >>> with attributes it does not support, when the intent was to actually >>> have the answerer select a potential configuration with attributes >>> the answerer does support. Clearly, this does not produce the >>> desired outcome. >>> >>> The reason for this is that we still use the standard SDP rules >>> where we ignore unknown SDP attributes. >>> >>> The design team did not get a chance to discuss this issue in >>> Prague, however there seems to be a few possible solutions to this one: >>> >>> 1) Continue with the current scheme, but allow the answerer to >>> select only a potential configuration if the potential configuration >>> makes sense and can be supported. This would ensure that any >>> attributes that are required in order for a potential configuration >>> to be used would have to be supported by the answerer in order for >>> him to select that. For example, if the media stream is for SRTP, >>> and the potential configuration specifies use of the "crypto" >>> attribute for keying material, which the answerer didn't support, >>> the answerer would move on to the next potential configuration >>> (which could use a different keying mechanism). >>> >>> >>> 2) Require that all attributes used by a potential configuration >>> MUST be supported by the answerer in order for that potential >>> configuration to be valid (and hence be able to be selected). An >>> attribute is supported if both the attribute type and its value can >>> be supported. This raises some potential ambiguity with payload >>> types for example, where an rtpmap is both understood and supported, >>> but the actual codec is not. >>> >>> 3) As 2), however allow for individual attribute capabilities to be >>> marked as "optional" in a potential configuration. If an "optional" >>> attribute capability is not supported by the answerer, the potential >>> configuration would still be considered valid. >>> >>> 4) Similar to 3), except the default would be "optional", and we can >>> mark certain attributes as mandatory. >>> >>> >>> Option 1 seems flaky and is not recommended. >>> Option 2 is simple to specify and use, however, as noted, it is not >>> clear it has sufficient flexibility >>> The recommendation here is for either option 3 or 4, with the choice >>> depending on whether you believe optional or mandatory attributes >>> are the more common use cases for SDP Capability Negotiation. >>> >>> My preference is for option 4. Compared to option 3, this option >>> aligns slightly better with standard SDP as well, inasmuch as the >>> default operation is normal SDP, and any changes from that requires >>> an explicit indication (mandatory attribute). >>> >>> Please let me know if you disagree or have any comments on this. >>> >>> Thanks >>> >>> -- Flemming >>> >>> _______________________________________________ >>> 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 Jul 03 15:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nq0-0000HL-PF; Tue, 03 Jul 2007 15:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5npy-0008TN-Is for mmusic@ietf.org; Tue, 03 Jul 2007 15:14:58 -0400 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5npk-0001vD-UN for mmusic@ietf.org; Tue, 03 Jul 2007 15:14:58 -0400 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id EB804BDC2F; Wed, 4 Jul 2007 04:14:43 +0900 (JST) Received: from [127.0.0.1] (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id BA67F6E362; Wed, 4 Jul 2007 04:14:43 +0900 (JST) Message-ID: <468AA02A.6090008@nttv6.jp> Date: Wed, 04 Jul 2007 04:14:50 +0900 From: Makoto SAITO User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Dan Wing Subject: [MMUSIC] draft-saito-mmusic-sdp-ike-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 Hello all, I updated the draft about media description for IKE, http://www.ietf.org/internet-drafts/draft-saito-mmusic-sdp-ike-01.txt I couldn't make a presentation about this draft in the previous meeting in Prague, but got various feedback from many people. This draft specifies how to use a certificate fingerprint in SDP (rfc4572) to bootstrap IKE setup. I hope this draft gets your interest. Thanks, -- Makoto Saito _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 03 15:18: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 1I5ntl-00038e-32; Tue, 03 Jul 2007 15:18:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ntj-00037T-KF for mmusic@ietf.org; Tue, 03 Jul 2007 15:18:51 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5nti-0006zv-8g for mmusic@ietf.org; Tue, 03 Jul 2007 15:18:51 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Jul 2007 12:18:49 -0700 X-IronPort-AV: i="4.16,493,1175497200"; d="scan'208,217"; a="6424362:sNHT74045604" 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 l63JImVq014221; Tue, 3 Jul 2007 12:18:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l63JIhkc028141; Tue, 3 Jul 2007 19:18:47 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, 3 Jul 2007 12:18:44 -0700 Received: from [10.21.83.42] ([10.21.83.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 12:18:43 -0700 Message-ID: <468AA112.4090904@cisco.com> Date: Tue, 03 Jul 2007 15:18:42 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Even, Roni" Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes References: <144ED8561CE90C41A3E5908EDECE315C04AFD06B@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04AFD06B@IsrExch01.israel.polycom.com> X-OriginalArrivalTime: 03 Jul 2007 19:18:43.0948 (UTC) FILETIME=[F8C8D2C0:01C7BDA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=27444; t=1183490328; x=1184354328; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#1=3A=20To=20Add, =20De lete=20and=20Replace=20Attributes |Sender:=20; bh=0bBu4wHF3QxGhB7uj6e3pOKVYDDukYf/hlYuUKy7yq0=; b=fK/XUOzXOthZtBNoqwr/3mAY0bxQfhxd8scV2hcgH8Yn8xgkfudAq4KOEIeavHap7Jibu6t9 izuKJI9KtrlJiNkTBN46X7Mml7hxr9QgXOLQpsRGpoITmVqiYL9qSiv7; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd Cc: mmusic 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="===============2012785359==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2012785359== Content-Type: multipart/alternative; boundary="------------030306040003010704010405" This is a multi-part message in MIME format. --------------030306040003010704010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Even, Roni wrote: > > Flemming, > > I see no problem in describing the behavior of rtpmap and fmtp in the > media draft but it will require that the core document will not define > any policy that is contradictory. > Right. > > That will mean that the core document will explicitly leave potential > m-line support for the media document. This is true if option A is > selected. > > > > If the consensus will be to option B for full delete it will mean that > you will have to repeat the rtpmap and fmtp in potential configuration > like Matt mentioned in his email so it is not even a question of replace. > Right. > > > > My personal view is to use option A for delete based on your > suggestion in section 4 of your draft and to leave the replace option > to the media document. > > It looks to me that this is also your view. > My suggestion in the draft is for option B, which is what I suggested in the e-mail thread here as well, i.e. a global delete. As you note, replace will be left for extensions. Thanks -- Flemming PS: In the original e-mail below, I incorrectly said that my personal preference was for for option A, however I meant option C (which is also what the draft suggests). It doesn't change my recommendation for option B though, which seems to be where consensus is at this point as well (based on the other responses, it seems people understood what I meant). Sorry for the confusion. > > > Roni > > > > ------------------------------------------------------------------------ > > *From:* Flemming Andreasen [mailto:fandreas@cisco.com] > *Sent:* Tuesday, July 03, 2007 1:05 AM > *To:* Even, Roni > *Cc:* mmusic > *Subject:* Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace > Attributes > > > > > > Even, Roni wrote: > > Flemming, > I reviewed the draft and from the option I think I prefer B but am not sure what it will mean. My preference is described here. > > My view is that the replace problem can be solved by implied behavior. The delete cases are more problematic. > > The replace - if you have in the potential configuration the same payload type in the fmpt or rtpmap as in the SDP than if using an actual configuration from the potential configuration it implies that it replaces the fmtp and rtpmap from the SDP. > This means that if in the SDP there is fmtp and rtpmap while in the actual configuration there is only rtpmap for the same payload type than both attributes from the SDP are replaced by only rtpmap. > > > Doing so requires logic and processing that is really outside the > scope of core capability negotiation framework, which I believe is why > we have seen pushback on these kinds of features. It may be more > sensible to adopt what you describe above as an enhancement that can > be used by the media capabilities extension. > > > The general case is that same attribute in the SDP and in the actual configuration are implicitly replaced. > > > The problem is that "same attribute" is too vague and also doesn't > quite do what you want some times. For example, you are not replacing > all "rtpmap" attributes in your example above, only the ones with the > same payload type and you then furthermore couple if with > corresponding "fmtp" attributes. We have other potential examples with > different attribute names (think about direction attributes, comedia, > etc.). > > > In the case of delete, your example shows the difficult part when the attributes do not have the same name or a using the same payload type. The duplication is based on similar semantics. It may be enough to leave it as you suggest in section 4 of your contribution but I would not object to real delete. > > > Me neither, but we don't seem to have consensus to go that far in the > core document. > > > > As for the point about if both should be addressed in the core document. I suggest yes since we will need it and I think that the replace problem is easier based on my description. > > > See above - again, I think we need to address these as part of a more > sophisticated extension (e.g. media capabilities). > > Thanks > > -- Flemming > > > > Roni > > >> -----Original Message----- >> From: Flemming Andreasen [mailto:fandreas@cisco.com] >> Sent: Monday, June 25, 2007 8:13 PM >> To: mmusic >> Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace >> Attributes >> >> Probably the biggest open issue we have in the SDP Capability >> Negotiation Framework at this point is the ability to replace and delete >> attributes from an actual configuration SDP when generating a potential >> configuration. At the Prague IETF, people asked for some more >> motiviation and use cases for this feature before deciding whether we >> should include it in the core capability negotiation framework or not. I >> have written a short I-D in the subject, which you can find at: >> >> >> http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att- >> del-00.txt >> >> Please take a look at this and let me know how you think we should >> resolve this issue. Options include: >> >> A) Remove the ability to delete and replace attributes completely. >> B) Remove the ability to delete and replace individual attributes, but >> allow for complete removal of all attributes (clean slate) >> C) Keep the current ability to delete and remove individual and all >> attributes. >> >> My personal preference is for option A, however in the interest of >> moving forward and making a reasonable compromise between functionality >> and complexity, my recommendation is option B. >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > --------------030306040003010704010405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Even, Roni wrote:

Flemming,

I see no problem in describing the behavior of rtpmap and fmtp in the media draft but it will require that the core document will not define any policy that is contradictory.

Right.

That will mean that the core document will explicitly leave potential m-line support for the media document. This is true if option A is selected.

 

If the consensus will be to option B for full delete it will mean that you will have to repeat the rtpmap and fmtp in potential configuration like Matt mentioned in his email so it is not even a question of replace.

Right.

 

My personal view is to use option A for delete based on your suggestion in section 4 of your draft and to leave the replace option to the media document.

It looks to me that this is also your view.

My suggestion in the draft is for option B, which is what I suggested in the e-mail thread here as well, i.e. a global delete. As you note, replace will be left for extensions.

Thanks

-- Flemming


PS:  In the original e-mail below, I incorrectly said that my personal preference was for for option A, however I meant option C (which is also what the draft suggests). It doesn't change my recommendation for option B though, which seems to be where consensus is at this point as well (based on the other responses, it seems people understood what I meant). Sorry for the confusion.

 

Roni

 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Tuesday, July 03, 2007 1:05 AM
To: Even, Roni
Cc: mmusic
Subject: Re: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace Attributes

 



Even, Roni wrote: 

Flemming,
I reviewed the draft and from the option I think I prefer B but am not sure what it will mean. My preference is described here.
 
My view is that the replace problem can be solved by implied behavior. The delete cases are more problematic.
 
The replace - if you have in the potential configuration the same payload type in the fmpt or rtpmap as in the SDP than if using an actual configuration from the potential configuration it implies that it replaces the fmtp and rtpmap from the SDP. 
This means that if in the SDP there is fmtp and rtpmap while in the actual configuration there is only rtpmap for the same payload type than both attributes from the SDP are replaced by only rtpmap.
 

Doing so requires logic and processing that is really outside the scope of core capability negotiation framework, which I believe is why we have seen pushback on these kinds of features. It may be more sensible to adopt what you describe above as an enhancement that can be used by the media capabilities extension. 


The general case is that same attribute in the SDP and in the actual configuration are implicitly replaced.
 

The problem is that "same attribute" is too vague and also doesn't quite do what you want some times. For example, you are not replacing all "rtpmap" attributes in your example above, only the ones with the same payload type and you then furthermore couple if with corresponding "fmtp" attributes. We have other potential examples with different attribute names (think about direction attributes, comedia, etc.). 


In the case of delete, your example shows the difficult part when the attributes do not have the same name or a using the same payload type. The duplication is based on similar semantics. It may be enough to leave it as you suggest in section 4 of your contribution but I would not object to real delete.
 

Me neither, but we don't seem to have consensus to go that far in the core document. 

 
 
As for the point about if both should be addressed in the core document. I suggest yes since we will need it and I think that the replace problem is easier based on my description.
 

See above - again, I think we need to address these as part of a more sophisticated extension (e.g. media capabilities).

Thanks

-- Flemming 


 
Roni
 
  
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Monday, June 25, 2007 8:13 PM
To: mmusic
Subject: [MMUSIC] SDPCapNeg Issue #1: To Add, Delete and Replace
Attributes
 
Probably the biggest open issue we have in the SDP Capability
Negotiation Framework at this point is the ability to replace and delete
attributes from an actual configuration SDP when generating a potential
configuration. At the Prague IETF, people asked for some more
motiviation and use cases for this feature before deciding whether we
should include it in the core capability negotiation framework or not. I
have written a short I-D in the subject, which you can find at:
 
 
http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdpcapneg-att-
del-00.txt
 
Please take a look at this and let me know how you think we should
resolve this issue. Options include:
 
A) Remove the ability to delete and replace attributes completely.
B) Remove the ability to delete and replace individual attributes, but
allow for complete removal of all attributes (clean slate)
C) Keep the current ability to delete and remove individual and all
attributes.
 
My personal preference is for option A, however in the interest of
moving forward and making a reasonable compromise between functionality
and complexity, my recommendation is option B.
 
Thanks
 
-- Flemming
 
 
 
 
 
 
 
 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
    
 
 
--------------030306040003010704010405-- --===============2012785359== 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 --===============2012785359==-- From mmusic-bounces@ietf.org Tue Jul 03 17:56: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 1I5qMS-0008Sp-Fs; Tue, 03 Jul 2007 17:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qMR-0008Sf-1z for mmusic@ietf.org; Tue, 03 Jul 2007 17:56:39 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5qMK-0003mh-LO for mmusic@ietf.org; Tue, 03 Jul 2007 17:56:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 03 Jul 2007 14:56:31 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAJZiikarR7PD/2dsb2JhbACIU6I3 X-IronPort-AV: i="4.16,494,1175497200"; d="scan'208"; a="6273737:sNHT24934902" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l63LuUuq027266; Tue, 3 Jul 2007 14:56:30 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l63LuPwB001374; Tue, 3 Jul 2007 21:56:30 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); Tue, 3 Jul 2007 14:56:25 -0700 Received: from [10.21.83.42] ([10.21.83.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 14:56:24 -0700 Message-ID: <468AC607.3010704@cisco.com> Date: Tue, 03 Jul 2007 17:56:23 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection References: <467FF858.6020503@cisco.com> <4682A52D.7020901@bbn.com> <4682A8B4.90401@cisco.com> <468A5563.1030602@bbn.com> In-Reply-To: <468A5563.1030602@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2007 21:56:25.0095 (UTC) FILETIME=[00114970:01C7BDBD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6608; t=1183499790; x=1184363790; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#9=3A=20Unknown=20attr ibutes=20and=20potential=0A=20configuration=20selection |Sender:=20; bh=YTesfRl1fiJu5CjnZ8ic5KvZsORruX6YxmYZvCJr+wg=; b=b3LNLbo9cbJoLgnz07rJqgHML88/fGhPCkT9WkwtVq8RFGi/agGXvML8e++jTlUFsfr2wKoI XzsxvXlhB8V5PGtbYaIxp8QscY9LRfEQsnHELqxsFvKFkobmXelUsJ+7; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Jonathan Lennox , mmusic 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 Matt Lepinski wrote: > Flemming, > > Thanks for the reply, I now see where the problem is with solution (2). > > Solution (4) seems like the best solution. (I guess it's more > convenient to mark my crypto attributes as mandatory than to mark all > of my rtpmaps as optional). > > It seems that in implementing Solution (4) there are two possibilities: > A) Mark the attributes as "optional" in the a=acap line > B) Mark the attributes as "optional" in the a=pcfg line > > Both of these options seem reasonable me. Agreed. > I guess (B) is probably perferred because it's more expressive. > (Although I'm not sure when you'd want an attribute to be optional in > one a=pcfg line and mandatory in another a=pcfg line). That's what I had in my mind too, although I have to admit that I'm struggling with use cases as well. Semantically, I think that whether a particular attribute needs to be supported or not is a feature of the potential configuration it is used in, not the attribute capability itself (after all, capabilities are just advertisements of things you can do, whereas potential configurations combine a set of capabilities to construct a meaningful offer SDP). Looking at the current popular use cases (SRTP), the attributes end up being mandatory all the time though. Taking another look at it and going through some examples, I now actually favor 3B (default being mandatory instead of optional as in 4B) since that is consistent with the way we use the transport protocol capability in the potential configuration (assumed behavior there is that you can only use a potential configuration if you support the transport protocol included in it, if any). For efficiency, and ease-of-human-parsing/debugging, I'd suggest a format as illustrated by the following example: a=pcfg a=1,2,[3,4]|2,7,[5] In the first alternative, attribute capabilities 1 and 2 are mandatory to support, whereas 3 and 4 are optional. In the second alternative, attribute capabilities 2 and 7 are mandatory to support whereas 5 is optional. Essentially, we'd have up to two lists of attribute capabilities in each alternative; the first one holds the mandatory ones and the second one the optional ones. Thanks -- Flemming > > - Matt Lepinski :-> > > Flemming Andreasen wrote: > >> >> >> Matt Lepinski wrote: >> >>> Flemming, >>> >>> I'm concerned that marking individual attributes within a potential >>> configuration as mandatory or optional will increase the perception >>> of complexity for SDP capability negotiation. Therefore, my >>> preference would be to avoid Options (3) and (4). >>> >>> Personally, I can't think of a use-case where the lack of >>> flexibility in Option (2) would cause signficant problems. >> >> How about rtpmaps mapping to an unsupported codec (which codec >> negotiation/standard 3264 procedures would have taken care of) ? It >> will be a quite common use case for the media capabilities extension. >> >>> Therefore, I'd favor Option (2). >>> >> Per the above, I think there are important use cases that will make >> this option problematic. >> >> -- Flemming >> >>> - Matt Lepinski :-> >>> >>> Flemming Andreasen wrote: >>> >>>> Jonathan Lennox had noted that the current potential configurationa >>>> algorithm combined with the standard SDP rules of ignoring unknown >>>> attributes, may lead an answerer to select a potential >>>> configuration with attributes it does not support, when the intent >>>> was to actually have the answerer select a potential configuration >>>> with attributes the answerer does support. Clearly, this does not >>>> produce the desired outcome. >>>> >>>> The reason for this is that we still use the standard SDP rules >>>> where we ignore unknown SDP attributes. >>>> >>>> The design team did not get a chance to discuss this issue in >>>> Prague, however there seems to be a few possible solutions to this >>>> one: >>>> >>>> 1) Continue with the current scheme, but allow the answerer to >>>> select only a potential configuration if the potential >>>> configuration makes sense and can be supported. This would ensure >>>> that any attributes that are required in order for a potential >>>> configuration to be used would have to be supported by the answerer >>>> in order for him to select that. For example, if the media stream >>>> is for SRTP, and the potential configuration specifies use of the >>>> "crypto" attribute for keying material, which the answerer didn't >>>> support, the answerer would move on to the next potential >>>> configuration (which could use a different keying mechanism). >>>> >>>> >>>> 2) Require that all attributes used by a potential configuration >>>> MUST be supported by the answerer in order for that potential >>>> configuration to be valid (and hence be able to be selected). An >>>> attribute is supported if both the attribute type and its value can >>>> be supported. This raises some potential ambiguity with payload >>>> types for example, where an rtpmap is both understood and >>>> supported, but the actual codec is not. >>>> >>>> 3) As 2), however allow for individual attribute capabilities to be >>>> marked as "optional" in a potential configuration. If an "optional" >>>> attribute capability is not supported by the answerer, the >>>> potential configuration would still be considered valid. >>>> >>>> 4) Similar to 3), except the default would be "optional", and we >>>> can mark certain attributes as mandatory. >>>> >>>> >>>> Option 1 seems flaky and is not recommended. >>>> Option 2 is simple to specify and use, however, as noted, it is not >>>> clear it has sufficient flexibility >>>> The recommendation here is for either option 3 or 4, with the >>>> choice depending on whether you believe optional or mandatory >>>> attributes are the more common use cases for SDP Capability >>>> Negotiation. >>>> >>>> My preference is for option 4. Compared to option 3, this option >>>> aligns slightly better with standard SDP as well, inasmuch as the >>>> default operation is normal SDP, and any changes from that requires >>>> an explicit indication (mandatory attribute). >>>> >>>> Please let me know if you disagree or have any comments on this. >>>> >>>> Thanks >>>> >>>> -- Flemming >>>> >>>> _______________________________________________ >>>> 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 Jul 03 18:20: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 1I5qjX-0004oU-B1; Tue, 03 Jul 2007 18:20:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qjV-0004hE-4g for mmusic@ietf.org; Tue, 03 Jul 2007 18:20:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5qiL-0008W5-1t for mmusic@ietf.org; Tue, 03 Jul 2007 18:20:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jul 2007 18:19:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADNoikZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,494,1175486400"; d="scan'208"; a="64305785:sNHT31512188" 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 l63MJGq4007065; Tue, 3 Jul 2007 18:19:16 -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 l63MJG6a019582; Tue, 3 Jul 2007 22:19:16 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, 3 Jul 2007 18:19:16 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 18:19:16 -0400 Message-ID: <468ACB67.5000809@cisco.com> Date: Tue, 03 Jul 2007 18:19:19 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jean-Francois Mule References: <9AAEDF491EF7CA48AB587781B8F5D7C62E9951@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9951@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2007 22:19:16.0066 (UTC) FILETIME=[313ADC20:01C7BDC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3418; t=1183501156; x=1184365156; 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=20Few=20comments=20on=20ICE-16 |Sender:=20 |To:=20Jean-Francois=20Mule=20; bh=6cdyQi2xfGUBOZ2oSXlHDDG8woabcYSCdfYZl6Rt44s=; b=UEPdh+eydR3zsr0EnqShWm3MadUDQD1kap56WPu4S83pzrNnNZfBUREl28zdwKeGdxdbmtEx ksXj/v99e3OBDxtAKWIxSoVDCWxgf0leUk23wyYRZf30+xbwupDRT9Cy; 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: a2c12dacc0736f14d6b540e805505a86 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Few comments on ICE-16 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: > Jonathan, > > Here are a few comments. > > - in 4.1.1.2., paragraph 2: > The current text puts 2 conditional MUSTs depending on the deployment > usage but does not clearly spell out what MUST be implemented and > configurable. > As you did in the first paragraph, it would be a plus to have a clear > requirement on what is RECOMMENDED for the agent to implement (SHOULD > for both STUN Allocate & Binding). Sorry - I'm not seeing what part of paragraph 2 is relevant here. Can you point it out? > > - re: the new formula for Ta: > I understand that this came out of the ICE pacing discussion and Dan's > proposal on the TSVWG list and following discussions but nonetheless, it > adds significant complexity. Yes. > 1) nit - while you point folks to read section B.1 for more details, it > is a bit opaque as presented. Adding one sentence around this formula's > goals (same bandwidth as RTP) or risks if implementers choose to > hardcode this as 20ms may help. OK. I added some text explaining that the purpose was to make the ICE checks take the same bandwidth as the media. > 2) what happens when you have a media stream being offered with a codec > and different ptimes supported (e.g. G.711, ptime=10, 20)? Should an > implementation should the default ptime for the codec or the ptime that > will result in the greater sum value? Ah, this is a good point. The Ta algorithm was primarily aimed at connectivity checks, where you have done the O/A exchange and thus know which codecs you are using. Here, when using it to pace gathering of candidates, you don't know yet. I think the right thing in this case would be to take the worst case and use that. > > - RTO: consider removing "/" from the formula Yeah - this is confusing. Its not division. Will fix. > > - what happens if an agent receives SDP with changes in the SDP that > would have required an ICE restart but the sending agent did not change > pwg/frag (not fully compliant or buggy implementation)? My general philosophy is to not specify in protocols behaviors when the other side has an implementation error. There are countless cases you could try and plan for. > Should it reject > the changes by sending an error response (which one)? or gracefully > assume a restart and proceed with an ICE restart? does this impact the > controlled/controlling role? > This could be clarified to handle the error case - may be it is and I > missed it. We should say nothing here. If an implementation can recover gracefully, excellent. Its a matter of local choice. > > - re: IPv6, the email I sent to the v6 list on 5/24 and copied you > Jonathan on asking for their review & guidance never made it to the v6 > list. I realized this today searching through the archive. I will update > it and resend - sorry about that. Given the changes though, getting more > eyeballs on the new text for dual-stack hosts will be a plus. Yes, I saw your note. 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 Tue Jul 03 18:22: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 1I5qls-0004gw-0G; Tue, 03 Jul 2007 18:22:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5qlq-0004Ri-0w for mmusic@ietf.org; Tue, 03 Jul 2007 18:22:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5qky-000155-2E for mmusic@ietf.org; Tue, 03 Jul 2007 18:22:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2007 18:21:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOZoikZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,494,1175486400"; d="scan'208"; a="125182374:sNHT556627284" 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 l63MLxEs024311; Tue, 3 Jul 2007 18:21:59 -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 l63MLr6s020185; Tue, 3 Jul 2007 22:21:59 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, 3 Jul 2007 18:21:37 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 18:21:36 -0400 Message-ID: <468ACBF3.30000@cisco.com> Date: Tue, 03 Jul 2007 18:21:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [MMUSIC] Few comments on ICE-16 References: <9AAEDF491EF7CA48AB587781B8F5D7C62E9951@srvxchg3.cablelabs.com> <090f01c7bada$9cfd20a0$a296150a@amer.cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C62E9985@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C62E9985@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2007 22:21:36.0674 (UTC) FILETIME=[8509F020:01C7BDC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3270; t=1183501319; x=1184365319; 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]=20Few=20comments=20on=20ICE-16 |Sender:=20 |To:=20Jean-Francois=20Mule=20; bh=BvwCkAdJEArmKz0WpfQVT2XvsBwz735M67YW2ASXYdY=; b=beYg4Rr0VIyS4fToh7f0t20Jicm35tVJH0BwlhO3+wZdzA1q8EqsuoW6WcQOW5AD/nz/31nH MS1IDsb6XLVHjodXL/NqkhD9eCmYZXIE6LxN46gnhMVnWgaN9fW+15u1; 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: 92df29fa99cf13e554b84c8374345c17 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. Jean-Francois Mule wrote: > Dan Wing wrote: >>> - re: the new formula for Ta: >>> I understand that this came out of the ICE pacing discussion and >> Dan's >>> proposal on the TSVWG list and following discussions but >>> nonetheless, it adds significant complexity. >> I don't believe it does; it merely defines a formula to calculate >> Ta and RTO, rather than using hard-coded values. The STUN state >> machine stays the same, and ICE and ICE's operation do not interfere >> with the STUN state machine or STUN timers due to this change. > > Ok, it is better than the hard-coded value given the intended benefits > but, as the ID is written, my understanding is that for each media > stream, the agent takes all the potential codecs to be offered, and for > all the associated ptimes, calculate the size of the RTP packet/stun to > compute Ta_i and for the sum. > May this is not "significant" given the benefits, but it still looks > more complex. > >>> 1) nit - while you point folks to read section B.1 for more >>> details, it >>> is a bit opaque as presented. Adding one sentence around this >>> formula's >>> goals (same bandwidth as RTP) or risks if implementers choose to >>> hardcode this as 20ms may help. >>> 2) what happens when you have a media stream being offered >>> with a codec >>> and different ptimes supported (e.g. G.711, ptime=10, 20)? Should an >>> implementation should the default ptime for the codec or the >>> ptime that will result in the greater sum value? >> It's impossible for the offerer to send a connectivity check until >> it receives the SDP answer (because until the answer arrives, it >> doesn't know the IP address and UDP port to send its connectivity >> checks to). When the answer arrives, the offerer will know which >> ptime to use. > Yes. > >> The RTO and Ta formulas are calculated at the time >> the answer is received (not when the offer is generated). > Well, nothing says so for Ta. The text in section 5.8 for RTO may > suggest that indeed but not for Ta. > > May be it was my sequential reading of the ID that made me believe that > at this point in the ICE text(4.1.x), the requirements are only about > gathering candidates. In section 5.8 (about scheduling checks), some > text even says: > | Ta is the same value used to > | pace the gathering of candidates, as described in Section 4.1.1. > > But no text actually forbids an agent to compute the Ta_i before SDP > negotiation as candidates are gathered. > May be the text for Ta should be moved or referenced elsewhere too > (section 6 and/or 9?). Actually, this is tricky since those values apply to both connectivity checks and to binding requests. There is no section currently common to both. I'm thinking of putting the formulas into an appendix, referenced from the main body. THis way the appendix can describe both cases. -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 Wed Jul 04 09:42: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 1I657v-0004Tz-7L; Wed, 04 Jul 2007 09:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I657t-0004RE-8I for mmusic@ietf.org; Wed, 04 Jul 2007 09:42:37 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I656r-0003Eo-CR for mmusic@ietf.org; Wed, 04 Jul 2007 09:42:37 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id l64DeRVA030779; Wed, 4 Jul 2007 15:40:27 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l64DeO4u025390; Wed, 4 Jul 2007 15:40:25 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 15:40:24 +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] SDPCapNeg Issue #9: Unknown attributes and potentialconfiguration selection Date: Wed, 4 Jul 2007 15:40:23 +0200 Message-ID: In-Reply-To: <468AC607.3010704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potentialconfiguration selection Thread-Index: Ace9vRHdA1TquGVtSI2Tou5ejMaoJwAgmdBw References: <467FF858.6020503@cisco.com> <4682A52D.7020901@bbn.com><4682A8B4.90401@cisco.com> <468A5563.1030602@bbn.com> <468AC607.3010704@cisco.com> From: "Stach, Thomas" To: "Flemming Andreasen" , "Matt Lepinski" X-OriginalArrivalTime: 04 Jul 2007 13:40:24.0321 (UTC) FILETIME=[DFAD4F10:01C7BE40] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070704154027-0AAFFBB0-2447AC37/0-0/0-15 X-purgate-size: 8042/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: Jonathan Lennox , mmusic 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 Flemming, I agree with your reasoning, that the a=3Dpcfg line should=20 declare what attributes are optional/mandatory for the=20 potential configuration. To have "mandatory" as default as for the transport=20 protocol makes sense as well. Your proposed syntax looks good too. Thanks=20 Thomas > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 > Sent: Tuesday, July 03, 2007 11:56 PM > To: Matt Lepinski > Cc: Jonathan Lennox; mmusic > Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes=20 > and potentialconfiguration selection >=20 >=20 >=20 > Matt Lepinski wrote: > > Flemming, > > > > Thanks for the reply, I now see where the problem is with=20 > solution (2). > > > > Solution (4) seems like the best solution. (I guess it's more=20 > > convenient to mark my crypto attributes as mandatory than=20 > to mark all=20 > > of my rtpmaps as optional). > > > > It seems that in implementing Solution (4) there are two=20 > possibilities: > > A) Mark the attributes as "optional" in the a=3Dacap line > > B) Mark the attributes as "optional" in the a=3Dpcfg line > > > > Both of these options seem reasonable me. > Agreed. > > I guess (B) is probably perferred because it's more expressive.=20 > > (Although I'm not sure when you'd want an attribute to be=20 > optional in=20 > > one a=3Dpcfg line and mandatory in another a=3Dpcfg line). > That's what I had in my mind too, although I have to admit that I'm=20 > struggling with use cases as well. Semantically, I think that=20 > whether a=20 > particular attribute needs to be supported or not is a feature of the=20 > potential configuration it is used in, not the attribute capability=20 > itself (after all, capabilities are just advertisements of things you=20 > can do, whereas potential configurations combine a set of=20 > capabilities=20 > to construct a meaningful offer SDP). Looking at the current=20 > popular use=20 > cases (SRTP), the attributes end up being mandatory all the=20 > time though. >=20 > Taking another look at it and going through some examples, I now=20 > actually favor 3B (default being mandatory instead of=20 > optional as in 4B)=20 > since that is consistent with the way we use the transport protocol=20 > capability in the potential configuration (assumed behavior there is=20 > that you can only use a potential configuration if you support the=20 > transport protocol included in it, if any). For efficiency, and=20 > ease-of-human-parsing/debugging, I'd suggest a format as=20 > illustrated by=20 > the following example: >=20 > a=3Dpcfg a=3D1,2,[3,4]|2,7,[5] >=20 > In the first alternative, attribute capabilities 1 and 2 are=20 > mandatory=20 > to support, whereas 3 and 4 are optional. In the second alternative,=20 > attribute capabilities 2 and 7 are mandatory to support whereas 5 is=20 > optional. Essentially, we'd have up to two lists of attribute=20 > capabilities in each alternative; the first one holds the=20 > mandatory ones=20 > and the second one the optional ones. >=20 > Thanks >=20 > -- Flemming >=20 > > > > - Matt Lepinski :-> > > > > Flemming Andreasen wrote: > > > >> > >> > >> Matt Lepinski wrote: > >> > >>> Flemming, > >>> > >>> I'm concerned that marking individual attributes within a=20 > potential=20 > >>> configuration as mandatory or optional will increase the=20 > perception=20 > >>> of complexity for SDP capability negotiation. Therefore, my=20 > >>> preference would be to avoid Options (3) and (4). > >>> > >>> Personally, I can't think of a use-case where the lack of=20 > >>> flexibility in Option (2) would cause signficant problems.=20 > >> > >> How about rtpmaps mapping to an unsupported codec (which codec=20 > >> negotiation/standard 3264 procedures would have taken care=20 > of) ? It=20 > >> will be a quite common use case for the media capabilities=20 > extension. > >> > >>> Therefore, I'd favor Option (2). > >>> > >> Per the above, I think there are important use cases that=20 > will make=20 > >> this option problematic. > >> > >> -- Flemming > >> > >>> - Matt Lepinski :-> > >>> > >>> Flemming Andreasen wrote: > >>> > >>>> Jonathan Lennox had noted that the current potential=20 > configurationa=20 > >>>> algorithm combined with the standard SDP rules of=20 > ignoring unknown=20 > >>>> attributes, may lead an answerer to select a potential=20 > >>>> configuration with attributes it does not support, when=20 > the intent=20 > >>>> was to actually have the answerer select a potential=20 > configuration=20 > >>>> with attributes the answerer does support. Clearly, this=20 > does not=20 > >>>> produce the desired outcome. > >>>> > >>>> The reason for this is that we still use the standard SDP rules=20 > >>>> where we ignore unknown SDP attributes. > >>>> > >>>> The design team did not get a chance to discuss this issue in=20 > >>>> Prague, however there seems to be a few possible=20 > solutions to this=20 > >>>> one: > >>>> > >>>> 1) Continue with the current scheme, but allow the answerer to=20 > >>>> select only a potential configuration if the potential=20 > >>>> configuration makes sense and can be supported. This=20 > would ensure=20 > >>>> that any attributes that are required in order for a potential=20 > >>>> configuration to be used would have to be supported by=20 > the answerer=20 > >>>> in order for him to select that. For example, if the=20 > media stream=20 > >>>> is for SRTP, and the potential configuration specifies=20 > use of the=20 > >>>> "crypto" attribute for keying material, which the=20 > answerer didn't=20 > >>>> support, the answerer would move on to the next potential=20 > >>>> configuration (which could use a different keying mechanism). > >>>> > >>>> > >>>> 2) Require that all attributes used by a potential configuration=20 > >>>> MUST be supported by the answerer in order for that potential=20 > >>>> configuration to be valid (and hence be able to be selected). An=20 > >>>> attribute is supported if both the attribute type and=20 > its value can=20 > >>>> be supported. This raises some potential ambiguity with payload=20 > >>>> types for example, where an rtpmap is both understood and=20 > >>>> supported, but the actual codec is not. > >>>> > >>>> 3) As 2), however allow for individual attribute=20 > capabilities to be=20 > >>>> marked as "optional" in a potential configuration. If an=20 > "optional"=20 > >>>> attribute capability is not supported by the answerer, the=20 > >>>> potential configuration would still be considered valid. > >>>> > >>>> 4) Similar to 3), except the default would be "optional", and we=20 > >>>> can mark certain attributes as mandatory. > >>>> > >>>> > >>>> Option 1 seems flaky and is not recommended. > >>>> Option 2 is simple to specify and use, however, as=20 > noted, it is not=20 > >>>> clear it has sufficient flexibility > >>>> The recommendation here is for either option 3 or 4, with the=20 > >>>> choice depending on whether you believe optional or mandatory=20 > >>>> attributes are the more common use cases for SDP Capability=20 > >>>> Negotiation. > >>>> > >>>> My preference is for option 4. Compared to option 3, this option=20 > >>>> aligns slightly better with standard SDP as well,=20 > inasmuch as the=20 > >>>> default operation is normal SDP, and any changes from=20 > that requires=20 > >>>> an explicit indication (mandatory attribute). > >>>> > >>>> Please let me know if you disagree or have any comments on this. > >>>> > >>>> Thanks > >>>> > >>>> -- Flemming > >>>> > >>>> _______________________________________________ > >>>> 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 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 05 11:16: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 1I6T44-0005Fj-8K; Thu, 05 Jul 2007 11:16:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6T3g-0004Oi-Pg; Thu, 05 Jul 2007 11:15:52 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6T3g-0001Ty-IR; Thu, 05 Jul 2007 11:15:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6327B2AC93; Thu, 5 Jul 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6T2s-0000WW-2E; Thu, 05 Jul 2007 11:15: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 Jul 2007 11:15:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.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 : The evaluation of different NAT traversal Techniques for media controlled by Real-time Streaming Protocol (RTSP) Author(s) : M. Westerlund Filename : draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Pages : 36 Date : 2007-7-5 This document describes several NAT traversal techniques that could be used by RTSP. Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP solution to standardize in the MMUSIC WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-00.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-rtsp-nat-evaluation-00.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-rtsp-nat-evaluation-00.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-7-5105258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-evaluation-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-evaluation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5105258.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 Jul 05 11:48: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 1I6TZ8-0003Ly-RB; Thu, 05 Jul 2007 11:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TPX-0006U0-LD for mmusic@ietf.org; Thu, 05 Jul 2007 11:38:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6TI9-0000WK-F8 for mmusic@ietf.org; Thu, 05 Jul 2007 11:31:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2007 11:30:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN6qjEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,503,1175486400"; d="scan'208"; a="64404222:sNHT30467504" 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 l65FUmiH005691 for ; Thu, 5 Jul 2007 11:30:49 -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 l65FUhsW027115 for ; Thu, 5 Jul 2007 15:30:48 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 Jul 2007 11:30:34 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:30:33 -0400 Message-ID: <468D0E9D.9040505@cisco.com> Date: Thu, 05 Jul 2007 11:30:37 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 15:30:33.0850 (UTC) FILETIME=[6DAD25A0:01C7BF19] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4284; t=1183649449; x=1184513449; 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:=20ICE-tcp=20proposed=20issue=20resolution=20for=20TLS=20then=20 STUN=20or=20STUN=20then=0A=20TLS |Sender:=20 |To:=20IETF=20MMUSIC=20WG=20; bh=txTMMPIVZ8UIsaNo3RXv7BqZMVUIFAe/DQxRnwBrkig=; b=0e5hKku/Rhj5J3RxA8+XhcSb3el9KplX3BD+e8gHd09PsSsNAnrGRijMSsAb95YdZIbY2i5e bHiP3locJ8xLKoyrejz64UOjKBg++ufeIqdlbgsSmr/fZfjHyJsE+KUv; 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: 5011df3e2a27abcc044eaa15befcaa87 Subject: [MMUSIC] ICE-tcp proposed issue resolution for TLS then STUN or STUN then TLS 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 working on a revision of ICE-tcp, which I hope to complete before the deadline this Monday. As folks may recall, the main outstanding issue is the question of "TLS then STUN" or "STUN then TLS". In particular, the question is whether, during ICE negotiations, you first do the STUN connectivity checks over the TCP connection, and then, once done, proceed with TLS ("STUN then TLS"). Or, once you open the TCP connection, do you immediately do TLS negotiations and then once those are done, begin STUN. We had a decent email thread on this in the beginning of April. There wasn't a clear consensus on it, though I think it weighed slightly in favor of "STUN then TLS". One of the things that came up during the discussion is that "STUN then TLS" will be faster, since it avoids the several-RTT TLS handshakes for connections which don't actually get connected or selected. With "STUN then TLS", you'll only end up doing the TLS handshakes once, for the selected candidate pair. Another issue that came up is that "STUN then TLS" matches how we are doing this for UDP, where STUN and DTLS are peers. THe main concern with "STUN then TLS" was its implementation complexity. I initially thought this would require custom TLS stacks in fact, but later it came out that most TLS stacks allow a socket abstraction and thus one could implement a socket abstraction that demuxed the STUN and TLS prior to feeding the TLS into the stack. So, based on all of this, my plan for the next revision is to specify "STUN then TLS". In particular, the stack is going to be: Please view in a fixed-width font such as Courier. +-----------+ | App | | | +----------+-----------+ | | | | STUN | TLS | +----------+-----------+ | | | cotrans shim | +----------------------+ | | | TCP | +----------------------+ | | | IP | +----------------------+ The cotrans shim is RFC 4571. This is a trivial shim that simply defines a length field for framing. Though its defined for RTP it is not RTP specific at all and you could use it with anything. ICE-tcp has, for a few revisions, required this shim for any application protocol, not just RTP. So, during ICE, you'll establish the TCP handshake and run STUN checks over the shim. Once ICE is done, and the USE-CANDIDATE flag has been sent in a STUN message sent over that shimmed TCP connection, TLS procedures start ontop of the same shim. Once the TLS is established, the app runs ontop of the TLS session. In terms of keepalives, the current ICE text as defined still applies; STUN (outside of the TLS) is recommended. But you can use something at the app layer if you want. It had been suggested during the email thread that we could run STUN and TLS as peers only initially, and then once TLS is established run the shim and STUN over TLS. I think this is massively confusing, since we are doing things at multiple layers. You'd need to synchronize this change through something like a STARTTLS mechanism and that adds more roundtrips. I don't see the benefit. In terms of who sends the ClientHello, I am thinking of using the RFC4145 attributes for this, but with ICE-tcp they EXCLUSIVELY indicate the TLS directionality. TCP directionality is determined by the ICE parameters. Given the proximity to the deadline I doubt there will be much discussion or time to disagree before the the deadline arrives. Thats fine, we can always change it. I am hoping to use the time between now and the meeting, and the time at the meeting itself, to conclude on this, and so we can finish this spec. 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 Jul 05 18:36: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 1I6ZhA-0001w3-4D; Thu, 05 Jul 2007 18:21:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Zh6-0001rm-0d for mmusic@ietf.org; Thu, 05 Jul 2007 18:21:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Zh4-0006ma-NY for mmusic@ietf.org; Thu, 05 Jul 2007 18:20:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 18:20:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALwLjUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125321663:sNHT30051530" 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 l65MKwIp027724; Thu, 5 Jul 2007 18:20:58 -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 l65MKws0025736; Thu, 5 Jul 2007 22:20: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); Thu, 5 Jul 2007 18:20:58 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:20:57 -0400 Message-ID: <468D6ECD.80108@cisco.com> Date: Thu, 05 Jul 2007 18:21:01 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 22:20:57.0650 (UTC) FILETIME=[C29AD920:01C7BF52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2801; t=1183674058; x=1184538058; 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:=20ICE-tcp=20implementation=20concerns |Sender:=20 |To:=20IETF=20MMUSIC=20WG=20; bh=Jymp86bjmwFLb8nuf0p5OfUDrfpH0QnIUAIvI4Tm6O8=; b=SJeEENTPrmtMd6iwMuXf8sI80M7eGRscXONVLx/eHgGF/DUmbDMKXD+6YM2CZqZaDEAw1R/5 aMe/aic7oA2YypCTOpr2sUt+8m9pUbryKnXnwbgzDbEtfg5mIfTHOQMG; 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: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Saikat Guha Subject: [MMUSIC] ICE-tcp implementation concerns 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 Most folks probably missed this, but deep within one of the threads on core ICE, was an important issue raised by Guylain Lavoie. With ICE-tcp, if you have passive or SO candidates, the basic sequence of events is as follows: 1. open a tcp connection to your stun server 2. send Binding Request, learn a mapped address A:B 3. send an INVITE with A:B as a passive or SO candidate 4. be prepared to receive TCP incoming connection requests on the IP and port from which you connected to the STUN server Guylain had indicated that, with BSD sockets at least, this could not be implemented. He said: > 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. If this is true, it would mean that ICE-tcp is basically useless. That would be bad. However, this same problem would exist in any solution for direct tcp through NAT (STUNT for example), so it didn't seem right. I sent a note to Saikat Guha, and got the following reply: > The following (preudo) code works, and has been tested to do TCP > traversal on Windows, Linux and OSX: > > for i in 1 to 100 > sock_i = socket() > set(sock_i, SO_REUSEPORT) > bind(sock_i, local) > > listen(sock_0) > connect(sock_1, stun) > connect(sock_2, remote_a) > connect(sock_3, remote_b) > ... > > The key thing is that all the sockets must be bound to the local port > before listen is called. So the pool of potential sockets to use for > ICE-TCP would need to be pre-allocated. Once you exhaust the pool, a > whole new pool needs to be created (with its own listen socket, and N > connect sockets). So, it seems this can be made to work, though its a bit awkward. But, such is the penalty. I don't think there is really an alternative. However I wanted to invite comments on this. I think it might be useful having an informational appendix in ice-tcp which mentions this issue. Otherwise this is going to be a huge problem for implementors. -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 Jul 05 23:05: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 1I6e8D-0006GG-4o; Thu, 05 Jul 2007 23:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6e8C-0006Fa-0J for mmusic@ietf.org; Thu, 05 Jul 2007 23:05:16 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6e87-0005TD-Kc for mmusic@ietf.org; Thu, 05 Jul 2007 23:05:15 -0400 Content-class: urn:content-classes:message Subject: RE: [MMUSIC] ICE-tcp implementation concerns Date: Thu, 5 Jul 2007 23:05:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <6EF4CC794ECF2B409390605FDEA9012225B3B6@m5tmail1.m5t.com> In-Reply-To: <468D6ECD.80108@cisco.com> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-tcp implementation concerns Thread-Index: Ace/VNLyvMRM4FvqRkiAVVcyr0P2YAAIux0g From: "Guylain Lavoie" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Saikat Guha 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, Frankly, I am very happy to learn that there is finally one way to make this work, albeit not very obvious. The effort deployed for this document will not have been done in vain. Having to implement our ICE stack for many platforms, I was beginning to be a bit worried about how we could manage to make this work. Thank you for this information. You are right, adding an appendix to explain this is a very good idea. Best Regards, Guylain -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: July 5, 2007 6:21 PM To: IETF MMUSIC WG Cc: Saikat Guha Subject: [MMUSIC] ICE-tcp implementation concerns Most folks probably missed this, but deep within one of the threads on core ICE, was an important issue raised by Guylain Lavoie. With ICE-tcp, if you have passive or SO candidates, the basic sequence of events is as follows: 1. open a tcp connection to your stun server 2. send Binding Request, learn a mapped address A:B 3. send an INVITE with A:B as a passive or SO candidate 4. be prepared to receive TCP incoming connection requests on the IP and port from which you connected to the STUN server Guylain had indicated that, with BSD sockets at least, this could not be implemented. He said: > 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=20 > and Windows). The only way to achieve this is by binding two sockets=20 > to the exact same address/port and this required special support from=20 > the OS (SO_REUSEPORT and/or SO_REUSEADDR combinason). From what I=20 > read, the needed fonctionality is not available on Linux. You are=20 > right that at the TCP level, nothing should prevent us from doing this. > However, it's the API level that does not follow. If this is true, it would mean that ICE-tcp is basically useless. That would be bad. However, this same problem would exist in any solution for direct tcp through NAT (STUNT for example), so it didn't seem right. I sent a note to Saikat Guha, and got the following reply: > The following (preudo) code works, and has been tested to do TCP=20 > traversal on Windows, Linux and OSX: >=20 > for i in 1 to 100 > sock_i =3D socket() > set(sock_i, SO_REUSEPORT) > bind(sock_i, local) >=20 > listen(sock_0) > connect(sock_1, stun) > connect(sock_2, remote_a) > connect(sock_3, remote_b) > ... >=20 > The key thing is that all the sockets must be bound to the local port=20 > before listen is called. So the pool of potential sockets to use for=20 > ICE-TCP would need to be pre-allocated. Once you exhaust the pool, a=20 > whole new pool needs to be created (with its own listen socket, and N=20 > connect sockets). So, it seems this can be made to work, though its a bit awkward. But, such is the penalty. I don't think there is really an alternative.=20 However I wanted to invite comments on this. I think it might be useful having an informational appendix in ice-tcp which mentions this issue. Otherwise this is going to be a huge problem for implementors. -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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 06 02:19: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 1I6hA9-0004LM-52; Fri, 06 Jul 2007 02:19:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hA7-0004L6-Cc for mmusic@ietf.org; Fri, 06 Jul 2007 02:19:27 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6hA6-0007Xf-Uk for mmusic@ietf.org; Fri, 06 Jul 2007 02:19:27 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l666IsOo003802; Fri, 6 Jul 2007 09:19:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:19:02 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:19:02 +0300 Received: from hed050127.research.nokia.com ([172.21.50.127]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:19:02 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org, "ext Jonathan Rosenberg" Subject: Re: [MMUSIC] ICE-tcp proposed issue resolution for TLS then STUN or STUN then TLS Date: Fri, 6 Jul 2007 09:18:56 +0300 User-Agent: KMail/1.9.6 References: <468D0E9D.9040505@cisco.com> In-Reply-To: <468D0E9D.9040505@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707060918.56855.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 06 Jul 2007 06:19:02.0552 (UTC) FILETIME=[8C238980:01C7BF95] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Hello, I also vaguely recall some people complaining that embedded devices would h= ave=20 a hard time generating crypto-parameters for more TLS sessions than needed = in=20 TLS then STUN case. Anyway... On Thursday 05 July 2007 18:30:37 ext Jonathan Rosenberg wrote: > The cotrans shim is RFC 4571. This is a trivial shim that simply defines > a length field for framing. Though its defined for RTP it is not RTP > specific at all and you could use it with anything. ICE-tcp has, for a > few revisions, required this shim for any application protocol, not just > RTP. I must have forgotten something, but why would ICE-TLS need a shim of ICE-T= CP=20 does not? or if you prefer: how come ICE-TCP can do without shim and ICE-TL= S=20 cannot? Also, if both TCP and TLS used the same shim/non-shim/whatever, there would= be=20 essentially no need for specifying TLS at all (it would just be part of the= =20 application layer from STUN/ICE perspective) - with the exception of=20 specifying who sends ClientHello. (...) > In terms of keepalives, the current ICE text as defined still applies; > STUN (outside of the TLS) is recommended. But you can use something at > the app layer if you want. It had been suggested during the email thread > that we could run STUN and TLS as peers only initially, and then once > TLS is established run the shim and STUN over TLS. I think this is > massively confusing, since we are doing things at multiple layers. Yes, sounds very confusing to me too. > In terms of who sends the ClientHello, I am thinking of using the > RFC4145 attributes for this, but with ICE-tcp they EXCLUSIVELY indicate > the TLS directionality. TCP directionality is determined by the ICE > parameters. Yes. I suppose COMEDIA attributes will also be used as default if the answe= rer=20 does not support ICE-TCP. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 06 02:43: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 1I6hXb-0002Wq-4S; Fri, 06 Jul 2007 02:43:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hXZ-0002Uz-G8 for mmusic@ietf.org; Fri, 06 Jul 2007 02:43:41 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6hXZ-0000cF-10 for mmusic@ietf.org; Fri, 06 Jul 2007 02:43:41 -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 l666hQBY010600; Fri, 6 Jul 2007 09:43:30 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:43:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:43:27 +0300 Received: from hed050127.research.nokia.com ([172.21.50.127]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:43:27 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org, magnus.westerlund@ericsson.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Date: Fri, 6 Jul 2007 09:43:21 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707060943.21697.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 06 Jul 2007 06:43:27.0761 (UTC) FILETIME=[F578B010:01C7BF98] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Hello, The "embedded STUN" case is currently defined to use two SETUPs... Couldn't= =20 the server authenticate the client directly from the USERNAME and=20 MESSAGE-INTEGRITY parameter of the incoming STUN Binding Discovery (much li= ke=20 ICE does, in fact)? Also, it is noted that it mostly does not work for multi-homed NATs. Though= =20 first, multi-homed NATs would normally use the mapped source address toward= a=20 given external address (otherwise just about how many web application using= =20 IP address has part of their session authentication would already break?).= =20 Secondly, the RTSP server will need to be modified to embed a STUN server=20 anyway, so it should not be too much to ask that when STUN is used, differe= nt=20 IP addresses can be used for different media streams. That being said, I suppose the Symmetric RTP *variant* looks better anyway. Regards, =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 06 02:45: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 1I6hZU-0008K4-Rl; Fri, 06 Jul 2007 02:45:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6hZT-0008Jy-5n for mmusic@ietf.org; Fri, 06 Jul 2007 02:45:39 -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 1I6hZO-0002ur-Mf for mmusic@ietf.org; Fri, 06 Jul 2007 02:45:39 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l666jWIj013239 for ; Fri, 6 Jul 2007 09:45:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:45:29 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:45:30 +0300 Received: from hed050127.research.nokia.com ([172.21.50.127]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 09:45:29 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org Subject: Re: [MMUSIC] ICE-tcp implementation concerns Date: Fri, 6 Jul 2007 09:45:24 +0300 User-Agent: KMail/1.9.6 References: <468D6ECD.80108@cisco.com> In-Reply-To: <468D6ECD.80108@cisco.com> MIME-Version: 1.0 Content-Disposition: inline X-UID: 305 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200707060945.24675.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 06 Jul 2007 06:45:29.0965 (UTC) FILETIME=[3E4F89D0:01C7BF99] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Friday 06 July 2007 01:21:01 ext Jonathan Rosenberg wrote: > sent a note to Saikat Guha, and got the following reply: > > The following (preudo) code works, and has been tested to do TCP > > traversal on Windows, Linux and OSX: > > > > for i in 1 to 100 > > sock_i =3D socket() > > set(sock_i, SO_REUSEPORT) > > bind(sock_i, local) > > > > listen(sock_0) > > connect(sock_1, stun) > > connect(sock_2, remote_a) > > connect(sock_3, remote_b) > > ... Unlikely to work as is. Linux nor Windows even define SO_REUSEPORT at all.= =20 Supposedly, that would rather be SO_REUSEADDR on every platform, and=20 SO_REUSEPORT in addition for BSDs... I'll have a look. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 06 08:54: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 1I6nKW-00069o-F6; Fri, 06 Jul 2007 08:54:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6nKU-00065I-MU for mmusic@ietf.org; Fri, 06 Jul 2007 08:54:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6nKU-0007Tq-Cn for mmusic@ietf.org; Fri, 06 Jul 2007 08:54:34 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2007 05:54:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI7YjUarR7MVZmdsb2JhbACPNAsO X-IronPort-AV: i="4.16,508,1175497200"; d="scan'208"; a="165851039:sNHT33747345" 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 l66CsP3x015646; Fri, 6 Jul 2007 05:54:25 -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 l66CsPmo028985; Fri, 6 Jul 2007 12:54:25 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, 6 Jul 2007 05:54:25 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 05:54:25 -0700 Message-ID: <468E3B84.2030402@cisco.com> Date: Fri, 06 Jul 2007 08:54:28 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [MMUSIC] ICE-tcp proposed issue resolution for TLS then STUN or STUN then TLS References: <468D0E9D.9040505@cisco.com> <200707060918.56855.remi.denis-courmont@nokia.com> In-Reply-To: <200707060918.56855.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Jul 2007 12:54:25.0275 (UTC) FILETIME=[C7FBCCB0:01C7BFCC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2731; t=1183726465; x=1184590465; 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-tcp=20proposed=20issue=20resolution=20 for=20TLS=20then=20STUN=0A=20or=20STUN=20then=20TLS |Sender:=20; bh=yaOOZhFf+uL1vjvslmK6xUMNZjhE93eoITs4fqCXxLQ=; b=MOhJazFT/XJcXDov5No6czu9M9wmgzTxCyjbxIRK2C2hLi9ZDZtkg/NAELSXlHcZ8ylAPu/z k2s/TB5ywL1DMP8XeV/hY6cctmnGsviYpmg/y5o6QWSWPuw2Lrg2N6vek6BPdElNjz8brc5g13 KlkIWEzy9A0Ado9XU6cbF3stQ=; 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: 41c17b4b16d1eedaa8395c26e9a251c4 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 Rémi Denis-Courmont wrote: > Hello, > > I also vaguely recall some people complaining that embedded devices would have > a hard time generating crypto-parameters for more TLS sessions than needed in > TLS then STUN case. > > Anyway... > > On Thursday 05 July 2007 18:30:37 ext Jonathan Rosenberg wrote: >> The cotrans shim is RFC 4571. This is a trivial shim that simply defines >> a length field for framing. Though its defined for RTP it is not RTP >> specific at all and you could use it with anything. ICE-tcp has, for a >> few revisions, required this shim for any application protocol, not just >> RTP. > > I must have forgotten something, but why would ICE-TLS need a shim of ICE-TCP > does not? or if you prefer: how come ICE-TCP can do without shim and ICE-TLS > cannot? It does have a shim, the same one. > > Also, if both TCP and TLS used the same shim/non-shim/whatever, there would be > essentially no need for specifying TLS at all (it would just be part of the > application layer from STUN/ICE perspective) - with the exception of > specifying who sends ClientHello. And that you need to use TLS, yes. But overall the interaction with ICE is minimal when its structured this way. > > (...) >> In terms of keepalives, the current ICE text as defined still applies; >> STUN (outside of the TLS) is recommended. But you can use something at >> the app layer if you want. It had been suggested during the email thread >> that we could run STUN and TLS as peers only initially, and then once >> TLS is established run the shim and STUN over TLS. I think this is >> massively confusing, since we are doing things at multiple layers. > > Yes, sounds very confusing to me too. > >> In terms of who sends the ClientHello, I am thinking of using the >> RFC4145 attributes for this, but with ICE-tcp they EXCLUSIVELY indicate >> the TLS directionality. TCP directionality is determined by the ICE >> parameters. > > Yes. I suppose COMEDIA attributes will also be used as default if the answerer > does not support ICE-TCP. > Exactly. So, if the peer is not ICE capable but using comedia, then the comedia attributes signal BOTH TCP and TLS directionality. If the peer is ICE capable, the comedia attributes signal TLS directionality only. TCP directionality is determined by the ICE parameters. -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 Jul 06 09:16: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 1I6nfa-0005JE-2F; Fri, 06 Jul 2007 09:16:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6nfY-0005Iv-E8 for mmusic@ietf.org; Fri, 06 Jul 2007 09:16:20 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6nfY-0008SK-4K for mmusic@ietf.org; Fri, 06 Jul 2007 09:16:20 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JKR0031YE5YOY@siemenscomms.co.uk> for mmusic@ietf.org; Fri, 06 Jul 2007 14:15:34 +0100 (BST) Date: Fri, 06 Jul 2007 14:15:45 +0100 From: "Elwell, John" To: Jonathan Rosenberg , mmusic Message-id: <0D5F89FAC29E2C41B98A6A762007F5D020539B@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: ICE lite - comment on gathering candidates at answerer (section 5.3) Thread-Index: Ace/z8Mu/xljqZTJRHuKYkMusSZ98g== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [MMUSIC] ICE lite - comment on gathering candidates at answerer (section 5.3) 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, "The process for gathering candidates at the answerer is identical to the process for the offerer as described in Section 4.1.1 for full implementations and Section 4.2 for lite implementations. It is RECOMMENDED that this process begin immediately on receipt of the offer, prior to alerting the user. Such gathering MAY begin when an agent starts." I think considerations for lite implementations are slightly different when the offerer is also lite. It would be advantageous for the answerer to choose just a single candidate that is compatible with one of the candidates in the offer. In this way it would be safe to override the recommendation to delay alerting. Alerting can take place, with the knowledge that when the user answers (or when early media is sent) media can be sent to the matching candidate from the offer. If alerting takes place but the answerer has submitted several candidates and not made a selection, it is unable to send early media or media when the user answers, unless a further offer has been received in an UPDATE request. Therefore clipping is likely to occur. If alerting does not commence at this point, the answerer will need to wait for another offer in an UPDATE request on the early dialog. This in turns means that 100rel/PRACK has to be used, which is something that we took a decision to avoid way back. For full ICE (including full-lite interworking) successful connectivity checks are the trigger to start alerting, but these do not occur with lite-lite working. So I would suggest the addition of the following words: "When both the offerer and the answerer are lite implementations, the answerer MAY gather just a single candidate that is compatible with one of the candidates in the offer and alert the user immediately. In this case it can assume that the offerer will select the compatible candidate and that media can be sent to that candidate without waiting for a further offer." In addition, I think the answerer would need to place the sole candidate pair into the Valid List when it sends this first SDP answer, in order to allow media to flow before the second offer arrives. I defer to your judgement as to which words need changing to reflect this. John _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 06 09:17:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ngQ-0006eC-Qv; Fri, 06 Jul 2007 09:17:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ngP-0006e6-BZ for mmusic@ietf.org; Fri, 06 Jul 2007 09:17:13 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6ngO-0008Tl-V7 for mmusic@ietf.org; Fri, 06 Jul 2007 09:17:13 -0400 Content-class: urn:content-classes:message Subject: RE: [MMUSIC] ICE-tcp implementation concerns MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jul 2007 09:16:37 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012225B3E8@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012225B3B6@m5tmail1.m5t.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE-tcp implementation concerns Thread-Index: Ace/VNLyvMRM4FvqRkiAVVcyr0P2YAAIux0gABVZPiA= From: "Guylain Lavoie" To: "Jonathan Rosenberg" , "IETF MMUSIC WG" , "Eric Tremblay" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Hi Jonathan, While thinking about this, I found one additional thing that you should add to your appendix. As I said, the technique is not obvious, but if it works, the implementation should be doable without to much sacrifice on the architecture. However, while thinking more about binding all those sockets at once, I stumble upon one less trivial issue. I am thinking about SIP forking where additional sockets will need to be bound much later in the process. We will need to create a poll of sockets already bound to the same port and use them later if there is forking. For example, we could bind a certain amount of additional sockets, that may not be sufficient or may be way too much, wasting valuable resources. This problem does not affect Active candidates because the port is not important. Neither does it affect Passive candidates because we are listening of the socket and one server socket is enough for this purpose. The issue show up with the SO candidates. This issue will have a much bigger impact on the implementation architecture and than I originally thought, at least in our implementation.=20 It would be good to discuss this also in the appendix. Best Regards, Guylain Guylain Lavoie Technical Product Manager M5T, a Division of Media5 Corporation Web: http://www.m5t.com Email: glavoie@m5t.com Tel: +1-819-829-1008, ext: 662 Fax: +1-819-829-1342 -----Original Message----- From: Guylain Lavoie [mailto:glavoie@m5t.com]=20 Sent: July 5, 2007 11:05 PM To: Jonathan Rosenberg; IETF MMUSIC WG Cc: Saikat Guha Subject: RE: [MMUSIC] ICE-tcp implementation concerns Hi Jonathan, Frankly, I am very happy to learn that there is finally one way to make this work, albeit not very obvious. The effort deployed for this document will not have been done in vain. Having to implement our ICE stack for many platforms, I was beginning to be a bit worried about how we could manage to make this work. Thank you for this information. You are right, adding an appendix to explain this is a very good idea. Best Regards, Guylain -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: July 5, 2007 6:21 PM To: IETF MMUSIC WG Cc: Saikat Guha Subject: [MMUSIC] ICE-tcp implementation concerns Most folks probably missed this, but deep within one of the threads on core ICE, was an important issue raised by Guylain Lavoie. With ICE-tcp, if you have passive or SO candidates, the basic sequence of events is as follows: 1. open a tcp connection to your stun server 2. send Binding Request, learn a mapped address A:B 3. send an INVITE with A:B as a passive or SO candidate 4. be prepared to receive TCP incoming connection requests on the IP and port from which you connected to the STUN server Guylain had indicated that, with BSD sockets at least, this could not be implemented. He said: > 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=20 > and Windows). The only way to achieve this is by binding two sockets=20 > to the exact same address/port and this required special support from=20 > the OS (SO_REUSEPORT and/or SO_REUSEADDR combinason). From what I=20 > read, the needed fonctionality is not available on Linux. You are=20 > right that at the TCP level, nothing should prevent us from doing this. > However, it's the API level that does not follow. If this is true, it would mean that ICE-tcp is basically useless. That would be bad. However, this same problem would exist in any solution for direct tcp through NAT (STUNT for example), so it didn't seem right. I sent a note to Saikat Guha, and got the following reply: > The following (preudo) code works, and has been tested to do TCP=20 > traversal on Windows, Linux and OSX: >=20 > for i in 1 to 100 > sock_i =3D socket() > set(sock_i, SO_REUSEPORT) > bind(sock_i, local) >=20 > listen(sock_0) > connect(sock_1, stun) > connect(sock_2, remote_a) > connect(sock_3, remote_b) > ... >=20 > The key thing is that all the sockets must be bound to the local port=20 > before listen is called. So the pool of potential sockets to use for=20 > ICE-TCP would need to be pre-allocated. Once you exhaust the pool, a=20 > whole new pool needs to be created (with its own listen socket, and N=20 > connect sockets). So, it seems this can be made to work, though its a bit awkward. But, such is the penalty. I don't think there is really an alternative.=20 However I wanted to invite comments on this. I think it might be useful having an informational appendix in ice-tcp which mentions this issue. Otherwise this is going to be a huge problem for implementors. -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 _______________________________________________ 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 Jul 06 12:55: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 1I6r5t-0006U5-6f; Fri, 06 Jul 2007 12:55:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6r5r-0006Hq-PG for mmusic@ietf.org; Fri, 06 Jul 2007 12:55:43 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6r5r-0003sc-HT for mmusic@ietf.org; Fri, 06 Jul 2007 12:55:43 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 06 Jul 2007 09:55:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIcQjkarR7PDh2dsb2JhbACPNAEBCQ4s X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="384052392:sNHT25147960" 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 l66GtY19002786; Fri, 6 Jul 2007 09:55:34 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l66GtYmo002523; Fri, 6 Jul 2007 16:55:34 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , , Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Date: Fri, 6 Jul 2007 09:55:33 -0700 Message-ID: <10d301c7bfee$78622c90$e171150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Ace/mQZNMNyJUA3EQ02+ht33wlsmxgAVOumw In-Reply-To: <200707060943.21697.remi.denis-courmont@nokia.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=724; t=1183740934; x=1184604934; 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=20[MMUSIC]=20I-D=20ACTION=3Adraft-ietf-mmusic-rtsp-nat- evaluation-00.txt |Sender:=20; bh=sddpRM6I42TPS2BrbdEh8kEc2chUjepjp3kEwMAkWqg=; b=Q76fS3Nmw6HrIBTOGaCUHyy4Z4HZKdb1ciYtR+ukc+k+Ulked8wV5bGghPSVA8aTDfUB7Gwk Gaq26wPuH3KhgptZyblaHfr1SUMQ6DZBSDLQ4ZUwAeDAAJ9FAgY2x+ar; 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: d6b246023072368de71562c0ab503126 Cc: thomas.zeng@gmail.com 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 > That being said, I suppose the Symmetric RTP *variant* looks > better anyway. The Symmetric RTP Variant does look better, but it doesn't work if the media server (RTSP server) is behind its own NAT -- such as, for example, you are visiting Grandma's house (which has its own NAT) and you want to interact with your media player at your house (which has its own NAT). The Symmetric RTP Variant is very similar to ICE-Lite, as defined in the last few iterations of ICE. I would really like the RTSP NAT Evaluation document to include an additional requirement for 'both RTSP server and RTSP client behind their own NATs' to its matrix in section 6, "Comparision of NAT traversal techniques". -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 06 16:20: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 1I6uHw-0007e3-Pf; Fri, 06 Jul 2007 16:20:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uHu-0007aV-AE for mmusic@ietf.org; Fri, 06 Jul 2007 16:20:22 -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 1I6uHp-0003NB-TP for mmusic@ietf.org; Fri, 06 Jul 2007 16:20:22 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2007 13:20:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFZAjkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="500798776:sNHT118983592" 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 l66KKGcI032095 for ; Fri, 6 Jul 2007 13:20:16 -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 l66KK2n6007944 for ; Fri, 6 Jul 2007 20:20:16 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); Fri, 6 Jul 2007 13:20:10 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:20:09 -0700 Message-ID: <468EA3FD.3020307@cisco.com> Date: Fri, 06 Jul 2007 16:20:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 20:20:09.0978 (UTC) FILETIME=[0D119DA0:01C7C00B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1629; t=1183753216; x=1184617216; 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:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY] |Sender:=20; bh=/a2gGbj9z3uAeaOyVraQo7NcVcWVa35n/rdAvyWYEgQ=; b=Alg8YVER7MsVcy2HxlB/Jz6m4i4C2PLQ/CpBfnG9odpZhIDlV7F+80pxmwSX2FK6wslCVXv3 +LW2ffric/7fWtvWVADefSIb1QhupPkLYtz9RscOTxddiAbub6tc6pa7; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [MMUSIC] ICE tutorial in Chicago [DO NOT REPLY] 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 (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- 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 Jul 06 17:54: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 1I6vkq-0007yG-RY; Fri, 06 Jul 2007 17:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vkp-0007yB-LM for mmusic@ietf.org; Fri, 06 Jul 2007 17:54:19 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6vkl-0005Fj-Cr for mmusic@ietf.org; Fri, 06 Jul 2007 17:54:19 -0400 Received: by an-out-0708.google.com with SMTP id c17so74095anc for ; Fri, 06 Jul 2007 14:54:15 -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=UFFqA8ja4DKlUQ2lNQgobkcIs1rJMpokBVrnCJqQNaizfBSiEO0+Ca2p7IYKeWBhlEjC+nI+k3Zo8BORbkuXSsJwg53r18+n6YQOw9FOzRzfNocnC/azFQ9t9a3oB/IOkVM/KWyIlIXkWAtR3Z2/GPc/QbHA8/9K5pKOAyH6VbM= 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=GJAUjqJikttXUXfQ/nX7WRVeiJ0f2PC0lpP3uCv5+Qn0MdL1fEnJ59rJ9T75ACwEZZZzBxtXZuBsRjVLPpIKDhUgJywW/xNIIS0awYljacn5Q1GlcHMYNHLcrCJGCvVNvWTvsve7Hk/GsMP/qBxFiQwTxmO6avJ5VtJzBl94rDI= Received: by 10.100.106.5 with SMTP id e5mr528801anc.1183758854771; Fri, 06 Jul 2007 14:54:14 -0700 (PDT) Received: by 10.100.189.2 with HTTP; Fri, 6 Jul 2007 14:54:14 -0700 (PDT) Message-ID: <458913680707061454j75a8f789l868ad7042c4addb6@mail.gmail.com> Date: Fri, 6 Jul 2007 23:54:14 +0200 From: "Xavier Marjou" To: magnus.westerlund@ericsson.com, thomas.zeng@gmail.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt In-Reply-To: <10d301c7bfee$78622c90$e171150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707060943.21697.remi.denis-courmont@nokia.com> <10d301c7bfee$78622c90$e171150a@amer.cisco.com> X-Google-Sender-Auth: 4b992a2851204254 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Som few comments: Section 3. Requirements : - The requirements section should also briefly mentions media transport, possibly with a requirement like: "the solution MUST allow delivery of data over TCP as well as data over UDP". Otherwise, if RTP/UDP is not required, a compelling solution with regards to the current requirements is probably the TCP tunneling solution. - I also support Dan's request to add a requirement where "both the RTSP client and RTSP server are behind their own NAT" Section 4.2. ICE : - The abstract of draft-ietf-mmusic-ice mentions that "ICE can be used by any protocol utilizing the offer/answer model". The direction taken by this section shows that RTSP specifications would end-up with a sort of 2nd offer/answer model very similar to RFC3264. The similarities will be that candidates will be exchanges in controlling messages... However, there will be some slight differences: for example in SIP all media are advertised within the same message, whereas in RTSP one message will be needed per media. Another drawback for 4.2.3 is thus ICE will need to be extended to discuss this specificities. - I also anticipate that if we go towards this direction in the future, an RTSP "server" located behind a NAT will probably need to register to a public proxy and maintain an outbound connection. Section 4.X. New Section? - Based on what I've said before, I think we need to at least mention the solution "SIP+ICE+RTSP". We know there are some drawbacks with the current version of RTSP (transport parameters carried within some RTSP messages ...), but there are also some advantages: - no need to redefine another offer/answer, another outbound-connection ... - allow for the requirement where "both RTSP client and RTSP server are behind their own NAT" - If such a new 4.X section is added, rename section 4.2 "ICE" into "ICE in RTSP". Section 6: - Add TCP tunneling in the table NITS: - replace TURN by STUN Relay within the document - page 3: s/evualation/evalution/ - page 3: s/shoulb/should/ - page 13: s/frist/first/ - page 20: Section Symmetric RTP: add ref on draft-wing-behave-symmetric-rtprtcp - page 29: s/RTSP is may/RTSP may/ Xavier _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jul 07 10:25: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 1I7BEI-00067s-1z; Sat, 07 Jul 2007 10:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5irl-0007Lr-Nx for mmusic@ietf.org; Tue, 03 Jul 2007 09:56:29 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ir5-00008s-UT for mmusic@ietf.org; Tue, 03 Jul 2007 09:56:29 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I5ir5-0000dA-5C; Tue, 03 Jul 2007 09:55:47 -0400 Message-ID: <468A5563.1030602@bbn.com> Date: Tue, 03 Jul 2007 09:55:47 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg Issue #9: Unknown attributes and potential configuration selection References: <467FF858.6020503@cisco.com> <4682A52D.7020901@bbn.com> <4682A8B4.90401@cisco.com> In-Reply-To: <4682A8B4.90401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-Mailman-Approved-At: Sat, 07 Jul 2007 10:25:45 -0400 Cc: Jonathan Lennox , mmusic 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 Flemming, Thanks for the reply, I now see where the problem is with solution (2). Solution (4) seems like the best solution. (I guess it's more convenient to mark my crypto attributes as mandatory than to mark all of my rtpmaps as optional). It seems that in implementing Solution (4) there are two possibilities: A) Mark the attributes as "optional" in the a=acap line B) Mark the attributes as "optional" in the a=pcfg line Both of these options seem reasonable me. I guess (B) is probably perferred because it's more expressive. (Although I'm not sure when you'd want an attribute to be optional in one a=pcfg line and mandatory in another a=pcfg line). - Matt Lepinski :-> Flemming Andreasen wrote: > > > Matt Lepinski wrote: > >> Flemming, >> >> I'm concerned that marking individual attributes within a potential >> configuration as mandatory or optional will increase the perception >> of complexity for SDP capability negotiation. Therefore, my >> preference would be to avoid Options (3) and (4). >> >> Personally, I can't think of a use-case where the lack of flexibility >> in Option (2) would cause signficant problems. > > How about rtpmaps mapping to an unsupported codec (which codec > negotiation/standard 3264 procedures would have taken care of) ? It > will be a quite common use case for the media capabilities extension. > >> Therefore, I'd favor Option (2). >> > Per the above, I think there are important use cases that will make > this option problematic. > > -- Flemming > >> - Matt Lepinski :-> >> >> Flemming Andreasen wrote: >> >>> Jonathan Lennox had noted that the current potential configurationa >>> algorithm combined with the standard SDP rules of ignoring unknown >>> attributes, may lead an answerer to select a potential configuration >>> with attributes it does not support, when the intent was to actually >>> have the answerer select a potential configuration with attributes >>> the answerer does support. Clearly, this does not produce the >>> desired outcome. >>> >>> The reason for this is that we still use the standard SDP rules >>> where we ignore unknown SDP attributes. >>> >>> The design team did not get a chance to discuss this issue in >>> Prague, however there seems to be a few possible solutions to this one: >>> >>> 1) Continue with the current scheme, but allow the answerer to >>> select only a potential configuration if the potential configuration >>> makes sense and can be supported. This would ensure that any >>> attributes that are required in order for a potential configuration >>> to be used would have to be supported by the answerer in order for >>> him to select that. For example, if the media stream is for SRTP, >>> and the potential configuration specifies use of the "crypto" >>> attribute for keying material, which the answerer didn't support, >>> the answerer would move on to the next potential configuration >>> (which could use a different keying mechanism). >>> >>> >>> 2) Require that all attributes used by a potential configuration >>> MUST be supported by the answerer in order for that potential >>> configuration to be valid (and hence be able to be selected). An >>> attribute is supported if both the attribute type and its value can >>> be supported. This raises some potential ambiguity with payload >>> types for example, where an rtpmap is both understood and supported, >>> but the actual codec is not. >>> >>> 3) As 2), however allow for individual attribute capabilities to be >>> marked as "optional" in a potential configuration. If an "optional" >>> attribute capability is not supported by the answerer, the potential >>> configuration would still be considered valid. >>> >>> 4) Similar to 3), except the default would be "optional", and we can >>> mark certain attributes as mandatory. >>> >>> >>> Option 1 seems flaky and is not recommended. >>> Option 2 is simple to specify and use, however, as noted, it is not >>> clear it has sufficient flexibility >>> The recommendation here is for either option 3 or 4, with the choice >>> depending on whether you believe optional or mandatory attributes >>> are the more common use cases for SDP Capability Negotiation. >>> >>> My preference is for option 4. Compared to option 3, this option >>> aligns slightly better with standard SDP as well, inasmuch as the >>> default operation is normal SDP, and any changes from that requires >>> an explicit indication (mandatory attribute). >>> >>> Please let me know if you disagree or have any comments on this. >>> >>> Thanks >>> >>> -- Flemming >>> >>> _______________________________________________ >>> 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 Sat Jul 07 10:25: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 1I7BEI-00067z-Cn; Sat, 07 Jul 2007 10:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aRt-0006Lv-1p for mmusic@ietf.org; Thu, 05 Jul 2007 19:09:21 -0400 Received: from mail-hub-2.cs.cornell.edu ([128.84.103.139] helo=exch-hub2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6aRo-0005TL-Mb for mmusic@ietf.org; Thu, 05 Jul 2007 19:09:21 -0400 Received: from exchfe1.cs.cornell.edu (128.84.97.33) by mail-hub.cs.cornell.edu (128.84.103.140) with Microsoft SMTP Server id 8.0.700.0; Thu, 5 Jul 2007 19:09:16 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.27]) by exchfe1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 19:09:02 -0400 Received: from localhost.localdomain ([128.84.96.18]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 19:09:01 -0400 From: Saikat Guha To: Jonathan Rosenberg In-Reply-To: <468D6ECD.80108@cisco.com> References: <468D6ECD.80108@cisco.com> Date: Thu, 5 Jul 2007 16:09:00 -0700 Message-ID: <1183676940.23674.36.camel@nephthys.corp.google.com> MIME-Version: 1.0 X-Mailer: Evolution 2.6.1 X-OriginalArrivalTime: 05 Jul 2007 23:09:01.0765 (UTC) FILETIME=[79ABDF50:01C7BF59] Received-SPF: None (mail-hub.cs.cornell.edu: saikat@cs.cornell.edu does not designate permitted sender hosts) X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Sat, 07 Jul 2007 10:25:45 -0400 Cc: IETF MMUSIC WG Subject: [MMUSIC] Re: ICE-tcp implementation concerns 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="===============1358053893==" Errors-To: mmusic-bounces@ietf.org --===============1358053893== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-prLUAgvKEcgrM2gclkOA" --=-prLUAgvKEcgrM2gclkOA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-07-05 at 18:21 -0400, Jonathan Rosenberg wrote: > Guylain had indicated that, with BSD sockets at least, this could not be=20 > implemented. He said: >=20 > > It seems that you cannot do a listen and then do a > > connect on the same socket. Just to clarify, pure TCP S-O can be triggered using the BSD api simply using: bind() then connect(). For pure S-O listen() doesn't need to be called. The connect will make the OS send the SYN, and when it receives a SYN in response, the OS stack with do S-O and the userspace will be none the wiser. The problem with this is getting the SYNs to cross in the network. And if either SYN reaches the remote endpoint before connect is called on that endpoint, RSTs are generated by the OS stack and the whole thing breaks down. > > The following (preudo) code works, and has been tested to do TCP > > traversal on Windows, Linux and OSX: > >=20 > > for i in 1 to 100 > > sock_i =3D socket() > > set(sock_i, SO_REUSEPORT) ^^^^^^^^^^^^ My mistake. This should be REUSEADDR. REUSEPORT isn't necessary. > > bind(sock_i, local) > >=20 > > listen(sock_0) > > connect(sock_1, stun) > > connect(sock_2, remote_a) > > connect(sock_3, remote_b) > > ... > >=20 > > The key thing is that all the sockets must be bound to the local port > > before listen is called. So the pool of potential sockets to use for > > ICE-TCP would need to be pre-allocated. Once you exhaust the pool, a > > whole new pool needs to be created (with its own listen socket, and N > > connect sockets). Just to clarify, the whole business of calling listen on sock_0 above is to catch a SYN that didn't cross in the network.=20 If the SYN's cross: - TCP S-O happens - one of the connect()s on the local host succeeds,=20 and one of the connect()s on the remote hosts succeeds. If SYNs don't cross: - Regular TCP happens - On one host, one of the connect()s succeeds - On the other host, a new socket can be accept()ed from sock_0 So more implementation advise: After calling listen() to catch an un-crossed SYNs, and connect()s to attempt either S-O or 3WHS ... an implementation needs to *asynchronously* wait for either a successful connect() or a successful accept().=20 --=20 Saikat --=-prLUAgvKEcgrM2gclkOA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBGjXoMnFltqi691/oRAg1LAJ4hVvSt+gyEtwNfsyxh1Wae/cVc0ACfYD9v c6haIYLad8KpFc8tTxifIiU= =4Rle -----END PGP SIGNATURE----- --=-prLUAgvKEcgrM2gclkOA-- --===============1358053893== 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 --===============1358053893==-- From mmusic-bounces@ietf.org Sat Jul 07 16:27: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 1I7GsD-0007d4-5d; Sat, 07 Jul 2007 16:27:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7GsB-0007Z7-SF for mmusic@ietf.org; Sat, 07 Jul 2007 16:27:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Gs7-000557-3D for mmusic@ietf.org; Sat, 07 Jul 2007 16:27:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2007 13:27:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC+Uj0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,511,1175497200"; d="scan'208"; a="178234605:sNHT33606603" 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 l67KREAu024675; Sat, 7 Jul 2007 13:27:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l67KRAka012350; Sat, 7 Jul 2007 20:27:10 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); Sat, 7 Jul 2007 13:27:10 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jul 2007 13:27:09 -0700 Message-ID: <468FF721.3010104@cisco.com> Date: Sat, 07 Jul 2007 16:27:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Guylain Lavoie Subject: Re: [MMUSIC] ICE-tcp implementation concerns References: <6EF4CC794ECF2B409390605FDEA9012225B3E8@m5tmail1.m5t.com> In-Reply-To: <6EF4CC794ECF2B409390605FDEA9012225B3E8@m5tmail1.m5t.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2007 20:27:09.0733 (UTC) FILETIME=[31ACE550:01C7C0D5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5644; t=1183840034; x=1184704034; 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-tcp=20implementation=20concerns |Sender:=20; bh=sL0PyTYiPE8iaM8xG+M6HqRGB9/sWbwLNvXgfBHJcNA=; b=Ld+0KSzBSuo9GRyJKVg/fPg8Qmq/djb16MHzDa7us1TE5doUbwx1CM9ihI2Ff14IZ0cd5H6e iqPBtcKUUyxVJjgTZy5jBwxGx2ibxMoi0VJ/1SAxERm/2X7nqHAdXo+l; 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: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Yes, I added text on this in the appendix. The recommendation is that the number of sockets to allocate should be equal to 25, which represents a worst case of five forked receipients, each with five SO candidates. As you point out, this problem is only for SO. -Jonathan R. Guylain Lavoie wrote: > Hi Jonathan, > > While thinking about this, I found one additional thing that you should > add to your appendix. > > As I said, the technique is not obvious, but if it works, the > implementation should be doable without to much sacrifice on the > architecture. > > However, while thinking more about binding all those sockets at once, I > stumble upon one less trivial issue. I am thinking about SIP forking > where additional sockets will need to be bound much later in the > process. We will need to create a poll of sockets already bound to the > same port and use them later if there is forking. For example, we could > bind a certain amount of additional sockets, that may not be sufficient > or may be way too much, wasting valuable resources. This problem does > not affect Active candidates because the port is not important. Neither > does it affect Passive candidates because we are listening of the socket > and one server socket is enough for this purpose. The issue show up with > the SO candidates. This issue will have a much bigger impact on the > implementation architecture and than I originally thought, at least in > our implementation. > > It would be good to discuss this also in the appendix. > > Best Regards, > Guylain > > Guylain Lavoie > Technical Product Manager > M5T, a Division of Media5 Corporation > Web: http://www.m5t.com > Email: glavoie@m5t.com > Tel: +1-819-829-1008, ext: 662 > Fax: +1-819-829-1342 > > -----Original Message----- > From: Guylain Lavoie [mailto:glavoie@m5t.com] > Sent: July 5, 2007 11:05 PM > To: Jonathan Rosenberg; IETF MMUSIC WG > Cc: Saikat Guha > Subject: RE: [MMUSIC] ICE-tcp implementation concerns > > Hi Jonathan, > > Frankly, I am very happy to learn that there is finally one way to make > this work, albeit not very obvious. The effort deployed for this > document will not have been done in vain. > > Having to implement our ICE stack for many platforms, I was beginning to > be a bit worried about how we could manage to make this work. Thank you > for this information. > > You are right, adding an appendix to explain this is a very good idea. > > Best Regards, > Guylain > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: July 5, 2007 6:21 PM > To: IETF MMUSIC WG > Cc: Saikat Guha > Subject: [MMUSIC] ICE-tcp implementation concerns > > Most folks probably missed this, but deep within one of the threads on > core ICE, was an important issue raised by Guylain Lavoie. > > With ICE-tcp, if you have passive or SO candidates, the basic sequence > of events is as follows: > > 1. open a tcp connection to your stun server 2. send Binding Request, > learn a mapped address A:B 3. send an INVITE with A:B as a passive or SO > candidate 4. be prepared to receive TCP incoming connection requests on > the IP and port from which you connected to the STUN server > > Guylain had indicated that, with BSD sockets at least, this could not be > implemented. He said: > >> 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. > > > If this is true, it would mean that ICE-tcp is basically useless. That > would be bad. However, this same problem would exist in any solution for > direct tcp through NAT (STUNT for example), so it didn't seem right. I > sent a note to Saikat Guha, and got the following reply: > >> The following (preudo) code works, and has been tested to do TCP >> traversal on Windows, Linux and OSX: >> >> for i in 1 to 100 >> sock_i = socket() >> set(sock_i, SO_REUSEPORT) >> bind(sock_i, local) >> >> listen(sock_0) >> connect(sock_1, stun) >> connect(sock_2, remote_a) >> connect(sock_3, remote_b) >> ... >> >> The key thing is that all the sockets must be bound to the local port >> before listen is called. So the pool of potential sockets to use for >> ICE-TCP would need to be pre-allocated. Once you exhaust the pool, a >> whole new pool needs to be created (with its own listen socket, and N >> connect sockets). > > > So, it seems this can be made to work, though its a bit awkward. But, > such is the penalty. I don't think there is really an alternative. > However I wanted to invite comments on this. > > I think it might be useful having an informational appendix in ice-tcp > which mentions this issue. Otherwise this is going to be a huge problem > for implementors. > > -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 Sat Jul 07 17:55: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 1I7IFu-0004fZ-JQ; Sat, 07 Jul 2007 17:55:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7IFs-0004Yb-TN for mmusic@ietf.org; Sat, 07 Jul 2007 17:55: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 1I7IFo-0001bI-Cs for mmusic@ietf.org; Sat, 07 Jul 2007 17:55:52 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2007 14:55:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEapj0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,511,1175497200"; d="scan'208"; a="500966470:sNHT37614256" 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 l67LtlBT025645; Sat, 7 Jul 2007 14:55:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l67Ltckc004757; Sat, 7 Jul 2007 21:55:47 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); Sat, 7 Jul 2007 14:55:46 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Jul 2007 14:55:45 -0700 Message-ID: <46900BE5.6030808@cisco.com> Date: Sat, 07 Jul 2007 17:55:49 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D020539B@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D020539B@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2007 21:55:46.0066 (UTC) FILETIME=[9274EF20:01C7C0E1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4203; t=1183845347; x=1184709347; 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=20ICE=20lite=20-=20comment=20on=20gathering=20candidate s=20at=20answerer=20(section=0A=205.3) |Sender:=20; bh=z1klca/6kP4DhRjBKW+ToxL9NkiZUzDcFVIgkf7LVJc=; b=On5pVkPqwolMvPawcmQp3moK8HydQFHOmQpBwMJSaPXGcYnDJTRgmgrbI7kalQdTuqAUycu+ iVyUHF1yn+2TEBNs6lU5uIJ81xP3HkMrDT/cfYvBdAsbwWfOYDeczsiv; 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: b5d20af10c334b36874c0264b10f59f1 Cc: mmusic Subject: [MMUSIC] Re: ICE lite - comment on gathering candidates at answerer (section 5.3) 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 Elwell, John wrote: > Jonathan, > > "The process for gathering candidates at the answerer is identical to > the process for the offerer as described in Section 4.1.1 for full > implementations and Section 4.2 for lite implementations. It is > RECOMMENDED that this process begin immediately on receipt of the > offer, prior to alerting the user. Such gathering MAY begin when an > agent starts." > > I think considerations for lite implementations are slightly different > when the offerer is also lite. It would be advantageous for the answerer > to choose just a single candidate that is compatible with one of the > candidates in the offer. In this way it would be safe to override the > recommendation to delay alerting. There is no delayed alerting in the case where both sides are lite. Immediately upon receipt of the offer, the answerer can begin to send media. Section 8.2.2 has a bug in that it is not clear that the procedures there apply to controlled agents also. There are no connectivity checks that get sent when both are lite, so ICE is basically immediately done. That said, an implementation is within its rights to include fewer candidates in its answer that would have otherwise, based on the offer. Alerting can take place, with the > knowledge that when the user answers (or when early media is sent) media > can be sent to the matching candidate from the offer. If alerting takes > place but the answerer has submitted several candidates and not made a > selection, it is unable to send early media or media when the user > answers, unless a further offer has been received in an UPDATE request. See above. > Therefore clipping is likely to occur. If alerting does not commence at > this point, the answerer will need to wait for another offer in an > UPDATE request on the early dialog. This in turns means that > 100rel/PRACK has to be used, which is something that we took a decision > to avoid way back. For full ICE (including full-lite interworking) > successful connectivity checks are the trigger to start alerting, but > these do not occur with lite-lite working. > > So I would suggest the addition of the following words: > "When both the offerer and the answerer are lite implementations, the > answerer MAY gather just a single candidate that is compatible with one > of the candidates in the offer and alert the user immediately. In this > case it can assume that the offerer will select the compatible candidate > and that media can be sent to that candidate without waiting for a > further offer." > > In addition, I think the answerer would need to place the sole candidate > pair into the Valid List when it sends this first SDP answer, in order > to allow media to flow before the second offer arrives. I defer to your > judgement as to which words need changing to reflect this. Section 8.2.2 is meant to apply to both controlling and controlled, which says: > If there is more than one pair per component: > > o The agent MUST select a pair based on local policy. Since this > case only arises for IPv6, it is RECOMMENDED that an agent follow > the procedures of RFC 3484 [12] to select a single pair. > > o The agent adds the selected pair for each component to the valid > list. As described in Section 11.1, this will permit media to > begin flowing. However, it is possible (and in fact likely) that > both agents have chosen different pairs. so this is already there. It just needs to be clarified that its for both. Now the twist is that it is possible that both agents choose different pairs. Thats OK; if both are lite, it should still work. They'll converge on a single pair when the re-INVITE comes. But there is no media clipping. -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 Jul 09 02:55: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 1I7n9P-0002qr-Jj; Mon, 09 Jul 2007 02:55:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7n9N-0002qm-Am for mmusic@ietf.org; Mon, 09 Jul 2007 02:55:13 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7n9D-0006SW-AW for mmusic@ietf.org; Mon, 09 Jul 2007 02:55:13 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l696sMB3013380; Mon, 9 Jul 2007 09:54:42 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:54:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:54:40 +0300 Received: from hed050116.research.nokia.com ([172.21.50.116]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:54:40 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" , mmusic@ietf.org, magnus.westerlund@ericsson.com, thomas.zeng@gmail.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Date: Mon, 9 Jul 2007 09:54:39 +0300 User-Agent: KMail/1.9.6 References: <10d301c7bfee$78622c90$e171150a@amer.cisco.com> In-Reply-To: <10d301c7bfee$78622c90$e171150a@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: <200707090954.39727.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 09 Jul 2007 06:54:40.0270 (UTC) FILETIME=[058EAAE0:01C7C1F6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Friday 06 July 2007 19:55:33 you wrote: > > That being said, I suppose the Symmetric RTP *variant* looks > > better anyway. > > The Symmetric RTP Variant does look better, but it doesn't > work if the media server (RTSP server) is behind its own NAT -- > such as, for example, you are visiting Grandma's house (which > has its own NAT) and you want to interact with your media > player at your house (which has its own NAT). > > The Symmetric RTP Variant is very similar to ICE-Lite, as > defined in the last few iterations of ICE. > > I would really like the RTSP NAT Evaluation document to include > an additional requirement for 'both RTSP server and RTSP client > behind their own NATs' to its matrix in section 6, "Comparision > of NAT traversal techniques". I might be pessimistic, or I might perceive a distortedly bad reality of NA= Ts=20 (due to having only Linux-based symmetric NATs around me). Still, I really= =20 doubt RTSP will fly if both sides are behind different NATs. I do think the= =20 success rate will be too low - without relays nor UPnP-ICD/NAT-PMP. But onl= y=20 time will tell. *However*, even if UDP traversal turns out to work, how do you get the TCP= =20 control connection through in the first place, if the server is NATed? So,= =20 you end up requiring some kind of port forwarding: manual port-triggering,= =20 UPnP-ICD or NAT-PMP on the server's NAT anyway; or (IPv6) tunneling: Teredo= ,=20 AYIYA, etc. Note that SOCKS5 or TURN will not work since they disallow=20 servers by design. In that perspective, I'd much rather see a simple NATed client to non-NATed= =20 server traversal scheme. Quick. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 09 02:59: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 1I7nDf-0004it-UV; Mon, 09 Jul 2007 02:59:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7nDe-0004io-VD for mmusic@ietf.org; Mon, 09 Jul 2007 02:59:38 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7nDe-0006YB-GH for mmusic@ietf.org; Mon, 09 Jul 2007 02:59:38 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l696xBUg028577 for ; Mon, 9 Jul 2007 09:59:36 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:59:23 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:59:23 +0300 Received: from hed050116.research.nokia.com ([172.21.50.116]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:59:23 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org, IETF MMUSIC WG Subject: Re: [MMUSIC] ICE-tcp implementation concerns Date: Mon, 9 Jul 2007 09:59:23 +0300 User-Agent: KMail/1.9.6 References: <6EF4CC794ECF2B409390605FDEA9012225B3E8@m5tmail1.m5t.com> <468FF721.3010104@cisco.com> In-Reply-To: <468FF721.3010104@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707090959.23462.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 09 Jul 2007 06:59:23.0663 (UTC) FILETIME=[AE7901F0:01C7C1F6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Saturday 07 July 2007 23:27:13 ext Jonathan Rosenberg wrote: > Yes, I added text on this in the appendix. The recommendation is that > the number of sockets to allocate should be equal to 25, which > represents a worst case of five forked receipients, each with five SO > candidates. As you point out, this problem is only for SO. That's quite big though. select() is limited to 64 sockets (by default) on a bunch of platforms (at= =20 least Winsock, Cygwin, Symbian). You might as well add an implementation hi= nt=20 to increasing FD_SETSIZE if more than one session may be pending at a time. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 09 03:33: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 1I7nk7-0003sA-S7; Mon, 09 Jul 2007 03:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7nk6-0003mI-Oo for mmusic@ietf.org; Mon, 09 Jul 2007 03:33:10 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7njt-0006LE-6m for mmusic@ietf.org; Mon, 09 Jul 2007 03:33:10 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l697WrYL013318 for ; Mon, 9 Jul 2007 09:32:55 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l697WpaB024521 for ; Mon, 9 Jul 2007 09:32:53 +0200 Received: from nets13ha.ww300.siemens.net ([158.226.250.77]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jul 2007 09:32:51 +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 Date: Mon, 9 Jul 2007 09:32:50 +0200 Message-ID: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-16 Comments Thread-Index: AcfB+1iUJOpH0LI8R2+rtSCkm3NSLw== From: "Zingerle, Meinrad" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 09 Jul 2007 07:32:51.0356 (UTC) FILETIME=[5B26A5C0:01C7C1FB] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070709093253-6ACDFBB0-4739E4D5/0-0/0-15 X-purgate-size: 2951/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mmusic@ietf.org Subject: [MMUSIC] ICE-16 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: , Errors-To: mmusic-bounces@ietf.org #1)Section 4.2. states that a ICE-Lite agent should allocate=20 "one IPv4 candidate, one link local and one global IPv6 address". =20 Since a Router MUST NOT forward packets with a link-local source and/or destination address (see RFC 3513, section 2.5.6 Local-Use IPv6 Unicast Addresses) and RFC3484 prefers smaller scopes over larger scopes, I guess the usage of link-local addresses in this context may be problematic (each agent would have to check if its partner is really on the same link). Thus, I would suggest that an ICE-Lite agent allocates a link-local IPv6 address only in that case there is no IPv6 address of global scope available.=20 Or even disallow the usage of link-local addresses at since their applicability in this context is very limited.=20 #2) Section 8.2.2 "... Two candidates are paired up when=20 they are for the same component, utilize the same transport protocol (UDP in this specification), and are from the same IP address family (IPv4 or IPv6)." In my understanding addresses of local scope (e.g. IPv6 linl-local, auto-configured IPv4 169.254.0.0/16) should not be paired with those of global scope.=20 #3)For clearness I would suggest to add the following sentence to section 7.2. STUN Server Procedures "The agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in its responses to connectivity checks." In my understanding that would be in line with "7.1.1.4. Forming Credentials ... Agent L included a username fragment of LFRAG for its candidates, and a password of LPASS. Agent R provided a username fragment of RFRAG and a password of RPASS. A connectivity check from L to R (and its response of course) utilize the username RFRAG:LFRAG and a password of RPASS. A connectivity check from R to L (and its response) utilize the username LFRAG:RFRAG and a password of LPASS." and=20 "17.1. Attacks on Connectivity Checks (page 84, 2nd paragraph) ... Fortunately, this attack is mitigated completely through the STUN message integrity mechanism. The attacker needs to inject a fake response, and in order for this response to be processed, the attacker needs the password. ..." #4) 7.2. STUN Server Procedures "... It is possible (and in fact very likely) that an offerer 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 Is it correct that at time of receiving the Binding Request the agent cannot send the response (due to lack of and of the answerer)? If so, I assume that the agent must not discard the Binding request but store it (or even prepare the response) and send the response as soon as the SDP answer (with and of the answerer) has been received, correct? =09 Meinrad=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 09 06:57: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 1I7qvP-0007qD-Px; Mon, 09 Jul 2007 06:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7qvO-0007pu-J5 for mmusic@ietf.org; Mon, 09 Jul 2007 06:57:02 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7qvB-00037m-1x for mmusic@ietf.org; Mon, 09 Jul 2007 06:57:02 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l69Audvb011454; Mon, 9 Jul 2007 12:56:39 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l69AuWUH021976; Mon, 9 Jul 2007 12:56:38 +0200 Received: from nets13ha.ww300.siemens.net ([158.226.250.77]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jul 2007 12:56:34 +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 Date: Mon, 9 Jul 2007 12:56:31 +0200 Message-ID: <9546CD0F7CC5EE48BCCE583AC4FC864D04057723@nets13ha.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-16: some questions Thread-Index: AcfCF86LNyyLQYYQQZiCkQsWBib4oA== From: "Zingerle, Meinrad" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 09 Jul 2007 10:56:34.0400 (UTC) FILETIME=[D0A72600:01C7C217] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070709125639-46D90BB0-0F78CC4B/0-0/0-15 X-purgate-size: 2805/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mmusic@ietf.org Subject: [MMUSIC] ICE-16: some questions 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) resolving role conflicts=20 "5.2. Determining Role ... Both Lite: The agent which generated the offer which started the ICE processing MUST take the controlling role, and the other MUST take the controlled role. In this case, no connectivity checks are ever sent. Rather, once the offer/answer exchange completes, each agent performs the processing described in Section 8 without connectivity checks. It is possible that both agents will believe they are controlled or controlling. In the latter case, the conflict is resolved through glare detection capabilities in the signaling protocol carrying the offer/answer exchange. .." Why the "glare detection capabilities in the signaling protocol" can resolve the role conflict in a Lite-Lite scenario but not in Full-Full one? #2) candidates pairs for the same media stream and same foundation "7.1.2.2.3. Updating Pair States The agent sets the state of the pair that generated the check to Succeeded. The success of this check might also cause the state of other checks to change as well. The agent MUST perform the following two steps: 1. The agent changes the states for all other Frozen pairs for the same media stream and same foundation to Waiting. Typically these other pairs will have different component IDs but not always. ..." In which cases different candidate pairs with same fondation and belonging to the same media may have the same component ID?=20 And in case there are two candidate pairs with same fondation and component ID belonging to the same media: how does an ICE agent handle it? As alternatives, or ..? #3) Peer reflexive candidates In my understanding peer reflexive candidates will be discovered in the following two scenarios only: a) the agent is behind a smmetric NAT=20 b) the agent belongs to private network that has more than one NAT exits to the public network =20 +---+ +-----+ +----+ | L | ---+------|NAT-1|----------|STUN|---- ....... +---+ | +-----+ +----+ . | | | +-----+ | +---+ +------|NAT-2|---------------------------+--------| R | +-----+ +---+=20 Is that incorrect or are there other scenarios where peer reflexive candidates will be learned? And am I right, that in scenario a) STUN checks with the server reflexive candidate of agent L wouldn't succeed? In case b) the selection of the path through the NAT-2 box is a routing decision and I'm not sure whether using the server reflexive candidate of agent L would work. Would it? Thanks, Meinrad _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 09 07:40: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 1I7rbd-0005dU-UY; Mon, 09 Jul 2007 07:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rb1-0004dJ-P0; Mon, 09 Jul 2007 07:40:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7rb0-0004Gd-Ff; Mon, 09 Jul 2007 07:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 683D0328EF; Mon, 9 Jul 2007 11:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7rb0-0002lg-Ao; Mon, 09 Jul 2007 07:40: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: Mon, 09 Jul 2007 07:40:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-05.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 Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : M. Westerlund, T. Zeng Filename : draft-ietf-mmusic-rtsp-nat-05.txt Pages : 8 Date : 2007-07-09 This document defines a solution for Network Address Trans(NAT) traversal for the media stream associated with an Real-time Streaming Protocol version 2 (RTSP 2.0). The mechanism is based on Interactive Connectivity Establishment (ICE) adapted for using RTSP as signalling channel. The necessary RTSP protocol extensions and procedure is defined in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-05.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-rtsp-nat-05.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-rtsp-nat-05.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-07-09073306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-09073306.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 Mon Jul 09 07:50: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 1I7rks-0007Qx-A5; Mon, 09 Jul 2007 07:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rkp-0007Qc-3u for mmusic@ietf.org; Mon, 09 Jul 2007 07:50:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7rkl-0004bY-6b for mmusic@ietf.org; Mon, 09 Jul 2007 07:50:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9BCB4215DC for ; Mon, 9 Jul 2007 13:50:06 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-5e-469220eee126 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7E834215D6 for ; Mon, 9 Jul 2007 13:50:06 +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, 9 Jul 2007 13:50:06 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:50:05 +0200 Message-ID: <469220ED.7090305@ericsson.com> Date: Mon, 09 Jul 2007 13:50:05 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-05.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 11:50:06.0004 (UTC) FILETIME=[4AEB0740:01C7C21F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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, This completes the document split of the content of draft-ietf-mmusic-rtsp-nat-04. Now the evaluation and reasoning around different versions are in draft-ietf-mmusic-rtsp-nat-evaluation-00 and this document has been cut down to be basically a technical specification. However, currently it is a technical specification without content. In fact I am not certain that the technical overview present even follows ICE correctly. Need to do a review of this and then get going on the details. Cheers Magnus Internet-Drafts@ietf.org skrev: > 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 Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) > Author(s) : M. Westerlund, T. Zeng > Filename : draft-ietf-mmusic-rtsp-nat-05.txt > Pages : 8 > Date : 2007-07-09 > > This document defines a solution for Network Address Trans(NAT) > traversal for the media stream associated with an Real-time Streaming > Protocol version 2 (RTSP 2.0). The mechanism is based on Interactive > Connectivity Establishment (ICE) adapted for using RTSP as signalling > channel. The necessary RTSP protocol extensions and procedure is > defined in this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-05.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-rtsp-nat-05.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-rtsp-nat-05.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. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Jul 09 08:50: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 1I7sgp-00057Z-OQ; Mon, 09 Jul 2007 08:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sgl-00050n-PV; Mon, 09 Jul 2007 08:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7sgk-0006QO-El; Mon, 09 Jul 2007 08:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5444F26E77; Mon, 9 Jul 2007 12:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7sgk-0006b1-8B; Mon, 09 Jul 2007 08: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: Mon, 09 Jul 2007 08:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-04.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 : TCP Candidates with Interactive Connectivity Establishment (ICE Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-tcp-04.txt Pages : 20 Date : 2007-07-09 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-04.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-ice-tcp-04.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-ice-tcp-04.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-07-09084916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-tcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-tcp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-09084916.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 Mon Jul 09 11:28: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 1I7vAG-0004ru-8d; Mon, 09 Jul 2007 11:28:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vAE-0004rb-Im for mmusic@ietf.org; Mon, 09 Jul 2007 11:28:38 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7vAE-0002Gs-1j for mmusic@ietf.org; Mon, 09 Jul 2007 11:28:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 08:28:27 -0700 X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="7270967:sNHT18807278544" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69FSRw1025365; Mon, 9 Jul 2007 08:28:27 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l69FSQka009081; Mon, 9 Jul 2007 15:28:26 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , , , Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Date: Mon, 9 Jul 2007 08:28:26 -0700 Message-ID: <064801c7c23d$cbe4c6b0$c3f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <200707090954.39727.remi.denis-courmont@nokia.com> Thread-Index: AcfB9ghgA3IoHsWARyG9Hebv3/H7ogARN58A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3335; t=1183994907; x=1184858907; c=relaxed/simple; s=sjdkim1004; 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]=20I-D=20ACTION=3Adraft-ietf-mmusic-rtsp-nat- evaluation-00.txt |Sender:=20; bh=otrS9hnbaRwGxVeBm24QHdb9y1ulVKTwv5Kw9y/UY0w=; b=SQZtQ3Oc7L7+1/rRvkGIwkLxDvDqLtwtUj7UXC79gpd52gs2mJqVOnc0uzNq36A2jYpZo+bY yLOP7pT6utAEhpsqlmMmZpo56mJVy2novOiEgm3akUh+VzG6OdfZhW685Vu2EJ1ZnAhloWuE2d 3VEA06jz3k535kxqVqx/+nd70=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Friday 06 July 2007 19:55:33 you wrote: > > > That being said, I suppose the Symmetric RTP *variant* looks > > > better anyway. > > > > The Symmetric RTP Variant does look better, but it doesn't > > work if the media server (RTSP server) is behind its own NAT -- > > such as, for example, you are visiting Grandma's house (which > > has its own NAT) and you want to interact with your media > > player at your house (which has its own NAT). > > > > The Symmetric RTP Variant is very similar to ICE-Lite, as > > defined in the last few iterations of ICE. > > > > I would really like the RTSP NAT Evaluation document to include > > an additional requirement for 'both RTSP server and RTSP client > > behind their own NATs' to its matrix in section 6, "Comparision > > of NAT traversal techniques". > > I might be pessimistic, or I might perceive a distortedly bad > reality of NATs (due to having only Linux-based symmetric NATs > around me). Still, I really doubt RTSP will fly if both sides > are behind different NATs. I do think the success rate will > be too low - without relays nor UPnP-ICD/NAT-PMP. But only > time will tell. Yes, that could well be true. But if you can purchase a UPnP- or NAT-PMP-capable NAT, you could (in theory) also purchase a non-filtering NAT. And ICE doesn't _require_ you learn all of your addresses using STUN -- you could learn your address via UPnP, NAT-PMP, MIDCOM, SIMCO, or a variety of other techniques, too. I would certainly find it reasonable that anyone wanting to serve RTSP content, from behind their NAT, is required to have only a non-symmetric and non-address-filtering NAT. > *However*, even if UDP traversal turns out to work, how do > you get the TCP control connection through in the first > place, if the server is NATed? If you're behind a NAT that doesn't do any filtering, you can poke a hole in that NAT, learn your IP address and TCP port, and advertise that (via DNS SRV records in Dynamic DNS). But you are right that if you're behind a NAT doing address filtering (or, worse, 'symmetric'), you won't be able to successfully serve RTSP content unless something on the Internet proxies the RTSP messages for you (and you maintain a TCP connection to that proxying device). In that same case, for media, if the other peer is also behind a 'symmetric' NAT or an 'address and port filtering' NAT, the media will have to be relayed, too. > So, you end up requiring some kind of port forwarding: > manual port-triggering, UPnP-ICD or NAT-PMP on the > server's NAT anyway; or (IPv6) tunneling: Teredo, > AYIYA, etc. Note that SOCKS5 or TURN will not work since > they disallow servers by design. > > In that perspective, I'd much rather see a simple NATed > client to non-NATed server traversal scheme. Quick. I believe everyone interested in IPTV wants that, too. I am interested in IPTV. However, I would like to understand the difference between the "Symmetric RTP Variant" (discussed in the draft) and ICE-lite. I think they are similar, but I admit that I don't fully grasp what all "symmetric RTP variant" might be doing when it is fully specified. If ICE-Lite and "Symmetric RTP Variant" are similar, would you still want "Symmetric RTP Variant"? -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 09 15:13: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 1I7yg9-0007rX-Hp; Mon, 09 Jul 2007 15:13:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yg8-0007rI-5z for mmusic@ietf.org; Mon, 09 Jul 2007 15:13:48 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7yg7-000384-Mq for mmusic@ietf.org; Mon, 09 Jul 2007 15:13:48 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 12:13:46 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKQlkkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="7384268:sNHT32495994" 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 l69JDkTl008336; Mon, 9 Jul 2007 12:13:46 -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 l69JDkka000782; Mon, 9 Jul 2007 19:13:46 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); Mon, 9 Jul 2007 12:13:46 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 12:13:45 -0700 Message-ID: <469288EE.2070004@cisco.com> Date: Mon, 09 Jul 2007 15:13:50 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Zingerle, Meinrad" References: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> In-Reply-To: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 19:13:46.0088 (UTC) FILETIME=[45B97E80:01C7C25D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4192; t=1184008426; x=1184872426; 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-16=20Comments |Sender:=20; bh=G5fgUpdUM3g1YblxjUJ6V+68wL+O1eXVX76IW7ztsO0=; b=fyXdgT1RTchXcGe2+H/8XWwEsmCUTIJOfS45vV3ZKoUZLtFrsqWCF6rxuQYfvXy5aIW76FIS odxNpVlLfMl+3LCJoup1dYfIF0u1n/MqM7UGVF58X/NW+jwn2zWOgc3a; 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: 6e922792024732fb1bb6f346e63517e4 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: ICE-16 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: , Errors-To: mmusic-bounces@ietf.org Thanks for the comments. Responses inline. Zingerle, Meinrad wrote: > #1)Section 4.2. states that a ICE-Lite agent should allocate > "one IPv4 candidate, one link local and one global IPv6 address". > > Since a Router MUST NOT forward packets with a link-local source and/or > destination address (see RFC 3513, section 2.5.6 Local-Use IPv6 Unicast > Addresses) and RFC3484 prefers smaller scopes over larger scopes, I > guess the usage of link-local addresses in this context may be > problematic (each agent would have to check if its partner is really on > the same link). > Thus, I would suggest that an ICE-Lite agent allocates a link-local IPv6 > address only in that case there is no IPv6 address of global scope > available. > Or even disallow the usage of link-local addresses at since their > applicability in this context is very limited. Right, good point. They can be used with full ICE since a connectivity check is performed to validate it. But not with ICE-lite since there may not be connectivity checks. > > #2) Section 8.2.2 > "... Two candidates are paired up when > they are for the same component, utilize the same transport > protocol > (UDP in this specification), and are from the same IP address > family > (IPv4 or IPv6)." > In my understanding addresses of local scope (e.g. IPv6 linl-local, > auto-configured IPv4 169.254.0.0/16) should not be paired with those of > global scope. Hmm, well if two IPv6 hosts are on the same link, I believe one can send from its link local address to the global v6 address of the other host. So it should work in those cases. When it doesn't work, the ICE checks will fail. So I think it does make sense, in the case of full ICE at least (link locals are only used for full ICE per your above comment). > > > #3)For clearness I would suggest to add the following sentence to > section 7.2. STUN Server Procedures > "The agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in > its responses to > connectivity checks." > In my understanding that would be in line with > "7.1.1.4. Forming Credentials > ... > Agent L included a username fragment of LFRAG for its > candidates, and > a password of LPASS. Agent R provided a username fragment of > RFRAG > and a password of RPASS. A connectivity check from L to R (and > its > response of course) utilize the username RFRAG:LFRAG and a > password > of RPASS. A connectivity check from R to L (and its response) > utilize the username LFRAG:RFRAG and a password of LPASS." > and > "17.1. Attacks on Connectivity Checks (page 84, 2nd paragraph) > ... Fortunately, this attack is mitigated completely > through the STUN message integrity mechanism. The attacker needs > to > inject a fake response, and in order for this response to be > processed, the attacker needs the password. ..." This text has been reworked in its alignment with the newly revised and I think much clearer rfc3489bis. rfc3489bis fully specifies this short term credential mechanism, so ICE does not need to say anything about when to include these attributes. > > #4) 7.2. STUN Server Procedures > "... It is possible (and in fact > very likely) that an offerer 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 > Is it correct that at time of receiving the Binding Request the agent > cannot send the response (due to lack of and of > the answerer)? No, it can send a response. It has the username (copied from the request), and the password is its own password. I added a sentence to clarify this. 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 Mon Jul 09 16:05:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zTt-0003L3-W5; Mon, 09 Jul 2007 16:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zTr-0003Ku-3p for mmusic@ietf.org; Mon, 09 Jul 2007 16:05:12 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zTn-0004hw-N0 for mmusic@ietf.org; Mon, 09 Jul 2007 16:05:11 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2007 13:05:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFMxkkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="179082757:sNHT27551493" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69K57ML028919 for ; Mon, 9 Jul 2007 13:05:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l69K53w9024891 for ; Mon, 9 Jul 2007 20:05:06 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); Mon, 9 Jul 2007 13:05:02 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:05:02 -0700 Message-ID: <469294F2.2000300@cisco.com> Date: Mon, 09 Jul 2007 16:05:06 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:05:02.0373 (UTC) FILETIME=[6F555550:01C7C264] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1469; t=1184011507; x=1184875507; 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:=20ICE-tcp=20is=20here |Sender:=20; bh=DTSD5aV0SBL6zb704/VwgOonIg4UHORfGYI/bh9X5iE=; b=k6GgBQWawekXzNuBFBLAgwTWgsvzlLKN3MfPa2OY99IsY6Z1pwsUn2Cked2+1UfPQZ5Hr9cF ujwGohizJQnQDIPNyB88alzpPjQYNNuUi5HHvY4lRhB5mVCWXa5TAkhx5SHfT/aE0sLRAfHLl8 3NNqCIXOwdqCDnTkehSI51aR8=; 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: b19722fc8d3865b147c75ae2495625f2 Subject: [MMUSIC] ICE-tcp is here 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 An updated ICE-tcp specification is now available: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-04.txt The changes in this version are: * terminology update to align with rfc3489bis * "STUN then TLS" specified, so that STUN runs outside of the TLS session * clarified that, when gathering candidates, TCP connection to STUN or TURN server must be kept open during ICE processing. Defined rules for connection lifecycle management, including reconnets, of connections to turn and stun servers * alignment of pacing rules with new algorithm in core ICE * after a connection re-establishment between peers, connectivity checks are redone prior to sending media or restarting TLS. This is to avoid attacks whereby an intermediary injects itself in after a connection fails and is reconnected. This is a change from before, where STUN was not sent after connection re-establishment * allowing either UDP or TCP candidates with secure media is now spelled out. The proposal in here is to allow DTLS-SRTP to run over TCP. There are a few open issues which I will post in other threads. 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 Mon Jul 09 16:06: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 1I7zVL-0003hM-GO; Mon, 09 Jul 2007 16:06:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zVK-0003h0-S4 for mmusic@ietf.org; Mon, 09 Jul 2007 16:06:42 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7ym6-0003jY-D1 for mmusic@ietf.org; Mon, 09 Jul 2007 15:20:00 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2007 12:19:29 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD4nkkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,517,1175497200"; d="scan'208"; a="384427736:sNHT1262713744" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l69JJS9N027114; Mon, 9 Jul 2007 12:19:28 -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 l69JJRn0020764; Mon, 9 Jul 2007 19:19:28 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); Mon, 9 Jul 2007 12:19:10 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 12:19:09 -0700 Message-ID: <46928A31.8090702@cisco.com> Date: Mon, 09 Jul 2007 15:19:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Zingerle, Meinrad" References: <9546CD0F7CC5EE48BCCE583AC4FC864D04057723@nets13ha.ww300.siemens.net> In-Reply-To: <9546CD0F7CC5EE48BCCE583AC4FC864D04057723@nets13ha.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 19:19:09.0956 (UTC) FILETIME=[06C3D440:01C7C25E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4052; t=1184008768; x=1184872768; 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=20ICE-16=3A=20some=20questions |Sender:=20; bh=qe1kcPbEQk+LLK/OS59VgsSvDnKDGAhhhG6Xr3gakeY=; b=ZioL9BfvPqxiP8llOBaNIuIoo7AcCiRLxN2Ta+D3BKRjzmLF4v4rbOyXMwYOGG9/IS/S6+ai +yBhMp6wq319YDr6aqBNSKIW13g9b+awUy+Qf0zCSJYEq0jSdTAnbqpR; 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: 9a2be21919e71dc6faef12b370c4ecf5 Cc: mmusic@ietf.org Subject: [MMUSIC] Re: ICE-16: some questions 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 Responses inline. Zingerle, Meinrad wrote: > #1) resolving role conflicts > "5.2. Determining Role > ... > Both Lite: The agent which generated the offer which started the ICE > processing MUST take the controlling role, and the other MUST > take > the controlled role. In this case, no connectivity checks are > ever sent. Rather, once the offer/answer exchange completes, > each > agent performs the processing described in Section 8 without > connectivity checks. It is possible that both agents will > believe > they are controlled or controlling. In the latter case, the > conflict is resolved through glare detection capabilities in the > signaling protocol carrying the offer/answer exchange. > .." > Why the "glare detection capabilities in the signaling protocol" can > resolve the role conflict in a Lite-Lite scenario but not in Full-Full > one? THey are far less efficient in the signaling case. Also in the signaling case you may have a transient period during which you send and receive media from different candidates. When both sides are ice-lite this is OK since there are no NAT. For full ICE this would fail. > > #2) candidates pairs for the same media stream and same foundation > "7.1.2.2.3. Updating Pair States > The agent sets the state of the pair that generated the check to > Succeeded. The success of this check might also cause the state > of > other checks to change as well. The agent MUST perform the > following > two steps: > 1. The agent changes the states for all other Frozen pairs > for the > same media stream and same foundation to Waiting. > Typically > these other pairs will have different component IDs but > not > always. > ..." > In which cases different candidate pairs with same fondation and > belonging to the same media may have the same component ID? If for some reason you have allocated two host candidates from the same interface but different ports. Largely useless but possible. > And in case there are two candidate pairs with same fondation and > component ID belonging to the same media: how does an ICE agent handle > it? As alternatives, or ..? Yes, alternatives as always. > > #3) Peer reflexive candidates > In my understanding peer reflexive candidates will be discovered in the > following two scenarios only: > a) the agent is behind a smmetric NAT > b) the agent belongs to private network that has more than one NAT exits > to the public network > > +---+ +-----+ +----+ > | L | ---+------|NAT-1|----------|STUN|---- ....... > +---+ | +-----+ +----+ . > | | > | +-----+ | +---+ > +------|NAT-2|---------------------------+--------| R | > +-----+ +---+ > > Is that incorrect or are there other scenarios where peer reflexive > candidates will be learned? (a) is the most common case. (b) is another case, yes. There is also additional cases. Philip Matthews some time back had uncovered some really nasty topologies where this could happen. He had a writeup on a website somewhere but I cannot find the URL. > And am I right, that in scenario a) STUN checks with the server > reflexive candidate of agent L wouldn't succeed? Right. > In case b) the selection of the path through the NAT-2 box is a routing > decision and I'm not sure whether using the server reflexive candidate > of agent L would work. Would it? Yes it should. 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 Mon Jul 09 16:14: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 1I7zd6-0007Cf-Vh; Mon, 09 Jul 2007 16:14:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zd5-0006wk-2B; Mon, 09 Jul 2007 16:14:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zd0-0004wG-KM; Mon, 09 Jul 2007 16:14:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2007 13:14:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACA0kkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="179087494:sNHT3047388453" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l69KEZDc016783; Mon, 9 Jul 2007 13:14:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l69KEZvv027138; Mon, 9 Jul 2007 20:14:35 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); Mon, 9 Jul 2007 13:14:35 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:14:35 -0700 Message-ID: <4692972F.8050003@cisco.com> Date: Mon, 09 Jul 2007 16:14:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:14:35.0111 (UTC) FILETIME=[C4B63770:01C7C265] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2604; t=1184012075; x=1184876075; 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:=20ICE-TCP=20issue=3A=20DTLS-SRTP=20over=20TCP? |Sender:=20; bh=quxDGBmUa2M4CCehx25LqvAtEFvuYerLTdfDiaoG7d4=; b=HMdMVb/0rx85ba016beR5m8NNR0aa5yvW3k3xHCtNhHJDVH96cWKq0SItSQGWOx9AnjoyUIt PWppvx6C9MeAGslkGC+neXd1LAguJq6nq95ml7+emPmLA2qB0uEe6cIL; 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "'avt@ietf.org'" Subject: [MMUSIC] ICE-TCP issue: DTLS-SRTP over TCP? 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 apologies for cc'ing AVT. However this is a cross-WG issue that impacts ICE and its usage with DTLS-SRTP. ICE-tcp: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-04.txt DTLS-srtp: http://www.ietf.org/internet-drafts/draft-ietf-avt-dtls-srtp-00.txt One of the really nice features of ICE-tcp is that you can offer, for an RTP-based media stream, either UDP or TCP candidates. The TCP ones are tried as a last resort, so that you get RTP over UDP when it works, and RTP over TCP when it doesn't. This choice is made dynamically based on the results of the connectivity checks. So, the interesting question is, what happens if the media is secure? Well, clearly if UDP is selected, we end up with DTLS-SRTP. In that case, the SDP offer would contain the fingerprint and setup attributes. What happens if ICE selects TCP instead? There are two things this could mean: 1. the media is secured using RTP over a TCP/TLS connection using RFC4571. This is *not* SRTP; the RTP packets are fully encrypted. 2. the media is secured using DTLS-SRTP, run over the RFC4571 shim that is ontop of TCP when ICE is in use. In this case, the media packets are SRTP and the RTP headers are in the clear as normal. In many ways, #2 is a far preferable solution. It means that the mechanism for securing the media, and the associated SDP parameters and their meaning, are independent of the transport protocol and apply for UDP or TCP. With #1, the agent needs to run different protocols (TLS vs. DTLS) for security, depending on the transport protocol selected. That also has interactions with SDP capability negotiation, and it gets really messy. So, #2 is what is specified in ice-tcp. However, AFAIK, DTLS-SRTP is not defined over TCP. I don't think it needs to change any per se; but it does need to be recognized as a valid mode. Similarly, even ignoring a mix of UDP and TCP candidates, if we are just offering TCP candidates, does the media get secured using #1 or #2? Do we allow both? Right now ICE-tcp is allowing both. However, I think its bad to have two ways of doing this. I'd rather settle on DTLS-SRTP over TCP as the one and only way of securing RTP over TCP. 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 Mon Jul 09 16:23: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 1I7zlc-0003sj-1J; Mon, 09 Jul 2007 16:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zlZ-0003om-VP for mmusic@ietf.org; Mon, 09 Jul 2007 16:23:29 -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 1I7zkZ-0005MF-6o for mmusic@ietf.org; Mon, 09 Jul 2007 16:23:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 13:22:24 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAAM2kkarR7MV/2dsb2JhbACKHw X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="7411543:sNHT711824460" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l69KMORD021810 for ; Mon, 9 Jul 2007 13:22:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l69KMKko027040 for ; Mon, 9 Jul 2007 20:22:24 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, 9 Jul 2007 13:22:23 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:22:23 -0700 Message-ID: <46929903.205@cisco.com> Date: Mon, 09 Jul 2007 16:22:27 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:22:23.0332 (UTC) FILETIME=[DBCB1240:01C7C266] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1109; t=1184012544; x=1184876544; 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:=20ICE-tcp=20issue=3A=20S-O=20candidates=20from=20TURN=20servers ? |Sender:=20; bh=FjEo3mfmZALx7dy8dw44ej/86cESIfSSOrDNm0tkW10=; b=XTYdiKPn0joCjFvTWu1mMG7NWk6NLhCOLhIt/SbLnLrPBgMCwotWzC2tLCg7EExoWX2o/0yk QkV08sqhBwZk+WUw+5RfXr26veavPzEsr4dvfwVYYIRoY23LQ7Puhdw85qtH9fGu+DDWRrS1Fh 1E2DpVvWFYbCiPMqn2Sq3LEbo=; 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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [MMUSIC] ICE-tcp issue: S-O candidates from TURN servers? 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 ICE-tcp has, for the last couple of revisions, instructed the client to obtain passive, active and S-O candidates from a TURN server. The open issue is, do we really need S-O candidates from a TURN server? If the TURN server is always north of the northernmost NAT (I.e., on the public Internet), then the answer is no. The S-O candidate is useless and passive is fine. Another issue is, if the TURN server is to provide S-O candidates, it would have to implement the nasty socket API stuff in the appendix of ice-tcp and it would be hard for it to figure out how many sockets to allocate. Also, more candidates takes more time to gather and check. So, I'd propose to remove S-O candidates from being gathered by the STUN server. Any objections? -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 Jul 09 16:28: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 1I7zqa-0006Yx-Ec; Mon, 09 Jul 2007 16:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zqZ-0006XR-3C for mmusic@ietf.org; Mon, 09 Jul 2007 16:28:39 -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 1I7zqV-0005jO-Nx for mmusic@ietf.org; Mon, 09 Jul 2007 16:28:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2007 13:28:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGs3kkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,518,1175497200"; d="scan'208"; a="7413428:sNHT13289790" 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 l69KSZhT029644 for ; Mon, 9 Jul 2007 13:28:35 -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 l69KSZmo016752 for ; Mon, 9 Jul 2007 20:28:35 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, 9 Jul 2007 13:28:34 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:28:34 -0700 Message-ID: <46929A76.8050003@cisco.com> Date: Mon, 09 Jul 2007 16:28:38 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 20:28:34.0710 (UTC) FILETIME=[B926DB60:01C7C267] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1311; t=1184012915; x=1184876915; 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:=20ICE-tcp=20issue=3A=20TURN=20shim=20vs.=20RFC=204571=20shim |Sender:=20; bh=loHNAwNJWneF8/A+076K8vyNvb4EkTAwYbwBdOc6t14=; b=toiudMm4TG1h0p+wSon9m36ljSO+JmmTl47LsQddlUXkJtRHI5QgeDkSLB6kgoaqi2XhOfbz T2caKyUhbFsiMuaa3ObTFUyFSk24197fSJjjdXaVGtKoC4SJGvOKT9ig; 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: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [MMUSIC] ICE-tcp issue: TURN shim vs. RFC 4571 shim 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 occurred to me that the TURN TCP shim (which allows for a type in addition to a length) might be a better choice for muxing STUN and application data over ice-tcp connections. RIght now, the RFC4571 shim is used, which provides only a length. The application data and STUN are demuxed based on the magic-cookie and other fields like FINGERPRINT, once they are extracted from the rfc4571 shim. This is not a deterministic demux, though it works with extremely high probability. But why not make it easy? If we just use the TURN framing, its deterministic. This would also eliminate the usage of two different framing protocols (one for the connection from the client to its turn server, and the other for ice-tcp run through that turn server). In fact we could move the turn framing into rfc3489bis and mandate it for usage with STUN over TCP, covering TURN and ICE. I don't see any technical drawbacks to this, except for it being a change. -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 Jul 09 20:02: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 1I83Bi-0004KP-2i; Mon, 09 Jul 2007 20:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I83Bh-0004KH-CW for mmusic@ietf.org; Mon, 09 Jul 2007 20:02:41 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I83Bc-0002Ys-VD for mmusic@ietf.org; Mon, 09 Jul 2007 20:02:41 -0400 Received: by wx-out-0506.google.com with SMTP id h27so958542wxd for ; Mon, 09 Jul 2007 17:02:36 -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:references:x-google-sender-auth; b=UYBxsx40M6wL7u1YM1gJrzqwgVfAyFTxpTh8tL7r0nBST6MH1NaNePXdLjem1WWtV3MJ6M6Az8Y+mfKLjsTmCtGnShsXLV4EkBPfYmwu559BsowQC7mUr+gAZq49XRwZwZ7qgwza7efq/Py6Br+hCFIP2gUsy0cAm2+LAM/n7l0= 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:references:x-google-sender-auth; b=UXHW5xV7+bFlUdxWbXid2tVvV0VVmeIgCeqcAt2BP87llKvv2MGcX43jI/nI4Xyfg8PyPtD5K+IiZtoO4XUIv+lgtEb8k9lN4OWCNajlhFKqZWJdAlPZsVOa4sqpFp4fIQkrjth1LBs3uXKiTQaRp65ooGfWT0OWObYKmPaMvwQ= Received: by 10.70.133.10 with SMTP id g10mr6689364wxd.1184025756679; Mon, 09 Jul 2007 17:02:36 -0700 (PDT) Received: by 10.70.98.9 with HTTP; Mon, 9 Jul 2007 17:02:36 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 20:02:36 -0400 From: "Adam Fisk" To: "Jonathan Rosenberg" Subject: Re: [MMUSIC] ICE-tcp issue: S-O candidates from TURN servers? In-Reply-To: <46929903.205@cisco.com> MIME-Version: 1.0 References: <46929903.205@cisco.com> X-Google-Sender-Auth: 4920566a66f2c3ff X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Content-Type: multipart/mixed; boundary="===============1474000563==" Errors-To: mmusic-bounces@ietf.org --===============1474000563== Content-Type: multipart/alternative; boundary="----=_Part_41121_24275541.1184025756217" ------=_Part_41121_24275541.1184025756217 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I support the change. I personally have no plans to create TURN servers behind NATs, although doing so is not a completely crazy idea. A p2p CDN where relays are sometimes required that wants to distribute load comes to mind. Nodes behind NATs that play well with TCP S-O could be TURN servers. That would be pretty neat, but I'd be surprised if anyone implemented it in the foreseeable future. Maybe you just make it a MAY implement? -Adam On 7/9/07, Jonathan Rosenberg wrote: > > ICE-tcp has, for the last couple of revisions, instructed the client to > obtain passive, active and S-O candidates from a TURN server. The open > issue is, do we really need S-O candidates from a TURN server? > > If the TURN server is always north of the northernmost NAT (I.e., on the > public Internet), then the answer is no. The S-O candidate is useless > and passive is fine. Another issue is, if the TURN server is to provide > S-O candidates, it would have to implement the nasty socket API stuff in > the appendix of ice-tcp and it would be hard for it to figure out how > many sockets to allocate. Also, more candidates takes more time to > gather and check. > > So, I'd propose to remove S-O candidates from being gathered by the STUN > server. Any objections? > > -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 > ------=_Part_41121_24275541.1184025756217 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I support the change.  I personally have no plans to create TURN servers behind NATs, although doing so is not a completely crazy idea.  A p2p CDN where relays are sometimes required that wants to distribute load comes to mind.  Nodes behind NATs that play well with TCP S-O could be TURN servers.  That would be pretty neat, but I'd be surprised if anyone implemented it in the foreseeable future.

Maybe you just make it a MAY implement?

-Adam


On 7/9/07, Jonathan Rosenberg <jdrosen@cisco.com > wrote:
ICE-tcp has, for the last couple of revisions, instructed the client to
obtain passive, active and S-O candidates from a TURN server. The open
issue is, do we really need S-O candidates from a TURN server?

If the TURN server is always north of the northernmost NAT (I.e., on the
public Internet), then the answer is no. The S-O candidate is useless
and passive is fine. Another issue is, if the TURN server is to provide
S-O candidates, it would have to implement the nasty socket API stuff in
the appendix of ice-tcp and it would be hard for it to figure out how
many sockets to allocate. Also, more candidates takes more time to
gather and check.

So, I'd propose to remove S-O candidates from being gathered by the STUN
server. Any objections?

-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

------=_Part_41121_24275541.1184025756217-- --===============1474000563== 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 --===============1474000563==-- From mmusic-bounces@ietf.org Mon Jul 09 20:06: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 1I83F4-0007lu-VO; Mon, 09 Jul 2007 20:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I83F4-0007lj-Bz for mmusic@ietf.org; Mon, 09 Jul 2007 20:06:10 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I83Ey-0002bm-KS for mmusic@ietf.org; Mon, 09 Jul 2007 20:06:08 -0400 Received: by wx-out-0506.google.com with SMTP id h27so959092wxd for ; Mon, 09 Jul 2007 17:06:04 -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:x-google-sender-auth; b=o46Z8sWK7K0wYf7DoGH5ToP+hAg6wPyVnBnOmsdAY3qpwzEnDNR8DG6t8/q2u3lVIlW7LJN/Jsq63+qhBKYOasPTZS/bbW/R3oCi7swQ0xyXhrx6gNY0ngnhQoS65ev3E7b3rn0tiWcBhigKEboTtwz05LQNkU/FUzKjkaVgeN0= 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:x-google-sender-auth; b=ENM5syf6eCAShY24uvo2cGnDd0UdJ0CZ5iHsm4FKaT6vhXas/agkUzCT5p9VLOnkJzEEMZZk6h32vHXHNzfoMR4bp9pXLtiWrFBx1PpfSEUpgdx7i8kpiOFvJFEeRWGqS4jjvBByBetaB1z40yPZuQeWMrkYC8b7YHUwlZDoryI= Received: by 10.70.72.11 with SMTP id u11mr6705763wxa.1184025964422; Mon, 09 Jul 2007 17:06:04 -0700 (PDT) Received: by 10.70.98.9 with HTTP; Mon, 9 Jul 2007 17:06:04 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 20:06:04 -0400 From: "Adam Fisk" To: "IETF MMUSIC WG" MIME-Version: 1.0 X-Google-Sender-Auth: ce542c5e6b29a288 X-Spam-Score: 1.8 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [MMUSIC] ICE-TCP-04 REUSEPORT 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="===============1979341065==" Errors-To: mmusic-bounces@ietf.org --===============1979341065== Content-Type: multipart/alternative; boundary="----=_Part_41141_14191181.1184025964395" ------=_Part_41141_14191181.1184025964395 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Saikat mentioned a bit ago that his pseudocode should have used "REUSEADDR" instead of "REUSEPORT". -Adam ------=_Part_41141_14191181.1184025964395 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Saikat mentioned a bit ago that his pseudocode should have used "REUSEADDR" instead of "REUSEPORT". 

-Adam
------=_Part_41141_14191181.1184025964395-- --===============1979341065== 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 --===============1979341065==-- From mmusic-bounces@ietf.org Tue Jul 10 04:47: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 1I8BNQ-0000Wp-Fp; Tue, 10 Jul 2007 04:47:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8BNB-00005X-Uc for mmusic@ietf.org; Tue, 10 Jul 2007 04:47:06 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8BMw-00073H-F6 for mmusic@ietf.org; Tue, 10 Jul 2007 04:47: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 l6A8jRik004280; Tue, 10 Jul 2007 11:46:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 11:45:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 11:45:35 +0300 Received: from hed050122.research.nokia.com ([172.21.50.122]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 11:45:35 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" , mmusic@ietf.org, magnus.westerlund@ericsson.com, thomas.zeng@gmail.com Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Date: Tue, 10 Jul 2007 11:45:29 +0300 User-Agent: KMail/1.9.6 References: <064801c7c23d$cbe4c6b0$c3f0200a@amer.cisco.com> In-Reply-To: <064801c7c23d$cbe4c6b0$c3f0200a@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: <200707101145.30126.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 10 Jul 2007 08:45:35.0121 (UTC) FILETIME=[AE921810:01C7C2CE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Monday 09 July 2007 18:28:26 you wrote: > However, I would like to understand the difference between > the "Symmetric RTP Variant" (discussed in the draft) and > ICE-lite. I think they are similar, but I admit that I > don't fully grasp what all "symmetric RTP variant" might > be doing when it is fully specified. > > If ICE-Lite and "Symmetric RTP Variant" are similar, would > you still want "Symmetric RTP Variant"? I suspect ICE-Lite requires a bunch of state be kept and intricate processi= ng=20 be done on both sides. That's really overkill when all we need for NATed=20 client to public server is a three-way handshake, =E0 la TCP (though likely= =20 with more entropy), and client-to-server keep-alives (RTCP RRs, I suppose). I may have gotten ICE-Lite wrong though. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 10 11:57: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 1I8I5O-0005uw-4S; Tue, 10 Jul 2007 11:57:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8I5K-0005ui-5X for mmusic@ietf.org; Tue, 10 Jul 2007 11:57:07 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8I55-0000Aq-Lf for mmusic@ietf.org; Tue, 10 Jul 2007 11:57:06 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D60572048D; Tue, 10 Jul 2007 17:56:34 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-fe-4693ac32bc80 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BAE602046F; Tue, 10 Jul 2007 17:56:34 +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, 10 Jul 2007 17:56:34 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 17:56:33 +0200 Message-ID: <4693AC30.2030400@ericsson.com> Date: Tue, 10 Jul 2007 17:56:32 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt References: <064801c7c23d$cbe4c6b0$c3f0200a@amer.cisco.com> <200707101145.30126.remi.denis-courmont@nokia.com> In-Reply-To: <200707101145.30126.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 10 Jul 2007 15:56:33.0894 (UTC) FILETIME=[E399B860:01C7C30A] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: thomas.zeng@gmail.com, mmusic@ietf.org, ext 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 R=E9mi Denis-Courmont skrev: > On Monday 09 July 2007 18:28:26 you wrote: >> However, I would like to understand the difference between >> the "Symmetric RTP Variant" (discussed in the draft) and >> ICE-lite. I think they are similar, but I admit that I >> don't fully grasp what all "symmetric RTP variant" might >> be doing when it is fully specified. >> >> If ICE-Lite and "Symmetric RTP Variant" are similar, would >> you still want "Symmetric RTP Variant"? >=20 > I suspect ICE-Lite requires a bunch of state be kept and intricate proc= essing=20 > be done on both sides. That's really overkill when all we need for NATe= d=20 > client to public server is a three-way handshake, =E0 la TCP (though li= kely=20 > with more entropy), and client-to-server keep-alives (RTCP RRs, I suppo= se). >=20 > I may have gotten ICE-Lite wrong though. >=20 Thanks for the comments. I will try to incorporate the comments in the next version. However, I=20 do like to point out two things. There exist a consensus on using ICE=20 type of mechanism. It simply is that we haven't come to the point where=20 we actually have specified the mechanism. So if you like to tear up=20 this, you better have good arguments. Secondly, is that ICE really helps with the DDoS security issue we do=20 have with RTSP today. Utilizing public streaming servers to deliver=20 content to an attackers target get substantially harder with checks in=20 the server to client direction. Sure, you could define mechanism that=20 include these checks also. But, then in reality I don't see them being=20 easier than ICE in any sense. Also please remember that streamin server=20 with a public IP address only needs a single candidate. That cuts down=20 the number of checks and everything substantially. While still having a=20 mechanism that can be made to work when deploying servers behind NATs.=20 It also leverage the existing specifications rather than rewriting things= . 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 Jul 10 13:53: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 1I8Jtp-0005UW-6q; Tue, 10 Jul 2007 13:53:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Jtn-0005SK-H2 for mmusic@ietf.org; Tue, 10 Jul 2007 13:53:19 -0400 Received: from m5tmail1.m5t.com ([207.134.65.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Jtl-0004Fs-Ic for mmusic@ietf.org; Tue, 10 Jul 2007 13:53:19 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jul 2007 13:53:17 -0400 Message-ID: <6EF4CC794ECF2B409390605FDEA9012225B5B6@m5tmail1.m5t.com> X-MS-Has-Attach: X-MIMEOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: New attributes type values Thread-Index: AcfDGzJCXBZXWnDOS4erQIH2/KzRIg== From: "Guy Lepine" To: "IETF MMUSIC WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [MMUSIC] New attributes type values 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="===============1501431844==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1501431844== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C31B.3163FA9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C31B.3163FA9A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, While implementing the ICE connectivity check by reading section 18 of draft-ietf-mmusic-ice-16, I stumbled upon the (small) difficulty of finding the ICE-CONTROLLED and ICE-CONTROLLING attributes type values. I eventually found them in section 19.2. I suggest to either adding their type values in section 18.5 as it is done for the PRIORITY and USE-CANDIDATE attributes or to refer all of them to section 19.2. Personally, I would prefer the former option. I also suggest referring to attribute type values instead of attribute values and to attribute values instead of attribute contents, so it would be more consistent with section 14 of draft-ietf-behave-rfc3489bis-07. Regards, Guy ------_=_NextPart_001_01C7C31B.3163FA9A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New attributes type values

Hi Jonathan,

While implementing the ICE connectivity check by reading section 18 = of draft-ietf-mmusic-ice-16, I stumbled upon the (small) difficulty of = finding the ICE-CONTROLLED and ICE-CONTROLLING attributes type values. I = eventually found them in section 19.2. I suggest to either adding their = type values in section 18.5 as it is done for the PRIORITY and = USE-CANDIDATE attributes or to refer all of them to section 19.2. = Personally, I would prefer the former option.

I = also suggest referring to attribute type values instead of attribute = values and to attribute values instead of attribute contents, so it = would be more consistent with section 14 of = draft-ietf-behave-rfc3489bis-07.


Regards,

Guy

------_=_NextPart_001_01C7C31B.3163FA9A-- --===============1501431844== 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 --===============1501431844==-- From mmusic-bounces@ietf.org Tue Jul 10 16:15: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 1I8M7F-0006Hv-5t; Tue, 10 Jul 2007 16:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M6w-0005mH-BI; Tue, 10 Jul 2007 16:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8M6v-0008Jt-RG; Tue, 10 Jul 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 825FE26EB3; Tue, 10 Jul 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8M6v-0004Vs-DO; Tue, 10 Jul 2007 16:15:01 -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: Tue, 10 Jul 2007 16:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-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 : SDP Capability Negotiation Author(s) : F. Andreasen Filename : draft-ietf-mmusic-sdp-capability-negotiation-06.txt Pages : 77 Date : 2007-7-10 The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP and its current extensions however do not define how to negotiate one or more alternative transport protocols (e.g. RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback, negotiate use of different keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The solution provided in this document provides a general SDP Capability Negotiation framework. It also defines specifically how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and media formats) may be provided in other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-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-sdp-capability-negotiation-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-sdp-capability-negotiation-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-7-10150711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-capability-negotiation-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10150711.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 Tue Jul 10 16:16: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 1I8M8K-0008W7-7R; Tue, 10 Jul 2007 16:16:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M7W-0006q7-Cm; Tue, 10 Jul 2007 16:15:38 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8M7W-0000hg-5B; Tue, 10 Jul 2007 16:15:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 525AB17623; Tue, 10 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8M6v-0004Wq-Ro; Tue, 10 Jul 2007 16:15:01 -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: Tue, 10 Jul 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-securityprecondition-04.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 : Security Preconditions for Session Description Protocol (SDP) Media Streams Author(s) : F. Andreasen, D. Wing Filename : draft-ietf-mmusic-securityprecondition-04.txt Pages : 16 Date : 2007-7-10 This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-securityprecondition-04.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-securityprecondition-04.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-securityprecondition-04.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-7-10155118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-securityprecondition-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-securityprecondition-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10155118.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 Tue Jul 10 16:33: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 1I8MP7-00065H-Np; Tue, 10 Jul 2007 16:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8MP5-000654-Pg for mmusic@ietf.org; Tue, 10 Jul 2007 16:33:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8MP1-0002KN-7z for mmusic@ietf.org; Tue, 10 Jul 2007 16:33:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2007 13:33:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKeJk0arR7PD/2dsb2JhbACIUZ8C X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="179758063:sNHT70408854" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6AKXgsh022722 for ; Tue, 10 Jul 2007 13:33:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6AKXgvv020496 for ; Tue, 10 Jul 2007 20:33:42 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, 10 Jul 2007 13:33:42 -0700 Received: from [10.21.122.250] ([10.21.122.250]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 13:33:42 -0700 Message-ID: <4693ED2D.3050707@cisco.com> Date: Tue, 10 Jul 2007 16:33:49 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 20:33:42.0233 (UTC) FILETIME=[9ADCE490:01C7C331] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3317; t=1184099622; x=1184963622; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20SDPCapNeg=20version=2006=20is=20here |Sender:=20; bh=iOYAalGWiTMb3Hm6OXfoVnioaReav1CmLit6QGZHuxI=; b=Z7RLExYD6yzt6xWuoC2ToTD3ksAVOOAZxlWhFtZeAq0Ai29jDmoQU4X6FVQZKMTl+iomVN4y 4paRWtG7e28JfA32k5yfJbg1KUP0AnmS8vgirFIUDgIIk97sUF8T0zF3; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [MMUSIC] SDPCapNeg version 06 is here 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 -06 version of the SDP Capability Negotiation document is now available at http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-06.txt I appreciate all the feedback and comments provided on the -05 version and I believe this version addresses all of those as discussed in Prague and subsequently on the mailing list. At this point, I am not aware of any open issues and hence believe we should be ready to issue a Working Group Last Call. The changes in the -06 version are (from Section 8.1): o Added additional background text on terminology used, and a new section on the negotiation model. o Allowed for session-level attribute capabilities to contain media-level only attributes, albeit the base framework does not define (or allow) them to be used in a potential configuration (extensions may change that) o Disallowing multiple "a=tcap" attributes at the session-level and/or on a per media description basis; at most one at the session-level and per media description now. o Changed the "a=pcfg" attribute to make a potential configuration list optional in order to allow for the actual configuration to be referenced. o Removed the ability to delete and replace individual attributes from the actual configuration SDP. o Introduced the notion of mandatory and optional attribute capabilities in a potential configuration and updated the "a=pcfg" attribute and associated procedures accordingly. o Specified that mandatory attribute capabilities and the transport protocol (if any) from a potential configuration need to be supported in order to select that potential configuration. Offer/answer procedures updated accordingly as well. o Noted potential interaction and synchronization issues with use of session-level attributes and attribute capabilities and added recommendation to avoid use of session-level attributes when possible. o Fixed error in "a=acfg" grammar (missing config-number) and updated attribute definition in accordance with the "a=pcfg" attribute changes. o Updated text associated with processing media before answer to allow for playing out garbage or discard until answer received. Additional detail on alternative solutions provided as well. o Added recommendation to send back answer SDP as soon as possible, when a potential configuration different from the actual configuration has been chosen. o Added new section on interactions with SIP option tags. o Added new section on dealing with large number of potential configurations. o Added new section on SDP capability negotiation and intermediaries. o Updated examples in accordance with other changes and to illustrate use of mandatory and optional attribute capabilities in a potential configuration. o Updated security considerations to address potential denial of service attack caused by large number of potential configurations. o Various editorial updates throughout. Please let me know if you have any questions, comments, feedback, etc. Thanks -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 10 23:39: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 1I8T37-00011x-KB; Tue, 10 Jul 2007 23:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8T36-00011o-CA for mmusic@ietf.org; Tue, 10 Jul 2007 23:39:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8T32-0003Pl-1Y for mmusic@ietf.org; Tue, 10 Jul 2007 23:39:32 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Jul 2007 20:39:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO/tk0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,524,1175497200"; d="scan'208"; a="179935727:sNHT29406681" 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 l6B3dRjt012584 for ; Tue, 10 Jul 2007 20:39:27 -0700 Received: from [128.107.147.32] (dhcp-128-107-147-32.cisco.com [128.107.147.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6B3dRmo015407 for ; Wed, 11 Jul 2007 03:39:27 GMT Message-ID: <469450EF.1030205@cisco.com> Date: Tue, 10 Jul 2007 20:39:27 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2151; t=1184125167; x=1184989167; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20RTSP-SIP=20mismatch |Sender:=20; bh=NA6LaJ2J35ywf+S+2dT4hfYMJ0r6VvfXRItQ4UbyZGE=; b=lY4WdVLNmV1VUK0cbUnOjF3I8mYjrKd1YWQ9sfCgDM1XBs+B7btj0hh27Spbnr4FVqlMac9K IuQ6gpSWf5bb0YGDYUs4yAndAP7o+y8gjoVh58FlG757lOVQtgRnN+Dp; Authentication-Results: sj-dkim-3; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [MMUSIC] RTSP-SIP mismatch 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 wonder if anyone has run into the following problem related to a mismatch between RTSP and SIP in a case where a 3rd party controller sets up a SIP dialog with a UA and wants to tell an RTSP server to send media to the UA. The call flow might look like the this: RTSP server controller SIP UA | | | |(1) RTSP DESCRIBE | | |<------------------| | |(2) 200 (SDP) | | |------------------>| | | |(3) INVITE (offer) | | |------------------>| | |(4) 200 (answer) | | |<------------------| | |(5) ACK | | |------------------>| |(6) RTSP SETUP | | |<------------------| | |(7) 200 | | |------------------>| | |(8) RTSP PLAY | | |<------------------| | |(9) 200 | | |------------------>| | |(10) RTP | | |.......................................| | | | | | | The specific problem is that the SIP UA says in the SDP answer carried in the 200 response that for some media stream it wants to receive RTP with payload type 96, say, but the RTSP server insists on sending RTP with payload type 126. According to the SIP offer/answer model the SIP UA gets to say what it wants to receive but AFAIK RTSP doesn't let the client (the controller in this example) pass these instructions on to the RTSP server, at least not for the payload type. Am I missing something in the RTP spec? I browsed through rfc2326bis without seeing it addressed but it seems like a valid scenario. Thanks, Anders _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 11 03:02: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 1I8WCt-0006Ye-KL; Wed, 11 Jul 2007 03:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WCr-0006YU-Of for mmusic@ietf.org; Wed, 11 Jul 2007 03:01:49 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8WCe-0006yR-06 for mmusic@ietf.org; Wed, 11 Jul 2007 03:01:49 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id l6B71XL3009288; Wed, 11 Jul 2007 09:01:33 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6B71VYg023857; Wed, 11 Jul 2007 09:01:32 +0200 Received: from nets13ha.ww300.siemens.net ([158.226.250.77]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 09:01:31 +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 Date: Wed, 11 Jul 2007 09:01:28 +0200 Message-ID: <9546CD0F7CC5EE48BCCE583AC4FC864D04057AFC@nets13ha.ww300.siemens.net> In-Reply-To: <469288EE.2070004@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-16 Comments Thread-Index: AcfCXWFYLfecYFwbS9ST3tefcfrA9QBKRFtw References: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> <469288EE.2070004@cisco.com> From: "Zingerle, Meinrad" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 11 Jul 2007 07:01:31.0608 (UTC) FILETIME=[4F8F5D80:01C7C389] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070711090133-46D93BB0-0CB90575/0-0/0-15 X-purgate-size: 5569/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: mmusic@ietf.org Subject: [MMUSIC] AW: ICE-16 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: , Errors-To: mmusic-bounces@ietf.org Jonathan, thanks for your response.=20 Just one remark regarding your answer to #3): Section "10.1.2. Receiving a Request or Indication" of rfc3489bis says: ".... o If the message does not contain both a MESSAGE-INTEGRITY and a USERNAME attribute: * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 400. o If the USERNAME does not contain a username value currently valid within the server: * If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401. ..." Thus, in case an agent receives a STUN Binding request before the SDP answer containing the of the answerer, I would expect that the agent rejects this Binding request due to unknown username. However, I think you have already a solution therefore ;-) Regards, Meinrad > Rosenberg, Jonathan wrote: >=20 > Thanks for the comments. Responses inline. >=20 > Zingerle, Meinrad wrote: > > #1)Section 4.2. states that a ICE-Lite agent should allocate "one=20 > > IPv4 candidate, one link local and one global IPv6 address". > > =20 > > Since a Router MUST NOT forward packets with a link-local source=20 > > and/or destination address (see RFC 3513, section 2.5.6=20 > Local-Use IPv6=20 > > Unicast > > Addresses) and RFC3484 prefers smaller scopes over larger scopes, I=20 > > guess the usage of link-local addresses in this context may be=20 > > problematic (each agent would have to check if its partner=20 > is really=20 > > on the same link). > > Thus, I would suggest that an ICE-Lite agent allocates a link-local=20 > > IPv6 address only in that case there is no IPv6 address of global=20 > > scope available. > > Or even disallow the usage of link-local addresses at since their=20 > > applicability in this context is very limited. >=20 > Right, good point. They can be used with full ICE since a=20 > connectivity check is performed to validate it. But not with=20 > ICE-lite since there may not be connectivity checks. >=20 > >=20 > > #2) Section 8.2.2 > > "... Two candidates are paired up when=20 > > they are for the same component, utilize the same=20 > transport protocol > > (UDP in this specification), and are from the same IP=20 > address family > > (IPv4 or IPv6)." > > In my understanding addresses of local scope (e.g. IPv6 linl-local,=20 > > auto-configured IPv4 169.254.0.0/16) should not be paired=20 > with those=20 > > of global scope. >=20 > Hmm, well if two IPv6 hosts are on the same link, I believe=20 > one can send from its link local address to the global v6=20 > address of the other host.=20 > So it should work in those cases. When it doesn't work, the=20 > ICE checks will fail. So I think it does make sense, in the=20 > case of full ICE at least (link locals are only used for full=20 > ICE per your above comment). >=20 > >=20 > >=20 > > #3)For clearness I would suggest to add the following sentence to > > section 7.2. STUN Server Procedures > > "The agent MUST include the USERNAME and MESSAGE-INTEGRITY=20 > attributes in > > its responses to > > connectivity checks." > > In my understanding that would be in line with > > "7.1.1.4. Forming Credentials > > ... > > Agent L included a username fragment of LFRAG for its > > candidates, and > > a password of LPASS. Agent R provided a username fragment of > > RFRAG > > and a password of RPASS. A connectivity check from L to R (and > > its > > response of course) utilize the username RFRAG:LFRAG and a > > password > > of RPASS. A connectivity check from R to L (and its response) > > utilize the username LFRAG:RFRAG and a password of LPASS." > > and=20 > > "17.1. Attacks on Connectivity Checks (page 84, 2nd paragraph) > > ... Fortunately, this attack is mitigated completely > > through the STUN message integrity mechanism. The attacker needs > > to > > inject a fake response, and in order for this response to be > > processed, the attacker needs the password. ..." >=20 > This text has been reworked in its alignment with the newly=20 > revised and=20 > I think much clearer rfc3489bis. rfc3489bis fully specifies=20 > this short=20 > term credential mechanism, so ICE does not need to say anything about=20 > when to include these attributes. >=20 > >=20 > > #4) 7.2. STUN Server Procedures > > "... It is possible (and in fact > > very likely) that an offerer 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 > > Is it correct that at time of receiving the Binding Request=20 > the agent > > cannot send the response (due to lack of and=20 > of > > the answerer)?=20 >=20 > No, it can send a response. It has the username (copied from the=20 > request), and the password is its own password. I added a sentence to=20 > clarify this. >=20 > Thanks, > 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 From mmusic-bounces@ietf.org Wed Jul 11 03:22: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 1I8WWZ-0002a8-VF; Wed, 11 Jul 2007 03:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WWX-0002Zt-5u for mmusic@ietf.org; Wed, 11 Jul 2007 03:22:09 -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 1I8WWT-0007Ki-KO for mmusic@ietf.org; Wed, 11 Jul 2007 03:22:09 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6B7LmP9008220; Wed, 11 Jul 2007 10:21:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:21:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:21:43 +0300 Received: from hed050115.research.nokia.com ([172.21.50.115]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:21:42 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Magnus Westerlund" Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt Date: Wed, 11 Jul 2007 10:21:38 +0300 User-Agent: KMail/1.9.6 References: <064801c7c23d$cbe4c6b0$c3f0200a@amer.cisco.com> <200707101145.30126.remi.denis-courmont@nokia.com> <4693AC30.2030400@ericsson.com> In-Reply-To: <4693AC30.2030400@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707111021.38161.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jul 2007 07:21:42.0943 (UTC) FILETIME=[21926AF0:01C7C38C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: thomas.zeng@gmail.com, mmusic@ietf.org, ext 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 Hello, On Tuesday 10 July 2007 18:56:32 ext Magnus Westerlund wrote: > I will try to incorporate the comments in the next version. However, I > do like to point out two things. There exist a consensus on using ICE > type of mechanism. It simply is that we haven't come to the point where > we actually have specified the mechanism. So if you like to tear up > this, you better have good arguments. Using full ICE on the server only makes sense if you specify some traversal= =20 mechanism for the control connection in the first place. Using ICE-Lite will indeed make the whole thing "relatively" simple on the= =20 server. On the client side, it will only simplify things if clients are=20 allowed to only support ICE-Lite servers: In that case, the client can assu= me=20 it is the controlling node. Most importantly, there is no need for the clie= nt=20 to signal its candidates to the server (they'd be ignored anyway), so I wou= ld=20 assume there is no need to "extend" the encoding already specified in ICE:= =20 server uses SDP encoding, client does not use any encoding at all... I am only worried that people may want to use ICE -particularly full ICE- w= ith=20 unrealistic hopes (such as a satisfactory success rate for NATed RTSP=20 servers). In that case, we may end up with something overly complex with=20 little benefits. If the RTSP client happens to be a SIP client too, using I= CE=20 is surely good. But many RTSP clients are media players rather than=20 softphones, and they surely do not have SIP. > Secondly, is that ICE really helps with the DDoS security issue we do > have with RTSP today. I totally agree. I was trying to point out that any three-way handshake (wi= th=20 a pseudo-random ID into it) solves this too. > Utilizing public streaming servers to deliver content to an attackers tar= get > get substantially harder with checks in the server to client direction. I do hope that non-ICE RTSP servers refuse to stream to a destination addre= ss=20 that does not match the source of the control connection (so it can leverag= e=20 the TCP three-way handshake as a basic security check), unless there is som= e=20 other reason to trust the client. > Sure, you could define mechanism that=20 > include these checks also. But, then in reality I don't see them being > easier than ICE in any sense. If the mechanism that is to be proposed is that easy, I am fine with it. If= =20 it's ICE-based, all the better for those who ship both SIP and RTSP (such a= s=20 my employer's devices) :-) > Also please remember that streamin server=20 > with a public IP address only needs a single candidate. That cuts down > the number of checks and everything substantially. While still having a > mechanism that can be made to work when deploying servers behind NATs. > It also leverage the existing specifications rather than rewriting things. [To me, specifications reuse/factorization is of very little value compared= to=20 sound design and ease of implementation. I believe implementation and=20 operational costs to be largely superior to specification ones. That's a=20 personnal view though.] Best regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 11 03:29: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 1I8Wdd-00034I-4c; Wed, 11 Jul 2007 03:29:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WdY-00033l-IE for mmusic@ietf.org; Wed, 11 Jul 2007 03:29:27 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8WdJ-0000Cs-46 for mmusic@ietf.org; Wed, 11 Jul 2007 03:29:24 -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 l6B7SN16013787; Wed, 11 Jul 2007 10:28:49 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:28:44 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:28:43 +0300 Received: from hed050115.research.nokia.com ([172.21.50.115]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:28:43 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org, "ext Jonathan Rosenberg" Subject: Re: [MMUSIC] ICE-tcp issue: TURN shim vs. RFC 4571 shim Date: Wed, 11 Jul 2007 10:28:38 +0300 User-Agent: KMail/1.9.6 References: <46929A76.8050003@cisco.com> In-Reply-To: <46929A76.8050003@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707111028.38630.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jul 2007 07:28:43.0428 (UTC) FILETIME=[1C335640:01C7C38D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Monday 09 July 2007 23:28:38 ext Jonathan Rosenberg wrote: > It occurred to me that the TURN TCP shim (which allows for a type in > addition to a length) might be a better choice for muxing STUN and > application data over ice-tcp connections. RIght now, the RFC4571 shim > is used, which provides only a length. The application data and STUN are > demuxed based on the magic-cookie and other fields like FINGERPRINT, > once they are extracted from the rfc4571 shim. This is not a > deterministic demux, though it works with extremely high probability. By the way, does RFC4571 work with DTLS(-SRTP) along with STUN? I know it=20 works with SRTP, and I know it works with STUN and RTP, but what about DTLS= ,=20 STUN and (S)RTP at the same time? Does the first two bits trick still work? If it does not, there is little questioning TURN shim should be used rather= =20 than Framed RTP. In any case, I'd tend to favor using RFC4571 only without STUN (incl. w/o I= CE)=20 and only TURN shim with STUN (incl. with ICE) from an implementation=20 perspective. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 11 03:40: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 1I8WoR-0006tc-Bf; Wed, 11 Jul 2007 03:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WoQ-0006oE-2z for mmusic@ietf.org; Wed, 11 Jul 2007 03:40:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8WoM-0007iV-65 for mmusic@ietf.org; Wed, 11 Jul 2007 03:40:38 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 77A2F20111; Wed, 11 Jul 2007 09:40:33 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-f0-46948971ec04 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 499F8203FA; Wed, 11 Jul 2007 09:40:33 +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, 11 Jul 2007 09:40:32 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:40:32 +0200 Message-ID: <46948970.8020505@ericsson.com> Date: Wed, 11 Jul 2007 09:40:32 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-nat-evaluation-00.txt References: <064801c7c23d$cbe4c6b0$c3f0200a@amer.cisco.com> <200707101145.30126.remi.denis-courmont@nokia.com> <4693AC30.2030400@ericsson.com> <200707111021.38161.remi.denis-courmont@nokia.com> In-Reply-To: <200707111021.38161.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 11 Jul 2007 07:40:32.0474 (UTC) FILETIME=[C2D32BA0:01C7C38E] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: thomas.zeng@gmail.com, mmusic@ietf.org, ext 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, I hear your arguments, and I think ICE for RTSP will not in reality=20 become too complex. I think there are a number of ways to cut down the=20 percieved complexities of ICE in an RTSP case. Using STUN for the connectiviy checks seems to me be beneficial from the=20 point of not specifying yet another alternative. Implementations can be=20 reused, etc. Also it has the benefit of being more media transport=20 protocol agnostic than most alternatives, like building something into=20 RTP or RTCP. However, the only node I am willing to make assumptions about knowing=20 where they really are deployed are servers. A server with public IP=20 address can have a configuration option that makes them cut down the=20 croft. I see two benefits from them. A single candidate and the=20 possibility to only use triggerd checks. If the server indicates this=20 the client can basically utilzie a single candidate itself. The main=20 issue with this is the signalling flow for RTSP that makes the=20 specification of such optimzations more difficult. However, we currently are at a stage where we need to flesh out ICE for=20 RTSP into something that actually will work. Cheers Magnus R=E9mi Denis-Courmont skrev: > Hello, >=20 > On Tuesday 10 July 2007 18:56:32 ext Magnus Westerlund wrote: >> I will try to incorporate the comments in the next version. However, I >> do like to point out two things. There exist a consensus on using ICE >> type of mechanism. It simply is that we haven't come to the point wher= e >> we actually have specified the mechanism. So if you like to tear up >> this, you better have good arguments. >=20 > Using full ICE on the server only makes sense if you specify some trave= rsal=20 > mechanism for the control connection in the first place. >=20 > Using ICE-Lite will indeed make the whole thing "relatively" simple on = the=20 > server. On the client side, it will only simplify things if clients are= =20 > allowed to only support ICE-Lite servers: In that case, the client can = assume=20 > it is the controlling node. Most importantly, there is no need for the = client=20 > to signal its candidates to the server (they'd be ignored anyway), so I= would=20 > assume there is no need to "extend" the encoding already specified in I= CE:=20 > server uses SDP encoding, client does not use any encoding at all... >=20 > I am only worried that people may want to use ICE -particularly full IC= E- with=20 > unrealistic hopes (such as a satisfactory success rate for NATed RTSP=20 > servers). In that case, we may end up with something overly complex wit= h=20 > little benefits. If the RTSP client happens to be a SIP client too, usi= ng ICE=20 > is surely good. But many RTSP clients are media players rather than=20 > softphones, and they surely do not have SIP. >=20 >> Secondly, is that ICE really helps with the DDoS security issue we do >> have with RTSP today. >=20 > I totally agree. I was trying to point out that any three-way handshake= (with=20 > a pseudo-random ID into it) solves this too. >=20 >> Utilizing public streaming servers to deliver content to an attackers = target >> get substantially harder with checks in the server to client direction= . >=20 > I do hope that non-ICE RTSP servers refuse to stream to a destination a= ddress=20 > that does not match the source of the control connection (so it can lev= erage=20 > the TCP three-way handshake as a basic security check), unless there is= some=20 > other reason to trust the client. >=20 >> Sure, you could define mechanism that=20 >> include these checks also. But, then in reality I don't see them being >> easier than ICE in any sense. >=20 > If the mechanism that is to be proposed is that easy, I am fine with it= . If=20 > it's ICE-based, all the better for those who ship both SIP and RTSP (su= ch as=20 > my employer's devices) :-) >=20 >> Also please remember that streamin server=20 >> with a public IP address only needs a single candidate. That cuts down >> the number of checks and everything substantially. While still having = a >> mechanism that can be made to work when deploying servers behind NATs. >> It also leverage the existing specifications rather than rewriting thi= ngs. >=20 > [To me, specifications reuse/factorization is of very little value comp= ared to=20 > sound design and ease of implementation. I believe implementation and=20 > operational costs to be largely superior to specification ones. That's = a=20 > personnal view though.] >=20 > Best regards, >=20 --=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 From mmusic-bounces@ietf.org Wed Jul 11 03:46: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 1I8WuL-0001Lu-8l; Wed, 11 Jul 2007 03:46:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8WuJ-0001LY-4t for mmusic@ietf.org; Wed, 11 Jul 2007 03:46:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8WuF-0007v9-Cj for mmusic@ietf.org; Wed, 11 Jul 2007 03:46:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C322820711; Wed, 11 Jul 2007 09:46:38 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-23-46948ade1961 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9FA5C212E6; Wed, 11 Jul 2007 09:46:38 +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, 11 Jul 2007 09:46:38 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:46:38 +0200 Message-ID: <46948ADE.10407@ericsson.com> Date: Wed, 11 Jul 2007 09:46:38 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Anders Kristensen , "mmusic (E-mail)" Subject: Re: [MMUSIC] RTSP-SIP mismatch References: <469450EF.1030205@cisco.com> In-Reply-To: <469450EF.1030205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 07:46:38.0052 (UTC) FILETIME=[9CB9F240:01C7C38F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Hi Anders, I think you are getting into places where specification hasn't gone. Interaction between SIP and RTSP are not really specified. RTSP has a model where media configuration is done by the server saying something and the client has the choice of taking it or leaving it. There is no negotiation of media parameters. The only thing that I know of that can affect the SDP is that the describe included a capability description of the client. That allows the server to tailor the session description to the clients capabilities. But that wouldn't solve the issue you have. This is an collison in regards to the models used for media configuration that I don't think have an easy answer. The only way to resolve this would be to indicate to the client in the Invite SDP that these sendonly streams can't be changed in regards to media configuration so take it or leave it. Magnus Anders Kristensen skrev: > I wonder if anyone has run into the following problem related to a > mismatch between RTSP and SIP in a case where a 3rd party controller > sets up a SIP dialog with a UA and wants to tell an RTSP server to send > media to the UA. The call flow might look like the this: > > RTSP server controller SIP UA > | | | > |(1) RTSP DESCRIBE | | > |<------------------| | > |(2) 200 (SDP) | | > |------------------>| | > | |(3) INVITE (offer) | > | |------------------>| > | |(4) 200 (answer) | > | |<------------------| > | |(5) ACK | > | |------------------>| > |(6) RTSP SETUP | | > |<------------------| | > |(7) 200 | | > |------------------>| | > |(8) RTSP PLAY | | > |<------------------| | > |(9) 200 | | > |------------------>| | > |(10) RTP | | > |.......................................| > | | | > | | | > > The specific problem is that the SIP UA says in the SDP answer carried > in the 200 response that for some media stream it wants to receive RTP > with payload type 96, say, but the RTSP server insists on sending RTP > with payload type 126. > > According to the SIP offer/answer model the SIP UA gets to say what it > wants to receive but AFAIK RTSP doesn't let the client (the controller > in this example) pass these instructions on to the RTSP server, at least > not for the payload type. > > Am I missing something in the RTP spec? I browsed through rfc2326bis > without seeing it addressed but it seems like a valid scenario. > > Thanks, > Anders > > _______________________________________________ > 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 Wed Jul 11 05: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 1I8YdS-0006PA-0E; Wed, 11 Jul 2007 05:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YdR-0006P1-89 for mmusic@ietf.org; Wed, 11 Jul 2007 05:37:25 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8YdD-0002Fe-NT for mmusic@ietf.org; Wed, 11 Jul 2007 05:37:25 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l6B9bAIO012802; Wed, 11 Jul 2007 11:37:10 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6B9au5d032478; Wed, 11 Jul 2007 11:37:08 +0200 Received: from nets13ha.ww300.siemens.net ([158.226.250.77]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 11:37:02 +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 Date: Wed, 11 Jul 2007 11:37:03 +0200 Message-ID: <9546CD0F7CC5EE48BCCE583AC4FC864D04057BA8@nets13ha.ww300.siemens.net> In-Reply-To: <469288EE.2070004@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-16: ICE Restarts Thread-Index: AcfCXWFYLfecYFwbS9ST3tefcfrA9QBL6vcg References: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> <469288EE.2070004@cisco.com> From: "Zingerle, Meinrad" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 11 Jul 2007 09:37:02.0526 (UTC) FILETIME=[093875E0:01C7C39F] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070711113710-46D99BB0-4061EC75/0-0/0-15 X-purgate-size: 2510/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mmusic@ietf.org Subject: [MMUSIC] ICE-16: ICE Restarts 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, some question concerning ICE Restarts: #1)If an agent has an active session ICE had been in use, and it receives a re-INVITE with no SDP, the agent should generate an offer in the same way as for an initial INVITE. Under the assumption that there are no changes concerning the media streams and their local candidates, may the agent use and from the active session or must it use new values for these attributes an restarting ICE overall? #2)Is it correct that an agent has to restart ICE for a media stream when it adds a new candidate - also in that case when ICE has not been completed for that media stream?=20 In other words: What happens if an agent receives a new candidate for a media stream the ICE processing is already finished but restarting ICE for that media stream is not requested by means of and ? #3) Is it correct that the receipt of an updated offer with no ICE attributes would cause all ICE procedures to be stopped immediately? #4) 9.1.1.1. ICE Restarts "... These rules imply that setting the IP address in the c line to 0.0.0.0 will cause an ICE restart. ..." Why would 0.0.0.0 in the c-line cause an ICE restart (for this media stream) an how would an agent receiving such a c-line handle it? Note that this condition is not mentioned in section "9.2.1.1. Detecting ICE Restart". #5) 9.1.1.1. ICE Restarts "... To restart ICE, an agent MUST change both the ice-pwd and the iceufrag for the media stream in an offer. Note that it is permissible to use a session-level attribute in one offer, but to provide the same ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. ..." Is it allowed to include a changed ice-pwd and a changed ice-ufrag at session-level in an updated offer in order to restart ICE for all media streams? =20 #6) 9.1.2.2. Existing Media Streams with ICE Completed "... In addition, if the agent is controlling, it MUST include the a=3Dremote-candidates attribute for each media stream whose check list is in the Completed state. The attribute contains the remote candidates from the highest priority nominated pair in the valid list for each component of that media stream. ..." I thought that in case the normal nomination algorithm is used the controlling agent is free to select another than the highest priority nominated pair in the valid list. Is that incorrect? Regards, Meinrad _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 11 08:28: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 1I8bIk-0004wS-R7; Wed, 11 Jul 2007 08:28:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bIj-0004wM-2u; Wed, 11 Jul 2007 08:28:13 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8bIf-0006S9-Oz; Wed, 11 Jul 2007 08:28:13 -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 l6BCS8Zn020414; Wed, 11 Jul 2007 06:28:08 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 11 Jul 2007 06:28:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/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: Wed, 11 Jul 2007 06:28:05 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C62EA023@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft mmusic agenda for Chicago Thread-Index: AcfDtu63AeB4UvE3Tz+dt3Jx6rFHvQ== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mmusic-chairs@ietf.org Subject: [MMUSIC] draft mmusic agenda for Chicago 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 below, let us know if we missed any request. Jean-Francois. Multiparty Multimedia Session Control (MMUSIC) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Joerg Ott Colin Perkins Jean-Francois Mule AGENDA Tuesday, July 24, 2007, 15:20-17:20 (Afternoon Session II) ---------------------------------------------------------- 15:20 Introduction and progress report (Chairs, 5) 15:25 Source-Specific Media Attributes in SDP (J Lennox, 15) draft-lennox-mmusic-sdp-source-attributes-01.txt 15:40 Media Description for IKE in SDP (M Saito, 10) draft-saito-mmusic-sdp-ike-01.txt 15:50 Configuring DSCP of SDP Established Media Streams draft-polk-mmusic-dscp-attribute-01.txt (J Polk, 10) 16:00 An SDP Offer/Answer Mechanism to Enable File Transfer draft-ietf-mmusic-file-transfer-mech-03.txt (M Garcia, 20) 16:20 Multiple Packetization Times in SDP: Problem Statement (M Garcia, 10) draft-garcia-mmusic-multiple-ptimes-problem-00.txt 16:30 SDP Capability Negotiation (Andreasen, 30) draft-ietf-mmusic-sdp-capability-negotiation-06.txt 17:00 tbd Wednesday, July 25, 2007, 13:00-15:00 (Afternoon Session I) ----------------------------------------------------------- 13:00 RTSP 2.0 (M Westerlund, 10) draft-ietf-mmusic-rfc2326bis-15.txt 13:10 RTSP NAT (M Westerlund, 10) draft-ietf-mmusic-rtsp-nat-evaluation-00.txt 13:20 ICE TCP (J Rosenberg, 30) draft-ietf-mmusic-ice-tcp-04.txt 13:50 tbd _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 11 08:47: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 1I8bbE-0006gT-6V; Wed, 11 Jul 2007 08:47:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bbD-0006gM-Bk for mmusic@ietf.org; Wed, 11 Jul 2007 08:47:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8bbD-0007Gm-2W for mmusic@ietf.org; Wed, 11 Jul 2007 08:47:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2007 08:47:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJpulEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,526,1175486400"; d="scan'208"; a="64885863:sNHT776557260" 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 l6BCl3Nv031428; Wed, 11 Jul 2007 08:47:03 -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 l6BCl36a009433; Wed, 11 Jul 2007 12:47:03 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); Wed, 11 Jul 2007 08:47:03 -0400 Received: from [10.86.240.94] ([10.86.240.94]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:47:02 -0400 Message-ID: <4694D14B.1010404@cisco.com> Date: Wed, 11 Jul 2007 08:47:07 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Zingerle, Meinrad" References: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> <469288EE.2070004@cisco.com> <9546CD0F7CC5EE48BCCE583AC4FC864D04057AFC@nets13ha.ww300.siemens.net> In-Reply-To: <9546CD0F7CC5EE48BCCE583AC4FC864D04057AFC@nets13ha.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 12:47:02.0813 (UTC) FILETIME=[945234D0:01C7C3B9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2608; t=1184158023; x=1185022023; 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=20AW=3A=20ICE-16=20Comments |Sender:=20 |To:=20=22Zingerle,=20Meinrad=22=20; bh=XUffFQekObJK5dsc98SWeQUdrFzbyLlPcBpBLfAYfAE=; b=HZ6kRJKWqw1pa0Ksy/wD7cUEm5OXGr54i3PSoR0bi5yFD2Wob+yxanPM8aLtqr0F7C7eh/4b eQiXTonVmb7DLfJIQMGilM8ujDporH45HrgSf8FkFFpa7L4jAZIIGqx/; 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: 0a7aa2e6e558383d84476dc338324fab Cc: mmusic@ietf.org Subject: [MMUSIC] Re: AW: ICE-16 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: , Errors-To: mmusic-bounces@ietf.org inline. Zingerle, Meinrad wrote: > Jonathan, > > thanks for your response. > Just one remark regarding your answer to #3): > Section "10.1.2. Receiving a Request or Indication" of rfc3489bis says: > ".... > o If the message does not contain both a MESSAGE-INTEGRITY and a > USERNAME attribute: > * If the message is a request, the server MUST reject the > request > with an error response. This response MUST use an error code > of 400. > o If the USERNAME does not contain a username value currently > valid > within the server: > * If the message is a request, the server MUST reject the > request > with an error response. This response MUST use an error code > of 401. > ..." > Thus, in case an agent receives a STUN Binding request before the SDP > answer containing the of the answerer, I would expect that > the agent rejects this Binding request due to unknown username. > However, I think you have already a solution therefore ;-) The text above says 'valid' and not 'unknown'. So ICE is careful about definition of validity: The agent MUST use a short term credential to authenticate the request and perform a message integrity check. The agent MUST consider the username to be valid if it consists of two values separated by a colon, where the first value is equal to the username fragment generated by the agent in an offer or answer for a session in-progress. It is possible (and in fact very likely) that an offerer will receive a Binding Request prior to receiving the answer from its peer. If this happens, the agent MUST immediately generate a response (including computation of the mapped address as described in . The agent has sufficient information at this point to generate the response; the password from the peer is not required. Once the answer is received, it MUST proceed with the remaining steps required, namely , , and for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several pairs to be queued up in the triggered check queue. -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 Wed Jul 11 08:56:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bjq-00006F-8V; Wed, 11 Jul 2007 08:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bjp-00006A-IC for mmusic@ietf.org; Wed, 11 Jul 2007 08:56:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8bjl-0007BJ-3N for mmusic@ietf.org; Wed, 11 Jul 2007 08:56:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2007 08:56:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMdvlEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,526,1175486400"; d="scan'208"; a="64886628:sNHT30896848" 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 l6BCu8PV002711; Wed, 11 Jul 2007 08:56:08 -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 l6BCu06e011991; Wed, 11 Jul 2007 12:56:04 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:56:02 -0400 Received: from [10.86.240.94] ([10.86.240.94]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:56:02 -0400 Message-ID: <4694D367.7030604@cisco.com> Date: Wed, 11 Jul 2007 08:56:07 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Zingerle, Meinrad" References: <9546CD0F7CC5EE48BCCE583AC4FC864D0405765F@nets13ha.ww300.siemens.net> <469288EE.2070004@cisco.com> <9546CD0F7CC5EE48BCCE583AC4FC864D04057BA8@nets13ha.ww300.siemens.net> In-Reply-To: <9546CD0F7CC5EE48BCCE583AC4FC864D04057BA8@nets13ha.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 12:56:02.0493 (UTC) FILETIME=[D5FED6D0:01C7C3BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4590; t=1184158568; x=1185022568; 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-16=3A=20ICE=20Restarts |Sender:=20 |To:=20=22Zingerle,=20Meinrad=22=20; bh=8CY72/1ZuG7+UwveJ0jitPof0tujJBs17X6ZorLnrb8=; b=jVw3mUOt+jxk9WAt67ExSFZQEvPzdUMIf0TW61bqNIMCOQcmSDx0vnzygYUviOqoysSq3MFK R5umHWyrskDjoCLfD8oK0ItdY/WFrEiWZ1zVtA5OXD0IT61YrUxeWujG; 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: 2086112c730e13d5955355df27e3074b Cc: mmusic@ietf.org Subject: [MMUSIC] Re: ICE-16: ICE Restarts 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. Zingerle, Meinrad wrote: > Jonathan, > > some question concerning ICE Restarts: > > #1)If an agent has an active session ICE had been in use, and it > receives a re-INVITE with no SDP, the agent should generate an offer in > the same way as for an initial INVITE. Under the assumption that there > are no changes concerning the media streams and their local candidates, > may the agent use and from the active session or > must it use new values for these attributes an restarting ICE overall? MUST restart. From Section 12.5: The flows for continued operation, as described in Section 7 of RFC 3725, require additional behavior of ICE implementations to support. In particular, if an agent receives a mid-dialog re-INVITE that contains no offer, it MUST restart ICE for each media stream and go through the process of gathering new candidates. Furthermore, that list of candidates SHOULD include the ones currently being used for media. this is required for 3pcc to work. It completely fails if you don't restart. > > #2)Is it correct that an agent has to restart ICE for a media stream > when it adds a new candidate - also in that case when ICE has not been > completed for that media stream? > In other words: What happens if an agent receives a new candidate for a > media stream the ICE processing is already finished but restarting ICE > for that media stream is not requested by means of and > ? If ICE has finished and selected a candidate, but an agent somehow gets a new candidate (not sure how it would just 'get' one), it would need to do an ICE restart if it wants to try it out. > > #3) Is it correct that the receipt of an updated offer with no ICE > attributes would cause all ICE procedures to be stopped immediately? Yes. > > #4) 9.1.1.1. ICE Restarts > "... > These rules imply that setting the IP address in the c line to > 0.0.0.0 will cause an ICE restart. ..." > > Why would 0.0.0.0 in the c-line cause an ICE restart (for this media > stream) an how would an agent receiving such a c-line handle it? > Note that this condition is not mentioned in section "9.2.1.1. Detecting > ICE Restart". A change of the target causes an ICE restart. From the text immediately above: An agent MUST restart ICE for a media stream if: The offer is being generated for the purposes of changing the target of the media stream. In other words, if an agent wants to generated an updated offer which, had ICE not been in use, would result in a new value for the destination of a media component. Since 0.0.0.0 is a new destination, an agent sending this has to restart ICE. Thats why usage of 0.0.0.0 for hold with ICE is a really bad idea. > > #5) 9.1.1.1. ICE Restarts > "... > To restart ICE, an agent MUST change both the ice-pwd and the > iceufrag > for the media stream in an offer. Note that it is permissible > to use a session-level attribute in one offer, but to provide > the > same ice-pwd or ice-ufrag as a media-level attribute in a > subsequent > offer. ..." > Is it allowed to include a changed ice-pwd and a changed ice-ufrag at > session-level in an updated offer in order to restart ICE for all media > streams? Yes. > > #6) 9.1.2.2. Existing Media Streams with ICE Completed > "... > In addition, if the agent is controlling, it MUST include the > a=remote-candidates attribute for each media stream whose check > list > is in the Completed state. The attribute contains the remote > candidates from the highest priority nominated pair in the valid > list > for each component of that media stream. ..." > I thought that in case the normal nomination algorithm is used the > controlling agent is free to select another than the highest priority > nominated pair in the valid list. Is that incorrect? Its free to select any valid pair it likes, yes. Once it does it sends an updated STUN check, with the nominated flag set. Thus, making it the only nominated pair in the valid list. The word 'nominated' is important in the above sentence. -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 Wed Jul 11 09:38: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 1I8cOs-0005Zo-9t; Wed, 11 Jul 2007 09:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cOr-0005Zi-AM for mmusic@ietf.org; Wed, 11 Jul 2007 09:38:37 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cOm-0000L4-SG for mmusic@ietf.org; Wed, 11 Jul 2007 09:38:37 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 15:38:22 +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 Date: Wed, 11 Jul 2007 15:38:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDP media stream with non symmetric codec Thread-Index: AcfDwMReJjo8KLnxQYq6yyPE4mH57w== From: "SOLLAUD Aurelien RD-TECH-LAN" To: X-OriginalArrivalTime: 11 Jul 2007 13:38:22.0129 (UTC) FILETIME=[BFBC8A10:01C7C3C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [MMUSIC] SDP media stream with non symmetric codec 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 When reading RFC 3388 (grouping of media lines in SDP), in 7.4.1 there is an example of use of the FID grouping : The next example shows how the "group" attribute used with FID semantics can indicate the use of two different codecs in the two directions of a bidirectional media stream. [...] a=3Dgroup:FID 1 2 m=3Daudio 30000 RTP/AVP 0 a=3Dmid:1 m=3Daudio 30002 RTP/AVP 8 a=3Drecvonly a=3Dmid:2 What I would like to express in SDP is a non symmetric stream, on a single RTP port, with one codec (or set of codecs) in one direction, and another codec (or set of codecs) in the other direction. It is close to the previous example, but Section 7.5.3 explicitly forbids to have the same transport address for media lines under a FID group. So Say I define a new XYZ grouping that allows that. I would have=20 [...] a=3Dgroup:XYZ 1 2 m=3Daudio 30000 RTP/AVP 0 a=3Dsendonly a=3Dmid:1 m=3Daudio 30000 RTP/AVP 8 a=3Drecvonly a=3Dmid:2 The problem I see is if the receiver of this SDP offer does not understand grouping, it will see 2 media lines with the same transport address, so the behavior is undefined (RFC 4566). In addition, if the receiver is designed to support only one media stream, it will take the first one and the result will be a mono-directional stream, which is not what was desired. A solution with a better fallback would be to define a new SDP attribute 'xyz' to express the non-symmetry. Something like: [...] m=3Daudio 30000 RTP/AVP 0 8 a=3Dxyz send=3D0;recv=3D8 If the receiver of this offer does not understand the a=3Dxyz, it will ignore it and we have a simple case with one bidirectional stream, which is not so bad. Any comments on the idea ? new grouping vs new attribute ? Thanks Aurelien _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 11 15:47: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 1I8i9s-0007mg-Rm; Wed, 11 Jul 2007 15:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8i9q-0007mP-Jg for mmusic@ietf.org; Wed, 11 Jul 2007 15:47:30 -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 1I8i9m-0005pP-4q for mmusic@ietf.org; Wed, 11 Jul 2007 15:47:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2007 12:22:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAN/PlEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208"; a="385041131:sNHT414832408" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6BJMbBX027945; Wed, 11 Jul 2007 12:22:37 -0700 Received: from [128.107.147.32] (dhcp-128-107-147-32.cisco.com [128.107.147.32]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6BJMbvv015279; Wed, 11 Jul 2007 19:22:37 GMT Message-ID: <46952DFD.2050702@cisco.com> Date: Wed, 11 Jul 2007 12:22:37 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] RTSP-SIP mismatch References: <469450EF.1030205@cisco.com> <46948ADE.10407@ericsson.com> In-Reply-To: <46948ADE.10407@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3924; t=1184181757; x=1185045757; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[MMUSIC]=20RTSP-SIP=20mismatch |Sender:=20; bh=fv3OutgZvXi94b7N/wGAiMJYABfDto2F++wCZx5y8+0=; b=WoGcZYKNq8JNIOCVpfxrqQZMI+sVAg0T/7JFpp00CE6m3BPnX0kIqZMI7gnid1KSe55t+wO3 oPwmgBUelQnUoBRsL+eWfMnUIwSWgbjWASjEh9RpPvpSV3CAgNdq5YZP; Authentication-Results: sj-dkim-2; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Magnus, OK, that's what I thought was the case. I think this scenario needs to be supported, though. It seems like a very basic and reasonable thing to do. I think it's fair to say that SIP is in wider use than RTSP at this point and I don't see much chance of the SIP offer/answer model being changed to accomodate this issue so I would actually suggest that it should be a requirement of rfc2326bis that it improve on the SIP-RTSP interop situation. Thanks, Anders Magnus Westerlund wrote: > Hi Anders, > > I think you are getting into places where specification hasn't gone. > Interaction between SIP and RTSP are not really specified. RTSP has a > model where media configuration is done by the server saying something > and the client has the choice of taking it or leaving it. There is no > negotiation of media parameters. The only thing that I know of that can > affect the SDP is that the describe included a capability description of > the client. That allows the server to tailor the session description to > the clients capabilities. But that wouldn't solve the issue you have. > > This is an collison in regards to the models used for media > configuration that I don't think have an easy answer. The only way to > resolve this would be to indicate to the client in the Invite SDP that > these sendonly streams can't be changed in regards to media > configuration so take it or leave it. > > Magnus > > Anders Kristensen skrev: >> I wonder if anyone has run into the following problem related to a >> mismatch between RTSP and SIP in a case where a 3rd party controller >> sets up a SIP dialog with a UA and wants to tell an RTSP server to >> send media to the UA. The call flow might look like the this: >> >> RTSP server controller SIP UA >> | | | >> |(1) RTSP DESCRIBE | | >> |<------------------| | >> |(2) 200 (SDP) | | >> |------------------>| | >> | |(3) INVITE (offer) | >> | |------------------>| >> | |(4) 200 (answer) | >> | |<------------------| >> | |(5) ACK | >> | |------------------>| >> |(6) RTSP SETUP | | >> |<------------------| | >> |(7) 200 | | >> |------------------>| | >> |(8) RTSP PLAY | | >> |<------------------| | >> |(9) 200 | | >> |------------------>| | >> |(10) RTP | | >> |.......................................| >> | | | >> | | | >> >> The specific problem is that the SIP UA says in the SDP answer carried >> in the 200 response that for some media stream it wants to receive RTP >> with payload type 96, say, but the RTSP server insists on sending RTP >> with payload type 126. >> >> According to the SIP offer/answer model the SIP UA gets to say what it >> wants to receive but AFAIK RTSP doesn't let the client (the controller >> in this example) pass these instructions on to the RTSP server, at >> least not for the payload type. >> >> Am I missing something in the RTP spec? I browsed through rfc2326bis >> without seeing it addressed but it seems like a valid scenario. >> >> Thanks, >> Anders >> >> _______________________________________________ >> 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 Jul 11 21:08: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 1I8nAZ-00018y-Pu; Wed, 11 Jul 2007 21:08:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8nAY-00018j-IF for mmusic@ietf.org; Wed, 11 Jul 2007 21:08:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8nAY-0006cT-2M for mmusic@ietf.org; Wed, 11 Jul 2007 21:08:34 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2007 18:08:09 -0700 X-IronPort-AV: i="unknown"; a="502304207:sNHT0" 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 l6C189a9002742; Wed, 11 Jul 2007 18:08:09 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6C188XH022287; Thu, 12 Jul 2007 01:08:08 GMT From: "Dan Wing" To: "'Jonathan Rosenberg'" , "'Zingerle, Meinrad'" Subject: RE: [MMUSIC] Re: ICE-16: ICE Restarts Date: Wed, 11 Jul 2007 18:08:08 -0700 Message-ID: <14d201c7c421$1c499e20$c3f0200a@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: <4694D367.7030604@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfDuvoPpTP93CYLSrqIMWuSrRiEFAAZVO8g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4170; t=1184202489; x=1185066489; c=relaxed/simple; s=sjdkim2002; 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]=20Re=3A=20ICE-16=3A=20ICE=20Restarts |Sender:=20; bh=BWpFlu1PJW4Wh3riM5X+Gwt9Ii1WSdNRsBcZoZRut/c=; b=AkhWneb6fXXT/sE7M+Pt0Q9iFX2l70szPi12C3KgWPN9/i9Cucqpqot7h1PE1UNUGxMlnMjU 7AOG333lpvgtXBezJ1LbONrxvcmd8hm7E8s4/vOVBOhp5Lz6IOTqohsC; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 > > #2)Is it correct that an agent has to restart ICE for a media stream > > when it adds a new candidate - also in that case when ICE > > has not been > > completed for that media stream? > > In other words: What happens if an agent receives a new > > candidate for a > > media stream the ICE processing is already finished but > > restarting ICE > > for that media stream is not requested by means of and > > ? > > If ICE has finished and selected a candidate, but an agent > somehow gets a new candidate (not sure how it would just 'get' > one), You might be on WiFi and have the opportunity to switch to another network (e.g., EDGE), which has a different IP address. You would like to test connectivity with that new network's candidate address before abandoning the previous network connection. -d > it would need to do an ICE restart if it wants to try > it out. > > > > > #3) Is it correct that the receipt of an updated offer with no ICE > > attributes would cause all ICE procedures to be stopped immediately? > > Yes. > > > > > #4) 9.1.1.1. ICE Restarts > > "... > > These rules imply that setting the IP address in the c line to > > 0.0.0.0 will cause an ICE restart. ..." > > > > Why would 0.0.0.0 in the c-line cause an ICE restart (for this media > > stream) an how would an agent receiving such a c-line handle it? > > Note that this condition is not mentioned in section > "9.2.1.1. Detecting > > ICE Restart". > > A change of the target causes an ICE restart. From the text > immediately > above: > > > An agent MUST restart ICE for a media stream if: > > > > The offer is being generated > for the purposes of changing the target of the media stream. In other > words, if an agent wants to generated an updated offer which, had ICE > not been in use, would result in a new value for the destination of a > media component. > > > > Since 0.0.0.0 is a new destination, an agent sending this has > to restart > ICE. Thats why usage of 0.0.0.0 for hold with ICE is a really > bad idea. > > > > > > #5) 9.1.1.1. ICE Restarts > > "... > > To restart ICE, an agent MUST change both the ice-pwd and the > > iceufrag > > for the media stream in an offer. Note that it is permissible > > to use a session-level attribute in one offer, but to provide > > the > > same ice-pwd or ice-ufrag as a media-level attribute in a > > subsequent > > offer. ..." > > Is it allowed to include a changed ice-pwd and a changed > ice-ufrag at > > session-level in an updated offer in order to restart ICE > for all media > > streams? > > Yes. > > > > > #6) 9.1.2.2. Existing Media Streams with ICE Completed > > "... > > In addition, if the agent is controlling, it MUST include the > > a=remote-candidates attribute for each media stream whose check > > list > > is in the Completed state. The attribute contains the remote > > candidates from the highest priority nominated pair in the valid > > list > > for each component of that media stream. ..." > > I thought that in case the normal nomination algorithm is used the > > controlling agent is free to select another than the > highest priority > > nominated pair in the valid list. Is that incorrect? > > Its free to select any valid pair it likes, yes. Once it does > it sends > an updated STUN check, with the nominated flag set. Thus, > making it the > only nominated pair in the valid list. The word 'nominated' > is important > in the above sentence. > > -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 Thu Jul 12 01:43: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 1I8rSY-0000y7-Mn; Thu, 12 Jul 2007 01:43:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rSX-0000y1-IK for mmusic@ietf.org; Thu, 12 Jul 2007 01:43:25 -0400 Received: from mail.tataelxsi.co.in ([203.200.1.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8rSI-0007Gp-4O for mmusic@ietf.org; Thu, 12 Jul 2007 01:43:25 -0400 Received: from vinodjoshi (59.160.207.5.ill-bgl.static.vsnl.net.in [59.160.207.5] (may be forged)) by mail.tataelxsi.co.in (MOS 3.8.4-GA) with ESMTP id ABG81199 (AUTH vinodjoshi); Thu, 12 Jul 2007 11:12:35 +0530 (IST) From: Vinod Madhav Joshi To: Date: Thu, 12 Jul 2007 11:14:17 +0530 Message-ID: <002701c7c447$b0ba4cf0$022a320a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 importance: Normal X-Junkmail-Status: score=10/50, host=mail.tataelxsi.co.in X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A09020A.4695BF4B.003C,ss=1,fgs=0, ip=59.160.207.5, so=2007-03-13 10:31:19, dmn=5.3.14/2007-05-31 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [MMUSIC] Audio Video synchronization 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, We are receiving MPEG2 demuxed elementary audio and video streams from streaming server o the set top box. The source for audio and video is the same. I want to know how to synchronise this audio and video data using RTP timestamps. i. e. how to generate Presentation Timestamps. For synchronization using RTP timestamps is it mandatory to use the RTCP packets? Please help me. Thank You. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 12 02:02: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 1I8rlJ-00068j-Fh; Thu, 12 Jul 2007 02:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rlI-00068b-SR for mmusic@ietf.org; Thu, 12 Jul 2007 02:02:48 -0400 Received: from keskus.netlab.hut.fi ([130.233.154.176] helo=smtp.netlab.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8rlE-0007oX-I4 for mmusic@ietf.org; Thu, 12 Jul 2007 02:02:48 -0400 Received: from [127.0.0.1] (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 84826C50E7; Thu, 12 Jul 2007 09:02:43 +0300 (EET DST) Message-ID: <4695C3C1.6030005@netlab.hut.fi> Date: Thu, 12 Jul 2007 09:01:37 +0300 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vinod Madhav Joshi Subject: Re: [MMUSIC] Audio Video synchronization References: <002701c7c447$b0ba4cf0$022a320a@telxsi.com> In-Reply-To: <002701c7c447$b0ba4cf0$022a320a@telxsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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, (this is probably a question for the AVT WG mailing list) > We are receiving MPEG2 demuxed elementary audio and video streams > from streaming server o the set top box. > The source for audio and video is the same. > I want to know how to synchronise this audio and video data using > RTP timestamps. > i. e. how to generate Presentation Timestamps. > For synchronization using RTP timestamps is it mandatory to use > the RTCP packets? yes. Both media streams, audio and video, have their own internal clock which are naturally different. RTCP packets relate the internal clock to wallclock time (which is simply the clock of the sender, so that no time-synchronization between sender and receiver devices is needed). As you know the clock rate of each stream and you get regular references to wall clock time, you can compute on the receiver side which media time stamps have to be played back at the same time and dimension your playout delay accordingly. Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 12 03:40: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 1I8tHv-00034y-Ra; Thu, 12 Jul 2007 03:40:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tHu-00034q-Ti for mmusic@ietf.org; Thu, 12 Jul 2007 03:40:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8tHr-0001VT-SR for mmusic@ietf.org; Thu, 12 Jul 2007 03:40:34 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3C6D320BA3; Thu, 12 Jul 2007 09:39:38 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-8e-4695daba6c43 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2BE1C20BA2; Thu, 12 Jul 2007 09:39:38 +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, 12 Jul 2007 09:39:37 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 09:39:37 +0200 Message-ID: <4695DAB9.2000708@ericsson.com> Date: Thu, 12 Jul 2007 09:39:37 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [MMUSIC] RTSP-SIP mismatch References: <469450EF.1030205@cisco.com> <46948ADE.10407@ericsson.com> <46952DFD.2050702@cisco.com> In-Reply-To: <46952DFD.2050702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 07:39:37.0840 (UTC) FILETIME=[CCAC6F00:01C7C457] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Anders Kristensen skrev: > Hi Magnus, > > OK, that's what I thought was the case. I think this scenario needs to > be supported, though. It seems like a very basic and reasonable thing to > do. > > I think it's fair to say that SIP is in wider use than RTSP at this > point and I don't see much chance of the SIP offer/answer model being > changed to accomodate this issue so I would actually suggest that it > should be a requirement of rfc2326bis that it improve on the SIP-RTSP > interop situation. > I would actually challenge this statement, at least in regards to RTSP 1.0. RTSP 1.0 is today deployed and in use by media player such as Quicktime, RealPlayer, and Windows Media Player. In addition there are some hundred million cell phones supporting streaming that uses RTSP. Meaning that bascially all PCs and a large percentage of mobile devices do have at least one RTSP implementation. I think that is a significant larger deployment than SIP currently has in the number of devices. But having said that I think there is an interesting discussion. But from my point of view totally redesigning RTSP to support offer/answer compared to an indication in offer/answer that you better take things as they are, is on two very different levels of changes. I would also like to point out that RTSP looks like it does because for on-demand or shared live content most of the parameters are not negotiable at all becuase they are written into the file the server has or the source stream. I think this is a fact that one has to have in mind when discussing these things. 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 Jul 12 13:14: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 1I92F9-0000FO-Tr; Thu, 12 Jul 2007 13:14:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92F8-0000FJ-Sq for mmusic@ietf.org; Thu, 12 Jul 2007 13:14:18 -0400 Received: from hm633-2.locaweb.com.br ([200.234.205.219] helo=hm633.locaweb.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I92Es-00040b-VQ for mmusic@ietf.org; Thu, 12 Jul 2007 13:14:18 -0400 Received: (qmail 20888 invoked from network); 12 Jul 2007 17:13:11 -0000 Received: from unknown (10.1.10.10) by hm633.locaweb.com.br with QMQP; 12 Jul 2007 17:13:11 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.88.221) by hm10.locaweb.com.br with SMTP; 12 Jul 2007 17:13:23 -0000 Message-ID: <4696611F.4060808@comunip.com.br> Date: Thu, 12 Jul 2007 14:13:03 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) 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: 52f7a77164458f8c7b36b66787c853da Subject: [MMUSIC] ICE-16 possible issue 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 section "4.1.1.3. Eliminating Redundant Candidates" states that "a candidate is redundant if its transport address equals another candidate, and its base equals the base of that other candidate". The next section "4.1.1.4. Computing Foundations" then states that "two candidates MUST have the same foundation ID when all of the following are true: they are of the same type, their bases have the same IP, for server and reflexive candidates, the STUN servers used to obtain them have the same IP address". Be the following scenario: - There are two STUN servers configured by an agent A (200.100.10.50:3478 and 200.100.10.51:3478); - The agent A have two components (RTP and RTCP); - The gathering process obtain the following addresses (in order): * component=1, transport=10.0.0.1:5004/udp, type=local; * component=2, transport=10.0.0.1:5005/udp, type=local; * component=2, transport=200.100.10.1:5005/udp, type=srflx, stunserver=200.100.10.50:3478; * component=1, transport=200.100.10.1:5004/udp, type=srflx, stunserver=200.100.10.51:3478; * component=1, transport=200.100.10.1:5004/udp, type=srflx, stunserver=200.100.10.50:3478; * component=2, transport=200.100.10.1:5005/udp, type=srflx, stunserver=200.100.10.51:3478; Following the algorithm described in the section "4.1.1.3", we must eliminate two of the server reflexive candidates as they have the same mapped-address. So, by removing the redundant candidates in order (forward comparison), we get the new candidate list as follows: * component=1, transport=10.0.0.1:5004/udp, type=local; * component=2, transport=10.0.0.1:5005/udp, type=local; * component=2, transport=200.100.10.1:5005/udp, type=srflx, stunserver=200.100.10.50:3478; * component=1, transport=200.100.10.1:5004/udp, type=srflx, stunserver=200.100.10.51:3478; Note that the two server reflexive candidates was obtained by two different STUN servers. Now I must compute the foundations, then I would get: * foundation=1, component=1, transport=10.0.0.1:5004/udp, type=local; * foundation=1, component=2, transport=10.0.0.1:5005/udp, type=local; * foundation=2, component=2, transport=200.100.10.1:5005/udp, type=srflx, stunserver=200.100.10.50:3478; * foundation=3, component=1, transport=200.100.10.1:5004/udp, type=srflx, stunserver=200.100.10.51:3478; I expected to have the same foundation for the last two candidates, for they have the same mapped-address IP and both the STUN servers are located at the same network. I know it is difficult to discover if two STUN servers are located in the same network, so I suggest you to review the section "4.1.1.4" the statement "for reflexive and relayed candidates, the STUN servers used to obtain them have the same IP address". I don't know if this is an issue or it is a normal behavior of the algorithm, but I use these foundations to conclude the ICE processing (I wait for two candidate pairs with the same foundation to complete, for QoS purposes). Regards, Guilherme Balena Versiani ComunIP S/A _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 12 13:16: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 1I92HZ-00052M-5A; Thu, 12 Jul 2007 13:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92HS-0004Rk-9I; Thu, 12 Jul 2007 13:16:42 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I92HK-0003Wt-KL; Thu, 12 Jul 2007 13:16:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 938A1329DA; Thu, 12 Jul 2007 17:16:34 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I92H6-0005YH-Rv; Thu, 12 Jul 2007 13:16:21 -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, 12 Jul 2007 13:16:20 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-17.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 : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-17.txt Pages : 111 Date : 2007-7-12 This document describes a protocol for Network Address Translator (NAT) traversal for multimedia sessions established with the offer/ answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.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-ice-17.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-ice-17.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-7-12123030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12123030.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 Jul 12 23:32: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 1I9Bt5-0003Qm-Ep; Thu, 12 Jul 2007 23:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Bt4-0003Qg-9S for mmusic@ietf.org; Thu, 12 Jul 2007 23:32:10 -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 1I9Bsz-0007Cp-TU for mmusic@ietf.org; Thu, 12 Jul 2007 23:32:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 12 Jul 2007 20:32:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAB6OlkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,535,1175497200"; d="scan'208"; a="502767450:sNHT29303436" 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 l6D3W5eU008334; Thu, 12 Jul 2007 20:32:05 -0700 Received: from [128.107.147.32] (dhcp-128-107-147-32.cisco.com [128.107.147.32]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6D3W5XH028434; Fri, 13 Jul 2007 03:32:05 GMT Message-ID: <4696F235.9020009@cisco.com> Date: Thu, 12 Jul 2007 20:32:05 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] RTSP-SIP mismatch References: <469450EF.1030205@cisco.com> <46948ADE.10407@ericsson.com> <46952DFD.2050702@cisco.com> <4695DAB9.2000708@ericsson.com> In-Reply-To: <4695DAB9.2000708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3638; t=1184297525; x=1185161525; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andersk@cisco.com; z=From:=20Anders=20Kristensen=20 |Subject:=20Re=3A=20[MMUSIC]=20RTSP-SIP=20mismatch |Sender:=20; bh=Hz44gjQQLJzw2ITy7Rrpm7sKdLTba9uUHqaQtTUHTXA=; b=yIh8sopulLMvb2FiEVy/fONRWjvH1LDnO9cnYdQ9VCX7LqxR2Rm10iFwdnM0RfSZHbv4V3ak O7580obeDYynFDQHDS5+T/e7llXsdFBaF6IJaOvC4xIM5xcA7gYuSOE9; Authentication-Results: sj-dkim-2; header.From=andersk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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, So if I understand you correctly you're saying that yes, there is a an issue that ought to be addressed but in your view it should be addressed in SIP, not RTSP? I suggested RTSP because I thought, mistakenly perhaps, that it is less mature and therefore more amenable to change. In my head RFC 2326 is more or less on par with SIP as defined in RFC 2543 making rfc2326bis the equivalent of RFC 3261. If 2326 is as widely deployed as you say then that certainly makes the comparison less than perfect. When you talk about shared live content you're thinking about a multicast scenario? There are RTSP features that have to do specifically with setting up point-to-point streams so AFAICT passing payload type from the client to the server is not particularly at odds with RTSP as such. It could be added to the Transport header field along with the client's IP and port. I guess it would either have to be considered a hint or else an extension token would have to be added. OTOH, I would find it tempting to have RTSP adopt SIP's offer/answer model more wholesale, possibly in addition to a mode where the server just announces the session parameters in support of broadcast-type scenarios. Should be possible to do something like that in a backwards compatible manner although I can't say I've thought it through. Thanks, Anders Magnus Westerlund wrote: > Anders Kristensen skrev: >> Hi Magnus, >> >> OK, that's what I thought was the case. I think this scenario needs to >> be supported, though. It seems like a very basic and reasonable thing >> to do. >> >> I think it's fair to say that SIP is in wider use than RTSP at this >> point and I don't see much chance of the SIP offer/answer model being >> changed to accomodate this issue so I would actually suggest that it >> should be a requirement of rfc2326bis that it improve on the SIP-RTSP >> interop situation. >> > > I would actually challenge this statement, at least in regards to RTSP > 1.0. RTSP 1.0 is today deployed and in use by media player such as > Quicktime, RealPlayer, and Windows Media Player. In addition there are > some hundred million cell phones supporting streaming that uses RTSP. > Meaning that bascially all PCs and a large percentage of mobile devices > do have at least one RTSP implementation. I think that is a significant > larger deployment than SIP currently has in the number of devices. > > But having said that I think there is an interesting discussion. But > from my point of view totally redesigning RTSP to support offer/answer > compared to an indication in offer/answer that you better take things as > they are, is on two very different levels of changes. I would also like > to point out that RTSP looks like it does because for on-demand or > shared live content most of the parameters are not negotiable at all > becuase they are written into the file the server has or the source > stream. I think this is a fact that one has to have in mind when > discussing these things. > > 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 Jul 13 04:22: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 1I9GQ1-0008Rz-Id; Fri, 13 Jul 2007 04:22:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GPz-0008Rr-KC for mmusic@ietf.org; Fri, 13 Jul 2007 04:22:27 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9GPz-0000uP-3L for mmusic@ietf.org; Fri, 13 Jul 2007 04:22:27 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 68F2420D01; Fri, 13 Jul 2007 10:22:10 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-c1-469736325d0f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 42AC020D41; Fri, 13 Jul 2007 10:22:10 +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 Jul 2007 10:22:09 +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 Jul 2007 10:22:09 +0200 Message-ID: <46973631.8010406@ericsson.com> Date: Fri, 13 Jul 2007 10:22:09 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Anders Kristensen Subject: Re: [MMUSIC] RTSP-SIP mismatch References: <469450EF.1030205@cisco.com> <46948ADE.10407@ericsson.com> <46952DFD.2050702@cisco.com> <4695DAB9.2000708@ericsson.com> <4696F235.9020009@cisco.com> In-Reply-To: <4696F235.9020009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 08:22:09.0097 (UTC) FILETIME=[E7C11B90:01C7C526] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Anders Kristensen skrev: > Magnus, > > So if I understand you correctly you're saying that yes, there is a an > issue that ought to be addressed but in your view it should be addressed > in SIP, not RTSP? Yes, Yes, and not because of maturity, but because of what I see as the correct place to implement the solution. As I said, fixing this issue in RTSP seems to imply that RTSP suddenly are forced to have two way media negotiation. > > I suggested RTSP because I thought, mistakenly perhaps, that it is less > mature and therefore more amenable to change. In my head RFC 2326 is > more or less on par with SIP as defined in RFC 2543 making rfc2326bis > the equivalent of RFC 3261. If 2326 is as widely deployed as you say > then that certainly makes the comparison less than perfect. I don't want to make parallels here. From a specification point of view regarding majurity I think your view holds. But not from reality and deployed base. RTSP 2.0 will be hard to get deployed, and I think the main advantage will be faster setup and standardized NAT traversal may get it deployed as soon as we can finish it. > > When you talk about shared live content you're thinking about a > multicast scenario? There are RTSP features that have to do specifically > with setting up point-to-point streams so AFAICT passing payload type > from the client to the server is not particularly at odds with RTSP as > such. It could be added to the Transport header field along with the > client's IP and port. I guess it would either have to be considered a > hint or else an extension token would have to be added. No, I am talking about unicast distribution using tree likes structures from a source where the setup and control of the flow from last tier servers to clients are done with RTSP. In this case the server may simply copy any incoming packets into multiple out-bound unicast flow and performs no per packet processing. I don't think what you propose realy flies well. Of course you could make a hack that only works under certain circumstances by passing a PT remapping in the transport header. However, what I think needs to be considered here are the model. > > OTOH, I would find it tempting to have RTSP adopt SIP's offer/answer > model more wholesale, possibly in addition to a mode where the server > just announces the session parameters in support of broadcast-type > scenarios. Should be possible to do something like that in a backwards > compatible manner although I can't say I've thought it through. > Well, that has been discussed but never taken anywhere. I think one needs to start in considering what the needs really are. And if one want to do real negotiation one should go for a three step negotiation model with. A->B: A's Capabilites, B->A: B's Capabilites + B's configuration, A->B: A's congfiguration + ACK. Because Offer/Answer is simply broken for any more advance cases, like assymetric configurations. 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 Jul 13 09:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9KkX-0008Hv-MG; Fri, 13 Jul 2007 08:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9KkX-0008Hf-20 for mmusic@ietf.org; Fri, 13 Jul 2007 08:59:57 -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 1I9KkS-0006Uy-AD for mmusic@ietf.org; Fri, 13 Jul 2007 08:59:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2007 05:59:52 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHoTl0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="385539735:sNHT40322398" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6DCxpIM009323; Fri, 13 Jul 2007 05:59:51 -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 l6DCxpmo014226; Fri, 13 Jul 2007 12:59:51 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, 13 Jul 2007 05:59:51 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 05:59:50 -0700 Message-ID: <4697774B.9040905@cisco.com> Date: Fri, 13 Jul 2007 08:59:55 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] Re: ICE-16: ICE Restarts References: <14d201c7c421$1c499e20$c3f0200a@amer.cisco.com> In-Reply-To: <14d201c7c421$1c499e20$c3f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 12:59:50.0598 (UTC) FILETIME=[B2C86660:01C7C54D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4763; t=1184331591; x=1185195591; 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-16=3A=20ICE=20Restarts |Sender:=20; bh=nmKUyoo+XxdIwdjUGG6XpfEMDwlVh/KAsAbYnD6SBis=; b=q8tS+nxCAf/bVBXU8u48F+/QbQVDHbIxgoBNdfdhfVuYdD79VF1V6I7j0tm5CpQn3OdkbFF2 4kQB+OciDaqmzK5QRoNvDAP3npusl9XBSWeFU1H2AI3MGZ/JkeqvsACy; 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: b1c41982e167b872076d0018e4e1dc3c 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 OK. You can do that. When there is an ICE-restart, you continue using the old candidate and switch over only when the restart completes. This way there is no gap in media continuity during the restart. -Jonathan R. Dan Wing wrote: >>> #2)Is it correct that an agent has to restart ICE for a media stream >>> when it adds a new candidate - also in that case when ICE >>> has not been >>> completed for that media stream? >>> In other words: What happens if an agent receives a new >>> candidate for a >>> media stream the ICE processing is already finished but >>> restarting ICE >>> for that media stream is not requested by means of and >>> ? >> If ICE has finished and selected a candidate, but an agent >> somehow gets a new candidate (not sure how it would just 'get' >> one), > > You might be on WiFi and have the opportunity to switch to > another network (e.g., EDGE), which has a different IP > address. You would like to test connectivity with that > new network's candidate address before abandoning the > previous network connection. > > -d > > >> it would need to do an ICE restart if it wants to try >> it out. >> >>> #3) Is it correct that the receipt of an updated offer with no ICE >>> attributes would cause all ICE procedures to be stopped immediately? >> Yes. >> >>> #4) 9.1.1.1. ICE Restarts >>> "... >>> These rules imply that setting the IP address in the c line to >>> 0.0.0.0 will cause an ICE restart. ..." >>> >>> Why would 0.0.0.0 in the c-line cause an ICE restart (for this media >>> stream) an how would an agent receiving such a c-line handle it? >>> Note that this condition is not mentioned in section >> "9.2.1.1. Detecting >>> ICE Restart". >> A change of the target causes an ICE restart. From the text >> immediately >> above: >> >> >> An agent MUST restart ICE for a media stream if: >> >> >> >> The offer is being generated >> for the purposes of changing the target of the media stream. In other >> words, if an agent wants to generated an updated offer which, had ICE >> not been in use, would result in a new value for the destination of a >> media component. >> >> >> >> Since 0.0.0.0 is a new destination, an agent sending this has >> to restart >> ICE. Thats why usage of 0.0.0.0 for hold with ICE is a really >> bad idea. >> >> >>> #5) 9.1.1.1. ICE Restarts >>> "... >>> To restart ICE, an agent MUST change both the ice-pwd and the >>> iceufrag >>> for the media stream in an offer. Note that it is permissible >>> to use a session-level attribute in one offer, but to provide >>> the >>> same ice-pwd or ice-ufrag as a media-level attribute in a >>> subsequent >>> offer. ..." >>> Is it allowed to include a changed ice-pwd and a changed >> ice-ufrag at >>> session-level in an updated offer in order to restart ICE >> for all media >>> streams? >> Yes. >> >>> #6) 9.1.2.2. Existing Media Streams with ICE Completed >>> "... >>> In addition, if the agent is controlling, it MUST include the >>> a=remote-candidates attribute for each media stream whose check >>> list >>> is in the Completed state. The attribute contains the remote >>> candidates from the highest priority nominated pair in the valid >>> list >>> for each component of that media stream. ..." >>> I thought that in case the normal nomination algorithm is used the >>> controlling agent is free to select another than the >> highest priority >>> nominated pair in the valid list. Is that incorrect? >> Its free to select any valid pair it likes, yes. Once it does >> it sends >> an updated STUN check, with the nominated flag set. Thus, >> making it the >> only nominated pair in the valid list. The word 'nominated' >> is important >> in the above sentence. >> >> -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 > -- 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 Jul 13 10:05: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 1I9Llh-0003RC-NX; Fri, 13 Jul 2007 10:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Llf-0003Qx-Ga for mmusic@ietf.org; Fri, 13 Jul 2007 10:05:11 -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 1I9Lla-0008Qv-TG for mmusic@ietf.org; Fri, 13 Jul 2007 10:05:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2007 07:05:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPIil0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="385557574:sNHT2763616692" 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 l6DE54Qa006918; Fri, 13 Jul 2007 07:05:04 -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 l6DE4sXX014328; Fri, 13 Jul 2007 14:05:04 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, 13 Jul 2007 07:05:02 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 07:05:01 -0700 Message-ID: <46978692.7040106@cisco.com> Date: Fri, 13 Jul 2007 10:05:06 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Guilherme Balena Versiani Subject: Re: [MMUSIC] ICE-16 possible issue References: <4696611F.4060808@comunip.com.br> In-Reply-To: <4696611F.4060808@comunip.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 14:05:01.0676 (UTC) FILETIME=[CDF78AC0:01C7C556] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4562; t=1184335504; x=1185199504; 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-16=20possible=20issue |Sender:=20; bh=KmWP0k332By3REmiI1EJKv14vO1qLuNqwG+2uNieYjQ=; b=SUiLgySA18MnAVF47nIsi5uRq0A1wI5JL4sVmItVvs6Uha0uu+qWAqVXeDLfaVM8L5sJRRbn q26l4XG+S6mVJtgEfJlD2ZD0x5q1zYVPJegmqfd4vA5FS3fhlIgHHien; 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: e1b0e72ff1bbd457ceef31828f216a86 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 What you describe is normal behavior of the algorithm. There is no way for ICE to know whether these STUN servers are really 'the same' and that their network paths towards the NAT are identical. The problem here is that, when you eliminated the redundant candidates, you ended up eliminating one from one STUN server, and one from the other. In fact you should have eliminated both of them from the same STUN server. THe spec is currently silent on WHICH candidates to eliminate when they are redundant. That is because the current redundancy elimination step happens prior to prioritization. I suggest a simple fix is that I merely move Section 4.1.2 down after prioriziation, and then suggest that the least preferred candidate is eliminated. -Jonathan R. Guilherme Balena Versiani wrote: > The section "4.1.1.3. Eliminating Redundant Candidates" states that "a > candidate is redundant if its transport address equals another > candidate, and its base equals the base of that other candidate". > > The next section "4.1.1.4. Computing Foundations" then states that "two > candidates MUST have the same foundation ID when all of the following > are true: they are of the same type, their bases have the same IP, for > server and reflexive candidates, the STUN servers used to obtain them > have the same IP address". > > Be the following scenario: > > - There are two STUN servers configured by an agent A > (200.100.10.50:3478 and 200.100.10.51:3478); > - The agent A have two components (RTP and RTCP); > - The gathering process obtain the following addresses (in order): > * component=1, transport=10.0.0.1:5004/udp, type=local; > * component=2, transport=10.0.0.1:5005/udp, type=local; > * component=2, transport=200.100.10.1:5005/udp, type=srflx, > stunserver=200.100.10.50:3478; > * component=1, transport=200.100.10.1:5004/udp, type=srflx, > stunserver=200.100.10.51:3478; > * component=1, transport=200.100.10.1:5004/udp, type=srflx, > stunserver=200.100.10.50:3478; > * component=2, transport=200.100.10.1:5005/udp, type=srflx, > stunserver=200.100.10.51:3478; > > Following the algorithm described in the section "4.1.1.3", we must > eliminate two of the server reflexive candidates as they have the same > mapped-address. So, by removing the redundant candidates in order > (forward comparison), we get the new candidate list as follows: > > * component=1, transport=10.0.0.1:5004/udp, type=local; > * component=2, transport=10.0.0.1:5005/udp, type=local; > * component=2, transport=200.100.10.1:5005/udp, type=srflx, > stunserver=200.100.10.50:3478; > * component=1, transport=200.100.10.1:5004/udp, type=srflx, > stunserver=200.100.10.51:3478; > > Note that the two server reflexive candidates was obtained by two > different STUN servers. Now I must compute the foundations, then I would > get: > > * foundation=1, component=1, transport=10.0.0.1:5004/udp, type=local; > * foundation=1, component=2, transport=10.0.0.1:5005/udp, type=local; > * foundation=2, component=2, transport=200.100.10.1:5005/udp, > type=srflx, stunserver=200.100.10.50:3478; > * foundation=3, component=1, transport=200.100.10.1:5004/udp, > type=srflx, stunserver=200.100.10.51:3478; > > I expected to have the same foundation for the last two candidates, for > they have the same mapped-address IP and both the STUN servers are > located at the same network. I know it is difficult to discover if two > STUN servers are located in the same network, so I suggest you to review > the section "4.1.1.4" the statement "for reflexive and relayed > candidates, the STUN servers used to obtain them have the same IP > address". I don't know if this is an issue or it is a normal behavior of > the algorithm, but I use these foundations to conclude the ICE > processing (I wait for two candidate pairs with the same foundation to > complete, for QoS purposes). > > Regards, > > Guilherme Balena Versiani > ComunIP S/A > > _______________________________________________ > 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 Fri Jul 13 10:08: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 1I9Loe-00009p-6Y; Fri, 13 Jul 2007 10:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Loc-00009Z-Lj for mmusic@ietf.org; Fri, 13 Jul 2007 10:08:14 -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 1I9LoY-000069-8y for mmusic@ietf.org; Fri, 13 Jul 2007 10:08:14 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2007 07:08:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAB4kl0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="502951996:sNHT27416728" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6DE89KL011864 for ; Fri, 13 Jul 2007 07:08:09 -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 l6DE89mo008757 for ; Fri, 13 Jul 2007 14:08:09 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); Fri, 13 Jul 2007 07:08:09 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 07:08:09 -0700 Message-ID: <4697874E.80304@cisco.com> Date: Fri, 13 Jul 2007 10:08:14 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 14:08:09.0191 (UTC) FILETIME=[3DBC0F70:01C7C557] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1071; t=1184335689; x=1185199689; 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:=20ICE-17=20is=20here |Sender:=20; bh=dbF9hmVDGYbGQ4jSO+EJTpPisldEjjAIJEGPO6cfMng=; b=TrJhXbWAgxK9mfVVmRUbLPjhSaH0IPSYXT4GJyu5G016Wi4qETeehiXIUymY2o+EzHB3sv/I 1HiI1fUeeM85hEy6cSaAX8Gaeh3kCHieZFBUHIYy4BKtZtFVlecweLpZ; 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: ea4ac80f790299f943f0a53be7e1a21a Subject: [MMUSIC] ICE-17 is here 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 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.txt Changes from -16 reflect comments received during the second WGLC period. These are: * clarified that STUN keepalives are not sent by lite implementations * foundation includes transport protocol (UDP only for this spec) * clarified concluding ICE for ICE-lite implementations that are controlled * removed link-local v6 addresses from ICE-lite usage * alignment with rfc3489bis-07 terminology and concepts * moved section on Ta and RTO computation to an appendix and clarified how operation differs in the gathering and connectivity check phases I believe we are done. I have not asked for agenda time for ICE during mmusic (yay!). -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 Jul 13 10:35: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 1I9MEq-0000gn-M2; Fri, 13 Jul 2007 10:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MEp-0000gJ-1z for mmusic@ietf.org; Fri, 13 Jul 2007 10:35:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9MEl-00017f-Nc for mmusic@ietf.org; Fri, 13 Jul 2007 10:35:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2007 07:35:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL8pl0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="181632059:sNHT26801991" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6DEZFge007031 for ; Fri, 13 Jul 2007 07:35:15 -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 l6DEZEka026383 for ; Fri, 13 Jul 2007 14:35:14 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); Fri, 13 Jul 2007 07:34:35 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 07:34:33 -0700 Message-ID: <46978D7F.3050300@cisco.com> Date: Fri, 13 Jul 2007 10:34:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 14:34:34.0008 (UTC) FILETIME=[EE5BF180:01C7C55A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=963; t=1184337315; x=1185201315; 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:=20ICE=20specification=20size=20evolution=20from=20birth=20till= 20now |Sender:=20; bh=LcqokE45imM+xsJTXbeV5y56kk6rgXcG0TLKuHhWe50=; b=Q3KPvmdmFSgHuUVmjWkr77P4rvhDTUG+uy/19W2ZziXj6QBFLl4zAa7KzXWnFu8RsvMddzvm hcJ7Ojrgz971kFKnl7qoHBl2MdOnGecTpFihDbq7Li4/8uEMtH0FPq7EOCnlNxaErbJ5X6KPtU gjHfBBKqBLajLQvyojyvEYtak=; 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [MMUSIC] ICE specification size evolution from birth till now 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 thought it would be interesting to chart the number of pages in the ICE spec as a function of version. The first version appeared in February 2003, and there have been 19 drafts total. For an Excel chart of sizes, see: http://www.jdrosen.net/papers/ice-size.xls Two interesting points to note are: * the spec (and I think all specs) always grow in size from revision to revision, unless there is a major rewrite * The big rewrite we did from ice-9 to ice-10 cut the size down from 109 to 70 pages - a huge improvement. ICE-17 is now up to 111, exceeding the size when we did the rewrite. 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 Jul 13 18:02: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 1I9TDV-0006Mf-54; Fri, 13 Jul 2007 18:02:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TDS-0006MS-N1; Fri, 13 Jul 2007 18:02:22 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9TDR-0002gj-QL; Fri, 13 Jul 2007 18:02:22 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb346982ac1; Sat, 14 Jul 2007 06:13:46 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm86469379d5; Tue, 10 Jul 2007 11:22:48 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 10 Jul 2007 11:22:48 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rbd-0005Zj-Hx; Mon, 09 Jul 2007 07:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7rb1-0004dJ-P0; Mon, 09 Jul 2007 07:40:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7rb0-0004Gd-Ff; Mon, 09 Jul 2007 07:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 683D0328EF; Mon, 9 Jul 2007 11:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7rb0-0002lg-Ao; Mon, 09 Jul 2007 07:40: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: Mon, 09 Jul 2007 07:40:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rtsp-nat-05.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 Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Author(s) : M. Westerlund, T. Zeng Filename : draft-ietf-mmusic-rtsp-nat-05.txt Pages : 8 Date : 2007-07-09 This document defines a solution for Network Address Trans(NAT) traversal for the media stream associated with an Real-time Streaming Protocol version 2 (RTSP 2.0). The mechanism is based on Interactive Connectivity Establishment (ICE) adapted for using RTSP as signalling channel. The necessary RTSP protocol extensions and procedure is defined in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-nat-05.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-rtsp-nat-05.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-rtsp-nat-05.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-07-09073306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-nat-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-nat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-09073306.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 Sat Jul 14 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 1I9kEw-0005cH-SY; Sat, 14 Jul 2007 12:13:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HrL-0003Bu-Qk for mmusic@ietf.org; Tue, 10 Jul 2007 11:42:39 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Hr6-0008Jz-Bd for mmusic@ietf.org; Tue, 10 Jul 2007 11:42:39 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6AFfbUK006707 for ; Tue, 10 Jul 2007 17:41:37 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 10 Jul 2007 17:41:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MMUSIC] help - question on SDP negotiation ( s=line) Date: Tue, 10 Jul 2007 17:41:50 +0200 Message-ID: <4584C1672579A94B9F287B57960F35D4B7E399@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] help - question on SDP negotiation ( s=line) Thread-Index: AcfDCNU2xFP4Zy4DQZGoS95Ds9SrgQ== From: "MARQUES SYLVIE" To: X-OriginalArrivalTime: 10 Jul 2007 15:41:51.0369 (UTC) FILETIME=[D5931790:01C7C308] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Sat, 14 Jul 2007 12:13:01 -0400 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="===============1870885260==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1870885260== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C308.D5828E2A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C308.D5828E2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding the modification of a session: When issuing an offer that modifies the session, must the "s=3D" line be identical to that in the previous SDP or can it be modified? Regards. ------_=_NextPart_001_01C7C308.D5828E2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MMUSIC] help - question on SDP negotiation ( s=3Dline)

Hi,

I have a question = regarding the modification of a session:
When issuing an = offer that modifies the session, must the "s=3D" line be = identical to that in the previous SDP or can it be = modified?

Regards.



------_=_NextPart_001_01C7C308.D5828E2A-- --===============1870885260== 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 --===============1870885260==-- From mmusic-bounces@ietf.org Mon Jul 16 10:38: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 1IARiu-00023m-9B; Mon, 16 Jul 2007 10:38:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARit-00023Q-Bz for mmusic@ietf.org; Mon, 16 Jul 2007 10:38:51 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IARik-0000FY-37 for mmusic@ietf.org; Mon, 16 Jul 2007 10:38:51 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62087 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IARhf-0000M6-Gp; Mon, 16 Jul 2007 15:37:35 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 16 Jul 2007 15:37:32 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Jean-Francois Mule , =?ISO-8859-1?Q?J=F6rg_Ott?= Subject: [MMUSIC] Updated agenda for Chicago 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 Multiparty Multimedia Session Control (MMUSIC) Working Group ============================================================ CHAIRS: Joerg Ott Colin Perkins Jean-Francois Mule AGENDA Tuesday, 24 July 2007 at 15:20-17:20 (Red Lacquer) -------------------------------------------------- 15:20 Introduction and progress report (Chairs, 5) 15:25 Source-Specific Media Attributes in SDP (Lennox, 15) draft-lennox-mmusic-sdp-source-attributes-01.txt 15:40 Media Description for IKE in SDP (Saito, 10) draft-saito-mmusic-sdp-ike-01.txt 15:50 Configuring DSCP of SDP Established Media Streams (Polk, 10) draft-polk-mmusic-dscp-attribute-01.txt 16:00 SDP Offer/Answer Mechanism for File Transfer (Garcia, 20) draft-ietf-mmusic-file-transfer-mech-03.txt 16:20 Multiple Packetization Times in SDP (Garcia, 10) draft-garcia-mmusic-multiple-ptimes-problem-00.txt 16:30 Signaling media decoding dependency in SDP (Schierl, 10) draft-schierl-mmusic-layered-codec-04.txt 16:40 SDP Capability Negotiation (Andreasen, 30) draft-ietf-mmusic-sdp-capability-negotiation-06.txt 17:10 End Wednesday, 25 July 2007 at 13:00-15:00 (Monroe) ----------------------------------------------- 13:00 Introduction (Chairs, 5) 13:05 RTSP 2.0 (Westerlund, 10) draft-ietf-mmusic-rfc2326bis-15.txt 13:15 RTSP NAT (Westerlund, 10) draft-ietf-mmusic-rtsp-nat-evaluation-00.txt 13:25 ICE TCP (Rosenberg, 30) draft-ietf-mmusic-ice-tcp-04.txt 13:55 End _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 16 18:38: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 1IAZD0-0002aO-Fc; Mon, 16 Jul 2007 18:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZCy-0002a0-O5; Mon, 16 Jul 2007 18:38:24 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAZCu-0004qh-3T; Mon, 16 Jul 2007 18:38:24 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Jul 2007 15:38:17 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6GMcAWs027869; Mon, 16 Jul 2007 15:38:11 -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 l6GMaHI9020725; Mon, 16 Jul 2007 15:36:17 -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 Jul 2007 15:38:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jul 2007 15:38:05 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LA== From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 16 Jul 2007 22:38:09.0551 (UTC) FILETIME=[FC35B1F0:01C7C7F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: Cullen Jennings , jon.peterson@neustar.biz Subject: [MMUSIC] ICE deployment data before LC for RFC 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="===============1355585482==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1355585482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C7F9.FBAEDB66" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C7F9.FBAEDB66 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested, * The % of success, * Performance, such as call setup delay using SIP. =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =20 ------_=_NextPart_001_01C7C7F9.FBAEDB66 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The work on ICE is truly impressive and so are the = numerous I-Ds associated with ICE.

 

However, before sending the <ice-17> I-D for LC = to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either = (1) make it an informational RFC or (2) publish some deployment data showing = such items as:

 

  • NAT scenarios that = have been tested,
  • The % of = success,
  • Performance, such as = call setup delay using SIP.

 

I have not seen any such public data on ICE = deployment, for example with SIP. A private report has raised my concern about the = performance of ICE.

 

In the best IETF tradition, it would also help to = have open source code available for ICE, before declaring it a = standard.

 

ICE is too important for the IETF (good work Jonathan = and other authors!) not to publish (1) deployment results and (2) publish = open source code as well.

The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get = resolved with such a process anyway.

 

These are my personal two = cents.

Henry = Sinnreich


 

------_=_NextPart_001_01C7C7F9.FBAEDB66-- --===============1355585482== 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 --===============1355585482==-- From mmusic-bounces@ietf.org Mon Jul 16 21:23: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 1IAbn3-0003bJ-T0; Mon, 16 Jul 2007 21:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbmy-0003Ut-DQ; Mon, 16 Jul 2007 21:23:44 -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 1IAbmt-0000YJ-W2; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 18:23:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANO2m0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="503820034:sNHT29354616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6H1Nc7k013165; Mon, 16 Jul 2007 18:23:38 -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 l6H1NcTb021446; Tue, 17 Jul 2007 01:23:38 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, 16 Jul 2007 18:23:38 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Message-ID: <469C1A1F.2090102@cisco.com> Date: Mon, 16 Jul 2007 21:23:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 01:23:38.0346 (UTC) FILETIME=[1A3B94A0:01C7C811] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1845; t=1184635418; x=1185499418; 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:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY]=20-=20PLEA SE=20ADVISE=20IF=20YOU=20WILL=0A=20ATTEND! |Sender:=20; bh=2mEMezIhgSd4fQtdetbfRv0w1jcLg1hf4bgHjST7IQc=; b=E8JzvIKOXdm/coVCa8PMIpZSSHcW1xP7WCAHJJydd1KTAo4rHvwnnmQbFu0sgmYA2MXhXiTZ 5mrrLKb6+K2doFKdUhVSQSvfLQ1cG+MRM5jN63ABURvqDhDJUyb32NZD; 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: Subject: [MMUSIC] ICE tutorial in Chicago [DO NOT REPLY] - PLEASE ADVISE IF YOU WILL ATTEND! 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've gotten very few responses indicating interest. If I don't get more acceptances I'll have to cancel. Please, if you do plan on attending, send me mail per the instructions below if you have not done so. (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- 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 Jul 17 08:28:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmA6-0000Rl-9Q; Tue, 17 Jul 2007 08:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmA3-0000Mw-Di for mmusic@ietf.org; Tue, 17 Jul 2007 08:28:15 -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 1IAm9x-0005G7-U0 for mmusic@ietf.org; Tue, 17 Jul 2007 08:28:15 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6HCRehf001683 for ; Tue, 17 Jul 2007 15:28:08 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:27:55 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:27:55 +0300 Received: from 4FIL28146 (esdhcp041141.research.nokia.com [172.21.41.141]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6HCRriV015330 for ; Tue, 17 Jul 2007 15:27:54 +0300 From: "Kai Vehmanen" To: References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Date: Tue, 17 Jul 2007 15:27:53 +0300 Organization: Nokia Message-ID: <001901c7c86d$e610a730$8d2915ac@NOE.Nokia.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.3138 Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAbLRxg In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> X-OriginalArrivalTime: 17 Jul 2007 12:27:55.0248 (UTC) FILETIME=[E6CC2F00:01C7C86D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [MMUSIC] open-source ICE implementations (was: RE: ICE deployment data before LC for RFC) 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 Henry and others, I'll only touch the open-source question in this mail, so replying only to mmusic. On 17 July, 2007 Henry Sinnreich wrote: > In the best IETF tradition, it would also help to have > open source code available for ICE, before declaring it a standard. We've been contributing full-mode ICE support (currently updating to ID-17) to the NICE project (LGPL/MPL): http://nice.freedesktop.org/wiki/ There is no TURN support yet, but otherwise the implementation is pretty complete. For information about the ID-17 patchset, see my mail: http://article.gmane.org/gmane.comp.telephony.sofia-sip.devel/1748 New contributor/testers are very much welcome (please contact me off list if you are interested)! As for other open-source implementations, I know at leat PJSIP (GPL) has ICE support (interoperability testing between PJSIP and NICE still a pending task). If there are other implementations out there, let us know! br, -- first.surname@nokia.com (Kai Vehmanen) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 08:41: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 1IAmMk-0005oq-Rc; Tue, 17 Jul 2007 08:41:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAk5Y-0005Mq-HX; Tue, 17 Jul 2007 06:15:28 -0400 Received: from anode.atosc.org ([195.154.245.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAk5T-0000BB-2L; Tue, 17 Jul 2007 06:15:28 -0400 Received: from anode.atosc.org (localhost.localdomain [127.0.0.1]) by internal.atosc.org (Postfix) with ESMTP id EF016FA6B; Tue, 17 Jul 2007 12:06:37 +0200 (CEST) Received: from antisip.antisip.com (unknown [77.197.73.102]) by anode.atosc.org (Postfix) with ESMTP id 9F3EFFA66; Tue, 17 Jul 2007 12:06:37 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by antisip.antisip.com (Postfix) with ESMTP id 41C4E1FE33; Tue, 17 Jul 2007 12:15:19 +0200 (CEST) X-Virus-Scanned: by hand at fauche.org Received: from antisip.antisip.com ([127.0.0.1]) by localhost (antisip.antisip.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFQjivmrBdDq; Tue, 17 Jul 2007 12:15:15 +0200 (CEST) Received: by antisip.antisip.com (Postfix, from userid 1000) id 89DE41FE4D; Tue, 17 Jul 2007 12:15:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by antisip.antisip.com (Postfix) with ESMTP id 877411FE33; Tue, 17 Jul 2007 12:15:15 +0200 (CEST) Date: Tue, 17 Jul 2007 12:15:15 +0200 (CEST) From: Aymeric Moizard X-X-Sender: jack@sip2 To: Henry Sinnreich In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Message-ID: References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on anode.atosc.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=ALL_TRUSTED autolearn=failed version=3.0.3 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Tue, 17 Jul 2007 08:41:20 -0400 Cc: sip@ietf.org, Cullen Jennings , mmusic@ietf.org, jon.peterson@neustar.biz Subject: [MMUSIC] Re: [Sip] ICE deployment data before LC for RFC 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 Henry, On Mon, 16 Jul 2007, Henry Sinnreich wrote: > In the best IETF tradition, it would also help to have open source code > available for ICE, before declaring it a standard. To answer one of your question: I have implemented ICE in open source software (around version 8... not 17): It's available through oRTP and mediastreamer2 library (not used in any open source final application) and still miss only TURN capability. I'm more or less waiting for an RFC before updating to the latest ICE specification... Regards, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 13:00: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 1IAqP4-0006KI-My; Tue, 17 Jul 2007 13:00:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAqP1-00064v-8y; Tue, 17 Jul 2007 12:59:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAqOz-0007Y5-Sz; Tue, 17 Jul 2007 12:59:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 17 Jul 2007 09:59:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAPaRnEarR7O6/2dsb2JhbAAs X-IronPort-AV: i="4.16,546,1175497200"; d="scan'208"; a="504085217:sNHT36300100" 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 l6HGxuDa031702; Tue, 17 Jul 2007 09:59:56 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HGxqA0005709; Tue, 17 Jul 2007 16:59:52 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , , Subject: RE: [MMUSIC] ICE deployment data before LC for RFC Date: Tue, 17 Jul 2007 09:59:51 -0700 Message-ID: <037501c7c893$e6c64650$7d646b80@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.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAl5b7A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3066; t=1184691596; x=1185555596; c=relaxed/simple; s=sjdkim2002; 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=20deployment=20data=20before=20LC=20fo r=20RFC |Sender:=20; bh=/nNmvvhgV9svjXnuOjir+NdlamMt0qgJt53653K2IJc=; b=IBq5sIK9zxdR5Ic0Bk+yF1cwDrEMnJ0/MVY1k9ZOmoZnEk3N6uZxUpQ5PyHMbTfO1puZa+tm dbgV8rk702HhNsoJWxu05sw1VtcEaU8uuOit9hpUdvr+F3li1iynAY/Q; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'Cullen Jennings' , jon.peterson@neustar.biz 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: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Monday, July 16, 2007 3:38 PM > To: mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: [MMUSIC] ICE deployment data before LC for RFC > > The work on ICE is truly impressive and so are the numerous > I-Ds associated with ICE. > > > > However, before sending the I-D for LC to the IESG, > it would be prudent and responsible to the industry (that > spends considerable resources on ICE in good faith) > implementing ICE, to either (1) make it an informational RFC > or To my knowledge, IETF only requires such deployment details and analysis when promoting a Proposed Standard to Draft Standard, and promoting Draft Standard to Internet Standard. Many Internet Drafts don't have deployment results, because they aren't yet deployed nor deployable until they achieve RFC status. As was well witnessed by the many substantive changes to ICE during its development, it is unreasonable to create interoperable implementations with an Internet Draft while that Internet Draft is undergoing substantial and substantive revision. I don't see the value to the community to deny ICE as a standards-track document. Making ICE an Informational document, as you suggest, will only further delay interoperation and deployment of ICE. If ICE had a competing, incrementally- deployable NAT traversal technique, I could see a desire to make one of those techniques a standards track document and the other an informational document; however, there is no such competing, incrementally-deployable NAT traversal technique. ICE should be a standards-track document. > (2) publish some deployment data showing such items as: > > > > * NAT scenarios that have been tested, > * The % of success, > * Performance, such as call setup delay using SIP. > > > > I have not seen any such public data on ICE deployment, for > example with SIP. A private report has raised my concern > about the performance of ICE. I do agree that publishing information, such as what you requested in (2), would be very useful. But publishing such information is not necessary for ICE to be published as a standard-track RFC. > In the best IETF tradition, it would also help to have open > source code available for ICE, before declaring it a standard. I see that already there have been two followups to your request for publicly-available code, pointing at three implementations (NICE, PJSIP, and oRTP/mediastreamer2). > ICE is too important for the IETF (good work Jonathan and > other authors!) not to publish (1) deployment results and (2) > publish open source code as well. > > The various nits discussed on the lists are only of secondary > importance to the LC compared to the above and would get > resolved with such a process anyway. -d > > > > These are my personal two cents. > > Henry Sinnreich > > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 13:51: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 1IArCU-0005Uj-Kh; Tue, 17 Jul 2007 13:51:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArCS-0005TL-N9; Tue, 17 Jul 2007 13:51:04 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=wrk225.corp.jabber.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IArCP-0000id-1m; Tue, 17 Jul 2007 13:51:04 -0400 Received: from wrk225.corp.jabber.com (localhost [127.0.0.1]) by wrk225.corp.jabber.com (Postfix) with ESMTP id D5FA6629DB2; Tue, 17 Jul 2007 11:52:53 -0600 (MDT) Message-ID: <469D01F5.7020704@jabber.org> Date: Tue, 17 Jul 2007 11:52:53 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [MMUSIC] ICE deployment data before LC for RFC References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: sip@ietf.org, Cullen Jennings , mmusic@ietf.org, jon.peterson@neustar.biz 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="===============1129710102==" Errors-To: mmusic-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1129710102== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070404000802050809020102" This is a cryptographically signed message in MIME format. --------------ms070404000802050809020102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: > The work on ICE is truly impressive and so are the numerous I-Ds > associated with ICE. > > However, before sending the I-D for LC to the IESG, it would be > prudent and responsible to the industry (that spends considerable > resources on ICE in good faith) implementing ICE, to either (1) make it > an informational RFC I see no reason for this work not to be standards track. > or (2) publish some deployment data showing such > items as: > > * NAT scenarios that have been tested, > * The % of success, > * Performance, such as call setup delay using SIP. It is my understanding that Google Talk uses something very similar to ICE, which at some point they will migrate to the XMPP profile of ICE defined in XEP-0176 . They are not typically forthcoming with detailed performance data, but the service appears to be fairly robust and on various public discussion lists Google Talk team members have indicated that they successfully establish media exchange about 92+% of the time without a media relay. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070404000802050809020102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzE3MTc1MjUzWjAjBgkqhkiG9w0BCQQxFgQUMm0+4Q6XXzSuWX5bm+e/EjpRFtQwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAgY07McBcSFHX1BatNinl++vJdmj30P4SGEF3ZQrFB1CUuMFT Hg97V5MXqcbwuPuFr0Ls+OuUIECi5I977iX8abSQxiYaT9Zvw/RL6T00qFBTxTYJbDFR2Tq6 4on/wK5RCJg1VGieCDHG7ra4H+S/iRDHjStyuvm7p/YimUUPsQ7yXiPBSA54Ls+wUbd6Bjs1 /6PRl5apVUXRkMpQdQrDxu2TRi5zsL6JGEs5Mg1GsZuhuk/tCEgG5lS8lHjf8J8516zH0hci hX0rycgMC2zbyqkptSxdOMuQFkPAr4MmTGryigcVyoJhRwwKmnCNgpC9iz9X3aDPc3oaCLB0 bj+nqgAAAAAAAA== --------------ms070404000802050809020102-- --===============1129710102== 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 --===============1129710102==-- From mmusic-bounces@ietf.org Tue Jul 17 13:56: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 1IArHH-00017t-11; Tue, 17 Jul 2007 13:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IArHE-0000y0-SX; Tue, 17 Jul 2007 13:56:00 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IArHD-0000dV-FO; Tue, 17 Jul 2007 13:56:00 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6HHtqcc015945; Tue, 17 Jul 2007 12:55:52 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:55:52 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 19:55:49 +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] ICE deployment data before LC for RFC Date: Tue, 17 Jul 2007 19:55:47 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJw References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> From: "DRAGE, Keith \(Keith\)" To: "Henry Sinnreich" , , X-OriginalArrivalTime: 17 Jul 2007 17:55:49.0601 (UTC) FILETIME=[B5A03510:01C7C89B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Cullen Jennings , jon.peterson@neustar.biz 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 SIP WG chair and the document shepherd for draft-ietf-sip-ice-option-tag this is what I shall be doing with regard to the ancillary document in this process... I went to RFC 2026 and carefully read the section on proposed standard: 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. My judgement is that at least the in terms of its draft, the SIP WG has fulfilled the requirements for a request to publish a proposed standard. It appears to me that any further decision about implementation rests with the IESG, who should obviously take into account any submissions made during the IESG last call process. It is therefore my intent to proceed with the publish request for draft-ietf-sip-ice-option-tag. Regards Keith ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 16, 2007 11:38 PM To: mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: [MMUSIC] ICE deployment data before LC for RFC =09 =09 The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested,=20 * The % of success,=20 * Performance, such as call setup delay using SIP.=20 =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =09 =09 =09 =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 14: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 1IAs7v-0004QH-8k; Tue, 17 Jul 2007 14:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7s-0004MY-Aa; Tue, 17 Jul 2007 14:50:24 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAs7q-0003b8-V8; Tue, 17 Jul 2007 14:50:24 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 11:50:19 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HIoDWs025784; Tue, 17 Jul 2007 11:50:17 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HIoB0e007207; Tue, 17 Jul 2007 11:50:12 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:50:11 -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 Date: Tue, 17 Jul 2007 11:50:07 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfIoaN6k6PDRX4fSfO/54PtQP6CcQ== From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 17 Jul 2007 18:50:11.0013 (UTC) FILETIME=[4D942F50:01C7C8A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Cullen Jennings , behave@ietf.org, jon.peterson@neustar.biz Subject: [MMUSIC] Re: ICE deployment data before LC for RFC 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 Following some discussions and soul searching, the best approach for ICE-17 for LC would be to _go ahead and make it an experimental RFC_. This would support the development of interoperable implementations, the collection of deployment data and also hopefully open source code. Though I have full faith in ICE, following the practices that made the IETF successful take precedent here, I believe. This is a change from the attached that I wrote on 7/16/2007. Note: We can only hope the proliferation of SBC in VoIP service provider networks will not make these concerns and ICE for SIP a moot issue, but this is another topic. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. >However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry=20 >(that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or=20 >(2) publish some deployment data showing such items as: >* NAT scenarios that have been tested, >* The % of success, >* Performance, such as call setup delay using SIP. >I have not seen any such public data on ICE deployment, for example with SIP.=20 >A private report has raised my concern about the performance of ICE. >In the best IETF tradition, it would also help to have open source code >available for ICE, before declaring it a standard. >ICE is too important for the IETF (good work Jonathan and other authors!) >not to publish=20 >(1) deployment results and (2) publish open source code as well. >The various nits discussed on the lists are only of secondary importance to >the LC=20 >compared to the above and would get resolved with such a process anyway. >These are my personal two cents. Henry Sinnreich _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 14:50: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 1IAs7w-0004SJ-0T; Tue, 17 Jul 2007 14:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAs7u-0004OX-6B; Tue, 17 Jul 2007 14:50:26 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAs7t-0003b3-NL; Tue, 17 Jul 2007 14:50:26 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 11:50:18 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 l6HIn1ot011398; Tue, 17 Jul 2007 11:49:02 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6HIoB0k007207; Tue, 17 Jul 2007 11:50:16 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:50: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: [MMUSIC] ICE deployment data before LC for RFC Date: Tue, 17 Jul 2007 11:48:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJwAAIRH/A= References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> From: "Henry Sinnreich" To: "DRAGE, Keith (Keith)" , , X-OriginalArrivalTime: 17 Jul 2007 18:50:15.0060 (UTC) FILETIME=[4FFDB540:01C7C8A3] X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Cullen Jennings , behave@ietf.org, jon.peterson@neustar.biz 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 Keith, Thanks for the attention and sorry our mail has crossed. Feel free to proceed as you best think. (I have made my point as well). Henry -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, July 17, 2007 10:56 AM To: Henry Sinnreich; mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: RE: [MMUSIC] ICE deployment data before LC for RFC As SIP WG chair and the document shepherd for draft-ietf-sip-ice-option-tag this is what I shall be doing with regard to the ancillary document in this process... I went to RFC 2026 and carefully read the section on proposed standard: 4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. My judgement is that at least the in terms of its draft, the SIP WG has fulfilled the requirements for a request to publish a proposed standard. It appears to me that any further decision about implementation rests with the IESG, who should obviously take into account any submissions made during the IESG last call process. It is therefore my intent to proceed with the publish request for draft-ietf-sip-ice-option-tag. Regards Keith ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Monday, July 16, 2007 11:38 PM To: mmusic@ietf.org; sip@ietf.org Cc: Cullen Jennings; jon.peterson@neustar.biz Subject: [MMUSIC] ICE deployment data before LC for RFC =09 =09 The work on ICE is truly impressive and so are the numerous I-Ds associated with ICE. =20 However, before sending the I-D for LC to the IESG, it would be prudent and responsible to the industry (that spends considerable resources on ICE in good faith) implementing ICE, to either (1) make it an informational RFC or (2) publish some deployment data showing such items as: =20 * NAT scenarios that have been tested,=20 * The % of success,=20 * Performance, such as call setup delay using SIP.=20 =20 I have not seen any such public data on ICE deployment, for example with SIP. A private report has raised my concern about the performance of ICE. =20 In the best IETF tradition, it would also help to have open source code available for ICE, before declaring it a standard. =20 ICE is too important for the IETF (good work Jonathan and other authors!) not to publish (1) deployment results and (2) publish open source code as well. The various nits discussed on the lists are only of secondary importance to the LC compared to the above and would get resolved with such a process anyway. =20 These are my personal two cents. Henry Sinnreich =09 =09 =09 =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 14:59: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 1IAsGF-0000Vg-LF; Tue, 17 Jul 2007 14:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsGD-0000UY-5d; Tue, 17 Jul 2007 14:59:01 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsGC-0003v1-NJ; Tue, 17 Jul 2007 14:59:01 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6HIww9H004652; Tue, 17 Jul 2007 13:58:58 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 13:58:58 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 20:58:56 +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] ICE deployment data before LC for RFC Date: Tue, 17 Jul 2007 20:58:55 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180014366C2@DEEXC1U01.de.lucent.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] ICE deployment data before LC for RFC Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAoNGJwAAIRH/AAADGJEA== References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <5D1A7985295922448D5550C94DE29180014366B4@DEEXC1U01.de.lucent.com> <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F6@namail5.corp.adobe.com> From: "DRAGE, Keith \(Keith\)" To: "Henry Sinnreich" , , X-OriginalArrivalTime: 17 Jul 2007 18:58:56.0655 (UTC) FILETIME=[86E2C9F0:01C7C8A4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Cullen Jennings , behave@ietf.org, jon.peterson@neustar.biz 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 further word on this. Attempting to do any status change is going to create all sorts of downreferencing problems, which while not unresolvable, will certainly delay getting this out. In order to register a new SIP option tag, draft-ietf-sip-ice-option-tag must be a standards track document. RFC 3427 mandates this. Draft-ietf-sip-ice-option-tag normatively references draft-ietf-mmusic-ice. If the former is standards track and the latter is either informational or experimental, I understand that would be a down reference.=20 I was unable to fire up the reference dependency tool to find out what other intended standards track documents normatively referenced draft-ietf-mmusic-ice, but I suspect there are a number. I would therefore suggest you investigate the potential referencing impact further if you wish to proceed. Regards Keith > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Tuesday, July 17, 2007 7:48 PM > To: DRAGE, Keith (Keith); mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz; behave@ietf.org > Subject: RE: [MMUSIC] ICE deployment data before LC for RFC >=20 > Keith, >=20 > Thanks for the attention and sorry our mail has crossed. >=20 > Feel free to proceed as you best think. (I have made my point=20 > as well). >=20 > Henry >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Tuesday, July 17, 2007 10:56 AM > To: Henry Sinnreich; mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: RE: [MMUSIC] ICE deployment data before LC for RFC >=20 > As SIP WG chair and the document shepherd for=20 > draft-ietf-sip-ice-option-tag this is what I shall be doing=20 > with regard to the ancillary document in this process... >=20 > I went to RFC 2026 and carefully read the section on proposed=20 > standard: >=20 >=20 > 4.1.1 Proposed Standard >=20 > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. >=20 > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood,=20 > has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. >=20 > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. >=20 > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. >=20 > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be=20 > useful and > necessary (and timely) even with known technical omissions. >=20 > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. >=20 > My judgement is that at least the in terms of its draft, the=20 > SIP WG has fulfilled the requirements for a request to=20 > publish a proposed standard. > It appears to me that any further decision about=20 > implementation rests with the IESG, who should obviously take=20 > into account any submissions made during the IESG last call process. >=20 > It is therefore my intent to proceed with the publish request=20 > for draft-ietf-sip-ice-option-tag. >=20 > Regards >=20 > Keith >=20 >=20 > ________________________________ >=20 > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Monday, July 16, 2007 11:38 PM > To: mmusic@ietf.org; sip@ietf.org > Cc: Cullen Jennings; jon.peterson@neustar.biz > Subject: [MMUSIC] ICE deployment data before LC for RFC > =09 > =09 >=20 > The work on ICE is truly impressive and so are the=20 > numerous I-Ds associated with ICE. >=20 > =20 >=20 > However, before sending the I-D for LC to the=20 > IESG, it would be prudent and responsible to the industry=20 > (that spends considerable resources on ICE in good faith)=20 > implementing ICE, to either > (1) make it an informational RFC or (2) publish some=20 > deployment data showing such items as: >=20 > =20 >=20 > * NAT scenarios that have been tested,=20 > * The % of success,=20 > * Performance, such as call setup delay using SIP.=20 >=20 > =20 >=20 > I have not seen any such public data on ICE deployment,=20 > for example with SIP. A private report has raised my concern=20 > about the performance of ICE. >=20 > =20 >=20 > In the best IETF tradition, it would also help to have=20 > open source code available for ICE, before declaring it a standard. >=20 > =20 >=20 > ICE is too important for the IETF (good work Jonathan and other > authors!) not to publish (1) deployment results and (2)=20 > publish open source code as well. >=20 > The various nits discussed on the lists are only of=20 > secondary importance to the LC compared to the above and=20 > would get resolved with such a process anyway. >=20 > =20 >=20 > These are my personal two cents. >=20 > Henry Sinnreich > =09 > =09 > =09 >=20 > =20 >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 17 15:06:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsNG-0005rJ-Oh; Tue, 17 Jul 2007 15:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsNF-0005rE-TZ for mmusic@ietf.org; Tue, 17 Jul 2007 15:06:17 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsNC-0004Co-D4 for mmusic@ietf.org; Tue, 17 Jul 2007 15:06:17 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 12:06:09 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 l6HJ4rot014020; Tue, 17 Jul 2007 12:04:53 -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 l6HJ4GI9020753; Tue, 17 Jul 2007 12:04:16 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:06: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: RE: [MMUSIC] open-source ICE implementations (was: RE: ICE deploymentdata before LC for RFC) Date: Tue, 17 Jul 2007 12:06:04 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED438@namail5.corp.adobe.com> In-Reply-To: <001901c7c86d$e610a730$8d2915ac@NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] open-source ICE implementations (was: RE: ICE deploymentdata before LC for RFC) Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAbLRxgAA+vKeA= References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <001901c7c86d$e610a730$8d2915ac@NOE.Nokia.com> From: "Henry Sinnreich" To: "Kai Vehmanen" , X-OriginalArrivalTime: 17 Jul 2007 19:06:08.0879 (UTC) FILETIME=[8882EFF0:01C7C8A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Kai, Can you also share deployment results, such as the success ratio in various NAT scenarios? Henry -----Original Message----- From: Kai Vehmanen [mailto:kai.vehmanen@nokia.com]=20 Sent: Tuesday, July 17, 2007 5:28 AM To: mmusic@ietf.org Subject: [MMUSIC] open-source ICE implementations (was: RE: ICE deploymentdata before LC for RFC) Hello Henry and others, I'll only touch the open-source question in this mail, so replying only to mmusic. On 17 July, 2007 Henry Sinnreich wrote: > In the best IETF tradition, it would also help to have=20 > open source code available for ICE, before declaring it a standard. We've been contributing full-mode ICE support (currently updating to ID-17) to the NICE project (LGPL/MPL): http://nice.freedesktop.org/wiki/ There is no TURN support yet, but otherwise the implementation is pretty complete. For information about the ID-17 patchset, see my mail: http://article.gmane.org/gmane.comp.telephony.sofia-sip.devel/1748 New contributor/testers are very much welcome (please contact me off=20 list if you are interested)! As for other open-source implementations, I know at leat PJSIP (GPL) has ICE support (interoperability testing between PJSIP and NICE still=20 a pending task). If there are other implementations out there, let=20 us know! br, --=20 first.surname@nokia.com (Kai Vehmanen) _______________________________________________ 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 Jul 18 04:10: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 1IB4cT-0001gf-Kg; Wed, 18 Jul 2007 04:10:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB4cR-0001f5-2L; Wed, 18 Jul 2007 04:10:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB4cP-0000Th-2l; Wed, 18 Jul 2007 04:10:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4F5D1215D8; Wed, 18 Jul 2007 10:10:44 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-61-469dcb042312 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 27FA6204A6; Wed, 18 Jul 2007 10:10:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:10:43 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 10:10:43 +0200 Message-ID: <469DCB03.9040300@ericsson.com> Date: Wed, 18 Jul 2007 10:10:43 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 08:10:43.0584 (UTC) FILETIME=[2338E000:01C7C913] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. > > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. > > This is a change from the attached that I wrote on 7/16/2007. > > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. Henry, I don't quite understand why you are requesting a status change of ICE? To me it appears that ICE is almost finished spec. It has been implemented, used and feedback has been influencing the protocol. It is definitly one of the better examples of current IETF work that actually has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE works in the intended core cases. If there are some corner cases where it fails, that may be. But that is not information we will have until really large scale deployement or someone makes very extensive tests. I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. And to be clear, proposed standard is allowed to be published without a single implementation exists. It might not be good practice, but it is allowed by our process. And as I said before ICE has had enough implementation that I am very confortable in balloting YES for it when it appears on the IESGs table. 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 Jul 18 08:42: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 1IB8r3-0005qs-Bf; Wed, 18 Jul 2007 08:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB8r2-0005qj-Bw for mmusic@ietf.org; Wed, 18 Jul 2007 08:42:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB8r1-000808-Gi for mmusic@ietf.org; Wed, 18 Jul 2007 08:42:08 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 04C3820ACB for ; Wed, 18 Jul 2007 14:42:07 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-f9-469e0a9e4723 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DA87720C59 for ; Wed, 18 Jul 2007 14:42:06 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:42:06 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:42:06 +0200 Message-ID: <469E0A9E.1070505@ericsson.com> Date: Wed, 18 Jul 2007 14:42:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "mmusic (E-mail)" , =?UTF-8?B?IlBlciBGcsO2amRoIChLSS8=?= =?UTF-8?B?RUFCKSI=?= Content-Type: multipart/mixed; boundary="------------060809070403050307070501" X-OriginalArrivalTime: 18 Jul 2007 12:42:06.0224 (UTC) FILETIME=[0C6E9100:01C7C939] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Subject: [MMUSIC] [Fwd: I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-05.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 This is a multi-part message in MIME format. --------------060809070403050307070501 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, We have finally managed to update the draft to take care of the comments raised by Jean-Francois. We also have addressed the issue with meeting the registration requirements for SDP "proto" identifiers which requires an RFC to document the definition. A normative definition of the protocol identifiers are now included in this document. Please provide any comments before the 27th of August. We plan to request publication if no comments has been received by then. 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 ---------------------------------------------------------------------- --------------060809070403050307070501 Content-Type: message/rfc822; name="I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt.eml" Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 21:22:17 +0200 Received: from mailgw1.ericsson.se ([193.180.251.45]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 21:22:16 +0200 Received: from mailgw1.ericsson.se (unknown [127.0.0.1]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id F202E400BC; Fri, 6 Jul 2007 21:22:15 +0200 (CEST) X-AuditID: c1b4fb2d-b0d96bb000000838-11-468e966779d9 Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id 3FB49401DB; Fri, 6 Jul 2007 21:22:15 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tGs-0005Bm-VK; Fri, 06 Jul 2007 15:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tGq-00054v-NR for i-d-announce@ietf.org; Fri, 06 Jul 2007 15:15:12 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6tGq-00055U-4s for i-d-announce@ietf.org; Fri, 06 Jul 2007 15:15:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 045D92ACC1 for ; Fri, 6 Jul 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6tGf-0006QW-P5 for i-d-announce@ietf.org; Fri, 06 Jul 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jul 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: I-D ACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Brightmail-Tracker: AAAAAA== Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 06 Jul 2007 19:22:16.0111 (UTC) FILETIME=[F67B93F0:01C7C002] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service Author(s) : P. Frojdh, M. Westerlund Filename : draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt Pages : 21 Date : 2007-7-6 The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-mmusic-3gpp-sdp-rtsp-05.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-westerlund-mmusic-3gpp-sdp-rtsp-05.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-westerlund-mmusic-3gpp-sdp-rtsp-05.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-7-6140705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-6140705.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-- --------------060809070403050307070501 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 --------------060809070403050307070501-- From mmusic-bounces@ietf.org Wed Jul 18 10:20: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 1IBAOY-0000Sb-3T; Wed, 18 Jul 2007 10:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAOT-0000ED-Ta; Wed, 18 Jul 2007 10:20:45 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAOS-0002QK-2I; Wed, 18 Jul 2007 10:20:45 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 07:20:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IEKWWs012870; Wed, 18 Jul 2007 07:20:32 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IEKT0g004802; Wed, 18 Jul 2007 07:20:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 07:20:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 07:20:23 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> In-Reply-To: <469DCB03.9040300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkg References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> From: "Henry Sinnreich" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 14:20:30.0725 (UTC) FILETIME=[CBC9EB50:01C7C946] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0c92ca299e0607fbf0058472806b19df Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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="===============1000954299==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1000954299== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C946.CB4C2FCF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C946.CB4C2FCF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Magnus, =20 I sincerely appreciate your interest and this note! =20 > I don't quite understand why you are requesting a status change of ICE =20 However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: =20 RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be.=20 =20 The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07. txt=20 What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? =20 By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as =20 "NAT Classification Test Results" =20 "Application Design Guidelines for Traversal through Network Address Translators"=20 The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators"=20 http://www.brynosaurus.com/pub/net/p2pnat/ =20 I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. =20 What happens if indeed hole punching proves to be the far more effective approach? =20 The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). =20 Thanks again for your attention to this concern about ICE.=20 Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. =20 Henry =20 =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC =20 Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >=20 > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. >=20 > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. >=20 > This is a change from the attached that I wrote on 7/16/2007. >=20 > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. =20 Henry, =20 I don't quite understand why you are requesting a status change of ICE?=20 To me it appears that ICE is almost finished spec. It has been=20 implemented, used and feedback has been influencing the protocol. It is=20 definitly one of the better examples of current IETF work that actually=20 has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE=20 works in the intended core cases. If there are some corner cases where=20 it fails, that may be. But that is not information we will have until=20 really large scale deployement or someone makes very extensive tests. =20 I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. =20 And to be clear, proposed standard is allowed to be published without a=20 single implementation exists. It might not be good practice, but it is=20 allowed by our process. And as I said before ICE has had enough=20 implementation that I am very confortable in balloting YES for it when=20 it appears on the IESGs table. =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 ---------------------------------------------------------------------- ------_=_NextPart_001_01C7C946.CB4C2FCF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Magnus,

 

I sincerely appreciate your interest and this = note!

 

> I don't quite understand why you are requesting a status = change of ICE

 

However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

 

RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be = used in the context of a NAT traversal solution. This is an important change = from the previous version of this specification (RFC 3489), which presented STUN = as a complete solution."

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

 

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

 

By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

 

"NAT Classification Test = Results"

 

"Application Design Guidelines for Traversal through = Network Address Translators"

The measurements for hole punching are reported = in

"Peer-to-Peer Communication Across Network Address Translators"

http://www.brynosauru= s.com/pub/net/p2pnat/

 

I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, but not yet = a standard so that:

 1. Independent, compliant implementations will be = developed,

 2. Testing in events such as = SIPit,

 3. Reporting the results, such as reported for the = "hole punching" above.

 

What happens if indeed hole punching proves to be the far more effective approach?

 

The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing = the right quotes).

 

Thanks again for your attention to this concern about ICE. =

Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

 

Henry

 

 

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

 

Henry = Sinnreich skrev:

> Following some discussions and soul searching, the best = approach for

> ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

>

> This would support the development of interoperable implementations, the

> collection of deployment data and also hopefully open = source code.

>

> Though I have full faith in ICE, following the practices = that made the

> IETF successful take precedent here, I = believe.

>

> This is a change from the attached that I wrote on = 7/16/2007.

>

> Note: We can only hope the proliferation of SBC in VoIP = service provider

> networks will not make these concerns and ICE for SIP a = moot issue, but

> this is another topic.

 

Henry,

 

I don't quite understand why you are requesting a status change = of ICE?

To me it appears that ICE is almost finished spec. It has been =

implemented, used and feedback has been influencing the = protocol. It is

definitly one of the better examples of current IETF work that = actually

has running code. Sure, the implementations may not be fully = updated yet

to the latest draft version. But I think it is safe to say that = ICE

works in the intended core cases. If there are some corner cases = where

it fails, that may be. But that is not information we will have = until

really large scale deployement or someone makes very extensive = tests.

 

I think the IETF and the Internet has much more benefit from a standards

track solution than any of the risks existing with ICE of = today.

 

And to be clear, proposed standard is allowed to be published = without a

single implementation exists. It might not be good practice, but = it is

allowed by our process. And as I said before ICE has had enough =

implementation that I am very confortable in balloting YES for = it when

it appears on the IESGs table.

 

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

-----------------------------------------------------------------= -----

------_=_NextPart_001_01C7C946.CB4C2FCF-- --===============1000954299== 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 --===============1000954299==-- From mmusic-bounces@ietf.org Wed Jul 18 11:37: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 1IBBaW-0000pP-14; Wed, 18 Jul 2007 11:37:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBaU-0000oz-Kq for mmusic@ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: from web33301.mail.mud.yahoo.com ([68.142.206.116]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBBaS-0005ih-PK for mmusic@ietf.org; Wed, 18 Jul 2007 11:37:14 -0400 Received: (qmail 20356 invoked by uid 60001); 18 Jul 2007 15:37:12 -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=RcWaY5dlPfv7Wn3bij5Yf8r9MyWFv3X7biBuAwQPozF1tnGNjOKR3Akeq04ufr9PpQZFrcNa5fmPB5DfiWJx9m2TC1+Lko5IOEX83LPy0y4quxBwXdK/9uRTUeeIN6goG5I1q1/UQq5sEXeU7u8oqsx3JzwY580a3M0pmCbAUk4=; X-YMail-OSG: YHPVtOsVM1muHnYjzgz5BvnlxjIGUXyjqCvFQHcu Received: from [69.236.76.222] by web33301.mail.mud.yahoo.com via HTTP; Wed, 18 Jul 2007 08:37:12 PDT Date: Wed, 18 Jul 2007 08:37:12 -0700 (PDT) From: Pyda Srisuresh To: "Frank W. Miller" , 'Henry Sinnreich' , 'Magnus Westerlund' In-Reply-To: <20070718145339.3E9A5758069@smtpauth00.csee.onr.siteprotect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <239224.19734.qm@web33301.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 to Henry and Frank for so eloquently articulating this. As both Henry and Frank mentioned, I fully support standardizing on HOLE PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to force NAT vendors to migrate towards implementations that are friendly to Hole Punching and the Application developers to design applications using the hole punching techniques. That should be the FIRST order of priority. Yet, what is happening in BEHAVE WG is the other way around. Some people have put their weight so heavily in favor of ICE that they asked to drop the work on hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT Traveral application design guidelines" as BEHAVE WG milestone. Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING TECHNIQUES to move forward as a WG item? regards, suresh --- "Frank W. Miller" wrote: > > > Greetings, > > > > What I think Henry is advocating is a systematic approach to making sure > that the content of the ICE spec is right for its intended purpose, i.e. a > complete, general NAT traversal solution. NAT traversal has been in my > opinion one of the most difficult aspects of SIP implementation and its very > important that its eventual standardized solution be right. I know I spent > a lot of time implementing all the "tests" in the first 3489, only to > discover that they were not that useful. There are two valid technical > concerns that are put forth in this email: > > > > 1) Viability of correct operation in practical implementations. ICE can > result in very complicated message transfers. > > 2) Performance. As pointed out in this email and in other places, the > additional latency associated with ICE operations can be significant. > > > > Henry also points out that there are competing approaches (e.g. Hole > Punching) that can perform well in many situations and have better > performance. IMHO, another approach by the IETF in general would be to > standardize on Hole Punching and leverage the IETF's considerable influence > to force NAT vendors to migrate towards implementations that are friendly to > Hole Punching. > > > > The bottom line is that I agree with Henry in that labeling ICE as an > experimental draft is the right thing to do. It will allow those > implementing ICE (including myself in all likelihood) to proceed but signals > to the users the correct status of the standard's contents. > > > > I also want to applaud loudly the underlying tone of Henry's thread here. > That is, in solving specific technical problems within the IETF forum, > focusing on empirical observation of working implementations should be the > MO that we all strive for when developing and proposing what may become > protocol standards. > > > > Thanks, > > FM > > > > > > _____ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, July 18, 2007 8:20 AM > To: Magnus Westerlund > Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > > > Magnus, > > > > I sincerely appreciate your interest and this note! > > > > > I don't quite understand why you are requesting a status change of ICE > > > > However the arguments stated by the WG co-chairs and by you here are > procedural in nature, whereas the facts are some cause for serious concern, > and I will just mention a few facts: > > > > RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, > but now clearly admits that "STUN is not a > NAT traversal solution by itself. Rather, it is a tool to be used in the > context of a NAT traversal solution. This is an important change from the > previous version of this specification (RFC 3489), which presented STUN as a > complete solution." > > http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt > > My guess is, in plain English, RFC 3489 turned out just NOT to be an > acceptable solution as it was hoped to be. > > > > The excellent I-D shows the ICE call > flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 > messages just for the SIP INVITE! > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt > > What happens if the two endpoints are in different ISPs that have NAT of > their own in addition to the ones in Fig. 22? > > What happens if one would try ICE along a P2PSIP route with say 5-8 hops? > Would there be hundreds of messages? What is the likelihood for failure? > > > > By contrast with such approaches based on hope and faith, the BEHAVE WG has > produced work based on real measurements and tools to do the measurements, > such as > > > > "NAT Classification Test Results" > > > > "Application Design Guidelines for Traversal through Network Address > Translators" > > The measurements for hole punching are reported in > > "Peer-to-Peer Communication Across Network Address Translators" > > http://www.brynosaurus.com/pub/net/p2pnat/ > > > > I am also a believer in ICE and have actually urged Jonathan Rosenberg to do > this work and he has given his best. Now that we have ICE-17 version, it is > in the best interest of the industry and the IETF to make it an experimental > RFC, but not yet a standard so that: > > 1. Independent, compliant implementations will be developed, > > 2. Testing in events such as SIPit, > > 3. Reporting the results, such as reported for the "hole punching" above. > > > > What happens if indeed hole punching proves to be the far more effective > approach? > > > > The industry can ill afford a new series of RFC[ICE]-bis and all the years > it takes to move from believing to measuring and proving. I am sure IETF > procedures were meant in this spirit (though I am not good in producing the > right quotes). > > > > Thanks again for your attention to this concern about ICE. > > Also my apology to all the anguish to the numerous contributors to the ICE > related I-Ds, but writing test tools and reporting measurements is the right > way to go. > > > > Henry > > > > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, July 18, 2007 1:11 AM > To: Henry Sinnreich > Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > > > Henry Sinnreich skrev: > > > Following some discussions and soul searching, the best approach for > > > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > > > > > This would support the development of interoperable implementations, the > > > collection of deployment data and also hopefully open source code. > > > > > > Though I have full faith in ICE, following the practices that made the > > > IETF successful take precedent here, I believe. > > > > > > This is a change from the attached that I wrote on 7/16/2007. > > > > > > Note: We can only hope the proliferation of SBC in VoIP service provider > > > networks will not make these concerns and ICE for SIP a moot issue, but > > > this is another topic. > > > > Henry, > > > > I don't quite understand why you are requesting a status change of ICE? > > To me it appears that ICE is almost finished spec. It has been > > implemented, used and feedback has been influencing the protocol. It is > > definitly one of the better examples of current IETF work that actually > > has running code. Sure, the implementations may not be fully updated yet > > to the latest draft version. But I think it is safe to say that ICE > > works in the intended core cases. If there are some corner cases where > > it fails, that may be. But that is not information we will have until > > really large scale deployement or someone makes very extensive tests. > > > > I think the IETF and the Internet has much more benefit from a standards > > track solution than any of the risks existing with ICE of today. > > > > And to be clear, proposed standard is allowed to be published without a > > single implementation exists. It might not be good practice, but it is > > allowed by our process. And as I said before ICE has had enough > > implementation that I am very confortable in balloting YES for it when > > it appears on the IESGs table. > > > > 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 > > ---------------------------------------------------------------------- > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 12:13: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 1IBC97-0003d2-7H; Wed, 18 Jul 2007 12:13:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBC90-0003D0-FT; Wed, 18 Jul 2007 12:12:55 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBC8y-0006mc-Qd; Wed, 18 Jul 2007 12:12:54 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.101]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IBC8x-0005M0-FG; Wed, 18 Jul 2007 11:12:51 -0500 In-Reply-To: <469DCB03.9040300@ericsson.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> 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: Dean Willis Date: Wed, 18 Jul 2007 11:12:27 -0500 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > Henry Sinnreich skrev: >> Following some discussions and soul searching, the best approach for >> ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >> This would support the development of interoperable >> implementations, the >> collection of deployment data and also hopefully open source code. >> Though I have full faith in ICE, following the practices that made >> the >> IETF successful take precedent here, I believe. >> This is a change from the attached that I wrote on 7/16/2007. >> Note: We can only hope the proliferation of SBC in VoIP service >> provider >> networks will not make these concerns and ICE for SIP a moot >> issue, but >> this is another topic. > > Henry, > > I don't quite understand why you are requesting a status change of > ICE? To me it appears that ICE is almost finished spec. It has been > implemented, used and feedback has been influencing the protocol. > It is definitly one of the better examples of current IETF work > that actually has running code. Sure, the implementations may not > be fully updated yet to the latest draft version. But I think it is > safe to say that ICE works in the intended core cases. If there are > some corner cases where it fails, that may be. But that is not > information we will have until really large scale deployement or > someone makes very extensive tests. Henry has, I believe, been very consistent in urging the IETF to have more "running code" experience on every specification (not just ICE) than our process requires. He has, IIRC, also advocated changing the process to require running code before publishing an RFC. He's even suggested at times that one should have running code before submitting a protocol draft. Another point to consider -- I've known Henry to bark at a tree with no squirrel in it occasionally, but most of the time he's pretty reliable, more so than most technology predictors. If he's worried about ICE, it's probably because he's been talking to people who are trying to implement it and they're telling him it is difficult or that they're having performance or reliability issues. I imagine that there are plenty of internal development teams in various companies that are working on this and not necessarily bringing their results back to the IETF. After all, if everybody sees the emperor as fully clothed, they'd be embarrassed to proclaim otherwise. Of course, I wish all of these developers were tied into the IETF, but then I'm sure I don't want to see every ice-implementor's question on the SIP list. That is why we have a sip-implementors mailing list, right? Personally, I think ICE is the best solution we have. We KNOW of cases where hole-punching doesn't work, and I think ICE will produce usable results in most of those cases. But that's just my personal opinion from reading the specs. I haven't implemented ICE, and I haven't used anybody else's implementation. Sure, it's complex, but that's because the underlying problem is complex -- there are just too many different behaviors out there in "NAT and firewall land". Of course, I could be wrong, too. It's happened before, once or twice ;-). Just how sure are we that we're right about this? Are we designing a "spruce goose" or a practical system? Only experience will tell us. But some good flight reports from the prototypes could go a long way towards reassuring us of the design's utility. So far we've had a couple of people report hearsay evidence -- that somebody else has an ICE implementation and it works. Any of you folks have personal experience you can share? Have there been prototypes exercised at the interop events? -- Dean _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 12:27: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 1IBCMd-0008Qn-9e; Wed, 18 Jul 2007 12:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCMW-0008Ew-2z; Wed, 18 Jul 2007 12:26:52 -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 1IBCMU-0005zP-QB; Wed, 18 Jul 2007 12:26:52 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBCMO-0007sj-2C; Wed, 18 Jul 2007 12:26:45 -0400 In-Reply-To: <239224.19734.qm@web33301.mail.mud.yahoo.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Date: Wed, 18 Jul 2007 12:26:55 -0400 To: Pyda Srisuresh X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: 'Magnus Westerlund' , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, "Frank W. Miller" Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20= the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20= > HOLE > PUNCHING TECHNIQUE and leveraging the IETF=92s considerable influence =20= > to force > NAT vendors to migrate towards implementations that are friendly to =20= > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20= > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20= > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20= >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20= >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20= >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20= >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20= >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> Cheers >> >> >> >> Magnus Westerlund >> >> >> >> IETF Transport Area Director & TSVWG Chair >> >> ---------------------------------------------------------------------=20= >> - >> >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> >> ---------------------------------------------------------------------=20= >> - >> >> Ericsson AB | Phone +46 8 4048287 >> >> Torshamsgatan 23 | Fax +46 8 7575550 >> >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> ---------------------------------------------------------------------=20= >> - >> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 12:29: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 1IBCOo-0002rz-QA; Wed, 18 Jul 2007 12:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAuM-0000Ms-F4; Wed, 18 Jul 2007 10:53:42 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAuK-0003FJ-Jn; Wed, 18 Jul 2007 10:53:42 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 3E9A5758069; Wed, 18 Jul 2007 09:53:39 -0500 (CDT) From: "Frank W. Miller" To: "'Henry Sinnreich'" , "'Magnus Westerlund'" Date: Wed, 18 Jul 2007 08:53:30 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAKU9CA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070718145339.3E9A5758069@smtpauth00.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c3f5218b222da1e73e850f1438da613 X-Mailman-Approved-At: Wed, 18 Jul 2007 12:29:12 -0400 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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="===============2024568811==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2024568811== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C7C919.1DDFF390" This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C7C919.1DDFF390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, What I think Henry is advocating is a systematic approach to making sure that the content of the ICE spec is right for its intended purpose, i.e. a complete, general NAT traversal solution. NAT traversal has been in my opinion one of the most difficult aspects of SIP implementation and its very important that its eventual standardized solution be right. I know I spent a lot of time implementing all the "tests" in the first 3489, only to discover that they were not that useful. There are two valid technical concerns that are put forth in this email: 1) Viability of correct operation in practical implementations. ICE can result in very complicated message transfers. 2) Performance. As pointed out in this email and in other places, the additional latency associated with ICE operations can be significant. Henry also points out that there are competing approaches (e.g. Hole Punching) that can perform well in many situations and have better performance. IMHO, another approach by the IETF in general would be to standardize on Hole Punching and leverage the IETF's considerable influence to force NAT vendors to migrate towards implementations that are friendly to Hole Punching. The bottom line is that I agree with Henry in that labeling ICE as an experimental draft is the right thing to do. It will allow those implementing ICE (including myself in all likelihood) to proceed but signals to the users the correct status of the standard's contents. I also want to applaud loudly the underlying tone of Henry's thread here. That is, in solving specific technical problems within the IETF forum, focusing on empirical observation of working implementations should be the MO that we all strive for when developing and proposing what may become protocol standards. Thanks, FM _____ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, July 18, 2007 8:20 AM To: Magnus Westerlund Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Magnus, I sincerely appreciate your interest and this note! > I don't quite understand why you are requesting a status change of ICE However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be. The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07.txt What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as "NAT Classification Test Results" "Application Design Guidelines for Traversal through Network Address Translators" The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators" http://www.brynosaurus.com/pub/net/p2pnat/ I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. What happens if indeed hole punching proves to be the far more effective approach? The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). Thanks again for your attention to this concern about ICE. Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. Henry -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. > > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. > > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. > > This is a change from the attached that I wrote on 7/16/2007. > > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. Henry, I don't quite understand why you are requesting a status change of ICE? To me it appears that ICE is almost finished spec. It has been implemented, used and feedback has been influencing the protocol. It is definitly one of the better examples of current IETF work that actually has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE works in the intended core cases. If there are some corner cases where it fails, that may be. But that is not information we will have until really large scale deployement or someone makes very extensive tests. I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. And to be clear, proposed standard is allowed to be published without a single implementation exists. It might not be good practice, but it is allowed by our process. And as I said before ICE has had enough implementation that I am very confortable in balloting YES for it when it appears on the IESGs table. 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 ---------------------------------------------------------------------- ------=_NextPart_000_00CF_01C7C919.1DDFF390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Greetings,<= /p>

 

What I think Henry is advocating is = a systematic approach to making sure that the content of the ICE spec is = right for its intended purpose, i.e. a complete, general NAT traversal = solution.  NAT traversal has been in my opinion one of the most difficult aspects = of SIP implementation and its very important that its eventual standardized = solution be right.  I know I spent a lot of time implementing all the = “tests” in the first 3489, only to discover that they were not that = useful.  There are two valid technical concerns that are put forth in this = email:

 

1)     = Viability of correct operation in practical implementations.  ICE can result in very complicated message transfers.

2)     = Performance.  As pointed out in this email and in other places, the additional latency associated with ICE operations can be = significant.

 

Henry also points out that there = are competing approaches (e.g. Hole Punching) that can perform well in many situations and have better performance.  IMHO, another approach by = the IETF in general would be to standardize on Hole Punching and leverage = the IETF’s considerable influence to force NAT vendors to migrate towards = implementations that are friendly to Hole Punching.

 

The bottom line is that I agree = with Henry in that labeling ICE as an experimental draft is the right thing to = do.  It will allow those implementing ICE (including myself in all = likelihood) to proceed but signals to the users the correct status of the standard’s = contents.

 

I also want to applaud loudly the underlying tone of Henry’s thread here.  That is, in solving specific technical problems within the IETF forum, focusing on empirical = observation of working implementations should be the MO that we all strive for when developing and proposing what may become protocol = standards.

 

Thanks,

=

FM

 

 

From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, July 18, = 2007 8:20 AM
To: Magnus Westerlund
Cc: sip@ietf.org; = behave@ietf.org; mmusic@ietf.org
Subject: [Sip] RE: = [BEHAVE] Re: ICE deployment data before LC for RFC

 

Magnus,

 

I sincerely appreciate your interest and this = note!

 

> I don't quite understand why you are requesting a status = change of ICE

 

However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

 

RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a = tool to be used in the context of a NAT traversal solution. This is an important = change from the previous version of this specification (RFC 3489), which = presented STUN as a complete solution."

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

 

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

 

By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

 

"NAT Classification Test = Results"

 

"Application Design Guidelines for Traversal through = Network Address Translators"

The measurements for hole punching are reported = in

"Peer-to-Peer Communication Across Network Address Translators"

http://www.brynosauru= s.com/pub/net/p2pnat/

 

I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, = but not yet a standard so that:

 1. Independent, compliant implementations will be = developed,

 2. Testing in events such as = SIPit,

 3. Reporting the results, such as reported for the = "hole punching" above.

 

What happens if indeed hole punching proves to be the far more effective approach?

 

The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing = the right quotes).

 

Thanks again for your attention to this concern about ICE. =

Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

 

Henry

 

 

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

 

Henry = Sinnreich skrev:

> Following some discussions and soul searching, the best = approach for

> ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

>

> This would support the development of interoperable implementations, the

> collection of deployment data and also hopefully open = source code.

>

> Though I have full faith in ICE, following the practices = that made the

> IETF successful take precedent here, I = believe.

>

> This is a change from the attached that I wrote on = 7/16/2007.

>

> Note: We can only hope the proliferation of SBC in VoIP = service provider

> networks will not make these concerns and ICE for SIP a = moot issue, but

> this is another topic.

 

Henry,

 

I don't quite understand why you are requesting a status change = of ICE?

To me it appears that ICE is almost finished spec. It has been =

implemented, used and feedback has been influencing the = protocol. It is

definitly one of the better examples of current IETF work that = actually

has running code. Sure, the implementations may not be fully = updated yet

to the latest draft version. But I think it is safe to say that = ICE

works in the intended core cases. If there are some corner cases = where

it fails, that may be. But that is not information we will have = until

really large scale deployement or someone makes very extensive = tests.

 

I think the IETF and the Internet has much more benefit from a standards

track solution than any of the risks existing with ICE of = today.

 

And to be clear, proposed standard is allowed to be published = without a

single implementation exists. It might not be good practice, but = it is

allowed by our process. And as I said before ICE has had enough =

implementation that I am very confortable in balloting YES for = it when

it appears on the IESGs table.

 

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

-----------------------------------------------------------------= -----

------=_NextPart_000_00CF_01C7C919.1DDFF390-- --===============2024568811== 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 --===============2024568811==-- From mmusic-bounces@ietf.org Wed Jul 18 13:02: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 1IBCv2-0002iU-3P; Wed, 18 Jul 2007 13:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCv0-0002iF-Co for mmusic@ietf.org; Wed, 18 Jul 2007 13:02:30 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBCuz-000767-6V for mmusic@ietf.org; Wed, 18 Jul 2007 13:02:30 -0400 X-VirusChecked: Checked X-Env-Sender: sam.ganesan@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1184778148!24244410!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 26523 invoked from network); 18 Jul 2007 17:02:28 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-119.messagelabs.com with SMTP; 18 Jul 2007 17:02:28 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l6IH2REx007736 for ; Wed, 18 Jul 2007 10:02:27 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l6IH2PeQ008802 for ; Wed, 18 Jul 2007 12:02:26 -0500 (CDT) Received: from de01exm62.ds.mot.com (de01exm62.am.mot.com [10.176.8.107]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l6IH2O3R008778 for ; Wed, 18 Jul 2007 12:02:25 -0500 (CDT) 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-SIP mismatch Date: Wed, 18 Jul 2007 13:02:21 -0400 Message-ID: <0A7B3E4DF2B4484F933C26AE3DF6F74E02A7486A@de01exm62.ds.mot.com> In-Reply-To: <46973631.8010406@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTSP-SIP mismatch Thread-Index: AcfFJwk96DKUcJJZTjK6khe0zPINTAENUpjw From: "Ganesan Sam-W00184" To: "Magnus Westerlund" , "Anders Kristensen" X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: David Ress , MARJOU Xavier RD-MAPS-LAN , "mmusic \(E-mail\)" , Tom-PT Taylor , steven.d.whitehead@verizon.com 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: Anders: As I understand this we are talking about a level of SIP and RTSP to interwork either via a gateway or otherwise. At the San Diego meeting a group of us had submitted a draft that talked about SIP RTSP interworking except in that case we tried to wrap the RTSP that needed to be transported inside a SIP message's sdp. I know the approach was different but the logical goal I believe was the same. If we are ready to revive the idea of SIP-RTSP interworking, we will be happy to revive draft-marjou in a new incarnation in collboration will everybody to get this going. I will also be in chicago and be happy to chat about potential mechanisms and how to ... Sam -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, July 13, 2007 4:22 AM To: Anders Kristensen Cc: mmusic (E-mail) Subject: Re: [MMUSIC] RTSP-SIP mismatch Anders Kristensen skrev: > Magnus, >=20 > So if I understand you correctly you're saying that yes, there is a an > issue that ought to be addressed but in your view it should be=20 > addressed in SIP, not RTSP? Yes, Yes, and not because of maturity, but because of what I see as the correct place to implement the solution. As I said, fixing this issue in RTSP seems to imply that RTSP suddenly are forced to have two way media negotiation. >=20 > I suggested RTSP because I thought, mistakenly perhaps, that it is less=20 > mature and therefore more amenable to change. In my head RFC 2326 is=20 > more or less on par with SIP as defined in RFC 2543 making rfc2326bis=20 > the equivalent of RFC 3261. If 2326 is as widely deployed as you say=20 > then that certainly makes the comparison less than perfect. I don't want to make parallels here. From a specification point of view=20 regarding majurity I think your view holds. But not from reality and=20 deployed base. RTSP 2.0 will be hard to get deployed, and I think the=20 main advantage will be faster setup and standardized NAT traversal may=20 get it deployed as soon as we can finish it. >=20 > When you talk about shared live content you're thinking about a=20 > multicast scenario? There are RTSP features that have to do specifically=20 > with setting up point-to-point streams so AFAICT passing payload type=20 > from the client to the server is not particularly at odds with RTSP as > such. It could be added to the Transport header field along with the=20 > client's IP and port. I guess it would either have to be considered a=20 > hint or else an extension token would have to be added. No, I am talking about unicast distribution using tree likes structures=20 from a source where the setup and control of the flow from last tier=20 servers to clients are done with RTSP. In this case the server may=20 simply copy any incoming packets into multiple out-bound unicast flow=20 and performs no per packet processing. I don't think what you propose realy flies well. Of course you could=20 make a hack that only works under certain circumstances by passing a PT=20 remapping in the transport header. However, what I think needs to be=20 considered here are the model. >=20 > OTOH, I would find it tempting to have RTSP adopt SIP's offer/answer=20 > model more wholesale, possibly in addition to a mode where the server=20 > just announces the session parameters in support of broadcast-type=20 > scenarios. Should be possible to do something like that in a backwards > compatible manner although I can't say I've thought it through. >=20 Well, that has been discussed but never taken anywhere. I think one=20 needs to start in considering what the needs really are. And if one want to do real negotiation one should go for a three step negotiation model=20 with. A->B: A's Capabilites, B->A: B's Capabilites + B's configuration,=20 A->B: A's congfiguration + ACK. Because Offer/Answer is simply broken=20 for any more advance cases, like assymetric configurations. 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 Jul 18 13:07: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 1IBCzX-0005DZ-9r; Wed, 18 Jul 2007 13:07:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCzW-0005DT-T7 for mmusic@ietf.org; Wed, 18 Jul 2007 13:07:10 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCzS-0008M8-Cg for mmusic@ietf.org; Wed, 18 Jul 2007 13:07:10 -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 l6IH6urH025586; Wed, 18 Jul 2007 20:07:00 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 20:06:56 +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); Wed, 18 Jul 2007 20:06:56 +0300 Received: from 4FIL28146 (esdhcp041141.research.nokia.com [172.21.41.141]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6IH6toj009857; Wed, 18 Jul 2007 20:06:55 +0300 From: "Kai Vehmanen" To: "'ext Henry Sinnreich'" , References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA10D@namail5.corp.adobe.com> <001901c7c86d$e610a730$8d2915ac@NOE.Nokia.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED438@namail5.corp.adobe.com> Subject: RE: [MMUSIC] open-source ICE implementations (was: RE: ICE deploymentdata before LC for RFC) Date: Wed, 18 Jul 2007 20:06:55 +0300 Organization: Nokia Message-ID: <001001c7c95e$0b37e5f0$8d2915ac@NOE.Nokia.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.3138 Thread-Index: AcfH+cwnIETVFFZtTmCLWopMWLu+LAAbLRxgAA+vKeAAHWNgcA== In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED438@namail5.corp.adobe.com> X-OriginalArrivalTime: 18 Jul 2007 17:06:56.0319 (UTC) FILETIME=[0BAAA4F0:01C7C95E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Hi, On 17 July 2007, Henry Sinnreich wrote: [NICE ICE implementation] >Can you also share deployment results, such as the success >ratio in various NAT scenarios? we don't have any deployment data yet, just results from lab testing: so far no unexpected failures (i.e. cases that in theory should work but don't with some combination of NATs). However, as we now have multiple implementations available, we should be able to get more test results in. As for NICE implementation, I've written step-by-step instructions on how to do real-life testing on UNIX systems with our current codebase at: - http://article.gmane.org/gmane.comp.telephony.sofia-sip.devel/1786 Feel free to try it out, and/or develop the test client further. -- first.surname@nokia.com (Kai Vehmanen) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 14:19: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 1IBE78-00009H-HR; Wed, 18 Jul 2007 14:19:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE74-00006Q-QW; Wed, 18 Jul 2007 14:19:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBE73-00027p-J0; Wed, 18 Jul 2007 14:19:02 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 11:19:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM70nUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,551,1175497200"; d="scan'208"; a="184397965:sNHT27953127" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6IIJ0Hn023569; Wed, 18 Jul 2007 11:19:00 -0700 Received: from dwingwxp ([10.32.240.196]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6IIIxSb020950; Wed, 18 Jul 2007 18:19:00 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Magnus Westerlund'" Date: Wed, 18 Jul 2007 11:18:59 -0700 Message-ID: <08c801c7c968$1d1cd8c0$7d646b80@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.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4270; t=1184782740; x=1185646740; c=relaxed/simple; s=sjdkim1004; 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[BEHAVE]=20Re=3A=20ICE=20deployment=20data=20before=2 0LC=20for=20RFC |Sender:=20; bh=2FWmfcMe0lUELpsCxRsiCfzJ5DQboIhP+QFWUpycxao=; b=rc1LY+x6P63Ju+iYeB0a+kHKDV/Y+Btd9EZzd2kDBor6bTDjwsRx93b1hhYdCs4eIaI/Hf2+ ebSY7CI6aMrC17UqVJYClcarL0C74Jc613LxV5f5lHEJVzAZKDCRj9hkCeKUIbwxT2ks9lojAl D4JQuevyEdpgVJsBJA5HYl43s=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 excellent I-D shows > the ICE call flow with two endpoints behind two NAT (Fig. 22 > on page 38) require 66 messages just for the SIP INVITE! > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN Server | | | |(1) Alloc Req | | |Src=L-PRIV-1 | | |Dest=STUN-PUB-1 | | |--------------->| | | | | | |(2) Alloc Req | | |Src=L-NAT-PUB-1 | | |Des=STUN-PUB-1 | | |--------------->| | | | | |(3) Alloc Resp | | |<---------------| | |Src=STUN-PUB-1 | | |Dest=L-NAT-PUB-1| | |Map=L-NAT-PUB-1 | | |Rel=STUN-PUB-2 | | | | |(4) Alloc Resp | | |<---------------| | |Src=STUN-PUB-1 | | |Dest=L-PRIV-1 | | |Map=L-NAT-PUB-1 | | |Rel=STUN-PUB-2 | | | | | If we added another NAT on that path, the number of messages on the network does not double. The number of messages on the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6 SIP messages. > What happens if the two endpoints are in different ISPs that > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and would remain the same 24 messages if you're doing the same Figure 22 flow. > Would there be hundreds of messages? No. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 14:38: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 1IBEPs-0003Tf-Mj; Wed, 18 Jul 2007 14:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEPq-0003SB-Ml for mmusic@ietf.org; Wed, 18 Jul 2007 14:38:26 -0400 Received: from web33313.mail.mud.yahoo.com ([68.142.206.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBEPp-0001Mx-BY for mmusic@ietf.org; Wed, 18 Jul 2007 14:38:26 -0400 Received: (qmail 9268 invoked by uid 60001); 18 Jul 2007 18:38:24 -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=3+2cY+yXyBkHGpWc8u4Ua2zsPKSOdRzfNvNuiznkVa3DC6IfYvIoKsXt1wClPSAI+9SyZWVrJOJN00uPyw5NpCe8LAnfssngyupTwL8rtaggH7gFuv2zciNnRWVoYL08Vm+FKBXad7heWxN1F4qRy15wdQrZn693v09YyaMp33c=; X-YMail-OSG: c8eMOgYVM1l2jEeRQ0Q9aMvg9aLtIhJfLV72DzMLBYEGYh5Z4gMv2ZMtWXXY9Dq3TCDRnTflv9.V.dcTa0PXhJPjG.xcZZ4rbBjsPYgXZzMj5h2UBhc- Received: from [209.172.74.45] by web33313.mail.mud.yahoo.com via HTTP; Wed, 18 Jul 2007 11:38:24 PDT Date: Wed, 18 Jul 2007 11:38:24 -0700 (PDT) From: Pyda Srisuresh To: Philip Matthews In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <857678.8925.qm@web33313.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: 'Magnus Westerlund' , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, "Frank W. Miller" Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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: > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > [suresh] Right, ICE does use the HOLE PUNCHING technique and the BCP guidelines described in draft-ford-behave-app draft, even though ICE draft does NOT acknowledge or reference the above draft or prior work that introduced HOLE PUNCHING TECHNIQUE. ICE is also using HOLE PUNCHING in a limited way within the constraints of STUN and SIP. Hence, the croner case scenarios you site. ICE is NOT HOLE PUNCHING in its native form. In the BEHAVE WG meeting(last IETF), several people talked of ICE as the new application traversal approach blessed by IETF, and proposed dropping the original draft ford-behave-app draft that proposes HOLE PUNCHING TECHNIQUE. As a result, the application milestone is dropped from the WG charter and ford-behave-app is not adapted as work group item. This, to me, is pitting ICE against the basic HOLE PUNCHING TECHNIQUE. This is what I believe to be WRONG. regards, suresh > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> 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 > >> > >> --------------------------------------------------------------------- > >> - > >> > >>> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > >> > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 14:50: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 1IBEb9-0002oH-L0; Wed, 18 Jul 2007 14:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBE25-0007Kj-1E for mmusic@ietf.org; Wed, 18 Jul 2007 14:13:53 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBE23-0000aK-3c for mmusic@ietf.org; Wed, 18 Jul 2007 14:13:53 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Wed, 18 Jul 2007 11:13:46 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Pyda Srisuresh'" Date: Wed, 18 Jul 2007 11:13:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSw In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f X-Mailman-Approved-At: Wed, 18 Jul 2007 14:50:06 -0400 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: I agree with Henry, Frank, Suresh, and the lurkers on this list who have concern that ICE hasn't demonstrated its claims in the real world, while others have achieved similar ends with great success using much simpler approaches. (Some examples: Skype, Hamachi, Red Swoosh/Akamai, etc.) For example, regarding the "hole punching" approach (by which I assume you mean "opening a hole and trying to keep it open" versus ICE's "open a hole 'on demand' for each connection"), it's been demonstrated to work at large scale with at least 90% direct peer connectivity across the internet, today, with a much simpler message flow and implementation. I find it concerning that ICE has taken a more costly, difficult route without confirming it's truly worth the additional incremental effort (or even a step backwards). I share the concern that ICE standardization has gotten far out ahead of the horse in inventing a new protocol from scratch rather than modeling off of the proven protocols that came before it, which historically has been the IETF strength. Given this choice to go a new route, I think it warrants a higher burden of evidence -- contrasted against known success rates of competing solutions -- before being formally endorsed by the IETF. I'm completely open to ICE being superior to all others. I have no doubt more effort has been put into it, and I'm eager to enjoy the fruits of everyone's labor. But I'd like to see the data that proves it, and I see no reason to charge ahead with standardization until data is firmly in hand. -david > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 9:27 AM > To: Pyda Srisuresh > Cc: behave@ietf.org; mmusic@ietf.org; sip@ietf.org; 'Henry Sinnreich' > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > Frank, Henry, Suresh: > > I agree that ICE is a complex spec. I also agree that it would be > very interesting to see > more data on which situations result in a direct path between > endpoints, as opposed to > a path via a TURN server. > > However, I don't understand the comment that "Hole Punching > Techniques" are an alternative. > In my view, ICE _is_ a "Hole Punching Technique". > > Perhaps you are referring to the use of STUN alone??? > The problem with using STUN alone is that there are cases where using > the reflexive address > doesn't work, and there is no way with STUN alone to determine when > an endpoint should or > should not use a reflexive address. > > But perhaps you are referring to something else? > - Philip > > > On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on > > HOLE > > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence > > to force > > NAT vendors to migrate towards implementations that are friendly to > > Hole > > Punching and the Application developers to design applications > > using the hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some > > people have > > put their weight so heavily in favor of ICE that they asked to drop > > the work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see > > "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > > TECHNIQUES > > to move forward as a WG item? > > > > regards, > > suresh > > > > --- "Frank W. Miller" wrote: > > > >> > >> > >> Greetings, > >> > >> > >> > >> What I think Henry is advocating is a systematic approach to > >> making sure > >> that the content of the ICE spec is right for its intended > >> purpose, i.e. a > >> complete, general NAT traversal solution. NAT traversal has been > >> in my > >> opinion one of the most difficult aspects of SIP implementation > >> and its very > >> important that its eventual standardized solution be right. I > >> know I spent > >> a lot of time implementing all the "tests" in the first 3489, only to > >> discover that they were not that useful. There are two valid > >> technical > >> concerns that are put forth in this email: > >> > >> > >> > >> 1) Viability of correct operation in practical > >> implementations. ICE can > >> result in very complicated message transfers. > >> > >> 2) Performance. As pointed out in this email and in other > >> places, the > >> additional latency associated with ICE operations can be significant. > >> > >> > >> > >> Henry also points out that there are competing approaches (e.g. Hole > >> Punching) that can perform well in many situations and have better > >> performance. IMHO, another approach by the IETF in general would > >> be to > >> standardize on Hole Punching and leverage the IETF's considerable > >> influence > >> to force NAT vendors to migrate towards implementations that are > >> friendly to > >> Hole Punching. > >> > >> > >> > >> The bottom line is that I agree with Henry in that labeling ICE as an > >> experimental draft is the right thing to do. It will allow those > >> implementing ICE (including myself in all likelihood) to proceed > >> but signals > >> to the users the correct status of the standard's contents. > >> > >> > >> > >> I also want to applaud loudly the underlying tone of Henry's > >> thread here. > >> That is, in solving specific technical problems within the IETF > >> forum, > >> focusing on empirical observation of working implementations > >> should be the > >> MO that we all strive for when developing and proposing what may > >> become > >> protocol standards. > >> > >> > >> > >> Thanks, > >> > >> FM > >> > >> > >> > >> > >> > >> _____ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, July 18, 2007 8:20 AM > >> To: Magnus Westerlund > >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org > >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Magnus, > >> > >> > >> > >> I sincerely appreciate your interest and this note! > >> > >> > >> > >>> I don't quite understand why you are requesting a status change > >>> of ICE > >> > >> > >> > >> However the arguments stated by the WG co-chairs and by you here are > >> procedural in nature, whereas the facts are some cause for serious > >> concern, > >> and I will just mention a few facts: > >> > >> > >> > >> RFC 3489 (STUN) was also presented as a NAT traversal solution > >> back in 2003, > >> but now clearly admits that > >> "STUN is not a > >> NAT traversal solution by itself. Rather, it is a tool to be used > >> in the > >> context of a NAT traversal solution. This is an important change > >> from the > >> previous version of this specification (RFC 3489), which presented > >> STUN as a > >> complete solution." > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-behave- > >> rfc3489bis-07.txt > >> > >> My guess is, in plain English, RFC 3489 turned out just NOT to be an > >> acceptable solution as it was hoped to be. > >> > >> > >> > >> The excellent I-D shows the > >> ICE call > >> flow with two endpoints behind two NAT (Fig. 22 on page 38) > >> require 66 > >> messages just for the SIP INVITE! > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat- > >> scenarios-07.txt > >> > >> What happens if the two endpoints are in different ISPs that have > >> NAT of > >> their own in addition to the ones in Fig. 22? > >> > >> What happens if one would try ICE along a P2PSIP route with say > >> 5-8 hops? > >> Would there be hundreds of messages? What is the likelihood for > >> failure? > >> > >> > >> > >> By contrast with such approaches based on hope and faith, the > >> BEHAVE WG has > >> produced work based on real measurements and tools to do the > >> measurements, > >> such as > >> > >> > >> > >> "NAT Classification Test Results" > >> > >> > >> > >> "Application Design Guidelines for Traversal through Network Address > >> Translators" > >> > >> The measurements for hole punching are reported in > >> > >> "Peer-to-Peer Communication Across Network Address Translators" > >> > >> http://www.brynosaurus.com/pub/net/p2pnat/ > >> > >> > >> > >> I am also a believer in ICE and have actually urged Jonathan > >> Rosenberg to do > >> this work and he has given his best. Now that we have ICE-17 > >> version, it is > >> in the best interest of the industry and the IETF to make it an > >> experimental > >> RFC, but not yet a standard so that: > >> > >> 1. Independent, compliant implementations will be developed, > >> > >> 2. Testing in events such as SIPit, > >> > >> 3. Reporting the results, such as reported for the "hole > >> punching" above. > >> > >> > >> > >> What happens if indeed hole punching proves to be the far more > >> effective > >> approach? > >> > >> > >> > >> The industry can ill afford a new series of RFC[ICE]-bis and all > >> the years > >> it takes to move from believing to measuring and proving. I am > >> sure IETF > >> procedures were meant in this spirit (though I am not good in > >> producing the > >> right quotes). > >> > >> > >> > >> Thanks again for your attention to this concern about ICE. > >> > >> Also my apology to all the anguish to the numerous contributors to > >> the ICE > >> related I-Ds, but writing test tools and reporting measurements is > >> the right > >> way to go. > >> > >> > >> > >> Henry > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Wednesday, July 18, 2007 1:11 AM > >> To: Henry Sinnreich > >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org > >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC > >> > >> > >> > >> Henry Sinnreich skrev: > >> > >>> Following some discussions and soul searching, the best approach for > >> > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >> > >>> > >> > >>> This would support the development of interoperable > >>> implementations, the > >> > >>> collection of deployment data and also hopefully open source code. > >> > >>> > >> > >>> Though I have full faith in ICE, following the practices that > >>> made the > >> > >>> IETF successful take precedent here, I believe. > >> > >>> > >> > >>> This is a change from the attached that I wrote on 7/16/2007. > >> > >>> > >> > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >> > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >> > >>> this is another topic. > >> > >> > >> > >> Henry, > >> > >> > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? > >> > >> To me it appears that ICE is almost finished spec. It has been > >> > >> implemented, used and feedback has been influencing the protocol. > >> It is > >> > >> definitly one of the better examples of current IETF work that > >> actually > >> > >> has running code. Sure, the implementations may not be fully > >> updated yet > >> > >> to the latest draft version. But I think it is safe to say that ICE > >> > >> works in the intended core cases. If there are some corner cases > >> where > >> > >> it fails, that may be. But that is not information we will have until > >> > >> really large scale deployement or someone makes very extensive tests. > >> > >> > >> > >> I think the IETF and the Internet has much more benefit from a > >> standards > >> > >> track solution than any of the risks existing with ICE of today. > >> > >> > >> > >> And to be clear, proposed standard is allowed to be published > >> without a > >> > >> single implementation exists. It might not be good practice, but > >> it is > >> > >> allowed by our process. And as I said before ICE has had enough > >> > >> implementation that I am very confortable in balloting YES for it > >> when > >> > >> it appears on the IESGs table. > >> > >> > >> > >> 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 > >> > >> --------------------------------------------------------------------- > >> - > >> > >>> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > >> > > > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 14:50: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 1IBEbA-0002qe-1m; Wed, 18 Jul 2007 14:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEVE-0002fN-CT; Wed, 18 Jul 2007 14:44:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBEVD-0001Wj-TG; Wed, 18 Jul 2007 14:44:00 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 11:43:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANb7nUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,551,1175497200"; d="scan'208"; a="184411557:sNHT26564256" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6IIhx6T004698; Wed, 18 Jul 2007 11:43:59 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6IIhYSx015490; Wed, 18 Jul 2007 18:43:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:43:56 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Jul 2007 18:43:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 18 Jul 2007 14:43:54 -0400 From: Melinda Shore To: David Barrett , "'Philip Matthews'" , Pyda Srisuresh Message-ID: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSwAAMGS0Q= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2007 18:43:56.0472 (UTC) FILETIME=[98BF8380:01C7C96B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1322; t=1184784239; x=1185648239; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=FGomruZHVVV5PGhYSPpx0WH2XrxXMCEh87GwWWzX504=; b=JVxkldbK6hIqokxk3r5WFxbTWEhtPpWjKvUyf4h4jm7VH4A4/Onj3dIuoP0LWRML+pBapGCy 2rhwWCZg3ldHSFEzFTQtd4PxUJpDkdwmOsLIv+UOyavuh3GjHAHXzN5ChmksG/DDNquHswxYhM vCBMBGvshBwwOXrKks5QFr9bM=; Authentication-Results: sj-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 18 Jul 2007 14:50:06 -0400 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 7/18/07 2:13 PM, "David Barrett" wrote: > For example, regarding the "hole punching" approach (by which I assume you > mean "opening a hole and trying to keep it open" versus ICE's "open a hole > 'on demand' for each connection"), it's been demonstrated to work at large > scale with at least 90% direct peer connectivity across the internet, today, > with a much simpler message flow and implementation. ICE makes me want to pound red-hot nails into my eye sockets. That said, 90% really isn't nearly good enough for residential deployments. For cheap-o residential equipment, the margins are so thin that a support call or two is sufficient to wipe out the profit on that sale. Part of the reason that ICE is the mess it is is that the group has been iteratively fixing the various failures by adding more tests and probes and messages and whatnot. There are certainly a lot of other ways to achieve reliability but regardless of which one you choose, reliability really does have to be a priority. Ancillary to that is that when you fail you should fail in a way that can be diagnosed with reasonable ease and transparency (auditability is good!), and I think we all know what happens when traditional NAT hole-punching fails - stuff just doesn't work. Melinda _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 15:20: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 1IBF4w-0006sG-3d; Wed, 18 Jul 2007 15:20:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0006gx-Vh; Wed, 18 Jul 2007 15:20:50 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0003p9-3f; Wed, 18 Jul 2007 15:20:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:20:40 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 l6IJJJot025959; Wed, 18 Jul 2007 12:19:20 -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 l6IJKI0i013432; Wed, 18 Jul 2007 12:20:34 -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, 18 Jul 2007 12:20:26 -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 Date: Wed, 18 Jul 2007 12:20:22 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> In-Reply-To: <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84A== References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:20:26.0798 (UTC) FILETIME=[B248BCE0:01C7C970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, Philip Matthews , behave@ietf.org, mmusic@ietf.org, p2psip@ietf.org Subject: [MMUSIC] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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, What you say makes sense but there is a lingering suspicion that after admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't work is that such paper evaluations are in no way a replacement for proof and measurements. We still need an explanation why the right approach cannot be taken: * Publish open source code at Sourceforge.net or similar, * Publish a test tool as well, * Gather and publish the results, possibly involving SIPit or another, * Perfect the OS code and the protocol until it works OK. This has been done for "Hole Punching for P2P" in=20 http://www.brynosaurus.com/pub/net/p2pnat/=20 What if ICE proves to be no better than its predecessors?=20 So how can one compare something that has tools, measured and published results with something like ICE that we have to take on pure faith? My assumption is that hole punching is much more effective for P2PSIP and I have copied the P2PSIP WG on this. The ratio of messages is probably 5:1 or higher for ICE vs. hole punching and this is critical when routing a P2PSIP message over an overlay in 5-10 hops. Of course I cannot prove it since as yet ICE cannot be measured. Let's do ICE the right way, there is too much at stake here. Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 18, 2007 1:19 PM To: Henry Sinnreich; 'Magnus Westerlund' Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC > The excellent I-D shows=20 > the ICE call flow with two endpoints behind two NAT (Fig. 22=20 > on page 38) require 66 messages just for the SIP INVITE! >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt=20 That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of=20 messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN =20 Server | | | =20 |(1) Alloc Req | | =20 |Src=3DL-PRIV-1 | | =20 |Dest=3DSTUN-PUB-1 | | =20 |--------------->| | =20 | | | =20 | |(2) Alloc Req | =20 | |Src=3DL-NAT-PUB-1 | =20 | |Des=3DSTUN-PUB-1 | =20 | |--------------->| =20 | | | =20 | |(3) Alloc Resp | =20 | |<---------------| =20 | |Src=3DSTUN-PUB-1 | =20 | |Dest=3DL-NAT-PUB-1| =20 | |Map=3DL-NAT-PUB-1 | =20 | |Rel=3DSTUN-PUB-2 | =20 | | | =20 |(4) Alloc Resp | | =20 |<---------------| | =20 |Src=3DSTUN-PUB-1 | | =20 |Dest=3DL-PRIV-1 | | =20 |Map=3DL-NAT-PUB-1 | | =20 |Rel=3DSTUN-PUB-2 | | =20 | | | =20 If we added another NAT on that path, the number of messages on the network does not double. The number of messages on=20 the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another=20 from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a=20 NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6=20 SIP messages. > What happens if the two endpoints are in different ISPs that=20 > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with=20 > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional=20 hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and=20 would remain the same 24 messages if you're doing the same=20 Figure 22 flow. =20 > Would there be hundreds of messages? No. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 15:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFh-0000bw-52; Wed, 18 Jul 2007 15:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFO-0000KY-UK; Wed, 18 Jul 2007 15:31:43 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFFN-0002zx-EC; Wed, 18 Jul 2007 15:31:42 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:31:34 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJVWWs017431; Wed, 18 Jul 2007 12:31:32 -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 l6IJVT0e014943; Wed, 18 Jul 2007 12:31:31 -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, 18 Jul 2007 12:31:30 -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 Date: Wed, 18 Jul 2007 12:31:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHZz70STkhAQTUWLy398tzWtmAAGFg6w References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "Pyda Srisuresh" X-OriginalArrivalTime: 18 Jul 2007 19:31:30.0491 (UTC) FILETIME=[3DE040B0:01C7C972] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, "Frank W. Miller" , p2psip@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Phil, > In my view, ICE _is_ a "Hole Punching Technique". Yes, you absolutely right, though the devil is in the details. We cannot go here into a shoot-out between hole punching or other mentioned on the list vs. ICE, but there seems to be a huge difference in effectiveness and performance.=20 Of course I cannot prove it since there are no measurements published for ICE, only faith.=20 Just think of traversing all the NAT while going over 5-10 overlay network hops. Also many ISP are NATed and some are multiple NATed. We are supposed to provide a solution that works across the Internet. A provable (testing tools) and proven solution (measurements). I like ICE and hope to be proven wrong, but the risk is just too big for now. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 9:27 AM To: Pyda Srisuresh Cc: Frank W. Miller; Henry Sinnreich; 'Magnus Westerlund'; sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20 the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20 > HOLE > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence =20 > to force > NAT vendors to migrate towards implementations that are friendly to =20 > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20 > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20 > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20 >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20 >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20 >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20 >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20 >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> 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 >> >> --------------------------------------------------------------------- >> - >> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 15:38: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 1IBFM0-000595-QH; Wed, 18 Jul 2007 15:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0004p2-Ep; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0003Ej-3E; Wed, 18 Jul 2007 15:38:23 -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 l6IJcIa02521; Wed, 18 Jul 2007 19:38: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 Date: Wed, 18 Jul 2007 14:38:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemA References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , "Dan Wing" , "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, p2psip@ietf.org, behave@ietf.org, Philip Matthews , mmusic@ietf.org Subject: [MMUSIC] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 15:43: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 1IBFR3-0005wd-AB; Wed, 18 Jul 2007 15:43:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFQc-0005Oj-CG; Wed, 18 Jul 2007 15:43:19 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFQb-0003Mr-Pi; Wed, 18 Jul 2007 15:43:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:43:13 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 l6IJfqot000197; Wed, 18 Jul 2007 12:41:53 -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 l6IJh60c016197; Wed, 18 Jul 2007 12:43:07 -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, 18 Jul 2007 12:43:06 -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 Date: Wed, 18 Jul 2007 12:42:57 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED891@namail5.corp.adobe.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemAAACP2dA= References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com><08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com><24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> From: "Henry Sinnreich" To: "Francois Audet" , "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:43:06.0466 (UTC) FILETIME=[DCB59C20:01C7C973] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, mmusic@ietf.org, behave@ietf.org, p2psip@ietf.org, Philip Matthews Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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, > Heuh, no. This is just "exploratory concept" stuff, certainly not an=20 > interoperable protocol specification. I am happy to report we are in total agreement. Henry -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, July 18, 2007 2:38 PM To: Henry Sinnreich; Dan Wing; Magnus Westerlund Cc: sip@ietf.org; p2psip@ietf.org; behave@ietf.org; Philip Matthews; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 17:06: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 1IBGii-0000zQ-Ag; Wed, 18 Jul 2007 17:06:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGi7-0000g0-5W; Wed, 18 Jul 2007 17:05:27 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBGi6-0007eH-PC; Wed, 18 Jul 2007 17:05:27 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 99B4C75807D; Wed, 18 Jul 2007 16:05:25 -0500 (CDT) From: "Frank W. Miller" To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 15:05:13 -0600 Message-Id: <1184792713.3347.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Magnus Westerlund , behave@ietf.org, p2psip@ietf.org, sip@ietf.org, Dan Wing , Philip Matthews , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Wed, 2007-07-18 at 14:38 -0500, Francois Audet wrote: > The other thing I find funny in here is that the alternative > hole punching techique as described on the web site uses a > centralize server common to BOTH ends to relay the address, while > ICE does not (i.e., each end can use their own STUN server). > > In other words, the major difference between ICE and the > alternative-hole- > punching technique seems to be that alternative-hole-punching > assumes both ends use the same STUN server, which makes the > rest of the exchange simpler (the "magic box" architectural > concept is always handy). > > Ironically, this seems to me to be LESS usable in a global network > where you wont't use centralize servers, especially for p2psip. > This may be sufficient, but I don't think its necessary. Each UA punches the hole (and keeps it open, as David described) to whatever STUN server they like, all that's required is that each server have the same view of each client. That is somewhat less restrictive. In the common case of the open Internet, as long as the STUN servers used by each respective UA are in the "open", they don't have to be the same. After that, the "public" or "visible" IP address/port is put in the Contact headers. Regarding the 90% coverage, this is what I'm referring to when I say that it may be preferable to influence the NAT vendors to not do the things that put them in the 10% cases. I sort of thought that was what the NAT guidelines draft was for. In addition, if we are standardizing a protocol based on the 10% cases and imposing potentially huge costs on the 90% to do so, then our approach is incorrect. We should be designing for the 90% case and handling the 10% as exceptional behavior, i.e. a solution where you pay the big cost only in the case where you are actually in the 10%. FM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 18:39: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 1IBIAo-0003VG-6H; Wed, 18 Jul 2007 18:39:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIAl-0003Qa-R5 for mmusic@ietf.org; Wed, 18 Jul 2007 18:39:08 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBIAl-0001rA-Bw for mmusic@ietf.org; Wed, 18 Jul 2007 18:39:07 -0400 Received: from lappy ([68.26.122.92]) by quinthar.com for ; Wed, 18 Jul 2007 15:38:59 -0700 From: "David Barrett" To: "'Melinda Shore'" , "'Philip Matthews'" , "'Pyda Srisuresh'" Date: Wed, 18 Jul 2007 15:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfJWHiK1kJjj4/ZRl2bJXpSN42/3wABwWSwAAMGS0QAB7yQkA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > 90% really isn't nearly good enough for residential deployments. Incidentally, 90% is where my stats come out today -- this doesn't include restricted-cone/symmetric and symmetric/symmetric penetration, which has been prototyped but not added to the production system yet. The hope is this will get us much close to the 99% range, but it remains to be seen by how much. Furthermore, I'd wager that for most applications (such as VoIP), even routing 1 in 10 calls through a central relay isn't going to break the bank. (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to act as "free" relays for their peers.) Thus while NAT penetration using what I guess we're calling the "hole punching technique" has been demonstrated to work at 90%+ on a very large scale (hundreds of thousands of clients tested) we should expect that it's possible to get even better still. If ICE can show how it'd do better, that'd be great. But we can't tolerate ICE being any worse than that, and thus before rushing ahead with standardizing an unproven ICE, we should just take the time to prove it. -david _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 21:19: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 1IBKfi-000084-9H; Wed, 18 Jul 2007 21:19:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKff-00006j-Fv; Wed, 18 Jul 2007 21:19:11 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBKff-00074j-1F; Wed, 18 Jul 2007 21:19:11 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBKfe-0001iS-22; Wed, 18 Jul 2007 21:19:10 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@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: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Wed, 18 Jul 2007 21:19:21 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole punching algorithm. It differs from others that I have seen written up in the following ways: - ICE has the concept of peer reflexive addresses, which other hole- punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 21:49: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 1IBL95-0006iF-7X; Wed, 18 Jul 2007 21:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBL94-0006es-3Z for mmusic@ietf.org; Wed, 18 Jul 2007 21:49:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBL92-0006El-EI for mmusic@ietf.org; Wed, 18 Jul 2007 21:49:34 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6J1nUOJ021788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2007 18:49:30 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6J1nT0g015874; Wed, 18 Jul 2007 18:49:29 -0700 Received: from NAEX01.qualcomm.com ([129.46.51.61]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 18:49: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: Proposal to modify RFC3890 TIAS in offer/answer Was RE:[MMUSIC]Comments on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt Date: Wed, 18 Jul 2007 18:49:32 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B03100E14@NAEX01.na.qualcomm.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60D92FF@srvxchg3.cablelabs.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+/cUAEBgCNwAIwRsaAAD/BCkAA2S8NQAP1E2pAN0/lCQA== From: "Desineni, Harikishan" To: X-OriginalArrivalTime: 19 Jul 2007 01:49:22.0492 (UTC) FILETIME=[07710FC0:01C7C9A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3419f078334bcda4102d3d704cee11c6 Cc: Jean-Francois Mule , "Leung, Nikolai" 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 the draft which is an outcome of the discussions on draft-hdesinen-mmusic-oa-send-bw-attr-02.txt.=20 http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-bw-attr-00. txt I posted a -00 version of the new draft before 9th July but it did not appear on IETF pages so far. Please read the draft at the above link until it shows up on IETF web server. I'll start a separate thread to collect comments on the new draft. Thanks, Hari > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Wednesday, May 09, 2007 9:38 AM > To: Desineni, Harikishan > Cc: mmusic@ietf.org > 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 > Hari, >=20 > It seems there are some issues as pointed out by your > draft-hdesinen-mmusic-oa-send-bw-attr-02, and the requirements in RFC > 3890 & 3264. >=20 > Based on the txt on the b param in 3264, > | "If the bandwidth attribute is present for a stream, > | it indicates the desired bandwidth that the offerer > | would like to receive." > and the notes from folks who have implemented it and responded to the > list, I too agree that it is best to keep the current usage (TIAS as > declarative of what the agent is willing to receive). >=20 > An update to 3890 with a new TIAS value and clarifications about the > current ones seem appropriate. >=20 > Does anyone disagree on this path forward? >=20 > Jean-Francois. >=20 > > -----Original Message----- > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > Sent: Friday, May 04, 2007 9:34 AM > > To: Geir Arne Sandbakken; Even, Roni; mmusic@ietf.org > > Cc: Magnus Westerlund; 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 > > > > Thanks for the responses. I too think that the declarative usage of > > TIAS as a receive bit-rate (RTP Payload) in offer/answer shall > > continue > > to exist. > > > > Thanks, > > Hari > > > > > -----Original Message----- > > > From: Geir Arne Sandbakken [mailto:geir.sandbakken@tandberg.com] > > > Sent: Thursday, May 03, 2007 7:05 AM > > > To: Even, Roni; Desineni, Harikishan; mmusic@ietf.org > > > Cc: Magnus Westerlund; 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 > > > > > > Hari, > > > > > > We are using it just as Roni explains. Receiver bandwidth indication > > has > > > been very useful for us, and it makes it possible to do quick > > > adjustments at the sender side without any renegotiation. > > > > > > Cheers, > > > Geir Arne > > > > > > > -----Original Message----- > > > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: 03 May 2007 08:03 > > > > To: Desineni, Harikishan; Geir Arne Sandbakken; mmusic@ietf.org > > > > Cc: Magnus Westerlund; 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 > > > > > > > > Hary, > > > > TIAS is being used as a media level attribute indicating the > > maximum > > > BW > > > > that the receiver would like to get. It is not used in offer > > answer. > > > The > > > > semantic of the attribute (what is bw) is as specified in RFC 3890 > > > > > > > > Roni > > > > > > > > > -----Original Message----- > > > > > From: Desineni, Harikishan [mailto:hdesinen@qualcomm.com] > > > > > Sent: Monday, April 30, 2007 2:13 PM > > > > > To: Geir Arne Sandbakken; mmusic@ietf.org > > > > > Cc: Magnus Westerlund; Even, Roni; 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 > > > > > > > > > > Geir, > > > > > > > > > > Thanks for your feedback. > > > > > > > > > > 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 > > > > > > > > > > > > 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. > > > > > > > > > > > > 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 > > > > > > > > > > > > > > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 21:57: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 1IBLGh-0005MW-Mc; Wed, 18 Jul 2007 21:57:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0005LB-OZ; Wed, 18 Jul 2007 21:57:24 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0008V8-CK; Wed, 18 Jul 2007 21:57:24 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBLGc-0007uL-2v; Wed, 18 Jul 2007 21:57:23 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Wed, 18 Jul 2007 21:57:34 -0400 To: Henry Sinnreich , Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [MMUSIC] Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 18-Jul-07, at 21:19 , Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which > gives the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some > other techniques do (e.g., Saikat's TCP work). I should add that ICE also handles: - the case of multi-homed peers, - peers that want to exchange multiple media streams, - media streams which are composed of multiple components (e.g. RTP and RTCP). These are cases that a solution for SIP needs to handle, but I have not seen discussed in other proposals. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 22:00: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 1IBLJV-0006o8-Ua; Wed, 18 Jul 2007 22:00:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLJV-0006nz-0q for mmusic@ietf.org; Wed, 18 Jul 2007 22:00:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBLJU-00006j-5w for mmusic@ietf.org; Wed, 18 Jul 2007 22:00:20 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6J20IOq022288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Jul 2007 19:00:18 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6J20HQS027593 for ; Wed, 18 Jul 2007 19:00:18 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 19:00:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 19:00:21 -0700 Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B03100E16@NAEX01.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please review the new draft "Bandwidth attributes in SDP Offer/Answer model" Thread-Index: AcfJqJBCEEEuQaueQteFTbRmZTfGVw== From: "Desineni, Harikishan" To: X-OriginalArrivalTime: 19 Jul 2007 02:00:10.0760 (UTC) FILETIME=[89D6E880:01C7C9A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: hd@qualcomm.com Subject: [MMUSIC] Please review the new draft "Bandwidth attributes in SDP Offer/Answer model" 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="===============1869995916==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1869995916== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9A8.8DC1EBDF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C9A8.8DC1EBDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please use this thread to post comments on draft-hdesinen-mmusic-oa-bw-attr-00.txt. Many details in this draft are based on the e-mail discussions on draft-hdesinen-mmusic-oa-send-bw-attr-02. =20 http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-bw-attr-00. txt =20 For past discussions on "draft-hdesinen-mmusic-oa-send-bw-attr-02", follow the e-mail thread "Proposal to modify RFC3890 TIAS in offer/answer" posted on 04/17/2007. =20 [I posted -00 version of the draft on 6th July but it did not appear on IETF pages so far. The above link will be kept active until the draft appears on IETF server.] =20 Thanks, Hari =20 ------_=_NextPart_001_01C7C9A8.8DC1EBDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please use this thread to post comments on = draft-hdesinen-mmusic-oa-bw-attr-00.txt. Many details in this draft are based on the e-mail discussions on = draft-hdesinen-mmusic-oa-send-bw-attr-02.

 

http://people.qualcomm.com/hdesinen/draft-hdesinen-mmusic-oa-bw-a= ttr-00.txt

 

For past discussions on = “draft-hdesinen-mmusic-oa-send-bw-attr-02”, follow the e-mail thread “Proposal to modify RFC3890 TIAS in = offer/answer” posted on 04/17/2007.

 

[I posted -00 version of the draft on 6th July but it did not = appear on IETF pages so far. The above link will be kept active until the draft = appears on IETF server.]

 

Thanks,

Hari

 

------_=_NextPart_001_01C7C9A8.8DC1EBDF-- --===============1869995916== 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 --===============1869995916==-- From mmusic-bounces@ietf.org Wed Jul 18 22:56: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 1IBMBp-0004I7-6P; Wed, 18 Jul 2007 22:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMBm-0004HA-Kp; Wed, 18 Jul 2007 22:56:26 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMBm-00089X-6y; Wed, 18 Jul 2007 22:56:26 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 2E7CD75804E; Wed, 18 Jul 2007 21:56:25 -0500 (CDT) From: "Frank W. Miller" To: Philip Matthews In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 20:56:09 -0600 Message-Id: <1184813769.3347.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , p2psip@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Wed, 2007-07-18 at 21:19 -0400, Philip Matthews wrote: > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? Well, here's the algorithm I use with my UA (the most recent versions I might add): STUN UA Registrar Server | REGISTER | | |-5060------->| | | w/rport | | | | | | 200 OK | | |<5060--------| | | | | | | | | STUN BReq | | |-5060--------------------->| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5060----------------------| | STUN BResp | | |<5004----------------------| | | | | . | | | . | | | 10sec | | | . | | | . | | | | | | STUN BReq | | |-5060--------------------->| | STUN BResp | | |<5060----------------------| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5004----------------------| | | | | | | I pick up the rport addressing during the REGISTER transaction because of the way my multithreading is done and because its nice to see the same value coming from two different sources out on the Internet. The port numbers on the UA are local port numbers. STUN BReq is a STUN binding request and STUN BResp is a STUN binding response. Port 5004 is for a single RTP session but the same algorithm is usable for any and all UDP ports you need, e.g. additional session ports and RTCP. The difference in order in the first and second sequence is intentional, the implementation doesn't care when the responses show up. This algorithm lets the UA know what its "visible" IP address and port is all the time (assuming that rport and STUN are working) and keeps it the same assuming that the NAT doesn't change it unilaterally (which I have yet to see BTW). When signaling occurs, the "visible" IP address and port are used in the Contact headers for SIP and in the SDP for offers/answers for RTP. Its just about as simple as it gets and I know you're going to say that it doesn't work 100% of the time. I haven't measured how well its done in deployments I've done as yet. I guess I need to do something along those lines. The good news is, I haven't had anyone complain about it so I guess I've been lucky. So let me have it... ;) Thanks, FM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 18 22:56: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 1IBMC8-0004pl-Tb; Wed, 18 Jul 2007 22:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMC4-0004e6-I9; Wed, 18 Jul 2007 22:56:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMC3-00089s-6g; Wed, 18 Jul 2007 22:56:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2007 19:56:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ9vnkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,553,1175497200"; d="scan'208"; a="184645472:sNHT33227658" 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 l6J2ugHS028945; Wed, 18 Jul 2007 19:56:42 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l6J2ufA1012744; Thu, 19 Jul 2007 02:56:41 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 18 Jul 2007 19:55:30 -0700 To: SIP , Behave WG , mmusic@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8440; t=1184813802; x=1185677802; c=relaxed/simple; s=sjdkim2002; 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=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=x+KWwSoKmqIEePOlsgp20zWpePInK2ZzORIHZTzbieU=; b=QBtjhv25FY3TyBQl1jiHLQF6wwNpKdvOpybfov2JXLOf3YZyd8T8LPY+bM5Gc/2Kwlr8v/YL ppKVaktamhwEHc1R4Q/6zQEm9K4yQwozW1dZ5X5EfgYpHzqfhII1T24j; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 First I apologize for the cross post - this is a mmusic draft, I would appreciate replies on the mmusic list only. Few things I am looking for here .... 1) specific reasons why this work is less appropriate for standards track than other work that IETF puts on the standards track. Keep in mind the first step of standards track is Proposed Standards which requires basically no interoperability, then it could move to Draft Standard where interoperability is shown and finally Full Standard if it turns out to be a good idea. If you are going to post a reply to this point, make sure you have read RFC 2026. 2) I am interested in the specifics of problems that ICE fails to solve that the WG has not previous considered. There are lots of people that have implemented versions of it and think it is a good idea - if people are having some problems with it, I'd love to hear about details of things that are wrong. That it has a lot of messages in some use cases has been known for a long time. It used to have far more messages - engineering was done to consider what was a reasonable amount for call set up times and a new design was done to bring the message to a level most people invovled with the design felt was reasonable. If there are specific other than these that are wrong and not considered in the design, now would be a good time to get them on the table. 3) If people think that Skype for example has a simpler solution that works better than ICE. Feel free to describe exactly what it is. Several people invovled with the ICE design have looked in extreme detail at Skype and others and so far none of them have come back with what we should do different than ICE. 4) ICE can be used in a mode where it only provided the reflexive candidate. People were pretty clear that this was far inferior to the modes where there are other candidates. If someone would like to provide exactly how hole punching works better than this very limited ICE technique, I'd be glad to hear the details. This has certainly been an topic that any could have brought up over the last several years. If someone has specifics, I suggest they get out a full proposal really soon. I am very doubtful that hole punching solution is fundamentally different than the type of hole punching ICE does. 5) Some people have suggested that if all NATs were behave complaint, then we would not need ICE. I strongly disagree. I think the only part of ICE we would not need is the TURN relays which are more or less an optional part. Again, specifics on what can be removed are welcome. ICE is far more complicated that anyone wants - the problem is, no one has come up with a proposal that looks like it comes anywhere close to meeting the requirements and if simpler. The design space has been extensively explored by many people. The raw data to understand what will work on what NATs have been painfully tested and documented in publications such as: http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt https://www.guha.cc/saikat/stunt-results.php? (Ford used to have a page too but it seems to be gone) I have a very open mind to considering better ways to do ICE - but I need specific suggestions or it is impossible for me to really think about if the suggestions represent a better path or not. I would love to see more open source ICE code (there is lots already) - I feel that this is an area where ICE is likely just table stakes and owning an proprietary ICE stack will not turn out to be a competitive advantage. Having open source implementations where the development cost was shared and everyone could get working products to market faster would be an advantage to companies. Clearly I expect the bulk of ICE implementations to not be open source but I still would be keen on doing what I can to contribute to an open source version as personally I feel that is in the interest of end users, my employer, and the IETF as a SDO. Cullen On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > > On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > >> Henry Sinnreich skrev: >>> Following some discussions and soul searching, the best approach for >>> ICE-17 for LC would be to _go ahead and make it an experimental >>> RFC_. >>> This would support the development of interoperable >>> implementations, the >>> collection of deployment data and also hopefully open source code. >>> Though I have full faith in ICE, following the practices that >>> made the >>> IETF successful take precedent here, I believe. >>> This is a change from the attached that I wrote on 7/16/2007. >>> Note: We can only hope the proliferation of SBC in VoIP service >>> provider >>> networks will not make these concerns and ICE for SIP a moot >>> issue, but >>> this is another topic. >> >> Henry, >> >> I don't quite understand why you are requesting a status change of >> ICE? To me it appears that ICE is almost finished spec. It has >> been implemented, used and feedback has been influencing the >> protocol. It is definitly one of the better examples of current >> IETF work that actually has running code. Sure, the >> implementations may not be fully updated yet to the latest draft >> version. But I think it is safe to say that ICE works in the >> intended core cases. If there are some corner cases where it >> fails, that may be. But that is not information we will have until >> really large scale deployement or someone makes very extensive tests. > > Henry has, I believe, been very consistent in urging the IETF to > have more "running code" experience on every specification (not > just ICE) than our process requires. He has, IIRC, also advocated > changing the process to require running code before publishing an > RFC. He's even suggested at times that one should have running code > before submitting a protocol draft. > > Another point to consider -- I've known Henry to bark at a tree > with no squirrel in it occasionally, but most of the time he's > pretty reliable, more so than most technology predictors. If he's > worried about ICE, it's probably because he's been talking to > people who are trying to implement it and they're telling him it is > difficult or that they're having performance or reliability issues. > I imagine that there are plenty of internal development teams in > various companies that are working on this and not necessarily > bringing their results back to the IETF. After all, if everybody > sees the emperor as fully clothed, they'd be embarrassed to > proclaim otherwise. Of course, I wish all of these developers were > tied into the IETF, but then I'm sure I don't want to see every ice- > implementor's question on the SIP list. That is why we have a sip- > implementors mailing list, right? > > Personally, I think ICE is the best solution we have. We KNOW of > cases where hole-punching doesn't work, and I think ICE will > produce usable results in most of those cases. But that's just my > personal opinion from reading the specs. I haven't implemented ICE, > and I haven't used anybody else's implementation. Sure, it's > complex, but that's because the underlying problem is complex -- > there are just too many different behaviors out there in "NAT and > firewall land". Of course, I could be wrong, too. It's happened > before, once or twice ;-). Just how sure are we that we're right > about this? > > Are we designing a "spruce goose" or a practical system? Only > experience will tell us. But some good flight reports from the > prototypes could go a long way towards reassuring us of the > design's utility. > > So far we've had a couple of people report hearsay evidence -- that > somebody else has an ICE implementation and it works. Any of you > folks have personal experience you can share? Have there been > prototypes exercised at the interop events? > > -- > Dean > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 02:45: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 1IBPkz-0005xj-WE; Thu, 19 Jul 2007 02:45:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPks-0005wf-Sh; Thu, 19 Jul 2007 02:44:54 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBPks-0005sT-7J; Thu, 19 Jul 2007 02:44:54 -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 l6J6ihpH030819; Thu, 19 Jul 2007 09:44:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:44:38 +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 Jul 2007 09:44:37 +0300 Received: from esdhcp05132.research.nokia.com ([172.21.51.32]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:44:33 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: mmusic@ietf.org, "ext Juha Heinanen" Date: Thu, 19 Jul 2007 09:43:17 +0300 User-Agent: KMail/1.9.6 References: <18079.325.333518.53741@tutpro.com> In-Reply-To: <18079.325.333518.53741@tutpro.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200707190943.17752.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Jul 2007 06:44:33.0499 (UTC) FILETIME=[440642B0:01C7C9D0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mmusic@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org [As Cullen pointed out, this is better located on MMUSIC. Thanks.] On Thursday 19 July 2007 09:14:29 ext Juha Heinanen wrote: > a while back i read ice tutorial slides and my impression was that the > protocol was very complex (pity implementers) and provided only a bit > better nat traversal capability than what [open]ser/rtpproxy/mediaproxy > have been offering to lots of users for years already. Media proxying is totally broken for a bunch of different reasons: 1/ Like many SIP ALGs - it screws the signaling when it does not understand= =20 something. Last time I tried OpenSER media proxying, TCP/COMEDIA sessions d= id=20 not work at all (even with public unfirewalled IPs on both endpoints). 2/ At least mediaproxy implementation does not scale at all. It might be go= od=20 if one's business consists of selling relay boxes. That's an implementation= =20 issue however. 3/ It is totally fatally insecure by design. It is trivial to DoS, or worse= ,=20 hijack, a media flow by sending fake RTP probe packets to the relay. > because of this (complexity, little added value), i doubt that full ice > will be widely implemented or used. i don't have any opinion on if ietf > should publish the spec or not though, because there are already so many > irrelevant rfcs out there that one more doesn't make any difference. 3/ ICE is secure: no voice hammer, no media hijacking. 2/ ICE scales well as it puts the hard work on the endpoints (and usage of= =20 TURN may be limited to worst cases). 1/ ICE does not screw up the SIP signaling, and you do not need to buy a SI= P=20 server upgrade to support the next SDP extension. In all due fairness, simple hole punching also has advantages 1 and 2 over= =20 media relaying. And it is about as secure as SIP without any traversal=20 mechanism, which is to say, less secure than ICE, but much more secure than= =20 media relaying. Regards, =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 Jul 19 04:12: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 1IBR7f-0000nH-1L; Thu, 19 Jul 2007 04:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBR7d-0000mt-4G for mmusic@ietf.org; Thu, 19 Jul 2007 04:12:29 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBR7c-0006G3-0R for mmusic@ietf.org; Thu, 19 Jul 2007 04:12:28 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 80D7720D8E; Thu, 19 Jul 2007 10:12:27 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-6a-469f1ceb183a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 63EEB209FC; Thu, 19 Jul 2007 10:12:27 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 10:12:26 +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 Jul 2007 10:12:26 +0200 Message-ID: <469F1CEA.1040101@ericsson.com> Date: Thu, 19 Jul 2007 10:12:26 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Pyda Srisuresh References: <239224.19734.qm@web33301.mail.mud.yahoo.com> In-Reply-To: <239224.19734.qm@web33301.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 19 Jul 2007 08:12:26.0596 (UTC) FILETIME=[8B090240:01C7C9DC] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "Frank W. Miller" , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Dropping all lists but MMUSIC! Pyda Srisuresh skrev: > Thanks to Henry and Frank for so eloquently articulating this.=20 >=20 > As both Henry and Frank mentioned, I fully support standardizing on HOL= E > PUNCHING TECHNIQUE and leveraging the IETF=92s considerable influence t= o force > NAT vendors to migrate towards implementations that are friendly to Hol= e > Punching and the Application developers to design applications using th= e hole > punching techniques. That should be the FIRST order of priority.=20 >=20 > Yet, what is happening in BEHAVE WG is the other way around. Some peopl= e have > put their weight so heavily in favor of ICE that they asked to drop the= work on > hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT > Traveral application design guidelines" as BEHAVE WG milestone. >=20 > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING TEC= HNIQUES > to move forward as a WG item? I would like to remind people about a few things. ICE was request to=20 become a MMUSIC WG item in Vienna, that is FOUR years ago! The people=20 present supported that. During these years ICE has been rebaked several=20 times. People have provided input about a number of things; traversal=20 cases that didn't work, different forms of complexity, signalling usage. During these 4 years anyone have had the possibility to influence the=20 process, including standing up saying that we should forget about the=20 maximum reliability for the sake of simplicity. But the consensus in=20 this discussion has remained that reliabilty is important. And I also=20 think the changes has shown that one has tried all the tricks that has=20 been thought of try to reduce the complexity of ICE. But as I think most=20 of you agree on, NAT traversal is problematic and simple solution=20 doesn't always work. We are today at state where we don't know know how=20 to make things simpler without sacrificing functionality. There also has been discussion about if there should be multiple=20 solutions etc. But, to my knowledge the consensus also there has been=20 that one solution is the way to go. So Suresh, you and everyone else as participants in the IETF is=20 responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG=20 item. The IETF has run its consensus process and it is now close to=20 completing and producing a ready specification. It may or may not have=20 been looking different if you had provided the details about how such a=20 solution would look. And worked to get consensus that it was what the=20 IETF wanted. Complaining about the general design and tradeoffs after two WG last=20 calls and more than four years of development isn't productive. You all=20 contributed to the consensus process that has leads to this state. At=20 this point only serious bugs in the solution should be forcing any=20 backtracking. Revisiting our choices at this point is wasting time=20 unless there are very strong evidence that the choices made was wrong. I do understand that Henry is arguing for that more experience should be=20 gathered. But, I am not personally agreeing that we need more to publish=20 this as an proposed standard. There has been implementations, there have=20 been tests, there is even deployement as I understand it for earlier=20 versions. I think this all indicate that the general principle does=20 work. And it is great that we are seeing implementations being updated=20 to follow the latest spec, that will help confirm that things do work.=20 But, to me the ICE specification is the most reviewed, worked on=20 specification that I personally has been involved in within the IETF. We=20 are approaching fast the point where more baking will not make any=20 improvements worth wathing for. If there are some minor error are found=20 down the road, we can update the RFC at that point. But I don't see that=20 adding more delay or make it jump through more hops will be beneficial=20 at all. It only increases the time to complete a specification I think=20 the market really want. Cheers Magnus Westerlund (Within his individual hat because this is not my WG) 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 Jul 19 05:21: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 1IBSCX-0000j2-Ju; Thu, 19 Jul 2007 05:21:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBSCW-0000ix-E8 for mmusic@ietf.org; Thu, 19 Jul 2007 05:21:36 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBSCV-00016a-Sk for mmusic@ietf.org; Thu, 19 Jul 2007 05:21:36 -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 l6J9LLSS024294; Thu, 19 Jul 2007 12:21:30 +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 Jul 2007 12:21:18 +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, 19 Jul 2007 12:21:18 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6J9LGGF021773; Thu, 19 Jul 2007 12:21:17 +0300 Received: from [172.21.41.35] (esdhcp04135.research.nokia.com [172.21.41.35]) by kusti.research.nokia.com (Postfix) with ESMTP id C7F9693B77; Thu, 19 Jul 2007 12:21:16 +0300 (EEST) Message-ID: <469F2D0B.8040002@nokia.com> Date: Thu, 19 Jul 2007 12:21:15 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Magnus Westerlund Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <469F1CEA.1040101@ericsson.com> In-Reply-To: <469F1CEA.1040101@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 09:21:18.0376 (UTC) FILETIME=[29C49A80:01C7C9E6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Frank W. Miller" , Pyda Srisuresh , 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 ext Magnus Westerlund wrote: > I do understand that Henry is arguing for that more experience should be > gathered. But, I am not personally agreeing that we need more to publish > this as an proposed standard. There has been implementations, there have > been tests, there is even deployement as I understand it for earlier > versions. I think this all indicate that the general principle does > work. And it is great that we are seeing implementations being updated > to follow the latest spec, that will help confirm that things do work. I agree ICE if anything should be a standards track RFC; it has been implemented, deployed and the spec reviewed more than a whole bunch of Standards Track RFCs that we have published over the years put together. There are numerous implementations with commercial deployment just waiting for the RFC number to bring their implementation up-to-date. Experimental would just not do justice here (not that it would really matter in the end, e.g., https is Informational). Cheers, Aki _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 06:16: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 1IBT3L-0003QQ-8K; Thu, 19 Jul 2007 06:16:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBT3I-0003Ia-8e for mmusic@ietf.org; Thu, 19 Jul 2007 06:16:08 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBT3G-0002d9-Ux for mmusic@ietf.org; Thu, 19 Jul 2007 06:16:08 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Thu, 19 Jul 2007 03:15:57 -0700 From: "David Barrett" To: "'Cullen Jennings'" , "'SIP'" , "'Behave WG'" , Date: Thu, 19 Jul 2007 03:15:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJsHPx6frYreoETXCtB795NMQVMAANmm8Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: Subject: [MMUSIC] RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: Hi Cullen, I think you bring up lot of really great and detailed questions. However, speaking for myself at least, answering those questions doesn't really address my concern. All I want to know is: Does ICE work, and how well? What "works" means is entirely open to debate. I've tossed out "high peer connectivity" and "low connection setup time" as the most important criteria, and I've put hard data behind those numbers as a stake in the ground for comparison, but I'm open to other metrics as well. But regardless of the metrics, I want somebody who uses it and loves it and bases their business upon its success to stand up and explain why it's great. And I want this person to provide real-world data, sampled on a wide scale, proving that ICE "works" -- by any definition. Basically, I want ICE firmly grounded in wide-scale testing and real-world data, and answering the questions below doesn't bring us any closer to that. Whether it's level 10 or level 12 doesn't produce new data. How its algorithms differ from competing ones doesn't show that they're any better or worse. Detailed proposals for change don't shed any light on whether those changes improve or worsen it, because its current state is completely unmeasured. The most powerful thing the IETF can do to standardize the world upon ICE is prove that it works better than any alternative. Because until that's proven, we just need to take it as a matter of faith. -david > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 18, 2007 7:56 PM > To: SIP; Behave WG; mmusic@ietf.org > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > > First I apologize for the cross post - this is a mmusic draft, I > would appreciate replies on the mmusic list only. > > Few things I am looking for here .... > > 1) specific reasons why this work is less appropriate for standards > track than other work that IETF puts on the standards track. Keep in > mind the first step of standards track is Proposed Standards which > requires basically no interoperability, then it could move to Draft > Standard where interoperability is shown and finally Full Standard if > it turns out to be a good idea. If you are going to post a reply to > this point, make sure you have read RFC 2026. > > 2) I am interested in the specifics of problems that ICE fails to > solve that the WG has not previous considered. There are lots of > people that have implemented versions of it and think it is a good > idea - if people are having some problems with it, I'd love to hear > about details of things that are wrong. That it has a lot of messages > in some use cases has been known for a long time. It used to have far > more messages - engineering was done to consider what was a > reasonable amount for call set up times and a new design was done to > bring the message to a level most people invovled with the design > felt was reasonable. If there are specific other than these that are > wrong and not considered in the design, now would be a good time to > get them on the table. > > 3) If people think that Skype for example has a simpler solution that > works better than ICE. Feel free to describe exactly what it is. > Several people invovled with the ICE design have looked in extreme > detail at Skype and others and so far none of them have come back > with what we should do different than ICE. > > 4) ICE can be used in a mode where it only provided the reflexive > candidate. People were pretty clear that this was far inferior to the > modes where there are other candidates. If someone would like to > provide exactly how hole punching works better than this very limited > ICE technique, I'd be glad to hear the details. This has certainly > been an topic that any could have brought up over the last several > years. If someone has specifics, I suggest they get out a full > proposal really soon. I am very doubtful that hole punching solution > is fundamentally different than the type of hole punching ICE does. > > 5) Some people have suggested that if all NATs were behave complaint, > then we would not need ICE. I strongly disagree. I think the only > part of ICE we would not need is the TURN relays which are more or > less an optional part. Again, specifics on what can be removed are > welcome. > > ICE is far more complicated that anyone wants - the problem is, no > one has come up with a proposal that looks like it comes anywhere > close to meeting the requirements and if simpler. The design space > has been extensively explored by many people. The raw data to > understand what will work on what NATs have been painfully tested and > documented in publications such as: > > http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > > http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt > > https://www.guha.cc/saikat/stunt-results.php? > > (Ford used to have a page too but it seems to be gone) > > I have a very open mind to considering better ways to do ICE - but I > need specific suggestions or it is impossible for me to really think > about if the suggestions represent a better path or not. > > I would love to see more open source ICE code (there is lots already) > - I feel that this is an area where ICE is likely just table stakes > and owning an proprietary ICE stack will not turn out to be a > competitive advantage. Having open source implementations where the > development cost was shared and everyone could get working products > to market faster would be an advantage to companies. Clearly I expect > the bulk of ICE implementations to not be open source but I still > would be keen on doing what I can to contribute to an open source > version as personally I feel that is in the interest of end users, my > employer, and the IETF as a SDO. > > Cullen > > > > On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > > > > > On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > > > >> Henry Sinnreich skrev: > >>> Following some discussions and soul searching, the best approach for > >>> ICE-17 for LC would be to _go ahead and make it an experimental > >>> RFC_. > >>> This would support the development of interoperable > >>> implementations, the > >>> collection of deployment data and also hopefully open source code. > >>> Though I have full faith in ICE, following the practices that > >>> made the > >>> IETF successful take precedent here, I believe. > >>> This is a change from the attached that I wrote on 7/16/2007. > >>> Note: We can only hope the proliferation of SBC in VoIP service > >>> provider > >>> networks will not make these concerns and ICE for SIP a moot > >>> issue, but > >>> this is another topic. > >> > >> Henry, > >> > >> I don't quite understand why you are requesting a status change of > >> ICE? To me it appears that ICE is almost finished spec. It has > >> been implemented, used and feedback has been influencing the > >> protocol. It is definitly one of the better examples of current > >> IETF work that actually has running code. Sure, the > >> implementations may not be fully updated yet to the latest draft > >> version. But I think it is safe to say that ICE works in the > >> intended core cases. If there are some corner cases where it > >> fails, that may be. But that is not information we will have until > >> really large scale deployement or someone makes very extensive tests. > > > > Henry has, I believe, been very consistent in urging the IETF to > > have more "running code" experience on every specification (not > > just ICE) than our process requires. He has, IIRC, also advocated > > changing the process to require running code before publishing an > > RFC. He's even suggested at times that one should have running code > > before submitting a protocol draft. > > > > Another point to consider -- I've known Henry to bark at a tree > > with no squirrel in it occasionally, but most of the time he's > > pretty reliable, more so than most technology predictors. If he's > > worried about ICE, it's probably because he's been talking to > > people who are trying to implement it and they're telling him it is > > difficult or that they're having performance or reliability issues. > > I imagine that there are plenty of internal development teams in > > various companies that are working on this and not necessarily > > bringing their results back to the IETF. After all, if everybody > > sees the emperor as fully clothed, they'd be embarrassed to > > proclaim otherwise. Of course, I wish all of these developers were > > tied into the IETF, but then I'm sure I don't want to see every ice- > > implementor's question on the SIP list. That is why we have a sip- > > implementors mailing list, right? > > > > Personally, I think ICE is the best solution we have. We KNOW of > > cases where hole-punching doesn't work, and I think ICE will > > produce usable results in most of those cases. But that's just my > > personal opinion from reading the specs. I haven't implemented ICE, > > and I haven't used anybody else's implementation. Sure, it's > > complex, but that's because the underlying problem is complex -- > > there are just too many different behaviors out there in "NAT and > > firewall land". Of course, I could be wrong, too. It's happened > > before, once or twice ;-). Just how sure are we that we're right > > about this? > > > > Are we designing a "spruce goose" or a practical system? Only > > experience will tell us. But some good flight reports from the > > prototypes could go a long way towards reassuring us of the > > design's utility. > > > > So far we've had a couple of people report hearsay evidence -- that > > somebody else has an ICE implementation and it works. Any of you > > folks have personal experience you can share? Have there been > > prototypes exercised at the interop events? > > > > -- > > Dean > > > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 07:57: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 1IBUdP-0007En-3x; Thu, 19 Jul 2007 07:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUdM-0007EB-GZ; Thu, 19 Jul 2007 07:57:28 -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 1IBUdL-0003WS-UH; Thu, 19 Jul 2007 07:57:28 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1IBUdP-0007Eb-Em; Thu, 19 Jul 2007 07:57:31 -0400 In-Reply-To: <1184813769.3347.32.camel@localhost.localdomain> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <1184813769.3347.32.camel@localhost.localdomain> 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, 19 Jul 2007 07:57:36 -0400 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , David Barrett , P2PSIP Mailing List Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 18-Jul-07, at 22:56 , Frank W. Miller wrote: > > Its just about as simple as it gets and I know you're going to say > that > it doesn't work 100% of the time. I haven't measured how well its > done > in deployments I've done as yet. I guess I need to do something along > those lines. The good news is, I haven't had anyone complain about it > so I guess I've been lucky. So let me have it... ;) This is the original STUN algorithm. One situation where it fails is the following: STUN server | NAT | ------------------ | | UA1 UA2 If the NAT does not support hairpinning, then your algorithm will not work. [http://tools.ietf.org/html/draft-jennings-behave-test-results-04 shows that most NATs today do not support UDP hairpinning, and http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not support TCP hairpinning.] This situation can occur when the two UAs belong to the same company, or both are in the same hotel, or both use the same service provider and the service provider has a NAT in front of its entire network, etc. ICE does to things to solve this problem. First of all, UA1 and UA2 exchange their local addresses and ports as well as their STUN-learned addresses. They then test to see which path works. Second, they also exchange TURN addresses, which serve as a backup in case everything else fails. David Barrett's algorithm, if I understand it correctly, would work in this situation. (As far as I can tell, David's is a simplified version of ICE). - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 08:29: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 1IBV8N-0006i5-IL; Thu, 19 Jul 2007 08:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBV8L-0006h8-5s; Thu, 19 Jul 2007 08:29:29 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBV8J-0004ho-Q0; Thu, 19 Jul 2007 08:29:29 -0400 Received: by mail.iptel.org (Postfix, from userid 103) id C03B11810C53; Thu, 19 Jul 2007 14:29:28 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on mail.iptel.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb Received: from [213.192.30.176] (unknown [213.192.30.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTP id 40EA01810C50; Thu, 19 Jul 2007 14:29:28 +0200 (CEST) Message-ID: <469F5925.20401@iptel.org> Date: Thu, 19 Jul 2007 14:29:25 +0200 From: Jan Janak User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Juha Heinanen References: <18079.325.333518.53741@tutpro.com> In-Reply-To: <18079.325.333518.53741@tutpro.com> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=F8190A31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Juha Heinanen wrote: > a while back i read ice tutorial slides and my impression was that the > protocol was very complex (pity implementers) and provided only a bit > better nat traversal capability than what [open]ser/rtpproxy/mediaproxy > have been offering to lots of users for years already. The NAT traversal algorithm implemented in [open]ser, rtpproxy, and mediaproxy had been developed long before the first version of the ICE draft; at that time no other solution existed (except for preliminary STUN and TURN drafts), and we needed something to make it work; in addition to that NAT traversal support in UA was virtually non-existent back then. Having said that, it is true that the algorithm implemented in [open]ser is simpler than ICE, but I believe that these two cannot be directly compared. Even the NAT traversal logic in SER can get pretty complex if none of the end-points is a PSTN gateway in the public internet (especially if you want to handle re-INVITEs and serial forking properly). Jan. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 08:57: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 1IBVZd-0003y6-MG; Thu, 19 Jul 2007 08:57:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVZb-0003xp-AO; Thu, 19 Jul 2007 08:57:39 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBVZa-0007ll-Qt; Thu, 19 Jul 2007 08:57:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6JCvI7u012825; Thu, 19 Jul 2007 15:57:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:57:21 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:57:21 +0300 Received: from hed050126.research.nokia.com ([172.21.50.126]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 15:57:21 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Thu, 19 Jul 2007 15:57:19 +0300 User-Agent: KMail/1.9.6 References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> <469F5A56.9010908@gmail.com> In-Reply-To: <469F5A56.9010908@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707191557.20173.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Jul 2007 12:57:21.0349 (UTC) FILETIME=[584D4F50:01C7CA04] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Cullen Jennings , ext Evgeniy Khramtsov , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 19 July 2007 15:34:30 ext Evgeniy Khramtsov wrote: > Cullen Jennings wrote: > > I would love to see more open source ICE code (there is lots already) > > Could you point me to the _lots_ of open source ICE code? Is there any > open source implementation which supports TURN? I doubt this be much relevant, since hole punching does not support TURN or= =20 anything equivalent either. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 09:59: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 1IBWXU-00038P-07; Thu, 19 Jul 2007 09:59:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWXR-00036c-Ai; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBWXP-0007Qs-Lr; Thu, 19 Jul 2007 09:59:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2007 06:59:26 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE4Kn0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="184927225:sNHT62504640" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6JDxQo6000569; Thu, 19 Jul 2007 06:59:26 -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 l6JDxQTb015331; Thu, 19 Jul 2007 13:59:26 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); Thu, 19 Jul 2007 06:59:26 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 06:59:25 -0700 Message-ID: <469F6E43.5050709@cisco.com> Date: Thu, 19 Jul 2007 09:59:31 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 13:59:25.0674 (UTC) FILETIME=[042C34A0:01C7CA0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20638; t=1184853566; x=1185717566; 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[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=kegm+GYDfRgP2LF/vwfjfUl7bEXiE1E+NDEidfORIVA=; b=USy6VQ3LvedwHSAHFhE0QW2GAsw+xCh0sVEgMXnqe9pcHEsroQ+1t5d5fAVPg9a92UkPrHr5 31n0RSbagRMrrsOnr/hLBlZg4dmD05MOiu2xLgb2fVfxfsGDtHIZ4wnc29XQ3Gh/gIQXgmY4ND woDpsfpx3YS/NsA3Vv3V1RTL4=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 are in fact deployments of ICE, more than one, based on previous versions of the draft. Most folks I talk to are waiting to IETF to finish this thing, so they can go upgrade their code and move to the final version. Delaying it, making it experiental, informational, or any other variation will serve no other purpose than to convince everyone that this work is not done, and so folks should continue to wait. If you want an industry's worth of feedback and data, lets go and finish this thing. That means PS. All of that said, ICE has, probably more than most other specs that have ever come out of RAI, have had the benefit of: a. extensive technical review, comments and feedbacks, including commentary from implementors (including one in my own company, and several others from outside of it) and deployers (Tim Moore from Microsoft) b. design based on years of experience with NATs and NAT traversal c. design based on real collected data on NAT behaviors and on techniques used in other applications d. consideration on incremental deployability and applicability across the entire range of SIP, from p2p to enterprise to large provider to closed application provider and so on e. multiple open source implementations (two have been pointed out already) f. an active design team including security experts that helped in the massive redesign in -10 to simplify things And as such, it would seem to me that, not only is there not a single shred of evidence that suggests this draft deserves anything less than PS, there is evidence only to demonstrate that it has quality far greater than most IETF protocols with that moniker. Other parts of this thread have been folks suggesting alternative techniques that are simpler or work better. Well, I look forward to their drafts. So far, no one has suggested a single thing which was not considered and/or incorporated into ICE in some way over the last four years. ICE was built for reliability - to cover lots of cases and achieve not just 90% effectiveness (not nearly good enough), but as effective as is possible within the limitations of hurting the Internet or violating security policies and other things we won't touch. Without a doubt you can design a custom protocol for any one single deployment scenario with some set of assumptions that works simpler with fewer messages. However, our objective was to design a NAT traversal solution for SIP that applied as broadly as SIP did. ICE has the benefit of resulting in simple flows in simple topologies, but the same logic produces more complex flows in more complex situations, but still works. That was a design decision we made years ago and it remains a sound one. Comments have also been made that, "well, you thought STUN would work and you were wrong". This too is bogus. The limitations of STUN were known at the time of its publication. It was our hope that enough of a market would find it acceptable to be useful. Quoting from RFC 3489: > STUN introduces brittleness into the system in several ways: > > o The discovery process assumes a certain classification of devices > based on their treatment of UDP. There could be other types of > NATs that are deployed that would not fit into one of these molds. > Therefore, future NATs may not be properly detected by STUN. STUN > clients (but not servers) would need to change to accommodate > that. > > o The binding acquisition usage of STUN does not work for all NAT > types. It will work for any application for full cone NATs only. > For restricted cone and port restricted cone NAT, it will work for > some applications depending on the application. Application > specific processing will generally be needed. For symmetric NATs, > the binding acquisition will not yield a usable address. The > tight dependency on the specific type of NAT makes the protocol > brittle. > > o STUN assumes that the server exists on the public Internet. If > the server is located in another private address realm, the user > may or may not be able to use its discovered address to > communicate with other users. There is no way to detect such a > condition. > > o The bindings allocated from the NAT need to be continuously > refreshed. Since the timeouts for these bindings is very > implementation specific, the refresh interval cannot easily be > determined. When the binding is not being actively used to > receive traffic, but to wait for an incoming message, the binding > refresh will needlessly consume network bandwidth. > > o The use of the STUN server as an additional network element > introduces another point of potential security attack. These > attacks are largely prevented by the security measures provided by > STUN, but not entirely. > > > > > > > > Rosenberg, et al. Standards Track [Page 40] > > RFC 3489 STUN March 2003 > > > o The use of the STUN server as an additional network element > introduces another point of failure. If the client cannot locate > a STUN server, or if the server should be unavailable due to > failure, the application cannot function. > > o The use of STUN to discover address bindings will result in an > increase in latency for applications. For example, a Voice over > IP application will see an increase of call setup delays equal to > at least one RTT to the STUN server. > > o The discovery of binding lifetimes is prone to error. It assumes > that the same lifetime will exist for all bindings. This may not > be true if the NAT uses dynamic binding lifetimes to handle > overload, or if the NAT itself reboots during the discovery > process. > > o STUN imposes some restrictions on the network topologies for > proper operation. If client A obtains an address from STUN server > X, and sends it to client B, B may not be able to send to A using > that IP address. The address will not work if any of the > following is true: > > - The STUN server is not in an address realm that is a common > ancestor (topologically) of both clients A and B. For example, > consider client A and B, both of which have residential NAT > devices. Both devices connect them to their cable operators, > but both clients have different providers. Each provider has a > NAT in front of their entire network, connecting it to the > public Internet. If the STUN server used by A is in A's cable > operator's network, an address obtained by it will not be > usable by B. The STUN server must be in the network which is a > common ancestor to both - in this case, the public Internet. > > - The STUN server is in an address realm that is a common > ancestor to both clients, but both clients are behind the same > NAT connecting to that address realm. For example, if the two > clients in the previous example had the same cable operator, > that cable operator had a single NAT connecting their network > to the public Internet, and the STUN server was on the public > Internet, the address obtained by A would not be usable by B. > That is because some NATs will not accept an internal packet > sent to a public IP address which is mapped back to an internal > address. To deal with this, additional protocol mechanisms or > configuration parameters need to be introduced which detect > this case. > > > > > > > Rosenberg, et al. Standards Track [Page 41] > > RFC 3489 STUN March 2003 > > > o Most significantly, STUN introduces potential security threats > which cannot be eliminated. This specification describes > heuristics that can be used to mitigate the problem, but it is > provably unsolvable given what STUN is trying to accomplish. > These security problems are described fully in Section 12. Well, the market didn't find it useful enough. And so we worked to improve. Nearly every one of these limitations has been eliminated by ICE. Go read the IAB considerations section, which discusses this. Binding lifetime discovery is pretty much the only remaining one; fortunately that is a minor one and ICE is just aggressive in that area to compensate. The STUN-control work Dan has been promoting is meant to add ontop of ICE to finally close that issue. So, in case its not abundantly clear, I think there is no merit to the calls for changing ICE to informational or experimental, and that these last minute claims of better solutions or simpler solutions are also without merit. ICE is as deserving, and indeed more so, of a PS moniker than most other documents that achieve that label. -Jonathan R. David Barrett wrote: > Hi Cullen, I think you bring up lot of really great and detailed questions. > > However, speaking for myself at least, answering those questions doesn't > really address my concern. All I want to know is: > > Does ICE work, and how well? > > What "works" means is entirely open to debate. I've tossed out "high peer > connectivity" and "low connection setup time" as the most important > criteria, and I've put hard data behind those numbers as a stake in the > ground for comparison, but I'm open to other metrics as well. > > But regardless of the metrics, I want somebody who uses it and loves it and > bases their business upon its success to stand up and explain why it's > great. And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. > > Basically, I want ICE firmly grounded in wide-scale testing and real-world > data, and answering the questions below doesn't bring us any closer to that. > Whether it's level 10 or level 12 doesn't produce new data. How its > algorithms differ from competing ones doesn't show that they're any better > or worse. Detailed proposals for change don't shed any light on whether > those changes improve or worsen it, because its current state is completely > unmeasured. > > The most powerful thing the IETF can do to standardize the world upon ICE is > prove that it works better than any alternative. Because until that's > proven, we just need to take it as a matter of faith. > > -david > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 18, 2007 7:56 PM >> To: SIP; Behave WG; mmusic@ietf.org >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> First I apologize for the cross post - this is a mmusic draft, I >> would appreciate replies on the mmusic list only. >> >> Few things I am looking for here .... >> >> 1) specific reasons why this work is less appropriate for standards >> track than other work that IETF puts on the standards track. Keep in >> mind the first step of standards track is Proposed Standards which >> requires basically no interoperability, then it could move to Draft >> Standard where interoperability is shown and finally Full Standard if >> it turns out to be a good idea. If you are going to post a reply to >> this point, make sure you have read RFC 2026. >> >> 2) I am interested in the specifics of problems that ICE fails to >> solve that the WG has not previous considered. There are lots of >> people that have implemented versions of it and think it is a good >> idea - if people are having some problems with it, I'd love to hear >> about details of things that are wrong. That it has a lot of messages >> in some use cases has been known for a long time. It used to have far >> more messages - engineering was done to consider what was a >> reasonable amount for call set up times and a new design was done to >> bring the message to a level most people invovled with the design >> felt was reasonable. If there are specific other than these that are >> wrong and not considered in the design, now would be a good time to >> get them on the table. >> >> 3) If people think that Skype for example has a simpler solution that >> works better than ICE. Feel free to describe exactly what it is. >> Several people invovled with the ICE design have looked in extreme >> detail at Skype and others and so far none of them have come back >> with what we should do different than ICE. >> >> 4) ICE can be used in a mode where it only provided the reflexive >> candidate. People were pretty clear that this was far inferior to the >> modes where there are other candidates. If someone would like to >> provide exactly how hole punching works better than this very limited >> ICE technique, I'd be glad to hear the details. This has certainly >> been an topic that any could have brought up over the last several >> years. If someone has specifics, I suggest they get out a full >> proposal really soon. I am very doubtful that hole punching solution >> is fundamentally different than the type of hole punching ICE does. >> >> 5) Some people have suggested that if all NATs were behave complaint, >> then we would not need ICE. I strongly disagree. I think the only >> part of ICE we would not need is the TURN relays which are more or >> less an optional part. Again, specifics on what can be removed are >> welcome. >> >> ICE is far more complicated that anyone wants - the problem is, no >> one has come up with a proposal that looks like it comes anywhere >> close to meeting the requirements and if simpler. The design space >> has been extensively explored by many people. The raw data to >> understand what will work on what NATs have been painfully tested and >> documented in publications such as: >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> (Ford used to have a page too but it seems to be gone) >> >> I have a very open mind to considering better ways to do ICE - but I >> need specific suggestions or it is impossible for me to really think >> about if the suggestions represent a better path or not. >> >> I would love to see more open source ICE code (there is lots already) >> - I feel that this is an area where ICE is likely just table stakes >> and owning an proprietary ICE stack will not turn out to be a >> competitive advantage. Having open source implementations where the >> development cost was shared and everyone could get working products >> to market faster would be an advantage to companies. Clearly I expect >> the bulk of ICE implementations to not be open source but I still >> would be keen on doing what I can to contribute to an open source >> version as personally I feel that is in the interest of end users, my >> employer, and the IETF as a SDO. >> >> Cullen >> >> >> >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: >> >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: >>> >>>> Henry Sinnreich skrev: >>>>> Following some discussions and soul searching, the best approach for >>>>> ICE-17 for LC would be to _go ahead and make it an experimental >>>>> RFC_. >>>>> This would support the development of interoperable >>>>> implementations, the >>>>> collection of deployment data and also hopefully open source code. >>>>> Though I have full faith in ICE, following the practices that >>>>> made the >>>>> IETF successful take precedent here, I believe. >>>>> This is a change from the attached that I wrote on 7/16/2007. >>>>> Note: We can only hope the proliferation of SBC in VoIP service >>>>> provider >>>>> networks will not make these concerns and ICE for SIP a moot >>>>> issue, but >>>>> this is another topic. >>>> Henry, >>>> >>>> I don't quite understand why you are requesting a status change of >>>> ICE? To me it appears that ICE is almost finished spec. It has >>>> been implemented, used and feedback has been influencing the >>>> protocol. It is definitly one of the better examples of current >>>> IETF work that actually has running code. Sure, the >>>> implementations may not be fully updated yet to the latest draft >>>> version. But I think it is safe to say that ICE works in the >>>> intended core cases. If there are some corner cases where it >>>> fails, that may be. But that is not information we will have until >>>> really large scale deployement or someone makes very extensive tests. >>> Henry has, I believe, been very consistent in urging the IETF to >>> have more "running code" experience on every specification (not >>> just ICE) than our process requires. He has, IIRC, also advocated >>> changing the process to require running code before publishing an >>> RFC. He's even suggested at times that one should have running code >>> before submitting a protocol draft. >>> >>> Another point to consider -- I've known Henry to bark at a tree >>> with no squirrel in it occasionally, but most of the time he's >>> pretty reliable, more so than most technology predictors. If he's >>> worried about ICE, it's probably because he's been talking to >>> people who are trying to implement it and they're telling him it is >>> difficult or that they're having performance or reliability issues. >>> I imagine that there are plenty of internal development teams in >>> various companies that are working on this and not necessarily >>> bringing their results back to the IETF. After all, if everybody >>> sees the emperor as fully clothed, they'd be embarrassed to >>> proclaim otherwise. Of course, I wish all of these developers were >>> tied into the IETF, but then I'm sure I don't want to see every ice- >>> implementor's question on the SIP list. That is why we have a sip- >>> implementors mailing list, right? >>> >>> Personally, I think ICE is the best solution we have. We KNOW of >>> cases where hole-punching doesn't work, and I think ICE will >>> produce usable results in most of those cases. But that's just my >>> personal opinion from reading the specs. I haven't implemented ICE, >>> and I haven't used anybody else's implementation. Sure, it's >>> complex, but that's because the underlying problem is complex -- >>> there are just too many different behaviors out there in "NAT and >>> firewall land". Of course, I could be wrong, too. It's happened >>> before, once or twice ;-). Just how sure are we that we're right >>> about this? >>> >>> Are we designing a "spruce goose" or a practical system? Only >>> experience will tell us. But some good flight reports from the >>> prototypes could go a long way towards reassuring us of the >>> design's utility. >>> >>> So far we've had a couple of people report hearsay evidence -- that >>> somebody else has an ICE implementation and it works. Any of you >>> folks have personal experience you can share? Have there been >>> prototypes exercised at the interop events? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- 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 Jul 19 10:23: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 1IBWu9-0004p0-TT; Thu, 19 Jul 2007 10:22:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWu7-0004nf-Ap; Thu, 19 Jul 2007 10:22:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBWu5-0001cB-P4; Thu, 19 Jul 2007 10:22:55 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2007 07:22:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALMPn0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,557,1175497200"; d="scan'208"; a="167345601:sNHT37532907" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6JEMqNK031706; Thu, 19 Jul 2007 07:22:52 -0700 Received: from [10.32.245.154] (stealth-10-32-245-154.cisco.com [10.32.245.154]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6JEMo6C005087; Thu, 19 Jul 2007 14:22:50 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4BD296F0-6FC7-4BDE-A783-A835F081FBE7@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Date: Thu, 19 Jul 2007 10:22:40 -0400 To: "David Barrett" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12383; t=1184854972; x=1185718972; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20; bh=kqAskR4tW+DPt7PvKW86K+THsqhA+TM3eU/Pi58egKQ=; b=epeHg/r4RBUPTAeLA1lWvf0v1oPD3eMC7bZLizS+3AIfwH00Haa3Ql5fVLI5FOyTEf71XEyw WileZupc1krOR5mCO8GEMflbOq9B8jQECA+1ly2NLow3mUzDlUJS+6RQ; Authentication-Results: sj-dkim-4; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Jul 19, 2007, at 6:15 AM, David Barrett wrote: > Hi Cullen, I think you bring up lot of really great and detailed =20 > questions. > > However, speaking for myself at least, answering those questions =20 > doesn't > really address my concern. All I want to know is: > > Does ICE work, and how well? > > What "works" means is entirely open to debate. It may have been in the past, but the debate I think is closed, =20 because the requirements captured the definition of "works". If you =20 want to re-open the requirements discussion, please be clear about that. > I've tossed out "high peer > connectivity" and "low connection setup time" as the most important > criteria, and I've put hard data behind those numbers as a stake in =20= > the > ground for comparison, but I'm open to other metrics as well. > See the requirements. One not often mentioned but clearly a =20 requirement that ICE works very hard to meet is "use the most direct =20 path available". > But regardless of the metrics, I want somebody who uses it and =20 > loves it and > bases their business upon its success to stand up and explain why it's > great. > And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. > This is in fact an extremely important exercise, and precisely the =20 activity which according to RFC2026 is what should be happening after =20= approval as proposed standard, and before advancement to draft =20 standard. > Basically, I want ICE firmly grounded in wide-scale testing and =20 > real-world > data, and answering the questions below doesn't bring us any closer =20= > to that. > Whether it's level 10 or level 12 doesn't produce new data. How its > algorithms differ from competing ones doesn't show that they're any =20= > better > or worse. Detailed proposals for change don't shed any light on =20 > whether > those changes improve or worsen it, because its current state is =20 > completely > unmeasured. > Showing how the algorithms work better, or work in more cases that =20 are covered by the requirements does in fact show that it's better, =20 with respect to the requirements. Again, you're arguing indirectly =20 that we should re-open the requirements discussion, which I do not =20 think would be terribly productive, but would support if there is in =20 fact consensus to do so. > The most powerful thing the IETF can do to standardize the world =20 > upon ICE is > prove that it works better than any alternative. Because until that's > proven, we just need to take it as a matter of faith. > I do not think that is desirable. The perfect is the enemy of the =20 good. ICE does not have to be better than anything else. It just has =20 to be "good enough" and see wide adoption. That's my 2=A2 (as an individual, not as an IAB member, in case anybody =20= cares). DaveO > -david > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 18, 2007 7:56 PM >> To: SIP; Behave WG; mmusic@ietf.org >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC =20 >> for RFC >> >> >> First I apologize for the cross post - this is a mmusic draft, I >> would appreciate replies on the mmusic list only. >> >> Few things I am looking for here .... >> >> 1) specific reasons why this work is less appropriate for standards >> track than other work that IETF puts on the standards track. Keep in >> mind the first step of standards track is Proposed Standards which >> requires basically no interoperability, then it could move to Draft >> Standard where interoperability is shown and finally Full Standard if >> it turns out to be a good idea. If you are going to post a reply to >> this point, make sure you have read RFC 2026. >> >> 2) I am interested in the specifics of problems that ICE fails to >> solve that the WG has not previous considered. There are lots of >> people that have implemented versions of it and think it is a good >> idea - if people are having some problems with it, I'd love to hear >> about details of things that are wrong. That it has a lot of messages >> in some use cases has been known for a long time. It used to have far >> more messages - engineering was done to consider what was a >> reasonable amount for call set up times and a new design was done to >> bring the message to a level most people invovled with the design >> felt was reasonable. If there are specific other than these that are >> wrong and not considered in the design, now would be a good time to >> get them on the table. >> >> 3) If people think that Skype for example has a simpler solution that >> works better than ICE. Feel free to describe exactly what it is. >> Several people invovled with the ICE design have looked in extreme >> detail at Skype and others and so far none of them have come back >> with what we should do different than ICE. >> >> 4) ICE can be used in a mode where it only provided the reflexive >> candidate. People were pretty clear that this was far inferior to the >> modes where there are other candidates. If someone would like to >> provide exactly how hole punching works better than this very limited >> ICE technique, I'd be glad to hear the details. This has certainly >> been an topic that any could have brought up over the last several >> years. If someone has specifics, I suggest they get out a full >> proposal really soon. I am very doubtful that hole punching solution >> is fundamentally different than the type of hole punching ICE does. >> >> 5) Some people have suggested that if all NATs were behave complaint, >> then we would not need ICE. I strongly disagree. I think the only >> part of ICE we would not need is the TURN relays which are more or >> less an optional part. Again, specifics on what can be removed are >> welcome. >> >> ICE is far more complicated that anyone wants - the problem is, no >> one has come up with a proposal that looks like it comes anywhere >> close to meeting the requirements and if simpler. The design space >> has been extensively explored by many people. The raw data to >> understand what will work on what NATs have been painfully tested and >> documented in publications such as: >> >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf >> >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt >> >> https://www.guha.cc/saikat/stunt-results.php? >> >> (Ford used to have a page too but it seems to be gone) >> >> I have a very open mind to considering better ways to do ICE - but I >> need specific suggestions or it is impossible for me to really think >> about if the suggestions represent a better path or not. >> >> I would love to see more open source ICE code (there is lots already) >> - I feel that this is an area where ICE is likely just table stakes >> and owning an proprietary ICE stack will not turn out to be a >> competitive advantage. Having open source implementations where the >> development cost was shared and everyone could get working products >> to market faster would be an advantage to companies. Clearly I expect >> the bulk of ICE implementations to not be open source but I still >> would be keen on doing what I can to contribute to an open source >> version as personally I feel that is in the interest of end users, my >> employer, and the IETF as a SDO. >> >> Cullen >> >> >> >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: >> >>> >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: >>> >>>> Henry Sinnreich skrev: >>>>> Following some discussions and soul searching, the best =20 >>>>> approach for >>>>> ICE-17 for LC would be to _go ahead and make it an experimental >>>>> RFC_. >>>>> This would support the development of interoperable >>>>> implementations, the >>>>> collection of deployment data and also hopefully open source code. >>>>> Though I have full faith in ICE, following the practices that >>>>> made the >>>>> IETF successful take precedent here, I believe. >>>>> This is a change from the attached that I wrote on 7/16/2007. >>>>> Note: We can only hope the proliferation of SBC in VoIP service >>>>> provider >>>>> networks will not make these concerns and ICE for SIP a moot >>>>> issue, but >>>>> this is another topic. >>>> >>>> Henry, >>>> >>>> I don't quite understand why you are requesting a status change of >>>> ICE? To me it appears that ICE is almost finished spec. It has >>>> been implemented, used and feedback has been influencing the >>>> protocol. It is definitly one of the better examples of current >>>> IETF work that actually has running code. Sure, the >>>> implementations may not be fully updated yet to the latest draft >>>> version. But I think it is safe to say that ICE works in the >>>> intended core cases. If there are some corner cases where it >>>> fails, that may be. But that is not information we will have until >>>> really large scale deployement or someone makes very extensive =20 >>>> tests. >>> >>> Henry has, I believe, been very consistent in urging the IETF to >>> have more "running code" experience on every specification (not >>> just ICE) than our process requires. He has, IIRC, also advocated >>> changing the process to require running code before publishing an >>> RFC. He's even suggested at times that one should have running code >>> before submitting a protocol draft. >>> >>> Another point to consider -- I've known Henry to bark at a tree >>> with no squirrel in it occasionally, but most of the time he's >>> pretty reliable, more so than most technology predictors. If he's >>> worried about ICE, it's probably because he's been talking to >>> people who are trying to implement it and they're telling him it is >>> difficult or that they're having performance or reliability issues. >>> I imagine that there are plenty of internal development teams in >>> various companies that are working on this and not necessarily >>> bringing their results back to the IETF. After all, if everybody >>> sees the emperor as fully clothed, they'd be embarrassed to >>> proclaim otherwise. Of course, I wish all of these developers were >>> tied into the IETF, but then I'm sure I don't want to see every ice- >>> implementor's question on the SIP list. That is why we have a sip- >>> implementors mailing list, right? >>> >>> Personally, I think ICE is the best solution we have. We KNOW of >>> cases where hole-punching doesn't work, and I think ICE will >>> produce usable results in most of those cases. But that's just my >>> personal opinion from reading the specs. I haven't implemented ICE, >>> and I haven't used anybody else's implementation. Sure, it's >>> complex, but that's because the underlying problem is complex -- >>> there are just too many different behaviors out there in "NAT and >>> firewall land". Of course, I could be wrong, too. It's happened >>> before, once or twice ;-). Just how sure are we that we're right >>> about this? >>> >>> Are we designing a "spruce goose" or a practical system? Only >>> experience will tell us. But some good flight reports from the >>> prototypes could go a long way towards reassuring us of the >>> design's utility. >>> >>> So far we've had a couple of people report hearsay evidence -- that >>> somebody else has an ICE implementation and it works. Any of you >>> folks have personal experience you can share? Have there been >>> prototypes exercised at the interop events? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www1.ietf.org/mailman/listinfo/behave >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 10:54: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 1IBXNp-0003hT-8f; Thu, 19 Jul 2007 10:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXNm-0003fs-21; Thu, 19 Jul 2007 10:53:34 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBXNl-0000So-Gs; Thu, 19 Jul 2007 10:53:34 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 2EA8B1810C50; Thu, 19 Jul 2007 16:53:33 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Jul 2007 16:45:59 +0200 To: Jan Janak ,Juha Heinanen From: Jiri Kuthan Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC In-Reply-To: <469F5925.20401@iptel.org> References: <18079.325.333518.53741@tutpro.com> <469F5925.20401@iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070719145334.2EA8B1810C50@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org, 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 At 14:29 19/07/2007, Jan Janak wrote: >Juha Heinanen wrote: >> a while back i read ice tutorial slides and my impression was that the >> protocol was very complex (pity implementers) and provided only a bit >> better nat traversal capability than what [open]ser/rtpproxy/mediaproxy >> have been offering to lots of users for years already. > > The NAT traversal algorithm implemented in [open]ser, rtpproxy, and > mediaproxy had been developed long before the first version of the ICE > draft; at that time no other solution existed (except for preliminary > STUN and TURN drafts), and we needed something to make it work; in > addition to that NAT traversal support in UA was virtually non-existent > back then. > > Having said that, it is true that the algorithm implemented in > [open]ser is simpler than ICE, but I believe that these two cannot > be directly compared. Even the NAT traversal logic in SER can get > pretty complex if none of the end-points is a PSTN gateway in the > public internet (especially if you want to handle re-INVITEs and > serial forking properly). I don't think it is a question whether ICE is complex or not. The question is if the complexity is worth it. An argumentation line one can choose is the e2e principle which justifies the load of software loaded in the end-devices (think for example of TCP) to gain reliability. If ICE can accomplish the reliability promise, it also helps to migrate away from media relays (which is what SER does using rtpproxy) , which is a good thing. So I think that the right course of action is that folks doubting ICE reliability make their case (by that I mean specific arguments rather than emotional debates about red-colored nails and other hardware). -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 11: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 1IBXUQ-0002Rs-MP; Thu, 19 Jul 2007 11:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXUP-0002Q3-Jv for mmusic@ietf.org; Thu, 19 Jul 2007 11:00:25 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBXUP-0000ki-BU for mmusic@ietf.org; Thu, 19 Jul 2007 11:00:25 -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 l6JF0LF05468; Thu, 19 Jul 2007 15:00:21 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 Date: Thu, 19 Jul 2007 10:00:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11568C2E@zrc2hxm0.corp.nortel.com> In-reply-to: <469F6E43.5050709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICE-17 and 4092 Thread-Index: AcfKDRAftGUFihrOTgqvswl3a369sQACEjOQ References: <469F6E43.5050709@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [MMUSIC] ICE-17 and 4092 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 Is there any reason why ICE-17 deprecates RFC 4091, but not RFC 4092? I think it should obsolete both, otherwise, it will let people believe that ANAT is still alive. - Francois _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 11:20: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 1IBXmr-0001Jb-8O; Thu, 19 Jul 2007 11:19:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBXmn-0001Bp-PI; Thu, 19 Jul 2007 11:19:25 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBXmn-0003GY-FR; Thu, 19 Jul 2007 11:19:25 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 14D4D1C8029; Thu, 19 Jul 2007 10:05:08 -0500 (CDT) From: "Frank W. Miller" To: "'Jonathan Rosenberg'" , "'David Barrett'" Date: Thu, 19 Jul 2007 09:19:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <469F6E43.5050709@cisco.com> Thread-index: AcfKDQH7ZSN1xI7SS1Wni46u9zV1DQACXjyw Message-Id: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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] a. extensive technical review, comments and feedbacks, including commentary from implementors (including one in my own company, and several others from outside of it) and deployers (Tim Moore from Microsoft) FM: While I applaud the time and effort that the large vendors have obviously invested in this, this is a qualitative statement. Perhaps Cisco and/or Microsoft have empirical data they would be willing to share about robustness and performance? I don't think anyone here, including myself, is saying that ICE should not go forward or be used (its ability to handle hairpinning is of great interest for example), we are asking for evidence that we're not going to have another 3489 experience if we can avoid it. e. multiple open source implementations (two have been pointed out already) FM: I think I missed those, can they be repeated? The only one I'm aware of is pjnath and its first release was a little over two months ago and its based on -15. Thanks, FM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 11:36: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 1IBY2M-0004XT-An; Thu, 19 Jul 2007 11:35:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY2J-0004W0-BF; Thu, 19 Jul 2007 11:35:27 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBY2I-0003tj-Pv; Thu, 19 Jul 2007 11:35:27 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 08:35:14 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 l6JFXqot020951; Thu, 19 Jul 2007 08:33:53 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6JFZ70c021529; Thu, 19 Jul 2007 08:35:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:35:07 -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 Date: Thu, 19 Jul 2007 08:30:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Thread-Index: AcfJothpej38ca2VQqWJmM78llWMcwAdAQ6Q References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 19 Jul 2007 15:35:07.0342 (UTC) FILETIME=[627936E0:01C7CA1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org Subject: [MMUSIC] RE: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC 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 Phil, You are right again, but as mentioned, concept papers (a true torrent over many years lately) and discussion lists cannot replace published measurement tools, measured results and tweaking the approach based on measurements; measuring the improvements, etc.=20 This is the reason why I am not going into debating points about the merits of ICE, but rather the best approach to make it successful and be able to prove it. ICE is not a protocol agreement like SIP, but a technology that faces the great physical complexity on the net, so the protocol discussion approach is no replacement for testing and tweaking. This probably explains why we are in this discussion about ICE in the first place. By the same token I-D process arguments and consensus are no replacement either for proof on the net.=20 Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 8:19 PM To: Henry Sinnreich Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole =20 punching algorithm. It differs from others that I have seen written up in the following =20 ways: - ICE has the concept of peer reflexive addresses, which other hole-=20 punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives =20 the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other =20 techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 11:42: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 1IBY8w-0003TK-8k; Thu, 19 Jul 2007 11:42:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY8t-0003S6-LY; Thu, 19 Jul 2007 11:42:15 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBY8t-0004Bo-7b; Thu, 19 Jul 2007 11:42:15 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JFgDq4006106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 10:42:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469F865A.204@nostrum.com> Date: Thu, 19 Jul 2007 10:42:18 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Frank W. Miller" References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'SIP' , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 7/19/07 10:19 AM, Frank W. Miller wrote: > FM: While I applaud the time and effort that the large vendors have > obviously invested in this, this is a qualitative statement. Perhaps Cisco > and/or Microsoft have empirical data they would be willing to share about > robustness and performance? That's the kind of data you get between "proposed standard" and "draft standard" -- not *prior* to publication. I'm not sure why there's so much noise about setting the bar much, much higher for ICE than we do for other IETF proposals. To be clear: to get this kind of experience (especially as it pertains to interoperability), you need to have a stable (i.e., frozen) specification. Internet Drafts simply don't provide an appropriate basis for the kinds of proof that you and others are demanding. I think we would all benefit from a quick review of RFC 2026: > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. ... > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. /a _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 12:23: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 1IBYmz-0007Nl-LW; Thu, 19 Jul 2007 12:23:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYmx-0007NT-4Q for mmusic@ietf.org; Thu, 19 Jul 2007 12:23:39 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=roundabout.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBYmw-0005EM-GO for mmusic@ietf.org; Thu, 19 Jul 2007 12:23:39 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id 66B0762A4E4; Thu, 19 Jul 2007 10:25:33 -0600 (MDT) Message-ID: <469F907C.90907@jabber.org> Date: Thu, 19 Jul 2007 10:25:32 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Adam Roach Subject: Re: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F865A.204@nostrum.com> In-Reply-To: <469F865A.204@nostrum.com> Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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="===============0556716776==" Errors-To: mmusic-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0556716776== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000200030806050402040606" This is a cryptographically signed message in MIME format. --------------ms000200030806050402040606 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Roach wrote: > On 7/19/07 10:19 AM, Frank W. Miller wrote: >> FM: While I applaud the time and effort that the large vendors have >> obviously invested in this, this is a qualitative statement. Perhaps >> Cisco >> and/or Microsoft have empirical data they would be willing to share about >> robustness and performance? > > That's the kind of data you get between "proposed standard" and "draft > standard" -- not *prior* to publication. I'm not sure why there's so > much noise about setting the bar much, much higher for ICE than we do > for other IETF proposals. Yes, it's a puzzle. Perhaps someone could elaborate? > To be clear: to get this kind of experience (especially as it pertains > to interoperability), you need to have a stable (i.e., frozen) > specification. Internet Drafts simply don't provide an appropriate basis > for the kinds of proof that you and others are demanding. Agreed. If the proof is not forthcoming once ICE advances to proposed standard, then it won't deserve to advance to draft standard. Simple as that. Let's not forget that RFC standards for "request for comments". :) Peter --------------ms000200030806050402040606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzE5MTYyNTMyWjAjBgkqhkiG9w0BCQQxFgQUj8JENBysUA42MQu60Kd8+vnWREswUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEAbhHCNJt9xJ399RYTttv3Zmi0OgIEioNTMAIeJ8QmT49Omn+T UlURly+ObAw4rfg36x/+SLTBKGwo9eIwIab3pLNaYoTixTl1CMVS9yYOXUc/sDgn152FHR+1 ZgYvHWEn1mWuQXMpaEqMwc/AVm5aON6X8tgN2g0U5jIOsxAngfrfl5prXTHT4LadlybyUmRN yW0Vd3ib3gjTvy72yzv7rTZoQiHLSQy2K9rvcD0sGdl4Q6+vg9L02Z3rlzRF89leKvfvqjmz hzRRmPfAljUG2lifT+UCdPpJbjXTIuzSdpnfmPqPjtVgPpOAuS8eWi2n24T3CXhV/2SA0RHE drkVwgAAAAAAAA== --------------ms000200030806050402040606-- --===============0556716776== 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 --===============0556716776==-- From mmusic-bounces@ietf.org Thu Jul 19 12:26: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 1IBYq7-0008OV-Oy; Thu, 19 Jul 2007 12:26:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYq6-0008OQ-C7 for mmusic@ietf.org; Thu, 19 Jul 2007 12:26:54 -0400 Received: from dencfw1.jabber.com ([207.182.164.5] helo=roundabout.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBYq4-00036q-Td for mmusic@ietf.org; Thu, 19 Jul 2007 12:26:54 -0400 Received: from roundabout.local (localhost [127.0.0.1]) by roundabout.local (Postfix) with ESMTP id 42E2262A4F4; Thu, 19 Jul 2007 10:28:48 -0600 (MDT) Message-ID: <469F913F.5070702@jabber.org> Date: Thu, 19 Jul 2007 10:28:47 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070604 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [MMUSIC] ICE deployment data before LC for RFC References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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="===============0037947416==" Errors-To: mmusic-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0037947416== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020308010101080907080005" This is a cryptographically signed message in MIME format. --------------ms020308010101080907080005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Frank W. Miller wrote: > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > e. multiple open source implementations (two have been pointed out > already) > > FM: I think I missed those, can they be repeated? The only one I'm aware of > is pjnath and its first release was a little over two months ago and its > based on -15. http://www1.ietf.org/mail-archive/web/mmusic/current/msg05999.html /psa --------------ms020308010101080907080005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYUDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGowggdSoAMCAQICAwFotjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwNzA1MTYxODMyWhcNMDgwNzA0MTYxODMyWjCBwjELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxIjAgBgNVBAoTGVhN UFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2Vy dGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3 DQEJARYSc3RwZXRlckBqYWJiZXIub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAoRCp9cymHb9V1L04LWCmN2wQEbHFWrmgFnAPxRVQpMsB4ifl5iYSDICmBkLINum2inq9 /+0Fz6ScCEONYC/CDOkkmLPItEDNZ0gdUd+kl+5wMPI+567ttt85ResrUAN0B/gcp+prQKxS 7uM6JcSxC0PdwrWK9pWwxPR+LveLgX9/oE9jSSy5BIQnZVgH8nhjlNMcfkTw/hVuGD/8HJFX 1MVySNt7Qy38Kc3CALmuR3ulGUkYeepGUHXj3gdITJ1CKSKCTq6hqzjTZ4m2BDAdIV4LVVlZ pH8AFs7zcl6HuQ2jLAXqBH97iSHjm5bziC9PaNmAbQkLYIPqSK46YdnSmwIDAQABo4IEeDCC BHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBS08ly4gUAQeznlzuQXQlnPQN0HMTCB3QYDVR0jBIHVMIHSgBQE rNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz cmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsT EUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0g BIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20g THRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2Fs IExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZh aWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRd MFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4 MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3Vz ZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3Mz LnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRD b20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAL7ynZiQ7FHEMcQsQetYQwDHKql1d2dBtPtW YjPvU62LyZHbqFKVc2oA6rKaGBqpUKVYUyoBkfJkyAz5/YgrFufw5mnrqysjctDMKTsjdtvu NnL0pIGnvZsQhlL/sTUV/hDOBv00ypsbHXpv5YrVKpCw4Vs9rwSo/5o8f2K8dMHbNB4dv3GX JfMGQUHR/UDTiMqMOxSRAXQ6xGBwNr3zmfDys7qtgoSqy9nBy3er12WRN10jUjdJsFv11Syh 1qyRr+RH0z3Yz6gfd0tq1S9sdzDZ+hFAai3eyjKU6kNLneumEu0w1jeL9EiDRioFsEqCYTuu +c4/cvqC+T/dP89QbGowgghqMIIHUqADAgECAgMBaLYwDQYJKoZIhvcNAQEFBQAwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnMB4XDTA3MDcwNTE2MTgzMloXDTA4MDcwNDE2MTgzMlowgcIxCzAJBgNVBAYT AlVTMREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQ IFN0YW5kYXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRp ZmljYXRlIE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0B CQEWEnN0cGV0ZXJAamFiYmVyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKEQqfXMph2/VdS9OC1gpjdsEBGxxVq5oBZwD8UVUKTLAeIn5eYmEgyApgZCyDbptop6vf/t Bc+knAhDjWAvwgzpJJizyLRAzWdIHVHfpJfucDDyPueu7bbfOUXrK1ADdAf4HKfqa0CsUu7j OiXEsQtD3cK1ivaVsMT0fi73i4F/f6BPY0ksuQSEJ2VYB/J4Y5TTHH5E8P4Vbhg//ByRV9TF ckjbe0Mt/CnNwgC5rkd7pRlJGHnqRlB1494HSEydQikigk6uoas402eJtgQwHSFeC1VZWaR/ ABbO83Jeh7kNoywF6gR/e4kh45uW84gvT2jZgG0JC2CD6kiuOmHZ0psCAwEAAaOCBHgwggR0 MAwGA1UdEwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAdBgNVHQ4EFgQUtPJcuIFAEHs55c7kF0JZz0DdBzEwgd0GA1UdIwSB1TCB0oAUBKzb JHdTRkaWXxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3Jh ZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFD QSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASC ATcwggEzMIIBLwYLKwYBBAGBtTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0 ZC4wAwIBARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBb MCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4Yl aHR0cDovL2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2 MDcGCCsGAQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2Vy L2NhMDsGCCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51 c2VyLmNhLmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29t IFRydXN0ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0 LnN0YXJ0Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC+8p2YkOxRxDHELEHrWEMAxyqpdXdnQbT7VmIz 71Oti8mR26hSlXNqAOqymhgaqVClWFMqAZHyZMgM+f2IKxbn8OZp66srI3LQzCk7I3bb7jZy 9KSBp72bEIZS/7E1Ff4Qzgb9NMqbGx16b+WK1SqQsOFbPa8EqP+aPH9ivHTB2zQeHb9xlyXz BkFB0f1A04jKjDsUkQF0OsRgcDa985nw8rO6rYKEqsvZwct3q9dlkTddI1I3SbBb9dUsodas ka/kR9M92M+oH3dLatUvbHcw2foRQGot3soylOpDS53rphLtMNY3i/RIg0YqBbBKgmE7rvnO P3L6gvk/3T/PUGxqMYIELDCCBCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJ c3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZp Y2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwg RnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYwCQYFKw4D AhoFAKCCAkkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcw NzE5MTYyODQ3WjAjBgkqhkiG9w0BCQQxFgQU+157h90qGiQH/y6N6ilSEYo/ybAwUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UE BhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UE CxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNz IDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNv bS5vcmcCAwFotjCBygYLKoZIhvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYD VQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBD ZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkg RW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBaLYw DQYJKoZIhvcNAQEBBQAEggEABgr/lspO1MFtmfzLx8CPPwanKf4rKNSLykU1oHifeccuwAjJ Utkxg12KHpdU9bUqM2IVVyFyra+a1hCSCF9LlMBSdjEK6kt0HkpOGa8j0/VLqRmg0GM7vdDV CF1EJjXwUV442YKEvf6rK6lzbIGanfdeYHy0YNRIB6+qN9fvvcsPmOcCjVuWt1yx2Z6M82s4 a3Ag3kZ6QwBDzAbvz3y8T7CWBA+ZbHnyR3dstkagZtKCkOVqSjdUj5/SlWYAqAUaQ5AEFSP6 hvoKpfGD+d20aLLrJdIkSucXeGZxLwLJSylFnpw1B93+bHzzmPo6bcWO9UGuqXBlTSuqjqML 7UEZRAAAAAAAAA== --------------ms020308010101080907080005-- --===============0037947416== 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 --===============0037947416==-- From mmusic-bounces@ietf.org Thu Jul 19 12:49: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 1IBZCE-0002RC-Sa; Thu, 19 Jul 2007 12:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY5K-0006ye-6x; Thu, 19 Jul 2007 11:38:34 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBY5J-0001sh-IN; Thu, 19 Jul 2007 11:38:34 -0400 Received: from orthrus.local ([172.17.1.56]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6JFcQ6C064180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 10:38:26 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <469F8577.4080506@estacado.net> Date: Thu, 19 Jul 2007 10:38:31 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Frank W. Miller" References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> In-Reply-To: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Thu, 19 Jul 2007 12:49:45 -0400 Cc: 'SIP' , 'Behave WG' , 'David Barrett' , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 7/19/07 10:19 AM, Frank W. Miller wrote: > FM: While I applaud the time and effort that the large vendors have > obviously invested in this, this is a qualitative statement. Perhaps Cisco > and/or Microsoft have empirical data they would be willing to share about > robustness and performance? That's the kind of data you get between "proposed standard" and "draft standard" -- not *prior* to publication. I'm not sure why there's so much noise about setting the bar much, much higher for ICE than we do for other IETF proposals. To be clear: to get this kind of experience (especially as it pertains to interoperability), you need to have a stable (i.e., frozen) specification. Internet Drafts simply don't provide an appropriate basis for the kinds of proof that you and others are demanding. I think we would all benefit from a quick review of RFC 2026: > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. ... > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 13:13: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 1IBZYc-0002Mm-QY; Thu, 19 Jul 2007 13:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZYb-0002Ma-Gf for mmusic@ietf.org; Thu, 19 Jul 2007 13:12:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZYZ-0004FP-UD for mmusic@ietf.org; Thu, 19 Jul 2007 13:12:53 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F248F2052F for ; Thu, 19 Jul 2007 19:12:50 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-25-469f9b9290b3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DD99A203F7 for ; Thu, 19 Jul 2007 19:12:50 +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, 19 Jul 2007 19:12:50 +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 Jul 2007 19:12:50 +0200 Message-ID: <469F9B92.3060906@ericsson.com> Date: Thu, 19 Jul 2007 19:12:50 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:12:50.0434 (UTC) FILETIME=[09260E20:01C7CA28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types 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 finally read the SDP capapbility draft in sufficient detail to think I understand it mostly. There is likely some details that I have gotten wrong. But I have found some issues that I need to raise for discussion. I will split this into separate emails for each topic. I think the handling of the transport capabilites have to little functionality. There is need for specifying which RTP payload types that apply to which transport capabilities. I will list some usages of this that doesn't seem to work correctly without it or bloody ugly hacks. 1. Usage of RTP retransmission (RFC 4588) using payload type multiplexing. In this case the RTP retransmission payload only can be used in cases when the session uses a profile that has AVPF functionality. If one offers both AVP and AVPF with CAPNEG then one gets at least one additional RTP payload type for the AVPF cases. 2. Usage of paylaod types that only make sense over particular transport. For example if one requires RTP/AVP/TCP for a particular paylaod type to be usable due to reliability requirements. As I see it this can be only solved by what I consider a hack. Which is to overdefine a number of payload types that one doesn't intended to use to provide sufficient number for other potential configurations. And I think you need to define them, because leaving them undefined would to me be against current SDP rules. I think this is a hack for several reasons. A. It doesn't clearly define which payload types that are intended to be used in a specific transport. B. It forces one to overwrite the RTP payload types, always. Despite the issues with media delivery prior to receiving answer or having performed the second round of offer/answer C. It prevents this mechanism to in the future be upgraded in a reasonable way with media cability negotiation. See separate email for discussion. I would recommend that one seriously consider using explicit declaration of the payload type used for each transport in the tcap attribute. 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 Jul 19 13:13: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 1IBZZC-0002iA-DZ; Thu, 19 Jul 2007 13:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZZC-0002i4-1X for mmusic@ietf.org; Thu, 19 Jul 2007 13:13:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZZA-0004G7-Pc for mmusic@ietf.org; Thu, 19 Jul 2007 13:13:30 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4B0682052F for ; Thu, 19 Jul 2007 19:13:28 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-31-469f9bb863e0 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 39447203F7 for ; Thu, 19 Jul 2007 19:13:28 +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, 19 Jul 2007 19:13:27 +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 Jul 2007 19:13:27 +0200 Message-ID: <469F9BB7.9040709@ericsson.com> Date: Thu, 19 Jul 2007 19:13:27 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:13:27.0746 (UTC) FILETIME=[1F636A20:01C7CA28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities 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 current proposal total failes to discuss the bandwidth parameter in SDP. This is a serious shortcomming and will result in real issues for the profiles. Different profiles and usages will have different bandwidth parameters. Although media bandwidth may different for different potential configurations I think the major issue exist for the RR and RS attribute which really makes sense to configure differently for different profiles. For example AVPF with some feedback may require much more RTCP bandwidth than AVP. And in case one uses the TFRC addition one may have need for yet another configuration. Thus there is need to be able to connect different bandwidth configurations with specific potential configurations. 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 Jul 19 13:13: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 1IBZZb-0002pJ-18; Thu, 19 Jul 2007 13:13:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZZZ-0002pD-QL for mmusic@ietf.org; Thu, 19 Jul 2007 13:13:53 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBZZZ-0006WJ-3A for mmusic@ietf.org; Thu, 19 Jul 2007 13:13:53 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5D2CD21398 for ; Thu, 19 Jul 2007 19:13:50 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-38-469f9bceac28 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3D281201B8 for ; Thu, 19 Jul 2007 19:13:50 +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, 19 Jul 2007 19:13:49 +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 Jul 2007 19:13:49 +0200 Message-ID: <469F9BCD.8070905@ericsson.com> Date: Thu, 19 Jul 2007 19:13:49 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:13:49.0777 (UTC) FILETIME=[2C851410:01C7CA28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation between potential configurations 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 draft comes to the conclusion that there is no real need for coordintion between different media descriptions and their potential configurations. I think that is wrong for several reasons: 1. I would start with referening once more to a defined usage in RFC 4588 (RTP Retransmission). In the case of desire to use session multiplexing for the retransmission one would only like to use that under the constraint that one already uses AVPF in the primary transmission session. Thus one would like to make the following offer: Primary session: AVP, potential configuration 1: AVPF with NACK Retransmission session: Only used in case primary session selects potential configuration 1. 2. Allow for media capability negotiation. As I see it when moving into a media capability negotiation extension one will very much like to present cases where there are set of media configurations. That may include additional media streams needing their own media descriptions, i.e. RTP sessions / or other media transport (MSRP). One would in other words like to express capabilites like. Lets do (Audio, video and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio and MSRP) depending on peers capabilities. Without the functionality to make higher level bindings between potential configurations into different sets that will not work. Unfortunately the above has one very frightening conclusion, we need to have possibility to do potential configurations for media descriptions that has no match in the actual configuration. 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 Jul 19 13:14: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 1IBZZj-000353-Sv; Thu, 19 Jul 2007 13:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZZi-00034p-Nb for mmusic@ietf.org; Thu, 19 Jul 2007 13:14:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZZh-0004H0-40 for mmusic@ietf.org; Thu, 19 Jul 2007 13:14:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 703AE201B8 for ; Thu, 19 Jul 2007 19:14:00 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-3f-469f9bd800d3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 53A12200F9 for ; Thu, 19 Jul 2007 19:14:00 +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 Jul 2007 19:14:00 +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 Jul 2007 19:13:59 +0200 Message-ID: <469F9BD7.7070308@ericsson.com> Date: Thu, 19 Jul 2007 19:13:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:13:59.0745 (UTC) FILETIME=[32761310:01C7CA28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [MMUSIC] SDPCapNeg-06: Usage of truncated syntax as capability definitions 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 find the suggestion that one uses truncated SDP attributes as an indication that one has a capability very worrying. The reason I think that is that it is ambigous in addition to breaking the defined syntax of attributes. In short there are in most cases no defined meaning for a SDP attribute without its value. To make a general rule without explicit defining that meaning for different attributes will be causing ambiogus results. Lets look at some examples of this. 1. a=rtpmap: in the form "a=rtpmap" it says nothing that rtp/avp hasen't already told you. "a=rtpmap: 97 AMR/8000" does provide some information about that you have some type of support for AMR. But it doesn't tell you what support in regards to payload configurations. In fact even with a single a=fmtp line you only know that one out of several different configurations are supported. To declare your capabilites for which AMR payload configurations you suport, you actually need a matrix over the features. That can't be done without explicit definition of how AMR is going to be interpreted and preferably in another syntax then what is used to provide a single configuration. 2. I think "a=rtcp-fb" is another one that has similar issues as AMR. In this case even worse as it combines with RTP payload formats for the payload specific feedback messages. For example PLI may be supported for some video codecs and not others. Thus requiring one to list the media types which one supports PLI with. I would suggest that one actually uses another attribute for defining capabilities and for that create a structure that allows different capabilities to be explicitly defined for each functionality separately. Overloading capability definitions on SDP attributes defined for configuration is not a good idea. 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 Jul 19 13:14: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 1IBZZp-0003BE-Ae; Thu, 19 Jul 2007 13:14:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZZo-0003B8-8c for mmusic@ietf.org; Thu, 19 Jul 2007 13:14:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBZZn-0004HK-MT for mmusic@ietf.org; Thu, 19 Jul 2007 13:14:08 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 357F52052F for ; Thu, 19 Jul 2007 19:14:07 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-3b-469f9bdf4bc5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29803203F7 for ; Thu, 19 Jul 2007 19:14:07 +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 Jul 2007 19:14:06 +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 Jul 2007 19:14:06 +0200 Message-ID: <469F9BDE.2090109@ericsson.com> Date: Thu, 19 Jul 2007 19:14:06 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:14:06.0573 (UTC) FILETIME=[3687F1D0:01C7CA28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [MMUSIC] SDPCapNeg-06: Media capabilites negotiation 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 like to expand a bit on what I consdier being media capabilites negotiation. It has quite some implications for the SDPCapNeg definition. However, I don't think that the full solution needs to be included in the core spec. It could be an extension if some capabilites of the core exist. But lets start on what I would like to see as possible and what it would be used for. In the requirements document requirement 10 exist which says: REQ-10: It MUST be possible to indicate and negotiate alternative media formats on a per media stream basis. For example, many implementations support multiple codecs, but only one at a time. Changes between codecs cannot be done on- the-fly, e.g. when receiving a simple RTP payload type change. However, to my knowledge that is not the close to the whole truth for devices with limited capabilites. Because they not be able to provide certain codecs when another media streams uses a particular codec. A good example would be that a device can't decode AAC when combined with H.264 while it could do AAC when doing H.263. Such constraints are complex to describe but do exist. In addition there is the issue of correctly describe what ones capabilites are in regards to a specific media format. This is actually a combination of the device capabilites in regards to the payload format, transport and encoding/decoding. Thus another language is need than the one used to configure devices when describing capabilites. For example in a capability language one can do efficient encoding of independent capabilites while configurations needs to list all permutations. There is also the issues around configuring more advanced relations for media which I already brought up in the other emails. This include issues with: - Media before answer - Media descriptions dependent on other media descriptions - Media configurations depending on transport There should be consideration on these issues and what it means for the core of 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 Thu Jul 19 13:14: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 1IBZZx-0003ME-HO; Thu, 19 Jul 2007 13:14:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZZw-0003LY-8G for mmusic@ietf.org; Thu, 19 Jul 2007 13:14:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBZZv-0006X2-I9 for mmusic@ietf.org; Thu, 19 Jul 2007 13:14:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08E53213E1; Thu, 19 Jul 2007 19:14:15 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-45-469f9be6a60a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC345204A3; Thu, 19 Jul 2007 19:14:14 +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 Jul 2007 19:14:12 +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 Jul 2007 19:14:11 +0200 Message-ID: <469F9BE3.5080804@ericsson.com> Date: Thu, 19 Jul 2007 19:14:11 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <467FF802.9050909@cisco.com> In-Reply-To: <467FF802.9050909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2007 17:14:11.0495 (UTC) FILETIME=[3976FB70:01C7CA28] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic 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 think it is quite important to try to avoid sending media if the answerer do not use the actual configuration. This due to the problem with the receivier not knowing what to do with this media. A related issue is that of send direction configuration information that for example H.264 over RTP suffers from. A device sending media needs to provide the receiver with some configuration information to enable it to decode things. This doesn't work particular well in normal offer/answer. In cases when the sender correctly can guess the configuration in the answer it works. But if the answerer changes the configuration it accepts to receive with things stops working well. This can be helped by providing potential configurations that narrows things down to have the answerer select a potential configuration that it actually can use. But in these cases it is quite clear, even if all potential configurations are AVP they still can't decode them because they are likely to use the same payload type number. Cheers Magnus Flemming Andreasen skrev: > The answerer may select a potential configuration containing > parameters that require the offerer to receive the answer before he can > process media correctly. The issue is explained in Section 3.8 in the > SDP Capability Negotiation framework, where one possible solutions is > outlined (preconditions), but not actually specified. The question was > raised whether we want to say more about this issue and if we want to > define additional solutions to it. For example, Jonathan Rosenberg > suggested that use of ICE can help the answerer determine when the > answer has been received by the offerer and hence it is safe to send > media to the offerer. > > The design team discussed this issue in Prague and agreed to elaborate > slightly on the current text. It will be noted that the offerer can > discard media until he receives the answer, if he wants to make sure he > doesn't play garbage. If the offerer wants to avoid clipping on the > other hand, he can play media as soon as it is received, but at the risk > of playing garbage. To avoid both, a three-way handshake is needed (e.g. > precondtion), however that is outside the basic SDP Capability > Negotiation. We will add a note to mention the use of ICE (STUN) as a > possible solution to this three-way handshake as well. > > If you disagree with this, please let me know. > > Thanks > > -- Flemming > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Jul 19 13:38: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 1IBZxd-0005jf-E5; Thu, 19 Jul 2007 13:38:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBZxa-0005ie-Nc for mmusic@ietf.org; Thu, 19 Jul 2007 13:38:42 -0400 Received: from web33312.mail.mud.yahoo.com ([68.142.206.127]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBZxa-0007Bj-9n for mmusic@ietf.org; Thu, 19 Jul 2007 13:38:42 -0400 Received: (qmail 15794 invoked by uid 60001); 19 Jul 2007 17:38:41 -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:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Q31OE9U5PaiNU50WPFXt08hk3aV7dVuJ7VwqOMSu3XEk1jW6xY93fkTEI3ojNazseXegCYe1YX8g4rFTn+MvJmk8QcbhOHMGj2qTdZVAS3uaQaazoAymuMNNDVWcmlivAmxvLTZPYa1fCieK2QwPXhQCc8yz27+yR/Jt6ponE64=; X-YMail-OSG: OoavG3AVM1l7DqQe672pWQ.yI1Y3WF0m1U8jwrcavRQ5lPFpOy6NB0UbhBB8IIEXizzQsg-- Received: from [209.172.74.45] by web33312.mail.mud.yahoo.com via HTTP; Thu, 19 Jul 2007 10:38:41 PDT Date: Thu, 19 Jul 2007 10:38:41 -0700 (PDT) From: Pyda Srisuresh To: David Barrett , 'Melinda Shore' , 'Philip Matthews' MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 David, 90% success in connection rate is very impressive. Are you refering to UDP, TCP or both? As you say, fallback such as relay is essential for 100% connectivity. One cannot use hole punching without a good fallback scheme. regards, suresh --- David Barrett wrote: > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > ICE makes me want to pound red-hot nails into my eye sockets. That said, > > 90% really isn't nearly good enough for residential deployments. > > Incidentally, 90% is where my stats come out today -- this doesn't include > restricted-cone/symmetric and symmetric/symmetric penetration, which has > been prototyped but not added to the production system yet. The hope is > this will get us much close to the 99% range, but it remains to be seen by > how much. > > Furthermore, I'd wager that for most applications (such as VoIP), even > routing 1 in 10 calls through a central relay isn't going to break the bank. > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) to > act as "free" relays for their peers.) > > Thus while NAT penetration using what I guess we're calling the "hole > punching technique" has been demonstrated to work at 90%+ on a very large > scale (hundreds of thousands of clients tested) we should expect that it's > possible to get even better still. If ICE can show how it'd do better, > that'd be great. But we can't tolerate ICE being any worse than that, and > thus before rushing ahead with standardizing an unproven ICE, we should just > take the time to prove it. > > -david > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 13:45:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa3u-0004dN-7b; Thu, 19 Jul 2007 13:45:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa3r-0004ct-UM for mmusic@ietf.org; Thu, 19 Jul 2007 13:45:12 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBa3r-0007lx-BL for mmusic@ietf.org; Thu, 19 Jul 2007 13:45:11 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:45:01 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Frank W. Miller'" Date: Thu, 19 Jul 2007 10:44:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJ/AEOlBMUriURROWxMoN7RNp/BQALk3Uw X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 'Magnus Westerlund' , 'Behave WG' , 'IETF MMUSIC WG' , sip@ietf.org, 'Pyda Srisuresh' , 'P2PSIP Mailing List' Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David Barrett's algorithm, if I understand it correctly, would work in > this situation. (As far as I can tell, David's is a simplified version > of ICE). That's correct. The major differences (so far as I know) between what I'm doing and what ICE does include: - Peer's needn't exchange SDP before attempting connection establishment (rather, the rendezvous server just tells both sides the others' LAN/NAT addresses and they try to connect immediately). - Paths are evaluated in parallel rather than sequentially (ie, I attempt to contact you direct via the LAN and indirectly via your NAT at the same time, and then pick the faster of the two) - There's no support for TURN servers as my application doesn't require them (though it would be extremely straightforward to add). - Clients attempt NAT classification as a *purely advisory* function to support debugging and feed into certain non-critical pairwise optimizations. (Said another way, even if the classification is totally wrong, it'll still work.) - Clients use adaptive keepalives to a STUN server to keep their NAT/FW "hole" open. By "adaptive" I mean I use probing to determine highest safe keepalive frequency of the NAT/FW. (Incidentally, there's no requirement that any two clients use the same STUN server, and indeed I intend to move to enable a "distributed STUN service" using the peers themselves.) Basically, I do the minimum necessary for my requirements, which I respect are much easier than SIP's. However, know that despite my system being much easier, it has been *extremely difficult and time consuming* to get working, despite dozens of iterations drawing upon a network of hundreds of thousands of machines on which to test. Thus I would suggest that if my solution took as long as it did, and went through as many variations as it did, the SIP/ICE implementers should be very wary of hardening anything too early before it hits the real world. Because the real world is really, really strange and unpredictable, I can guarantee you that. Phillip's asked me to put together a bit more precise overview of the system I use and I'll try to get to that soon. -david _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 13:51: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 1IBaA8-0007R8-Jn; Thu, 19 Jul 2007 13:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaA4-0007Pf-NO; Thu, 19 Jul 2007 13:51:36 -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 1IBaA2-0005Qs-TN; Thu, 19 Jul 2007 13:51:36 -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 1IBaA3-0000Eq-0i; Thu, 19 Jul 2007 13:51:35 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@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: <9280291A-AB5A-4AC8-BD63-75AE5339B33D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 19 Jul 2007 13:51:47 -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.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org Subject: [MMUSIC] Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC 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 it would be very nice to see more published data on when ICE succeeds (and specifically when it succeeds in finding a direct path). It would also be nice to see more open source implementations. It used to be that the Routing area would hold a draft in the "almost done" state until they had some implementation experience, and then publish as an RFC only once they had that data. Is this what you are looking for? - Philip On 19-Jul-07, at 11:30 , Henry Sinnreich wrote: > Phil, > > You are right again, but as mentioned, concept papers (a true torrent > over many years lately) and discussion lists cannot replace published > measurement tools, measured results and tweaking the approach based on > measurements; measuring the improvements, etc. > > This is the reason why I am not going into debating points about the > merits of ICE, but rather the best approach to make it successful > and be > able to prove it. > > ICE is not a protocol agreement like SIP, but a technology that faces > the great physical complexity on the net, so the protocol discussion > approach is no replacement for testing and tweaking. This probably > explains why we are in this discussion about ICE in the first place. > > By the same token I-D process arguments and consensus are no > replacement > either for proof on the net. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 8:19 PM > To: Henry Sinnreich > Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; > Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org > Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data > before > LCfor RFC > > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). > > Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 13:57: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 1IBaFr-0008Mw-2M; Thu, 19 Jul 2007 13:57:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaFp-0008Mm-Ll for mmusic@ietf.org; Thu, 19 Jul 2007 13:57:33 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaFp-0008Dr-27 for mmusic@ietf.org; Thu, 19 Jul 2007 13:57:33 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:57:30 -0700 From: "David Barrett" To: "'Jonathan Rosenberg'" Date: Thu, 19 Jul 2007 10:57:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F6E43.5050709@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKDQrsCgBg9rNPRKqODM/+VLHMWwAH6iJg X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > ICE was built for reliability - to cover lots of cases and achieve not > just 90% effectiveness (not nearly good enough), but as effective as is > possible within the limitations of hurting the Internet or violating > security policies and other things we won't touch. Just to clarify, the 90% number (which I'm guessing comes from my published stats) is the success rate of any two peers being able to establish a direct connection without a relay service. If I were to add a relay service (which I don't need for my application, but would be trivial) for the remaining 10% I hope you agree that near 100% of peers would be able to talk. (I say "near" because nothing works at 100% in the real world, no matter how simple it appears on paper.) > a. extensive technical review, comments and feedbacks, including > commentary from implementors (including one in my own company, and > several others from outside of it) and deployers (Tim Moore from > Microsoft) Excellent! Do you or any of your implementor colleagues have any data showing how well the result works? Or if not, do you have an active system that you can instrument to get it? Or a test implementation that can be instrumented in the lab? Or any data at all showing how well ICE works? I understand we have data about the general NAT penetration techniques, years of experience, and active security teams. Does anybody have actual users, using this on a daily basis on a broad scale, proving that the product of all this hard work accomplishes its goals? -david _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:02: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 1IBaK6-0001Ed-Uc; Thu, 19 Jul 2007 14:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaK4-0001Dd-VE for mmusic@ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBaK3-0005pV-Lg for mmusic@ietf.org; Thu, 19 Jul 2007 14:01:56 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:01:52 -0700 From: "David Barrett" To: "'Pyda Srisuresh'" , "'Melinda Shore'" , "'Philip Matthews'" Date: Thu, 19 Jul 2007 11:01:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <725173.15437.qm@web33312.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKLJfy3vmiOiN8RFO5qEAMFGqczAAAiOtQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: Just UDP so far, though I harbor ambitions of adding TCP to the mix so it'll try a bit of everything. > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Thursday, July 19, 2007 10:39 AM > To: David Barrett; 'Melinda Shore'; 'Philip Matthews' > Cc: sip@ietf.org; 'Henry Sinnreich'; behave@ietf.org; mmusic@ietf.org > Subject: RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David, > > 90% success in connection rate is very impressive. Are you refering to > UDP, TCP > or both? As you say, fallback such as relay is essential for 100% > connectivity. > One cannot use hole punching without a good fallback scheme. > > regards, > suresh > > --- David Barrett wrote: > > > > -----Original Message----- > > > From: Melinda Shore [mailto:mshore@cisco.com] > > > > > > ICE makes me want to pound red-hot nails into my eye sockets. That > said, > > > 90% really isn't nearly good enough for residential deployments. > > > > Incidentally, 90% is where my stats come out today -- this doesn't > include > > restricted-cone/symmetric and symmetric/symmetric penetration, which has > > been prototyped but not added to the production system yet. The hope is > > this will get us much close to the 99% range, but it remains to be seen > by > > how much. > > > > Furthermore, I'd wager that for most applications (such as VoIP), even > > routing 1 in 10 calls through a central relay isn't going to break the > bank. > > (Or for mega-discounts, use the full-cone and non-NAT'd clients (>30%) > to > > act as "free" relays for their peers.) > > > > Thus while NAT penetration using what I guess we're calling the "hole > > punching technique" has been demonstrated to work at 90%+ on a very > large > > scale (hundreds of thousands of clients tested) we should expect that > it's > > possible to get even better still. If ICE can show how it'd do better, > > that'd be great. But we can't tolerate ICE being any worse than that, > and > > thus before rushing ahead with standardizing an unproven ICE, we should > just > > take the time to prove it. > > > > -david > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:02: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 1IBaKN-0001qv-MA; Thu, 19 Jul 2007 14:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaKG-0001eD-Sn for mmusic@ietf.org; Thu, 19 Jul 2007 14:02:08 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBaKF-0005qH-7j for mmusic@ietf.org; Thu, 19 Jul 2007 14:02:08 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:01:53 -0700 From: "David Barrett" To: "'David R Oran'" Date: Thu, 19 Jul 2007 11:01:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4BD296F0-6FC7-4BDE-A783-A835F081FBE7@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKEH90TIWL7i1uTU+0yFCSG5eilwAHdIkw X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: 'Cullen Jennings' , 'SIP' , 'Behave WG' , mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: Actually, I'm not trying to reopen the requirements debate. I just want = ICE measured against the requirements that were agreed upon. And I completely agree that perfect is the enemy of the good. The only = ally of the good is reality, and I want to enlist her on our side. -david > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Thursday, July 19, 2007 7:23 AM > To: David Barrett > Cc: 'Cullen Jennings'; 'SIP'; 'Behave WG'; mmusic@ietf.org > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for = RFC >=20 >=20 > On Jul 19, 2007, at 6:15 AM, David Barrett wrote: >=20 > > Hi Cullen, I think you bring up lot of really great and detailed > > questions. > > > > However, speaking for myself at least, answering those questions > > doesn't > > really address my concern. All I want to know is: > > > > Does ICE work, and how well? > > > > What "works" means is entirely open to debate. > It may have been in the past, but the debate I think is closed, > because the requirements captured the definition of "works". If you > want to re-open the requirements discussion, please be clear about = that. >=20 > > I've tossed out "high peer > > connectivity" and "low connection setup time" as the most important > > criteria, and I've put hard data behind those numbers as a stake in > > the > > ground for comparison, but I'm open to other metrics as well. > > > See the requirements. One not often mentioned but clearly a > requirement that ICE works very hard to meet is "use the most direct > path available". >=20 > > But regardless of the metrics, I want somebody who uses it and > > loves it and > > bases their business upon its success to stand up and explain why = it's > > great. > > And I want this person to provide real-world data, sampled on a wide > > scale, proving that ICE "works" -- by any definition. > > > This is in fact an extremely important exercise, and precisely the > activity which according to RFC2026 is what should be happening after > approval as proposed standard, and before advancement to draft > standard. >=20 > > Basically, I want ICE firmly grounded in wide-scale testing and > > real-world > > data, and answering the questions below doesn't bring us any closer > > to that. > > Whether it's level 10 or level 12 doesn't produce new data. How its > > algorithms differ from competing ones doesn't show that they're any > > better > > or worse. Detailed proposals for change don't shed any light on > > whether > > those changes improve or worsen it, because its current state is > > completely > > unmeasured. > > > Showing how the algorithms work better, or work in more cases that > are covered by the requirements does in fact show that it's better, > with respect to the requirements. Again, you're arguing indirectly > that we should re-open the requirements discussion, which I do not > think would be terribly productive, but would support if there is in > fact consensus to do so. >=20 > > The most powerful thing the IETF can do to standardize the world > > upon ICE is > > prove that it works better than any alternative. Because until = that's > > proven, we just need to take it as a matter of faith. > > > I do not think that is desirable. The perfect is the enemy of the > good. ICE does not have to be better than anything else. It just has > to be "good enough" and see wide adoption. >=20 > That's my 2=A2 (as an individual, not as an IAB member, in case = anybody > cares). >=20 > DaveO > > -david > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Wednesday, July 18, 2007 7:56 PM > >> To: SIP; Behave WG; mmusic@ietf.org > >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC > >> for RFC > >> > >> > >> First I apologize for the cross post - this is a mmusic draft, I > >> would appreciate replies on the mmusic list only. > >> > >> Few things I am looking for here .... > >> > >> 1) specific reasons why this work is less appropriate for standards > >> track than other work that IETF puts on the standards track. Keep = in > >> mind the first step of standards track is Proposed Standards which > >> requires basically no interoperability, then it could move to Draft > >> Standard where interoperability is shown and finally Full Standard = if > >> it turns out to be a good idea. If you are going to post a reply = to > >> this point, make sure you have read RFC 2026. > >> > >> 2) I am interested in the specifics of problems that ICE fails to > >> solve that the WG has not previous considered. There are lots of > >> people that have implemented versions of it and think it is a good > >> idea - if people are having some problems with it, I'd love to hear > >> about details of things that are wrong. That it has a lot of = messages > >> in some use cases has been known for a long time. It used to have = far > >> more messages - engineering was done to consider what was a > >> reasonable amount for call set up times and a new design was done = to > >> bring the message to a level most people invovled with the design > >> felt was reasonable. If there are specific other than these that = are > >> wrong and not considered in the design, now would be a good time to > >> get them on the table. > >> > >> 3) If people think that Skype for example has a simpler solution = that > >> works better than ICE. Feel free to describe exactly what it is. > >> Several people invovled with the ICE design have looked in extreme > >> detail at Skype and others and so far none of them have come back > >> with what we should do different than ICE. > >> > >> 4) ICE can be used in a mode where it only provided the reflexive > >> candidate. People were pretty clear that this was far inferior to = the > >> modes where there are other candidates. If someone would like to > >> provide exactly how hole punching works better than this very = limited > >> ICE technique, I'd be glad to hear the details. This has certainly > >> been an topic that any could have brought up over the last several > >> years. If someone has specifics, I suggest they get out a full > >> proposal really soon. I am very doubtful that hole punching = solution > >> is fundamentally different than the type of hole punching ICE does. > >> > >> 5) Some people have suggested that if all NATs were behave = complaint, > >> then we would not need ICE. I strongly disagree. I think the only > >> part of ICE we would not need is the TURN relays which are more or > >> less an optional part. Again, specifics on what can be removed are > >> welcome. > >> > >> ICE is far more complicated that anyone wants - the problem is, no > >> one has come up with a proposal that looks like it comes anywhere > >> close to meeting the requirements and if simpler. The design space > >> has been extensively explored by many people. The raw data to > >> understand what will work on what NATs have been painfully tested = and > >> documented in publications such as: > >> > >> http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf > >> > >> http://tools.ietf.org/id/draft-jennings-behave-test-results-04.txt > >> > >> https://www.guha.cc/saikat/stunt-results.php? > >> > >> (Ford used to have a page too but it seems to be gone) > >> > >> I have a very open mind to considering better ways to do ICE - but = I > >> need specific suggestions or it is impossible for me to really = think > >> about if the suggestions represent a better path or not. > >> > >> I would love to see more open source ICE code (there is lots = already) > >> - I feel that this is an area where ICE is likely just table stakes > >> and owning an proprietary ICE stack will not turn out to be a > >> competitive advantage. Having open source implementations where the > >> development cost was shared and everyone could get working products > >> to market faster would be an advantage to companies. Clearly I = expect > >> the bulk of ICE implementations to not be open source but I still > >> would be keen on doing what I can to contribute to an open source > >> version as personally I feel that is in the interest of end users, = my > >> employer, and the IETF as a SDO. > >> > >> Cullen > >> > >> > >> > >> On Jul 18, 2007, at 9:12 AM, Dean Willis wrote: > >> > >>> > >>> On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote: > >>> > >>>> Henry Sinnreich skrev: > >>>>> Following some discussions and soul searching, the best > >>>>> approach for > >>>>> ICE-17 for LC would be to _go ahead and make it an experimental > >>>>> RFC_. > >>>>> This would support the development of interoperable > >>>>> implementations, the > >>>>> collection of deployment data and also hopefully open source = code. > >>>>> Though I have full faith in ICE, following the practices that > >>>>> made the > >>>>> IETF successful take precedent here, I believe. > >>>>> This is a change from the attached that I wrote on 7/16/2007. > >>>>> Note: We can only hope the proliferation of SBC in VoIP service > >>>>> provider > >>>>> networks will not make these concerns and ICE for SIP a moot > >>>>> issue, but > >>>>> this is another topic. > >>>> > >>>> Henry, > >>>> > >>>> I don't quite understand why you are requesting a status change = of > >>>> ICE? To me it appears that ICE is almost finished spec. It has > >>>> been implemented, used and feedback has been influencing the > >>>> protocol. It is definitly one of the better examples of current > >>>> IETF work that actually has running code. Sure, the > >>>> implementations may not be fully updated yet to the latest draft > >>>> version. But I think it is safe to say that ICE works in the > >>>> intended core cases. If there are some corner cases where it > >>>> fails, that may be. But that is not information we will have = until > >>>> really large scale deployement or someone makes very extensive > >>>> tests. > >>> > >>> Henry has, I believe, been very consistent in urging the IETF to > >>> have more "running code" experience on every specification (not > >>> just ICE) than our process requires. He has, IIRC, also advocated > >>> changing the process to require running code before publishing an > >>> RFC. He's even suggested at times that one should have running = code > >>> before submitting a protocol draft. > >>> > >>> Another point to consider -- I've known Henry to bark at a tree > >>> with no squirrel in it occasionally, but most of the time he's > >>> pretty reliable, more so than most technology predictors. If he's > >>> worried about ICE, it's probably because he's been talking to > >>> people who are trying to implement it and they're telling him it = is > >>> difficult or that they're having performance or reliability = issues. > >>> I imagine that there are plenty of internal development teams in > >>> various companies that are working on this and not necessarily > >>> bringing their results back to the IETF. After all, if everybody > >>> sees the emperor as fully clothed, they'd be embarrassed to > >>> proclaim otherwise. Of course, I wish all of these developers were > >>> tied into the IETF, but then I'm sure I don't want to see every = ice- > >>> implementor's question on the SIP list. That is why we have a sip- > >>> implementors mailing list, right? > >>> > >>> Personally, I think ICE is the best solution we have. We KNOW of > >>> cases where hole-punching doesn't work, and I think ICE will > >>> produce usable results in most of those cases. But that's just my > >>> personal opinion from reading the specs. I haven't implemented = ICE, > >>> and I haven't used anybody else's implementation. Sure, it's > >>> complex, but that's because the underlying problem is complex -- > >>> there are just too many different behaviors out there in "NAT and > >>> firewall land". Of course, I could be wrong, too. It's happened > >>> before, once or twice ;-). Just how sure are we that we're right > >>> about this? > >>> > >>> Are we designing a "spruce goose" or a practical system? Only > >>> experience will tell us. But some good flight reports from the > >>> prototypes could go a long way towards reassuring us of the > >>> design's utility. > >>> > >>> So far we've had a couple of people report hearsay evidence -- = that > >>> somebody else has an ICE implementation and it works. Any of you > >>> folks have personal experience you can share? Have there been > >>> prototypes exercised at the interop events? > >>> > >>> -- > >>> Dean > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/behave > >> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www1.ietf.org/mailman/listinfo/behave > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:06: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 1IBaOB-0005hy-K2; Thu, 19 Jul 2007 14:06:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaOB-0005hh-2s for mmusic@ietf.org; Thu, 19 Jul 2007 14:06:11 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBaOA-0008W1-Kg for mmusic@ietf.org; Thu, 19 Jul 2007 14:06:11 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:06:03 -0700 From: "David Barrett" To: "'Jiri Kuthan'" , "'Jan Janak'" , "'Juha Heinanen'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore LC for RFC Date: Thu, 19 Jul 2007 11:05:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20070719145334.2EA8B1810C50@mail.iptel.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKFJ51LZhR1yDyQZ+JHkmd4bpt3wAGmvEg X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, 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 Message-Id: > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore > LC for RFC > > So I think that the right course of action is that folks doubting ICE > reliability > make their case (by that I mean specific arguments rather than emotional > debates > about red-colored nails and other hardware). Er, my "specific argument" is "until it's been proven to work, it hasn't been proven to work". It's tautological, but no less true for it. Indeed, if you're *not* doubting ICE, why aren't you? -david _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:08: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 1IBaQZ-0007N0-5v; Thu, 19 Jul 2007 14:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaQW-0007K5-9k for mmusic@ietf.org; Thu, 19 Jul 2007 14:08:36 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBaQU-00060x-S9 for mmusic@ietf.org; Thu, 19 Jul 2007 14:08:36 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 11:08:31 -0700 From: "David Barrett" To: "'Adam Roach'" , "'Frank W. Miller'" Date: Thu, 19 Jul 2007 11:08:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F8577.4080506@estacado.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfKGuJrnaAzFrntQRqf5CHohBEUPQAFKB0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'SIP' , 'Behave WG' , mmusic@ietf.org Subject: [MMUSIC] RE: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Message-Id: > -----Original Message----- > From: Adam Roach [mailto:adam@estacado.net] > Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC > > To be clear: to get this kind of experience (especially as it pertains > to interoperability), you need to have a stable (i.e., frozen) > specification. Internet Drafts simply don't provide an appropriate basis > for the kinds of proof that you and others are demanding. It seems premature to freeze the specification before we've proven that what specified actually works. Indeed, the most successful real-world projects I've participated in worked in the exact opposite manner. -da _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:26: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 1IBahW-0008Qx-OS; Thu, 19 Jul 2007 14:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBahV-0008Jq-Km for mmusic@ietf.org; Thu, 19 Jul 2007 14:26:09 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBahU-0006cU-CT for mmusic@ietf.org; Thu, 19 Jul 2007 14:26:09 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IBahS-0007UC-RP; Thu, 19 Jul 2007 13:26:07 -0500 Message-ID: <469FADDA.8020106@softarmor.com> Date: Thu, 19 Jul 2007 13:30:50 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: David Barrett References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Cullen Jennings' , mmusic@ietf.org Subject: [MMUSIC] Some ICE deployment data before LC for RFC 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 David Barrett wrote in: > But regardless of the metrics, I want somebody who uses it and loves it and > bases their business upon its success to stand up and explain why it's > great. And I want this person to provide real-world data, sampled on a wide > scale, proving that ICE "works" -- by any definition. I issued a plea a few days ago for similar information. I didn't get the sort of detail that I wanted, but I was contacted by a lowly peon at an operator that is using an early ICE implementation for several million minutes of traffic per day and finds it to be satisfactory. The lowly peon strongly suggested that an RFC would be extremely helpful at resolving the one point of dissatisfaction noted -- that everybody seems to have an implementation based on a different version of the draft, resulting in poor interop. Unfortunately, said operator has neither publicly confirmed nor denied this position, nor provided time and performance study numbers. -- Dean _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:30: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 1IBalq-0003RK-Jq; Thu, 19 Jul 2007 14:30:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaln-0003Q7-9C; Thu, 19 Jul 2007 14:30:35 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBalm-0000zd-Sn; Thu, 19 Jul 2007 14:30:35 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JIUSek015558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 13:30:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FADC9.3000006@nostrum.com> Date: Thu, 19 Jul 2007 13:30:33 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: David Barrett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'SIP' , 'Behave WG' , 'Adam Roach' , "'Frank W. Miller'" , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 7/19/07 1:08 PM, David Barrett wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@estacado.net] >> Subject: Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> To be clear: to get this kind of experience (especially as it pertains >> to interoperability), you need to have a stable (i.e., frozen) >> specification. Internet Drafts simply don't provide an appropriate basis >> for the kinds of proof that you and others are demanding. >> > > It seems premature to freeze the specification before we've proven that what > specified actually works. Indeed, the most successful real-world projects > I've participated in worked in the exact opposite manner. > In that case, you're arguing with the IETF standards process, and have decided to beat on ICE as a proxy whipping boy for reasons that have no technical basis in ICE itself. The current process surrounding RFC publication is detailed in RFC 2026. Section 4.1 details the process you're misunderstanding. It's short. You should read it. If you're up to it, RFC 3774 and RFC 3844 also provide some useful background on the work that has been done in this area recently. Concerns about IETF RFC publication process in general -- and that's what you're arguing about here, not ICE itself -- are best addressed to the IETF-general mailing list and/or the IESG itself (as the conclusion of the problem WG was that issues surrounding the standards process were to be handed back to the IESG). /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:36: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 1IBarl-00017c-WB; Thu, 19 Jul 2007 14:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBarl-00017K-4o for mmusic@ietf.org; Thu, 19 Jul 2007 14:36:45 -0400 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBark-0006ue-8S for mmusic@ietf.org; Thu, 19 Jul 2007 14:36:45 -0400 Received: (qmail 88534 invoked by uid 60001); 19 Jul 2007 18:36:43 -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=bigYgUwI+cfV9L3tv5m93sHHFpmTZCtbqsSohA/prvWyYodznXDGIjyowcGpskBYIz9UxC7xlm1TpfPSngm0CyH59G5+ImcfuE+m+VGxJfg5US/CTXNCF2c9NwAHuKIJHuHx7bEKzKzuaak1si9og0gtFUmJjpAG1CBYUevbZR4=; X-YMail-OSG: QjmRvcwVM1lWWTrYcJAAjxuVPSWN8nP_s5NpjThwTRjFWiaIk_ocu.mBDGjIkj_X0D3lm4H.lw-- Received: from [209.172.74.45] by web33304.mail.mud.yahoo.com via HTTP; Thu, 19 Jul 2007 11:36:43 PDT Date: Thu, 19 Jul 2007 11:36:43 -0700 (PDT) From: Pyda Srisuresh To: Magnus Westerlund In-Reply-To: <469F1CEA.1040101@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <383711.88528.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Pyda Srisuresh , behave@ietf.org, "Frank W. Miller" , mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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, The discussion thread started on the BEHAVE list. I believe, My comments are also relevant to BEHAVE list. SO, I am including BEHAVE list to this thread. Please see my comments inline below. Thanks. regards, suresh --- Magnus Westerlund wrote: > Dropping all lists but MMUSIC! > > Pyda Srisuresh skrev: > > Thanks to Henry and Frank for so eloquently articulating this. > > > > As both Henry and Frank mentioned, I fully support standardizing on HOLE > > PUNCHING TECHNIQUE and leveraging the IETF’s considerable influence to > force > > NAT vendors to migrate towards implementations that are friendly to Hole > > Punching and the Application developers to design applications using the > hole > > punching techniques. That should be the FIRST order of priority. > > > > Yet, what is happening in BEHAVE WG is the other way around. Some people > have > > put their weight so heavily in favor of ICE that they asked to drop the > work on > > hole punching technique as WG item. THIS IS WRONG. I no longer see "NAT > > Traveral application design guidelines" as BEHAVE WG milestone. > > > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING > TECHNIQUES > > to move forward as a WG item? > > I would like to remind people about a few things. ICE was request to > become a MMUSIC WG item in Vienna, that is FOUR years ago! The people > present supported that. During these years ICE has been rebaked several > times. People have provided input about a number of things; traversal > cases that didn't work, different forms of complexity, signalling usage. > > During these 4 years anyone have had the possibility to influence the > process, including standing up saying that we should forget about the > maximum reliability for the sake of simplicity. But the consensus in > this discussion has remained that reliabilty is important. And I also > think the changes has shown that one has tried all the tricks that has > been thought of try to reduce the complexity of ICE. But as I think most > of you agree on, NAT traversal is problematic and simple solution > doesn't always work. We are today at state where we don't know know how > to make things simpler without sacrificing functionality. > > There also has been discussion about if there should be multiple > solutions etc. But, to my knowledge the consensus also there has been > that one solution is the way to go. > [suresh] I have not been part of the discussion pertaining to the merit of multiple solutions vs single soultions. This may have been discussed in the context of SIP and NAT traversal. So, I cant comment on this. But, let me reiterate that HOLE PUNCHING TECHNIQUES have been around longer than ICE. The techniques are generic and applicable to application traversal in general. Kegel's work on UDP is the first published work on UDP hole punching. USENIX paper by Bryan, Kegel and myself is the first work on TCP hole punching. ford-behave-app draft is the first draft that I know if that describes the BCP design practicies for P2P applications to traverse NATs. > So Suresh, you and everyone else as participants in the IETF is > responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG > item. [suresh] Magnus - I dont know what you are talking about. How do you mean I am responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The ford-behave-app draft has been around for many years since the inception of BEHAVE. Last I checked, The application milestone is no longer on BEHVAE charter. I certainly am not responsible for removign the milestone. > The IETF has run its consensus process and it is now close to > completing and producing a ready specification. It may or may not have > been looking different if you had provided the details about how such a > solution would look. And worked to get consensus that it was what the > IETF wanted. > > Complaining about the general design and tradeoffs after two WG last > calls and more than four years of development isn't productive. You all > contributed to the consensus process that has leads to this state. At > this point only serious bugs in the solution should be forcing any > backtracking. Revisiting our choices at this point is wasting time > unless there are very strong evidence that the choices made was wrong. > [suresh] Magnus - I have not been part of the consensus for ICE. However, I do know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or the TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING as normative reference. This iS WRONG. I believe, the ICE drafts should refer the prior work (kegel work on UDP hole punching, USENIX paper for TCP hole punching and ford-behave-app draft for application traversal design) on which the ICE work is based. On the one hand, IETF (IESG) has been adamant about the standard level of the normative references for a proposes standard. Yet, it is ironic that when HOLE PUNCHING is normative to the design of ICE, the IETF is not allowing the HOLE PUNCHING work to be standardized. Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application traversal identified in draft-ford-behave-app draft to move forward as a BCP WG item? regards, suresh > I do understand that Henry is arguing for that more experience should be > gathered. But, I am not personally agreeing that we need more to publish > this as an proposed standard. There has been implementations, there have > been tests, there is even deployement as I understand it for earlier > versions. I think this all indicate that the general principle does > work. And it is great that we are seeing implementations being updated > to follow the latest spec, that will help confirm that things do work. > But, to me the ICE specification is the most reviewed, worked on > specification that I personally has been involved in within the IETF. We > are approaching fast the point where more baking will not make any > improvements worth wathing for. If there are some minor error are found > down the road, we can update the RFC at that point. But I don't see that > adding more delay or make it jump through more hops will be beneficial > at all. It only increases the time to complete a specification I think > the market really want. > > > Cheers > > Magnus Westerlund > (Within his individual hat because this is not my WG) > > > 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 Jul 19 14:37: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 1IBas6-0001JQ-7O; Thu, 19 Jul 2007 14:37:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBas4-0001Hw-WA; Thu, 19 Jul 2007 14:37:05 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBas4-0001DR-KS; Thu, 19 Jul 2007 14:37:04 -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 1IBary-0005o8-2q; Thu, 19 Jul 2007 14:36:59 -0400 In-Reply-To: <469F8577.4080506@estacado.net> References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F8577.4080506@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <906B914C-31A5-43E9-99B5-424899262C7B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 19 Jul 2007 14:37:17 -0400 To: Adam Roach X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: SIP , Behave WG , "Frank W. Miller" , IETF MMUSIC WG , David Barrett Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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-Jul-07, at 11:38 , Adam Roach wrote: > On 7/19/07 10:19 AM, Frank W. Miller wrote: >> FM: While I applaud the time and effort that the large vendors have >> obviously invested in this, this is a qualitative statement. >> Perhaps Cisco >> and/or Microsoft have empirical data they would be willing to >> share about >> robustness and performance? > > That's the kind of data you get between "proposed standard" and > "draft standard" -- not *prior* to publication. I'm not sure why > there's so much noise about setting the bar much, much higher for > ICE than we do for other IETF proposals. Just to play the other side of the fence ... In theory, RFCs advance from "proposed standard" to "draft standard" to "full standard". In practice, this rarely happens. In practice, once an RFC is published, it is either accepted and becomes a de-facto standard, or is ignored. Rarely is it revised and advanced along the standards track. And it is often difficult to discover which status (de-facto standard or ignored) a particular RFC actually has. Look at SIP, for example. It is still at "proposed standard" and will likely stay there for a long time. What Henry, David, and Frank want is some evidence that actually works (and thus will become the de-facto standard) before publishing the document as an RFC. - Philip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 14:39: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 1IBauS-0002BR-33; Thu, 19 Jul 2007 14:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBauO-0002AV-Er for mmusic@ietf.org; Thu, 19 Jul 2007 14:39:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBauM-0006xb-Px for mmusic@ietf.org; Thu, 19 Jul 2007 14:39:28 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IBauL-0007XE-3J; Thu, 19 Jul 2007 13:39:25 -0500 Message-ID: <469FB0F9.9040703@softarmor.com> Date: Thu, 19 Jul 2007 13:44:09 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F865A.204@nostrum.com> <469F907C.90907@jabber.org> In-Reply-To: <469F907C.90907@jabber.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Peter Saint-Andre wrote: > Adam Roach wrote: >> On 7/19/07 10:19 AM, Frank W. Miller wrote: >>> FM: While I applaud the time and effort that the large vendors have >>> obviously invested in this, this is a qualitative statement. Perhaps >>> Cisco >>> and/or Microsoft have empirical data they would be willing to share about >>> robustness and performance? >> That's the kind of data you get between "proposed standard" and "draft >> standard" -- not *prior* to publication. I'm not sure why there's so >> much noise about setting the bar much, much higher for ICE than we do >> for other IETF proposals. > > Yes, it's a puzzle. Perhaps someone could elaborate? There is a school of thought (which the person who opened this debate has consistently supported) that says we should have running code to accompany any protocol draft, and that the process of RFC 2026 is broken because almost nothing advances beyond proposed standard. SIP, as an example, is on its second rev as a proposed standard, and although we've started work to advance it to draft, my money is not on that happening in my productive lifetime. And, as we all know, there is ongoing work to replace the process of 2026, and its most commonly anticipated result is likely to be the elimination of at least one level of standards-track status. Since it takes two years of WG effort, most of a year of IESG effort, and another year of RFC Editor effort to cough up an RFC, we end up with a very high need to get the RFC right the first time. Personally, I'm wondering if a process like 3GPP's, where we could revise each RFC every 90 days or so, might not have some major advantages over the IETF process. -- Dean _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 15:34: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 1IBblP-0003lY-KA; Thu, 19 Jul 2007 15:34:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBblL-0003Ue-Bv for mmusic@ietf.org; Thu, 19 Jul 2007 15:34:11 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBblK-0002m9-Ur for mmusic@ietf.org; Thu, 19 Jul 2007 15:34:11 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6JJY7F05613; Thu, 19 Jul 2007 19:34:08 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: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Thu, 19 Jul 2007 14:34:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115AA565D@zrc2hxm2.corp.nortel.com> In-Reply-To: <469FB0F9.9040703@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfKNCvopuHceQsvQgu117se+J00xQABqaSg References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F865A.204@nostrum.com> <469F907C.90907@jabber.org> <469FB0F9.9040703@softarmor.com> From: "Brian Stucker" To: "Dean Willis" 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 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 [ SNIP ] >=20 > Personally, I'm wondering if a process like 3GPP's, where we=20 > could revise each RFC every 90 days or so, might not have=20 > some major advantages over the IETF process. >=20 You can do that... Just issue a new WG draft every 90 days or so, and never promote something to RFC status. Hey wait, isn't that what we've been doing? :) ICE-17: July 2007 ICE-16: June 2007 ICE-15: March 2007 ICE-14: March 2007 ICE-13: January 2007 ICE-12: October 2006 ICE-11: October 2006 ICE-10: August 2006 ICE-09: June 2006 ICE-08: March 2006 ICE-07: March 2006 ... I'd put the GRUU revisions up there, but I don't want to be accused of cross-posting. :P Regards, Brian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 15:37: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 1IBbov-0008Sj-EU; Thu, 19 Jul 2007 15:37:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbot-0008Qc-Uy for mmusic@ietf.org; Thu, 19 Jul 2007 15:37:52 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbot-0002wx-Gt for mmusic@ietf.org; Thu, 19 Jul 2007 15:37:51 -0400 Received: from orthrus.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6JJboAl019091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2007 14:37:51 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <469FBD94.9040309@nostrum.com> Date: Thu, 19 Jul 2007 14:37:56 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 Followup-To: IETF,General, To: Dean Willis Subject: Standards Process (was Re: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC) References: <20070719150508.14D4D1C8029@smtpauth01.csee.onr.siteprotect.com> <469F865A.204@nostrum.com> <469F907C.90907@jabber.org> <469FB0F9.9040703@softarmor.com> In-Reply-To: <469FB0F9.9040703@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) 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 Reply-To: IETF General List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On 7/19/07 1:44 PM, Dean Willis wrote: > There is a school of thought (which the person who opened this debate > has consistently supported) that says we should have running code to > accompany any protocol draft, and that the process of RFC 2026 is broken > because almost nothing advances beyond proposed standard. > > SIP, as an example, is on its second rev as a proposed standard, and > although we've started work to advance it to draft, my money is not on > that happening in my productive lifetime. > > And, as we all know, there is ongoing work to replace the process of > 2026, and its most commonly anticipated result is likely to be the > elimination of at least one level of standards-track status. > But the process currently stands at what is documented in 2026. Perhaps it's broken and needs updating. There are places to make that point, but a quick glance at MMUSIC's charter leads me to believe that this isn't one of them. In the interim, _selective_ enforcement of new and undocumented process requirements as a means to disrupt publication of a document is, at the very least, inequitable. (And even if intentions are other than I imply by that statement, _capricious_ enforcement of new and undocumented process requirements is equally problematic -- "Standards Calvinball [1]" may sound fun at first, but you'll lose workers if the rules are too amorphous to know whether their work is actually going anywhere). I'm not arguing either way whether the IETF publication process needs to be changed -- I'm arguing that if and when it changes, it needs to be the result of a broad community review, it needs to be documented, and it needs to be applied uniformly. And this is far more than an MMUSIC or RAI issue. This is an IETF issue. Followups to IETF-general, please. /a [1] http://www.geocities.com/SoHo/Nook/2990/cb_rules.htm _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 15:45: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 1IBbwF-0004x2-Pt; Thu, 19 Jul 2007 15:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbwE-0004wx-KB for mmusic@ietf.org; Thu, 19 Jul 2007 15:45:26 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbwD-0000RS-AP for mmusic@ietf.org; Thu, 19 Jul 2007 15:45:26 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IBbwC-0007bM-Pi for mmusic@ietf.org; Thu, 19 Jul 2007 14:45:24 -0500 Message-ID: <469FC071.3040702@softarmor.com> Date: Thu, 19 Jul 2007 14:50:09 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: mmusic@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [MMUSIC] [Fwd: Please confirm (conf#02fa898d1296c0583f0e82a8d54500e8)] 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 hate it when IETFers use this stuff. No, I'm not sending a confirmation message. Read it on the list. -------- Original Message -------- Subject: Please confirm (conf#02fa898d1296c0583f0e82a8d54500e8) Date: Thu, 19 Jul 2007 13:45:46 CDT From: Peter Saint-Andre To: dean.willis@softarmor.com << IMPORTANT INFORMATION! >> This is an automated message. The message you sent (attached below) requires confirmation before it can be delivered. To confirm that you sent the message below, just hit the "R"eply button and send this message back (you don't need to edit anything). Once this is done, no more confirmations will be necessary. This email account is protected by: Active Spam Killer (ASK) V2.5.2 - (C) 2001-2004 by Marco Paganini For more information visit http://www.paganini.net/ask --- Original Message Follows --- From: Dean Willis To: Peter Saint-Andre Subject: Re: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before (Original message truncated) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 17: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 1IBdKk-00014z-NA; Thu, 19 Jul 2007 17:14:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0000tc-Pm; Thu, 19 Jul 2007 17:14:46 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0005RE-9s; Thu, 19 Jul 2007 17:14:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 14:14:38 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLEQWs013301; Thu, 19 Jul 2007 14:14:27 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLCUI9025470; Thu, 19 Jul 2007 14:12:30 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:14:25 -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 Date: Thu, 19 Jul 2007 14:14:21 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDCA6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfKSR+4bsdL7cvpRK+b5k7AGN+GsQ== From: "Henry Sinnreich" To: , , , , X-OriginalArrivalTime: 19 Jul 2007 21:14:25.0847 (UTC) FILETIME=[C9168C70:01C7CA49] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Cullen Jennings , Magnus Westerlund , jon.peterson@neustar.biz Subject: [MMUSIC] Re: ICE deployment data before LC for RFC 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 apology for the duplicate postings.=20 Having initiated this ample discussion about how to proceed with ICE-17, it seems the following have emerged: ICE-17 is an excellent document (bravo authors and contributors) and can hardly get better at present. The technical points discussed cannot change this fact either way. Ironically, the defense of ICE-17 on procedural grounds makes even less sense, since the culprit is not ICE-17, but the fact that present IETF procedures do not make a clear enough distinction that everyone can understand between I-D categories, such as: * Concept memos; see the torrent in the P2PSIP WG * Protocol standard agreements, such as for SIP * Technology solutions such as ICE-17 or hole punching for NAT traversal * I-Ds to support a business model (excuse me; I will not go there...) Sorry to repeat: Process and consensus in meetings have nothing to do with how good a technology may be. Only measurements and proof will do. How does the IETF support the proof for a technology? (Yes, I have seen all those quotes). Please remember that proving a technology also costs money. This is the reason why I trust more technologies coming out of funded R&D, especially from University research. Vendors of technology may be less likely to share such information. Question: Is a standards organization the best place to develop and promote new technology such as for NAT traversal? (all those p2p companies and Skype did not think so...) Also, be prepared, SBC traversal may come next. In conclusion, there is nothing wrong with the ICE-17 paper IMHO, but rather the IETF processes are either not satisfactory or not well understood by folks like me who avoid reading process documents longer than one web page :-)=20 I have taken therefore the liberty to copy as Adam Roach has suggested. Thanks,=20 Henry Sinnreich _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 19 22:54: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 1IBidH-0008Gn-Bk; Thu, 19 Jul 2007 22:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBidG-0008Gi-H7 for mmusic@ietf.org; Thu, 19 Jul 2007 22:54:18 -0400 Received: from [211.189.53.2] (helo=kor1corpmail01.mediator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBidE-0002aT-S2 for mmusic@ietf.org; Thu, 19 Jul 2007 22:54:18 -0400 Subject: [MMUSIC] draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt - section 7.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 11:54:14 +0900 Message-ID: In-Reply-To: <469E0A9E.1070505@ericsson.com> References: <469E0A9E.1070505@ericsson.com> From: "Jaehwan Kim" To: "Magnus Westerlund" , "mmusic (E-mail)" , =?iso-8859-1?Q?=22Per_Fr=F6jdh_=28KI/EAB=29=22?= X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Hi Magnus, The section 7.7, "RTSP URI extension" in this draft looks like saying an = extension of RTSP request URI, while I understand that 5.3.3.1 of 3GPP = TS26.234 just defines a special format of SDP a=3Dcontrol URI for 3GPP = service.=20 Therefore, the possible revise would be: --- 7.7. SDP a=3Dcontrol URI format In 3GPP RTSP streaming session, a=3Dcontrol URI must have a track ID = information. The value of a=3Dcontrol URI, stream identifiers must be = expressed using the following syntax: streamIdentifier =3D "=3D" stream-id-token =3D 1*alpha stream-id =3D 1*digit This stream-id must be equal to the value of track-ID field in the track = header (tkhd) box associated with the media track of "3GP" file format = [PSS-3GP].=20 When hinted track is used, embedded SDP must also follow this rule. In 3GPP, streaming-server profile of 3GP format defines hinted track. (See 5.3.3.1 of [PSS-234]). --- In generic RTSP streaming, we could use a free format, e.g. = a=3Dcontrol:audio or a=3Dcontrol:video. But in 3GPP, a=3Dcontrol must = contain trackID or streamID with '=3D'. We understand this is the main = point of this clause.=20 Cheers, Jaehwan Vidiator -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, July 18, 2007 9:42 PM To: mmusic (E-mail); "Per Fr=F6jdh (KI/EAB)" Subject: [MMUSIC] [Fwd: = I-DACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt] Hi, We have finally managed to update the draft to take care of the comments = raised by Jean-Francois. We also have addressed the issue with meeting=20 the registration requirements for SDP "proto" identifiers which requires = an RFC to document the definition. A normative definition of the=20 protocol identifiers are now included in this document. Please provide any comments before the 27th of August. We plan to=20 request publication if no comments has been received by then. 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 Jul 20 06:24: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 1IBpfD-00081l-Km; Fri, 20 Jul 2007 06:24:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpfC-00081X-3r for mmusic@ietf.org; Fri, 20 Jul 2007 06:24:46 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBpfB-0006pF-86 for mmusic@ietf.org; Fri, 20 Jul 2007 06:24:46 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l6KAOhmQ031412; Fri, 20 Jul 2007 12:24:43 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6KAOeSF006540; Fri, 20 Jul 2007 12:24:42 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 12:24: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] SDPCapNeg-06: Transport capabilites and RTP payload types Date: Fri, 20 Jul 2007 12:24:35 +0200 Message-ID: In-Reply-To: <469F9B92.3060906@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types Thread-Index: AcfKKBTLhW7ey273SmGlThWuBfr3KwAh9oww References: <469F9B92.3060906@ericsson.com> From: "Stach, Thomas" To: "Magnus Westerlund" , "mmusic (E-mail)" X-OriginalArrivalTime: 20 Jul 2007 10:24:40.0708 (UTC) FILETIME=[2E8C2C40:01C7CAB8] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070720122443-4AFBFBB0-7473F6C2/0-0/0-15 X-purgate-size: 5416/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Magnus, I really appreciate your comment If I recall correctly, the design team reached consensus that the negotiation for attribute in the core spec=20 provides a poor man's media capability negotiation.=20 It was not the goal to cover all corner case. Nevertheless your comment points to an oversight for the a=3Dtcap attribute.=20 More inline. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Thursday, July 19, 2007 7:13 PM > To: mmusic (E-mail) > Subject: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP=20 > payload types >=20 > Hi, >=20 > I have finally read the SDP capapbility draft in sufficient detail to=20 > think I understand it mostly. There is likely some details=20 > that I have=20 > gotten wrong. But I have found some issues that I need to raise for=20 > discussion. I will split this into separate emails for each topic. >=20 > I think the handling of the transport capabilites have to little=20 > functionality. There is need for specifying which RTP payload=20 > types that=20 > apply to which transport capabilities. I will list some=20 > usages of this=20 > that doesn't seem to work correctly without it or bloody ugly hacks. >=20 > 1. Usage of RTP retransmission (RFC 4588) using payload type=20 > multiplexing. In this case the RTP retransmission payload only can be=20 > used in cases when the session uses a profile that has AVPF=20 > functionality. If one offers both AVP and AVPF with CAPNEG=20 > then one gets=20 > at least one additional RTP payload type for the AVPF cases. If I understand correctly you want to be able to negotiate=20 an offer for the actual configuration (RTP/AVP, one payload type) v=3D0 o=3D- 25678 753849 IN IP4 192.0.2.1 s=3D c=3DIN IP4 192.0.2.1 t=3D0 0 --> m=3Dvideo 49170 RTP/AVP 96 <-- one PT a=3Drtpmap:96 MP4V-ES/90000 a=3Dfmtp:96 profile-level-id=3D8; / config=3D01010000012000884006682C2090A21F and for the potential configuration (RTP/AVPF, two payload types) v=3D0 o=3D- 25678 753849 IN IP4 192.0.2.1 s=3D c=3DIN IP4 192.0.2.1 t=3D0 0 --> m=3Dvideo 49170 RTP/AVPF 96 97 <-- two PTs a=3Dfmtp:96 profile-level-id=3D8; / config=3D01010000012000884006682C2090A21F a=3Drtcp-fb:96 nack a=3Drtpmap:97 rtx/90000 a=3Dfmtp:97 apt=3D96;rtx-time=3D3000 and the core spec does not provide for using a different number of PTs in the actual/potential configurations. >=20 > 2. Usage of paylaod types that only make sense over particular=20 > transport. For example if one requires RTP/AVP/TCP for a particular=20 > paylaod type to be usable due to reliability requirements. yes, this can result in a similar problem as above. >=20 > As I see it this can be only solved by what I consider a=20 > hack. Which is=20 > to overdefine a number of payload types that one doesn't=20 > intended to use=20 > to provide sufficient number for other potential=20 > configurations. And I=20 > think you need to define them, because leaving them undefined=20 > would to=20 > me be against current SDP rules. >=20 > I think this is a hack for several reasons. >=20 > A. It doesn't clearly define which payload types that are=20 > intended to be=20 > used in a specific transport. >=20 > B. It forces one to overwrite the RTP payload types, always.=20 > Despite the=20 > issues with media delivery prior to receiving answer or=20 > having performed=20 > the second round of offer/answer >=20 > C. It prevents this mechanism to in the future be upgraded in a=20 > reasonable way with media cability negotiation. See separate=20 > email for=20 > discussion. I see the extensibily problem differently. As a first step the core spec should disallow different numbers of PTs and=20 the media capability negotiation should cope with it.=20 >=20 > I would recommend that one seriously consider using explicit=20 > declaration=20 > of the payload type used for each transport in the tcap attribute. As the media capability negotiation already extends the definition of the a=3Dpcfg attribute, it could also e.g. extend the a=3Dtcap attribute to allow for inclusion = of payload types as you propose. However, the ABNF for a=3Dtcap does currently not allow for = extensibility. My proposal would be to provide for such extensibility in the core and tackle the problem within=20 the media capability negotiation. Regards Thomas >=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 > ---------------------------------------------------------------------- >=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 Fri Jul 20 06:24: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 1IBpfI-0008CG-Uu; Fri, 20 Jul 2007 06:24:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpfH-000893-NG for mmusic@ietf.org; Fri, 20 Jul 2007 06:24:51 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBpfG-0006pL-W5 for mmusic@ietf.org; Fri, 20 Jul 2007 06:24:51 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id l6KAOjK5010674; Fri, 20 Jul 2007 12:24:45 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6KAOhgl008353; Fri, 20 Jul 2007 12:24:44 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 12:24: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] SDPCapNeg-06: Session level coordintation betweenpotential configurations Date: Fri, 20 Jul 2007 12:24:38 +0200 Message-ID: In-Reply-To: <469F9BCD.8070905@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Session level coordintation betweenpotential configurations Thread-Index: AcfKKEU9T0C5ViaPQWiwuFHiXLvKUwAjRmCA References: <469F9BCD.8070905@ericsson.com> From: "Stach, Thomas" To: "Magnus Westerlund" , "mmusic (E-mail)" X-OriginalArrivalTime: 20 Jul 2007 10:24:43.0783 (UTC) FILETIME=[30616170:01C7CAB8] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070720122445-46D9EBB0-34B9290E/0-0/0-15 X-purgate-size: 3301/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Magnus, more inline.=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Thursday, July 19, 2007 7:14 PM > To: mmusic (E-mail) > Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation=20 > betweenpotential configurations >=20 > The draft comes to the conclusion that there is no real need for=20 > coordintion between different media descriptions and their potential=20 > configurations. I think that is wrong for several reasons: >=20 > 1. I would start with referening once more to a defined usage in RFC=20 > 4588 (RTP Retransmission). In the case of desire to use session=20 > multiplexing for the retransmission one would only like to use that=20 > under the constraint that one already uses AVPF in the primary=20 > transmission session. Thus one would like to make the following offer: >=20 > Primary session: AVP, potential configuration 1: AVPF with NACK >=20 > Retransmission session: Only used in case primary session selects=20 > potential configuration 1. In other words this means an actual configuration with one m-line and=20 a potential configuration with two m-lines. Would it help if the problem is described in the core spec, but not solved? My intention is to keep the core spec as simple as possible,=20 but to state its restrictions. >=20 > 2. Allow for media capability negotiation. As I see it when=20 > moving into=20 > a media capability negotiation extension one will very much like to=20 > present cases where there are set of media configurations. That may=20 > include additional media streams needing their own media=20 > descriptions,=20 > i.e. RTP sessions / or other media transport (MSRP). One=20 > would in other=20 > words like to express capabilites like. Lets do (Audio, video=20 > and Text),=20 > or (Audio, video and MSRP) or (Audio and Text) or (Audio and MSRP)=20 > depending on peers capabilities. Without the functionality to make=20 > higher level bindings between potential configurations into different=20 > sets that will not work. Here I think we must decide how far we want go with media capability negotiation. >=20 > Unfortunately the above has one very frightening conclusion,=20 > we need to=20 > have possibility to do potential configurations for media=20 > descriptions=20 > that has no match in the actual configuration. I'm not sure how frightening that is from specification perspective (e.g. an a=3Dmcap for additional m-lines could do),=20 but it surely is for an implementor. Regards Thomas >=20 >=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 > ---------------------------------------------------------------------- >=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 Fri Jul 20 06:24: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 1IBpfK-0008DZ-Ae; Fri, 20 Jul 2007 06:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBpfJ-0008DM-2v for mmusic@ietf.org; Fri, 20 Jul 2007 06:24:53 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBpfH-00038r-ES for mmusic@ietf.org; Fri, 20 Jul 2007 06:24:53 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id l6KAOnY1031529; Fri, 20 Jul 2007 12:24:49 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6KAOmrt008384; Fri, 20 Jul 2007 12:24:49 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 12:24:49 +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] SDPCapNeg-06: Lack of bandwidth capabilities Date: Fri, 20 Jul 2007 12:24:44 +0200 Message-ID: In-Reply-To: <469F9BB7.9040709@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities Thread-Index: AcfKKCL8uH3iYqhaQd2YgkXqKWY90gAikPqw References: <469F9BB7.9040709@ericsson.com> From: "Stach, Thomas" To: "Magnus Westerlund" , "mmusic (E-mail)" X-OriginalArrivalTime: 20 Jul 2007 10:24:49.0346 (UTC) FILETIME=[33B23A20:01C7CAB8] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070720122449-4AFBEBB0-7C19EC86/0-0/0-15 X-purgate-size: 2004/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Magnus, I agree that this is neither covered in the core spec nor in the media capability extension. Could that be left for an extension (either its own or media capabilities) in order to keep the core spec simpler? Regards Thomas=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Thursday, July 19, 2007 7:13 PM > To: mmusic (E-mail) > Subject: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities >=20 > The current proposal total failes to discuss the bandwidth=20 > parameter in=20 > SDP. This is a serious shortcomming and will result in real=20 > issues for=20 > the profiles. Different profiles and usages will have different=20 > bandwidth parameters. Although media bandwidth may different for=20 > different potential configurations I think the major issue=20 > exist for the=20 > RR and RS attribute which really makes sense to configure differently=20 > for different profiles. For example AVPF with some feedback=20 > may require=20 > much more RTCP bandwidth than AVP. And in case one uses the TFRC=20 > addition one may have need for yet another configuration.=20 > Thus there is=20 > need to be able to connect different bandwidth configurations with=20 > specific potential configurations. >=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 > ---------------------------------------------------------------------- >=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 Fri Jul 20 07:43: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 1IBqta-0002l8-KE; Fri, 20 Jul 2007 07:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqtV-0002kJ-Io; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqtU-0004vw-2E; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49215) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IBqtQ-0003El-Cr; Fri, 20 Jul 2007 12:43:32 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Date: Fri, 20 Jul 2007 12:43:30 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Cullen Jennings , Jean-Francois Mule , Joerg Ott Subject: [MMUSIC] Progressing ICE 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 note is sent to MMUSIC, with bcc to BEHAVE, SIP, and P2PSIP =20 since the discussion has included those groups. Replies to MMUSIC =20 only please, as ICE is an MMUSIC working group draft] The MMUSIC chairs have reviewed the mailing list discussion =20 pertaining to ICE over the last few days. While we agree that further =20= implementation experience and publication of deployment results would =20= be valuable, as it is for any new protocol, we do not believe this =20 sufficient cause to revisit the consensus to request publication of =20 draft-ietf-mmusic-ice-17.txt as a Proposed Standard. The characteristics of Proposed Standard specifications are described =20= in RFC 2026 section 4.1.1 as follows: > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has =20 > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be =20 > useful and > necessary (and timely) even with known technical omissions. > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. Our judgement is that ICE meets these requirements, and that there is =20= general working group consensus to request publication. Accordingly, =20 our intention is to proceed as we previously announced, and request =20 that ICE be published as a Proposed Standard RFC. Colin Perkins, J=F6rg Ott, and Jean-Fran=E7ois Mul=E9 MMUSIC chairs _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 20 09:24: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 1IBsSz-0005YH-4R; Fri, 20 Jul 2007 09:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsSx-0005X2-Th for mmusic@ietf.org; Fri, 20 Jul 2007 09:24:19 -0400 Received: from hm398-2.locaweb.com.br ([200.234.205.170] helo=hm398.locaweb.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBsSv-0006yq-PJ for mmusic@ietf.org; Fri, 20 Jul 2007 09:24:19 -0400 Received: (qmail 12890 invoked from network); 20 Jul 2007 13:24:13 -0000 Received: from unknown (10.1.10.10) by hm398.locaweb.com.br with QMQP; 20 Jul 2007 13:24:13 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.17.146.249) by hm10.locaweb.com.br with SMTP; 20 Jul 2007 13:24:18 -0000 Message-ID: <46A0B77B.8030404@comunip.com.br> Date: Fri, 20 Jul 2007 10:24:11 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-16 possible issue References: <4696611F.4060808@comunip.com.br> <46978692.7040106@cisco.com> In-Reply-To: <46978692.7040106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Just moving Section 4.1.2 down does not do the work, as there are not any defined order between the native candidates during Gathering. Is there any reason to not check just the base IP address and the mapped IP address? I though something like "a candidate must have the same foundation ID when all of the following are true: they are of the same type, their bases have the same IP, for server and reflexive candidates, the transport address have the same IP". Is there any known issue related to this solution? -- Guilherme Balena Versiani. Jonathan Rosenberg wrote: > What you describe is normal behavior of the algorithm. There is no way > for ICE to know whether these STUN servers are really 'the same' and > that their network paths towards the NAT are identical. > > The problem here is that, when you eliminated the redundant > candidates, you ended up eliminating one from one STUN server, and one > from the other. In fact you should have eliminated both of them from > the same STUN server. > > THe spec is currently silent on WHICH candidates to eliminate when > they are redundant. That is because the current redundancy elimination > step happens prior to prioritization. > > I suggest a simple fix is that I merely move Section 4.1.2 down after > prioriziation, and then suggest that the least preferred candidate is > eliminated. > > -Jonathan R. > > > Guilherme Balena Versiani wrote: >> The section "4.1.1.3. Eliminating Redundant Candidates" states that >> "a candidate is redundant if its transport address equals another >> candidate, and its base equals the base of that other candidate". >> >> The next section "4.1.1.4. Computing Foundations" then states that >> "two candidates MUST have the same foundation ID when all of the >> following are true: they are of the same type, their bases have the >> same IP, for server and reflexive candidates, the STUN servers used >> to obtain them have the same IP address". >> >> Be the following scenario: >> >> - There are two STUN servers configured by an agent A >> (200.100.10.50:3478 and 200.100.10.51:3478); >> - The agent A have two components (RTP and RTCP); >> - The gathering process obtain the following addresses (in order): >> * component=1, transport=10.0.0.1:5004/udp, type=local; >> * component=2, transport=10.0.0.1:5005/udp, type=local; >> * component=2, transport=200.100.10.1:5005/udp, type=srflx, >> stunserver=200.100.10.50:3478; >> * component=1, transport=200.100.10.1:5004/udp, type=srflx, >> stunserver=200.100.10.51:3478; >> * component=1, transport=200.100.10.1:5004/udp, type=srflx, >> stunserver=200.100.10.50:3478; >> * component=2, transport=200.100.10.1:5005/udp, type=srflx, >> stunserver=200.100.10.51:3478; >> >> Following the algorithm described in the section "4.1.1.3", we must >> eliminate two of the server reflexive candidates as they have the >> same mapped-address. So, by removing the redundant candidates in >> order (forward comparison), we get the new candidate list as follows: >> >> * component=1, transport=10.0.0.1:5004/udp, type=local; >> * component=2, transport=10.0.0.1:5005/udp, type=local; >> * component=2, transport=200.100.10.1:5005/udp, type=srflx, >> stunserver=200.100.10.50:3478; >> * component=1, transport=200.100.10.1:5004/udp, type=srflx, >> stunserver=200.100.10.51:3478; >> >> Note that the two server reflexive candidates was obtained by two >> different STUN servers. Now I must compute the foundations, then I >> would get: >> >> * foundation=1, component=1, transport=10.0.0.1:5004/udp, type=local; >> * foundation=1, component=2, transport=10.0.0.1:5005/udp, type=local; >> * foundation=2, component=2, transport=200.100.10.1:5005/udp, >> type=srflx, stunserver=200.100.10.50:3478; >> * foundation=3, component=1, transport=200.100.10.1:5004/udp, >> type=srflx, stunserver=200.100.10.51:3478; >> >> I expected to have the same foundation for the last two candidates, >> for they have the same mapped-address IP and both the STUN servers >> are located at the same network. I know it is difficult to discover >> if two STUN servers are located in the same network, so I suggest you >> to review the section "4.1.1.4" the statement "for reflexive and >> relayed candidates, the STUN servers used to obtain them have the >> same IP address". I don't know if this is an issue or it is a normal >> behavior of the algorithm, but I use these foundations to conclude >> the ICE processing (I wait for two candidate pairs with the same >> foundation to complete, for QoS purposes). >> >> Regards, >> >> Guilherme Balena Versiani >> ComunIP S/A >> >> _______________________________________________ >> 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 Jul 20 09:43: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 1IBsl8-0002qV-LR; Fri, 20 Jul 2007 09:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsl7-0002qQ-Es for mmusic@ietf.org; Fri, 20 Jul 2007 09:43:05 -0400 Received: from hm398-2.locaweb.com.br ([200.234.205.170] helo=hm398.locaweb.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBsl5-0007Nk-S0 for mmusic@ietf.org; Fri, 20 Jul 2007 09:43:04 -0400 Received: (qmail 8476 invoked from network); 20 Jul 2007 13:43:00 -0000 Received: from unknown (10.1.10.10) by hm398.locaweb.com.br with QMQP; 20 Jul 2007 13:43:00 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.17.146.249) by hm10.locaweb.com.br with SMTP; 20 Jul 2007 13:43:03 -0000 Message-ID: <46A0BBE3.8040605@comunip.com.br> Date: Fri, 20 Jul 2007 10:42:59 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE-16 possible issue References: <4696611F.4060808@comunip.com.br> <46978692.7040106@cisco.com> <46A0B77B.8030404@comunip.com.br> In-Reply-To: <46A0B77B.8030404@comunip.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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'm sorry. Moving the Section 4.1.2 really do the work. BTW, please check my question. Guilherme Balena Versiani wrote: > Just moving Section 4.1.2 down does not do the work, as there are not > any defined order between the native candidates during Gathering. > > Is there any reason to not check just the base IP address and the > mapped IP address? I though something like "a candidate must have the > same foundation ID when all of the following are true: they are of the > same type, their bases have the same IP, for server and reflexive > candidates, the transport address have the same IP". Is there any > known issue related to this solution? > > -- Guilherme Balena Versiani. > > Jonathan Rosenberg wrote: >> What you describe is normal behavior of the algorithm. There is no >> way for ICE to know whether these STUN servers are really 'the same' >> and that their network paths towards the NAT are identical. >> >> The problem here is that, when you eliminated the redundant >> candidates, you ended up eliminating one from one STUN server, and >> one from the other. In fact you should have eliminated both of them >> from the same STUN server. >> >> THe spec is currently silent on WHICH candidates to eliminate when >> they are redundant. That is because the current redundancy >> elimination step happens prior to prioritization. >> >> I suggest a simple fix is that I merely move Section 4.1.2 down after >> prioriziation, and then suggest that the least preferred candidate is >> eliminated. >> >> -Jonathan R. >> >> >> Guilherme Balena Versiani wrote: >>> The section "4.1.1.3. Eliminating Redundant Candidates" states that >>> "a candidate is redundant if its transport address equals another >>> candidate, and its base equals the base of that other candidate". >>> >>> The next section "4.1.1.4. Computing Foundations" then states that >>> "two candidates MUST have the same foundation ID when all of the >>> following are true: they are of the same type, their bases have the >>> same IP, for server and reflexive candidates, the STUN servers used >>> to obtain them have the same IP address". >>> >>> Be the following scenario: >>> >>> - There are two STUN servers configured by an agent A >>> (200.100.10.50:3478 and 200.100.10.51:3478); >>> - The agent A have two components (RTP and RTCP); >>> - The gathering process obtain the following addresses (in order): >>> * component=1, transport=10.0.0.1:5004/udp, type=local; >>> * component=2, transport=10.0.0.1:5005/udp, type=local; >>> * component=2, transport=200.100.10.1:5005/udp, type=srflx, >>> stunserver=200.100.10.50:3478; >>> * component=1, transport=200.100.10.1:5004/udp, type=srflx, >>> stunserver=200.100.10.51:3478; >>> * component=1, transport=200.100.10.1:5004/udp, type=srflx, >>> stunserver=200.100.10.50:3478; >>> * component=2, transport=200.100.10.1:5005/udp, type=srflx, >>> stunserver=200.100.10.51:3478; >>> >>> Following the algorithm described in the section "4.1.1.3", we must >>> eliminate two of the server reflexive candidates as they have the >>> same mapped-address. So, by removing the redundant candidates in >>> order (forward comparison), we get the new candidate list as follows: >>> >>> * component=1, transport=10.0.0.1:5004/udp, type=local; >>> * component=2, transport=10.0.0.1:5005/udp, type=local; >>> * component=2, transport=200.100.10.1:5005/udp, type=srflx, >>> stunserver=200.100.10.50:3478; >>> * component=1, transport=200.100.10.1:5004/udp, type=srflx, >>> stunserver=200.100.10.51:3478; >>> >>> Note that the two server reflexive candidates was obtained by two >>> different STUN servers. Now I must compute the foundations, then I >>> would get: >>> >>> * foundation=1, component=1, transport=10.0.0.1:5004/udp, >>> type=local; >>> * foundation=1, component=2, transport=10.0.0.1:5005/udp, >>> type=local; >>> * foundation=2, component=2, transport=200.100.10.1:5005/udp, >>> type=srflx, stunserver=200.100.10.50:3478; >>> * foundation=3, component=1, transport=200.100.10.1:5004/udp, >>> type=srflx, stunserver=200.100.10.51:3478; >>> >>> I expected to have the same foundation for the last two candidates, >>> for they have the same mapped-address IP and both the STUN servers >>> are located at the same network. I know it is difficult to discover >>> if two STUN servers are located in the same network, so I suggest >>> you to review the section "4.1.1.4" the statement "for reflexive and >>> relayed candidates, the STUN servers used to obtain them have the >>> same IP address". I don't know if this is an issue or it is a normal >>> behavior of the algorithm, but I use these foundations to conclude >>> the ICE processing (I wait for two candidate pairs with the same >>> foundation to complete, for QoS purposes). >>> >>> Regards, >>> >>> Guilherme Balena Versiani >>> ComunIP S/A >>> >>> _______________________________________________ >>> 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 Jul 20 10: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 1IBtmb-00025O-2Q; Fri, 20 Jul 2007 10:48:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtmZ-00024z-I1 for mmusic@ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IBtmZ-0004cA-48 for mmusic@ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: (qmail 42524 invoked by uid 60001); 20 Jul 2007 14:48:38 -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=bgOG0vEyxaJUH0jcE3EPAYoUALnk99g5hyCvgkoZR9UDDiSB4ppOhkAXvZuRxvqsetUKD7VaPx7+8VJjpOS6ctqXlE28pht271hlG7yQfowt360CE3eYB0RNJAxw5tPKt5GzzkbQWSH4WNr5c2jzOEFlx9/TLH41xOjF2XjpZME=; X-YMail-OSG: p_naqYoVM1k8h9.pNsw5qeWaWi.N2xoQnYRPbntHxDHAUnSmCZRDU.sd4z7zU7.G_fRTsU6BaQ-- Received: from [69.236.76.222] by web33306.mail.mud.yahoo.com via HTTP; Fri, 20 Jul 2007 07:48:38 PDT Date: Fri, 20 Jul 2007 07:48:38 -0700 (PDT) From: Pyda Srisuresh To: Philip Matthews , Henry Sinnreich In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <615870.42407.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; [suresh] I dont know what you are talking about. AFAIK, Peer reflexive address is same as the public endpoint assigned to a node behind NAT. How can that be not part of HOLE-PUNCHING technique? > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; [suresh] HOLE-PUNCHING technique is based on communication along a control path with external rendezvous server(s), which act as the key controller. The peering endpoints either make requests to punch holes or receiving requests to help in hole-punching by a peer. > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). [suresh] Hole punchign technique is not complete by itself to setup connections. It needs a fallback scheme. Port prediction and relays can be effective fallback to hole punching. regards, suresh > > Philip > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 20 13:16: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 1IBw56-0005Lc-H8; Fri, 20 Jul 2007 13:15:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBw54-0005LQ-LL for mmusic@ietf.org; Fri, 20 Jul 2007 13:15:54 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBw53-0007ar-6Z for mmusic@ietf.org; Fri, 20 Jul 2007 13:15: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] SDPCapNeg-06: Lack of bandwidth capabilities Date: Fri, 20 Jul 2007 20:16:55 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04C22FC2@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities Thread-Index: AcfKKCL8uH3iYqhaQd2YgkXqKWY90gAikPqwAA/JBQA= From: "Even, Roni" To: "Stach, Thomas" , "Magnus Westerlund" , "mmusic (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Thomas, I think we may cover it in the media capabilities. Still I think that we may decide that we can use RTCP CCM for flow control to lower BW based on selected mode. Roni > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@SIEMENS.COM] > Sent: Friday, July 20, 2007 1:25 PM > To: Magnus Westerlund; mmusic (E-mail) > Subject: RE: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities >=20 > Magnus, >=20 > I agree that this is neither covered in the core spec nor in the media > capability extension. > Could that be left for an extension (either its own or media > capabilities) in order to keep the core spec simpler? >=20 > Regards > Thomas >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, July 19, 2007 7:13 PM > > To: mmusic (E-mail) > > Subject: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities > > > > The current proposal total failes to discuss the bandwidth > > parameter in > > SDP. This is a serious shortcomming and will result in real > > issues for > > the profiles. Different profiles and usages will have different > > bandwidth parameters. Although media bandwidth may different for > > different potential configurations I think the major issue > > exist for the > > RR and RS attribute which really makes sense to configure differently > > for different profiles. For example AVPF with some feedback > > may require > > much more RTCP bandwidth than AVP. And in case one uses the TFRC > > addition one may have need for yet another configuration. > > Thus there is > > need to be able to connect different bandwidth configurations with > > specific potential configurations. > > > > 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 Fri Jul 20 13:22: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 1IBwB5-0001Me-N4; Fri, 20 Jul 2007 13:22:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwB4-0001MJ-Hk for mmusic@ietf.org; Fri, 20 Jul 2007 13:22:06 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBwB3-0007j6-VX for mmusic@ietf.org; Fri, 20 Jul 2007 13:22:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg-06: Session level coordintation betweenpotential configurations Date: Fri, 20 Jul 2007 20:23:09 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04C22FC3@IsrExch01.israel.polycom.com> In-Reply-To: <469F9BCD.8070905@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Session level coordintation betweenpotential configurations Thread-Index: AcfKKFzGd+t5dfZ3Sqa3c1NvOZjS3QAydAIw From: "Even, Roni" To: "Magnus Westerlund" , "mmusic (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Content-Type: multipart/mixed; boundary="===============1347017200==" Errors-To: mmusic-bounces@ietf.org --===============1347017200== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFnbnVzLA0KDQpJIGhhdmUgb3RoZXIgZXhhbXBsZXMgZm9yIHN1Y2ggcmVxdWlyZW1lbnRzIGxp a2UgcmVjZWl2ZXIgd291bGQgbGlrZSB0byBnZXQgb25lIEguMjY0IHN0cmVhbSBvciB0d28gSC4y NjMgc3RyZWFtcy4gSSB0aGluayB0aGF0IHRoZXJlIGlzIGFscmVhZHkgYSBwcm9ibGVtIHdpdGgg Z3JvdXBpbmcgc3VjaCBhbHRlcm5hdGl2ZXMgaW4gcmVndWxhciBTRFAgYW5kIHRoYW4gSSBhbHJl YWR5IHN0YXJ0ZWQgdG8gZGlzY3VzcyB3aXRoIEJvYiBHaWxtYW4gYWJvdXQgaGF2aW5nIHNpbWls YXIgZnVuY3Rpb25hbGl0eSBmb3IgbWVkaWEgcG90ZW50aWFsIGNvbmZpZ3VyYXRpb25zLg0KDQpS b25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rl cmx1bmQgW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBKdWx5IDE5LCAyMDA3IDg6MTQgUE0NCj4gVG86IG1tdXNpYyAoRS1tYWlsKQ0KPiBT dWJqZWN0OiBbTU1VU0lDXSBTRFBDYXBOZWctMDY6IFNlc3Npb24gbGV2ZWwgY29vcmRpbnRhdGlv bg0KPiBiZXR3ZWVucG90ZW50aWFsIGNvbmZpZ3VyYXRpb25zDQo+IA0KPiBUaGUgZHJhZnQgY29t ZXMgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGVyZSBpcyBubyByZWFsIG5lZWQgZm9yDQo+IGNv b3JkaW50aW9uIGJldHdlZW4gZGlmZmVyZW50IG1lZGlhIGRlc2NyaXB0aW9ucyBhbmQgdGhlaXIg cG90ZW50aWFsDQo+IGNvbmZpZ3VyYXRpb25zLiBJIHRoaW5rIHRoYXQgaXMgd3JvbmcgZm9yIHNl dmVyYWwgcmVhc29uczoNCj4gDQo+IDEuIEkgd291bGQgc3RhcnQgd2l0aCByZWZlcmVuaW5nIG9u Y2UgbW9yZSB0byBhIGRlZmluZWQgdXNhZ2UgaW4gUkZDDQo+IDQ1ODggKFJUUCBSZXRyYW5zbWlz c2lvbikuIEluIHRoZSBjYXNlIG9mIGRlc2lyZSB0byB1c2Ugc2Vzc2lvbg0KPiBtdWx0aXBsZXhp bmcgZm9yIHRoZSByZXRyYW5zbWlzc2lvbiBvbmUgd291bGQgb25seSBsaWtlIHRvIHVzZSB0aGF0 DQo+IHVuZGVyIHRoZSBjb25zdHJhaW50IHRoYXQgb25lIGFscmVhZHkgdXNlcyBBVlBGIGluIHRo ZSBwcmltYXJ5DQo+IHRyYW5zbWlzc2lvbiBzZXNzaW9uLiBUaHVzIG9uZSB3b3VsZCBsaWtlIHRv IG1ha2UgdGhlIGZvbGxvd2luZyBvZmZlcjoNCj4gDQo+IFByaW1hcnkgc2Vzc2lvbjogQVZQLCBw b3RlbnRpYWwgY29uZmlndXJhdGlvbiAxOiBBVlBGIHdpdGggTkFDSw0KPiANCj4gUmV0cmFuc21p c3Npb24gc2Vzc2lvbjogT25seSB1c2VkIGluIGNhc2UgcHJpbWFyeSBzZXNzaW9uIHNlbGVjdHMN Cj4gcG90ZW50aWFsIGNvbmZpZ3VyYXRpb24gMS4NCj4gDQo+IDIuIEFsbG93IGZvciBtZWRpYSBj YXBhYmlsaXR5IG5lZ290aWF0aW9uLiBBcyBJIHNlZSBpdCB3aGVuIG1vdmluZyBpbnRvDQo+IGEg bWVkaWEgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBleHRlbnNpb24gb25lIHdpbGwgdmVyeSBtdWNo IGxpa2UgdG8NCj4gcHJlc2VudCBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgc2V0IG9mIG1lZGlhIGNv bmZpZ3VyYXRpb25zLiBUaGF0IG1heQ0KPiBpbmNsdWRlIGFkZGl0aW9uYWwgbWVkaWEgc3RyZWFt cyBuZWVkaW5nIHRoZWlyIG93biBtZWRpYSBkZXNjcmlwdGlvbnMsDQo+IGkuZS4gUlRQIHNlc3Np b25zIC8gb3Igb3RoZXIgbWVkaWEgdHJhbnNwb3J0IChNU1JQKS4gT25lIHdvdWxkIGluIG90aGVy DQo+IHdvcmRzIGxpa2UgdG8gZXhwcmVzcyBjYXBhYmlsaXRlcyBsaWtlLiBMZXRzIGRvIChBdWRp bywgdmlkZW8gYW5kIFRleHQpLA0KPiBvciAoQXVkaW8sIHZpZGVvIGFuZCBNU1JQKSBvciAoQXVk aW8gYW5kIFRleHQpIG9yIChBdWRpbyBhbmQgTVNSUCkNCj4gZGVwZW5kaW5nIG9uIHBlZXJzIGNh cGFiaWxpdGllcy4gV2l0aG91dCB0aGUgZnVuY3Rpb25hbGl0eSB0byBtYWtlDQo+IGhpZ2hlciBs ZXZlbCBiaW5kaW5ncyBiZXR3ZWVuIHBvdGVudGlhbCBjb25maWd1cmF0aW9ucyBpbnRvIGRpZmZl cmVudA0KPiBzZXRzIHRoYXQgd2lsbCBub3Qgd29yay4NCj4gDQo+IFVuZm9ydHVuYXRlbHkgdGhl IGFib3ZlIGhhcyBvbmUgdmVyeSBmcmlnaHRlbmluZyBjb25jbHVzaW9uLCB3ZSBuZWVkIHRvDQo+ IGhhdmUgcG9zc2liaWxpdHkgdG8gZG8gcG90ZW50aWFsIGNvbmZpZ3VyYXRpb25zIGZvciBtZWRp YSBkZXNjcmlwdGlvbnMNCj4gdGhhdCBoYXMgbm8gbWF0Y2ggaW4gdGhlIGFjdHVhbCBjb25maWd1 cmF0aW9uLg0KPiANCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+ IElFVEYgVHJhbnNwb3J0IEFyZWEgRGlyZWN0b3IgJiBUU1ZXRyBDaGFpcg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IE11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZN L00NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25l ICs0NiA4IDQwNDgyODcNCj4gVG9yc2hhbXNnYXRhbiAyMyAgICAgICAgICAgfCBGYXggICArNDYg OCA3NTc1NTUwDQo+IFMtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2ljIG1haWxpbmcg bGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQo= --===============1347017200== 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 --===============1347017200==-- From mmusic-bounces@ietf.org Fri Jul 20 13:46: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 1IBwYb-0006Hf-8W; Fri, 20 Jul 2007 13:46:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwYZ-0006Cr-L3 for mmusic@ietf.org; Fri, 20 Jul 2007 13:46:23 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBwYZ-0008Ew-2u for mmusic@ietf.org; Fri, 20 Jul 2007 13:46:23 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 29791219ED for ; Fri, 20 Jul 2007 19:46:22 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-73-46a0f4ee6ac8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 052EB21992 for ; Fri, 20 Jul 2007 19:46:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 19:46:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jul 2007 19:46:21 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C7B8@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A few small questions on ICE-17 Thread-Index: AcfK9eJC3AdOqooVQLSpbi5tw93DSg== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 20 Jul 2007 17:46:21.0856 (UTC) FILETIME=[E2767200:01C7CAF5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [MMUSIC] A few small questions on ICE-17 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="===============1135333301==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1135333301== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CAF5.E239C506" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CAF5.E239C506 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 1. To my understanding, ICE is a "STUN usage" (as per 3489bis-07), but that sentence is not used anywhere in the document. Is there a reason for that? 2. ICE says that the Binding request is constructed "as defined in 3489bis", but 3489bis says that the different usage defines which headers are used. So, I assume that ICE does say (directly or indirectly) which STUN headers etc shall be used. 3. 3489bis says that the different usages shall define how the addresses of the STUN servers etc are retrieved. Maybe I've missed it, but does ICE specify that? Regards, Christer ------_=_NextPart_001_01C7CAF5.E239C506 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few small questions on ICE-17

Hi,

1. To my understanding, ICE is a = "STUN usage" (as per 3489bis-07), but that sentence is not = used anywhere in the document. Is there a reason for that?

2. ICE says that the Binding request is = constructed "as defined in 3489bis", but 3489bis says that the = different usage defines which headers are used. So,  I assume that = ICE does say (directly or indirectly) which STUN headers etc shall be = used.

3. 3489bis says that the different = usages shall define how the addresses of the STUN servers etc are = retrieved. Maybe I've missed it, but does ICE specify that?

Regards,

Christer

------_=_NextPart_001_01C7CAF5.E239C506-- --===============1135333301== 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 --===============1135333301==-- From mmusic-bounces@ietf.org Fri Jul 20 14:19: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 1IBx4E-0005E1-NI; Fri, 20 Jul 2007 14:19:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx4D-0005Dv-3q for mmusic@ietf.org; Fri, 20 Jul 2007 14:19:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBx4C-0000ND-9s for mmusic@ietf.org; Fri, 20 Jul 2007 14:19:04 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8F48F204EF; Fri, 20 Jul 2007 20:19:03 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-ed-46a0fc97c246 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5622E2007B; Fri, 20 Jul 2007 20:19:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 20:19:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 20:19:01 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C7D6@esealmw113.eemea.ericsson.se> In-Reply-To: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Progressing ICE Thread-Index: AcfK+Sm98BjX9r+qQOioGkFYZA5AUQAANUyQ References: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> From: "Christer Holmberg (JO/LMF)" To: "Colin Perkins" , "MMUSIC WG" X-OriginalArrivalTime: 20 Jul 2007 18:19:02.0971 (UTC) FILETIME=[7360D8B0:01C7CAFA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Cullen Jennings , Jean-Francois Mule , Joerg Ott Subject: [MMUSIC] RE: [Sip] Progressing ICE 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, Some minutes ago, I sent an e-mail regarding ICE to the list, with some = questions. Two of the questions weren't that big, but the COULD be an issue (unless = I've missed something in the ICE text). You don't detect this issue when = reading the ICE draft, but when reading the STUN bis draft, which = describes some rules for "STUN usages" (ICE is a STUN usage). I hope Jonathan will be able to take a quick look at the questions, so = see whether we have an issue or not. Regards, Christer =20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: 20. hein=E4kuuta 2007 14:44 > To: MMUSIC WG > Cc: Cullen Jennings; Jean-Francois Mule; Joerg Ott > Subject: [Sip] Progressing ICE >=20 > [This note is sent to MMUSIC, with bcc to BEHAVE, SIP, and=20 > P2PSIP since the discussion has included those groups.=20 > Replies to MMUSIC only please, as ICE is an MMUSIC working=20 > group draft] >=20 >=20 > The MMUSIC chairs have reviewed the mailing list discussion=20 > pertaining to ICE over the last few days. While we agree that=20 > further implementation experience and publication of=20 > deployment results would be valuable, as it is for any new=20 > protocol, we do not believe this sufficient cause to revisit=20 > the consensus to request publication of=20 > draft-ietf-mmusic-ice-17.txt as a Proposed Standard. >=20 > The characteristics of Proposed Standard specifications are=20 > described in RFC 2026 section 4.1.1 as follows: >=20 > > The entry-level maturity for the standards track is "Proposed > > Standard". A specific action by the IESG is required to move a > > specification onto the standards track at the "Proposed Standard" > > level. > > > > A Proposed Standard specification is generally stable,=20 > has resolved > > known design choices, is believed to be well-understood, has=20 > > received > > significant community review, and appears to enjoy=20 > enough community > > interest to be considered valuable. However, further experience > > might result in a change or even retraction of the specification > > before it advances. > > > > Usually, neither implementation nor operational experience is > > required for the designation of a specification as a Proposed > > Standard. However, such experience is highly desirable, and will > > usually represent a strong argument in favor of a=20 > Proposed Standard > > designation. > > > > The IESG may require implementation and/or operational experience > > prior to granting Proposed Standard status to a=20 > specification that > > materially affects the core Internet protocols or that specifies > > behavior that may have significant operational impact on the > > Internet. > > > > A Proposed Standard should have no known technical omissions with > > respect to the requirements placed upon it. However,=20 > the IESG may > > waive this requirement in order to allow a specification=20 > to advance > > to the Proposed Standard state when it is considered to=20 > be useful=20 > > and > > necessary (and timely) even with known technical omissions. > > > > Implementors should treat Proposed Standards as immature > > specifications. It is desirable to implement them in=20 > order to gain > > experience and to validate, test, and clarify the specification. > > However, since the content of Proposed Standards may be=20 > changed if > > problems are found or better solutions are identified, deploying > > implementations of such standards into a disruption-sensitive > > environment is not recommended. >=20 > Our judgement is that ICE meets these requirements, and that=20 > there is general working group consensus to request=20 > publication. Accordingly, our intention is to proceed as we=20 > previously announced, and request that ICE be published as a=20 > Proposed Standard RFC. >=20 > Colin Perkins, J=F6rg Ott, and Jean-Fran=E7ois Mul=E9 MMUSIC chairs >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 20 14:42:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxQb-0000F5-9r; Fri, 20 Jul 2007 14:42:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxQW-0000Et-Iy for mmusic@ietf.org; Fri, 20 Jul 2007 14:42:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBxQV-0006w4-Kp for mmusic@ietf.org; Fri, 20 Jul 2007 14:42:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2007 11:42:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABKfoEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,563,1175497200"; d="scan'208"; a="185790407:sNHT53915310" 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 l6KIg6UG002448; Fri, 20 Jul 2007 11:42:06 -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 l6KIft6O008063; Fri, 20 Jul 2007 18:42:06 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 11:42:06 -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] SDPCapNeg-06: Session level coordintationbetweenpotential configurations Date: Fri, 20 Jul 2007 11:42:05 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations Thread-Index: AcfKKEU9T0C5ViaPQWiwuFHiXLvKUwAjRmCAAAxEFPA= From: "Joe Stone \(joestone\)" To: "Stach, Thomas" , "Magnus Westerlund" , "mmusic \(E-mail\)" X-OriginalArrivalTime: 20 Jul 2007 18:42:06.0114 (UTC) FILETIME=[ABCBB820:01C7CAFD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5807; t=1184956926; x=1185820926; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joestone@cisco.com; z=From:=20=22Joe=20Stone=20\(joestone\)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Session=20level=20coordi ntationbetweenpotential=20configurations |Sender:=20; bh=IDZz8OOpk3kkmJ1eueGsy0Ev8BeUW0q7Vqdfcx7yCpA=; b=Y8TpCxaXodQc7hUJxGt+Jjc3tT2y9Yuwbs8cgLLfVrNtWaspmeEDwUT7RdOgkfZGN1AIRMlQ VizlJtyAHG1pZ6IGmxTsZnPLwsW22ChLlDr0Vw4eZBI6JFqiONSxlIN2; Authentication-Results: sj-dkim-3; header.From=joestone@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 Magnus seems to be discussing the notion of an "actual session description" consisting of "actual media descriptions" versus "potential session descriptions" consisting of "potential media descriptions". Not to confuse matters and for purely illustrative purposes (in short-hand SDP notation), v=3D0 a=3DX-psd:1 X-pmd=3D1 a=3DX-pmd:1 m=3Dimage 53458 udptl t38 a=3DX-pmd:1 a=3DT38FaxVersion: a=3DX-pmd:1 a=3DT38MaxBitrate: m=3Daudio 53456 RTP/AVP 0 The actual session description consists of one actual media description involving audio/PCMU. There is one potential (preferred) session description, "X-psd:1", consisting of one potential media description, "X-pmd:1", involving image/t38. And more along the lines of Magnus' example, v=3D0 a=3DX-psd:1 X-pmd=3D1|2 a=3DX-psd:2 X-pmd=3D3 a=3DX-pmd:1 m=3Daudio 53456 RTP/AVP 18 a=3DX-pmd:2 m=3Dtext 53458 RTP/AVP 98 <<< RFC 4103 a=3DX-pmd:2 a=3Drtpmap:98 t140/1000 a=3DX-pmd:3 m=3Daudio 53456 RTP/AVP 18 98 <<< RFC 4351 a=3DX-pmd:3 a=3Drtpmap:98 t140c/8000 m=3Daudio 53456 RTP/AVP 18 98 <<< V.152 a=3Drtpmap:98 PCMU/8000 a=3Dgpmd:98 vbd=3Dyes Applying semantics similar to sdp-capability-negotiation, the most preferred potential session description, "X-psd:1", consists of two potential media descriptions involving audio/G729 and text/t140, respectively. The second most preferred potential session description, "X-psd:2", consists of one potential media description involving audio/G729 and audio/t140c. If my hypothetical pseudo-code doesn't make any sense, disregard it. However, I do agree with Magnus that there's a need to negotiate between groups of media descriptions. I see this as the "big picture". It should be shown, at least at a high-level, that the transport protocol negotiation of sdp-capability-negotiation will fit with a more comprehensive SDP negotiation framework.=20 On a related topic... I'm not convinced that sdp-capability-negotiation should obsolete RFC 3407 given that sdp-capability-negotiation doesn't define equivalent functionality (at least based on -06). Joe -----Original Message----- From: Stach, Thomas [mailto:thomas.stach@siemens.com]=20 Sent: Friday, July 20, 2007 5:25 AM To: Magnus Westerlund; mmusic (E-mail) Subject: RE: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations Magnus, more inline.=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, July 19, 2007 7:14 PM > To: mmusic (E-mail) > Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation=20 > betweenpotential configurations >=20 > The draft comes to the conclusion that there is no real need for=20 > coordintion between different media descriptions and their potential=20 > configurations. I think that is wrong for several reasons: >=20 > 1. I would start with referening once more to a defined usage in RFC > 4588 (RTP Retransmission). In the case of desire to use session=20 > multiplexing for the retransmission one would only like to use that=20 > under the constraint that one already uses AVPF in the primary=20 > transmission session. Thus one would like to make the following offer: >=20 > Primary session: AVP, potential configuration 1: AVPF with NACK >=20 > Retransmission session: Only used in case primary session selects=20 > potential configuration 1. In other words this means an actual configuration with one m-line and a potential configuration with two m-lines. Would it help if the problem is described in the core spec, but not solved? My intention is to keep the core spec as simple as possible, but to state its restrictions. >=20 > 2. Allow for media capability negotiation. As I see it when moving=20 > into a media capability negotiation extension one will very much like=20 > to present cases where there are set of media configurations. That may > include additional media streams needing their own media descriptions, > i.e. RTP sessions / or other media transport (MSRP). One would in=20 > other words like to express capabilites like. Lets do (Audio, video=20 > and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio=20 > and MSRP) depending on peers capabilities. Without the functionality=20 > to make higher level bindings between potential configurations into=20 > different sets that will not work. Here I think we must decide how far we want go with media capability negotiation. >=20 > Unfortunately the above has one very frightening conclusion, we need=20 > to have possibility to do potential configurations for media=20 > descriptions that has no match in the actual configuration. I'm not sure how frightening that is from specification perspective (e.g. an a=3Dmcap for additional m-lines could do), but it surely is for an implementor. Regards Thomas >=20 >=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 > ---------------------------------------------------------------------- >=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 Fri Jul 20 17:57: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 1IC0TW-000877-AD; Fri, 20 Jul 2007 17:57:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0TU-00084s-0D for mmusic@ietf.org; Fri, 20 Jul 2007 17:57:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC0TT-00035A-IZ for mmusic@ietf.org; Fri, 20 Jul 2007 17:57:23 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2007 14:57:09 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACDMoEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,564,1175497200"; d="scan'208"; a="387216699:sNHT1791411258" 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 l6KLv9rG024310; Fri, 20 Jul 2007 14:57:09 -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 l6KLujAU001322; Fri, 20 Jul 2007 21:57:08 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, 20 Jul 2007 14:57:08 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 14:57:06 -0700 Message-ID: <46A12FB9.7000800@cisco.com> Date: Fri, 20 Jul 2007 17:57:13 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [MMUSIC] A few small questions on ICE-17 References: <7374777208BDC7449D5620EF942325670743C7B8@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670743C7B8@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2007 21:57:06.0729 (UTC) FILETIME=[E9E7E190:01C7CB18] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1364; t=1184968629; x=1185832629; 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]=20A=20few=20small=20questions=20on=20ICE-17 |Sender:=20; bh=IJpMFvov34WhjahhtL/hsL7dlSeYcCixl6/JIZOs2hk=; b=Nis0gN9PfcQ+8nurLM2foWdMHUWLE04Gc/YcCm/ccA00GdXTmUYmUz1JLVdH3r+fC+yTMtWs 418nN/BNnnSb5R3LJJCHeZZ3Wb9/zPDyiRjxFDt49CpECg0fnaTHkRSK; 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: 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. Christer Holmberg (JO/LMF) wrote: > > Hi, > > 1. To my understanding, ICE is a "STUN usage" (as per 3489bis-07), but > that sentence is not used anywhere in the document. Is there a reason > for that? "usage" isn't a formalism anymore; so the fact that ICE uses STUN is all that is needed to make it a usage. The ICE spec is pretty clear that it uses STUN. > > 2. ICE says that the Binding request is constructed "as defined in > 3489bis", but 3489bis says that the different usage defines which > headers are used. So, I assume that ICE does say (directly or > indirectly) which STUN headers etc shall be used. It does. > > 3. 3489bis says that the different usages shall define how the addresses > of the STUN servers etc are retrieved. Maybe I've missed it, but does > ICE specify that? It says it assumes its configured in some way but doesn't specify how, for the address gathering step. For connectivity checks obviously that is learned through the SDP. -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 Jul 20 21:15: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 1IC3YN-0005PG-Ey; Fri, 20 Jul 2007 21:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC3YM-0005PB-2g for mmusic@ietf.org; Fri, 20 Jul 2007 21:14:38 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC3YK-00041Q-Sg for mmusic@ietf.org; Fri, 20 Jul 2007 21:14:38 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 451F775805D for ; Fri, 20 Jul 2007 20:14:36 -0500 (CDT) From: "Frank W. Miller" To: Date: Fri, 20 Jul 2007 19:14:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <469F8577.4080506@estacado.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfK+Rmw3XhH2T/3TbKp8g0F6EumLAAOHYsg Message-Id: <20070721011436.451F775805D@smtpauth00.csee.onr.siteprotect.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [MMUSIC] ICE -17 questions 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 Since it appears that the draft will proceed as planned, I've been going over -17. I'd first like to say that I have not read the draft since the -11 timeframe and its readability has improved dramatically! My questions so far are: Section 5.1 talks about what an agent does when it encounters another agent that is not implementing ICE. It appears that the agent is supposed to implement the basic hole-punching algorithm in this case. Is that the intent? If so, should that algorithm be spec'd here or perhaps referred to in the form of the Ford draft? I think that there will be forever apps that do not implement ICE so this may be important. If dealing with a non-ICE agent, it seems logical to me that the ICE enabled agent should be able to tell which of its candidate addresses to use but will that really be the case? For example, let's assume that an ICE enabled agent decides to send an offer containing host, server-reflexive, and relay addresses. It gets a response back without an ICE lines in the SDP. Which address should it proceed with? Any comment on this? ICE passes candidates using SDP attribute lines. Once the checks are completed, I for one would put the winning address in the Contact header lines in subsequent messages. Perhaps this is documented elsewhere but it might be helpful to implementers to include recommendations on where the resulting addresses should be used in SIP header lines in Section 12. I'm sure I'll have more questions later on... Thanks, FM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Jul 20 22:10: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 1IC4PT-00054R-02; Fri, 20 Jul 2007 22:09:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC4PR-00054H-Ja for mmusic@ietf.org; Fri, 20 Jul 2007 22:09:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC4PQ-0007YM-Un for mmusic@ietf.org; Fri, 20 Jul 2007 22:09:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ABAB120FD8; Sat, 21 Jul 2007 04:09:27 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-44-46a16ad7a321 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8696020060; Sat, 21 Jul 2007 04:09:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 04:09:27 +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] A few small questions on ICE-17 Date: Sat, 21 Jul 2007 04:09:26 +0200 Message-ID: <7374777208BDC7449D5620EF942325670743C866@esealmw113.eemea.ericsson.se> In-Reply-To: <46A12FB9.7000800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] A few small questions on ICE-17 Thread-Index: AcfLGPR111TEvYi/T6icSKrndzKjDwAIYJsg References: <7374777208BDC7449D5620EF942325670743C7B8@esealmw113.eemea.ericsson.se> <46A12FB9.7000800@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 21 Jul 2007 02:09:27.0365 (UTC) FILETIME=[2A6D9750:01C7CB3C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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,=20 >>1. To my understanding, ICE is a "STUN usage" (as per 3489bis-07), but >>that sentence is not used anywhere in the document. Is there a reason=20 >>for that? >=20 >"usage" isn't a formalism anymore; so the fact that ICE uses=20 >STUN is all that is needed to make it a usage. The ICE spec=20 >is pretty clear that it uses STUN. Yes. My question we why the term wasn't used. Blah blah blah "ICE is a STUN usage, as defiend in 3489bis, and it uses STUN for blah blah blah...". But, it is true that it is clear even without text. >>2. ICE says that the Binding request is constructed "as defined in=20 >>3489bis", but 3489bis says that the different usage defines which=20 >>headers are used. So, I assume that ICE does say (directly or >>indirectly) which STUN headers etc shall be used. >=20 >It does. Ok. >>3. 3489bis says that the different usages shall define how the=20 >>addresses of the STUN servers etc are retrieved. Maybe I've missed it, >>but does ICE specify that? >=20 >It says it assumes its configured in some way but doesn't=20 >specify how, for the address gathering step. Ok. So, saying "it is configured in some way" is enough to fulfil the 3489bis "requirement"? >For connectivity checks obviously that is learned through the SDP. Yes. I was thinking about the STUN servers used to gather the addresses. Thanks! Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jul 21 08:24: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 1ICE0V-0004kk-EW; Sat, 21 Jul 2007 08:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICE0T-0004kX-Ks for mmusic@ietf.org; Sat, 21 Jul 2007 08:24:21 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICE0S-0007IV-To for mmusic@ietf.org; Sat, 21 Jul 2007 08:24:21 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2454D2084C; Sat, 21 Jul 2007 14:24:20 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-26-46a1faf43a16 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 08CC92042B; Sat, 21 Jul 2007 14:24:20 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 14:24:19 +0200 Received: from [138.85.12.57] ([138.85.12.57]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 14:24:19 +0200 Message-ID: <46A1FAF3.2020205@ericsson.com> Date: Sat, 21 Jul 2007 14:24:19 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Jaehwan Kim Subject: Re: [MMUSIC] draft-westerlund-mmusic-3gpp-sdp-rtsp-05.txt - section 7.7 References: <469E0A9E.1070505@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 21 Jul 2007 12:24:19.0285 (UTC) FILETIME=[0FB9D850:01C7CB92] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: =?ISO-8859-1?Q?_=28KI/EAB=29=22?= , "mmusic \(E-mail\)" , =?ISO-8859-1?Q?=22Per_Fr=F6jdh?= 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 Jaehwan, We will look into what you suggest. /Magnus Jaehwan Kim skrev: > Hi Magnus, >=20 > The section 7.7, "RTSP URI extension" in this draft looks like saying a= n extension of RTSP request URI, while I understand that 5.3.3.1 of 3GPP = TS26.234 just defines a special format of SDP a=3Dcontrol URI for 3GPP se= rvice.=20 >=20 > Therefore, the possible revise would be: > --- > 7.7. SDP a=3Dcontrol URI format > In 3GPP RTSP streaming session, a=3Dcontrol URI must have a track ID in= formation. The value of a=3Dcontrol URI, stream identifiers must be expre= ssed using the following syntax: >=20 > streamIdentifier =3D "=3D" > stream-id-token =3D 1*alpha > stream-id =3D 1*digit >=20 > This stream-id must be equal to the value of track-ID field in the trac= k header (tkhd) box associated with the media track of "3GP" file format = [PSS-3GP].=20 >=20 > When hinted track is used, embedded SDP must also follow this rule. > In 3GPP, streaming-server profile of 3GP format defines hinted track. > (See 5.3.3.1 of [PSS-234]). > --- >=20 > In generic RTSP streaming, we could use a free format, e.g. a=3Dcontrol= :audio or a=3Dcontrol:video. But in 3GPP, a=3Dcontrol must contain trackI= D or streamID with '=3D'. We understand this is the main point of this cl= ause.=20 >=20 > Cheers, > Jaehwan > Vidiator >=20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Wednesday, July 18, 2007 9:42 PM > To: mmusic (E-mail); "Per Fr=F6jdh (KI/EAB)" > Subject: [MMUSIC] [Fwd: I-DACTION:draft-westerlund-mmusic-3gpp-sdp-rtsp= -05.txt] >=20 > Hi, >=20 > We have finally managed to update the draft to take care of the comment= s=20 > raised by Jean-Francois. We also have addressed the issue with meeting=20 > the registration requirements for SDP "proto" identifiers which require= s=20 > an RFC to document the definition. A normative definition of the=20 > protocol identifiers are now included in this document. >=20 > Please provide any comments before the 27th of August. We plan to=20 > request publication if no comments has been received by then. >=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 > ---------------------------------------------------------------------- >=20 --=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 From mmusic-bounces@ietf.org Sat Jul 21 10:48: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 1ICGFa-0000l0-3g; Sat, 21 Jul 2007 10:48:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICGFX-0000kC-SL; Sat, 21 Jul 2007 10:48:03 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICGFX-0001XZ-DT; Sat, 21 Jul 2007 10:48:03 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 41B4F1810C56; Sat, 21 Jul 2007 16:48:03 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Jul 2007 16:47:52 +0200 To: "David Barrett" ,"'Jan Janak'" , "'Juha Heinanen'" From: Jiri Kuthan Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore LC for RFC In-Reply-To: <20070719180614.85AB218115BC@mail.iptel.org> References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070721144803.41B4F1810C56@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, 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 At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >> >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jul 21 12:03: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 1ICHQr-00085j-OW; Sat, 21 Jul 2007 12:03:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICHQp-00085Y-RD for mmusic@ietf.org; Sat, 21 Jul 2007 12:03:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICHQp-000672-Ix for mmusic@ietf.org; Sat, 21 Jul 2007 12:03:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2007 12:03:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAE/LoUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,566,1175486400"; d="scan'208"; a="65786605:sNHT24900168" 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 l6LG3ljr001300; Sat, 21 Jul 2007 12:03:47 -0400 Received: from [192.168.16.101] (rtp-vpn3-758.cisco.com [10.82.218.249]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6LG3gWI020712; Sat, 21 Jul 2007 16:03:46 GMT In-Reply-To: <469F5A56.9010908@gmail.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AAA3F3@namail5.corp.adobe.com> <469DCB03.9040300@ericsson.com> <13AC112D-E5EF-438B-97C8-9F3827EA07BF@cisco.com> <469F5A56.9010908@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E989D58-7D7C-4451-BF6A-93077E8C0B3D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sat, 21 Jul 2007 11:03:36 -0500 To: Evgeniy Khramtsov X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=365; t=1185033827; x=1185897827; c=relaxed/simple; s=rtpdkim2001; 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=20[Sip]=20Re=3A=20[BEHAVE]=20Re=3A=20ICE=20deployment=2 0data=20before=20LC=20for=20RFC |Sender:=20 |To:=20Evgeniy=20Khramtsov=20; bh=CFpvkVRPw5ZGfswIY+50dodxfVqEMGJ4JKTsz74IMJ8=; b=JGG8KuP4AZ0ntzPFzNY6ex0Fab76/FHd3xQ0NeWCgb7XG/ZVty8RwfK4wV0V+D2c3QOhXcAp 7IxTyhkHiaBilosWL+RZFrBF3xRJ+qHLQ/VpE3nG10HEkO6D3IhaRjjU; Authentication-Results: rtp-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: MMUSIC WG Subject: [MMUSIC] Re: [Sip] Re: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Jul 19, 2007, at 7:34 AM, Evgeniy Khramtsov wrote: > > I would love to see more open source ICE code (there is lots > already) > > > Could you point me to the _lots_ of open source ICE code? My mistake here and I apologize for the too quick typing when half asleep - I meant to say there is lots of ICE code not lots of open source ice code _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jul 21 13:10: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 1ICITq-00074K-9c; Sat, 21 Jul 2007 13:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICITn-00073n-Bu; Sat, 21 Jul 2007 13:10:55 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICITm-0003h7-Pa; Sat, 21 Jul 2007 13:10:55 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sat, 21 Jul 2007 10:10:47 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 l6LH9Uot007824; Sat, 21 Jul 2007 10:09:30 -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 l6LH8nI9011858; Sat, 21 Jul 2007 10:08:49 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 10:10:46 -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: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Sat, 21 Jul 2007 10:10:10 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> In-Reply-To: <20070721144803.41B4F1810C56@mail.iptel.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfLpi72E4uz+FnVTwmkMQscEMfhaAAErYbw References: <20070719145334.2EA8B1810C50@mail.iptel.org><20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> From: "Henry Sinnreich" To: "Jiri Kuthan" , "David Barrett" , "Jan Janak" , "Juha Heinanen" X-OriginalArrivalTime: 21 Jul 2007 17:10:46.0676 (UTC) FILETIME=[14359540:01C7CBBA] X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org, 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 fully agree with Jiri that this is an IETF problem and not an ICE problem. ICE-17 is a great document, no doubt about it. What happens however of someone finds an innovative approach that may work better? Will it be rejected because it will not be RFC standards compliant? What could an innovator tell customers about a solution that works better but is not IETF ICE RFC standards compliant? Henry -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org]=20 Sent: Saturday, July 21, 2007 9:48 AM To: David Barrett; 'Jan Janak'; 'Juha Heinanen' Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >>=20 >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be=20 an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Jul 21 16:43: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 1ICLnl-0000ZI-05; Sat, 21 Jul 2007 16:43:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLnh-0000YN-Vb; Sat, 21 Jul 2007 16:43:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICLng-0003jz-Va; Sat, 21 Jul 2007 16:43:41 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2007 16:43:39 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAHYMokZAZnme/2dsb2JhbACCLjY X-IronPort-AV: i="4.16,567,1175486400"; d="scan'208,217"; a="126671085:sNHT48362078" 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 l6LKhcdB029305; Sat, 21 Jul 2007 16:43:38 -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 l6LKhPWI024142; Sat, 21 Jul 2007 20:43:25 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 16:43:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Sat, 21 Jul 2007 16:43:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Thread-Index: AcfLpi72E4uz+FnVTwmkMQscEMfhaAAErYbwAAe45yU= From: "Jonathan Rosenberg \(jdrosen\)" To: "Henry Sinnreich" , "Jiri Kuthan" , "David Barrett" , "Jan Janak" , "Juha Heinanen" X-OriginalArrivalTime: 21 Jul 2007 20:43:25.0078 (UTC) FILETIME=[C8CF3B60:01C7CBD7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9155; t=1185050618; x=1185914618; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20 |To:=20=22Henry=20Sinnreich=22=20, =20=22Jiri=20Kuthan =22=20, =0A=20=20=20=20=20=20=20=20=22David=20Barrett=22=20 , =20=22Jan=20Janak=22=20, =0A=20=20=2 0=20=20=20=20=20=22Juha=20Heinanen=22=20; bh=FeXTbE1vsDRwBwYW0xanIKHvkLx0HL6s83l09CenqQE=; b=sVXKLLnRkiYijmZD35FW/HSRsgr8ziSzwQUe5wVgRU42J2AamO4St22alANvAF4aNL0Op809 sxbGhYFz9iLu4UhFNB/3uMM4sHazhFvCP/6kBRQOWwiZIj1sbo++Dvy2; 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: 6907f330301e69261fa73bed91449a20 Cc: sip@ietf.org, 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="===============0759027819==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0759027819== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CBD7.C8A4C4CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CBD7.C8A4C4CE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Of course they can bring such a thing to ietf. There is a long history = of new work improving on the old (ice improving on stun, v6 improving on = v4, ospf improving on rip, and so on). I look forward to your draft suggesting something better. Jonathan R. -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, July 21, 2007 01:11 PM Eastern Standard Time To: Jiri Kuthan; David Barrett; Jan Janak; Juha Heinanen Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE = deploymentdatabefore LCfor RFC I fully agree with Jiri that this is an IETF problem and not an ICE problem. ICE-17 is a great document, no doubt about it. What happens however of someone finds an innovative approach that may work better? Will it be rejected because it will not be RFC standards compliant? What could an innovator tell customers about a solution that works better but is not IETF ICE RFC standards compliant? Henry -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org]=20 Sent: Saturday, July 21, 2007 9:48 AM To: David Barrett; 'Jan Janak'; 'Juha Heinanen' Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:jiri@iptel.org] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >>=20 >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be=20 an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C7CBD7.C8A4C4CE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore = LCfor RFC

Of course they can bring such a thing to ietf. There = is a long history of new work improving on the old (ice improving on = stun, v6 improving on v4, ospf improving on rip, and so on).

I look forward to your draft suggesting something better.

Jonathan R.

 -----Original Message-----
From:   Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent:   Saturday, July 21, 2007 01:11 PM Eastern Standard = Time
To:     Jiri Kuthan; David Barrett; Jan Janak; Juha = Heinanen
Cc:     sip@ietf.org; mmusic@ietf.org
Subject:        RE: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC

I fully agree with Jiri that this is an IETF problem and not an ICE
problem.
ICE-17 is a great document, no doubt about it.

What happens however of someone finds an innovative approach that = may
work better? Will it be rejected because it will not be RFC = standards
compliant?

What could an innovator tell customers about a solution that works
better but is not IETF ICE RFC standards compliant?

Henry

-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Saturday, July 21, 2007 9:48 AM
To: David Barrett; 'Jan Janak'; 'Juha Heinanen'
Cc: sip@ietf.org; mmusic@ietf.org
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabefore LC for RFC

At 20:05 19/07/2007, David Barrett wrote:
>> -----Original Message-----
>> From: Jiri Kuthan [mailto:jiri@iptel.org]
>> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE = deployment
databefore
>> LC for RFC
>>
>> So I think that the right course of action is that folks = doubting ICE
>> reliability
>> make their case (by that I mean specific arguments rather = than
emotional
>> debates
>> about red-colored nails and other hardware).
>
>Er, my "specific argument" is "until it's been proven = to work, it
hasn't
>been proven to work".  It's tautological, but no less true = for it.
>
>Indeed, if you're *not* doubting ICE, why aren't you?

Hi David,

I'm not entirely sure what is the step you are suggesting?

I think ICE is architecturally right answer to the right problem.
Notwithstanding that, there are certainly some things I prefer
differently (e.g., the infamous debate about proactive hole = punching)
or may turn out to be bugs. I think though that the key problem at
this point is of institutional nature. In the IETF language, = "hasn't
been proven to work" is adequate to "lacking running = code" and this
appears to be a phenomen which is indeed occuring in the IETF and
is not unique to ICE.

The question is how to get this fixed?

Some other standardization bodies enjoying the amount of = contributions
and complexity as the IETF is enjoying now (S in SIP does not really
stand for Simple), proceed with 'after-fact filters', in that they
produce the initial specs faster and later produce 'profiles' which
separate what has proved and what less. Plus -bis versions are = produced
for whatever appears worth puttting effort in it (i.e., for which = there
is running code and field evidence of improvement need).This could = be
an approach  which may be more feasible in today's IETF's dimension = than

trying to get back to historical roots.

-jiri



_______________________________________________
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

------_=_NextPart_001_01C7CBD7.C8A4C4CE-- --===============0759027819== 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 --===============0759027819==-- From mmusic-bounces@ietf.org Sat Jul 21 22:42: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 1ICROr-0003dd-24; Sat, 21 Jul 2007 22:42:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICROp-0003dS-GF for mmusic@ietf.org; Sat, 21 Jul 2007 22:42:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICROp-0001hp-3y for mmusic@ietf.org; Sat, 21 Jul 2007 22:42:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2007 22:42:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoUAF5gokZAZnmf/2dsb2JhbACIX5w2 X-IronPort-AV: i="4.16,567,1175486400"; d="scan'208"; a="65801311:sNHT27552706" 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 l6M2gM8J009118 for ; Sat, 21 Jul 2007 22:42:22 -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 l6M2gMEZ027655 for ; Sun, 22 Jul 2007 02:42:22 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); Sat, 21 Jul 2007 22:42:22 -0400 Received: from [10.86.240.164] ([10.86.240.164]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Jul 2007 22:42:22 -0400 Message-ID: <46A2C40C.30003@cisco.com> Date: Sat, 21 Jul 2007 22:42:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2007 02:42:22.0180 (UTC) FILETIME=[EDEC3240:01C7CC09] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1722; t=1185072142; x=1185936142; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Comments=20on=20draft-ietf-mmusic-sdp-capability-negotiation- 06 |Sender:=20 |To:=20IETF=20MMUSIC=20WG=20; bh=AG5aQeYCL/WDoZ0w/mApEXGP87iUBOHfbjddLaS4nNQ=; b=iDlV/KB3EgTHTEgP6/nlQtVjUNAffJXH+QPlUiBL54eXMu2XxxJDgookRLRMnvGoMv4MvW8p rOVDLyI9ekfEC4Uy+ZW5UZEZdx6feAy3hbrlBMebG0E0ds3u7YABeGIM; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Flemming Andreasen Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-capability-negotiation-06 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 Flemming, I have been studiously avoiding all the earlier versions of this draft, because it clearly required more bandwidth than I was prepared to devote. Now that it is almost done I decided to read it. This is an impressive piece of work. You have managed to wedge a huge increase in functionality into a format that really isn't well suited to it. While the result is still ugly, in the context of SDP it is really quite elegant. I was looking for issues in all the corners, but it seems somebody generally beat me to it, so almost all of the ones I thought I had found were covered by subsequent text. I think I found one thing that wasn't covered: > 3.7.3. Offerer Processing of the Answer ... > For each media description where the offerer included a potential > configuration attribute ("a=pcfg"), the offerer MUST first examine > the media description for the presence of an actual configuration > attribute ("a=acfg"). If an actual configuration attribute is not > present in a media description, then the offerer MUST process the > answer SDP for that media stream per the normal offer/answer rules > defined in [RFC3264]. ... Something seems to be missing here. If there is more than one media description in the answer, and one contains a=acfg and the other does not, then the one that does may cause a change in session level attributes, and that can affect the way the media description without a=acfg is processed. There is text covering this for the offerer, but it is lacking here in the procedures for the answerer. That is the only thing I could find. Congratulations! Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jul 22 22:44: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 1ICnuK-0004Ju-Js; Sun, 22 Jul 2007 22:44:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICnuJ-0004Jo-VW for mmusic@ietf.org; Sun, 22 Jul 2007 22:44:23 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICnuJ-00021E-El for mmusic@ietf.org; Sun, 22 Jul 2007 22:44:23 -0400 Received: from orthrus.local ([67.97.210.2]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l6N2iFJP068961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2007 21:44:21 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <46A3AE3B.3010908@estacado.net> Date: Sun, 22 Jul 2007 14:21:31 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Miguel-Angel Garcia Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mmusic@ietf.org Subject: [MMUSIC] file transfer: examples nits 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 current file transfer draft calls out to RFC 2822 for the syntax for date-time. RFC 2822 defines numeric time zones to be of the form "-0600" -- however, the examples in the file transfer document all show them with a colon: "-06:00" Similarly, Figure 2 uses an undefined value of "not-render" where it almost certainly means "attachment". We need to be careful here; otherwise, the 5% of the people who read the text will create implementations that won't interoperate with the 95% who merely implement the examples. :) /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 23 06:50: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 1ICvUK-0005Wp-Gm; Mon, 23 Jul 2007 06:50:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICvUK-0005Tc-1a for mmusic@ietf.org; Mon, 23 Jul 2007 06:50:04 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICvUJ-0000gd-FV for mmusic@ietf.org; Mon, 23 Jul 2007 06:50:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6NAnP3L007551; Mon, 23 Jul 2007 13:49:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 13:49:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 13:49:33 +0300 Received: from [10.243.7.58] ([10.243.7.58]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 13:49:33 +0300 Message-ID: <46A487BA.6020307@nsn.com> Date: Mon, 23 Jul 2007 13:49:30 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach References: <46A3AE3B.3010908@estacado.net> In-Reply-To: <46A3AE3B.3010908@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 10:49:33.0263 (UTC) FILETIME=[276B3DF0:01C7CD17] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mmusic@ietf.org Subject: [MMUSIC] Re: file transfer: examples nits 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 Good catch. Thanks. I agree, the examples MUST be absolutely correct. So, I did a review of the whole draft (for dates and times) and this is the conclusion: In SIP, the Date header uses only GMT: Date: Sun, 21 May 2006 13:02:03 GMT In SDP, the file-date attribute uses time zones without colon: a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" In MIME wrappers, the *-date parameter in the Content-Disposition header uses time zones without a colon (like the file-date attribute in SDP): creation-date="Mon, 15 May 2006 15:01:31 +0300" In MSRP, the DateTime header uses colons: DateTime: 2006-05-15T15:02:31-03:00 I also fixed the file-disposition to be attachment I hope it is correct now in my working copy. Thanks again for this catches. /Miguel Adam Roach wrote: > The current file transfer draft calls out to RFC 2822 for the syntax for > date-time. RFC 2822 defines numeric time zones to be of the form "-0600" > -- however, the examples in the file transfer document all show them > with a colon: "-06:00" > > Similarly, Figure 2 uses an undefined value of "not-render" where it > almost certainly means "attachment". > > We need to be careful here; otherwise, the 5% of the people who read the > text will create implementations that won't interoperate with the 95% > who merely implement the examples. :) > > /a > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 23 11:39:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzzq-0005nQ-4S; Mon, 23 Jul 2007 11:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzzp-0005nL-1f for mmusic@ietf.org; Mon, 23 Jul 2007 11:38:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzzn-0001AN-Ge for mmusic@ietf.org; Mon, 23 Jul 2007 11:38:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2007 08:38:33 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAK5opEarR7MV/2dsb2JhbACIX51G X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="186958484:sNHT1084286691" 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 l6NFcXJt023822; Mon, 23 Jul 2007 08:38:33 -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 l6NFcS6G015920; Mon, 23 Jul 2007 15:38:33 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); Mon, 23 Jul 2007 08:38:29 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 08:38:28 -0700 Message-ID: <46A4CB73.1010701@cisco.com> Date: Mon, 23 Jul 2007 11:38:27 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> In-Reply-To: <469F9B92.3060906@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 15:38:28.0679 (UTC) FILETIME=[8421CD70:01C7CD3F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5453; t=1185205113; x=1186069113; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Transport=20capabilites= 20and=20RTP=20payload=0A=20types |Sender:=20; bh=RiTgDZcYcFx13y5R2hok3jSw9t+cwo/3oH46Cznh1pI=; b=CiUCmMeM0wmlAa+SiV+29/9YQ6IIyF7mS/8PdswSBa5W3TSY19o75dz3mPiZrEakzsg+G+BY SlUddP8myzsryqPO6iyQRwdMzqZQH88lX/EvKZkloGM5q2YtzdeiuaHiHmhw4wL7thHxGVHSnc AIzUpOtxuAQlJ3LEQCrL+GSnw=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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: > Hi, > > I have finally read the SDP capapbility draft in sufficient detail to > think I understand it mostly. There is likely some details that I have > gotten wrong. But I have found some issues that I need to raise for > discussion. I will split this into separate emails for each topic. Thanks for taking the time to read the document Magnus - responses below. > > I think the handling of the transport capabilites have to little > functionality. There is need for specifying which RTP payload types > that apply to which transport capabilities. I will list some usages of > this that doesn't seem to work correctly without it or bloody ugly hacks. > > 1. Usage of RTP retransmission (RFC 4588) using payload type > multiplexing. I assume you mean when using session-multiplexing as opposed to SSRC-multiplexing and hence the issue here is one of requiring syncrhonized O/A operation over multiple streams. > In this case the RTP retransmission payload only can be used in cases > when the session uses a profile that has AVPF functionality. If one > offers both AVP and AVPF with CAPNEG then one gets at least one > additional RTP payload type for the AVPF cases. Can RFC 4588 only be used under AVPF profiles ? Regardless, I understand your point, that there are cases where you would like to have this syncrhonized O/A operation. As mentioned above, SSRC-multiplexing works, and if you can do RFC 4588 today, then presumably you have implemented some logic on top of the "pure" O/A procedures to ensure that you do not accept the redundant stream without the primary stream being accepted itself. Also, since there is SSRC and payload type synchronization between the two streams, there is clearly more going on here than pure per-media stream only O/A procedures. Based on that, I'm not sure we in practice get into any new scenarios here; you already have logic in place to accept only potential configuration SDPs that adhere to the principles effectively required by RFC 4588. Taking a step back, the question however is whether this type of functionality should be in scope of the core capabilities negotiation document or not. We only have "per media stream" requirements in the requirements document (draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt). Furthermore, the "media format negotiation" requirement (REQ-10) as well as the inter-media stream requirements are (REQ-150 and REQ-160) are all listed as enchancements, and hence would be covered by an extension rather than the core. This (fairly reduced) scope was the result of a lot of discusions and consideration to people that are primarily interested in addressing the pure transport protocol problem and hence did not want an overly complicated solution. I think your comment here is that you disagree with these requirements, but I think it's a little late for that and also does not align with the general consensus so far. > > 2. Usage of paylaod types that only make sense over particular > transport. For example if one requires RTP/AVP/TCP for a particular > paylaod type to be usable due to reliability requirements. > > As I see it this can be only solved by what I consider a hack. Which > is to overdefine a number of payload types that one doesn't intended > to use to provide sufficient number for other potential > configurations. And I think you need to define them, because leaving > them undefined would to me be against current SDP rules. > > I think this is a hack for several reasons. > > A. It doesn't clearly define which payload types that are intended to > be used in a specific transport. That's not an issue with the capability negotiation framework. The potential configuration, which references capabilities by use of their capability numbers would be used for this. > > B. It forces one to overwrite the RTP payload types, always. Despite > the issues with media delivery prior to receiving answer or having > performed the second round of offer/answer Right. I agree that in order to properly address this, you need an extension. > > C. It prevents this mechanism to in the future be upgraded in a > reasonable way with media cability negotiation. See separate email for > discussion. I'll have a look - I currently don't see the issue. > > I would recommend that one seriously consider using explicit > declaration of the payload type used for each transport in the tcap > attribute. > Your comment could be addressed in many different ways, however we should probably agree on whether we want to address it in the core document first, before getting into the actual solution. Thanks -- Flemming > 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 Mon Jul 23 11:43: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 1ID044-0007c0-Ak; Mon, 23 Jul 2007 11:43:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID042-0007be-Df for mmusic@ietf.org; Mon, 23 Jul 2007 11:43:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID041-0008TX-CA for mmusic@ietf.org; Mon, 23 Jul 2007 11:43:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2007 08:43:12 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgeAK5opEarR7MV/2dsb2JhbACCLzWFe51G X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208,217"; a="506018123:sNHT68362836" 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 l6NFhCYt032445; Mon, 23 Jul 2007 08:43:12 -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 l6NFh8A4028761; Mon, 23 Jul 2007 15:43:08 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); Mon, 23 Jul 2007 08:42:59 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 08:42:58 -0700 Message-ID: <46A4CC82.5090209@cisco.com> Date: Mon, 23 Jul 2007 11:42:58 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Stach, Thomas" Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 23 Jul 2007 15:42:58.0808 (UTC) FILETIME=[25243780:01C7CD40] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8448; t=1185205392; x=1186069392; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Transport=20capabilites= 20and=20RTP=20payload=0A=20types |Sender:=20; bh=ZeDrr4XRcXXE6NDOUkNvJRmKXMOUdGPP/Cq25PQdqvY=; b=iGbKK6KPmb7xbP/D5rXUxHkONKuUrGbP/YxVjtUodLIqpceP8Wx9BF9aV37hcJaBWGHgMK+E OWBeAm5EqqtbZv7LxpaCvGb7fR3qeJ9PMvJOlgBTTz45fl3mGnQoBJsjB80CS0udfzhni9kG+3 qQMLtl0oN0waYQejNg1L2SFJE=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e 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: , Content-Type: multipart/mixed; boundary="===============1062308689==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1062308689== Content-Type: multipart/alternative; boundary="------------050001030207010606020009" This is a multi-part message in MIME format. --------------050001030207010606020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stach, Thomas wrote: > >> As I see it this can be only solved by what I consider a >> hack. Which is >> to overdefine a number of payload types that one doesn't >> intended to use >> to provide sufficient number for other potential >> configurations. And I >> think you need to define them, because leaving them undefined >> would to >> me be against current SDP rules. >> >> I think this is a hack for several reasons. >> >> A. It doesn't clearly define which payload types that are >> intended to be >> used in a specific transport. >> >> B. It forces one to overwrite the RTP payload types, always. >> Despite the >> issues with media delivery prior to receiving answer or >> having performed >> the second round of offer/answer >> >> C. It prevents this mechanism to in the future be upgraded in a >> reasonable way with media cability negotiation. See separate >> email for >> discussion. >> > > > > I see the extensibily problem differently. > As a first step the core spec should disallow different numbers of PTs > I'm not sure what that would actually mean - can you elaborate ? > and > the media capability negotiation should cope with it. > > > >> I would recommend that one seriously consider using explicit >> declaration >> of the payload type used for each transport in the tcap attribute. >> > > As the media capability negotiation already extends the definition of > the a=pcfg attribute, > it could also e.g. extend the a=tcap attribute to allow for inclusion of > payload types as you propose. > However, the ABNF for a=tcap does currently not allow for extensibility. > > My proposal would be to provide for such extensibility in the core I'm somewhat reluctant to doing that. The extensibility would need to be provided in a way where we have clearly defined rules for what to do if you don't support the extentions, don't get into parsing ambiguities, etc. The current format doesn't seem well-suited for that, and we'd clearly need added procedures. However, we already have an extension mechanism defined which would allow you define another kind of "transport protocol + payload type" configuration parameter if needed (my preference would be actually use capability numbers for such a thing, but that's a separate point). > and > tackle the problem within > the media capability negotiation. > Agree the problem should be tackled there. -- Flemming > Regards > Thomas > > > > >> 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 > > --------------050001030207010606020009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stach, Thomas wrote: 
  
As I see it this can be only solved by what I consider a 
hack. Which is 
to overdefine a number of payload types that one doesn't 
intended to use 
to provide sufficient number for other potential 
configurations. And I 
think you need to define them, because leaving them undefined 
would to 
me be against current SDP rules.

I think this is a hack for several reasons.

A. It doesn't clearly define which payload types that are 
intended to be 
used in a specific transport.

B. It forces one to overwrite the RTP payload types, always. 
Despite the 
issues with media delivery prior to receiving answer or 
having performed 
the second round of offer/answer

C. It prevents this mechanism to in the future be upgraded in a 
reasonable way with media cability negotiation. See separate 
email for 
discussion.
    



I see the extensibily problem differently.
As a first step the core spec should disallow different numbers of PTs
I'm not sure what that would actually mean - can you elaborate ? 
and 
the media capability negotiation should cope with it. 


  
I would recommend that one seriously consider using explicit 
declaration 
of the payload type used for each transport in the tcap attribute.
    

As the media capability negotiation already extends the definition of
the a=pcfg attribute,
it could also e.g. extend the a=tcap attribute to allow for inclusion of
payload types as you propose.
However, the ABNF for a=tcap does currently not allow for extensibility.

My proposal would be to provide for such extensibility in the core
I'm somewhat reluctant to doing that. The extensibility would need to be provided in a way where we have clearly defined rules for what to do if you don't support the extentions, don't get into parsing ambiguities, etc. The current format doesn't seem well-suited for that, and we'd clearly need added procedures. However, we already have an extension mechanism defined which would allow you define another kind of "transport protocol + payload type" configuration parameter if needed (my preference would be actually use capability numbers for such a thing, but that's a separate point). 


 and
tackle the problem within 
the media capability negotiation.
Agree the problem should be tackled there.

-- Flemming 
Regards
Thomas



  
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
--------------050001030207010606020009-- --===============1062308689== 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 --===============1062308689==-- From mmusic-bounces@ietf.org Mon Jul 23 11:49: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 1ID0AC-0008Qk-QM; Mon, 23 Jul 2007 11:49:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0AC-0008Pn-4G for mmusic@ietf.org; Mon, 23 Jul 2007 11:49:36 -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 1ID0AB-0001XF-LD for mmusic@ietf.org; Mon, 23 Jul 2007 11:49:36 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Jul 2007 08:49:35 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAAZrpEarR7PE/2dsb2JhbACIX51L X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="9899078:sNHT14719260" 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 l6NFnZDA004054; Mon, 23 Jul 2007 08:49:35 -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 l6NFnZA0006111; Mon, 23 Jul 2007 15:49:35 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); Mon, 23 Jul 2007 08:49:28 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 08:49:28 -0700 Message-ID: <46A4CE07.2090707@cisco.com> Date: Mon, 23 Jul 2007 11:49:27 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities References: <469F9BB7.9040709@ericsson.com> In-Reply-To: <469F9BB7.9040709@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 15:49:28.0285 (UTC) FILETIME=[0D49B0D0:01C7CD41] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2054; t=1185205775; x=1186069775; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Lack=20of=20bandwidth=20 capabilities |Sender:=20; bh=y6mRp4knqMKdEbDIxgl+TkmSRu/0jS9SOLIn9zga6mI=; b=OhcU14goa5X6W9wNfZMVQD2vNeFyvi+GgVMB3kOH/zEBhVX3/LqU/XMWYXSUbakmnRo1awG0 9JULhcD+EWsI5CgLW/w9sYnUvkmBXLrQgETtuyYLtsK8ytFzn9ckjVmV; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: > The current proposal total failes to discuss the bandwidth parameter > in SDP. This is a serious shortcomming and will result in real issues > for the profiles. Different profiles and usages will have different > bandwidth parameters. Although media bandwidth may different for > different potential configurations I think the major issue exist for > the RR and RS attribute which really makes sense to configure > differently for different profiles. For example AVPF with some > feedback may require much more RTCP bandwidth than AVP. And in case > one uses the TFRC addition one may have need for yet another > configuration. Thus there is need to be able to connect different > bandwidth configurations with specific potential configurations. > We don't have a requirement for this currently, however your point is well taken. I think we have two options here: 1) Add a section noting the interaction issue. 2) Add a new requirement to address this and incorporate it (relatively straightforward: we define a "bandwitdh" capability and allow it to be referenced as part of the potential and actual configuration - the original "bandwidth" parameter from the actual configuration would be replaced automatically). I'm open either way and look to the WG for further guidance on this. -- Flemming > 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 Mon Jul 23 12: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 1ID0Kp-00079V-6v; Mon, 23 Jul 2007 12:00:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Kn-00079K-JA for mmusic@ietf.org; Mon, 23 Jul 2007 12:00:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID0Km-0001rv-VW for mmusic@ietf.org; Mon, 23 Jul 2007 12:00:33 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2007 09:00:32 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRANZtpEarR7MV/2dsb2JhbACIX501 X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="167829453:sNHT34182846" 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 l6NG0W0L000999; Mon, 23 Jul 2007 09:00:32 -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 l6NG0V6G010546; Mon, 23 Jul 2007 16:00:32 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); Mon, 23 Jul 2007 09:00:22 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:00:21 -0700 Message-ID: <46A4D094.4040507@cisco.com> Date: Mon, 23 Jul 2007 12:00:20 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Session level coordintation between potential configurations References: <469F9BCD.8070905@ericsson.com> In-Reply-To: <469F9BCD.8070905@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 16:00:21.0929 (UTC) FILETIME=[92E3D990:01C7CD42] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3244; t=1185206432; x=1186070432; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Session=20level=20coordi ntation=20between=09potential=0A=20configurations |Sender:=20; bh=Lp4eWZp3p7pxKNMXu33z67N4IO2AyvX5NsTfPrN0wSg=; b=Bcor65uDKfH/kNPxdvLedfa9Ggrre3dwufC+JbVW7Suyx3oxRjE39uOjbwXpEsl1fNI/0iSR aeeB/pvjjweDOUWiNbJvoSUaA7N9vmHsS/lZJeknGWsPzOfdvOtPaAwSA1kNKFY1eeguzxzAAK FL4+zMGFXqbtaq3HONoZGbNw0=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: > The draft comes to the conclusion that there is no real need for > coordintion between different media descriptions and their potential > configurations. I think that is wrong for several reasons: > > 1. I would start with referening once more to a defined usage in RFC > 4588 (RTP Retransmission). In the case of desire to use session > multiplexing for the retransmission one would only like to use that > under the constraint that one already uses AVPF in the primary > transmission session. Thus one would like to make the following offer: > > Primary session: AVP, potential configuration 1: AVPF with NACK > > Retransmission session: Only used in case primary session selects > potential configuration 1. Agree with your point - we had primarily looked at attribute interactions, but as you note RFC 4588 (and FEC as well I believe) are examples where do you may need inter-media stream syncrhonization of the negotiated parameters (payload formats, etc.). Still, per our limited scope in the core document, and support for extensions, such as media capabilities, I don't believe we need to solve this in the core capabilities document, however we should at least add a note pointing out the above. > > 2. Allow for media capability negotiation. As I see it when moving > into a media capability negotiation extension one will very much like > to present cases where there are set of media configurations. That may > include additional media streams needing their own media descriptions, > i.e. RTP sessions / or other media transport (MSRP). One would in > other words like to express capabilites like. Lets do (Audio, video > and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio > and MSRP) depending on peers capabilities. Without the functionality > to make higher level bindings between potential configurations into > different sets that will not work. > Right - this is well understood I believe, however there has not been consensus to adopt this level of complexity in the core document. Instead the WG consensus is that this type of functionality can be handled in an (optional) extensions. > Unfortunately the above has one very frightening conclusion, we need > to have possibility to do potential configurations for media > descriptions that has no match in the actual configuration. > If you want to address that requirement (which we currently don't have) I agree, however why is that frightening ? -- Flemming > > 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 Mon Jul 23 12:05: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 1ID0Pv-0006YN-AW; Mon, 23 Jul 2007 12:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Pt-0006YG-Ua for mmusic@ietf.org; Mon, 23 Jul 2007 12:05:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID0Ps-0002Bl-JZ for mmusic@ietf.org; Mon, 23 Jul 2007 12:05:49 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 23 Jul 2007 09:05:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgeAMZupEarR7MV/2dsb2JhbACCLzWFe505 X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208,217"; a="7146382:sNHT30113370" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NG5lUt012399; Mon, 23 Jul 2007 09:05:47 -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 l6NG5dU3027376; Mon, 23 Jul 2007 16:05:47 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); Mon, 23 Jul 2007 09:05:45 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:05:44 -0700 Message-ID: <46A4D1D8.30904@cisco.com> Date: Mon, 23 Jul 2007 12:05:44 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Joe Stone (joestone)" Subject: Re: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations References: In-Reply-To: X-OriginalArrivalTime: 23 Jul 2007 16:05:44.0981 (UTC) FILETIME=[5371AC50:01C7CD43] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12459; t=1185206747; x=1186070747; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Session=20level=09coordi ntationbetweenpotential=0A=20configurations |Sender:=20; bh=0Y3xjxj89iy1GCS3qdSGs0Pl7weyBu5bZxyPvjLaQ5k=; b=uBio4/+h7CUghpHAgnMOD9EK49JX6fILDt78MhA0GHCS7KDUKxMvsubMxFiSCIj17WWd8RLS +tiAIfBcNq634YlCOtl8LdbeblagoO3s0aiANCb2ukYiWEVLFoX6BdcKqkEPc8eRJCd8xX7Njx GUYV7A4Q/2MTcGy9ZgYsGZ0mY=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad 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: , Content-Type: multipart/mixed; boundary="===============1460154352==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1460154352== Content-Type: multipart/alternative; boundary="------------040209000901060203000107" This is a multi-part message in MIME format. --------------040209000901060203000107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe Stone (joestone) wrote: > However, I do agree with Magnus that there's a need to negotiate between > groups of media descriptions. I see this as the "big picture". It should > be shown, at least at a high-level, that the transport protocol > negotiation of sdp-capability-negotiation will fit with a more > comprehensive SDP negotiation framework. > Or rather a set of possible extensions to the core framework. We keep going back to scope and requirements here. Currently, we have a separate requirement document (which we don't have any real plans for, e.g. turning into RFC). At one point, we discussed incorporating it into an Appendix to give some people some additional background and motivation for the design and scope. What do people (and the chairs) want to do here: 1) Let the requirements draft expire. 2) Publich requirements draft as a separate RFC 3) Incorporate requirements into an appendix in the core document 4) Something else ? > On a related topic... > > I'm not convinced that sdp-capability-negotiation should obsolete RFC > 3407 given that sdp-capability-negotiation doesn't define equivalent > functionality (at least based on -06). > I'm open either way - current consensus is to obsolete it. -- Flemming > Joe > > -----Original Message----- > From: Stach, Thomas [mailto:thomas.stach@siemens.com] > Sent: Friday, July 20, 2007 5:25 AM > To: Magnus Westerlund; mmusic (E-mail) > Subject: RE: [MMUSIC] SDPCapNeg-06: Session level > coordintationbetweenpotential configurations > > Magnus, > > more inline. > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, July 19, 2007 7:14 PM >> To: mmusic (E-mail) >> Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation >> betweenpotential configurations >> >> The draft comes to the conclusion that there is no real need for >> coordintion between different media descriptions and their potential >> configurations. I think that is wrong for several reasons: >> >> 1. I would start with referening once more to a defined usage in RFC >> 4588 (RTP Retransmission). In the case of desire to use session >> multiplexing for the retransmission one would only like to use that >> under the constraint that one already uses AVPF in the primary >> transmission session. Thus one would like to make the following offer: >> >> Primary session: AVP, potential configuration 1: AVPF with NACK >> >> Retransmission session: Only used in case primary session selects >> potential configuration 1. >> > > In other words this means an actual configuration with one m-line and a > potential configuration with two m-lines. > Would it help if the problem is described in the core spec, but not > solved? > My intention is to keep the core spec as simple as possible, but to > state its restrictions. > > >> 2. Allow for media capability negotiation. As I see it when moving >> into a media capability negotiation extension one will very much like >> to present cases where there are set of media configurations. That may >> > > >> include additional media streams needing their own media descriptions, >> > > >> i.e. RTP sessions / or other media transport (MSRP). One would in >> other words like to express capabilites like. Lets do (Audio, video >> and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio >> and MSRP) depending on peers capabilities. Without the functionality >> to make higher level bindings between potential configurations into >> different sets that will not work. >> > > Here I think we must decide how far we want go with media capability > negotiation. > > >> Unfortunately the above has one very frightening conclusion, we need >> to have possibility to do potential configurations for media >> descriptions that has no match in the actual configuration. >> > > I'm not sure how frightening that is from specification perspective > (e.g. an a=mcap for additional m-lines could do), but it surely is for > an implementor. > > Regards > Thomas > > >> 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 > > --------------040209000901060203000107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Joe Stone (joestone) wrote: 
However, I do agree with Magnus that there's a need to negotiate between
groups of media descriptions. I see this as the "big picture". It should
be shown, at least at a high-level, that the transport protocol
negotiation of sdp-capability-negotiation will fit with a more
comprehensive SDP negotiation framework.
Or rather a set of possible extensions to the core framework.

We keep going back to scope and requirements here. Currently, we have a separate requirement document (which we don't have any real plans for, e.g. turning into RFC). At one point, we discussed incorporating it into an Appendix to give some people some additional background and motivation for the design and scope. What do people (and the chairs) want to do here:
1) Let the requirements draft expire.
2) Publich requirements draft as a separate RFC
3) Incorporate requirements into an appendix in the core document
4) Something else ? 

On a related topic...

I'm not convinced that sdp-capability-negotiation should obsolete RFC
3407 given that sdp-capability-negotiation doesn't define equivalent
functionality (at least based on -06).
I'm open either way - current consensus is to obsolete it.

-- Flemming 

Joe

-----Original Message-----
From: Stach, Thomas [mailto:thomas.stach@siemens.com] 
Sent: Friday, July 20, 2007 5:25 AM
To: Magnus Westerlund; mmusic (E-mail)
Subject: RE: [MMUSIC] SDPCapNeg-06: Session level
coordintationbetweenpotential configurations

Magnus,

more inline. 

  
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Thursday, July 19, 2007 7:14 PM
To: mmusic (E-mail)
Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation 
betweenpotential configurations

The draft comes to the conclusion that there is no real need for 
coordintion between different media descriptions and their potential 
configurations. I think that is wrong for several reasons:

1. I would start with referening once more to a defined usage in RFC
4588 (RTP Retransmission). In the case of desire to use session 
multiplexing for the retransmission one would only like to use that 
under the constraint that one already uses AVPF in the primary 
transmission session. Thus one would like to make the following offer:

Primary session: AVP, potential configuration 1: AVPF with NACK

Retransmission session: Only used in case primary session selects 
potential configuration 1.
    

In other words this means an actual configuration with one m-line and a
potential configuration with two m-lines.
Would it help if the problem is described in the core spec, but not
solved?
My intention is to keep the core spec as simple as possible, but to
state its restrictions.

  
2. Allow for media capability negotiation. As I see it when moving 
into a media capability negotiation extension one will very much like 
to present cases where there are set of media configurations. That may
    

  
include additional media streams needing their own media descriptions,
    

  
i.e. RTP sessions / or other media transport (MSRP). One would in 
other words like to express capabilites like. Lets do (Audio, video 
and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio 
and MSRP) depending on peers capabilities. Without the functionality 
to make higher level bindings between potential configurations into 
different sets that will not work.
    

Here I think we must decide how far we want go with media capability
negotiation.

  
Unfortunately the above has one very frightening conclusion, we need 
to have possibility to do potential configurations for media 
descriptions that has no match in the actual configuration.
    

I'm not sure how frightening that is from specification perspective
(e.g. an a=mcap for additional m-lines could do), but it surely is for
an implementor.

Regards
Thomas

  
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
--------------040209000901060203000107-- --===============1460154352== 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 --===============1460154352==-- From mmusic-bounces@ietf.org Mon Jul 23 12:20: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 1ID0dl-0004Tu-2Z; Mon, 23 Jul 2007 12:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0di-0004TY-Pl; Mon, 23 Jul 2007 12:20:06 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID0di-0002X1-7n; Mon, 23 Jul 2007 12:20:06 -0400 Received: from dhcp-1398.ietf69.org ([130.129.19.152]:54073) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1ID0dh-0003Mo-E3; Mon, 23 Jul 2007 17:20:05 +0100 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: <96AB315B-327A-49AF-83CA-A4012F6A5153@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Mon, 23 Jul 2007 11:20:06 -0500 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tsvwg WG , MMUSIC WG Subject: [MMUSIC] Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-udp-guidelines-02.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 On 9 Jul 2007, at 04:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Area Working Group > Working Group of the IETF. > > > Title : UDP Usage Guidelines for Application > Designers > Author(s) : L. Eggert, G. Fairhurst > Filename : draft-ietf-tsvwg-udp-guidelines-02.txt > Pages : 15 > Date : 2007-07-09 > > The User Datagram Protocol (UDP) provides a minimal, message-passing > transport that has no inherent congestion control mechanisms. > Because congestion control is critical to the stable operation of the > Internet, applications and upper-layer protocols that choose to use > UDP as an Internet transport must employ mechanisms to prevent > congestion collapse and establish some degree of fairness with > concurrent traffic. This document provides guidelines on the use of > UDP for the designers of such applications and upper-layer protocols > that cover congestion-control and other topics, including message > sizes, reliability, checksums and middlebox traversal. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp- > guidelines-02.txt Section 3.5 states: Applications MAY in addition send periodic keep-alive messages to attempt to refresh middlebox state. Unfortunately, no common timeout has been specified for per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787] requires a state timeout of 2 minutes or longer, and it is likely that other types of middleboxes use timeouts of similar timescales. Consequently, if applications choose to send periodic keep-alives, they SHOULD NOT send them more frequently than once every two minutes. (Not that some deployed middleboxes use a shorter timeout value than 2 minutes, violating [RFC4787].) which is fine, except that draft-ietf-mmusic-ice-17 suggests a 15 second keep alive interval by default. Can we align these? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 23 12:23: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 1ID0h2-00053t-50; Mon, 23 Jul 2007 12:23:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0h0-00053o-8a for mmusic@ietf.org; Mon, 23 Jul 2007 12:23:30 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0gz-0001Og-JD for mmusic@ietf.org; Mon, 23 Jul 2007 12:23:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2007 09:23:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAFxzpEarR7O6/2dsb2JhbACIX50z X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="186984790:sNHT2496236409" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NGNSJC022264; Mon, 23 Jul 2007 09:23:28 -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 l6NGNR6G005174; Mon, 23 Jul 2007 16:23:27 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); Mon, 23 Jul 2007 09:23:24 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:23:24 -0700 Message-ID: <46A4D5FB.9010705@cisco.com> Date: Mon, 23 Jul 2007 12:23:23 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Usage of truncated syntax as capability definitions References: <469F9BD7.7070308@ericsson.com> In-Reply-To: <469F9BD7.7070308@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 16:23:24.0148 (UTC) FILETIME=[CAC1BB40:01C7CD45] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3807; t=1185207808; x=1186071808; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Usage=20of=20truncated=2 0syntax=20as=20capability=0A=20definitions |Sender:=20; bh=VS9UuVXfCRMsSkXtjsvFeUQ+B3GA4tOfWYaNEGHmXuw=; b=gt9IYtB26/BEsyKgPHolAkIS1MzH57Nvcchl2XvImMycoof4dXYLPxNZEXt+PNJI4d0UmvD4 SjS32hpye2vBg7QqDx0+WHRCHQylvgbzyxwQifcfTixKUEUwUmDHpGCT; Authentication-Results: sj-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: > I find the suggestion that one uses truncated SDP attributes as an > indication that one has a capability very worrying. The reason I think > that is that it is ambigous in addition to breaking the defined syntax > of attributes. In short there are in most cases no defined meaning for > a SDP attribute without its value. To make a general rule without > explicit defining that meaning for different attributes will be > causing ambiogus results. The idea was to allow for such capabilities to be defined, but not for them to actually be used; this would strictly limit the use to the capability negotiation framework itself (since the contained attribute . However, in looking through the document, I can't seem to find text that prevents such attribute capabilities from being used by a potential configuration. If I either find it or add text to that effect, would that address your concern ? The reason the functionality is in there is primarily because we had it in RFC 3407. From a capability point of view, I think there are use cases for this (e.g. indicate that you support the "crypto" attribute without necessarily listing all the necessary parameters for it), and with the above clarifications, I don't believe it's harmful in any way either. > Lets look at some examples of this. > > 1. a=rtpmap: in the form "a=rtpmap" it says nothing that rtp/avp > hasen't already told you. "a=rtpmap: 97 AMR/8000" does provide some > information about that you have some type of support for AMR. But it > doesn't tell you what support in regards to payload configurations. In > fact even with a single a=fmtp line you only know that one out of > several different configurations are supported. To declare your > capabilites for which AMR payload configurations you suport, you > actually need a matrix over the features. That can't be done without > explicit definition of how AMR is going to be interpreted and > preferably in another syntax then what is used to provide a single > configuration. > > 2. I think "a=rtcp-fb" is another one that has similar issues as AMR. > In this case even worse as it combines with RTP payload formats for > the payload specific feedback messages. For example PLI may be > supported for some video codecs and not others. Thus requiring one to > list the media types which one supports PLI with. > > I would suggest that one actually uses another attribute for defining > capabilities and for that create a structure that allows different > capabilities to be explicitly defined for each functionality > separately. Overloading capability definitions on SDP attributes > defined for configuration is not a good idea. > The attribute and transport protocol capabilities defined in the document are intended to be capabilities, not just configuration lists (we have the potential configuration attribute for that). Having said that, I agree that you can construct more elaborate capability structures, but would rather not go there in the core document. -- Flemming > > 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 Jul 23 12: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 1ID0j7-0005Ws-H5; Mon, 23 Jul 2007 12:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0j6-0005WW-F9 for mmusic@ietf.org; Mon, 23 Jul 2007 12:25:40 -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 1ID0j5-0002fP-61 for mmusic@ietf.org; Mon, 23 Jul 2007 12:25:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2007 09:25:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAHdzpEarR7PE/2dsb2JhbACIX500 X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="387460132:sNHT29577076" 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 l6NGPcIG009514; Mon, 23 Jul 2007 09:25:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6NGPcSb015606; Mon, 23 Jul 2007 16:25:38 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); Mon, 23 Jul 2007 09:25:38 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:25:38 -0700 Message-ID: <46A4D681.9030602@cisco.com> Date: Mon, 23 Jul 2007 12:25:37 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <467FF802.9050909@cisco.com> <469F9BE3.5080804@ericsson.com> In-Reply-To: <469F9BE3.5080804@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 16:25:38.0106 (UTC) FILETIME=[1A9A19A0:01C7CD46] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3015; t=1185207938; x=1186071938; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#5=3A=20Media=20before =20answer |Sender:=20; bh=jZBid8uHsmW1NKh8pPE06zrWUuSs1fuGNTeEV4QxR3o=; b=GaHV+PAqbVO6XqpsRWmGnSPHlTkUdffM+eEJsf89Jy/R+2buflzq8HHefCtTK0YyjlTVOubd wFkXsquInLa3/LT12FV74ljHy5amV5L6si/xOWNY6nAx92VbwAZquNJQ; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mmusic 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: > Hi, > > I think it is quite important to try to avoid sending media if the > answerer do not use the actual configuration. This due to the problem > with the receivier not knowing what to do with this media. > > A related issue is that of send direction configuration information > that for example H.264 over RTP suffers from. A device sending media > needs to provide the receiver with some configuration information to > enable it to decode things. This doesn't work particular well in > normal offer/answer. In cases when the sender correctly can guess the > configuration in the answer it works. But if the answerer changes the > configuration it accepts to receive with things stops working well. > This can be helped by providing potential configurations that narrows > things down to have the answerer select a potential configuration that > it actually can use. > > But in these cases it is quite clear, even if all potential > configurations are AVP they still can't decode them because they are > likely to use the same payload type number. Do you have any concerns with the relevant text on this point in the draft right now (if so, which parts ?) Thanks -- Flemming > > Cheers > > Magnus > > > Flemming Andreasen skrev: >> The answerer may select a potential configuration containing >> parameters that require the offerer to receive the answer before he >> can process media correctly. The issue is explained in Section 3.8 in >> the SDP Capability Negotiation framework, where one possible >> solutions is outlined (preconditions), but not actually specified. >> The question was raised whether we want to say more about this issue >> and if we want to define additional solutions to it. For example, >> Jonathan Rosenberg suggested that use of ICE can help the answerer >> determine when the answer has been received by the offerer and hence >> it is safe to send media to the offerer. >> >> The design team discussed this issue in Prague and agreed to >> elaborate slightly on the current text. It will be noted that the >> offerer can discard media until he receives the answer, if he wants >> to make sure he doesn't play garbage. If the offerer wants to avoid >> clipping on the other hand, he can play media as soon as it is >> received, but at the risk of playing garbage. To avoid both, a >> three-way handshake is needed (e.g. precondtion), however that is >> outside the basic SDP Capability Negotiation. We will add a note to >> mention the use of ICE (STUN) as a possible solution to this >> three-way handshake as well. >> >> If you disagree with this, please let me know. >> >> Thanks >> >> -- Flemming >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Jul 23 12:26: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 1ID0jR-0005jn-Vv; Mon, 23 Jul 2007 12:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0jR-0005jb-5x for mmusic@ietf.org; Mon, 23 Jul 2007 12:26:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID0jP-0002fv-Oa for mmusic@ietf.org; Mon, 23 Jul 2007 12:26:01 -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 l6NGPw0s018296 for ; Mon, 23 Jul 2007 10:25:58 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 23 Jul 2007 10:25:58 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/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: [MMUSIC] slides for IETF69 Date: Mon, 23 Jul 2007 10:24:46 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C63AF5CC@srvxchg3.cablelabs.com> In-Reply-To: <46A487BA.6020307@nsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] slides for IETF69 Thread-Index: AcfNF2AK5Nw0A1rqRV+wvUnMQzM2GgALfKHg References: <46A3AE3B.3010908@estacado.net> <46A487BA.6020307@nsn.com> From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 you plan on presenting slides for the 2 mmusic sessions, please send the slides to mmusic-chairs@ietf.org (if possible by early tomorrow morning Chicago time). Thank you in advance, Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 23 12:35: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 1ID0sC-0006ss-Vo; Mon, 23 Jul 2007 12:35:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0sB-0006hB-14 for mmusic@ietf.org; Mon, 23 Jul 2007 12:35:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0sA-0001hB-Bx for mmusic@ietf.org; Mon, 23 Jul 2007 12:35:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2007 09:35:01 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRANp1pEarR7PE/2dsb2JhbACIX51G X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="506038383:sNHT76457944" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6NGZ1eX028011; Mon, 23 Jul 2007 09:35:01 -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 l6NGYv6Q016811; Mon, 23 Jul 2007 16:35:01 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); Mon, 23 Jul 2007 09:34:43 -0700 Received: from [10.21.88.33] ([10.21.88.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 09:34:42 -0700 Message-ID: <46A4D8A2.8060203@cisco.com> Date: Mon, 23 Jul 2007 12:34:42 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Media capabilites negotiation References: <469F9BDE.2090109@ericsson.com> In-Reply-To: <469F9BDE.2090109@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 16:34:42.0731 (UTC) FILETIME=[5F3947B0:01C7CD47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3549; t=1185208501; x=1186072501; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Media=20capabilites=20ne gotiation |Sender:=20; bh=pj/PI3w2hsw9f9MEhfQ0WN/dWx8IY0jt2ielxnBno/4=; b=H7UGBFPlqLp5UO+pSjFZ/OqIy7AgyKaBZvjrNoxIxVBtgMCfmIhx/k3kslthSFcjA1R08y+T Xe1pYYcJfeuQtsUjxcRA7MuhQlMk6CIv1fY02XS83/BDdrxyCFz/Eale; Authentication-Results: sj-dkim-4; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: > I would like to expand a bit on what I consdier being media > capabilites negotiation. It has quite some implications for the > SDPCapNeg definition. However, I don't think that the full solution > needs to be included in the core spec. It could be an extension if > some capabilites of the core exist. But lets start on what I would > like to see as possible and what it would be used for. > > In the requirements document requirement 10 exist which says: > > REQ-10: It MUST be possible to indicate and negotiate alternative > media formats on a per media stream basis. > > For example, many implementations support multiple codecs, but > only one at a time. Changes between codecs cannot be done on- > the-fly, e.g. when receiving a simple RTP payload type change. > Pleaes note that requirement 10 is not in scope for the core document but instead is an enhancement (per REQ-310) > However, to my knowledge that is not the close to the whole truth for > devices with limited capabilites. Because they not be able to provide > certain codecs when another media streams uses a particular codec. A > good example would be that a device can't decode AAC when combined > with H.264 while it could do AAC when doing H.263. Such constraints > are complex to describe Agreed - I believe REQ-160 talks about this (out of scope as well). > > In addition there is the issue of correctly describe what ones > capabilites are in regards to a specific media format. This is > actually a combination of the device capabilites in regards to the > payload format, transport and encoding/decoding. Thus another language > is need than the one used to configure devices when describing > capabilites. For example in a capability language one can do efficient > encoding of independent capabilites while configurations needs to list > all permutations. > > There is also the issues around configuring more advanced relations > for media which I already brought up in the other emails. This include > issues with: > > - Media before answer > - Media descriptions dependent on other media descriptions > - Media configurations depending on transport > > There should be consideration on these issues and what it means for > the core of the proposal. I'm not sure how to address this comment without effectively halting further progress until we have the media capabilities work done. While I agree it would be desirable to have the media capabilities work done as validation that we can address the extensions you are looking for, I think it would add significant delay and so far there hasn't been somewhat limited interest in solving the whole media capabilities negotiation issue. Can you propose something here ? Thanks -- Flemming > > 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 Mon Jul 23 14:24: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 1ID2a8-0001Hi-V9; Mon, 23 Jul 2007 14:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2a7-0001HY-EF for mmusic@ietf.org; Mon, 23 Jul 2007 14:24:31 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID2a5-0006LE-Hz for mmusic@ietf.org; Mon, 23 Jul 2007 14:24:31 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id l6NIOE2n010581; Mon, 23 Jul 2007 20:24:14 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6NIODRB001262; Mon, 23 Jul 2007 20:24:13 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jul 2007 20:24:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types Date: Mon, 23 Jul 2007 20:24:09 +0200 Message-ID: In-Reply-To: <46A4CC82.5090209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types Thread-Index: AcfNQEUmBcZQ++1BTtm9kxr8pPwQfQAFLjPA References: <469F9B92.3060906@ericsson.com> <46A4CC82.5090209@cisco.com> From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 23 Jul 2007 18:24:12.0670 (UTC) FILETIME=[AB3669E0:01C7CD56] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070723202414-4AFB1BB0-4AF2EBA3/0-0/0-15 X-purgate-size: 10822/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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: , Content-Type: multipart/mixed; boundary="===============0188750619==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0188750619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CD56.AAF34B68" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CD56.AAF34B68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Flemming, =20 inline < snip> =20 =09 =09 =09 I see the extensibily problem differently. As a first step the core spec should disallow different numbers of PTs =20 I'm not sure what that would actually mean - can you elaborate ? [Stach Thomas] What I mean is that the scope of the core spec does not include the scenario mentioned by Magnus. In order to discourage people to implement the hack that Magnus mentioned, some guidance could be given in the core spec.=20 That should refer people to the media capability negotiation, if they want to tackle scenarios where different numbers of payload types (or m-lines) appear in actual and potential configurations. =09 and=20 the media capability negotiation should cope with it.=20 =09 =09 =20 I would recommend that one seriously consider using explicit=20 declaration=20 of the payload type used for each transport in the tcap attribute. =20 =09 As the media capability negotiation already extends the definition of the a=3Dpcfg attribute, it could also e.g. extend the a=3Dtcap attribute to allow for inclusion of payload types as you propose. However, the ABNF for a=3Dtcap does currently not allow for extensibility. =09 My proposal would be to provide for such extensibility in the core I'm somewhat reluctant to doing that. The extensibility would need to be provided in a way where we have clearly defined rules for what to do if you don't support the extentions, don't get into parsing ambiguities, etc. The current format doesn't seem well-suited for that, and we'd clearly need added procedures. However, we already have an extension mechanism defined which would allow you define another kind of "transport protocol + payload type" configuration parameter if needed (my preference would be actually use capability numbers for such a thing, but that's a separate point).=20 [Stach Thomas] Shortly after writing my comment, I came to the same conclusion that the already defined extension mechanisn could serve the same purpose. Extensibility of the tcap attribute is not necessary. =20 Regards Thomas =20 =09 =09 and tackle the problem within=20 the media capability negotiation. =20 Agree the problem should be tackled there.=20 =09 -- Flemming=20 =09 Regards Thomas =09 =09 =09 =20 Cheers =09 Magnus Westerlund =09 IETF Transport Area Director & TSVWG Chair =09 ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M =09 ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com =09 ---------------------------------------------------------------------- =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 ------_=_NextPart_001_01C7CD56.AAF34B68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

Flemming,
 
inline
  < snip>  



I see the extensibily problem differently.
As a first step the core spec should disallow different numbers of PTs
I'm not sure what that would actually mean - can you elaborate ?=20
[Stach Thomas] What I mean is that the scope of the core = spec does=20 not include the scenario mentioned by Magnus. In order to discourage=20 people
to=20 implement the hack that Magnus mentioned, some guidance could be given = in the=20 core spec.
That=20 should refer people to the media capability  negotiation, if = they=20 want to tackle scenarios where different numbers of payload types (or = m-lines)=20 appear in actual and potential configurations.
and=20
the media capability negotiation should cope with it.=20


  
I would recommend that one =
seriously consider using explicit=20
declaration=20
of the payload type used for each transport in the tcap attribute.
    

As the media capability negotiation already extends the definition of
the a=3Dpcfg attribute,
it could also e.g. extend the a=3Dtcap attribute to allow for inclusion =
of
payload types as you propose.
However, the ABNF for a=3Dtcap does currently not allow for =
extensibility.

My proposal would be to provide for such extensibility in the =
core
I'm somewhat reluctant to doing that. The extensibility would = need to be=20 provided in a way where we have clearly defined rules for what to do = if you=20 don't support the extentions, don't get into parsing ambiguities, etc. = The=20 current format doesn't seem well-suited for that, and we'd clearly = need added=20 procedures. However, we already have an extension mechanism defined = which=20 would allow you define another kind of "transport protocol + payload = type"=20 configuration parameter if needed (my preference would be actually use = capability numbers for such a thing, but that's a separate point). =
[Stach=20 Thomas] Shortly after writing my comment, I came to the same = conclusion=20 that the already defined extension mechanisn could serve the same=20 purpose.
Extensibility of = the tcap attribute=20 is not necessary.
 
Regards
Thomas  

 and
tackle the problem within=20
the media capability negotiation.
Agree the problem should be tackled there. =

--=20 Flemming 
Regards
Thomas



  
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
------_=_NextPart_001_01C7CD56.AAF34B68-- --===============0188750619== 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 --===============0188750619==-- From mmusic-bounces@ietf.org Mon Jul 23 14:29: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 1ID2ey-0002qR-5K; Mon, 23 Jul 2007 14:29:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2ew-0002qM-QE for mmusic@ietf.org; Mon, 23 Jul 2007 14:29:30 -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 1ID2ew-0006Qt-CQ for mmusic@ietf.org; Mon, 23 Jul 2007 14:29:30 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2007 11:29:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAIaQpEarR7PD/2dsb2JhbACIX5st X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="387497876:sNHT38206638" 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 l6NITT1C002526 for ; Mon, 23 Jul 2007 11:29:29 -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 l6NITT6C011503 for ; Mon, 23 Jul 2007 18:29:29 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); Mon, 23 Jul 2007 11:29:29 -0700 Received: from [10.21.86.195] ([10.21.86.195]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 11:29:28 -0700 Message-ID: <46A4F387.2020400@cisco.com> Date: Mon, 23 Jul 2007 14:29:27 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat References: <46A2C40C.30003@cisco.com> In-Reply-To: <46A2C40C.30003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 18:29:29.0004 (UTC) FILETIME=[67C326C0:01C7CD57] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2148; t=1185215369; x=1186079369; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20Comments=20on=20draft-ietf-mmusic-sdp-capability-nego tiation-06 |Sender:=20; bh=04XQBH18W1SSJYIaVzRgopxcVrilCBo68O7S1IN4CsE=; b=lHCJ96qTYQP/QKctWcTJR9l0tmdPT5K/A8ElwwGDzbKSaRuDdNHpTAhlM2AfCfdUG9hdP1iX yrBSvExgVAuKv1AqeQplEF/f5L+mjWtGVHDn+9QycztD7IOXOvcuPTC1; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IETF MMUSIC WG Subject: [MMUSIC] Re: Comments on draft-ietf-mmusic-sdp-capability-negotiation-06 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 Paul Kyzivat wrote: > Flemming, > > I have been studiously avoiding all the earlier versions of this > draft, because it clearly required more bandwidth than I was prepared > to devote. Now that it is almost done I decided to read it. > > This is an impressive piece of work. You have managed to wedge a huge > increase in functionality into a format that really isn't well suited > to it. While the result is still ugly, in the context of SDP it is > really quite elegant. > Thanks Paul, and thank you for doing a review. > I was looking for issues in all the corners, but it seems somebody > generally beat me to it, so almost all of the ones I thought I had > found were covered by subsequent text. > > I think I found one thing that wasn't covered: > >> 3.7.3. Offerer Processing of the Answer > ... >> For each media description where the offerer included a >> potential >> configuration attribute ("a=pcfg"), the offerer MUST first >> examine >> the media description for the presence of an actual >> configuration >> attribute ("a=acfg"). If an actual configuration attribute is >> not >> present in a media description, then the offerer MUST process >> the >> answer SDP for that media stream per the normal offer/answer >> rules >> defined in [RFC3264]. ... > > Something seems to be missing here. > > If there is more than one media description in the answer, and one > contains a=acfg and the other does not, then the one that does may > cause a change in session level attributes, and that can affect the > way the media description without a=acfg is processed. > > There is text covering this for the offerer, but it is lacking here in > the procedures for the answerer. Good point. I will add a note pointing out this potential issue and noting that the session-level attribute added will apply to all the media descriptions, whether they used the capability negotiation framework or not. > That is the only thing I could find. Congratulations! Thanks -- Flemming > > Thanks, > Paul > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 23 14:33: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 1ID2iM-00082p-73; Mon, 23 Jul 2007 14:33:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2iK-00082e-Nc for mmusic@ietf.org; Mon, 23 Jul 2007 14:33:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID2iJ-0005XL-OL for mmusic@ietf.org; Mon, 23 Jul 2007 14:33:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2007 11:32:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAIaQpEarR7PD/2dsb2JhbACCZIV7my0 X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208,217"; a="187059918:sNHT87787665" 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 l6NIWx9X009746; Mon, 23 Jul 2007 11:32:59 -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 l6NIWtA8025751; Mon, 23 Jul 2007 18:32:59 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); Mon, 23 Jul 2007 11:32:56 -0700 Received: from [10.21.86.195] ([10.21.86.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 11:32:56 -0700 Message-ID: <46A4F457.5050404@cisco.com> Date: Mon, 23 Jul 2007 14:32:55 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Stach, Thomas" Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> <46A4CC82.5090209@cisco.com> In-Reply-To: X-OriginalArrivalTime: 23 Jul 2007 18:32:56.0512 (UTC) FILETIME=[E3725C00:01C7CD57] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8016; t=1185215579; x=1186079579; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Transport=20capabilites= 20and=20RTP=20payload=0A=20types |Sender:=20; bh=chnV3KdPgfOoxOlcrCJywyxXr8W5dk/cA1D3Uk4Zb2M=; b=QrM3BuPVBjz2kZ2uhmCTbqs9n4o1e3S5vv7hN60SXXAQiJNtV1aIkXATPKZ4OLK6RPPVOeFC 3UtX4jAV4t+j8lwGdsPyuKrEYebirua4ulsHI31+buklUDrea3HWz8a/; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e 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: , Content-Type: multipart/mixed; boundary="===============2127482127==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============2127482127== Content-Type: multipart/alternative; boundary="------------020500080301050202010803" This is a multi-part message in MIME format. --------------020500080301050202010803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stach, Thomas wrote: > > > Flemming, > > inline > > < snip> >> >> >> >> I see the extensibily problem differently. >> As a first step the core spec should disallow different numbers of PTs >> > I'm not sure what that would actually mean - can you elaborate ? > [Stach Thomas] What I mean is that the scope of the core spec does > not include the scenario mentioned by Magnus. In order to > discourage people > to implement the hack that Magnus mentioned, some guidance could > be given in the core spec. > That should refer people to the media capability negotiation, if > they want to tackle scenarios where different numbers of payload > types (or m-lines) appear in actual and potential configurations. > As long as we can do that with a "for example" reference and hence have it as an informative reference, I'm fine with that. > >> and >> the media capability negotiation should cope with it. >> >> >> >>> I would recommend that one seriously consider using explicit >>> declaration >>> of the payload type used for each transport in the tcap attribute. >>> >> >> As the media capability negotiation already extends the definition of >> the a=pcfg attribute, >> it could also e.g. extend the a=tcap attribute to allow for inclusion of >> payload types as you propose. >> However, the ABNF for a=tcap does currently not allow for extensibility. >> >> My proposal would be to provide for such extensibility in the core > I'm somewhat reluctant to doing that. The extensibility would need > to be provided in a way where we have clearly defined rules for > what to do if you don't support the extentions, don't get into > parsing ambiguities, etc. The current format doesn't seem > well-suited for that, and we'd clearly need added procedures. > However, we already have an extension mechanism defined which > would allow you define another kind of "transport protocol + > payload type" configuration parameter if needed (my preference > would be actually use capability numbers for such a thing, but > that's a separate point). > [Stach Thomas] Shortly after writing my comment, I came to the > same conclusion that the already defined extension mechanisn could > serve the same purpose. > Extensibility of the tcap attribute is not necessary. > Sounds good. Thanks -- Flemming --------------020500080301050202010803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stach, Thomas wrote:
 

Flemming,
 
inline
  < snip>  



I see the extensibily problem differently.
As a first step the core spec should disallow different numbers of PTs
I'm not sure what that would actually mean - can you elaborate ?
[Stach Thomas] What I mean is that the scope of the core spec does not include the scenario mentioned by Magnus. In order to discourage people
to implement the hack that Magnus mentioned, some guidance could be given in the core spec.
That should refer people to the media capability  negotiation, if they want to tackle scenarios where different numbers of payload types (or m-lines) appear in actual and potential configurations.
As long as we can do that with a "for example" reference and hence have it as an informative reference, I'm fine with that. 
and 
the media capability negotiation should cope with it. 


  
I would recommend that one seriously consider using explicit 
declaration 
of the payload type used for each transport in the tcap attribute.
    

As the media capability negotiation already extends the definition of
the a=pcfg attribute,
it could also e.g. extend the a=tcap attribute to allow for inclusion of
payload types as you propose.
However, the ABNF for a=tcap does currently not allow for extensibility.

My proposal would be to provide for such extensibility in the core
I'm somewhat reluctant to doing that. The extensibility would need to be provided in a way where we have clearly defined rules for what to do if you don't support the extentions, don't get into parsing ambiguities, etc. The current format doesn't seem well-suited for that, and we'd clearly need added procedures. However, we already have an extension mechanism defined which would allow you define another kind of "transport protocol + payload type" configuration parameter if needed (my preference would be actually use capability numbers for such a thing, but that's a separate point).
[Stach Thomas] Shortly after writing my comment, I came to the same conclusion that the already defined extension mechanisn could serve the same purpose.
Extensibility of the tcap attribute is not necessary.

Sounds good.

Thanks

-- Flemming


--------------020500080301050202010803-- --===============2127482127== 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 --===============2127482127==-- From mmusic-bounces@ietf.org Mon Jul 23 14:51: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 1ID30X-0008QF-9v; Mon, 23 Jul 2007 14:51:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID30V-0008Oz-Dg for mmusic@ietf.org; Mon, 23 Jul 2007 14:51:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID30U-0006Ox-4C for mmusic@ietf.org; Mon, 23 Jul 2007 14:51:47 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 85A0A2102B; Mon, 23 Jul 2007 20:51:45 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-39-46a4f8c1e561 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6151620424; Mon, 23 Jul 2007 20:51: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, 23 Jul 2007 20:51:45 +0200 Received: from [138.85.12.20] ([138.85.12.20]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 20:51:44 +0200 Message-ID: <46A4F8BF.6030504@ericsson.com> Date: Mon, 23 Jul 2007 20:51:43 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> <46A4CB73.1010701@cisco.com> In-Reply-To: <46A4CB73.1010701@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 18:51:44.0970 (UTC) FILETIME=[840F62A0:01C7CD5A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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, See comments inline. Flemming Andreasen skrev: > > > Magnus Westerlund wrote: >> Hi, >> >> I have finally read the SDP capapbility draft in sufficient detail to >> think I understand it mostly. There is likely some details that I have >> gotten wrong. But I have found some issues that I need to raise for >> discussion. I will split this into separate emails for each topic. > Thanks for taking the time to read the document Magnus - responses below. >> >> I think the handling of the transport capabilites have to little >> functionality. There is need for specifying which RTP payload types >> that apply to which transport capabilities. I will list some usages of >> this that doesn't seem to work correctly without it or bloody ugly hacks. >> >> 1. Usage of RTP retransmission (RFC 4588) using payload type >> multiplexing. > I assume you mean when using session-multiplexing as opposed to > SSRC-multiplexing and hence the issue here is one of requiring > syncrhonized O/A operation over multiple streams. Yes. Sorry for mixing up the language. >> In this case the RTP retransmission payload only can be used in cases >> when the session uses a profile that has AVPF functionality. If one >> offers both AVP and AVPF with CAPNEG then one gets at least one >> additional RTP payload type for the AVPF cases. > Can RFC 4588 only be used under AVPF profiles ? Well, you can use the payload format in AVP but then you lack the NACK format to request any retransmissions with. Regardless, I > understand your point, that there are cases where you would like to have > this syncrhonized O/A operation. As mentioned above, SSRC-multiplexing > works, and if you can do RFC 4588 today, then presumably you have > implemented some logic on top of the "pure" O/A procedures to ensure > that you do not accept the redundant stream without the primary stream > being accepted itself. Also, since there is SSRC and payload type > synchronization between the two streams, there is clearly more going on > here than pure per-media stream only O/A procedures. Based on that, I'm > not sure we in practice get into any new scenarios here; you already > have logic in place to accept only potential configuration SDPs that > adhere to the principles effectively required by RFC 4588. However, that uses grouping of media lines. An without a reasonable support of grouping of media lines for potential configuration that will not work. Thus, as I see it this is a problem. > > > Taking a step back, the question however is whether this type of > functionality should be in scope of the core capabilities negotiation > document or not. We only have "per media stream" requirements in the > requirements document > (draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt). > Furthermore, the "media format negotiation" requirement (REQ-10) as well > as the inter-media stream requirements are (REQ-150 and REQ-160) are all > listed as enchancements, and hence would be covered by an extension > rather than the core. This (fairly reduced) scope was the result of a > lot of discusions and consideration to people that are primarily > interested in addressing the pure transport protocol problem and hence > did not want an overly complicated solution. I think your comment here > is that you disagree with these requirements, but I think it's a little > late for that and also does not align with the general consensus so far. > I can understand that you don't want to change the requirements and I accept that. However, as I see it you are ready to restrict applications to use functionalities that actually the reason for deploying the transport negotiation capability. To me it seems that you are arguing that the only valid transport negotiation usage that needs to work is SRTP. I don't think it is reasonable to disregard solutions that uses AVPF from using this mechanism to determine if one can or cannot use for example retransmission. >> >> 2. Usage of paylaod types that only make sense over particular >> transport. For example if one requires RTP/AVP/TCP for a particular >> paylaod type to be usable due to reliability requirements. >> >> As I see it this can be only solved by what I consider a hack. Which >> is to overdefine a number of payload types that one doesn't intended >> to use to provide sufficient number for other potential >> configurations. And I think you need to define them, because leaving >> them undefined would to me be against current SDP rules. >> >> I think this is a hack for several reasons. >> >> A. It doesn't clearly define which payload types that are intended to >> be used in a specific transport. > That's not an issue with the capability negotiation framework. The > potential configuration, which references capabilities by use of their > capability numbers would be used for this. I think you are missunderstanding my point, or I am completely missunderstanding you. My point is that you have different payload types for different potential configuration using different transport alternatives. For clarity it should be explicit which transport alterantives uses which payload type numbers. Instead of forcing one to declare a number of payload types that aren't intended to be used, but still negotiated. >> >> B. It forces one to overwrite the RTP payload types, always. Despite >> the issues with media delivery prior to receiving answer or having >> performed the second round of offer/answer > Right. I agree that in order to properly address this, you need an > extension. >> >> C. It prevents this mechanism to in the future be upgraded in a >> reasonable way with media cability negotiation. See separate email for >> discussion. > I'll have a look - I currently don't see the issue. The issue I see is that any extension would have to replace the transport alternatives with a totally new mechanism. Thus making the upgrade path very hard as you need to do a required supported mechanism, rather than a optional one for media capability negotiation. >> >> I would recommend that one seriously consider using explicit >> declaration of the payload type used for each transport in the tcap >> attribute. >> > Your comment could be addressed in many different ways, however we > should probably agree on whether we want to address it in the core > document first, before getting into the actual solution. > Agreed, lets discuss the general issues. To me it is a choice between doing work and complicate the solution, or cripple the functionality. 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 Jul 23 14:53: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 1ID32M-0002vN-P8; Mon, 23 Jul 2007 14:53:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID32L-0002s5-73 for mmusic@ietf.org; Mon, 23 Jul 2007 14:53:41 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID32K-0006b9-Gx for mmusic@ietf.org; Mon, 23 Jul 2007 14:53:41 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l6NIrHgc018202; Mon, 23 Jul 2007 20:53:17 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l6NIrFCu006184; Mon, 23 Jul 2007 20:53:15 +0200 Received: from nets13ja.ww300.siemens.net ([158.226.250.79]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jul 2007 20:53:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types Date: Mon, 23 Jul 2007 20:53:12 +0200 Message-ID: In-Reply-To: <46A4F457.5050404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types Thread-Index: AcfNV+c9rBU0vVzSSYepVV5J3Q8iVwAAgoEA References: <469F9B92.3060906@ericsson.com> <46A4CC82.5090209@cisco.com> <46A4F457.5050404@cisco.com> From: "Stach, Thomas" To: "Flemming Andreasen" X-OriginalArrivalTime: 23 Jul 2007 18:53:14.0979 (UTC) FILETIME=[B9B5AB30:01C7CD5A] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070723205317-46D90BB0-5AA8F3CF/0-0/0-15 X-purgate-size: 5421/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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: , Content-Type: multipart/mixed; boundary="===============1880335334==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1880335334== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CD5A.B9620F01" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CD5A.B9620F01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Flemming, =20 inline < snip> =20 =09 =09 =09 I see the extensibily problem differently. As a first step the core spec should disallow different numbers of PTs =20 I'm not sure what that would actually mean - can you elaborate ?=20 [Stach Thomas] What I mean is that the scope of the core spec does not include the scenario mentioned by Magnus. In order to discourage people to implement the hack that Magnus mentioned, some guidance could be given in the core spec.=20 That should refer people to the media capability negotiation, if they want to tackle scenarios where different numbers of payload types (or m-lines) appear in actual and potential configurations. =09 As long as we can do that with a "for example" reference and hence have it as an informative reference, I'm fine with that.=20 [Stach Thomas] Sure, or if you want to avoid even the informative reference, I could live as well with referring people to an unnamed extension of the core spec. =20 =20 ------_=_NextPart_001_01C7CD5A.B9620F01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 
Flemming,
 
inline
  <=20 snip>  



I see the extensibily problem differently.
As a first step the core spec should disallow different numbers of PTs
I'm not sure what that would actually mean - can you = elaborate ?=20
[Stach Thomas] What I mean is that the scope of the = core spec=20 does not include the scenario mentioned by Magnus. In order to = discourage=20 people
to implement the hack that Magnus mentioned, some = guidance could be=20 given in the core spec.
That should refer people to the media = capability =20 negotiation, if they want to tackle scenarios where different = numbers of=20 payload types (or m-lines) appear in actual and potential=20 configurations.
As long as we can do that with a "for example" reference and = hence have=20 it as an informative reference, I'm fine with that.
[Stach=20 Thomas] Sure, or if you want to avoid even the = informative=20 reference, I could live as well with referring people to an unnamed = extension=20 of the core spec.  
 
------_=_NextPart_001_01C7CD5A.B9620F01-- --===============1880335334== 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 --===============1880335334==-- From mmusic-bounces@ietf.org Mon Jul 23 15:04: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 1ID3D3-0000K2-9f; Mon, 23 Jul 2007 15:04:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3D1-0000Jx-K7 for mmusic@ietf.org; Mon, 23 Jul 2007 15:04:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID3D1-0006t1-6d for mmusic@ietf.org; Mon, 23 Jul 2007 15:04:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9754C20180; Mon, 23 Jul 2007 21:04:42 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-06-46a4fbcae3dd Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 74F6D20079; Mon, 23 Jul 2007 21:04:42 +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, 23 Jul 2007 21:04:41 +0200 Received: from [138.85.12.20] ([138.85.12.20]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 21:04:41 +0200 Message-ID: <46A4FBC7.6010806@ericsson.com> Date: Mon, 23 Jul 2007 21:04:39 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Stach, Thomas" Subject: Re: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities References: <469F9BB7.9040709@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:04:41.0752 (UTC) FILETIME=[530EE980:01C7CD5C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Stach, Thomas skrev: > Magnus, > > I agree that this is neither covered in the core spec nor in the media > capability extension. > Could that be left for an extension (either its own or media > capabilities) in order to keep the core spec simpler? > In my opinion, NO! The reason is that different transport capabilities do need different bandwidth modifiers to make the work correctly. Thus, not providing this in the core will have serious effect for usage of some transport options for RTP. 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 Jul 23 15:10: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 1ID3IM-0001VS-CL; Mon, 23 Jul 2007 15:10:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3IL-0001VK-77 for mmusic@ietf.org; Mon, 23 Jul 2007 15:10:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID3IK-0006zA-Od for mmusic@ietf.org; Mon, 23 Jul 2007 15:10:13 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AE39420603; Mon, 23 Jul 2007 21:09:58 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-07-46a4fd06d4fd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8B3D720014; Mon, 23 Jul 2007 21:09:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 21:09:58 +0200 Received: from [138.85.12.20] ([138.85.12.20]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 21:09:58 +0200 Message-ID: <46A4FD03.5040509@ericsson.com> Date: Mon, 23 Jul 2007 21:09:55 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Even, Roni" Subject: Re: [MMUSIC] SDPCapNeg-06: Lack of bandwidth capabilities References: <144ED8561CE90C41A3E5908EDECE315C04C22FC2@IsrExch01.israel.polycom.com> In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C04C22FC2@IsrExch01.israel.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:09:58.0631 (UTC) FILETIME=[0FEECF70:01C7CD5D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Stach, Thomas" , "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 Even, Roni skrev: > Thomas, > I think we may cover it in the media capabilities. > Still I think that we may decide that we can use RTCP CCM for flow > control to lower BW based on selected mode. Well, that is not really what CCM is intended to be used for. It also doesn't allow the answerer to determine if a potential configuration has a reasonable bandwidth configuration to be accepted. I also think that we should consider the RTCP bandwidth configuration that is very much tied into the transport used. Difference between AVP and AVPF. 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 Jul 23 15:28: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 1ID3aQ-000067-Um; Mon, 23 Jul 2007 15:28:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3aP-00005z-Ff for mmusic@ietf.org; Mon, 23 Jul 2007 15:28:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID3aO-0007uy-8j for mmusic@ietf.org; Mon, 23 Jul 2007 15:28:53 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2007 12:28:51 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAJaepEarR7PD/2dsb2JhbACIX5wp X-IronPort-AV: i="4.16,572,1175497200"; d="scan'208"; a="187092737:sNHT57221694" 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 l6NJSp8o010016; Mon, 23 Jul 2007 12:28:51 -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 l6NJSp6C013468; Mon, 23 Jul 2007 19:28:51 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); Mon, 23 Jul 2007 12:28:50 -0700 Received: from [10.21.86.195] ([10.21.86.195]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 12:28:50 -0700 Message-ID: <46A50171.1030906@cisco.com> Date: Mon, 23 Jul 2007 15:28:49 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> <46A4CB73.1010701@cisco.com> <46A4F8BF.6030504@ericsson.com> In-Reply-To: <46A4F8BF.6030504@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:28:50.0347 (UTC) FILETIME=[B27CF7B0:01C7CD5F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9416; t=1185218931; x=1186082931; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Transport=20capabilites= 20and=20RTP=20payload=0A=20types |Sender:=20; bh=4vB/aBYNPrg5OY4RberaO2fRgON6fjmCbMA6ZZK2FPo=; b=m40qboSvekaGRsnafkHYBRYR0xckEITlLMgAeeumO10cc2pk11d4BMsxDM1DJFeIwCjGM4CX rPqC1OqniLOwDGOu+PxzavbAiN2Ooa8ddr7H1aASsgELRdPG+vYYTymJ; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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: > Hi, > > See comments inline. > > Flemming Andreasen skrev: >> >> >> Magnus Westerlund wrote: >>> Hi, >>> >>> I have finally read the SDP capapbility draft in sufficient detail >>> to think I understand it mostly. There is likely some details that I >>> have gotten wrong. But I have found some issues that I need to raise >>> for discussion. I will split this into separate emails for each topic. >> Thanks for taking the time to read the document Magnus - responses >> below. >>> >>> I think the handling of the transport capabilites have to little >>> functionality. There is need for specifying which RTP payload types >>> that apply to which transport capabilities. I will list some usages >>> of this that doesn't seem to work correctly without it or bloody >>> ugly hacks. >>> >>> 1. Usage of RTP retransmission (RFC 4588) using payload type >>> multiplexing. >> I assume you mean when using session-multiplexing as opposed to >> SSRC-multiplexing and hence the issue here is one of requiring >> syncrhonized O/A operation over multiple streams. > > Yes. Sorry for mixing up the language. > >>> In this case the RTP retransmission payload only can be used in >>> cases when the session uses a profile that has AVPF functionality. >>> If one offers both AVP and AVPF with CAPNEG then one gets at least >>> one additional RTP payload type for the AVPF cases. >> Can RFC 4588 only be used under AVPF profiles ? > > Well, you can use the payload format in AVP but then you lack the NACK > format to request any retransmissions with. > > Regardless, I >> understand your point, that there are cases where you would like to have >> this syncrhonized O/A operation. As mentioned above, SSRC-multiplexing >> works, and if you can do RFC 4588 today, then presumably you have >> implemented some logic on top of the "pure" O/A procedures to ensure >> that you do not accept the redundant stream without the primary stream >> being accepted itself. Also, since there is SSRC and payload type >> synchronization between the two streams, there is clearly more going on >> here than pure per-media stream only O/A procedures. Based on that, I'm >> not sure we in practice get into any new scenarios here; you already >> have logic in place to accept only potential configuration SDPs that >> adhere to the principles effectively required by RFC 4588. > > However, that uses grouping of media lines. An without a reasonable > support of grouping of media lines for potential configuration that > will not work. Thus, as I see it this is a problem. Actually, I believe this particular scenario is supported as well as with RFC 4588 itself. You can define a session level "a=group:FID" attribute capability which is only used by the potential configuration for the AVPF transport protocol. The per-media stream "mid" attributes can always be added to the actual configuration. >> >> Taking a step back, the question however is whether this type of >> functionality should be in scope of the core capabilities negotiation >> document or not. We only have "per media stream" requirements in the >> requirements document >> (draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt). >> Furthermore, the "media format negotiation" requirement (REQ-10) as well >> as the inter-media stream requirements are (REQ-150 and REQ-160) are all >> listed as enchancements, and hence would be covered by an extension >> rather than the core. This (fairly reduced) scope was the result of a >> lot of discusions and consideration to people that are primarily >> interested in addressing the pure transport protocol problem and hence >> did not want an overly complicated solution. I think your comment here >> is that you disagree with these requirements, but I think it's a little >> late for that and also does not align with the general consensus so far. >> > > > I can understand that you don't want to change the requirements and I > accept that. However, as I see it you are ready to restrict > applications to use functionalities that actually the reason for > deploying the transport negotiation capability. To me it seems that > you are arguing that the only valid transport negotiation usage that > needs to work is SRTP. I'm not. What I am saying however is that there has been significant pushback on complicating the core and including functionality that is not needed for the SRTP crowd. At the same time, it is also agreed that we want a general and extensible solution that can be used to address other capability negotiation problems (like the ones you bring up). It's not an easy balancing act... > I don't think it is reasonable to disregard solutions that uses AVPF > from using this mechanism to determine if one can or cannot use for > example retransmission. Per the above, I think that scenario actually works without any extensions. Are there other specific scenarios you are concerned about in the core (e.g. it would be helpful if you can identify scenarios that absolutely MUST be supported by the core) ? >>> 2. Usage of paylaod types that only make sense over particular >>> transport. For example if one requires RTP/AVP/TCP for a particular >>> paylaod type to be usable due to reliability requirements. >>> >>> As I see it this can be only solved by what I consider a hack. Which >>> is to overdefine a number of payload types that one doesn't intended >>> to use to provide sufficient number for other potential >>> configurations. And I think you need to define them, because leaving >>> them undefined would to me be against current SDP rules. >>> >>> I think this is a hack for several reasons. >>> >>> A. It doesn't clearly define which payload types that are intended >>> to be used in a specific transport. > > >> That's not an issue with the capability negotiation framework. The >> potential configuration, which references capabilities by use of their >> capability numbers would be used for this. > > I think you are missunderstanding my point, or I am completely > missunderstanding you. My point is that you have different payload > types for different potential configuration using different transport > alternatives. For clarity it should be explicit which transport > alterantives uses which payload type numbers. Instead of forcing one > to declare a number of payload types that aren't intended to be used, > but still negotiated. We agree (I think) that a payload type mapping neither is nor should be a capability. Support for a particular media format with a specific set of parameters however is. Mapping such media formats and their associated parameters to a particular payload type is something that falls under the realm of a configuration (IMO). Where we differ is on whether those features need to provided by the core document or if they can be provided by an extension. So far, the consensus has been to provide them as extensions (but again, under the assumption that extensions that fit within the framework actually can be defined). > >>> >>> B. It forces one to overwrite the RTP payload types, always. Despite >>> the issues with media delivery prior to receiving answer or having >>> performed the second round of offer/answer >> Right. I agree that in order to properly address this, you need an >> extension. >>> >>> C. It prevents this mechanism to in the future be upgraded in a >>> reasonable way with media cability negotiation. See separate email >>> for discussion. > >> I'll have a look - I currently don't see the issue. > > The issue I see is that any extension would have to replace the > transport alternatives with a totally new mechanism. Thus making the > upgrade path very hard as you need to do a required supported > mechanism, rather than a optional one for media capability negotiation. We are back to discussing scope of the core document and I'm not sure how to address that except to note what consensus has been so far and we'll probably need additional input on this. >>> I would recommend that one seriously consider using explicit >>> declaration of the payload type used for each transport in the tcap >>> attribute. >>> >> Your comment could be addressed in many different ways, however we >> should probably agree on whether we want to address it in the core >> document first, before getting into the actual solution. >> > > > Agreed, lets discuss the general issues. To me it is a choice between > doing work and complicate the solution, or cripple the functionality. I don't think we are crippling functionality, but there is clearly additional work needed to address some of your requirements. -- Flemming > > 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 Jul 23 15:56: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 1ID40r-00014E-CF; Mon, 23 Jul 2007 15:56:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40m-0000t9-2B; Mon, 23 Jul 2007 15:56:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID40l-0000LV-JA; Mon, 23 Jul 2007 15:56:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 15:56:07 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACalpEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126801974:sNHT29190148" 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 l6NJu6Zx023742; Mon, 23 Jul 2007 15:56:06 -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 l6NJtvWs017987; Mon, 23 Jul 2007 19:56:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:55:41 -0400 Received: from [10.86.242.144] ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:55:41 -0400 Message-ID: <46A507C5.5060206@cisco.com> Date: Mon, 23 Jul 2007 15:55:49 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:55:41.0404 (UTC) FILETIME=[72C0C1C0:01C7CD63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1840; t=1185220566; x=1186084566; 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:=20ICE=20tutorial=20in=20Chicago=20is=20CONFIRMED=20[DO=20NOT=20 REPLY]=20-=20lunch=20logistics=0A=20below |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=KpxqDxUhtprUSwrX98Ct3c1X0mBsvpY4gzyMN2aH5Go=; b=Ncyw7y256jwE7lC5Q5QuZfDCdjVn1oabrjGvlOL+VyhF0ZalmP15rKSMhRmaAGHHsSvG2PuK zZyuKd5iE8415bdWZIZuxeIGqTOje15E+zSKCePNlEj5RGkZbwjUABDm; 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: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [MMUSIC] ICE tutorial in Chicago is CONFIRMED [DO NOT REPLY] - lunch logistics below 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 (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.txt) Slides: http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt WHEN: Tuesday, July 24, 2007, 1145-1245 lunch will be available to those who RSVPd previously sandwiches, chips, salad and drinks $20/head - please pay Jonathan R. after the tutorial WHERE: Red Lacquar MP3 streaming hopefully available at: http://videolab.uoregon.edu/events/ietf/ietf694.m3u WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Anyone may attend without RSVP, but lunch may not be there for you if you have not RSVPd previously. I've ordered a few extra !DO NOT REPLY TO THIS NOTE! -- 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 Jul 23 16:51: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 1ID4sZ-00080J-F3; Mon, 23 Jul 2007 16:51:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4sW-0007xD-5B; Mon, 23 Jul 2007 16:51:40 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID4sV-00023m-DI; Mon, 23 Jul 2007 16:51:40 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id EC8031811206; Mon, 23 Jul 2007 22:51:40 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jul 2007 22:37:31 +0200 To: "Henry Sinnreich" , "David Barrett" ,"Jan Janak" , "Juha Heinanen" From: Jiri Kuthan Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe. com> References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070723205140.EC8031811206@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, 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 At 19:10 21/07/2007, Henry Sinnreich wrote: >I fully agree with Jiri that this is an IETF problem and not an ICE >problem. >ICE-17 is a great document, no doubt about it. > >What happens however of someone finds an innovative approach that may >work better? Will it be rejected because it will not be RFC standards >compliant? I don't think so, IETF is having a history of working on competing standards, jabber and simple being a prominent and recent example thereof. I think that's actually with current IETF's size and dynamics a fairly good strategy to eliminate single points of failure. -jiri >What could an innovator tell customers about a solution that works >better but is not IETF ICE RFC standards compliant? > >Henry > >-----Original Message----- >From: Jiri Kuthan [mailto:jiri@iptel.org] >Sent: Saturday, July 21, 2007 9:48 AM >To: David Barrett; 'Jan Janak'; 'Juha Heinanen' >Cc: sip@ietf.org; mmusic@ietf.org >Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE >deploymentdatabefore LC for RFC > >At 20:05 19/07/2007, David Barrett wrote: >>> -----Original Message----- >>> From: Jiri Kuthan [mailto:jiri@iptel.org] >>> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment >databefore >>> LC for RFC >>> >>> So I think that the right course of action is that folks doubting ICE >>> reliability >>> make their case (by that I mean specific arguments rather than >emotional >>> debates >>> about red-colored nails and other hardware). >> >>Er, my "specific argument" is "until it's been proven to work, it >hasn't >>been proven to work". It's tautological, but no less true for it. >> >>Indeed, if you're *not* doubting ICE, why aren't you? > >Hi David, > >I'm not entirely sure what is the step you are suggesting? > >I think ICE is architecturally right answer to the right problem. >Notwithstanding that, there are certainly some things I prefer >differently (e.g., the infamous debate about proactive hole punching) >or may turn out to be bugs. I think though that the key problem at >this point is of institutional nature. In the IETF language, "hasn't >been proven to work" is adequate to "lacking running code" and this >appears to be a phenomen which is indeed occuring in the IETF and >is not unique to ICE. > >The question is how to get this fixed? > >Some other standardization bodies enjoying the amount of contributions >and complexity as the IETF is enjoying now (S in SIP does not really >stand for Simple), proceed with 'after-fact filters', in that they >produce the initial specs faster and later produce 'profiles' which >separate what has proved and what less. Plus -bis versions are produced >for whatever appears worth puttting effort in it (i.e., for which there >is running code and field evidence of improvement need).This could be >an approach which may be more feasible in today's IETF's dimension than > >trying to get back to historical roots. > >-jiri > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Jul 23 18:29: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 1ID6PS-0005ca-75; Mon, 23 Jul 2007 18:29:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID6PQ-0005cV-3n for mmusic@ietf.org; Mon, 23 Jul 2007 18:29:44 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID6PO-0004ML-7X for mmusic@ietf.org; Mon, 23 Jul 2007 18:29:43 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2007 15:29:12 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIrIpEarR7PD/2dsb2JhbACCLzU X-IronPort-AV: i="4.16,572,1175497200"; d="scan'208,217"; a="387560366:sNHT81565298020" 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 l6NMTBwO025508; Mon, 23 Jul 2007 15:29:11 -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 l6NMT66K020273; Mon, 23 Jul 2007 22:29:11 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:29:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations Date: Mon, 23 Jul 2007 15:29:07 -0700 Message-ID: In-Reply-To: <46A4D1D8.30904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations Thread-Index: AcfNQ1PpUHdw4aJpTDeUzJ2hYtXpEwAIkRAg From: "Joe Stone \(joestone\)" To: "Flemming Andreasen \(fandreas\)" X-OriginalArrivalTime: 23 Jul 2007 22:29:10.0771 (UTC) FILETIME=[E3F6A430:01C7CD78] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17800; t=1185229751; x=1186093751; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joestone@cisco.com; z=From:=20=22Joe=20Stone=20\(joestone\)=22=20 |Subject:=20RE=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Session=20level=09coordi ntationbetweenpotential=20configurations |Sender:=20; bh=zSR/PRCWtG4312LFCMhdFZgypnVeTjEBt7cUAnjdGhA=; b=qhfQNKGsHORvfpnuwuZJkF0xoI4RndPIVgy9iRzh/egg8ywDju1KfiULfGJbaIkNhV90kein X3oHtXme7H7cvCxRuflRZRTvn/rZ2fTJBE8SobzxLMoDs/Fe47D1FjeK; Authentication-Results: sj-dkim-3; header.From=joestone@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb7a33d18683bf5063a44e640cf125f1 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: , Content-Type: multipart/mixed; boundary="===============1969976350==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1969976350== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CD78.E3AF78DC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CD78.E3AF78DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [js] Comments in line... ________________________________ From: Flemming Andreasen (fandreas)=20 Sent: Monday, July 23, 2007 11:06 AM To: Joe Stone (joestone) Cc: Stach, Thomas; Magnus Westerlund; mmusic (E-mail) Subject: Re: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations Joe Stone (joestone) wrote:=20 However, I do agree with Magnus that there's a need to negotiate between groups of media descriptions. I see this as the "big picture". It should be shown, at least at a high-level, that the transport protocol negotiation of sdp-capability-negotiation will fit with a more comprehensive SDP negotiation framework.=20 =20 Or rather a set of possible extensions to the core framework.=20 We keep going back to scope and requirements here. Currently, we have a separate requirement document (which we don't have any real plans for, e.g. turning into RFC). At one point, we discussed incorporating it into an Appendix to give some people some additional background and motivation for the design and scope. What do people (and the chairs) want to do here: 1) Let the requirements draft expire. 2) Publich requirements draft as a separate RFC=20 3) Incorporate requirements into an appendix in the core document=20 4) Something else ? =20 =20 [js] I'm not suggesting a change to the scope of sdp-capability-negotiation(-06) or the requirements of sdp-capability-negotiation-reqts-01. However, you should consider... sdp-capability-negotiation-reqts-01 defines a set of requirements. It categorizes these requirements (and the corresponding functionality) as either mandatory ("core") or optional ("enhancements"), dealing with whether an entity must support/implement a particular function or not. It gives examples of "extensions", e.g., unicast/multicast and IPv4/IPv6 address negotiation. Note that REQ-150 (valid combinations of media lines) is an enhancement, not necessarily an extension. sdp-capability-negotiation-reqts-01 does not limit the scope of sdp-capability-negotiation(-06) to the core requirements. You may want to clarify this before further referencing the requirements I-D. On a related topic... =09 I'm not convinced that sdp-capability-negotiation should obsolete RFC 3407 given that sdp-capability-negotiation doesn't define equivalent functionality (at least based on -06). =20 I'm open either way - current consensus is to obsolete it.=20 =20 [js] I hope that those who form the consensus understand the way in which RFC 3407 is being used. I understand the motivation for wanting to derail RFC 3407 (in favor of SDPCapNeg) sooner than later. However, as you're well aware, RFC 3407 support is mandatory with MGCP profiles such as PacketCable's NCS and TGCP. RFC 3407 has found its way into SIP implementations. It's acknowledged as part of the PacketCable 2.0 (SIP) specifications. Once the cat is out of the bag... =20 [js] I can see an extension to SDPCapNeg (with equivalent functionality) *possibly* obsoleting RFC 3407, however, I don't see where it makes sense in the case of sdp-capability-negotiation-06. =20 -- Flemming=20 Joe =09 -----Original Message----- From: Stach, Thomas [mailto:thomas.stach@siemens.com]=20 Sent: Friday, July 20, 2007 5:25 AM To: Magnus Westerlund; mmusic (E-mail) Subject: RE: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations =09 Magnus, =09 more inline.=20 =09 =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Thursday, July 19, 2007 7:14 PM To: mmusic (E-mail) Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation=20 betweenpotential configurations =09 The draft comes to the conclusion that there is no real need for=20 coordintion between different media descriptions and their potential=20 configurations. I think that is wrong for several reasons: =09 1. I would start with referening once more to a defined usage in RFC 4588 (RTP Retransmission). In the case of desire to use session=20 multiplexing for the retransmission one would only like to use that=20 under the constraint that one already uses AVPF in the primary=20 transmission session. Thus one would like to make the following offer: =09 Primary session: AVP, potential configuration 1: AVPF with NACK =09 Retransmission session: Only used in case primary session selects=20 potential configuration 1. =20 =09 In other words this means an actual configuration with one m-line and a potential configuration with two m-lines. Would it help if the problem is described in the core spec, but not solved? My intention is to keep the core spec as simple as possible, but to state its restrictions. =09 =20 2. Allow for media capability negotiation. As I see it when moving=20 into a media capability negotiation extension one will very much like=20 to present cases where there are set of media configurations. That may =20 =09 =20 include additional media streams needing their own media descriptions, =20 =09 =20 i.e. RTP sessions / or other media transport (MSRP). One would in=20 other words like to express capabilites like. Lets do (Audio, video=20 and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio=20 and MSRP) depending on peers capabilities. Without the functionality=20 to make higher level bindings between potential configurations into=20 different sets that will not work. =20 =09 Here I think we must decide how far we want go with media capability negotiation. =09 =20 Unfortunately the above has one very frightening conclusion, we need=20 to have possibility to do potential configurations for media=20 descriptions that has no match in the actual configuration. =20 =09 I'm not sure how frightening that is from specification perspective (e.g. an a=3Dmcap for additional m-lines could do), but it surely is for an implementor. =09 Regards Thomas =09 =20 Cheers =09 Magnus Westerlund =09 IETF Transport Area Director & TSVWG Chair =09 ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M =09 ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com =09 ---------------------------------------------------------------------- =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =09 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic =09 =20 ------_=_NextPart_001_01C7CD78.E3AF78DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
[js] Comments in = line...

From: Flemming Andreasen (fandreas)=20
Sent: Monday, July 23, 2007 11:06 AM
To: Joe Stone=20 (joestone)
Cc: Stach, Thomas; Magnus Westerlund; mmusic=20 (E-mail)
Subject: Re: [MMUSIC] SDPCapNeg-06: Session level=20 coordintationbetweenpotential configurations



Joe Stone (joestone) wrote:=20 
However, I do agree with Magnus that =
there's a need to negotiate between
groups of media descriptions. I see this as the "big picture". It should
be shown, at least at a high-level, that the transport protocol
negotiation of sdp-capability-negotiation will fit with a more
comprehensive SDP negotiation framework.=20
Or rather a set of possible extensions to the core framework. =

We=20 keep going back to scope and requirements here. Currently, we have a = separate=20 requirement document (which we don't have any real plans for, e.g. = turning into=20 RFC). At one point, we discussed incorporating it into an Appendix to = give some=20 people some additional background and motivation for the design and = scope. What=20 do people (and the chairs) want to do here:
1) Let the requirements = draft=20 expire.
2) Publich requirements draft as a separate RFC
3) = Incorporate=20 requirements into an appendix in the core document
4) Something else = ?  
 
[js]=20 I'm not suggesting a change to the scope of = sdp-capability-negotiation(-06) or=20 the requirements of sdp-capability-negotiation-reqts-01. However, you = should=20 consider... sdp-capability-negotiation-reqts-01 defines a set of = requirements. It=20 categorizes these requirements (and the corresponding functionality) as = either=20 mandatory ("core") or optional ("enhancements"), dealing with whether an = entity=20 must support/implement a particular function or not. It gives = examples of=20 "extensions",  e.g., unicast/multicast and IPv4/IPv6 address=20 negotiation. Note that REQ-150 (valid combinations of media lines) is an = enhancement, not necessarily an extension. = sdp-capability-negotiation-reqts-01=20 does not limit the scope of sdp-capability-negotiation(-06) to the = core=20 requirements. You may want to clarify this before further referencing = the=20 requirements I-D.
On a related topic...

I'm not convinced that sdp-capability-negotiation should obsolete RFC
3407 given that sdp-capability-negotiation doesn't define equivalent
functionality (at least based on -06).
I'm open either way - current consensus is to obsolete = it. 
 
[js] I=20 hope that those who form the consensus understand the way in which RFC = 3407 is=20 being used. I understand the motivation for wanting to derail RFC 3407 = (in favor=20 of SDPCapNeg) sooner than later. However, as you're well aware, RFC 3407 = support=20 is mandatory with MGCP profiles such as PacketCable's NCS and TGCP. = RFC=20 3407 has found its way into SIP implementations. It's acknowledged as = part of=20 the PacketCable 2.0 (SIP) specifications. Once the cat is out of the=20 bag...
 
[js] I=20 can see an extension to SDPCapNeg (with equivalent functionality) = *possibly*=20 obsoleting RFC 3407, however, I don't see where it makes sense in the = case of=20 sdp-capability-negotiation-06.
 
-- Flemming = 

Joe

-----Original Message-----
From: Stach, Thomas [mailto:thomas.stach@siemens.com<=
/A>]=20
Sent: Friday, July 20, 2007 5:25 AM
To: Magnus Westerlund; mmusic (E-mail)
Subject: RE: [MMUSIC] SDPCapNeg-06: Session level
coordintationbetweenpotential configurations

Magnus,

more inline.=20

  
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@e=
ricsson.com]
Sent: Thursday, July 19, 2007 7:14 PM
To: mmusic (E-mail)
Subject: [MMUSIC] SDPCapNeg-06: Session level coordintation=20
betweenpotential configurations

The draft comes to the conclusion that there is no real need for=20
coordintion between different media descriptions and their potential=20
configurations. I think that is wrong for several reasons:

1. I would start with referening once more to a defined usage in RFC
4588 (RTP Retransmission). In the case of desire to use session=20
multiplexing for the retransmission one would only like to use that=20
under the constraint that one already uses AVPF in the primary=20
transmission session. Thus one would like to make the following offer:

Primary session: AVP, potential configuration 1: AVPF with NACK

Retransmission session: Only used in case primary session selects=20
potential configuration 1.
    

In other words this means an actual configuration with one m-line and a
potential configuration with two m-lines.
Would it help if the problem is described in the core spec, but not
solved?
My intention is to keep the core spec as simple as possible, but to
state its restrictions.

  
2. Allow for media capability =
negotiation. As I see it when moving=20
into a media capability negotiation extension one will very much like=20
to present cases where there are set of media configurations. That may
    

  
include additional media =
streams needing their own media descriptions,
    

  
i.e. RTP sessions / or other =
media transport (MSRP). One would in=20
other words like to express capabilites like. Lets do (Audio, video=20
and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio=20
and MSRP) depending on peers capabilities. Without the functionality=20
to make higher level bindings between potential configurations into=20
different sets that will not work.
    

Here I think we must decide how far we want go with media capability
negotiation.

  
Unfortunately the above has =
one very frightening conclusion, we need=20
to have possibility to do potential configurations for media=20
descriptions that has no match in the actual configuration.
    

I'm not sure how frightening that is from specification perspective
(e.g. an a=3Dmcap for additional m-lines could do), but it surely is for
an implementor.

Regards
Thomas

  
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
------_=_NextPart_001_01C7CD78.E3AF78DC-- --===============1969976350== 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 --===============1969976350==-- From mmusic-bounces@ietf.org Mon Jul 23 19:35: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 1ID7Qw-00012E-Nh; Mon, 23 Jul 2007 19:35:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7Qv-00011x-2y for mmusic@ietf.org; Mon, 23 Jul 2007 19:35:21 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID7Qu-0005ln-DR for mmusic@ietf.org; Mon, 23 Jul 2007 19:35:20 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D772C20771; Tue, 24 Jul 2007 01:35:19 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-e1-46a53b3760ec Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC07320478; Tue, 24 Jul 2007 01:35:19 +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 Jul 2007 01:35:19 +0200 Received: from [138.85.12.20] ([138.85.12.20]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 01:35:18 +0200 Message-ID: <46A53B35.3070403@ericsson.com> Date: Tue, 24 Jul 2007 01:35:17 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg-06: Session level coordintation between potential configurations References: <469F9BCD.8070905@ericsson.com> <46A4D094.4040507@cisco.com> In-Reply-To: <46A4D094.4040507@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 23:35:19.0039 (UTC) FILETIME=[213C48F0:01C7CD82] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Flemming Andreasen skrev: >> 2. Allow for media capability negotiation. As I see it when moving >> into a media capability negotiation extension one will very much like >> to present cases where there are set of media configurations. That may >> include additional media streams needing their own media descriptions, >> i.e. RTP sessions / or other media transport (MSRP). One would in >> other words like to express capabilites like. Lets do (Audio, video >> and Text), or (Audio, video and MSRP) or (Audio and Text) or (Audio >> and MSRP) depending on peers capabilities. Without the functionality >> to make higher level bindings between potential configurations into >> different sets that will not work. >> > Right - this is well understood I believe, however there has not been > consensus to adopt this level of complexity in the core document. > Instead the WG consensus is that this type of functionality can be > handled in an (optional) extensions. >> Unfortunately the above has one very frightening conclusion, we need >> to have possibility to do potential configurations for media >> descriptions that has no match in the actual configuration. >> > If you want to address that requirement (which we currently don't have) > I agree, however why is that frightening ? > Because you need to be able to create media descriptions, i.e. m= lines that only exist in potential configurations, not in the actual configurations. That means one thing to me. We need some attribute to encode the equivalent to a "m=" line and also its attributes and other functions in the media block. This may not really be frightining, but it has potential issues in regards to both complexity and getting things right. -- 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 Jul 23 19:46: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 1ID7ba-0004mb-M8; Mon, 23 Jul 2007 19:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7bZ-0004mU-8a for mmusic@ietf.org; Mon, 23 Jul 2007 19:46:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID7bY-00077Z-U1 for mmusic@ietf.org; Mon, 23 Jul 2007 19:46:21 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4415B21340; Tue, 24 Jul 2007 01:46:20 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-92-46a53dcce20a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1F36A20094; Tue, 24 Jul 2007 01:46:20 +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, 24 Jul 2007 01:46:20 +0200 Received: from [138.85.12.20] ([138.85.12.20]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 01:46:19 +0200 Message-ID: <46A53DC8.5090302@ericsson.com> Date: Tue, 24 Jul 2007 01:46:16 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <467FF802.9050909@cisco.com> <469F9BE3.5080804@ericsson.com> <46A4D681.9030602@cisco.com> In-Reply-To: <46A4D681.9030602@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 23:46:19.0547 (UTC) FILETIME=[AAEDCEB0:01C7CD83] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mmusic 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 Flemming Andreasen skrev: > Do you have any concerns with the relevant text on this point in the > draft right now (if so, which parts ?) > I think section 3.10 might be not contain enough normative requirement on the media handling. Is this written somewhere else? I think it is important to point out that for an answer, he really shouldn't send any media if he selects a potential configuration. 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 Jul 24 07:43: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 1IDIn6-0002lE-RB; Tue, 24 Jul 2007 07:43:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDIn5-0002l2-8v for mmusic@ietf.org; Tue, 24 Jul 2007 07:42:59 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDIn4-0003iy-Bx for mmusic@ietf.org; Tue, 24 Jul 2007 07:42:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Jul 2007 07:42:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAKKCpUZAZnmf/2dsb2JhbACCZIV7nzE X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208,217"; a="126862934:sNHT61819710" 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 l6OBgvZe005763; Tue, 24 Jul 2007 07:42:57 -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 l6OBgrEZ011840; Tue, 24 Jul 2007 11:42:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 07:42:53 -0400 Received: from [10.82.217.231] ([10.82.217.231]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 07:42:52 -0400 Message-ID: <46A5E5BB.6040803@cisco.com> Date: Tue, 24 Jul 2007 07:42:51 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Joe Stone (joestone)" Subject: Re: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations References: In-Reply-To: X-OriginalArrivalTime: 24 Jul 2007 11:42:52.0956 (UTC) FILETIME=[C4FF65C0:01C7CDE7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9343; t=1185277377; x=1186141377; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Session=20level=09coordi ntationbetweenpotential=0A=20configurations |Sender:=20 |To:=20=22Joe=20Stone=20(joestone)=22=20; bh=ggqt8kKgAt6cnX2ksbhcypGg80sShpbQc5hy4od4XWU=; b=u56WaNdTwHt1JAWflIwpquFmdY31wVpB44VxK3tzJAtRIEMDAGngIBnZ221kZYgPak9hImdb 8R5D+fbPs3itAg2TdTM+MzIESZRCOl+LbL0vPdnK8u5VCSTL2PiJW8Fk; Authentication-Results: rtp-dkim-2; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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: , Content-Type: multipart/mixed; boundary="===============1591659383==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============1591659383== Content-Type: multipart/alternative; boundary="------------090409050801060003010401" This is a multi-part message in MIME format. --------------090409050801060003010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe Stone (joestone) wrote: > [js] Comments in line... > > ------------------------------------------------------------------------ > *From:* Flemming Andreasen (fandreas) > *Sent:* Monday, July 23, 2007 11:06 AM > *To:* Joe Stone (joestone) > *Cc:* Stach, Thomas; Magnus Westerlund; mmusic (E-mail) > *Subject:* Re: [MMUSIC] SDPCapNeg-06: Session level > coordintationbetweenpotential configurations > > > > Joe Stone (joestone) wrote: >> However, I do agree with Magnus that there's a need to negotiate between >> groups of media descriptions. I see this as the "big picture". It should >> be shown, at least at a high-level, that the transport protocol >> negotiation of sdp-capability-negotiation will fit with a more >> comprehensive SDP negotiation framework. >> > Or rather a set of possible extensions to the core framework. > > We keep going back to scope and requirements here. Currently, we have > a separate requirement document (which we don't have any real plans > for, e.g. turning into RFC). At one point, we discussed incorporating > it into an Appendix to give some people some additional background and > motivation for the design and scope. What do people (and the chairs) > want to do here: > 1) Let the requirements draft expire. > 2) Publich requirements draft as a separate RFC > 3) Incorporate requirements into an appendix in the core document > 4) Something else ? > > [js] I'm not suggesting a change to the scope of > sdp-capability-negotiation(-06) or the requirements of > sdp-capability-negotiation-reqts-01. However, you should consider... > sdp-capability-negotiation-reqts-01 defines a set of requirements. It > categorizes these requirements (and the corresponding functionality) > as either mandatory ("core") or optional ("enhancements"), dealing > with whether an entity must support/implement a particular function or > not. It gives examples of "extensions", e.g., unicast/multicast and > IPv4/IPv6 address negotiation. Note that REQ-150 (valid combinations > of media lines) is an enhancement, not necessarily an extension. Enhancement and extension is largely synonymous in the requirements document. > sdp-capability-negotiation-reqts-01 does not limit the scope of > sdp-capability-negotiation(-06) to the core requirements. You may want > to clarify this before further referencing the requirements I-D. OK. I think it's hereby clarified. >> On a related topic... >> >> I'm not convinced that sdp-capability-negotiation should obsolete RFC >> 3407 given that sdp-capability-negotiation doesn't define equivalent >> functionality (at least based on -06). >> > I'm open either way - current consensus is to obsolete it. > > [js] I hope that those who form the consensus understand the way in > which RFC 3407 is being used. I understand the motivation for wanting > to derail RFC 3407 (in favor of SDPCapNeg) sooner than later. However, > as you're well aware, RFC 3407 support is mandatory with MGCP profiles > such as PacketCable's NCS and TGCP. RFC 3407 has found its way into > SIP implementations. It's acknowledged as part of the PacketCable 2.0 > (SIP) specifications. Once the cat is out of the bag... > > [js] I can see an extension to SDPCapNeg (with equivalent > functionality) *possibly* obsoleting RFC 3407, however, I don't see > where it makes sense in the case of sdp-capability-negotiation-06. Fair point. -- Flemming --------------090409050801060003010401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Joe Stone (joestone) wrote:
[js] Comments in line...

From: Flemming Andreasen (fandreas)
Sent: Monday, July 23, 2007 11:06 AM
To: Joe Stone (joestone)
Cc: Stach, Thomas; Magnus Westerlund; mmusic (E-mail)
Subject: Re: [MMUSIC] SDPCapNeg-06: Session level coordintationbetweenpotential configurations



Joe Stone (joestone) wrote: 
However, I do agree with Magnus that there's a need to negotiate between
groups of media descriptions. I see this as the "big picture". It should
be shown, at least at a high-level, that the transport protocol
negotiation of sdp-capability-negotiation will fit with a more
comprehensive SDP negotiation framework.
Or rather a set of possible extensions to the core framework.

We keep going back to scope and requirements here. Currently, we have a separate requirement document (which we don't have any real plans for, e.g. turning into RFC). At one point, we discussed incorporating it into an Appendix to give some people some additional background and motivation for the design and scope. What do people (and the chairs) want to do here:
1) Let the requirements draft expire.
2) Publich requirements draft as a separate RFC
3) Incorporate requirements into an appendix in the core document
4) Something else ?  
 
[js] I'm not suggesting a change to the scope of sdp-capability-negotiation(-06) or the requirements of sdp-capability-negotiation-reqts-01. However, you should consider... sdp-capability-negotiation-reqts-01 defines a set of requirements. It categorizes these requirements (and the corresponding functionality) as either mandatory ("core") or optional ("enhancements"), dealing with whether an entity must support/implement a particular function or not. It gives examples of "extensions",  e.g., unicast/multicast and IPv4/IPv6 address negotiation. Note that REQ-150 (valid combinations of media lines) is an enhancement, not necessarily an extension.
Enhancement and extension is largely synonymous in the requirements document.
sdp-capability-negotiation-reqts-01 does not limit the scope of sdp-capability-negotiation(-06) to the core requirements. You may want to clarify this before further referencing the requirements I-D.
OK. I think it's hereby clarified. 
On a related topic...

I'm not convinced that sdp-capability-negotiation should obsolete RFC
3407 given that sdp-capability-negotiation doesn't define equivalent
functionality (at least based on -06).
I'm open either way - current consensus is to obsolete it. 
 
[js] I hope that those who form the consensus understand the way in which RFC 3407 is being used. I understand the motivation for wanting to derail RFC 3407 (in favor of SDPCapNeg) sooner than later. However, as you're well aware, RFC 3407 support is mandatory with MGCP profiles such as PacketCable's NCS and TGCP. RFC 3407 has found its way into SIP implementations. It's acknowledged as part of the PacketCable 2.0 (SIP) specifications. Once the cat is out of the bag...
 
[js] I can see an extension to SDPCapNeg (with equivalent functionality) *possibly* obsoleting RFC 3407, however, I don't see where it makes sense in the case of sdp-capability-negotiation-06.
Fair point.

-- Flemming


--------------090409050801060003010401-- --===============1591659383== 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 --===============1591659383==-- From mmusic-bounces@ietf.org Tue Jul 24 07: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 1IDIuI-0007K3-Ju; Tue, 24 Jul 2007 07:50:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDIuI-0007Jn-0K for mmusic@ietf.org; Tue, 24 Jul 2007 07:50:26 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDIuH-0003vZ-A3 for mmusic@ietf.org; Tue, 24 Jul 2007 07:50:25 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2007 04:50:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAIKEpUarR7PD/2dsb2JhbACIX58w X-IronPort-AV: i="4.16,574,1175497200"; d="scan'208"; a="506355099:sNHT34438046" 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 l6OBoOAX017123; Tue, 24 Jul 2007 04:50:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6OBoO6C019465; Tue, 24 Jul 2007 11:50:24 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, 24 Jul 2007 07:50:23 -0400 Received: from [10.82.217.231] ([10.82.217.231]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 07:50:23 -0400 Message-ID: <46A5E77E.20401@cisco.com> Date: Tue, 24 Jul 2007 07:50:22 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <467FF802.9050909@cisco.com> <469F9BE3.5080804@ericsson.com> <46A4D681.9030602@cisco.com> <46A53DC8.5090302@ericsson.com> In-Reply-To: <46A53DC8.5090302@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 11:50:23.0479 (UTC) FILETIME=[D187C070:01C7CDE8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4260; t=1185277824; x=1186141824; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg=20Issue=20#5=3A=20Media=20before =20answer |Sender:=20; bh=eyeMf3Ykt80bV+HJ/XEsHLLp2QkCP7sop75wFngYjs8=; b=OSbEX7kyfOuZDGqmWXHSOdrnge1Ir4MvhZ4zySoBT46wfAo+UktapQxhVQrNZKmK2gqtLk/q R/52NWSIcIbgKnYvtlFDyNjwis9mEqHNWELSnkyUoPqRnZfp8mJ5niHH; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mmusic 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: > Flemming Andreasen skrev: >> Do you have any concerns with the relevant text on this point in the >> draft right now (if so, which parts ?) >> > > I think section 3.10 might be not contain enough normative requirement > on the media handling. Is this written somewhere else? I think it is > important to point out that for an answer, he really shouldn't send > any media if he selects a potential configuration. I believe the last two paragraphs in Section 3.7.1 (Generating the Initial Offer) and 3.7.2 (Generating the Answer) address this concern. From Section 3.7.1: Per [RFC3264], once the offerer generates the offer, he must be prepared to receive incoming media in accordance with that offer. That rule applies here as well, but for the actual configurations provided in the offer only: Media received by the offerer according to one of the potential configurations MAY be discarded, until the offerer receives an answer indicating what the actual selected configuration is. Once that answer is received, incoming media MUST be processed in accordance with the actual selected configuration indicated and the answer received (provided the offer/answer exchange completed successfully). The above rule assumes that the offerer can determine whether incoming media adheres to the actual configuration offered or one of the potential configurations instead; this may not always be the case. If the offerer wants to ensure he does not play out any garbage, the offerer SHOULD discard all media received before the answer SDP is received. Conversely, if the offerer wants to avoid clipping, he should attempt to play any incoming media as soon as it is received (at the risk of playing out garbage). For further details, please refer to Section 3.10. and from Section 3.7.2: The offerer's originally provided actual configuration is contained in the media description's "m=" line (and associated parameters). The answerer MAY send media to the offerer in accordance with that actual configuration as soon as it receives the offer, however it MUST NOT send media based on that actual configuration if it selects an alternative potential configuration. If the answerer selects one of the potential configurations, then the answerer MAY immediately start to send media to the offerer in accordance with the selected potential configuration, however the offerer MAY discard such media or play out garbage until the offerer receives the answer. Please refer to section 3.10. for additional considerations and possible alternative solutions outside the base SDP Capability Negotiation framework. If the offerer selected a potential configuration instead of the actual configuration, then it is RECOMMENDED that the answerer sends back an answer SDP as soon as possible. This minimizes the risk of having media discarded or played out as garbage by the offerer. In the case of SIP [RFC3261] without any extensions, this implies that if the offer was received in an INVITE message, then the answer SDP should be provided in the first non-100 provisional response sent back (per RFC3261, the answer would need to be repeated in the 200 response as well, unless a relevant extension such as [RFC3262] is being used). -- Flemming > > 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 Jul 24 13:15: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 1IDNz5-0006iB-Ig; Tue, 24 Jul 2007 13:15:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNyv-000633-Bu; Tue, 24 Jul 2007 13:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDNyu-0000rg-N0; Tue, 24 Jul 2007 13:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5BFAA175CF; Tue, 24 Jul 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDNyP-0008MK-Qc; Tue, 24 Jul 2007 13:15:01 -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: Tue, 24 Jul 2007 13:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-qos-identification-00.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 : Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) Author(s) : J. Polk, et al. Filename : draft-ietf-mmusic-qos-identification-00.txt Pages : 10 Date : 2007-7-24 The offer/answer model for SDP assumes that endpoints establish, somehow, the QoS required for the media streams they establish. Endpoints in closed environments typically agree out of band (e.g., using configuration information) which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-qos-identification-00.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-qos-identification-00.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-qos-identification-00.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-7-24120808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-qos-identification-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-qos-identification-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-24120808.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 Tue Jul 24 16:07: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 1IDQfQ-0007Yp-6q; Tue, 24 Jul 2007 16:07:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQfN-0007YF-S6 for mmusic@ietf.org; Tue, 24 Jul 2007 16:07:34 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQfN-0005XI-8H for mmusic@ietf.org; Tue, 24 Jul 2007 16:07:33 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1825920wxd for ; Tue, 24 Jul 2007 13:07:32 -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:references:x-google-sender-auth; b=n6EVJzDDLCEBdBXxOil+vFnGXpisymoA6UGcqgEui7+LTL/bP36ZRG4hpj/sNVyPHWuo4nWsdyp2kPO7HhdC6LCWT69DBXxzEIjxSxjv6t2nr4CB952aHNC82nRFPWZAaLUaQgZDSjvm/9PPX//PoSEVtrx3fUTkgxfLT90JFkQ= 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:references:x-google-sender-auth; b=t7gGdNSdweZNgu94fHwt3Uzc37/DeECuCo9bCeGY+luySDhIHuirpXKrDuKm2+zxMPOFcsRZ2svhQuMMDm5NuXYc95SD6M9q7DY0bukEjPwMuswXyRu1hOmh7iKtidSn2ueG1yxtCEMGKnjzh5yrpi4R7t61Zsuuf9zzQfErmFs= Received: by 10.90.118.12 with SMTP id q12mr3760495agc.1185307652470; Tue, 24 Jul 2007 13:07:32 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Tue, 24 Jul 2007 13:07:32 -0700 (PDT) Message-ID: Date: Tue, 24 Jul 2007 16:07:32 -0400 From: "Adam Fisk" To: "Jiri Kuthan" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <20070723205140.EC8031811206@mail.iptel.org> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> X-Google-Sender-Auth: e83d915c39d3890a X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , David Barrett , Jan Janak 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="===============1256845924==" Errors-To: mmusic-bounces@ietf.org --===============1256845924== Content-Type: multipart/alternative; boundary="----=_Part_87196_32586101.1185307652344" ------=_Part_87196_32586101.1185307652344 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience: 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC. 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm. I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power. -Adam ------=_Part_87196_32586101.1185307652344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.  Here are the key points I've taken away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group.  I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler.  In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation.  I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback.  I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it.  That would be a huge hindrance to ICE's adoption and power.

-Adam


------=_Part_87196_32586101.1185307652344-- --===============1256845924== 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 --===============1256845924==-- From mmusic-bounces@ietf.org Tue Jul 24 16:51: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 1IDRM2-0005Oy-Om; Tue, 24 Jul 2007 16:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRM0-0005Ns-9K; Tue, 24 Jul 2007 16:51:36 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRLz-0002l4-E9; Tue, 24 Jul 2007 16:51:36 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 24 Jul 2007 13:51:27 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 l6OKo2ot020617; Tue, 24 Jul 2007 13:50:03 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6OKpJ0c002568; Tue, 24 Jul 2007 13:51:19 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 13:51:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Tue, 24 Jul 2007 13:48:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfOLkcd4W3U2DmDRkKJoVjFQ5z8VQABO4Ug References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> From: "Henry Sinnreich" To: "Adam Fisk" , "Jiri Kuthan" X-OriginalArrivalTime: 24 Jul 2007 20:51:18.0957 (UTC) FILETIME=[6280ADD0:01C7CE34] X-Spam-Score: -4.0 (----) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: sip@ietf.org, Juha Heinanen , Jan Janak , mmusic@ietf.org, David Barrett 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="===============0198866665==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0198866665== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE34.6066DD19" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE34.6066DD19 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Adam, =20 I fully agree with your positive assessment of the ICE-17 document. =20 Do you by any chance plan to also develop a test tool for testing the NAT environment and the success/failure cases, connection times, etc., to measure results? =20 Or maybe you know someone who does? =20 Thanks, Henry =20 ________________________________ From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk Sent: Tuesday, July 24, 2007 3:08 PM To: Jiri Kuthan Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience:=20 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.=20 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm.=20 I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power.=20 -Adam ------_=_NextPart_001_01C7CE34.6066DD19 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Adam,

 

I fully agree with your positive = assessment of the ICE-17 document.

 

Do you by any chance plan to also = develop a test tool for testing the NAT environment and the success/failure = cases, connection times, etc., to measure results?

 

Or maybe you know someone who = does?

 

Thanks, = Henry

 

From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk
Sent: Tuesday, July 24, = 2007 3:08 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; David = Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

I've followed = ICE development on the sidelines for years now, and I'm currently = implementing ICE 17.  I've implemented what will be open source implementations of = STUN and TURN, both client and server.  Here are the key points I've taken = away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to = the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I = was surprised at how hard it was, particularly for a draft that's so close = to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the = "almost done" state like used to happen in the Routing group.  I = realize that's asking a lot given how much work has gone into it and how eager = everyone is to finalize it.  I think the problem is that standardizing NAT = traversal is just hard, and hard problems are difficult to make simpler.  In = my implementation of ICE, I do think it could be done more simply, but I = don't have concrete suggestions right now because I'm still pulling my hair = out with the implementation.  I'm not talking about drastic changes = anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it = to ourselves to be even more patient with an "almost done" state = that adds the final touches based on real-world feedback.  I don't doubt = for a second that ICE works, but it's so complex that I worry no one outside = huge companies will ever implement it.  That would be a huge hindrance = to ICE's adoption and power.

-Adam

------_=_NextPart_001_01C7CE34.6066DD19-- --===============0198866665== 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 --===============0198866665==-- From mmusic-bounces@ietf.org Tue Jul 24 17:06: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 1IDRaX-0007jk-4f; Tue, 24 Jul 2007 17:06:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRaV-0007hh-P3 for mmusic@ietf.org; Tue, 24 Jul 2007 17:06:35 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRaU-0006q3-Tr for mmusic@ietf.org; Tue, 24 Jul 2007 17:06:35 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F333C205A2; Tue, 24 Jul 2007 23:06:33 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-0d-46a669d9a3fe Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C973220494; Tue, 24 Jul 2007 23:06:33 +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, 24 Jul 2007 23:06:33 +0200 Received: from [138.85.4.148] ([138.85.4.148]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 23:06:33 +0200 Message-ID: <46A669D6.7040009@ericsson.com> Date: Tue, 24 Jul 2007 23:06:30 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg Issue #5: Media before answer References: <467FF802.9050909@cisco.com> <469F9BE3.5080804@ericsson.com> <46A4D681.9030602@cisco.com> <46A53DC8.5090302@ericsson.com> <46A5E77E.20401@cisco.com> In-Reply-To: <46A5E77E.20401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 21:06:33.0599 (UTC) FILETIME=[83ABF8F0:01C7CE36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mmusic 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 think the text in this regard is fine. I didn't spend enough time to dig out the right paragraphs when you asked for concreate examples. Sorry about that. Magnus Flemming Andreasen skrev: > > > Magnus Westerlund wrote: >> Flemming Andreasen skrev: >>> Do you have any concerns with the relevant text on this point in the >>> draft right now (if so, which parts ?) >>> >> >> I think section 3.10 might be not contain enough normative requirement >> on the media handling. Is this written somewhere else? I think it is >> important to point out that for an answer, he really shouldn't send >> any media if he selects a potential configuration. > I believe the last two paragraphs in Section 3.7.1 (Generating the > Initial Offer) and 3.7.2 (Generating the Answer) address this concern. > > From Section 3.7.1: > > Per [RFC3264], once the offerer generates the offer, he must be > prepared to receive incoming media in accordance with that offer. > That rule applies here as well, but for the actual configurations > provided in the offer only: Media received by the offerer according > to one of the potential configurations MAY be discarded, until the > offerer receives an answer indicating what the actual selected > configuration is. Once that answer is received, incoming media MUST > be processed in accordance with the actual selected configuration > indicated and the answer received (provided the offer/answer > exchange > completed successfully). > The above rule assumes that the offerer can determine whether > incoming media adheres to the actual configuration offered or one of > the potential configurations instead; this may not always be the > case. If the offerer wants to ensure he does not play out any > garbage, the offerer SHOULD discard all media received before the > answer SDP is received. Conversely, if the offerer wants to avoid > clipping, he should attempt to play any incoming media as soon as it > is received (at the risk of playing out garbage). For further > details, please refer to Section 3.10. > > and from Section 3.7.2: > > The offerer's originally provided actual configuration is contained > in the media description's "m=" line (and associated parameters). > The > answerer MAY send media to the offerer in accordance with that > actual > configuration as soon as it receives the offer, however it MUST NOT > send media based on that actual configuration if it selects an > alternative potential configuration. If the answerer selects one of > the potential configurations, then the answerer MAY immediately > start > to send media to the offerer in accordance with the selected > potential configuration, however the offerer MAY discard such media > or play out garbage until the offerer receives the answer. Please > refer to section 3.10. for additional considerations and possible > alternative solutions outside the base SDP Capability Negotiation > framework. > If the offerer selected a potential configuration instead of the > actual configuration, then it is RECOMMENDED that the answerer sends > back an answer SDP as soon as possible. This minimizes the risk of > having media discarded or played out as garbage by the offerer. In > the case of SIP [RFC3261] without any extensions, this implies that > if the offer was received in an INVITE message, then the answer SDP > should be provided in the first non-100 provisional response sent > back (per RFC3261, the answer would need to be repeated in the 200 > response as well, unless a relevant extension such as [RFC3262] is > being used). > > > -- Flemming >> >> 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 >> ---------------------------------------------------------------------- >> > -- 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 Jul 24 17:18: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 1IDRmL-0001Wl-P4; Tue, 24 Jul 2007 17:18:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRmK-0001Wb-FF for mmusic@ietf.org; Tue, 24 Jul 2007 17:18:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRmK-0003Hk-3Y for mmusic@ietf.org; Tue, 24 Jul 2007 17:18:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8EE8720094; Tue, 24 Jul 2007 23:18:47 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-88-46a66cb70464 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7434D20005; Tue, 24 Jul 2007 23:18:47 +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, 24 Jul 2007 23:18:47 +0200 Received: from [138.85.4.148] ([138.85.4.148]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 23:18:47 +0200 Message-ID: <46A66CB4.9050109@ericsson.com> Date: Tue, 24 Jul 2007 23:18:44 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Flemming Andreasen Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> <46A4CB73.1010701@cisco.com> <46A4F8BF.6030504@ericsson.com> <46A50171.1030906@cisco.com> In-Reply-To: <46A50171.1030906@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 21:18:47.0302 (UTC) FILETIME=[38FE2A60:01C7CE38] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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, I had actually missed one of the issues of not providing the FMT strings from the m= line. This has to do with how the format string is defined. I think one has primarily thought about RTP and different profiles that all have the same definition of the FMT part of the m= line. But there exist a number of SDP using protocol that doesn't use a list of RTP payload type numbers in this field. Some contains only "*" such as MSRP or FLUTE, others contain text strings. An example is the UDPTL transport for T.38. Thus clearly, so far one can't handle any case when transport alterernatives are not having a common FMT string definition. 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 Jul 24 17:25: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 1IDRsU-0005ZM-Sc; Tue, 24 Jul 2007 17:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRsS-0005YQ-VA; Tue, 24 Jul 2007 17:25:08 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRsR-0003Ns-LJ; Tue, 24 Jul 2007 17:25:08 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id 4029E181124D; Tue, 24 Jul 2007 23:25:09 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Jul 2007 23:25:04 +0200 To: "Adam Fisk" From: Jiri Kuthan Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070724212509.4029E181124D@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , David Barrett , Jan Janak 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 22:07 24/07/2007, Adam Fisk wrote: >I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. That's marvellous news -- can you send me a pointer to that? > Here are the key points I've taken away from that experience: > >1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. >2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC. >3) ICE is solving a very tricky problem. All three points are wholeheartly easy to agree with. I would have added too ICE is the "right" solution. The question to me is whether Mr. Time and Mr. $ are not against us. That question was asked couple of meetings ago by Spencer D. in an 'sbc bar bof' -- basically fingerpointing at the NAT experience, "right" solution (IPv6) and the outcome. The concern is that by time we have ICE, everyone will have the problem solved using media relays and mass economy will make it a more viable solution than anything else. Future is generally hard to predict (that's why analysts like to predict past :-)), so I think it would be at least a proper step to document current practices (media relays) so that the IETF's picture stays grounded (whatever the risky comeout of work on "right" solutions may be.) -jiri _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 24 17:28: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 1IDRvI-0008PI-OM; Tue, 24 Jul 2007 17:28:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRvI-0008P8-3g for mmusic@ietf.org; Tue, 24 Jul 2007 17:28:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRvH-0007E7-K1 for mmusic@ietf.org; Tue, 24 Jul 2007 17:28:03 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Jul 2007 14:27:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusRAOYBpkarR7MV/2dsb2JhbACIX58d X-IronPort-AV: i="4.16,575,1175497200"; d="scan'208"; a="187884753:sNHT20105723718" 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 l6OLRv4f023240; Tue, 24 Jul 2007 14:27:57 -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 l6OLRvA0028005; Tue, 24 Jul 2007 21:27:57 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); Tue, 24 Jul 2007 14:27:56 -0700 Received: from [10.21.81.223] ([10.21.81.223]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 14:27:56 -0700 Message-ID: <46A66EDB.5000901@cisco.com> Date: Tue, 24 Jul 2007 17:27:55 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types References: <469F9B92.3060906@ericsson.com> <46A4CB73.1010701@cisco.com> <46A4F8BF.6030504@ericsson.com> <46A50171.1030906@cisco.com> <46A66CB4.9050109@ericsson.com> In-Reply-To: <46A66CB4.9050109@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 21:27:56.0359 (UTC) FILETIME=[80419D70:01C7CE39] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1497; t=1185312477; x=1186176477; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20SDPCapNeg-06=3A=20Transport=20capabilites= 20and=20RTP=20payload=0A=20types |Sender:=20; bh=7PECBzzl+aQ+IFcZNN70bl1m6ILV8hPnZtkaQYqVOfw=; b=SybaWouSzl03/r+Ddkju34tJOMgOjmdzgQRNQnmvD62F/dYb8eqUnzrbZX3NOiMzW1xkCNrM x2YO6I91cHiwUm/m3HQaDJ5HnlEx6nTLejFu/F8ltCu/Kf3/kmA0XFbinEJtUzlbT6LNqN5eHl 6k5E4AVDlZmEEQI6Ws/EuJ4Ps=; Authentication-Results: sj-dkim-1; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: > Hi, > > I had actually missed one of the issues of not providing the FMT > strings from the m= line. This has to do with how the format string is > defined. I think one has primarily thought about RTP and different > profiles that all have the same definition of the FMT part of the m= > line. But there exist a number of SDP using protocol that doesn't use > a list of RTP payload type numbers in this field. Some contains only > "*" such as MSRP or FLUTE, others contain text strings. An example is > the UDPTL transport for T.38. > > Thus clearly, so far one can't handle any case when transport > alterernatives are not having a common FMT string definition. Agreed. Again, I'll go back to the requirements where we don't have media format negotiation in scope in the core (nor combinations of media format and transport protocol) - these are left for an extension currently. -- Flemming > > 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 Jul 24 19:22: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 1IDTi9-0007Y6-SC; Tue, 24 Jul 2007 19:22:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTi7-0007Xs-Fj for mmusic@ietf.org; Tue, 24 Jul 2007 19:22:35 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDTi6-0000t8-Rj for mmusic@ietf.org; Tue, 24 Jul 2007 19:22:35 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D5522204E5 for ; Wed, 25 Jul 2007 01:22:33 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-49-46a689b98e0e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C1EBA20052 for ; Wed, 25 Jul 2007 01:22:33 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 01:22:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jul 2007 01:22:32 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05055B979B@esealmw109.eemea.ericsson.se> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bandwidth modifiers in SDPCapNeg Thread-Index: AcfOLkcd4W3U2DmDRkKJoVjFQ5z8VQABO4UgAATh5DA= References: <20070719145334.2EA8B1810C50@mail.iptel.org><20070719180614.85AB218115BC@mail.iptel.org><20070721144803.41B4F1810C56@mail.iptel.org><24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com><20070723205140.EC8031811206@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> From: "Ingemar Johansson S (LU/EAB)" To: X-OriginalArrivalTime: 24 Jul 2007 23:22:33.0339 (UTC) FILETIME=[83417CB0:01C7CE49] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [MMUSIC] Bandwidth modifiers in SDPCapNeg 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 =20 I have been looking at the possibility to include the bandwidth = modifiers from RFC3556 in SDPCapNeg or its companying media cap draft.=20 As the whole configuration is not set until the potential configurations = my interpretation is that the bandwidth modifiers must be put here. If one look at draft-ietf-mmusic-sdp-media-capabilities page 6 one could = imagine that the pcfg line(s) are modified in the direction a=3Dpcfg:1 m=3D1,3|4,3 t=3D1 a=3D1 pt=3D1:100,4:101,3:102 \ b=3D1:[AS:64,RS:800,RR:2400],4:[AS... and so on (The '\' sign is a line continuation sign) The extra stuff is added after the already existing pcfg info, cannot = say how valid the syntax is but I hope the principle is visible, i.e = that one can set bandwidths for each potential config.=20 As I see it there is at least one consequence, namely that it is not = possible to specify several different options for the transport = capabilities in the same pcfg line as this may mean different bandwidth = settings. The consequence may then be that one need to specify more pcfg = lines. Possibly kicking in open doors with this email, if so the reason is that = the mailthreads are sometimes a pain to follow. Comments are welcome. Ingemar ******************************************* Ingemar Johansson Senior Research Engineer EAB/TVP - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden Tel: +46 (0)8 4043042 ECN: 850-43042 Mobile: +46 (0)730 783289 MSN: ingemarjohansson1965@hotmail.com ******************************************* _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 24 20:07: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 1IDUP9-0004Kh-R8; Tue, 24 Jul 2007 20:07:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUP8-0004Ek-3R for mmusic@ietf.org; Tue, 24 Jul 2007 20:07:02 -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 1IDUP7-0006K5-E6 for mmusic@ietf.org; Tue, 24 Jul 2007 20:07:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6P06uMl028680; Wed, 25 Jul 2007 03:06:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 03:06:55 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 03:06:55 +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); Wed, 25 Jul 2007 03:06:54 +0300 Received: from [10.241.59.124] (daec-linuxvpn059124.americas.nokia.com [10.241.59.124]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6P06q2E009212; Wed, 25 Jul 2007 03:06:53 +0300 Message-ID: <46A6941A.5030108@nokia.com> Date: Wed, 25 Jul 2007 03:06:50 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ext Adam Fisk Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 00:06:54.0914 (UTC) FILETIME=[B5AD9A20:01C7CE4F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Adam, ext Adam Fisk wrote: > I like Phillip's earlier suggestion that the draft stay in the "almost > done" > state like used to happen in the Routing group. This is not how we're supposed to operate in the IETF. We determine when something is good enough and publish it. It can be revised later. There is no such thing as a perfect standard. Otherwise it would not be called a standard. And I am certain that actual implementors have all along been involved in the development of the specifications. How many other implementors would we have to give an opportunity to comment before publication? > I realize that's asking a > lot given how much work has gone into it and how eager everyone is to > finalize it. I think the problem is that standardizing NAT traversal is > just hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more simply, but I don't > have concrete suggestions right now because I'm still pulling my hair out > with the implementation. I'm not talking about drastic changes anywhere, > but all the checklist fiddling sure takes a lot of patience to write. > Simplifications might just be in the description and not necessarily the > algorithm. > > I think it's a hard enough and important enough problem that we owe it to > ourselves to be even more patient with an "almost done" state that adds the > final touches based on real-world feedback. I don't doubt for a second > that > ICE works, but it's so complex that I worry no one outside huge companies > will ever implement it. That would be a huge hindrance to ICE's adoption > and power. There are a lot of other protocols that are complex. For instance, if I were to start implementing something that required TLS, I would not dream of starting the effort by implementing my own crypto library. And just for this reason, I strongly believe that one of the keys to success of ICE is the availability of good-quality, appropriately licensed open source implementations, so I applaud your efforts. There is also another FOSS effort, in which what some might call a "huge company" has been involved: http://www1.ietf.org/mail-archive/web/mmusic/current/msg06016.html Cheers, Aki _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 25 10:00: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 1IDhPe-0001by-C3; Wed, 25 Jul 2007 10:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhPc-0001bh-Bp for mmusic@ietf.org; Wed, 25 Jul 2007 10:00:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDhPb-00087m-Jl for mmusic@ietf.org; Wed, 25 Jul 2007 10:00:24 -0400 Received: by wx-out-0506.google.com with SMTP id h27so176063wxd for ; Wed, 25 Jul 2007 07:00:21 -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:references:x-google-sender-auth; b=Iqig/Yg8X8OXxVqOya+XdIuWz2Z0BAKGnD4/Wx8MVfkKu2/PY5D9hgz7HUt71Vzn8rc5x7+avcXpvQfArHvKkllu457/+Hmc30hhptvlPizzhrNhZFGNejGKwKBgUN1aXdsjjjg34N5hzqF2F97arqjBIR0dXN/6yDYLxuD/lBI= 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:references:x-google-sender-auth; b=Fp4dilU1tKDa9q6qmwg2ChU4ikal1PxOq+tODSV/d5SIqy1LiNIHYQcKJz0tbzZvhIgr9NqcxCVfFK/qBwO3bKHywjaD6z1kcUsAOixItpAtWwmb/jPr/vaCbTV+zP3PXJIk0MVzv5MPB5zOVY+dOlZ73erwRNoluogIF/P7WhY= Received: by 10.90.116.6 with SMTP id o6mr430269agc.1185372021363; Wed, 25 Jul 2007 07:00:21 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Wed, 25 Jul 2007 07:00:21 -0700 (PDT) Message-ID: Date: Wed, 25 Jul 2007 10:00:21 -0400 From: "Adam Fisk" To: "Henry Sinnreich" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> X-Google-Sender-Auth: 3fae490a26934a3b X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: mmusic@ietf.org, sip@ietf.org, Jiri Kuthan , Juha Heinanen , David Barrett , Jan Janak 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="===============1077996661==" Errors-To: mmusic-bounces@ietf.org --===============1077996661== Content-Type: multipart/alternative; boundary="----=_Part_93954_1009523.1185372021190" ------=_Part_93954_1009523.1185372021190 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We do plan on doing that eventually, Henry, but it will be awhile. We're a 2 coder shop, so these things take us forever, but we will definitely do that at some point. It just might not be in 2007, honestly, so it would likely be too late to be useful for the WG. -Adam On 7/24/07, Henry Sinnreich wrote: > > Adam, > > > > I fully agree with your positive assessment of the ICE-17 document. > > > > Do you by any chance plan to also develop a test tool for testing the NAT > environment and the success/failure cases, connection times, etc., to > measure results? > > > > Or maybe you know someone who does? > > > > Thanks, Henry > > > ------------------------------ > > *From:* adamfisk@gmail.com [mailto:adamfisk@gmail.com] *On Behalf Of *Adam > Fisk > *Sent:* Tuesday, July 24, 2007 3:08 PM > *To:* Jiri Kuthan > *Cc:* Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; > mmusic@ietf.org > *Subject:* Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LC for RFC > > > > I've followed ICE development on the sidelines for years now, and I'm > currently implementing ICE 17. I've implemented what will be open source > implementations of STUN and TURN, both client and server. Here are the key > points I've taken away from that experience: > > 1) The patience of Jonathan and everyone else in meticulously getting to > the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. I was > surprised at how hard it was, particularly for a draft that's so close to > becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in the "almost > done" state like used to happen in the Routing group. I realize that's > asking a lot given how much work has gone into it and how eager everyone is > to finalize it. I think the problem is that standardizing NAT traversal is > just hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more simply, but I don't > have concrete suggestions right now because I'm still pulling my hair out > with the implementation. I'm not talking about drastic changes anywhere, > but all the checklist fiddling sure takes a lot of patience to write. > Simplifications might just be in the description and not necessarily the > algorithm. > > I think it's a hard enough and important enough problem that we owe it to > ourselves to be even more patient with an "almost done" state that adds the > final touches based on real-world feedback. I don't doubt for a second that > ICE works, but it's so complex that I worry no one outside huge companies > will ever implement it. That would be a huge hindrance to ICE's adoption > and power. > > -Adam > ------=_Part_93954_1009523.1185372021190 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We do plan on doing that eventually, Henry, but it will be awhile.  We're a 2 coder shop, so these things take us forever, but we will definitely do that at some point.  It just might not be in 2007, honestly, so it would likely be too late to be useful for the WG.

-Adam


On 7/24/07, Henry Sinnreich <hsinnrei@adobe.com> wrote:

Adam,

 

I fully agree with your positive assessment of the ICE-17 document.

 

Do you by any chance plan to also develop a test tool for testing the NAT environment and the success/failure cases, connection times, etc., to measure results?

 

Or maybe you know someone who does?

 

Thanks, Henry

 

From: adamfisk@gmail.com [mailto: adamfisk@gmail.com] On Behalf Of Adam Fisk
Sent: Tuesday, July 24, 2007 3:08 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; sip@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC

 

I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.  Here are the key points I've taken away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group.  I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler.  In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation.  I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback.  I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it.  That would be a huge hindrance to ICE's adoption and power.

-Adam


------=_Part_93954_1009523.1185372021190-- --===============1077996661== 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 --===============1077996661==-- From mmusic-bounces@ietf.org Wed Jul 25 10:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhdy-0001JJ-0J; Wed, 25 Jul 2007 10:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhdw-0001JE-2o for mmusic@ietf.org; Wed, 25 Jul 2007 10:15:12 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDhdv-0008NS-GQ for mmusic@ietf.org; Wed, 25 Jul 2007 10:15:12 -0400 Received: by wx-out-0506.google.com with SMTP id h27so180289wxd for ; Wed, 25 Jul 2007 07:15:11 -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:references:x-google-sender-auth; b=tgU32w5LyDEFzr8JmnYTF8swt/YOGpKjykxwfhO3YjT+eGKSoaiH8jDRAEh49jm89yUz3iAM/hotOpOaPj5kgEkVyeU44KvulI6mjxO4jEoC9If2Tt7fBoNoHYGaWTfEHWuDT42T9OEpLi/4sNd/2BhmflXlW4B76KJwUWD4OxM= 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:references:x-google-sender-auth; b=VIqGS30kUMcnKEb1RGvzQUNWn8i7/Z81FGQMgkKB6y0F27kboWNs2hSmYbt9eaESuPNeTB4BRcvqOP+HLyfScYkPE6KBL63+pbhI2wTE5xClnxym54dw6AdFvrz7bqkppdId+Soa/QYhRYY379PvnDWHuESkOtH7YrGQkgn1jbA= Received: by 10.70.87.11 with SMTP id k11mr1213859wxb.1185372911233; Wed, 25 Jul 2007 07:15:11 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Wed, 25 Jul 2007 07:15:11 -0700 (PDT) Message-ID: Date: Wed, 25 Jul 2007 10:15:11 -0400 From: "Adam Fisk" To: "Aki Niemi" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <46A6941A.5030108@nokia.com> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> <46A6941A.5030108@nokia.com> X-Google-Sender-Auth: bacacad81e8fd8ea X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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="===============1042154250==" Errors-To: mmusic-bounces@ietf.org --===============1042154250== Content-Type: multipart/alternative; boundary="----=_Part_94150_4023709.1185372911111" ------=_Part_94150_4023709.1185372911111 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Aki- > This is not how we're supposed to operate in the IETF. We determine when > something is good enough and publish it. It can be revised later. There > is no such thing as a perfect standard. Otherwise it would not be called > a standard. Understood. It just sounded like a prudent approach -- more of a "real-world beta". The more I wrap my ahead around ICE-17, the more I become convinced it is the right approach and "good enough." The fact that it's such a pain to implement made me think there must be possible simplifications, but I have yet to be able to point to any concrete suggestion. So the draft's holding up strongly for me. > > There are a lot of other protocols that are complex. For instance, if I > were to start implementing something that required TLS, I would not > dream of starting the effort by implementing my own crypto library. Yes. I think that's the key. ICE is hard, and implementors have to realize that going in. I think it's mostly tricky because everything is so ICE-specific. There aren't a lot of "gimmes" in ICE where you read it and think "oh, no problem, that's just like X RFC or draft" -- things you can just knock off without thinking too much about it. As such, it takes considerable coding patience and endurance to plow through. But that's fine. And just for this reason, I strongly believe that one of the keys to > success of ICE is the availability of good-quality, appropriately > licensed open source implementations, so I applaud your efforts. There > is also another FOSS effort, in which what some might call a "huge > company" has been involved: > > http://www1.ietf.org/mail-archive/web/mmusic/current/msg06016.html Ah, great! I had missed that. I love Nokia's efforts in this area. Thanks. -Adam ------=_Part_94150_4023709.1185372911111 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Aki-


This is not how we're supposed to operate in the IETF. We determine when
something is good enough and publish it. It can be revised later. There
is no such thing as a perfect standard. Otherwise it would not be called
a standard.

Understood.  It just sounded like a prudent approach -- more of a "real-world beta".  The more I wrap my ahead around ICE-17, the more I become convinced it is the right approach and "good enough."  The fact that it's such a pain to implement made me think there must be possible simplifications, but I have yet to be able to point to any concrete suggestion.  So the draft's holding up strongly for me.



There are a lot of other protocols that are complex. For instance, if I
were to start implementing something that required TLS, I would not
dream of starting the effort by implementing my own crypto library.

Yes.  I think that's the key.  ICE is hard, and implementors have to realize that going in.  I think it's mostly tricky because everything is so ICE-specific.  There aren't a lot of "gimmes" in ICE where you read it and think "oh, no problem, that's just like X RFC or draft"  -- things you can just knock off without thinking too much about it.  As such, it takes considerable coding patience and endurance to plow through.  But that's fine.

And just for this reason, I strongly believe that one of the keys to
success of ICE is the availability of good-quality, appropriately
licensed open source implementations, so I applaud your efforts. There
is also another FOSS effort, in which what some might call a "huge
company" has been involved:

http://www1.ietf.org/mail-archive/web/mmusic/current/msg06016.html

Ah, great!  I had missed that.  I love Nokia's efforts in this area.  Thanks.

-Adam


------=_Part_94150_4023709.1185372911111-- --===============1042154250== 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 --===============1042154250==-- From mmusic-bounces@ietf.org Wed Jul 25 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 1IDlRK-00011A-Mh; Wed, 25 Jul 2007 14:18:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlRH-0000zb-R1; Wed, 25 Jul 2007 14:18:23 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlRH-0005DZ-I1; Wed, 25 Jul 2007 14:18:23 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4C22E175D5; Wed, 25 Jul 2007 18:18:23 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IDlRG-00037m-TJ; Wed, 25 Jul 2007 14:18:22 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 25 Jul 2007 14:18:22 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: draft-ietf-mmusic-ice (Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-08-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11119&rfc_flag=0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Jul 25 23:04: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 1IDtei-0006ZR-8f; Wed, 25 Jul 2007 23:04:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDteg-0006ZA-O0; Wed, 25 Jul 2007 23:04:46 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDteg-0007c9-3o; Wed, 25 Jul 2007 23:04:46 -0400 Received: from cornfed (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 868641C802D; Wed, 25 Jul 2007 21:49:26 -0500 (CDT) From: "Frank W. Miller" To: "'Jiri Kuthan'" , "'Henry Sinnreich'" , "'David Barrett'" , "'Jan Janak'" , "'Juha Heinanen'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICEdeploymentdatabefore LC for RFC Date: Wed, 25 Jul 2007 21:04:43 -0600 Message-ID: <00d601c7cf31$b81c5480$6901a8c0@cornfed> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20070723205140.EC8031811206@mail.iptel.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: sip@ietf.org, 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 For those that may not know, another example of this is IAX2 which is currently under review for publication by the IETF. This protocol clearly competes with SIP at least on some fronts. It may be difficult for new protocols to emerge, particularly with there is such huge momentum behind one, but it can happen. FM -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org] Sent: Monday, July 23, 2007 2:38 PM To: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen Cc: sip@ietf.org; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICEdeploymentdatabefore LC for RFC At 19:10 21/07/2007, Henry Sinnreich wrote: >I fully agree with Jiri that this is an IETF problem and not an ICE >problem. >ICE-17 is a great document, no doubt about it. > >What happens however of someone finds an innovative approach that may >work better? Will it be rejected because it will not be RFC standards >compliant? I don't think so, IETF is having a history of working on competing standards, jabber and simple being a prominent and recent example thereof. I think that's actually with current IETF's size and dynamics a fairly good strategy to eliminate single points of failure. -jiri >What could an innovator tell customers about a solution that works >better but is not IETF ICE RFC standards compliant? > >Henry > >-----Original Message----- >From: Jiri Kuthan [mailto:jiri@iptel.org] >Sent: Saturday, July 21, 2007 9:48 AM >To: David Barrett; 'Jan Janak'; 'Juha Heinanen' >Cc: sip@ietf.org; mmusic@ietf.org >Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE >deploymentdatabefore LC for RFC > >At 20:05 19/07/2007, David Barrett wrote: >>> -----Original Message----- >>> From: Jiri Kuthan [mailto:jiri@iptel.org] >>> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment >databefore >>> LC for RFC >>> >>> So I think that the right course of action is that folks doubting ICE >>> reliability >>> make their case (by that I mean specific arguments rather than >emotional >>> debates >>> about red-colored nails and other hardware). >> >>Er, my "specific argument" is "until it's been proven to work, it >hasn't >>been proven to work". It's tautological, but no less true for it. >> >>Indeed, if you're *not* doubting ICE, why aren't you? > >Hi David, > >I'm not entirely sure what is the step you are suggesting? > >I think ICE is architecturally right answer to the right problem. >Notwithstanding that, there are certainly some things I prefer >differently (e.g., the infamous debate about proactive hole punching) >or may turn out to be bugs. I think though that the key problem at >this point is of institutional nature. In the IETF language, "hasn't >been proven to work" is adequate to "lacking running code" and this >appears to be a phenomen which is indeed occuring in the IETF and >is not unique to ICE. > >The question is how to get this fixed? > >Some other standardization bodies enjoying the amount of contributions >and complexity as the IETF is enjoying now (S in SIP does not really >stand for Simple), proceed with 'after-fact filters', in that they >produce the initial specs faster and later produce 'profiles' which >separate what has proved and what less. Plus -bis versions are produced >for whatever appears worth puttting effort in it (i.e., for which there >is running code and field evidence of improvement need).This could be >an approach which may be more feasible in today's IETF's dimension than > >trying to get back to historical roots. > >-jiri > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 26 00:41: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 1IDvA5-00036p-PU; Thu, 26 Jul 2007 00:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDvA4-00036k-60 for mmusic@ietf.org; Thu, 26 Jul 2007 00:41:16 -0400 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDvA3-0003UK-EL for mmusic@ietf.org; Thu, 26 Jul 2007 00:41:16 -0400 Received: by wx-out-0506.google.com with SMTP id h27so364751wxd for ; Wed, 25 Jul 2007 21:41:15 -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:references:x-google-sender-auth; b=G7N0Nfb2q2bpSTsOLYu8obMlv1+Af3rEw7Lu1pInkCM5UTCZXnvkX2/eiUMsjFHTXo/262UR3r9tPBsS2rVaTxO8eFP0gUrRSk7tV/PKoDwoxulIDgxSyl2WWftq7SMM6JWBzTxYS/IjZKlJpK676SKfYH1r61TgVxFxwBQ7+QE= 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:references:x-google-sender-auth; b=Sb/z5iUanyhh3H8qzxdSK/SXEo1Xv3XieBI5Tvl0r7dNNjyCnxmPBvdQDkAK/LDTZSiqV3FjLfTwWBEzVCKrNFy8F32MqiIVaO1BB3ZGAcaoj5jIqlBRT58toZkyTVPy00Jxi6otEQvA+QAjWtH3lrhcfXJXsay65Azt/mDvrt8= Received: by 10.70.96.3 with SMTP id t3mr2419527wxb.1185424875100; Wed, 25 Jul 2007 21:41:15 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Wed, 25 Jul 2007 21:41:14 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 00:41:14 -0400 From: "Adam Fisk" To: "Jiri Kuthan" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> X-Google-Sender-Auth: 4676f8fc4d91e5c1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Jan Janak , Juha Heinanen , David Barrett , 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="===============1562620633==" Errors-To: mmusic-bounces@ietf.org --===============1562620633== Content-Type: multipart/alternative; boundary="----=_Part_101884_30940363.1185424874990" ------=_Part_101884_30940363.1185424874990 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I had a conversation earlier tonight at the NYC p2p meetup that led me to question my previous assumptions about ICE "working". Supposedly many routers start to do funny things when they see lots of ICE UDP packets flying by and trying lots of candidates. This has me worried. We all know the frightening number of NAT configurations out there. Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE? If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)? I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia. I think performing those simple tests would set everyone's mind at ease. Otherwise, I am concerned that some NAT and firmware combinations would balk at what they see as packet floods. To a person, everyone I've talked to who has implemented this stuff in the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at first. I think this is the central problem -- the world we're deploying this in is much more chaotic than that of more RFCs, as the BEHAVE group is trying to address. -Adam On 7/24/07, Adam Fisk wrote: > > I've followed ICE development on the sidelines for years now, and I'm > currently implementing ICE 17. I've implemented what will be open source > implementations of STUN and TURN, both client and server. Here are the key > points I've taken away from that experience: > > 1) The patience of Jonathan and everyone else in meticulously getting to > the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. I was > surprised at how hard it was, particularly for a draft that's so close to > becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in the "almost > done" state like used to happen in the Routing group. I realize that's > asking a lot given how much work has gone into it and how eager everyone is > to finalize it. I think the problem is that standardizing NAT traversal is > just hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more simply, but I don't > have concrete suggestions right now because I'm still pulling my hair out > with the implementation. I'm not talking about drastic changes anywhere, > but all the checklist fiddling sure takes a lot of patience to write. > Simplifications might just be in the description and not necessarily the > algorithm. > > I think it's a hard enough and important enough problem that we owe it to > ourselves to be even more patient with an "almost done" state that adds the > final touches based on real-world feedback. I don't doubt for a second that > ICE works, but it's so complex that I worry no one outside huge companies > will ever implement it. That would be a huge hindrance to ICE's adoption > and power. > > -Adam > > > ------=_Part_101884_30940363.1185424874990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I had a conversation earlier tonight at the NYC p2p meetup that led me to question my previous assumptions about ICE "working".  Supposedly many routers start to do funny things when they see lots of ICE UDP packets flying by and trying lots of candidates.

This has me worried.  We all know the frightening number of NAT configurations out there.  Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE?  If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)?  I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia.

I think performing those simple tests would set everyone's mind at ease.  Otherwise, I am concerned that some NAT and firmware combinations would balk at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at first.  I think this is the central problem -- the world we're deploying this in is much more chaotic than that of more RFCs, as the BEHAVE group is trying to address.

-Adam


On 7/24/07, Adam Fisk <a@lastbamboo.org> wrote:
I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.  Here are the key points I've taken away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group.  I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler.  In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation.  I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback.  I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it.  That would be a huge hindrance to ICE's adoption and power.

-Adam



------=_Part_101884_30940363.1185424874990-- --===============1562620633== 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 --===============1562620633==-- From mmusic-bounces@ietf.org Thu Jul 26 07:12: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 1IE1GA-000575-0x; Thu, 26 Jul 2007 07:11:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1G7-00056f-Cm; Thu, 26 Jul 2007 07:11:55 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE1G6-0000wj-7h; Thu, 26 Jul 2007 07:11:55 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 26 Jul 2007 04:11:32 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6QBBOWs010290; Thu, 26 Jul 2007 04:11:29 -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 l6QB9KI9000054; Thu, 26 Jul 2007 04:09:20 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 04:11:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Thu, 26 Jul 2007 04:09:54 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeA References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> From: "Henry Sinnreich" To: "Adam Fisk" , "Jiri Kuthan" X-OriginalArrivalTime: 26 Jul 2007 11:11:23.0362 (UTC) FILETIME=[B389BC20:01C7CF75] X-Spam-Score: 0.0 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: behave@ietf.org, mmusic@ietf.org, Juha Heinanen , David Barrett , Jan Janak , P2PSIP 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: , Content-Type: multipart/mixed; boundary="===============0459014707==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0459014707== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CF75.B153F385" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CF75.B153F385 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This insight may be very useful when designing a test tool for ICE.=20 As I have insisted, we need deployment testing for ICE and continued tweaking to make it real. I have no idea what the deployment testing may reveal and the attached is a welcome example. =20 Is anyone on these lists designing a test tool for NAT scenario discovery and for ICE? =20 Henry =20 ________________________________ From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk Sent: Wednesday, July 25, 2007 11:41 PM To: Jiri Kuthan Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 I had a conversation earlier tonight at the NYC p2p meetup that led me to question my previous assumptions about ICE "working". Supposedly many routers start to do funny things when they see lots of ICE UDP packets flying by and trying lots of candidates.=20 This has me worried. We all know the frightening number of NAT configurations out there. Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE? If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)? I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia.=20 I think performing those simple tests would set everyone's mind at ease. Otherwise, I am concerned that some NAT and firmware combinations would balk at what they see as packet floods. To a person, everyone I've talked to who has implemented this stuff in the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at first. I think this is the central problem -- the world we're deploying this in is much more chaotic than that of more RFCs, as the BEHAVE group is trying to address.=20 -Adam On 7/24/07, Adam Fisk wrote: I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience:=20 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.=20 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm.=20 I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power.=20 -Adam =20 ------_=_NextPart_001_01C7CF75.B153F385 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This insight may be very useful = when designing a test tool for ICE.

As I have insisted, we need = deployment testing for ICE and continued tweaking to make it = real.

I have no idea what the deployment = testing may reveal and the attached is a welcome = example.

 

Is anyone on these lists designing = a test tool for NAT scenario discovery and for = ICE?

 

Henry

 

From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk
Sent: Wednesday, July 25, = 2007 11:41 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; = David Barrett; Jan Janak; Juha Heinanen; mmusic@ietf.org
Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

I had a = conversation earlier tonight at the NYC p2p meetup that led me to question my = previous assumptions about ICE "working".  Supposedly many routers = start to do funny things when they see lots of ICE UDP packets flying by and = trying lots of candidates.

This has me worried.  We all know the frightening number of NAT configurations out there.  Maybe I missed it, but is there a test = matrix somewhere of NAT combinations and their success rates with ICE?  If = not, could we create one using one of the open source ICE implementations out = there (mine's not quite ready)?  I'd be happy to contribute my own router = if we had a simple test program, maybe based on the work at Nokia.

I think performing those simple tests would set everyone's mind at = ease.  Otherwise, I am concerned that some NAT and firmware combinations would = balk at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in = the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at = first.  I think this is the central problem -- the world we're deploying this in = is much more chaotic than that of more RFCs, as the BEHAVE group is trying to = address.

-Adam

On 7/24/07, Adam Fisk <a@lastbamboo.org> wrote:

I've followed = ICE development on the sidelines for years now, and I'm currently = implementing ICE 17.  I've implemented what will be open source implementations of = STUN and TURN, both client and server.  Here are the key points I've taken = away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to = the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I = was surprised at how hard it was, particularly for a draft that's so close = to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the = "almost done" state like used to happen in the Routing group.  I = realize that's asking a lot given how much work has gone into it and how eager = everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make = simpler.  In my implementation of ICE, I do think it could be done more simply, = but I don't have concrete suggestions right now because I'm still pulling my = hair out with the implementation.  I'm not talking about drastic changes = anywhere, but all the checklist fiddling sure takes a lot of patience to = write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it = to ourselves to be even more patient with an "almost done" state = that adds the final touches based on real-world feedback.  I don't doubt = for a second that ICE works, but it's so complex that I worry no one outside = huge companies will ever implement it.  That would be a huge hindrance = to ICE's adoption and power.

-Adam

 

------_=_NextPart_001_01C7CF75.B153F385-- --===============0459014707== 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 --===============0459014707==-- From mmusic-bounces@ietf.org Thu Jul 26 10:00: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 1IE3tP-000189-5S; Thu, 26 Jul 2007 10:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE3tM-00017p-Hy for mmusic@ietf.org; Thu, 26 Jul 2007 10:00:36 -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 1IE3tL-00061d-4F for mmusic@ietf.org; Thu, 26 Jul 2007 10:00:36 -0400 Received: from dhcp-17f5.ietf69.org ([130.129.23.245]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IE3tG-0000HD-13; Thu, 26 Jul 2007 10:00:30 -0400 In-Reply-To: References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Philip Matthews Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Thu, 26 Jul 2007 09:00:35 -0500 To: Adam Fisk X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - dhcp-17f5.ietf69.org [130.129.23.245] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Jiri Kuthan , Juha Heinanen , Jan Janak , mmusic@ietf.org, David Barrett 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="===============1203575140==" Errors-To: mmusic-bounces@ietf.org --===============1203575140== Content-Type: multipart/alternative; boundary=Apple-Mail-20-992805879 --Apple-Mail-20-992805879 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Have these people implemented the pacing stuff that is in ICE? This behavior is why ICE has this pacing stuff. - Philip On 25-Jul-07, at 23:41 , Adam Fisk wrote: > I had a conversation earlier tonight at the NYC p2p meetup that led > me to question my previous assumptions about ICE "working". > Supposedly many routers start to do funny things when they see lots > of ICE UDP packets flying by and trying lots of candidates. > > This has me worried. We all know the frightening number of NAT > configurations out there. Maybe I missed it, but is there a test > matrix somewhere of NAT combinations and their success rates with > ICE? If not, could we create one using one of the open source ICE > implementations out there (mine's not quite ready)? I'd be happy > to contribute my own router if we had a simple test program, maybe > based on the work at Nokia. > > I think performing those simple tests would set everyone's mind at > ease. Otherwise, I am concerned that some NAT and firmware > combinations would balk at what they see as packet floods. > > To a person, everyone I've talked to who has implemented this stuff > in the "real world" has said the array of problems with specific > NAT configurations is much more significant than they realized at > first. I think this is the central problem -- the world we're > deploying this in is much more chaotic than that of more RFCs, as > the BEHAVE group is trying to address. > > -Adam > > > On 7/24/07, Adam Fisk wrote: > I've followed ICE development on the sidelines for years now, and > I'm currently implementing ICE 17. I've implemented what will be > open source implementations of STUN and TURN, both client and > server. Here are the key points I've taken away from that experience: > > 1) The patience of Jonathan and everyone else in meticulously > getting to the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. I > was surprised at how hard it was, particularly for a draft that's > so close to becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in the > "almost done" state like used to happen in the Routing group. I > realize that's asking a lot given how much work has gone into it > and how eager everyone is to finalize it. I think the problem is > that standardizing NAT traversal is just hard, and hard problems > are difficult to make simpler. In my implementation of ICE, I do > think it could be done more simply, but I don't have concrete > suggestions right now because I'm still pulling my hair out with > the implementation. I'm not talking about drastic changes > anywhere, but all the checklist fiddling sure takes a lot of > patience to write. Simplifications might just be in the > description and not necessarily the algorithm. > > I think it's a hard enough and important enough problem that we owe > it to ourselves to be even more patient with an "almost done" state > that adds the final touches based on real-world feedback. I don't > doubt for a second that ICE works, but it's so complex that I worry > no one outside huge companies will ever implement it. That would > be a huge hindrance to ICE's adoption and power. > > -Adam > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --Apple-Mail-20-992805879 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Have these people implemented = the pacing stuff that is in ICE?=A0 This behavior is why ICE has this = pacing stuff.

- = Philip

On 25-Jul-07, at = 23:41 , Adam Fisk wrote:

I had a = conversation earlier tonight at the NYC p2p meetup that led me to = question my previous assumptions about ICE "working".=A0 Supposedly many = routers start to do funny things when they see lots of ICE UDP packets = flying by and trying lots of candidates.

This has me worried.=A0 = We all know the frightening number of NAT configurations out there.=A0 = Maybe I missed it, but is there a test matrix somewhere of NAT = combinations and their success rates with ICE?=A0 If not, could we = create one using one of the open source ICE implementations out there = (mine's not quite ready)?=A0 I'd be happy to contribute my own router if = we had a simple test program, maybe based on the work at Nokia. =

I think performing those simple tests would set everyone's mind = at ease.=A0 Otherwise, I am concerned that some NAT and firmware = combinations would balk at what they see as packet floods.

To a = person, everyone I've talked to who has implemented this stuff in the = "real world" has said the array of problems with specific NAT = configurations is much more significant than they realized at first.=A0 = I think this is the central problem -- the world we're deploying this in = is much more chaotic than that of more RFCs, as the BEHAVE group is = trying to address.

-Adam


On 7/24/07, Adam = Fisk <a@lastbamboo.org> = wrote:
I've followed ICE development on the sidelines for years now, and = I'm currently implementing ICE 17.=A0 I've implemented what will be open = source implementations of STUN and TURN, both client and server.=A0 Here = are the key points I've taken away from that experience:

1) The = patience of Jonathan and everyone else in meticulously getting to the = current draft is astonishing.
2) ICE is complex as hell and a pain in = the ^#* to implement.=A0 I was surprised at how hard it was, = particularly for a draft that's so close to becoming an RFC.
3) ICE = is solving a very tricky problem.

I like Phillip's earlier = suggestion that the draft stay in the "almost done" state like used to = happen in the Routing group.=A0 I realize that's asking a lot given how = much work has gone into it and how eager everyone is to finalize it.=A0 = I think the problem is that standardizing NAT traversal is just hard, = and hard problems are difficult to make simpler.=A0 In my implementation = of ICE, I do think it could be done more simply, but I don't have = concrete suggestions right now because I'm still pulling my hair out = with the implementation.=A0 I'm not talking about drastic changes = anywhere, but all the checklist fiddling sure takes a lot of patience to = write.=A0 Simplifications might just be in the description and not = necessarily the algorithm.

I think it's a hard enough and = important enough problem that we owe it to ourselves to be even more = patient with an "almost done" state that adds the final touches based on = real-world feedback.=A0 I don't doubt for a second that ICE works, but = it's so complex that I worry no one outside huge companies will ever = implement it.=A0 That would be a huge hindrance to ICE's adoption and = power.

-Adam


=

mmusic mailing list
=

= --Apple-Mail-20-992805879-- --===============1203575140== 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 --===============1203575140==-- From mmusic-bounces@ietf.org Thu Jul 26 12:19: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 1IE63h-0007B2-MK; Thu, 26 Jul 2007 12:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE63c-000759-H3; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE63b-0002lR-B9; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2007 12:19:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANxlqEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175486400"; d="scan'208"; a="127119221:sNHT26802332" 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 l6QGJIaP025436; Thu, 26 Jul 2007 12:19:18 -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 l6QGIsWk003600; Thu, 26 Jul 2007 16:19:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 12:19:06 -0400 Received: from [10.86.241.65] ([10.86.241.65]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 12:19:06 -0400 Message-ID: <46A8C983.4060302@cisco.com> Date: Thu, 26 Jul 2007 12:19:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 16:19:06.0078 (UTC) FILETIME=[B02C9FE0:01C7CFA0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=740; t=1185466758; x=1186330758; 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:=20ICE=20tutorial=20in=20Chicago=20=20-=20PLEASE=20PAY=20IF=20YO U=20ATE=20LUNCH |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=Zrtno2xh1JufqqypXQrJG3eaM0QxnaFVcCRKizkJRlU=; b=EAbRlhLzYaOy4oHUNIotoEwBXwvoS8Zp1gyIR9U0ZLbsLNA0SW2PWFoOvExi7DXio14brEfh Ctw1A+j6KiaWFP+lwWplEuOmXoKwNKI3GCkheAO1e18guOsiXHEOunJT; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [MMUSIC] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH 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 Lunch during the tutorial was paid out of my pocket, and I was expecting to get re-imbursed by everyone that took a sandwich. Though all of the food was taken by the end of the tutorial, I am several hundred dollars short. Please, if you took lunch and did not give me $20, give it to me before you leave, and if you have not, contact me privately and we can arrange for paper mail. 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 Jul 26 14:15: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 1IE7rm-0000Is-VI; Thu, 26 Jul 2007 14:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7rl-0000IQ-6K; Thu, 26 Jul 2007 14:15:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE7rj-0005fX-O8; Thu, 26 Jul 2007 14:15:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2007 11:15:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMWBqEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="189195896:sNHT91438155" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6QIFA3L015996; Thu, 26 Jul 2007 11:15:10 -0700 Received: from dwingwxp ([10.21.118.134]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QIF16D025827; Thu, 26 Jul 2007 18:15:02 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Adam Fisk'" , "'Jiri Kuthan'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Thu, 26 Jul 2007 13:14:35 -0500 Message-ID: <05d701c7cfb0$e71ed620$3015590a@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.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> thread-index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeAAAqJ3lA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5139; t=1185473710; x=1186337710; c=relaxed/simple; s=sjdkim2002; 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]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20; bh=ykxSheCBcPAaJEACuzGg9KmUWyl5qLkfBJI6uD/fzmY=; b=WGquyMh/LgJgZG6ORZt/14XukZFS83KmCvPnKRLAs1BzXA2/mNktmo0+/vUwbzQn4eSZ5vzb TBK4Pp6XvH2j3rmDAogyO2IL0iU5tUFE4S91zxQam63awzQhB9iPntDX; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 'Jan Janak' , 'Juha Heinanen' , behave@ietf.org, mmusic@ietf.org, 'P2PSIP 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 > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, July 26, 2007 6:10 AM > To: Adam Fisk; Jiri Kuthan > Cc: behave@ietf.org; mmusic@ietf.org; Juha Heinanen; Jan > Janak; P2PSIP WG > Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LCfor RFC > > This insight may be very useful when designing a test tool for ICE. > > As I have insisted, we need deployment testing for ICE and > continued tweaking to make it real. > > I have no idea what the deployment testing may reveal and the > attached is a welcome example. > > > > Is anyone on these lists designing a test tool for NAT > scenario discovery and for ICE? Awhile back Christian Huitema announced Microsoft's NAT testing tool, http://www1.ietf.org/mail-archive/web/behave/current/msg02117.html > > Microsoft just released a tool that may be interesting for > this list: > http://www.microsoft.com/windows/using/tools/igd/default.mspx > The tool applies various tests against routers to check > how they implement NAT, UPNP, or support of various TCP > options. It is based on Microsoft's "home networking" > requirements for XP and Vista. Arguably, a later version > could implement BEHAVE's requirement, when they are > published by the IETF. > > -- Christian Huitema > It requires a browser that supports Active X. -d > Henry > > > > ________________________________ > > From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On > Behalf Of Adam Fisk > Sent: Wednesday, July 25, 2007 11:41 PM > To: Jiri Kuthan > Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; > mmusic@ietf.org > Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LC for RFC > > > > I had a conversation earlier tonight at the NYC p2p meetup > that led me to question my previous assumptions about ICE > "working". Supposedly many routers start to do funny things > when they see lots of ICE UDP packets flying by and trying > lots of candidates. > > This has me worried. We all know the frightening number of > NAT configurations out there. Maybe I missed it, but is > there a test matrix somewhere of NAT combinations and their > success rates with ICE? If not, could we create one using > one of the open source ICE implementations out there (mine's > not quite ready)? I'd be happy to contribute my own router > if we had a simple test program, maybe based on the work at Nokia. > > I think performing those simple tests would set everyone's > mind at ease. Otherwise, I am concerned that some NAT and > firmware combinations would balk at what they see as packet floods. > > To a person, everyone I've talked to who has implemented this > stuff in the "real world" has said the array of problems with > specific NAT configurations is much more significant than > they realized at first. I think this is the central problem > -- the world we're deploying this in is much more chaotic > than that of more RFCs, as the BEHAVE group is trying to address. > > -Adam > > On 7/24/07, Adam Fisk wrote: > > I've followed ICE development on the sidelines for years now, > and I'm currently implementing ICE 17. I've implemented what > will be open source implementations of STUN and TURN, both > client and server. Here are the key points I've taken away > from that experience: > > 1) The patience of Jonathan and everyone else in meticulously > getting to the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. > I was surprised at how hard it was, particularly for a draft > that's so close to becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in > the "almost done" state like used to happen in the Routing > group. I realize that's asking a lot given how much work has > gone into it and how eager everyone is to finalize it. I > think the problem is that standardizing NAT traversal is just > hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more > simply, but I don't have concrete suggestions right now > because I'm still pulling my hair out with the > implementation. I'm not talking about drastic changes > anywhere, but all the checklist fiddling sure takes a lot of > patience to write. Simplifications might just be in the > description and not necessarily the algorithm. > > I think it's a hard enough and important enough problem that > we owe it to ourselves to be even more patient with an > "almost done" state that adds the final touches based on > real-world feedback. I don't doubt for a second that ICE > works, but it's so complex that I worry no one outside huge > companies will ever implement it. That would be a huge > hindrance to ICE's adoption and power. > > -Adam > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 26 14:15: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 1IE7rs-0000PQ-Tg; Thu, 26 Jul 2007 14:15:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7rr-0000PI-Fn for mmusic@ietf.org; Thu, 26 Jul 2007 14:15:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE7rq-0004Rf-Ja for mmusic@ietf.org; Thu, 26 Jul 2007 14:15:19 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2007 11:15:17 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACOCqEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="168293000:sNHT32199381" 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 l6QIFHaH023670; Thu, 26 Jul 2007 11:15:17 -0700 Received: from dwingwxp ([10.21.118.134]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QIF16E025827; Thu, 26 Jul 2007 18:15:10 GMT From: "Dan Wing" To: "'Adam Fisk'" , "'Jiri Kuthan'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Thu, 26 Jul 2007 13:15:10 -0500 Message-ID: <05d801c7cfb0$eae490b0$3015590a@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.3138 In-Reply-To: thread-index: AcfPPz0z/f3iTAzqT62R4RrzU0myJwAYHovg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4920; t=1185473717; x=1186337717; 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=20[MMUSIC]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20; bh=n2e0V+bAXYiaED/SGijYji/4XsUakUVUvrNdIAwTKKs=; b=ROXOo5goZ/zQ4xwjUJ8ila6eJiy6Ztdi8LMrsE/ht8FgivSwQ53dpzPwsqEdgS/JxbLhW+Ky AfRu0TLbzQM7FE9Ji1FGlRpBRo0ZRnUQooptxbwt6HhIVFkwMCxapQFg; 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: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'Juha Heinanen' , 'Jan Janak' , mmusic@ietf.org, 'David Barrett' 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: Adam Fisk [mailto:a@lastbamboo.org] > Sent: Wednesday, July 25, 2007 11:41 PM > To: Jiri Kuthan > Cc: Jan Janak; Juha Heinanen; David Barrett; mmusic@ietf.org > Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LCfor RFC > > I had a conversation earlier tonight at the NYC p2p meetup > that led me to question my previous assumptions about ICE > "working". Supposedly many routers start to do funny things > when they see lots of ICE UDP packets flying by and trying > lots of candidates. *Routers*? Or NATs? Routers don't maintain state and thus aren't aware of new flows or old flows; I would be surprised of this happening and would be very interested in hearing more about it. I suppose all sorts of packet-optimization boxes, network scanning detectors, and intrusion prevention devices might perceive a bunch of ICE probes as a network scanner. > This has me worried. We all know the frightening number of > NAT configurations out there. Maybe I missed it, but is > there a test matrix somewhere of NAT combinations and their > success rates with ICE? No, partially because it's terribly difficult -- if not flat-out impossible -- to emperically test a NAT and determine how its internal code operates (filtering behavior and port mapping behavior). > If not, could we create one using > one of the open source ICE implementations out there (mine's > not quite ready)? I'd be happy to contribute my own router > if we had a simple test program, maybe based on the work at Nokia. There is Microsoft's Active X-based test, see http://www1.ietf.org/mail-archive/web/behave/current/msg02117.html But I'm not aware of anything for ICE; ICE doesn't care what 'kind' of NAT you have, it just tries to get connectivity. Having statistics with ICE would be valuable and would be useful. > I think performing those simple tests would set everyone's > mind at ease. Otherwise, I am concerned that some NAT and > firmware combinations would balk at what they see as packet floods. Some NATs do balk at new UDP flows being initiated quickly and cannot keep up with such new flows. This is described in section B.1 of draft-ietf-mmusic-ice-17, and this is why ICE paces its checks 20ms apart. > To a person, everyone I've talked to who has implemented this > stuff in the "real world" has said the array of problems with > specific NAT configurations is much more significant than > they realized at first. I think this is the central problem > -- the world we're deploying this in is much more chaotic > than that of more RFCs, as the BEHAVE group is trying to address. I fully agree that BEHAVE's documents will not make the problem go away. Like anything (TCP implementation, RTP implementation), a NAT might or might not adhere to the RFCs created by the BEHAVE working group. -d > -Adam > > > > On 7/24/07, Adam Fisk wrote: > > I've followed ICE development on the sidelines for > years now, and I'm currently implementing ICE 17. I've > implemented what will be open source implementations of STUN > and TURN, both client and server. Here are the key points > I've taken away from that experience: > > 1) The patience of Jonathan and everyone else in > meticulously getting to the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to > implement. I was surprised at how hard it was, particularly > for a draft that's so close to becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay > in the "almost done" state like used to happen in the Routing > group. I realize that's asking a lot given how much work has > gone into it and how eager everyone is to finalize it. I > think the problem is that standardizing NAT traversal is just > hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more > simply, but I don't have concrete suggestions right now > because I'm still pulling my hair out with the > implementation. I'm not talking about drastic changes > anywhere, but all the checklist fiddling sure takes a lot of > patience to write. Simplifications might just be in the > description and not necessarily the algorithm. > > I think it's a hard enough and important enough problem > that we owe it to ourselves to be even more patient with an > "almost done" state that adds the final touches based on > real-world feedback. I don't doubt for a second that ICE > works, but it's so complex that I worry no one outside huge > companies will ever implement it. That would be a huge > hindrance to ICE's adoption and power. > > -Adam > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 26 14:40: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 1IE8Fv-0007B7-0X; Thu, 26 Jul 2007 14:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8Ft-000770-Tn for mmusic@ietf.org; Thu, 26 Jul 2007 14:40:09 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8Fs-000699-IV for mmusic@ietf.org; Thu, 26 Jul 2007 14:40:09 -0400 Received: by wx-out-0506.google.com with SMTP id h27so535940wxd for ; Thu, 26 Jul 2007 11:40:08 -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:references:x-google-sender-auth; b=CPfeTHD0SWaCnG+GVtRiuRcqEnGC5FDJFPf/KPsBMMxVQAMUSSe+775HG/+INYE1V9UlytL2cjCx5B+m8j6vg3Jl3dqM5d8i+eVEHLR96tIy1Je8Jun39aGLOnVKc4UyfW7x+/OY568zp7NyyTDO5GcSVuhgWPi6w7n56mnLzB0= 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:references:x-google-sender-auth; b=kJNjurIvTS67zoiXtO4pGSljT7WbBHGx5Zt7n9qo8xNtETNSMknBdX5LXYSVseBZeFwM3N6vc7dJS36alwnXgm39pnW/jEparLesKxn+uAyQd1pmv8zkaiSld1hxzea6N7bFYk7qO96kGbBxIpkYcKIfyhKoTBNHN/hlukZ9xjo= Received: by 10.70.70.7 with SMTP id s7mr3497677wxa.1185475208048; Thu, 26 Jul 2007 11:40:08 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Thu, 26 Jul 2007 11:40:07 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 14:40:07 -0400 From: "Adam Fisk" To: "Philip Matthews" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> X-Google-Sender-Auth: 9c808640c35b75e3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Jiri Kuthan , Juha Heinanen , Jan Janak , mmusic@ietf.org, David Barrett 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="===============2004864360==" Errors-To: mmusic-bounces@ietf.org --===============2004864360== Content-Type: multipart/alternative; boundary="----=_Part_108682_33365194.1185475207680" ------=_Part_108682_33365194.1185475207680 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I have to get the contact information for the developer who I talked to about it, but I'll hopefully track him down. He's the lead developer for Civil Netizen. I'll post to the list anything I discover. It's good to hear the pacing behavior in ICE is designed to address this. Do you know approximately what draft introduced that? Thanks. -Adam On 7/26/07, Philip Matthews wrote: > > Have these people implemented the pacing stuff that is in ICE? This > behavior is why ICE has this pacing stuff. > - Philip > > On 25-Jul-07, at 23:41 , Adam Fisk wrote: > > I had a conversation earlier tonight at the NYC p2p meetup that led me to > question my previous assumptions about ICE "working". Supposedly many > routers start to do funny things when they see lots of ICE UDP packets > flying by and trying lots of candidates. > > This has me worried. We all know the frightening number of NAT > configurations out there. Maybe I missed it, but is there a test matrix > somewhere of NAT combinations and their success rates with ICE? If not, > could we create one using one of the open source ICE implementations out > there (mine's not quite ready)? I'd be happy to contribute my own router if > we had a simple test program, maybe based on the work at Nokia. > > I think performing those simple tests would set everyone's mind at ease. > Otherwise, I am concerned that some NAT and firmware combinations would balk > at what they see as packet floods. > > To a person, everyone I've talked to who has implemented this stuff in the > "real world" has said the array of problems with specific NAT configurations > is much more significant than they realized at first. I think this is the > central problem -- the world we're deploying this in is much more chaotic > than that of more RFCs, as the BEHAVE group is trying to address. > > -Adam > > > On 7/24/07, Adam Fisk wrote: > > > > I've followed ICE development on the sidelines for years now, and I'm > > currently implementing ICE 17. I've implemented what will be open source > > implementations of STUN and TURN, both client and server. Here are the key > > points I've taken away from that experience: > > > > 1) The patience of Jonathan and everyone else in meticulously getting to > > the current draft is astonishing. > > 2) ICE is complex as hell and a pain in the ^#* to implement. I was > > surprised at how hard it was, particularly for a draft that's so close to > > becoming an RFC. > > 3) ICE is solving a very tricky problem. > > > > I like Phillip's earlier suggestion that the draft stay in the "almost > > done" state like used to happen in the Routing group. I realize that's > > asking a lot given how much work has gone into it and how eager everyone is > > to finalize it. I think the problem is that standardizing NAT traversal is > > just hard, and hard problems are difficult to make simpler. In my > > implementation of ICE, I do think it could be done more simply, but I don't > > have concrete suggestions right now because I'm still pulling my hair out > > with the implementation. I'm not talking about drastic changes anywhere, > > but all the checklist fiddling sure takes a lot of patience to write. > > Simplifications might just be in the description and not necessarily the > > algorithm. > > > > I think it's a hard enough and important enough problem that we owe it > > to ourselves to be even more patient with an "almost done" state that adds > > the final touches based on real-world feedback. I don't doubt for a second > > that ICE works, but it's so complex that I worry no one outside huge > > companies will ever implement it. That would be a huge hindrance to ICE's > > adoption and power. > > > > -Adam > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > ------=_Part_108682_33365194.1185475207680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have to get the contact information for the developer who I talked to about it, but I'll hopefully track him down.  He's the lead developer for Civil Netizen.  I'll post to the list anything I discover. 

It's good to hear the pacing behavior in ICE is designed to address this.  Do you know approximately what draft introduced that?

Thanks.

-Adam


On 7/26/07, Philip Matthews <philip_matthews@magma.ca> wrote:
Have these people implemented the pacing stuff that is in ICE?  This behavior is why ICE has this pacing stuff.

- Philip

On 25-Jul-07, at 23:41 , Adam Fisk wrote:

I had a conversation earlier tonight at the NYC p2p meetup that led me to question my previous assumptions about ICE "working".  Supposedly many routers start to do funny things when they see lots of ICE UDP packets flying by and trying lots of candidates.

This has me worried.  We all know the frightening number of NAT configurations out there.  Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE?  If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)?  I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia.

I think performing those simple tests would set everyone's mind at ease.  Otherwise, I am concerned that some NAT and firmware combinations would balk at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at first.  I think this is the central problem -- the world we're deploying this in is much more chaotic than that of more RFCs, as the BEHAVE group is trying to address.

-Adam


On 7/24/07, Adam Fisk <a@lastbamboo.org > wrote:
I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.  Here are the key points I've taken away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group.  I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler.  In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation.  I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback.  I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it.  That would be a huge hindrance to ICE's adoption and power.

-Adam



_______________________________________________
mmusic mailing list


------=_Part_108682_33365194.1185475207680-- --===============2004864360== 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 --===============2004864360==-- From mmusic-bounces@ietf.org Thu Jul 26 16:13: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 1IE9i7-00050s-5p; Thu, 26 Jul 2007 16:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9i6-00050l-J3 for mmusic@ietf.org; Thu, 26 Jul 2007 16:13:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE9i5-00087X-Uu for mmusic@ietf.org; Thu, 26 Jul 2007 16:13:22 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2007 13:13:21 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswMAIqbqEarR7PD/2dsb2JhbACIYp1F X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="189268999:sNHT151677306" 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 l6QKDLbr021481; Thu, 26 Jul 2007 13:13:21 -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 l6QKDK6C028199; Thu, 26 Jul 2007 20:13:20 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 Jul 2007 13:13:20 -0700 Received: from [10.21.118.243] ([10.21.118.243]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 13:13:20 -0700 Message-ID: <46A9005F.6050106@cisco.com> Date: Thu, 26 Jul 2007 16:13:19 -0400 From: Flemming Andreasen User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Ingemar Johansson S (LU/EAB)" Subject: Re: [MMUSIC] Bandwidth modifiers in SDPCapNeg References: <20070719145334.2EA8B1810C50@mail.iptel.org><20070719180614.85AB218115BC@mail.iptel.org><20070721144803.41B4F1810C56@mail.iptel.org><24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com><20070723205140.EC8031811206@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22B32036@namail5.corp.adobe.com> <026F8EEDAD2C4342A993203088C1FC05055B979B@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05055B979B@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Jul 2007 20:13:20.0529 (UTC) FILETIME=[6947A810:01C7CFC1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2452; t=1185480801; x=1186344801; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fandreas@cisco.com; z=From:=20Flemming=20Andreasen=20 |Subject:=20Re=3A=20[MMUSIC]=20Bandwidth=20modifiers=20in=20SDPCapNeg |Sender:=20; bh=pRbd+7HnHAQJZ7fh2Z4s5cyB5KaaRnZNR/CB6crwnNs=; b=JWyzAtHy5qOCblh/1X42HGCKEnJHh4AwTizZeeFz2G7RbO7lTYvo1lzDUwIHVxS/9/T5tH52 bRPEwi4661Nt6ugQEtQ58qXcfnB6mEuiQbR7QU4/smOAj2iRY36LXF+9; Authentication-Results: sj-dkim-3; header.From=fandreas@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.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 The issue on whether to include the bandwidth parameter (incl. RTCP bw modifiers) in the core was discussed the MMUSIC session yesterday. There was no clear consensus, except that Magnus will take another look at-it, and come up with some motivational use cases in the next 2 weeks. Based on those, the WG will then decide whether this is a problem that needs to be addressed in the core or not. As to the specifics of how we would do that, I'd probably do it differently (more in line with the current capability-reference-by-number strategy), but let's hold off on that part of the discussion. Thanks -- Flemming Ingemar Johansson S (LU/EAB) wrote: > Hi > > I have been looking at the possibility to include the bandwidth modifiers from RFC3556 in SDPCapNeg or its companying media cap draft. > > As the whole configuration is not set until the potential configurations my interpretation is that the bandwidth modifiers must be put here. > If one look at draft-ietf-mmusic-sdp-media-capabilities page 6 one could imagine that the pcfg line(s) are modified in the direction > > a=pcfg:1 m=1,3|4,3 t=1 a=1 pt=1:100,4:101,3:102 \ > b=1:[AS:64,RS:800,RR:2400],4:[AS... and so on > (The '\' sign is a line continuation sign) > > The extra stuff is added after the already existing pcfg info, cannot say how valid the syntax is but I hope the principle is visible, i.e that one can set bandwidths for each potential config. > > As I see it there is at least one consequence, namely that it is not possible to specify several different options for the transport capabilities in the same pcfg line as this may mean different bandwidth settings. The consequence may then be that one need to specify more pcfg lines. > > Possibly kicking in open doors with this email, if so the reason is that the mailthreads are sometimes a pain to follow. > > Comments are welcome. > > Ingemar > > ******************************************* > Ingemar Johansson > Senior Research Engineer > EAB/TVP - Multimedia Technologies > Ericsson Research Ericsson AB > Box 920 S-971 28 Luleå, Sweden > Tel: +46 (0)8 4043042 > ECN: 850-43042 > Mobile: +46 (0)730 783289 > MSN: ingemarjohansson1965@hotmail.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 Jul 26 16:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAJV-0006wZ-7d; Thu, 26 Jul 2007 16:52:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAJT-0006qn-UX for mmusic@ietf.org; Thu, 26 Jul 2007 16:51:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEAJT-0007s1-J9 for mmusic@ietf.org; Thu, 26 Jul 2007 16:51:59 -0400 Received: by wx-out-0506.google.com with SMTP id h27so564467wxd for ; Thu, 26 Jul 2007 13:51:59 -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:references:x-google-sender-auth; b=ehWEk1WoIi2bvg+SqPUOQrCmMvLvV51WRxKnx6E8OTTaACOl5cSDV/dkKGMRwdhmz0F5tY3P34I6ODPTmUVgy/0uNDtQVVQsYTUE7yWBbpcLlD7XkzGY7J/pbXLFPQCD9g81LcCx7eOzDFqmGM2HKQQT+4Q2lUlLLpdZqeJgxDE= 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:references:x-google-sender-auth; b=iobURGDsqNFmDca56nOqv4Wnq4kP+CWJv5eB6uVLBgbASMyC8OB3UDiVer6Y5sE/ACvrLDNkPBpm0a+FN+f0TdbIAp1M5W7mgTwlQ32GSFcD/usVZFZo7hmrFKeFvAbKFESCLawmylczWuOHONV1E7jV9pQrS4ss/RU89z15SB0= Received: by 10.70.116.1 with SMTP id o1mr3655821wxc.1185483119038; Thu, 26 Jul 2007 13:51:59 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Thu, 26 Jul 2007 13:51:58 -0700 (PDT) Message-ID: Date: Thu, 26 Jul 2007 16:51:58 -0400 From: "Adam Fisk" To: "Jiri Kuthan" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC In-Reply-To: <20070724212509.4029E181124D@mail.iptel.org> MIME-Version: 1.0 References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> <20070724212509.4029E181124D@mail.iptel.org> X-Google-Sender-Auth: 9d143adb8062ffa4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mmusic@ietf.org, sip@ietf.org, Juha Heinanen , David Barrett , Jan Janak 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="===============1299346348==" Errors-To: mmusic-bounces@ietf.org --===============1299346348== Content-Type: multipart/alternative; boundary="----=_Part_110055_11584226.1185483118369" ------=_Part_110055_11584226.1185483118369 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/24/07, Jiri Kuthan wrote: > > At 22:07 24/07/2007, Adam Fisk wrote: > >I've followed ICE development on the sidelines for years now, and I'm > currently implementing ICE 17. I've implemented what will be open source > implementations of STUN and TURN, both client and server. > > That's marvellous news -- can you send me a pointer to that? We're not quite public yet, Jiri. I'll send a note to the list when we're up, though. -Adam ------=_Part_110055_11584226.1185483118369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/24/07, Jiri Kuthan <jiri@iptel.org> wrote:
At 22:07 24/07/2007, Adam Fisk wrote:
>I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.

That's marvellous news -- can you send me a pointer to that?

We're not quite public yet, Jiri.  I'll send a note to the list when we're up, though. 

-Adam
------=_Part_110055_11584226.1185483118369-- --===============1299346348== 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 --===============1299346348==-- From mmusic-bounces@ietf.org Thu Jul 26 17:01: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 1IEASF-0004SC-VW; Thu, 26 Jul 2007 17:01:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEASF-0004S7-Cm for mmusic@ietf.org; Thu, 26 Jul 2007 17:01:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEASF-00084D-1p for mmusic@ietf.org; Thu, 26 Jul 2007 17:01:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2007 14:01:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADanqEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="189295246:sNHT35530164" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6QL12X2019659; Thu, 26 Jul 2007 14:01:02 -0700 Received: from dwingwxp (sjc-vpn7-1071.cisco.com [10.21.148.47]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QL116C016675; Thu, 26 Jul 2007 21:01:01 GMT From: "Dan Wing" To: "'Adam Fisk'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Thu, 26 Jul 2007 16:01:01 -0500 Message-ID: <082101c7cfc8$135e1450$3015590a@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.3138 In-Reply-To: thread-index: AcfPtHBjcLjjgSuITjCbbqyZkHK9EgAEy11A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=390; t=1185483662; x=1186347662; 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=20[MMUSIC]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20; bh=4YLzEIycJqFiCbByMvU8xWE1zc8H0pb3iPTjQ899gZc=; b=lgGmHVSlomHX9wQ7cYuoDiQaW5A9RtwwYoKNflsQ3uaiOO/IVbhg9U4ZSeLBfI4+88ETrXL5 Q4oljjkxonIbcPmfGPrRmX0HHS41ZhfkFATKsCONFGK5qe968LiQXrMn; 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: mmusic@ietf.org, 'Jiri Kuthan' , 'Juha Heinanen' , 'David Barrett' , 'Jan Janak' , '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 ... > It's good to hear the pacing behavior in ICE is designed to > address this. Do you know approximately what draft introduced that? The first mention in ICE that I see of the per-transaction pacing was in ICE-06, http://tools.ietf.org/html/draft-ietf-mmusic-ice-06, published October 2005. As I recall, this was added because NAT testing showed it was necessary. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 26 18:19: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 1IEBgQ-0003qx-1O; Thu, 26 Jul 2007 18:19:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBgN-0003pn-K9; Thu, 26 Jul 2007 18:19:43 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEBgN-00010h-2G; Thu, 26 Jul 2007 18:19:43 -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 l6QMJTl1016558; Fri, 27 Jul 2007 01:19:29 +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 Jul 2007 01:19:28 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 01:19:28 +0300 Received: from essapo-nirac25395.europe.nokia.com ([10.162.253.95]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 01:19:11 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: ma.saito@nttv6.jp Date: Fri, 27 Jul 2007 01:17:29 +0300 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707270117.30051.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 26 Jul 2007 22:19:12.0115 (UTC) FILETIME=[FE603C30:01C7CFD2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sipping@ietf.org, mmusic@ietf.org, ext Dan Wing Subject: [MMUSIC] Comments on saito-mmusic-sdp-ike 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 Hey, Some somewhat cosmetic comments: * I really do not like "udp-setup"; UDP does not have a notion of connectio= n=20 direction, for it does not have connections at all. You could probably=20 use "ike-setup", but I would recommend (ab)using COMEDIA "setup". ICE-TCP=20 already does (uses setup for TLS direction instead of TCP direction). * As pointed out by MMUSIC chairs, the m=3D line syntax is wrong, as there = is no=20 application/IKE MIME type. It should probably be "UDP/IKE *" instead of "UDP IKE" * In security considerations, you may want to clarify why SRTP must still b= e=20 used for end-to-end security. I reckon the point is that the remote tunnel= =20 endpoint may be distinct from the remote RTP endpoint. By the way, any reas= on=20 why you only specify tunnel mode? With ICE, it could work in transport mode= =20 too. Otherwise, the document looks good to me. I feel it fits better in SIPPING than MMUSIC, but I defer to the respective= WG=20 chairs for obvious reasons. Regards, =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 Jul 26 18:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEC39-0001L2-RK; Thu, 26 Jul 2007 18:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEC36-0001Kj-Ie for mmusic@ietf.org; Thu, 26 Jul 2007 18:43:12 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEC36-0002Pe-7e for mmusic@ietf.org; Thu, 26 Jul 2007 18:43:12 -0400 Received: by py-out-1112.google.com with SMTP id f31so2303712pyh for ; Thu, 26 Jul 2007 15:43:12 -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=VnkQpL0KGdf0YX99zTPnttWq8eStFO94oeVTnqZN0YVLwQilOu37mZ1Ozdy2mLye+2TTRumxg1h9n30AzhYsfV4jv7XmgXzgwOfq1/408DXvk1ch6W4ROPqy3EsVxyjSIqLbGTps2ogd3X4F2Lij2sJUB4ztIUgVHHXKRZ4UdwI= 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=kuK4tsFnIXM1tCkZFzhljKXB/P8sMeRVnx5IcyqWiu11XjrRnq4VqwlIAkUx+qVy9n1jUflehC8CxWWnF/XzA9b7EJPlr41nNQYSl+6CTTEHGAwgg3r+k+PdYI4/8I03QCa1ihzdZzBfHgmGSa7MORCgjFnsbWt/SbhjT09Xipw= Received: by 10.35.111.14 with SMTP id o14mr3607814pym.1185489791946; Thu, 26 Jul 2007 15:43:11 -0700 (PDT) Received: by 10.35.70.16 with HTTP; Thu, 26 Jul 2007 15:43:11 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 01:43:11 +0300 From: "Diego B" To: mmusic@ietf.org 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: a983da46e557ec23 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [MMUSIC] ICE Question: Sharing the same IP between two UAs on different networks 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 apologies if this question is out of scope or not relevant. After the tutorial I was thinking about the case where UA1 and UA2 share the same private IP but in different networks. lets say UA1 in acme.com and UA2 in foo.com. What will be the situation here ? UA1 and UA2 will send media to their own IP ? or ICE will recognize the problem in one of the protocol steps ? or may be this situation can not happen at all. Another similar question is if UA1 and UA2 are in the same network and UA3 in a different network but with the same private IP range. UA1 has the same IP than UA3. UA2 makes a call to UA3. In the UA3's SDP UA2 will see the private IP of UA3 that is the same as UA1, so if UA2 proves that IP there can be a chance that UA1 answers to UA2 requests. what will be the scenario here ? UA2 will ends up sending media to UA1 ? or this path will be discarded for some reason ? Thanks Diego B _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 26 19:03: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 1IECMV-0002Pp-Br; Thu, 26 Jul 2007 19:03:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECMU-0002Pk-3z for mmusic@ietf.org; Thu, 26 Jul 2007 19:03:14 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IECMT-0001xG-Lb for mmusic@ietf.org; Thu, 26 Jul 2007 19:03:14 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLT005OV6PAMG@tid.hi.inet> for mmusic@ietf.org; Fri, 27 Jul 2007 01:03:10 +0200 (MEST) Received: from matrix ([10.95.89.1]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLT0078L6P6HM@tid.hi.inet> for mmusic@ietf.org; Fri, 27 Jul 2007 01:03:10 +0200 (MEST) Date: Fri, 27 Jul 2007 01:03:11 +0200 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= Subject: RE: [MMUSIC] ICE Question: Sharing the same IP between two UAs ondifferent networks In-reply-to: To: 'Diego B' Message-id: <059a01c7cfd9$25df42f0$719dc8d0$@es> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es Content-transfer-encoding: 7BIT Thread-index: AcfP1mD1p2zYCEk4TIeVDyLm5lwHkAAAIAgQ References: X-Spam-Score: 1.2 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Diego, > After the tutorial I was thinking about the case > where UA1 and UA2 share the same private IP but in different networks. > lets say UA1 in acme.com and UA2 in foo.com. > What will be the situation here ? > UA1 and UA2 will send media to their own IP ? or > ICE will recognize the problem in one of the protocol steps ? > or may be this situation can not happen at all. A UA could detect this situation and avoid sending connectivity checks to its own IP address, but even if the UA send the STUN connectivity checks to its own IP address, the connectivity checks will not succeed because the STUN credentials that will use in the checks won't be valid. (i.e. UA1 will send to itself requests using the STUN password received from UA2). " STUN connectivity checks between agents are authenticated using the short term credential mechanism defined for STUN [I-D.ietf-behave-rfc3489bis]." > Another similar question is if > UA1 and UA2 are in the same network > and UA3 in a different network but with the same private IP range. > > UA1 has the same IP than UA3. > UA2 makes a call to UA3. > In the UA3's SDP UA2 will see the private IP of UA3 that is the same as > UA1, > so if UA2 proves that IP there can be a chance that UA1 answers to UA2 > requests. The connectivity checks will not succeed in this scenario either. > Thanks > Diego B BR, G. > _______________________________________________ > 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 Jul 26 19:15: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 1IECYN-0003Cp-A8; Thu, 26 Jul 2007 19:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEBYk-0001DD-Sg for mmusic@ietf.org; Thu, 26 Jul 2007 18:11:50 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEBYk-0001lV-Iw for mmusic@ietf.org; Thu, 26 Jul 2007 18:11:50 -0400 Received: by py-out-1112.google.com with SMTP id f31so2280264pyh for ; Thu, 26 Jul 2007 15:11:50 -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=rEi26nvTGGZQBVOEGBM0uZw7qsxX62k5S9Ea8KblReNreZ3YR9QcOOZ3hIgAxuIQSG1k+tQtA+wROKOB6wqoMb1HKN2eQB1ZZYN2joS2+660SOYhLwfMxHq1aixFCpY7mOAZrfiUqFy8Z2l2nV1zAs5hCNBPBs0c2/lyKZyy5cI= 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=skc9Z6hqlBL66Bl6f73MxW3nIz1vmtGOApSaGpbHO7eQ+kPbi16Fi62sYthJ9eEMa/xoX8pRURQdhnd02iqcYXcOHEGmzTTmo1dkuYYBEs/kadnk+e/GYcBsBertKQ2uw+wwLZ0CYCd2VMxD8HXWCAzO+R0Hpt6JbAzjeCiPAmQ= Received: by 10.35.87.10 with SMTP id p10mr12134871pyl.1185487910028; Thu, 26 Jul 2007 15:11:50 -0700 (PDT) Received: by 10.35.70.16 with HTTP; Thu, 26 Jul 2007 15:11:49 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 01:11:50 +0300 From: "Diego B" To: mmusic@ietf.org 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: 6954007b61157a6c X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Thu, 26 Jul 2007 19:15:28 -0400 Subject: [MMUSIC] ICE Question: Sharing the same IP between two UAs on different networks 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 apologies if this question is out of scope or not relevant. After the tutorial I was thinking about the case where UA1 and UA2 share the same private IP but in different networks. lets say UA1 in acme.com and UA2 in foo.com. What will be the situation here ? UA1 and UA2 will send media to their own IP ? or ICE will recognize the problem in one of the protocol steps ? or may be this situation can not happen at all. Another similar question is if UA1 and UA2 are in the same network and UA3 in a different network but with the same private IP range. UA1 has the same IP than UA3. UA2 makes a call to UA3. In the UA3's SDP UA2 will see the private IP of UA3 that is the same as UA1, so if UA2 proves that IP there can be a chance that UA1 answers to UA2 requests. what will be the scenario here ? UA2 will ends up sending media to UA1 ? or this path will be discarded for some reason ? Thanks Diego B _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Jul 26 20:06: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 1IEDLl-0001gE-6B; Thu, 26 Jul 2007 20:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEDLi-0001eG-Ds; Thu, 26 Jul 2007 20:06:30 -0400 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEDLh-00046E-SK; Thu, 26 Jul 2007 20:06:30 -0400 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 9F067BDC08; Fri, 27 Jul 2007 09:06:26 +0900 (JST) Received: from [127.0.0.1] (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 933E16D885; Fri, 27 Jul 2007 09:06:25 +0900 (JST) Message-ID: <46A93700.4080801@nttv6.jp> Date: Fri, 27 Jul 2007 09:06:24 +0900 From: Makoto SAITO User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200707270117.30051.remi.denis-courmont@nokia.com> In-Reply-To: <200707270117.30051.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: sipping@ietf.org, mmusic@ietf.org, ext Dan Wing Subject: [MMUSIC] Re: Comments on saito-mmusic-sdp-ike 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 R=E9mi, Thank you for the review. > * I really do not like "udp-setup"; UDP does not have a notion of conne= ction=20 > direction, for it does not have connections at all. You could probably=20 > use "ike-setup", but I would recommend (ab)using COMEDIA "setup". ICE-T= CP=20 > already does (uses setup for TLS direction instead of TCP direction). In fact, I didn't know what was a better way to indicate the direction of IKE (hopefully UDP for a generic use) so this is what I wanted to take a feedback from WG. And "setup" might be a popular way here. > * As pointed out by MMUSIC chairs, the m=3D line syntax is wrong, as th= ere is no=20 > application/IKE MIME type. It should probably be > "UDP/IKE *" > instead of > "UDP IKE" Thank you for your comment. > * In security considerations, you may want to clarify why SRTP must sti= ll be=20 > used for end-to-end security. I reckon the point is that the remote tun= nel=20 > endpoint may be distinct from the remote RTP endpoint. By the way, any = reason=20 > why you only specify tunnel mode? With ICE, it could work in transport = mode=20 > too. Yes, the reason that SRTP must be used for end-to-end security is the VPN just provides the security between the remote terminal and the local network. And as you pointed, transport mode can also be used with SDP-IKE, and it will provide end-to-end security. I've only mentioned tunnel mode IPsec for VPN use in our draft, so there remains a room to describe it, too. >=20 > Otherwise, the document looks good to me. >=20 > I feel it fits better in SIPPING than MMUSIC, but I defer to the respec= tive WG=20 > chairs for obvious reasons. >=20 > Regards, >=20 Thank you very much, --=20 Makoto Saito _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sun Jul 29 13:00: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 1IFC8F-0001jG-Rg; Sun, 29 Jul 2007 13:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFC8E-0001eF-Az for mmusic@ietf.org; Sun, 29 Jul 2007 13:00:38 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IFC8C-00009E-MK for mmusic@ietf.org; Sun, 29 Jul 2007 13:00:38 -0400 Received: from lappy ([217.43.151.83]) by quinthar.com for ; Sun, 29 Jul 2007 10:00:31 -0700 From: "David Barrett" To: "'Adam Fisk'" , "'Jiri Kuthan'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Sun, 29 Jul 2007 18:00:28 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfPPzTaYk7Iv3gXSci8IowcsKm62wCwN/sw X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: 'Jan Janak' , 'Juha Heinanen' , 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="===============0902978583==" Errors-To: mmusic-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============0902978583== Content-Type: multipart/alternative; boundary="----=_NextPart_000_04BB_01C7D20A.5B875450" This is a multi-part message in MIME format. ------=_NextPart_000_04BB_01C7D20A.5B875450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: adamfisk@gmail.com Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC This has me worried. We all know the frightening number of NAT configurations out there. Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE? If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)? I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia. I'm not sure that matrixing out connectivity through NAT models is the right approach. Every NAT has a hundred ways to be configured (and misconfigured), and generally at least two of them sit between most client pairs. The number of real-world permutations is astronomical, and it almost certainly won't catch the weird cases that can and do happen with surprising frequency. A recent example is the bizarre NAT I mentioned before that duplicates every packet sent 3-7 times (at the "It's A Grind" coffeeshop on Polk St in San Francisco). I've also dealt with the Google WiFi network (in Union Square, San Francisco), which has the unusual property of only being able to receive UDP from exactly *one* remote host per port - so you can send from a UDP port to anywhere in the world just fine (with symmetric behavior), but you can only receive back from the first - all other responses are blocked. These are just two that I've personally experienced and that come up from recent memory: I've seen even more unusual behavior I can't even begin to explain in my users' logs. I'd suggest that the only way to test ICE (or any other NAT-traversal implementation) is to actually run it on thousands of computers hosted behind real-world network connections and see how well it works. I can't overstress how unusual, slow, unpredictable, and unreliable the internet can get in the real world, and how making thing works in the real world is far more difficult than making it work on paper. The faster you embrace real-world, large-scale testing, the faster you have something that works outside the lab. -david ------=_NextPart_000_04BB_01C7D20A.5B875450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: adamfisk@gmail.com
Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

This has me worried.  We all know the frightening number of = NAT configurations out there.  Maybe I missed it, but is there a test = matrix somewhere of NAT combinations and their success rates with ICE?  If = not, could we create one using one of the open source ICE implementations out = there (mine's not quite ready)?  I'd be happy to contribute my own router = if we had a simple test program, maybe based on the work at Nokia. =

 

I’m not sure that matrixing = out connectivity through NAT models is the right approach.  Every NAT has a hundred = ways to be configured (and misconfigured), and generally at least two of them = sit between most client pairs.  The number of real-world permutations = is astronomical, and it almost certainly won’t catch the weird cases = that can and do happen with surprising = frequency.

 

A recent example is the bizarre NAT = I mentioned before that duplicates every packet sent 3-7 times (at the = “It’s A Grind” coffeeshop on Polk St in San Francisco).  I’ve also dealt with = the Google WiFi network (in Union Square, San Francisco), which has the = unusual property of only being able to receive UDP from exactly *one* remote host per port – = so you can send from a UDP port to anywhere in the world just fine (with = symmetric behavior), but you can only receive back from the first – all = other responses are blocked.

 

These are just two that I’ve personally experienced and that come up from recent memory: I’ve = seen even more unusual behavior I can’t even begin to explain in my = users’ logs.  I’d suggest that the only way to test ICE (or any = other NAT-traversal implementation) is to actually run it on thousands of computers hosted = behind real-world network connections and see how well it = works.

 

I can’t overstress how = unusual, slow, unpredictable, and unreliable the internet can get in the real world, = and how making thing works in the real world is far more difficult than making it work = on paper.  The faster you embrace real-world, large-scale testing, the = faster you have something that works outside the = lab.

 

-david

 

 

------=_NextPart_000_04BB_01C7D20A.5B875450-- --===============0902978583== 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 --===============0902978583==-- From mmusic-bounces@ietf.org Sun Jul 29 18:08: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 1IFGwJ-00042U-VF; Sun, 29 Jul 2007 18:08:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFGwJ-00042P-AQ for mmusic@ietf.org; Sun, 29 Jul 2007 18:08:39 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFGwI-0006Xv-I2 for mmusic@ietf.org; Sun, 29 Jul 2007 18:08:39 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 29 Jul 2007 15:07:59 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6TM7nWs015022; Sun, 29 Jul 2007 15:07:50 -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 l6TM5gIB021587; Sun, 29 Jul 2007 15:05:43 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 15:07:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Sun, 29 Jul 2007 15:04:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B8662A@namail5.corp.adobe.com> In-Reply-To: <200707291700.l6TH0roX004288@inbound-smtp-1.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfPPzTaYk7Iv3gXSci8IowcsKm62wCwN/swAAronOA= References: <200707291700.l6TH0roX004288@inbound-smtp-1.corp.adobe.com> From: "Henry Sinnreich" To: "David Barrett" , "Adam Fisk" , "Jiri Kuthan" X-OriginalArrivalTime: 29 Jul 2007 22:07:48.0413 (UTC) FILETIME=[E618D6D0:01C7D22C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Cc: Juha Heinanen , Jan Janak , 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="===============0109232998==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0109232998== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D22C.E59F1026" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D22C.E59F1026 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable * I'd suggest that the only way to test ICE (or any other NAT-traversal implementation) is to actually run it on thousands of computers hosted=20 * behind real-world network connections and see how well it works. =20 I fully agree and to make this work we need some tools that folks like here in the IETF WGs can download and report back the results. The requirements for such a NAT testing tool would make a nice I-D on the condition someone is willing to write the code and make it available on a web site, similar to most beta testing sites, say in this case DSL Reports - > Speed Tests. =20 Thanks, Henry =20 =20 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Sunday, July 29, 2007 12:00 PM To: 'Adam Fisk'; 'Jiri Kuthan' Cc: Henry Sinnreich; 'Jan Janak'; 'Juha Heinanen'; mmusic@ietf.org Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 ________________________________ From: adamfisk@gmail.com=20 Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 This has me worried. We all know the frightening number of NAT configurations out there. Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE? If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)? I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia.=20 =20 I'm not sure that matrixing out connectivity through NAT models is the right approach. Every NAT has a hundred ways to be configured (and misconfigured), and generally at least two of them sit between most client pairs. The number of real-world permutations is astronomical, and it almost certainly won't catch the weird cases that can and do happen with surprising frequency. =20 A recent example is the bizarre NAT I mentioned before that duplicates every packet sent 3-7 times (at the "It's A Grind" coffeeshop on Polk St in San Francisco). I've also dealt with the Google WiFi network (in Union Square, San Francisco), which has the unusual property of only being able to receive UDP from exactly *one* remote host per port - so you can send from a UDP port to anywhere in the world just fine (with symmetric behavior), but you can only receive back from the first - all other responses are blocked. =20 These are just two that I've personally experienced and that come up from recent memory: I've seen even more unusual behavior I can't even begin to explain in my users' logs. I'd suggest that the only way to test ICE (or any other NAT-traversal implementation) is to actually run it on thousands of computers hosted behind real-world network connections and see how well it works. =20 I can't overstress how unusual, slow, unpredictable, and unreliable the internet can get in the real world, and how making thing works in the real world is far more difficult than making it work on paper. The faster you embrace real-world, large-scale testing, the faster you have something that works outside the lab. =20 -david =20 =20 ------_=_NextPart_001_01C7D22C.E59F1026 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Ø       I’d suggest that the only way to test ICE (or any other NAT-traversal implementation) is to actually run it on thousands of computers hosted =

Ø       behind real-world network connections and see how well it = works.

 

I fully agree and to make this work = we need some tools that folks like here in the IETF WGs can download and = report back the results.

The requirements for such a NAT = testing tool would make a nice I-D on the condition someone is willing to write = the code and make it available on a web site, similar to most beta testing = sites, say in this case DSL Reports - > Speed = Tests.

 

Thanks, = Henry

 

 

From: = David Barrett = [mailto:dbarrett@quinthar.com]
Sent: Sunday, July 29, = 2007 12:00 PM
To: 'Adam Fisk'; 'Jiri = Kuthan'
Cc: Henry Sinnreich; 'Jan = Janak'; 'Juha Heinanen'; = mmusic@ietf.org
Subject: RE: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

From: adamfisk@gmail.com
Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

This has me worried.  We all know the frightening number of = NAT configurations out there.  Maybe I missed it, but is there a test = matrix somewhere of NAT combinations and their success rates with ICE?  If = not, could we create one using one of the open source ICE implementations out = there (mine's not quite ready)?  I'd be happy to contribute my own router = if we had a simple test program, maybe based on the work at Nokia. =

 

I’m not sure that matrixing = out connectivity through NAT models is the right approach.  Every NAT = has a hundred ways to be configured (and misconfigured), and generally at = least two of them sit between most client pairs.  The number of real-world permutations is astronomical, and it almost certainly won’t catch = the weird cases that can and do happen with surprising = frequency.

 

A recent example is the bizarre NAT = I mentioned before that duplicates every packet sent 3-7 times (at the “It’s A Grind” coffeeshop on Polk St in San Francisco).  I’ve = also dealt with the Google WiFi network (in Union Square, San Francisco), which has the = unusual property of only being able to receive UDP from exactly *one* remote host per port – = so you can send from a UDP port to anywhere in the world just fine (with = symmetric behavior), but you can only receive back from the first – all other responses = are blocked.

 

These are just two that I’ve personally experienced and that come up from recent memory: I’ve = seen even more unusual behavior I can’t even begin to explain in my = users’ logs.  I’d suggest that the only way to test ICE (or any = other NAT-traversal implementation) is to actually run it on thousands of = computers hosted behind real-world network connections and see how well it = works.

 

I can’t overstress how = unusual, slow, unpredictable, and unreliable the internet can get in the real = world, and how making thing works in the real world is far more difficult than = making it work on paper.  The faster you embrace real-world, = large-scale testing, the faster you have = something that works outside the lab.

 

-david

 

 

------_=_NextPart_001_01C7D22C.E59F1026-- --===============0109232998== 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 --===============0109232998==-- From mmusic-bounces@ietf.org Sun Jul 29 19:37: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 1IFIKR-0004u8-93; Sun, 29 Jul 2007 19:37:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIKQ-0004tf-6y for mmusic@ietf.org; Sun, 29 Jul 2007 19:37:38 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFIKP-0008Bz-T0 for mmusic@ietf.org; Sun, 29 Jul 2007 19:37:38 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1187746wxd for ; Sun, 29 Jul 2007 16:37:37 -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:references:x-google-sender-auth; b=PZFokHS+1uCi80L06fiV2tpKBDlQNUNYrAE6Y3EqxItihqsbaY3HBp13u0BePiayKhcSMDaDRfpOb7/DIY7dzP9UFnuVTYojt7HmEI3xAGTwIF44/B/kuvwQAwuiHkCOIA7DfuLo2LkWbBxUL1Xof+dW3u85BR/o8qU7habrIT0= 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:references:x-google-sender-auth; b=liL+m55red+VRbgivps/edP/sagf3Xj0cCESYclilD+wftrOxVa1tQHRHPWD2KeErBl6l8xaUAathro+jNN72t/0tuhJqPFpChFQgJp++Y35L43LkBygCKfmhVzcKp65VQDMo0BGcJIRRjg27Idu2bTZAygiMUWEsRl5M90ymS8= Received: by 10.70.53.7 with SMTP id b7mr6130201wxa.1185752257504; Sun, 29 Jul 2007 16:37:37 -0700 (PDT) Received: by 10.70.38.2 with HTTP; Sun, 29 Jul 2007 16:37:37 -0700 (PDT) Message-ID: Date: Sun, 29 Jul 2007 19:37:37 -0400 From: "Adam Fisk" To: "Dan Wing" Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC In-Reply-To: <05d801c7cfb0$eae490b0$3015590a@amer.cisco.com> MIME-Version: 1.0 References: <05d801c7cfb0$eae490b0$3015590a@amer.cisco.com> X-Google-Sender-Auth: 56f7bc977de09c14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Jiri Kuthan , Juha Heinanen , Jan Janak , mmusic@ietf.org, David Barrett 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="===============1095117985==" Errors-To: mmusic-bounces@ietf.org --===============1095117985== Content-Type: multipart/alternative; boundary="----=_Part_22025_339399.1185752257024" ------=_Part_22025_339399.1185752257024 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I lost your message in the shuffle, Dan, so apologies for the delay. > > *Routers*? Or NATs? Routers don't maintain state and thus > aren't aware of new flows or old flows; I would be surprised > of this happening and would be very interested in hearing more > about it. I suppose all sorts of packet-optimization boxes, > network scanning detectors, and intrusion prevention devices > might perceive a bunch of ICE probes as a network scanner. Sorry -- NATs. I believe he was talking about the kind of issues discussed in B.1. I've unfortunately been unable to get back in touch with the developer, but I suspect he implemented a much earlier ICE draft and abandoned it. That's the impression I got, so hopefully it's the case and he abandoned a version from before the pacing was introduced. Thanks Dan. -Adam ------=_Part_22025_339399.1185752257024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I lost your message in the shuffle, Dan, so apologies for the delay.



*Routers*?  Or NATs?  Routers don't maintain state and thus
aren't aware of new flows or old flows; I would be surprised
of this happening and would be very interested in hearing more
about it.  I suppose all sorts of packet-optimization boxes,
network scanning detectors, and intrusion prevention devices
might perceive a bunch of ICE probes as a network scanner.


Sorry -- NATs.  I believe he was talking about the kind of issues discussed in B.1.  I've unfortunately been unable to get back in touch with the developer, but I suspect he implemented a much earlier ICE draft and abandoned it.  That's the impression I got, so hopefully it's the case and he abandoned a version from before the pacing was introduced.

Thanks Dan.

-Adam


------=_Part_22025_339399.1185752257024-- --===============1095117985== 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 --===============1095117985==-- From mmusic-bounces@ietf.org Tue Jul 31 09:24: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 1IFriK-0007Fa-GO; Tue, 31 Jul 2007 09:24:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFriI-0007FC-7v; Tue, 31 Jul 2007 09:24:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFriH-0001To-8m; Tue, 31 Jul 2007 09:24:38 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 69A6821185; Tue, 31 Jul 2007 15:24:36 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-6f-46af3814c655 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3333B21236; Tue, 31 Jul 2007 15:24:36 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 15:24:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 15:24:35 +0200 Message-ID: <46AF3813.1020105@ericsson.com> Date: Tue, 31 Jul 2007 15:24:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Pyda Srisuresh References: <383711.88528.qm@web33304.mail.mud.yahoo.com> In-Reply-To: <383711.88528.qm@web33304.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 13:24:35.0134 (UTC) FILETIME=[23121DE0:01C7D376] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC 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 Suresh, I would propose that you drop MMUSIC mailing listif responding to this as you appear to want to discuss the removal of a BEHAVE milestone, rather than ICE and its way forward. But I will leave it there to let the MMUSIC people see my response. It seems most of the issues in this discussion is between, what I at least thought was a specific way of performing the hole punching rather than the general concept that I acknowledge has existed since the creation of NATs. I will drop these items an respond to few of them. Pyda Srisuresh skrev: > --- Magnus Westerlund wrote: >> >> There also has been discussion about if there should be multiple >> solutions etc. But, to my knowledge the consensus also there has been >> that one solution is the way to go. >> > [suresh] I have not been part of the discussion pertaining to the merit of > multiple solutions vs single soultions. This may have been discussed in the > context of SIP and NAT traversal. So, I cant comment on this. Yes, that was in the context of ICE. As my email was about that. > >> So Suresh, you and everyone else as participants in the IETF is >> responsible for what you call HOLE PUNCHING TECHNIQUES are not an WG >> item. > > [suresh] Magnus - I dont know what you are talking about. How do you mean I am > responsible for why the HOLE PUNCHING TECHNIQUE draft is not a WG item. The > ford-behave-app draft has been around for many years since the inception of > BEHAVE. Last I checked, The application milestone is no longer on BEHVAE > charter. I certainly am not responsible for removign the milestone. This was written as reaction on how work gets done in the IETF. One or more proponents goes out and sell their idea so that enough people are interested to participate in the work on that idea. In cases the proponents are not succesful in getting traction for the idea it rarely goes anywhere. In the case of the ford-behave-app draft there has been no support for keeping the milestone or more important, do the work. > [suresh] Magnus - I have not been part of the consensus for ICE. However, I do > know ICE adapts the HOLE PUNCHING TECHNIQUES and the BCP recommendations > identified in ford-behave-app draft. Yet, neither of the ICE drafts (UDP or the > TCP version) refer the ford-behave-app draft or prior work on HOLE PUNCHING as > normative reference. This iS WRONG. > > I believe, the ICE drafts should refer the prior work (kegel work on UDP hole > punching, USENIX paper for TCP hole punching and ford-behave-app draft for > application traversal design) on which the ICE work is based. > I think you should review your sources here. The first version of ford-beahve-app was submitted february 2005. At that point STUN (RFC 3489 had been published in almost 2 years (March 2003). The first individual version of ICE was submitted to IETF february 2003. I am not going to untangle this, but if you are going down this path: Please have you facts right. I am not denying that work commonly builds up on others. And that it is common curtesy to reference such work. However, that is commonly done by an informative reference. Normative references are for things that you absolutely need to include to build interoperable implementations. Please do review IESG statement on references: http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt > On the one hand, IETF (IESG) has been adamant about the standard level of the > normative references for a proposes standard. Yet, it is ironic that when HOLE > PUNCHING is normative to the design of ICE, the IETF is not allowing the HOLE > PUNCHING work to be standardized. Once more a missunderstanding about what it means to be a normative reference in an RFC. > > Why is the IETF not allowing HOLE PUNCHING TECHNIQUES and P2P application > traversal identified in draft-ford-behave-app draft to move forward as a BCP WG > item? > As stated before. There is a clear lack of interest in this document. I wished there wasn't. But the fact is that no-one except you have really argued for it, not even your co-authors. We can't publish a document where no-one reads and reviews it and stil claim that their exist consensus behind it. Regards 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 Jul 31 19:54: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 1IG1Xo-0000i3-41; Tue, 31 Jul 2007 19:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG1Xm-0000hr-Mf for mmusic@ietf.org; Tue, 31 Jul 2007 19:54:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG1Xm-000155-9d for mmusic@ietf.org; Tue, 31 Jul 2007 19:54:26 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2007 16:54:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAxor0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.19,205,1183359600"; d="scan'208"; a="192075560:sNHT26165493" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6VNsPb3029096; Tue, 31 Jul 2007 16:54:25 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6VNs1Tb021210; Tue, 31 Jul 2007 23:54:07 GMT From: "Dan Wing" To: "'Adam Fisk'" Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Tue, 31 Jul 2007 16:53:58 -0700 Message-ID: <0a7c01c7d3ce$1fe762d0$c5f0200a@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.3138 Thread-Index: AcfSOXkZ2kT4uEpSQaO2N8LpR1eN9gBlDJeA In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1275; t=1185926065; x=1186790065; c=relaxed/simple; s=sjdkim1004; 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]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20; bh=Brz9O8rdrQto9pV4MdjI1bM0l2hFIQXYdLC5wr1uRqk=; b=TKu5m0+5dCSTckI/O6ZZHGbiz4tO8EH3d7AcYw4TARYdUFqh2QaVzW4YUMqfr0QoydL+sUt8 t6TNiw2iSC8khcyXw5hnCFuhsstnsGMUjVIxNTvcQ358cKjXzpS/zY5olZfuS54t48uXyEGAzF jGMpIAhuPDyGH6opfkPYTpOVc=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'Jiri Kuthan' , 'Juha Heinanen' , 'Jan Janak' , mmusic@ietf.org, 'David Barrett' 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 lost your message in the shuffle, Dan, so apologies for the delay. > > > > > > *Routers*? Or NATs? Routers don't maintain state and thus > aren't aware of new flows or old flows; I would be surprised > of this happening and would be very interested in hearing more > about it. I suppose all sorts of packet-optimization boxes, > network scanning detectors, and intrusion prevention devices > might perceive a bunch of ICE probes as a network scanner. > > > > Sorry -- NATs. I believe he was talking about the kind of > issues discussed in B.1. I've unfortunately been unable to > get back in touch with the developer, but I suspect he > implemented a much earlier ICE draft and abandoned it. > That's the impression I got, so hopefully it's the case and > he abandoned a version from before the pacing was introduced. I would like to hear any more detail you might have. This behavior has echos of some issues that Phil Zimmermann and Alan Johnston mentioned they had seen during their development of ZRTP. However, I don't recall any details about the beginning-of-UDP-flow packet loss they were seeing; perhaps it was also across these same sort of NATs. -d > Thanks Dan. > > -Adam > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Jul 31 20:23: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 1IG20M-0001rO-AC; Tue, 31 Jul 2007 20:23:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG20L-0001q1-7P for mmusic@ietf.org; Tue, 31 Jul 2007 20:23:57 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG20K-00035x-Me for mmusic@ietf.org; Tue, 31 Jul 2007 20:23:57 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Tue, 31 Jul 2007 17:23:23 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 l710Ljot029994; Tue, 31 Jul 2007 17:21:45 -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 l710N40c013863; Tue, 31 Jul 2007 17:23:04 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 17:23:04 -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: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Date: Tue, 31 Jul 2007 17:22:46 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B86E77@namail5.corp.adobe.com> In-Reply-To: <0a7c01c7d3ce$1fe762d0$c5f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfSOXkZ2kT4uEpSQaO2N8LpR1eN9gBlDJeAAAD8VfA= References: <0a7c01c7d3ce$1fe762d0$c5f0200a@amer.cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "Adam Fisk" X-OriginalArrivalTime: 01 Aug 2007 00:23:04.0011 (UTC) FILETIME=[203251B0:01C7D3D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Jiri Kuthan , Juha Heinanen , Jan Janak , mmusic@ietf.org, David Barrett 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 starting to wonder if this is a moot discussion since large providers install SBC on all customers facing links. The tendency of the SBC may to just route the SIP message to their own SIP proxy, who will just discard SIP messages from sources it does not know. Do you have any information on this? Thanks, Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Tuesday, July 31, 2007 6:54 PM To: 'Adam Fisk' Cc: 'Jiri Kuthan'; 'Juha Heinanen'; 'Jan Janak'; mmusic@ietf.org; 'David Barrett' Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabeforeLCfor RFC > I lost your message in the shuffle, Dan, so apologies for the delay. >=20 >=20 >=20 >=20 >=20 > *Routers*? Or NATs? Routers don't maintain state and thus=20 > aren't aware of new flows or old flows; I would be surprised > of this happening and would be very interested in hearing more > about it. I suppose all sorts of packet-optimization boxes, > network scanning detectors, and intrusion prevention devices=20 > might perceive a bunch of ICE probes as a network scanner. >=20 >=20 >=20 > Sorry -- NATs. I believe he was talking about the kind of=20 > issues discussed in B.1. I've unfortunately been unable to=20 > get back in touch with the developer, but I suspect he=20 > implemented a much earlier ICE draft and abandoned it. =20 > That's the impression I got, so hopefully it's the case and=20 > he abandoned a version from before the pacing was introduced.=20 I would like to hear any more detail you might have. This behavior has echos of some issues that Phil Zimmermann and Alan Johnston=20 mentioned they had seen during their development of ZRTP. However, I don't recall any details about the beginning-of-UDP-flow packet loss they were seeing; perhaps it was also across these same sort of NATs. -d > Thanks Dan. >=20 > -Adam >=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