From simon.perreault@viagenie.ca Tue Feb 1 08:51:27 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0373A6C3B for ; Tue, 1 Feb 2011 08:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVQ+nGIAYwu9 for ; Tue, 1 Feb 2011 08:51:26 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9A8B03A6BFF for ; Tue, 1 Feb 2011 08:51:25 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0555F21EE3 for ; Tue, 1 Feb 2011 11:54:41 -0500 (EST) Message-ID: <4D483AD1.4030700@viagenie.ca> Date: Tue, 01 Feb 2011 11:54:41 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <4D0B883A.5050104@nomadiclab.com> <07F779ED-7B31-4810-AF3B-0B173432C315@nomadiclab.com> <4D3FDC0A.7070008@ericsson.com> <0FD76042-E69F-4EC0-8D99-C17B76536E5F@nomadiclab.com> <4D4023ED.6000703@digium.com> In-Reply-To: <4D4023ED.6000703@digium.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Lite mode to ICE TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 16:51:27 -0000 On 2011-01-26 08:38, Kevin P. Fleming wrote: >> [...] The lack of connectivity checks is >> especially problematic if one of the hosts is behind a NAT and has an >> address from a private address space: the peer may accidentally >> connect to a host in a different subnet that uses the same private >> address space. This is one of the reasons why a lite implementation >> MUST NOT be located behind a NAT. > > Maybe that should be worded a bit differently; a UA that implements both > full ICE and ICE-lite can certainly be located behind a NAT, but it must > not choose lite mode when it is behind a NAT. In addition, the > restriction should be based on communicating *across* the NAT, not the > location of the implementation. It should be perfectly acceptable for an > ICE-lite implementation to talk another ICE-lite implementation on a > private network that is also behind a NAT to a public network, if the > two implementations are not attempting to communicate across the NAT. > > It's too early in the morning here for me to attempt to draft some text, > but I'll try later today if nobody else has taken a stab at it :-) Here's an attempt: "This is one of the reasons why ICE-lite MUST NOT be used from behind a NAT (unless it is known, via static configuration or otherwise, that no communication will happen across the NAT)." Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ari.keranen@nomadiclab.com Tue Feb 1 09:24:25 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5A73A6C00 for ; Tue, 1 Feb 2011 09:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhXrD22QuZu2 for ; Tue, 1 Feb 2011 09:24:24 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 6DB963A6BFA for ; Tue, 1 Feb 2011 09:24:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B02014E6D7; Tue, 1 Feb 2011 19:27:40 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7DfDf7H-lYF; Tue, 1 Feb 2011 19:27:39 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id AAC504E6BC; Tue, 1 Feb 2011 19:27:39 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <4D483AD1.4030700@viagenie.ca> Date: Tue, 1 Feb 2011 19:27:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C33FDDD-172C-44E9-9D56-E823EC7CF221@nomadiclab.com> References: <4D0B883A.5050104@nomadiclab.com> <07F779ED-7B31-4810-AF3B-0B173432C315@nomadiclab.com> <4D3FDC0A.7070008@ericsson.com> <0FD76042-E69F-4EC0-8D99-C17B76536E5F@nomadiclab.com> <4D4023ED.6000703@digium.com> <4D483AD1.4030700@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Lite mode to ICE TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:24:25 -0000 On Feb 1, 2011, at 6:54 PM, Simon Perreault wrote: > On 2011-01-26 08:38, Kevin P. Fleming wrote: >>> [...] The lack of connectivity checks is >>> especially problematic if one of the hosts is behind a NAT and = has an >>> address from a private address space: the peer may accidentally >>> connect to a host in a different subnet that uses the same = private >>> address space. This is one of the reasons why a lite = implementation >>> MUST NOT be located behind a NAT. >>=20 >> Maybe that should be worded a bit differently; a UA that implements = both >> full ICE and ICE-lite can certainly be located behind a NAT, but it = must >> not choose lite mode when it is behind a NAT. In addition, the >> restriction should be based on communicating *across* the NAT, not = the >> location of the implementation. It should be perfectly acceptable for = an >> ICE-lite implementation to talk another ICE-lite implementation on a >> private network that is also behind a NAT to a public network, if the >> two implementations are not attempting to communicate across the NAT. >>=20 >> It's too early in the morning here for me to attempt to draft some = text, >> but I'll try later today if nobody else has taken a stab at it :-) >=20 > Here's an attempt: >=20 > "This is one of the reasons why ICE-lite MUST NOT be used from behind = a > NAT (unless it is known, via static configuration or otherwise, that = no > communication will happen across the NAT)." Thanks for the text Simon. However, while I sympathize with the problem = you're trying to solve, this would be inconsistent with what is defined = for UDP in ICE RFC, and thus I think this document is not the right = place to fix that. I would rather keep ICE TCP (lite) consistent with ICE UDP and have a = different document (maybe one of the 3 we already have) defining the = behavior in this use case. Cheers, Ari= From simon.perreault@viagenie.ca Tue Feb 1 09:40:06 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49333A6DA2 for ; Tue, 1 Feb 2011 09:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNJyorH+asv8 for ; Tue, 1 Feb 2011 09:40:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0654C3A6C56 for ; Tue, 1 Feb 2011 09:40:04 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B695021CC9; Tue, 1 Feb 2011 12:43:20 -0500 (EST) Message-ID: <4D484638.6020808@viagenie.ca> Date: Tue, 01 Feb 2011 12:43:20 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ari Keranen References: <4D0B883A.5050104@nomadiclab.com> <07F779ED-7B31-4810-AF3B-0B173432C315@nomadiclab.com> <4D3FDC0A.7070008@ericsson.com> <0FD76042-E69F-4EC0-8D99-C17B76536E5F@nomadiclab.com> <4D4023ED.6000703@digium.com> <4D483AD1.4030700@viagenie.ca> <9C33FDDD-172C-44E9-9D56-E823EC7CF221@nomadiclab.com> In-Reply-To: <9C33FDDD-172C-44E9-9D56-E823EC7CF221@nomadiclab.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Lite mode to ICE TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 17:40:07 -0000 On 2011-02-01 12:27, Ari Keranen wrote: >> "This is one of the reasons why ICE-lite MUST NOT be used from >> behind a NAT (unless it is known, via static configuration or >> otherwise, that no communication will happen across the NAT)." > > Thanks for the text Simon. However, while I sympathize with the > problem you're trying to solve, this would be inconsistent with what > is defined for UDP in ICE RFC, and thus I think this document is not > the right place to fix that. Makes sense. I honestly don't care that much because implementations will do whatever they need to do, no matter what gets written. So please don't let this prevent you from publishing, and let's move on. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From pkyzivat@cisco.com Tue Feb 1 13:58:43 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A9C3A6C99 for ; Tue, 1 Feb 2011 13:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LGF9GOwgg-C for ; Tue, 1 Feb 2011 13:58:43 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F021E3A6C8D for ; Tue, 1 Feb 2011 13:58:42 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUDAKYRSE1AZnwM/2dsb2JhbACWKj+OI3Ohd5sdhVMEhROHEINC Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Feb 2011 22:01:59 +0000 Received: from [10.86.254.109] ([10.86.254.109]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p11M1xK2026437 for ; Tue, 1 Feb 2011 22:01:59 GMT Message-ID: <4D4882D7.2080701@cisco.com> Date: Tue, 01 Feb 2011 17:01:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <1215F876-58CC-4309-B126-03893425B367@ntt-at.com> <0884B6C8-DDCD-4BA6-A8A8-054380170411@nomadiclab.com> <131601cbc186$a127a720$e376f560$@com> In-Reply-To: <131601cbc186$a127a720$e376f560$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:58:44 -0000 conceptually sctp seems like a good thing for many application uses. I just don't know if I will live long enough to see it generally usable. Thanks, Paul On 1/31/2011 3:37 PM, Dan Wing wrote: > +1. > > -d > > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Ari Keranen >> Sent: Monday, January 31, 2011 1:29 AM >> To: IETF MMUSIC WG >> Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 >> >> +1 >> >> >> Cheers, >> Ari >> >> On Jan 29, 2011, at 9:36 AM, Shida Schubert wrote: >>> >>> +1 >>> >>> On Jan 29, 2011, at 3:01 AM, Michael Tuexen wrote: >>> >>>> Dear all, >>>> >>>> I think the ID makes perfect sense and should be progressed. >>>> >>>> Just one note: [I-D.ietf-tsvwg-dtls-for-sctp] is now [RFC6083]. >>>> >>>> Best regards >>>> Michael >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From abegen@cisco.com Tue Feb 1 14:02:05 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97FD3A6C52 for ; Tue, 1 Feb 2011 14:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uvQbLhs5s2b for ; Tue, 1 Feb 2011 14:02:02 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 24D6E3A6C4D for ; Tue, 1 Feb 2011 14:01:59 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYCANMSSE2rRN+K/2dsb2JhbACWKo5ic6IAmx6FUwSFE4pY Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2011 22:05:02 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p11M52cX008405 for ; Tue, 1 Feb 2011 22:05:02 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 14:05:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 14:04:55 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E367CC5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D4882D7.2080701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 Thread-Index: AcvCW66saGBmaatSSfmWF0glx8dwgAAAFCKQ References: <1215F876-58CC-4309-B126-03893425B367@ntt-at.com> <0884B6C8-DDCD-4BA6-A8A8-054380170411@nomadiclab.com><131601cbc186$a127a720$e376f560$@com> <4D4882D7.2080701@cisco.com> From: "Ali C. Begen (abegen)" To: "Paul Kyzivat (pkyzivat)" , X-OriginalArrivalTime: 01 Feb 2011 22:05:02.0078 (UTC) FILETIME=[12F161E0:01CBC25C] Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:02:05 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Paul Kyzivat (pkyzivat) > Sent: Tuesday, February 01, 2011 5:02 PM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 >=20 > conceptually sctp seems like a good thing for many application uses. > I just don't know if I will live long enough to see it generally = usable. +1 :) =20 > Thanks, > Paul From fandreas@cisco.com Tue Feb 1 14:23:21 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88463A6C7B for ; Tue, 1 Feb 2011 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.267 X-Spam-Level: X-Spam-Status: No, score=-10.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYKQVJeVjmXH for ; Tue, 1 Feb 2011 14:23:17 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A8E4F3A6C52 for ; Tue, 1 Feb 2011 14:23:17 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMIAI0XSE2rR7Ht/2dsb2JhbAAWoAuEbHOUZY0OmxyFUwSFE4cQ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2011 22:26:35 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p11MQYk5009633; Tue, 1 Feb 2011 22:26:35 GMT Message-ID: <4D488918.4030306@cisco.com> Date: Tue, 01 Feb 2011 17:28:40 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4D42BE19.8060007@ericsson.com> In-Reply-To: <4D42BE19.8060007@ericsson.com> Content-Type: multipart/alternative; boundary="------------050105070509060805020101" Cc: mmusic Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:23:21 -0000 This is a multi-part message in MIME format. --------------050105070509060805020101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Seems reasonable to me as well. Is this a request to adopt it as a WG item ? A few quick draft comments: - I'm a little confused by the examples in Section 6. Why is "*" used as the media format ? - Section 6.2: Why is the media type changed from 6.1 ? Why is the connection shown as "new" ? Please add a note explaining why the port changes to 9 in the answer. - IANA Considerations: I believe you are defining both "SCTP" and "SCTP/DTLS" for IANA registration. - NAT considerations: In lieu of the amount of effort we have put into NAT traversal, I think it would be useful to add a section around this. - Multihoming: It would be worthwhile discussing the current re-INVITE approach compared to an actual listing of the different addresses (refer to James Polk/Randy Stewart's MMUSIC message of March 18, 2009) Thanks -- Flemming On 1/28/11 8:01 AM, Gonzalo Camarillo wrote: > > Folks, > > [as an individual] > > the following draft allows offer/answer exchanges to establish streams > that are transported by SCTP. > > http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06 > > We need to decide what to do with the draft, whether to let it die or to > progress it. The ability to describe SCTP-based streams seems useful > even though, as we all know, SCTP is not nearly as widely deployed as > UDP or TCP. Does anybody see any reason why the offer/answer model > should not support SCTP-based streams? > > Your comments are appreciated. > > Thanks, > > Gonzalo > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------050105070509060805020101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Seems reasonable to me as well. Is this a request to adopt it as a WG item ?


A few quick draft comments:
- I'm a little confused by the examples in Section 6. Why is "*" used as the media format ?
- Section 6.2: Why is the media type changed from 6.1 ? Why is the connection shown as "new" ? Please add a note explaining why the port changes to 9 in the answer.
- IANA Considerations: I believe you are defining both "SCTP" and "SCTP/DTLS" for IANA registration.
- NAT considerations: In lieu of the amount of effort we have put into NAT traversal, I think it would be useful to add a section around this.
- Multihoming: It would be worthwhile discussing the current re-INVITE approach compared to an actual listing of the different addresses (refer to James Polk/Randy Stewart's MMUSIC message of March 18, 2009)

Thanks

-- Flemming




On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
[MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06

Folks,

[as an individual]

the following draft allows offer/answer exchanges to establish streams
that are transported by SCTP.

http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06

We need to decide what to do with the draft, whether to let it die or to
progress it. The ability to describe SCTP-based streams seems useful
even though, as we all know, SCTP is not nearly as widely deployed as
UDP or TCP. Does anybody see any reason why the offer/answer model
should not support SCTP-based streams?

Your comments are appreciated.

Thanks,

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

--------------050105070509060805020101-- From kpfleming@digium.com Tue Feb 1 14:24:43 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2543A6C8C for ; Tue, 1 Feb 2011 14:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCvwgcBmvKlU for ; Tue, 1 Feb 2011 14:24:40 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 2E7583A6C9E for ; Tue, 1 Feb 2011 14:24:37 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1PkOhW-0002S7-Oa for mmusic@ietf.org; Tue, 01 Feb 2011 16:27:54 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id BC9E1D82A1 for ; Tue, 1 Feb 2011 16:27:54 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JYut6aVcXVF for ; Tue, 1 Feb 2011 16:27:54 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 66ACDD82A0 for ; Tue, 1 Feb 2011 16:27:54 -0600 (CST) Message-ID: <4D4888EA.7010103@digium.com> Date: Tue, 01 Feb 2011 16:27:54 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: mmusic@ietf.org References: <4D0B883A.5050104@nomadiclab.com> <07F779ED-7B31-4810-AF3B-0B173432C315@nomadiclab.com> <4D3FDC0A.7070008@ericsson.com> <0FD76042-E69F-4EC0-8D99-C17B76536E5F@nomadiclab.com> <4D4023ED.6000703@digium.com> <4D483AD1.4030700@viagenie.ca> <9C33FDDD-172C-44E9-9D56-E823EC7CF221@nomadiclab.com> <4D484638.6020808@viagenie.ca> In-Reply-To: <4D484638.6020808@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Lite mode to ICE TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 22:24:44 -0000 On 02/01/2011 11:43 AM, Simon Perreault wrote: > On 2011-02-01 12:27, Ari Keranen wrote: >>> "This is one of the reasons why ICE-lite MUST NOT be used from >>> behind a NAT (unless it is known, via static configuration or >>> otherwise, that no communication will happen across the NAT)." >> >> Thanks for the text Simon. However, while I sympathize with the >> problem you're trying to solve, this would be inconsistent with what >> is defined for UDP in ICE RFC, and thus I think this document is not >> the right place to fix that. > > Makes sense. I honestly don't care that much because implementations > will do whatever they need to do, no matter what gets written. So please > don't let this prevent you from publishing, and let's move on. Agreed :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From gonzalo.camarillo@ericsson.com Tue Feb 1 23:43:24 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161233A6CBE for ; Tue, 1 Feb 2011 23:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.623 X-Spam-Level: X-Spam-Status: No, score=-106.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcTsJUpSLJ18 for ; Tue, 1 Feb 2011 23:43:23 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1AD963A6CB1 for ; Tue, 1 Feb 2011 23:43:22 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-c7-4d490be02ca2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.FD.13987.0EB094D4; Wed, 2 Feb 2011 08:46:40 +0100 (CET) Received: from [131.160.126.175] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Wed, 2 Feb 2011 08:46:40 +0100 Message-ID: <4D490BDF.5050505@ericsson.com> Date: Wed, 2 Feb 2011 09:46:39 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Flemming Andreasen References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> In-Reply-To: <4D488918.4030306@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 07:43:24 -0000 Hi Flemming, > Seems reasonable to me as well. Is this a request to adopt it as a WG > item ? yes, that would be the next natural step given that people seem to think it is a reasonable thing to specify. Thanks, Gonzalo From ari.keranen@nomadiclab.com Wed Feb 2 01:53:53 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106CD3A7125 for ; Wed, 2 Feb 2011 01:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8c4JgJnkqSR for ; Wed, 2 Feb 2011 01:53:52 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id EA60C3A711E for ; Wed, 2 Feb 2011 01:53:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id C4D564E6DA; Wed, 2 Feb 2011 11:57:07 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCrT19y6U1qA; Wed, 2 Feb 2011 11:57:07 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 41A7C4E6BC; Wed, 2 Feb 2011 11:57:07 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <4D484638.6020808@viagenie.ca> Date: Wed, 2 Feb 2011 11:57:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D3A30A3-69C8-4398-B737-93AFB83DF798@nomadiclab.com> References: <4D0B883A.5050104@nomadiclab.com> <07F779ED-7B31-4810-AF3B-0B173432C315@nomadiclab.com> <4D3FDC0A.7070008@ericsson.com> <0FD76042-E69F-4EC0-8D99-C17B76536E5F@nomadiclab.com> <4D4023ED.6000703@digium.com> <4D483AD1.4030700@viagenie.ca> <9C33FDDD-172C-44E9-9D56-E823EC7CF221@nomadiclab.com> <4D484638.6020808@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Lite mode to ICE TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 09:53:53 -0000 On Feb 1, 2011, at 7:43 PM, Simon Perreault wrote: > On 2011-02-01 12:27, Ari Keranen wrote: >>> "This is one of the reasons why ICE-lite MUST NOT be used from >>> behind a NAT (unless it is known, via static configuration or >>> otherwise, that no communication will happen across the NAT)." >>=20 >> Thanks for the text Simon. However, while I sympathize with the >> problem you're trying to solve, this would be inconsistent with what >> is defined for UDP in ICE RFC, and thus I think this document is not >> the right place to fix that. >=20 > Makes sense. I honestly don't care that much because implementations > will do whatever they need to do, no matter what gets written. So = please > don't let this prevent you from publishing, and let's move on. Yeah, that is a probable outcome for the folks with this scenario. =10At = least we have warned them about the risks involved. Also, since the actual choice of words in ICE RFC is that "a lite = implementation is only appropriate for devices that will *always* be = connected to the public Internet and have a public IP address", I = changed the text in the security section to match that: This is one of the reasons why the lite mode is not appropriate for an ICE agent located behind a NAT. That's closer to what you also proposed and doesn't normatively prevent = future docs to specify lite-like behavior behind a NAT. Cheers, Ari= From Internet-Drafts@ietf.org Wed Feb 2 05:30:03 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805CC3A6BF3; Wed, 2 Feb 2011 05:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.128 X-Spam-Level: X-Spam-Status: No, score=-102.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HejwOBtDzdl1; Wed, 2 Feb 2011 05:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3453A6BAB; Wed, 2 Feb 2011 05:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110202133002.29799.30499.idtracker@localhost> Date: Wed, 02 Feb 2011 05:30:02 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 13:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : TCP Candidates with Interactive Connectivity Establishment (ICE) Author(s) : J. Rosenberg, et al. Filename : draft-ietf-mmusic-ice-tcp-12.txt Pages : 29 Date : 2011-02-02 Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-tcp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-02052902.I-D@ietf.org> --NextPart-- From ari.keranen@nomadiclab.com Wed Feb 2 05:35:13 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750083A6CD6 for ; Wed, 2 Feb 2011 05:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kTERa-0cxQg for ; Wed, 2 Feb 2011 05:35:12 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 899413A6CB7 for ; Wed, 2 Feb 2011 05:35:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6C3A44E6D7 for ; Wed, 2 Feb 2011 15:38:27 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBnTn0gqpzLE for ; Wed, 2 Feb 2011 15:38:26 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id A78EB4E6BC for ; Wed, 2 Feb 2011 15:38:26 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: <20110202133002.29799.30499.idtracker@localhost> Date: Wed, 2 Feb 2011 15:38:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73AE4D31-0D94-42DA-98CD-BB9F250490D3@nomadiclab.com> References: <20110202133002.29799.30499.idtracker@localhost> To: IETF MMUSIC WG X-Mailer: Apple Mail (2.1082) Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 13:35:13 -0000 Hi all, This version contains all the changes discussed on the mailing list (and = a set of editorial fixes). Most notably - Defining ICE lite for TCP - Added SDP examples - Updated the prioritization formula for TCP candidates Reviews are welcome. Cheers, Ari On Feb 2, 2011, at 3:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multiparty Multimedia Session Control = Working Group of the IETF. >=20 >=20 > Title : TCP Candidates with Interactive Connectivity = Establishment (ICE) > Author(s) : J. Rosenberg, et al. > Filename : draft-ietf-mmusic-ice-tcp-12.txt > Pages : 29 > Date : 2011-02-02 >=20 > Interactive Connectivity Establishment (ICE) defines a mechanism for > NAT traversal for multimedia communication protocols based on the > offer/answer model of session negotiation. ICE works by providing a > set of candidate transport addresses for each media stream, which are > then validated with peer-to-peer connectivity checks based on Session > Traversal Utilities for NAT (STUN). ICE provides a general framework > for describing candidates, but only defines UDP-based transport > protocols. This specification extends ICE to TCP-based media, > including the ability to offer a mix of TCP and UDP-based candidates > for a single stream. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-12.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From ari.keranen@nomadiclab.com Wed Feb 2 05:41:39 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF703A6CE1 for ; Wed, 2 Feb 2011 05:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SJb0WNlppVH for ; Wed, 2 Feb 2011 05:41:39 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id BF0F53A6900 for ; Wed, 2 Feb 2011 05:41:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id D36D34E6D7; Wed, 2 Feb 2011 15:44:57 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGLJMeQNuQ-D; Wed, 2 Feb 2011 15:44:57 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6727B4E6BC; Wed, 2 Feb 2011 15:44:57 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: Date: Wed, 2 Feb 2011 15:44:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3209CD6B-1275-4962-A578-2AF0A612FE2F@nomadiclab.com> References: <4D0B883A.5050104@nomadiclab.com> <07F779ED-7B31-4810-AF3B-0B173432C315@nomadiclab.com> <4D3FDC0A.7070008@ericsson.com> <0FD76042-E69F-4EC0-8D99-C17B76536E5F@nomadiclab.com> <4D4023ED.6000703@digium.com> <68DCC559-8C2E-4C80-A116-204676A51C4F@nomadiclab.com> <4D40465B.1070807@viagenie.ca> <26058A88-85A1-4FDE-8D84-B730E60E2660@nomadiclab.com> <4D4174B1.2030206@viagenie.ca> <988D948F-616F-4DE9-8081-628BA947B598@nomadiclab.com> To: Ross Finlayson X-Mailer: Apple Mail (2.1082) Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Lite mode to ICE TCP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 13:41:39 -0000 Hi Ross, On Jan 29, 2011, at 3:55 AM, Ross Finlayson wrote: > Am I the only person annoyed by the spelling "lite"? Seems that most of us can live with it :) But given that is how the ICE = RFC spells it, I guess that's the best option anyway. Cheers, Ari= From dwing@cisco.com Wed Feb 2 11:52:04 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EE93A6D9A for ; Wed, 2 Feb 2011 11:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRXJ13j5G8Hr for ; Wed, 2 Feb 2011 11:52:01 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A84763A6D41 for ; Wed, 2 Feb 2011 11:52:01 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2011 19:55:22 +0000 Received: from dwingWS ([10.32.240.197]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p12JtL5Z018203; Wed, 2 Feb 2011 19:55:22 GMT From: "Dan Wing" To: "'Flemming Andreasen'" , "'Gonzalo Camarillo'" References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> In-Reply-To: <4D488918.4030306@cisco.com> Date: Wed, 2 Feb 2011 11:55:22 -0800 Message-ID: <095101cbc313$2066e400$6134ac00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvCXxy8/slBr0YJTQCQO1N+fa9e5wAs7CGg Content-Language: en-us Cc: 'mmusic' Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 19:52:04 -0000 > Seems reasonable to me as well. Is this a request to adopt it as a WG > item ? > > > A few quick draft comments: > - I'm a little confused by the examples in Section 6. Why is "*" used > as the media format ? > - Section 6.2: Why is the media type changed from 6.1 ? Why is the > connection shown as "new" ? Please add a note explaining why the port > changes to 9 in the answer. > - IANA Considerations: I believe you are defining both "SCTP" and > "SCTP/DTLS" for IANA registration. > - NAT considerations: In lieu of the amount of effort we have put into > NAT traversal, I think it would be useful to add a section around this. On that topic, do we want draft-loreto-mmusic-sctp-sdp to include the ability to signal SCTP-over-UDP (*)? SCTP-over-UDP is generally necessary to traverse non-SCTP-aware firewalls and NATs. But tunneling SCTP over UDP brings with it other issues, including bifurcating SCTP itself. (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps -d > - Multihoming: It would be worthwhile discussing the current re-INVITE > approach compared to an actual listing of the different addresses > (refer to James Polk/Randy Stewart's MMUSIC message of March 18, 2009) > > Thanks > > -- Flemming > > > > > On 1/28/11 8:01 AM, Gonzalo Camarillo wrote: > > Folks, > > [as an individual] > > the following draft allows offer/answer exchanges to establish > streams > that are transported by SCTP. > > http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06 > > We need to decide what to do with the draft, whether to let it > die or to > progress it. The ability to describe SCTP-based streams seems > useful > even though, as we all know, SCTP is not nearly as widely > deployed as > UDP or TCP. Does anybody see any reason why the offer/answer > model > should not support SCTP-based streams? > > Your comments are appreciated. > > Thanks, > > Gonzalo > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From petithug@acm.org Wed Feb 2 12:41:56 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AFA3A6C81; Wed, 2 Feb 2011 12:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.056 X-Spam-Level: X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhj1uX5jQlRt; Wed, 2 Feb 2011 12:41:56 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id EC08D3A6DBF; Wed, 2 Feb 2011 12:41:55 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 2C7C4DBCC052; Wed, 2 Feb 2011 20:45:16 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 38272DBCC050; Wed, 2 Feb 2011 20:45:15 +0000 (UTC) Message-ID: <4D49C25A.4090300@acm.org> Date: Wed, 02 Feb 2011 12:45:14 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: 'mmusic' , splices@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-petithuguenin-mmusic-ice-attributes-level-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 20:41:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found an issue with aggregated media that use different ICE implementations. I wrote a small I-D that explain the problem and how I fixed it: http://datatracker.ietf.org/doc/draft-petithuguenin-mmusic-ice-attributes-level/ Comments and suggestions are welcome. I posted this email in both mmusic and splices, but please follow-up in mmusic. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1JwlgACgkQ9RoMZyVa61d0vgCfYOGDMYvDEx3U0c7Zyo2FUP9M ty4AnjNDxpqCF+KpPh+/Er8r6QhZipQJ =bHOw -----END PGP SIGNATURE----- From fandreas@cisco.com Wed Feb 2 13:58:46 2011 Return-Path: X-Original-To: mmusic@core3.amsl.com Delivered-To: mmusic@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FAB3A6ABE for ; Wed, 2 Feb 2011 13:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va8WCvLio9IB for ; Wed, 2 Feb 2011 13:58:45 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0C4853A687A for ; Wed, 2 Feb 2011 13:58:44 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFACZjSU1AZnwN/2dsb2JhbACCRZ1uhGxzoHWbIoVTBIR4hmk Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2011 22:02:05 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p12M25ux004026; Wed, 2 Feb 2011 22:02:05 GMT Message-ID: <4D49D4DC.40900@cisco.com> Date: Wed, 02 Feb 2011 17:04:12 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: mmusic Content-Type: multipart/alternative; boundary="------------030403090904060309040604" Cc: Simo Veikkolainen Subject: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 21:58:46 -0000 This is a multi-part message in MIME format. --------------030403090904060309040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I've taken a look at draft-garcia-mmusic-sdp-icap-bcap-00.txt and have a few questions and comments. First of all, based on Jean-Francois' e-mail to the list on July 30, 2010, it is my understanding that this draft is a WG item, so the next version should be submitted as "draft-ietf-mmusic...". Secondly, here are my draft comments: - Given the scope of the draft is now "media title" and "media bandwidth", I'd suggest changing the title accordingly. - Section 1, 2nd, paragraph: Why are we talking about "k=" here ? It's possible to define lots of things, so why call this one out as one we don't ? - Section 3.1, "The optional "+" is used to indicate that the entire configuration, not just the parameter, must be ignored if the parameter is not supported " The wording is technically correct, but counter intuitive to the careless reader compared to the RFC 5939 wording. In order to avoid confusion, I'd suggest rephrasing it. - Section 3.1, "Therefore, capabilities referenced by any configuration attribute MUST appear at the media level when a configuration is "converted" to a corresponding media block" I'm not sure how to interpret this paragraph. Please elaborate/clarify text - Section 3.1 and other places: I'd suggest we call "icap" for "media title" capability instead of media information, etc. for consistency with RFC 4566. - Section 3.1.1, ABNF: We've limited capability numbers syntactically to 10 digits in RFC 5939. For consistency, I'd do the same here. - Section 3.1.1.1, first paragraph: Description of "acfg" is inaccurate (it does not convey potential configurations to be negotiated, but rather the potential configuration that was actually used for negotiation). - Section 3.1.1.1, ABNF: 10 digit limit again and s/b-/bw-/ - Section 3.1.1.1, first paragraph after ABNF: What does it mean to have more than one of these, and in particular, can there be more than one with a given bw-type ? Also s/b-/bw-/ - Section 3.1.2: Suggest changing "Information Capability" to "Media Title Capability" - Section 3.1.2, ABNF: 10 digit limit again. - Section 3.1.2.1, first paragraph: Inaccurate description of "acfg" attribute (similar to above) - Section 3.1.2.1, ABNF: Missing the optional "+" and associated description of it. Also, When would you have more than one media title in a given pcfg ? Can you give an example ? Lastly, 10 digit limit again. - Section 3.1.2.2: May want to add a comment about use of "+" not being very likely either (or maybe include that as part of previous comment). - Section 3.2, first sentence. Delete "ccap". Suggest adding the following to the end of the sentence: ", i.e. the capabilities they provide can only result in media level types and values (not session level)" - Section 4: Suggest changing "at the base media level" to " within the media description in question " (Note: Two occurrences). - Section ?: Missing an offer/answer section. - Section 5: Suggest changing "Information Capability" to "Media Title Capability" - Section 5.2: s/ccap/icap - Section 6: Security considerations need to be expanded with specific considerations for these parameters (e.g. specific threats) Thanks -- Flemming --------------030403090904060309040604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi

I've taken a look at

        draft-garcia-mmusic-sdp-icap-bcap-00.txt

and have a few questions and comments.

First of all, based on Jean-Francois' e-mail to the list on July 30, 2010, it is my understanding that this draft is a WG item, so the next version should be submitted as "draft-ietf-mmusic...".

Secondly, here are my draft comments:

- Given the scope of the draft is now "media title" and "media bandwidth", I'd suggest changing the title accordingly.

- Section 1, 2nd, paragraph: Why are we talking about "k=" here ? It's possible to define lots of things, so why call this one out as one we don't ?

- Section 3.1, "The optional "+" is used to indicate that the entire configuration, not just the parameter, must be ignored if the parameter is not supported "
The wording is technically correct, but counter intuitive to the careless reader compared to the RFC 5939 wording. In order to avoid confusion, I'd suggest rephrasing it.

- Section 3.1, "Therefore, capabilities referenced by any configuration attribute MUST appear at the media level when a configuration is "converted" to a corresponding media block"
I'm not sure how to interpret this paragraph. Please elaborate/clarify text 

- Section 3.1 and other places: I'd suggest we call "icap" for "media title" capability instead of media information, etc. for consistency with RFC 4566.

- Section 3.1.1, ABNF: We've limited capability numbers syntactically to 10 digits in RFC 5939. For consistency, I'd do the same here.

- Section 3.1.1.1, first paragraph: Description of "acfg" is inaccurate (it does not convey potential configurations to be negotiated, but rather the potential configuration that was actually used for negotiation).

- Section 3.1.1.1, ABNF: 10 digit limit again and s/b-/bw-/

- Section 3.1.1.1, first paragraph after ABNF:
What does it mean to have more than one of these, and in particular, can there be more than one with a given bw-type ?
Also s/b-/bw-/

- Section 3.1.2: Suggest changing "Information Capability" to "Media Title Capability"

- Section 3.1.2, ABNF: 10 digit limit again.

- Section 3.1.2.1, first paragraph: Inaccurate description of "acfg" attribute (similar to above)

- Section 3.1.2.1, ABNF: Missing the optional "+" and associated description of it. Also, When would you have more than one media title in a given pcfg ? Can you give an example ? Lastly, 10 digit limit again.

- Section 3.1.2.2: May want to add a comment about use of "+" not being very likely either (or maybe include that as part of previous comment).

- Section 3.2, first sentence. Delete "ccap". Suggest adding the following to the end of the sentence: ", i.e. the capabilities they provide can only result in media level types and values (not session level)"

- Section 4: Suggest changing "at the base media level" to " within the media description in question " (Note: Two occurrences).

- Section ?: Missing an offer/answer section.

- Section 5: Suggest changing "Information Capability" to "Media Title Capability"

- Section 5.2: s/ccap/icap

- Section 6: Security considerations need to be expanded with specific considerations for these parameters (e.g. specific threats)

Thanks

-- Flemming 










--------------030403090904060309040604--

From gonzalo.camarillo@ericsson.com  Wed Feb  2 23:16:30 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A8B3A6859 for ; Wed,  2 Feb 2011 23:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.622
X-Spam-Level: 
X-Spam-Status: No, score=-106.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSiBAbQNnyRU for ; Wed,  2 Feb 2011 23:16:29 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 666AA3A679C for ; Wed,  2 Feb 2011 23:16:29 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-85-4d4a5715c5e9
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 52.20.23694.5175A4D4; Thu,  3 Feb 2011 08:19:50 +0100 (CET)
Received: from [131.160.126.175] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Thu, 3 Feb 2011 08:19:22 +0100
Message-ID: <4D4A56F9.9080707@ericsson.com>
Date: Thu, 3 Feb 2011 09:19:21 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Dan Wing 
References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> <095101cbc313$2066e400$6134ac00$@com>
In-Reply-To: <095101cbc313$2066e400$6134ac00$@com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: 'Flemming Andreasen' , 'mmusic' 
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Feb 2011 07:16:30 -0000

Hi Dan,

good point. It all depends on what we want to do in the NAT traversal
area. If we want to define how to use ICE to establish SCTP streams,
then we should include UDP encapsulation as well. Something like what
RFC 5770 did for HIP.

Cheers,

Gonzalo

On 02/02/2011 9:55 PM, Dan Wing wrote:
>> Seems reasonable to me as well. Is this a request to adopt it as a WG
>> item ?
>>
>>
>> A few quick draft comments:
>> - I'm a little confused by the examples in Section 6. Why is "*" used
>> as the media format ?
>> - Section 6.2: Why is the media type changed from 6.1 ? Why is the
>> connection shown as "new" ? Please add a note explaining why the port
>> changes to 9 in the answer.
>> - IANA Considerations: I believe you are defining both "SCTP" and
>> "SCTP/DTLS" for IANA registration.
>> - NAT considerations: In lieu of the amount of effort we have put into
>> NAT traversal, I think it would be useful to add a section around this.
> 
> On that topic, do we want draft-loreto-mmusic-sctp-sdp to include the 
> ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP is generally 
> necessary to traverse non-SCTP-aware firewalls and NATs.  But tunneling
> SCTP over UDP brings with it other issues, including bifurcating SCTP
> itself.
> 
> (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
> 
> -d
> 
>> - Multihoming: It would be worthwhile discussing the current re-INVITE
>> approach compared to an actual listing of the different addresses
>> (refer to James Polk/Randy Stewart's MMUSIC message of March 18, 2009)
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>
>> On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
>>
>> 	Folks,
>>
>> 	[as an individual]
>>
>> 	the following draft allows offer/answer exchanges to establish
>> streams
>> 	that are transported by SCTP.
>>
>> 	http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06
>>
>> 	We need to decide what to do with the draft, whether to let it
>> die or to
>> 	progress it. The ability to describe SCTP-based streams seems
>> useful
>> 	even though, as we all know, SCTP is not nearly as widely
>> deployed as
>> 	UDP or TCP. Does anybody see any reason why the offer/answer
>> model
>> 	should not support SCTP-based streams?
>>
>> 	Your comments are appreciated.
>>
>> 	Thanks,
>>
>> 	Gonzalo
>> 	_______________________________________________
>> 	mmusic mailing list
>> 	mmusic@ietf.org
>> 	https://www.ietf.org/mailman/listinfo/mmusic
>>
> 
> 


From Simo.Veikkolainen@nokia.com  Thu Feb  3 02:52:39 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F070D3A68F0 for ; Thu,  3 Feb 2011 02:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.629
X-Spam-Level: 
X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLCcbXnrhH7u for ; Thu,  3 Feb 2011 02:52:38 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id AD0663A68B1 for ; Thu,  3 Feb 2011 02:52:38 -0800 (PST)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p13AtmV8002670; Thu, 3 Feb 2011 12:55:58 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 3 Feb 2011 12:55:49 +0200
Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 Feb 2011 11:55:49 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Thu, 3 Feb 2011 11:55:47 +0100
From: 
To: , 
Thread-Topic: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
Thread-Index: AQHLwyTg/83x22pCHkaqbdNtAedVz5PvX+Wg
Date: Thu, 3 Feb 2011 10:55:46 +0000
Message-ID: 
References: <4D49D4DC.40900@cisco.com>
In-Reply-To: <4D49D4DC.40900@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Feb 2011 10:55:49.0705 (UTC) FILETIME=[EB16FB90:01CBC390]
X-Nokia-AV: Clean
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Feb 2011 10:52:40 -0000

Hello Flemming, and thanks for your detailed review.
Please see below lines marked with [SV].

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of=
 ext Flemming Andreasen
Sent: 03 February, 2011 00:04
To: mmusic
Cc: Simo Veikkolainen
Subject: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item

Hi=20

I've taken a look at=20

=A0=A0=A0 =A0=A0=A0 draft-garcia-mmusic-sdp-icap-bcap-00.txt

and have a few questions and comments.=20

[SV] Incidentally, I just yesterday submitted a -01 version of the draft. H=
owever, the content was only modified to clean up some text and to remove t=
he last remaining references to "ccap" attribute.

First of all, based on Jean-Francois' e-mail to the list on July 30, 2010, =
it is my understanding that this draft is a WG item, so the next version sh=
ould be submitted as "draft-ietf-mmusic...".=20

[SV] Ok will send the next version as WG item.

Secondly, here are my draft comments:=20

- Given the scope of the draft is now "media title" and "media bandwidth", =
I'd suggest changing the title accordingly.=20

[SV] Changed this to "Media title and Media bandwidth Capabilities Negotiat=
ion in the SDP"

- Section 1, 2nd, paragraph: Why are we talking about "k=3D" here ? It's po=
ssible to define lots of things, so why call this one out as one we don't ?=
=20

[SV] I think "k=3D" was mentioned there before since we mentioned that we a=
re defining capabilities for the rest of the (meaningful) attribute lines w=
hich were not covered anywhere else. Now that "ccap" is not part of the dra=
ft anymore, I think we can also remove the text regarding "k=3D" lines.

- Section 3.1, "The optional "+" is used to indicate that the entire config=
uration, not just the parameter, must be ignored if the parameter is not su=
pported "
The wording is technically correct, but counter intuitive to the careless r=
eader compared to the RFC 5939 wording. In order to avoid confusion, I'd su=
ggest rephrasing it.=20

[SV] Changed this to follow RFC5939 wording: "The optional "+" is used to i=
ndicate that the extension is mandatory and MUST be supported in order to u=
se that potential configuration."

- Section 3.1, "Therefore, capabilities referenced by any configuration att=
ribute MUST appear at the media level when a configuration is "converted" t=
o a corresponding media block"=20
I'm not sure how to interpret this paragraph. Please elaborate/clarify text=
=A0=20

[SV] The intention has been to say that even though "i=3D" can appear eithe=
r at session or media level, we are defining the "icap" attribute only for =
media level. I think the sentence becomes clearer by just deleting "..when =
a configuration is "converted" to a corresponding media block".

- Section 3.1 and other places: I'd suggest we call "icap" for "media title=
" capability instead of media information, etc. for consistency with RFC 45=
66.=20

[SV] Ok.

- Section 3.1.1, ABNF: We've limited capability numbers syntactically to 10=
 digits in RFC 5939. For consistency, I'd do the same here.=20

[SV] Changed.

- Section 3.1.1.1, first paragraph: Description of "acfg" is inaccurate (it=
 does not convey potential configurations to be negotiated, but rather the =
potential configuration that was actually used for negotiation).=20

[SV] Right. I removed the text "which can carry one or more potential confi=
guration to be negotiated".

- Section 3.1.1.1, ABNF: 10 digit limit again and s/b-/bw-/

[SV] Done.

- Section 3.1.1.1, first paragraph after ABNF:=20
What does it mean to have more than one of these, and in particular, can th=
ere be more than one with a given bw-type ?=20
Also s/b-/bw-/

[SV] Hmm, good catch. I would assume there is only one "b=3D" line for each=
 media block. Or are there cases when more than one bandwidth value would b=
e needed? If this is the case, then also in the configuration parameters it=
 would suffice to only have one.=20

- Section 3.1.2: Suggest changing "Information Capability" to "Media Title =
Capability"

[SV] Changed.

- Section 3.1.2, ABNF: 10 digit limit again.=20

[SV] Ok.

- Section 3.1.2.1, first paragraph: Inaccurate description of "acfg" attrib=
ute (similar to above)

[SV] Changed as in above (deleted the text after the comma).

- Section 3.1.2.1, ABNF: Missing the optional "+" and associated descriptio=
n of it.=20

[SV] Here we thought that the "+" would not be needed since it is unlikely =
that the potential configuration should be rejected if the media title capa=
bility is not supported. Do you see this differently?

Also, When would you have more than one media title in a given pcfg ? Can y=
ou give an example ?=20

[SV] I'm tempted to limit also this one to only one, unless I hear objectio=
ns.

Lastly, 10 digit limit again.=20

[SV] Ok.

- Section 3.1.2.2: May want to add a comment about use of "+" not being ver=
y likely either (or maybe include that as part of previous comment).=20

[SV] Do we need the "+" at all? For consistency's sake I guess yes, but is =
there a use case?

- Section 3.2, first sentence. Delete "ccap". Suggest adding the following =
to the end of the sentence: ", i.e. the capabilities they provide can only =
result in media level types and values (not session level)"=20

[SV] Done.

- Section 4: Suggest changing "at the base media level" to " within the med=
ia description in question " (Note: Two occurrences).=20

[SV] Changed.

- Section ?: Missing an offer/answer section.=20

[SV] You mean a section defining the offerer and answerer behaviour like in=
 Media capabilities draft Section 3.4? I guess we could add such a section.

- Section 5: Suggest changing "Information Capability" to "Media Title Capa=
bility"

[SV] Done.

- Section 5.2: s/ccap/icap

[SV] Done.

- Section 6: Security considerations need to be expanded with specific cons=
iderations for these parameters (e.g. specific threats)

[SV] Do you have any specific examples mind?

[SV] Thanks, Simo

Thanks=20

-- Flemming=20









From dwing@cisco.com  Thu Feb  3 07:54:21 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB5F3A69E5 for ; Thu,  3 Feb 2011 07:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.523
X-Spam-Level: 
X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfs2XdpJOrMS for ; Thu,  3 Feb 2011 07:54:21 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F20F53A69E2 for ; Thu,  3 Feb 2011 07:54:20 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 03 Feb 2011 15:57:43 +0000
Received: from dwingWS ([10.32.240.197]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p13FvhV4008835; Thu, 3 Feb 2011 15:57:43 GMT
From: "Dan Wing" 
To: "'Gonzalo Camarillo'" 
References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> <095101cbc313$2066e400$6134ac00$@com> <4D4A56F9.9080707@ericsson.com>
In-Reply-To: <4D4A56F9.9080707@ericsson.com>
Date: Thu, 3 Feb 2011 07:57:42 -0800
Message-ID: <011201cbc3bb$177a41e0$466ec5a0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvDcsk76E8edNehTgqpmfd4Rwas9wAR8rOA
Content-Language: en-us
Cc: 'Flemming Andreasen' , 'mmusic' 
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Feb 2011 15:54:22 -0000

> good point. It all depends on what we want to do in the NAT traversal
> area. If we want to define how to use ICE to establish SCTP streams,
> then we should include UDP encapsulation as well.

ICE should be discussed, but SCTP doesn't need to be tunneled over
UDP to do that.

A problem we (the industry) have with migrating from HTTP-over-TCP
to HTTP-over- is that we have nothing like SDP's
"m=" line.  And, as you know, SDP's "m=" line doesn't really allow
negotiating different transports, which is where ICE and/or SDP Capability
Negotiation come in.

For SDP to offer SCTP but also provide fallback to plain UDP or offer
fallback to plain TCP, I think ICE needs to be considered.


But, as for SCTP-over-UDP tunneling, I am really hoping we can just
not do it.  It further complicates things.  However, everyone should
be aware of it and make that decision themselves for the scope of
the MMUSIC document.

-d


> Something like what
> RFC 5770 did for HIP.
> 
> Cheers,
> 
> Gonzalo
> 
> On 02/02/2011 9:55 PM, Dan Wing wrote:
> >> Seems reasonable to me as well. Is this a request to adopt it as a
> WG
> >> item ?
> >>
> >>
> >> A few quick draft comments:
> >> - I'm a little confused by the examples in Section 6. Why is "*"
> used
> >> as the media format ?
> >> - Section 6.2: Why is the media type changed from 6.1 ? Why is the
> >> connection shown as "new" ? Please add a note explaining why the
> port
> >> changes to 9 in the answer.
> >> - IANA Considerations: I believe you are defining both "SCTP" and
> >> "SCTP/DTLS" for IANA registration.
> >> - NAT considerations: In lieu of the amount of effort we have put
> into
> >> NAT traversal, I think it would be useful to add a section around
> this.
> >
> > On that topic, do we want draft-loreto-mmusic-sctp-sdp to include the
> > ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP is generally
> > necessary to traverse non-SCTP-aware firewalls and NATs.  But
> tunneling
> > SCTP over UDP brings with it other issues, including bifurcating SCTP
> > itself.
> >
> > (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
> >
> > -d
> >
> >> - Multihoming: It would be worthwhile discussing the current re-
> INVITE
> >> approach compared to an actual listing of the different addresses
> >> (refer to James Polk/Randy Stewart's MMUSIC message of March 18,
> 2009)
> >>
> >> Thanks
> >>
> >> -- Flemming
> >>
> >>
> >>
> >>
> >> On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
> >>
> >> 	Folks,
> >>
> >> 	[as an individual]
> >>
> >> 	the following draft allows offer/answer exchanges to establish
> >> streams
> >> 	that are transported by SCTP.
> >>
> >> 	http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06
> >>
> >> 	We need to decide what to do with the draft, whether to let it
> >> die or to
> >> 	progress it. The ability to describe SCTP-based streams seems
> >> useful
> >> 	even though, as we all know, SCTP is not nearly as widely
> >> deployed as
> >> 	UDP or TCP. Does anybody see any reason why the offer/answer
> >> model
> >> 	should not support SCTP-based streams?
> >>
> >> 	Your comments are appreciated.
> >>
> >> 	Thanks,
> >>
> >> 	Gonzalo
> >> 	_______________________________________________
> >> 	mmusic mailing list
> >> 	mmusic@ietf.org
> >> 	https://www.ietf.org/mailman/listinfo/mmusic
> >>
> >
> >


From fandreas@cisco.com  Thu Feb  3 08:47:34 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D053A698F for ; Thu,  3 Feb 2011 08:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level: 
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU9IU-eAo95h for ; Thu,  3 Feb 2011 08:47:33 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 65E953A6938 for ; Thu,  3 Feb 2011 08:47:33 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAP9rSk1AZnwM/2dsb2JhbACgP4Rtc6JfmxCFWASEeYZt
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2011 16:50:55 +0000
Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p13Gorpb009131; Thu, 3 Feb 2011 16:50:53 GMT
Message-ID: <4D4ADD70.1070008@cisco.com>
Date: Thu, 03 Feb 2011 11:53:04 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: Simo.Veikkolainen@nokia.com
References: <4D49D4DC.40900@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030608080507000803060805"
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Feb 2011 16:47:34 -0000

This is a multi-part message in MIME format.
--------------030608080507000803060805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for the updates Simo. A few follow-ups below...

>
> - Section 3.1, "Therefore, capabilities referenced by any 
> configuration attribute MUST appear at the media level when a 
> configuration is "converted" to a corresponding media block"
> I'm not sure how to interpret this paragraph. Please elaborate/clarify 
> text
>
> [SV] The intention has been to say that even though "i=" can appear 
> either at session or media level, we are defining the "icap" attribute 
> only for media level. I think the sentence becomes clearer by just 
> deleting "..when a configuration is "converted" to a corresponding 
> media block".
>
I think you should elaborate on the text so there is no confusion 
between capabilities being present at the session-level and media-level 
versus generating a configuration from a pcfg attribute present within a 
media description that references them, and hence effectively 
instantiates them at the media-level (except for session-level 
attributes, which is fraught with challenges as per RFC 5939). An 
accompanying example may help as well.

>
> - Section 3.1.1.1, first paragraph after ABNF:
> What does it mean to have more than one of these, and in particular, 
> can there be more than one with a given bw-type ?
> Also s/b-/bw-/
>
> [SV] Hmm, good catch. I would assume there is only one "b=" line for 
> each media block. Or are there cases when more than one bandwidth 
> value would be needed? If this is the case, then also in the 
> configuration parameters it would suffice to only have one.
>
You can have different bandwidth types, so I can see where you might 
want to have more than one "b=" line per configuration, however I'm not 
sure I see how it would be useful to have different values for the same 
bw-type within a given potential configuration (which one do you pick, 
and why ?)

>
> - Section 3.1.2.1, ABNF: Missing the optional "+" and associated 
> description of it.
>
> [SV] Here we thought that the "+" would not be needed since it is 
> unlikely that the potential configuration should be rejected if the 
> media title capability is not supported. Do you see this differently?
>
Not really, but since RFC 5939 includes the "+" for extensions, and 
there doesn't seem to be any harm in allowing it here either, I would 
include it for consistency with a note that you wouldn't normally expect 
it to be used (but then again, you never know what use cases people come 
up with).

> Also, When would you have more than one media title in a given pcfg ? 
> Can you give an example ?
>
> [SV] I'm tempted to limit also this one to only one, unless I hear 
> objections.
>
One seems right to me as well.


>
> - Section 3.1.2.2: May want to add a comment about use of "+" not 
> being very likely either (or maybe include that as part of previous 
> comment).
>
> [SV] Do we need the "+" at all? For consistency's sake I guess yes, 
> but is there a use case?
>
I can come up with a contrived use case if necessary, but it's not 
obvious. I'd keep it for consistency.


>
> - Section ?: Missing an offer/answer section.
>
> [SV] You mean a section defining the offerer and answerer behaviour 
> like in Media capabilities draft Section 3.4? I guess we could add 
> such a section.
>
Sounds good.


>
> [SV] Done.
>
> - Section 6: Security considerations need to be expanded with specific 
> considerations for these parameters (e.g. specific threats)
>
> [SV] Do you have any specific examples mind?
>

Describe what happens if an attacker is able to change one or more of 
these new parameters. The bw in particular seems to be the one that 
might have some ramifications, since choice of a potential configuration 
could be affected by its expected bw usage (and hence you could launch a 
denial of service attack this way, or at least impact the service 
quality). Changing title information seems more like a nuisance, but 
still, if it's used to select between configurations (e.g. via human 
interaction), it could impact service. The mechanisms to address these 
threats are the same as in RFC 5939 I believe, however we need to ensure 
people understand the threats they are faced with.

Thanks

-- Flemming



--------------030608080507000803060805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Thanks for the updates Simo. A few follow-ups below...





  


- Section 3.1, "Therefore, capabilities referenced by any configuration
attribute MUST appear at the media level when a configuration is
"converted" to a corresponding media block"

I'm not sure how to interpret this paragraph. Please elaborate/clarify
text 

  

[SV] The intention has been to say that even though "i=" can appear
either at session or media level, we are defining the "icap" attribute
only for media level. I think the sentence becomes clearer by just
deleting "..when a configuration is "converted" to a corresponding
media block".

  

  



I think you should elaborate on the text so there is no confusion
between capabilities being present at the session-level and media-level
versus generating a configuration from a pcfg attribute present within
a media description that references them, and hence effectively
instantiates them at the media-level (except for session-level
attributes, which is fraught with challenges as per RFC 5939). An
accompanying example may help as well. 





  


- Section 3.1.1.1, first paragraph after ABNF:

What does it mean to have more than one of these, and in particular,
can there be more than one with a given bw-type ?

Also s/b-/bw-/

  

[SV] Hmm, good catch. I would assume there is only one "b=" line for
each media block. Or are there cases when more than one bandwidth value
would be needed? If this is the case, then also in the configuration
parameters it would suffice to only have one.

  



You can have different bandwidth types, so I can see where you might
want to have more than one "b=" line per configuration, however I'm not
sure I see how it would be useful to have different values for the same
bw-type within a given potential configuration (which one do you pick,
and why ?) 





  


- Section 3.1.2.1, ABNF: Missing the optional "+" and associated
description of it.

  

[SV] Here we thought that the "+" would not be needed since it is
unlikely that the potential configuration should be rejected if the
media title capability is not supported. Do you see this differently?

  

  



Not really, but since RFC 5939 includes the "+" for extensions, and
there doesn't seem to be any harm in allowing it here either, I would
include it for consistency with a note that you wouldn't normally
expect it to be used (but then again, you never know what use cases
people come up with). 





  
Also, When would you have more than one media title
in a given pcfg ? Can you give an example ?

  

[SV] I'm tempted to limit also this one to only one, unless I hear
objections.

  



One seems right to me as well. 







  


- Section 3.1.2.2: May want to add a comment about use of "+" not being
very likely either (or maybe include that as part of previous comment).

  

[SV] Do we need the "+" at all? For consistency's sake I guess yes, but
is there a use case?

  

  



I can come up with a contrived use case if necessary, but it's not
obvious. I'd keep it for consistency. 







  


- Section ?: Missing an offer/answer section.

  

[SV] You mean a section defining the offerer and answerer behaviour
like in Media capabilities draft Section 3.4? I guess we could add such
a section.

  

  



Sounds good. 







  


[SV] Done.

  

- Section 6: Security considerations need to be expanded with specific
considerations for these parameters (e.g. specific threats)

  

[SV] Do you have any specific examples mind?

  





Describe what happens if an attacker is able to change one or more of
these new parameters. The bw in particular seems to be the one that
might have some ramifications, since choice of a potential
configuration could be affected by its expected bw usage (and hence you
could launch a denial of service attack this way, or at least impact
the service quality). Changing title information seems more like a
nuisance, but still, if it's used to select between configurations
(e.g. via human interaction), it could impact service. The mechanisms
to address these threats are the same as in RFC 5939 I believe, however
we need to ensure people understand the threats they are faced with.  



Thanks



-- Flemming 












--------------030608080507000803060805--

From fandreas@cisco.com  Thu Feb  3 09:03:04 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA363A69B3 for ; Thu,  3 Feb 2011 09:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.14
X-Spam-Level: 
X-Spam-Status: No, score=-10.14 tagged_above=-999 required=5 tests=[AWL=0.458,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn05FUU27xZp for ; Thu,  3 Feb 2011 09:03:03 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 15DEF3A687D for ; Thu,  3 Feb 2011 09:03:03 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFAIJvSk1AZnwN/2dsb2JhbACCRZ17hG1zolqbEYVYBIR5hm0
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2011 17:06:25 +0000
Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p13H6PZN027113 for ; Thu, 3 Feb 2011 17:06:25 GMT
Message-ID: <4D4AE111.6070508@cisco.com>
Date: Thu, 03 Feb 2011 12:08:33 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: mmusic 
Content-Type: multipart/alternative; boundary="------------050508060203040302070200"
Subject: [MMUSIC] Proposed new work item on SCTP-Based Media Transport in SDP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Feb 2011 17:03:04 -0000

This is a multi-part message in MIME format.
--------------050508060203040302070200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi MMUSIC Group

As discussed on the mailing list already, we hereby propose to add a new 
WG item on supporting SCTP-Based Media Transport in SDP and adopt

http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06

as a starting point for this work item. The intent is to define a 
Proposed Standard.

Please let us know if you have any objections to this before February 
14, 2011

Thanks

-- Flemming
[MMUSIC co-chair]


--------------050508060203040302070200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit








Hi MMUSIC Group 



As discussed on the mailing list already, we hereby propose to add a
new WG item on
supporting
SCTP-Based
Media Transport in SDP and adopt 



    http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06



as a starting point for this work item. The intent is to define a
Proposed Standard. 



Please let us know if you have any objections to this before February
14, 2011



Thanks 



-- Flemming

[MMUSIC co-chair]






--------------050508060203040302070200--

From fandreas@cisco.com  Thu Feb  3 09:09:34 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EEE3A69DC for ; Thu,  3 Feb 2011 09:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.175
X-Spam-Level: 
X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6G0JxYlkC0a for ; Thu,  3 Feb 2011 09:09:33 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 678123A6A0B for ; Thu,  3 Feb 2011 09:09:33 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqkBAK5wSk1AZnwM/2dsb2JhbACWSIl4hG1zolibEIVYBIR5hm0
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2011 17:12:55 +0000
Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p13HCrhE015614; Thu, 3 Feb 2011 17:12:53 GMT
Message-ID: <4D4AE298.2030307@cisco.com>
Date: Thu, 03 Feb 2011 12:15:04 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: mmusic 
References: <4D30BAE6.8090609@cisco.com>
In-Reply-To: <4D30BAE6.8090609@cisco.com>
Content-Type: multipart/alternative; boundary="------------090602080405020105040702"
Cc: Tom Taylor , Magnus Westerlund , Colin Perkins 
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-ice-options-registry-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 03 Feb 2011 17:09:34 -0000

This is a multi-part message in MIME format.
--------------090602080405020105040702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The WGLC has ended without any additional comments, and hence the 
document is hereby considered ready for progression by the WG.

Thanks

-- Flemming


On 1/14/11 4:06 PM, Flemming Andreasen (fandreas) wrote:
> This is to announce a 2 week Working Group Last Call for
>
>     draft-ietf-mmusic-ice-options-registry-00.txt
>
> as Proposed Standard. Please review and provide any comments you may 
> have on the document before Monday, January 31, 2011. Comments should 
> be sent to the document authors and the MMUSIC WG list.
>
>
> Thanks
>
> -- Flemming
> [MMUSIC co-chair]
>
>
>
> Draft info:
>
>         Title           : IANA Registry for Interactive Connectivity 
> Establishment (ICE) Options
>         Author(s)       : M. Westerlund, C. Perkins
>         Filename        : draft-ietf-mmusic-ice-options-registry-00.txt
>         Pages           : 5
>         Date            : 2011-01-11
>
> It has been identified that Interactive Connectivity Establishment
> (ICE) is missing a registry for ICE options.  This document defines
> this missing IANA registry.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-00.txt
>

--------------090602080405020105040702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


The WGLC has ended without any additional comments, and hence the
document is hereby considered ready for progression by the WG. 



Thanks 



-- Flemming 





On 1/14/11 4:06 PM, Flemming Andreasen (fandreas) wrote:


  
This is to announce a 2 week Working Group Last Call for 

  

    draft-ietf-mmusic-ice-options-registry-00.txt

  

as Proposed Standard. Please review and provide any comments you may
have on the document before Monday, January 31, 2011. Comments should
be sent to the document authors and the MMUSIC WG list. 

  

  

Thanks 

  

-- Flemming 

[MMUSIC co-chair]

  

  

  

Draft info:

  

        Title           : IANA Registry for Interactive Connectivity
Establishment (ICE) Options

        Author(s)       : M. Westerlund, C. Perkins

        Filename        : draft-ietf-mmusic-ice-options-registry-00.txt

        Pages           : 5

        Date            : 2011-01-11

  

It has been identified that Interactive Connectivity Establishment

(ICE) is missing a registry for ICE options.  This document defines

this missing IANA registry.

  

A URL for this Internet-Draft is:

  http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-options-registry-00.txt

  

  

  





--------------090602080405020105040702--

From gonzalo.camarillo@ericsson.com  Fri Feb  4 00:39:26 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E7C3A6B70 for ; Fri,  4 Feb 2011 00:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.621
X-Spam-Level: 
X-Spam-Status: No, score=-106.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj8hbc0dFW19 for ; Fri,  4 Feb 2011 00:39:25 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D87BD3A6893 for ; Fri,  4 Feb 2011 00:39:24 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-54-4d4bbc0818a6
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 20.10.23694.80CBB4D4; Fri,  4 Feb 2011 09:42:48 +0100 (CET)
Received: from [131.160.126.198] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 4 Feb 2011 09:42:46 +0100
Message-ID: <4D4BBC06.3080104@ericsson.com>
Date: Fri, 4 Feb 2011 10:42:46 +0200
From: Gonzalo Camarillo 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Dan Wing 
References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> <095101cbc313$2066e400$6134ac00$@com> <4D4A56F9.9080707@ericsson.com> <011201cbc3bb$177a41e0$466ec5a0$@com>
In-Reply-To: <011201cbc3bb$177a41e0$466ec5a0$@com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: 'Flemming Andreasen' , 'mmusic' 
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Feb 2011 08:39:26 -0000

Hi Dan,

yes, it is a scope question: whether we want ICE to only use SCTP over
IP candidates or we want ICE to use SCTP over UDP candidates as well. In
HIP, the hosts negotiate whether they support (and are willing to use)
UDP encapsulation in their base exchange. If both support it and are
willing to use it, they can include ESP over UDP candidates in their
"offers" and "answers". Otherwise, they only include ESP over IP candidates.

In this way, any implementation is free not to support UDP encapsulation
at all. On the other hand, implementations concerned with NATs can
support it and use it between them to increase the likelihood of
establishing associations successfully.

Cheers,

Gonzalo

On 03/02/2011 5:57 PM, Dan Wing wrote:
>> good point. It all depends on what we want to do in the NAT traversal
>> area. If we want to define how to use ICE to establish SCTP streams,
>> then we should include UDP encapsulation as well.
> 
> ICE should be discussed, but SCTP doesn't need to be tunneled over
> UDP to do that.
> 
> A problem we (the industry) have with migrating from HTTP-over-TCP
> to HTTP-over- is that we have nothing like SDP's
> "m=" line.  And, as you know, SDP's "m=" line doesn't really allow
> negotiating different transports, which is where ICE and/or SDP Capability
> Negotiation come in.
> 
> For SDP to offer SCTP but also provide fallback to plain UDP or offer
> fallback to plain TCP, I think ICE needs to be considered.
> 
> 
> But, as for SCTP-over-UDP tunneling, I am really hoping we can just
> not do it.  It further complicates things.  However, everyone should
> be aware of it and make that decision themselves for the scope of
> the MMUSIC document.
> 
> -d
> 
> 
>> Something like what
>> RFC 5770 did for HIP.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> On 02/02/2011 9:55 PM, Dan Wing wrote:
>>>> Seems reasonable to me as well. Is this a request to adopt it as a
>> WG
>>>> item ?
>>>>
>>>>
>>>> A few quick draft comments:
>>>> - I'm a little confused by the examples in Section 6. Why is "*"
>> used
>>>> as the media format ?
>>>> - Section 6.2: Why is the media type changed from 6.1 ? Why is the
>>>> connection shown as "new" ? Please add a note explaining why the
>> port
>>>> changes to 9 in the answer.
>>>> - IANA Considerations: I believe you are defining both "SCTP" and
>>>> "SCTP/DTLS" for IANA registration.
>>>> - NAT considerations: In lieu of the amount of effort we have put
>> into
>>>> NAT traversal, I think it would be useful to add a section around
>> this.
>>>
>>> On that topic, do we want draft-loreto-mmusic-sctp-sdp to include the
>>> ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP is generally
>>> necessary to traverse non-SCTP-aware firewalls and NATs.  But
>> tunneling
>>> SCTP over UDP brings with it other issues, including bifurcating SCTP
>>> itself.
>>>
>>> (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
>>>
>>> -d
>>>
>>>> - Multihoming: It would be worthwhile discussing the current re-
>> INVITE
>>>> approach compared to an actual listing of the different addresses
>>>> (refer to James Polk/Randy Stewart's MMUSIC message of March 18,
>> 2009)
>>>>
>>>> Thanks
>>>>
>>>> -- Flemming
>>>>
>>>>
>>>>
>>>>
>>>> On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
>>>>
>>>> 	Folks,
>>>>
>>>> 	[as an individual]
>>>>
>>>> 	the following draft allows offer/answer exchanges to establish
>>>> streams
>>>> 	that are transported by SCTP.
>>>>
>>>> 	http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06
>>>>
>>>> 	We need to decide what to do with the draft, whether to let it
>>>> die or to
>>>> 	progress it. The ability to describe SCTP-based streams seems
>>>> useful
>>>> 	even though, as we all know, SCTP is not nearly as widely
>>>> deployed as
>>>> 	UDP or TCP. Does anybody see any reason why the offer/answer
>>>> model
>>>> 	should not support SCTP-based streams?
>>>>
>>>> 	Your comments are appreciated.
>>>>
>>>> 	Thanks,
>>>>
>>>> 	Gonzalo
>>>> 	_______________________________________________
>>>> 	mmusic mailing list
>>>> 	mmusic@ietf.org
>>>> 	https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>>
> 


From dwing@cisco.com  Fri Feb  4 08:12:06 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD033A6969 for ; Fri,  4 Feb 2011 08:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.539
X-Spam-Level: 
X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wXsjHOrf84X for ; Fri,  4 Feb 2011 08:12:05 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F5463A695F for ; Fri,  4 Feb 2011 08:12:05 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 04 Feb 2011 16:15:30 +0000
Received: from dwingWS ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p14GFUh1024111; Fri, 4 Feb 2011 16:15:30 GMT
From: "Dan Wing" 
To: "'Gonzalo Camarillo'" 
References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> <095101cbc313$2066e400$6134ac00$@com> <4D4A56F9.9080707@ericsson.com> <011201cbc3bb$177a41e0$466ec5a0$@com> <4D4BBC06.3080104@ericsson.com>
In-Reply-To: <4D4BBC06.3080104@ericsson.com>
Date: Fri, 4 Feb 2011 08:15:30 -0800
Message-ID: <054801cbc486$be3c0f60$3ab42e20$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcvER4TNOgk0IFYATWyYrFvP8yaxQAAPxUDg
Content-Language: en-us
Cc: 'Flemming Andreasen' , 'mmusic' 
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Feb 2011 16:12:06 -0000

Another factor is that while HIP-over-UDP is RFC'd (I didn't
say standard or experimental), SCTP-over-UDP is only an 
individual document.

-d


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> Sent: Friday, February 04, 2011 12:43 AM
> To: Dan Wing
> Cc: 'Flemming Andreasen'; 'mmusic'
> Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
> 
> Hi Dan,
> 
> yes, it is a scope question: whether we want ICE to only use SCTP over
> IP candidates or we want ICE to use SCTP over UDP candidates as well.
> In
> HIP, the hosts negotiate whether they support (and are willing to use)
> UDP encapsulation in their base exchange. If both support it and are
> willing to use it, they can include ESP over UDP candidates in their
> "offers" and "answers". Otherwise, they only include ESP over IP
> candidates.
> 
> In this way, any implementation is free not to support UDP
> encapsulation
> at all. On the other hand, implementations concerned with NATs can
> support it and use it between them to increase the likelihood of
> establishing associations successfully.
> 
> Cheers,
> 
> Gonzalo
> 
> On 03/02/2011 5:57 PM, Dan Wing wrote:
> >> good point. It all depends on what we want to do in the NAT
> traversal
> >> area. If we want to define how to use ICE to establish SCTP streams,
> >> then we should include UDP encapsulation as well.
> >
> > ICE should be discussed, but SCTP doesn't need to be tunneled over
> > UDP to do that.
> >
> > A problem we (the industry) have with migrating from HTTP-over-TCP
> > to HTTP-over- is that we have nothing like SDP's
> > "m=" line.  And, as you know, SDP's "m=" line doesn't really allow
> > negotiating different transports, which is where ICE and/or SDP
> Capability
> > Negotiation come in.
> >
> > For SDP to offer SCTP but also provide fallback to plain UDP or offer
> > fallback to plain TCP, I think ICE needs to be considered.
> >
> >
> > But, as for SCTP-over-UDP tunneling, I am really hoping we can just
> > not do it.  It further complicates things.  However, everyone should
> > be aware of it and make that decision themselves for the scope of
> > the MMUSIC document.
> >
> > -d
> >
> >
> >> Something like what
> >> RFC 5770 did for HIP.
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
> >> On 02/02/2011 9:55 PM, Dan Wing wrote:
> >>>> Seems reasonable to me as well. Is this a request to adopt it as a
> >> WG
> >>>> item ?
> >>>>
> >>>>
> >>>> A few quick draft comments:
> >>>> - I'm a little confused by the examples in Section 6. Why is "*"
> >> used
> >>>> as the media format ?
> >>>> - Section 6.2: Why is the media type changed from 6.1 ? Why is the
> >>>> connection shown as "new" ? Please add a note explaining why the
> >> port
> >>>> changes to 9 in the answer.
> >>>> - IANA Considerations: I believe you are defining both "SCTP" and
> >>>> "SCTP/DTLS" for IANA registration.
> >>>> - NAT considerations: In lieu of the amount of effort we have put
> >> into
> >>>> NAT traversal, I think it would be useful to add a section around
> >> this.
> >>>
> >>> On that topic, do we want draft-loreto-mmusic-sctp-sdp to include
> the
> >>> ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP is generally
> >>> necessary to traverse non-SCTP-aware firewalls and NATs.  But
> >> tunneling
> >>> SCTP over UDP brings with it other issues, including bifurcating
> SCTP
> >>> itself.
> >>>
> >>> (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
> >>>
> >>> -d
> >>>
> >>>> - Multihoming: It would be worthwhile discussing the current re-
> >> INVITE
> >>>> approach compared to an actual listing of the different addresses
> >>>> (refer to James Polk/Randy Stewart's MMUSIC message of March 18,
> >> 2009)
> >>>>
> >>>> Thanks
> >>>>
> >>>> -- Flemming
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
> >>>>
> >>>> 	Folks,
> >>>>
> >>>> 	[as an individual]
> >>>>
> >>>> 	the following draft allows offer/answer exchanges to establish
> >>>> streams
> >>>> 	that are transported by SCTP.
> >>>>
> >>>> 	http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06
> >>>>
> >>>> 	We need to decide what to do with the draft, whether to let it
> >>>> die or to
> >>>> 	progress it. The ability to describe SCTP-based streams seems
> >>>> useful
> >>>> 	even though, as we all know, SCTP is not nearly as widely
> >>>> deployed as
> >>>> 	UDP or TCP. Does anybody see any reason why the offer/answer
> >>>> model
> >>>> 	should not support SCTP-based streams?
> >>>>
> >>>> 	Your comments are appreciated.
> >>>>
> >>>> 	Thanks,
> >>>>
> >>>> 	Gonzalo
> >>>> 	_______________________________________________
> >>>> 	mmusic mailing list
> >>>> 	mmusic@ietf.org
> >>>> 	https://www.ietf.org/mailman/listinfo/mmusic
> >>>>
> >>>
> >>>
> >


From fandreas@cisco.com  Fri Feb  4 08:37:54 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603FC3A695F for ; Fri,  4 Feb 2011 08:37:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.205
X-Spam-Level: 
X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAT7rNltZ9MP for ; Fri,  4 Feb 2011 08:37:53 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 95F893A67F7 for ; Fri,  4 Feb 2011 08:37:52 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2011 16:41:17 +0000
Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p14GfHAt018319; Fri, 4 Feb 2011 16:41:17 GMT
Message-ID: <4D4C2CAF.2030506@cisco.com>
Date: Fri, 04 Feb 2011 11:43:27 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: "Dan Wing (dwing)" 
References: <4D42BE19.8060007@ericsson.com> <4D488918.4030306@cisco.com> <095101cbc313$2066e400$6134ac00$@com> <4D4A56F9.9080707@ericsson.com> <011201cbc3bb$177a41e0$466ec5a0$@com> <4D4BBC06.3080104@ericsson.com> <054801cbc486$be3c0f60$3ab42e20$@com>
In-Reply-To: <054801cbc486$be3c0f60$3ab42e20$@com>
Content-Type: multipart/alternative; boundary="------------010407030300020304090102"
Cc: Gonzalo Camarillo , mmusic 
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 04 Feb 2011 16:37:54 -0000

This is a multi-part message in MIME format.
--------------010407030300020304090102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Considering that we are likely looking at a lot of end-user endpoints 
here when considering SCTP media streams in SDP, it would seem to 
greatly facilitate the practical deployment aspects if we included 
SCTP-over-UDP (assuming SCTP-over-UDP continues to move forward).

-- Flemming



On 2/4/11 11:15 AM, Dan Wing (dwing) wrote:
>
> Another factor is that while HIP-over-UDP is RFC'd (I didn't
> say standard or experimental), SCTP-over-UDP is only an
> individual document.
>
> -d
>
>
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> > Sent: Friday, February 04, 2011 12:43 AM
> > To: Dan Wing
> > Cc: 'Flemming Andreasen'; 'mmusic'
> > Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
> >
> > Hi Dan,
> >
> > yes, it is a scope question: whether we want ICE to only use SCTP over
> > IP candidates or we want ICE to use SCTP over UDP candidates as well.
> > In
> > HIP, the hosts negotiate whether they support (and are willing to use)
> > UDP encapsulation in their base exchange. If both support it and are
> > willing to use it, they can include ESP over UDP candidates in their
> > "offers" and "answers". Otherwise, they only include ESP over IP
> > candidates.
> >
> > In this way, any implementation is free not to support UDP
> > encapsulation
> > at all. On the other hand, implementations concerned with NATs can
> > support it and use it between them to increase the likelihood of
> > establishing associations successfully.
> >
> > Cheers,
> >
> > Gonzalo
> >
> > On 03/02/2011 5:57 PM, Dan Wing wrote:
> > >> good point. It all depends on what we want to do in the NAT
> > traversal
> > >> area. If we want to define how to use ICE to establish SCTP streams,
> > >> then we should include UDP encapsulation as well.
> > >
> > > ICE should be discussed, but SCTP doesn't need to be tunneled over
> > > UDP to do that.
> > >
> > > A problem we (the industry) have with migrating from HTTP-over-TCP
> > > to HTTP-over- is that we have nothing like SDP's
> > > "m=" line.  And, as you know, SDP's "m=" line doesn't really allow
> > > negotiating different transports, which is where ICE and/or SDP
> > Capability
> > > Negotiation come in.
> > >
> > > For SDP to offer SCTP but also provide fallback to plain UDP or offer
> > > fallback to plain TCP, I think ICE needs to be considered.
> > >
> > >
> > > But, as for SCTP-over-UDP tunneling, I am really hoping we can just
> > > not do it.  It further complicates things.  However, everyone should
> > > be aware of it and make that decision themselves for the scope of
> > > the MMUSIC document.
> > >
> > > -d
> > >
> > >
> > >> Something like what
> > >> RFC 5770 did for HIP.
> > >>
> > >> Cheers,
> > >>
> > >> Gonzalo
> > >>
> > >> On 02/02/2011 9:55 PM, Dan Wing wrote:
> > >>>> Seems reasonable to me as well. Is this a request to adopt it as a
> > >> WG
> > >>>> item ?
> > >>>>
> > >>>>
> > >>>> A few quick draft comments:
> > >>>> - I'm a little confused by the examples in Section 6. Why is "*"
> > >> used
> > >>>> as the media format ?
> > >>>> - Section 6.2: Why is the media type changed from 6.1 ? Why is the
> > >>>> connection shown as "new" ? Please add a note explaining why the
> > >> port
> > >>>> changes to 9 in the answer.
> > >>>> - IANA Considerations: I believe you are defining both "SCTP" and
> > >>>> "SCTP/DTLS" for IANA registration.
> > >>>> - NAT considerations: In lieu of the amount of effort we have put
> > >> into
> > >>>> NAT traversal, I think it would be useful to add a section around
> > >> this.
> > >>>
> > >>> On that topic, do we want draft-loreto-mmusic-sctp-sdp to include
> > the
> > >>> ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP is generally
> > >>> necessary to traverse non-SCTP-aware firewalls and NATs.  But
> > >> tunneling
> > >>> SCTP over UDP brings with it other issues, including bifurcating
> > SCTP
> > >>> itself.
> > >>>
> > >>> (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps
> > >>>
> > >>> -d
> > >>>
> > >>>> - Multihoming: It would be worthwhile discussing the current re-
> > >> INVITE
> > >>>> approach compared to an actual listing of the different addresses
> > >>>> (refer to James Polk/Randy Stewart's MMUSIC message of March 18,
> > >> 2009)
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>> -- Flemming
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:
> > >>>>
> > >>>>  Folks,
> > >>>>
> > >>>>  [as an individual]
> > >>>>
> > >>>>  the following draft allows offer/answer exchanges to establish
> > >>>> streams
> > >>>>  that are transported by SCTP.
> > >>>>
> > >>>> http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06
> > >>>>
> > >>>>  We need to decide what to do with the draft, whether to let it
> > >>>> die or to
> > >>>>  progress it. The ability to describe SCTP-based streams seems
> > >>>> useful
> > >>>>  even though, as we all know, SCTP is not nearly as widely
> > >>>> deployed as
> > >>>>  UDP or TCP. Does anybody see any reason why the offer/answer
> > >>>> model
> > >>>>  should not support SCTP-based streams?
> > >>>>
> > >>>>  Your comments are appreciated.
> > >>>>
> > >>>>  Thanks,
> > >>>>
> > >>>>  Gonzalo
> > >>>>  _______________________________________________
> > >>>>  mmusic mailing list
> > >>>>  mmusic@ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/mmusic
> > >>>>
> > >>>
> > >>>
> > >
>

--------------010407030300020304090102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Considering that we are likely looking at a lot of end-user endpoints
here when considering SCTP media streams in SDP, it would seem to
greatly facilitate the practical deployment aspects if we included
SCTP-over-UDP (assuming SCTP-over-UDP continues to move forward). 



-- Flemming 







On 2/4/11 11:15 AM, Dan Wing (dwing) wrote:


  
  
  RE: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06

  
Another factor is that while HIP-over-UDP is RFC'd
(I didn't

say standard or experimental), SCTP-over-UDP is only an

individual document.

  

-d

  

  

> -----Original Message-----

> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]

> Sent: Friday, February 04, 2011 12:43 AM

> To: Dan Wing

> Cc: 'Flemming Andreasen'; 'mmusic'

> Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06

>

> Hi Dan,

>

> yes, it is a scope question: whether we want ICE to only use SCTP
over

> IP candidates or we want ICE to use SCTP over UDP candidates as
well.

> In

> HIP, the hosts negotiate whether they support (and are willing to
use)

> UDP encapsulation in their base exchange. If both support it and
are

> willing to use it, they can include ESP over UDP candidates in
their

> "offers" and "answers". Otherwise, they only include ESP over IP

> candidates.

>

> In this way, any implementation is free not to support UDP

> encapsulation

> at all. On the other hand, implementations concerned with NATs can

> support it and use it between them to increase the likelihood of

> establishing associations successfully.

>

> Cheers,

>

> Gonzalo

>

> On 03/02/2011 5:57 PM, Dan Wing wrote:

> >> good point. It all depends on what we want to do in the
NAT

> traversal

> >> area. If we want to define how to use ICE to establish
SCTP streams,

> >> then we should include UDP encapsulation as well.

> >

> > ICE should be discussed, but SCTP doesn't need to be tunneled
over

> > UDP to do that.

> >

> > A problem we (the industry) have with migrating from
HTTP-over-TCP

> > to HTTP-over-<fancy_new_transport> is that we have
nothing like SDP's

> > "m=" line.  And, as you know, SDP's "m=" line doesn't really
allow

> > negotiating different transports, which is where ICE and/or
SDP

> Capability

> > Negotiation come in.

> >

> > For SDP to offer SCTP but also provide fallback to plain UDP
or offer

> > fallback to plain TCP, I think ICE needs to be considered.

> >

> >

> > But, as for SCTP-over-UDP tunneling, I am really hoping we
can just

> > not do it.  It further complicates things.  However, everyone
should

> > be aware of it and make that decision themselves for the
scope of

> > the MMUSIC document.

> >

> > -d

> >

> >

> >> Something like what

> >> RFC 5770 did for HIP.

> >>

> >> Cheers,

> >>

> >> Gonzalo

> >>

> >> On 02/02/2011 9:55 PM, Dan Wing wrote:

> >>>> Seems reasonable to me as well. Is this a request
to adopt it as a

> >> WG

> >>>> item ?

> >>>>

> >>>>

> >>>> A few quick draft comments:

> >>>> - I'm a little confused by the examples in
Section 6. Why is "*"

> >> used

> >>>> as the media format ?

> >>>> - Section 6.2: Why is the media type changed from
6.1 ? Why is the

> >>>> connection shown as "new" ? Please add a note
explaining why the

> >> port

> >>>> changes to 9 in the answer.

> >>>> - IANA Considerations: I believe you are defining
both "SCTP" and

> >>>> "SCTP/DTLS" for IANA registration.

> >>>> - NAT considerations: In lieu of the amount of
effort we have put

> >> into

> >>>> NAT traversal, I think it would be useful to add
a section around

> >> this.

> >>>

> >>> On that topic, do we want
draft-loreto-mmusic-sctp-sdp to include

> the

> >>> ability to signal SCTP-over-UDP (*)?  SCTP-over-UDP
is generally

> >>> necessary to traverse non-SCTP-aware firewalls and
NATs.  But

> >> tunneling

> >>> SCTP over UDP brings with it other issues, including
bifurcating

> SCTP

> >>> itself.

> >>>

> >>> (*) http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps

> >>>

> >>> -d

> >>>

> >>>> - Multihoming: It would be worthwhile discussing
the current re-

> >> INVITE

> >>>> approach compared to an actual listing of the
different addresses

> >>>> (refer to James Polk/Randy Stewart's MMUSIC
message of March 18,

> >> 2009)

> >>>>

> >>>> Thanks

> >>>>

> >>>> -- Flemming

> >>>>

> >>>>

> >>>>

> >>>>

> >>>> On 1/28/11 8:01 AM, Gonzalo Camarillo wrote:

> >>>>

> >>>>  Folks,

> >>>>

> >>>>  [as an individual]

> >>>>

> >>>>  the following draft allows offer/answer
exchanges to establish

> >>>> streams

> >>>>  that are transported by SCTP.

> >>>>

> >>>>  http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-06

> >>>>

> >>>>  We need to decide what to do with the draft,
whether to let it

> >>>> die or to

> >>>>  progress it. The ability to describe SCTP-based
streams seems

> >>>> useful

> >>>>  even though, as we all know, SCTP is not nearly
as widely

> >>>> deployed as

> >>>>  UDP or TCP. Does anybody see any reason why the
offer/answer

> >>>> model

> >>>>  should not support SCTP-based streams?

> >>>>

> >>>>  Your comments are appreciated.

> >>>>

> >>>>  Thanks,

> >>>>

> >>>>  Gonzalo

> >>>>  _______________________________________________

> >>>>  mmusic mailing list

> >>>>  mmusic@ietf.org

> >>>>  https://www.ietf.org/mailman/listinfo/mmusic

> >>>>

> >>>

> >>>

> >

  

  
  






--------------010407030300020304090102--

From Simo.Veikkolainen@nokia.com  Mon Feb  7 03:52:33 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A3B3A6C80 for ; Mon,  7 Feb 2011 03:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-4ihR3QGHIG for ; Mon,  7 Feb 2011 03:52:32 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 7447C3A69A8 for ; Mon,  7 Feb 2011 03:52:32 -0800 (PST)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p17BqXdv032201; Mon, 7 Feb 2011 13:52:34 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 7 Feb 2011 13:52:05 +0200
Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 Feb 2011 12:52:04 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi; Mon, 7 Feb 2011 12:52:04 +0100
From: 
To: 
Thread-Topic: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
Thread-Index: AQHLwyTg/83x22pCHkaqbdNtAedVz5PvX+WggACOswCABgUasA==
Date: Mon, 7 Feb 2011 11:52:03 +0000
Message-ID: 
References: <4D49D4DC.40900@cisco.com>  <4D4ADD70.1070008@cisco.com>
In-Reply-To: <4D4ADD70.1070008@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2011 11:52:05.0145 (UTC) FILETIME=[70A94090:01CBC6BD]
X-Nokia-AV: Clean
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Feb 2011 11:52:33 -0000

From: ext Flemming Andreasen [mailto:fandreas@cisco.com]=20
Sent: 03 February, 2011 18:53
To: Veikkolainen Simo (Nokia-MS/Helsinki)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG ite=
m

Thanks for the updates Simo. A few follow-ups below...



- Section 3.1, "Therefore, capabilities referenced by any configuration att=
ribute MUST appear at the media level when a configuration is "converted" t=
o a corresponding media block"
I'm not sure how to interpret this paragraph. Please elaborate/clarify text=
=A0

[SV] The intention has been to say that even though "i=3D" can appear eithe=
r at session or media level, we are defining the "icap" attribute only for =
media level. I think the sentence becomes clearer by just deleting "..when =
a configuration is "converted" to a corresponding media block".

I think you should elaborate on the text so there is no confusion between c=
apabilities being present at the session-level and media-level versus gener=
ating a configuration from a pcfg attribute present within a media descript=
ion that references them, and hence effectively instantiates them at the me=
dia-level (except for session-level attributes, which is fraught with chall=
enges as per RFC 5939). An accompanying example may help as well.=20

[SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST appea=
r only at media level. Therefore, the "icap" and "bcap" capabilities refere=
nced by pcfg attribute are always on media level.=20

Simo


From Simo.Veikkolainen@nokia.com  Mon Feb  7 04:40:16 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39683A6DE8 for ; Mon,  7 Feb 2011 04:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz9TwLtWVFW3 for ; Mon,  7 Feb 2011 04:40:15 -0800 (PST)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 989A43A6D04 for ; Mon,  7 Feb 2011 04:40:14 -0800 (PST)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p17CeFb6027486; Mon, 7 Feb 2011 14:40:15 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 7 Feb 2011 14:40:07 +0200
Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 Feb 2011 13:40:06 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Mon, 7 Feb 2011 13:40:06 +0100
From: 
To: 
Thread-Topic: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
Thread-Index: AQHLwyTg/83x22pCHkaqbdNtAedVz5PvX+WggACOswCABhDpYA==
Date: Mon, 7 Feb 2011 12:40:04 +0000
Message-ID: 
References: <4D49D4DC.40900@cisco.com>  <4D4ADD70.1070008@cisco.com>
In-Reply-To: <4D4ADD70.1070008@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2011 12:40:07.0208 (UTC) FILETIME=[26812A80:01CBC6C4]
X-Nokia-AV: Clean
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Feb 2011 12:40:16 -0000

Hi,
See below (again with [SV]).

---

From: ext Flemming Andreasen [mailto:fandreas@cisco.com]=20
Sent: 03 February, 2011 18:53
To: Veikkolainen Simo (Nokia-MS/Helsinki)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG ite=
m

Thanks for the updates Simo. A few follow-ups below...



- Section 3.1, "Therefore, capabilities referenced by any configuration att=
ribute MUST appear at the media level when a configuration is "converted" t=
o a corresponding media block"
I'm not sure how to interpret this paragraph. Please elaborate/clarify text=
=A0

[SV] The intention has been to say that even though "i=3D" can appear eithe=
r at session or media level, we are defining the "icap" attribute only for =
media level. I think the sentence becomes clearer by just deleting "..when =
a configuration is "converted" to a corresponding media block".
I think you should elaborate on the text so there is no confusion between c=
apabilities being present at the session-level and media-level versus gener=
ating a configuration from a pcfg attribute present within a media descript=
ion that references them, and hence effectively instantiates them at the me=
dia-level (except for session-level attributes, which is fraught with chall=
enges as per RFC 5939). An accompanying example may help as well.=20

[SV] I sent a separate email on this.


- Section 3.1.1.1, first paragraph after ABNF:
What does it mean to have more than one of these, and in particular, can th=
ere be more than one with a given bw-type ?
Also s/b-/bw-/

[SV] Hmm, good catch. I would assume there is only one "b=3D" line for each=
 media block. Or are there cases when more than one bandwidth value would b=
e needed? If this is the case, then also in the configuration parameters it=
 would suffice to only have one.

You can have different bandwidth types, so I can see where you might want t=
o have more than one "b=3D" line per configuration, however I'm not sure I =
see how it would be useful to have different values for the same bw-type wi=
thin a given potential configuration (which one do you pick, and why ?)=20

[SV] Right, but now looking at RFC4566 it does not say anything about havin=
g different values for the same bwtype in the same media block. I'm not sur=
e we should limit this either, even though I agree there might not be use i=
t.=20

- Section 3.1.2.1, ABNF: Missing the optional "+" and associated descriptio=
n of it.

[SV] Here we thought that the "+" would not be needed since it is unlikely =
that the potential configuration should be rejected if the media title capa=
bility is not supported. Do you see this differently?
Not really, but since RFC 5939 includes the "+" for extensions, and there d=
oesn't seem to be any harm in allowing it here either, I would include it f=
or consistency with a note that you wouldn't normally expect it to be used =
(but then again, you never know what use cases people come up with).=20

[SV] Ok we can add it for consistency.

Also, When would you have more than one media title in a given pcfg ? Can y=
ou give an example ?

[SV] I'm tempted to limit also this one to only one, unless I hear objectio=
ns.

One seems right to me as well.=20

[SV] Ok.

- Section 3.1.2.2: May want to add a comment about use of "+" not being ver=
y likely either (or maybe include that as part of previous comment).

[SV] Do we need the "+" at all? For consistency's sake I guess yes, but is =
there a use case?
I can come up with a contrived use case if necessary, but it's not obvious.=
 I'd keep it for consistency.=20

[SV] Ok.

- Section ?: Missing an offer/answer section.

[SV] You mean a section defining the offerer and answerer behaviour like in=
 Media capabilities draft Section 3.4? I guess we could add such a section.
Sounds good.=20

[SV] Coming up in next version.

Simo


[SV] Done.

- Section 6: Security considerations need to be expanded with specific cons=
iderations for these parameters (e.g. specific threats)

[SV] Do you have any specific examples mind?

Describe what happens if an attacker is able to change one or more of these=
 new parameters. The bw in particular seems to be the one that might have s=
ome ramifications, since choice of a potential configuration could be affec=
ted by its expected bw usage (and hence you could launch a denial of servic=
e attack this way, or at least impact the service quality). Changing title =
information seems more like a nuisance, but still, if it's used to select b=
etween configurations (e.g. via human interaction), it could impact service=
. The mechanisms to address these threats are the same as in RFC 5939 I bel=
ieve, however we need to ensure people understand the threats they are face=
d with.=A0=20

Thanks

-- Flemming=20




From Simo.Veikkolainen@nokia.com  Mon Feb  7 05:39:17 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44863A6E0F for ; Mon,  7 Feb 2011 05:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXbB4rfW8sEJ for ; Mon,  7 Feb 2011 05:39:16 -0800 (PST)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 94EC33A6E0A for ; Mon,  7 Feb 2011 05:39:16 -0800 (PST)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p17DcCYp007090; Mon, 7 Feb 2011 15:38:13 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 7 Feb 2011 15:38:03 +0200
Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 7 Feb 2011 14:38:02 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Mon, 7 Feb 2011 14:38:02 +0100
From: 
To: , 
Thread-Topic: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
Thread-Index: AQHLwyTg/83x22pCHkaqbdNtAedVz5PvX+WggACOswCABgUasIAAHZ2A
Date: Mon, 7 Feb 2011 13:38:01 +0000
Message-ID: 
References: <4D49D4DC.40900@cisco.com>  <4D4ADD70.1070008@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2011 13:38:03.0345 (UTC) FILETIME=[3E719410:01CBC6CC]
X-Nokia-AV: Clean
Cc: miguel.a.garcia@ericsson.com, mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Feb 2011 13:39:17 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)
> Sent: 07 February, 2011 13:52
> To: fandreas@cisco.com
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
> item
>=20
> From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: 03 February, 2011 18:53
> To: Veikkolainen Simo (Nokia-MS/Helsinki)
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
> item
>=20
> Thanks for the updates Simo. A few follow-ups below...
>=20
>=20
>=20
> - Section 3.1, "Therefore, capabilities referenced by any configuration
> attribute MUST appear at the media level when a configuration is
> "converted" to a corresponding media block"
> I'm not sure how to interpret this paragraph. Please elaborate/clarify
> text
>=20
> [SV] The intention has been to say that even though "i=3D" can appear
> either at session or media level, we are defining the "icap" attribute
> only for media level. I think the sentence becomes clearer by just
> deleting "..when a configuration is "converted" to a corresponding
> media block".
>=20
> I think you should elaborate on the text so there is no confusion
> between capabilities being present at the session-level and media-level
> versus generating a configuration from a pcfg attribute present within
> a media description that references them, and hence effectively
> instantiates them at the media-level (except for session-level
> attributes, which is fraught with challenges as per RFC 5939). An
> accompanying example may help as well.
>=20
> [SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST
> appear only at media level. Therefore, the "icap" and "bcap"
> capabilities referenced by pcfg attribute are always on media level.

Correcting myself. We have the following piece of text in Section 3.2:

	  The icap and bcap attributes can appear at the session
	  level and/or at the media level, but MUST be interpreted
	  as a media-level capability,

so I guess we could either do
1) declare icap and bcap as media-level only, or
2) describe in more detail in this section how session-level capability att=
ributes should be treated.

Option 1) could be simpler to implement and understand, while 2) would prov=
ide more generality. Any opinions?

Simo
=20
> Simo
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From john.elwell@siemens-enterprise.com  Mon Feb  7 07:02:28 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA6D3A6DD3 for ; Mon,  7 Feb 2011 07:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK0nLi11-7Fb for ; Mon,  7 Feb 2011 07:02:27 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9D49D3A6D8C for ; Mon,  7 Feb 2011 07:02:27 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3299228 for mmusic@ietf.org; Mon, 7 Feb 2011 16:02:30 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 72BAF1EB82BB for ; Mon,  7 Feb 2011 16:02:30 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 7 Feb 2011 16:02:30 +0100
From: "Elwell, John" 
To: mmusic 
Date: Mon, 7 Feb 2011 16:02:29 +0100
Thread-Topic: Draft-elwell-ice-updated-offer (was RE: [MMUSIC] Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4A
Message-ID: 
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>
In-Reply-To: <4CFAA584.8080507@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Feb 2011 15:02:29 -0000

In response to Gonzalo's request for a better understanding  of the issues =
that keep ICE from being widely deployed, I have submitted a new I-D on pro=
blems arising from the updated SDP offer that ICE requires under some circu=
mstances:
https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updated-offer/

Comments welcome.

John


> -----Original Message-----
> From: mmusic-bounces@ietf.org=20
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> Sent: 04 December 2010 20:33
> To: Flemming Andreasen
> Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20
> draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic
> Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20
> draft-ietf-mmusic-media-loopback-14 review and comments)
>=20
> Hi,
>=20
> >> - NAT Traversal and usage of ICE
> >>
> >> [Authors] As Hadriel mentioned, if you have ICE you don't need the
> >> loopback primer. As he also clarified, the loopback situation is
> >> different from standard calls because the mirror will never send a
> >> packet until it receives something from the source. This=20
> is certainly
> >> possible for a regular call and calls may fail for that reason, but
> >> the loopback draft is dead without a solution for this problem.
> >> Remember that the primary use case for this draft is=20
> service providers
> >> wanting to test to subscriber devices that are almost always behind
> >> NATs. The proposed solution meets the requirements for the dominant
> >> use case and while standard solutions are certainly usable=20
> when they
> >> are available, the unfortunate reality is that most of them are not
> >> implemented. We can add clarification text that if available ICE
> >> should be used instead of the loopback primer method.
> >>
> > Thanks. The draft will also need to clearly explain how the loopback
> > primer would work, and in particular what the underlying=20
> assumptions are
> > (e.g. latching) as well as when it will not work (e.g. when=20
> both source
> > and mirror are behind a NAT, when you have overlapping=20
> IP-addresses and
> > ports, etc). In short, the limitations of this approach=20
> must be clearly
> > documented.
> >=20
> > I will also check with our AD as to whether there are any additional
> > concerns with specifying such a solution when we already=20
> have ICE as the
> > Standard.
>=20
> as you all know, there have been a number of proposals to standardize
> simpler-than-ICE NAT traversal solutions that would only work=20
> in certain
> scenarios or circumstances. There have been a lot of=20
> discussions around
> them. A couple of IETFs ago there was even a bar BOF where=20
> people tried
> to understand the issues that kept folks from deploying ICE in some
> scenarios. I know there have been off-list follow ups on those
> discussions but no draft have been submitted yet, AFAIK.
>=20
> So, we need to frame this discussion taking into account the=20
> big picture
> of NAT traversal and ICE. In this case, we need to understand=20
> the issues
> that keep ICE from being widely deployed and, if needed, specify a
> general solution to address those issues. Coming up with several
> different NAT traversal mechanisms that only work in specific=20
> conditions
> does not seem like the best outcome we can wish for.
>=20
> I encourage people who are working on those ICE-related issues to
> participate in this discussion because this is an important area.
>=20
> Thanks,
>=20
> Gonzalo
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> =

From christer.holmberg@ericsson.com  Tue Feb  8 05:52:46 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD7C3A6DDF for ; Tue,  8 Feb 2011 05:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNVr8TmW9qwj for ; Tue,  8 Feb 2011 05:52:45 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EABC63A6924 for ; Tue,  8 Feb 2011 05:52:44 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-23-4d514ab20798
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A1.51.13987.2BA415D4; Tue,  8 Feb 2011 14:52:50 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 8 Feb 2011 14:52:50 +0100
From: Christer Holmberg 
To: "Elwell, John" , mmusic 
Date: Tue, 8 Feb 2011 14:52:49 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DA=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 13:52:46 -0000

Hi John,

Wouldn't the usage of RFC 3262 be a potential solution also for the fax cas=
e, if it would be able to send the candidate update before 200 OK?

Regards,

Christer
=20

> -----Original Message-----
> From: mmusic-bounces@ietf.org=20
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Elwell, John
> Sent: 7. helmikuuta 2011 17:02
> To: mmusic
> Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet=20
> another alternative to ICE)
>=20
> In response to Gonzalo's request for a better understanding =20
> of the issues that keep ICE from being widely deployed, I=20
> have submitted a new I-D on problems arising from the updated=20
> SDP offer that ICE requires under some circumstances:
> https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat
> ed-offer/
>=20
> Comments welcome.
>=20
> John
>=20
>=20
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org
> > [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> > Sent: 04 December 2010 20:33
> > To: Flemming Andreasen
> > Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20
> > draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic
> > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20
> > draft-ietf-mmusic-media-loopback-14 review and comments)
> >=20
> > Hi,
> >=20
> > >> - NAT Traversal and usage of ICE
> > >>
> > >> [Authors] As Hadriel mentioned, if you have ICE you=20
> don't need the=20
> > >> loopback primer. As he also clarified, the loopback situation is=20
> > >> different from standard calls because the mirror will=20
> never send a=20
> > >> packet until it receives something from the source. This
> > is certainly
> > >> possible for a regular call and calls may fail for that=20
> reason, but=20
> > >> the loopback draft is dead without a solution for this problem.
> > >> Remember that the primary use case for this draft is
> > service providers
> > >> wanting to test to subscriber devices that are almost=20
> always behind=20
> > >> NATs. The proposed solution meets the requirements for=20
> the dominant=20
> > >> use case and while standard solutions are certainly usable
> > when they
> > >> are available, the unfortunate reality is that most of=20
> them are not=20
> > >> implemented. We can add clarification text that if available ICE=20
> > >> should be used instead of the loopback primer method.
> > >>
> > > Thanks. The draft will also need to clearly explain how=20
> the loopback=20
> > > primer would work, and in particular what the underlying
> > assumptions are
> > > (e.g. latching) as well as when it will not work (e.g. when
> > both source
> > > and mirror are behind a NAT, when you have overlapping
> > IP-addresses and
> > > ports, etc). In short, the limitations of this approach
> > must be clearly
> > > documented.
> > >=20
> > > I will also check with our AD as to whether there are any=20
> additional=20
> > > concerns with specifying such a solution when we already
> > have ICE as the
> > > Standard.
> >=20
> > as you all know, there have been a number of proposals to=20
> standardize=20
> > simpler-than-ICE NAT traversal solutions that would only work in=20
> > certain scenarios or circumstances. There have been a lot of=20
> > discussions around them. A couple of IETFs ago there was even a bar=20
> > BOF where people tried to understand the issues that kept=20
> folks from=20
> > deploying ICE in some scenarios. I know there have been off-list=20
> > follow ups on those discussions but no draft have been=20
> submitted yet,=20
> > AFAIK.
> >=20
> > So, we need to frame this discussion taking into account the big=20
> > picture of NAT traversal and ICE. In this case, we need to=20
> understand=20
> > the issues that keep ICE from being widely deployed and, if needed,=20
> > specify a general solution to address those issues. Coming up with=20
> > several different NAT traversal mechanisms that only work=20
> in specific=20
> > conditions does not seem like the best outcome we can wish for.
> >=20
> > I encourage people who are working on those ICE-related issues to=20
> > participate in this discussion because this is an important area.
> >=20
> > Thanks,
> >=20
> > Gonzalo
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> =

From fandreas@cisco.com  Tue Feb  8 10:12:35 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C263A6813 for ; Tue,  8 Feb 2011 10:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZGZq8rk9tdD for ; Tue,  8 Feb 2011 10:12:33 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3F7243A6812 for ; Tue,  8 Feb 2011 10:12:33 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAH0WUU1AZnwN/2dsb2JhbACgSIRrc6EYmzWFWgSEe4Zv
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 18:12:39 +0000
Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18ICdBi004102; Tue, 8 Feb 2011 18:12:39 GMT
Message-ID: <4D51881C.1080407@cisco.com>
Date: Tue, 08 Feb 2011 13:14:52 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: Simo.Veikkolainen@nokia.com
References: <4D49D4DC.40900@cisco.com>  <4D4ADD70.1070008@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090703070400030107000506"
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 18:12:35 -0000

This is a multi-part message in MIME format.
--------------090703070400030107000506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 2/7/11 7:40 AM, Simo.Veikkolainen@nokia.com wrote:
>
> Hi,
> See below (again with [SV]).
>
> ---
>
> From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: 03 February, 2011 18:53
> To: Veikkolainen Simo (Nokia-MS/Helsinki)
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and 
> WG item
>
> Thanks for the updates Simo. A few follow-ups below...
>
>
>
> - Section 3.1, "Therefore, capabilities referenced by any 
> configuration attribute MUST appear at the media level when a 
> configuration is "converted" to a corresponding media block"
> I'm not sure how to interpret this paragraph. Please elaborate/clarify 
> text
>
> [SV] The intention has been to say that even though "i=" can appear 
> either at session or media level, we are defining the "icap" attribute 
> only for media level. I think the sentence becomes clearer by just 
> deleting "..when a configuration is "converted" to a corresponding 
> media block".
> I think you should elaborate on the text so there is no confusion 
> between capabilities being present at the session-level and 
> media-level versus generating a configuration from a pcfg attribute 
> present within a media description that references them, and hence 
> effectively instantiates them at the media-level (except for 
> session-level attributes, which is fraught with challenges as per RFC 
> 5939). An accompanying example may help as well.
>
> [SV] I sent a separate email on this.
>
ok
>
>
> - Section 3.1.1.1, first paragraph after ABNF:
> What does it mean to have more than one of these, and in particular, 
> can there be more than one with a given bw-type ?
> Also s/b-/bw-/
>
> [SV] Hmm, good catch. I would assume there is only one "b=" line for 
> each media block. Or are there cases when more than one bandwidth 
> value would be needed? If this is the case, then also in the 
> configuration parameters it would suffice to only have one.
>
> You can have different bandwidth types, so I can see where you might 
> want to have more than one "b=" line per configuration, however I'm 
> not sure I see how it would be useful to have different values for the 
> same bw-type within a given potential configuration (which one do you 
> pick, and why ?)
>
> [SV] Right, but now looking at RFC4566 it does not say anything about 
> having different values for the same bwtype in the same media block. 
> I'm not sure we should limit this either, even though I agree there 
> might not be use it.
>
ok - maybe just add an informative note about it then.


> - Section 3.1.2.1, ABNF: Missing the optional "+" and associated 
> description of it.
>
> [SV] Here we thought that the "+" would not be needed since it is 
> unlikely that the potential configuration should be rejected if the 
> media title capability is not supported. Do you see this differently?
> Not really, but since RFC 5939 includes the "+" for extensions, and 
> there doesn't seem to be any harm in allowing it here either, I would 
> include it for consistency with a note that you wouldn't normally 
> expect it to be used (but then again, you never know what use cases 
> people come up with).
>
> [SV] Ok we can add it for consistency.
>
> Also, When would you have more than one media title in a given pcfg ? 
> Can you give an example ?
>
> [SV] I'm tempted to limit also this one to only one, unless I hear 
> objections.
>
> One seems right to me as well.
>
> [SV] Ok.
>
> - Section 3.1.2.2: May want to add a comment about use of "+" not 
> being very likely either (or maybe include that as part of previous 
> comment).
>
> [SV] Do we need the "+" at all? For consistency's sake I guess yes, 
> but is there a use case?
> I can come up with a contrived use case if necessary, but it's not 
> obvious. I'd keep it for consistency.
>
> [SV] Ok.
>
> - Section ?: Missing an offer/answer section.
>
> [SV] You mean a section defining the offerer and answerer behaviour 
> like in Media capabilities draft Section 3.4? I guess we could add 
> such a section.
> Sounds good.
>
> [SV] Coming up in next version.
>
> Simo
>
>
> [SV] Done.
>
Thanks

-- Flemming

> - Section 6: Security considerations need to be expanded with specific 
> considerations for these parameters (e.g. specific threats)
>
> [SV] Do you have any specific examples mind?
>
> Describe what happens if an attacker is able to change one or more of 
> these new parameters. The bw in particular seems to be the one that 
> might have some ramifications, since choice of a potential 
> configuration could be affected by its expected bw usage (and hence 
> you could launch a denial of service attack this way, or at least 
> impact the service quality). Changing title information seems more 
> like a nuisance, but still, if it's used to select between 
> configurations (e.g. via human interaction), it could impact service. 
> The mechanisms to address these threats are the same as in RFC 5939 I 
> believe, however we need to ensure people understand the threats they 
> are faced with.
>
> Thanks
>
> -- Flemming
>
>
>

--------------090703070400030107000506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  






On 2/7/11 7:40 AM, Simo.Veikkolainen@nokia.com wrote:


  
  
  RE: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
item

  
Hi,

See below (again with [SV]).

  

---

  

From: ext Flemming Andreasen [mailto:fandreas@cisco.com]

Sent: 03 February, 2011 18:53

To: Veikkolainen Simo (Nokia-MS/Helsinki)

Cc: mmusic@ietf.org

Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
item

  

Thanks for the updates Simo. A few follow-ups below...

  

  

  

- Section 3.1, "Therefore, capabilities referenced by any configuration
attribute MUST appear at the media level when a configuration is
"converted" to a corresponding media block"

I'm not sure how to interpret this paragraph. Please elaborate/clarify
text 

  

[SV] The intention has been to say that even though "i=" can appear
either at session or media level, we are defining the "icap" attribute
only for media level. I think the sentence becomes clearer by just
deleting "..when a configuration is "converted" to a corresponding
media block".

I think you should elaborate on the text so there is no confusion
between capabilities being present at the session-level and media-level
versus generating a configuration from a pcfg attribute present within
a media description that references them, and hence effectively
instantiates them at the media-level (except for session-level
attributes, which is fraught with challenges as per RFC 5939). An
accompanying example may help as well.

  

[SV] I sent a separate email on this.

  

  



ok



  


- Section 3.1.1.1, first paragraph after ABNF:

What does it mean to have more than one of these, and in particular,
can there be more than one with a given bw-type ?

Also s/b-/bw-/

  

[SV] Hmm, good catch. I would assume there is only one "b=" line for
each media block. Or are there cases when more than one bandwidth value
would be needed? If this is the case, then also in the configuration
parameters it would suffice to only have one.

  

You can have different bandwidth types, so I can see where you might
want to have more than one "b=" line per configuration, however I'm not
sure I see how it would be useful to have different values for the same
bw-type within a given potential configuration (which one do you pick,
and why ?)

  

[SV] Right, but now looking at RFC4566 it does not say anything about
having different values for the same bwtype in the same media block.
I'm not sure we should limit this either, even though I agree there
might not be use it.

  

  



ok - maybe just add an informative note about it then. 







  
- Section 3.1.2.1, ABNF: Missing the optional "+"
and associated description of it.

  

[SV] Here we thought that the "+" would not be needed since it is
unlikely that the potential configuration should be rejected if the
media title capability is not supported. Do you see this differently?

Not really, but since RFC 5939 includes the "+" for extensions, and
there doesn't seem to be any harm in allowing it here either, I would
include it for consistency with a note that you wouldn't normally
expect it to be used (but then again, you never know what use cases
people come up with).

  

[SV] Ok we can add it for consistency.

  

Also, When would you have more than one media title in a given pcfg ?
Can you give an example ?

  

[SV] I'm tempted to limit also this one to only one, unless I hear
objections.

  

One seems right to me as well.

  

[SV] Ok.

  

- Section 3.1.2.2: May want to add a comment about use of "+" not being
very likely either (or maybe include that as part of previous comment).

  

[SV] Do we need the "+" at all? For consistency's sake I guess yes, but
is there a use case?

I can come up with a contrived use case if necessary, but it's not
obvious. I'd keep it for consistency.

  

[SV] Ok.

  

- Section ?: Missing an offer/answer section.

  

[SV] You mean a section defining the offerer and answerer behaviour
like in Media capabilities draft Section 3.4? I guess we could add such
a section.

Sounds good.

  

[SV] Coming up in next version.

  

Simo

  

  

[SV] Done.

  

  



Thanks 



-- Flemming 





  
- Section 6: Security considerations need to be
expanded with specific considerations for these parameters (e.g.
specific threats)

  

[SV] Do you have any specific examples mind?

  

Describe what happens if an attacker is able to change one or more of
these new parameters. The bw in particular seems to be the one that
might have some ramifications, since choice of a potential
configuration could be affected by its expected bw usage (and hence you
could launch a denial of service attack this way, or at least impact
the service quality). Changing title information seems more like a
nuisance, but still, if it's used to select between configurations
(e.g. via human interaction), it could impact service. The mechanisms
to address these threats are the same as in RFC 5939 I believe, however
we need to ensure people understand the threats they are faced with. 

  

Thanks

  

-- Flemming

  

  

  

  
  






--------------090703070400030107000506--

From fandreas@cisco.com  Tue Feb  8 10:36:02 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BE93A6823 for ; Tue,  8 Feb 2011 10:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaltEhwnZoK9 for ; Tue,  8 Feb 2011 10:36:01 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 176703A6821 for ; Tue,  8 Feb 2011 10:36:01 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGQcUU1AZnwM/2dsb2JhbACgTIRrc6EemzmFWgSEe4Zv
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 18:36:08 +0000
Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p18Ia7kq002637; Tue, 8 Feb 2011 18:36:07 GMT
Message-ID: <4D518D9D.8060509@cisco.com>
Date: Tue, 08 Feb 2011 13:38:21 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: Simo.Veikkolainen@nokia.com
References: <4D49D4DC.40900@cisco.com><4D4ADD70.1070008@cisco.com>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030209000102030506050104"
Cc: miguel.a.garcia@ericsson.com, mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 18:36:02 -0000

This is a multi-part message in MIME format.
--------------030209000102030506050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 2/7/11 8:38 AM, Simo.Veikkolainen@nokia.com wrote:
>
>
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)
> > Sent: 07 February, 2011 13:52
> > To: fandreas@cisco.com
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
> > item
> >
> > From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: 03 February, 2011 18:53
> > To: Veikkolainen Simo (Nokia-MS/Helsinki)
> > Cc: mmusic@ietf.org
> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
> > item
> >
> > Thanks for the updates Simo. A few follow-ups below...
> >
> >
> >
> > - Section 3.1, "Therefore, capabilities referenced by any configuration
> > attribute MUST appear at the media level when a configuration is
> > "converted" to a corresponding media block"
> > I'm not sure how to interpret this paragraph. Please elaborate/clarify
> > text
> >
> > [SV] The intention has been to say that even though "i=" can appear
> > either at session or media level, we are defining the "icap" attribute
> > only for media level. I think the sentence becomes clearer by just
> > deleting "..when a configuration is "converted" to a corresponding
> > media block".
> >
> > I think you should elaborate on the text so there is no confusion
> > between capabilities being present at the session-level and media-level
> > versus generating a configuration from a pcfg attribute present within
> > a media description that references them, and hence effectively
> > instantiates them at the media-level (except for session-level
> > attributes, which is fraught with challenges as per RFC 5939). An
> > accompanying example may help as well.
> >
> > [SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST
> > appear only at media level. Therefore, the "icap" and "bcap"
> > capabilities referenced by pcfg attribute are always on media level.
>
> Correcting myself. We have the following piece of text in Section 3.2:
>
>           The icap and bcap attributes can appear at the session
>           level and/or at the media level, but MUST be interpreted
>           as a media-level capability,
>
Yeah, and I suspect this was probably introduced with an eye towards the 
latent configuration mechanism defined by the media capabilities draft.


> so I guess we could either do
> 1) declare icap and bcap as media-level only, or
> 2) describe in more detail in this section how session-level 
> capability attributes should be treated.
>
> Option 1) could be simpler to implement and understand, while 2) would 
> provide more generality. Any opinions?
>
My understanding is that the bcap and icap attributes are specifically 
defined for the media-level only currently in the draft, but maybe it 
needs to be made clearer. It gets tricky when we mix types that can 
appear at both the session and media-level, and then start interpreting 
what they actually are, *not* based on whether they indeed are at the 
session or the media-level, but how they are referenced. The latent 
configuration attribute ("lcfg") in the media capabilities draft 
currently relies on this, however I'm not keen on it (opens up a can of 
worms). The media capabilities authors are discussing this and, assuming 
the only reason you want to allow the above is for latent 
configurations, then I think we need to settle that discussion first. 
Alternatively, you could adopt wording similar to Section 3.4.1 in RFC 
5939, which deals with the same problem for attribute capabilities (and 
basically only defines usage at the media-level, but allows for the 
media capabilities framework to extend that and define procedures above 
and beyond the media-leve only procedures defined in RFC 5939).

-- Flemming


> Simo
>
> > Simo
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>

--------------030209000102030506050104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  






On 2/7/11 8:38 AM, Simo.Veikkolainen@nokia.com wrote:


  
  
  RE: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
item

  

  

  
> -----Original Message-----

> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On

> Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)

> Sent: 07 February, 2011 13:52

> To: fandreas@cisco.com

> Cc: mmusic@ietf.org

> Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments
and WG

> item

>

> From: ext Flemming Andreasen [mailto:fandreas@cisco.com]

> Sent: 03 February, 2011 18:53

> To: Veikkolainen Simo (Nokia-MS/Helsinki)

> Cc: mmusic@ietf.org

> Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments
and WG

> item

>

> Thanks for the updates Simo. A few follow-ups below...

>

>

>

> - Section 3.1, "Therefore, capabilities referenced by any
configuration

> attribute MUST appear at the media level when a configuration is

> "converted" to a corresponding media block"

> I'm not sure how to interpret this paragraph. Please
elaborate/clarify

> text

>

> [SV] The intention has been to say that even though "i=" can appear

> either at session or media level, we are defining the "icap"
attribute

> only for media level. I think the sentence becomes clearer by just

> deleting "..when a configuration is "converted" to a corresponding

> media block".

>

> I think you should elaborate on the text so there is no confusion

> between capabilities being present at the session-level and
media-level

> versus generating a configuration from a pcfg attribute present
within

> a media description that references them, and hence effectively

> instantiates them at the media-level (except for session-level

> attributes, which is fraught with challenges as per RFC 5939). An

> accompanying example may help as well.

>

> [SV] I'm not sure I follow you. We define that "icap" and "bcap"
MUST

> appear only at media level. Therefore, the "icap" and "bcap"

> capabilities referenced by pcfg attribute are always on media
level.

  

Correcting myself. We have the following piece of text in Section 3.2:

  

          The icap and bcap attributes can appear at the session

          level and/or at the media level, but MUST be interpreted

          as a media-level capability,

  

  



Yeah, and I suspect this was probably introduced with an eye towards
the latent configuration mechanism defined by the media capabilities
draft. 







  
so I guess we could either do

1) declare icap and bcap as media-level only, or

2) describe in more detail in this section how session-level capability
attributes should be treated.

  

Option 1) could be simpler to implement and understand, while 2) would
provide more generality. Any opinions?

  

  



My understanding is that the bcap and icap attributes are specifically
defined for the media-level only currently in the draft, but maybe it
needs to be made clearer. It gets tricky when we mix types that can
appear at both the session and media-level, and then start interpreting
what they actually are, *not* based on whether they indeed are at the
session or the media-level, but how they are referenced. The latent
configuration attribute ("lcfg") in the media capabilities draft
currently relies on this, however I'm not keen on it (opens up a can of
worms). The media capabilities authors are discussing this and,
assuming the only reason you want to allow the above is for latent
configurations, then I think we need to settle that discussion first.
Alternatively, you could adopt wording similar to Section 3.4.1 in RFC
5939, which deals with the same problem for attribute capabilities (and
basically only defines usage at the media-level, but allows for the
media capabilities framework to extend that and define procedures above
and beyond the media-leve only procedures defined in RFC 5939). 



-- Flemming 







  
Simo

  

> Simo

>

> _______________________________________________

> mmusic mailing list

> mmusic@ietf.org

> https://www.ietf.org/mailman/listinfo/mmusic

  
  






--------------030209000102030506050104--

From fandreas@cisco.com  Tue Feb  8 10:49:37 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743F33A67F5 for ; Tue,  8 Feb 2011 10:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLkyRJTufGEI for ; Tue,  8 Feb 2011 10:49:36 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9DEBD3A67D6 for ; Tue,  8 Feb 2011 10:49:36 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALAeUU1AZnwN/2dsb2JhbAClN3OhIJs5hVoEhHuGbw
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2011 18:49:43 +0000
Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18Inhsn017319; Tue, 8 Feb 2011 18:49:43 GMT
Message-ID: <4D5190CD.5090008@cisco.com>
Date: Tue, 08 Feb 2011 13:51:57 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: mmusic 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Tom Taylor 
Subject: [MMUSIC] MMUSIC Agenda Items for IETF 80 (Prague) ?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 18:49:37 -0000

Hi

IETF 80 will be here before we know it, and now would be a good time to 
think about what we should be discussing. If you have an agenda item, 
please let the chairs know, and include the following:

- Topics to be discussed
- Amount of time requested
- Reference to existing (or expected) draft.

To ensure a productive meeting, please make sure that your topics are 
raised on the mailing list sufficiently in advance of our meeting so we 
can spend our time trying to resolve them rather than just presenting them.

Thanks

     Tom & Flemming








From bob_gilman@comcast.net  Tue Feb  8 11:21:40 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1EC3A67D6 for ; Tue,  8 Feb 2011 11:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBHpovbrfSEg for ; Tue,  8 Feb 2011 11:21:39 -0800 (PST)
Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 384A93A672E for ; Tue,  8 Feb 2011 11:21:39 -0800 (PST)
Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 5Wnf1g0031smiN4AFXMmTC; Tue, 08 Feb 2011 19:21:46 +0000
Received: from [127.0.0.1] ([67.190.47.98]) by omta20.emeryville.ca.mail.comcast.net with comcast id 5XMi1g00e276NET8gXMlTB; Tue, 08 Feb 2011 19:21:46 +0000
Message-ID: <4D5197C6.1010604@comcast.net>
Date: Tue, 08 Feb 2011 12:21:42 -0700
From: Bob Gilman 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Flemming Andreasen 
References: <4D49D4DC.40900@cisco.com><4D4ADD70.1070008@cisco.com>   <4D518D9D.8060509@cisco.com>
In-Reply-To: <4D518D9D.8060509@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: miguel.a.garcia@ericsson.com, mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 19:21:40 -0000

On 2/8/2011 11:38 AM, Flemming Andreasen wrote:
>
>
> On 2/7/11 8:38 AM, Simo.Veikkolainen@nokia.com wrote:
>>
>>
>> > -----Original Message-----
>> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> > Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)
>> > Sent: 07 February, 2011 13:52
>> > To: fandreas@cisco.com
>> > Cc: mmusic@ietf.org
>> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
>> > item
>> >
>> > From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
>> > Sent: 03 February, 2011 18:53
>> > To: Veikkolainen Simo (Nokia-MS/Helsinki)
>> > Cc: mmusic@ietf.org
>> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
>> > item
>> >
>> > Thanks for the updates Simo. A few follow-ups below...
>> >
>> >
>> >
>> > - Section 3.1, "Therefore, capabilities referenced by any configuration
>> > attribute MUST appear at the media level when a configuration is
>> > "converted" to a corresponding media block"
>> > I'm not sure how to interpret this paragraph. Please elaborate/clarify
>> > text
>> >
>> > [SV] The intention has been to say that even though "i=" can appear
>> > either at session or media level, we are defining the "icap" attribute
>> > only for media level. I think the sentence becomes clearer by just
>> > deleting "..when a configuration is "converted" to a corresponding
>> > media block".
>> >
>> > I think you should elaborate on the text so there is no confusion
>> > between capabilities being present at the session-level and media-level
>> > versus generating a configuration from a pcfg attribute present within
>> > a media description that references them, and hence effectively
>> > instantiates them at the media-level (except for session-level
>> > attributes, which is fraught with challenges as per RFC 5939). An
>> > accompanying example may help as well.
>> >
>> > [SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST
>> > appear only at media level. Therefore, the "icap" and "bcap"
>> > capabilities referenced by pcfg attribute are always on media level.
>>
>> Correcting myself. We have the following piece of text in Section 3.2:
>>
>> The icap and bcap attributes can appear at the session
>> level and/or at the media level, but MUST be interpreted
>> as a media-level capability,
>>
> Yeah, and I suspect this was probably introduced with an eye towards the
> latent configuration mechanism defined by the media capabilities draft.
[rrg]: Your suspicion is correct.  However, I think I've found a better
        way to define the latent configuration attribute that makes this
        media-level-only restriction unnecessary for these attributes, or
        for other attributes referenced by a latent configuration (except
        mcap, mfcap, or mscap attributes defined in the media cap draft.)
>
>
>> so I guess we could either do
>> 1) declare icap and bcap as media-level only, or
>> 2) describe in more detail in this section how session-level
>> capability attributes should be treated.
>>
>> Option 1) could be simpler to implement and understand, while 2) would
>> provide more generality. Any opinions?
>>
> My understanding is that the bcap and icap attributes are specifically
> defined for the media-level only currently in the draft, but maybe it
> needs to be made clearer. It gets tricky when we mix types that can
> appear at both the session and media-level, and then start interpreting
> what they actually are, *not* based on whether they indeed are at the
> session or the media-level, but how they are referenced. The latent
> configuration attribute ("lcfg") in the media capabilities draft
> currently relies on this, however I'm not keen on it (opens up a can of
> worms). The media capabilities authors are discussing this and, assuming
> the only reason you want to allow the above is for latent
> configurations, then I think we need to settle that discussion first.
> Alternatively, you could adopt wording similar to Section 3.4.1 in RFC
> 5939, which deals with the same problem for attribute capabilities (and
> basically only defines usage at the media-level, but allows for the
> media capabilities framework to extend that and define procedures above
> and beyond the media-leve only procedures defined in RFC 5939).
[rrg]: I think it would be most flexible if we could allow a potential
        or latent configuration to select both a session-level and
        media-level bandwidths, for example, and the specification of
        RFC5939 seems easiest: session-level capabilities are declared
        at the session level, and media-level caps are declared at the
        media level.  I think this is easily accommodated in the media
        caps document by defining the lcfg attribute as a media-level
        attribute, rather than a session-level attribute.
>
> -- Flemming
>
>
>> Simo
>>
>> > Simo
>> >
>> > _______________________________________________
>> > mmusic mailing list
>> > mmusic@ietf.org
>> > https://www.ietf.org/mailman/listinfo/mmusic
>>


-------------------------------------------------------------
Bob Gilman        bob_gilman@comcast.net      +1 303 898 9780




From fandreas@cisco.com  Tue Feb  8 12:32:56 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BABB3A6857 for ; Tue,  8 Feb 2011 12:32:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmOwNwx-uuyl for ; Tue,  8 Feb 2011 12:32:54 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E85473A681E for ; Tue,  8 Feb 2011 12:32:53 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEw3UU1AZnwN/2dsb2JhbACgTYRrc6FTmzmFWgSEe4Zv
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2011 20:33:01 +0000
Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18KX0ij027564; Tue, 8 Feb 2011 20:33:00 GMT
Message-ID: <4D51A902.8000607@cisco.com>
Date: Tue, 08 Feb 2011 15:35:14 -0500
From: Flemming Andreasen 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11
MIME-Version: 1.0
To: Bob Gilman 
References: <4D49D4DC.40900@cisco.com><4D4ADD70.1070008@cisco.com>   <4D518D9D.8060509@cisco.com> <4D5197C6.1010604@comcast.net>
In-Reply-To: <4D5197C6.1010604@comcast.net>
Content-Type: multipart/alternative; boundary="------------030206000401000106030902"
Cc: miguel.a.garcia@ericsson.com, mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 20:32:56 -0000

This is a multi-part message in MIME format.
--------------030206000401000106030902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit



On 2/8/11 2:21 PM, Bob Gilman wrote:
>
> On 2/8/2011 11:38 AM, Flemming Andreasen wrote:
> >
> >
> > On 2/7/11 8:38 AM, Simo.Veikkolainen@nokia.com wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> >> > Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)
> >> > Sent: 07 February, 2011 13:52
> >> > To: fandreas@cisco.com
> >> > Cc: mmusic@ietf.org
> >> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments 
> and WG
> >> > item
> >> >
> >> > From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
> >> > Sent: 03 February, 2011 18:53
> >> > To: Veikkolainen Simo (Nokia-MS/Helsinki)
> >> > Cc: mmusic@ietf.org
> >> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments 
> and WG
> >> > item
> >> >
> >> > Thanks for the updates Simo. A few follow-ups below...
> >> >
> >> >
> >> >
> >> > - Section 3.1, "Therefore, capabilities referenced by any 
> configuration
> >> > attribute MUST appear at the media level when a configuration is
> >> > "converted" to a corresponding media block"
> >> > I'm not sure how to interpret this paragraph. Please 
> elaborate/clarify
> >> > text
> >> >
> >> > [SV] The intention has been to say that even though "i=" can appear
> >> > either at session or media level, we are defining the "icap" 
> attribute
> >> > only for media level. I think the sentence becomes clearer by just
> >> > deleting "..when a configuration is "converted" to a corresponding
> >> > media block".
> >> >
> >> > I think you should elaborate on the text so there is no confusion
> >> > between capabilities being present at the session-level and 
> media-level
> >> > versus generating a configuration from a pcfg attribute present 
> within
> >> > a media description that references them, and hence effectively
> >> > instantiates them at the media-level (except for session-level
> >> > attributes, which is fraught with challenges as per RFC 5939). An
> >> > accompanying example may help as well.
> >> >
> >> > [SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST
> >> > appear only at media level. Therefore, the "icap" and "bcap"
> >> > capabilities referenced by pcfg attribute are always on media level.
> >>
> >> Correcting myself. We have the following piece of text in Section 3.2:
> >>
> >> The icap and bcap attributes can appear at the session
> >> level and/or at the media level, but MUST be interpreted
> >> as a media-level capability,
> >>
> > Yeah, and I suspect this was probably introduced with an eye towards the
> > latent configuration mechanism defined by the media capabilities draft.
> [rrg]: Your suspicion is correct.  However, I think I've found a better
>         way to define the latent configuration attribute that makes this
>         media-level-only restriction unnecessary for these attributes, or
>         for other attributes referenced by a latent configuration (except
>         mcap, mfcap, or mscap attributes defined in the media cap draft.)
> >
> >
> >> so I guess we could either do
> >> 1) declare icap and bcap as media-level only, or
> >> 2) describe in more detail in this section how session-level
> >> capability attributes should be treated.
> >>
> >> Option 1) could be simpler to implement and understand, while 2) would
> >> provide more generality. Any opinions?
> >>
> > My understanding is that the bcap and icap attributes are specifically
> > defined for the media-level only currently in the draft, but maybe it
> > needs to be made clearer. It gets tricky when we mix types that can
> > appear at both the session and media-level, and then start interpreting
> > what they actually are, *not* based on whether they indeed are at the
> > session or the media-level, but how they are referenced. The latent
> > configuration attribute ("lcfg") in the media capabilities draft
> > currently relies on this, however I'm not keen on it (opens up a can of
> > worms). The media capabilities authors are discussing this and, assuming
> > the only reason you want to allow the above is for latent
> > configurations, then I think we need to settle that discussion first.
> > Alternatively, you could adopt wording similar to Section 3.4.1 in RFC
> > 5939, which deals with the same problem for attribute capabilities (and
> > basically only defines usage at the media-level, but allows for the
> > media capabilities framework to extend that and define procedures above
> > and beyond the media-leve only procedures defined in RFC 5939).
> [rrg]: I think it would be most flexible if we could allow a potential
>         or latent configuration to select both a session-level and
>         media-level bandwidths, for example, and the specification of
>         RFC5939 seems easiest: session-level capabilities are declared
>         at the session level, and media-level caps are declared at the
>         media level.  I think this is easily accommodated in the media
>         caps document by defining the lcfg attribute as a media-level
>         attribute, rather than a session-level attribute.
>

That sounds like a good way forward. Will that still allow for latent 
media streams as well ?

Thanks

-- Flemming



--------------030206000401000106030902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  






On 2/8/11 2:21 PM, Bob Gilman wrote:


  
  
  Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG
item

  
On 2/8/2011 11:38 AM, Flemming Andreasen wrote:

>

>

> On 2/7/11 8:38 AM, Simo.Veikkolainen@nokia.com wrote:

>>

>>

>> > -----Original Message-----

>> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On

>> > Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)

>> > Sent: 07 February, 2011 13:52

>> > To: fandreas@cisco.com

>> > Cc: mmusic@ietf.org

>> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap
comments and WG

>> > item

>> >

>> > From: ext Flemming Andreasen [mailto:fandreas@cisco.com]

>> > Sent: 03 February, 2011 18:53

>> > To: Veikkolainen Simo (Nokia-MS/Helsinki)

>> > Cc: mmusic@ietf.org

>> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap
comments and WG

>> > item

>> >

>> > Thanks for the updates Simo. A few follow-ups below...

>> >

>> >

>> >

>> > - Section 3.1, "Therefore, capabilities referenced by any
configuration

>> > attribute MUST appear at the media level when a
configuration is

>> > "converted" to a corresponding media block"

>> > I'm not sure how to interpret this paragraph. Please
elaborate/clarify

>> > text

>> >

>> > [SV] The intention has been to say that even though "i="
can appear

>> > either at session or media level, we are defining the
"icap" attribute

>> > only for media level. I think the sentence becomes
clearer by just

>> > deleting "..when a configuration is "converted" to a
corresponding

>> > media block".

>> >

>> > I think you should elaborate on the text so there is no
confusion

>> > between capabilities being present at the session-level
and media-level

>> > versus generating a configuration from a pcfg attribute
present within

>> > a media description that references them, and hence
effectively

>> > instantiates them at the media-level (except for
session-level

>> > attributes, which is fraught with challenges as per RFC
5939). An

>> > accompanying example may help as well.

>> >

>> > [SV] I'm not sure I follow you. We define that "icap" and
"bcap" MUST

>> > appear only at media level. Therefore, the "icap" and
"bcap"

>> > capabilities referenced by pcfg attribute are always on
media level.

>>

>> Correcting myself. We have the following piece of text in
Section 3.2:

>>

>> The icap and bcap attributes can appear at the session

>> level and/or at the media level, but MUST be interpreted

>> as a media-level capability,

>>

> Yeah, and I suspect this was probably introduced with an eye
towards the

> latent configuration mechanism defined by the media capabilities
draft.

[rrg]: Your suspicion is correct.  However, I think I've found a better

        way to define the latent configuration attribute that makes this

        media-level-only restriction unnecessary for these attributes,
or

        for other attributes referenced by a latent configuration
(except

        mcap, mfcap, or mscap attributes defined in the media cap
draft.)

>

>

>> so I guess we could either do

>> 1) declare icap and bcap as media-level only, or

>> 2) describe in more detail in this section how session-level

>> capability attributes should be treated.

>>

>> Option 1) could be simpler to implement and understand, while
2) would

>> provide more generality. Any opinions?

>>

> My understanding is that the bcap and icap attributes are
specifically

> defined for the media-level only currently in the draft, but maybe
it

> needs to be made clearer. It gets tricky when we mix types that can

> appear at both the session and media-level, and then start
interpreting

> what they actually are, *not* based on whether they indeed are at
the

> session or the media-level, but how they are referenced. The latent

> configuration attribute ("lcfg") in the media capabilities draft

> currently relies on this, however I'm not keen on it (opens up a
can of

> worms). The media capabilities authors are discussing this and,
assuming

> the only reason you want to allow the above is for latent

> configurations, then I think we need to settle that discussion
first.

> Alternatively, you could adopt wording similar to Section 3.4.1 in
RFC

> 5939, which deals with the same problem for attribute capabilities
(and

> basically only defines usage at the media-level, but allows for the

> media capabilities framework to extend that and define procedures
above

> and beyond the media-leve only procedures defined in RFC 5939).

[rrg]: I think it would be most flexible if we could allow a potential

        or latent configuration to select both a session-level and

        media-level bandwidths, for example, and the specification of

        RFC5939 seems easiest: session-level capabilities are declared

        at the session level, and media-level caps are declared at the

        media level.  I think this is easily accommodated in the media

        caps document by defining the lcfg attribute as a media-level

        attribute, rather than a session-level attribute.

  





That sounds like a good way forward. Will that still allow for latent
media streams as well ? 



Thanks 



-- Flemming 












--------------030206000401000106030902--

From bob_gilman@comcast.net  Tue Feb  8 13:31:12 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F1A3A6893 for ; Tue,  8 Feb 2011 13:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krnGrFSTZ7J2 for ; Tue,  8 Feb 2011 13:31:11 -0800 (PST)
Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 823F33A6888 for ; Tue,  8 Feb 2011 13:31:11 -0800 (PST)
Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 5Z6b1g00C1eYJf8A2ZXKvZ; Tue, 08 Feb 2011 21:31:19 +0000
Received: from [127.0.0.1] ([67.190.47.98]) by omta19.emeryville.ca.mail.comcast.net with comcast id 5ZXE1g00s276NET01ZXHzF; Tue, 08 Feb 2011 21:31:18 +0000
Message-ID: <4D51B622.7030105@comcast.net>
Date: Tue, 08 Feb 2011 14:31:14 -0700
From: Bob Gilman 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Flemming Andreasen 
References: <4D49D4DC.40900@cisco.com><4D4ADD70.1070008@cisco.com>   <4D518D9D.8060509@cisco.com> <4D5197C6.1010604@comcast.net> <4D51A902.8000607@cisco.com>
In-Reply-To: <4D51A902.8000607@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: miguel.a.garcia@ericsson.com, mmusic@ietf.org
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 08 Feb 2011 21:31:12 -0000

Flemming-
Defining the latent configuration attribute as a media-level
attribute (and treating it as if it were another m-line) allows
the lcfg attribute to refer to either session-level capabilities
or media-level capabilities (following the a=lcfg line.)
The only potential problem is if such an offer is given to an
endpoint that recognizes cap negotiation, but doesn't recognize
media caps.   If media capabilities is not required in the offer,
the unique numbering of any lcfg-referenced capabilites should
permit them to be ignored (go unused) by the answerer.  The one
thing that shouldn't be done is to place a non-capability attribute
(what we've called a "conventional attribute") after the a=lcfg
line - which could be associated with the preceding m-line media
block if media caps is not recognized or required.  At some point,
it would be desirable to have a capability attribute for every
possible SDP line that might be associated with an lcfg attribute.
I'll try to make this more clear in the coming version of the
media capabilities document.
-Bob
-------------------------------------------------------------
Bob Gilman        bob_gilman@comcast.net      +1 303 898 9780

On 2/8/2011 1:35 PM, Flemming Andreasen wrote:
>
>
> On 2/8/11 2:21 PM, Bob Gilman wrote:
>>
>> On 2/8/2011 11:38 AM, Flemming Andreasen wrote:
>> >
>> >
>> > On 2/7/11 8:38 AM, Simo.Veikkolainen@nokia.com wrote:
>> >>
>> >>
>> >> > -----Original Message-----
>> >> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> >> > Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)
>> >> > Sent: 07 February, 2011 13:52
>> >> > To: fandreas@cisco.com
>> >> > Cc: mmusic@ietf.org
>> >> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments
>> and WG
>> >> > item
>> >> >
>> >> > From: ext Flemming Andreasen [mailto:fandreas@cisco.com]
>> >> > Sent: 03 February, 2011 18:53
>> >> > To: Veikkolainen Simo (Nokia-MS/Helsinki)
>> >> > Cc: mmusic@ietf.org
>> >> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments
>> and WG
>> >> > item
>> >> >
>> >> > Thanks for the updates Simo. A few follow-ups below...
>> >> >
>> >> >
>> >> >
>> >> > - Section 3.1, "Therefore, capabilities referenced by any
>> configuration
>> >> > attribute MUST appear at the media level when a configuration is
>> >> > "converted" to a corresponding media block"
>> >> > I'm not sure how to interpret this paragraph. Please
>> elaborate/clarify
>> >> > text
>> >> >
>> >> > [SV] The intention has been to say that even though "i=" can appear
>> >> > either at session or media level, we are defining the "icap"
>> attribute
>> >> > only for media level. I think the sentence becomes clearer by just
>> >> > deleting "..when a configuration is "converted" to a corresponding
>> >> > media block".
>> >> >
>> >> > I think you should elaborate on the text so there is no confusion
>> >> > between capabilities being present at the session-level and
>> media-level
>> >> > versus generating a configuration from a pcfg attribute present
>> within
>> >> > a media description that references them, and hence effectively
>> >> > instantiates them at the media-level (except for session-level
>> >> > attributes, which is fraught with challenges as per RFC 5939). An
>> >> > accompanying example may help as well.
>> >> >
>> >> > [SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST
>> >> > appear only at media level. Therefore, the "icap" and "bcap"
>> >> > capabilities referenced by pcfg attribute are always on media level.
>> >>
>> >> Correcting myself. We have the following piece of text in Section 3.2:
>> >>
>> >> The icap and bcap attributes can appear at the session
>> >> level and/or at the media level, but MUST be interpreted
>> >> as a media-level capability,
>> >>
>> > Yeah, and I suspect this was probably introduced with an eye towards the
>> > latent configuration mechanism defined by the media capabilities draft.
>> [rrg]: Your suspicion is correct. However, I think I've found a better
>> way to define the latent configuration attribute that makes this
>> media-level-only restriction unnecessary for these attributes, or
>> for other attributes referenced by a latent configuration (except
>> mcap, mfcap, or mscap attributes defined in the media cap draft.)
>> >
>> >
>> >> so I guess we could either do
>> >> 1) declare icap and bcap as media-level only, or
>> >> 2) describe in more detail in this section how session-level
>> >> capability attributes should be treated.
>> >>
>> >> Option 1) could be simpler to implement and understand, while 2) would
>> >> provide more generality. Any opinions?
>> >>
>> > My understanding is that the bcap and icap attributes are specifically
>> > defined for the media-level only currently in the draft, but maybe it
>> > needs to be made clearer. It gets tricky when we mix types that can
>> > appear at both the session and media-level, and then start interpreting
>> > what they actually are, *not* based on whether they indeed are at the
>> > session or the media-level, but how they are referenced. The latent
>> > configuration attribute ("lcfg") in the media capabilities draft
>> > currently relies on this, however I'm not keen on it (opens up a can of
>> > worms). The media capabilities authors are discussing this and, assuming
>> > the only reason you want to allow the above is for latent
>> > configurations, then I think we need to settle that discussion first.
>> > Alternatively, you could adopt wording similar to Section 3.4.1 in RFC
>> > 5939, which deals with the same problem for attribute capabilities (and
>> > basically only defines usage at the media-level, but allows for the
>> > media capabilities framework to extend that and define procedures above
>> > and beyond the media-leve only procedures defined in RFC 5939).
>> [rrg]: I think it would be most flexible if we could allow a potential
>> or latent configuration to select both a session-level and
>> media-level bandwidths, for example, and the specification of
>> RFC5939 seems easiest: session-level capabilities are declared
>> at the session level, and media-level caps are declared at the
>> media level. I think this is easily accommodated in the media
>> caps document by defining the lcfg attribute as a media-level
>> attribute, rather than a session-level attribute.
>>
>
> That sounds like a good way forward. Will that still allow for latent
> media streams as well ?
>
> Thanks
>
> -- Flemming
>
>





From john.elwell@siemens-enterprise.com  Wed Feb  9 09:38:47 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BBF3A69CE for ; Wed,  9 Feb 2011 09:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-fcNqN1jkJJ for ; Wed,  9 Feb 2011 09:38:46 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 401E83A69E0 for ; Wed,  9 Feb 2011 09:38:45 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3340005; Wed, 9 Feb 2011 18:38:55 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 712FB1EB82AB; Wed,  9 Feb 2011 18:38:55 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 9 Feb 2011 18:38:55 +0100
From: "Elwell, John" 
To: Christer Holmberg , mmusic 
Date: Wed, 9 Feb 2011 18:38:54 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEA==
Message-ID: 
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Feb 2011 17:38:47 -0000

I am not sure it would work in all circumstances - the UAS might send the 2=
00 OK before the UPDATE request reaches the UAS. It seems RFC 3262 just add=
s its own complications - something ICE was trying to avoid, don't forget. =
ICE does not mandate RFC 3262 support.

John

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
> Sent: 08 February 2011 13:53
> To: Elwell, John; mmusic
> Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> Yet another alternative to ICE)
>=20
>=20
> Hi John,
>=20
> Wouldn't the usage of RFC 3262 be a potential solution also=20
> for the fax case, if it would be able to send the candidate=20
> update before 200 OK?
>=20
> Regards,
>=20
> Christer
> =20
>=20
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org=20
> > [mailto:mmusic-bounces@ietf.org] On Behalf Of Elwell, John
> > Sent: 7. helmikuuta 2011 17:02
> > To: mmusic
> > Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet=20
> > another alternative to ICE)
> >=20
> > In response to Gonzalo's request for a better understanding =20
> > of the issues that keep ICE from being widely deployed, I=20
> > have submitted a new I-D on problems arising from the updated=20
> > SDP offer that ICE requires under some circumstances:
> > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat
> > ed-offer/
> >=20
> > Comments welcome.
> >=20
> > John
> >=20
> >=20
> > > -----Original Message-----
> > > From: mmusic-bounces@ietf.org
> > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> > > Sent: 04 December 2010 20:33
> > > To: Flemming Andreasen
> > > Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20
> > > draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic
> > > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20
> > > draft-ietf-mmusic-media-loopback-14 review and comments)
> > >=20
> > > Hi,
> > >=20
> > > >> - NAT Traversal and usage of ICE
> > > >>
> > > >> [Authors] As Hadriel mentioned, if you have ICE you=20
> > don't need the=20
> > > >> loopback primer. As he also clarified, the loopback=20
> situation is=20
> > > >> different from standard calls because the mirror will=20
> > never send a=20
> > > >> packet until it receives something from the source. This
> > > is certainly
> > > >> possible for a regular call and calls may fail for that=20
> > reason, but=20
> > > >> the loopback draft is dead without a solution for this problem.
> > > >> Remember that the primary use case for this draft is
> > > service providers
> > > >> wanting to test to subscriber devices that are almost=20
> > always behind=20
> > > >> NATs. The proposed solution meets the requirements for=20
> > the dominant=20
> > > >> use case and while standard solutions are certainly usable
> > > when they
> > > >> are available, the unfortunate reality is that most of=20
> > them are not=20
> > > >> implemented. We can add clarification text that if=20
> available ICE=20
> > > >> should be used instead of the loopback primer method.
> > > >>
> > > > Thanks. The draft will also need to clearly explain how=20
> > the loopback=20
> > > > primer would work, and in particular what the underlying
> > > assumptions are
> > > > (e.g. latching) as well as when it will not work (e.g. when
> > > both source
> > > > and mirror are behind a NAT, when you have overlapping
> > > IP-addresses and
> > > > ports, etc). In short, the limitations of this approach
> > > must be clearly
> > > > documented.
> > > >=20
> > > > I will also check with our AD as to whether there are any=20
> > additional=20
> > > > concerns with specifying such a solution when we already
> > > have ICE as the
> > > > Standard.
> > >=20
> > > as you all know, there have been a number of proposals to=20
> > standardize=20
> > > simpler-than-ICE NAT traversal solutions that would only work in=20
> > > certain scenarios or circumstances. There have been a lot of=20
> > > discussions around them. A couple of IETFs ago there was=20
> even a bar=20
> > > BOF where people tried to understand the issues that kept=20
> > folks from=20
> > > deploying ICE in some scenarios. I know there have been off-list=20
> > > follow ups on those discussions but no draft have been=20
> > submitted yet,=20
> > > AFAIK.
> > >=20
> > > So, we need to frame this discussion taking into account the big=20
> > > picture of NAT traversal and ICE. In this case, we need to=20
> > understand=20
> > > the issues that keep ICE from being widely deployed and,=20
> if needed,=20
> > > specify a general solution to address those issues.=20
> Coming up with=20
> > > several different NAT traversal mechanisms that only work=20
> > in specific=20
> > > conditions does not seem like the best outcome we can wish for.
> > >=20
> > > I encourage people who are working on those ICE-related issues to=20
> > > participate in this discussion because this is an important area.
> > >=20
> > > Thanks,
> > >=20
> > > Gonzalo
> > > _______________________________________________
> > > mmusic mailing list
> > > mmusic@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mmusic
> > >=20
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> > =

From dreibh@iem.uni-due.de  Wed Feb  9 13:48:28 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E1F3A6A06 for ; Wed,  9 Feb 2011 13:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz2vbU7ciJn4 for ; Wed,  9 Feb 2011 13:48:27 -0800 (PST)
Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by core3.amsl.com (Postfix) with ESMTP id A030C3A6823 for ; Wed,  9 Feb 2011 13:48:25 -0800 (PST)
Received: from lupo.localnet (p5086D0F4.dip.t-dialin.net [80.134.208.244]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id p19LmVfS023352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Feb 2011 22:48:33 +0100
From: Thomas Dreibholz 
Organization: University of Duisburg-Essen, Institute for Experimental Mathematics
To: mmusic@ietf.org
Date: Wed, 9 Feb 2011 22:48:19 +0100
User-Agent: KMail/1.13.5 (Linux/2.6.37dreibholz; KDE/4.5.5; x86_64; ; )
References:  <1215F876-58CC-4309-B126-03893425B367@ntt-at.com> <0884B6C8-DDCD-4BA6-A8A8-054380170411@nomadiclab.com>
In-Reply-To: <0884B6C8-DDCD-4BA6-A8A8-054380170411@nomadiclab.com>
MIME-Version: 1.0
X-UID: 15
Content-Type: multipart/signed; boundary="nextPart1377596.A1N1R3P4P7"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201102092248.25745.dreibh@iem.uni-due.de>
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Feb 2011 21:48:28 -0000

--nextPart1377596.A1N1R3P4P7
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,

I also think that this draft is quite useful and should be progressed.

Just one remark on section 5, last sentence ("Therefore, it is=20
RECOMMENDED that SCTP endpoints use a main address all the time (e.g., they=
 do=20
not send retransmissions to a backup address) ..."): not using non-primary=
=20
paths for retransmissions would mean to not utilize the multi-homing featur=
e=20
of SCTP for resilience. That is, an important feature of SCTP would be give=
n=20
up. This may help to get around firewall problems, but it should not be a=20
general recommendation. May be replace "RECOMMENDED" by "MAY" and also note=
=20
that this solution has an important disadvantage. IMHO, the best=20
recommendation on firewall problems would be to fix the firewall configurat=
ion.


On Montag 31 Januar 2011, Ari Keranen wrote:
> +1
>=20
>=20
> Cheers,
> Ari
>=20
> On Jan 29, 2011, at 9:36 AM, Shida Schubert wrote:
> > +1
> >=20
> > On Jan 29, 2011, at 3:01 AM, Michael Tuexen wrote:
> >> Dear all,
> >>=20
> >> I think the ID makes perfect sense and should be progressed.
> >>=20
> >> Just one note: [I-D.ietf-tsvwg-dtls-for-sctp] is now [RFC6083].
> >>=20
> >> Best regards
> >> Michael
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >=20
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

Best regards
=2D-=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstra=DFe 29
 Computer Networking Technology Group            D-45326 Essen/Germany
=2D----------------------------------------------------------------------
 E-Mail:     dreibh@iem.uni-due.de
 Homepage:   http://www.iem.uni-due.de/~dreibh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--nextPart1377596.A1N1R3P4P7
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAk1TC6kACgkQ32BbsHYPLWXR0wCfag8fzaFWsw+XvXvmPoQc9jo2
/u8AoM0dIxOQjZZyAkUQp0qg0AixZLqU
=DLEe
-----END PGP SIGNATURE-----

--nextPart1377596.A1N1R3P4P7--

From christer.holmberg@ericsson.com  Wed Feb  9 22:47:25 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004B33A685D for ; Wed,  9 Feb 2011 22:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOWUO3cp6SOe for ; Wed,  9 Feb 2011 22:47:23 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D6E533A6879 for ; Wed,  9 Feb 2011 22:47:22 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-d4-4d538a053db0
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.B2.23694.50A835D4; Thu, 10 Feb 2011 07:47:33 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 10 Feb 2011 07:47:33 +0100
From: Christer Holmberg 
To: "Elwell, John" , mmusic 
Date: Thu, 10 Feb 2011 07:47:32 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Feb 2011 06:47:25 -0000

Hi John,=20

>I am not sure it would work in all circumstances - the UAS=20
>might send the 200 OK before the UPDATE request reaches the=20
>UAS.

Well, to avoid that you have the preconditions mechanism. Ie you don't indi=
cate that preconditions have been met until ICE is done, which means the UA=
S user won't even be alarmed before ICE is done.

>It seems RFC 3262 just adds its own complications -=20
>something ICE was trying to avoid, don't forget. ICE does not=20
>mandate RFC 3262 support.

I know.

I was just thinking that, since you use RFC 3262 as an alternative in secti=
on 3, it would also work for section 2.

Another approach would be to, rather than getting rid of the ICE UPDATE, al=
ways require the ICE UPDATE. Then the UAS knows it will come, and can delay=
 the fax UPDATE.

Regards,

Christer



> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > Sent: 08 February 2011 13:53
> > To: Elwell, John; mmusic
> > Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> > Yet another alternative to ICE)
> >=20
> >=20
> > Hi John,
> >=20
> > Wouldn't the usage of RFC 3262 be a potential solution also for the=20
> > fax case, if it would be able to send the candidate update=20
> before 200=20
> > OK?
> >=20
> > Regards,
> >=20
> > Christer
> > =20
> >=20
> > > -----Original Message-----
> > > From: mmusic-bounces@ietf.org
> > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Elwell, John
> > > Sent: 7. helmikuuta 2011 17:02
> > > To: mmusic
> > > Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet=20
> > > another alternative to ICE)
> > >=20
> > > In response to Gonzalo's request for a better=20
> understanding of the=20
> > > issues that keep ICE from being widely deployed, I have=20
> submitted a=20
> > > new I-D on problems arising from the updated SDP offer that ICE=20
> > > requires under some circumstances:
> > > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat
> > > ed-offer/
> > >=20
> > > Comments welcome.
> > >=20
> > > John
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: mmusic-bounces@ietf.org
> > > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo Camarillo
> > > > Sent: 04 December 2010 20:33
> > > > To: Flemming Andreasen
> > > > Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20
> > > > draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic
> > > > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20
> > > > draft-ietf-mmusic-media-loopback-14 review and comments)
> > > >=20
> > > > Hi,
> > > >=20
> > > > >> - NAT Traversal and usage of ICE
> > > > >>
> > > > >> [Authors] As Hadriel mentioned, if you have ICE you
> > > don't need the
> > > > >> loopback primer. As he also clarified, the loopback
> > situation is
> > > > >> different from standard calls because the mirror will
> > > never send a
> > > > >> packet until it receives something from the source. This
> > > > is certainly
> > > > >> possible for a regular call and calls may fail for that
> > > reason, but
> > > > >> the loopback draft is dead without a solution for=20
> this problem.
> > > > >> Remember that the primary use case for this draft is
> > > > service providers
> > > > >> wanting to test to subscriber devices that are almost
> > > always behind
> > > > >> NATs. The proposed solution meets the requirements for
> > > the dominant
> > > > >> use case and while standard solutions are certainly usable
> > > > when they
> > > > >> are available, the unfortunate reality is that most of
> > > them are not
> > > > >> implemented. We can add clarification text that if
> > available ICE
> > > > >> should be used instead of the loopback primer method.
> > > > >>
> > > > > Thanks. The draft will also need to clearly explain how
> > > the loopback
> > > > > primer would work, and in particular what the underlying
> > > > assumptions are
> > > > > (e.g. latching) as well as when it will not work (e.g. when
> > > > both source
> > > > > and mirror are behind a NAT, when you have overlapping
> > > > IP-addresses and
> > > > > ports, etc). In short, the limitations of this approach
> > > > must be clearly
> > > > > documented.
> > > > >=20
> > > > > I will also check with our AD as to whether there are any
> > > additional
> > > > > concerns with specifying such a solution when we already
> > > > have ICE as the
> > > > > Standard.
> > > >=20
> > > > as you all know, there have been a number of proposals to
> > > standardize
> > > > simpler-than-ICE NAT traversal solutions that would=20
> only work in=20
> > > > certain scenarios or circumstances. There have been a lot of=20
> > > > discussions around them. A couple of IETFs ago there was
> > even a bar
> > > > BOF where people tried to understand the issues that kept
> > > folks from
> > > > deploying ICE in some scenarios. I know there have been=20
> off-list=20
> > > > follow ups on those discussions but no draft have been
> > > submitted yet,
> > > > AFAIK.
> > > >=20
> > > > So, we need to frame this discussion taking into=20
> account the big=20
> > > > picture of NAT traversal and ICE. In this case, we need to
> > > understand
> > > > the issues that keep ICE from being widely deployed and,
> > if needed,
> > > > specify a general solution to address those issues.=20
> > Coming up with
> > > > several different NAT traversal mechanisms that only work
> > > in specific
> > > > conditions does not seem like the best outcome we can wish for.
> > > >=20
> > > > I encourage people who are working on those ICE-related=20
> issues to=20
> > > > participate in this discussion because this is an=20
> important area.
> > > >=20
> > > > Thanks,
> > > >=20
> > > > Gonzalo
> > > > _______________________________________________
> > > > mmusic mailing list
> > > > mmusic@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/mmusic
> > > >=20
> > > _______________________________________________
> > > mmusic mailing list
> > > mmusic@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mmusic
> > > =

From john.elwell@siemens-enterprise.com  Thu Feb 10 01:16:09 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840D53A6933 for ; Thu, 10 Feb 2011 01:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXhfD3y+hqXn for ; Thu, 10 Feb 2011 01:16:08 -0800 (PST)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C34863A689C for ; Thu, 10 Feb 2011 01:16:07 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3342533; Thu, 10 Feb 2011 10:16:18 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 198CD23F028E; Thu, 10 Feb 2011 10:16:18 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 10 Feb 2011 10:16:18 +0100
From: "Elwell, John" 
To: Christer Holmberg , mmusic 
Date: Thu, 10 Feb 2011 10:16:16 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxAAAV8GkA=
Message-ID: 
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Feb 2011 09:16:09 -0000

=20

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
> Sent: 10 February 2011 06:48
> To: Elwell, John; mmusic
> Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> Yet another alternative to ICE)
>=20
>=20
> Hi John,=20
>=20
> >I am not sure it would work in all circumstances - the UAS=20
> >might send the 200 OK before the UPDATE request reaches the=20
> >UAS.
>=20
> Well, to avoid that you have the preconditions mechanism. Ie=20
> you don't indicate that preconditions have been met until ICE=20
> is done, which means the UAS user won't even be alarmed=20
> before ICE is done.
[JRE] ICE is determined to be done on the basis of what happens on the medi=
a path(s). An auto-answer device could send the 200 almost immediately.

>=20
> >It seems RFC 3262 just adds its own complications -=20
> >something ICE was trying to avoid, don't forget. ICE does not=20
> >mandate RFC 3262 support.
>=20
> I know.
>=20
> I was just thinking that, since you use RFC 3262 as an=20
> alternative in section 3, it would also work for section 2.
>=20
> Another approach would be to, rather than getting rid of the=20
> ICE UPDATE, always require the ICE UPDATE. Then the UAS knows=20
> it will come, and can delay the fax UPDATE.
[JRE] Can we rely on it always arriving in a timely manner, soon enough not=
 to impact fax? What if a SIP intermediary rejects the UPDATE for some reas=
on and it never arrives at the UAS?

However, these are useful points you make, which I will take into account i=
f there is a need to update the document. Thanks.

John


>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > > Sent: 08 February 2011 13:53
> > > To: Elwell, John; mmusic
> > > Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> > > Yet another alternative to ICE)
> > >=20
> > >=20
> > > Hi John,
> > >=20
> > > Wouldn't the usage of RFC 3262 be a potential solution=20
> also for the=20
> > > fax case, if it would be able to send the candidate update=20
> > before 200=20
> > > OK?
> > >=20
> > > Regards,
> > >=20
> > > Christer
> > > =20
> > >=20
> > > > -----Original Message-----
> > > > From: mmusic-bounces@ietf.org
> > > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Elwell, John
> > > > Sent: 7. helmikuuta 2011 17:02
> > > > To: mmusic
> > > > Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet=20
> > > > another alternative to ICE)
> > > >=20
> > > > In response to Gonzalo's request for a better=20
> > understanding of the=20
> > > > issues that keep ICE from being widely deployed, I have=20
> > submitted a=20
> > > > new I-D on problems arising from the updated SDP offer that ICE=20
> > > > requires under some circumstances:
> > > > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat
> > > > ed-offer/
> > > >=20
> > > > Comments welcome.
> > > >=20
> > > > John
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: mmusic-bounces@ietf.org
> > > > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo=20
> Camarillo
> > > > > Sent: 04 December 2010 20:33
> > > > > To: Flemming Andreasen
> > > > > Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20
> > > > > draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic
> > > > > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20
> > > > > draft-ietf-mmusic-media-loopback-14 review and comments)
> > > > >=20
> > > > > Hi,
> > > > >=20
> > > > > >> - NAT Traversal and usage of ICE
> > > > > >>
> > > > > >> [Authors] As Hadriel mentioned, if you have ICE you
> > > > don't need the
> > > > > >> loopback primer. As he also clarified, the loopback
> > > situation is
> > > > > >> different from standard calls because the mirror will
> > > > never send a
> > > > > >> packet until it receives something from the source. This
> > > > > is certainly
> > > > > >> possible for a regular call and calls may fail for that
> > > > reason, but
> > > > > >> the loopback draft is dead without a solution for=20
> > this problem.
> > > > > >> Remember that the primary use case for this draft is
> > > > > service providers
> > > > > >> wanting to test to subscriber devices that are almost
> > > > always behind
> > > > > >> NATs. The proposed solution meets the requirements for
> > > > the dominant
> > > > > >> use case and while standard solutions are certainly usable
> > > > > when they
> > > > > >> are available, the unfortunate reality is that most of
> > > > them are not
> > > > > >> implemented. We can add clarification text that if
> > > available ICE
> > > > > >> should be used instead of the loopback primer method.
> > > > > >>
> > > > > > Thanks. The draft will also need to clearly explain how
> > > > the loopback
> > > > > > primer would work, and in particular what the underlying
> > > > > assumptions are
> > > > > > (e.g. latching) as well as when it will not work (e.g. when
> > > > > both source
> > > > > > and mirror are behind a NAT, when you have overlapping
> > > > > IP-addresses and
> > > > > > ports, etc). In short, the limitations of this approach
> > > > > must be clearly
> > > > > > documented.
> > > > > >=20
> > > > > > I will also check with our AD as to whether there are any
> > > > additional
> > > > > > concerns with specifying such a solution when we already
> > > > > have ICE as the
> > > > > > Standard.
> > > > >=20
> > > > > as you all know, there have been a number of proposals to
> > > > standardize
> > > > > simpler-than-ICE NAT traversal solutions that would=20
> > only work in=20
> > > > > certain scenarios or circumstances. There have been a lot of=20
> > > > > discussions around them. A couple of IETFs ago there was
> > > even a bar
> > > > > BOF where people tried to understand the issues that kept
> > > > folks from
> > > > > deploying ICE in some scenarios. I know there have been=20
> > off-list=20
> > > > > follow ups on those discussions but no draft have been
> > > > submitted yet,
> > > > > AFAIK.
> > > > >=20
> > > > > So, we need to frame this discussion taking into=20
> > account the big=20
> > > > > picture of NAT traversal and ICE. In this case, we need to
> > > > understand
> > > > > the issues that keep ICE from being widely deployed and,
> > > if needed,
> > > > > specify a general solution to address those issues.=20
> > > Coming up with
> > > > > several different NAT traversal mechanisms that only work
> > > > in specific
> > > > > conditions does not seem like the best outcome we can=20
> wish for.
> > > > >=20
> > > > > I encourage people who are working on those ICE-related=20
> > issues to=20
> > > > > participate in this discussion because this is an=20
> > important area.
> > > > >=20
> > > > > Thanks,
> > > > >=20
> > > > > Gonzalo
> > > > > _______________________________________________
> > > > > mmusic mailing list
> > > > > mmusic@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/mmusic
> > > > >=20
> > > > _______________________________________________
> > > > mmusic mailing list
> > > > mmusic@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/mmusic
> > > > =

From christer.holmberg@ericsson.com  Thu Feb 10 04:39:07 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C2D3A6977 for ; Thu, 10 Feb 2011 04:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVQO4bybKRl8 for ; Thu, 10 Feb 2011 04:39:05 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 34AF83A694F for ; Thu, 10 Feb 2011 04:39:04 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-08-4d53dc73ce14
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8B.8A.23694.37CD35D4; Thu, 10 Feb 2011 13:39:15 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 10 Feb 2011 13:39:14 +0100
From: Christer Holmberg 
To: "Elwell, John" , mmusic 
Date: Thu, 10 Feb 2011 13:39:14 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxAAAV8GkAABuw/sA==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851944373D0B@ESESSCMS0356.eemea.ericsson.se>
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Feb 2011 12:39:07 -0000

Hi,=20

>>>I am not sure it would work in all circumstances - the UAS=20
>>>might send the 200 OK before the UPDATE request reaches the UAS.
>>=20
>>Well, to avoid that you have the preconditions mechanism.=20
>>Ie you don't indicate that preconditions have been met until ICE is done,=
 which=20
>>means the UAS user won't even be alarmed before ICE is done.
>[JRE] ICE is determined to be done on the basis of what=20
>happens on the media path(s).

True. I guess you may not even be able to do ICE on the media path before t=
he preconditions have met.

>An auto-answer device could send the 200 almost immediately.
>=20
>>=20
>>>It seems RFC 3262 just adds its own complications -=20
>>>something ICE was trying to avoid, don't forget. ICE does not mandate RF=
C=20
>>>3262 support.
>>=20
>>I know.
>>=20
>>I was just thinking that, since you use RFC 3262 as an=20
>>alternative in section 3, it would also work for section 2.
>>=20
>>Another approach would be to, rather than getting rid of the ICE=20
>>UPDATE, always require the ICE UPDATE. Then the UAS knows it will=20
>>come, and can delay the fax UPDATE.
>[JRE] Can we rely on it always arriving in a timely manner,=20
>soon enough not to impact fax? What if a SIP intermediary=20
>rejects the UPDATE for some reason and it never arrives at the UAS?

Well, things can of course always go wrong. But, even the audio-to-fax UPDA=
TE, when eventually sent, may get rejected or delayed in the network.

>However, these are useful points you make, which I will take into account =
if there is a need to update the document. Thanks.

Regarding doing ICE after 200 OK (assuming the 200 OK is sent when the call=
 is answered - not earlier), there are some issues related to that:

1. Early media won't be possible

2. Any media plane procedure (e.g. related to media security) that is to ta=
ke place before the call is established won't work

3. Since ICE, in the worse case scenario, may take a while to finish, there=
 is a bigger risk of a bigger delay than just a little "clipping".


Regarding sending an "early" 200 OK, that of course destroys the whole fork=
ing model (which, one might say, would be a good thing since it solves a nu=
mber of other issues :). In addition it would have impact on charging model=
s etc. But, in IETF we of course don't use such ugly words as charging...

Regards,

Christer






> > > > -----Original Message-----
> > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> > > > Sent: 08 February 2011 13:53
> > > > To: Elwell, John; mmusic
> > > > Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> > > > Yet another alternative to ICE)
> > > >=20
> > > >=20
> > > > Hi John,
> > > >=20
> > > > Wouldn't the usage of RFC 3262 be a potential solution
> > also for the
> > > > fax case, if it would be able to send the candidate update
> > > before 200
> > > > OK?
> > > >=20
> > > > Regards,
> > > >=20
> > > > Christer
> > > > =20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: mmusic-bounces@ietf.org
> > > > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Elwell, John
> > > > > Sent: 7. helmikuuta 2011 17:02
> > > > > To: mmusic
> > > > > Subject: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet=20
> > > > > another alternative to ICE)
> > > > >=20
> > > > > In response to Gonzalo's request for a better
> > > understanding of the
> > > > > issues that keep ICE from being widely deployed, I have
> > > submitted a
> > > > > new I-D on problems arising from the updated SDP=20
> offer that ICE=20
> > > > > requires under some circumstances:
> > > > > https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updat
> > > > > ed-offer/
> > > > >=20
> > > > > Comments welcome.
> > > > >=20
> > > > > John
> > > > >=20
> > > > >=20
> > > > > > -----Original Message-----
> > > > > > From: mmusic-bounces@ietf.org
> > > > > > [mailto:mmusic-bounces@ietf.org] On Behalf Of Gonzalo
> > Camarillo
> > > > > > Sent: 04 December 2010 20:33
> > > > > > To: Flemming Andreasen
> > > > > > Cc: vnagarjuna@gmail.com; Kaynam Hedayat;=20
> > > > > > draft-ietf-mmusic-media-loopback@tools.ietf.org; mmusic
> > > > > > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re:=20
> > > > > > draft-ietf-mmusic-media-loopback-14 review and comments)
> > > > > >=20
> > > > > > Hi,
> > > > > >=20
> > > > > > >> - NAT Traversal and usage of ICE
> > > > > > >>
> > > > > > >> [Authors] As Hadriel mentioned, if you have ICE you
> > > > > don't need the
> > > > > > >> loopback primer. As he also clarified, the loopback
> > > > situation is
> > > > > > >> different from standard calls because the mirror will
> > > > > never send a
> > > > > > >> packet until it receives something from the source. This
> > > > > > is certainly
> > > > > > >> possible for a regular call and calls may fail for that
> > > > > reason, but
> > > > > > >> the loopback draft is dead without a solution for
> > > this problem.
> > > > > > >> Remember that the primary use case for this draft is
> > > > > > service providers
> > > > > > >> wanting to test to subscriber devices that are almost
> > > > > always behind
> > > > > > >> NATs. The proposed solution meets the requirements for
> > > > > the dominant
> > > > > > >> use case and while standard solutions are=20
> certainly usable
> > > > > > when they
> > > > > > >> are available, the unfortunate reality is that most of
> > > > > them are not
> > > > > > >> implemented. We can add clarification text that if
> > > > available ICE
> > > > > > >> should be used instead of the loopback primer method.
> > > > > > >>
> > > > > > > Thanks. The draft will also need to clearly explain how
> > > > > the loopback
> > > > > > > primer would work, and in particular what the underlying
> > > > > > assumptions are
> > > > > > > (e.g. latching) as well as when it will not work=20
> (e.g. when
> > > > > > both source
> > > > > > > and mirror are behind a NAT, when you have overlapping
> > > > > > IP-addresses and
> > > > > > > ports, etc). In short, the limitations of this approach
> > > > > > must be clearly
> > > > > > > documented.
> > > > > > >=20
> > > > > > > I will also check with our AD as to whether there are any
> > > > > additional
> > > > > > > concerns with specifying such a solution when we already
> > > > > > have ICE as the
> > > > > > > Standard.
> > > > > >=20
> > > > > > as you all know, there have been a number of proposals to
> > > > > standardize
> > > > > > simpler-than-ICE NAT traversal solutions that would
> > > only work in
> > > > > > certain scenarios or circumstances. There have been=20
> a lot of=20
> > > > > > discussions around them. A couple of IETFs ago there was
> > > > even a bar
> > > > > > BOF where people tried to understand the issues that kept
> > > > > folks from
> > > > > > deploying ICE in some scenarios. I know there have been
> > > off-list
> > > > > > follow ups on those discussions but no draft have been
> > > > > submitted yet,
> > > > > > AFAIK.
> > > > > >=20
> > > > > > So, we need to frame this discussion taking into
> > > account the big
> > > > > > picture of NAT traversal and ICE. In this case, we need to
> > > > > understand
> > > > > > the issues that keep ICE from being widely deployed and,
> > > > if needed,
> > > > > > specify a general solution to address those issues.=20
> > > > Coming up with
> > > > > > several different NAT traversal mechanisms that only work
> > > > > in specific
> > > > > > conditions does not seem like the best outcome we can
> > wish for.
> > > > > >=20
> > > > > > I encourage people who are working on those ICE-related
> > > issues to
> > > > > > participate in this discussion because this is an
> > > important area.
> > > > > >=20
> > > > > > Thanks,
> > > > > >=20
> > > > > > Gonzalo
> > > > > > _______________________________________________
> > > > > > mmusic mailing list
> > > > > > mmusic@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/mmusic
> > > > > >=20
> > > > > _______________________________________________
> > > > > mmusic mailing list
> > > > > mmusic@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/mmusic
> > > > > =

From john.elwell@siemens-enterprise.com  Thu Feb 10 05:34:39 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2CB3A69A4 for ; Thu, 10 Feb 2011 05:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIZBNvQeEQjV for ; Thu, 10 Feb 2011 05:34:38 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D0A1F3A6984 for ; Thu, 10 Feb 2011 05:34:37 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3350958; Thu, 10 Feb 2011 14:34:48 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id CDFD51EB82B0; Thu, 10 Feb 2011 14:34:48 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 10 Feb 2011 14:34:48 +0100
From: "Elwell, John" 
To: Christer Holmberg , mmusic 
Date: Thu, 10 Feb 2011 14:34:47 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxAAAV8GkAABuw/sAAB/i8Q
Message-ID: 
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05851944373D0B@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851944373D0B@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Feb 2011 13:34:39 -0000

=20

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
> Sent: 10 February 2011 12:39
> To: Elwell, John; mmusic
> Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> Yet another alternative to ICE)
>=20
>=20
> Hi,=20
>=20
> >>>I am not sure it would work in all circumstances - the UAS=20
> >>>might send the 200 OK before the UPDATE request reaches the UAS.
> >>=20
> >>Well, to avoid that you have the preconditions mechanism.=20
> >>Ie you don't indicate that preconditions have been met=20
> until ICE is done, which=20
> >>means the UAS user won't even be alarmed before ICE is done.
> >[JRE] ICE is determined to be done on the basis of what=20
> >happens on the media path(s).
>=20
> True. I guess you may not even be able to do ICE on the media=20
> path before the preconditions have met.
>=20
> >An auto-answer device could send the 200 almost immediately.
> >=20
> >>=20
> >>>It seems RFC 3262 just adds its own complications -=20
> >>>something ICE was trying to avoid, don't forget. ICE does=20
> not mandate RFC=20
> >>>3262 support.
> >>=20
> >>I know.
> >>=20
> >>I was just thinking that, since you use RFC 3262 as an=20
> >>alternative in section 3, it would also work for section 2.
> >>=20
> >>Another approach would be to, rather than getting rid of the ICE=20
> >>UPDATE, always require the ICE UPDATE. Then the UAS knows it will=20
> >>come, and can delay the fax UPDATE.
> >[JRE] Can we rely on it always arriving in a timely manner,=20
> >soon enough not to impact fax? What if a SIP intermediary=20
> >rejects the UPDATE for some reason and it never arrives at the UAS?
>=20
> Well, things can of course always go wrong. But, even the=20
> audio-to-fax UPDATE, when eventually sent, may get rejected=20
> or delayed in the network.
>=20
> >However, these are useful points you make, which I will take=20
> into account if there is a need to update the document. Thanks.
>=20
> Regarding doing ICE after 200 OK (assuming the 200 OK is sent=20
> when the call is answered - not earlier), there are some=20
> issues related to that:
>=20
> 1. Early media won't be possible
>=20
> 2. Any media plane procedure (e.g. related to media security)=20
> that is to take place before the call is established won't work
>=20
> 3. Since ICE, in the worse case scenario, may take a while to=20
> finish, there is a bigger risk of a bigger delay than just a=20
> little "clipping".
>=20
>=20
> Regarding sending an "early" 200 OK, that of course destroys=20
> the whole forking model (which, one might say, would be a=20
> good thing since it solves a number of other issues :). In=20
> addition it would have impact on charging models etc. But, in=20
> IETF we of course don't use such ugly words as charging...
[JRE] This was not what I was suggesting. I was suggesting that ICE would c=
omplete (on the media paths) and then the user would be alerted, but in the=
 case of auto-answer there would be an immediate 200 OK. So I am not sugges=
ting sending 200 OK early, and I am not suggesting sending 200 OK before IC=
E completes. I was just pointing out that it might not be feasible for the =
UAC to send the UPDATE request with the updated offer and have that arrive =
at the UAS before the UAS sends the 200 OK to the INVITE request.

John

From christer.holmberg@ericsson.com  Thu Feb 10 05:39:59 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FA73A69F9 for ; Thu, 10 Feb 2011 05:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9JxnJYcb1q0 for ; Thu, 10 Feb 2011 05:39:59 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C310C3A6984 for ; Thu, 10 Feb 2011 05:39:58 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-6e-4d53eab915ff
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 82.45.23694.9BAE35D4; Thu, 10 Feb 2011 14:40:10 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 10 Feb 2011 14:40:09 +0100
From: Christer Holmberg 
To: "Elwell, John" , mmusic 
Date: Thu, 10 Feb 2011 14:40:08 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxAAAV8GkAABuw/sAAB/i8QAABk7OA=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519443A7B15@ESESSCMS0356.eemea.ericsson.se>
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05851944373D0B@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Feb 2011 13:40:00 -0000

Hi,=20

>>Regarding sending an "early" 200 OK, that of course=20
>>destroys the whole forking model (which, one might say, would be a good t=
hing since it=20
>>solves a number of other issues :). In addition it would=20
>>have impact on charging models etc. But, in IETF we of course don't use=20
>>such ugly=20
>>words as charging...
>[JRE] This was not what I was suggesting. I was suggesting=20
>that ICE would complete (on the media paths) and then the=20
>user would be alerted, but in the case of auto-answer there=20
>would be an immediate 200 OK. So I am not suggesting sending=20
>200 OK early, and I am not suggesting sending 200 OK before=20
>ICE completes. I was just pointing out that it might not be=20
>feasible for the UAC to send the UPDATE request with the=20
>updated offer and have that arrive at the UAS before the UAS=20
>sends the 200 OK to the INVITE request.

One could define an "ICE precondition" mechanism, where, eventhough the med=
ia plane resources are in place, the UAS user still isn't alterted until th=
e "ICE preconditions" have been met.

Regards,

Christer


From john.elwell@siemens-enterprise.com  Fri Feb 11 00:45:15 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A1E3A6A43 for ; Fri, 11 Feb 2011 00:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.59
X-Spam-Level: 
X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQWoHECuKkpC for ; Fri, 11 Feb 2011 00:45:14 -0800 (PST)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 811D23A6BDE for ; Fri, 11 Feb 2011 00:45:14 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3362333; Fri, 11 Feb 2011 09:45:27 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id DBA0823F0278; Fri, 11 Feb 2011 09:45:27 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 11 Feb 2011 09:45:27 +0100
From: "Elwell, John" 
To: Christer Holmberg , mmusic 
Date: Fri, 11 Feb 2011 09:45:27 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxAAAV8GkAABuw/sAAB/i8QAABk7OAAJ8NokA==
Message-ID: 
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05851944373D0B@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A058519443A7B15@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058519443A7B15@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Feb 2011 08:45:15 -0000

=20

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
> Sent: 10 February 2011 13:40
> To: Elwell, John; mmusic
> Subject: RE: [MMUSIC] Draft-elwell-ice-updated-offer (was RE:=20
> Yet another alternative to ICE)
>=20
>=20
> Hi,=20
>=20
> >>Regarding sending an "early" 200 OK, that of course=20
> >>destroys the whole forking model (which, one might say,=20
> would be a good thing since it=20
> >>solves a number of other issues :). In addition it would=20
> >>have impact on charging models etc. But, in IETF we of=20
> course don't use=20
> >>such ugly=20
> >>words as charging...
> >[JRE] This was not what I was suggesting. I was suggesting=20
> >that ICE would complete (on the media paths) and then the=20
> >user would be alerted, but in the case of auto-answer there=20
> >would be an immediate 200 OK. So I am not suggesting sending=20
> >200 OK early, and I am not suggesting sending 200 OK before=20
> >ICE completes. I was just pointing out that it might not be=20
> >feasible for the UAC to send the UPDATE request with the=20
> >updated offer and have that arrive at the UAS before the UAS=20
> >sends the 200 OK to the INVITE request.
>=20
> One could define an "ICE precondition" mechanism, where,=20
> eventhough the media plane resources are in place, the UAS=20
> user still isn't alterted until the "ICE preconditions" have been met.
[JRE] Yes indeed, but this raises even further the barriers to adoption of =
ICE. It means one needs to implement 100rel and pre-conditions in order to =
have a viable ICE implementation that works for fax - hardly what was antic=
ipated when ICE was written. It also increases the risk that middleboxes (e=
.g., SBCs) might not behave as expected. We really should be looking for si=
mplifications, not further complexity.

John

From christer.holmberg@ericsson.com  Fri Feb 11 02:11:50 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D373A3A6AE4 for ; Fri, 11 Feb 2011 02:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmZBkpgZ+1Q0 for ; Fri, 11 Feb 2011 02:11:50 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BEE153A6960 for ; Fri, 11 Feb 2011 02:11:49 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-2f-4d550b72f84d
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A0.69.13987.27B055D4; Fri, 11 Feb 2011 11:12:02 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 11 Feb 2011 11:12:02 +0100
From: Christer Holmberg 
To: "Elwell, John" , mmusic 
Date: Fri, 11 Feb 2011 11:12:01 +0100
Thread-Topic: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
Thread-Index: AcuUJeG5sbpAzv1gRcGSGxoe76YJ/wysYM4AAC/x5DAAOiziEAAbLCxAAAV8GkAABuw/sAAB/i8QAABk7OAAJ8NokAADO1kw
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058519443A7F4B@ESESSCMS0356.eemea.ericsson.se>
References: <4CCF3F10.2080100@cisco.com> <03464A80-502E-4DAD-9831-DE04D41CD9B0@acmepacket.com> <4CD82041.8030303@cisco.com> <4AFCCFD8-044F-46AD-8B29-B2B9320F78E1@acmepacket.com> <4CD8E26A.5090600@cisco.com>  <4CD90E61.9020700@cisco.com> <62B0A6FB-750B-4741-8FD3-C11A3C06AE07@acmepacket.com> <4CD91BC6.5080804@cisco.com> <53E603EF-2D5B-4CA9-B988-F56CD8ADF1A0@acmepacket.com> <4CDA13A0.2030809@cisco.com>  <86F9069E07A5EC4E890AF73FD8E85E175F8355@spboexc01.exfo.com> <4CF43041.10404@cisco.com> <4CFAA584.8080507@gmail.com>  <7F2072F1E0DE894DA4B517B93C6A05851944372FA9@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A0585194437397E@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05851944373D0B@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A058519443A7B15@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer (was RE: Yet another alternative to ICE)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Feb 2011 10:11:50 -0000

Hi,=20

>>One could define an "ICE precondition" mechanism, where, eventhough=20
>>the media plane resources are in place, the UAS user still isn't=20
>>alterted until the "ICE preconditions" have been met.
>[JRE] Yes indeed, but this raises even further the barriers=20
>to adoption of ICE. It means one needs to implement 100rel=20
>and pre-conditions in order to have a viable ICE=20
>implementation that works for fax -=20

I agree. But, there is a reason why those mechanisms were defined: to solve=
 a specific problem :)

>hardly what was anticipated when ICE was written.

Well, SIP itself, and SDP offer/answer, were originally supposed to be very=
 easy and simple things :)

>It also increases the risk that middleboxes (e.g., SBCs) might not behave =
as expected.=20
>We really should be looking for simplifications, not further complexity.

I agree. But, again, the reason the mentioned extensions were defined was b=
ecause there was no existing mechanism available.

Regards,

Christer

From martin.becke@uni-due.de  Tue Feb 15 05:46:43 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9553A6E8E for ; Tue, 15 Feb 2011 05:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpSUgniNsqrQ for ; Tue, 15 Feb 2011 05:46:42 -0800 (PST)
Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by core3.amsl.com (Postfix) with ESMTP id 791F93A6D2C for ; Tue, 15 Feb 2011 05:46:42 -0800 (PST)
Received: from HT01.win.uni-due.de (virt080.zim.uni-duisburg-essen.de [132.252.185.80]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id p1FDl4qD015848 for ; Tue, 15 Feb 2011 14:47:04 +0100
Received: from ccr01.win.uni-due.de ([169.254.1.74]) by HT01.win.uni-due.de ([132.252.190.233]) with mapi id 14.01.0218.012; Tue, 15 Feb 2011 14:47:04 +0100
From: "Becke, Martin" 
To: "mmusic@ietf.org" 
Thread-Topic: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
Thread-Index: AcvNFlNmoBNCyRkjR5W8mwhiBOkWqQ==
Date: Tue, 15 Feb 2011 13:47:03 +0000
Message-ID: <466847B318CFAB419C80EFC5014D621E897FE2@ccr01.win.uni-due.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.252.151.182]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16
X-Mailman-Approved-At: Tue, 15 Feb 2011 06:02:19 -0800
Subject: Re: [MMUSIC] Progressing draft-loreto-mmusic-sctp-sdp-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Feb 2011 13:46:43 -0000

Dear all,

I like the idea of this ID, and I think there are arguments to proceed...

Best regards
Martin


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0Martin Becke

=A0University of Duisburg-Essen,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 Room 308a
=A0Inst. for Experimental Mathematics=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Ellernstra=DFe 29
=A0Computer Networking Technology Group=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0D-=
45326 Essen/Germany
-----------------------------------------------------------------------
=A0Phone :=A0=A0=A0=A0 +49-201-183-7667
=A0E-Mail:=A0=A0=A0=A0 martin.becke@uni-due.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



From Internet-Drafts@ietf.org  Fri Feb 18 00:00:02 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1023A6E3B; Fri, 18 Feb 2011 00:00:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id engtXrYrwegR; Fri, 18 Feb 2011 00:00:02 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7E23A6E87; Fri, 18 Feb 2011 00:00:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.12
Message-ID: <20110218080002.6339.11030.idtracker@localhost>
Date: Fri, 18 Feb 2011 00:00:02 -0800
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-sdp-cs-06.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 08:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.


	Title           : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
	Author(s)       : M. Garcia, S. Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-06.txt
	Pages           : 26
	Date            : 2011-02-17

This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-cs-06.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-02-17234845.I-D@ietf.org>


--NextPart--

From Simo.Veikkolainen@nokia.com  Fri Feb 18 01:16:10 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDCA3A6EAC for ; Fri, 18 Feb 2011 01:16:10 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body
X-Spam-Flag: NO
X-Spam-Score: -3.266
X-Spam-Level: 
X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPUT+H+KqyOu for ; Fri, 18 Feb 2011 01:16:08 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id E7BDF3A6E0C for ; Fri, 18 Feb 2011 01:16:07 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1I9GCmc003916 for ; Fri, 18 Feb 2011 11:16:39 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Feb 2011 11:16:05 +0200
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 18 Feb 2011 10:16:01 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.245]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Fri, 18 Feb 2011 10:16:01 +0100
From: 
To: 
Thread-Topic: I-D Action:draft-mmusic-sdp-icap-bcap-00.txt
Thread-Index: AQHLzz3Z/pYm++Blc0yRCEKfh6gY3JQG+iuQ
Date: Fri, 18 Feb 2011 09:15:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.162.77.185]
Content-Type: multipart/mixed; boundary="_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C068008AM1MPN1004mg_"
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Feb 2011 09:16:05.0380 (UTC) FILETIME=[7859B440:01CBCF4C]
X-Nokia-AV: Clean
Subject: [MMUSIC] FW: I-D Action:draft-mmusic-sdp-icap-bcap-00.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 09:16:10 -0000

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C068008AM1MPN1004mg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
I just submitted a new version of the icap-bcap document, this time as WG v=
ersion.
=20
I have now changed the document according to Flemming's comments, except th=
ese are still TBD:
- Offer/Answer section
- clarification of session vs. media level usage
- security considerations

Thanks
Simo

-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of ext Internet-Drafts@ietf.org
Sent: 18 February, 2011 09:30
To: i-d-announce@ietf.org
Subject: I-D Action:draft-mmusic-sdp-icap-bcap-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

	Title           : Media title and Media bandwidth Capabilities Negotiation=
 in the Session Description Protocol (SDP)
	Author(s)       : M. Garcia, et al.
	Filename        : draft-mmusic-sdp-icap-bcap-00.txt
	Pages           : 14
	Date            : 2011-02-17

SDP has been extended with a capability negotiation mechanism framework tha=
t allows the endpoints to negotiate transport protocols and attributes.  Th=
is framework has been extended with a media capabilities negotiation mechan=
ism that allows endpoints to negotiate additional media-related capabilitie=
s.  This negotiation is embedded into the widely-used SDP offer/answer proc=
edures.

This memo extends the SDP capability negotiation framework to allow endpoin=
ts to negotiate two additional SDP capabilities.  In particular, this memo =
provides a mechanism to negotiate media titles ("i=3D" line for each media)=
 and media bandwidth ("b=3D" line).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mmusic-sdp-icap-bcap-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementa=
tion to automatically retrieve the ASCII version of the Internet-Draft.

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C068008AM1MPN1004mg_
Content-Type: message/external-body;
	name="draft-mmusic-sdp-icap-bcap-00.url"
Content-Description: draft-mmusic-sdp-icap-bcap-00.url
Content-Disposition: attachment;
	filename="draft-mmusic-sdp-icap-bcap-00.url"; size=94;
	creation-date="Fri, 18 Feb 2011 07:31:25 GMT";
	modification-date="Fri, 18 Feb 2011 07:31:25 GMT"
Content-Transfer-Encoding: base64


W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1tbXVzaWMtc2RwLWljYXAtYmNhcC0wMC50eHQNCg==

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C068008AM1MPN1004mg_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=258;
	creation-date="Fri, 18 Feb 2011 07:31:25 GMT";
	modification-date="Fri, 18 Feb 2011 07:31:25 GMT"
Content-ID: <686025C421FBEB4D913449D424C0E0DE@nokia.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C068008AM1MPN1004mg_--

From Simo.Veikkolainen@nokia.com  Fri Feb 18 01:17:40 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B803A6E81 for ; Fri, 18 Feb 2011 01:17:40 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB8zprNF8WFd for ; Fri, 18 Feb 2011 01:17:39 -0800 (PST)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 00EAE3A6E88 for ; Fri, 18 Feb 2011 01:17:38 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1I9I3bc030999; Fri, 18 Feb 2011 11:18:10 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Feb 2011 11:17:54 +0200
Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 18 Feb 2011 10:17:54 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.245]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0270.002; Fri, 18 Feb 2011 10:17:53 +0100
From: 
To: 
Thread-Topic: I-D Action:draft-ietf-mmusic-sdp-cs-06.txt
Thread-Index: AQHLz0IRdaQJQm0dykaYa3pSNcTd/ZQG+nAw
Date: Fri, 18 Feb 2011 09:17:52 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.162.77.185]
Content-Type: multipart/mixed; boundary="_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C081008AM1MPN1004mg_"
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Feb 2011 09:17:54.0853 (UTC) FILETIME=[B999F550:01CBCF4C]
X-Nokia-AV: Clean
Cc: miguel.a.garcia@ericsson.com
Subject: [MMUSIC] FW: I-D Action:draft-ietf-mmusic-sdp-cs-06.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 09:17:40 -0000

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C081008AM1MPN1004mg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have submitted a new version of the SDP CS draft. I got some comments off=
line from Tom Taylor, mostly about grouping the text on offerer and answere=
r behavior into a section of its own. Besides that, I cleaned some typos an=
d tried to make some passages clearer.

Regards,
Simo

-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of ext Internet-Drafts@ietf.org
Sent: 18 February, 2011 10:00
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: I-D Action:draft-ietf-mmusic-sdp-cs-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Multiparty Multimedia Session Control Work=
ing Group of the IETF.


	Title           : Session Description Protocol (SDP) Extension For Setting=
 Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ=
ic Switched Telephone Network (PSTN)
	Author(s)       : M. Garcia, S. Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-06.txt
	Pages           : 26
	Date            : 2011-02-17

This memo describes use cases, requirements, and protocol extensions for us=
ing the Session Description Protocol (SDP) Offer/Answer model for establish=
ing audio and video media streams over circuit-switched bearers in the Publ=
ic Switched Telephone Network (PSTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementa=
tion to automatically retrieve the ASCII version of the Internet-Draft.

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C081008AM1MPN1004mg_
Content-Type: message/external-body; name="draft-ietf-mmusic-sdp-cs-06.url"
Content-Description: draft-ietf-mmusic-sdp-cs-06.url
Content-Disposition: attachment; filename="draft-ietf-mmusic-sdp-cs-06.url";
	size=92; creation-date="Fri, 18 Feb 2011 08:01:38 GMT";
	modification-date="Fri, 18 Feb 2011 08:01:38 GMT"
Content-Transfer-Encoding: base64


W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtY3MtMDYudHh0DQo=

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C081008AM1MPN1004mg_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=258;
	creation-date="Fri, 18 Feb 2011 08:01:38 GMT";
	modification-date="Fri, 18 Feb 2011 08:01:38 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K

--_003_F9E2FDAF48D4544F874A56A3A8BD68B10105C081008AM1MPN1004mg_--

From Internet-Drafts@ietf.org  Fri Feb 18 03:00:03 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F8D3A6EF8; Fri, 18 Feb 2011 03:00:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRDZptxn4w2a; Fri, 18 Feb 2011 03:00:02 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289A93A6AF3; Fri, 18 Feb 2011 03:00:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.12
Message-ID: <20110218110002.955.31421.idtracker@localhost>
Date: Fri, 18 Feb 2011 03:00:02 -0800
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-image-attributes-11.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Feb 2011 11:00:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.


	Title           : Negotiation of Generic Image Attributes in SDP
	Author(s)       : I. Johansson, K. Jung
	Filename        : draft-ietf-mmusic-image-attributes-11.txt
	Pages           : 26
	Date            : 2011-02-18

This document proposes a new generic session set up attribute to make
it possible to negotiate different image attributes such as image
size.  A possible use case is to make it possible for a low-end hand-
held terminal to display video without the need to rescale the image,
something that may consume large amounts of memory and processing
power.  The draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is
transmitted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-image-attributes-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-image-attributes-11.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-02-18024851.I-D@ietf.org>


--NextPart--

From skillzero@gmail.com  Mon Feb 21 08:27:43 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313903A6DDB for ; Mon, 21 Feb 2011 08:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.67
X-Spam-Level: 
X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNg7eEMuGXpe for ; Mon, 21 Feb 2011 08:27:42 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0B34A3A6DC6 for ; Mon, 21 Feb 2011 08:27:41 -0800 (PST)
Received: by wwa36 with SMTP id 36so6415012wwa.13 for ; Mon, 21 Feb 2011 08:28:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=/BX/9DKdzFOaDNCz3IpoABxUinecSokUfhzWMQ2UpzQ=; b=IP0+9av9Jb2tRQ2CzpgRqrXudmc664FGq+vVx8895/wPbB0gO6hDuGL6lR4RtAcBGw toWb2Z/FabaUHZV/qY49AshMYSFVS1dEfXZK2nuB43YFc8plFhiQ3sGP0xlH7Hv7RzT1 jXfFI49nowMiR5ECZE5ichnSL1KNEvaN05YNo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Neg/nP4f0mQdDBX3KARjv1Q2cjnqHQdlE1aceEZH4fFyCmu2N/54yNLn7QxL0PNTyH MAeNKNXOdHLWELKOIqMLe4+0TnsfvoLCklmn5UHcgRqGOOceHBNp/Pk4foVyK96DsADQ qSorouc8i/d9WyafvA02CUQIVhu7trkK+SP5M=
MIME-Version: 1.0
Received: by 10.216.185.199 with SMTP id u49mr1621481wem.45.1298305305092; Mon, 21 Feb 2011 08:21:45 -0800 (PST)
Received: by 10.216.242.130 with HTTP; Mon, 21 Feb 2011 08:21:45 -0800 (PST)
Date: Mon, 21 Feb 2011 08:21:45 -0800
Message-ID: 
From: skillzero@gmail.com
To: mmusic@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: [MMUSIC] RECORD removed?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Feb 2011 16:27:43 -0000

Sorry if this is the wrong mailing list to discuss this, but I noticed
in draft-ietf-mmusic-rfc2326bis-26 that the RECORD method has been
removed from RTSP. Is this because the recording-like functionality
has been removed from RTSP or is there another recommended mechanism
in RTSP 2.0?

I'm using RTSP to control pushing of audio and video content for live
playback on an RTSP server device. So a client connects to the RTSP
server, sets up a session, and then sends a RECORD to the server to
prepare it to receive audio and video RTP streams. The server then
plays those streams via its audio/video hardware (e.g. a TV is the
RTSP server and plays the content on its screen and speakers).

Is this a valid use of RTSP 2.0?

From magnus.westerlund@ericsson.com  Mon Feb 21 08:56:28 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90353A712B for ; Mon, 21 Feb 2011 08:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.324
X-Spam-Level: 
X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fFA4btphA7n for ; Mon, 21 Feb 2011 08:56:27 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 720CC3A6DC6 for ; Mon, 21 Feb 2011 08:56:27 -0800 (PST)
X-AuditID: c1b4fb3d-b7c78ae000005844-59-4d62996307f4
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B9.BE.22596.369926D4; Mon, 21 Feb 2011 17:57:08 +0100 (CET)
Received: from [147.214.183.8] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Mon, 21 Feb 2011 17:57:06 +0100
Message-ID: <4D629962.6010909@ericsson.com>
Date: Mon, 21 Feb 2011 17:57:06 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "skillzero@gmail.com" 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RECORD removed?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Feb 2011 16:56:28 -0000

skillzero@gmail.com skrev 2011-02-21 17:21:
> Sorry if this is the wrong mailing list to discuss this, but I noticed
> in draft-ietf-mmusic-rfc2326bis-26 that the RECORD method has been
> removed from RTSP. Is this because the recording-like functionality
> has been removed from RTSP or is there another recommended mechanism
> in RTSP 2.0?
> 
> I'm using RTSP to control pushing of audio and video content for live
> playback on an RTSP server device. So a client connects to the RTSP
> server, sets up a session, and then sends a RECORD to the server to
> prepare it to receive audio and video RTP streams. The server then
> plays those streams via its audio/video hardware (e.g. a TV is the
> RTSP server and plays the content on its screen and speakers).
> 
> Is this a valid use of RTSP 2.0?

Hi,

You are certainly on the right list.

We excluded RECORD from RTSP 2.0 because it underspecified nature, and
the lack of interest from anyone in performing the specification work
needed.

As your use case appears to be primarily a case of configuring a media
stream sink. There is no action for the server to do other than to
render what ever media it receives. Thus I would think that this can be
easily accomplished using an auto-answering SIP client in what you call
the server.

I think if one was interested in defining RECORD for RTSP 2.0 one should
start at considering what functionality are one really needing, and what
is the semantics of RECORD. This as I think your use case could be
viewed in several ways from an semantics point of view. One is to view
it as playback scenario where the server controls the client, rather
than having the client request from the server what to play.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

From skillzero@gmail.com  Mon Feb 21 12:15:44 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160C33A7132 for ; Mon, 21 Feb 2011 12:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.134
X-Spam-Level: 
X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFxTOEJxq6Zv for ; Mon, 21 Feb 2011 12:15:43 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EEA2F3A6CCB for ; Mon, 21 Feb 2011 12:15:42 -0800 (PST)
Received: by wwa36 with SMTP id 36so6653999wwa.13 for ; Mon, 21 Feb 2011 12:16:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iYT3sFcUIUudV1lr/76PaTha/5dEFWPTzLbQBfMesGw=; b=U9nhnci0IxZWLUd9Vp9nLOU8T52VGZQaN9zC6ujbXv7f6Ik1sMlpmyTJdy08mGPYql o8dyXI6puM6OdSgTbEA4BVrSL27HUlorhaQ8yVleYyjVw6P+QQzoc0p4bbU682yVYQLi 4PzM1W/P4s86UVnRR6gaBnxG6GJQImP1Rod7E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mycNrvqIPLU7C1MLpz2InZo6FJhjGGv/X43KGCW09v+anTLB+y+u1zx/5Bf6R+1rSt 6TfFLRjUMMLJq1wAJ3vmkkZt4DnRUBja6EgtDKNlyYAY8JNvFIWgoTFcV40kMcNkYQyH UPwpyzbms6Tnfq/o2BRrRaGzqd+UjshkLxE94=
MIME-Version: 1.0
Received: by 10.216.71.209 with SMTP id r59mr2790417wed.15.1298319384728; Mon, 21 Feb 2011 12:16:24 -0800 (PST)
Received: by 10.216.242.130 with HTTP; Mon, 21 Feb 2011 12:16:24 -0800 (PST)
In-Reply-To: <4D629962.6010909@ericsson.com>
References:  <4D629962.6010909@ericsson.com>
Date: Mon, 21 Feb 2011 12:16:24 -0800
Message-ID: 
From: skillzero@gmail.com
To: Magnus Westerlund 
Content-Type: text/plain; charset=UTF-8
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RECORD removed?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Feb 2011 20:15:44 -0000

On Mon, Feb 21, 2011 at 8:57 AM, Magnus Westerlund
 wrote:
> skillzero@gmail.com skrev 2011-02-21 17:21:
>> Sorry if this is the wrong mailing list to discuss this, but I noticed
>> in draft-ietf-mmusic-rfc2326bis-26 that the RECORD method has been
>> removed from RTSP. Is this because the recording-like functionality
>> has been removed from RTSP or is there another recommended mechanism
>> in RTSP 2.0?
>>
>> I'm using RTSP to control pushing of audio and video content for live
>> playback on an RTSP server device. So a client connects to the RTSP
>> server, sets up a session, and then sends a RECORD to the server to
>> prepare it to receive audio and video RTP streams. The server then
>> plays those streams via its audio/video hardware (e.g. a TV is the
>> RTSP server and plays the content on its screen and speakers).
>>
>> Is this a valid use of RTSP 2.0?
>
> Hi,
>
> You are certainly on the right list.
>
> We excluded RECORD from RTSP 2.0 because it underspecified nature, and
> the lack of interest from anyone in performing the specification work
> needed.
>
> As your use case appears to be primarily a case of configuring a media
> stream sink. There is no action for the server to do other than to
> render what ever media it receives. Thus I would think that this can be
> easily accomplished using an auto-answering SIP client in what you call
> the server.

Thanks, I'll check out SIP.

My reason for starting with RTSP is that it also has several other
features I need:

- SETUP/TEARDOWN for session management. I use this for correlating
audio and video streams as well as controlling access (e.g. a device
might only support playing one audio stream at a time and I use RTSP
sessions to manage this).

- ANNOUNCE/DESCRIBE for communicating stream details (e.g. encoding
formats, RTP payload type mappings, etc.).

- GET_PARAMETER/SET_PARAMETER for things like controlling audio
volume, setting meta data, etc.

Does this seem like an appropriate use of RTSP?

From magnus.westerlund@ericsson.com  Wed Feb 23 00:06:10 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF8C3A69E6 for ; Wed, 23 Feb 2011 00:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.374
X-Spam-Level: 
X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aVjR4GOEKd1 for ; Wed, 23 Feb 2011 00:06:09 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 539C63A69A2 for ; Wed, 23 Feb 2011 00:06:08 -0800 (PST)
X-AuditID: c1b4fb39-b7b76ae00000276e-dc-4d64c01e82ff
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 63.D7.10094.E10C46D4; Wed, 23 Feb 2011 09:06:54 +0100 (CET)
Received: from [147.214.183.8] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Wed, 23 Feb 2011 09:06:51 +0100
Message-ID: <4D64C01C.8050309@ericsson.com>
Date: Wed, 23 Feb 2011 09:06:52 +0100
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "skillzero@gmail.com" 
References: 	<4D629962.6010909@ericsson.com> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RECORD removed?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 08:06:10 -0000

skillzero@gmail.com skrev 2011-02-21 21:16:
> On Mon, Feb 21, 2011 at 8:57 AM, Magnus Westerlund
>  wrote:
>> skillzero@gmail.com skrev 2011-02-21 17:21:
>>> Sorry if this is the wrong mailing list to discuss this, but I noticed
>>> in draft-ietf-mmusic-rfc2326bis-26 that the RECORD method has been
>>> removed from RTSP. Is this because the recording-like functionality
>>> has been removed from RTSP or is there another recommended mechanism
>>> in RTSP 2.0?
>>>
>>> I'm using RTSP to control pushing of audio and video content for live
>>> playback on an RTSP server device. So a client connects to the RTSP
>>> server, sets up a session, and then sends a RECORD to the server to
>>> prepare it to receive audio and video RTP streams. The server then
>>> plays those streams via its audio/video hardware (e.g. a TV is the
>>> RTSP server and plays the content on its screen and speakers).
>>>
>>> Is this a valid use of RTSP 2.0?
>>
>> Hi,
>>
>> You are certainly on the right list.
>>
>> We excluded RECORD from RTSP 2.0 because it underspecified nature, and
>> the lack of interest from anyone in performing the specification work
>> needed.
>>
>> As your use case appears to be primarily a case of configuring a media
>> stream sink. There is no action for the server to do other than to
>> render what ever media it receives. Thus I would think that this can be
>> easily accomplished using an auto-answering SIP client in what you call
>> the server.
> 
> Thanks, I'll check out SIP.
> 
> My reason for starting with RTSP is that it also has several other
> features I need:
> 
> - SETUP/TEARDOWN for session management. I use this for correlating
> audio and video streams as well as controlling access (e.g. a device
> might only support playing one audio stream at a time and I use RTSP
> sessions to manage this).
> 
> - ANNOUNCE/DESCRIBE for communicating stream details (e.g. encoding
> formats, RTP payload type mappings, etc.).
> 
> - GET_PARAMETER/SET_PARAMETER for things like controlling audio
> volume, setting meta data, etc.
> 
> Does this seem like an appropriate use of RTSP?

Well, your semantics is using the reverse direction for what RTSP PLAY
functionality was designed for. And the RECORD semantics has some
additional things actually doing with recording, rather than controlling
far end playback.

I would say that RTSP 2.0 would need a serious consideration of the
semantics and likely some extensions to cleanly support your use case.
At the same time, I don't know what amount of extensions would be needed
in SIP case for handling the Meta data and other settings.

The question is what your goals are. Do you want a standardized solution
for performing your use case, or simply trying to capitalize on existing
implementations? IF the later than it might be possible to take parts of
a client implementation and drop it into the server side to reverse the
direction of messages. IF you want standardization I that is also
possible, but will need quite a lot of work.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

From Rod.Walsh@nokia.com  Wed Feb 23 06:32:00 2011
Return-Path: 
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B083A6859 for ; Wed, 23 Feb 2011 06:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.341
X-Spam-Level: 
X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHtigvqfaDhG for ; Wed, 23 Feb 2011 06:31:58 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id B5DE63A6845 for ; Wed, 23 Feb 2011 06:31:58 -0800 (PST)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1NEW6Tv012245; Wed, 23 Feb 2011 16:32:40 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Feb 2011 16:32:22 +0200
Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 23 Feb 2011 15:32:22 +0100
From: 
To: 
Date: Wed, 23 Feb 2011 15:32:09 +0100
Thread-Topic: [MMUSIC] draft-johansson-mmusic-grouping-simultaneous-01
Thread-Index: AcvTZns2Vw7ngfYsSyWUopD3Gl3duw==
Message-ID: <4D651A69.7080506@nokia.com>
References: 
In-Reply-To: 
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4D651A697080506nokiacom_"
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Feb 2011 14:32:22.0969 (UTC) FILETIME=[7BF0BA90:01CBD366]
X-Nokia-AV: Clean
Cc: jani.peltotalo@tut.fi, bo.burman@ericsson.com, mmusic@ietf.org
Subject: Re: [MMUSIC] draft-johansson-mmusic-grouping-simultaneous-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Feb 2011 14:32:00 -0000

--_000_4D651A697080506nokiacom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ingemar et al.

Could you please verify whether the "Composite Session" (CS) token syntax a=
nd semantics provide the necessary and sufficient functionality for the SID=
 use cases?

(CS: http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-sdp-00.txt, o=
riginally draft-mehta-rmt-flute-sdp-04, November 2005)

It might not make sense to have two IANA MID tokens doing the same job and,=
 IMHO, CS and SID are both grouping the same content session together for a=
 set of media for the receiver/sink/client to interpret which one or more m=
edia to use. In the RTP & SID case, the expectation is a single media is us=
ed, in the FLUTE and CS case the expectation is that the client understands=
 enough of the channelisation or congestion control to know which one or se=
veral to use (in both cases the same content is delivered within media of t=
he "composite session" / media group). In the (not documented) multi-layer =
delivered over multi-media RTP case I would assume something like the FLUTE=
 and CS expectation of the client understanding which one or more media to =
use.

Sorry about any conflicts or inconvenience caused, no wailing or gnashing o=
f teeth is intended!

There's no obsicle to documenting the RTP/SID use case in draft-ietf-rmt-fl=
ute-sdp if it make sense to use the CS token for this use case. Likewise, d=
ocumenting the RTP/SID case using the CS token in a seperate ID would achie=
ve the same thing.

The relevant (and modifiable) quote from draft-ietf-rmt-flute-sdp is:
3.2.2.  Composite Session Semantics for Protocols other than FLUTE
   The Composite Session mechanism solves the problem of describing
   multiple FLUTE sessions in a single SDP instance.  However, this does
   not place any restrictions on the use of the Composite Session
   mechanism with transport protocols other than FLUTE/UDP, nor on
   whether a complete SDP would include media of other transport
   protocols too.  Specification of semantics beyond the use of FLUTE
   sessions is outside the scope of this document.

(Incidentally, we are interested in any final conflicts and inconveniences =
for the security and congestion control description in draft-ietf-rmt-flute=
-sdp-00 before we revise to 01 and do a standards track WGLC. i.e. - sugges=
ted reuse and extension of existing work is very welcome! So far we've only=
 found RFCs 4567 and 4568 to be promising).

Cheers, Rod.


On 17/11/2010 15:29, ext Ingemar Johansson S wrote:

Hi

I would like to make the WGs aware of this draft
http://tools.ietf.org/id/draft-johansson-mmusic-grouping-simultaneous-01.tx=
t

This draft has relevance for the upcoming multistreams work discussed in DI=
SPATCH (Teleprecense)

=3D=3D=3D=3D=3D=3D=3D=3D=3D
Abstract
   This document proposes an extension to the grouping framework
   [RFC5888].  The extension identifies media descriptions that contain
   different representations of identical content.  An example of this
   is an endpoint that sends both a high-resolution and a low-resolution
   video sequence to a conferencing server.
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Regards
/Ingeamr
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
INGEMAR JOHANSSON  M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
Visit http://labs.ericsson.com !
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_4D651A697080506nokiacom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



  
   =20
    
  
  
    Hi Ingemar et al.

    

    Could you please verify whether the "Composite Session" (CS) token
    syntax and semantics provide the necessary and sufficient
    functionality for the SID use cases?

    

    (CS: http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-sdp-00.txt,
    originally draft-mehta-rmt-flute-sdp-04, November 2005)

    

    It might not make sense to have two IANA MID tokens doing the same
    job and, IMHO, CS and SID are both grouping the same content session
    together for a set of media for the receiver/sink/client to
    interpret which one or more media to use. In the RTP & SID case,
    the expectation is a single media is used, in the FLUTE and CS case
    the expectation is that the client understands enough of the
    channelisation or congestion control to know which one or several to
    use (in both cases the same content is delivered within media of the
    "composite session" / media group). In the (not documented)
    multi-layer delivered over multi-media RTP case I would assume
    something like the FLUTE and CS expectation of the client
    understanding which one or more media to use.

    

    Sorry about any conflicts or inconvenience caused, no wailing or
    gnashing of teeth is intended!

    

    There's no obsicle to documenting the RTP/SID use case in
    draft-ietf-rmt-flute-sdp if it make sense to use the CS token for
    this use case. Likewise, documenting the RTP/SID case using the CS
    token in a seperate ID would achieve the same thing.

    

    The relevant (and modifiable) quote from draft-ietf-rmt-flute-sdp
    is:

    3.2.2.  Composite Session Semantics for Protocols other than FLUTE=


       The Composite Session mechanism solves the problem of desc=
ribing

       multiple FLUTE sessions in a single SDP instance.  Ho=
wever, this
    does

       not place any restrictions on the use of the Composite Ses=
sion

       mechanism with transport protocols other than FLUTE/UDP, n=
or on

       whether a complete SDP would include media of other transp=
ort

       protocols too.  Specification of semantics beyond the=
 use of
    FLUTE

       sessions is outside the scope of this document.

    

    (Incidentally, we are interested in any final conflicts and
    inconveniences for the security and congestion control description
    in draft-ietf-rmt-flute-sdp-00 before we revise to 01 and do a
    standards track WGLC. i.e. - suggested reuse and extension of
    existing work is very welcome! So far we've only found RFCs 4567 and 4568 to be promising).

    

    Cheers, Rod.

    

    

    On 17/11/2010 15:29, ext Ingemar Johansson S wrote:
    

      
      
      [MMUSIC] draft-johansson-mmusic-grouping-simultaneous-01</titl=
e>
      <!-- Converted from text/plain format -->
      <p><font size=3D"2">Hi<br>
          <br>
          I would like to make the WGs aware of this draft<br>
          <a moz-do-not-send=3D"true"
href=3D"http://tools.ietf.org/id/draft-johansson-mmusic-grouping-simultaneo=
us-01.txt">http://tools.ietf.org/id/draft-johansson-mmusic-grouping-simulta=
neous-01.txt</a><br>
          <br>
          This draft has relevance for the upcoming multistreams work
          discussed in DISPATCH (Teleprecense)<br>
          <br>
          =3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
          Abstract<br>
             This document proposes an extension to the grouping
          framework<br>
             [RFC5888].  The extension identifies media desc=
riptions
          that contain<br>
             different representations of identical content. =
; An example
          of this<br>
             is an endpoint that sends both a high-resolution and=
 a
          low-resolution<br>
             video sequence to a conferencing server.<br>
          =3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
          <br>
          Regards<br>
          /Ingeamr<br>
          =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
          INGEMAR JOHANSSON  M.Sc.<br>
          Senior Research Engineer<br>
          <br>
          Ericsson AB<br>
          Multimedia Technologies<br>
          Labratoriegränd 11<br>
          971 28, Luleå, Sweden<br>
          Phone +46-1071 43042<br>
          SMS/MMS +46-73 078 3289<br>
          <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ingemar.s.jo=
hansson@ericsson.com">ingemar.s.johansson@ericsson.com</a><br>
          <a class=3D"moz-txt-link-abbreviated" href=3D"http://www.ericsson=
.com">www.ericsson.com</a><br>
          Visit <a moz-do-not-send=3D"true"
            href=3D"http://labs.ericsson.com">http://labs.ericsson.com</a>
          !<br>
          =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
          _______________________________________________<br>
          mmusic mailing list<br>
          <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:mmusic@ietf.=
org">mmusic@ietf.org</a><br>
          <a moz-do-not-send=3D"true"
            href=3D"https://www.ietf.org/mailman/listinfo/mmusic">https://w=
ww.ietf.org/mailman/listinfo/mmusic</a><br>
        </font>
      </p>
    </blockquote>
  </body>
</html>=

--_000_4D651A697080506nokiacom_--

From iesg-secretary@ietf.org  Wed Feb 23 07:20:43 2011
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA47F3A6A45; Wed, 23 Feb 2011 07:20:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level: 
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHWRiiN2plxC; Wed, 23 Feb 2011 07:20:42 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC153A6A4A; Wed, 23 Feb 2011 07:20:41 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 3.12
Message-ID: <20110223152041.25798.4512.idtracker@localhost>
Date: Wed, 23 Feb 2011 07:20:41 -0800
Cc: mmusic chair <mmusic-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, mmusic mailing list <mmusic@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [MMUSIC] Protocol Action: 'Negotiation of Generic Image Attributes in SDP' to	Proposed Standard (draft-ietf-mmusic-image-attributes-11.txt)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2011 15:20:43 -0000

The IESG has approved the following document:
- 'Negotiation of Generic Image Attributes in SDP'
  (draft-ietf-mmusic-image-attributes-11.txt) as a Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-image-attributes/




Technical Summary

This document proposes a new generic session set up attribute to make
it possible to negotiate different image attributes such as image
size. A possible use case is to make it possible for a low-end hand-
held terminal to display video without the need to rescale the image,
something that may consume large amounts of memory and processing
power. The draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is
transmitted.

Working Group Summary

Work on this document was initiated to satisfy 3GPP requirements.
It benefited from comments on and off the list before going to WGLC,
and attracted a number of comments during WGLC.

Document Quality

3GPP confirmed that the emerging document met their requirements,
and its content has been taken up into their specifications. 

Personnel

Tom Taylor is the Document Shepherd.
Robert Sparks is the responsible Area Director.


From bgreeven@huawei.com  Sun Feb 27 17:15:30 2011
Return-Path: <bgreeven@huawei.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5063A6A4B for <mmusic@core3.amsl.com>; Sun, 27 Feb 2011 17:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y6ifw4mu4MI for <mmusic@core3.amsl.com>; Sun, 27 Feb 2011 17:15:30 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 899F63A6A3B for <mmusic@ietf.org>; Sun, 27 Feb 2011 17:15:29 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHA00NCHZJ30B@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 28 Feb 2011 09:16:16 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHA00818ZJ33I@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 28 Feb 2011 09:16:15 +0800 (CST)
Received: from z00127286a ([10.70.109.54]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHA00D21ZIZ4L@szxml04-in.huawei.com> for mmusic@ietf.org; Mon, 28 Feb 2011 09:16:15 +0800 (CST)
Date: Mon, 28 Feb 2011 09:16:11 +0800
From: Bert Greevenbosch <bgreeven@huawei.com>
To: mmusic@ietf.org
Message-id: <008101cbd6e5$164449a0$42ccdce0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_QO78OZN0lQRKSd14AJ6ntw)"
Content-language: en-gb
Thread-index: AcvW5RYlKyh34dU+SMuaNUs3H40pNA==
Subject: [MMUSIC] Upload of draft-greevenbosch-mmusic-parallax-attribute
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2011 01:15:31 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_QO78OZN0lQRKSd14AJ6ntw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hello all,

 

I have uploaded an individual draft
"draft-greevenbosch-mmusic-parallax-attribute".

 

The draft concerns streaming in 3D. More precisely, it defines a new
ParallaxInfo attribute in SDP, which is used to signal the displayed
position of 2D objects, such as text/subtitles or on-screen display, in the
3D space.

 

The draft can be accessed under the following link:

https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribut
e/

 

I look forward to your comments.

 

Best regards,

Bert

 

---

Bert Greevenbosch M.Sc.

Senior Research and Standardisation Engineer

 

email: bgreeven@huawei.com

telephone: +86-755-28978088

 

HUAWEI TECHNOLOGIES CO.,LTD.

Building F1 / Floor 8

Huawei Industrial Base

Bantian Longgang

Shenzhen  518129

P.R. China

 

****************************************************************************
***

This email and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained here in any way (including, but
not limited to, total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient(s) is prohibited. If you
receive this email in error, please notify the sender by phone or email
immediately and delete it!

****************************************************************************
**

 


--Boundary_(ID_QO78OZN0lQRKSd14AJ6ntw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal>Hello all,<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>I have uploaded an individual draft "draft-greevenbosch-mmusic-parallax-attribute".<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>The draft concerns streaming in 3D. More precisely, it
defines a new ParallaxInfo attribute in SDP, which is used to signal the displayed
position of 2D objects, such as text/subtitles or on-screen display, in the 3D
space.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>The draft can be accessed under the following link:<o:p></o:p></p>

<p class=MsoNormal>https://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-parallax-attribute/<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>I look forward to your comments.<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>Best regards,<o:p></o:p></p>

<p class=MsoNormal>Bert<o:p></o:p></p>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal><span lang=EN-US>---<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>Bert Greevenbosch M.Sc.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>Senior Research and Standardisation
Engineer<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>

<p class=MsoNormal><span lang=EN-US>email: bgreeven@huawei.com<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>telephone: +86-755-28978088<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>

<p class=MsoNormal><span lang=EN-US>HUAWEI TECHNOLOGIES CO.,LTD.<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>Building F1 / Floor 8<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>Huawei Industrial Base<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>Bantian Longgang<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>Shenzhen  518129<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>P.R. China<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p>

<p class=MsoNormal><span lang=EN-US>*******************************************************************************<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>This email and its attachments contain
confidential information from HUAWEI, which is intended only for the person or
entity whose address is listed above. Any use of the information contained here
in any way (including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended recipient(s)
is prohibited. If you receive this email in error, please notify the sender by
phone or email immediately and delete it!<o:p></o:p></span></p>

<p class=MsoNormal><span lang=EN-US>******************************************************************************<o:p></o:p></span></p>

<p class=MsoNormal><o:p> </o:p></p>

</div>

</body>

</html>

--Boundary_(ID_QO78OZN0lQRKSd14AJ6ntw)--

From Internet-Drafts@ietf.org  Mon Feb 28 20:00:03 2011
Return-Path: <Internet-Drafts@ietf.org>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA983A6D9B; Mon, 28 Feb 2011 20:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level: 
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V8SviaxzRjr; Mon, 28 Feb 2011 20:00:02 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2826F3A6D16; Mon, 28 Feb 2011 20:00:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.12
Message-ID: <20110301040002.7768.98328.idtracker@localhost>
Date: Mon, 28 Feb 2011 20:00:02 -0800
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-sdp-media-capabilities-11.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2011 04:00:03 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.


	Title           : SDP Media Mapabilities Negotiation
	Author(s)       : R. Gilman, et al.
	Filename        : draft-ietf-mmusic-sdp-media-capabilities-11.txt
	Pages           : 47
	Date            : 2011-02-28

Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating
transport protocols and attributes.  In this document, we extend the
framework by defining media capabilities that can be used to
negotiate media types and their associated parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-capabilities-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-media-capabilities-11.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-02-28195153.I-D@ietf.org>


--NextPart--