From gonzalo.camarillo@ericsson.com Wed Aug 3 01:08:30 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F5821F8B39 for ; Wed, 3 Aug 2011 01:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.004 X-Spam-Level: X-Spam-Status: No, score=-106.004 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBcDV1XXgIzl for ; Wed, 3 Aug 2011 01:08:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4E421F8B35 for ; Wed, 3 Aug 2011 01:08:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-da-4e3901ecb5f3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 72.B5.09774.CE1093E4; Wed, 3 Aug 2011 10:08:12 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 3 Aug 2011 10:08:12 +0200 Message-ID: <4E3901EC.3060608@ericsson.com> Date: Wed, 3 Aug 2011 11:08:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <3A2AFEE4-4C7D-47EA-B934-D07E44430417@acmepacket.com> In-Reply-To: <3A2AFEE4-4C7D-47EA-B934-D07E44430417@acmepacket.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] resurecting the CCAP attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 08:08:30 -0000 Hi Hadriel, a quick question on these two drafts. RFC 4566 defines the format of the c line as follows: c= Per the emails below, the function of the ccap attribute would be to choose between different nettypes while the purpose of the altc attribute would be to choose between different addrtypes, right? That is, you would use ccap to choose between the following configurations: c=IN IP4 example.com c=PSTN E164 +15551234 While you will use altc to choose between: c=IN IP4 example.com c=IN IP6 example.com Is this the intention? Thanks, Gonzalo On 27/07/2011 8:33 PM, Hadriel Kaplan wrote: > So what happens if a UAC puts both an IPv4 and IPv6 addresses as ccap - > is the UAS mandated to ignore it, or reject the request, or may it use it? > > I ask because we've taken the altc draft outside of the IETF as an > independent submission to the RFC editor, using the altc syntax. If it > would be better, we could instead change our independent submission to > say "implement the sdp-icap-bcap using CCAP but ignore the MUST NOT ". > I don't know if that would be better or worse, so just asking. > > -hadriel > > > On Jul 27, 2011, at 11:17 AM, Andrew Allen wrote: > >> >> Yesterday several MMUSIC participants including Jonathan Lennox and >> Miguel Garcia got together to discuss what to do regarding the CCAP >> attribute which is currently used in 3GPP specifications but was >> removed from the misc-cap draft (which then became the sdp-icap-bcap >> draft without the CCAP attribute). The CCAP attribute was removed >> after earlier comments on the list from Jonathan regarding the >> possibility that CCAP might be used as an alternative to ICE for >> negotiating IP addresses for the C line (see email thread below). 3GPP >> currently utilize the CCAP attribute with SDP-cap-neg for negotiation >> of use of a circuit switched call for the audio media as an >> alternative to an audio RTP stream over packet switched access. CCAP >> is used to offer the PSTN net type and E.164 number used to set up >> that call. >> >> After a thorough discussion the conclusion of those involved in the >> discussion (including Jonathan) was that the best way forward given >> the constraints of the 3GPP architecture is to resurrect the CCAP >> attribute but with some wording that places constraints on its usage >> so that it isnt used to negotiate alternative addresses for a network >> type for which ICE can be used to negotiate addresses. This means that >> CCAP could be used to negotiate the possibility to use PSTN net type >> as an alternative to the IN net type but that using alternative IP >> address candidates within the IN net type would need to be negotiated >> using ICE not using CCAP. >> >> Are the any concerns from other MMUSIC participants if CCAP is >> resurrected (probably in an again renamed version of the sdp-icap-bcap >> draft that would again include CCAP) with appropriate text to address >> the ICE issue along the lines of above? >> >> Andrew >> >> * /To/: "Simo.Veikkolainen at nokia.com >> " > nokia.com >, "mmusic at >> ietf.org " > > >> * /Subject/: Re: [MMUSIC] What to do with the ccap attribute? >> * /From/: Jonathan Lennox > > >> * /Date/: Mon, 10 May 2010 11:24:36 -0400 >> * /Accept-language/: en-US >> * /Acceptlanguage/: en-US >> * /Delivered-to/: mmusic at core3.amsl.com >> >> * /In-reply-to/: > NOK-EUMSG-01.mgdnok.nokia.com >> > >> * /List-archive/: >> * /List-help/: >> * /List-id/: Multiparty Multimedia Session Control Working Group >> > >> * /List-post/: >> * /List-subscribe/: >> , >> >> * /List-unsubscribe/: >> , >> >> * /References/: > NOK-EUMSG-01.mgdnok.nokia.com >> > >> * /Thread-index/: AcrwJWqZpvLJ586JTjK5XQiTSB6kSAALoU1w >> * /Thread-topic/: What to do with the ccap attribute? >> >> ------------------------------------------------------------------------ >> I think it'd be best to unify the requirements of this use case >> (separate IP and PSTN addresses) with the requirements of the >> IPv4/IPv6 transition use cases, and come up with a common solution. >> >> Having two mechanisms (ANAT and ICE) to specify multiple connection >> addresses is a standard but annoying consequence of a technology >> transition. Having three (ANAT, ICE, and ALTC) gets unmanageable. >> Having four (ANAT, ICE, ALTC, and CCAP) is just silly. >> >> -- >> Jonathan Lennox >> Vidyo, Inc >> jonathan at vidyo.com >> >> > -----Original Message----- >> > From: Simo.Veikkolainen at nokia.com [mailto:Simo.Veikkolainen at nokia.com ] >> > Sent: Monday, May 10, 2010 5:45 AM >> > To: mmusic at ietf.org >> > Subject: [MMUSIC] What to do with the ccap attribute? >> > >> > Now that the discussion on ICE and v6 transition has quieted down, I >> > would like to ask for the list's opinion on how to proceed with the >> > ccap attribute defined in http://tools.ietf.org/html/draft-ietf-mmusic- >> > sdp-misc-cap >> > >> > Note that this draft will be re-submitted as an individual document >> > according to the WG decision in IETF#77. Nevertheless it contains the >> > most up-to-date text, hence the reference. >> > >> > As a short reminder, the misc-cap document defines capability >> > attributes for "i=", "b"= and "c=" lines (icap, bcap and ccap, >> > respectively). The ccap capability attribute is used to indicate >> > alternative connection addresses. Our use case for this has been the >> > ability to indicate alternative IP and PSTN addresses; a feature which >> > is needed in some 3GPP scenarios. >> > >> > As ccap is currently specified, it includes also the port number in >> > addition to the contents of a "c=" line (, and the >> > ). The port number is needed in order to indicate a >> > port number for internet addresses, the PSTN addresses don't have a >> > similar concept. >> > >> > Now, as a side effect, the ccap attribute could also be used to >> > circumvent ICE, if one used IP4 and IP6 addrtypes as alternatives. >> > >> > In order to move forward with the misc-cap document I'm now asking how >> > do folks feel we should handle this issue. Possible alternatives are at >> > least: >> > >> > 1. Leave the current text as is (see [1]). >> > >> > 2. Make a more strict statement that ccap SHOULD NOT be used for v4/v6 >> > address pairs. >> > >> > 3. Come up with altogether different way of indicating alternative >> > connection addresses that fulfill our use case (PSTN/IP addresses). >> > >> > Regards, >> > Simo >> > >> > [1] The text from Section 3.1.2 from http://tools.ietf.org/html/draft- >> > ietf-mmusic-sdp-misc-cap currently says >> > " >> > The connection information capability can be used to negotiate the >> > use of IPv4 or IPv6 addresses without resort to Interactive >> > Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice]. Note, >> > however, that ICE provides for real-time reachability testing of >> > multiple addresses, whereas use of the connection capability forces >> > an early choice of connection address. >> > >> > [I-D.boucadair-mmusic-altc] describes a simple method of specifying >> > alternative network addresses when the transport protocol () >> > is the same. >> > " >> > _______________________________________________ >> > mmusic mailing list >> > mmusic at ietf.org >> > https://www.ietf.org/mailman/listinfo/mmusic >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute >> non-public information. Any use of this information by anyone other >> than the intended recipient is prohibited. If you have received this >> transmission in error, please immediately reply to the sender and >> delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. > From aallen@rim.com Wed Aug 3 07:16:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692BD21F8AE9 for ; Wed, 3 Aug 2011 07:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.596 X-Spam-Level: X-Spam-Status: No, score=-4.596 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX7A20FDS8IZ for ; Wed, 3 Aug 2011 07:16:58 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id DC2D321F8658 for ; Wed, 3 Aug 2011 07:16:57 -0700 (PDT) X-AuditID: 0a412830-b7c48ae000005798-e3-4e39585b48c0 Received: from XHT110CNC.rim.net (xht110cnc.rim.net [10.65.22.55]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 2D.C7.22424.B58593E4; Wed, 3 Aug 2011 14:16:59 +0000 (GMT) Received: from XCT104ADS.rim.net (10.67.111.45) by XHT110CNC.rim.net (10.65.22.55) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 3 Aug 2011 10:17:07 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.01.0289.001; Wed, 3 Aug 2011 09:17:05 -0500 From: Andrew Allen To: Gonzalo Camarillo , Hadriel Kaplan , "'simo.veikkolainen@nokia.com'" , "Miguel A. Garcia" Thread-Topic: [MMUSIC] resurecting the CCAP attribute Thread-Index: AcxMcFWSeEr66jGGTs2RSJrRuz2lcwAPOfSAAUxKHAAAAkrnQA== Date: Wed, 3 Aug 2011 14:17:04 +0000 Message-ID: References: <3A2AFEE4-4C7D-47EA-B934-D07E44430417@acmepacket.com> <4E3901EC.3060608@ericsson.com> In-Reply-To: <4E3901EC.3060608@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsXC5ShmrhsdYelncOK4tMWm5SuZLOZefs5u sebTCnaLqcsfs1ic+3SXxYHVY9PkzWwev75eZfNYsuQnk8fdW5eYAliiGhhtEvPy8ksSS1IV UlKLk22VfFLTE3MUAooyyxKTKxVcMouTcxIzc1OLlBQyU2yVTJQUCnISk1NzU/NKbJUSCwpS 81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWuoZKdLhJI+Med8f7rJraCrwEVz7s7 WRoYjzp0MXJwSAiYSFzdVtXFyAlkiklcuLeerYuRi0NIoIdJ4ue1SVDOEkaJ3p/72UCqhAQ2 M0rMbHUEsdkElCWW/57BCGKLCFxnlNi9zxVkKLOAusTVxUEgYWGg+Q8O/2MECYsImErcnFwK Ue0ksfndFnYQm0VARWJ612xWEJtXwE2ia9F1Roi1CxglruxdxAyS4BTQkfi1vY0JxGYEOvT7 qTVgNrOAuMStJ/OZIB4QkFiy5zwzhC0q8fLxP1YIW1FiUed3Roh6HYkFuz+xQdjaEssWvmaG WCwocXLmExaIF6UldpxcwziBUWIWkhWzkLTPQtI+C0n7AkaWVYyCuRnFBmaGyXnJekWZuXp5 qSWbGMFpSMNgB+OEvVqHGAU4GJV4eH2CLf2EWBPLiitzDzFKcDArifC28wKFeFMSK6tSi/Lj i0pzUosPMVoAg2gisxR3cj4wReaVxBsbGKBwlMR5w6QN/IQE0oHpKzs1tSC1CKaViYNTqoHx lGfj5TUCM7f8eJR3ZMbtDcuXW+xg/89TouLXE5Nn3Kxm2m3u761kPOmv4FXuPfemP+vJeBY7 7fLLZmXhG2XdL3N+t1/pLPbR3+c4Zfuxbc9W2tz2jvUs03xTVrK3vtOuUqzTqqjz6f2yt7bf zaprjvWGG396utJnavSnc7zKS7LdVqff3bFLiaU4I9FQi7moOBEAW0+1blwDAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] resurecting the CCAP attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 14:16:59 -0000 Gonzalo Adding Simo and Miguel The example and functionality you show for CCAP is what we need for 3GPP. I= can't knowledgably comment on altc but your altc description is also my und= erstanding. Andrew > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Wednesday, August 03, 2011 3:08 AM > To: Hadriel Kaplan > Cc: Andrew Allen; mmusic@ietf.org > Subject: Re: [MMUSIC] resurecting the CCAP attribute > > Hi Hadriel, > > a quick question on these two drafts. RFC 4566 defines the format of the > c line as follows: > > c=3D > > Per the emails below, the function of the ccap attribute would be to > choose between different nettypes while the purpose of the altc > attribute would be to choose between different addrtypes, right? > > That is, you would use ccap to choose between the following > configurations: > > c=3DIN IP4 example.com > c=3DPSTN E164 +15551234 > > While you will use altc to choose between: > > c=3DIN IP4 example.com > c=3DIN IP6 example.com > > Is this the intention? > > Thanks, > > Gonzalo > > > On 27/07/2011 8:33 PM, Hadriel Kaplan wrote: > > So what happens if a UAC puts both an IPv4 and IPv6 addresses as ccap - > > is the UAS mandated to ignore it, or reject the request, or may it use > it? > > > > I ask because we've taken the altc draft outside of the IETF as an > > independent submission to the RFC editor, using the altc syntax. If it > > would be better, we could instead change our independent submission to > > say "implement the sdp-icap-bcap using CCAP but ignore the MUST NOT ..."= . > > I don't know if that would be better or worse, so just asking. > > > > -hadriel > > > > > > On Jul 27, 2011, at 11:17 AM, Andrew Allen wrote: > > > >> > >> Yesterday several MMUSIC participants including Jonathan Lennox and > >> Miguel Garcia got together to discuss what to do regarding the CCAP > >> attribute which is currently used in 3GPP specifications but was > >> removed from the misc-cap draft (which then became the sdp-icap-bcap > >> draft without the CCAP attribute). The CCAP attribute was removed > >> after earlier comments on the list from Jonathan regarding the > >> possibility that CCAP might be used as an alternative to ICE for > >> negotiating IP addresses for the C line (see email thread below). 3GPP > >> currently utilize the CCAP attribute with SDP-cap-neg for negotiation > >> of use of a circuit switched call for the audio media as an > >> alternative to an audio RTP stream over packet switched access. CCAP > >> is used to offer the PSTN net type and E.164 number used to set up > >> that call. > >> > >> After a thorough discussion the conclusion of those involved in the > >> discussion (including Jonathan) was that the best way forward given > >> the constraints of the 3GPP architecture is to resurrect the CCAP > >> attribute but with some wording that places constraints on its usage > >> so that it isn't used to negotiate alternative addresses for a network > >> type for which ICE can be used to negotiate addresses. This means that > >> CCAP could be used to negotiate the possibility to use PSTN net type > >> as an alternative to the IN net type but that using alternative IP > >> address candidates within the IN net type would need to be negotiated > >> using ICE not using CCAP. > >> > >> Are the any concerns from other MMUSIC participants if CCAP is > >> resurrected (probably in an again renamed version of the sdp-icap-bcap > >> draft that would again include CCAP) with appropriate text to address > >> the ICE issue along the lines of above? > >> > >> Andrew > >> > >> * /To/: "Simo.Veikkolainen at nokia.com > >> " >> nokia.com >, "mmusic at > >> ietf.org " >> > > >> * /Subject/: Re: [MMUSIC] What to do with the ccap attribute? > >> * /From/: Jonathan Lennox >> > > >> * /Date/: Mon, 10 May 2010 11:24:36 -0400 > >> * /Accept-language/: en-US > >> * /Acceptlanguage/: en-US > >> * /Delivered-to/: mmusic at core3.amsl.com > >> > >> * /In-reply-to/: >> NOK-EUMSG-01.mgdnok.nokia.com > >> > > > >> * /List-archive/: > >> * /List-help/: > >> * /List-id/: Multiparty Multimedia Session Control Working Group > >> > > >> * /List-post/: > >> * /List-subscribe/: > >> , > >> > >> * /List-unsubscribe/: > >> , > >> > >> * /References/: >> NOK-EUMSG-01.mgdnok.nokia.com > >> > > > >> * /Thread-index/: AcrwJWqZpvLJ586JTjK5XQiTSB6kSAALoU1w > >> * /Thread-topic/: What to do with the ccap attribute? > >> > >> ----------------------------------------------------------------------- > - > >> I think it'd be best to unify the requirements of this use case > >> (separate IP and PSTN addresses) with the requirements of the > >> IPv4/IPv6 transition use cases, and come up with a common solution. > >> > >> Having two mechanisms (ANAT and ICE) to specify multiple connection > >> addresses is a standard but annoying consequence of a technology > >> transition. Having three (ANAT, ICE, and ALTC) gets unmanageable. > >> Having four (ANAT, ICE, ALTC, and CCAP) is just silly. > >> > >> -- > >> Jonathan Lennox > >> Vidyo, Inc > >> jonathan at vidyo.com > >> > >> > -----Original Message----- > >> > From: Simo.Veikkolainen at nokia.com > [mailto:Simo.Veikkolainen at nokia.com ] > >> > Sent: Monday, May 10, 2010 5:45 AM > >> > To: mmusic at ietf.org > >> > Subject: [MMUSIC] What to do with the ccap attribute? > >> > > >> > Now that the discussion on ICE and v6 transition has quieted down, I > >> > would like to ask for the list's opinion on how to proceed with the > >> > ccap attribute defined in http://tools.ietf.org/html/draft-ietf- > mmusic- > >> > sdp-misc-cap > >> > > >> > Note that this draft will be re-submitted as an individual document > >> > according to the WG decision in IETF#77. Nevertheless it contains the > >> > most up-to-date text, hence the reference. > >> > > >> > As a short reminder, the misc-cap document defines capability > >> > attributes for "i=3D", "b"=3D and "c=3D" lines (icap, bcap and ccap, > >> > respectively). The ccap capability attribute is used to indicate > >> > alternative connection addresses. Our use case for this has been the > >> > ability to indicate alternative IP and PSTN addresses; a feature > which > >> > is needed in some 3GPP scenarios. > >> > > >> > As ccap is currently specified, it includes also the port number in > >> > addition to the contents of a "c=3D" line (, and > the > >> > ). The port number is needed in order to indicate > a > >> > port number for internet addresses, the PSTN addresses don't have a > >> > similar concept. > >> > > >> > Now, as a side effect, the ccap attribute could also be used to > >> > circumvent ICE, if one used IP4 and IP6 addrtypes as alternatives. > >> > > >> > In order to move forward with the misc-cap document I'm now asking > how > >> > do folks feel we should handle this issue. Possible alternatives are > at > >> > least: > >> > > >> > 1. Leave the current text as is (see [1]). > >> > > >> > 2. Make a more strict statement that ccap SHOULD NOT be used for > v4/v6 > >> > address pairs. > >> > > >> > 3. Come up with altogether different way of indicating alternative > >> > connection addresses that fulfill our use case (PSTN/IP addresses). > >> > > >> > Regards, > >> > Simo > >> > > >> > [1] The text from Section 3.1.2 from > http://tools.ietf.org/html/draft- > >> > ietf-mmusic-sdp-misc-cap currently says > >> > " > >> > The connection information capability can be used to negotiate the > >> > use of IPv4 or IPv6 addresses without resort to Interactive > >> > Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice]. Note, > >> > however, that ICE provides for real-time reachability testing of > >> > multiple addresses, whereas use of the connection capability > forces > >> > an early choice of connection address. > >> > > >> > [I-D.boucadair-mmusic-altc] describes a simple method of > specifying > >> > alternative network addresses when the transport protocol > () > >> > is the same. > >> > " > >> > _______________________________________________ > >> > mmusic mailing list > >> > mmusic at ietf.org > >> > https://www.ietf.org/mailman/listinfo/mmusic > >> > >> > >> --------------------------------------------------------------------- > >> This transmission (including any attachments) may contain confidential > >> information, privileged material (including material protected by the > >> solicitor-client or other applicable privileges), or constitute > >> non-public information. Any use of this information by anyone other > >> than the intended recipient is prohibited. If you have received this > >> transmission in error, please immediately reply to the sender and > >> delete this information from your system. Use, dissemination, > >> distribution, or reproduction of this transmission by unintended > >> recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Wed Aug 3 13:51:17 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2B221F865B for ; Wed, 3 Aug 2011 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpF405GOAjqB for ; Wed, 3 Aug 2011 13:51:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F119721F863A for ; Wed, 3 Aug 2011 13:51:16 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4f-4e39b4d0c366 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BC.04.09774.0D4B93E4; Wed, 3 Aug 2011 22:51:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 3 Aug 2011 22:51:28 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 22:51:26 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: Introduction Thread-Index: AQHMUhdA8YGk1F+pH0+8d6TNhJ+irA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B6C@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: Introduction X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 20:51:18 -0000 Hi, I have been asked to provide comments on draft-singh-avtcore-mprtp-02, from= an "SDP perspective". I have a number of comments, so I will split them into separate e-mails, in= order for possible discussions to be more manageble. As you will see, in addition to section 11 (SDP) I am also commenting on ma= ny of the other sections, so one could claim that many of my comments are n= ot related to SDP. However, there are many things (related to connectivity = checks, providing multiple IP addresses etc) in the draft which are very cl= ose to the "heart and mind of MMUSIC", so I think it's appropriate to give = them here.=20 But, having said that, please let me know if some things should be discusse= d in AVTCORE instead :) I have prefixed editorial comments/questions with ED and functional ones wi= th FU. Example: ED_11_1-5 =3D the 5th editorial comment of section 11.1. Regards, Christer= From christer.holmberg@ericsson.com Wed Aug 3 13:53:59 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B523811E8080 for ; Wed, 3 Aug 2011 13:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZl6mEblTh1T for ; Wed, 3 Aug 2011 13:53:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EF9D911E807D for ; Wed, 3 Aug 2011 13:53:58 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-3f-4e39b5727719 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 87.24.09774.375B93E4; Wed, 3 Aug 2011 22:54:11 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 3 Aug 2011 22:54:10 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 22:54:09 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: General - Connectivity checks Thread-Index: AQHMUhdqAT7RZAEPnE+VK2zdKU4bDg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B6D@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: General - Connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 20:53:59 -0000 Hi, Below are some general comments on the connectivity checks. More specific c= omments will be found in my e-mails commending the individual sections. Regards, Christer Connectivity checks: FU_GEN-1: The document defines a new type of connectivity check. We should= have a=20 discussion whether that's a good thing to do or not, but assuming it will = be done,=20 as I also indicate in my editorial comments, you need to more clearly defi= ne the "RTCP=20 connectivity checks" somewhere in the document, and then refer to it. I think you also need to describe the characteristic differences (security= etc)=20 compared to STUN connectivity checks, and I think you should have some tex= t on why=20 you define a new type of connectivity check in the first place (rather tha= n relying on=20 STUN).= From christer.holmberg@ericsson.com Wed Aug 3 13:59:14 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B211E807D for ; Wed, 3 Aug 2011 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bl+eMQVyDRej for ; Wed, 3 Aug 2011 13:59:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B111E807C for ; Wed, 3 Aug 2011 13:59:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b1-4e39b6a7754f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2B.93.20773.7A6B93E4; Wed, 3 Aug 2011 22:59:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 3 Aug 2011 22:59:19 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 22:57:10 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: General - Alternative IPv4 and v6 addresses Thread-Index: AQHMUhd7oSex7yT3IEWnCVVsw+ws0w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B6F@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: General - Alternative IPv4 and v6 addresses X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 20:59:14 -0000 Hi, Below is a comment regarding the potential usage of the mechanism to provid= e alternative IPv4 and v6 addresses. Regards, Christer IPv4/v6 addresses: FU_GEN-2: The document does not explicitly mention it, but I guess one cou= ld provide both IPv4 and IPv6 addresses. Non-ICE mechanism of doing that have been rejected in the past. And, eventhough the idea is to be able to = use multiple paths, an entity is not forced to do so. From christer.holmberg@ericsson.com Wed Aug 3 14:05:28 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9A11E8088 for ; Wed, 3 Aug 2011 14:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1kF4Uel1P9e for ; Wed, 3 Aug 2011 14:05:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 767A011E807C for ; Wed, 3 Aug 2011 14:05:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-bd-4e39b823bbea Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BA.84.09774.328B93E4; Wed, 3 Aug 2011 23:05:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Aug 2011 23:05:39 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 23:05:35 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: MPRTP Architecture (Section 4 ) - SIP ALERT Thread-Index: AQHMUhfbkzzxSu7flkCmPaF2zdZDXA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B71@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: MPRTP Architecture (Section 4 ) - SIP ALERT X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 21:05:28 -0000 Hi, Below is a comment on the normative statements regarding SIP signalling. I = think the discussion belongs to SIPCORE, though. Regards, Christer Section 4.1: =20 FU_4-1: The text says that, for SIP, one SHOULD use SCTP or MPTCP instead = of UDP or TCP, but there is no justification. Also, isn't such statement is outside the scope of the document? From christer.holmberg@ericsson.com Wed Aug 3 14:05:51 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1A11E808C for ; Wed, 3 Aug 2011 14:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOAUDSD9jI0m for ; Wed, 3 Aug 2011 14:05:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C31CF11E807C for ; Wed, 3 Aug 2011 14:05:47 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-17-4e39b837d9b3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E2.E3.20773.738B93E4; Wed, 3 Aug 2011 23:06:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 3 Aug 2011 23:05:59 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 23:05:57 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: Example Media Flow Diagrams (Section 5) Thread-Index: AcxSISO1WeNXuaKNRDiRNCrOgi0KQg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B72@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: Example Media Flow Diagrams (Section 5) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 21:05:51 -0000 Hi, Below are my comments/questions on section 5. Regards, Christer Section 5.3: ED_5_3-1: I don't think this section belongs to the example call flows. ED_5_3-2: The text talks about "ahead of time". Ahead of what time? From christer.holmberg@ericsson.com Wed Aug 3 14:05:56 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A201211E8096 for ; Wed, 3 Aug 2011 14:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQOmij6lC4ev for ; Wed, 3 Aug 2011 14:05:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D4ECF11E8094 for ; Wed, 3 Aug 2011 14:05:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-da-4e39b83fe5a8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.84.09774.F38B93E4; Wed, 3 Aug 2011 23:06:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 3 Aug 2011 23:06:07 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 23:06:06 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: Available Mechanisms within the Functional Blocks (Section 7) Thread-Index: AcxSISjlxd+4HGTxSoWWiCCHNN7/2w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B73@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: Available Mechanisms within the Functional Blocks (Section 7) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 21:05:56 -0000 Hi, Below are my comments/questions on section 7. Regards, Christer Section 7.1: The text says: "Furthermore, ICE [3] may be used for discovering and performing connectiv= ity checks during session setup." ED_7_1-1: Discovering what? ED_7_1-2: ICE can also be used during mid-session modification (as you als= o later indicate=20 in section 7.3). =09 Section 7.3: ED_7_3-1: "(using SDP)" -> "(e.g. using SDP)". The text says: "If the connectivity packets are received by the peers, then multimedia da= ta can=20 flow between the new address, port pairs." ED_7_3-2: I think it would be better to be more general, and talk about wh= en the connectivity=20 checks have been successfully performed, or something like that. Because, = when using ICE we talk=20 about STUN connectivity messages, rather than connectivity packets. Section 7.5: ED_7_5-1: I guess you are going to add some text here, or remove the secti= on. But, as I commented earlier,=20 (FU_4-1), I don't think it's within the scope of this draft to make any re= commendations regarding SIP/SDP transport.=20 From christer.holmberg@ericsson.com Wed Aug 3 14:06:02 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8911E809A for ; Wed, 3 Aug 2011 14:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+PzUnO+9Xl4 for ; Wed, 3 Aug 2011 14:06:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDC511E8099 for ; Wed, 3 Aug 2011 14:06:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e2-4e39b845f028 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.84.09774.648B93E4; Wed, 3 Aug 2011 23:06:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 3 Aug 2011 23:06:13 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 23:06:10 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: MPRTP Protocol (Section 8) Thread-Index: AcxSISvHlIcAJ7TRTXq4CTOw0fvHBA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B75@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: MPRTP Protocol (Section 8) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 21:06:02 -0000 Hi, Below are my comments/questions on section 8. Regards, Christer Section 8: The text says: "To enable a quick start of a multimedia session, a multipath session MUST be upgraded from a single path session. Therefore, no explicit changes are needed in multimedia session setup and the session can be setup as before." ED_8-1: I don't understand what the text is trying to say. Especially the = second sentence is very unclear to me. ED_8-2: In the picture, would it be better to use "Interface" instead of "= Address", to be more consistant in=20 terminology with the associated text in section 8.1 (and the terminology u= sed elsewhere throughout the document). Section 8.1: ED_8_1-1: In bullet one, I am not sure what you mean by "standard session = setup". I assume you are talking about=20 "establishment of a normal RTP session", or something like that. ED_8_1-2: "This may be SIP or RTSP." -> "This can be performed e.g. using = SIP or RTSP." ED_8_1-3: "Following the setup, like in a conventional RTP scenario," -> "= When the RTP session has been established," ED_8_1-4: "Host B is an MPRTP-capable media sender" -> "Host B supports se= nding of media using MPRTP" ED_8_1-5: "another interface B2." -> "an additional interface, B2." ED_8_1-6: "Host A is an MPRTP-capable media receiver and becomes aware of = another interface A2." -> "Host A supports receiving of media using MPRTP, and becomes aware of an a= dditional interface, A2." Section 8.1.1: The text says: "On receiving the MPRTP Interface Advertisement, an MPRTP-capable receiver= MUST respond with its own set of interfaces." ED_8_1_1-1: I assume the receiver should, even if it supports MPRTP, still= be able to choose=20 whether it wants to use it. So, maybe saying something like: "On receiving= the MPRTP Interface=20 Advertisement, if the receiver supports and is willing to use MPRTP, it MU= ST response with...". ED_8_1_1-2: "MUST respond with the default..." -> "MUST indicate the defau= lt..." ED_8_1_1-3: Please clarify what "default" means. I assume you are talking = about the ports and=20 addresses that the endpoint would use for a normal RTP session. Section 8.1.2: ED_8_1_2-1: "After MPRTP support has been discovered" -> "After MPRTP supp= ort has been negotiated" ED_8_1_2-2: What is an "interface pair"? ED_8_1_2-3: I think you should define the "RTCP connectivity checks" somew= here else in the document,=20 and simply refer to them in this section. ED_8_1_2-4: Is there a reason why STUN connectivity checks can't be used (= even if the endpoints don't use ICE, or even SDP, to negotiate the interfaces)? ED_8_1_2-5: I think the section should talk about the collecting of candic= ate subflows, as they are=20 later used in secion 8.1.3. Section 8.1.3: The text says: "The sender MAY open any number of subflows from the set of candidate subflows after performing connectivity checks." ED_8_1_3-1: Clarify what "open a subflow" means. ED_8_1_3-2: Define "candicate subflow". I assume it is the interface pairs= , for which sucessful=20 connectivity checks have been performed, something like that. I also think= that section 8.1.2=20 should talk about the gathering of candidates.=20 The text says: "To avoid redoing the connectivity checks the endpoint MAY send keep-alive= MPRTP packets=20 (see Section 9.1.3) to the passivesubflows to keep the NAT bindings alive.= " ED_8_1_3-3: I think it would be good to have a dedicated subsction (8.1.x)= about NAT traversal. ED_8_1_3-4: "to the passive subflows" -> "on the subflows where bo media i= s sent". From christer.holmberg@ericsson.com Wed Aug 3 14:06:07 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6488D11E80A2 for ; Wed, 3 Aug 2011 14:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0vIFfhFS-7w for ; Wed, 3 Aug 2011 14:06:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A174E11E80A1 for ; Wed, 3 Aug 2011 14:06:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e7-4e39b84b20e2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CE.84.09774.B48B93E4; Wed, 3 Aug 2011 23:06:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 3 Aug 2011 23:06:19 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 23:06:17 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: Packet Formats (Section 9) Thread-Index: AcxSIS/Oe6aQtq2GTMSSyVQSriVtrQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B76@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: Packet Formats (Section 9) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 21:06:07 -0000 Hi, Below are my comments/questions on section 9. Regards, Christer Section 9.1: ED_9_1-1: I don't understand the text about the urn. What is it, and where= is it used? In addition,=20 if it is SDP specific, I think it belongs to section 11. Section 9.1.3 FU_9_1_3-1: Even if you do NOT do RTP/RTCP multiplexing, do you really nee= d a dedicated keep-alive=20 MPID ID? Can't you simply use RTP for keep-alive as defined in RFC 6263? Section 9.3. The text says: "This sub-section defines the RTCP header extension for in-band interface advertisement by the receiver, instead of relying on ICE or in situations when the interface appears after SDP session establishment." ED_9_3-1: Should the text say "instead of relying on SDP or ICE"? Because,= you don't need ICE in order=20 to use the new SDP interface attributes used in the document. ED_9_3-2: The text seems to suggest that you can't do mid-session modifica= tions (including=20 addition of interfaces) using SDP, which is not true. Section 9.3.1: FU_9_3_1: If I advertise an interface, what does it mean? Does it mean, si= milar to SDP, that I=20 am willing to receive media on this interface? OR, does it mean that I am = willing to send AND receive media=20 on this interface? From christer.holmberg@ericsson.com Wed Aug 3 14:06:23 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C675F11E8088 for ; Wed, 3 Aug 2011 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laazpTyNA7D5 for ; Wed, 3 Aug 2011 14:06:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E811E807C for ; Wed, 3 Aug 2011 14:06:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3f-4e39b85a471b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A6.E3.20773.A58B93E4; Wed, 3 Aug 2011 23:06:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Aug 2011 23:06:34 +0200 From: Christer Holmberg To: mmusic Date: Wed, 3 Aug 2011 23:06:33 +0200 Thread-Topic: SDP comments on draft-singh-avtcore-mprtp-02: SDP Considerations (Section 11) Thread-Index: AcxSITkME1iLeokTQpGcdVjlm8lsHw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B77@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 X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: SDP Considerations (Section 11) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 03 Aug 2011 21:06:23 -0000 Hi, Below are my comments/questions on section 11. Regards, Christer Section 11: ED_11-1: I don't understand what the text in the section has to do with SD= P. I think=20 the text should say that the section defines SDP extensions, procedures et= c. Copy/paste error? Section 11.1: The text says: "Not providing this information may/will make the sender or receiver ignor= e the header=20 extensions. However, MPRTP MAY be used by either sender or receiver withou= t prior signaling." ED_11_1-1: The text is a little confusing. I assume it means that you can = use the header extension without prior signaling, but that endpoints will ignore it. Now, if "signaling" also con= tains in-band signaling, I think this text belongs elsewhere in the document, as it is not SDP specific. FU_11_1-1: Why allow usage of MPRTP even if it hasn't been negotiated? FU_11_1-2: The fact that the usage of SDP is optional raises some issues. = For example, assume=20 I establish a session, and uses in-band signaling to negotiate interfaces.= The SDP does not =20 contain any interface information. Then, later during the session I send a= new SDP offer, again=20 without any interface information. Now, does that remove the interfaces th= at I previously=20 negotiated in-band? Which signaling has higher priority: in-band or out-of= -band?=20 I think it would be good if only ONE mechansim was used throughout the ses= sion, and I think you=20 later claim, that if the SDP only contains the a=3Dmprtp attribute, withou= t any interface information,=20 one should use in-band signaling. =09 FU_11_1-3: Depending on the outcome of FU_11_1-2, you need to define the o= ffer/answer aspects of the=20 attribute. For example, if an offer contains an attribute without interfac= e parameter(s), does the=20 answer have to do the same? What about mid-session modifications? ED_11_1-2: "The literal 'mprtp' MUST be used to indicate support for MPRTP= ." -> "The a=3Dmprtp MUST be used to indicate support of receiving media on the = associated media stream=20 using MPRTP." ED_11_1-3: In order to be consistance with section 11.3.1, please add the = following text in front=20 of the attribute syntax: "The syntax of the mprtp attribute is defined using the following Augmente= d BNF, as defined in [9]."=20 ED_11_1-4: I think the name of the section should be "a=3Dmprtp attribute"= . Section 11.2: ED_11_2-1: I don't understand the text. What is this URN, and where is it = used? Section 11.3: ED_11_3-1: I think it would be good to have a level 11.x section, named "M= PRTP with ICE", or something. ED_11_3-2: "out-band" -> "out-of-band" ED_11_3-3: What is a "preloaded interface"?=20 (Comment applies also to sections 5.1 and 5.2) ED_11_3-4: "initial INVITE" -> "initial SDP offer" The text says: "2. Advertising MPRTP interfaces: When a sufficient number of connectivity checks succeed the endpoint MUST send an updated offer containing their interfaces." FU_11_3-1: I don't understand the second step. FU_11_3-1a: Are you talking about ICE connectivity checks, based on the IC= E candidates? FU_11_3-1b: What does "their interfaces" mean? FU_11_3-1c: Do you mean that, when ICE is finished and an ICE candidate ha= s been selected, you send an updated SDP offer=20 which contains that ICE candicate (according to the ICE procedures), and I= N ADDITION to that you add one or more=20 interfaces associated with that ICE candidate? FU_11_3-1d: Do you mean that, when ICE has determined which ICE candidates= work (based on the ICE connectivity checks), and updated offer is sent where each ICE candidate is represented by an interf= ace, but no additional interfaces are added? FU_11_3-1e: If the interfaces are based on ICE candidates, I think the pri= ority of the interfaces should also somehow be associated with the priority of the ICE candidates. Section 11.3.1: ED_11_3_1-1: "interface" is not an attribute. It is an optional attribute = parameter. The text says: "It is used to describe one of the many network addresses of an endpoint." ED_11_3_1-2: Please use similar wording/terminology as for the in-band mec= hanism. Something like "It is used to advertise an interface address", or something like that. ED_11_3_1-3: "It reuses the RFC4566 [18] definitions of unicast-address, p= ort, token, SP, and CRLF." -> "The definitions of unicast-address, port, token, SP, and CRLF are accordi= ng to RFC4566 [18]." FU_11_3_1-1: . I don't think it is good to rely on the or= der of interface attributes, so I=20 think it would be better to say that the interface with the lowest counter= value must match the c/m-line=20 information. In the same way, the priority should be based on the counter = value, not the position of the attribute. FU_11_3_1-2: : How can the value represent an address for which the = connectivity checks have succeeded, if the=20 endpoints haven't even negotiated where to send the connectivity checks ye= t? FU_11_3_1-3: : Is there a reason not to have a MUST instead of SH= OULD?` FU_11_3_1-4: Is the value required to stay the same throughout t= he session? Section 11.5: ED_11_5-1: I would like to see an example where MPRTP is used with ICE. Section 11.5.1: The text says: "...SHOULD use in-band signaling for exchanging interfaces and for performing connectivity checks." ED_11_5_1-1: Please do not use "SHOULD" in an informative example. ED_11_5_1-2: Aren't the connectivity checks always performed in-band (even= when STUN is used)? ED_11_5_1-3: "out-band" -> "out-of-band" ED_11_5_1-4: Is there text in the normative part of the draft saying that = in-band signaling should be used=20 when the a=3Dmprtp attribute is used without interface information (see FU= _11_1-2)? Section 11.5.2: ED_11_5_2-1: "out-band" -> "out-of-band" ED_11_5_2-2: Please do not use "MAY" in an informative example. In this ca= se I think you could use "can" instead. From brian.adamson@nrl.navy.mil Thu Aug 4 08:31:13 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B8421F8880; Thu, 4 Aug 2011 08:31:13 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndfBYnbRf-+D; Thu, 4 Aug 2011 08:31:13 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF621F87FA; Thu, 4 Aug 2011 08:31:12 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id p74FVLY9013653; Thu, 4 Aug 2011 11:31:23 -0400 Received: from macsimus.itd.nrl.navy.mil ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2011080411312312281 ; Thu, 04 Aug 2011 11:31:23 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: brian.adamson@nrl.navy.mil In-Reply-To: <4D5BD754.9060507@tut.fi> Date: Thu, 4 Aug 2011 11:30:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D5BD754.9060507@tut.fi> To: rmt@ietf.org, mmusic@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 04 Aug 2011 09:05:26 -0700 Cc: Magnus Westerlund , Jani Peltotalo Subject: Re: [MMUSIC] [Rmt] FLUTE SDP specification X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Aug 2011 15:31:13 -0000 At the last working group meeting in Quebec, I raised the question = regarding the readiness of the FLUTE SDP draft for last call. However, = upon reviewing the RMT Mailing list archive, I found this note from Jani = & Rod which mentions a couple of dangling issues that would be addressed = in an -01 draft. I think the authors were looking for comments from the Working Group on = the -00 draft? At Magnus' suggestion, I have cc'd the MMUSIC mailing list to get their = involvement on this. For their benefit, the history here is that it has = taken some time (years) to finalize the revised FLUTE Proposed Standard = specification and this SDP document was in limbo until that work was = completed. The authors refreshed / renamed the document earlier in the = year and we have reached consensus on the FLUTE specification and it is = ready to move forward so this document (FLUTE SDP) can be finally = finalized as well. best regards, Brian Adamson brian.adamson@nrl.navy.mil On Feb 16, 2011, at 8:55 AM, Jani Peltotalo wrote: > Dear RMTers, >=20 > I just submitted a new version of the FLUTE SDP specification. > Currently, it is available here: >=20 > http://www.ietf.org/staging/draft-ietf-rmt-flute-sdp-00.txt >=20 > We changed the document title to "draft-ietf-rmt-flute-sdp" to reflect > the status as an official working group draft. We have still few open > issues, relating to CC & SEC, but those will be covered in the 01 > version which will then be ready (in our opinion) for WGLC. >=20 > Since there has not been much input from the working group we are > planning to cover CC & SEC mostly as informative annexes. CC will be > based on WEBRC and today we spotted RFCs 4567 and 4568 which might be > usable for SEC. >=20 > Cheers, Jani & Rod > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www.ietf.org/mailman/listinfo/rmt >=20 From dwing@cisco.com Thu Aug 4 14:01:36 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A584411E809B for ; Thu, 4 Aug 2011 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.485 X-Spam-Level: X-Spam-Status: No, score=-103.485 tagged_above=-999 required=5 tests=[AWL=-1.486, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHiYbQP90wqI for ; Thu, 4 Aug 2011 14:01:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0619A11E8082 for ; Thu, 4 Aug 2011 14:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1517; q=dns/txt; s=iport; t=1312491712; x=1313701312; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=RxU81iUu/jCWhQy/XC88GmRn5kQ0yV51K9GdbFC4tx0=; b=K6YrH5hTt8QijC1aaeIufRXqFk573WyRpW0sH0owi8TEo1hNq32Sdluz kjkajaAQX1yYmsIj8hX+GGkJVgDMz6RLvgANnYZP7UY0AmPx8MEfrvidd wvpMbltWHPOFFWtfPynK6G1w6PboNhqY/f4OVV+ZC4m5GlbkxEXfl9XJB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADoIO06rRDoG/2dsb2JhbABDmXqNcHeBRwgKARcQPw0FGFAjHAEEAR0Xqj0Bnl+GQgSHWpwl X-IronPort-AV: E=Sophos;i="4.67,319,1309737600"; d="scan'208";a="9791316" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 04 Aug 2011 21:01:50 +0000 Received: from dwingWS (sjc-vpn2-56.cisco.com [10.21.112.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p74L1noT012069; Thu, 4 Aug 2011 21:01:49 GMT From: "Dan Wing" To: , , "'Gonzalo Camarillo'" Date: Thu, 4 Aug 2011 14:01:49 -0700 Message-ID: <01a701cc52e9$bab196c0$3014c440$@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: AcxS6bpvHiUSY5UYQ4iOXyIBPKgpYQ== Content-Language: en-us Cc: 'IETF MMUSIC WG' Subject: [MMUSIC] comments on draft-ietf-mmusic-sctp-sdp-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 04 Aug 2011 21:01:36 -0000 A couple of comments when I was reviewing draft-ietf-mmusic-sctp-sdp-00: Background: SCTP allows sending multiple streams through a single connection (that is, over a single 5-tuple of source port, destination port, protocol=SCTP, source IP, destination IP). By using a single connection, there is one congestion control context for all of the streams within that connection. Question: I notice that draft-ietf-mmusic-sctp-sdp doesn't try to take advantage of that SCTP capability. I admit it would be pretty complex considering how SDP (and TCP and UDP) are all very much tied to the concept of using ports to demultiplex traffic. However, with the work going on in RTCWEB (which wants to multiplex audio and vidoe over the same 5 tuple), should we consider how SCTP can signal this functionality in SDP? Small issue related to NAT: SCTP specific features (not present in UDP/TCP), such as the checksum (CRC32c) value calculated on the whole packet (not just the header) or its multihoming capabilities, present new challenges for NAT traversal. [I-D.ietf-behave-sctpnat] describes an SCTP specific variant of NAT, which provides similar features of Network Address and Port Translation (NAPT). To work with draft-ietf-behave-sctpnat, the client and the server SCTP implementations also need to support and use the DISABLE_RESTART extension described in draft-ietf-tsvwg-natsupp. I suggest adding SHOULD implement draft-ietf-tsvwg-natsupp. -d From fandreas@cisco.com Sat Aug 6 08:10:17 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863EE21F86C1 for ; Sat, 6 Aug 2011 08:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq9AVKy4YhKZ for ; Sat, 6 Aug 2011 08:10:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6548E21F86D8 for ; Sat, 6 Aug 2011 08:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=10302; q=dns/txt; s=iport; t=1312643435; x=1313853035; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1w1cuzt7VQPDT8LR1/tx2/OdBxDmDmpkzNIIrxJBQQI=; b=YLj6kuRrcWFCuYWab2tiHBFUvCmOCCvTAhzDEqvRx07r2ebYLI50VDnL 5i3yu7QSxdl0TsTgaJUvd0UzS3u3gb5kwZuzO9acRErsAL+3RXi+O8fm5 4Ao2QCAFJ2GhpQXjA2bFAWuhJMkGDHd3UIf/glrgV8TvtV/dXt3PQ1emz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAOFYPU6tJXG8/2dsb2JhbABChEeTWI9Ld4FAAQEBAQIBAQEBDwEQCkEKAQwECQIRBAEBAQkWCAMCAgkDAgECARUfCQgGDQEFAgEBFQmHSwSfbAGNK5BkhTaBEASTApEE X-IronPort-AV: E=Sophos;i="4.67,328,1309737600"; d="scan'208,217";a="10439027" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 06 Aug 2011 15:10:33 +0000 Received: from rtp-fandreas-8712.cisco.com (rtp-fandreas-8712.cisco.com [10.117.7.83]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p76FAW2J025127; Sat, 6 Aug 2011 15:10:32 GMT Message-ID: <4E3D5968.3070001@cisco.com> Date: Sat, 06 Aug 2011 11:10:32 -0400 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: Kaynam Hedayat References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> In-Reply-To: <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> Content-Type: multipart/alternative; boundary="------------010507010201030802050802" Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 15:10:17 -0000 This is a multi-part message in MIME format. --------------010507010201030802050802 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kaynam I think this is a good path forward. If anybody in the WG feels otherwise, please let us know. Thanks -- Flemming (as MMUSIC co-chair) On 7/26/11 12:01 PM, Kaynam Hedayat wrote: > > Flemming, et. al, > > Given the amount of argument and the importance of ICE I suggest > removing the alternative mechanism from the draft (sections 5.7, 8, > 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new > section that requires use of ICE for calls behind NAT. I believe this > is the best path forward. > > Please let me know if the group agrees and we will change the draft > accordingly. > > Regards, > Kaynam > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Emil Ivov > Sent: Thursday, July 07, 2011 12:31 PM > To: Flemming Andreasen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE > alternative ? > > Hey Flemming, > > На 07.07.11 16:49, Flemming Andreasen написа: > > > > >> How are these "irregular" SDP and what reason would a middle box > have to > >> remove them? > >> > > My point is that they are just as regular or irregular as any other SDP, > > including ICE. The one difference I do see at this point is that by the > > middle box changing address information in the SDP, it will effectively > > turn off ICE based on the ice-mismatch procedure you pointed out. The > > loopback mechanism will not suffer from this problem, as long as the > > middle box passes through the SDP with whatever parameters it contains > > (i.e. the middle box does not insist on understanding the SDP itself; if > > it did, it would have to support the loopback mechanism including its > > defined SDP extensions and loopback primer payload). > > Wel does it really need to support the payload or any loopback-specific > mechanisms? I apologise if I am missing something but, as long as the > middle box is not planning on absolutely decoding media, it should be > OK. According to my experience, it is reasonable to expect that most SIP > proxies would handle this properly. > > I am of course only talking about the NAT traversal/latching aspects of > the draft. Obviously the echo-related params may be more exposed to > pruning. > > > > >> Well again, I don't see anything in this draft that would allow two > >> clients, both of which are behind a NAT, to talk to each other. The > >> relay in the middle does. In that respect I don't see how anyone can > >> pretend that the loopback primer is an "alternative to ICE". It is not. > >> It does not provide means for clients to discover a direct path to > each > >> other. It does not provide relaying. It only helps to resolve a > >> starvation in the echo use case and in a scenario where a regular > >> bi-directional voip call would have worked anyway because of the > >> latching that middle boxes are doing. > >> > > I agree with your point above, however it does also provide a limited > > alternative to ICE inasmuch as it defines an alternative NAT traversal > > mechanism that can be used in certain limited deployment scenarios > > (without relays), and the way the draft is written currently, that's the > > way this mechanim is positioned as well. Again, you are bringing up > > another real-life use case that has merit IMO. It would be good to know > > if there are others. > > Well, there's also the case of UDP-only SIP proxies. I have yet to see a > real-life audio/video INVITE that can fit into a single ethernet MTU > together with an ICE candidate lists. In such cases clients may again > wish to fall back to an ICEless leap of faith and hope for latching. > > Of course, UDP-only proxies being prohibited by 3261, this case may be > considered irrelevant. Still, I thought I' mention it anyway given that > many providers out there choose not to enable TCP regardless of what > 3261 says. > > Cheers, > Emil > > > -- > http://jitsi.org > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------010507010201030802050802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Kaynam

I think this is a good path forward.

If anybody in the WG feels otherwise, please let us know.

Thanks

-- Flemming (as MMUSIC co-chair)




On 7/26/11 12:01 PM, Kaynam Hedayat wrote:
RE: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

Flemming, et. al,

Given the amount of argument and the importance of ICE I suggest removing the alternative mechanism from the draft (sections 5.7, 8, 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new section that requires use of ICE for calls behind NAT. I believe this is the best path forward.

Please let me know if the group agrees and we will change the draft accordingly.

Regards,
Kaynam



-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Emil Ivov
Sent: Thursday, July 07, 2011 12:31 PM
To: Flemming Andreasen
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

Hey Flemming,

На 07.07.11 16:49, Flemming Andreasen написа:

<snip>

>> How are these "irregular" SDP and what reason would a middle box have to
>> remove them?
>>
> My point is that they are just as regular or irregular as any other SDP,
> including ICE. The one difference I do see at this point is that by the
> middle box changing address information in the SDP, it will effectively
> turn off ICE based on the ice-mismatch procedure you pointed out. The
> loopback mechanism will not suffer from this problem, as long as the
> middle box passes through the SDP with whatever parameters it contains
> (i.e. the middle box does not insist on understanding the SDP itself; if
> it did, it would have to support the loopback mechanism including its
> defined SDP extensions and loopback primer payload).

Wel does it really need to support the payload or any loopback-specific
mechanisms? I apologise if I am missing something but, as long as the
middle box is not planning on absolutely decoding media, it should be
OK. According to my experience, it is reasonable to expect that most SIP
proxies would handle this properly.

I am of course only talking about the NAT traversal/latching aspects of
the draft. Obviously the echo-related params may be more exposed to
pruning.

<snip>

>> Well again, I don't see anything in this draft that would allow two
>> clients, both of which are behind a NAT, to talk to each other. The
>> relay in the middle does. In that respect I don't see how anyone can
>> pretend that the loopback primer is an "alternative to ICE". It is not.
>>  It does not provide means for clients to discover a direct path to each
>> other. It does not provide relaying. It only helps to resolve a
>> starvation in the echo use case and in a scenario where a regular
>> bi-directional voip call would have worked anyway because of the
>> latching that middle boxes are doing.
>>
> I agree with your point above, however it does also provide a limited
> alternative to ICE inasmuch as it defines an alternative NAT traversal
> mechanism that can be used in certain limited deployment scenarios
> (without relays), and the way the draft is written currently, that's the
> way this mechanim is positioned as well. Again, you are bringing up
> another real-life use case that has merit IMO. It would be good to know
> if there are others.

Well, there's also the case of UDP-only SIP proxies. I have yet to see a
real-life audio/video INVITE that can fit into a single ethernet MTU
together with an ICE candidate lists. In such cases clients may again
wish to fall back to an ICEless leap of faith and hope for latching.

Of course, UDP-only proxies being prohibited by 3261, this case may be
considered irrelevant. Still, I thought I' mention it anyway given that
many providers out there choose not to enable TCP regardless of what
3261 says.

Cheers,
Emil


--
http://jitsi.org

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

--------------010507010201030802050802-- From gonzalo.camarillo@ericsson.com Mon Aug 8 01:12:19 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA9421F8A7E for ; Mon, 8 Aug 2011 01:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.292 X-Spam-Level: X-Spam-Status: No, score=-106.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCF8aMjR97md for ; Mon, 8 Aug 2011 01:12:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E94A321F8A7B for ; Mon, 8 Aug 2011 01:12:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d6-4e3f9a7a1fa7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 78.10.09774.A7A9F3E4; Mon, 8 Aug 2011 10:12:42 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 8 Aug 2011 10:12:42 +0200 Message-ID: <4E3F9A79.6000504@ericsson.com> Date: Mon, 8 Aug 2011 11:12:41 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dan Wing References: <01a701cc52e9$bab196c0$3014c440$@com> In-Reply-To: <01a701cc52e9$bab196c0$3014c440$@com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-mmusic-sctp-sdp@tools.ietf.org" , 'IETF MMUSIC WG' Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sctp-sdp-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 08 Aug 2011 08:12:19 -0000 Hi Dan, thanks for your comments. Answers inline: On 05/08/2011 12:01 AM, Dan Wing wrote: > A couple of comments when I was reviewing draft-ietf-mmusic-sctp-sdp-00: > > > Background: SCTP allows sending multiple streams through a single > connection (that is, over a single 5-tuple of source port, destination > port, protocol=SCTP, source IP, destination IP). By using a single > connection, there is one congestion control context for all of > the streams within that connection. correct, although in SCTP terminology that is called an association (instead of a connection). > Question: I notice that draft-ietf-mmusic-sctp-sdp doesn't try > to take advantage of that SCTP capability. I admit it would be > pretty complex considering how SDP (and TCP and UDP) are all very > much tied to the concept of using ports to demultiplex traffic. > However, with the work going on in RTCWEB (which wants to multiplex > audio and vidoe over the same 5 tuple), should we consider how > SCTP can signal this functionality in SDP? Yes, taking advantage of the multi-stream capability of SCTP for something else than HOLB avoidance would be useful indeed. I believe the way to use streams by a particular application or set of applications (e.g., RTCWeb) needs to be done separately. That is, in my view, this draft provides general guidelines to describe SCTP associations in SDP. If a particular application wants to do something more special, such as multiplexing different types of traffic in different streams, they would specify that separately. > Small issue related to NAT: > > SCTP specific features (not present in UDP/TCP), such as the checksum > (CRC32c) value calculated on the whole packet (not just the header) > or its multihoming capabilities, present new challenges for NAT > traversal. [I-D.ietf-behave-sctpnat] describes an SCTP specific > variant of NAT, which provides similar features of Network Address > and Port Translation (NAPT). > > To work with draft-ietf-behave-sctpnat, the client and the server SCTP > implementations also need to support and use the DISABLE_RESTART extension > described in draft-ietf-tsvwg-natsupp. I suggest adding SHOULD > implement draft-ietf-tsvwg-natsupp. Yes, I agree SCTP endpoints should try and support that. The question is whether this is the right document to specify that. This document only applies to SCTP associations that are established using SDP (i.e., offer/answer) while the recommendation to use natsupp would be a general recommendation, which would also be applicable to SCTP associations established in the traditional way (i.e., no SDP involved). So, to me, this sounds more like something to be documented as best current practice for SCTP. With respect to the feedback we got in Quebec, I agree that adding use cases to the draft would be useful. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Tue Aug 9 00:26:32 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E821F21F85B5 for ; Tue, 9 Aug 2011 00:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVIgwmviOGtc for ; Tue, 9 Aug 2011 00:26:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB5221F85B8 for ; Tue, 9 Aug 2011 00:26:31 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e3-4e40e142d84d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 78.E7.09774.241E04E4; Tue, 9 Aug 2011 09:26:58 +0200 (CEST) Received: from [131.160.36.41] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 9 Aug 2011 09:26:57 +0200 Message-ID: <4E40E141.3000905@ericsson.com> Date: Tue, 9 Aug 2011 10:26:57 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Flemming Andreasen References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> In-Reply-To: <4E3D5968.3070001@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Kaynam Hedayat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 09 Aug 2011 07:26:33 -0000 Hi, if you could summarize what is the plan, just to be clear, that would be great. With respect to the ICE fallback discussion, if we are defining something that is specific to the loopback mechanism, it might make sense to include it in the draft. However, if we are thinking of defining a general ICE fallback mechanism, its scope would be wider than the draft's. Cheers, Gonzalo On 06/08/2011 6:10 PM, Flemming Andreasen wrote: > Hi Kaynam > > I think this is a good path forward. > > If anybody in the WG feels otherwise, please let us know. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > > On 7/26/11 12:01 PM, Kaynam Hedayat wrote: >> >> Flemming, et. al, >> >> Given the amount of argument and the importance of ICE I suggest >> removing the alternative mechanism from the draft (sections 5.7, 8, >> 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new >> section that requires use of ICE for calls behind NAT. I believe this >> is the best path forward. >> >> Please let me know if the group agrees and we will change the draft >> accordingly. >> >> Regards, >> Kaynam >> >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Emil Ivov >> Sent: Thursday, July 07, 2011 12:31 PM >> To: Flemming Andreasen >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE >> alternative ? >> >> Hey Flemming, >> >> На 07.07.11 16:49, Flemming Andreasen написа: >> >> >> >> >> How are these "irregular" SDP and what reason would a middle box >> have to >> >> remove them? >> >> >> > My point is that they are just as regular or irregular as any other SDP, >> > including ICE. The one difference I do see at this point is that by the >> > middle box changing address information in the SDP, it will effectively >> > turn off ICE based on the ice-mismatch procedure you pointed out. The >> > loopback mechanism will not suffer from this problem, as long as the >> > middle box passes through the SDP with whatever parameters it contains >> > (i.e. the middle box does not insist on understanding the SDP itself; if >> > it did, it would have to support the loopback mechanism including its >> > defined SDP extensions and loopback primer payload). >> >> Wel does it really need to support the payload or any loopback-specific >> mechanisms? I apologise if I am missing something but, as long as the >> middle box is not planning on absolutely decoding media, it should be >> OK. According to my experience, it is reasonable to expect that most SIP >> proxies would handle this properly. >> >> I am of course only talking about the NAT traversal/latching aspects of >> the draft. Obviously the echo-related params may be more exposed to >> pruning. >> >> >> >> >> Well again, I don't see anything in this draft that would allow two >> >> clients, both of which are behind a NAT, to talk to each other. The >> >> relay in the middle does. In that respect I don't see how anyone can >> >> pretend that the loopback primer is an "alternative to ICE". It is not. >> >> It does not provide means for clients to discover a direct path to >> each >> >> other. It does not provide relaying. It only helps to resolve a >> >> starvation in the echo use case and in a scenario where a regular >> >> bi-directional voip call would have worked anyway because of the >> >> latching that middle boxes are doing. >> >> >> > I agree with your point above, however it does also provide a limited >> > alternative to ICE inasmuch as it defines an alternative NAT traversal >> > mechanism that can be used in certain limited deployment scenarios >> > (without relays), and the way the draft is written currently, that's the >> > way this mechanim is positioned as well. Again, you are bringing up >> > another real-life use case that has merit IMO. It would be good to know >> > if there are others. >> >> Well, there's also the case of UDP-only SIP proxies. I have yet to see a >> real-life audio/video INVITE that can fit into a single ethernet MTU >> together with an ICE candidate lists. In such cases clients may again >> wish to fall back to an ICEless leap of faith and hope for latching. >> >> Of course, UDP-only proxies being prohibited by 3261, this case may be >> considered irrelevant. Still, I thought I' mention it anyway given that >> many providers out there choose not to enable TCP regardless of what >> 3261 says. >> >> Cheers, >> Emil >> >> >> -- >> http://jitsi.org >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> From paulbeaumont.ietf@gmail.com Tue Aug 9 19:24:22 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDB021F8AA9 for ; Tue, 9 Aug 2011 19:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60zcqOvBZ4vd for ; Tue, 9 Aug 2011 19:24:22 -0700 (PDT) Received: from mail-ww0-f52.google.com (mail-ww0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id C1AAA21F8AA8 for ; Tue, 9 Aug 2011 19:24:21 -0700 (PDT) Received: by wwe6 with SMTP id 6so520224wwe.33 for ; Tue, 09 Aug 2011 19:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:in-reply-to:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=OpNtZeZ0SOmkvY0sj47aEW6TJWKUnJbDpxFP0Coo0hI=; b=Ru8m/49erB5W5lGN0Ggf6WT5paddCBgEMnPTKB2w7/3n3/NVImd+Mt+5q6jnUk/oFr a4A9oa4hL+3VE3kT/rIUhqvoh0Orf/oqnsWiNwOJQ/ZDmKx8Ky4OIaJ1uETmT+hH+4FB JsGqLzvJkTZJK3UTRbPk9qFr6CCHz394Nf/aQ= Received: by 10.216.24.31 with SMTP id w31mr712886wew.67.1312943091004; Tue, 09 Aug 2011 19:24:51 -0700 (PDT) Received: from [192.168.0.6] (5ac68db1.bb.sky.com [90.198.141.177]) by mx.google.com with ESMTPS id j54sm299068wed.23.2011.08.09.19.24.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 19:24:49 -0700 (PDT) References: <201107132136.p6DLamPn002152@mtv-core-3.cisco.com> <058f01cc4df5$f4e38720$deaa9560$@packetizer.com> <062701cc4e7b$b985f650$2c91e2f0$@packetizer.com> From: Paul Beaumont Content-Type: text/plain; charset=us-ascii In-Reply-To: <062701cc4e7b$b985f650$2c91e2f0$@packetizer.com> Message-Id: Date: Mon, 1 Aug 2011 22:59:29 +0100 To: IETF - MMUSIC Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8J2) X-Mailer: iPad Mail (8J2) Subject: [MMUSIC] draft-greevenbosch-mmusic-signal-3d-format-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 02:24:22 -0000 At IETF 81 meeting mmusic WG the line was cut before I could comment, but as= part of the parameters possible to signal, should there also be an indicati= on as to the content horizontal resolutions. Eg 2k or 4k. Movies are now bei= ng produced in the latter, eg District 9 was one of the first. Paul From yuepeiyu@huawei.com Tue Aug 9 19:39:16 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A839021F8B34 for ; Tue, 9 Aug 2011 19:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q01jOf-S7oIJ for ; Tue, 9 Aug 2011 19:39:16 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0E78321F8B31 for ; Tue, 9 Aug 2011 19:39:16 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00J5FY1LTK@szxga03-in.huawei.com> for mmusic@ietf.org; Wed, 10 Aug 2011 10:39:21 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPO00DIIY1LCP@szxga03-in.huawei.com> for mmusic@ietf.org; Wed, 10 Aug 2011 10:39:21 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC10106; Wed, 10 Aug 2011 10:39:21 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 10 Aug 2011 10:39:17 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.174]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 10 Aug 2011 10:39:20 +0800 Date: Wed, 10 Aug 2011 02:39:20 +0000 From: "Roy Yue(PeiYu)" In-reply-to: X-Originating-IP: [10.138.73.89] To: Paul Beaumont Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [MMUSIC] draft-greevenbosch-mmusic-signal-3d-format-01 Thread-index: AQHMVwS6vVmlViN1pU+0TOiyKXisEpUVXO6Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201107132136.p6DLamPn002152@mtv-core-3.cisco.com> <058f01cc4df5$f4e38720$deaa9560$@packetizer.com> <062701cc4e7b$b985f650$2c91e2f0$@packetizer.com> Cc: IETF - MMUSIC Subject: Re: [MMUSIC] draft-greevenbosch-mmusic-signal-3d-format-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 02:39:16 -0000 SGkgUGF1bCwNCg0KVGhlIGluZGljYXRpb24gb2YgaG9yaXpvbnRhbCByZXNvbHV0aW9ucyBpcyBk ZWZpbml0ZWx5IHVzZWZ1bCwgaG93ZXZlciBJIHRoaW5rLCB0aGlzIGlzIG9ydGhvcmhvbWJpYyB3 aXRoIHRoZSBzaWduYWwgb2YgM0QgZm9ybWF0Lg0KSW5zdGVhZCwgd2UgbWF5IGhhdmUgYSBuZXcg YXR0cmlidXRlIGluIFNEUCB0byBpbmRpY2F0ZSBob3Jpem9udGFsIHJlc29sdXRpb24gZm9yIGEg Z2VuZXJhbCBwdXJwb3NlLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgaW4gY3VycmVudCBUViBzeXN0 ZW0sIGFubm90YXRpb24gb2YgY29udGVudCBob3Jpem9udGFsIHJlc29sdXRpb25zIGlzIHVzdWFs bHkgZG9uZSBpbiB0d28gcGxhY2UsIG9uZSBpcyBpbiBFUEcgZm9yIHRoZSB1c2VyIHJlYWRpbmcg YW5kIHRoZSBvdGhlciBpcyBpbiB0aGUgc3RyZWFtaW5nL2ZpbGUgaXRzZWxmIGZvciB0aGUgZGVj b2RlciBpbml0aWFsaXphdGlvbi4NClByb2JhYmx5IHRoYXQgaXMgZW5vdWdoLg0KDQpCZXN0IHJl Z2FyZHMsDQpQZWl5dSBZVUUNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG1tdXNpYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUGF1 bCBCZWF1bW9udA0Kt6LLzcqxvOQ6IDIwMTHE6jjUwjLI1SA1OjU5DQrK1bz+yMs6IElFVEYgLSBN TVVTSUMNCtb3zOI6IFtNTVVTSUNdIGRyYWZ0LWdyZWV2ZW5ib3NjaC1tbXVzaWMtc2lnbmFsLTNk LWZvcm1hdC0wMQ0KDQpBdCBJRVRGIDgxIG1lZXRpbmcgbW11c2ljIFdHIHRoZSBsaW5lIHdhcyBj dXQgYmVmb3JlIEkgY291bGQgY29tbWVudCwgYnV0IGFzIHBhcnQgb2YgdGhlIHBhcmFtZXRlcnMg cG9zc2libGUgdG8gc2lnbmFsLCBzaG91bGQgdGhlcmUgYWxzbyBiZSBhbiBpbmRpY2F0aW9uIGFz IHRvIHRoZSBjb250ZW50IGhvcml6b250YWwgcmVzb2x1dGlvbnMuIEVnIDJrIG9yIDRrLiBNb3Zp ZXMgYXJlIG5vdyBiZWluZyBwcm9kdWNlZCBpbiB0aGUgbGF0dGVyLCBlZyBEaXN0cmljdCA5IHdh cyBvbmUgb2YgdGhlIGZpcnN0Lg0KDQpQYXVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= From miguel.a.garcia@ericsson.com Wed Aug 10 02:13:29 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B1D21F86AF for ; Wed, 10 Aug 2011 02:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AW7k29tOmiWF for ; Wed, 10 Aug 2011 02:13:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 81ADD21F8639 for ; Wed, 10 Aug 2011 02:13:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-2e-4e424bd5551a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 09.48.09774.5DB424E4; Wed, 10 Aug 2011 11:13:57 +0200 (CEST) Received: from [159.107.105.21] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 10 Aug 2011 11:13:57 +0200 Message-ID: <4E424BD3.5060709@ericsson.com> Date: Wed, 10 Aug 2011 11:13:55 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] IETF 81 minutes posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 09:13:29 -0000 The minutes of the IETF 81 MMUSIC meeting are now available at: http://www.ietf.org/proceedings/81/minutes/mmusic.txt Please read them, and if you have comments, questions, or changes to be made, let the chairs know it. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Wed Aug 10 11:02:11 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFFE21F84C5 for ; Wed, 10 Aug 2011 11:02:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-5-K999y+08 for ; Wed, 10 Aug 2011 11:02:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 944C121F8538 for ; Wed, 10 Aug 2011 11:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=14233; q=dns/txt; s=iport; t=1312999362; x=1314208962; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=/SuET0mOqsl4hEtHLgUiW6gQ/sQNhbXZHfrUm7jbX1s=; b=ARg+GSxdCxAbSsNn9g/Ai4V4m1WxeMd/WPetXU4plBObkcGOcQ6ys9x7 4eE5kgUIT740QI/copeaZpMfVJEedR23nDjY36sovP13NdpWCSeRUvInq zULhepbcQbWCUXRJjISuLM/HfBp5Vyfy5TvdHIHQkYHYUTv42Q+Om45iX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAGvHQk6Q/khR/2dsb2JhbABChEiTKI9Gd4FAAQEBAQMBAQEPARAKQQoBDAQJAhEEAQEBCRYIAwICCQMCAQIBFR8JCAYNAQUCAQEVCYdQoBQBjS+RKYU2gRAEkwmRCQ X-IronPort-AV: E=Sophos;i="4.67,351,1309737600"; d="scan'208,217";a="109282662" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 10 Aug 2011 18:02:40 +0000 Received: from fandreas-mac.local (dhcp-10-55-83-129.cisco.com [10.55.83.129]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7AI2dn6011392; Wed, 10 Aug 2011 18:02:39 GMT Message-ID: <4E42C7BE.3050405@cisco.com> Date: Wed, 10 Aug 2011 14:02:38 -0400 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: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> <4E40E141.3000905@ericsson.com> In-Reply-To: <4E40E141.3000905@ericsson.com> Content-Type: multipart/alternative; boundary="------------000805000800010909060204" Cc: Kaynam Hedayat , mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 18:02:11 -0000 This is a multi-part message in MIME format. --------------000805000800010909060204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit To summarize, the current latching mechanism and the associated payload type definitions for it will be removed, and ICE will be the only NAT traversal mechanism specified for loopback in this draft. The loopback payload types that are needed in general (i.e. without latching) will remain in the draft and the PAYLOAD WG will review them as part of this draft. If the authors and/or the WG believe that we should continue working on the latching (or other) NAT traversal mechanisms different from ICE, then that is something that will be discussed and/or developed outside of the media loopback work. Thanks -- Flemming PS: I have few other nits that I will forward to the draft authors separately. On 8/9/11 3:26 AM, Gonzalo Camarillo wrote: > > Hi, > > if you could summarize what is the plan, just to be clear, that would be > great. With respect to the ICE fallback discussion, if we are defining > something that is specific to the loopback mechanism, it might make > sense to include it in the draft. However, if we are thinking of > defining a general ICE fallback mechanism, its scope would be wider than > the draft's. > > Cheers, > > Gonzalo > > > On 06/08/2011 6:10 PM, Flemming Andreasen wrote: > > Hi Kaynam > > > > I think this is a good path forward. > > > > If anybody in the WG feels otherwise, please let us know. > > > > Thanks > > > > -- Flemming (as MMUSIC co-chair) > > > > > > > > > > On 7/26/11 12:01 PM, Kaynam Hedayat wrote: > >> > >> Flemming, et. al, > >> > >> Given the amount of argument and the importance of ICE I suggest > >> removing the alternative mechanism from the draft (sections 5.7, 8, > >> 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new > >> section that requires use of ICE for calls behind NAT. I believe this > >> is the best path forward. > >> > >> Please let me know if the group agrees and we will change the draft > >> accordingly. > >> > >> Regards, > >> Kaynam > >> > >> > >> > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Emil Ivov > >> Sent: Thursday, July 07, 2011 12:31 PM > >> To: Flemming Andreasen > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE > >> alternative ? > >> > >> Hey Flemming, > >> > >> На 07.07.11 16:49, Flemming Andreasen написа: > >> > >> > >> > >> >> How are these "irregular" SDP and what reason would a middle box > >> have to > >> >> remove them? > >> >> > >> > My point is that they are just as regular or irregular as any > other SDP, > >> > including ICE. The one difference I do see at this point is that > by the > >> > middle box changing address information in the SDP, it will > effectively > >> > turn off ICE based on the ice-mismatch procedure you pointed out. The > >> > loopback mechanism will not suffer from this problem, as long as the > >> > middle box passes through the SDP with whatever parameters it > contains > >> > (i.e. the middle box does not insist on understanding the SDP > itself; if > >> > it did, it would have to support the loopback mechanism including its > >> > defined SDP extensions and loopback primer payload). > >> > >> Wel does it really need to support the payload or any loopback-specific > >> mechanisms? I apologise if I am missing something but, as long as the > >> middle box is not planning on absolutely decoding media, it should be > >> OK. According to my experience, it is reasonable to expect that > most SIP > >> proxies would handle this properly. > >> > >> I am of course only talking about the NAT traversal/latching aspects of > >> the draft. Obviously the echo-related params may be more exposed to > >> pruning. > >> > >> > >> > >> >> Well again, I don't see anything in this draft that would allow two > >> >> clients, both of which are behind a NAT, to talk to each other. The > >> >> relay in the middle does. In that respect I don't see how anyone can > >> >> pretend that the loopback primer is an "alternative to ICE". It > is not. > >> >> It does not provide means for clients to discover a direct path to > >> each > >> >> other. It does not provide relaying. It only helps to resolve a > >> >> starvation in the echo use case and in a scenario where a regular > >> >> bi-directional voip call would have worked anyway because of the > >> >> latching that middle boxes are doing. > >> >> > >> > I agree with your point above, however it does also provide a limited > >> > alternative to ICE inasmuch as it defines an alternative NAT > traversal > >> > mechanism that can be used in certain limited deployment scenarios > >> > (without relays), and the way the draft is written currently, > that's the > >> > way this mechanim is positioned as well. Again, you are bringing up > >> > another real-life use case that has merit IMO. It would be good > to know > >> > if there are others. > >> > >> Well, there's also the case of UDP-only SIP proxies. I have yet to > see a > >> real-life audio/video INVITE that can fit into a single ethernet MTU > >> together with an ICE candidate lists. In such cases clients may again > >> wish to fall back to an ICEless leap of faith and hope for latching. > >> > >> Of course, UDP-only proxies being prohibited by 3261, this case may be > >> considered irrelevant. Still, I thought I' mention it anyway given that > >> many providers out there choose not to enable TCP regardless of what > >> 3261 says. > >> > >> Cheers, > >> Emil > >> > >> > >> -- > >> http://jitsi.org > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > --------------000805000800010909060204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit To summarize, the current latching mechanism and the associated payload type definitions for it will be removed, and ICE will be the only NAT traversal mechanism specified for loopback in this draft. The loopback payload types that are needed in general (i.e. without latching) will remain in the draft and the PAYLOAD WG will review them as part of this draft.

If the authors and/or the WG believe that we should continue working on the latching (or other) NAT traversal mechanisms different from ICE, then that is something that will be discussed and/or developed outside of the media loopback work.

Thanks

-- Flemming

PS: I have few other nits that I will forward to the draft authors separately.

On 8/9/11 3:26 AM, Gonzalo Camarillo wrote:
Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ?

Hi,

if you could summarize what is the plan, just to be clear, that would be
great. With respect to the ICE fallback discussion, if we are defining
something that is specific to the loopback mechanism, it might make
sense to include it in the draft. However, if we are thinking of
defining a general ICE fallback mechanism, its scope would be wider than
the draft's.

Cheers,

Gonzalo


On 06/08/2011 6:10 PM, Flemming Andreasen wrote:
> Hi Kaynam
>
> I think this is a good path forward.
>
> If anybody in the WG feels otherwise, please let us know.
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
>
>
>
> On 7/26/11 12:01 PM, Kaynam Hedayat wrote:
>>
>> Flemming, et. al,
>>
>> Given the amount of argument and the importance of ICE I suggest
>> removing the alternative mechanism from the draft (sections 5.7, 8,
>> 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new
>> section that requires use of ICE for calls behind NAT. I believe this
>> is the best path forward.
>>
>> Please let me know if the group agrees and we will change the draft
>> accordingly.
>>
>> Regards,
>> Kaynam
>>
>>
>>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Emil Ivov
>> Sent: Thursday, July 07, 2011 12:31 PM
>> To: Flemming Andreasen
>> Cc: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE
>> alternative ?
>>
>> Hey Flemming,
>>
>> На 07.07.11 16:49, Flemming Andreasen написа:
>>
>> <snip>
>>
>> >> How are these "irregular" SDP and what reason would a middle box
>> have to
>> >> remove them?
>> >>
>> > My point is that they are just as regular or irregular as any other SDP,
>> > including ICE. The one difference I do see at this point is that by the
>> > middle box changing address information in the SDP, it will effectively
>> > turn off ICE based on the ice-mismatch procedure you pointed out. The
>> > loopback mechanism will not suffer from this problem, as long as the
>> > middle box passes through the SDP with whatever parameters it contains
>> > (i.e. the middle box does not insist on understanding the SDP itself; if
>> > it did, it would have to support the loopback mechanism including its
>> > defined SDP extensions and loopback primer payload).
>>
>> Wel does it really need to support the payload or any loopback-specific
>> mechanisms? I apologise if I am missing something but, as long as the
>> middle box is not planning on absolutely decoding media, it should be
>> OK. According to my experience, it is reasonable to expect that most SIP
>> proxies would handle this properly.
>>
>> I am of course only talking about the NAT traversal/latching aspects of
>> the draft. Obviously the echo-related params may be more exposed to
>> pruning.
>>
>> <snip>
>>
>> >> Well again, I don't see anything in this draft that would allow two
>> >> clients, both of which are behind a NAT, to talk to each other. The
>> >> relay in the middle does. In that respect I don't see how anyone can
>> >> pretend that the loopback primer is an "alternative to ICE". It is not.
>> >>  It does not provide means for clients to discover a direct path to
>> each
>> >> other. It does not provide relaying. It only helps to resolve a
>> >> starvation in the echo use case and in a scenario where a regular
>> >> bi-directional voip call would have worked anyway because of the
>> >> latching that middle boxes are doing.
>> >>
>> > I agree with your point above, however it does also provide a limited
>> > alternative to ICE inasmuch as it defines an alternative NAT traversal
>> > mechanism that can be used in certain limited deployment scenarios
>> > (without relays), and the way the draft is written currently, that's the
>> > way this mechanim is positioned as well. Again, you are bringing up
>> > another real-life use case that has merit IMO. It would be good to know
>> > if there are others.
>>
>> Well, there's also the case of UDP-only SIP proxies. I have yet to see a
>> real-life audio/video INVITE that can fit into a single ethernet MTU
>> together with an ICE candidate lists. In such cases clients may again
>> wish to fall back to an ICEless leap of faith and hope for latching.
>>
>> Of course, UDP-only proxies being prohibited by 3261, this case may be
>> considered irrelevant. Still, I thought I' mention it anyway given that
>> many providers out there choose not to enable TCP regardless of what
>> 3261 says.
>>
>> Cheers,
>> Emil
>>
>>
>> --
>> http://jitsi.org
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>

--------------000805000800010909060204-- From gonzalo.camarillo@ericsson.com Wed Aug 10 11:35:08 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C6D21F8A35 for ; Wed, 10 Aug 2011 11:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYAZ5ao0g+Wx for ; Wed, 10 Aug 2011 11:35:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B237221F8A36 for ; Wed, 10 Aug 2011 11:35:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-32-4e42cf795bd9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.17.20773.97FC24E4; Wed, 10 Aug 2011 20:35:37 +0200 (CEST) Received: from [131.160.126.254] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 10 Aug 2011 20:35:36 +0200 Message-ID: <4E42CF78.7080405@ericsson.com> Date: Wed, 10 Aug 2011 21:35:36 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Flemming Andreasen References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> <4E40E141.3000905@ericsson.com> <4E42C7BE.3050405@cisco.com> In-Reply-To: <4E42C7BE.3050405@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Kaynam Hedayat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 10 Aug 2011 18:35:08 -0000 Hi Flemming, thanks for the summary. Yes, this sounds like a good way forward. Cheers, Gonzalo On 10/08/2011 9:02 PM, Flemming Andreasen wrote: > To summarize, the current latching mechanism and the associated payload > type definitions for it will be removed, and ICE will be the only NAT > traversal mechanism specified for loopback in this draft. The loopback > payload types that are needed in general (i.e. without latching) will > remain in the draft and the PAYLOAD WG will review them as part of this > draft. > > If the authors and/or the WG believe that we should continue working on > the latching (or other) NAT traversal mechanisms different from ICE, > then that is something that will be discussed and/or developed outside > of the media loopback work. > > Thanks > > -- Flemming > > PS: I have few other nits that I will forward to the draft authors > separately. > > On 8/9/11 3:26 AM, Gonzalo Camarillo wrote: >> >> Hi, >> >> if you could summarize what is the plan, just to be clear, that would be >> great. With respect to the ICE fallback discussion, if we are defining >> something that is specific to the loopback mechanism, it might make >> sense to include it in the draft. However, if we are thinking of >> defining a general ICE fallback mechanism, its scope would be wider than >> the draft's. >> >> Cheers, >> >> Gonzalo >> >> >> On 06/08/2011 6:10 PM, Flemming Andreasen wrote: >> > Hi Kaynam >> > >> > I think this is a good path forward. >> > >> > If anybody in the WG feels otherwise, please let us know. >> > >> > Thanks >> > >> > -- Flemming (as MMUSIC co-chair) >> > >> > >> > >> > >> > On 7/26/11 12:01 PM, Kaynam Hedayat wrote: >> >> >> >> Flemming, et. al, >> >> >> >> Given the amount of argument and the importance of ICE I suggest >> >> removing the alternative mechanism from the draft (sections 5.7, 8, >> >> 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will add a new >> >> section that requires use of ICE for calls behind NAT. I believe this >> >> is the best path forward. >> >> >> >> Please let me know if the group agrees and we will change the draft >> >> accordingly. >> >> >> >> Regards, >> >> Kaynam >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> >> Behalf Of Emil Ivov >> >> Sent: Thursday, July 07, 2011 12:31 PM >> >> To: Flemming Andreasen >> >> Cc: mmusic@ietf.org >> >> Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE >> >> alternative ? >> >> >> >> Hey Flemming, >> >> >> >> На 07.07.11 16:49, Flemming Andreasen написа: >> >> >> >> >> >> >> >> >> How are these "irregular" SDP and what reason would a middle box >> >> have to >> >> >> remove them? >> >> >> >> >> > My point is that they are just as regular or irregular as any >> other SDP, >> >> > including ICE. The one difference I do see at this point is that >> by the >> >> > middle box changing address information in the SDP, it will >> effectively >> >> > turn off ICE based on the ice-mismatch procedure you pointed out. The >> >> > loopback mechanism will not suffer from this problem, as long as the >> >> > middle box passes through the SDP with whatever parameters it >> contains >> >> > (i.e. the middle box does not insist on understanding the SDP >> itself; if >> >> > it did, it would have to support the loopback mechanism including its >> >> > defined SDP extensions and loopback primer payload). >> >> >> >> Wel does it really need to support the payload or any loopback-specific >> >> mechanisms? I apologise if I am missing something but, as long as the >> >> middle box is not planning on absolutely decoding media, it should be >> >> OK. According to my experience, it is reasonable to expect that >> most SIP >> >> proxies would handle this properly. >> >> >> >> I am of course only talking about the NAT traversal/latching aspects of >> >> the draft. Obviously the echo-related params may be more exposed to >> >> pruning. >> >> >> >> >> >> >> >> >> Well again, I don't see anything in this draft that would allow two >> >> >> clients, both of which are behind a NAT, to talk to each other. The >> >> >> relay in the middle does. In that respect I don't see how anyone can >> >> >> pretend that the loopback primer is an "alternative to ICE". It >> is not. >> >> >> It does not provide means for clients to discover a direct path to >> >> each >> >> >> other. It does not provide relaying. It only helps to resolve a >> >> >> starvation in the echo use case and in a scenario where a regular >> >> >> bi-directional voip call would have worked anyway because of the >> >> >> latching that middle boxes are doing. >> >> >> >> >> > I agree with your point above, however it does also provide a limited >> >> > alternative to ICE inasmuch as it defines an alternative NAT >> traversal >> >> > mechanism that can be used in certain limited deployment scenarios >> >> > (without relays), and the way the draft is written currently, >> that's the >> >> > way this mechanim is positioned as well. Again, you are bringing up >> >> > another real-life use case that has merit IMO. It would be good >> to know >> >> > if there are others. >> >> >> >> Well, there's also the case of UDP-only SIP proxies. I have yet to >> see a >> >> real-life audio/video INVITE that can fit into a single ethernet MTU >> >> together with an ICE candidate lists. In such cases clients may again >> >> wish to fall back to an ICEless leap of faith and hope for latching. >> >> >> >> Of course, UDP-only proxies being prohibited by 3261, this case may be >> >> considered irrelevant. Still, I thought I' mention it anyway given that >> >> many providers out there choose not to enable TCP regardless of what >> >> 3261 says. >> >> >> >> Cheers, >> >> Emil >> >> >> >> >> >> -- >> >> http://jitsi.org >> >> >> >> _______________________________________________ >> >> mmusic mailing list >> >> mmusic@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> From yuepeiyu@huawei.com Wed Aug 10 18:03:57 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABD111E80B2 for ; Wed, 10 Aug 2011 18:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yemzaNGoHbVy for ; Wed, 10 Aug 2011 18:03:57 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C831E11E80A2 for ; Wed, 10 Aug 2011 18:03:56 -0700 (PDT) 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 <0LPQ008NYOBG4Z@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 11 Aug 2011 09:04:28 +0800 (CST) Received: from szxrg02-dlp.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 <0LPQ00F4AOBFDM@szxga04-in.huawei.com> for mmusic@ietf.org; Thu, 11 Aug 2011 09:04:28 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADB93223; Thu, 11 Aug 2011 09:04:27 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 09:04:21 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.174]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 09:04:26 +0800 Date: Thu, 11 Aug 2011 01:04:25 +0000 From: "Roy Yue(PeiYu)" In-reply-to: <4E424BD3.5060709@ericsson.com> X-Originating-IP: [10.138.73.89] To: "Miguel A. Garcia" , mmusic Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [MMUSIC] IETF 81 minutes posted Thread-index: AQHMVz3vny6M1kY8MUuVnRb6010ZI5UW01/Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E424BD3.5060709@ericsson.com> Cc: Flemming Andreasen Subject: Re: [MMUSIC] IETF 81 minutes posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 11 Aug 2011 01:03:57 -0000 SGkgTWlndWVsLA0KDQpbUXVvdGVdDQotIFBlaXl1IFl1ZSBub3RlZCB0aGF0IHRoZSBCcm9hZGJh bmQgRm9ydW0gaXMgYWxzbyBkb2luZyBWUE4gYmFzZWQgb24gDQpTSVAsIGFsYmVpdCB1c2luZyBh IGRpZmZlcmVudCBtZWNoYW5pc20uDQpbL1F1b3RlXQ0KDQpJdCBpcyAiT3BlbiBJUFRWIEZvcnVt IiBidXQgbm90ICIgQnJvYWRiYW5kIEZvcnVtIiwgdGhhdCBJIHNhaWQgZHVyaW5nIHRoZSBtZWV0 aW5nLg0KDQpSZWdhcmRzLCANClJveSBZVUUoUGVpeXUpDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0K t6K8/sjLOiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIE1pZ3VlbCBBLiBHYXJjaWENCreiy83KsbzkOiAyMDExxOo41MIxMMjVIDE3 OjE0DQrK1bz+yMs6IG1tdXNpYw0Ks63LzTogRmxlbW1pbmcgQW5kcmVhc2VuDQrW98ziOiBbTU1V U0lDXSBJRVRGIDgxIG1pbnV0ZXMgcG9zdGVkDQoNClRoZSBtaW51dGVzIG9mIHRoZSBJRVRGIDgx IE1NVVNJQyBtZWV0aW5nIGFyZSBub3cgYXZhaWxhYmxlIGF0Og0KDQpodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzgxL21pbnV0ZXMvbW11c2ljLnR4dA0KDQpQbGVhc2UgcmVhZCB0aGVt LCBhbmQgaWYgeW91IGhhdmUgY29tbWVudHMsIHF1ZXN0aW9ucywgb3IgY2hhbmdlcyB0byBiZSAN Cm1hZGUsIGxldCB0aGUgY2hhaXJzIGtub3cgaXQuDQoNCi9NaWd1ZWwNCi0tIA0KTWlndWVsIEEu IEdhcmNpYQ0KKzM0LTkxLTMzOS0zNjA4DQpFcmljc3NvbiBTcGFpbg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1t dXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg== From miguel.a.garcia@ericsson.com Thu Aug 11 01:25:05 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2906021F8A7B for ; Thu, 11 Aug 2011 01:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.193 X-Spam-Level: X-Spam-Status: No, score=-5.193 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZatNN6pgcKXV for ; Thu, 11 Aug 2011 01:25:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7291421F8AF3 for ; Thu, 11 Aug 2011 01:25:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-49-4e4391fead86 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.5E.09774.EF1934E4; Thu, 11 Aug 2011 10:25:34 +0200 (CEST) Received: from [159.107.105.21] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 11 Aug 2011 10:25:34 +0200 Message-ID: <4E4391FC.80903@ericsson.com> Date: Thu, 11 Aug 2011 10:25:32 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Roy Yue(PeiYu)" References: <4E424BD3.5060709@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] IETF 81 minutes posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 11 Aug 2011 08:25:05 -0000 Thanks. I have fixed the minutes and re-uploaded them. /Miguel On 11/08/2011 3:04, Roy Yue(PeiYu) wrote: > Hi Miguel, > > [Quote] > - Peiyu Yue noted that the Broadband Forum is also doing VPN based on > SIP, albeit using a different mechanism. > [/Quote] > > It is "Open IPTV Forum" but not " Broadband Forum", that I said during the meeting. > > Regards, > Roy YUE(Peiyu) > > -----ʼԭ----- > : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Miguel A. Garcia > ʱ: 2011810 17:14 > ռ: mmusic > : Flemming Andreasen > : [MMUSIC] IETF 81 minutes posted > > The minutes of the IETF 81 MMUSIC meeting are now available at: > > http://www.ietf.org/proceedings/81/minutes/mmusic.txt > > Please read them, and if you have comments, questions, or changes to be > made, let the chairs know it. > > /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Bert.Greevenbosch@huawei.com Sun Aug 14 19:43:43 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21521F89CC for ; Sun, 14 Aug 2011 19:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eHIRMasTFVl for ; Sun, 14 Aug 2011 19:43:43 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7895A21F8997 for ; Sun, 14 Aug 2011 19:43:42 -0700 (PDT) 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 <0LPY008MT7M0IT@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 15 Aug 2011 10:44:24 +0800 (CST) Received: from szxrg02-dlp.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 <0LPY0058C7M098@szxga04-in.huawei.com> for mmusic@ietf.org; Mon, 15 Aug 2011 10:44:24 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADE34242; Mon, 15 Aug 2011 10:44:24 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 15 Aug 2011 10:44:22 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.150]) by szxeml409-hub.china.huawei.com ([169.254.89.141]) with mapi id 14.01.0270.001; Mon, 15 Aug 2011 10:44:21 +0800 Date: Mon, 15 Aug 2011 02:44:19 +0000 From: Bert Greevenbosch In-reply-to: X-Originating-IP: [10.70.109.57] To: "Roy Yue(PeiYu)" , Paul Beaumont Message-id: <46A1DF3F04371240B504290A071B4DB60BF141B0@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-GB, zh-CN, en-US Thread-topic: [MMUSIC] draft-greevenbosch-mmusic-signal-3d-format-01 Thread-index: AQHMVwS5bHODDOiBpkKqrxi0jfT6uZUU2UMAgAhTCVA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201107132136.p6DLamPn002152@mtv-core-3.cisco.com> <058f01cc4df5$f4e38720$deaa9560$@packetizer.com> <062701cc4e7b$b985f650$2c91e2f0$@packetizer.com> Cc: IETF - MMUSIC Subject: Re: [MMUSIC] draft-greevenbosch-mmusic-signal-3d-format-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 15 Aug 2011 02:43:43 -0000 SGkgUGF1bCwgUm95LCBhbGwsDQoNClJGQyA2MjM2IChzZWUgZXNwLiBzZWN0aW9uIDMuMS4xKSBz cGVjaWZpZXMgYSBnZW5lcmljIG1lY2hhbmlzbSB0byBzaWduYWwvbmVnb3RpYXRlIGltYWdlL3Zp ZGVvIGF0dHJpYnV0ZXMsIHN1Y2ggYXMgaW1hZ2Ugc2l6ZSwgaW4gU0RQLg0KDQpJZiBuZWVkZWQs IHRoaXMgbWVjaGFuaXNtIGNhbiBiZSB1c2VkIGZvciAzRCB2aWRlbyB0b28uIFRoZSBvbmx5IHBy b2JsZW0gSSBzZWUgaXMgaG93IHRvIGludGVycHJldCBpdCBpbiBjYXNlIG9mIGZyYW1lIHBhY2tp bmcuIEZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBwdXJwb3NlcywgSSB3b3VsZCBzYXkgaXQg c2hvdWxkIGJlIHRoZSBhY2N1bXVsYXRlZCBzaXplIG9mIHRoZSBMIGFuZCBSIGZyYW1lcywgaS5l LiBpbiBjYXNlIG9mIHNpZGUtYnktc2lkZSB2aWV3IHRoZSB4IHZhbHVlIHNob3VsZCBiZSB0d2lj ZSB0aGUgd2lkdGggb2YgdGhlIGRpc3BsYXllZCAzRCB2aWRlbyAocG9zc2libHkgd2l0aCAic2Fy PTIuMCIpLg0KDQpIZXJlIGlzIHRoZSBsaW5rIHRvIFJGQyA2MjM2OiBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL3JmYzYyMzYvDQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJveSBZdWUoUGVpWXUp DQpTZW50OiAxMCBBdWd1c3QgMjAxMSAxMDozOQ0KVG86IFBhdWwgQmVhdW1vbnQNCkNjOiBJRVRG IC0gTU1VU0lDDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gZHJhZnQtZ3JlZXZlbmJvc2NoLW1tdXNp Yy1zaWduYWwtM2QtZm9ybWF0LTAxDQoNCkhpIFBhdWwsDQoNClRoZSBpbmRpY2F0aW9uIG9mIGhv cml6b250YWwgcmVzb2x1dGlvbnMgaXMgZGVmaW5pdGVseSB1c2VmdWwsIGhvd2V2ZXIgSSB0aGlu aywgdGhpcyBpcyBvcnRob3Job21iaWMgd2l0aCB0aGUgc2lnbmFsIG9mIDNEIGZvcm1hdC4NCklu c3RlYWQsIHdlIG1heSBoYXZlIGEgbmV3IGF0dHJpYnV0ZSBpbiBTRFAgdG8gaW5kaWNhdGUgaG9y aXpvbnRhbCByZXNvbHV0aW9uIGZvciBhIGdlbmVyYWwgcHVycG9zZS4NCg0KT24gdGhlIG90aGVy IGhhbmQsIGluIGN1cnJlbnQgVFYgc3lzdGVtLCBhbm5vdGF0aW9uIG9mIGNvbnRlbnQgaG9yaXpv bnRhbCByZXNvbHV0aW9ucyBpcyB1c3VhbGx5IGRvbmUgaW4gdHdvIHBsYWNlLCBvbmUgaXMgaW4g RVBHIGZvciB0aGUgdXNlciByZWFkaW5nIGFuZCB0aGUgb3RoZXIgaXMgaW4gdGhlIHN0cmVhbWlu Zy9maWxlIGl0c2VsZiBmb3IgdGhlIGRlY29kZXIgaW5pdGlhbGl6YXRpb24uDQpQcm9iYWJseSB0 aGF0IGlzIGVub3VnaC4NCg0KQmVzdCByZWdhcmRzLA0KUGVpeXUgWVVFDQoNCi0tLS0t08q8/tSt vP4tLS0tLQ0Kt6K8/sjLOiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1tdXNpYy1i b3VuY2VzQGlldGYub3JnXSC0+rHtIFBhdWwgQmVhdW1vbnQNCreiy83KsbzkOiAyMDExxOo41MIy yNUgNTo1OQ0KytW8/sjLOiBJRVRGIC0gTU1VU0lDDQrW98ziOiBbTU1VU0lDXSBkcmFmdC1ncmVl dmVuYm9zY2gtbW11c2ljLXNpZ25hbC0zZC1mb3JtYXQtMDENCg0KQXQgSUVURiA4MSBtZWV0aW5n IG1tdXNpYyBXRyB0aGUgbGluZSB3YXMgY3V0IGJlZm9yZSBJIGNvdWxkIGNvbW1lbnQsIGJ1dCBh cyBwYXJ0IG9mIHRoZSBwYXJhbWV0ZXJzIHBvc3NpYmxlIHRvIHNpZ25hbCwgc2hvdWxkIHRoZXJl IGFsc28gYmUgYW4gaW5kaWNhdGlvbiBhcyB0byB0aGUgY29udGVudCBob3Jpem9udGFsIHJlc29s dXRpb25zLiBFZyAyayBvciA0ay4gTW92aWVzIGFyZSBub3cgYmVpbmcgcHJvZHVjZWQgaW4gdGhl IGxhdHRlciwgZWcgRGlzdHJpY3QgOSB3YXMgb25lIG9mIHRoZSBmaXJzdC4NCg0KUGF1bA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1h aWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21tdXNpYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg== From miguel.a.garcia@ericsson.com Tue Aug 16 03:18:29 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB2121F8AD3 for ; Tue, 16 Aug 2011 03:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FckYJMCh9EVd for ; Tue, 16 Aug 2011 03:18:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6539B21F8ACE for ; Tue, 16 Aug 2011 03:18:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-3f-4e4a44230eeb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AD.EC.02839.3244A4E4; Tue, 16 Aug 2011 12:19:15 +0200 (CEST) Received: from [159.107.24.231] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 16 Aug 2011 12:19:15 +0200 Message-ID: <4E4A4422.7040802@ericsson.com> Date: Tue, 16 Aug 2011 12:19:14 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mmusic , Simo Veikkolainen , Bob Gilman Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [MMUSIC] Submission of draft-garcia-mmusic-sdp-miscellaneous-caps X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 10:18:29 -0000 Hi, we have just submitted a new version of the miscellaneous capabilities negotiation in SDP draft. Here is the link: http://datatracker.ietf.org/doc/draft-garcia-mmusic-sdp-miscellaneous-caps/ This is an evolution of previous drafts, namely: draft-garcia-mmusic-sdp-icap-bcap, and draft garcia-mmusic-sdp-misc-cap. In previous versions of this draft, we define an icap and bcap attributes. We have now added a ccap attribute, whose purpose is to negotiate c= line capabilities. The main use case behind this capability is to be able to offer media streams over Circuit-Switched bearers (draft-ietf-mmusic-sdp-cs) or over regular RTP. We also want to note that earlier versions of draft-ietf-mmusic-sdp-cs discussed the negotiation of CS and RTP media streams, and they defined this ccap attribute, so, if you read one of those earlier versions, the text may sound quite familiar to you. As usually, the authors are looking for comments. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From HKaplan@acmepacket.com Tue Aug 16 07:56:48 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E6421F8B86 for ; Tue, 16 Aug 2011 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDE24L2RWsZ9 for ; Tue, 16 Aug 2011 07:56:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF021F8B7F for ; Tue, 16 Aug 2011 07:56:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 16 Aug 2011 10:57:32 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 16 Aug 2011 10:57:32 -0400 From: Hadriel Kaplan To: Flemming Andreasen Date: Tue, 16 Aug 2011 10:57:31 -0400 Thread-Topic: [MMUSIC] Media loopback draft and General Need for ICE alternative ? Thread-Index: AcxcJNMNk6ku8kDmRsaKtYytih16QQ== Message-ID: <003E4F9C-6DF6-4E85-8D39-0C8FE4BB0524@acmepacket.com> References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> In-Reply-To: <4E3D5968.3070001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_003E4F9C6DF64E858D390C8FE4BB0524acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Kaynam Hedayat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 14:56:48 -0000 --_000_003E4F9C6DF64E858D390C8FE4BB0524acmepacketcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93ZHksDQpJIG9iamVjdCB0byB0aGlzIGNoYW5nZSwgZndpdy4NCg0KVGhpcyBkcmFmdCB3YXMg c3RhcnRlZCBiZWZvcmUgdGhlcmUgd2FzIHN1Y2ggYSB0aGluZyBhcyBJQ0UsIGFuZCByZXF1aXJp bmcgSUNFIGF0IHRoaXMgc3RhZ2UgaXMgYSBzaWduaWZpY2FudCBodXJkbGUvYmFycmllci4gIElD RSBpcyBhIGh1Z2UgYW1vdW50IG9mIHdvcmsgdG8gaW1wbGVtZW50IHNpbXBseSB0byBnZXQgTkFU IHRyYXZlcnNhbCBmb3IgbWVkaWEtbG9vcGJhY2suICBPYnZpb3VzbHkgaWYgdGhlIFVBQyBhbmQg VUFTIGFscmVhZHkgdXNlIElDRSBmb3Igbm9ybWFsIGNhbGxzLCB0aGVuIGFsbCBpcyB3ZWxsIC0g YW5kIHRoZSBkcmFmdCBhbGxvd3MgZm9yIHRoYXQgLSBidXQgKnJlcXVpcmluZyogVUFzIHRoYXQg ZG9uJ3QgaGF2ZSBhbnkgSUNFIHN1cHBvcnQgdG8gc3VwcG9ydCBJQ0Ugc2ltcGx5IHRvIGJlIGFi bGUgdG8gcmVjZWl2ZS9hbnN3ZXIgbWVkaWEtbG9vcGJhY2sgY2FsbHMgaXMgY3JhenkuDQoNCkZ1 cnRoZXJtb3JlLCB0aGUgZW50aXJlIHBvaW50IG9mIGEgbWVkaWEgbG9vcGJhY2sgbWVjaGFuaXNt IGlzIHRvIG1ha2UgdGVzdCBjYWxscyAtIHRvIHZlcmlmeSB0aGUgc2lnbmFsaW5nIGFuZCBtZWRp YSBwYXRocyB3b3JrLCBhcyBpZiBhICJyZWFsIiBjYWxsIGhhZCBiZWVuIG1hZGUuICBTaW5jZSAi cmVhbCIgY2FsbHMgbWF5IG5vdCB1c2UgSUNFIChhbmQgaW4gZmFjdCBtb3N0IG9mdGVuIGRvIG5v dCB0b2RheSksIG1hbmRhdGluZyBpdCBiZSB1c2VkIGZvciBhIG1lZGlhLWxvb3BiYWNrIGNhbGwg aXMgYSBtaXN0YWtlLiAgRm9yIGV4YW1wbGUsIGl0IGNvdWxkIGZpbmQgbWVkaWEgcGF0aHMgdGhh dCB3b3VsZCBub3QgYmUgdXNlZCBmb3IgYWN0dWFsIGNhbGxzLCBmYWlsIHdoZW4gaXQgb3RoZXJ3 aXNlIHdvdWxkIGhhdmUgc3VjY2VlZGVkLCBvciBzdWNjZWVkIHdoZW4gaXQgd291bGQgb3RoZXJ3 aXNlIGhhdmUgZmFpbGVkLiAgVGhhdCBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIHRoZSBtZWRpYSBs b29wYmFjayBtZWNoYW5pc20uDQoNCi1oYWRyaWVsDQoNCg0KT24gQXVnIDYsIDIwMTEsIGF0IDEx OjEwIEFNLCBGbGVtbWluZyBBbmRyZWFzZW4gd3JvdGU6DQoNCkhpIEtheW5hbQ0KDQpJIHRoaW5r IHRoaXMgaXMgYSBnb29kIHBhdGggZm9yd2FyZC4NCg0KSWYgYW55Ym9keSBpbiB0aGUgV0cgZmVl bHMgb3RoZXJ3aXNlLCBwbGVhc2UgbGV0IHVzIGtub3cuDQoNClRoYW5rcw0KDQotLSBGbGVtbWlu ZyAoYXMgTU1VU0lDIGNvLWNoYWlyKQ0KDQoNCg0KDQpPbiA3LzI2LzExIDEyOjAxIFBNLCBLYXlu YW0gSGVkYXlhdCB3cm90ZToNCg0KRmxlbW1pbmcsIGV0LiBhbCwNCg0KR2l2ZW4gdGhlIGFtb3Vu dCBvZiBhcmd1bWVudCBhbmQgdGhlIGltcG9ydGFuY2Ugb2YgSUNFIEkgc3VnZ2VzdCByZW1vdmlu ZyB0aGUgYWx0ZXJuYXRpdmUgbWVjaGFuaXNtIGZyb20gdGhlIGRyYWZ0IChzZWN0aW9ucyA1Ljcs IDgsIDExLjMsIGFuZCAxMS41LCAxNC4yLjksIDE0LjIuMTAsIDE0LjIuMTEsIDE0LjIuMTIpLiBX ZSB3aWxsIGFkZCBhIG5ldyBzZWN0aW9uIHRoYXQgcmVxdWlyZXMgdXNlIG9mIElDRSBmb3IgY2Fs bHMgYmVoaW5kIE5BVC4gSSBiZWxpZXZlIHRoaXMgaXMgdGhlIGJlc3QgcGF0aCBmb3J3YXJkLg0K DQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhlIGdyb3VwIGFncmVlcyBhbmQgd2Ugd2lsbCBjaGFu Z2UgdGhlIGRyYWZ0IGFjY29yZGluZ2x5Lg0KDQpSZWdhcmRzLA0KS2F5bmFtDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRW1pbCBJdm92DQpTZW50OiBUaHVyc2RheSwgSnVseSAwNywgMjAx MSAxMjozMSBQTQ0KVG86IEZsZW1taW5nIEFuZHJlYXNlbg0KQ2M6IG1tdXNpY0BpZXRmLm9yZzxt YWlsdG86bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIE1lZGlhIGxvb3Bi YWNrIGRyYWZ0IGFuZCBHZW5lcmFsIE5lZWQgZm9yIElDRSBhbHRlcm5hdGl2ZSA/DQoNCkhleSBG bGVtbWluZywNCg0K0J3QsCAwNy4wNy4xMSAxNjo0OSwgRmxlbW1pbmcgQW5kcmVhc2VuINC90LDQ v9C40YHQsDoNCg0KPHNuaXA+DQoNCj4+IEhvdyBhcmUgdGhlc2UgImlycmVndWxhciIgU0RQIGFu ZCB3aGF0IHJlYXNvbiB3b3VsZCBhIG1pZGRsZSBib3ggaGF2ZSB0bw0KPj4gcmVtb3ZlIHRoZW0/ DQo+Pg0KPiBNeSBwb2ludCBpcyB0aGF0IHRoZXkgYXJlIGp1c3QgYXMgcmVndWxhciBvciBpcnJl Z3VsYXIgYXMgYW55IG90aGVyIFNEUCwNCj4gaW5jbHVkaW5nIElDRS4gVGhlIG9uZSBkaWZmZXJl bmNlIEkgZG8gc2VlIGF0IHRoaXMgcG9pbnQgaXMgdGhhdCBieSB0aGUNCj4gbWlkZGxlIGJveCBj aGFuZ2luZyBhZGRyZXNzIGluZm9ybWF0aW9uIGluIHRoZSBTRFAsIGl0IHdpbGwgZWZmZWN0aXZl bHkNCj4gdHVybiBvZmYgSUNFIGJhc2VkIG9uIHRoZSBpY2UtbWlzbWF0Y2ggcHJvY2VkdXJlIHlv dSBwb2ludGVkIG91dC4gVGhlDQo+IGxvb3BiYWNrIG1lY2hhbmlzbSB3aWxsIG5vdCBzdWZmZXIg ZnJvbSB0aGlzIHByb2JsZW0sIGFzIGxvbmcgYXMgdGhlDQo+IG1pZGRsZSBib3ggcGFzc2VzIHRo cm91Z2ggdGhlIFNEUCB3aXRoIHdoYXRldmVyIHBhcmFtZXRlcnMgaXQgY29udGFpbnMNCj4gKGku ZS4gdGhlIG1pZGRsZSBib3ggZG9lcyBub3QgaW5zaXN0IG9uIHVuZGVyc3RhbmRpbmcgdGhlIFNE UCBpdHNlbGY7IGlmDQo+IGl0IGRpZCwgaXQgd291bGQgaGF2ZSB0byBzdXBwb3J0IHRoZSBsb29w YmFjayBtZWNoYW5pc20gaW5jbHVkaW5nIGl0cw0KPiBkZWZpbmVkIFNEUCBleHRlbnNpb25zIGFu ZCBsb29wYmFjayBwcmltZXIgcGF5bG9hZCkuDQoNCldlbCBkb2VzIGl0IHJlYWxseSBuZWVkIHRv IHN1cHBvcnQgdGhlIHBheWxvYWQgb3IgYW55IGxvb3BiYWNrLXNwZWNpZmljDQptZWNoYW5pc21z PyBJIGFwb2xvZ2lzZSBpZiBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGJ1dCwgYXMgbG9uZyBhcyB0 aGUNCm1pZGRsZSBib3ggaXMgbm90IHBsYW5uaW5nIG9uIGFic29sdXRlbHkgZGVjb2RpbmcgbWVk aWEsIGl0IHNob3VsZCBiZQ0KT0suIEFjY29yZGluZyB0byBteSBleHBlcmllbmNlLCBpdCBpcyBy ZWFzb25hYmxlIHRvIGV4cGVjdCB0aGF0IG1vc3QgU0lQDQpwcm94aWVzIHdvdWxkIGhhbmRsZSB0 aGlzIHByb3Blcmx5Lg0KDQpJIGFtIG9mIGNvdXJzZSBvbmx5IHRhbGtpbmcgYWJvdXQgdGhlIE5B VCB0cmF2ZXJzYWwvbGF0Y2hpbmcgYXNwZWN0cyBvZg0KdGhlIGRyYWZ0LiBPYnZpb3VzbHkgdGhl IGVjaG8tcmVsYXRlZCBwYXJhbXMgbWF5IGJlIG1vcmUgZXhwb3NlZCB0bw0KcHJ1bmluZy4NCg0K PHNuaXA+DQoNCj4+IFdlbGwgYWdhaW4sIEkgZG9uJ3Qgc2VlIGFueXRoaW5nIGluIHRoaXMgZHJh ZnQgdGhhdCB3b3VsZCBhbGxvdyB0d28NCj4+IGNsaWVudHMsIGJvdGggb2Ygd2hpY2ggYXJlIGJl aGluZCBhIE5BVCwgdG8gdGFsayB0byBlYWNoIG90aGVyLiBUaGUNCj4+IHJlbGF5IGluIHRoZSBt aWRkbGUgZG9lcy4gSW4gdGhhdCByZXNwZWN0IEkgZG9uJ3Qgc2VlIGhvdyBhbnlvbmUgY2FuDQo+ PiBwcmV0ZW5kIHRoYXQgdGhlIGxvb3BiYWNrIHByaW1lciBpcyBhbiAiYWx0ZXJuYXRpdmUgdG8g SUNFIi4gSXQgaXMgbm90Lg0KPj4gIEl0IGRvZXMgbm90IHByb3ZpZGUgbWVhbnMgZm9yIGNsaWVu dHMgdG8gZGlzY292ZXIgYSBkaXJlY3QgcGF0aCB0byBlYWNoDQo+PiBvdGhlci4gSXQgZG9lcyBu b3QgcHJvdmlkZSByZWxheWluZy4gSXQgb25seSBoZWxwcyB0byByZXNvbHZlIGENCj4+IHN0YXJ2 YXRpb24gaW4gdGhlIGVjaG8gdXNlIGNhc2UgYW5kIGluIGEgc2NlbmFyaW8gd2hlcmUgYSByZWd1 bGFyDQo+PiBiaS1kaXJlY3Rpb25hbCB2b2lwIGNhbGwgd291bGQgaGF2ZSB3b3JrZWQgYW55d2F5 IGJlY2F1c2Ugb2YgdGhlDQo+PiBsYXRjaGluZyB0aGF0IG1pZGRsZSBib3hlcyBhcmUgZG9pbmcu DQo+Pg0KPiBJIGFncmVlIHdpdGggeW91ciBwb2ludCBhYm92ZSwgaG93ZXZlciBpdCBkb2VzIGFs c28gcHJvdmlkZSBhIGxpbWl0ZWQNCj4gYWx0ZXJuYXRpdmUgdG8gSUNFIGluYXNtdWNoIGFzIGl0 IGRlZmluZXMgYW4gYWx0ZXJuYXRpdmUgTkFUIHRyYXZlcnNhbA0KPiBtZWNoYW5pc20gdGhhdCBj YW4gYmUgdXNlZCBpbiBjZXJ0YWluIGxpbWl0ZWQgZGVwbG95bWVudCBzY2VuYXJpb3MNCj4gKHdp dGhvdXQgcmVsYXlzKSwgYW5kIHRoZSB3YXkgdGhlIGRyYWZ0IGlzIHdyaXR0ZW4gY3VycmVudGx5 LCB0aGF0J3MgdGhlDQo+IHdheSB0aGlzIG1lY2hhbmltIGlzIHBvc2l0aW9uZWQgYXMgd2VsbC4g QWdhaW4sIHlvdSBhcmUgYnJpbmdpbmcgdXANCj4gYW5vdGhlciByZWFsLWxpZmUgdXNlIGNhc2Ug dGhhdCBoYXMgbWVyaXQgSU1PLiBJdCB3b3VsZCBiZSBnb29kIHRvIGtub3cNCj4gaWYgdGhlcmUg YXJlIG90aGVycy4NCg0KV2VsbCwgdGhlcmUncyBhbHNvIHRoZSBjYXNlIG9mIFVEUC1vbmx5IFNJ UCBwcm94aWVzLiBJIGhhdmUgeWV0IHRvIHNlZSBhDQpyZWFsLWxpZmUgYXVkaW8vdmlkZW8gSU5W SVRFIHRoYXQgY2FuIGZpdCBpbnRvIGEgc2luZ2xlIGV0aGVybmV0IE1UVQ0KdG9nZXRoZXIgd2l0 aCBhbiBJQ0UgY2FuZGlkYXRlIGxpc3RzLiBJbiBzdWNoIGNhc2VzIGNsaWVudHMgbWF5IGFnYWlu DQp3aXNoIHRvIGZhbGwgYmFjayB0byBhbiBJQ0VsZXNzIGxlYXAgb2YgZmFpdGggYW5kIGhvcGUg Zm9yIGxhdGNoaW5nLg0KDQpPZiBjb3Vyc2UsIFVEUC1vbmx5IHByb3hpZXMgYmVpbmcgcHJvaGli aXRlZCBieSAzMjYxLCB0aGlzIGNhc2UgbWF5IGJlDQpjb25zaWRlcmVkIGlycmVsZXZhbnQuIFN0 aWxsLCBJIHRob3VnaHQgSScgbWVudGlvbiBpdCBhbnl3YXkgZ2l2ZW4gdGhhdA0KbWFueSBwcm92 aWRlcnMgb3V0IHRoZXJlIGNob29zZSBub3QgdG8gZW5hYmxlIFRDUCByZWdhcmRsZXNzIG9mIHdo YXQNCjMyNjEgc2F5cy4NCg0KQ2hlZXJzLA0KRW1pbA0KDQoNCi0tDQpodHRwOi8vaml0c2kub3Jn PGh0dHA6Ly9qaXRzaS5vcmcvPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0 bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYw0KDQo= --_000_003E4F9C6DF64E858D390C8FE4BB0524acmepacketcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj48ZGl2Pkhvd2R5LDwvZGl2PjxkaXY+SSBvYmplY3QgdG8gdGhpcyBjaGFuZ2UsIGZ3 aXcuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGlzIGRyYWZ0IHdhcyBzdGFydGVkIGJlZm9y ZSB0aGVyZSB3YXMgc3VjaCBhIHRoaW5nIGFzIElDRSwgYW5kIHJlcXVpcmluZyBJQ0UgYXQgdGhp cyBzdGFnZSBpcyBhIHNpZ25pZmljYW50IGh1cmRsZS9iYXJyaWVyLiAmbmJzcDtJQ0UgaXMgYSBo dWdlIGFtb3VudCBvZiB3b3JrIHRvIGltcGxlbWVudCBzaW1wbHkgdG8gZ2V0IE5BVCB0cmF2ZXJz YWwgZm9yIG1lZGlhLWxvb3BiYWNrLiAmbmJzcDtPYnZpb3VzbHkgaWYgdGhlIFVBQyBhbmQgVUFT Jm5ic3A7YWxyZWFkeSZuYnNwO3VzZSBJQ0UgZm9yIG5vcm1hbCBjYWxscywgdGhlbiBhbGwgaXMg d2VsbCAtIGFuZCB0aGUgZHJhZnQgYWxsb3dzIGZvciB0aGF0IC0gYnV0ICpyZXF1aXJpbmcqIFVB cyB0aGF0IGRvbid0IGhhdmUgYW55IElDRSBzdXBwb3J0IHRvIHN1cHBvcnQgSUNFIHNpbXBseSB0 byBiZSBhYmxlIHRvIHJlY2VpdmUvYW5zd2VyIG1lZGlhLWxvb3BiYWNrIGNhbGxzIGlzIGNyYXp5 LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RnVydGhlcm1vcmUsIHRoZSBlbnRpcmUgcG9pbnQg b2YgYSBtZWRpYSBsb29wYmFjayBtZWNoYW5pc20gaXMgdG8gbWFrZSB0ZXN0IGNhbGxzIC0gdG8g dmVyaWZ5IHRoZSBzaWduYWxpbmcgYW5kIG1lZGlhIHBhdGhzIHdvcmssIGFzIGlmIGEgInJlYWwi IGNhbGwgaGFkIGJlZW4gbWFkZS4gJm5ic3A7U2luY2UgInJlYWwiIGNhbGxzIG1heSBub3QgdXNl IElDRSAoYW5kIGluIGZhY3QgbW9zdCBvZnRlbiBkbyBub3QgdG9kYXkpLCBtYW5kYXRpbmcgaXQg YmUgdXNlZCBmb3IgYSBtZWRpYS1sb29wYmFjayBjYWxsIGlzIGEgbWlzdGFrZS4gJm5ic3A7Rm9y IGV4YW1wbGUsIGl0IGNvdWxkIGZpbmQgbWVkaWEgcGF0aHMgdGhhdCB3b3VsZCBub3QgYmUgdXNl ZCBmb3IgYWN0dWFsIGNhbGxzLCBmYWlsIHdoZW4gaXQgb3RoZXJ3aXNlIHdvdWxkIGhhdmUgc3Vj Y2VlZGVkLCBvciBzdWNjZWVkIHdoZW4gaXQgd291bGQgb3RoZXJ3aXNlIGhhdmUgZmFpbGVkLiAm bmJzcDtUaGF0IGRlZmVhdHMgdGhlIHB1cnBvc2Ugb2YgdGhlIG1lZGlhIGxvb3BiYWNrIG1lY2hh bmlzbS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi1oYWRyaWVsPC9kaXY+PGRpdj48YnI+PC9k aXY+PGJyPjxkaXY+PGRpdj5PbiBBdWcgNiwgMjAxMSwgYXQgMTE6MTAgQU0sIEZsZW1taW5nIEFu ZHJlYXNlbiB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KDQoNCiAgPG1ldGEgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PVVURi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KDQo8ZGl2IGJnY29s b3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiPg0KSGkgS2F5bmFtIDxicj4NCjxicj4NCkkgdGhp bmsgdGhpcyBpcyBhIGdvb2QgcGF0aCBmb3J3YXJkLiA8YnI+DQo8YnI+DQpJZiBhbnlib2R5IGlu IHRoZSBXRyBmZWVscyBvdGhlcndpc2UsIHBsZWFzZSBsZXQgdXMga25vdy4gPGJyPg0KPGJyPg0K VGhhbmtzIDxicj4NCjxicj4NCi0tIEZsZW1taW5nIChhcyBNTVVTSUMgY28tY2hhaXIpIDxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDcvMjYvMTEgMTI6MDEgUE0sIEtheW5hbSBIZWRh eWF0IHdyb3RlOg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjg2RjkwNjlFMDdBNUVDNEU4OTBBRjcz RkQ4RTg1RTE3NzdERjJDQHNwYm9leGMwMS5leGZvLmNvbSIgdHlwZT0iY2l0ZSI+DQogIDxtZXRh IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVU Ri04Ij4NCiAgPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNUyBFeGNoYW5nZSBTZXJ2 ZXIgdmVyc2lvbiA2LjUuNzY1NS4xMCI+DQogIDx0aXRsZT5SRTogW01NVVNJQ10gTWVkaWEgbG9v cGJhY2sgZHJhZnQgYW5kIEdlbmVyYWwgTmVlZCBmb3IgSUNFDQphbHRlcm5hdGl2ZSA/PC90aXRs ZT4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+PHA+PGZvbnQgc2l6 ZT0iMiI+RmxlbW1pbmcsIGV0LiBhbCw8YnI+DQogIDxicj4NCkdpdmVuIHRoZSBhbW91bnQgb2Yg YXJndW1lbnQgYW5kIHRoZSBpbXBvcnRhbmNlIG9mIElDRSBJIHN1Z2dlc3QNCnJlbW92aW5nIHRo ZSBhbHRlcm5hdGl2ZSBtZWNoYW5pc20gZnJvbSB0aGUgZHJhZnQgKHNlY3Rpb25zIDUuNywgOCwN CjExLjMsIGFuZCAxMS41LCAxNC4yLjksIDE0LjIuMTAsIDE0LjIuMTEsIDE0LjIuMTIpLiBXZSB3 aWxsIGFkZCBhIG5ldw0Kc2VjdGlvbiB0aGF0IHJlcXVpcmVzIHVzZSBvZiBJQ0UgZm9yIGNhbGxz IGJlaGluZCBOQVQuIEkgYmVsaWV2ZSB0aGlzDQppcyB0aGUgYmVzdCBwYXRoIGZvcndhcmQuPGJy Pg0KICA8YnI+DQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhlIGdyb3VwIGFncmVlcyBhbmQgd2Ug d2lsbCBjaGFuZ2UgdGhlIGRyYWZ0DQphY2NvcmRpbmdseS48YnI+DQogIDxicj4NClJlZ2FyZHMs PGJyPg0KS2F5bmFtPGJyPg0KICA8YnI+DQogIDxicj4NCiAgPGJyPg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVk IiBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3VuY2VzQGll dGYub3JnPC9hPiBbPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86bW11c2lj LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQpP biBCZWhhbGYgT2YgRW1pbCBJdm92PGJyPg0KU2VudDogVGh1cnNkYXksIEp1bHkgMDcsIDIwMTEg MTI6MzEgUE08YnI+DQpUbzogRmxlbW1pbmcgQW5kcmVhc2VuPGJyPg0KQ2M6IDxhIGNsYXNzPSJt b3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1t dXNpY0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gTWVkaWEgbG9vcGJh Y2sgZHJhZnQgYW5kIEdlbmVyYWwgTmVlZCBmb3IgSUNFDQphbHRlcm5hdGl2ZSA/PGJyPg0KICA8 YnI+DQpIZXkgRmxlbW1pbmcsPGJyPg0KICA8YnI+DQrQndCwIDA3LjA3LjExIDE2OjQ5LCBGbGVt bWluZyBBbmRyZWFzZW4g0L3QsNC/0LjRgdCwOjxicj4NCiAgPGJyPg0KJmx0O3NuaXAmZ3Q7PGJy Pg0KICA8YnI+DQomZ3Q7Jmd0OyBIb3cgYXJlIHRoZXNlICJpcnJlZ3VsYXIiIFNEUCBhbmQgd2hh dCByZWFzb24gd291bGQgYSBtaWRkbGUNCmJveCBoYXZlIHRvPGJyPg0KJmd0OyZndDsgcmVtb3Zl IHRoZW0/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IE15IHBvaW50IGlzIHRoYXQgdGhleSBhcmUg anVzdCBhcyByZWd1bGFyIG9yIGlycmVndWxhciBhcyBhbnkNCm90aGVyIFNEUCw8YnI+DQomZ3Q7 IGluY2x1ZGluZyBJQ0UuIFRoZSBvbmUgZGlmZmVyZW5jZSBJIGRvIHNlZSBhdCB0aGlzIHBvaW50 IGlzIHRoYXQNCmJ5IHRoZTxicj4NCiZndDsgbWlkZGxlIGJveCBjaGFuZ2luZyBhZGRyZXNzIGlu Zm9ybWF0aW9uIGluIHRoZSBTRFAsIGl0IHdpbGwNCmVmZmVjdGl2ZWx5PGJyPg0KJmd0OyB0dXJu IG9mZiBJQ0UgYmFzZWQgb24gdGhlIGljZS1taXNtYXRjaCBwcm9jZWR1cmUgeW91IHBvaW50ZWQg b3V0Lg0KVGhlPGJyPg0KJmd0OyBsb29wYmFjayBtZWNoYW5pc20gd2lsbCBub3Qgc3VmZmVyIGZy b20gdGhpcyBwcm9ibGVtLCBhcyBsb25nIGFzDQp0aGU8YnI+DQomZ3Q7IG1pZGRsZSBib3ggcGFz c2VzIHRocm91Z2ggdGhlIFNEUCB3aXRoIHdoYXRldmVyIHBhcmFtZXRlcnMgaXQNCmNvbnRhaW5z PGJyPg0KJmd0OyAoaS5lLiB0aGUgbWlkZGxlIGJveCBkb2VzIG5vdCBpbnNpc3Qgb24gdW5kZXJz dGFuZGluZyB0aGUgU0RQDQppdHNlbGY7IGlmPGJyPg0KJmd0OyBpdCBkaWQsIGl0IHdvdWxkIGhh dmUgdG8gc3VwcG9ydCB0aGUgbG9vcGJhY2sgbWVjaGFuaXNtIGluY2x1ZGluZw0KaXRzPGJyPg0K Jmd0OyBkZWZpbmVkIFNEUCBleHRlbnNpb25zIGFuZCBsb29wYmFjayBwcmltZXIgcGF5bG9hZCku PGJyPg0KICA8YnI+DQpXZWwgZG9lcyBpdCByZWFsbHkgbmVlZCB0byBzdXBwb3J0IHRoZSBwYXls b2FkIG9yIGFueSBsb29wYmFjay1zcGVjaWZpYzxicj4NCm1lY2hhbmlzbXM/IEkgYXBvbG9naXNl IGlmIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgYnV0LCBhcyBsb25nIGFzIHRoZTxicj4NCm1pZGRs ZSBib3ggaXMgbm90IHBsYW5uaW5nIG9uIGFic29sdXRlbHkgZGVjb2RpbmcgbWVkaWEsIGl0IHNo b3VsZCBiZTxicj4NCk9LLiBBY2NvcmRpbmcgdG8gbXkgZXhwZXJpZW5jZSwgaXQgaXMgcmVhc29u YWJsZSB0byBleHBlY3QgdGhhdCBtb3N0IFNJUDxicj4NCnByb3hpZXMgd291bGQgaGFuZGxlIHRo aXMgcHJvcGVybHkuPGJyPg0KICA8YnI+DQpJIGFtIG9mIGNvdXJzZSBvbmx5IHRhbGtpbmcgYWJv dXQgdGhlIE5BVCB0cmF2ZXJzYWwvbGF0Y2hpbmcgYXNwZWN0cyBvZjxicj4NCnRoZSBkcmFmdC4g T2J2aW91c2x5IHRoZSBlY2hvLXJlbGF0ZWQgcGFyYW1zIG1heSBiZSBtb3JlIGV4cG9zZWQgdG88 YnI+DQpwcnVuaW5nLjxicj4NCiAgPGJyPg0KJmx0O3NuaXAmZ3Q7PGJyPg0KICA8YnI+DQomZ3Q7 Jmd0OyBXZWxsIGFnYWluLCBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGlzIGRyYWZ0IHRoYXQg d291bGQNCmFsbG93IHR3bzxicj4NCiZndDsmZ3Q7IGNsaWVudHMsIGJvdGggb2Ygd2hpY2ggYXJl IGJlaGluZCBhIE5BVCwgdG8gdGFsayB0byBlYWNoDQpvdGhlci4gVGhlPGJyPg0KJmd0OyZndDsg cmVsYXkgaW4gdGhlIG1pZGRsZSBkb2VzLiBJbiB0aGF0IHJlc3BlY3QgSSBkb24ndCBzZWUgaG93 DQphbnlvbmUgY2FuPGJyPg0KJmd0OyZndDsgcHJldGVuZCB0aGF0IHRoZSBsb29wYmFjayBwcmlt ZXIgaXMgYW4gImFsdGVybmF0aXZlIHRvIElDRSIuDQpJdCBpcyBub3QuPGJyPg0KJmd0OyZndDsm bmJzcDsgSXQgZG9lcyBub3QgcHJvdmlkZSBtZWFucyBmb3IgY2xpZW50cyB0byBkaXNjb3ZlciBh IGRpcmVjdA0KcGF0aCB0byBlYWNoPGJyPg0KJmd0OyZndDsgb3RoZXIuIEl0IGRvZXMgbm90IHBy b3ZpZGUgcmVsYXlpbmcuIEl0IG9ubHkgaGVscHMgdG8gcmVzb2x2ZSBhPGJyPg0KJmd0OyZndDsg c3RhcnZhdGlvbiBpbiB0aGUgZWNobyB1c2UgY2FzZSBhbmQgaW4gYSBzY2VuYXJpbyB3aGVyZSBh DQpyZWd1bGFyPGJyPg0KJmd0OyZndDsgYmktZGlyZWN0aW9uYWwgdm9pcCBjYWxsIHdvdWxkIGhh dmUgd29ya2VkIGFueXdheSBiZWNhdXNlIG9mDQp0aGU8YnI+DQomZ3Q7Jmd0OyBsYXRjaGluZyB0 aGF0IG1pZGRsZSBib3hlcyBhcmUgZG9pbmcuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IEkgYWdy ZWUgd2l0aCB5b3VyIHBvaW50IGFib3ZlLCBob3dldmVyIGl0IGRvZXMgYWxzbyBwcm92aWRlIGEN CmxpbWl0ZWQ8YnI+DQomZ3Q7IGFsdGVybmF0aXZlIHRvIElDRSBpbmFzbXVjaCBhcyBpdCBkZWZp bmVzIGFuIGFsdGVybmF0aXZlIE5BVA0KdHJhdmVyc2FsPGJyPg0KJmd0OyBtZWNoYW5pc20gdGhh dCBjYW4gYmUgdXNlZCBpbiBjZXJ0YWluIGxpbWl0ZWQgZGVwbG95bWVudCBzY2VuYXJpb3M8YnI+ DQomZ3Q7ICh3aXRob3V0IHJlbGF5cyksIGFuZCB0aGUgd2F5IHRoZSBkcmFmdCBpcyB3cml0dGVu IGN1cnJlbnRseSwNCnRoYXQncyB0aGU8YnI+DQomZ3Q7IHdheSB0aGlzIG1lY2hhbmltIGlzIHBv c2l0aW9uZWQgYXMgd2VsbC4gQWdhaW4sIHlvdSBhcmUgYnJpbmdpbmcgdXA8YnI+DQomZ3Q7IGFu b3RoZXIgcmVhbC1saWZlIHVzZSBjYXNlIHRoYXQgaGFzIG1lcml0IElNTy4gSXQgd291bGQgYmUg Z29vZCB0bw0Ka25vdzxicj4NCiZndDsgaWYgdGhlcmUgYXJlIG90aGVycy48YnI+DQogIDxicj4N CldlbGwsIHRoZXJlJ3MgYWxzbyB0aGUgY2FzZSBvZiBVRFAtb25seSBTSVAgcHJveGllcy4gSSBo YXZlIHlldCB0byBzZWUgYTxicj4NCnJlYWwtbGlmZSBhdWRpby92aWRlbyBJTlZJVEUgdGhhdCBj YW4gZml0IGludG8gYSBzaW5nbGUgZXRoZXJuZXQgTVRVPGJyPg0KdG9nZXRoZXIgd2l0aCBhbiBJ Q0UgY2FuZGlkYXRlIGxpc3RzLiBJbiBzdWNoIGNhc2VzIGNsaWVudHMgbWF5IGFnYWluPGJyPg0K d2lzaCB0byBmYWxsIGJhY2sgdG8gYW4gSUNFbGVzcyBsZWFwIG9mIGZhaXRoIGFuZCBob3BlIGZv ciBsYXRjaGluZy48YnI+DQogIDxicj4NCk9mIGNvdXJzZSwgVURQLW9ubHkgcHJveGllcyBiZWlu ZyBwcm9oaWJpdGVkIGJ5IDMyNjEsIHRoaXMgY2FzZSBtYXkgYmU8YnI+DQpjb25zaWRlcmVkIGly cmVsZXZhbnQuIFN0aWxsLCBJIHRob3VnaHQgSScgbWVudGlvbiBpdCBhbnl3YXkgZ2l2ZW4gdGhh dDxicj4NCm1hbnkgcHJvdmlkZXJzIG91dCB0aGVyZSBjaG9vc2Ugbm90IHRvIGVuYWJsZSBUQ1Ag cmVnYXJkbGVzcyBvZiB3aGF0PGJyPg0KMzI2MSBzYXlzLjxicj4NCiAgPGJyPg0KQ2hlZXJzLDxi cj4NCkVtaWw8YnI+DQogIDxicj4NCiAgPGJyPg0KLS08YnI+DQogIDxhIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgaHJlZj0iaHR0cDovL2ppdHNpLm9yZy8iPmh0dHA6Ly9qaXRzaS5vcmc8L2E+PGJy Pg0KICA8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFi YnJldmlhdGVkIiBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyPg0KICA8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQogIDwvZm9udD4NCiAgPC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9ib2R5PjwvaHRtbD4= --_000_003E4F9C6DF64E858D390C8FE4BB0524acmepacketcom_-- From dwing@cisco.com Tue Aug 16 11:11:37 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577BA21F8BCD for ; Tue, 16 Aug 2011 11:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.458 X-Spam-Level: X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTYBoyBugaop for ; Tue, 16 Aug 2011 11:11:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4A82521F8B98 for ; Tue, 16 Aug 2011 11:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6789; q=dns/txt; s=iport; t=1313518345; x=1314727945; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=cIxkR2Hw9cg8anp3slQXtpsS+vh+WbJN6GbHxnN/DZY=; b=AKMMJx8cYfPlcfMJXvKubeJB033Tv0vbHjTNelI8C9ormcAJUSjKI0Hj RGzSBHFQNyyeliL25npLdwMQM9/DzzwkOTj8NVF2W+bMHNLYyhr9lZt80 D2wGvrgEdVb2+r9GSsocvpRBhJWv2KxS7lGY12X1IZkxG4NPbC/5UhssT 0=; X-IronPort-AV: E=Sophos;i="4.68,234,1312156800"; d="scan'208";a="13659393" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2011 18:12:24 +0000 Received: from dwingWS (sjc-vpn2-166.cisco.com [10.21.112.166]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7GICOfj011163; Tue, 16 Aug 2011 18:12:24 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Flemming Andreasen'" References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> <003E4F9C-6DF6-4E85-8D39-0C8FE4BB0524@acmepacket.com> In-Reply-To: <003E4F9C-6DF6-4E85-8D39-0C8FE4BB0524@acmepacket.com> Date: Tue, 16 Aug 2011 11:12:24 -0700 Message-ID: <16ef01cc5c40$0c772920$25657b60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxcJNMNk6ku8kDmRsaKtYytih16QQAGpyWA Content-Language: en-us Cc: 'Kaynam Hedayat' , mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 18:11:37 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Tuesday, August 16, 2011 7:58 AM > To: Flemming Andreasen > Cc: Kaynam Hedayat; mmusic@ietf.org > Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE > alternative ? >=20 > Howdy, > I object to this change, fwiw. There are two changes: (1) removing the loopback-specific NAT = traversal, and (2) the requirement to use ICE. I believe you are objecting to (2), but you are okay with (1)? > This draft was started before there was such a thing as ICE, and > requiring ICE at this stage is a significant hurdle/barrier. ICE is a > huge amount of work to implement simply to get NAT traversal for = media- > loopback. Obviously if the UAC and UAS already use ICE for normal > calls, then all is well - and the draft allows for that - but > *requiring* UAs that don't have any ICE support to support ICE simply > to be able to receive/answer media-loopback calls is crazy. >=20 > Furthermore, the entire point of a media loopback mechanism is to make > test calls - to verify the signaling and media paths work, as if a > "real" call had been made. Since "real" calls may not use ICE (and in > fact most often do not today), mandating it be used for a media- > loopback call is a mistake. For example, it could find media paths > that would not be used for actual calls, fail when it otherwise would > have succeeded, or succeed when it would otherwise have failed. That > defeats the purpose of the media loopback mechanism. How about something like: "When performing a media loopback, the endpoints MUST use the same=20 NAT traversal and the same IPv6 transition mechanism employed=20 by the network for normal call setup (e.g., ICE [RFC5245], media latching [I-D.ietf-mmusic-media-path-middleboxes])." (Yes, I threw IPv6 transition into the mix, because ICE is also the official IPv6 transition mechanism. ICE isn't just for NAT44.) -d > -hadriel >=20 >=20 > On Aug 6, 2011, at 11:10 AM, Flemming Andreasen wrote: >=20 >=20 > Hi Kaynam >=20 > I think this is a good path forward. >=20 > If anybody in the WG feels otherwise, please let us know. >=20 > Thanks >=20 > -- Flemming (as MMUSIC co-chair) >=20 >=20 >=20 >=20 > On 7/26/11 12:01 PM, Kaynam Hedayat wrote: >=20 > Flemming, et. al, >=20 > Given the amount of argument and the importance of ICE I > suggest removing the alternative mechanism from the draft (sections > 5.7, 8, 11.3, and 11.5, 14.2.9, 14.2.10, 14.2.11, 14.2.12). We will = add > a new section that requires use of ICE for calls behind NAT. I believe > this is the best path forward. >=20 > Please let me know if the group agrees and we will change > the draft accordingly. >=20 > Regards, > Kaynam >=20 >=20 >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic- > bounces@ietf.org] On Behalf Of Emil Ivov > Sent: Thursday, July 07, 2011 12:31 PM > To: Flemming Andreasen > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Media loopback draft and General Need > for ICE alternative ? >=20 > Hey Flemming, >=20 > =D0=9D=D0=B0 07.07.11 16:49, Flemming Andreasen = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: >=20 > >=20 > >> How are these "irregular" SDP and what reason would a > middle box have to > >> remove them? > >> > > My point is that they are just as regular or irregular as > any other SDP, > > including ICE. The one difference I do see at this point > is that by the > > middle box changing address information in the SDP, it > will effectively > > turn off ICE based on the ice-mismatch procedure you > pointed out. The > > loopback mechanism will not suffer from this problem, as > long as the > > middle box passes through the SDP with whatever > parameters it contains > > (i.e. the middle box does not insist on understanding the > SDP itself; if > > it did, it would have to support the loopback mechanism > including its > > defined SDP extensions and loopback primer payload). >=20 > Wel does it really need to support the payload or any > loopback-specific > mechanisms? I apologise if I am missing something but, as > long as the > middle box is not planning on absolutely decoding media, it > should be > OK. According to my experience, it is reasonable to expect > that most SIP > proxies would handle this properly. >=20 > I am of course only talking about the NAT > traversal/latching aspects of > the draft. Obviously the echo-related params may be more > exposed to > pruning. >=20 > >=20 > >> Well again, I don't see anything in this draft that > would allow two > >> clients, both of which are behind a NAT, to talk to each > other. The > >> relay in the middle does. In that respect I don't see > how anyone can > >> pretend that the loopback primer is an "alternative to > ICE". It is not. > >> It does not provide means for clients to discover a > direct path to each > >> other. It does not provide relaying. It only helps to > resolve a > >> starvation in the echo use case and in a scenario where > a regular > >> bi-directional voip call would have worked anyway > because of the > >> latching that middle boxes are doing. > >> > > I agree with your point above, however it does also > provide a limited > > alternative to ICE inasmuch as it defines an alternative > NAT traversal > > mechanism that can be used in certain limited deployment > scenarios > > (without relays), and the way the draft is written > currently, that's the > > way this mechanim is positioned as well. Again, you are > bringing up > > another real-life use case that has merit IMO. It would > be good to know > > if there are others. >=20 > Well, there's also the case of UDP-only SIP proxies. I have > yet to see a > real-life audio/video INVITE that can fit into a single > ethernet MTU > together with an ICE candidate lists. In such cases clients > may again > wish to fall back to an ICEless leap of faith and hope for > latching. >=20 > Of course, UDP-only proxies being prohibited by 3261, this > case may be > considered irrelevant. Still, I thought I' mention it > anyway given that > many providers out there choose not to enable TCP > regardless of what > 3261 says. >=20 > Cheers, > Emil >=20 >=20 > -- > http://jitsi.org >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 From HKaplan@acmepacket.com Tue Aug 16 13:03:29 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F43F21F8A4E for ; Tue, 16 Aug 2011 13:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUskKigD8L3C for ; Tue, 16 Aug 2011 13:03:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE20921F8A4D for ; Tue, 16 Aug 2011 13:03:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 16 Aug 2011 16:04:15 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 16 Aug 2011 16:04:15 -0400 From: Hadriel Kaplan To: Dan Wing Date: Tue, 16 Aug 2011 16:04:14 -0400 Thread-Topic: [MMUSIC] Media loopback draft and General Need for ICE alternative ? Thread-Index: AcxcT6xp6GeZAsMXR2CSN55hKzO7qg== Message-ID: References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> <003E4F9C-6DF6-4E85-8D39-0C8FE4BB0524@acmepacket.com> <16ef01cc5c40$0c772920$25657b60$@com> In-Reply-To: <16ef01cc5c40$0c772920$25657b60$@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 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Flemming Andreasen , Kaynam Hedayat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:03:29 -0000 On Aug 16, 2011, at 2:12 PM, Dan Wing wrote: >> -----Original Message----- >> From: Hadriel Kaplan >>=20 >> Howdy, >> I object to this change, fwiw. >=20 > There are two changes: (1) removing the loopback-specific NAT traversal, > and (2) the requirement to use ICE. I believe you are objecting to (2), > but you are okay with (1)? Nope - I object to both. :) =20 The current draft already supports using ICE, but doesn't mandate it be use= d.=20 > How about something like: >=20 > "When performing a media loopback, the endpoints MUST use the same=20 > NAT traversal and the same IPv6 transition mechanism employed=20 > by the network for normal call setup (e.g., ICE [RFC5245], > media latching [I-D.ietf-mmusic-media-path-middleboxes])." >=20 > (Yes, I threw IPv6 transition into the mix, because ICE is also > the official IPv6 transition mechanism. ICE isn't just for NAT44.) I'm ok with the sentence, but the draft needs to specify how to "prime the = pump" (i.e., what's in section 5.7 and 8)... since there is no such thing s= pecified elsewhere and media-loopback has the unusual property of being one= -way forever. -hadriel From dwing@cisco.com Tue Aug 16 13:14:31 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2684811E8081 for ; Tue, 16 Aug 2011 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj4ejdHciUiC for ; Tue, 16 Aug 2011 13:14:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4131811E807F for ; Tue, 16 Aug 2011 13:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2204; q=dns/txt; s=iport; t=1313525719; x=1314735319; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=iz2BpQif6qc5NVFEUjOcJh/EbkFzR6zwTW+Vi+Rm3IY=; b=QtR9A33LwdUs+upovfUSp9JTc3XGiRWGSZYe4iPwYFGGSWci/jdP11ma GvobTz2iN1YcmuWu0ur8+JYuZZPOdQXf9kdzudei4tJlSTJ3ZAlxEsj60 hhu8Lnl0bW+o5g58xc6X/8KuHthC7ib2mUrumLEaJMXxaVSUxUviY43vk s=; X-IronPort-AV: E=Sophos;i="4.68,235,1312156800"; d="scan'208";a="13696851" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 16 Aug 2011 20:15:19 +0000 Received: from dwingWS (sjc-vpn2-166.cisco.com [10.21.112.166]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7GKFIV3023213; Tue, 16 Aug 2011 20:15:18 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" References: <4E13A55D.5050100@cisco.com> <1309911822.4148.4.camel@TesterTop4><4E149D0E.2040809@jitsi.org> <4E14C91A.8080204@cisco.com><4E14EAC1.4040203@jitsi.org> <4E15004B.70705@cisco.com><4E1547BC.8030902@jitsi.org> <4E15C791.10600@cisco.com> <4E15DF54.2020504@jitsi.org> <86F9069E07A5EC4E890AF73FD8E85E1777DF2C@spboexc01.exfo.com> <4E3D5968.3070001@cisco.com> <003E4F9C-6DF6-4E85-8D39-0C8FE4BB0524@acmepacket.com> <16ef01cc5c40$0c772920$25657b60$@com> In-Reply-To: Date: Tue, 16 Aug 2011 13:15:18 -0700 Message-ID: <17a501cc5c51$37f214a0$a7d63de0$@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: AcxcT6xp6GeZAsMXR2CSN55hKzO7qgAAO0OA Content-Language: en-us Cc: 'Flemming Andreasen' , 'Kaynam Hedayat' , mmusic@ietf.org Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE alternative ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 16 Aug 2011 20:14:31 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Tuesday, August 16, 2011 1:04 PM > To: Dan Wing > Cc: Flemming Andreasen; Kaynam Hedayat; mmusic@ietf.org > Subject: Re: [MMUSIC] Media loopback draft and General Need for ICE > alternative ? > > > On Aug 16, 2011, at 2:12 PM, Dan Wing wrote: > > >> -----Original Message----- > >> From: Hadriel Kaplan > >> > >> Howdy, > >> I object to this change, fwiw. > > > > There are two changes: (1) removing the loopback-specific NAT > traversal, > > and (2) the requirement to use ICE. I believe you are objecting to > (2), > > but you are okay with (1)? > > Nope - I object to both. :) > The current draft already supports using ICE, but doesn't mandate it be > used. > > > > How about something like: > > > > "When performing a media loopback, the endpoints MUST use the same > > NAT traversal and the same IPv6 transition mechanism employed > > by the network for normal call setup (e.g., ICE [RFC5245], > > media latching [I-D.ietf-mmusic-media-path-middleboxes])." > > > > (Yes, I threw IPv6 transition into the mix, because ICE is also > > the official IPv6 transition mechanism. ICE isn't just for NAT44.) > > I'm ok with the sentence, but the draft needs to specify how to "prime > the pump" (i.e., what's in section 5.7 and 8)... since there is no such > thing specified elsewhere and media-loopback has the unusual property > of being one-way forever. So an additional sentence added to my suggested paragraph above, such as: "If the network is using media latching, the endpoint MUST emit a UDP packet (in order for media latching to work) towards the remote endpoint and it SHOULD send several packets to accommodate packet loss. If the network is using ICE or media latching, the endpoint SHOULD emit packets every 15 seconds to accommodate stateful middleboxes (e.g., NATs) [RFC6263]." would suffice? -d > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Wed Aug 17 02:48:15 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6F421F8ACC for ; Wed, 17 Aug 2011 02:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ELfGflBR23z for ; Wed, 17 Aug 2011 02:48:15 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 207F421F8ACA for ; Wed, 17 Aug 2011 02:48:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9DE639E0F5 for ; Wed, 17 Aug 2011 11:47:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqjBB9NNwwN0 for ; Wed, 17 Aug 2011 11:47:51 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [74.125.118.2]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6FD1639E082 for ; Wed, 17 Aug 2011 11:47:51 +0200 (CEST) Message-ID: <4E4B8E8F.7090201@alvestrand.no> Date: Wed, 17 Aug 2011 11:49:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: MMUSIC WG Content-Type: multipart/alternative; boundary="------------070706000701080508060004" Subject: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 09:48:16 -0000 This is a multi-part message in MIME format. --------------070706000701080508060004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have attempted to synthesize a possible solution to the "multiple media types on one RTP session" problem that was discussed in Quebec City. I feel that it is urgent for RTCWEB to get this issue to a point where we have consensus on where we're going in the short term, so apologies in advance if I seem to be rushing things. Feedback (including on how to process this) is VERY welcome! Harald Alvestrand -------- Original Message -------- Subject: I-D Action: draft-alvestrand-one-rtp-01.txt Date: Wed, 17 Aug 2011 01:48:18 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SDP Grouping for Single RTP Sessions Author(s) : Harald Tveit Alvestrand Filename : draft-alvestrand-one-rtp-01.txt Pages : 12 Date : 2011-08-17 This document describes an extension to the Session Description Protocol (SDP) to describe RTP sessions where media of multiple top level types, for example audio and video, are carried in the same RTP session. This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070706000701080508060004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have attempted to synthesize a possible solution to the "multiple media types on one RTP session" problem that was discussed in Quebec City. I feel that it is urgent for RTCWEB to get this issue to a point where we have consensus on where we're going in the short term, so apologies in advance if I seem to be rushing things.

Feedback (including on how to process this) is VERY welcome!

                    Harald Alvestrand

-------- Original Message --------
Subject: I-D Action: draft-alvestrand-one-rtp-01.txt
Date: Wed, 17 Aug 2011 01:48:18 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : SDP Grouping for Single RTP Sessions
	Author(s)       : Harald Tveit Alvestrand
	Filename        : draft-alvestrand-one-rtp-01.txt
	Pages           : 12
	Date            : 2011-08-17

   This document describes an extension to the Session Description
   Protocol (SDP) to describe RTP sessions where media of multiple top
   level types, for example audio and video, are carried in the same RTP
   session.

   This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for
   consideration.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------070706000701080508060004-- From christer.holmberg@ericsson.com Wed Aug 17 11:06:55 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86001F0C41 for ; Wed, 17 Aug 2011 11:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzI7OObsW3cH for ; Wed, 17 Aug 2011 11:06:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BEA851F0C3F for ; Wed, 17 Aug 2011 11:06:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-49-4e4c03718eba Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AB.C4.02839.1730C4E4; Wed, 17 Aug 2011 20:07:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.242]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 17 Aug 2011 20:07:45 +0200 From: Christer Holmberg To: Harald Alvestrand , MMUSIC WG Date: Wed, 17 Aug 2011 20:07:44 +0200 Thread-Topic: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt Thread-Index: AQHMXQiQgkgIvKAYCUmAvfcoOH+TRw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2011 18:06:55 -0000 Hi Harald, First, I think it is good to indicate that RTCWEB as a WG has made no decis= ion regarding this draft. I have some issues with the draft. Some I have already mentioned in RTCWEB,= but I will repeat them here for the MMUSIC community. Editorial =3D=3D=3D=3D=3D Q: When referring to a m- line, rather than talking about "section", I woul= d suggest to use "media description". SDP offer/answer =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Rejecting a stream ---------------------- The text says: "The answerer cannot refuse the first m=3D section and establish the call. [[NOTE IN DRAFT: This could be relaxed by allowing it when ICE is in use, or saying that the first non-zero port number is used. Both lead to nonobvious edge cases. Is the extra complexity worth it?]]" Q: It must be possible for the answerer to reject a specific stream - inclu= ding the one described in the first media description. Adding/remvoing a stream ------------------------------ Q: I would like to see some text on how adding/removing streams in subseque= nt SDP offer/answers. For example, what if you want to remove the stream as= sociated with the first media descriptor, currently used for the multiplex? Intermediaries =3D=3D=3D=3D=3D=3D=3D=3D=3D Q: Intermediaries that do not understand the extension will assume that med= ia will be sent according to the media descriptions in the SDP offer and an= swer. For example, they might reserve bandwidth (and/or allow codecs) specified for the media = description now used for all streams part of the multiplex. Regards, Christer ________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Harald= Alvestrand [harald@alvestrand.no] Sent: Wednesday, August 17, 2011 12:49 PM To: MMUSIC WG Subject: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-= 01.txt I have attempted to synthesize a possible solution to the "multiple media t= ypes on one RTP session" problem that was discussed in Quebec City. I feel = that it is urgent for RTCWEB to get this issue to a point where we have con= sensus on where we're going in the short term, so apologies in advance if I= seem to be rushing things. Feedback (including on how to process this) is VERY welcome! Harald Alvestrand -------- Original Message -------- Subject: I-D Action: draft-alvestrand-one-rtp-01.txt Date: Wed, 17 Aug 2011 01:48:18 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SDP Grouping for Single RTP Sessions Author(s) : Harald Tveit Alvestrand Filename : draft-alvestrand-one-rtp-01.txt Pages : 12 Date : 2011-08-17 This document describes an extension to the Session Description Protocol (SDP) to describe RTP sessions where media of multiple top level types, for example audio and video, are carried in the same RTP session. This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-one-rtp-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From harald@alvestrand.no Wed Aug 17 22:59:14 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165D221F85E3 for ; Wed, 17 Aug 2011 22:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUQAwvPYzeHJ for ; Wed, 17 Aug 2011 22:59:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2664721F85EE for ; Wed, 17 Aug 2011 22:59:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9E4E39E123; Thu, 18 Aug 2011 07:58:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4iFIgVvlalM; Thu, 18 Aug 2011 07:58:50 +0200 (CEST) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8284239E03C; Thu, 18 Aug 2011 07:58:50 +0200 (CEST) Message-ID: <4E4CAA63.5080904@alvestrand.no> Date: Thu, 18 Aug 2011 08:00:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MMUSIC WG Subject: Re: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 05:59:14 -0000 On 08/17/2011 08:07 PM, Christer Holmberg wrote: > Hi Harald, > > First, I think it is good to indicate that RTCWEB as a WG has made no decision regarding this draft. > > > I have some issues with the draft. Some I have already mentioned in RTCWEB, but I will repeat them here for the MMUSIC community. Thanks for repeating, Christer! As before, I'm happy to hear if you have any suggestions on how to solve these issues. > Editorial > ===== > > Q: When referring to a m- line, rather than talking about "section", I would suggest to use "media description". Will do. Thanks. > > SDP offer/answer > =========== > > Rejecting a stream > ---------------------- > > The text says: > > "The answerer cannot refuse the first m= section and establish the > call. [[NOTE IN DRAFT: This could be relaxed by allowing it when ICE > is in use, or saying that the first non-zero port number is used. > Both lead to nonobvious edge cases. Is the extra complexity worth > it?]]" > > > > Q: It must be possible for the answerer to reject a specific stream - including the one described in the first media description. That's a requirement - can you give a little more background on why you think it's a requirement? And just to verify - for the case when TOGETHER is successfully negotiated - when you say "stream", you mean "all media that uses the payload types listed in that specific media description", right? > Adding/remvoing a stream > ------------------------------ > > Q: I would like to see some text on how adding/removing streams in subsequent SDP offer/answers. For example, what if you want to remove the stream associated with the first media descriptor, currently used for the multiplex? My problem here is that I don't understand what you mean when you say "add/remove stream". We might have different interpretations of the word "stream". In the case where TOGETHER is successfully negotiated, how does this relate to manipulating media descriptions? Can you give a description/example of the scenario you're trying to enable, down to the details of payload types and SSRC numbers? Or a reference to a document describing adding/removing streams when TOGETHER is not used? Happy to talk through this offline if you want. > Intermediaries > > ========= > > > > Q: Intermediaries that do not understand the extension will assume that media will be sent according to the media descriptions in the SDP offer and answer. For example, > > they might reserve bandwidth (and/or allow codecs) specified for the media description now used for all streams part of the multiplex. I added a description part in the draft of this issue, as far as I understand it: B.4. SDP-inspecting intermediaries There may exist intermediaries that inspect, but do not modify, the SDP flow, and take some action based on what they parse there. Such intermediaries are architecturally unsound in general (if they really are needed, they should be explicit participants and be able to refuse to carry the extension they don't understand; if not, their working is of no concern to the callers), but they still exist. In the RTCWEB use case, they may have more problems existing, since the negotiation will normally be carried over encrypted HTTPS connections. In other cases, where negotiation is done in the clear, they may be more common. For figuring out where we are: Are you talking about intermediaries that snoop the SDP flow without being in the flow, or are you talking about intermediaries that are part of the SDP flow? If you talk about intermediaries that snoop the flow, where would you think those would be placed for the RTCWEB use case, given that signalling traffic is likely to be carried over encrypted connections? Harald From christer.holmberg@ericsson.com Thu Aug 18 00:03:02 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A570F11E8094 for ; Thu, 18 Aug 2011 00:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR0hMAayQulH for ; Thu, 18 Aug 2011 00:03:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F12BD11E808C for ; Thu, 18 Aug 2011 00:03:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-ae-4e4cb959f70c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 47.91.02839.959BC4E4; Thu, 18 Aug 2011 09:03:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.242]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 18 Aug 2011 09:03:52 +0200 From: Christer Holmberg To: Harald Alvestrand Date: Thu, 18 Aug 2011 09:03:51 +0200 Thread-Topic: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt Thread-Index: AcxdbBO0mKXddRTlRPaEUnd1FUSr9AABOHGg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852232E98692@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@ESESSCMS0356.eemea.ericsson.se> <4E4CAA63.5080904@alvestrand.no> In-Reply-To: <4E4CAA63.5080904@alvestrand.no> 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== Cc: MMUSIC WG Subject: Re: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 07:03:02 -0000 Hi Harald,=20 >>I have some issues with the draft. Some I have already=20 >>mentioned in RTCWEB, but I will repeat them here for the=20 >>MMUSIC community. >>Thanks for repeating, Christer! >As before, I'm happy to hear if you have any suggestions on=20 >how to solve these issues. I have been thinking about a different solution. But, there are also some i= ssues with such approach. >>SDP offer/answer >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Rejecting a stream >>---------------------- >> >>The text says: >> >> "The answerer cannot refuse the first m=3D section and=20 >> establish the call. [[NOTE IN DRAFT: This could be relaxed by=20 >> allowing it when ICE is in use, or saying that the first non-zero po= rt=20 >> number is used. Both lead to nonobvious edge cases. Is the extra=20 >> complexity worth it?]]" >> >> >> >>Q: It must be possible for the answerer to reject a=20 >>specific stream - including the one described in the first=20 >>media description. >That's a requirement - can you give a little more background=20 >on why you think it's a requirement? It wasn't a suggested requirement, but rather a comment on your text. >And just to verify - for the case when TOGETHER is=20 >successfully negotiated - when you say "stream", you mean=20 >"all media that uses the payload types listed in that=20 >specific media description", right? When I talk about "stream", I refer to an individual media type, e.g. audio= or video. Whether they are sent as individual media streams, or as part of= a multiplex, is not relevant. But, maybe I should talk about "media type" instead? But, to clarify my issue: If the first media descriptor (m- line) describes audio, and I don't want t= hat audio (again, no matter whether sent as an individual stream, or as par= t of a multiplex) I should have the possibility to reject that audio.=20 In my opinoin entities need to be able to explicitly negotiate what media w= ill be sent - even in a multiplex. >>Adding/remvoing a stream >>------------------------------ >> >>Q: I would like to see some text on how adding/removing=20 >>streams in subsequent SDP offer/answers. For example, what if=20 >>you want to remove the stream associated with the first media=20 >>descriptor, currently used for the multiplex? >>My problem here is that I don't understand what you mean when=20 >>you say "add/remove stream". We might have different=20 >>interpretations of the word "stream". >=20 >In the case where TOGETHER is successfully negotiated, how=20 >does this relate to manipulating media descriptions? >Can you give a description/example of the scenario you're=20 >trying to enable, down to the details of payload types and=20 >SSRC numbers? >Or a reference to a document describing adding/removing=20 >streams when TOGETHER is not used? >=20 >Happy to talk through this offline if you want. When the session is established, I SOMEHOW negotiate a multiplex stream tha= t contains audio from my microphone and a video from my front camera. Later, I want to negotiate the removal of the video. Using "normal" SDP, I = would send an offer where I put the port number of the media descriptor ass= ociated with the video stream to zero. You seem to suggest, that once the multiplex has been negotiated, entities = can send whatever within it, and there is no need to negotiate when differe= nt types of media are addedd/removed. Or? >>Intermediaries >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >>Q: Intermediaries that do not understand the extension will assume=20 >>that media will be sent according to the media descriptions=20 >>in the SDP offer and answer. For example, >> >>they might reserve bandwidth (and/or allow codecs)=20 >>specified for the media description now used for all streams=20 >>part of the multiplex. >I added a description part in the draft of this issue, as far=20 >as I understand it: >=20 >B.4. SDP-inspecting intermediaries >=20 > There may exist intermediaries that inspect, but do not=20 > modify, the SDP flow, and take some action based on what=20 > they parse there. >=20 > Such intermediaries are architecturally unsound in=20 > general (if they really are needed, they should be explicit=20 > participants and be able to refuse to carry the extension they=20 > don't understand; if not, their working is of no concern to the=20 > callers), but they still exist. It would be so simple if we in IETF could dictate exactly how the intermedi= aries behave :) > In the RTCWEB use case, they may have more problems=20 > existing, since the negotiation will normally be carried over=20 > encrypted HTTPS connections. In other cases, where negotiation is=20 > done in the clear, they may be more common. Sure. But, security is a separate issue. >For figuring out where we are: Are you talking about=20 >intermediaries that snoop the SDP flow without being in the=20 >flow, or are you talking about intermediaries that are part=20 >of the SDP flow? I am talking about intermediaries that will anchor the media flow, and will= reserve resources etc based on the SDP. >If you talk about intermediaries that snoop the flow, where=20 >would you think those would be placed for the RTCWEB use=20 >case, given that signalling traffic is likely to be carried=20 >over encrypted connections? I don't know yet. Maybe there will be no intermediary between the browser a= nd the webserver/legacy GW, but there could be between webservers. And, eve= n if whatever happens there is outside the scope of RTCWEB, we need to keep= in mind that the SIP/SDP signalling extensions etc we define might be used= there. However, keep in mind that CLUE most likely will also be interested in a so= lution to negotiate a multiplex. And, CLUE entities will be located in "leg= acy" networks where these kind of entities do exist. Many also want to be able to participate in video conferences using a brows= er, and I think it would be good if there was a common system for negotiati= ong the usage of multiplex. Regards, Christer From miguel.a.garcia@ericsson.com Thu Aug 18 06:03:18 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133D921F8A95 for ; Thu, 18 Aug 2011 06:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIUOIG28VSnD for ; Thu, 18 Aug 2011 06:03:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6221F8A7E for ; Thu, 18 Aug 2011 06:03:16 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-50-4e4d0dc9edde Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.04.20773.9CD0D4E4; Thu, 18 Aug 2011 15:04:10 +0200 (CEST) To: undisclosed-recipients:; Received: from [159.107.24.158] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 18 Aug 2011 15:04:09 +0200 Message-ID: <4E4D0DC8.5030903@ericsson.com> Date: Thu, 18 Aug 2011 15:04:08 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 References: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B6D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB6558B6D@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic , Christer Holmberg Subject: Re: [MMUSIC] SDP comments on draft-singh-avtcore-mprtp-02: General - Connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 13:03:18 -0000 As an individual... Some comments to the connectivity checks of this draft. I basically agree with Christer. I find confusing several concepts that are highly mixed in the draft, namely: a) Whether ICE is mandatory or not b) The presence of two mechanisms for doing connectivity checks: ICE and the RTP built-in c) It seems to be mandated to do connectivity checks prior to using the MPRTP. This is something that currently is not mandated (unless you implement ICE). But if you implement vanilla RTP, you don't need to test the connectivity before you send or receive data. So, the recommendation to the authors is to avoid mandating connectivity tests, but having as an option. Use clear terminology: "STUN connectivity tests" versus "built-in RTP connectivity tests". This, of course, assuming that you still want to support both types of connectivity test, something that is arguable. /Miguel On 03/08/2011 22:54, Christer Holmberg wrote: > Hi, > > Below are some general comments on the connectivity checks. More specific comments will be found in my e-mails commending the individual sections. > > Regards, > > Christer > > > Connectivity checks: > > FU_GEN-1: The document defines a new type of connectivity check. We should have a > discussion whether that's a good thing to do or not, but assuming it will be done, > as I also indicate in my editorial comments, you need to more clearly define the "RTCP > connectivity checks" somewhere in the document, and then refer to it. > > I think you also need to describe the characteristic differences (security etc) > compared to STUN connectivity checks, and I think you should have some text on why > you define a new type of connectivity check in the first place (rather than relying on > STUN). > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu Aug 18 06:20:14 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06BA21F8AFE; Thu, 18 Aug 2011 06:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fpNYg5kNq3o; Thu, 18 Aug 2011 06:20:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D740921F8AAC; Thu, 18 Aug 2011 06:20:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-77-4e4d11c36fb0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.76.20773.3C11D4E4; Thu, 18 Aug 2011 15:21:07 +0200 (CEST) Received: from [159.107.24.158] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 18 Aug 2011 15:21:07 +0200 Message-ID: <4E4D11C2.2030104@ericsson.com> Date: Thu, 18 Aug 2011 15:21:06 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Varun Singh , avt@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic Subject: [MMUSIC] SDP comments on draft-signh-avtcore-mprtp-02: Scope of the document X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 13:20:15 -0000 I have a general comment on the scope of the draft-signh-avtcore-mprtp-02. I think the document needs to provide a neat cut on scope. At the moment I think that the intention of the authors is to include RTP and SDP as part of the scope, and presumably ICE. Fair enough. Then, it is not acceptable to find normative statements outside the scope of the document, for example, those pertaining to SIP and RTSP, or even legacy implementations. Let me provide you examples: - Section 4.1 Session signaling (e.g., SIP [14], RTSP [15]) SHOULD be done over a failover-capable or multipath-capable transport for e.g., SCTP [10] or MPTCP [11] instead of TCP or UDP. Comment: The scope of the document should not consider SIP, RTSP, and whether it is used over a failover-capable or multipath-capable transport. This could be described in other drafts, and actually RFC 4168 already describes how to use SIP over SCTP. - Section 6, 5th bullet point: [Open Issue: What happens if the interface that setup the session disappears? does the control channel also failover? re-start the session?] Same comment, not in the scope of the draft. - Section 7.5 [Note: If the original interface that setup the session disappears then does the session signaling failover to another interface? Can we recommend that SIP/RTSP be run over MPTCP, SCTP]. - Section 11.2: To signal the use of MPRTP header extensions in SDP, the following URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp. Legacy RTP (non- MPRTP) clients MUST ignore this header extension, but continue to parse and decode the packet. Comment: The second sentence puts a requirement ("MUST ignore") to legacy clients. How do you intend legacy clients to implement a requirement which has been written in the future (your document was written after the legacy client was put into operation). You can say that "it is expected that legacy RTP clients will ignore this header extension ....", but it is merely an expectation, not a requirement. - Section 11.3, 1st bullet point: 1. Advertising ICE candidates: in the initial INVITE the endpoints exchange candidates, as defined in ICE [3]. Comment: replace "INVITE" "SDP offer", and then you are back within the scope of the document. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From randell-ietf@jesup.org Thu Aug 18 06:50:11 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C86121F8B2A for ; Thu, 18 Aug 2011 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG-6-gaNUYrl for ; Thu, 18 Aug 2011 06:50:11 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id A0DFB21F86D0 for ; Thu, 18 Aug 2011 06:50:10 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qu2zw-0008Mh-8h for mmusic@ietf.org; Thu, 18 Aug 2011 08:51:04 -0500 Message-ID: <4E4D1847.3050800@jesup.org> Date: Thu, 18 Aug 2011 09:48:55 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@ESESSCMS0356.eemea.ericsson.se> <4E4CAA63.5080904@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852232E98692@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852232E98692@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 13:50:11 -0000 On 8/18/2011 3:03 AM, Christer Holmberg wrote: > > >>> SDP offer/answer >>> ================ >>> >>> Rejecting a stream >>> ---------------------- >>> >>> The text says: >>> >>> "The answerer cannot refuse the first m= section and >>> establish the call. [[NOTE IN DRAFT: This could be relaxed by >>> allowing it when ICE is in use, or saying that the first non-zero port >>> number is used. Both lead to nonobvious edge cases. Is the extra >>> complexity worth it?]]" >>> >>> >>> >>> Q: It must be possible for the answerer to reject a >>> specific stream - including the one described in the first >>> media description. >> That's a requirement - can you give a little more background >> on why you think it's a requirement? > > It wasn't a suggested requirement, but rather a comment on your text. > >> And just to verify - for the case when TOGETHER is >> successfully negotiated - when you say "stream", you mean >> "all media that uses the payload types listed in that >> specific media description", right? > > > When I talk about "stream", I refer to an individual media type, e.g. audio or video. Whether they are sent as individual media streams, or as part of a multiplex, is not relevant. > > But, maybe I should talk about "media type" instead? > > > But, to clarify my issue: > > If the first media descriptor (m- line) describes audio, and I don't want that audio (again, no matter whether sent as an individual stream, or as part of a multiplex) I should have the possibility to reject that audio. > > In my opinoin entities need to be able to explicitly negotiate what media will be sent - even in a multiplex. Agreed - there are all sorts of reservations (and UI implications) attached to knowing if video will be part of the session. The UI typically would be different for an audio-only connection. And for VRS and other hearing-impaired calls, they may not want to use audio (and there are other instances where audio would not be the default, and would only be added later if wanted). Now, for other reasons we may not want to reject the m= line with port=0, but instead include an attribute marking it as not to be used (a=rejected). Or can we use inactive here? That might confuse things if a=inactive caused a midbox/TURN/etc to not expect any traffic. If we allow it to be rejected it can be re-added later by a new offer-answer pair, as normal. This is also how adding "sessions" (or changing codecs, codec params, etc beyond the agreed to set) should happen later. >>> Adding/remvoing a stream >>> ------------------------------ >>> >>> Q: I would like to see some text on how adding/removing >>> streams in subsequent SDP offer/answers. For example, what if >>> you want to remove the stream associated with the first media >>> descriptor, currently used for the multiplex? >>> My problem here is that I don't understand what you mean when >>> you say "add/remove stream". We might have different >>> interpretations of the word "stream". >> >> In the case where TOGETHER is successfully negotiated, how >> does this relate to manipulating media descriptions? >> Can you give a description/example of the scenario you're >> trying to enable, down to the details of payload types and >> SSRC numbers? >> Or a reference to a document describing adding/removing >> streams when TOGETHER is not used? >> >> Happy to talk through this offline if you want. > > When the session is established, I SOMEHOW negotiate a multiplex stream that contains audio from my microphone and a video from my front camera. > > Later, I want to negotiate the removal of the video. Using "normal" SDP, I would send an offer where I put the port number of the media descriptor associated with the video stream to zero. > > You seem to suggest, that once the multiplex has been negotiated, entities can send whatever within it, and there is no need to negotiate when different types of media are addedd/removed. Or? Well, you don't *have* to send anything - but without renegotiation of some sort it's hard to stop the other person from burning bandwidth sending to you. And it's bad to leave them thinking you're seeing something you're not (usually). Starting/stopping your camera (Mute) doesn't need negotiation; and adding another camera stream (if it has compatible codec/etc specs) doesn't require negotiation (and conversely, having the other end (or conference) add another stream doesn't normally need negotiation given this approach. (Note that I have issues with wanting to be to say to an incoming connection "enough!" and stop it from sending me more streams and wasting bandwidth on what I won't see (and hurting what I will).) -- Randell Jesup randell-ietf@jesup.org From christer.holmberg@ericsson.com Thu Aug 18 09:36:56 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA83D21F8BB1 for ; Thu, 18 Aug 2011 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k0Jj2mxGwE1 for ; Thu, 18 Aug 2011 09:36:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5A621F8BAE for ; Thu, 18 Aug 2011 09:36:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-85-4e4d3fdc5ecb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.E1.02839.CDF3D4E4; Thu, 18 Aug 2011 18:37:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.242]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 18 Aug 2011 18:37:48 +0200 From: Christer Holmberg To: Randell Jesup , "mmusic@ietf.org" Date: Thu, 18 Aug 2011 18:37:47 +0200 Thread-Topic: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt Thread-Index: AcxdreLAklq3frXmS2e1ALB5VrSHMQAFgkFQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACE2@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@ESESSCMS0356.eemea.ericsson.se> <4E4CAA63.5080904@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852232E98692@ESESSCMS0356.eemea.ericsson.se>, <4E4D1847.3050800@jesup.org> In-Reply-To: <4E4D1847.3050800@jesup.org> 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] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 16:36:56 -0000 Hi Randell, >>>> SDP offer/answer >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> Rejecting a stream >>>> ---------------------- >>>> >>>> The text says: >>>> >>>> "The answerer cannot refuse the first m=3D section and >>>> establish the call. [[NOTE IN DRAFT: This could be relaxed by >>>> allowing it when ICE is in use, or saying that the first non-zero= port >>>> number is used. Both lead to nonobvious edge cases. Is the extra >>>> complexity worth it?]]" >>>> >>>> >>>> >>>> Q: It must be possible for the answerer to reject a >>>> specific stream - including the one described in the first >>>> media description. >>> That's a requirement - can you give a little more background >>> on why you think it's a requirement? >> >> It wasn't a suggested requirement, but rather a comment on your text. >> >>> And just to verify - for the case when TOGETHER is >>> successfully negotiated - when you say "stream", you mean >>> "all media that uses the payload types listed in that >>> specific media description", right? >> >> >> When I talk about "stream", I refer to an individual media type, e.g. au= dio or video. Whether they are sent as individual media streams, or as part= of a multiplex, is not relevant. >> >> But, maybe I should talk about "media type" instead? >> >> >> But, to clarify my issue: >> >> If the first media descriptor (m- line) describes audio, and I don't wan= t that audio (again, no matter whether sent as an individual stream, or as = part of a multiplex) I should have the possibility to reject that audio. >> >> In my opinoin entities need to be able to explicitly negotiate what medi= a will be sent - even in a multiplex. > >Agreed - there are all sorts of reservations (and UI implications) attache= d to knowing >if video will be part of the session. The UI typically would be different= for an >audio-only connection. And for VRS and other hearing-impaired calls, they= may not >want to use audio (and there are other instances where audio would not be = the default, >and would only be added later if wanted). Correct.=20 >Now, for other reasons we may not want to reject the m=3D line with port= =3D0, but instead >include an attribute marking it as not to be used (a=3Drejected). Or can= we use >inactive here? That might confuse things if a=3Dinactive caused a midbox/= TURN/etc >to not expect any traffic. "Inactive" will still maintain the RTCP traffic. But, sure, there may be cases where you want to use something else than por= t=3D0. But, I think those cases should be the same no matter if you use mul= tiplex or not. >If we allow it to be rejected it can be re-added later by a new offer-answ= er pair, >as normal. This is also how adding "sessions" (or changing codecs, codec = params, >etc beyond the agreed to set) should happen later. Correct. But, again that is normal offer/answer behavior. >>>> Adding/remvoing a stream >>>> ------------------------------ >>>> >>>> Q: I would like to see some text on how adding/removing >>>> streams in subsequent SDP offer/answers. For example, what if >>>> you want to remove the stream associated with the first media >>>> descriptor, currently used for the multiplex? >>>> My problem here is that I don't understand what you mean when >>>> you say "add/remove stream". We might have different >>>> interpretations of the word "stream". >>>> >>> In the case where TOGETHER is successfully negotiated, how >>> does this relate to manipulating media descriptions? >>> Can you give a description/example of the scenario you're >>> trying to enable, down to the details of payload types and >>> SSRC numbers? >>> Or a reference to a document describing adding/removing >>> streams when TOGETHER is not used? >>> >>> Happy to talk through this offline if you want. >> >>When the session is established, I SOMEHOW negotiate a multiplex stream t= hat contains audio from my microphone and a video from my front camera. >> >>Later, I want to negotiate the removal of the video. Using "normal" SDP, = I would send an offer where I put the port number of the media descriptor a= ssociated with the video stream to zero. >> >>You seem to suggest, that once the multiplex has been negotiated, entitie= s can send whatever within it, and there is no need to negotiate when diffe= rent types of media are addedd/removed. Or? > >Well, you don't *have* to send anything - but without renegotiation of som= e sort >it's hard to stop the other person from burning bandwidth sending to you. = And it's >bad to leave them thinking you're seeing something you're not (usually). > >Starting/stopping your camera (Mute) doesn't need negotiation; and adding = another >camera stream (if it has compatible codec/etc specs) doesn't require negot= iation (and >conversely, having the other end (or conference) add another stream doesn'= t normally >need negotiation given this approach. (Note that I have issues with wanti= ng to be >to say to an incoming connection "enough!" and stop it from sending me mor= e streams >and wasting bandwidth on what I won't see (and hurting what I will).) Sure, there may be moments where you don't send anything (in case of "mute"= etc). But, my point was that when you do something, it should be something that y= ou have explicitly negotiated to send. Regards, Christer= From thomas.belling@nsn.com Thu Aug 18 10:47:15 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC38E11E80A1 for ; Thu, 18 Aug 2011 10:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1+tIcEGU6wt for ; Thu, 18 Aug 2011 10:47:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C354721F85B5 for ; Thu, 18 Aug 2011 10:47:13 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p7IHm6O0013482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 19:48:06 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7IHm5Fu023321; Thu, 18 Aug 2011 19:48:06 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 19:48:05 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5DCE.FBE3AB54" Date: Thu, 18 Aug 2011 19:48:04 +0200 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F6424EE@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-mmusic-sdp-media-capabilities] How to encode unknown format list? Thread-Index: AcxdztpvylxYYK31SAi7lhK5o4JiVA== From: "Belling, Thomas (NSN - DE/Munich)" To: "mmusic" X-OriginalArrivalTime: 18 Aug 2011 17:48:05.0855 (UTC) FILETIME=[FBF2EEF0:01CC5DCE] Subject: [MMUSIC] [draft-ietf-mmusic-sdp-media-capabilities] How to encode unknown format list? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 18 Aug 2011 17:47:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5DCE.FBE3AB54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all I would be grateful if you could help to clarify the following question, which relates to ongoing discussions in 3GPP: We need to express in a potential configuration that we do not know the used codecs. (this can occur e.g. in combination with draft-ietf-mmusic-sdp-cs) draft-ietf-mmusic-sdp-media-capabilities-11 contains the following: 3.3.4.2. The Payload Type Number Mapping Parameter (pt=3D) ... The "*" value for payload-type-number is used in cases such as BFCP [RFC4583] in which the fmt list in the m-line is ignored. To be syntactically correct, "pt=3D" requires a media-map-list, and = thus at least one numerical media-cap-num. However, a couple of related questions pop up: a. Would a "m=3D" with the same media-cap-num also be required in the potential configuration? b. Would a "a=3Dmcap" attribute with the same media-cap-num also be required in the SDP? c. Would it be also allowed to simply omit "pt=3D" in a potential configuration? In other words, which of the examples below are correct? 1. a=3Dmcap:1 -/- a=3Dtcap:1 PSTN a=3Dccap:1 PSTN E164 +12125556666 a=3Dpcfg:1 t=3D1 m=3D1 c=3D1 2. a=3Dmcap:1 -/- a=3Dtcap:1 PSTN a=3Dccap:1 PSTN E164 +12125556666 a=3Dpcfg:1 t=3D1 m=3D1 c=3D1 pt=3D1:* 3. a=3Dtcap:1 PSTN a=3Dccap:1 PSTN E164 +12125556666 a=3Dpcfg:1 t=3D1 m=3D1 c=3D1 pt=3D1:* 4. a=3Dtcap:1 PSTN a=3Dccap:1 PSTN E164 +12125556666 a=3Dpcfg:1 t=3D1 c=3D1 pt=3D1:* Perhaps it might even be worth to add some clarifying words to the quoted sentence above within the draft? Many thanks in advance, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation=20 Nokia Siemens Networks =20 ------_=_NextPart_001_01CC5DCE.FBE3AB54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [draft-ietf-mmusic-sdp-media-capabilities] How to encode unknown = format list?

Dear = all

I would be grateful if = you could help to clarify the following question, = which relates to ongoing discussions in = 3GPP:

We need to = express in a potential = configuration  = that we do not know the used codecs.

(this can = occur e.g.  in combination = with draft-ietf-mmusic-sdp-cs)

draft-ietf-mmusic-sdp-media-capabilities-11 = contains the following:

3.3.4.2.  The Payload Type Number Mapping = Parameter (pt=3D)

…

   The "*" value for = payload-type-number is used in cases such as BFCP

   = [RFC4583] in which the fmt list in the m-line is = ignored.

To = be syntactically = correct,  “pt=3D” requires = a media-map-list, and = thus at least one numerical media-cap-num.

However, a = couple of related questions pop up:

a.      Would a “m=3D” with the same media-cap-num also be required in the potential = configuration?

b.      Would a “a=3Dmcap" = attribute with the = same media-cap-num also be required in the = SDP?

c.      Would it be also allowed to = simply omit “pt=3D” in a potential = configuration?

In = other words, which of the examples below = are correct?

1.

a=3Dmcap:1 -/-

a=3Dtcap:1 PSTN

a=3Dccap:1 PSTN E164 = +12125556666

a=3Dpcfg:1 t=3D1 = m=3D1 c=3D1

2.

a=3Dmcap:1 -/-

a=3Dtcap:1 PSTN

a=3Dccap:1 PSTN E164 = +12125556666

a=3Dpcfg:1 t=3D1 = m=3D1 c=3D1 = pt=3D1:*

3.

a=3Dtcap:1 PSTN

a=3Dccap:1 PSTN E164 = +12125556666

a=3Dpcfg:1 t=3D1 = m=3D1 c=3D1 pt=3D1:*

4.

a=3Dtcap:1 PSTN

a=3Dccap:1 PSTN E164 = +12125556666

a=3Dpcfg:1 t=3D1 c=3D1 pt=3D1:*

Perhaps it = might even be worth to add some clarifying words to the quoted sentence = above within the draft?


Many thanks = in advance, Thomas

----------------------------------
Dr. Thomas Belling
3GPP Standardisation
Nokia Siemens = Networks  

------_=_NextPart_001_01CC5DCE.FBE3AB54-- From miguel.a.garcia@ericsson.com Fri Aug 19 03:05:36 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02C21F876A; Fri, 19 Aug 2011 03:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g2fsAJqW9sl; Fri, 19 Aug 2011 03:05:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7675121F8783; Fri, 19 Aug 2011 03:05:35 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-16-4e4e35a78609 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 95.E4.20773.7A53E4E4; Fri, 19 Aug 2011 12:06:31 +0200 (CEST) Received: from [159.107.24.201] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 19 Aug 2011 12:06:30 +0200 Message-ID: <4E4E35A5.40104@ericsson.com> Date: Fri, 19 Aug 2011 12:06:29 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Varun Singh Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: mmusic , avt@ietf.org Subject: [MMUSIC] Comments to draft-singh-avtcore-mprtp-02: A bunch of comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 19 Aug 2011 10:05:36 -0000 Here is a bunch of comments to the MPRTP draft. - In several sections (take for example the second paragraph in the Introduction), the text talks of packets that are "transmitted over different paths". I think we need to differentiate the use case that you are considering from the use case when two packets with the same origin and end travel through different paths in the network, due to, e.g., congestion of intermediate routers. So, I guess you need to clarify that you are not addressing that use case, but instead, one where at least one of the endpoints has multiple interfaces at its disposal. Furthermore, these multiple interfaces at an endpoint should also have different IP addresses among them. - In the third paragraph of the introduction you mention that SCTP, MPTCP and SHIM6 are not suitable for realtime communications. I wouldn't dare to write such statement, perhaps you don't want to hurt someone else's sensitivity. - Section 1.2 reads: Endpoint: host either initiating or terminating an RTP connection. I don't know what is an RTP "connection". Perhaps "flow", or "session". - Section 1.3 reads: o Load balancing: Transmitting one RTP stream over multiple paths can reduce the bandwidth usage, compared to transmitting the same stream along a single path. This reduces the impact on other traffic. Question: why is it so that transmitting the same flow over several paths reduces the bandwidth usage? I guess that the aggregated bandwidth wouldn't change when you use several paths. - Section 7.1. When you mention "RTP/RTCP header extension" you should add a reference to where such extension is defined, I guess Sections 9.1 and 9.2 in your same draft. The same applies to the second paragraph in Section 7 .2 - Confusing text in Section 8: To enable a quick start of a multimedia session, a multipath session MUST be upgraded from a single path session. The text gives me the impression that something will break if one does not upgrade to a multipath from a single path session. The problem is how the "MUST" is interpreted. I guess what you want to say is: If an endpoint wants to enable a quick start of a multimedia session, it will first start a single path session and will then upgrade it to a multipath session. - Section 8.1.3, first paragraph, reads: The sender MAY open any number of subflows from the set of candidate subflows after performing connectivity checks. What is "open"? Do we open flows? In particular, I don't know if you are referring to "publish the SDP", "is ready to receive RTP", or "starts sending RTP". Please clarify it. - Section 9.1, third paragraph reads: To signal the use of the above RTP header extensions in SDP, the following URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp. I believe the above text is written in the wrong section. Section 9.1 is about the RTP header extension for MPRTP, not about SDP. Additionally, you have the same sentences correctly included in the SDP section, therefore, you can safely delete the above misplaced paragraph in 9.1. - Section 9.3.1 reads: Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) The address to which receivers send feedback reports. For IPv4 and IPv6, fixed-length address fields are used. A DNS name is an arbitrary-length string. The string MAY contain Internationalizing Domain Names in Applications (IDNA) domain names and MUST be UTF-8 [8] encoded. I don't know how IPv4 and IPv6 addresses are encoded. One could use its binary representation per octet, or its UTF-8 encoding of the string (e.g., including the dots, colons, etc.). Please clearly specify how this is done. - Section 11.2 has normative text to use ("MUST use") a URN. But without normatively specifying how to use, e.g., in which line, attribute, to include it, the normative strength is useless. - Section 11.3.1 says: : is taken from RFC5245 [3]. This is not true. RFC 5245 does not define unicast-address. RFC 5245 reuses from RFC 4566, which also includes multicast-address. I guess you need to point to RFC 4566, which is the canonical source of unicast-address for this purpose. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From internet-drafts@ietf.org Mon Aug 22 02:41:30 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5421F8AFF; Mon, 22 Aug 2011 02:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVtsh2of71Vd; Mon, 22 Aug 2011 02:41:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF92721F87D9; Mon, 22 Aug 2011 02:41:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110822094129.5747.49764.idtracker@ietfa.amsl.com> Date: Mon, 22 Aug 2011 02:41:29 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2011 09:41:30 -0000 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= 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 Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-07.txt Pages : 26 Date : 2011-08-22 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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-07.txt From Simo.Veikkolainen@nokia.com Mon Aug 22 04:11:13 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506CF21F8A51 for ; Mon, 22 Aug 2011 04:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuyDiAYQtyWi for ; Mon, 22 Aug 2011 04:11:12 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4909421F8A4F for ; Mon, 22 Aug 2011 04:11:11 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7MBC4Qs011586; Mon, 22 Aug 2011 14:12:13 +0300 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); Mon, 22 Aug 2011 14:12:10 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 22 Aug 2011 13:12:10 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.182]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Mon, 22 Aug 2011 13:12:10 +0200 From: To: Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-cs-07.txt Thread-Index: AQHMYK/hQf/AGrmmtU2Gt7TdU68tO5Uottlw Date: Mon, 22 Aug 2011 11:12:10 +0000 Message-ID: References: <20110822094129.5747.49764.idtracker@ietfa.amsl.com> In-Reply-To: <20110822094129.5747.49764.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: NgLgUAGhIMVcmkVcu9QCAzv+Bz/SDrcr/xSr2jrzza9g21NPZJkwj0rJbeCn4+LF60Z/biesy6v+xCDxpoG+l32IoyHZ61PQgVhe05q+ZoASJN9GuELyr+7FP+eHCvGHW5kimfNh4azxB0d4NddJxMcg4QhUSh6K1gjC10agE1O7K10ZbY5Css76F4awe8mKqaPCT2XyBpMov3WTA82HpBWjZ1MQuEwAILKMmbUIElT1jadEwL9PsBkLr1IT29KZ x-originating-ip: [88.114.28.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2011 11:12:10.0714 (UTC) FILETIME=[566F13A0:01CC60BC] X-Nokia-AV: Clean Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2011 11:11:13 -0000 Hello, We've submitted a new version of the draft to prevent expiration. Stay tune= d for another update within a couple of days which will address Paul Kyziva= t's and Flemming's comments. 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: 22 August, 2011 12:41 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: I-D Action: draft-ietf-mmusic-sdp-cs-07.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= 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 Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-07.txt Pages : 26 Date : 2011-08-22 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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-07.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From harald@alvestrand.no Wed Aug 24 07:49:30 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7445621F8B8A for ; Wed, 24 Aug 2011 07:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.684 X-Spam-Level: X-Spam-Status: No, score=-106.684 tagged_above=-999 required=5 tests=[AWL=3.915, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JXnzDvT3QrU for ; Wed, 24 Aug 2011 07:49:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5421F8B6B for ; Wed, 24 Aug 2011 07:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC12B39E178; Wed, 24 Aug 2011 16:49:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4WJGj6BXkwX; Wed, 24 Aug 2011 16:49:23 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 31BDC39E0FC; Wed, 24 Aug 2011 16:49:23 +0200 (CEST) Message-ID: <4E550FBD.3080700@alvestrand.no> Date: Wed, 24 Aug 2011 16:50:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852232F3ACD5@ESESSCMS0356.eemea.ericsson.se> <4E4CAA63.5080904@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852232E98692@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852232E98692@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MMUSIC WG Subject: Re: [MMUSIC] Request for review: I-D Action: draft-alvestrand-one-rtp-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2011 14:49:30 -0000 On 08/18/11 09:03, Christer Holmberg wrote: > Hi Harald, > >>> I have some issues with the draft. Some I have already >>> mentioned in RTCWEB, but I will repeat them here for the >>> MMUSIC community. >>> Thanks for repeating, Christer! >> As before, I'm happy to hear if you have any suggestions on >> how to solve these issues. > I have been thinking about a different solution. But, there are also some issues with such approach. > > >>> SDP offer/answer >>> ================ >>> >>> Rejecting a stream >>> ---------------------- >>> >>> The text says: >>> >>> "The answerer cannot refuse the first m= section and >>> establish the call. [[NOTE IN DRAFT: This could be relaxed by >>> allowing it when ICE is in use, or saying that the first non-zero port >>> number is used. Both lead to nonobvious edge cases. Is the extra >>> complexity worth it?]]" >>> >>> >>> >>> Q: It must be possible for the answerer to reject a >>> specific stream - including the one described in the first >>> media description. >> That's a requirement - can you give a little more background >> on why you think it's a requirement? > It wasn't a suggested requirement, but rather a comment on your text. > >> And just to verify - for the case when TOGETHER is >> successfully negotiated - when you say "stream", you mean >> "all media that uses the payload types listed in that >> specific media description", right? > > When I talk about "stream", I refer to an individual media type, e.g. audio or video. Whether they are sent as individual media streams, or as part of a multiplex, is not relevant. > > But, maybe I should talk about "media type" instead? > > > But, to clarify my issue: > > If the first media descriptor (m- line) describes audio, and I don't want that audio (again, no matter whether sent as an individual stream, or as part of a multiplex) I should have the possibility to reject that audio. > > In my opinoin entities need to be able to explicitly negotiate what media will be sent - even in a multiplex. I think that in the larger context, they should be able to negotiate what streams are sent, even when those streams have the same data type and travel on the same RTP session - I should be able to shut off a stream I do not want. But SDP doesn't offer that functionality. I'm trying to work out where to do the tradeoff here - do we continue to preserve the functionality that SDP currently does partway, or do we give up at the SDP layer and claim that it has to be done elsewhere? > >>> Adding/remvoing a stream >>> ------------------------------ >>> >>> Q: I would like to see some text on how adding/removing >>> streams in subsequent SDP offer/answers. For example, what if >>> you want to remove the stream associated with the first media >>> descriptor, currently used for the multiplex? >>> My problem here is that I don't understand what you mean when >>> you say "add/remove stream". We might have different >>> interpretations of the word "stream". >> In the case where TOGETHER is successfully negotiated, how >> does this relate to manipulating media descriptions? >> Can you give a description/example of the scenario you're >> trying to enable, down to the details of payload types and >> SSRC numbers? >> Or a reference to a document describing adding/removing >> streams when TOGETHER is not used? >> >> Happy to talk through this offline if you want. > When the session is established, I SOMEHOW negotiate a multiplex stream that contains audio from my microphone and a video from my front camera. > > Later, I want to negotiate the removal of the video. Using "normal" SDP, I would send an offer where I put the port number of the media descriptor associated with the video stream to zero. > > You seem to suggest, that once the multiplex has been negotiated, entities can send whatever within it, and there is no need to negotiate when different types of media are addedd/removed. Or? That's exactly right, as long as the payload types are within the negotiated payload types for the combined stream. > > >>> Intermediaries >>> ============== >>> >>> >>> >>> Q: Intermediaries that do not understand the extension will assume >>> that media will be sent according to the media descriptions >>> in the SDP offer and answer. For example, >>> >>> they might reserve bandwidth (and/or allow codecs) >>> specified for the media description now used for all streams >>> part of the multiplex. >> I added a description part in the draft of this issue, as far >> as I understand it: >> >> B.4. SDP-inspecting intermediaries >> >> There may exist intermediaries that inspect, but do not >> modify, the SDP flow, and take some action based on what >> they parse there. >> >> Such intermediaries are architecturally unsound in >> general (if they really are needed, they should be explicit >> participants and be able to refuse to carry the extension they >> don't understand; if not, their working is of no concern to the >> callers), but they still exist. > It would be so simple if we in IETF could dictate exactly how the intermediaries behave :) Yes, wouldn't it? :-) in this case, I think what we can do is to flag that "these intermediaries will get into trouble, but we think that's an acceptable cost of deploying this technology". That's what I tried to say above, but I may have been too mild. >> In the RTCWEB use case, they may have more problems >> existing, since the negotiation will normally be carried over >> encrypted HTTPS connections. In other cases, where negotiation is >> done in the clear, they may be more common. > Sure. But, security is a separate issue. Security is never a separate issue :-) > >> For figuring out where we are: Are you talking about >> intermediaries that snoop the SDP flow without being in the >> flow, or are you talking about intermediaries that are part >> of the SDP flow? > I am talking about intermediaries that will anchor the media flow, and will reserve resources etc based on the SDP. What does the term "anchor the media flow" mean? And you did not answer my question on whether these intermediaries are part of the SDP flow or not. >> If you talk about intermediaries that snoop the flow, where >> would you think those would be placed for the RTCWEB use >> case, given that signalling traffic is likely to be carried >> over encrypted connections? > I don't know yet. Maybe there will be no intermediary between the browser and the webserver/legacy GW, but there could be between webservers. And, even if whatever happens there is outside the scope of RTCWEB, we need to keep in mind that the SIP/SDP signalling extensions etc we define might be used there. > > However, keep in mind that CLUE most likely will also be interested in a solution to negotiate a multiplex. And, CLUE entities will be located in "legacy" networks where these kind of entities do exist. When you say "network", do you mean "physical network", or "network of SIP entities"? Browsers will definitely be on the physical network too, but will probably not be directly on the web of SIP-interconnected entities. > Many also want to be able to participate in video conferences using a browser, and I think it would be good if there was a common system for negotiationg the usage of multiplex. That's why the spec has no references to RTCWEB apart from background.... From john.elwell@siemens-enterprise.com Fri Aug 26 03:37:25 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1FC21F8AFB for ; Fri, 26 Aug 2011 03:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dC9qhFpZ2C9 for ; Fri, 26 Aug 2011 03:37:24 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7910221F87C9 for ; Fri, 26 Aug 2011 03:37:24 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 4E7B11EB846E for ; Fri, 26 Aug 2011 12:38:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 26 Aug 2011 12:38:37 +0200 From: "Elwell, John" To: "mmusic@ietf.org" Date: Fri, 26 Aug 2011 12:38:35 +0200 Thread-Topic: SDP extensions in draft-ietf-siprec-protocol Thread-Index: Acxj3E7KU1f4G7ajRiOGEwmf67AiFw== Message-ID: 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] SDP extensions in draft-ietf-siprec-protocol X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 26 Aug 2011 10:37:25 -0000 I briefly mentioned during the MMUSIC session at IETF81 that SIPREC has som= e proposed SDP extensions in one of its drafts. At the time it was an indiv= idual draft, but this has now been adopted as a WG draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ See sections 6.2 and 7.5. In addition, the draft discusses use of SDP, in particular the label attrib= ute - see section 5.3. Although this is an early draft and needs more work, it would be good if so= me SDP experts could review the proposals and comment to the SIPREC mailing= list. SIPREC will hold a virtual interim meeting on 19th/23rd September, s= o any discussion before then would be particularly valuable. John= From miguel.a.garcia@ericsson.com Mon Aug 29 00:48:25 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E88021F89CC for ; Mon, 29 Aug 2011 00:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8W8t21qmJj0 for ; Mon, 29 Aug 2011 00:48:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B77C321F8A23 for ; Mon, 29 Aug 2011 00:48:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d7-4e5b449bd9de Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 29.93.20773.B944B5E4; Mon, 29 Aug 2011 09:49:47 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 29 Aug 2011 09:49:46 +0200 Message-ID: <4E5B449A.4070700@ericsson.com> Date: Mon, 29 Aug 2011 09:49:46 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP extensions in draft-ietf-siprec-protocol X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2011 07:48:25 -0000 Thanks John, We will try to recruit some people to take a look at your draft and two other drafts coming from AVTEXT. I will post it separately. /Miguel On 26/08/2011 12:38, Elwell, John wrote: > I briefly mentioned during the MMUSIC session at IETF81 that SIPREC has some proposed SDP extensions in one of its drafts. At the time it was an individual draft, but this has now been adopted as a WG draft: > https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol/ > > See sections 6.2 and 7.5. > > In addition, the draft discusses use of SDP, in particular the label attribute - see section 5.3. > > Although this is an early draft and needs more work, it would be good if some SDP experts could review the proposals and comment to the SIPREC mailing list. SIPREC will hold a virtual interim meeting on 19th/23rd September, so any discussion before then would be particularly valuable. > > John > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Mon Aug 29 01:08:32 2011 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE5221F8801 for ; Mon, 29 Aug 2011 01:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6DE7xlJ6snn for ; Mon, 29 Aug 2011 01:08:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EA5EA21F8781 for ; Mon, 29 Aug 2011 01:08:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-87-4e5b495364d4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.37.20773.3594B5E4; Mon, 29 Aug 2011 10:09:55 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 29 Aug 2011 10:09:54 +0200 Message-ID: <4E5B4951.6020000@ericsson.com> Date: Mon, 29 Aug 2011 10:09:53 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mmusic , "\"Elwell, John\" " , Keith Drage Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Three SDP extensions drafts. Reviewers needed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 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, 29 Aug 2011 08:08:32 -0000 Hi, We have received requests to review three Internet-Drafts that are extending SDP. We would like to get a few volunteers who can take a look at those drafts and verify that the SDP usage is correct, so are the examples, extensibility, IANA considerations sections (if applicable), etc. These are the drafts_ - SIPREC protocol (Sections 6.2 and 7.5): http://www.ietf.org/id/draft-ietf-siprec-protocol-00.txt - AVTEXT Client to mixer audio level (Sections 4 and 7). http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio-level-04.txt - AVTEXT Mixer to client audio level (Sections 5 and 7). http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio-level-04.txt We have been asked to provide comments asap, as soon as this week (at least for the AVTEXT drafts). If you are interested in review them and got a bit of spare time, please contact Flemming and myself. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain