From mmusic-bounces@ietf.org Wed Aug 01 09:49: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 1IGEZQ-0003Je-1W; Wed, 01 Aug 2007 09:49:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEZO-0003Fu-Pf for mmusic@ietf.org; Wed, 01 Aug 2007 09:48:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGEZO-0007AN-9k for mmusic@ietf.org; Wed, 01 Aug 2007 09:48:58 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2007 06:48:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHYrsEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,208,1183359600"; d="scan'208"; a="192431338:sNHT50222160" 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 l71DmvL0000652; Wed, 1 Aug 2007 06:48:57 -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 l71DmqSh004413; Wed, 1 Aug 2007 13:48:57 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); Wed, 1 Aug 2007 06:47:29 -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); Wed, 1 Aug 2007 06:47:29 -0700 Message-ID: <46B08EFC.8090001@cisco.com> Date: Wed, 01 Aug 2007 09:47:40 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Diego B Subject: Re: [MMUSIC] ICE Question: Sharing the same IP between two UAs on different networks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2007 13:47:29.0377 (UTC) FILETIME=[8098B510:01C7D442] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1887; t=1185976137; x=1186840137; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20ICE=20Question=3A=20Sharing=20the=20same=2 0IP=20between=20two=20UAs=20on=0A=20different=20networks |Sender:=20; bh=F94/XIHJne85ST0RqrFMS3beIfc+dF6ojqT82NTFBBQ=; b=fgqAcPFubpC0ZTSofEar2B1vP7vt2zwFMYhT/7YBROx31kxiePnSPfYGUGcF5rBjUiJX54QT MnaRb0sKGBDoZZZCyOpqJekOFUtDXdOlMthaw5VqXzJNqYITbe85Ls95; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Take a look at appendix B.4 of ICE, which discusses this case and how ICE addresses it. Some specific answers below: Diego B wrote: > 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. The check will occur, but because the short-term credential is wrong, it will immediately fail. > > 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. Same as above. Dealing with these cases is one of the reasons that the short term credential is formed by combining username fragments from both sides. > > 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. No, since it will not know the username fragment, it will not be able to authenticate the STUN response. So, the check from UA2 to UA1 will fail. However, checks along a different path (through server reflexive or relayed candidates) will succeed since those are properly routed to UA3. -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 Aug 02 16:10: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 1IGh0O-0002ba-I8; Thu, 02 Aug 2007 16:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGh0N-0002bV-Mq for mmusic@ietf.org; Thu, 02 Aug 2007 16:10:43 -0400 Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IGh0M-00012C-HE for mmusic@ietf.org; Thu, 02 Aug 2007 16:10:43 -0400 Received: (qmail 16200 invoked by uid 1014); 2 Aug 2007 20:10:42 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (spamassassin: 2.63. Clear:RC:1(65.202.222.12):. Processed in 0.033171 secs); 02 Aug 2007 20:10:42 -0000 Received: from unknown (HELO exchange.corp.sentito.com) (65.202.222.12) by airwolf.sentito.com with SMTP; 2 Aug 2007 20:10:42 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 2 Aug 2007 16:10:42 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Pair Priority in ICE-17 Thread-Index: AcfVQTPunHhY4WGOS3GHfptLHSXfwA== From: "Shan Lu" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [MMUSIC] Question on Pair Priority in 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: , Errors-To: mmusic-bounces@ietf.org Hi All, >From 5.7.2/ICE-17: pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). Yet B.5 stated that the objective is to sort on the MAX/MIN property (as opposed to MIN/MAX). So shouldn't pair priority be defined as: pair priority =3D 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) Regards, Shan Lu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 03 09:45: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 1IGxTZ-0004GR-No; Fri, 03 Aug 2007 09:45:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGxTZ-0004GE-8e for mmusic@ietf.org; Fri, 03 Aug 2007 09:45:57 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGxTY-00031m-0s for mmusic@ietf.org; Fri, 03 Aug 2007 09:45:57 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 686132068E for ; Fri, 3 Aug 2007 15:44:34 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-d9-46b331429959 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 47DA7205CE for ; Fri, 3 Aug 2007 15:44:34 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 15:44:34 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 15:44:34 +0200 Message-ID: <46B33141.9070200@ericsson.com> Date: Fri, 03 Aug 2007 15:44:33 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2007 13:44:34.0080 (UTC) FILETIME=[6CF00200:01C7D5D4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [MMUSIC] SDP CAP Neg example using it for media 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 Hi, The below SDP example is using the core of the SDP capability negotiation, or at least attempts to, to perform some media capability negotiation. It is built on the 10k SDP example but here trimmed down to just a simple video and audio stream. I use two different configurations to indicate different media work points. In the case of the video it is both H.264 but here for two different bit-rate work points like a 10 mbit/s and a 512 kbit/s case. For example "streaming quality" and HD quality. I do a similar thing on the audio where it is either AMR-WB(+) or AC3 (dolby digital 5.1 channels). As this is offer answer and I don't know about the RTP payload depacketizer capabilites it includes several packetization modes to ensure that it works. In the video case I also have retransmission support in case AVPF or SAVPF is supported. Otherwise these and 3 of the Audio payload type numbers neeeds to be dummied due to different number of payload formats in different configuration. As can be see the bandwidth values are not possible to express on configuration basis. Thus, one doesn't really know how much the lower bit-rate media configuraiton really uses. One can probably derive a maximum which is likely to be much larger than reality. Thus it is really hidden that some configuration is inteded to use no more than 500 (video) or 50 (audio) kb. You can also spot the downside of no delete function for attributes as I am forced to use the "-m" option and thus need to acap all SDP attributes basically. I havent' found anything that doesn't work in the exercise of creating this SDP. However, I must say that it looks quite ugly. But I forsee that this type of arrangement will start to pop up. And then I think we can forsee even more complex cases. Warning SDP is hand-made and may contain large syntax errors. That is definitely true for the H.264 parameterization. So please consider what this mechanism really means when you get into a bit more serious usages. Also do not expect any replies from me until after the 26th of August. /Magnus v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=A SDP CAP NEG example built on the 10k example I did a while ago i=Uses proxying for some payload typs and does media capability negotiation with only core support u=http://www.example.com/seminars/sdp.pdf e=magnus.westerlund@ericsson.com (Magnus Westerlund) t=2873397496 2873404696 a=ice-pwd:speEc3QGZiNWpVLFJhQX m=video 49170 RTP/AVP 100 99 98 97 96 95 c=IN IP4 192.0.2.56 b=AS:10000 b=TIAS:10000000 b=RR:4000 b=RS:3000 a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF a=pcfg:1 t=1 a=-m:1,2,3,4,5,6,7,11,12,13,30,31,32,33,34,35,36,37,38,39 a=pcfg:2 t=1 a=-m:1,2,3,4,5,6,7,8,9,10,11,12,13,30,31,32,33,34,35,36,37,38,39 a=pcfg:3 t=2 a= a=pcfg:4 t=2 a=8,9,10 a=pcfg:4 t=3 a=1,2,3,4,5,6,7,11,12,13 a=pcfg:5 t=3 a=1,2,3,4,5,6,7,8,9,10,11,12,13 a=maxprate:1000 a=acap:1 a=rtcp-fb:* nack a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42A01E; packetization-mode=0; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== a=rtpmap:100 H264/90000 a=fmtp:100 profile-level-id=42A01E; packetization-mode=2; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==; sprop-interleaving-depth=45; sprop-deint-buf-req=64000; sprop-init-buf-time=102478; deint-buf-cap=128000 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42A01E; packetization-mode=0; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42A01E; packetization-mode=0; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== a=rtpmap:95 H264/90000 a=fmtp:95 profile-level-id=42A01E; packetization-mode=0; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA== a=acap:2 a=rtpmap:97 rtx/90000 a=acap:3 a=fmtp:97 apt=100;rtx-time=3000 a=acap:4 a=rtpmap:96 rtx/90000 a=acap:5 a=fmtp:96 apt=99;rtx-time=3000 a=acap:6 a=rtpmap:95 rtx/90000 a=acap:7 a=fmtp:95 apt=98;rtx-time=3000 a=acap:8 a=fmtp:98 profile-level-id=82A01E; packetization-mode=0; sprop-parameter-sets=fetgasd,fleaS== a=acap:9 a=fmtp:99 profile-level-id=82A01E; packetization-mode=0; sprop-parameter-sets=fetgasd,fleaS== a=acap:10 a=fmtp:100 profile-level-id=82A01E; packetization-mode=0; sprop-parameter-sets=fetgasd,fleaS==; sprop-interleaving-depth=45; sprop-deint-buf-req=64000; sprop-init-buf-time=102478; deint-buf-cap=128000 a=acap:11 a=rtpmap:98 H264/90000 a=acap:12 a=rtpmap:99 H264/90000 a=acap:13 a=rtpmap:100 H264/90000 a=rtcp:51540 a=sendonly a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32 a=candidate 12345678 1 UDP 1.0 192.0.2.56 49170 a=candidate 23456781 2 UDP 1.0 192.0.2.56 51540 a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345 a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567 a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000 a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001 a=acap:30 a=rtcp:51540 a=acap:31 a=sendonly a=acap:32 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32 a=acap:33 a=candidate 12345678 1 UDP 1.0 192.0.2.56 49170 a=acap:34 a=candidate 23456781 2 UDP 1.0 192.0.2.56 51540 a=acap:35 a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345 a=acap:36 a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567 a=acap:37 a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000 a=acap:38 a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001 a=acap:39 a=maxprate:1000 m=audio 49176 RTP/AVP 101 100 99 98 c=IN IP4 192.0.2.56 b=AS:512 b=TIAS:512000 b=RR:4000 b=RS:3000 a=tcap:4 RTP/SAVP a=pcfg:6 t=4 a=23 a=pcfg:7 t=4 a=-m: 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29 a=maxprate:120 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 octet-align=1; mode-change-capability=2 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2 a=rtpmap:100 AMR-WB/16000/2 a=fmtp:100 octet-align=1; interleaving=30 a=rtpmap:101 AMR-WB+/72000/2 a=fmtp:101 interleaving=50; int-delay=160000; a=acap:14 a=rtpmap:98 ac3/48000/6 a=acap:15 a=rtpmap:99 ac3/48000/6 a=acap:16 a=rtpmap:100 ac3/48000/6 a=acap:17 a=rtpmap:101 ac3/48000/6 a=acap:18 a=ptime:32 a=acap:19 a=maxprate:120 a=acap:20 a=maxptime:200 a=acap:21 a=rtcp:51534 a=acap:22 a=sendonly a=acap:23 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|220|1:32 a=acap:24 a=candidate 12345678 1 UDP 1.0 192.0.2.56 49176 a=acap:25 a=candidate 23456781 2 UDP 1.0 192.0.2.56 51534 a=acap:26 a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345 a=acap:27 a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567 a=acap:28 a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000 a=acap:29 a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001 a=ptime:60 a=maxptime:200 a=rtcp:51534 a=sendonly a=candidate 12345678 1 UDP 1.0 192.0.2.56 49176 a=candidate 23456781 2 UDP 1.0 192.0.2.56 51534 a=candidate 34567812 1 UDP 0.7 10.0.0.1 41345 a=candidate 45678123 2 UDP 0.7 10.0.0.1 52567 a=candidate 56781234 1 UDP 0.3 192.0.2.100 49000 a=candidate 67812345 2 UDP 0.3 192.0.2.100 49001 -- 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 Aug 03 13:22:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0qo-00068S-NT; Fri, 03 Aug 2007 13:22:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0qn-00068M-Dp for mmusic@ietf.org; Fri, 03 Aug 2007 13:22:09 -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 1IH0qn-0000qy-19 for mmusic@ietf.org; Fri, 03 Aug 2007 13:22:09 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 03 Aug 2007 08:24:37 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOblskarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.19,217,1183359600"; d="scan'208"; a="510076485:sNHT3607158550" 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 l73FObk8026837; Fri, 3 Aug 2007 08:24:37 -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 l73FObE0023816; Fri, 3 Aug 2007 15:24:37 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, 3 Aug 2007 08:24:37 -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, 3 Aug 2007 08:24:36 -0700 Message-ID: <46B348C0.2010109@cisco.com> Date: Fri, 03 Aug 2007 11:24:48 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Shan Lu Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2007 15:24:36.0909 (UTC) FILETIME=[66E705D0:01C7D5E2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=996; t=1186154677; x=1187018677; 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]=20Question=20on=20Pair=20Priority=20in=20ICE -17 |Sender:=20; bh=EoHDFoOKg5MXPrvteIgS0iff8TH8a0w/a0oj6lhKjPo=; b=P4wpG07IuMSsTC7ESQPJzaibZBaQae9ysZ1QdbQR0MP7D7B3+fCUa1sD0oCRwWLk00WTAxOu O2gwr7btFMlUqR8hrjUCowHNpAju9W9SOPTmL9aW/LMFA6XnuzqbdEcf; 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: 97adf591118a232206bdb5a27b217034 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 formula is correct as written. The term "max/min" sorting refers to the property that, pairs with the largest prioritites come first. -Jonathan R. Shan Lu wrote: > Hi All, > >>From 5.7.2/ICE-17: > > pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). > > Yet B.5 stated that the objective is to sort on the MAX/MIN property (as > opposed to MIN/MAX). So shouldn't pair priority be defined as: > > pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) > > Regards, > > Shan Lu > > _______________________________________________ > 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 Aug 03 16:36: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 1IH3sQ-00085j-0u; Fri, 03 Aug 2007 16:36:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3sO-00084s-JQ for mmusic@ietf.org; Fri, 03 Aug 2007 16:36:00 -0400 Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IH3sL-0001Wz-D6 for mmusic@ietf.org; Fri, 03 Aug 2007 16:36:00 -0400 Received: (qmail 56213 invoked by uid 1014); 3 Aug 2007 20:35:57 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (spamassassin: 2.63. Clear:RC:1(65.202.222.12):. Processed in 0.096751 secs); 03 Aug 2007 20:35:57 -0000 Received: from unknown (HELO exchange.corp.sentito.com) (65.202.222.12) by airwolf.sentito.com with SMTP; 3 Aug 2007 20:35:56 -0000 Content-class: urn:content-classes:message Subject: RE: [MMUSIC] Question on Pair Priority in ICE-17 Date: Fri, 3 Aug 2007 16:35:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: In-Reply-To: <46B348C0.2010109@cisco.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on Pair Priority in ICE-17 Thread-Index: AcfV4o9hLHbb3Kn5TD6z0NGoBF1XRQAKl90g References: <46B348C0.2010109@cisco.com> From: "Shan Lu" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 In that case, the two sentences at top of Page 106 should have "maximum" and "minimum" swapped to read as: ... the pairs are first sorted based on decreasing value of the minimum of the two priorities. For pairs that have the same value of the minimum priority, the maximum priority is used to sort amongst them. Also "priority" should replace "sequence number" in this section. Regards, Shan Lu=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Friday, August 03, 2007 11:25 AM > To: Shan Lu > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 >=20 > The formula is correct as written. The term "max/min" sorting=20 > refers to=20 > the property that, pairs with the largest prioritites come first. >=20 > -Jonathan R. >=20 > Shan Lu wrote: > > Hi All, > >=20 > >>From 5.7.2/ICE-17: > >=20 > > pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). > >=20 > > Yet B.5 stated that the objective is to sort on the MAX/MIN=20 > property (as > > opposed to MIN/MAX). So shouldn't pair priority be defined as: > >=20 > > pair priority =3D 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) > >=20 > > Regards, > >=20 > > Shan Lu > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Aug 04 08:46: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 1IHJ1U-0003eH-G1; Sat, 04 Aug 2007 08:46:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHJ1T-0003eC-QJ for mmusic@ietf.org; Sat, 04 Aug 2007 08:46:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHJ1T-00013q-8s for mmusic@ietf.org; Sat, 04 Aug 2007 08:46:23 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2007 05:46:22 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPMRtEarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.19,220,1183359600"; d="scan'208"; a="194288224:sNHT26654634" 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 l74CkM0n006807; Sat, 4 Aug 2007 05:46:22 -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 l74CkMVp002404; Sat, 4 Aug 2007 12:46:22 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, 4 Aug 2007 05:46:22 -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, 4 Aug 2007 05:46:21 -0700 Message-ID: <46B47529.8060800@cisco.com> Date: Sat, 04 Aug 2007 08:46:33 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Shan Lu Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 References: <46B348C0.2010109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2007 12:46:22.0025 (UTC) FILETIME=[75EC7390:01C7D695] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2175; t=1186231582; x=1187095582; 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]=20Question=20on=20Pair=20Priority=20in=20ICE -17 |Sender:=20; bh=sSwood+mIf98BSes8Doapm2fAUD44lV7AojRlR5r2F0=; b=frK6M1I97jNts6i0Qmc3I3WzYJgCUrxzQGXnyB0qgKdAOY0qssl/yyBHWmpxpIumv7iKmFir hVMBNh9zQFg1ppWKbRIl6kAlkRu0P5yW/Urs8cSYbQVzop0hRIjV27qwMSv9/BFpD6rDw+U2MV mAFVi7EO6dPXqPU3iAkbJwx1s=; 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: fb6060cb60c0cea16e3f7219e40a0a81 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 Fixed, thanks for catching it. -Jonathan R. Shan Lu wrote: > In that case, the two sentences at top of Page 106 should have "maximum" > and "minimum" swapped to read as: > > ... the pairs are first sorted based on decreasing value of the > minimum of the two priorities. For pairs that have the same > value of the minimum priority, the maximum priority is > used to sort amongst them. > > Also "priority" should replace "sequence number" in this section. > > Regards, > > Shan Lu > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: Friday, August 03, 2007 11:25 AM >> To: Shan Lu >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 >> >> The formula is correct as written. The term "max/min" sorting >> refers to >> the property that, pairs with the largest prioritites come first. >> >> -Jonathan R. >> >> Shan Lu wrote: >>> Hi All, >>> >>> >From 5.7.2/ICE-17: >>> >>> pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). >>> >>> Yet B.5 stated that the objective is to sort on the MAX/MIN >> property (as >>> opposed to MIN/MAX). So shouldn't pair priority be defined as: >>> >>> pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) >>> >>> Regards, >>> >>> Shan Lu >>> >>> _______________________________________________ >>> 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 >> >> > -- 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 Aug 06 16:44: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 1II9RY-0005YD-5i; Mon, 06 Aug 2007 16:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9RU-0005Xx-Tz for mmusic@ietf.org; Mon, 06 Aug 2007 16:44:46 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9RT-0001ow-0E for mmusic@ietf.org; Mon, 06 Aug 2007 16:44:44 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1340154wxd for ; Mon, 06 Aug 2007 13:44:41 -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=bdgsWjmJ1osoLWJwBcdLfVele2J+v1vxjGd1zgGZuFgyGQxOO7diGPwoKgNyFUhUsgy/VCQq25zkcPdfHAAYJMvl03eWu0iTYUfUDh6Nzsq4kNUAmZOUhuxIbRIEBgSgNWqFfDUAi2tqH/F6l/kQgDsQ0hG2o19K7hHpFx76EQo= 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=TfofHDOcZXCKHds6Qg003xbwxVQfMaokCCGUc4MctUzAahNqtYhi9Eo5ORDMA4by90jxR5OjjrGwKoFzUhICAGQ4+RfiDEA9dQUACUHpR4zekU1lRPNZFNojSUFBzPjOb1y7gH0oQMf4dOMs3ASsBBopleRDZfSVD3EqDb/VpnI= Received: by 10.70.122.11 with SMTP id u11mr10428077wxc.1186433081434; Mon, 06 Aug 2007 13:44:41 -0700 (PDT) Received: by 10.70.123.1 with HTTP; Mon, 6 Aug 2007 13:44:41 -0700 (PDT) Message-ID: Date: Mon, 6 Aug 2007 16:44:41 -0400 From: "Adam Fisk" To: "Jonathan Rosenberg" Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 In-Reply-To: <46B47529.8060800@cisco.com> MIME-Version: 1.0 References: <46B348C0.2010109@cisco.com> <46B47529.8060800@cisco.com> X-Google-Sender-Auth: f706e49a9ff0d76d X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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="===============1525887793==" Errors-To: mmusic-bounces@ietf.org --===============1525887793== Content-Type: multipart/alternative; boundary="----=_Part_83538_13793763.1186433081388" ------=_Part_83538_13793763.1186433081388 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Related nit in the same section: "the offerers priority is used as the tie breaker" should be: "the offerer's priority is used as the tie breaker" -Adam On 8/4/07, Jonathan Rosenberg wrote: > > Fixed, thanks for catching it. > > -Jonathan R. > > Shan Lu wrote: > > In that case, the two sentences at top of Page 106 should have "maximum" > > and "minimum" swapped to read as: > > > > ... the pairs are first sorted based on decreasing value of the > > minimum of the two priorities. For pairs that have the same > > value of the minimum priority, the maximum priority is > > used to sort amongst them. > > > > Also "priority" should replace "sequence number" in this section. > > > > Regards, > > > > Shan Lu > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: Friday, August 03, 2007 11:25 AM > >> To: Shan Lu > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 > >> > >> The formula is correct as written. The term "max/min" sorting > >> refers to > >> the property that, pairs with the largest prioritites come first. > >> > >> -Jonathan R. > >> > >> Shan Lu wrote: > >>> Hi All, > >>> > >>> >From 5.7.2/ICE-17: > >>> > >>> pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). > >>> > >>> Yet B.5 stated that the objective is to sort on the MAX/MIN > >> property (as > >>> opposed to MIN/MAX). So shouldn't pair priority be defined as: > >>> > >>> pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) > >>> > >>> Regards, > >>> > >>> Shan Lu > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > > > > -- > 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_83538_13793763.1186433081388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Related nit in the same section:

"the offerers priority is used as the tie breaker"

should be:

"the offerer's priority is used as the tie breaker"

-Adam


On 8/4/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
Fixed, thanks for catching it.

-Jonathan R.

Shan Lu wrote:
> In that case, the two sentences at top of Page 106 should have "maximum"
> and "minimum" swapped to read as:
>
>    ... the pairs are first sorted based on decreasing value of the
>    minimum of the two priorities.  For pairs that have the same
>    value of the minimum priority, the maximum priority is
>    used to sort amongst them.
>
> Also "priority" should replace "sequence number" in this section.
>
> Regards,
>
> Shan Lu
>
>> -----Original Message-----
>> From: Jonathan Rosenberg [mailto: jdrosen@cisco.com]
>> Sent: Friday, August 03, 2007 11:25 AM
>> To: Shan Lu
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17
>>
>> The formula is correct as written. The term "max/min" sorting
>> refers to
>> the property that, pairs with the largest prioritites come first.
>>
>> -Jonathan R.
>>
>> Shan Lu wrote:
>>> Hi All,
>>>
>>> >From 5.7.2/ICE-17:
>>>
>>>     pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0).
>>>
>>> Yet B.5 stated that the objective is to sort on the MAX/MIN
>> property (as
>>> opposed to MIN/MAX). So shouldn't pair priority be defined as:
>>>
>>>     pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0)
>>>
>>> Regards,
>>>
>>> Shan Lu
>>>
>>> _______________________________________________
>>> 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
>>
>>
>

--
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_83538_13793763.1186433081388-- --===============1525887793== 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 --===============1525887793==-- From mmusic-bounces@ietf.org Mon Aug 06 16:50: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 1II9XO-0000KD-6d; Mon, 06 Aug 2007 16:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9XM-0000K0-Nh for mmusic@ietf.org; Mon, 06 Aug 2007 16:50:48 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9XL-0001xY-7B for mmusic@ietf.org; Mon, 06 Aug 2007 16:50:48 -0400 Received: by wx-out-0506.google.com with SMTP id h27so1341242wxd for ; Mon, 06 Aug 2007 13:50:46 -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=sjnUVjyD7LujJ0tkcAvV4Ql+XB9+OgqBu+llQam04QyQZSHFPfHHpE+MNTmRTL4OuD8PdfrSQRdAnnoZSCTDKHMXiCC8vQGEUclT5v8jXzugdQ0h05X2w5Bf5p+38U9P0ywOaBtplHiQO8GakOqu1ER+shJubM28LH+1t1ufCdI= 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=JTmLcVpaDXdB5sNP1HL2DByzOjDfE7sSkr1zTpllWu02S2FbqcJHTSGpBnDpl5aMgdClQoLw26vO9/xpaknXTUkizF2wGu9tUsV7rQHvxQK8zHioQkGQ/n5Q6La7Ro32wy/ftfHgr1eEJL2F/+evCFrgHI/KTRPXd8XlfM/fMLQ= Received: by 10.70.61.3 with SMTP id j3mr10481990wxa.1186433445833; Mon, 06 Aug 2007 13:50:45 -0700 (PDT) Received: by 10.70.123.1 with HTTP; Mon, 6 Aug 2007 13:50:45 -0700 (PDT) Message-ID: Date: Mon, 6 Aug 2007 16:50:45 -0400 From: "Adam Fisk" To: "Jonathan Rosenberg" Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 In-Reply-To: MIME-Version: 1.0 References: <46B348C0.2010109@cisco.com> <46B47529.8060800@cisco.com> X-Google-Sender-Auth: 3ef8eae202f4a981 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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="===============0637035411==" Errors-To: mmusic-bounces@ietf.org --===============0637035411== Content-Type: multipart/alternative; boundary="----=_Part_83610_2417779.1186433445777" ------=_Part_83610_2417779.1186433445777 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Looking more closely at this, it appears this section is slightly inconsistent with section 5.7.2. I believe that instead of: "the offerers priority is used as the tie breaker" it should be: "the controlling agent's priority is used as the tie breaker" -Adam On 8/6/07, Adam Fisk wrote: > > Related nit in the same section: > > "the offerers priority is used as the tie breaker" > > should be: > > "the offerer's priority is used as the tie breaker" > > -Adam > > > On 8/4/07, Jonathan Rosenberg wrote: > > > > Fixed, thanks for catching it. > > > > -Jonathan R. > > > > Shan Lu wrote: > > > In that case, the two sentences at top of Page 106 should have > > "maximum" > > > and "minimum" swapped to read as: > > > > > > ... the pairs are first sorted based on decreasing value of the > > > minimum of the two priorities. For pairs that have the same > > > value of the minimum priority, the maximum priority is > > > used to sort amongst them. > > > > > > Also "priority" should replace "sequence number" in this section. > > > > > > Regards, > > > > > > Shan Lu > > > > > >> -----Original Message----- > > >> From: Jonathan Rosenberg [mailto: jdrosen@cisco.com] > > >> Sent: Friday, August 03, 2007 11:25 AM > > >> To: Shan Lu > > >> Cc: mmusic@ietf.org > > >> Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 > > >> > > >> The formula is correct as written. The term "max/min" sorting > > >> refers to > > >> the property that, pairs with the largest prioritites come first. > > >> > > >> -Jonathan R. > > >> > > >> Shan Lu wrote: > > >>> Hi All, > > >>> > > >>> >From 5.7.2/ICE-17: > > >>> > > >>> pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). > > >>> > > >>> Yet B.5 stated that the objective is to sort on the MAX/MIN > > >> property (as > > >>> opposed to MIN/MAX). So shouldn't pair priority be defined as: > > >>> > > >>> pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) > > >>> > > >>> Regards, > > >>> > > >>> Shan Lu > > >>> > > >>> _______________________________________________ > > >>> 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 > > >> > > >> > > > > > > > -- > > 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_83610_2417779.1186433445777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Looking more closely at this, it appears this section is slightly inconsistent with section 5.7.2.

I believe that instead of:

"the offerers priority is used as the tie breaker"

it should be:

"the controlling agent's priority is used as the tie breaker"

-Adam


On 8/6/07, Adam Fisk <a@lastbamboo.org> wrote:
Related nit in the same section:

"the offerers priority is used as the tie breaker"

should be:

"the offerer's priority is used as the tie breaker"

-Adam


On 8/4/07, Jonathan Rosenberg < jdrosen@cisco.com> wrote:
Fixed, thanks for catching it.

-Jonathan R.

Shan Lu wrote:
> In that case, the two sentences at top of Page 106 should have "maximum"
> and "minimum" swapped to read as:
>
>    ... the pairs are first sorted based on decreasing value of the
>    minimum of the two priorities.  For pairs that have the same
>    value of the minimum priority, the maximum priority is
>    used to sort amongst them.
>
> Also "priority" should replace "sequence number" in this section.
>
> Regards,
>
> Shan Lu
>
>> -----Original Message-----
>> From: Jonathan Rosenberg [mailto: jdrosen@cisco.com]
>> Sent: Friday, August 03, 2007 11:25 AM
>> To: Shan Lu
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17
>>
>> The formula is correct as written. The term "max/min" sorting
>> refers to
>> the property that, pairs with the largest prioritites come first.
>>
>> -Jonathan R.
>>
>> Shan Lu wrote:
>>> Hi All,
>>>
>>> >From 5.7.2/ICE-17:
>>>
>>>     pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0).
>>>
>>> Yet B.5 stated that the objective is to sort on the MAX/MIN
>> property (as
>>> opposed to MIN/MAX). So shouldn't pair priority be defined as:
>>>
>>>     pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0)
>>>
>>> Regards,
>>>
>>> Shan Lu
>>>
>>> _______________________________________________
>>> 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
>>
>>
>

--
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_83610_2417779.1186433445777-- --===============0637035411== 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 --===============0637035411==-- From mmusic-bounces@ietf.org Tue Aug 07 09:38: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 1IIPGS-0002wF-19; Tue, 07 Aug 2007 09:38:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPGP-0002vz-Pr for mmusic@ietf.org; Tue, 07 Aug 2007 09:38:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIPGP-0006Ss-10 for mmusic@ietf.org; Tue, 07 Aug 2007 09:38:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Aug 2007 06:38:20 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFoSuEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,229,1183359600"; d="scan'208"; a="195760964:sNHT37011987" 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 l77DcK7n015687; Tue, 7 Aug 2007 06:38:20 -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 l77DcCVp005841; Tue, 7 Aug 2007 13:38:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 06:38:11 -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); Tue, 7 Aug 2007 06:38:11 -0700 Message-ID: <46B875CE.9020002@cisco.com> Date: Tue, 07 Aug 2007 09:38:22 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adam Fisk Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 References: <46B348C0.2010109@cisco.com> <46B47529.8060800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 13:38:11.0525 (UTC) FILETIME=[3291BF50:01C7D8F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4578; t=1186493900; x=1187357900; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[MMUSIC]=20Question=20on=20Pair=20Priority=20in=20ICE -17 |Sender:=20; bh=QkD23sWqA9/PIghzomUxkHL3UP823k+iVeMx8aHoTEw=; b=aPOpTyuzWO86aZsYrDtxeQj1bJdA6X1Raz5NvSYWeMKlEK2N9sWy0jnqklwVvE5Siedkb2Sp Gmnh7FRuH1gLRQWNJm+PWc9UUw6qWdxvgJ0CCfDIRGc26Padjn9c7QjV; 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: 7da5a831c477fb6ef97f379a05fb683c Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Yup, another bug. I haven't kept the appendix up to date here, obviously. Fixed. -Jonathan R. Adam Fisk wrote: > Looking more closely at this, it appears this section is slightly > inconsistent with section 5.7.2. > > I believe that instead of: > > "the offerers priority is used as the tie breaker" > > it should be: > > "the controlling agent's priority is used as the tie breaker" > > -Adam > > > > On 8/6/07, *Adam Fisk* > wrote: > > Related nit in the same section: > > "the offerers priority is used as the tie breaker" > > should be: > > "the offerer's priority is used as the tie breaker" > > -Adam > > > On 8/4/07, *Jonathan Rosenberg* < jdrosen@cisco.com > > wrote: > > Fixed, thanks for catching it. > > -Jonathan R. > > Shan Lu wrote: > > In that case, the two sentences at top of Page 106 should have > "maximum" > > and "minimum" swapped to read as: > > > > ... the pairs are first sorted based on decreasing value of the > > minimum of the two priorities. For pairs that have the same > > value of the minimum priority, the maximum priority is > > used to sort amongst them. > > > > Also "priority" should replace "sequence number" in this section. > > > > Regards, > > > > Shan Lu > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto: jdrosen@cisco.com > ] > > > Sent: Friday, August 03, 2007 11:25 AM > > > To: Shan Lu > > > Cc: mmusic@ietf.org > > > Subject: Re: [MMUSIC] Question on Pair Priority in ICE-17 > > > > > > The formula is correct as written. The term "max/min" sorting > > > refers to > > > the property that, pairs with the largest prioritites come first. > > > > > > -Jonathan R. > > > > > > Shan Lu wrote: > > >> Hi All, > > >> > > >> >From 5.7.2/ICE-17: > > >> > > >> pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0). > > >> > > >> Yet B.5 stated that the objective is to sort on the MAX/MIN > > > property (as > > >> opposed to MIN/MAX). So shouldn't pair priority be defined as: > > >> > > >> pair priority = 2^32*MAX(G,D) + 2*MIN(G,D) + (G>D?1:0) > > >> > > >> Regards, > > >> > > >> Shan Lu > > >> > > >> _______________________________________________ > > >> 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 > > > > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com > FAX: > (973) 952-5050 > http://www.jdrosen.net PHONE: (973) > 952-5000 > http://www.cisco.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Aug 07 10:29: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 1IIQ3e-0004UD-79; Tue, 07 Aug 2007 10:29:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQ3c-0004TY-DE; Tue, 07 Aug 2007 10:29:12 -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 1IIQ3b-000179-TH; Tue, 07 Aug 2007 10:29:12 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77ESilH009245; Tue, 7 Aug 2007 17:29:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:29:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:29:00 +0300 Received: from hed050118.research.nokia.com ([172.21.50.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 17:28:59 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Date: Tue, 7 Aug 2007 17:28:59 +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: <200708071728.59636.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 Aug 2007 14:28:59.0590 (UTC) FILETIME=[4B5B8E60:01C7D8FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mmusic@ietf.org Subject: [MMUSIC] STUN fingerprint and integrity tests X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org [ Please direct responses to BEHAVE mailing list, NOT MMUSIC! ] Hello, If anyone is implementing an ICE or something-using-STUN stack, I have put= =20 sample FINGERPRINT and MESSAGE-INTEGRITY test vectors. I might have messed= =20 them up, since I have not had the chance to test with third parties. Pending processing by the secretariat, you can find them here: http://www.remlab.net/files/ietf/draft-denis-behave-rfc3489bis-test-vectors= =2D00.txt 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 Aug 08 13:17: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 1IIp78-0007SZ-S0; Wed, 08 Aug 2007 13:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHtjW-0002CC-H9 for mmusic@ietf.org; Sun, 05 Aug 2007 23:58:18 -0400 Received: from mailipao.vtcif.telstra.com.au ([202.12.144.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHtjU-0001rY-JU for mmusic@ietf.org; Sun, 05 Aug 2007 23:58:18 -0400 Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipai.vtcif.telstra.com.au with ESMTP; 06 Aug 2007 13:58:11 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 340AF1DA82 for ; Mon, 6 Aug 2007 13:58:10 +1000 (EST) Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA01213 for ; Mon, 6 Aug 2007 13:58:09 +1000 (EST) Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 13:57:57 +1000 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, 6 Aug 2007 13:57:57 +1000 Message-ID: <903E4F74808D4F4B93635C9D9183EBAC021999E0@WSMSG2103V.srv.dir.telstra.com> Thread-Topic: [Sip] Bandwidth parameter in SIP/SDP Thread-Index: AcfTpPUITnFCvDyRTE2aGwhpLpZQmwEODzeQAAAwyCA= From: "Robins, Ellen" To: X-OriginalArrivalTime: 06 Aug 2007 03:57:57.0471 (UTC) FILETIME=[F95CEEF0:01C7D7DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Wed, 08 Aug 2007 13:14:28 -0400 Subject: [MMUSIC] FW: [Sip] Bandwidth parameter in SIP/SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 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: James M. Polk [mailto:jmpolk@cisco.com] Sent: Wednesday, 1 August 2007 4:59 AM To: Robins, Ellen Subject: Re: [Sip] Bandwidth parameter in SIP/SDP this question is on the wrong list. Try posting to the MMUSIC WG At 12:42 AM 7/31/2007, you wrote: > Dear all, >Please help to confirm which bandwidth parameter shall be used by Video >Terminal Client for a SIP Client to SIP Client call case, i.e. between >2 parties not a three-way conference. > > Bandwidth > > b=3D: > > o This specifies the proposed bandwidth to be used by the session or > media, and is optional. > > o is in kilobits per second > > o is a single alphanumeric word giving the meaning of the > bandwidth figure. > > o Two modifiers are initially defined: > > CT Conference Total: An implicit maximum bandwidth is associated with > each TTL on the Mbone or within a particular multicast > administrative scope region (the Mbone bandwidth vs. TTL limits are > given in the MBone FAQ). If the bandwidth of a session or media in > a session is different from the bandwidth implicit from the scope, > a `b=3DCT:...' line should be supplied for the session giving the > proposed upper limit to the bandwidth used. The primary purpose of > this is to give an approximate idea as to whether two or more > conferences can co-exist simultaneously. > > AS Application-Specific Maximum: The bandwidth is interpreted to be > application-specific, i.e., will be the application's concept of > maximum bandwidth. Normally this will coincide with what is set on > the application's "maximum bandwidth" control if applicable. > > Note that CT gives a total bandwidth figure for all the media at > all sites. AS gives a bandwidth figure for a single media at a > single site, although there may be many sites sending > simultaneously. > > >Thanks and kind regards / Ellen Robins >ViG Technology Manager >Services Enablers >Wireless Engineering & Operations >Telstra Operations >Telstra Corporation Limited > >Ph 03 8627 8981 >Mob 0428 309 250 >Fax 03 9620 7864 >Mail ellen.robins@team.telstra.com > >The information contained in this email message may be confidential. If >you are not the intended recipient, any use of, interference with,=20 >disclosure or copying of this material is unauthorised and prohibited. >If you have received this message in error, please notify me by reply=20 >email and then delete the message. > > >_______________________________________________ >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 Use=20 >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 Aug 09 10:33: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 1IJ93M-0007xv-HR; Thu, 09 Aug 2007 10:31:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ93L-0007rB-PA for mmusic@ietf.org; Thu, 09 Aug 2007 10:31:55 -0400 Received: from hm632-2.locaweb.com.br ([200.234.205.216] helo=hm632.locaweb.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IJ93K-0004n3-TY for mmusic@ietf.org; Thu, 09 Aug 2007 10:31:55 -0400 Received: (qmail 15658 invoked from network); 9 Aug 2007 14:31:48 -0000 Received: from unknown (10.1.10.10) by hm632.locaweb.com.br with QMQP; 9 Aug 2007 14:31:48 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.67.56) by hm10.locaweb.com.br with SMTP; 9 Aug 2007 14:31:51 -0000 Message-ID: <46BB254B.6090803@comunip.com.br> Date: Thu, 09 Aug 2007 11:31:39 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [MMUSIC] ICE-17 minor fix X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Section 7.1.1.1. "PRIORITY and USE-CANDIDATE", first paragraph: (...) This priority value will be computed identically to how the priority for the local candidate of the pair was computed, except that the type preference is set to the value for peer derived candidate types. The term "peer derived" should be "peer reflexive", isn't it? Regards, Guilherme Balena Versiani. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Aug 09 12:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJB5O-0007ew-Hw; Thu, 09 Aug 2007 12:42:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJB5M-0007eq-Ov for mmusic@ietf.org; Thu, 09 Aug 2007 12:42:08 -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 1IJB5M-0008To-8j for mmusic@ietf.org; Thu, 09 Aug 2007 12:42:08 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l79Gfskn008409; Thu, 9 Aug 2007 19:41:55 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 19:41:54 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 19:41:53 +0300 Received: from 4FIL28146 (esdhcp04178.research.nokia.com [172.21.41.78]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l79Gfo5Z002625; Thu, 9 Aug 2007 19:41:50 +0300 From: "Kai Vehmanen" To: "'ext Henry Sinnreich'" , "Adam Fisk" , "Jiri Kuthan" 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> <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC Date: Thu, 9 Aug 2007 19:41:49 +0300 Organization: Nokia Message-ID: <000001c7daa4$2feb25e0$0a9db70a@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeAAss0sAA= In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> X-OriginalArrivalTime: 09 Aug 2007 16:41:53.0709 (UTC) FILETIME=[31210DD0:01C7DAA4] X-Nokia-AV: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Denis-Courmont Remi \(Nokia-TP-MSW/Helsinki\)" , 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: , Errors-To: mmusic-bounces@ietf.org Hi, =20 dropping BEHAVE and P2PSIP from the CC-list. On 26 July 2007, Henry Sinnreich wrote: > Is anyone on these lists designing a test tool for NAT=20 > scenario discovery and for ICE? we have a simple automated tester "nice_tester" available as open-source. Details on where to get it and how to use it are available at: http://article.gmane.org/gmane.comp.telephony.sofia-sip.devel/1786 We currently don't have the time to expand this into a general purpose testing tool, but it's a start. Feel free to grab the sources and extend the tool! Also welcome are test results from other ICE=20 implementations (for instance if you run nice_tester against your ICE=20 implementation). So far no succesful tests with our -17 implementation=20 as we've yet to find anyone to test against. If you have an up-to-date=20 implementation and are ready for some basic IOP test runs, please=20 contact me or R=E9mi (see CC-list). --=20 first.surname@nokia.com (Kai Vehmanen) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 10 09:48: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 1IJUpL-0007ui-Ij; Fri, 10 Aug 2007 09:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJUpK-0007rW-9n for mmusic@ietf.org; Fri, 10 Aug 2007 09:46:54 -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 1IJUpI-0005tI-QP for mmusic@ietf.org; Fri, 10 Aug 2007 09:46:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7ADkNsa002762; Fri, 10 Aug 2007 16:46:49 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 16:46:18 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 16:46:18 +0300 Received: from [10.144.23.148] ([10.144.23.148]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 16:46:18 +0300 Message-ID: <46BC6C2A.9000305@nsn.com> Date: Fri, 10 Aug 2007 16:46:18 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach , mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 13:46:18.0448 (UTC) FILETIME=[D4098D00:01C7DB54] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org During the last IETF meeting there was a comment with respect the relation of SDP bodies and icon bodies. When the two bodies appear together, the draft says they need to be wrapped in a MIME multipart/mixed container. Adam commented that it should be multipart/related instead. RFC 2387 defines the multipart/related MIME wrapper: The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts. RFC 2046 defines the multipart/mixed MIME wrapper: The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order. Any "multipart" subtypes that an implementation does not recognize must be treated as being of subtype "mixed". The difference between both is subtle, in my opinion. The multipart/related definition says that "proper display cannot be achieved by individually displayign the constituent body parts", which is not entirely true: SDP will be meaningful in the absence of an icon; the icon is also meaningful isolated, although it is not linked to any file descriptor. The multipart/mixed definition speaks about "independent parts that need to be bundled in a particular order", which is probably true, because although the SDP and the icon are independent, the SDP should be read first. While I don't have a strong opinion, I would suggest to leave the draft with the current indication of multipart/mixed. Comments? /Migel -- 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 Fri Aug 10 12: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 1IJXYn-0007Ce-I5; Fri, 10 Aug 2007 12:42:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJXYm-0007CY-MI for mmusic@ietf.org; Fri, 10 Aug 2007 12:42:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJXYl-0001a5-FW for mmusic@ietf.org; Fri, 10 Aug 2007 12:42:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2007 12:41:59 -0400 X-IronPort-AV: i="4.19,245,1183348800"; d="scan'208"; a="128542079:sNHT49371586" 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 l7AGfx27026561; Fri, 10 Aug 2007 12:41:59 -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 l7AGfnmn018497; Fri, 10 Aug 2007 16:41: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); Fri, 10 Aug 2007 12:41:52 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 12:41:51 -0400 Message-ID: <46BC954D.2000309@cisco.com> Date: Fri, 10 Aug 2007 12:41:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related References: <46BC6C2A.9000305@nsn.com> In-Reply-To: <46BC6C2A.9000305@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 16:41:51.0616 (UTC) FILETIME=[5A4B7000:01C7DB6D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2260; t=1186764119; x=1187628119; 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:=20Re=3A=20[MMUSIC]=20File=20transfer=20issue=2049=3A=20multipar t/mixed=20or=09multipart/related |Sender:=20 |To:=20Miguel=20Garcia=20; bh=ERWSvDdbF8PKnGtc921/6wRDdUm64qpW5oAkOoBw0N8=; b=U3N4XmI48uQpnPrSko4+BQHmzlGm4mt9BE4f4DV4pdNeHOadY0SVSEP7t5Cg2tuHTQxH5fg0 7fUj2pXnbhf3ysjdf4fUaEe9wpDW6/xCVEtKy2EcrbLG2vnllP3KWIsc; 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: 538aad3a3c4f01d8b6a6477ca4248793 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 Miguel Garcia wrote: > During the last IETF meeting there was a comment with respect the > relation of SDP bodies and icon bodies. > > When the two bodies appear together, the draft says they need to be > wrapped in a MIME multipart/mixed container. Adam commented that it > should be multipart/related instead. > > RFC 2387 defines the multipart/related MIME wrapper: > > The Multipart/Related media type is intended for compound objects > consisting of several inter-related body parts. For a > Multipart/Related object, proper display cannot be achieved by > individually displaying the constituent body parts. > > RFC 2046 defines the multipart/mixed MIME wrapper: > > The "mixed" subtype of "multipart" is intended for use when the body > parts are independent and need to be bundled in a particular order. > Any "multipart" subtypes that an implementation does not recognize > must be treated as being of subtype "mixed". > > > The difference between both is subtle, in my opinion. The > multipart/related definition says that "proper display cannot be > achieved by individually displayign the constituent body parts", which > is not entirely true: SDP will be meaningful in the absence of an icon; > the icon is also meaningful isolated, although it is not linked to any > file descriptor. I agree that in this case the parts don't seem to be related. > The multipart/mixed definition speaks about "independent parts that need > to be bundled in a particular order", which is probably true, because > although the SDP and the icon are independent, the SDP should be read > first. I don't see any ordering requirement here. There are certainly other cases where mixed seems to be the thing to use where ordering definitely isn't important. Is there another multipart subtype that is like mixed except without ordering? (multipart/unordered?) I've not heard of such a thing. If not it seems that mixed must be used even when ordering isn't important. > While I don't have a strong opinion, I would suggest to leave the draft > with the current indication of multipart/mixed. I agree unless there is a choice better than mixed or related. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 10 15:04:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZlG-0002ec-QP; Fri, 10 Aug 2007 15:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZlF-0002eX-6s for mmusic@ietf.org; Fri, 10 Aug 2007 15:03:01 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJZlE-0003I8-M7 for mmusic@ietf.org; Fri, 10 Aug 2007 15:03:01 -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 l7AJ2xHq052330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 14:03:00 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46BCB66B.4080507@nostrum.com> Date: Fri, 10 Aug 2007 14:03:07 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Miguel Garcia References: <46BC6C2A.9000305@nsn.com> In-Reply-To: <46BC6C2A.9000305@nsn.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-Virus-Scanned: ClamAV 0.91.1/3909/Fri Aug 10 10:10:24 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mmusic Subject: [MMUSIC] Re: File transfer issue 49: multipart/mixed or multipart/related X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org Comments inline. On 8/10/07 8:46 AM, Miguel Garcia wrote: > During the last IETF meeting there was a comment with respect the > relation of SDP bodies and icon bodies. > > When the two bodies appear together, the draft says they need to be > wrapped in a MIME multipart/mixed container. Adam commented that it > should be multipart/related instead. > > RFC 2387 defines the multipart/related MIME wrapper: > > The Multipart/Related media type is intended for compound objects > consisting of several inter-related body parts. For a > Multipart/Related object, proper display cannot be achieved by > individually displaying the constituent body parts. > > RFC 2046 defines the multipart/mixed MIME wrapper: > > The "mixed" subtype of "multipart" is intended for use when the body > parts are independent and need to be bundled in a particular order. > Any "multipart" subtypes that an implementation does not recognize > must be treated as being of subtype "mixed". > > > The difference between both is subtle, in my opinion. The > multipart/related definition says that "proper display cannot be > achieved by individually displayign the constituent body parts", which > is not entirely true: SDP will be meaningful in the absence of an > icon; the icon is also meaningful isolated, although it is not linked > to any file descriptor. The canonical use case today for mutipart/related in email communications is a multipart/related document which contains an HTML document as its root, and dependencies (such as images) as the remaining parts. Section 5.2 of RFC 2387 provides an example of such a set up. The key idea in multipart/related is that the root document provides a semantic context for the remaining parts. (I presume you read enough to 2387 to understand the "root document" concept, right?) In this use case, the HTML will typically be meaningful in the absence of the images (for example, I use Thunderbird, which automatically blocks images in HTML mail until you specifically unblock them; for about 90% of the HTML mail I get, I never bother to load the images, because the HTML is sufficiently meaningful without them). By the same token, the images are also as meaningful in isolation as the icons you discuss above. These properties are not sufficient to counter-indicate the use of multipart/related, as you imply. So, in both of these respects, it appears that the SDP/icon setup you're describing in the draft is congruent with the examples given in RFC 2387. > The multipart/mixed definition speaks about "independent parts that > need to be bundled in a particular order", which is probably true, > because although the SDP and the icon are independent, the SDP should > be read first. This simply means that the SDP is the root document -- it's the part that gives context to the other parts. For example: consider the case in which you are putting together an SDP that is requesting the transfer of two files, both with icons. The root document -- the actual SDP -- is what provides the information that relates the icons to the appropriate files. The definition of "multipart/mixed" doesn't provide this necessary correlation property. > While I don't have a strong opinion, I would suggest to leave the > draft with the current indication of multipart/mixed. I _do_ have a strong opinion, and I am really rather certain that multipart/mixed is _inappropriate_ for the usage this draft proposes. I encourage you to seek the guidance of someone better versed in MIME before you make a final decision. I would suggest starting with Eric Burger or Chris Newman . /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 10 15:13: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 1IJZtx-0001BO-Ik; Fri, 10 Aug 2007 15:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZtv-00016I-VM for mmusic@ietf.org; Fri, 10 Aug 2007 15:11:59 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJZtu-00056o-VH for mmusic@ietf.org; Fri, 10 Aug 2007 15:11:59 -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 l7AJBofw052800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 14:11:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46BCB87E.4050201@nostrum.com> Date: Fri, 10 Aug 2007 14:11:58 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related References: <46BC6C2A.9000305@nsn.com> <46BC954D.2000309@cisco.com> In-Reply-To: <46BC954D.2000309@cisco.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-Virus-Scanned: ClamAV 0.91.1/3909/Fri Aug 10 10:10:24 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Miguel Garcia , 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 On 8/10/07 11:41 AM, Paul Kyzivat wrote: > > >> The difference between both is subtle, in my opinion. The >> multipart/related definition says that "proper display cannot be >> achieved by individually displayign the constituent body parts", >> which is not entirely true: SDP will be meaningful in the absence of >> an icon; the icon is also meaningful isolated, although it is not >> linked to any file descriptor. > > I agree that in this case the parts don't seem to be related. But they are -- the SDP contains a CID URI that indicates the related part that corresponds to a specific MSRP m= line. > Is there another multipart subtype that is like mixed except without > ordering? (multipart/unordered?) I've not heard of such a thing. If > not it seems that mixed must be used even when ordering isn't important. You're describing multipart/parallel, which would be appropriate if the parts actually _were_ unrelated and unordered. However, in this case, they *are* related (one part containing a CID indicating another part is sort of the dictionary definition of being related) so multipart/parallel is also inappropriate. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 10 17: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 1IJbh7-00058m-Ao; Fri, 10 Aug 2007 17:06:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJbh6-00058h-Jx for mmusic@ietf.org; Fri, 10 Aug 2007 17:06:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJbh5-0007jH-AI for mmusic@ietf.org; Fri, 10 Aug 2007 17:06:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Aug 2007 14:06:47 -0700 X-IronPort-AV: i="4.19,246,1183359600"; d="scan'208"; a="198113599:sNHT51701580" 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 l7AL6kmN026054; Fri, 10 Aug 2007 14:06:46 -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 l7AL67il021129; Fri, 10 Aug 2007 21:06:46 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); Fri, 10 Aug 2007 17:06:43 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 17:06:43 -0400 Message-ID: <46BCD363.3030308@cisco.com> Date: Fri, 10 Aug 2007 17:06:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach Subject: Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related References: <46BC6C2A.9000305@nsn.com> <46BC954D.2000309@cisco.com> <46BCB87E.4050201@nostrum.com> In-Reply-To: <46BCB87E.4050201@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 21:06:43.0159 (UTC) FILETIME=[5A647670:01C7DB92] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2688; t=1186780006; x=1187644006; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20File=20transfer=20issue=2049=3A=20multipar t/mixed=20or=09multipart/related |Sender:=20; bh=xw52IjR50MrlAeMWUXde9nosLHa9CU8+HFQD+yETd/w=; b=qyndvWcaE5uS1NOQlBD73yIosmH+AsQ3BoVqMR1ZgPDA0IgIhNKdS9lCMbDlaZ5OaP0snz6T 7G9ZpSXkSZ2RmcdbALx6SEx9sp70BW0myQ4XcyLrkkK+PW+Ln+WOn7CI; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Miguel Garcia , 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 Adam, First, I have to say that I know next to nothing about this, so I defer to the experts. I think you now have me convinced re multipart/related for the example at hand. The situation seems cloudier for mixed vs parallel. I googled about multipart/parallel and got a bunch of hits - most of them more than 10 years old. They all seem to be focused on *presentation*. In the case of mixed apparently they are to be presented sequentially, while in the case of parallel they may be presented concurrently. The best example I came across was if there was both a picture and an picture and an audio clip then with parallel they would be played together. In our case much of the stuff is not "presented". I don't know whether or not we should consider the order of *processing* to be equivalent to presentation, of if it matters. Lets consider what is appropriate for some other cases: - An invite request containing an SDP part and a QSIG part. - An invite request containing SDP and a part referenced by a CID URI in an Alert-Info header. - An invite request containing two Alert-Info headers, each with a CID URI. One references a picture, the other references an audio clip. None of these seem to call for multipart/related. The first two can, I think, use either multipart/mixed or multipart/parallel. The last might get different results using mixed and parallel. Thanks, Paul Adam Roach wrote: > On 8/10/07 11:41 AM, Paul Kyzivat wrote: >> >> >>> The difference between both is subtle, in my opinion. The >>> multipart/related definition says that "proper display cannot be >>> achieved by individually displayign the constituent body parts", >>> which is not entirely true: SDP will be meaningful in the absence of >>> an icon; the icon is also meaningful isolated, although it is not >>> linked to any file descriptor. >> >> I agree that in this case the parts don't seem to be related. > > But they are -- the SDP contains a CID URI that indicates the related > part that corresponds to a specific MSRP m= line. > >> Is there another multipart subtype that is like mixed except without >> ordering? (multipart/unordered?) I've not heard of such a thing. If >> not it seems that mixed must be used even when ordering isn't important. > > You're describing multipart/parallel, which would be appropriate if the > parts actually _were_ unrelated and unordered. However, in this case, > they *are* related (one part containing a CID indicating another part is > sort of the dictionary definition of being related) so > multipart/parallel is also inappropriate. > > /a > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 10 18:34: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 1IJd2L-0008U4-3J; Fri, 10 Aug 2007 18:32:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJd2J-0008Tz-L3 for mmusic@ietf.org; Fri, 10 Aug 2007 18:32:51 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJd2J-0000uK-0E for mmusic@ietf.org; Fri, 10 Aug 2007 18:32: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 l7AMWiNw062920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 17:32:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46BCE794.1020301@nostrum.com> Date: Fri, 10 Aug 2007 17:32:52 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Paul Kyzivat Subject: Estoterica regarding multipart MIME (was Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related) References: <46BC6C2A.9000305@nsn.com> <46BC954D.2000309@cisco.com> <46BCB87E.4050201@nostrum.com> <46BCD363.3030308@cisco.com> In-Reply-To: <46BCD363.3030308@cisco.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-Virus-Scanned: ClamAV 0.91.1/3911/Fri Aug 10 15:44:41 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Miguel Garcia , 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 On 8/10/07 4:06 PM, Paul Kyzivat wrote: > The situation seems cloudier for mixed vs parallel. I googled about > multipart/parallel and got a bunch of hits - most of them more than 10 > years old. They all seem to be focused on *presentation*. Well, that makes sense. After all, MIME is "Multipurpose Internet Mail Extensions" -- which means that presentation is pretty important. However, I think the practicalities of how these things ended up implemented in mail agents is fairly irrelevant for their use in SIP -- we don't need to worry about interoperating SIP bodies with mail agents. Consequently, it seems prudent to turn to the formal definitions of the MIME types under discussion... > In the case of mixed apparently they are to be presented sequentially, > while in the case of parallel they may be presented concurrently. The > best example I came across was if there was both a picture and an > picture and an audio clip then with parallel they would be played > together. > > In our case much of the stuff is not "presented". I don't know whether > or not we should consider the order of *processing* to be equivalent > to presentation, of if it matters. For me, the key semantic differences between the types are summarized by the following sets of text (from RFC 2046): The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order. ...and... This document defines a "parallel" subtype of the "multipart" Content-Type. This type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, in a parallel entity, the order of body parts is not significant. In both cases, that's the full definition of the types. The parallel type does go on to discuss the fact that most mail agents won't really be able to render items in an unordered fashion, but this appears to be commentary instead of definition. So, based on these two definitions, it would appear that the sole difference is that mixed is an ordered pile of media, while parallel is an unordered pile of media. > > Lets consider what is appropriate for some other cases: > > - An invite request containing an SDP part and a QSIG part. > - An invite request containing SDP and a part referenced by > a CID URI in an Alert-Info header. > - An invite request containing two Alert-Info headers, each > with a CID URI. One references a picture, the other > references an audio clip. > > None of these seem to call for multipart/related. The first two can, I > think, use either multipart/mixed or multipart/parallel. The last > might get different results using mixed and parallel. I think that, if we were being pedantic, all of these should probably be multipart/parallel to keep in the spirit of what RFC 2046 defines -- ordering seems unimportant for any of these cases. Note that "mixed" does not imply "one at a time" -- it merely implies that order is significant. In practice, I doubt the difference between parallel and mixed makes much difference for anything that we're working on (with the possible exception of instant messaging, which will have nearly identical considerations as email). /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 10 19:08: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 1IJdYj-00033H-2u; Fri, 10 Aug 2007 19:06:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJdYe-0002Xc-TG for mmusic@ietf.org; Fri, 10 Aug 2007 19:06:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJdYe-0000EZ-C4 for mmusic@ietf.org; Fri, 10 Aug 2007 19:06:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Aug 2007 19:06:13 -0400 X-IronPort-AV: i="4.19,246,1183348800"; d="scan'208"; a="67698565:sNHT682924614" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7AN6DJF027886; Fri, 10 Aug 2007 19:06:13 -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 l7AN6Cmd006174; Fri, 10 Aug 2007 23:06:12 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); Fri, 10 Aug 2007 19:06:12 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 19:06:12 -0400 Message-ID: <46BCEF64.7040201@cisco.com> Date: Fri, 10 Aug 2007 19:06:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach Subject: Re: Estoterica regarding multipart MIME (was Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related) References: <46BC6C2A.9000305@nsn.com> <46BC954D.2000309@cisco.com> <46BCB87E.4050201@nostrum.com> <46BCD363.3030308@cisco.com> <46BCE794.1020301@nostrum.com> In-Reply-To: <46BCE794.1020301@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 23:06:12.0453 (UTC) FILETIME=[0B9FE950:01C7DBA3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3977; t=1186787173; x=1187651173; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20Estoterica=20regarding=20multipart=20MIME=20(was=20Re =3A=20[MMUSIC]=20File=20transfer=0A=20issue=2049=3A=20multipart/mixed=20or =20multipart/related) |Sender:=20 |To:=20Adam=20Roach=20; bh=7yHDxVZ74G9ZIQn/hy7jQuATbma1j1nsSq9iWY32qCQ=; b=dhTojJ7FyZEBZ7a0i4WUshzNQJ8i3+FdSz2BbRtd3K/K9+kOjo236K7+8/5JLKsiFaybAvo9 4w7LwXBEw5QxKxi2Wh2lIfzTS1ko8BrqtaEXwaullZ17tCCJ2AdsdjUc; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Miguel Garcia , 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 OK Adam. I can't find anything to argue with in your response. Practically speaking, I suspect that there are more implementations of mixed than parallel out there. If parallel isn't understood, then it is supposed to be processed as mixed, so the mixed implementations out there should deal with it. (Will be interesting to see what actually happens.) I guess the bottom line is what (if anything) we should *recommend* for use in the common cases such as SDP + QSIG. Thanks, Paul Adam Roach wrote: > On 8/10/07 4:06 PM, Paul Kyzivat wrote: >> The situation seems cloudier for mixed vs parallel. I googled about >> multipart/parallel and got a bunch of hits - most of them more than 10 >> years old. They all seem to be focused on *presentation*. > > Well, that makes sense. After all, MIME is "Multipurpose Internet Mail > Extensions" -- which means that presentation is pretty important. > However, I think the practicalities of how these things ended up > implemented in mail agents is fairly irrelevant for their use in SIP -- > we don't need to worry about interoperating SIP bodies with mail agents. > > Consequently, it seems prudent to turn to the formal definitions of the > MIME types under discussion... > >> In the case of mixed apparently they are to be presented sequentially, >> while in the case of parallel they may be presented concurrently. The >> best example I came across was if there was both a picture and an >> picture and an audio clip then with parallel they would be played >> together. >> >> In our case much of the stuff is not "presented". I don't know whether >> or not we should consider the order of *processing* to be equivalent >> to presentation, of if it matters. > > For me, the key semantic differences between the types are summarized by > the following sets of text (from RFC 2046): > > The "mixed" subtype of "multipart" is intended for use when the body > parts are independent and need to be bundled in a particular order. > > > ...and... > > This document defines a "parallel" subtype of the "multipart" > Content-Type. This type is syntactically identical to > "multipart/mixed", but the semantics are different. In particular, > in a parallel entity, the order of body parts is not significant. > > > In both cases, that's the full definition of the types. The parallel > type does go on to discuss the fact that most mail agents won't really > be able to render items in an unordered fashion, but this appears to be > commentary instead of definition. > > So, based on these two definitions, it would appear that the sole > difference is that mixed is an ordered pile of media, while parallel is > an unordered pile of media. > >> >> Lets consider what is appropriate for some other cases: >> >> - An invite request containing an SDP part and a QSIG part. >> - An invite request containing SDP and a part referenced by >> a CID URI in an Alert-Info header. >> - An invite request containing two Alert-Info headers, each >> with a CID URI. One references a picture, the other >> references an audio clip. >> >> None of these seem to call for multipart/related. The first two can, I >> think, use either multipart/mixed or multipart/parallel. The last >> might get different results using mixed and parallel. > > > I think that, if we were being pedantic, all of these should probably be > multipart/parallel to keep in the spirit of what RFC 2046 defines -- > ordering seems unimportant for any of these cases. Note that "mixed" > does not imply "one at a time" -- it merely implies that order is > significant. > > In practice, I doubt the difference between parallel and mixed makes > much difference for anything that we're working on (with the possible > exception of instant messaging, which will have nearly identical > considerations as email). > > /a > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Sat Aug 11 00:55: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 1IJiz9-0004h1-Nd; Sat, 11 Aug 2007 00:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJiz8-0004e0-C9 for mmusic@ietf.org; Sat, 11 Aug 2007 00:53:58 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJiz7-0006ow-SX for mmusic@ietf.org; Sat, 11 Aug 2007 00:53:58 -0400 Received: from localhost.localdomain (ppp-70-242-115-229.dsl.rcsntx.swbell.net [70.242.115.229]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l7B4rpun079153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 23:53:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46BD40D6.5040807@nostrum.com> Date: Fri, 10 Aug 2007 23:53:42 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: Estoterica regarding multipart MIME (was Re: [MMUSIC] File transfer issue 49: multipart/mixed or multipart/related) References: <46BC6C2A.9000305@nsn.com> <46BC954D.2000309@cisco.com> <46BCB87E.4050201@nostrum.com> <46BCD363.3030308@cisco.com> <46BCE794.1020301@nostrum.com> <46BCEF64.7040201@cisco.com> In-Reply-To: <46BCEF64.7040201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.115.229 is authenticated by a trusted mechanism) X-Virus-Scanned: ClamAV 0.91.1/3922/Fri Aug 10 22:00:55 2007 on shaman.nostrum.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Miguel Garcia , 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 Paul Kyzivat wrote: > OK Adam. I can't find anything to argue with in your response. > > Practically speaking, I suspect that there are more implementations of > mixed than parallel out there. If parallel isn't understood, then it > is supposed to be processed as mixed, so the mixed implementations out > there should deal with it. (Will be interesting to see what actually > happens.) > > I guess the bottom line is what (if anything) we should *recommend* > for use in the common cases such as SDP + QSIG. I still contend that the technically correct answer would be multipart/parallel -- however, we did this wrong in RFC 3398 (I'm one of the guilty parties), and I don't think there's any way of getting that particular cat back into this particular bag. Future extensions would do well to use mixed only if ordering is important, and parallel otherwise -- but it can only *hurt* interoperability to try to change what's specified for the stuff that's already published, implemented and deployed. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 13 02:51: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 1IKTjv-0006YB-EU; Mon, 13 Aug 2007 02:49:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKTjt-0006Y6-ES for mmusic@ietf.org; Mon, 13 Aug 2007 02:49:21 -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 1IKTjs-00024E-KH for mmusic@ietf.org; Mon, 13 Aug 2007 02:49:21 -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 l7D6miY3027835; Mon, 13 Aug 2007 09:49:16 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:48:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:48:54 +0300 Received: from [10.144.23.104] ([10.144.23.104]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 09:48:54 +0300 Message-ID: <46BFFED6.2040209@nsn.com> Date: Mon, 13 Aug 2007 09:48:54 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Adam Roach References: <46BC6C2A.9000305@nsn.com> <46BCB66B.4080507@nostrum.com> In-Reply-To: <46BCB66B.4080507@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 06:48:54.0471 (UTC) FILETIME=[03E72D70:01C7DD76] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mmusic Subject: [MMUSIC] Re: File transfer issue 49: multipart/mixed or multipart/related X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org After reading the email thread, I don't have a problem to change the MIME wrapper to multipart/related. I will ask Eric and Chris to confirm our discussion. /Miguel Adam Roach wrote: > Comments inline. > > On 8/10/07 8:46 AM, Miguel Garcia wrote: >> During the last IETF meeting there was a comment with respect the >> relation of SDP bodies and icon bodies. >> >> When the two bodies appear together, the draft says they need to be >> wrapped in a MIME multipart/mixed container. Adam commented that it >> should be multipart/related instead. >> >> RFC 2387 defines the multipart/related MIME wrapper: >> >> The Multipart/Related media type is intended for compound objects >> consisting of several inter-related body parts. For a >> Multipart/Related object, proper display cannot be achieved by >> individually displaying the constituent body parts. >> >> RFC 2046 defines the multipart/mixed MIME wrapper: >> >> The "mixed" subtype of "multipart" is intended for use when the body >> parts are independent and need to be bundled in a particular order. >> Any "multipart" subtypes that an implementation does not recognize >> must be treated as being of subtype "mixed". >> >> >> The difference between both is subtle, in my opinion. The >> multipart/related definition says that "proper display cannot be >> achieved by individually displayign the constituent body parts", which >> is not entirely true: SDP will be meaningful in the absence of an >> icon; the icon is also meaningful isolated, although it is not linked >> to any file descriptor. > > The canonical use case today for mutipart/related in email > communications is a multipart/related document which contains an HTML > document as its root, and dependencies (such as images) as the remaining > parts. Section 5.2 of RFC 2387 provides an example of such a set up. The > key idea in multipart/related is that the root document provides a > semantic context for the remaining parts. (I presume you read enough to > 2387 to understand the "root document" concept, right?) > > In this use case, the HTML will typically be meaningful in the absence > of the images (for example, I use Thunderbird, which automatically > blocks images in HTML mail until you specifically unblock them; for > about 90% of the HTML mail I get, I never bother to load the images, > because the HTML is sufficiently meaningful without them). By the same > token, the images are also as meaningful in isolation as the icons you > discuss above. These properties are not sufficient to counter-indicate > the use of multipart/related, as you imply. > > So, in both of these respects, it appears that the SDP/icon setup you're > describing in the draft is congruent with the examples given in RFC 2387. > >> The multipart/mixed definition speaks about "independent parts that >> need to be bundled in a particular order", which is probably true, >> because although the SDP and the icon are independent, the SDP should >> be read first. > > This simply means that the SDP is the root document -- it's the part > that gives context to the other parts. > > For example: consider the case in which you are putting together an SDP > that is requesting the transfer of two files, both with icons. The root > document -- the actual SDP -- is what provides the information that > relates the icons to the appropriate files. The definition of > "multipart/mixed" doesn't provide this necessary correlation property. > >> While I don't have a strong opinion, I would suggest to leave the >> draft with the current indication of multipart/mixed. > > I _do_ have a strong opinion, and I am really rather certain that > multipart/mixed is _inappropriate_ for the usage this draft proposes. I > encourage you to seek the guidance of someone better versed in MIME > before you make a final decision. I would suggest starting with Eric > Burger or Chris Newman . > > /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 Aug 13 03:59: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 1IKUoT-00011O-4C; Mon, 13 Aug 2007 03:58:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKUoS-00011J-GN for mmusic@ietf.org; Mon, 13 Aug 2007 03:58:08 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKUoR-0003ly-Q2 for mmusic@ietf.org; Mon, 13 Aug 2007 03:58:08 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l7D7w556015541; Mon, 13 Aug 2007 09:58:05 +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 l7D7w2os031905; Mon, 13 Aug 2007 09:58:03 +0200 Received: from nets13ha.ww300.siemens.net ([158.226.250.77]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Aug 2007 09:57:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MMUSIC] Question on Forming Candidate Pairs in ICE-17 Date: Mon, 13 Aug 2007 09:57:37 +0200 Message-ID: <9546CD0F7CC5EE48BCCE583AC4FC864D041D860B@nets13ha.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Question on Forming Candidate Pairs in ICE-17 Thread-Index: Acfdf51YFUYmRRAuRbWlgnWBtok3ig== From: "Zingerle, Meinrad" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 13 Aug 2007 07:57:39.0428 (UTC) FILETIME=[9E91AA40:01C7DD7F] 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::070813095805-46D95BB0-61E5C495/0-0/0-15 X-purgate-size: 4003/999999 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: , Content-Type: multipart/mixed; boundary="===============0917823994==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0917823994== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DD7F.9E542CB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DD7F.9E542CB3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, =20 probably I'm annoying you - but I need to address the topic of pairing a addresses of local scope with addresses global scope once again, this time with the focus on IPv4 addresses.=20 =20 Given the following candidates local remote 10.0.0.8 host 192.168.34.33 host 210.221.23.4 srflx 210.123.44.14 srflx 210.221.25.1 relayed =20 As I've understood ICE-17, we would get the following candidate pairs: 10.0.0.8-192.168.34.33 10.0.0.8-210.123.44.14 210.221.23.4-210.123.44.14 210.221.25.1-192.168.34.33 (**)=20 210.221.25.1-210.123.44.14 My question now is, in what case it makes sense to piar a candidate of a private IP address (192.168.34.33 in this example) with one of a public IP address (210.221.25.1)? In my understanding, the connectivity checks for such pairs will always fail ...=20 Note that RFC3330 states: "192.168.0.0/16 - This block is set aside for use in private networks. Its intended use is documented in [RFC1918]. Addresses within this block should not appear on the public Internet." The same is stated for the block 10.0.0.0/8 =20 Regards, Meinrad ------_=_NextPart_001_01C7DD7F.9E542CB3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,
 
probably I'm annoying you - but I need to address the topic = of pairing=20 a addresses of local scope=20 with addresses global scope = once again,=20 this time with the focus on IPv4 addresses.
 
Given the following=20 candidates
local         =            =20 remote
10.0.0.8=20 host           &nb= sp;=20 192.168.34.33 host
210.221.23.4=20 srflx        210.123.44.14=20 srflx
210.221.25.1 relayed
 
As I've understood ICE-17, we = would get the=20 following candidate pairs:
   =20 10.0.0.8-192.168.34.33
   =20 10.0.0.8-210.123.44.14
210.221.23.4-210.123.44.14
210.221.25.1-192.= 168.34.33=20 (**)
210.221.25.1-210.123.44.14
My question now is, in what case = it makes=20 sense to piar a candidate of a=20 private IP address (192.168.34.33 in this example) with one of a = public=20 IP address (210.221.25.1)? In my=20 understanding, the connectivity checks for such pairs will always = fail=20 ... 

Note that RFC3330 = states:
"192.168.0.0/16 -=20 This block is set aside for use in private networks.
Its intended use = is=20 documented in [RFC1918]. Addresses within this
block should not = appear on the=20 public Internet."
The same is stated for the block = 10.0.0.0/8
 
Regards,
  =20 Meinrad
------_=_NextPart_001_01C7DD7F.9E542CB3-- --===============0917823994== 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 --===============0917823994==-- From mmusic-bounces@ietf.org Mon Aug 13 06:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWxZ-0002of-Px; Mon, 13 Aug 2007 06:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWxX-0002oN-KG for mmusic@ietf.org; Mon, 13 Aug 2007 06:15:39 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKWxX-0008MV-DY for mmusic@ietf.org; Mon, 13 Aug 2007 06:15:39 -0400 Received: by an-out-0708.google.com with SMTP id c17so259230anc for ; Mon, 13 Aug 2007 03:15:39 -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=Xv+4o+X550T945llKdOxvaLMchiEUTlTPrQiTCCKVMgd3/91roCsl5BjAGiQM/8W+S0P8J7yR75SdkN2NpJqzQhNvQZk8iTDo1wFGFqAlHQlgTBVlLdlEFVEffhUikkVuvqQpI6OTov2s5dGeL5EmJpibU2xMqCRofNcCYG/3u4= 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=cIztA0klbGiYPBydG3BbxpX3ep1MU1rx+L4+uEi67/oKvW269nNne/6Y8UqyTsK4Bju0YZGO9D1lBQ8RU3qeF63mqPuNe5xWKT7yaASJWK/iuHWNmEto5tLdntqBvnH3+7G64CH5zZpCCziOn8FfB6b6iBHyGk24wORpQrL7IpY= Received: by 10.100.8.18 with SMTP id 18mr1504876anh.1187000138803; Mon, 13 Aug 2007 03:15:38 -0700 (PDT) Received: by 10.100.190.17 with HTTP; Mon, 13 Aug 2007 03:15:38 -0700 (PDT) Message-ID: <458913680708130315i5b2723clde59c24966b18e87@mail.gmail.com> Date: Mon, 13 Aug 2007 12:15:38 +0200 From: "Xavier Marjou" To: mmusic , "Jonathan Rosenberg" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: f4810eb80be1e8db X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [MMUSIC] ICE and local preference X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I have a minor comment related to the calcultation of local preference in ICE. In order to be consistent between the section 4.1.2.1 of ice-17 and the section 3.2 of ice-tcp-04, I think that ice-tcp-04 should recommend that UDP have an other-pref of 511 if there is a single-interface and a direction-pref of 7. Otherwise, the result given by the local-preference formula of tcp-04 for a UDP candidate may not be 65535, which is the default result in ice-17. Cheers, Xavier _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 13 07:27: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 1IKY3K-0002VJ-68; Mon, 13 Aug 2007 07:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKY3J-0002VC-13 for mmusic@ietf.org; Mon, 13 Aug 2007 07:25:41 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKY3H-000226-6D for mmusic@ietf.org; Mon, 13 Aug 2007 07:25:41 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id l7DBPWop011645; Mon, 13 Aug 2007 13:25:32 +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 l7DBPUaD022602; Mon, 13 Aug 2007 13:25:30 +0200 Received: from nets13ha.ww300.siemens.net ([158.226.250.77]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Aug 2007 13:25:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MMUSIC] Adding a new candidate when ICE running Date: Mon, 13 Aug 2007 13:25:26 +0200 Message-ID: <9546CD0F7CC5EE48BCCE583AC4FC864D041D86C0@nets13ha.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Adding a new candidate when ICE running Thread-Index: AcfdnKW8+zrXQ9UVR52txLh5zdrh3g== From: "Zingerle, Meinrad" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 13 Aug 2007 11:25:28.0392 (UTC) FILETIME=[A6A69480:01C7DD9C] 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::070813132532-46D9FBB0-1075BDDC/0-0/0-15 X-purgate-size: 7669/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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="===============0418263979==" Errors-To: mmusic-bounces@ietf.org This is a multi-part message in MIME format. --===============0418263979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DD9C.A67E2385" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DD9C.A67E2385 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, =20 in my understanding, section 9.1.2.1. and section 9.3.1.4. allow adding new candidates without restarting ICE.=20 =20 9.1.2.1. Existing Media Streams with ICE Running If an agent generates an updated offer including media stream that was previously established, and for which ICE checks are in the Running state, the agent follows the procedures defined here. An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream. The properties of that candidate as signaled in SDP - the priority, foundation, type and related transport address SHOULD remain the same. The IP address, port and transport protocol, which fundamentally identify that candidate, MUST remain the same (if they change, it would be a new candidate). The component ID MUST remain the same. The agent MAY include additional candidates it did not offer previously, but which it has gathered since the last offer/answer exchange, including peer reflexive candidates. =20 9.3.1.4. ICE Continuing for Existing Media Stream The valid list is not affected by an updated offer/answer exchange unless ICE is restarting. If an agent is in the Running state for that media stream, the check list is updated (the check list is irrelevant if the state is completed). To do that, the agent recomputes the check list using the procedures described in Section 5.7. If a pair on the new check list was also on the previous check list, and its state was Waiting, In-Progress, Succeeded or Failed, its state is copied over. Otherwise, its state is set to Frozen. ..... =20 If my understanding is correct, what's the reason behind it?=20 Wouldn't it simplify ICE a little bit, if the ICE draft requests restarting ICE wehn adding a new candidate to an existing media stream for that ICE hasn't completed yet? At least the answerer would not have to recompute the check list and in my opinion requesting an ICE restart when adding a new candidate would make such scenarios more deterministic. =20 Thanks for your patience and regards, Meinrad ------_=_NextPart_001_01C7DD9C.A67E2385 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Jonathan,
 
in my=20 understanding,  section 9.1.2.1. = and=20 section 9.3.1.4. allow=20 adding new candidates without restarting ICE. =
 
    9.1.2.1. Existing Media = Streams with=20 ICE Running
    If an agent generates an updated offer = including media stream that
    was previously = established,=20 and for which ICE checks are in the
    Running state, = the=20 agent follows the procedures defined here.
    An = agent MUST=20 include candidate attributes for all local = candidates
    it=20 had signaled previously for that media stream. The properties=20 of
    that candidate as signaled in SDP - the = priority,=20 foundation, type
    and related transport address = SHOULD=20 remain the same. The IP
    address, port and = transport=20 protocol, which fundamentally identify
    that = candidate,=20 MUST remain the same (if they change, it would be = a
    new=20 candidate). The component ID MUST remain the same. The=20 agent
    MAY include additional candidates it did not = offer=20 previously, but
    which it has gathered since the = last=20 offer/answer exchange, including
    peer reflexive=20 candidates.
 
    9.3.1.4. ICE = Continuing for=20 Existing Media Stream
   =20 The valid list is not affected by an updated offer/answer=20 exchange
    = unless ICE=20 is restarting.
    = If an=20 agent is in the Running state for that media stream, the check
    list is updated = (the check=20 list is irrelevant if the state is
    completed). To do = that, the=20 agent recomputes the check list using
    the procedures = described in=20 Section 5.7. If a pair on the new check
    list was also on = the previous=20 check list, and its state was Waiting,
    In-Progress, = Succeeded or=20 Failed, its state is copied over.
    Otherwise, its = state is set=20 to Frozen.
       =20 .....
 
If my = understanding=20 is correct, what's the reason behind it?
Wouldn't it simplify=20 ICE a little bit, if the ICE draft requests restarting ICE wehn = adding a=20 new candidate to an existing media stream for that ICE hasn't completed=20 yet? At least the answerer would not have to recompute the check = list and=20 in my opinion requesting an ICE restart when adding a new candidate = would make=20 such scenarios more deterministic.
 
Thanks = for your=20 patience and regards,
  = Meinrad
------_=_NextPart_001_01C7DD9C.A67E2385-- --===============0418263979== 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 --===============0418263979==-- From mmusic-bounces@ietf.org Mon Aug 13 07:28: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 1IKY44-0002aC-RZ; Mon, 13 Aug 2007 07:26:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKY43-0002Zx-O1 for mmusic@ietf.org; Mon, 13 Aug 2007 07:26:27 -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 1IKY43-0001jN-8W for mmusic@ietf.org; Mon, 13 Aug 2007 07:26:27 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JMP0065PMFLFT@siemenscomms.co.uk> for mmusic@ietf.org; Mon, 13 Aug 2007 12:26:09 +0100 (BST) Date: Mon, 13 Aug 2007 12:26:25 +0100 From: "Elwell, John" Subject: RE: Estoterica regarding multipart MIME (was Re: [MMUSIC] Filetransfer issue 49: multipart/mixed or multipart/related) In-reply-to: <46BD40D6.5040807@nostrum.com> To: Adam Roach , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026EF48@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: Estoterica regarding multipart MIME (was Re: [MMUSIC] Filetransfer issue 49: multipart/mixed or multipart/related) Thread-Index: Acfb08H+tX/cQLJQR1Gw43vBn/X+qAByPPXQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46BC6C2A.9000305@nsn.com> <46BC954D.2000309@cisco.com> <46BCB87E.4050201@nostrum.com> <46BCD363.3030308@cisco.com> <46BCE794.1020301@nostrum.com> <46BCEF64.7040201@cisco.com> <46BD40D6.5040807@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Garcia, Miguel \(NSN - FI/Espoo\)" , 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 QSIG over SIP implementations I am aware of use multipart/mixed. John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 11 August 2007 05:54 > To: Paul Kyzivat > Cc: Garcia, Miguel (NSN - FI/Espoo); mmusic > Subject: Re: Estoterica regarding multipart MIME (was Re: > [MMUSIC] Filetransfer issue 49: multipart/mixed or multipart/related) > > Paul Kyzivat wrote: > > OK Adam. I can't find anything to argue with in your response. > > > > Practically speaking, I suspect that there are more > implementations of > > mixed than parallel out there. If parallel isn't > understood, then it > > is supposed to be processed as mixed, so the mixed > implementations out > > there should deal with it. (Will be interesting to see what > actually > > happens.) > > > > I guess the bottom line is what (if anything) we should *recommend* > > for use in the common cases such as SDP + QSIG. > I still contend that the technically correct answer would be > multipart/parallel -- however, we did this wrong in RFC 3398 > (I'm one of > the guilty parties), and I don't think there's any way of > getting that > particular cat back into this particular bag. > > Future extensions would do well to use mixed only if ordering is > important, and parallel otherwise -- but it can only *hurt* > interoperability to try to change what's specified for the > stuff that's > already published, implemented and deployed. > > /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 Mon Aug 13 07:59: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 1IKYYP-0006nO-CS; Mon, 13 Aug 2007 07:57:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYYO-0006nE-7l for mmusic@ietf.org; Mon, 13 Aug 2007 07:57:48 -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 1IKYYN-0002Xx-Mw for mmusic@ietf.org; Mon, 13 Aug 2007 07:57:48 -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 l7DBvbMO014283; Mon, 13 Aug 2007 14:57:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:57:41 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:57:41 +0300 Received: from [10.144.23.104] ([10.144.23.104]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 14:57:40 +0300 Message-ID: <46C04734.7080009@nsn.com> Date: Mon, 13 Aug 2007 14:57:40 +0300 From: Miguel Garcia 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: 13 Aug 2007 11:57:40.0853 (UTC) FILETIME=[267CBA50:01C7DDA1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [MMUSIC] File transfer issue 50: Single hash X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org During the IETF meeting in Chicago, Jonathan indicated that the way the draft allows multiple hash algorithms creates an extra unneeded complexity. It would be easier to use a single hash algorithm, such as SHA-1. Background: The hash is used for a double purpose: a) unique file identification b) verification of the correct reception of the file. Bearing in mind the current complexity the endpoints need to deal with, when they support several hashing algorithms, I am ok with the suggestion. So, I recommend to use SHA-1 as the only hashing algorithm. Do people have concerns? /Miguel -- 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 Aug 13 08:17: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 1IKYq4-0007D7-9M; Mon, 13 Aug 2007 08:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYq3-0007D0-EJ for mmusic@ietf.org; Mon, 13 Aug 2007 08:16:03 -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 1IKYq1-00036x-Qr for mmusic@ietf.org; Mon, 13 Aug 2007 08:16:03 -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 l7DCFfEb017897; Mon, 13 Aug 2007 15:15:57 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:15:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:15:46 +0300 Received: from [10.144.23.104] ([10.144.23.104]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:15:46 +0300 Message-ID: <46C04B72.9030308@nsn.com> Date: Mon, 13 Aug 2007 15:15:46 +0300 From: Miguel Garcia 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: 13 Aug 2007 12:15:46.0788 (UTC) FILETIME=[ADC14240:01C7DDA3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [MMUSIC] File transfer Issue 51: transfer identifier X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org In the file transfer draft, the current a=file-transfer attribute is used to indicate to the remote endpoint whether a new file transfer is requested or not. This allows to keep the file description without provoking a new file transfer, if, for example, the SDP is repeated (imagine, due to session timer re-invite). The problem is: in order to keep the existing ongoing file transfer, the SDP creator has to change the SDP and set a=file-transfer to "existing". This is a fragile mechanism: if the application just ships the last SDP without any changes, then it will provoke a restart of the file, due to the presence of a=file-transfer:new. Ideally we would like a mechanism so that, in case the application repeats the SDP, nothing happens, i.e., if the file transfer is still going on, remains. If it is concluded, it is not restarted. Jonathan suggested to use a transfer identifier instead. This looks interesting: When the endpoint repeats the SDP, if a transfer is still taking place, it continues. If it already concluded, nothing happens. If it is a new identifier, it will start at this point. I propose to replace the current file-transfer attribute with a file-transfer-id attribute, according to Jonathan's suggestions. /Miguel -- 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 Aug 13 10:19: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 1IKakE-0003sA-9N; Mon, 13 Aug 2007 10:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKakD-0003s3-CC for mmusic@ietf.org; Mon, 13 Aug 2007 10:18:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKakC-0006Gy-5i for mmusic@ietf.org; Mon, 13 Aug 2007 10:18:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2007 10:18:08 -0400 X-IronPort-AV: i="4.19,255,1183348800"; d="scan'208"; a="128716240:sNHT48187986" 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 l7DEI7If032199; Mon, 13 Aug 2007 10:18:08 -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 l7DEI3jQ001719; Mon, 13 Aug 2007 14:18:10 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:18:06 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:18:06 -0400 Message-ID: <46C0681D.80104@cisco.com> Date: Mon, 13 Aug 2007 10:18:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [MMUSIC] File transfer Issue 51: transfer identifier References: <46C04B72.9030308@nsn.com> In-Reply-To: <46C04B72.9030308@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 14:18:06.0016 (UTC) FILETIME=[C4469400:01C7DDB4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1973; t=1187014688; x=1187878688; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20File=20transfer=20Issue=2051=3A=20transfer =20identifier |Sender:=20 |To:=20Miguel=20Garcia=20; bh=u5JCRVmrvxqv3pbEqLZWZGq7Gp0FySbvssEa7Mqfve4=; b=RB/PwVEqwkrLAULCRqzGlhRxKbdm+qDeCHmADNb5vFQbweeE7wAyQHZ8Jmu7CoUTUaNVWmSt CwC5Xc1km28qaW1iFI5R8RjSJtMdOSMD2PYg4MthutaMcVIPaW40JXMP; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 inline Miguel Garcia wrote: > In the file transfer draft, the current a=file-transfer attribute is > used to indicate to the remote endpoint whether a new file transfer is > requested or not. This allows to keep the file description without > provoking a new file transfer, if, for example, the SDP is repeated > (imagine, due to session timer re-invite). > > The problem is: in order to keep the existing ongoing file transfer, the > SDP creator has to change the SDP and set a=file-transfer to > "existing". This is a fragile mechanism: if the application just ships > the last SDP without any changes, then it will provoke a restart of the > file, due to the presence of a=file-transfer:new. > > Ideally we would like a mechanism so that, in case the application > repeats the SDP, nothing happens, i.e., if the file transfer is still > going on, remains. If it is concluded, it is not restarted. This was a major concern of mine when discussing comedia. I tried very hard to come up with a mechanism that had this property. But in the end I was unsuccessful. What is proposed here is what was used in comedia. I will have to dig back through all the discussion of comedia to discover what the major impediments were to a mechanism with this property. I just don't remember any longer. > Jonathan suggested to use a transfer identifier instead. This looks > interesting: When the endpoint repeats the SDP, if a transfer is still > taking place, it continues. If it already concluded, nothing happens. If > it is a new identifier, it will start at this point. I'm quite sure we investigated mechanisms like this for comedia and found them problematic for some reason. Perhaps Gonzalo remembers - he was the other person involved in that I think. Paul > I propose to replace the current file-transfer attribute with a > file-transfer-id attribute, according to Jonathan's suggestions. > > /Miguel _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 13 14:19: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 1IKeTo-0002nE-Cm; Mon, 13 Aug 2007 14:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeTm-0002cQ-MM; Mon, 13 Aug 2007 14:17:26 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKeTl-0007Y5-FI; Mon, 13 Aug 2007 14:17:26 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IKeTk-0001Xn-5g; Mon, 13 Aug 2007 14:17:25 -0400 Message-ID: <46C0A032.5020901@bbn.com> Date: Mon, 13 Aug 2007 14:17:22 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MMUSIC , SIPPING Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [MMUSIC] Review of draft-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 Draft: draft-saito-mmusic-sdp-ike-01 Reviewer: Richard Barnes Review Date: 13 Aug 07 General Comments: ------------------------------------------------------------------------ 1. This document seems to be doing two things: (1) Using SDP carried in SIP to initiate an IKE session, and (2) Defining how SIP Identity can be used in lieu of IKE authentication. 1.1. With respect to signaling IKE in SIP/SDP: 1.1.1 What is this document trying to get out of SIP/SDP? If it's trying to get redirection to various IP addresses, there's already the DNS for that. If it's trying to do NAT traversal, IKE already has mechanisms for that. (RFC 3497) 1.1.2. SDP attributes defined by this document provide an incomplete definition of the resulting traffic stream. The document doesn't say anything about how IPsec traffic negotiated by this mechanisms should be handled. As Ekr has pointed out, if you're going through NATs you'd probably want to do something like ICE for IPsec or encapsulating IPsec in UDP. Whatever the solution is, even if it's just doing RFC 3947 NAT traversal, this document should say how the negotiated IPsec traffic should be carried. 1.2. With respect to re-using SIP Identity & self-signed certificates: 1.2.1. The security model you're using here is not clear. This document should describe in detail (referring to RFC 4474 and RFC 4306) how the two parties authenticate each other, both at the SIP layer and at the IKE and IPsec layers. 1.2.2. This document does not address how the authenticated identity is connected to IPsec's authorization mechanism, i.e., the PAD. RFC 4301 defines the contents of PAD entries, including specific sets of acceptable identifiers, and acceptable authentication protocols and mechanisms. In order to use SIP identity to identify IPsec peers, you need to define how one constructs and retrieves the relevant PAD entries. 1.2.3. Likewise, the IPsec authorization process uses either the remote IP address or the content of the IKE ID payload as an identifier. So you'll need to fill the authenticated identity into the IKE ID payload, but you'll need to make sure this doesn't cause IKE authentication to fail. 2. The document suggests several times a relationship between the lifetime of the SIP-negotiated session, the lifetime of the IKE exchange, and the lifetime of the IPsec SA. Please clarify this. 3. There's no reason to limit the mechanisms here to tunnel mode (and hence no need to involve VPNs). I think this can be mostly fixed by changing instances of "VPN tunnel" to "IPsec SA". _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 13 20:11: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 1IKjyS-0002Le-P2; Mon, 13 Aug 2007 20:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKjyR-0002L9-37; Mon, 13 Aug 2007 20:09:27 -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 1IKjyQ-0003wa-70; Mon, 13 Aug 2007 20:09:27 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2007 17:09:26 -0700 X-IronPort-AV: i="4.19,257,1183359600"; d="scan'208"; a="513147579:sNHT54203468" 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 l7E09PPx032441; Mon, 13 Aug 2007 17:09:25 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7E09Da1000344; Tue, 14 Aug 2007 00:09:24 GMT From: "Dan Wing" To: "'Richard Barnes'" , "'MMUSIC'" , "'SIPPING'" Date: Mon, 13 Aug 2007 17:09:08 -0700 Message-ID: <03dc01c7de07$5c6dde30$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46C0A032.5020901@bbn.com> Thread-Index: Acfd1kHMgF0t6LQpSai3ldcR2DMBBQALScsA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5068; t=1187050165; x=1187914165; 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[Sipping]=20Review=20of=20draft-saito-mmusic-sdp-ike |Sender:=20; bh=1PYuoGgIfPVDE+/Ei6Pq0+6ZGhPkb2Yad2Pg3n2uZAg=; b=XTLoFmsL9Vtd6kBUMYsnHeyIsUV5ToAdRqstx/NxjGW/X7/imEGRq5woCZeZO48J9JCinw+W lFxr40JWR6JqiEtrXHP5WAZSEL/vc8AAG4XVa49GTf9QSl0tE4tnv6zq; 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: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [MMUSIC] RE: [Sipping] Review of draft-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 > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, August 13, 2007 11:17 AM > To: MMUSIC; SIPPING > Subject: [Sipping] Review of draft-saito-mmusic-sdp-ike > > Draft: draft-saito-mmusic-sdp-ike-01 > Reviewer: Richard Barnes > Review Date: 13 Aug 07 > > > General Comments: > -------------------------------------------------------------- > ---------- > 1. This document seems to be doing two things: (1) Using SDP > carried in SIP to initiate an IKE session, and (2) Defining > how SIP Identity can be used in lieu of IKE authentication. In *conjunction* with IKE authentication. IKE authentication still occurs, even with draft-saito-mmusic-sdp-ike -- very much like comedia-tls (RFC4572) uses TLS for authentication and also conveys the certificate fingerprint in SDP (a=fingerprint). What the draft says is that instead of using certificates for your identity assertion (a meaningful subjectAltName, validation of the CA signature, and checking CRLs), you could instead use SIP-Identity's assertion of identity. > 1.1. With respect to signaling IKE in SIP/SDP: > > 1.1.1 What is this document trying to get out of SIP/SDP? If it's > trying to get redirection to various IP addresses, there's > already the > DNS for that. If it's trying to do NAT traversal, IKE already has > mechanisms for that. (RFC 3497) The advantage of SIP over Dynamic DNS is explained in slide 3 of http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt, namely; * Name resolution to a floating IP address (admittedly, this is also possible with DynDNS, as indicated in the slide). * ability to delegate user authentication (identity) to a 3rd party (rely on SIP-Identity's signature rather than a meaningful subjectAltName). * hole punching. RFC3497 won't work if both endpoints are behind NATs; RFC3497 only works if the IKE initiator is behind a NAT and the IKE 'server' (VPN concentrator, most typically) has a public IP address and its IKE UDP port is not firewalled. * re-use of existing SIP infrastructure, which takes advantage of the above features for VoIP, to deploy a new, non-VoIP service > 1.1.2. SDP attributes defined by this document provide an incomplete > definition of the resulting traffic stream. The document doesn't say > anything about how IPsec traffic negotiated by this > mechanisms should be > handled. As Ekr has pointed out, if you're going through NATs you'd > probably want to do something like ICE for IPsec or > encapsulating IPsec > in UDP. Whatever the solution is, even if it's just doing > RFC 3947 NAT > traversal, this document should say how the negotiated IPsec traffic > should be carried. I agree it should be clearer about what happens after IKE is negotiated, and if we switch to RFC3948 (IPsec-over-UDP) or try to do plain IPsec (protocol 50). > 1.2. With respect to re-using SIP Identity & self-signed certificates: > > 1.2.1. The security model you're using here is not clear. > This document should describe in detail (referring to RFC 4474 > and RFC 4306) how the two parties authenticate each other, both > at the SIP layer and at the IKE and IPsec layers. Thanks. We'll improve that. > 1.2.2. This document does not address how the authenticated > identity is > connected to IPsec's authorization mechanism, i.e., the PAD. > RFC 4301 > defines the contents of PAD entries, including specific sets of > acceptable identifiers, and acceptable authentication protocols and > mechanisms. In order to use SIP identity to identify IPsec > peers, you > need to define how one constructs and retrieves the relevant > PAD entries. draft-saito-mmusic-sdp-ike does not replace or supercede IKE, so I don't understand what needs to be said. Can you provide additional guidance on what you'd like to see here? > 1.2.3. Likewise, the IPsec authorization process uses either > the remote > IP address or the content of the IKE ID payload as an identifier. So > you'll need to fill the authenticated identity into the IKE > ID payload, > but you'll need to make sure this doesn't cause IKE > authentication to fail. IKE still works as-is. > 2. The document suggests several times a relationship between the > lifetime of the SIP-negotiated session, the lifetime of the IKE > exchange, and the lifetime of the IPsec SA. Please clarify this. I only found one such discussion in section 2, Protocol Overview: If the high-level application thinks a VPN session as the media session, it will discard the security policy and terminate IKE when that media session is terminated by BYE request. > 3. There's no reason to limit the mechanisms here to tunnel mode (and > hence no need to involve VPNs). I think this can be mostly fixed by > changing instances of "VPN tunnel" to "IPsec SA". That would be a worthwhile enhancement. Thanks for suggesting it! -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Aug 14 03:16: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 1IKqbU-0002D2-GE; Tue, 14 Aug 2007 03:14:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKqbS-0002AG-Kz for mmusic@ietf.org; Tue, 14 Aug 2007 03:14: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 1IKqbR-00005f-Qe for mmusic@ietf.org; Tue, 14 Aug 2007 03:14: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 l7E7E2c0002289; Tue, 14 Aug 2007 10:14:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 10:14:01 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 10:14:01 +0300 Received: from [10.144.23.155] ([10.144.23.155]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 10:14:01 +0300 Message-ID: <46C15639.6050606@nsn.com> Date: Tue, 14 Aug 2007 10:14:01 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: mmusic Subject: Re: [MMUSIC] Re: File transfer issue 49: multipart/mixed or multipart/related References: <46BC6C2A.9000305@nsn.com> <46BCB66B.4080507@nostrum.com> <46BFFED6.2040209@nsn.com> In-Reply-To: <46BFFED6.2040209@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 07:14:01.0147 (UTC) FILETIME=[B05D70B0:01C7DE42] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I got a reply from Chris indicating that multipart/related makes more sense than multipart/mixed. So I will proceed with the change. /Miguel Miguel Garcia wrote: > After reading the email thread, I don't have a problem to change the > MIME wrapper to multipart/related. I will ask Eric and Chris to confirm > our discussion. > > /Miguel > > Adam Roach wrote: >> Comments inline. >> >> On 8/10/07 8:46 AM, Miguel Garcia wrote: >>> During the last IETF meeting there was a comment with respect the >>> relation of SDP bodies and icon bodies. >>> >>> When the two bodies appear together, the draft says they need to be >>> wrapped in a MIME multipart/mixed container. Adam commented that it >>> should be multipart/related instead. >>> >>> RFC 2387 defines the multipart/related MIME wrapper: >>> >>> The Multipart/Related media type is intended for compound objects >>> consisting of several inter-related body parts. For a >>> Multipart/Related object, proper display cannot be achieved by >>> individually displaying the constituent body parts. >>> >>> RFC 2046 defines the multipart/mixed MIME wrapper: >>> >>> The "mixed" subtype of "multipart" is intended for use when the body >>> parts are independent and need to be bundled in a particular order. >>> Any "multipart" subtypes that an implementation does not recognize >>> must be treated as being of subtype "mixed". >>> >>> >>> The difference between both is subtle, in my opinion. The >>> multipart/related definition says that "proper display cannot be >>> achieved by individually displayign the constituent body parts", >>> which is not entirely true: SDP will be meaningful in the absence of >>> an icon; the icon is also meaningful isolated, although it is not >>> linked to any file descriptor. >> >> The canonical use case today for mutipart/related in email >> communications is a multipart/related document which contains an HTML >> document as its root, and dependencies (such as images) as the >> remaining parts. Section 5.2 of RFC 2387 provides an example of such a >> set up. The key idea in multipart/related is that the root document >> provides a semantic context for the remaining parts. (I presume you >> read enough to 2387 to understand the "root document" concept, right?) >> >> In this use case, the HTML will typically be meaningful in the absence >> of the images (for example, I use Thunderbird, which automatically >> blocks images in HTML mail until you specifically unblock them; for >> about 90% of the HTML mail I get, I never bother to load the images, >> because the HTML is sufficiently meaningful without them). By the same >> token, the images are also as meaningful in isolation as the icons you >> discuss above. These properties are not sufficient to counter-indicate >> the use of multipart/related, as you imply. >> >> So, in both of these respects, it appears that the SDP/icon setup >> you're describing in the draft is congruent with the examples given in >> RFC 2387. >> >>> The multipart/mixed definition speaks about "independent parts that >>> need to be bundled in a particular order", which is probably true, >>> because although the SDP and the icon are independent, the SDP should >>> be read first. >> >> This simply means that the SDP is the root document -- it's the part >> that gives context to the other parts. >> >> For example: consider the case in which you are putting together an >> SDP that is requesting the transfer of two files, both with icons. The >> root document -- the actual SDP -- is what provides the information >> that relates the icons to the appropriate files. The definition of >> "multipart/mixed" doesn't provide this necessary correlation property. >> >>> While I don't have a strong opinion, I would suggest to leave the >>> draft with the current indication of multipart/mixed. >> >> I _do_ have a strong opinion, and I am really rather certain that >> multipart/mixed is _inappropriate_ for the usage this draft proposes. >> I encourage you to seek the guidance of someone better versed in MIME >> before you make a final decision. I would suggest starting with Eric >> Burger or Chris Newman . >> >> /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 Tue Aug 14 09:24: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 1IKwLn-0005Sf-9g; Tue, 14 Aug 2007 09:22:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwLm-0005Sa-G4 for mmusic@ietf.org; Tue, 14 Aug 2007 09:22:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKwLl-00042n-Qm for mmusic@ietf.org; Tue, 14 Aug 2007 09:22:22 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2007 09:22:21 -0400 X-IronPort-AV: i="4.19,259,1183348800"; d="scan'208"; a="67951361:sNHT88182834" 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 l7EDMLTi000639; Tue, 14 Aug 2007 09:22:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7EDMEmj010255; Tue, 14 Aug 2007 13:22:21 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:22:17 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:22:16 -0400 Message-ID: <46C1AC87.7010203@cisco.com> Date: Tue, 14 Aug 2007 09:22:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] File transfer Issue 51: transfer identifier References: <46C04B72.9030308@nsn.com> <46C0681D.80104@cisco.com> In-Reply-To: <46C0681D.80104@cisco.com> Content-Type: multipart/mixed; boundary="------------090902090607040608000607" X-OriginalArrivalTime: 14 Aug 2007 13:22:16.0711 (UTC) FILETIME=[2258F170:01C7DE76] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5397; t=1187097741; x=1187961741; 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:=20Re=3A=20[MMUSIC]=20File=20transfer=20Issue=2051=3A=20transfer =20identifier |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=WYht0x7TXM0NRTr3GO8zRTpmz7amusoYy3Y6A1le/iM=; b=cqggP3YPvDHtqvnoYa9J9ANlBkaJFg8LQFZkExWvxXxnxM0Hbjg/vrQpLn1gjjy9cuArqaLT k4Emt9hD7b6+wNBnPyXjf2P/chZgSaPm4uCrGBhHNmh1aYjHjW9rLkPE; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Miguel Garcia , 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 This is a multi-part message in MIME format. --------------090902090607040608000607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit More info inline. Paul Paul Kyzivat wrote: > inline > > Miguel Garcia wrote: >> In the file transfer draft, the current a=file-transfer attribute is >> used to indicate to the remote endpoint whether a new file transfer is >> requested or not. This allows to keep the file description without >> provoking a new file transfer, if, for example, the SDP is repeated >> (imagine, due to session timer re-invite). >> >> The problem is: in order to keep the existing ongoing file transfer, >> the SDP creator has to change the SDP and set a=file-transfer to >> "existing". This is a fragile mechanism: if the application just ships >> the last SDP without any changes, then it will provoke a restart of >> the file, due to the presence of a=file-transfer:new. >> >> Ideally we would like a mechanism so that, in case the application >> repeats the SDP, nothing happens, i.e., if the file transfer is still >> going on, remains. If it is concluded, it is not restarted. > > This was a major concern of mine when discussing comedia. > I tried very hard to come up with a mechanism that had this property. > But in the end I was unsuccessful. What is proposed here is what was > used in comedia. > > I will have to dig back through all the discussion of comedia to > discover what the major impediments were to a mechanism with this > property. I just don't remember any longer. I went digging in my archives. I came up with two messages on the subject. One is in the official archives: http://www1.ietf.org/mail-archive/web/mmusic/current/msg02686.html The other was private between me and gonzalo. I'm attaching a copy. This one eventually led to what was adopted, but I don't have any more discussion on the topic. >> Jonathan suggested to use a transfer identifier instead. This looks >> interesting: When the endpoint repeats the SDP, if a transfer is still >> taking place, it continues. If it already concluded, nothing happens. >> If it is a new identifier, it will start at this point. > > I'm quite sure we investigated mechanisms like this for comedia and > found them problematic for some reason. Perhaps Gonzalo remembers - he > was the other person involved in that I think. draft-ietf-mmusic-sdp-comedia-08 used an a=connid attribute with a token, which I presume is similar to what Jonathan is suggesting. In any case, as is often the case with o/a issues, 3pcc scenarios broke this mechanism. > Paul > >> I propose to replace the current file-transfer attribute with a >> file-transfer-id attribute, according to Jonathan's suggestions. >> >> /Miguel > --------------090902090607040608000607 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Return-Path: Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO58169; Tue, 3 Aug 2004 12:06:24 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2004 09:07:10 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i73G6MuU011380; Tue, 3 Aug 2004 09:06:22 -0700 (PDT) Received: from cisco.com (sjc-vpn4-435.cisco.com [10.21.81.179]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKO58163; Tue, 3 Aug 2004 12:06:20 -0400 (EDT) Message-ID: <410FB744.3090205@cisco.com> Date: Tue, 03 Aug 2004 12:03:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gonzalo Camarillo Subject: comedia connid Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Gonzalo, I thought about this some more while sleeping. I agree the problem cannot be fixed to achieve the goal I was trying to achieve. In retrospect, there are other cases where it can't be achieved. For instance, there is a similar situation with preconditions, where after one offer/answer cycle, the next offer is dependent on something in the previous answer. So I think the best we can hope for is a weaker condition - that at the end of one offer/answer cycle it is possible to compute what the next offer should be in order to preserve the status quo. Then that only need be changed if change is subsequently required. Having said that, if that is the goal, then I think we can do considerably better than the current proposal for connid - something that is much mor intuitive. I propose we replace connid with: a=connection: new or a=connection: existing This is very similar to the old proposal of a=reconnect, except for one small but significant difference - use in the initial offer. I don't especially like having to weaken the condition for preserving the status quo, but if one acknowledges the need to do so I think this change is an improvement. Paul --------------090902090607040608000607 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 --------------090902090607040608000607-- From mmusic-bounces@ietf.org Tue Aug 14 10:00: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 1IKwvL-0007Ym-Ff; Tue, 14 Aug 2007 09:59:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwvJ-0007XS-FT; Tue, 14 Aug 2007 09:59:05 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKwvI-00058x-VR; Tue, 14 Aug 2007 09:59:05 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IKwvH-0003yS-4v; Tue, 14 Aug 2007 09:59:03 -0400 Received: from col-dhcp33-244-173.bbn.com ([128.33.244.173] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IKwvH-00027V-Ec; Tue, 14 Aug 2007 09:59:03 -0400 Message-ID: <46C1B525.6000507@bbn.com> Date: Tue, 14 Aug 2007 09:59:01 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <03dc01c7de07$5c6dde30$c6f0200a@cisco.com> In-Reply-To: <03dc01c7de07$5c6dde30$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'SIPPING' , 'MMUSIC' Subject: [MMUSIC] Re: [Sipping] Review of draft-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 Dan, A couple of responses inline: > The advantage of SIP over Dynamic DNS is explained in > slide 3 of http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt, > namely; > * ability to delegate user authentication (identity) to a > 3rd party (rely on SIP-Identity's signature rather than > a meaningful subjectAltName). You can already delegate authentication to a CA in IKE. You're just replacing the CA key with the Authentication Service's key. > * hole punching. RFC3497 won't work if both endpoints are behind > NATs; RFC3497 only works if the IKE initiator is behind a NAT > and the IKE 'server' (VPN concentrator, most typically) has a > public IP address and its IKE UDP port is not firewalled. I'm not sure of the utility of this. It's not like IKE uses a whole bunch of different ports like RTP does -- it's always on port 500. If you want to allow IKE, just open port 500. > * re-use of existing SIP infrastructure, which takes advantage > of the above features for VoIP, to deploy a new, non-VoIP service This is irrelevant -- "SIP infrastructure" includes DNS infrastructure (to support REFC 3693 routing), so if you've got SIP infrastructure, you might as well use the DNS. And conversely, not using SIP (just DNS) allows people who only have DNS to do the same redirection. > draft-saito-mmusic-sdp-ike does not replace or supercede IKE, > so I don't understand what needs to be said. Can you provide > additional guidance on what you'd like to see here? Sure. Section 4.4.3 of RFC 4301 defines the authorization mechanism for IPsec -- the Peer Authorization Database, or PAD. The PAD has entries that contain: 1. An identifier or set of identifiers 2. Authentication protocol(s) (e.g. IKE, KINK) 3. Authentication method(s) (either X.509 or PSK) 4. Authentication data (either X.509 trust anchor or the PSK) When an request for a new SA comes in (via IKE), the IPsec endpoint checks (in order) that 1. The authenticated identifier (e.g. X.509 DN) has a PAD entry 2. The authentication parameters in the PAD match what actually happened, e.g., the identifier was authenticated through IKE with a certificate verified by the included trust anchor. With respect to the first check, you need to specify how identifiers are derived from the self-signed certificate (i.e., where the SIP identity needs to be placed) Without more explanation, I'm not sure how you would handle the second check: You're obviously not using a PSK, and there's no trust anchor to verify a self-signed certificate. You may want to look into the work that the BTNS working group is doing. > I only found one such discussion in section 2, Protocol Overview: That paragraph seems to imply that the IPsec (Child) SA should be terminated when the BYE request is accepted, and that any IKE negotiations in process should be terminated. (Note that it's the SA that's discarded, not the policy!) Is this what you meant to say? If so, you need to address two issues: 1. IKE has its own mechanisms for negotiating SA lifetimes, so you'll need to specify how to set IKE parameters to be compatible with this. 2. How should IKE SAs be handled? Should they be terminated on the BYE as well? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Aug 14 12:46: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 1IKzW0-0006rp-He; Tue, 14 Aug 2007 12:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzVx-0006qP-V4; Tue, 14 Aug 2007 12:45:05 -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 1IKzVw-000066-Jn; Tue, 14 Aug 2007 12:45:05 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2007 09:45:04 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="513411351:sNHT53693926" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EGj3RA021480; Tue, 14 Aug 2007 09:45:03 -0700 Received: from dwingwxp01 ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7EGiwa1017837; Tue, 14 Aug 2007 16:45:03 GMT From: "Dan Wing" To: "'Richard Barnes'" Date: Tue, 14 Aug 2007 09:44:58 -0700 Message-ID: <04b801c7de92$7696bc10$c6f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46C1B525.6000507@bbn.com> Thread-Index: Acfee00ljXNSiOG4SciBcs2mjQ5HDwAFZFMQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4821; t=1187109903; x=1187973903; 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[Sipping]=20Review=20of=20draft-saito-mmusic-sdp-ike |Sender:=20; bh=AWh/B/D9YrsFlOAIHQ8YmEvsIXv3W0jVPArRT3non7w=; b=b+L4PFPL1uNbLXmopPMXuhxEJock7VpSPwr6TpZrIryv8w33mlQKOPzSKa+H3f1IR5nnE+Vd tg6IU61yN/qXR0eiH+6Amr2iwt8EtXl/RgjSbuQa1Ao9aZSQpBC+VJjT; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: 'SIPPING' , 'MMUSIC' Subject: [MMUSIC] RE: [Sipping] Review of draft-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 > A couple of responses inline: > > > The advantage of SIP over Dynamic DNS is explained in > > slide 3 of > http://www3.ietf.org/proceedings/07jul/slides/sipping-11.ppt, > > namely; > > > * ability to delegate user authentication (identity) to a > > 3rd party (rely on SIP-Identity's signature rather than > > a meaningful subjectAltName). > > You can already delegate authentication to a CA in IKE. You're just > replacing the CA key with the Authentication Service's key. To delegate authentication to a CA in IKE, you need a certificate whose subjectAltName matches something that makes sense -- such as being the hostname or username or friendly name. This is what we're trying to avoid. > > * hole punching. RFC3497 won't work if both endpoints are behind > > NATs; RFC3497 only works if the IKE initiator is behind a NAT > > and the IKE 'server' (VPN concentrator, most typically) has a > > public IP address and its IKE UDP port is not firewalled. > > I'm not sure of the utility of this. It's not like IKE uses a whole > bunch of different ports like RTP does RTP only needs one port, now-a-days (draft-ietf-avt-rtp-and-rtcp-mux). > -- it's always on port > 500. If you want to allow IKE, just open port 500. IKE doesn't always have to run on 500, it could run on any port you want. And, certainly, if two hosts are behind their own respective NATs and want to establish IKE between themselves (and thereafter IPsec), it is very unlikely either of them will get UDP/500 from their NAT. RFC3974 (section 4) explains that using UDP/500 can, itself, be problematic because IKE-aware NATs try to be overly helpful but instead cause more problem for IKE. To your argument, though, DNS SRV records (in conjunction with dynamic DNS) could also advertise a non-UDP/500 port. However, if you're behind a NAT, and you don't have NAT-PMP or UPnP, it's difficult to keep that port open. Existing SIP techniques (SIP-Outbound) keep SIP signaling active, allowing a SIP- initiated call to the device which can then, for that call, open the pinholes through the necessary NATs. > > * re-use of existing SIP infrastructure, which takes advantage > > of the above features for VoIP, to deploy a new, > non-VoIP service > > This is irrelevant -- "SIP infrastructure" includes DNS > infrastructure > (to support REFC 3693 routing), so if you've got SIP > infrastructure, you > might as well use the DNS. And conversely, not using SIP (just DNS) > allows people who only have DNS to do the same redirection. Dynamic DNS doesn't provide the same functionality. > > draft-saito-mmusic-sdp-ike does not replace or supercede IKE, > > so I don't understand what needs to be said. Can you provide > > additional guidance on what you'd like to see here? > > Sure. Section 4.4.3 of RFC 4301 defines the authorization > mechanism for > IPsec -- the Peer Authorization Database, or PAD. The PAD > has entries > that contain: > 1. An identifier or set of identifiers > 2. Authentication protocol(s) (e.g. IKE, KINK) > 3. Authentication method(s) (either X.509 or PSK) > 4. Authentication data (either X.509 trust anchor or the PSK) > > When an request for a new SA comes in (via IKE), the IPsec endpoint > checks (in order) that > 1. The authenticated identifier (e.g. X.509 DN) has a PAD entry > 2. The authentication parameters in the PAD match what actually > happened, e.g., the identifier was authenticated through IKE with a > certificate verified by the included trust anchor. > > With respect to the first check, you need to specify how > identifiers are > derived from the self-signed certificate (i.e., where the SIP > identity needs to be placed) > > Without more explanation, I'm not sure how you would handle > the second > check: You're obviously not using a PSK, and there's no trust > anchor to > verify a self-signed certificate. You may want to look into the work > that the BTNS working group is doing. Ok, thanks. > > I only found one such discussion in section 2, Protocol Overview: > > That paragraph seems to imply that the IPsec (Child) SA should be > terminated when the BYE request is accepted, and that any IKE > negotiations in process should be terminated. (Note that it's the SA > that's discarded, not the policy!) Is this what you meant to say? > > If so, you need to address two issues: > 1. IKE has its own mechanisms for negotiating SA lifetimes, so you'll > need to specify how to set IKE parameters to be compatible with this. > 2. How should IKE SAs be handled? Should they be terminated > on the BYE as well? Yes, I don't see any reason to keep IKE active after the SIP BYE. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Aug 14 16:12: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 1IL2jM-0006kI-V7; Tue, 14 Aug 2007 16:11:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL2jJ-0006bt-Or; Tue, 14 Aug 2007 16:11:05 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL2jJ-0000HC-C4; Tue, 14 Aug 2007 16:11:05 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IL2jJ-0003sE-3F; Tue, 14 Aug 2007 16:11:05 -0400 Received: from col-dhcp33-244-173.bbn.com ([128.33.244.173] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IL2jI-00042O-Tc; Tue, 14 Aug 2007 16:11:04 -0400 Message-ID: <46C20C57.6050504@bbn.com> Date: Tue, 14 Aug 2007 16:11:03 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <04b801c7de92$7696bc10$c6f0200a@cisco.com> In-Reply-To: <04b801c7de92$7696bc10$c6f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'SIPPING' , 'MMUSIC' Subject: [MMUSIC] Re: [Sipping] Review of draft-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 > To delegate authentication to a CA in IKE, you need a certificate > whose subjectAltName matches something that makes sense -- such > as being the hostname or username or friendly name. This is what > we're trying to avoid. IKE and IPsec don't make any particular demands on the relationship between the certificate and the authenticated identifier, just on what goes in the IKE ID payload. To quote RFC 4301: " This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. " However, you will need to define what identifier gets put in the IKE ID field, since that's the identifier that gets used for IPsec authorization. So if you define which identifiers to use, the certificate can be whatever you want (subject to policy) -- provided that you work out the issues with self-signed certs I mentioned before. > Yes, I don't see any reason to keep IKE active after the SIP BYE. On the other hand, I don't know if you should necessarily throw the IKE SA away after the SIP BYE. There are reasons to keep IKE SAs around for some time, namely that it saves a Diffie-Hellman computation from the next setup (in IKEv2; there are other, different savings in IKEv1). It's reminiscent of credential caching used by other protocols. I guess you need to clarify what the SDP in the SIP transaction is describing: The IKE negotiation, the IKE SA, the IPsec SA, or some combination of the above. If it's just the IKE packets that you're worried about, you could send the BYE after I think 6 IKE packets and let the SAs carry on. If you're worried about the BYE tearing down whatever NAT magic you've done, then you'll need to postpone it until the IPsec SA is done. Perhaps instead of saying "tear down the IPsec stuff when you see a BYE", you should say "don't send a BYE until you're done doing IPsec". --Richard _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Aug 16 08: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 1ILe0F-0004o8-M3; Thu, 16 Aug 2007 07:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILe0E-0004nr-B5; Thu, 16 Aug 2007 07:59:02 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILe0C-0004mG-PJ; Thu, 16 Aug 2007 07:59:02 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1BA1E212C77; Thu, 16 Aug 2007 14:58:59 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D844A212C65; Thu, 16 Aug 2007 14:58:58 +0300 (EEST) Message-ID: <46C43C02.7050808@nomadiclab.com> Date: Thu, 16 Aug 2007 14:58:58 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070604 Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Gen-ART Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: fluffy@cisco.com, mmusic@ietf.org Subject: [MMUSIC] Gen-ART Review of draft-ietf-mmusic-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: , Errors-To: mmusic-bounces@ietf.org I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-ice-17.txt Reviewer: Christian Vogt Review Date: August 16, 2007 IETF LC End Date: August 13, 2007 Summary: This document is of very good quality. It also has a very plausible problem statement and an excellent summary of the ICE operation. I support this document going forward in the publication process. Comments: A few comments still, but they are easy to fix: (1) Section 2.6, 1st paragraph: However, it is possible that packet losses will cause a higher priority check to take longer to complete. In that case, allowing ICE to run a little longer might produce better results. Just to avoid confusion: I would say "a packet loss" rather than "packet losses". A reader might otherwise wonder why running "a little longer might produce better results" if it would mean that a high-packet-loss path gets eventually chosen. (2) Regarding the Security Considerations section: Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate probes could be used for amplified flooding: It is impossible to eliminate the amplification, but the volume can be reduced through a variety of heuristics. [...] A reader might at first glance wonder why the amplification could not be avoided by requiring the initiator to send a separate request per response. E.g., this is done in Mobile IPv6 route optimization where a mobile host sends out two initialization messages that each prompt the peer to send a single response message. It might hence be valuable to note in section 18.5.2 that a "balancing" of the number of request and response messages is not possible in the case of ICE because the initiator does not know the number of responses at the time it sends the request. In ICE, the number of responses depends on both the initiator's and the responder's set of IP addresses. (3) Finally some editorial notes: Section 2.1, 1st paragraph: In all cases, such a network interface appears to the agent as a local interface from which ports (and thus a candidate) can be allocated. s/ports (and thus a candidate)/a port (and thus a candidate)/ ...or plural in both cases. Section 2.1, 2nd paragraph on page 11: I assume "local interface Y" should be "local IP address Y" because only the IP address is relevant for connectivity, not the interface. And an interface may have multiple IP addresses, of course. Kind regards, - Christian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Aug 16 11:18: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 1ILh5Y-00015N-30; Thu, 16 Aug 2007 11:16:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILh5W-000155-2i for mmusic@ietf.org; Thu, 16 Aug 2007 11:16:42 -0400 Received: from hm632-1.locaweb.com.br ([200.234.205.215] helo=hm632.locaweb.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILh5T-0000uu-Uk for mmusic@ietf.org; Thu, 16 Aug 2007 11:16:41 -0400 Received: (qmail 31647 invoked from network); 16 Aug 2007 15:16:34 -0000 Received: from unknown (10.1.10.10) by hm632.locaweb.com.br with QMQP; 16 Aug 2007 15:16:34 -0000 Received: from unknown (HELO ?192.168.0.216?) (guibv@comunip.com.br@201.78.67.56) by hm10.locaweb.com.br with SMTP; 16 Aug 2007 15:16:44 -0000 Message-ID: <46C46A4A.9000107@comunip.com.br> Date: Thu, 16 Aug 2007 12:16:26 -0300 From: Guilherme Balena Versiani Organization: ComunIP User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Vogt Subject: Re: [MMUSIC] Gen-ART Review of draft-ietf-mmusic-ice-17 References: <46C43C02.7050808@nomadiclab.com> In-Reply-To: <46C43C02.7050808@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: fluffy@cisco.com, Gen-ART Mailing List , 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 an addendum (below): Christian Vogt wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > > Document: draft-ietf-mmusic-ice-17.txt > Reviewer: Christian Vogt > Review Date: August 16, 2007 > IETF LC End Date: August 13, 2007 > > > Summary: > > This document is of very good quality. It also has a very plausible > problem statement and an excellent summary of the ICE operation. I > support this document going forward in the publication process. > > > Comments: > > A few comments still, but they are easy to fix: > > (1) Section 2.6, 1st paragraph: > > However, it is possible that packet > losses will cause a higher priority check to take longer to complete. > In that case, allowing ICE to run a little longer might produce > better results. > > Just to avoid confusion: I would say "a packet loss" rather than > "packet losses". A reader might otherwise wonder why running "a > little longer might produce better results" if it would mean that > a high-packet-loss path gets eventually chosen. > > (2) Regarding the Security Considerations section: > > Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate > probes could be used for amplified flooding: > > It is impossible to eliminate the amplification, but the volume can > be reduced through a variety of heuristics. [...] > > A reader might at first glance wonder why the amplification could not be > avoided by requiring the initiator to send a separate request per > response. E.g., this is done in Mobile IPv6 route optimization where a > mobile host sends out two initialization messages that each prompt the > peer to send a single response message. > > It might hence be valuable to note in section 18.5.2 that a "balancing" > of the number of request and response messages is not possible in the > case of ICE because the initiator does not know the number of responses > at the time it sends the request. In ICE, the number of responses > depends on both the initiator's and the responder's set of IP addresses. > > (3) Finally some editorial notes: > > Section 2.1, 1st paragraph: > > In all cases, such > a network interface appears to the agent as a local interface from > which ports (and thus a candidate) can be allocated. > > s/ports (and thus a candidate)/a port (and thus a candidate)/ > ...or plural in both cases. > > Section 2.1, 2nd paragraph on page 11: > > I assume "local interface Y" should be "local IP address Y" because > only the IP address is relevant for connectivity, not the interface. > And an interface may have multiple IP addresses, of course. > > Kind regards, > - Christian > Section 7.1.1.1., 1st paragraph on page 40: "(...) This priority value will be computed identically to how the priority for the local candidate of the pair was computed, except that the type preference is set to the value for peer derived candidate types." Just a little conformance issue: "(...) for peer derived candidate types" would be "(...) for peer reflexive candidate types". Regards, Guilherme Balena Versiani. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Aug 16 11:34: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 1ILhLE-0004f5-Gg; Thu, 16 Aug 2007 11:32:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhLB-0004dr-Vb; Thu, 16 Aug 2007 11:32:54 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILhLB-0002ko-J3; Thu, 16 Aug 2007 11:32:53 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1ILhLA-0002GA-ME; Thu, 16 Aug 2007 10:32:52 -0500 In-Reply-To: <46C0A032.5020901@bbn.com> References: <46C0A032.5020901@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <490014F0-CE4D-4677-90F5-A48866FA6452@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [MMUSIC] Review of draft-saito-mmusic-sdp-ike Date: Thu, 16 Aug 2007 10:32:38 -0500 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: SIPPING , 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 On Aug 13, 2007, at 1:17 PM, Richard Barnes wrote: > Draft: draft-saito-mmusic-sdp-ike-01 > Reviewer: Richard Barnes > Review Date: 13 Aug 07 > > > General Comments: > ---------------------------------------------------------------------- > -- > 1. This document seems to be doing two things: (1) Using SDP > carried in SIP to initiate an IKE session, and (2) Defining how SIP > Identity can be used in lieu of IKE authentication. > I think you're looking at the side-effects, not the central theme. And I'm not sure the draft really brings the central them into clear focus. The question to ask is "Why do people want to use SIP to establish an IPSEC SA"? And the answer, I think, has to do with: 1) SIP's utility as a cross-nat rendezvous mechanism. We currently don't have any other good way for node A, which is behind a NAT, to find and establish communication with node B, which is also behind a NAT. Much of the complexity of SIP, including "ice", "outbound", and "gruu", is involved in solving this problem. This is a very difficult problem to solve, and many communications modalities suffer from it. Having solved it in SIP, we can expect to see attempts to use SIP to bootstrap a solution to all those communication modalities. 2) SIP's extension of the domain namespace to include "user parts", allowing more flexible addressing that includes subaddressing at a given host without burning more IP address space. Of course, one might argue that we'd have a cleaner model if we replaced many of these SIP graft-ons with a transport protocol that handles them transparently and independently from the application. We've started talking about ways to do that in P2PSIP. But for now, SIP is the only hammer we have that appears to succeed in driving this kind of nail. -- Dean _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Aug 16 19:47:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILp21-0003do-Ek; Thu, 16 Aug 2007 19:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILp1z-0003cT-2p; Thu, 16 Aug 2007 19:45:35 -0400 Received: from gura.nttv6.jp ([2001:218:1:1040::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILp1y-0008KW-B0; Thu, 16 Aug 2007 19:45:35 -0400 Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2001:218:1f01:1::26]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 5AA8EBDC08; Fri, 17 Aug 2007 08:45:30 +0900 (JST) Received: from [127.0.0.1] (localhost.nttv6.jp [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id CA6A36D6FB; Fri, 17 Aug 2007 08:45:28 +0900 (JST) Message-ID: <46C4E199.6070101@nttv6.jp> Date: Thu, 16 Aug 2007 19:45:29 -0400 From: Makoto SAITO User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [MMUSIC] Review of draft-saito-mmusic-sdp-ike References: <46C0A032.5020901@bbn.com> <490014F0-CE4D-4677-90F5-A48866FA6452@softarmor.com> In-Reply-To: <490014F0-CE4D-4677-90F5-A48866FA6452@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: SIPPING , 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: , Errors-To: mmusic-bounces@ietf.org Hi Richard and Dean, Thank you for your comments. As Dean pointed, it will be a decisive reason of using SIP that SIP is the most effective way to launch the NAT-T mechanism. I don't see any reasons not to use SIP to establish IPsec in this situation (although the current draft only specifies the NAT-free cases). By the way, I also believe it is a big advantage to delegate authentication to 3rd party (sip proxy) very easily by just riding existing SIP infrastructure and SIP-identity mechanism. I may also have to look closely at BTNS works as Richard said, but I think using finger print of self-signed cert endorsed by SIP-Identity is fairly simple way because your application only keeps the faithful fingerprint for the following IKE authentication. Of course, we need to brush-up the technical details not mentioned in the current draft, so it is very helpful to dig down the details. -- Makoto Saito Dean Willis wrote: > > On Aug 13, 2007, at 1:17 PM, Richard Barnes wrote: > >> Draft: draft-saito-mmusic-sdp-ike-01 >> Reviewer: Richard Barnes >> Review Date: 13 Aug 07 >> >> >> General Comments: >> ------------------------------------------------------------------------ >> 1. This document seems to be doing two things: (1) Using SDP carried >> in SIP to initiate an IKE session, and (2) Defining how SIP Identity >> can be used in lieu of IKE authentication. >> > > I think you're looking at the side-effects, not the central theme. And > I'm not sure the draft really brings the central them into clear focus. > > The question to ask is "Why do people want to use SIP to establish an > IPSEC SA"? > > And the answer, I think, has to do with: > > 1) SIP's utility as a cross-nat rendezvous mechanism. We currently don't > have any other good way for node A, which is behind a NAT, to find and > establish communication with node B, which is also behind a NAT. Much of > the complexity of SIP, including "ice", "outbound", and "gruu", is > involved in solving this problem. This is a very difficult problem to > solve, and many communications modalities suffer from it. Having solved > it in SIP, we can expect to see attempts to use SIP to bootstrap a > solution to all those communication modalities. > > 2) SIP's extension of the domain namespace to include "user parts", > allowing more flexible addressing that includes subaddressing at a given > host without burning more IP address space. > > Of course, one might argue that we'd have a cleaner model if we replaced > many of these SIP graft-ons with a transport protocol that handles them > transparently and independently from the application. We've started > talking about ways to do that in P2PSIP. But for now, SIP is the only > hammer we have that appears to succeed in driving this kind of nail. > > -- > Dean > > > > _______________________________________________ > 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 Aug 17 00:40: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 1ILtbk-0001pz-UR; Fri, 17 Aug 2007 00:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILtbj-0001mo-IC for mmusic@ietf.org; Fri, 17 Aug 2007 00:38:47 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILtbi-0007CC-9a for mmusic@ietf.org; Fri, 17 Aug 2007 00:38:47 -0400 Received: by wx-out-0506.google.com with SMTP id h27so381569wxd for ; Thu, 16 Aug 2007 21:38:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Io+anfpGyFKVPvsG8pGhNSk+q4I6+3uKDT8bNGy2XzzoB7QTHJMsGnpX7cegcUn2xk76p+lWkDDIESpP6uzjyAYqB8ffdJR2Pz9jPHBU5SJsAxcCVfILtOZy7xcG/dQMxnEe4cEmpXsBs2oTmeYFxetmxWzXYz7eWzgdRULY144= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HFlUyU3KNuKwfMq8plkVdXly2SRRqtOJiG0FrF/MsB4PtwroQXtbqhbPADKNTRFhAYPOq5cpWfhHRxoF1gIeFqM9JQekhNGK3V+ikRFuSGdaIPqWrhPIKNq9zvgz+WiVlwhI8T+CUU0Qb8+GeeTnb/5uQZSJFf27g85iXMLRKq8= Received: by 10.90.90.16 with SMTP id n16mr3779346agb.1187325525660; Thu, 16 Aug 2007 21:38:45 -0700 (PDT) Received: by 10.90.49.6 with HTTP; Thu, 16 Aug 2007 21:38:45 -0700 (PDT) Message-ID: Date: Fri, 17 Aug 2007 06:38:45 +0200 From: "Alan Bergmin" To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [MMUSIC] setup:actpass = simultaneous-open? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I have a question concerning RFC4145 (TCP-Based Media Transport in the SDP) Does a setup:actpass SDP attribute mean that the agent has to implement a TCP simultaneous-open behavior? Thanks _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 17 01:53: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 1ILukV-0005VI-2x; Fri, 17 Aug 2007 01:51:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILukT-0005VC-GI for mmusic@ietf.org; Fri, 17 Aug 2007 01:51:53 -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 1ILukS-0003tB-US for mmusic@ietf.org; Fri, 17 Aug 2007 01:51:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7H5pmQL010104; Fri, 17 Aug 2007 08:51:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 08:51:47 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 08:51:47 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 08:51:47 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Alan Bergmin" Subject: Re: [MMUSIC] setup:actpass = simultaneous-open? Date: Fri, 17 Aug 2007 08:51:52 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708170851.52670.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Aug 2007 05:51:47.0136 (UTC) FILETIME=[B2B45C00:01C7E092] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Friday 17 August 2007 07:38:45 ext Alan Bergmin wrote: > I have a question concerning RFC4145 (TCP-Based Media Transport in the SD= P) > > Does a setup:actpass SDP attribute mean that the agent has to > implement a TCP simultaneous-open behavior? No. actpass means that in his grandeur the offerer is willing to abide to=20 whatever the answerer decides as regard the connection direction. The=20 answerer MUST decide on either active or passive (see RFC4145, =A74.1). There is a possibility that the answerer decides to be the "active" side,=20 sends the TCP SYN packet and the SDP answer. The TCP SYN packet might reach= =20 the offerer before the SDP answer; in fact, this is very likely to happen,= =20 because routing a single TCP packet is normally much faster than routing a= =20 SIP response. Therefore, when "actpass" is used, the offerer, MUST have a=20 listening socket ready before it sends the SDP offer. However, it does not need to implement simultaneous-open: if it turns out t= hat=20 the answerer picks "passive", the offerer can close the listening socket, a= nd=20 open a new socket to do an active connection. Simultaneous-open is only needed with ICE-TCP. In fact, it is only legal wh= en=20 ICE-TCP is used. =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 Aug 17 02:02: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 1ILut9-0003H6-1P; Fri, 17 Aug 2007 02:00:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILut7-0003Gm-T8; Fri, 17 Aug 2007 02:00:49 -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 1ILut7-00045P-AV; Fri, 17 Aug 2007 02:00:49 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7H60Tuo024871; Fri, 17 Aug 2007 09:00:47 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:00:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:00:36 +0300 Received: from esdhcp041244.research.nokia.com ([172.21.41.244]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:00:35 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Iliff, Tina" Date: Fri, 17 Aug 2007 09:00:41 +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: <200708170900.41623.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 17 Aug 2007 06:00:35.0835 (UTC) FILETIME=[EDD56CB0:01C7E093] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: [Sipping] SDP offer/answer -- Port 9 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 I think MMUSIC working group is a better place to discuss this. On Thursday 16 August 2007 18:59:39 ext Iliff, Tina wrote: > Hi! I have encountered an application in the "real world" which > provides port 9 in the SDP answer in the 200OK. The SDP m line > indicates RTP/AVP. I recognize that port 9 is acceptable if the SDP m > line indicates BFCP. My question is: Is port 9 acceptable for > RTP/AVP. In other words, should the original offerer send an ACK and > then immediate BYE indicating that it rejected the answer? Or....should > the offerer send an ACK, then send media to port 8? Port 9 is legal for any connection-oriented media transport. You are right= =20 however that it should not be used with RTP/AVP (=3D> UDP =3D> not=20 connection-oriented). Unless the SDP author wants the data really be sent t= o=20 port 9. > FYI. What I am actually seeing is that the answerer indicates port 9 in > the answer but sends a re-INVITE immediately after the ACK; however, the > originator/offerer does not accept the re-INVITE due to it is already in > the process of tearing down the call. > > Has anyone else seen this specific behavior or similar behavior? > > P.S. RFC2327 noted a range of 1024-65535 for RTP ports; however, > RFC4566 does not indicate a specific range. I think it's not the job of the SDP receiver to check the port numbers. If = the=20 sender wants to use port 9, why not afterall? Maybe it wants you to send to= =20 its discard service (makes sense if it's a send-only chatter bot). However, I would assume that in the case you describe, it would not actuall= y=20 work properly if you sent data to port 9 anyway. =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 Aug 17 02:02: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 1ILutZ-0003Uo-D9; Fri, 17 Aug 2007 02:01:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILutX-0003Ui-PC for mmusic@ietf.org; Fri, 17 Aug 2007 02:01:15 -0400 Received: from mailhost1.aepona.com ([194.46.24.5] helo=mailhost2.aepona.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILutX-00046Q-DD for mmusic@ietf.org; Fri, 17 Aug 2007 02:01:15 -0400 Received: from exim by mailhost2.aepona.com with local (Exim 4.52) id 1ILutW-0003Nr-Kr for mmusic@ietf.org; Fri, 17 Aug 2007 07:01:14 +0100 From: Stephen.McVarnock@aepona.com To: mmusic@ietf.org In-Reply-To: <200708170900.41623.remi.denis-courmont@nokia.com> Auto-Submitted: auto-replied Message-Id: Date: Fri, 17 Aug 2007 07:01:14 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [MMUSIC] Out-of-office-reply: [Sip] Re: [Sipping] SDP offer/answer -- Port 9 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 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 will be on leave from Wednesday 8th to Friday the 25th (inclusive). I will be returning to work on Monday the 27th of August. Urgent questions and queries may be directed towards David Monahan (david.monahan@aepona.com). Regards, Steve. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Aug 17 10:53: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 1IM3BI-0001i4-EV; Fri, 17 Aug 2007 10:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3BH-0001hz-Bd for mmusic@ietf.org; Fri, 17 Aug 2007 10:52:07 -0400 Received: from poy.chewa.net ([2002:c2f2:7249::1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3BH-0006CK-0p for mmusic@ietf.org; Fri, 17 Aug 2007 10:52:07 -0400 Received: from auguste.remlab.net (unknown [IPv6:2002:3e4e:969c:0:20d:60ff:fe38:6d16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by poy.chewa.net (Postfix) with ESMTP id 848DE966DD for ; Fri, 17 Aug 2007 16:52:06 +0200 (CEST) From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: VideoLAN project - www.videolan.org To: mmusic@ietf.org Date: Fri, 17 Aug 2007 17:52:07 +0300 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708171752.07419@auguste.remlab.net> X-Spam-Score: -0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [MMUSIC] RTSP timeout 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 Hello, I suppose this has been discussed many times over the past decade, but=20 anyway. One thing I keep wondering, and never came to a satisfactorily safe=20 conclusion is, "who decides" how to refresh an RTSP session, so that it=20 does not timeout. The specs (both 1.0 and current draft of 2.0) say the client can send=20 either a dummy RTSP request with the Session-ID to the server, or send=20 RTCP-RR. Hmm, so the client decides then... But but, what if the server=20 specifies a nul bandwidth for RTCP-RR in the SDP? Is it so that the=20 client MUST use RTSP-level refreshes, or that no timing out is used at=20 all? I have no strong opinions on using either mechanism, but shouldn't=20 RTSP/2.0 mandate one of them specifically (and if RTCP is selected,=20 that the RR bandwidth specification MUST be "compatible"...), as well=20 as a minimum timeout that the server shall apply? Or then mandate=20 ICE-style Binding Indication. Then of course there is the side issue, of proving that the=20 client "owns" the IP address it receives data on - especially when a=20 proxy is used. I guess nobody wants to require congestion control (->=20 DCCP) support usage at this point. Regards, =2D-=20 R=C3=A9mi Denis-Courmont http://www.remlab.net/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 20 07:40: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 1IN5aN-0006dF-Le; Mon, 20 Aug 2007 07:38:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN5aL-0006cu-Qc; Mon, 20 Aug 2007 07:38:17 -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 1IN5aL-0004a9-AO; Mon, 20 Aug 2007 07:38:17 -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 l7KBboZY026318; Mon, 20 Aug 2007 14:38:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 14:37:55 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 14:37:55 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 14:37:54 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: ext Jonathan Rosenberg Date: Mon, 20 Aug 2007 14:37:55 +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: <200708201437.55515.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 Aug 2007 11:37:54.0900 (UTC) FILETIME=[8C7EE940:01C7E31E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] STUN/ICE: Username length inconstency X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 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, It seems there is a minor error in the maximum username length between ICE-= 17=20 and RFC3489bis-09. STUN says USERNAME are at most 127 Unicode code points. There is no way a I= CE=20 user fragment of 1024 bytes could fit in there. I would assume the ICE ufra= g=20 should be limited to (127-1)/2 =3D 63 characters, so that the resulting STU= N=20 username is always within the 127 code points limits, including one code=20 point for the semi-colon. In any case, an ICE implemention that fails to obey this limit would fail t= o=20 interoperate with another instance of itself, which is pretty lame :) Also, it ensures the ICE connectivity check packets size remain within the= =20 minimum IPv4 MTU. I hope, that I either misunderstood something, or that this is a minor enou= gh=20 change that it can still be done this late in the process. =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 Aug 20 17:38: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 1INEvQ-0007eJ-Gz; Mon, 20 Aug 2007 17:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INEvP-0007dx-2B; Mon, 20 Aug 2007 17:36:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INEvN-0001Pj-NC; Mon, 20 Aug 2007 17:36:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2007 14:36:37 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="203392750:sNHT53297955" 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 l7KLabYT008676; Mon, 20 Aug 2007 14:36:37 -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 l7KLaWVp012659; Mon, 20 Aug 2007 21:36:32 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, 20 Aug 2007 14:36:32 -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); Mon, 20 Aug 2007 14:36:31 -0700 Message-ID: <46CA096D.50902@cisco.com> Date: Mon, 20 Aug 2007 17:36:45 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Vogt References: <46C43C02.7050808@nomadiclab.com> In-Reply-To: <46C43C02.7050808@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 21:36:31.0809 (UTC) FILETIME=[2CA44B10:01C7E372] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4613; t=1187645797; x=1188509797; 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=20Gen-ART=20Review=20of=20draft-ietf-mmusic-ice-17 |Sender:=20; bh=f2KMyKTX+KvWnwdX41145cKl3mq/QqOLwqwwhif//Q4=; b=hLPbfqgf8869HKZclnPnQZcf+JMTpj/fmuSn6cqmKahmM7E/mQFh3tC2way6Cx3RSSI6UCH5 yCZz/PeQSPTFJ+IlhoWcwQAjz3ZhXx21FP5zW8CkQ5t7/te7hoOcSLNk; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: fluffy@cisco.com, Gen-ART Mailing List , mmusic@ietf.org Subject: [MMUSIC] Re: Gen-ART Review of draft-ietf-mmusic-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: , Errors-To: mmusic-bounces@ietf.org Thanks for the comments. Responses inline. Christian Vogt wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > > Document: draft-ietf-mmusic-ice-17.txt > Reviewer: Christian Vogt > Review Date: August 16, 2007 > IETF LC End Date: August 13, 2007 > > > Summary: > > This document is of very good quality. It also has a very plausible > problem statement and an excellent summary of the ICE operation. I > support this document going forward in the publication process. > > > Comments: > > A few comments still, but they are easy to fix: > > (1) Section 2.6, 1st paragraph: > > However, it is possible that packet > losses will cause a higher priority check to take longer to complete. > In that case, allowing ICE to run a little longer might produce > better results. > > Just to avoid confusion: I would say "a packet loss" rather than > "packet losses". A reader might otherwise wonder why running "a > little longer might produce better results" if it would mean that > a high-packet-loss path gets eventually chosen. OK. Of course there could be more than one packet loss, and it might still be a better choice... > > (2) Regarding the Security Considerations section: > > Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate > probes could be used for amplified flooding: > > It is impossible to eliminate the amplification, but the volume can > be reduced through a variety of heuristics. [...] > > A reader might at first glance wonder why the amplification could not be > avoided by requiring the initiator to send a separate request per > response. E.g., this is done in Mobile IPv6 route optimization where a > mobile host sends out two initialization messages that each prompt the > peer to send a single response message. The problem is, that receipt of a response would assume connectivity. The whole problem ICE is trying to resolve is that I don't know if I have connectivity. It could be, the reason I got no response, is that this candidate isn't reachable from here. So you cannot pace the checks based on responses. > > It might hence be valuable to note in section 18.5.2 that a "balancing" > of the number of request and response messages is not possible in the > case of ICE because the initiator does not know the number of responses > at the time it sends the request. In ICE, the number of responses > depends on both the initiator's and the responder's set of IP addresses. Right. I added the following paragprah at the end of that section: Frequently, protocols that wish to avoid these kinds of attacks force the initiator to wait for a response prior to sending the next message. However, in the case of ICE, this is not possible. It is not possible to differentiate the following two cases: There was no response because the initiator is being used to launch a DoS attack against an unsuspecting target that will not respond There was no response because the IP address and port is not reachable by the initiator In the second case, another check should be sent at the next opportunity, while in the former case, no further checks should be sent. > > (3) Finally some editorial notes: > > Section 2.1, 1st paragraph: > > In all cases, such > a network interface appears to the agent as a local interface from > which ports (and thus a candidate) can be allocated. > > s/ports (and thus a candidate)/a port (and thus a candidate)/ > ...or plural in both cases. fixed. > > Section 2.1, 2nd paragraph on page 11: > > I assume "local interface Y" should be "local IP address Y" because > only the IP address is relevant for connectivity, not the interface. > And an interface may have multiple IP addresses, of course. Yes, fixed. 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 Aug 20 17:39: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 1INEwF-000868-7t; Mon, 20 Aug 2007 17:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INEwD-00083o-Qu; Mon, 20 Aug 2007 17:37:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INEwC-0001Qc-Iy; Mon, 20 Aug 2007 17:37:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2007 14:37:28 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="203393152:sNHT45721971" 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 l7KLbRXp008644; Mon, 20 Aug 2007 14:37:27 -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 l7KLbRF4006682; Mon, 20 Aug 2007 21:37:27 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, 20 Aug 2007 14:37: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); Mon, 20 Aug 2007 14:37:26 -0700 Message-ID: <46CA09A4.9010805@cisco.com> Date: Mon, 20 Aug 2007 17:37:40 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Guilherme Balena Versiani Subject: Re: [MMUSIC] Gen-ART Review of draft-ietf-mmusic-ice-17 References: <46C43C02.7050808@nomadiclab.com> <46C46A4A.9000107@comunip.com.br> In-Reply-To: <46C46A4A.9000107@comunip.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 21:37:26.0809 (UTC) FILETIME=[4D6CA090:01C7E372] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1044; t=1187645848; x=1188509848; 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]=20Gen-ART=20Review=20of=20draft-ietf-mmusic- ice-17 |Sender:=20; bh=iyt3eTah0VMHmRUMKGUItQnzqsCJ9BhM2HFykQwq0tM=; b=kiWRFY8jcJcMizzQ9WEIuWZeb1QYX3v07YpOzXbUUtF5LRB3XJXZHJc2Rk4gwFXTOBpZx+CR fRILU1GZ11YelBnW12ysx0yuNe8gXRgrv6H2LA2bxFA3DxjLYq/T5ZHd; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: fluffy@cisco.com, Christian Vogt , Gen-ART Mailing List , 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 Fixed. Thanks, Jonathan R. Guilherme Balena Versiani wrote: > Just an addendum (below): > > Section 7.1.1.1., 1st paragraph on page 40: > > "(...) This priority value will be computed identically to how > the priority for the local candidate of the pair was computed, except > that the type preference is set to the value for peer derived > candidate types." > > Just a little conformance issue: "(...) for peer derived candidate > types" would be "(...) for peer reflexive candidate types". > > Regards, > > Guilherme Balena Versiani. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 20 17:50: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 1INF6d-0006wj-NM; Mon, 20 Aug 2007 17:48:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INF6c-0006ql-D1 for mmusic@ietf.org; Mon, 20 Aug 2007 17:48:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INF6b-00051E-Tw for mmusic@ietf.org; Mon, 20 Aug 2007 17:48:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 20 Aug 2007 14:48:13 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="8624618:sNHT23504268" 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 l7KLmDWC004830; Mon, 20 Aug 2007 14:48:13 -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 l7KLmDF4014723; Mon, 20 Aug 2007 21:48:13 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, 20 Aug 2007 14:48:13 -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, 20 Aug 2007 14:48:12 -0700 Message-ID: <46CA0C2B.5000207@cisco.com> Date: Mon, 20 Aug 2007 17:48:27 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Zingerle, Meinrad" Subject: Re: [MMUSIC] Adding a new candidate when ICE running References: <9546CD0F7CC5EE48BCCE583AC4FC864D041D86C0@nets13ha.ww300.siemens.net> In-Reply-To: <9546CD0F7CC5EE48BCCE583AC4FC864D041D86C0@nets13ha.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 21:48:13.0014 (UTC) FILETIME=[CE97AF60:01C7E373] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3044; t=1187646493; x=1188510493; 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]=20Adding=20a=20new=20candidate=20when=20ICE= 20running |Sender:=20; bh=2PEJZO23eHM9uKzilewnXEC0w9NP2TfkBzBcbxKun1o=; b=i91IFmGRyzp55eBOJ4AHEnZsI89IVwPjC/KzgrrfEXAz73LJoBLVe3NRT37ALubpKQ9YWRxC 1cz2/+btLkHOepZSt5vccqw5rn4CxLyM6SmGxrbYXnx1thb6QIZqAIoajTS2XTD2Dj6vQ5O1LV +Gw1uyIN1tS+FQhv6z4tKpgbU=; 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: 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 A restart is a heavy-handed process really. There are cases where an agent doesn't want to wait to finish its gathering before sending the initial offer, in order to speed things up. And so it sends the initial offer and continues gathering and then sends an updated offer, all to make things go faster. If ICE needs to restart on the updated offer, any time savings are eliminated. -Jonathan R. Zingerle, Meinrad wrote: > Hi Jonathan, > > in my understanding, section 9.1.2.1. and section 9.3.1.4. allow adding > new candidates without restarting ICE. > > 9.1.2.1. Existing Media Streams with ICE Running > If an agent generates an updated offer including media stream that > was previously established, and for which ICE checks are in the > Running state, the agent follows the procedures defined here. > An agent MUST include candidate attributes for all local candidates > it had signaled previously for that media stream. The properties of > that candidate as signaled in SDP - the priority, foundation, type > and related transport address SHOULD remain the same. The IP > address, port and transport protocol, which fundamentally identify > that candidate, MUST remain the same (if they change, it would be a > new candidate). The component ID MUST remain the same. The agent > MAY include additional candidates it did not offer previously, but > which it has gathered since the last offer/answer exchange, including > peer reflexive candidates. > > 9.3.1.4. ICE Continuing for Existing Media Stream > The valid list is not affected by an updated offer/answer exchange > unless ICE is restarting. > If an agent is in the Running state for that media stream, the check > list is updated (the check list is irrelevant if the state is > completed). To do that, the agent recomputes the check list using > the procedures described in Section 5.7. If a pair on the new check > list was also on the previous check list, and its state was Waiting, > In-Progress, Succeeded or Failed, its state is copied over. > Otherwise, its state is set to Frozen. > ..... > > If my understanding is correct, what's the reason behind it? > Wouldn't it simplify ICE a little bit, if the ICE draft requests > restarting ICE wehn adding a new candidate to an existing media stream > for that ICE hasn't completed yet? At least the answerer would not have > to recompute the check list and in my opinion requesting an ICE restart > when adding a new candidate would make such scenarios more deterministic. > > Thanks for your patience and regards, > Meinrad -- 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 Aug 20 17:56: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 1INFDO-00057t-F2; Mon, 20 Aug 2007 17:55:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFDN-000558-1q for mmusic@ietf.org; Mon, 20 Aug 2007 17:55:13 -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 1INFDL-0001o7-Mo for mmusic@ietf.org; Mon, 20 Aug 2007 17:55:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2007 14:55:11 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="393276737:sNHT48820208" 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 l7KLtAjr013765; Mon, 20 Aug 2007 14:55:10 -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 l7KLtAiF013578; Mon, 20 Aug 2007 21:55:10 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, 20 Aug 2007 14:55:10 -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); Mon, 20 Aug 2007 14:55:10 -0700 Message-ID: <46CA0DCC.1000203@cisco.com> Date: Mon, 20 Aug 2007 17:55:24 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Zingerle, Meinrad" Subject: Re: [MMUSIC] Question on Forming Candidate Pairs in ICE-17 References: <9546CD0F7CC5EE48BCCE583AC4FC864D041D860B@nets13ha.ww300.siemens.net> In-Reply-To: <9546CD0F7CC5EE48BCCE583AC4FC864D041D860B@nets13ha.ww300.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 21:55:10.0722 (UTC) FILETIME=[C790DE20:01C7E374] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2483; t=1187646910; x=1188510910; 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]=20Question=20on=20Forming=20Candidate=20Pair s=20in=20ICE-17 |Sender:=20; bh=waitr5eIh8Xu7B0Nr4xJMo2kXql5cK51b/Ob9gW41Kk=; b=MXJSckwnKquDKbrWlfW81FGMfR3mkF7eCgEQrY2kfpgBRaeUkHUdYFur5228eR00nhEmllp+ RCcMxgyOrvnOgemMpL6Y73/hq6MBCuJ61+tb6qmDhLoGEfjPGzqKhZT/arjvEh4AgqEts1MT7L lxygWnIbvibpg+tmC82Pkzmhk=; 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: 02ec665d00de228c50c93ed6b5e4fc1a 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. Zingerle, Meinrad wrote: > Hi Jonathan, > > probably I'm annoying you - but I need to address the topic of pairing > a addresses of local scope with addresses global scope once again, this > time with the focus on IPv4 addresses. > > Given the following candidates > local remote > 10.0.0.8 host 192.168.34.33 host > 210.221.23.4 srflx 210.123.44.14 srflx > 210.221.25.1 relayed > > As I've understood ICE-17, we would get the following candidate pairs: > 10.0.0.8-192.168.34.33 > 10.0.0.8-210.123.44.14 > 210.221.23.4-210.123.44.14 > 210.221.25.1-192.168.34.33 (**) > 210.221.25.1-210.123.44.14 > My question now is, in what case it makes sense to piar a candidate of a > private IP address (192.168.34.33 in this example) with one of a public > IP address (210.221.25.1)? In my understanding, the connectivity checks > for such pairs will always fail ... Ahh. Were it so easy as that ;) Never make assumptions. That is the cardinal rule of ICE. And you've made an assumption - that a private IP and public IP are never directly reachable from each other. Turns out this isn't always true. I am aware of real, large scale enterprise IP network deployments that use private and public IP addresses internal to the enterprise, WITHOUT nat between them, and then NAT the entire internal enterprise into a small number of external public IP. In this case, calls between two hosts within the enterprise, would end up working when a check is sent from a private IP to a 'seemingly' public IP from the peer. Its not hard to imagine how something like an acquisition or network expansion could produce a deployment like this over time. > > Note that RFC3330 states: > "192.168.0.0/16 - This block is set aside for use in private networks. > Its intended use is documented in [RFC1918]. Addresses within this > block should not appear on the public Internet." > The same is stated for the block 10.0.0.0/8 Right. But public addresses can be used within private networks, and that is what is happening in this case. -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 Aug 20 17:57: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 1INFEL-0006Yb-87; Mon, 20 Aug 2007 17:56:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFEK-0006Y0-9G for mmusic@ietf.org; Mon, 20 Aug 2007 17:56:12 -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 1INFEJ-0005EO-Qd for mmusic@ietf.org; Mon, 20 Aug 2007 17:56:12 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2007 14:55:55 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="393276958:sNHT44064495572" 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 l7KLttom014571; Mon, 20 Aug 2007 14:55:55 -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 l7KLtjFG020835; Mon, 20 Aug 2007 21:55:55 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, 20 Aug 2007 14:55:46 -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, 20 Aug 2007 14:55:45 -0700 Message-ID: <46CA0DF0.9030000@cisco.com> Date: Mon, 20 Aug 2007 17:56:00 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Guilherme Balena Versiani Subject: Re: [MMUSIC] ICE-17 minor fix References: <46BB254B.6090803@comunip.com.br> In-Reply-To: <46BB254B.6090803@comunip.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 21:55:45.0829 (UTC) FILETIME=[DC7DC550:01C7E374] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1031; t=1187646955; x=1188510955; 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-17=20minor=20fix |Sender:=20; bh=T2yDRW4OBQCAWVX9JeRTPzOluhswSWWPYO/KI9v/xCM=; b=CDgX78m9pCVMcDTT15BNeJnn0isTAufiZwGN9PdMaC2LIh7hmYoIfwXTZv8oAlikOYVXtgLi avQvItvujLHbBWS84Xr6IXsLDrRBzgfoXS9FSXvugOBMWmyM2VzA4b+jfDOb7cw/7XynFH1xrF 3wHLlwdu6uAqYn5ZQagU7+bWY=; 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 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 Yes, fixed per your other note. THis is leftover terminology from an older revision. -Jonathan R. Guilherme Balena Versiani wrote: > Section 7.1.1.1. "PRIORITY and USE-CANDIDATE", first paragraph: > > (...) This priority value will be computed identically to how > the priority for the local candidate of the pair was computed, except > that the type preference is set to the value for peer derived > candidate types. > > > The term "peer derived" should be "peer reflexive", isn't it? > > Regards, > > Guilherme Balena Versiani. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Aug 20 18:18: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 1INFY9-0002j8-Qw; Mon, 20 Aug 2007 18:16:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INFY6-0002gN-Ko; Mon, 20 Aug 2007 18:16:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INFY5-0002E2-Ab; Mon, 20 Aug 2007 18:16:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2007 15:16:26 -0700 X-IronPort-AV: i="4.19,286,1183359600"; d="scan'208"; a="203412041:sNHT1657807002" 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 l7KMGQwm026695; Mon, 20 Aug 2007 15:16:26 -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 l7KMGQF4006559; Mon, 20 Aug 2007 22:16:26 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, 20 Aug 2007 15:16: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); Mon, 20 Aug 2007 15:16:25 -0700 Message-ID: <46CA12C7.6020302@cisco.com> Date: Mon, 20 Aug 2007 18:16:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <200708201437.55515.remi.denis-courmont@nokia.com> In-Reply-To: <200708201437.55515.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Aug 2007 22:16:25.0965 (UTC) FILETIME=[BFAB81D0:01C7E377] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1585; t=1187648186; x=1188512186; 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=20STUN/ICE=3A=20Username=20length=20inconstency |Sender:=20; bh=ZAJdL4EqF8pIUENOk4XApHAqBvVrntu8kBSNh6nzkH4=; b=lZ2awQTAPFzfiPcu5+yLwW6YgLRpvyCreROf69r3CHy713AdQWyfo1ezXYtbvHCl1YyODn5f U9K0WdviUomphzLFSsQmLqDq6x8Z7AeEkgiRPcotypVia0VxnqnanyDJ; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: STUN/ICE: Username length inconstency X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 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 good catch. I recently introduced the limit in STUN based on last call comments, forgetting that we had ICE use cases that could result in values longer than 127. I had picked 127 thinking about human readable usernames. My bad. I think the limit in STUN should be increased to match ICE, not the other way around. -Jonathan R. Rémi Denis-Courmont wrote: > Hello, > > It seems there is a minor error in the maximum username length between ICE-17 > and RFC3489bis-09. > > STUN says USERNAME are at most 127 Unicode code points. There is no way a ICE > user fragment of 1024 bytes could fit in there. I would assume the ICE ufrag > should be limited to (127-1)/2 = 63 characters, so that the resulting STUN > username is always within the 127 code points limits, including one code > point for the semi-colon. > > In any case, an ICE implemention that fails to obey this limit would fail to > interoperate with another instance of itself, which is pretty lame :) > Also, it ensures the ICE connectivity check packets size remain within the > minimum IPv4 MTU. > > I hope, that I either misunderstood something, or that this is a minor enough > change that it can still be done this late in the process. > -- 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 Aug 21 01: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 1INMcz-0001it-Le; Tue, 21 Aug 2007 01:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMcx-0001hM-Ia; Tue, 21 Aug 2007 01:50:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INMcw-0004az-0S; Tue, 21 Aug 2007 01:50:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2B98B212D27; Tue, 21 Aug 2007 08:50:04 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E47E4212D26; Tue, 21 Aug 2007 08:50:03 +0300 (EEST) Message-ID: <46CA7D0B.2010001@nomadiclab.com> Date: Tue, 21 Aug 2007 08:50:03 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070604 Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Jonathan Rosenberg References: <46C43C02.7050808@nomadiclab.com> <46CA096D.50902@cisco.com> In-Reply-To: <46CA096D.50902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: fluffy@cisco.com, Gen-ART Mailing List , mmusic@ietf.org Subject: [MMUSIC] Re: Gen-ART Review of draft-ietf-mmusic-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: , Errors-To: mmusic-bounces@ietf.org Jonathan, two small comments. >> (1) Section 2.6, 1st paragraph: >> >> However, it is possible that packet >> losses will cause a higher priority check to take longer to complete. >> In that case, allowing ICE to run a little longer might produce >> better results. >> >> Just to avoid confusion: I would say "a packet loss" rather than >> "packet losses". A reader might otherwise wonder why running "a >> little longer might produce better results" if it would mean that >> a high-packet-loss path gets eventually chosen. > > OK. Of course there could be more than one packet loss, and it might > still be a better choice... Sure. I was thinking that the text in the draft sounds a bit like /persistent/ packet loss. That was my impression. Maybe you just reformulate it to this: [...] However, it is possible that a higher- priority check takes longer to complete due to packet loss. [...] >> Section 18.5.2, "STUN Amplification Attack", explains that ICE candidate >> probes could be used for amplified flooding: >> >> It is impossible to eliminate the amplification, but the volume can >> be reduced through a variety of heuristics. [...] >> >> A reader might at first glance wonder why the amplification could not be >> avoided by requiring the initiator to send a separate request per >> response. E.g., this is done in Mobile IPv6 route optimization where a >> mobile host sends out two initialization messages that each prompt the >> peer to send a single response message. > > The problem is, that receipt of a response would assume connectivity. > The whole problem ICE is trying to resolve is that I don't know if I > have connectivity. It could be, the reason I got no response, is that > this candidate isn't reachable from here. So you cannot pace the checks > based on responses. What I was thinking of was not that the initiator should wait for request n+1 until it has received response n. Rather, the initiator could be required to send N separate requests if it has N candidates, i.e., one request per candidate. That would preclude amplification if and only if we have (at most) one response per candidate. But in the case of ICE, we typically have more than one response per candidate given that there is one response per local/remote-candidate pair. So sending a separate request for each candidate does not mitigate the amplification threat. - Christian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Aug 21 02:29: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 1INNCv-0005ui-8X; Tue, 21 Aug 2007 02:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNCo-0005uJ-Sw; Tue, 21 Aug 2007 02:27:11 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INNCn-0005EI-Dl; Tue, 21 Aug 2007 02:27:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7L6QgBU019706; Tue, 21 Aug 2007 09:27:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:26:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:26:42 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:26:42 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Jonathan Rosenberg" Date: Tue, 21 Aug 2007 09:26:44 +0300 User-Agent: KMail/1.9.6 References: <200708201437.55515.remi.denis-courmont@nokia.com> <46CA12C7.6020302@cisco.com> In-Reply-To: <46CA12C7.6020302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708210926.45072.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 21 Aug 2007 06:26:42.0065 (UTC) FILETIME=[3D082810:01C7E3BC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: behave@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Re: STUN/ICE: Username length inconstency X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org On Tuesday 21 August 2007 01:16:39 ext Jonathan Rosenberg wrote: > This is a good catch. I recently introduced the limit in STUN based on > last call comments, forgetting that we had ICE use cases that could > result in values longer than 127. I had picked 127 thinking about human > readable usernames. My bad. I think the limit in STUN should be > increased to match ICE, not the other way around. Hmm, I am not sure 1023 character long username are that great really. For = a=20 start, after concatenation (2047 characters), you'll get connectivity check= s=20 that exceed the typical Internet MTU. That brings either problem: =2D NATs will not handle fragmented packets, or =2D ICE implementation will refuse to send at all (packet too big). Second, I wonder if if makes sense to have a higher entropy for the usernam= e=20 (12,000 bits here!) than we have for the message integrity (160 bits=20 currently) or the shared secret password. But that's something for security= =20 gurus to judge. Even if we switched to SHA512, we'd still have more than=20 enough username entropy with just 63 characters from each sides (756 bits). Third, we do not want to drain the entropy pool of ICE-capable device too=20 badly. There are better stuff to dedicate entropy to that ICE connectivity= =20 checks, such as generating TLS parameters. =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 Aug 21 10:36: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 1INUoJ-00025v-0N; Tue, 21 Aug 2007 10:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUoE-00023d-7C; Tue, 21 Aug 2007 10:34:18 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INUoD-0003gt-VH; Tue, 21 Aug 2007 10:34:18 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8A01A26E7A; Tue, 21 Aug 2007 14:34:17 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INUoD-0005zW-CW; Tue, 21 Aug 2007 10:34:17 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 21 Aug 2007 10:34:17 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mmusic chair , Internet Architecture Board , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'Security Preconditions for Session Description Protocol (SDP) Media Streams' to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 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 IESG has approved the following document: - 'Security Preconditions for Session Description Protocol (SDP) Media Streams ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-securityprecondition-04.txt Technical Summary This document defines a new security precondition for the Session Description Protocol precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security has been negotiated successfully. Working Group Summary This is a typical application of the SIP/SDP preconditions framework. There was no controversy surrounding the work, and it is needed by a range of SIP users. Protocol Quality This document was reviewed for the IESG by David Black (GEN-ART) and Jon Peterson. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Aug 23 10:33: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 1IODjE-0001nD-L0; Thu, 23 Aug 2007 10:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODjD-0001ms-5t; Thu, 23 Aug 2007 10:32:07 -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 1IODjB-0007S0-G9; Thu, 23 Aug 2007 10:32:07 -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 l7NEVPh7022008; Thu, 23 Aug 2007 17:32:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 17:31:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 17:31:31 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 17:31:31 +0300 Received: from [172.21.37.28] (esdhcp03728.research.nokia.com [172.21.37.28]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7NEVUTr025697; Thu, 23 Aug 2007 17:31:30 +0300 In-Reply-To: <96AB315B-327A-49AF-83CA-A4012F6A5153@csperkins.org> References: <96AB315B-327A-49AF-83CA-A4012F6A5153@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4FA00E40-69A3-4B92-A5DA-04E83054D771@nokia.com> From: Lars Eggert Date: Thu, 23 Aug 2007 17:31:12 +0300 To: ext Colin Perkins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Aug 2007 14:31:31.0556 (UTC) FILETIME=[4C8BBA40:01C7E592] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Godred Fairhurst , 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: , Content-Type: multipart/mixed; boundary="===============1510282858==" Errors-To: mmusic-bounces@ietf.org --===============1510282858== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-62--881124343; protocol="application/pkcs7-signature" --Apple-Mail-62--881124343 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-23, at 19:20, ext Colin Perkins wrote: > On 9 Jul 2007, at 04:50, Internet-Drafts@ietf.org wrote: >> 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? We discussed this in the hallways in Chicago, and I've become grudgingly convinced that for specialized uses of UDP, where communication disruptions due to disappearing middlebox state are highly problematic (e.g., media transmission), 15-second timeouts are probably needed. But I did want to make it clear that such timeouts - or even the use of keepalives in general - are not recommended for arbitrary UDP applications. Below is the modified Section 3.5 from my working copy of -03 FYI. Please let me know what you think of the changes. Lars 3.5. Middlebox Traversal Guidelines Network address translators (NATs) and firewalls are examples of intermediary devices ("middleboxes") that can exist along an end-to- end path. A middlebox typically performs a function that requires it to maintain per-flow state. For connection-oriented protocols, such as TCP, middleboxes snoop and parse the connection-management traffic and create and destroy per-flow state accordingly. For a connectionless protocol such as UDP, this approach is not possible. Consequently, middleboxes may create per-flow state when they see a packet that indicates a new flow, and destroy the state after some period of time during which no packets belonging to the same flow have arrived. Depending on the specific function that the middlebox performs, this behavior can introduce a time-dependency that restricts the kinds of UDP traffic exchanges that will be successful across the middlebox. For example, NATs and firewalls typically define the partial path on one side of them to be interior to the domain they serve, whereas the partial path on their other side is defined to be exterior to that domain. Per-flow state is typically created when the first packet crosses from the interior to the exterior, and while the state is present, NATs and firewalls will forward return traffic. Return traffic arriving after the per-flow state has timed out is dropped, as is other traffic arriving from the exterior. Many applications that use UDP for communication operate across middleboxes without needing to employ additional mechanisms. One example is the DNS, which has a strict request-response communication pattern that typically completes within seconds. Other applications may experience communication failures when middleboxes destroy the per-flow state associated with an application session during periods when the application does not exchange any UDP traffic. Applications SHOULD be able to gracefully handle such communication failures and implement mechanisms to re-establish their UDP sessions. For some applications, such as media transmissions, this re- synchronization is highly undesirable, because it can cause user- perceivable playback artifacts. Such specialized applications MAY send periodic keep-alive messages to attempt to refresh middlebox state. It is important to note that keep-alive messages are NOT RECOMMENDED for general use - they are unnecessary for many applications and can consume significant amounts of system and network resources. An application that needs to employ keep-alives to deliver useful service in the presence of middleboxes SHOULD NOT transmit them more frequently than once every 15 seconds and SHOULD strongly consider using longer intervals. 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. However, empirical evidence suggests that a significant fraction of the deployed middleboxes unfortunately uses shorter timeouts. The timeout of 15 seconds originates with the Interactive Connectivity Establishment (ICE) protocol [I-D.ietf-mmusic-ice]. It is important to note that sending keep-alives is not a substitute for implementing a robust connection handling. Like all UDP messages, keep-alives can be delayed or dropped, causing middlebox state to time out. In addition, the congestion control guidelines in Section 3.1 cover all UDP transmissions by an application, including the transmission of middlebox keep-alives. Congestion control may thus lead to delays or temporary suspension of keep-alive transmission. --Apple-Mail-62--881124343 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA4MjMxNDMxMTNaMCMGCSqGSIb3DQEJBDEWBBT7/qfHrfhFzKxa kOXJcOwCecnzYTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAnODXe251Us4UM4Z31VkrCDmiH9SXaG/SQHnVg4eImoxItpdm2Dmb M0RqJsj72YDmnc0t8MTVYAOl29xXOOGkaJuPK8u2L4SXktJmiv8DT4sHvANEe3Krz+AkwnXCOlyv cqP4psS7znKJFLb+q0vWd+Pjyg++irDmlcrmvw9JYiwTbVOqj0mUWVKq/BARdQMsEYNd/PRFs9QB KCeDuYN7ayT5UCko6zOgdjCnHEZcVq+0l3kPh55ppxu5+mutgWxycYlmvaNkwubuIGqreOkdCrqc 6tvgzjNfZmRv/xFi8ZzKE6hi/Z5IKnjJKUCmW28/meS7JxlXyUqUleqTTw3fGAAAAAAAAA== --Apple-Mail-62--881124343-- --===============1510282858== 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 --===============1510282858==-- From mmusic-bounces@ietf.org Thu Aug 23 10:47: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 1IODw9-0003rt-Bl; Thu, 23 Aug 2007 10:45:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODw7-0003ro-N6 for mmusic@ietf.org; Thu, 23 Aug 2007 10:45:28 -0400 Received: from eracle.polito.it ([130.192.3.44] helo=polito.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IODw7-0008R3-C1 for mmusic@ietf.org; Thu, 23 Aug 2007 10:45:27 -0400 X-ExtScanner: Niversoft's FindAttachments (free) Received: from [151.42.232.3] (account d016068@polito.it HELO Parsifal.local) by eracle.polito.it (CommuniGate Pro SMTP 5.1.10) with ESMTPSA id 8705873 for mmusic@ietf.org; Thu, 23 Aug 2007 16:45:25 +0200 Message-ID: <46CD9D83.6090305@polito.it> Date: Thu, 23 Aug 2007 16:45:23 +0200 From: Livio Torrero Organization: politecncio User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: MMUSIC Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [MMUSIC] Looking for UAs supporting ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: livio.torrero@polito.it List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mmusic-bounces@ietf.org I'm currently investigating NAT traversal techniques for SIP User Agents and I've read all the ICE-related drafts. I'm very interested in it and I would like to try a UA supporting ICE. Could you please suggest me if and where I can download a free UA supporting ICE? If it is not possible, can you please suggest me commercial UAs supporting it? I've just tried Counterpath X-lite but it seems to me that the ICE version included is out of date. Is there any chance to have an UA supporting a more recent version? Best regards, Livio Torrero _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Aug 29 08:34: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 1IQMiX-0001mm-AE; Wed, 29 Aug 2007 08:32:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQMiW-0001m0-0m for mmusic@ietf.org; Wed, 29 Aug 2007 08:32:16 -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 1IQMiU-0007bE-Ik for mmusic@ietf.org; Wed, 29 Aug 2007 08:32:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MMUSIC] SDP CAP Neg example using it for media capabilities Date: Wed, 29 Aug 2007 15:33:36 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C04DE7C28@IsrExch01.israel.polycom.com> In-Reply-To: <46B33141.9070200@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP CAP Neg example using it for media capabilities Thread-Index: AcfV1NipDmn6v7kST92zxELn66FIFAUY7rSg From: "Even, Roni" To: "Magnus Westerlund" , "mmusic (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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="===============0667275011==" Errors-To: mmusic-bounces@ietf.org --===============0667275011== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFnbnVzLA0KSSBzZWUgdGhhdCB5b3UgY291bGQgbm90IHNwZWNpZnkgdGhlIGJhbmR3aWR0aCBz aW5jZSB0aGUgYWNhcCBhZGRyZXNzZXMgb25seSBhPSBhdHRyaWJ1dGUgYW5kIG5vdCB0aGUgYj0N CkFzIGZvciB0aGUgLW0geW91IGNvdWxkIGhhdmUgdXNlZCBtb3JlIHBheWxvYWQgdHlwZXMgaW5z dGVhZCBvZiBvdmVybG9hZGluZyB0aGUgSDI2NCB3aXRoIHJ0eCBwYXlsb2FkIHR5cGUNCg0KUm9u aQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rl cmx1bmQgW21haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IEZy aWRheSwgQXVndXN0IDAzLCAyMDA3IDQ6NDUgUE0NCj4gVG86IG1tdXNpYyAoRS1tYWlsKQ0KPiBT dWJqZWN0OiBbTU1VU0lDXSBTRFAgQ0FQIE5lZyBleGFtcGxlIHVzaW5nIGl0IGZvciBtZWRpYSBj YXBhYmlsaXRpZXMNCj4gDQo+IEhpLA0KPiANCj4gVGhlIGJlbG93IFNEUCBleGFtcGxlIGlzIHVz aW5nIHRoZSBjb3JlIG9mIHRoZSBTRFAgY2FwYWJpbGl0eQ0KPiBuZWdvdGlhdGlvbiwgb3IgYXQg bGVhc3QgYXR0ZW1wdHMgdG8sIHRvIHBlcmZvcm0gc29tZSBtZWRpYSBjYXBhYmlsaXR5DQo+IG5l Z290aWF0aW9uLiBJdCBpcyBidWlsdCBvbiB0aGUgMTBrIFNEUCBleGFtcGxlIGJ1dCBoZXJlIHRy aW1tZWQgZG93biB0bw0KPiBqdXN0IGEgc2ltcGxlIHZpZGVvIGFuZCBhdWRpbyBzdHJlYW0uIEkg dXNlIHR3byBkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMNCj4gdG8gaW5kaWNhdGUgZGlmZmVyZW50 IG1lZGlhIHdvcmsgcG9pbnRzLiBJbiB0aGUgY2FzZSBvZiB0aGUgdmlkZW8gaXQgaXMNCj4gYm90 aCBILjI2NCBidXQgaGVyZSBmb3IgdHdvIGRpZmZlcmVudCBiaXQtcmF0ZSB3b3JrIHBvaW50cyBs aWtlIGEgMTANCj4gbWJpdC9zIGFuZCBhIDUxMiBrYml0L3MgY2FzZS4gRm9yIGV4YW1wbGUgInN0 cmVhbWluZyBxdWFsaXR5IiBhbmQgSEQNCj4gcXVhbGl0eS4gSSBkbyBhIHNpbWlsYXIgdGhpbmcg b24gdGhlIGF1ZGlvIHdoZXJlIGl0IGlzIGVpdGhlciBBTVItV0IoKykNCj4gb3IgQUMzIChkb2xi eSBkaWdpdGFsIDUuMSBjaGFubmVscykuIEFzIHRoaXMgaXMgb2ZmZXIgYW5zd2VyIGFuZCBJIGRv bid0DQo+IGtub3cgYWJvdXQgdGhlIFJUUCBwYXlsb2FkIGRlcGFja2V0aXplciBjYXBhYmlsaXRl cyBpdCBpbmNsdWRlcyBzZXZlcmFsDQo+IHBhY2tldGl6YXRpb24gbW9kZXMgdG8gZW5zdXJlIHRo YXQgaXQgd29ya3MuIEluIHRoZSB2aWRlbyBjYXNlIEkgYWxzbw0KPiBoYXZlIHJldHJhbnNtaXNz aW9uIHN1cHBvcnQgaW4gY2FzZSBBVlBGIG9yIFNBVlBGIGlzIHN1cHBvcnRlZC4NCj4gT3RoZXJ3 aXNlIHRoZXNlIGFuZCAzIG9mIHRoZSBBdWRpbyBwYXlsb2FkIHR5cGUgbnVtYmVycyBuZWVlZHMg dG8gYmUNCj4gZHVtbWllZCBkdWUgdG8gZGlmZmVyZW50IG51bWJlciBvZiBwYXlsb2FkIGZvcm1h dHMgaW4gZGlmZmVyZW50DQo+IGNvbmZpZ3VyYXRpb24uDQo+IA0KPiBBcyBjYW4gYmUgc2VlIHRo ZSBiYW5kd2lkdGggdmFsdWVzIGFyZSBub3QgcG9zc2libGUgdG8gZXhwcmVzcyBvbg0KPiBjb25m aWd1cmF0aW9uIGJhc2lzLiBUaHVzLCBvbmUgZG9lc24ndCByZWFsbHkga25vdyBob3cgbXVjaCB0 aGUgbG93ZXINCj4gYml0LXJhdGUgbWVkaWEgY29uZmlndXJhaXRvbiByZWFsbHkgdXNlcy4gT25l IGNhbiBwcm9iYWJseSBkZXJpdmUgYQ0KPiBtYXhpbXVtIHdoaWNoIGlzIGxpa2VseSB0byBiZSBt dWNoIGxhcmdlciB0aGFuIHJlYWxpdHkuIFRodXMgaXQgaXMNCj4gcmVhbGx5IGhpZGRlbiB0aGF0 IHNvbWUgY29uZmlndXJhdGlvbiBpcyBpbnRlZGVkIHRvIHVzZSBubyBtb3JlIHRoYW4gNTAwDQo+ ICh2aWRlbykgb3IgNTAgKGF1ZGlvKSBrYi4NCj4gDQo+IFlvdSBjYW4gYWxzbyBzcG90IHRoZSBk b3duc2lkZSBvZiBubyBkZWxldGUgZnVuY3Rpb24gZm9yIGF0dHJpYnV0ZXMgYXMgSQ0KPiBhbSBm b3JjZWQgdG8gdXNlIHRoZSAiLW0iIG9wdGlvbiBhbmQgdGh1cyBuZWVkIHRvIGFjYXAgYWxsIFNE UA0KPiBhdHRyaWJ1dGVzIGJhc2ljYWxseS4NCj4gDQo+IEkgaGF2ZW50JyBmb3VuZCBhbnl0aGlu ZyB0aGF0IGRvZXNuJ3Qgd29yayBpbiB0aGUgZXhlcmNpc2Ugb2YgY3JlYXRpbmcNCj4gdGhpcyBT RFAuIEhvd2V2ZXIsIEkgbXVzdCBzYXkgdGhhdCBpdCBsb29rcyBxdWl0ZSB1Z2x5LiBCdXQgSSBm b3JzZWUNCj4gdGhhdCB0aGlzIHR5cGUgb2YgYXJyYW5nZW1lbnQgd2lsbCBzdGFydCB0byBwb3Ag dXAuIEFuZCB0aGVuIEkgdGhpbmsgd2UNCj4gY2FuIGZvcnNlZSBldmVuIG1vcmUgY29tcGxleCBj YXNlcy4NCj4gDQo+IFdhcm5pbmcgU0RQIGlzIGhhbmQtbWFkZSBhbmQgbWF5IGNvbnRhaW4gbGFy Z2Ugc3ludGF4IGVycm9ycy4gVGhhdCBpcw0KPiBkZWZpbml0ZWx5IHRydWUgZm9yIHRoZSBILjI2 NCBwYXJhbWV0ZXJpemF0aW9uLg0KPiANCj4gU28gcGxlYXNlIGNvbnNpZGVyIHdoYXQgdGhpcyBt ZWNoYW5pc20gcmVhbGx5IG1lYW5zIHdoZW4geW91IGdldCBpbnRvIGENCj4gYml0IG1vcmUgc2Vy aW91cyB1c2FnZXMuIEFsc28gZG8gbm90IGV4cGVjdCBhbnkgcmVwbGllcyBmcm9tIG1lIHVudGls DQo+IGFmdGVyIHRoZSAyNnRoIG9mIEF1Z3VzdC4NCj4gDQo+IC9NYWdudXMNCj4gDQo+IA0KPiB2 PTANCj4gbz1qZG9lIDI4OTA4NDQ1MjYgMjg5MDg0MjgwNyBJTiBJUDQgMTAuNDcuMTYuNQ0KPiBz PUEgU0RQIENBUCBORUcgZXhhbXBsZSBidWlsdCBvbiB0aGUgMTBrIGV4YW1wbGUgSSBkaWQgYSB3 aGlsZSBhZ28NCj4gaT1Vc2VzIHByb3h5aW5nIGZvciBzb21lIHBheWxvYWQgdHlwcyBhbmQgZG9l cyBtZWRpYSBjYXBhYmlsaXR5DQo+IG5lZ290aWF0aW9uIHdpdGggb25seSBjb3JlIHN1cHBvcnQN Cj4gdT1odHRwOi8vd3d3LmV4YW1wbGUuY29tL3NlbWluYXJzL3NkcC5wZGYNCj4gZT1tYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20gKE1hZ251cyBXZXN0ZXJsdW5kKQ0KPiB0PTI4NzMzOTc0 OTYgMjg3MzQwNDY5Ng0KPiBhPWljZS1wd2Q6c3BlRWMzUUdaaU5XcFZMRkpoUVgNCj4gbT12aWRl byA0OTE3MCBSVFAvQVZQIDEwMCA5OSA5OCA5NyA5NiA5NQ0KPiBjPUlOIElQNCAxOTIuMC4yLjU2 DQo+IGI9QVM6MTAwMDANCj4gYj1USUFTOjEwMDAwMDAwDQo+IGI9UlI6NDAwMA0KPiBiPVJTOjMw MDANCj4gYT10Y2FwOjEgUlRQL1NBVlBGIFJUUC9TQVZQIFJUUC9BVlBGDQo+IGE9cGNmZzoxIHQ9 MSBhPS1tOjEsMiwzLDQsNSw2LDcsMTEsMTIsMTMsMzAsMzEsMzIsMzMsMzQsMzUsMzYsMzcsMzgs MzkNCj4gYT1wY2ZnOjIgdD0xDQo+IGE9LW06MSwyLDMsNCw1LDYsNyw4LDksMTAsMTEsMTIsMTMs MzAsMzEsMzIsMzMsMzQsMzUsMzYsMzcsMzgsMzkNCj4gYT1wY2ZnOjMgdD0yIGE9DQo+IGE9cGNm Zzo0IHQ9MiBhPTgsOSwxMA0KPiBhPXBjZmc6NCB0PTMgYT0xLDIsMyw0LDUsNiw3LDExLDEyLDEz DQo+IGE9cGNmZzo1IHQ9MyBhPTEsMiwzLDQsNSw2LDcsOCw5LDEwLDExLDEyLDEzDQo+IGE9bWF4 cHJhdGU6MTAwMA0KPiBhPWFjYXA6MSBhPXJ0Y3AtZmI6KiBuYWNrDQo+IGE9cnRwbWFwOjk4IEgy NjQvOTAwMDANCj4gYT1mbXRwOjk4IHByb2ZpbGUtbGV2ZWwtaWQ9NDJBMDFFOyBwYWNrZXRpemF0 aW9uLW1vZGU9MDsNCj4gc3Byb3AtcGFyYW1ldGVyLXNldHM9WjBJQUNwWlRCWW1JLGFNbGppQT09 DQo+IGE9cnRwbWFwOjk5IEgyNjQvOTAwMDANCj4gYT1mbXRwOjk5IHByb2ZpbGUtbGV2ZWwtaWQ9 NDJBMDFFOyBwYWNrZXRpemF0aW9uLW1vZGU9MTsNCj4gc3Byb3AtcGFyYW1ldGVyLXNldHM9WjBJ QUNwWlRCWW1JLGFNbGppQT09DQo+IGE9cnRwbWFwOjEwMCBIMjY0LzkwMDAwDQo+IGE9Zm10cDox MDAgcHJvZmlsZS1sZXZlbC1pZD00MkEwMUU7IHBhY2tldGl6YXRpb24tbW9kZT0yOw0KPiBzcHJv cC1wYXJhbWV0ZXItc2V0cz1aMElBQ3BaVEJZbUksYU1samlBPT07IHNwcm9wLWludGVybGVhdmlu Zy1kZXB0aD00NTsNCj4gc3Byb3AtZGVpbnQtYnVmLXJlcT02NDAwMDsgc3Byb3AtaW5pdC1idWYt dGltZT0xMDI0Nzg7IGRlaW50LWJ1Zi0NCj4gY2FwPTEyODAwMA0KPiBhPXJ0cG1hcDo5NyBIMjY0 LzkwMDAwDQo+IGE9Zm10cDo5NyBwcm9maWxlLWxldmVsLWlkPTQyQTAxRTsgcGFja2V0aXphdGlv bi1tb2RlPTA7DQo+IHNwcm9wLXBhcmFtZXRlci1zZXRzPVowSUFDcFpUQlltSSxhTWxqaUE9PQ0K PiBhPXJ0cG1hcDo5NiBIMjY0LzkwMDAwDQo+IGE9Zm10cDo5NiBwcm9maWxlLWxldmVsLWlkPTQy QTAxRTsgcGFja2V0aXphdGlvbi1tb2RlPTA7DQo+IHNwcm9wLXBhcmFtZXRlci1zZXRzPVowSUFD cFpUQlltSSxhTWxqaUE9PQ0KPiBhPXJ0cG1hcDo5NSBIMjY0LzkwMDAwDQo+IGE9Zm10cDo5NSBw cm9maWxlLWxldmVsLWlkPTQyQTAxRTsgcGFja2V0aXphdGlvbi1tb2RlPTA7DQo+IHNwcm9wLXBh cmFtZXRlci1zZXRzPVowSUFDcFpUQlltSSxhTWxqaUE9PQ0KPiBhPWFjYXA6MiBhPXJ0cG1hcDo5 NyBydHgvOTAwMDANCj4gYT1hY2FwOjMgYT1mbXRwOjk3IGFwdD0xMDA7cnR4LXRpbWU9MzAwMA0K PiBhPWFjYXA6NCBhPXJ0cG1hcDo5NiBydHgvOTAwMDANCj4gYT1hY2FwOjUgYT1mbXRwOjk2IGFw dD05OTtydHgtdGltZT0zMDAwDQo+IGE9YWNhcDo2IGE9cnRwbWFwOjk1IHJ0eC85MDAwMA0KPiBh PWFjYXA6NyBhPWZtdHA6OTUgYXB0PTk4O3J0eC10aW1lPTMwMDANCj4gYT1hY2FwOjggYT1mbXRw Ojk4IHByb2ZpbGUtbGV2ZWwtaWQ9ODJBMDFFOyBwYWNrZXRpemF0aW9uLW1vZGU9MDsNCj4gc3By b3AtcGFyYW1ldGVyLXNldHM9ZmV0Z2FzZCxmbGVhUz09DQo+IGE9YWNhcDo5IGE9Zm10cDo5OSBw cm9maWxlLWxldmVsLWlkPTgyQTAxRTsgcGFja2V0aXphdGlvbi1tb2RlPTA7DQo+IHNwcm9wLXBh cmFtZXRlci1zZXRzPWZldGdhc2QsZmxlYVM9PQ0KPiBhPWFjYXA6MTAgYT1mbXRwOjEwMCBwcm9m aWxlLWxldmVsLWlkPTgyQTAxRTsgcGFja2V0aXphdGlvbi1tb2RlPTA7DQo+IHNwcm9wLXBhcmFt ZXRlci1zZXRzPWZldGdhc2QsZmxlYVM9PTsgc3Byb3AtaW50ZXJsZWF2aW5nLWRlcHRoPTQ1Ow0K PiBzcHJvcC1kZWludC1idWYtcmVxPTY0MDAwOyBzcHJvcC1pbml0LWJ1Zi10aW1lPTEwMjQ3ODsg ZGVpbnQtYnVmLQ0KPiBjYXA9MTI4MDAwDQo+IGE9YWNhcDoxMSBhPXJ0cG1hcDo5OCBIMjY0Lzkw MDAwDQo+IGE9YWNhcDoxMiBhPXJ0cG1hcDo5OSBIMjY0LzkwMDAwDQo+IGE9YWNhcDoxMyBhPXJ0 cG1hcDoxMDAgSDI2NC85MDAwMA0KPiBhPXJ0Y3A6NTE1NDANCj4gYT1zZW5kb25seQ0KPiBhPWNy eXB0bzoxIEFFU19DTV8xMjhfSE1BQ19TSEExXzgwDQo+IGlubGluZTpkMFJtZG1jbVZDc3BlRWMz UUdaaU5XcFZMRkpoUVgxY2ZIQXdKU29qfDIyMHwxOjMyDQo+IGE9Y2FuZGlkYXRlIDEyMzQ1Njc4 IDEgVURQIDEuMCAxOTIuMC4yLjU2IDQ5MTcwDQo+IGE9Y2FuZGlkYXRlIDIzNDU2NzgxIDIgVURQ IDEuMCAxOTIuMC4yLjU2IDUxNTQwDQo+IGE9Y2FuZGlkYXRlIDM0NTY3ODEyIDEgVURQIDAuNyAx MC4wLjAuMSA0MTM0NQ0KPiBhPWNhbmRpZGF0ZSA0NTY3ODEyMyAyIFVEUCAwLjcgMTAuMC4wLjEg NTI1NjcNCj4gYT1jYW5kaWRhdGUgNTY3ODEyMzQgMSBVRFAgMC4zIDE5Mi4wLjIuMTAwIDQ5MDAw DQo+IGE9Y2FuZGlkYXRlIDY3ODEyMzQ1IDIgVURQIDAuMyAxOTIuMC4yLjEwMCA0OTAwMQ0KPiBh PWFjYXA6MzAgYT1ydGNwOjUxNTQwDQo+IGE9YWNhcDozMSBhPXNlbmRvbmx5DQo+IGE9YWNhcDoz MiBhPWNyeXB0bzoxIEFFU19DTV8xMjhfSE1BQ19TSEExXzgwDQo+IGlubGluZTpkMFJtZG1jbVZD c3BlRWMzUUdaaU5XcFZMRkpoUVgxY2ZIQXdKU29qfDIyMHwxOjMyDQo+IGE9YWNhcDozMyBhPWNh bmRpZGF0ZSAxMjM0NTY3OCAxIFVEUCAxLjAgMTkyLjAuMi41NiA0OTE3MA0KPiBhPWFjYXA6MzQg YT1jYW5kaWRhdGUgMjM0NTY3ODEgMiBVRFAgMS4wIDE5Mi4wLjIuNTYgNTE1NDANCj4gYT1hY2Fw OjM1IGE9Y2FuZGlkYXRlIDM0NTY3ODEyIDEgVURQIDAuNyAxMC4wLjAuMSA0MTM0NQ0KPiBhPWFj YXA6MzYgYT1jYW5kaWRhdGUgNDU2NzgxMjMgMiBVRFAgMC43IDEwLjAuMC4xIDUyNTY3DQo+IGE9 YWNhcDozNyBhPWNhbmRpZGF0ZSA1Njc4MTIzNCAxIFVEUCAwLjMgMTkyLjAuMi4xMDAgNDkwMDAN Cj4gYT1hY2FwOjM4IGE9Y2FuZGlkYXRlIDY3ODEyMzQ1IDIgVURQIDAuMyAxOTIuMC4yLjEwMCA0 OTAwMQ0KPiBhPWFjYXA6MzkgYT1tYXhwcmF0ZToxMDAwDQo+IG09YXVkaW8gNDkxNzYgUlRQL0FW UCAxMDEgMTAwIDk5IDk4DQo+IGM9SU4gSVA0IDE5Mi4wLjIuNTYNCj4gYj1BUzo1MTINCj4gYj1U SUFTOjUxMjAwMA0KPiBiPVJSOjQwMDANCj4gYj1SUzozMDAwDQo+IGE9dGNhcDo0IFJUUC9TQVZQ DQo+IGE9cGNmZzo2IHQ9NCBhPTIzDQo+IGE9cGNmZzo3IHQ9NCBhPS1tOiAxNCwxNSwxNiwxNywx OCwxOSwyMCwyMSwyMiwyMywyNCwyNSwyNiwyNywyOCwyOQ0KPiBhPW1heHByYXRlOjEyMA0KPiBh PXJ0cG1hcDo5OCBBTVItV0IvMTYwMDANCj4gYT1mbXRwOjk4IG9jdGV0LWFsaWduPTE7IG1vZGUt Y2hhbmdlLWNhcGFiaWxpdHk9Mg0KPiBhPXJ0cG1hcDo5OSBBTVItV0IvMTYwMDANCj4gYT1mbXRw Ojk5IG9jdGV0LWFsaWduPTE7IGNyYz0xOyBtb2RlLWNoYW5nZS1jYXBhYmlsaXR5PTINCj4gYT1y dHBtYXA6MTAwIEFNUi1XQi8xNjAwMC8yDQo+IGE9Zm10cDoxMDAgb2N0ZXQtYWxpZ249MTsgaW50 ZXJsZWF2aW5nPTMwDQo+IGE9cnRwbWFwOjEwMSBBTVItV0IrLzcyMDAwLzINCj4gYT1mbXRwOjEw MSBpbnRlcmxlYXZpbmc9NTA7IGludC1kZWxheT0xNjAwMDA7DQo+IGE9YWNhcDoxNCBhPXJ0cG1h cDo5OCBhYzMvNDgwMDAvNg0KPiBhPWFjYXA6MTUgYT1ydHBtYXA6OTkgYWMzLzQ4MDAwLzYNCj4g YT1hY2FwOjE2IGE9cnRwbWFwOjEwMCBhYzMvNDgwMDAvNg0KPiBhPWFjYXA6MTcgYT1ydHBtYXA6 MTAxIGFjMy80ODAwMC82DQo+IGE9YWNhcDoxOCBhPXB0aW1lOjMyDQo+IGE9YWNhcDoxOSBhPW1h eHByYXRlOjEyMA0KPiBhPWFjYXA6MjAgYT1tYXhwdGltZToyMDANCj4gYT1hY2FwOjIxIGE9cnRj cDo1MTUzNA0KPiBhPWFjYXA6MjIgYT1zZW5kb25seQ0KPiBhPWFjYXA6MjMgYT1jcnlwdG86MSBB RVNfQ01fMTI4X0hNQUNfU0hBMV84MA0KPiBpbmxpbmU6ZDBSbWRtY21WQ3NwZUVjM1FHWmlOV3BW TEZKaFFYMWNmSEF3SlNvanwyMjB8MTozMg0KPiBhPWFjYXA6MjQgYT1jYW5kaWRhdGUgMTIzNDU2 NzggMSBVRFAgMS4wIDE5Mi4wLjIuNTYgNDkxNzYNCj4gYT1hY2FwOjI1IGE9Y2FuZGlkYXRlIDIz NDU2NzgxIDIgVURQIDEuMCAxOTIuMC4yLjU2IDUxNTM0DQo+IGE9YWNhcDoyNiBhPWNhbmRpZGF0 ZSAzNDU2NzgxMiAxIFVEUCAwLjcgMTAuMC4wLjEgNDEzNDUNCj4gYT1hY2FwOjI3IGE9Y2FuZGlk YXRlIDQ1Njc4MTIzIDIgVURQIDAuNyAxMC4wLjAuMSA1MjU2Nw0KPiBhPWFjYXA6MjggYT1jYW5k aWRhdGUgNTY3ODEyMzQgMSBVRFAgMC4zIDE5Mi4wLjIuMTAwIDQ5MDAwDQo+IGE9YWNhcDoyOSBh PWNhbmRpZGF0ZSA2NzgxMjM0NSAyIFVEUCAwLjMgMTkyLjAuMi4xMDAgNDkwMDENCj4gYT1wdGlt ZTo2MA0KPiBhPW1heHB0aW1lOjIwMA0KPiBhPXJ0Y3A6NTE1MzQNCj4gYT1zZW5kb25seQ0KPiBh PWNhbmRpZGF0ZSAxMjM0NTY3OCAxIFVEUCAxLjAgMTkyLjAuMi41NiA0OTE3Ng0KPiBhPWNhbmRp ZGF0ZSAyMzQ1Njc4MSAyIFVEUCAxLjAgMTkyLjAuMi41NiA1MTUzNA0KPiBhPWNhbmRpZGF0ZSAz NDU2NzgxMiAxIFVEUCAwLjcgMTAuMC4wLjEgNDEzNDUNCj4gYT1jYW5kaWRhdGUgNDU2NzgxMjMg MiBVRFAgMC43IDEwLjAuMC4xIDUyNTY3DQo+IGE9Y2FuZGlkYXRlIDU2NzgxMjM0IDEgVURQIDAu MyAxOTIuMC4yLjEwMCA0OTAwMA0KPiBhPWNhbmRpZGF0ZSA2NzgxMjM0NSAyIFVEUCAwLjMgMTky LjAuMi4xMDAgNDkwMDENCj4gDQo+IC0tDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4g SUVURiBUcmFuc3BvcnQgQXJlYSBEaXJlY3RvciAmIFRTVldHIENoYWlyDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0v TQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUg KzQ2IDggNDA0ODI4Nw0KPiBUb3JzaGFtc2dhdGFuIDIzICAgICAgICAgICB8IEZheCAgICs0NiA4 IDc1NzU1NTANCj4gUy0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMgbWFpbGluZyBs aXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg== --===============0667275011== 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 --===============0667275011==--