From obsidian97@gmail.com Sat Jun 30 22:21:29 2012 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 253EC21F8557 for ; Sat, 30 Jun 2012 22:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qKErc1F94UUh for ; Sat, 30 Jun 2012 22:21:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0465921F847F for ; Sat, 30 Jun 2012 22:21:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7074230obb.31 for ; Sat, 30 Jun 2012 22:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6IjoD9jigew/q00+lfSQSNRtRwPBnafygIv3A2BLz2Y=; b=Ec+MFkwL7o9I/LM5HvVUCXl+YNqoxFemwNeJ6XlFsIwvRkXxdpT+8+7ClbYoGuKx51 WXfu6T6gP27r0EunlIG2bf1hvPc5yZqL18O5xk7Hs+h90hT21Qo0IT/9Ckfxe3IRPxL7 INGUqYX4u5Kw2beg/gQkHnHPDm2ExeGszrvOUQdx009mWD+/R841b2glu1GREwLlNYzG +KB9B2tplESKRpc9VkoY9XDyv3A6cy9WS58SrnNe/26SaEPFWjPzAYMDX1KJ1mdHT8a8 Hfu5Yok4Yd4uYHAmkgzcgxAQT/omuJAroG86Or0EqDN3FGeywaMmt2KarUIXnWVOeyqJ hvkg== MIME-Version: 1.0 Received: by 10.182.167.39 with SMTP id zl7mr2633093obb.10.1341120089235; Sat, 30 Jun 2012 22:21:29 -0700 (PDT) Received: by 10.182.221.104 with HTTP; Sat, 30 Jun 2012 22:21:29 -0700 (PDT) In-Reply-To: References: <4FD27EAB.1090102@cisco.com> <4FD28645.5000702@cisco.com> Date: Sat, 30 Jun 2012 22:21:29 -0700 Message-ID: From: Brian Stucker To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=e89a8f642c7485211904c3bdda3b X-Mailman-Approved-At: Mon, 02 Jul 2012 00:25:29 -0700 Cc: Flemming Andreasen , mmusic , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes) 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: Sun, 01 Jul 2012 05:21:29 -0000 --e89a8f642c7485211904c3bdda3b Content-Type: text/plain; charset=ISO-8859-1 Why wouldn't the WG simply publish the document and move on? Cheers, Brian Stucker On Thu, Jun 28, 2012 at 12:19 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Flemming, > > I take a pragmatic view. The document has been worked on in the group for > a while, a WGLC had been held, the received last call comments had been > incorporated in the meanwhile. > > From there on there are only two routes (IMHO): > a) publish the document through the working group, > b) the authors submit it to the RFC editor as an independent submission > > At this point in time the outcome is not so much different anymore (since > the working group had already provided their input). > > The text about the impact of middleboxes on signaling protocols is > something worth capturing and the offered guidance seems to be OK. I still > think that this writeup will be a useful reference for the work on > middleboxes with relationship to security protocols. > > Ciao > Hannes > > > On Jun 9, 2012, at 2:09 AM, Flemming Andreasen wrote: > > > Some comments (as an individual) > > > > A lot of the SIP and SDP work started out with a somewhat "purist" > Internet view of the world, where things such as middleboxes were not > considered. As other standards and industry organizations became interested > in using SIP and SDP, different architectures were defined and some of > those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and > CableLabs PacketCable). From an IETF point of view, there was, at least > initially, not a great deal of knowledge about these architectures and what > the middleboxes defined by them were doing. Conversely, there was (is) also > a concern that such middleboxes may break end-to-end transparency and hence > there was a desire to try and alleviate that. > > > > To that effect, it was seen as useful to have a document that could > > a) Explain what/how middleboxes might be operating in these architectures > > b) Provide guidelines as to how such middleboxes could minimize (ideally > avoid) impacting end-to-end transparency and/or how protocols could be used > to try and alleviate any impact such middleboxes might have. > > > > The middleboxes draft is trying to address the above as it relates to > the media path. The target audience is thus IETF participants that would > like an overview of how these middleboxes may affect SIP/SDP-signaled media > streams as well as what can be done to try and overcome that. Similarly, > the document is targeted at people involved in these "other" architecture > efforts, with a goal of making it clear how middleboxes may affect the > operation of SIP/SDP-signaled media streams and hence provide some "design > principles". This is not unlike some of the NAT work that was done in > BEHAVE. > > > > It could be argued that these architectures have now been around for so > long that producing the above document will not make any difference at this > point. While I have some sympathy for this, I also think we have to > recognize the importance of documenting what we know and to make that > readily available for new people that will be working in this space. > > > > In other words, I still believe there is value in pursuing this > document. As to whether it should be a BCP or Informational, I don't > have any strong opinions. > > > > Thanks > > > > -- Flemming (as an individual) > > > > > > > > > > On 6/8/12 6:37 PM, Flemming Andreasen wrote: > >> Hi > >> > >> As part of the MMUSIC charter we have the following milestone > >> > >> Sep 2012 Submit Considerations for using SDP offer/answer with > middleboxes for BCP > >> and we have the middleboxes draft > >> > >> > http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt > >> > >> to address that milestone. > >> > >> As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns > with the goal of the document and the potential target as further explained > in the following e-mail: > >> > >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html > >> > >> A set of (initial) technical comments were also provided by Hadriel in > the following e-mail: > >> > >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html > >> > >> For now, the chairs would like to focus on the first set of questions > above, i.e. what is the goal and potential target audience for the document > and is there still value in pursuing it ? > >> > >> > >> The chairs would like to poll the group for opinions and interest in > this. Specific areas to consider: > >> > >> 1) What is the target audience for the document ? > >> > >> 2) Do people believe that the target audience will read and/or care > about this document at this point ? > >> > >> 3) Should the document be a BCP or Informational ? > >> > >> > >> Thanks > >> > >> -- Miguel & Flemming (as chairs) > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > --e89a8f642c7485211904c3bdda3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why wouldn't the WG simply publish the document and move on?

Cheers,
Brian Stucker

= On Thu, Jun 28, 2012 at 12:19 AM, Hannes Tschofenig <<= a href=3D"mailto:hannes.tschofenig@gmx.net" target=3D"_blank">hannes.tschof= enig@gmx.net> wrote:
Hi Flemming,

I take a pragmatic view. The document has been worked on in the group for a= while, a WGLC had been held, the received last call comments had been inco= rporated in the meanwhile.

>From there on there are only two routes (IMHO):
a) publish the document through the working group,
b) the authors submit it to the RFC editor as an independent submission

At this point in time the outcome is not so much different anymore (since t= he working group had already provided their input).

The text about the impact of middleboxes on signaling protocols is somethin= g worth capturing and the offered guidance seems to be OK. I still think th= at this writeup will be a useful reference for the work on middleboxes with= relationship to security protocols.

Ciao
Hannes


On Jun 9, 2012, at 2:09 AM, Flemming Andreasen wrote:

> Some comments (as an individual)
>
> A lot of the SIP and SDP work started out with a somewhat "purist= " Internet view of the world, where things such as middleboxes were no= t considered. As other standards and industry organizations became interest= ed in using SIP and SDP, different architectures were defined and some of t= hose arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and = CableLabs PacketCable). From an IETF point of view, there was, at least ini= tially, not a great deal of knowledge about these architectures and what th= e middleboxes defined by them were doing. Conversely, there was (is) also a= concern that such middleboxes may break end-to-end transparency and hence = there was a desire to try and alleviate that.
>
> To that effect, it was seen as useful to have a document that could > a) Explain what/how middleboxes might be operating in these architectu= res
> b) Provide guidelines as to how such middleboxes could minimize (ideal= ly avoid) impacting end-to-end transparency and/or how protocols could be u= sed to try and alleviate any impact such middleboxes might have.
>
> The middleboxes draft is trying to address the above as it relates to = the media path. The target audience is thus IETF participants that would li= ke an overview of how these middleboxes may affect SIP/SDP-signaled media s= treams as well as what can be done to try and overcome that. Similarly, the= document is targeted at people involved in these "other" archite= cture efforts, with a goal of making it clear how middleboxes may affect th= e operation of SIP/SDP-signaled media streams and hence provide some "= design principles". This is not unlike some of the NAT work that was d= one in BEHAVE.
>
> It could be argued that these architectures have now been around for s= o long that producing the above document will not make any difference at th= is point. While I have some sympathy for this, I also think we have to reco= gnize the importance of documenting what we know and to make that readily a= vailable for new people that will be working in this space.
>
> In other words, I still believe there is value in pursuing this docume= nt. As to whether it should be a BCP or Informational, I don't =A0 =A0 = have any strong opinions.
>
> Thanks
>
> -- Flemming (as an individual)
>
>
>
>
> On 6/8/12 6:37 PM, Flemming Andreasen wrote:
>> Hi
>>
>> As part of the MMUSIC charter we have the following milestone
>>
>> Sep 2012 =A0 =A0 Submit Considerations for using SDP offer/answer = with middleboxes for BCP
>> and we have the middleboxes draft
>>
>> =A0 =A0 http://www.ietf.org/id/draft-iet= f-mmusic-media-path-middleboxes-04.txt
>>
>> to address that milestone.
>>
>> As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concer= ns with the goal of the document and the potential target as further explai= ned in the following e-mail:
>>
>> =A0 =A0 http://www.ietf.org/mail-archive/web/= mmusic/current/msg09278.html
>>
>> A set of (initial) technical comments were also provided by Hadrie= l in the following e-mail:
>>
>> =A0 =A0 http://www.ietf.org/mail-archive/web/= mmusic/current/msg08640.html
>>
>> For now, the chairs would like to focus on the first set of questi= ons above, i.e. what is the goal and potential target audience for the docu= ment and is there still value in pursuing it ?
>>
>>
>> The chairs would like to poll the group for opinions and interest = in this. Specific areas to consider:
>>
>> 1) What is the target audience for the document ?
>>
>> 2) Do people believe that the target audience will read and/or car= e about this document at this point ?
>>
>> 3) Should the document be a BCP or Informational ?
>>
>>
>> Thanks
>>
>> -- Miguel & Flemming (as chairs)
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>>
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--e89a8f642c7485211904c3bdda3b-- From hannes.tschofenig@nsn.com Mon Jul 2 00:51:51 2012 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 5381121F8AC7 for ; Mon, 2 Jul 2012 00:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.9 X-Spam-Level: X-Spam-Status: No, score=-105.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 R65qRClvRsBR for ; Mon, 2 Jul 2012 00:51:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 63CF821F8AB8 for ; Mon, 2 Jul 2012 00:51:44 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q627pfD9023947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jul 2012 09:51:41 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q627paEQ015350; Mon, 2 Jul 2012 09:51:39 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Jul 2012 09:51:36 +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_01CD5827.80FAB824" Date: Mon, 2 Jul 2012 10:51:34 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01A03205@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WG Poll on the middleboxes draft(draft-ietf-mmusic-media-path-middleboxes) Thread-Index: Ac1YI+KxjtzREJ7bSP6OhOfKdSxeTQAAAgGQ References: <4FD27EAB.1090102@cisco.com> <4FD28645.5000702@cisco.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Brian Stucker" , "Hannes Tschofenig" X-OriginalArrivalTime: 02 Jul 2012 07:51:36.0162 (UTC) FILETIME=[81676C20:01CD5827] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 24256 X-purgate-ID: 151667::1341215502-0000425E-D348B8B4/0-0/0-0 Cc: Flemming Andreasen , mmusic , draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft(draft-ietf-mmusic-media-path-middleboxes) 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, 02 Jul 2012 07:51:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD5827.80FAB824 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian,=20 =20 In this specific case I don't know.=20 =20 However, there have been cases in the past were folks claim that a specific body of work is overtaken by events.=20 =20 For this specific document that would mean:=20 =20 1. There are no middleboxes anymore.=20 2. Nobody uses SIP anymore.=20 3. End-to-end security isn't relevant anymore (and in particular when considering end-to-end security work that concerns proposals that use the media path).=20 =20 Regarding (1): I have no reason to believe that middleboxes will go away anytime in the near future.=20 =20 Regarding (2): With RTCWeb SIP may not be used between the end host and the VSP/ASP but JavaScript instead. We could improve the document to also take the recent developments in the RTCWeb environment into consideration since the discussion we have in the document isn't necessarily specific to SIP but rather to the offer-answer exchange.=20 =20 Regarding (3): I hope that e2e security isn't something that will go away either. The approach for media security in RTCWeb is very similar to what had been done in SIP a few years ago with http://tools.ietf.org/html/rfc5763 (at least after I quickly looked at http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-02).=20 =20 In a nutshell I still believe the document is relevant and none of the core foundations of the document has changed. What could, however, be done is to improve the writeup by referencing some of the more recent work on RTCWEB.=20 =20 Ciao Hannes =20 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext Brian Stucker Sent: Sunday, July 01, 2012 8:21 AM To: Hannes Tschofenig Cc: Flemming Andreasen; mmusic; draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org Subject: Re: [MMUSIC] WG Poll on the middleboxes draft(draft-ietf-mmusic-media-path-middleboxes) =20 Why wouldn't the WG simply publish the document and move on? =20 Cheers, Brian Stucker On Thu, Jun 28, 2012 at 12:19 AM, Hannes Tschofenig wrote: Hi Flemming, I take a pragmatic view. The document has been worked on in the group for a while, a WGLC had been held, the received last call comments had been incorporated in the meanwhile. >From there on there are only two routes (IMHO): a) publish the document through the working group, b) the authors submit it to the RFC editor as an independent submission At this point in time the outcome is not so much different anymore (since the working group had already provided their input). The text about the impact of middleboxes on signaling protocols is something worth capturing and the offered guidance seems to be OK. I still think that this writeup will be a useful reference for the work on middleboxes with relationship to security protocols. Ciao Hannes On Jun 9, 2012, at 2:09 AM, Flemming Andreasen wrote: > Some comments (as an individual) > > A lot of the SIP and SDP work started out with a somewhat "purist" Internet view of the world, where things such as middleboxes were not considered. As other standards and industry organizations became interested in using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, there was, at least initially, not a great deal of knowledge about these architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that such middleboxes may break end-to-end transparency and hence there was a desire to try and alleviate that. > > To that effect, it was seen as useful to have a document that could > a) Explain what/how middleboxes might be operating in these architectures > b) Provide guidelines as to how such middleboxes could minimize (ideally avoid) impacting end-to-end transparency and/or how protocols could be used to try and alleviate any impact such middleboxes might have. > > The middleboxes draft is trying to address the above as it relates to the media path. The target audience is thus IETF participants that would like an overview of how these middleboxes may affect SIP/SDP-signaled media streams as well as what can be done to try and overcome that. Similarly, the document is targeted at people involved in these "other" architecture efforts, with a goal of making it clear how middleboxes may affect the operation of SIP/SDP-signaled media streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE. > > It could be argued that these architectures have now been around for so long that producing the above document will not make any difference at this point. While I have some sympathy for this, I also think we have to recognize the importance of documenting what we know and to make that readily available for new people that will be working in this space. > > In other words, I still believe there is value in pursuing this document. As to whether it should be a BCP or Informational, I don't have any strong opinions. > > Thanks > > -- Flemming (as an individual) > > > > > On 6/8/12 6:37 PM, Flemming Andreasen wrote: >> Hi >> >> As part of the MMUSIC charter we have the following milestone >> >> Sep 2012 Submit Considerations for using SDP offer/answer with middleboxes for BCP >> and we have the middleboxes draft >> >> http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt >> >> to address that milestone. >> >> As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the document and the potential target as further explained in the following e-mail: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html >> >> A set of (initial) technical comments were also provided by Hadriel in the following e-mail: >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html >> >> For now, the chairs would like to focus on the first set of questions above, i.e. what is the goal and potential target audience for the document and is there still value in pursuing it ? >> >> >> The chairs would like to poll the group for opinions and interest in this. Specific areas to consider: >> >> 1) What is the target audience for the document ? >> >> 2) Do people believe that the target audience will read and/or care about this document at this point ? >> >> 3) Should the document be a BCP or Informational ? >> >> >> Thanks >> >> -- Miguel & Flemming (as chairs) >> >> >> >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic =20 ------_=_NextPart_001_01CD5827.80FAB824 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

In this specific case I don’t know.

 

However, there have been cases in the past were folks claim that a = specific body of work is overtaken by events.

 

For this specific document that would mean:

 

1.      = There are no middleboxes anymore.

2.      = Nobody uses SIP anymore.

3.      = End-to-end security isn’t relevant anymore (and in particular = when considering end-to-end security work that concerns proposals that = use the media path).

 

Regarding (1): I have no reason to believe that middleboxes will go = away anytime in the near future.

 

Regarding (2): With RTCWeb SIP may not be used between the end host = and the VSP/ASP but JavaScript instead. We could improve the document to = also take the recent developments in the RTCWeb environment into = consideration since the discussion we have in the document isn’t = necessarily specific to SIP but rather to the offer-answer exchange. =

 

Regarding (3): I hope that e2e security isn’t something that = will go away either. The approach for media security in RTCWeb is very = similar to what had been done in SIP a few years ago with http://tools.ietf.org/html/rf= c5763 (at least after I quickly looked at = http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-02). =

 

In a nutshell I still believe the document is relevant and none of = the core foundations of the document has changed. What could, however, = be done is to improve the writeup by referencing some of the more recent = work on RTCWEB.

 

Ciao

Hannes

 

From:= = mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of = ext Brian Stucker
Sent: Sunday, July 01, 2012 8:21 = AM
To: Hannes Tschofenig
Cc: Flemming Andreasen; = mmusic; = draft-ietf-mmusic-media-path-middleboxes@tools.ietf.org
Subject: Re: [MMUSIC] WG Poll on the middleboxes = draft(draft-ietf-mmusic-media-path-middleboxes)

 

Why wouldn't the WG simply publish the document and = move on?

 

Cheers,

Brian Stucker

On Thu, Jun 28, 2012 at 12:19 AM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> = wrote:

Hi Flemming,

I take a = pragmatic view. The document has been worked on in the group for a = while, a WGLC had been held, the received last call comments had been = incorporated in the meanwhile.

From there on there are only two = routes (IMHO):
a) publish the document through the working = group,
b) the authors submit it to the RFC editor as an independent = submission

At this point in time the outcome is not so much = different anymore (since the working group had already provided their = input).

The text about the impact of middleboxes on signaling = protocols is something worth capturing and the offered guidance seems to = be OK. I still think that this writeup will be a useful reference for = the work on middleboxes with relationship to security = protocols.

Ciao
Hannes



On Jun 9, 2012, = at 2:09 AM, Flemming Andreasen wrote:

> Some comments (as an = individual)
>
> A lot of the SIP and SDP work started out = with a somewhat "purist" Internet view of the world, where = things such as middleboxes were not considered. As other standards and = industry organizations became interested in using SIP and SDP, different = architectures were defined and some of those arcitectures did include = the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). = >From an IETF point of view, there was, at least initially, not a great = deal of knowledge about these architectures and what the middleboxes = defined by them were doing. Conversely, there was (is) also a concern = that such middleboxes may break end-to-end transparency and hence there = was a desire to try and alleviate that.
>
> To that effect, = it was seen as useful to have a document that could
> a) Explain = what/how middleboxes might be operating in these architectures
> = b) Provide guidelines as to how such middleboxes could minimize (ideally = avoid) impacting end-to-end transparency and/or how protocols could be = used to try and alleviate any impact such middleboxes might = have.
>
> The middleboxes draft is trying to address the = above as it relates to the media path. The target audience is thus IETF = participants that would like an overview of how these middleboxes may = affect SIP/SDP-signaled media streams as well as what can be done to try = and overcome that. Similarly, the document is targeted at people = involved in these "other" architecture efforts, with a goal of = making it clear how middleboxes may affect the operation of = SIP/SDP-signaled media streams and hence provide some "design = principles". This is not unlike some of the NAT work that was done = in BEHAVE.
>
> It could be argued that these architectures = have now been around for so long that producing the above document will = not make any difference at this point. While I have some sympathy for = this, I also think we have to recognize the importance of documenting = what we know and to make that readily available for new people that will = be working in this space.
>
> In other words, I still = believe there is value in pursuing this document. As to whether it = should be a BCP or Informational, I don't     have any strong = opinions.
>
> Thanks
>
> -- Flemming (as an = individual)
>
>
>
>
> On 6/8/12 6:37 PM, = Flemming Andreasen wrote:
>> Hi
>>
>> As part = of the MMUSIC charter we have the following = milestone
>>
>> Sep 2012     Submit = Considerations for using SDP offer/answer with middleboxes for = BCP
>> and we have the middleboxes = draft
>>
>>     http://www.ietf.org/id/draft-ietf-mmusic-media-path-mid= dleboxes-04.txt
>>
>> to address that = milestone.
>>
>> As discussed at IETF 83 (Paris), = Hadriel Kaplan raised some concerns with the goal of the document and = the potential target as further explained in the following = e-mail:
>>
>>     http://www.ietf.org/mail-archive/web/mmusic/current/msg= 09278.html
>>
>> A set of (initial) technical = comments were also provided by Hadriel in the following = e-mail:
>>
>>     http://www.ietf.org/mail-archive/web/mmusic/current/msg= 08640.html
>>
>> For now, the chairs would like to = focus on the first set of questions above, i.e. what is the goal and = potential target audience for the document and is there still value in = pursuing it ?
>>
>>
>> The chairs would like = to poll the group for opinions and interest in this. Specific areas to = consider:
>>
>> 1) What is the target audience for the = document ?
>>
>> 2) Do people believe that the target = audience will read and/or care about this document at this point = ?
>>
>> 3) Should the document be a BCP or = Informational ?
>>
>>
>> = Thanks
>>
>> -- Miguel & Flemming (as = chairs)
>>
>>
>>
>>
>>
&g= t;>
>>
>>
>> = _______________________________________________
>> mmusic = mailing list
>>
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>= ; _______________________________________________
> mmusic mailing = list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

 

------_=_NextPart_001_01CD5827.80FAB824-- From wwwrun@rfc-editor.org Tue Jul 3 11:02:35 2012 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 AB0B311E808C for ; Tue, 3 Jul 2012 11:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DwbdWJhARA45 for ; Tue, 3 Jul 2012 11:02:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CB14011E808E for ; Tue, 3 Jul 2012 11:02:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1CF9F72F1C4; Tue, 3 Jul 2012 11:01:16 -0700 (PDT) To: M.Handley@cs.ucl.ac.uk, van@packetdesign.com, csp@csperkins.org, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, fandreas@cisco.com, miguel.a.garcia@ericsson.com From: RFC Errata System Message-Id: <20120703180119.1CF9F72F1C4@rfc-editor.org> Date: Tue, 3 Jul 2012 11:01:16 -0700 (PDT) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) 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, 03 Jul 2012 18:02:35 -0000 The following errata report has been submitted for RFC4566, "SDP: Session Description Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=3278 -------------------------------------- Type: Technical Reported by: Riccardo Bernardini Section: 5 Original Text ------------- At page 9: Media description, if present m= (media name and transport address) Corrected Text -------------- Media description, if present m=* (media name and transport address) Notes ----- A '*' is added making "m=" lines optional Rationale: The description about media lines in section 5, page 9 is conflicting with the ABNF syntax of media-description in Section 9, page 40 media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields ) According to the ABNF grammar, an SDP description can have zero "m=" lines, but according to the description at page 9, at least one line must be present. Note that the conflict could be solved also by replacing the media-descriptions definition with media-descriptions = 1*( media-field ... ) but at page 8 (still Section 5) it is said An SDP session description consists of a session-level section followed by zero or more media-level sections. ... ^^^^^^^^^^^^^^^^^^^^^^^^ so, I guess that the ABNF grammar is correct. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4566 (draft-ietf-mmusic-sdp-new-26) -------------------------------------- Title : SDP: Session Description Protocol Publication Date : July 2006 Author(s) : M. Handley, V. Jacobson, C. Perkins Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From miguel.a.garcia@ericsson.com Wed Jul 4 02:12:34 2012 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 0814021F86D9 for ; Wed, 4 Jul 2012 02:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 6Rz02orpPg1F for ; Wed, 4 Jul 2012 02:12:33 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BF34B21F86D4 for ; Wed, 4 Jul 2012 02:12:32 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-08-4ff4090a895e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CE.94.25842.A0904FF4; Wed, 4 Jul 2012 11:12:42 +0200 (CEST) Received: from [159.107.25.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Wed, 4 Jul 2012 11:12:41 +0200 Message-ID: <4FF40908.80904@ericsson.com> Date: Wed, 4 Jul 2012 11:12:40 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: RFC Errata System , "\"Ali C. Begen (abegen)\" " References: <20120703180119.1CF9F72F1C4@rfc-editor.org> In-Reply-To: <20120703180119.1CF9F72F1C4@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+JvrS4X5xd/g1e7RCwebJ/LaLH85QlG i/cXdC3u/p7GYjF1+WMWi6b9X9ks2puWs1pcm9PIZvHt7G1WB06PKb83sno8O76WyWPa/fts HkuW/GTymLXzCYvHhOadbB4NbcdYPf4sOcsYwBHFZZOSmpNZllqkb5fAlbHzxiXGglbxike3 5jA1MB4U6GLk5JAQMJG4uegPE4QtJnHh3nq2LkYuDiGBU4wSr1ZuY4JwVjNKTH21kRGkildA U+LF+gYWEJtFQEXic+9xVhCbTcBconXjRnYQW1QgWOLMp/XsEPWCEidnPgGrFxFIkTh36gsL yFBmgU5mif51y8ESwkDNv3efBxrEAbTNXOL1dA2QMKeAhcSnY0/ArmMWsJW4MOc6C4QtL7H9 7RxmEFsI6J7JN5cyT2AUnIVk3SwkLbOQtCxgZF7FKJybmJmTXm6ul1qUmVxcnJ+nV5y6iREY LQe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFdJW8ea Ci7aEfxX+MymLw9/iDwvDpzOo/zbjM9g0ct3Gnet6x8HP0vXe6/Qpbhwy+bO/GJHx+el2YHz 5/qtKpQL+PyeTV//0iGPHeJrVU/s7X9y3dXaVkdp4gP5fXoWq3Y2iazKyuura5/AksARk6r0 9ZrPrel8NnLNPVdfz/RYuajJ+N+vJ0osxRmJhlrMRcWJALQTio5kAgAA Cc: "mmusic@ietf.org" , Gonzalo Camarillo , "fandreas@cisco.com" , "M.Handley@cs.ucl.ac.uk" , "csp@csperkins.org" , "van@packetdesign.com" Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) 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, 04 Jul 2012 09:12:34 -0000 I am adding Ali Begen to the loop, who is the current editor of 4566bis. Ali, can you please comment on the technical errata? /Miguel On 03/07/2012 20:01, RFC Errata System wrote: > > The following errata report has been submitted for RFC4566, > "SDP: Session Description Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=3278 > > -------------------------------------- > Type: Technical > Reported by: Riccardo Bernardini > > Section: 5 > > Original Text > ------------- > At page 9: > > > > > > Media description, if present > > m= (media name and transport address) > > Corrected Text > -------------- > > > Media description, if present > > m=* (media name and transport address) > > > > > > Notes > ----- > A '*' is added making "m=" lines optional > > > > Rationale: > > The description about media lines in section 5, page 9 is conflicting with the ABNF syntax of media-description in Section 9, page 40 > > > > media-descriptions = *( media-field > > information-field > > *connection-field > > bandwidth-fields > > key-field > > attribute-fields ) > > > > According to the ABNF grammar, an SDP description can have zero "m=" lines, but according to the description at page 9, at least one line must be present. Note that the conflict could be solved also by replacing the media-descriptions definition with > > > > media-descriptions = 1*( media-field ... ) > > > > but at page 8 (still Section 5) it is said > > > > An SDP session description consists of a session-level section > > followed by zero or more media-level sections. ... > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > > > so, I guess that the ABNF grammar is correct. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4566 (draft-ietf-mmusic-sdp-new-26) > -------------------------------------- > Title : SDP: Session Description Protocol > Publication Date : July 2006 > Author(s) : M. Handley, V. Jacobson, C. Perkins > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Wed Jul 4 15:09:15 2012 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 EF4B421F8624 for ; Wed, 4 Jul 2012 15:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=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 jqiC3oCUhtFB for ; Wed, 4 Jul 2012 15:09:15 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D10DB21F8618 for ; Wed, 4 Jul 2012 15:09:14 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-61-4ff4bf0aa009 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 99.A9.25842.A0FB4FF4; Thu, 5 Jul 2012 00:09:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 5 Jul 2012 00:09:14 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Date: Thu, 5 Jul 2012 00:09:13 +0200 Thread-Topic: BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used Thread-Index: AQHNWjGlnaxSmEpWZUODzqGn4/YWUQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@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: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+JvrS7X/i/+Bt0TjCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMV7+lgLTnFWTHwc2sB4ib2LkZNDQsBE4veuw2wQtpjEhXvr gWwuDiGBU4wSB2/dZoFwFjBKTPr/lamLkYODTcBCovufNkiDiIC6xNe9PcwgNouAisSpFf9Z QGxhAS+JR0dns0HUBErs3f6LHcLWkzi65wpYPa9AuMS1j0/BahiBFn8/tYYJxGYWEJe49WQ+ E8RBAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvZ7EjalT2CBsbYllC19DzReUODnzCcsERuFZ SMbOQtIyC0nLLCQtCxhZVjEK5yZm5qSXm+ulFmUmFxfn5+kVp25iBAb3wS2/DXYwbrovdohR moNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGuGMObyIebWP373S2i1Q13sZz QM7qzfsNpc79bv56jacfiovUN8459qD0oW4Ko96GwuNzEqbYBGoffOf0s/Ot4i4f41MO7uXX t7xI279apTIhWuXj2XD1eMPT9baXQ280vX1obnrM74/X28bvAdOMDGJyn6xVn/rQ61bmMQkv h7fKhYmLyxyUWIozEg21mIuKEwEiOUaoPAIAAA== Subject: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used 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, 04 Jul 2012 22:09:16 -0000 Hi, A question related to RTP/RTCP multiplexing with BUNDLE. BUNDLE allows the usage of identical port numbers for multiple m- lines. It= also expects a remote endpoint that does not support BUNDLE to send media associ= ated with multiple m- lines to that single port, even if the remote endpoint its= elf will use different ports for each m- line. In addition, the BUNDLE client can also multiplex RTP and RTCP, using the a= =3Drtcp-mux attribute. However, RFC 5761 says that one must be able to receive RTCP on the default= RTCP port, if the remote endpoint does not support a=3Drtcp-mux attribute. But, even if the remote endpoint does not support RTCP/RTP muxing, the ques= tion is whether the local endpoint could still use the same port for RTCP/RTP - and expect = the remote endpoint to send both RTP and RTCP to that single port (even if the remote endpoint = itself uses different ports for RTP and RTCP). In addition to the a=3Drtcp-mux attribute, the loc= al endpoint would use the a=3Drtcp attribute, containing the RTP port value. That would also, when ICE is used, prevent the local endpoint from having t= o reserve RTCP specific candidate ports. Regards, Christer From Bert.Greevenbosch@huawei.com Wed Jul 4 23:26:06 2012 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 C612211E80A3 for ; Wed, 4 Jul 2012 23:26:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq56EASU9xvr for ; Wed, 4 Jul 2012 23:26:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69711E8079 for ; Wed, 4 Jul 2012 23:26:06 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHL29689; Thu, 05 Jul 2012 02:26:18 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 23:25:58 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 23:26:03 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 14:25:54 +0800 From: Bert Greevenbosch To: "mmusic@ietf.org" Thread-Topic: Status of "Hitchhiker's Guide to SDP" Thread-Index: Ac1adwdyKake702nQZeBSXLg/TheQw== Date: Thu, 5 Jul 2012 06:25:53 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB629054D47@szxeml509-mbs> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [MMUSIC] Status of "Hitchhiker's Guide to SDP" 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, 05 Jul 2012 06:26:06 -0000 Hello all, I have just uploaded a new version of the "Hitchhiker's Guide to SDP" draft= : http://datatracker.ietf.org/doc/draft-greevenbosch-mmusic-hitchhikersguide-= sdp/ The main work done was identifying the drafts related to SDP, SIP, Megaco a= nd RTSP. Gonzalo Salguiero and Yue Peiyu (Roy) have helped in this. In addi= tion, I have copied some text from the original "Hitchhiker's Guide to SDP"= (RFC 5411). This is the current state of the work. However, we have some doubts about i= f this approach is the right one, especially as the document would become v= ery similar to RFC 5411. So we would like to ask feedback from the group on the approach. We are considering the following options: (1) Maintain the same style as RFC5411, including SIP. This would mean copy= & paste from RFC 5411, or even start with RFC 5411 and expand it. The draf= t would become RFC5411bis. (2) Start completely from scratch, and use a different format from RFC 5411= . The new guide could be "textbook style", giving a prosaic description of = SDP, its different components and working areas, and in the process referen= ces to the related RFCs. Notice that this is distinctively different from R= FC 5411, as the new document will not be a categorised list of SDP related = RFCs with short descriptions. (3) Reference RFC 5411, and include only new descriptions. This would keep = the document concise, but the reader has to read both the new draft and RFC= 5411 to get the complete picture. The advantage is, that we could focus on= what was done after RFC 5411, giving an insight in the latest developments= . =20 (4) Reconsider the scope of the document, i.e. inclusion of SIP or not. What would be the groups preference? Best regards, Bert From mperumal@cisco.com Thu Jul 5 04:46:56 2012 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 4B96321F864E for ; Thu, 5 Jul 2012 04:46:56 -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 LEiU8y5Cfn2J for ; Thu, 5 Jul 2012 04:46:55 -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 5F8FC21F8501 for ; Thu, 5 Jul 2012 04:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=7148; q=dns/txt; s=iport; t=1341488829; x=1342698429; h=from:to:cc:subject:date:message-id:mime-version; bh=eMh9z68WVGxK7g1A2lHSS3euB2kZXLVWH2HLhAYmHL8=; b=ldIv4aKti/353nbYZX+PyidH4SWYMBRjuJWWi18WjBRyv9cHQRfMs5te sOf9Jl+51x0f7CVpmpFqQHqmgmgOQ/0ufOHbQMumfsRy0D9ory21NZ1vO eAl9C8Hyl2gDlwGllAO8tjy4KGG1B/h2YJBQC1jDA0YgUxChzkOg/a0Hx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOJ99U+tJXG8/2dsb2JhbABFgki0XIEHghoBBBIBGj4OEgEqViYBBA4NGodpmiCfcZEXYAOjVIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,530,1336348800"; d="scan'208,217";a="99003940" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jul 2012 11:47:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65Bl8Sb011295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Jul 2012 11:47:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 06:47:07 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: mmusic Thread-Topic: SDP grouping in a new offer Thread-Index: Ac1ao+bIIyNbq2IgR+ayS6qhne1GYQ== Date: Thu, 5 Jul 2012 11:47:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.239.203] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--29.213900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012B443Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "Raghavendra S \(raghs\)" , "Toleti Danayya Naidu \(naidud\)" , "Dinesh V \(dinv\)" Subject: [MMUSIC] SDP grouping in a new offer 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, 05 Jul 2012 11:46:56 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012B443Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Experts, RFC3264 states that: If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=3D" lines, the new SDP MUST have at least N "m=3D" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. This matching is necessary in order for the answerer to determine which stream in the new SDP corresponds to a stream in the previous SDP. Because of these requirements, the number of "m=3D" lines in a stream never decreases, but either stays the same or increases. Deleted media streams from a previous SDP MUST NOT be removed in a new SDP; however, attributes for these streams need not be present. >From section 9.1 of RFC5888, it seems the same is applicable with SDP group= ing, but is not explicit. Should there be matching m-lines in the new offer= even with SDP grouping? Does SDP grouping change anything w.r.t to the abo= ve statements in RFC3264? thanks, Muthu --_000_E721D8C6A2E1544DB2DEBC313AF54DE2012B443Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Experts,

 

RFC3264 states that:

 

   If an SDP is offered, which is different from= the previous SDP, the

   new SDP MUST have a matching media stream for= each media stream in

   the previous SDP.  In other words, if th= e previous SDP had N "m=3D"

   lines, the new SDP MUST have at least N "= ;m=3D" lines.  The i-th media

   stream in the previous SDP, counting from the= top, matches the i-th

   media stream in the new SDP, counting from th= e top.  This matching is

   necessary in order for the answerer to determ= ine which stream in the

   new SDP corresponds to a stream in the previo= us SDP.  Because of

   these requirements, the number of "m=3D&= quot; lines in a stream never

   decreases, but either stays the same or incre= ases.  Deleted media

   streams from a previous SDP MUST NOT be remov= ed in a new SDP;

   however, attributes for these streams need no= t be present.

 

From section 9.1 of RFC5888, it seems the same is applicab= le with SDP grouping, but is not explicit. Should there be matching m-lines= in the new offer even with SDP grouping? Does SDP grouping change anything w.r.t to the above statements in RFC3264?

 

thanks,

Muthu

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE2012B443Dxmbrcdx02ciscoc_-- From christer.holmberg@ericsson.com Thu Jul 5 09:16:39 2012 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 AA9B621F8741 for ; Thu, 5 Jul 2012 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oNRtJS-M+6qL for ; Thu, 5 Jul 2012 09:16:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A113921F864B for ; Thu, 5 Jul 2012 09:16:36 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-28-4ff5bdf1170f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 02.1A.23986.1FDB5FF4; Thu, 5 Jul 2012 18:16:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 5 Jul 2012 18:16:49 +0200 From: Christer Holmberg To: "Muthu Arul Mozhi Perumal (mperumal)" , mmusic Date: Thu, 5 Jul 2012 18:15:01 +0200 Thread-Topic: SDP grouping in a new offer Thread-Index: Ac1ao+bIIyNbq2IgR+ayS6qhne1GYQAJW4bt Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF418C@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvre7HvV/9DZbttLLY9XQbq8XU5Y9Z LO58msNq8evgPRaLGVsmsjiwekz5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGQcv32Yr6OOt +D17O3sD43KuLkZODgkBE4nlz18wQ9hiEhfurWfrYuTiEBI4xSixeWknO4SzgFFi37QpQBkO DjYBC4nuf9ogDSICURKTbi5gBalhFmhnlDhzeBsrSIJFQEVi87dHjCD1wgIaEn9flkHUa0rs vr2CHcI2kvg95x8jiM0rEC7x/f9KJhBbSMBHYurMS2wgNqeAr8S/P//BjmMEOu77qTVgNcwC 4hK3nsxngjhaQGLJnvNQD4hKvHz8jxWiXlTiTvt6Roh6PYkbU6ewQdjaEssWvmaG2CsocXLm E5YJjGKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkvN9JLLcpMLi7Oz9MrTt3ECIysg1t+q+5g vHNO5BCjNAeLkjiv9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYHeQ6ROOO3nthtMFm sgkzf7fnuVlOX01b0439ZY/zKW9Snhs5/calv14iAZIK8fkH/nH45a3TmrVm1YXbT66ZH5Y8 yBd+KMt5TcIN3mNWQjyVFwWfNBqrL5wXLlC0Pt5U0ILzXoGhc8fFrW5e5cuX/1h/6H9F48bD 17Y92nR1W6m+XY9wz8ONSizFGYmGWsxFxYkAUW+SgHoCAAA= Cc: "Raghavendra S \(raghs\)" , "Dinesh V \(dinv\)" , "Toleti Danayya Naidu \(naidud\)" Subject: Re: [MMUSIC] SDP grouping in a new offer 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, 05 Jul 2012 16:16:39 -0000 Hi, In my opinion the grouping framework does not change the at-least-N-m=3D-li= nes rule. ...which is probably why 5888 doesn't mention it. Regards, Christer ________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Muthu = Arul Mozhi Perumal (mperumal) [mperumal@cisco.com] Sent: Thursday, July 05, 2012 2:47 PM To: mmusic Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv) Subject: [MMUSIC] SDP grouping in a new offer Experts, RFC3264 states that: If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=3D" lines, the new SDP MUST have at least N "m=3D" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. This matching is necessary in order for the answerer to determine which stream in the new SDP corresponds to a stream in the previous SDP. Because of these requirements, the number of "m=3D" lines in a stream never decreases, but either stays the same or increases. Deleted media streams from a previous SDP MUST NOT be removed in a new SDP; however, attributes for these streams need not be present. >From section 9.1 of RFC5888, it seems the same is applicable with SDP group= ing, but is not explicit. Should there be matching m-lines in the new offer= even with SDP grouping? Does SDP grouping change anything w.r.t to the abo= ve statements in RFC3264? thanks, Muthu From mperumal@cisco.com Thu Jul 5 10:21:19 2012 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 123D321F861D for ; Thu, 5 Jul 2012 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0LMwOYpdb6F for ; Thu, 5 Jul 2012 10:21:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8E07321F854D for ; Thu, 5 Jul 2012 10:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2169; q=dns/txt; s=iport; t=1341508891; x=1342718491; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EFTkBxO0jDx9z3j2iz6qHq8zy+Y9BGYi0zFWGHubQr8=; b=h+FHdgHk2WxTYdZT4SRtOGciKvYfUo9ZdQxwNNKEgVJjPiZDC4maoHjs GiEuvxjcziO8MzgLfASewz/uI7aqO6J1dO1L1uWTteVrx2dRb3fRgClZR PA+TKI28Cf8OdAlm88Rmx+AkUyJBTDFwisXHXS3fNcP6J5HnXDmvx+2qi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOnM9U+tJV2Y/2dsb2JhbABFtzCBB4IYAQEBBBIBJzEODAQCAQgRBAEBCxQJBzIUCQgBAQQBDQUIGodpmWqfc4s5hV5gA6NUgWaCXw X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="99090139" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jul 2012 17:21:17 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65HLH6P026581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 17:21:17 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 12:21:17 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Christer Holmberg , mmusic Thread-Topic: SDP grouping in a new offer Thread-Index: Ac1ao+bIIyNbq2IgR+ayS6qhne1GYQAJW4btAAImCfA= Date: Thu, 5 Jul 2012 17:21:17 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853405AF418C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853405AF418C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.84.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004 x-tm-as-result: No--35.795400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Raghavendra S \(raghs\)" , "Dinesh V \(dinv\)" , "Toleti Danayya Naidu \(naidud\)" Subject: Re: [MMUSIC] SDP grouping in a new offer 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, 05 Jul 2012 17:21:19 -0000 Thanks, Christer. It does make sense, but is not clear from RFC5888. What w= ould be best way to fix it? File an errata on RFC5888? Muthu |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Thursday, July 05, 2012 9:45 PM |To: Muthu Arul Mozhi Perumal (mperumal); mmusic |Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv) |Subject: RE: SDP grouping in a new offer | |Hi, | |In my opinion the grouping framework does not change the at-least-N-m=3D-l= ines rule. | |...which is probably why 5888 doesn't mention it. | |Regards, | |Christer | |________________________________ |From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Muthu= Arul Mozhi Perumal |(mperumal) [mperumal@cisco.com] |Sent: Thursday, July 05, 2012 2:47 PM |To: mmusic |Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv) |Subject: [MMUSIC] SDP grouping in a new offer | |Experts, | |RFC3264 states that: | | If an SDP is offered, which is different from the previous SDP, the | new SDP MUST have a matching media stream for each media stream in | the previous SDP. In other words, if the previous SDP had N "m=3D" | lines, the new SDP MUST have at least N "m=3D" lines. The i-th media | stream in the previous SDP, counting from the top, matches the i-th | media stream in the new SDP, counting from the top. This matching is | necessary in order for the answerer to determine which stream in the | new SDP corresponds to a stream in the previous SDP. Because of | these requirements, the number of "m=3D" lines in a stream never | decreases, but either stays the same or increases. Deleted media | streams from a previous SDP MUST NOT be removed in a new SDP; | however, attributes for these streams need not be present. | |From section 9.1 of RFC5888, it seems the same is applicable with SDP grou= ping, but is not explicit. |Should there be matching m-lines in the new offer even with SDP grouping? = Does SDP grouping change |anything w.r.t to the above statements in RFC3264? | |thanks, |Muthu From christer.holmberg@ericsson.com Thu Jul 5 10:49:20 2012 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 C509921F8624 for ; Thu, 5 Jul 2012 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 29g3rV0K5pRD for ; Thu, 5 Jul 2012 10:49:20 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B55D821F85F4 for ; Thu, 5 Jul 2012 10:49:19 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-0f-4ff5d3acfdb1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 41.82.25842.CA3D5FF4; Thu, 5 Jul 2012 19:49:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 5 Jul 2012 19:49:32 +0200 From: Christer Holmberg To: "Muthu Arul Mozhi Perumal (mperumal)" , mmusic Date: Thu, 5 Jul 2012 19:48:30 +0200 Thread-Topic: SDP grouping in a new offer Thread-Index: Ac1ao+bIIyNbq2IgR+ayS6qhne1GYQAJW4btAAImCfAAAR2mIA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF418E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853405AF418C@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvre6ay1/9Df7tM7HY9XQbq8XU5Y9Z LO58msNq8evgPRaLGVsmsjiwekz5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGSvu7mAteCNY 8WfdBJYGxhl8XYycHBICJhITzs9igrDFJC7cW8/WxcjFISRwilHi0tRjrBDOAkaJ3n/f2bsY OTjYBCwkuv9pgzSICERJTLq5AKyGWaCdUeLM4W2sIAkWARWJK1vWsILUCwtoSPx9WQZRrymx +/YKdgjbSWL/hS9gI3kFwiVOb5WHWHWbUeLHhMksIDWcAr4SJ+/fBTuOEei476fWgNnMAuIS t57MhzpaQGLJnvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4Wuwel4BQYmTM5+w TGAUm4Vk7CwkLbOQtMxC0rKAkWUVo3BuYmZOerm5XmpRZnJxcX6eXnHqJkZgZB3c8ttgB+Om +2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYMw2SZwZ/sX5c+6E/yuW PJINS5RX6Ulf8J3/d4PVy7KLa264nRK78mWdB2tv3dSXHefM5N47Lt02kcfa4tfV3QkbZt3d tmVRy8ZvRU0rf5m0ery3sPZ+M6Xwu1dr8qXQ/LPJRRO3O/paZfb9PrjkqPsStS3+nw4eeFS0 8oimpRZjytqNBWvefEpSYinOSDTUYi4qTgQAORLniHoCAAA= Cc: "Raghavendra S \(raghs\)" , "Dinesh V \(dinv\)" , "Toleti Danayya Naidu \(naidud\)" Subject: Re: [MMUSIC] SDP grouping in a new offer 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, 05 Jul 2012 17:49:20 -0000 Hi, >Thanks, Christer. It does make sense, but is not clear from RFC5888. What = would be best way to fix it? File >an errata on RFC5888? I am not sure anything needs to be fixed. Unless explicitly stated, 3264 ap= plies. Regards, Christer |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Thursday, July 05, 2012 9:45 PM |To: Muthu Arul Mozhi Perumal (mperumal); mmusic |Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv) |Subject: RE: SDP grouping in a new offer | |Hi, | |In my opinion the grouping framework does not change the at-least-N-m=3D-l= ines rule. | |...which is probably why 5888 doesn't mention it. | |Regards, | |Christer | |________________________________ |From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] On Behalf Of Muthu= Arul Mozhi Perumal |(mperumal) [mperumal@cisco.com] |Sent: Thursday, July 05, 2012 2:47 PM |To: mmusic |Cc: Raghavendra S (raghs); Toleti Danayya Naidu (naidud); Dinesh V (dinv) |Subject: [MMUSIC] SDP grouping in a new offer | |Experts, | |RFC3264 states that: | | If an SDP is offered, which is different from the previous SDP, the | new SDP MUST have a matching media stream for each media stream in | the previous SDP. In other words, if the previous SDP had N "m=3D" | lines, the new SDP MUST have at least N "m=3D" lines. The i-th media | stream in the previous SDP, counting from the top, matches the i-th | media stream in the new SDP, counting from the top. This matching is | necessary in order for the answerer to determine which stream in the | new SDP corresponds to a stream in the previous SDP. Because of | these requirements, the number of "m=3D" lines in a stream never | decreases, but either stays the same or increases. Deleted media | streams from a previous SDP MUST NOT be removed in a new SDP; | however, attributes for these streams need not be present. | |From section 9.1 of RFC5888, it seems the same is applicable with SDP grou= ping, but is not explicit. |Should there be matching m-lines in the new offer even with SDP grouping? = Does SDP grouping change |anything w.r.t to the above statements in RFC3264? | |thanks, |Muthu= From mperumal@cisco.com Thu Jul 5 12:14:30 2012 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 9FC5D11E80BA for ; Thu, 5 Jul 2012 12:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 6AwOs402l8DF for ; Thu, 5 Jul 2012 12:14:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6811E80AA for ; Thu, 5 Jul 2012 12:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2731; q=dns/txt; s=iport; t=1341515684; x=1342725284; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kmJ0v4u5QAFe9VMPWopYHYGFW5MYnwfEXQWz68wfWp4=; b=Iq02HEJBl3tXFSuLDqtxt6B0lxxImPYgOgKjKKN3M5iFwaa95ZGxQNoA mAU3pC7dX4Ic69Vs/IFdGxtDL4sx3PBBGNGaX36o+J715cz8kYfkH84x5 Jx9qT2k4nV73wXUjWLS1Tm0dqROQvw8MMA3f2sNhC0XGTS5H9km6/XI7B k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHLn9U+tJXG9/2dsb2JhbABFtzCBB4IYAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHaQuZVaAKBIs5hV5gA6NUgWaCX4FWBw X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="98914157" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jul 2012 19:14:43 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q65JEgvw031155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jul 2012 19:14:42 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 14:14:31 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used Thread-Index: AQHNWjGlnaxSmEpWZUODzqGn4/YWUZcbDTdQ Date: Thu, 5 Jul 2012 19:14:41 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.84.140] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19022.000 x-tm-as-result: No--36.304200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used 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, 05 Jul 2012 19:14:30 -0000 Hi Christer, I think the question boils down to whether the fallback port for RTCP descr= ibed in section 5.1.3 of RFC5761 could be the same as the RTP port. This lo= oks fine from a pragmatic point of view. However, the following statements = from RFC5761 seem to forbid it: On receipt of the answer, the offerer looks for the presence of the "a=3Drtcp-mux" line for each media where multiplexing was offered. If this is present, then connectivity checks proceed as if only a single candidate (for RTP) were offered, and multiplexing is used once the session is established. If the "a=3Drtcp-mux" line is not present, the session proceeds with connectivity checks using both RTP and RTCP candidates, eventually leading to a session being established with RTP and RTCP on separate ports (as signalled by the "a=3Drtcp:" attribute). Not sure if the statement "eventually leading to a session being establishe= d with RTP and RTCP on separate ports" was intentional. If not, it needs to= be fixed. Muthu |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f Christer Holmberg |Sent: Thursday, July 05, 2012 3:39 AM |To: mmusic@ietf.org |Subject: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mu= x is used | |Hi, | |A question related to RTP/RTCP multiplexing with BUNDLE. | |BUNDLE allows the usage of identical port numbers for multiple m- lines. I= t also |expects a remote endpoint that does not support BUNDLE to send media assoc= iated |with multiple m- lines to that single port, even if the remote endpoint it= self will use |different ports for each m- line. | |In addition, the BUNDLE client can also multiplex RTP and RTCP, using the = a=3Drtcp-mux attribute. | |However, RFC 5761 says that one must be able to receive RTCP on the defaul= t RTCP port, |if the remote endpoint does not support a=3Drtcp-mux attribute. | |But, even if the remote endpoint does not support RTCP/RTP muxing, the que= stion is whether |the local endpoint could still use the same port for RTCP/RTP - and expect= the remote endpoint |to send both RTP and RTCP to that single port (even if the remote endpoint= itself uses different |ports for RTP and RTCP). In addition to the a=3Drtcp-mux attribute, the lo= cal endpoint |would use the a=3Drtcp attribute, containing the RTP port value. | |That would also, when ICE is used, prevent the local endpoint from having = to reserve |RTCP specific candidate ports. | |Regards, | |Christer |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Fri Jul 6 00:00:31 2012 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 A7B6821F8758 for ; Fri, 6 Jul 2012 00:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.628 X-Spam-Level: X-Spam-Status: No, score=-105.628 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_74=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 Rgsn1dzCaNso for ; Fri, 6 Jul 2012 00:00:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 230B821F86DC for ; Fri, 6 Jul 2012 00:00:29 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-b9-4ff68d1cfe6d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D3.CD.23986.C1D86FF4; Fri, 6 Jul 2012 09:00:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 09:00:44 +0200 Message-ID: <4FF68D1B.3070103@ericsson.com> Date: Fri, 6 Jul 2012 09:00:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: , "Christer Holmberg (JO/LMF)" References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3Vle295u/wY5lLBZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv2WnUwFP8UrVs/+yd7AuFq4i5GTQ0LAROLwyW9MELaYxIV7 69m6GLk4hAROMUpcfPkaylnGKLF+1R5mkCpeAW2JoxuvsYLYLAIqEu9mPmYDsdkELCRu/mgE s0UFgiWmTb/HDlEvKHFy5hOWLkYODhGBMIlj0xxAwsICkRJLfuxnh5g/g1Fi8pcGsHpOAV+J p9tes0BcJClxr3012ExmAT2JKVdbGCFseYnmrbPB7hECuqehqYN1AqPgLCTrZiFpmYWkZQEj 8ypG4dzEzJz0ciO91KLM5OLi/Dy94tRNjMDAPLjlt+oOxjvnRA4xSnOwKInzWm/d4y8kkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0e3pOZu4IJ853bvNnDcsN/o9W9+7+vnNlSGr326doaI1 n+PnMt81c3cfnjH/bCI347Rv4QqK0nLb/xy1f5IW+/G7i2rL/w2nV30/qb2mU+VlMqNWQ3lF dN7UM9eu699/nbky/fnhnkUepd9KVUJ7KvgEtS8v7+Wq2/3gMH/7ssU6+7r9+Xbui1NiKc5I NNRiLipOBAAvhUj3GgIAAA== Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used 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, 06 Jul 2012 07:00:31 -0000 On 2012-07-05 21:14, Muthu Arul Mozhi Perumal (mperumal) wrote: > Hi Christer, > > I think the question boils down to whether the fallback port for RTCP > described in section 5.1.3 of RFC5761 could be the same as the RTP > port. This looks fine from a pragmatic point of view. However, the > following statements from RFC5761 seem to forbid it: > > On receipt of the answer, the offerer looks for the presence of the > "a=rtcp-mux" line for each media where multiplexing was offered. If > this is present, then connectivity checks proceed as if only a > single candidate (for RTP) were offered, and multiplexing is used > once the session is established. If the "a=rtcp-mux" line is not > present, the session proceeds with connectivity checks using both RTP > and RTCP candidates, eventually leading to a session being > established with RTP and RTCP on separate ports (as signalled by the > "a=rtcp:" attribute). > > Not sure if the statement "eventually leading to a session being > established with RTP and RTCP on separate ports" was intentional. If > not, it needs to be fixed. > As co-author of RFC5761 I think that sentence reflects how we perceived it would be used. In other words we only thought of the current legacy, not what could happen when someone made additional proposals that interacts with the RTP and RTCP port multiplexing. And based on that you would fall back to having different ports. However, I think I have found an issue that prevents one from using the same port for RTP and RTCP on one side. What I can figure out there exist nothing in a STUN binding request that are different between a binding request targeted to the ICE candidate for component ID=0 and component ID=1. If those two ICE candidates are co-located on the same port then you don't know which component the binding request is targeted for. It appears that the only thing keeping those separate is that the different components would not be present at the same base address+port. I think this identifies another requirement on bundle as the same is true between ICE media streams, i.e. m=lines. To ensure that different m=lines and their candidates can be correctly associated an OFFER with bundle MUST contain different ufrag per m= block. That way the offerer can use the security mechanism to verify that this STUN binding request is intended for m= context X and not any of the others. This is not the prettiest, but at least possible. I hope someone can poke a hole in my reasoning and show some way this can be avoided. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From miguel.a.garcia@ericsson.com Fri Jul 6 00:24:37 2012 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 8872511E80A6 for ; Fri, 6 Jul 2012 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_19=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 Y3a2ocZ16Pe6 for ; Fri, 6 Jul 2012 00:24:36 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8211E80A3 for ; Fri, 6 Jul 2012 00:24:35 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-cf-4ff692c2931f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 88.D2.25842.2C296FF4; Fri, 6 Jul 2012 09:24:51 +0200 (CEST) Received: from [164.48.161.153] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 09:24:50 +0200 Message-ID: <4FF692C1.9090903@ericsson.com> Date: Fri, 6 Jul 2012 09:24:49 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "petithug@acm.org" , "mmusic@ietf.org" References: <20120307124012.0AFC962179@rfc-editor.org> In-Reply-To: <20120307124012.0AFC962179@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvre7hSd/8DV7f4LZ4f0HXovn5MnaL qcsfs1hcWHOXyeLanEY2B1aPy1e8Pab83sjqsWTJTyaP1vUzGT1m7XzCEsAaxWWTkpqTWZZa pG+XwJVx4eYSpoIVohXbby5hb2B8LdDFyMEhIWAi8X1CbhcjJ5ApJnHh3nq2LkYuDiGBU4wS y3evhXJWM0oc+3SVBaSKV0Bb4sXs96wgNouAisT2+f+YQWw2AXOJ1o0b2UFsUYFgiTOf1rND 1AtKnJz5BKxXRMBPYkVPI9hQZoGDjBJff0M0CwM1d5w+wgZiCwmYSTxY1ArWwAkU77p4FqyG WcBW4sKc6ywQtrzE9rdzmCHqNSUm31zKPIFRcBaSfbOQtMxC0rKAkXkVo3BuYmZOerm5XmpR ZnJxcX6eXnHqJkZgkB/c8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYPSfnvTieIS0Mn+RIZebldvrTTobbVrnxT7avHPrn+sW2klPH13gP3vG90fgpo74 VSe3tTgf+tok/Olp5WmxLTP7OMO67U85PQr2Xc8kFvJfWV/i+2Hbpk9V5y9PesDN+VNO+Vbc i0/e3lf3rHHearHS1Prg1+VVa4/421x6Fpw6XX6tZGdO/14lluKMREMt5qLiRAC/gr9XQAIA AA== Cc: "jdrosen@jdrosen.net" , "fandreas@cisco.com" , Gonzalo Camarillo Subject: Re: [MMUSIC] [Editorial Errata Reported] RFC5245 (3149) 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, 06 Jul 2012 07:24:37 -0000 Hi: Some time ago Marc reported an editorial errata in RFC 5245. The errata was that the ice-mismatch SDP attribute was listed as session-level only, but it should have been listed as media-level only. IANA has fixed the SDP parameter registry, http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml and now the ice-mismatch attribute is listed as media-level only, and there is a pointer to the errata text. /Miguel On 07/03/2012 13:40, RFC Errata System wrote: > > The following errata report has been submitted for RFC5245, > "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3149 > > -------------------------------------- > Type: Editorial > Reported by: Marc Petit-huguenin > > Section: 21.1.4 > > Original Text > ------------- > Type of Attribute: session-level > > Corrected Text > -------------- > Type of Attribute: media-level > > Notes > ----- > Section 15.3 clearly says that "ice-mismatch" is media-level: > > > > '"ice-mismatch" is a media-level > > attribute only, and when present in an answer, indicates that the > > offer arrived with a default destination for a media component that > > didn't have a corresponding candidate attribute.' > > > > Section Section 6.1 also implies that "ice-mismatch" is media-level: > > > > "In some cases, the answer may omit a=candidate attributes for the > > media streams, and instead include an a=ice-mismatch attribute for > > one or more of the media streams in the SDP." > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5245 (draft-ietf-mmusic-ice-19) > -------------------------------------- > Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols > Publication Date : April 2010 > Author(s) : J. Rosenberg > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From thomas.stach@siemens-enterprise.com Fri Jul 6 01:00:59 2012 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 11C9721F8755 for ; Fri, 6 Jul 2012 01:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 TDkZNVE37W-B for ; Fri, 6 Jul 2012 01:00:58 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 101B921F86F7 for ; Fri, 6 Jul 2012 01:00:58 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 6D07623F0521 for ; Fri, 6 Jul 2012 10:01:13 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Fri, 6 Jul 2012 10:01:13 +0200 From: "Stach, Thomas" To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) Thread-Index: AQHNWUYPMQCIfhkIgU+LW5F7OYfakZcb4ASg Date: Fri, 6 Jul 2012 08:01:12 +0000 Message-ID: References: <20120703180119.1CF9F72F1C4@rfc-editor.org> In-Reply-To: <20120703180119.1CF9F72F1C4@rfc-editor.org> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.248.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) 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, 06 Jul 2012 08:00:59 -0000 All, I think this errata should be rejected. The text on page 9 is pretty clear and I don't see a conflict with the ABNF= . =20 Under "Session description" it is explicitly stated that you can have zero = or more media descriptions (as well as time descriptions) Further down under "Media description, if present" it is elaborated what a = media description includes.=20 It must at least include exactly one m-line. The a,b,k,i,c-lines are option= al. Adding the asterisk as proposed would remove this subtlety. The same technique is used for "Time description". The t-line is mandatory,= the r-lines are optional.=20 BTW: Being able to provide zero media descriptions is crucial for certain i= mplementations. An example is tunneling QSIG in SIP. Regards Thomas =20 > -----Urspr=FCngliche Nachricht----- > Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=20 > Im Auftrag von RFC Errata System > Gesendet: Dienstag, 03. Juli 2012 20:01 > An: M.Handley@cs.ucl.ac.uk; van@packetdesign.com;=20 > csp@csperkins.org; gonzalo.camarillo@ericsson.com;=20 > rjsparks@nostrum.com; fandreas@cisco.com; miguel.a.garcia@ericsson.com > Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org > Betreff: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) >=20 >=20 > The following errata report has been submitted for RFC4566, > "SDP: Session Description Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4566&eid=3D3278 >=20 > -------------------------------------- > Type: Technical > Reported by: Riccardo Bernardini >=20 > Section: 5 >=20 > Original Text > ------------- > At page 9: >=20 >=20 > Media description, if present > m=3D (media name and transport address) >=20 > Corrected Text > -------------- >=20 > Media description, if present > m=3D* (media name and transport address) >=20 >=20 >=20 > Notes > ----- > A '*' is added making "m=3D" lines optional >=20 > Rationale:=20 > The description about media lines in section 5, page 9 is=20 > conflicting with the ABNF syntax of media-description in=20 > Section 9, page 40 >=20 > media-descriptions =3D *( media-field > information-field > *connection-field > bandwidth-fields > key-field > attribute-fields ) >=20 > According to the ABNF grammar, an SDP description can have=20 > zero "m=3D" lines, but according to the description at page 9,=20 > at least one line must be present. Note that the conflict=20 > could be solved also by replacing the media-descriptions=20 > definition with=20 >=20 > media-descriptions =3D 1*( media-field ... ) >=20 > but at page 8 (still Section 5) it is said >=20 > An SDP session description consists of a session-level section > followed by zero or more media-level sections. ... > ^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > so, I guess that the ABNF grammar is correct. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4566 (draft-ietf-mmusic-sdp-new-26) > -------------------------------------- > Title : SDP: Session Description Protocol > Publication Date : July 2006 > Author(s) : M. Handley, V. Jacobson, C. Perkins > Category : PROPOSED STANDARD > Source : Multiparty Multimedia Session Control > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From magnus.westerlund@ericsson.com Fri Jul 6 02:25:10 2012 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 C02FE21F8700 for ; Fri, 6 Jul 2012 02:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.91 X-Spam-Level: X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_74=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 5KBt2Gh1QjAN for ; Fri, 6 Jul 2012 02:25:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AB3D521F86BD for ; Fri, 6 Jul 2012 02:25:09 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-02-4ff6af03eed1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 76.B4.23986.30FA6FF4; Fri, 6 Jul 2012 11:25:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 11:25:23 +0200 Message-ID: <4FF6AF02.7050806@ericsson.com> Date: Fri, 6 Jul 2012 11:25:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "mmusic@ietf.org" References: <7F2072F1E0DE894DA4B517B93C6A05853405AF4182@ESESSCMS0356.eemea.ericsson.se> <4FF68D1B.3070103@ericsson.com> In-Reply-To: <4FF68D1B.3070103@ericsson.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+JvrS7z+m/+BnNOW1tMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGY8m7mQsOC9ecff0dsYGxknCXYwcHBICJhLrD+p0MXICmWIS F+6tZ+ti5OIQEjjFKLFrwUoWCGcZo8Sdk3PZQKp4BbQllq1ZDGazCKhIdLZdZgWx2QQsJG7+ aASLiwoES0ybfo8dol5Q4uTMJywgtoiAusTXvT3MIDazgJnEpVsnwOLCApESS37sZ4dYtoNR 4kfzCrAEp4COxLU56xghzpOUuNe+mg2iWU9iytUWRghbXqJ562ywoUJAxzU0dbBOYBSahWT3 LCQts5C0LGBkXsUonJuYmZNebqSXWpSZXFycn6dXnLqJERiwB7f8Vt3BeOecyCFGaQ4WJXFe 6617/IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw7shqEJwRu+5JevLZotMWdzfcepDAODOF Y/tflsb3EWum3L+9esNsx5a4k7G3Ffs1FdK6P6W/s9Kbo7flqmvPxI1Rf2fpHpJMsp7fvXyV 9ddbfVlBcyxiT869IB256F5J+hVlXpmra88f8We0OuPjxi/ZJCzwrX7bMdYPp1p8/xgv6G2f vMNDVImlOCPRUIu5qDgRAI9ZyWomAgAA Cc: Christer Holmberg Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used 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, 06 Jul 2012 09:25:10 -0000 On 2012-07-06 09:00, Magnus Westerlund wrote: > On 2012-07-05 21:14, Muthu Arul Mozhi Perumal (mperumal) wrote: >> Hi Christer, >> >> I think the question boils down to whether the fallback port for RTCP >> described in section 5.1.3 of RFC5761 could be the same as the RTP >> port. This looks fine from a pragmatic point of view. However, the >> following statements from RFC5761 seem to forbid it: >> >> On receipt of the answer, the offerer looks for the presence of the >> "a=rtcp-mux" line for each media where multiplexing was offered. If >> this is present, then connectivity checks proceed as if only a >> single candidate (for RTP) were offered, and multiplexing is used >> once the session is established. If the "a=rtcp-mux" line is not >> present, the session proceeds with connectivity checks using both RTP >> and RTCP candidates, eventually leading to a session being >> established with RTP and RTCP on separate ports (as signalled by the >> "a=rtcp:" attribute). >> >> Not sure if the statement "eventually leading to a session being >> established with RTP and RTCP on separate ports" was intentional. If >> not, it needs to be fixed. >> > > As co-author of RFC5761 I think that sentence reflects how we perceived > it would be used. In other words we only thought of the current legacy, > not what could happen when someone made additional proposals that > interacts with the RTP and RTCP port multiplexing. And based on that you > would fall back to having different ports. > > However, I think I have found an issue that prevents one from using the > same port for RTP and RTCP on one side. What I can figure out there > exist nothing in a STUN binding request that are different between a > binding request targeted to the ICE candidate for component ID=0 and > component ID=1. If those two ICE candidates are co-located on the same > port then you don't know which component the binding request is targeted > for. It appears that the only thing keeping those separate is that the > different components would not be present at the same base address+port. I forgot one thing when writing this. When the offerer gets the SDP answer and the candidates it contains it will know the source address+port for any candidate that matches the ones the answerer provided. Thus most of the answers binding requests will be correctly determined and bound to the right component. Unfortunately there exist peer-reflexive candidates and those can't be correctly bound at this stage. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From riccardo.bernardini@uniud.it Fri Jul 6 02:39:22 2012 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 043FE21F8736 for ; Fri, 6 Jul 2012 02:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 k2S41FgJKKLj for ; Fri, 6 Jul 2012 02:39:21 -0700 (PDT) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 19EE921F870F for ; Fri, 6 Jul 2012 02:39:20 -0700 (PDT) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id AE1C0B72C9C for ; Fri, 6 Jul 2012 11:39:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at talitha1 Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id 2PtU3MPBU8mS for ; Fri, 6 Jul 2012 11:39:34 +0200 (CEST) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 94EA0B0035 for ; Fri, 6 Jul 2012 11:39:34 +0200 (CEST) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Fri, 06 Jul 2012 11:39:34 +0200 Message-ID: <20120706113934.316446cy7mrqdhzq@webmail.uniud.it> Date: Fri, 06 Jul 2012 11:39:34 +0200 From: Riccardo Bernardini To: mmusic@ietf.org References: <20120703180119.1CF9F72F1C4@rfc-editor.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) 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, 06 Jul 2012 09:39:22 -0000 "Stach, Thomas" ha scritto: > All, > > I think this errata should be rejected. > > The text on page 9 is pretty clear and I don't see a conflict with the ABNF. > > Under "Session description" it is explicitly stated that you can > have zero or more media descriptions (as well as time descriptions) > Further down under "Media description, if present" it is elaborated > what a media description includes. > It must at least include exactly one m-line. The a,b,k,i,c-lines are > optional. > Adding the asterisk as proposed would remove this subtlety. > The same technique is used for "Time description". The t-line is > mandatory, the r-lines are optional. OK, let me try to rephrase it: the media-description BLOCK is OPTIONAL and you can have zero media-description blocks; but the "m=" line is MANDATORY whenever you have a media-description block. Maybe this was the reason of my confusion: I interpreted the missing asterisk as ``you cannot have SDP descriptions without m= lines,'' while I should have read ``m= lines are mandatory within a media block, but an SDP without m= lines is OK as long as you have no media blocks.'' I guess that "if present" part should clarify this, but it escaped me, sorry. Note that this type of subtlety does not happen with t= lines since, according to the ABNF, at least one "time-fields" block must be present. OK, I can see why the text on page 9 is correct. Regards Riccardo > > BTW: Being able to provide zero media descriptions is crucial for > certain implementations. An example is tunneling QSIG in SIP. > > Regards > Thomas > >> -----Ursprüngliche Nachricht----- >> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Im Auftrag von RFC Errata System >> Gesendet: Dienstag, 03. Juli 2012 20:01 >> An: M.Handley@cs.ucl.ac.uk; van@packetdesign.com; >> csp@csperkins.org; gonzalo.camarillo@ericsson.com; >> rjsparks@nostrum.com; fandreas@cisco.com; miguel.a.garcia@ericsson.com >> Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org >> Betreff: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) >> >> >> The following errata report has been submitted for RFC4566, >> "SDP: Session Description Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=3278 >> >> -------------------------------------- >> Type: Technical >> Reported by: Riccardo Bernardini >> >> Section: 5 >> >> Original Text >> ------------- >> At page 9: >> >> >> Media description, if present >> m= (media name and transport address) >> >> Corrected Text >> -------------- >> >> Media description, if present >> m=* (media name and transport address) >> >> >> >> Notes >> ----- >> A '*' is added making "m=" lines optional >> >> Rationale: >> The description about media lines in section 5, page 9 is >> conflicting with the ABNF syntax of media-description in >> Section 9, page 40 >> >> media-descriptions = *( media-field >> information-field >> *connection-field >> bandwidth-fields >> key-field >> attribute-fields ) >> >> According to the ABNF grammar, an SDP description can have >> zero "m=" lines, but according to the description at page 9, >> at least one line must be present. Note that the conflict >> could be solved also by replacing the media-descriptions >> definition with >> >> media-descriptions = 1*( media-field ... ) >> >> but at page 8 (still Section 5) it is said >> >> An SDP session description consists of a session-level section >> followed by zero or more media-level sections. ... >> ^^^^^^^^^^^^^^^^^^^^^^^^ >> >> so, I guess that the ABNF grammar is correct. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4566 (draft-ietf-mmusic-sdp-new-26) >> -------------------------------------- >> Title : SDP: Session Description Protocol >> Publication Date : July 2006 >> Author(s) : M. Handley, V. Jacobson, C. Perkins >> Category : PROPOSED STANDARD >> Source : Multiparty Multimedia Session Control >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine From miguel.a.garcia@ericsson.com Fri Jul 6 05:01:03 2012 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 93D1321F8796 for ; Fri, 6 Jul 2012 05:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 idmx2bGSnSK5 for ; Fri, 6 Jul 2012 05:01:02 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7441D21F877D for ; Fri, 6 Jul 2012 05:01:02 -0700 (PDT) X-AuditID: c1b4fb30-b7fb46d0000064f2-f1-4ff6d38d3f53 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 45.8F.25842.D83D6FF4; Fri, 6 Jul 2012 14:01:17 +0200 (CEST) Received: from [164.48.161.153] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 14:01:17 +0200 Message-ID: <4FF6D38B.9080704@ericsson.com> Date: Fri, 6 Jul 2012 14:01:15 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+JvrW7v5W/+Bkv2WVi8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+Pxl2PsBT0sFR2XDjA1MM5k7mLk4JAQMJG4 MFm3i5ETyBSTuHBvPVsXIxeHkMApRolFF3+xQzirGSUeXlzOBFLFK6AtcfH5MxYQm0VAReLz 3omMIDabgLlE68aN7CC2qECwxJlP69kh6gUlTs58AlYvIiAjsXfTZmYQmxlozuw7s8BmCgPN 2da8mxEibitxYc51FghbXmL72zlg9UICmhKTby5lnsDIPwvJ2FlIWmYhaVnAyLyKUTg3MTMn vdxcL7UoM7m4OD9Przh1EyMw8A5u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MCpUK6c5FvIVSaU1rX2g5zfFrnduxXd366u/Yt/qfP7kxhKkzCHrUpMh ++7bnvXnpJ5WFRiEPFnsc/L6V//6yCcNuyvedMUvXjuBoyd95UrDaJGCrLJVW9SUbd5+Clrk 57U2cFvuJ6sLy85wKqz/xn9Dpbnkuk/jw1lmz0RDF5dcPhEhXFUQrcRSnJFoqMVcVJwIAPWM ZSIKAgAA Cc: Flemming Andreasen Subject: [MMUSIC] Agenda requests for IETF 84 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, 06 Jul 2012 12:01:03 -0000 MMUSIC will meet for 2.5 hours on August 1st at IETF 84 in Vancouver. If you want to request a time slot to discuss a draft, please send an e-mail to Flemming and myself. As usually, we want to remind you that we should smartly use our meeting time. In principle, the meeting time should be use to discuss open issues. We give priority to drafts that gather attention and discussion in the mailing list prior to the meeting. -- Miguel and Flemming -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From abegen@cisco.com Sat Jul 7 15:55:16 2012 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 2789B21F8666 for ; Sat, 7 Jul 2012 15:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4ADORnCdU+Af for ; Sat, 7 Jul 2012 15:55:14 -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 78D7021F8541 for ; Sat, 7 Jul 2012 15:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3768; q=dns/txt; s=iport; t=1341701735; x=1342911335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sIQ27OJdz8HRx9ye6MKEveMwlSFHY6vVlsAtoheeGPI=; b=mWj5dVv00d0/pRf2WVn7Jv+7Y933WMb5rNy5JwfCKXpsfVSCZBRz0Dq+ 6y1le+NuoS7CFVs9TTn9fXD5kExXG3k5ljbfrC+uX/RZnXxo2Bf3kJJSr ado6+5iURFJNkKUaD0LewNyESb4Mozcrp3OkyQjVAqwoBwHdaph8+njOk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADu++E+tJV2Z/2dsb2JhbAArGrdagQeCIAEBAQMBEgFmDAQCAQgRBAEBAQodBzIUCQgCBAENBQgah2UGAQopmWuef4tAhSxgA6NVgWaCX28 X-IronPort-AV: E=Sophos;i="4.77,544,1336348800"; d="scan'208";a="99708134" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jul 2012 22:55:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q67MtDVQ013322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Jul 2012 22:55:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Sat, 7 Jul 2012 17:55:13 -0500 From: "Ali C. Begen (abegen)" To: "Miguel A. Garcia" , RFC Errata System Thread-Topic: [Technical Errata Reported] RFC4566 (3278) Thread-Index: AQHNWcUsCxsD7MaFb0mykMo5Z93uU5cec3Bw Date: Sat, 7 Jul 2012 22:55:12 +0000 Message-ID: References: <20120703180119.1CF9F72F1C4@rfc-editor.org> <4FF40908.80904@ericsson.com> In-Reply-To: <4FF40908.80904@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.250] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19024.004 x-tm-as-result: No--53.332000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , Gonzalo Camarillo , "Flemming Andreasen \(fandreas\)" , "M.Handley@cs.ucl.ac.uk" , "csp@csperkins.org" , "van@packetdesign.com" Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) 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, 07 Jul 2012 22:55:16 -0000 I agree with Thomas' assessment. I don=92t see a problem with the current A= BNF. > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Wednesday, July 04, 2012 5:13 AM > To: RFC Errata System; Ali C. Begen (abegen) > Cc: M.Handley@cs.ucl.ac.uk; van@packetdesign.com; csp@csperkins.org; Gonz= alo Camarillo; rjsparks@nostrum.com; > Flemming Andreasen (fandreas); riccardo.bernardini@uniud.it; mmusic@ietf.= org > Subject: Re: [Technical Errata Reported] RFC4566 (3278) >=20 > I am adding Ali Begen to the loop, who is the current editor of 4566bis. >=20 > Ali, can you please comment on the technical errata? >=20 > /Miguel >=20 >=20 >=20 > On 03/07/2012 20:01, RFC Errata System wrote: > > > > The following errata report has been submitted for RFC4566, > > "SDP: Session Description Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D4566&eid=3D3278 > > > > -------------------------------------- > > Type: Technical > > Reported by: Riccardo Bernardini > > > > Section: 5 > > > > Original Text > > ------------- > > At page 9: > > > > > > > > > > > > Media description, if present > > > > m=3D (media name and transport address) > > > > Corrected Text > > -------------- > > > > > > Media description, if present > > > > m=3D* (media name and transport address) > > > > > > > > > > > > Notes > > ----- > > A '*' is added making "m=3D" lines optional > > > > > > > > Rationale: > > > > The description about media lines in section 5, page 9 is conflicting w= ith the ABNF syntax of media-description in Section 9, > page 40 > > > > > > > > media-descriptions =3D *( media-field > > > > information-field > > > > *connection-field > > > > bandwidth-fields > > > > key-field > > > > attribute-fields ) > > > > > > > > According to the ABNF grammar, an SDP description can have zero "m=3D" = lines, but according to the description at page 9, > at least one line must be present. Note that the conflict could be solve= d also by replacing the media-descriptions definition > with > > > > > > > > media-descriptions =3D 1*( media-field ... ) > > > > > > > > but at page 8 (still Section 5) it is said > > > > > > > > An SDP session description consists of a session-level section > > > > followed by zero or more media-level sections. ... > > > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > so, I guess that the ABNF grammar is correct. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4566 (draft-ietf-mmusic-sdp-new-26) > > -------------------------------------- > > Title : SDP: Session Description Protocol > > Publication Date : July 2006 > > Author(s) : M. Handley, V. Jacobson, C. Perkins > > Category : PROPOSED STANDARD > > Source : Multiparty Multimedia Session Control > > Area : Real-time Applications and Infrastructure > > Stream : IETF > > Verifying Party : IESG > > >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain >=20 From nleung@qualcomm.com Tue Jul 3 18:21:35 2012 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 66D3711E80BF for ; Tue, 3 Jul 2012 18:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 30dqwGDjaBWD for ; Tue, 3 Jul 2012 18:21:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8811E80AE for ; Tue, 3 Jul 2012 18:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1341364904; x=1372900904; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; bh=+Nhwv/BDJmhAs6tX7nUHo0bMv/0y6MuF5AmcXp341sc=; b=vcwbNK9qQ5uDtHFDUPTKA0cqZpxIN5LceEbkvEJrwf+ZVeBABqILcfbL H1wH0jYPnAHUb7iMCUswF0thM/9mXkSvFBgdhM9+UUn0/9N+y9jwp/uAb cqrWPQxYSeahL6ruHyWpWAEs14BfSFz7SDXYfsecNDeSSEBCPt37zaQQB o=; X-IronPort-AV: E=McAfee;i="5400,1158,6761"; a="204934046" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 03 Jul 2012 18:21:39 -0700 X-IronPort-AV: E=Sophos;i="4.77,518,1336374000"; d="scan'208";a="252988305" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2012 18:21:39 -0700 Received: from NASANEXD02A.na.qualcomm.com ([169.254.1.100]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.02.0309.002; Tue, 3 Jul 2012 18:21:37 -0700 From: "Leung, Nikolai" To: Roni Even , "'Miguel A. Garcia'" , 'mmusic' Thread-Topic: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation Thread-Index: AQHNQBBpc/y6MXup6kKbmtpq5SDarpcYfR+g Date: Wed, 4 Jul 2012 01:21:36 +0000 Message-ID: <1D66EB63CC41C84C962C30306A2B5F6828D15103@NASANEXD02A.na.qualcomm.com> References: <4FC8AB79.5050808@ericsson.com> <4fc8e853.4668b40a.1705.7838@mx.google.com> In-Reply-To: <4fc8e853.4668b40a.1705.7838@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.114.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 08 Jul 2012 20:11:06 -0700 Cc: 'Flemming Andreasen' , "'kyunghun.jung@samsung.com'" <'kyunghun.jung@samsung.com'> Subject: Re: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation 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, 04 Jul 2012 01:22:27 -0000 Hi, Thanks for the feedback. A key concern we have in 3GPP is the amount of bandwidth used for real-time= applications as the traffic uses a considerable amount of the resources sh= ared among the mobile terminals in a cell. In our specifications we provid= e options and recommendations for terminals to minimize the RTCP bandwidth = used for a session (in some cases turning off RTCP). =20 The option for an Answering terminal to answer with smaller RR and RS value= s was for the case where a terminal wants to reduce the RTCP bandwidth belo= w what was offered. Perhaps we could add a clarification that the Answer m= ay respond with a lower RTCP bandwidth due to available bandwidth restrict= ions? Best Regards, -Nikolai -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Friday, June 01, 2012 12:03 PM To: 'Miguel A. Garcia'; 'mmusic' Cc: 'Flemming Andreasen'; Leung, Nikolai Subject: RE: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth Neg= otiation Hi, In general it is good to add some text about this case since it is not addr= essed in RFC3556 or RFC3264. I do not see any text that claims that RFC3556 should be used for multicast or broadcast only and not to negotiate= for point to point calls. I am not sure about the proposed recommendations. My understanding is that = since RTCP unlike RTP is bidirectional channel than the RS and RR values sp= ecify the bw required for all endpoints. If the offer had a value for RS an= d RR, I believe that in a point to point call when we have two sender and t= wo receivers each will get half of the RS and RR bandwidth.=20 The offerer in this case will offer what he believes is needed for him to s= end RTCP RRs and SRs reports multiply by two so if the answerer thinks he n= eed less bandwidth he should allow for the offerer to have enough RTCP band= width at least for his sender reports. So I think that answerer should resp= ond with the same value or possibly higher. otherwise we may need to define= that the RR and RS values in the offer represent the bw that offerer wants= to use and the values in the answer would be the value the answerer like t= o use, the total RTCP bw will be the sum of the two values. Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > Behalf Of Miguel A. Garcia > Sent: Friday, June 01, 2012 2:46 PM > To: mmusic > Cc: Flemming Andreasen; nleung@qualcomm.com > Subject: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth=20 > Negotiation >=20 > 3GPP SA4 has sent us an LS on RTCP Bandwidth Negotiation. I copy below=20 > the text. >=20 > We should be able to provide them an answer in a reasonable time=20 > frame, so please, review it and provide with comments to the list. The=20 > chairs will compile a reply text. >=20 > The original document can be found at the 3GPP web site: > http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_69/Docs/S4-120810.zip >=20 > /Miguel and Flemming > ------- >=20 > 3GPP SA4 uses the RTCP bandwidth modifiers (b=3DRS and b=3DRR) to control= =20 > the amount of RTCP bandwidth used in point-to-point VoIP and video=20 > telephony sessions. As these parameters were primarily designed for=20 > multicast sessions, the calculations in section 2 of RFC 3556 apply to=20 > the total RTCP bandwidth for the session, i.e., total bandwidth for=20 > all clients sending/receiving RTCP traffic. However, there are no SDP=20 > Offer/Answer models defined that use these parameters for the=20 > negotiation of the total RTCP bandwidth for point-to-point sessions. >=20 > To clarify this, SA4 is planning to make the following recommendations=20 > in our specifications: >=20 > 1. The RS and RR values included in the SDP offer should be treated > as > proposed values for the session and may be modified by the answerer=20 > during session negotiation. >=20 > 2. When generating the SDP answer, the answerer should include the > RR and > RS values proposed in the SDP offer. The answerer may instead choose=20 > to include RR and RS values lower than those proposed in the SDP Offer. >=20 > 3. The RS and RR values included in the SDP answer should be treated > as > the negotiated values for the session and should be used to calculate=20 > the total RTCP bandwidth for all terminals in the session. >=20 >=20 >=20 > Actions: > To IETF MMUSIC WG >=20 > ACTION: SA4 asks MMUSIC WG to review the above recommendations and > identify if there are any discrepancies with the practices or=20 > understanding in the IETF. >=20 > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From miguel.a.garcia@ericsson.com Mon Jul 9 00:13:39 2012 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 CCE0F21F8638 for ; Mon, 9 Jul 2012 00:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 SHGaNAuzzOWg for ; Mon, 9 Jul 2012 00:13:38 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6666221F856C for ; Mon, 9 Jul 2012 00:13:38 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-84-4ffa84b969a8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 58.7D.23986.9B48AFF4; Mon, 9 Jul 2012 09:14:01 +0200 (CEST) Received: from [159.107.24.133] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Mon, 9 Jul 2012 09:14:01 +0200 Message-ID: <4FFA84B8.3040700@ericsson.com> Date: Mon, 9 Jul 2012 09:14:00 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Stach, Thomas" References: <20120703180119.1CF9F72F1C4@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre7Oll/+BrO26Fg82D6X0WLq8scs Fru21zgwe0z5vZHVY8mSn0weN26/Zw5gjuKySUnNySxLLdK3S+DKaFt5gKmgV61izcuZbA2M u2S7GDk5JARMJL5f3MYEYYtJXLi3nq2LkYtDSOAUo8TahzehnNWMEkdu/WYHqeIV0JY4cPsQ I4jNIqAi8XziCjCbTcBconXjRrAaUYFgiTOf1kPVC0qcnPmEBcQWEbCUePbiJ9g2ZoFoif8N W4FqODiEBRwk1j0HKxcSqJDYcfoqK4jNKeAr0di7mgWi3FbiwpzrULa8RPPW2cwQ9ZoSk28u ZZ7AKDgLybZZSFpmIWlZwMi8ilE4NzEzJ73cSC+1KDO5uDg/T684dRMjMHgPbvmtuoPxzjmR Q4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDUvv2ja57xHOdPL00sPs85 E2Scqlt4NDT++GLxnDx2neTS4+tdLrZW2LU9PyRk2yrwQnSF//ddJSIvTlg3vkg/OGXGp+l+ hTffZ15v0b91RMIiqIzr+OrGIDuWJ7/mrCmQdj7YM8960sKaxrXPVopc+uXkVDJ9ESOPyxFm 36kWVbEPkl9O7dJQYinOSDTUYi4qTgQAQfYYXCwCAAA= Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) 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, 09 Jul 2012 07:13:39 -0000 Hi Thomas: I am also copying Ali, who is currently editing 4566bis. This comment is as an individual. I see your point, and I believe you are right as well. The text needs to be read as a whole: The "Session Description" indicates that "Zero or more media descriptions" can follow. And the text then says "Media description, if present". So, if there is a media description present, the "m=" line is mandatory, thus, there is no asterisk close to it. BR, Miguel On 06/07/2012 10:01, Stach, Thomas wrote: > All, > > I think this errata should be rejected. > > The text on page 9 is pretty clear and I don't see a conflict with the ABNF. > > Under "Session description" it is explicitly stated that you can have zero or more media descriptions (as well as time descriptions) > Further down under "Media description, if present" it is elaborated what a media description includes. > It must at least include exactly one m-line. The a,b,k,i,c-lines are optional. > Adding the asterisk as proposed would remove this subtlety. > The same technique is used for "Time description". The t-line is mandatory, the r-lines are optional. > > BTW: Being able to provide zero media descriptions is crucial for certain implementations. An example is tunneling QSIG in SIP. > > Regards > Thomas > >> -----Ursprüngliche Nachricht----- >> Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >> Im Auftrag von RFC Errata System >> Gesendet: Dienstag, 03. Juli 2012 20:01 >> An: M.Handley@cs.ucl.ac.uk; van@packetdesign.com; >> csp@csperkins.org; gonzalo.camarillo@ericsson.com; >> rjsparks@nostrum.com; fandreas@cisco.com; miguel.a.garcia@ericsson.com >> Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org >> Betreff: [MMUSIC] [Technical Errata Reported] RFC4566 (3278) >> >> >> The following errata report has been submitted for RFC4566, >> "SDP: Session Description Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=3278 >> >> -------------------------------------- >> Type: Technical >> Reported by: Riccardo Bernardini >> >> Section: 5 >> >> Original Text >> ------------- >> At page 9: >> >> >> Media description, if present >> m= (media name and transport address) >> >> Corrected Text >> -------------- >> >> Media description, if present >> m=* (media name and transport address) >> >> >> >> Notes >> ----- >> A '*' is added making "m=" lines optional >> >> Rationale: >> The description about media lines in section 5, page 9 is >> conflicting with the ABNF syntax of media-description in >> Section 9, page 40 >> >> media-descriptions = *( media-field >> information-field >> *connection-field >> bandwidth-fields >> key-field >> attribute-fields ) >> >> According to the ABNF grammar, an SDP description can have >> zero "m=" lines, but according to the description at page 9, >> at least one line must be present. Note that the conflict >> could be solved also by replacing the media-descriptions >> definition with >> >> media-descriptions = 1*( media-field ... ) >> >> but at page 8 (still Section 5) it is said >> >> An SDP session description consists of a session-level section >> followed by zero or more media-level sections. ... >> ^^^^^^^^^^^^^^^^^^^^^^^^ >> >> so, I guess that the ABNF grammar is correct. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4566 (draft-ietf-mmusic-sdp-new-26) >> -------------------------------------- >> Title : SDP: Session Description Protocol >> Publication Date : July 2006 >> Author(s) : M. Handley, V. Jacobson, C. Perkins >> Category : PROPOSED STANDARD >> Source : Multiparty Multimedia Session Control >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From fandreas@cisco.com Mon Jul 9 07:52:08 2012 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 8118C11E809A for ; Mon, 9 Jul 2012 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 y4DhgqIxMRWH for ; Mon, 9 Jul 2012 07:52:04 -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 C35FF21F84B3 for ; Mon, 9 Jul 2012 07:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fandreas@cisco.com; l=20317; q=dns/txt; s=iport; t=1341845549; x=1343055149; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Pn2YCbYc7z2R3COe6o0tScpxRKTCyrpZPEZZ8kb71GU=; b=ddNoaCkGr/Fb0AtdtUre7uX0ZA5dmjc5+GDXa2EohASA9u6b+1/eXA1c ls+Jd857Cf+04gbtnZZJYi6YcO0iK1+CrHxQpaG7Tad7w3IH8ip77pn2W aFdZcfhLNEt2rHl5OylcqoVNohhKm7vzHTyKoHPjVs6XDnzYND1o80Aox 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAODu+k+tJXHA/2dsb2JhbABFgkqIe6hCg2SBB4IgAQEBBBIBGkwQCxgJFw4PAkYGDQEHAQEeh2ubUp9ikUwDlTaOH4Fmgns X-IronPort-AV: E=Sophos;i="4.77,552,1336348800"; d="scan'208,217";a="100034413" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jul 2012 14:52:28 +0000 Received: from rtp-fandreas-8715.cisco.com (rtp-fandreas-8715.cisco.com [10.117.7.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q69EqRHP005394; Mon, 9 Jul 2012 14:52:27 GMT Message-ID: <4FFAF035.40401@cisco.com> Date: Mon, 09 Jul 2012 10:52:37 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C442AB5C5@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------010105030009030708030808" Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13 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, 09 Jul 2012 14:52:08 -0000 This is a multi-part message in MIME format. --------------010105030009030708030808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Christer Thank you for the review comments - feedback below On 4/30/12 8:27 AM, Christer Holmberg wrote: > > Hi, > > Eventhough a very detailed mechanism, in the same way as Cullen I > could not come up with cases where the mechanism would not work. > > I also took a detailed look at the ABNF, where I have some comments. > > ----------------- > > General: > > SDP normally has a rather strict syntax. For example, elements are > normally separated explicitly with "SP". However, you use "1*WSP" in > most places. Is there a reason for having a more relaxed syntax in > media cap? > Not really, but I have never understood why a text-based protocol should choke on white-space. There is a well-defined grammar, so I don't really see any reason to change (not least since you'd change to something less liberal). > ---------------- > > > Section 3.3.2.1: > > The section contains examples with a number of rmcap attributes: > > a=rmcap:1,2 audio G729/8000 > a=rmcap:1 video H263-1998/90000 > a=rmcap:2 video H263-2000/90000 > > However, I don't think these are valid according to the syntax in section 3.3.1, which does not define the media type ("audio", "video", etc): > > a=rmcap: / [/] > Good catch - fixed. > > --------------- > > > Section 3.3.8: > > The example contains the following line: > > a=rmcap:51 * > > However, I don't think that is valid according to the syntax in section 3.3.1, which mandates both encoding name and clock-rate: > > a=rmcap: / [/] > > > In addition, I find no definition of using "*" for the encoding-name (I assume it is some kind of wildcard). > Outstanding catch :-) Fixed (to "omcap", which clarifies use of "*" as well) > > --------------- > > > Section 4.1: > > See issue on 3.3.8. > Sorry - I don't see the corresponding issue in 4.1. Can you elaborate ? > > --------------- > > > a=omcap: > > There is no example showing the a=omcap attribute. I think it would be good to have one. > Expanded example in Section 4.3 to cover omcap. > > --------------- > > > a=sescap: > > There is no example showing the usage of optional-configs. I think it would be good to have one. > I changed one of the examples in Section 3.3.8 to illustrate this. Thanks -- Flemming > > --------------- > > > Regards, > > Christer > --------------010105030009030708030808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Christer

Thank you for the review comments - feedback below


On 4/30/12 8:27 AM, Christer Holmberg wrote:

Hi,

 

Eventhough a very detailed mechanism, in the same way as Cullen I could not come up with cases where the mechanism would not work.

 

I also took a detailed look at the ABNF, where I have some comments.

 

-----------------

 

 

General:

 

SDP normally has a rather strict syntax. For example, elements are normally separated explicitly with “SP”. However, you use “1*WSP” in most places. Is there a reason for having a more relaxed syntax in media cap?

 

Not really, but I have never understood why a text-based protocol should choke on white-space. There is a well-defined grammar, so I don't really see any reason to change (not least since you'd change to something less liberal).

 

----------------

 

 
Section 3.3.2.1:
 
The section contains examples with a number of rmcap attributes:
 
       a=rmcap:1,2 audio G729/8000
       a=rmcap:1 video H263-1998/90000
       a=rmcap:2 video H263-2000/90000
 
However, I don’t think these are valid according to the syntax in section 3.3.1, which does not define the media type (“audio”, “video”, etc):
 
               a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/<encoding-parms>]
 

Good catch - fixed. 
 
---------------
 
 
Section 3.3.8:
 
The example contains the following line:
 
               a=rmcap:51 *
 
However, I don’t think that is valid according to the syntax in section 3.3.1, which mandates both encoding name and clock-rate:
 
               a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/<encoding-parms>]
 
 
In addition, I find no definition of using “*” for the encoding-name (I assume it is some kind of wildcard).
 
Outstanding catch :-)

Fixed (to "omcap", which clarifies use of "*" as well)
 
---------------
 
 
Section 4.1:
 
See issue on 3.3.8.
 

Sorry - I don't see the corresponding issue in 4.1. Can you elaborate ? 

 
---------------
 
 
a=omcap:
 
There is no example showing the a=omcap attribute. I think it would be good to have one.
 
Expanded example in Section 4.3 to cover omcap. 
 
---------------
 
 
a=sescap:
 
There is no example showing the usage of optional-configs. I think it would be good to have one.
 
I changed one of the examples in Section 3.3.8 to illustrate this.

Thanks

-- Flemming 


 
---------------
 

Regards,

 

Christer



--------------010105030009030708030808-- From internet-drafts@ietf.org Mon Jul 9 14:18:30 2012 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 7E52821F84EF; Mon, 9 Jul 2012 14:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 yUhLMqgmfYVY; Mon, 9 Jul 2012 14:18:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0692C21F8533; Mon, 9 Jul 2012 14:18:30 -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: 4.30p3 Message-ID: <20120709211830.11133.35472.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 14:18:30 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-14.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, 09 Jul 2012 21:18: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 Wor= king Group of the IETF. Title : SDP Media Capabilities Negotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-14.txt Pages : 60 Date : 2012-07-09 Abstract: Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-media-capabilities There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-14 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-media-capabiliti= es-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From miguel.a.garcia@ericsson.com Tue Jul 10 00:02:24 2012 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 C98CE21F850D for ; Tue, 10 Jul 2012 00:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 wOz1Y2SljKe3 for ; Tue, 10 Jul 2012 00:02:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C96F621F851A for ; Tue, 10 Jul 2012 00:02:23 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-aa-4ffbd399fa49 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.DB.15286.993DBFF4; Tue, 10 Jul 2012 09:02:49 +0200 (CEST) Received: from [159.107.25.27] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 09:02:49 +0200 Message-ID: <4FFBD398.9050706@ericsson.com> Date: Tue, 10 Jul 2012 09:02:48 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvre7My7/9DVYcULXY/yjUYuryxywO TB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8aRV9IF85grFn19zNbAeIqpi5GTQ0LARGL2 zC/MELaYxIV769m6GLk4hAROMUosm7SdHcJZzShx6/8SsA5eAW2J7qPzGUFsFgFVidsbJrKD 2GwC5hKtGzeC2aICwRJnPq1nh6gXlDg58wkLiC0iICOxd9NmsG3MAs4SzZ9vg80UFrCReNn3 nR0ibitxYc51FghbXmL72zlg9UICmhKTby5lnsDIPwvJ2FlIWmYhaVnAyLyKUTg3MTMnvdxI L7UoM7m4OD9Przh1EyMw8A5u+a26g/HOOZFDjNIcLErivNZb9/gLCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYKxn0udZ2M94ojKU9S7rZ12J9bOuPdijmnrHojHTgefErKlZX6/fuMQp4XHZ f9X5284Lrs0x9n37Znbr8Y1/7x++tXTyroYVl3m3ljJr5E+Mjbkk+u1N0/FZ/+cYbo0JWnHz xMvn+y1sgjxz3R/r8c18LnlDaO9nj1lv/255WrhAtlbcJZO7OlBDiaU4I9FQi7moOBEAxYLi QAoCAAA= Cc: draft-ietf-mmusic-sdp-media-capabilities.authors@tools.ietf.org Subject: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-media-capabilities-14 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, 10 Jul 2012 07:02:24 -0000 This is to start a 2-week Working Group Last Call for draft-ietf-mmusic-sdp-media-capabilities-14 available at: http://www.ietf.org/id/draft-ietf-mmusic-sdp-media-capabilities-14.txt The WGLC ends on July 25th, 2012. Please reply to this e-mail to send comments, so that the authors and the mailing list are all copied. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From stefan.lk.hakansson@ericsson.com Tue Jul 10 05:20:39 2012 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 2530B11E808E for ; Tue, 10 Jul 2012 05:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_74=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 whANsIwK1kVu for ; Tue, 10 Jul 2012 05:20:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B539721F871D for ; Tue, 10 Jul 2012 05:20:36 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-c8-4ffc1e2faec2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1B.2E.03067.F2E1CFF4; Tue, 10 Jul 2012 14:21:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 14:21:03 +0200 Message-ID: <4FFC1E2E.6090509@ericsson.com> Date: Tue, 10 Jul 2012 14:21:02 +0200 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <4FFC1D96.107@ericsson.com> In-Reply-To: <4FFC1D96.107@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvra6+3B9/gzNdqhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtqeM2wFr6QqXi6dy9bA+Fuki5GTQ0LAROLwh5/MELaYxIV7 69m6GLk4hAROMUrMPPiUHcJZziixe9E5dpAqXgFtiQcLfjKC2CwCqhIP718Hs9kEbCTWdk9h 6mLk4BAVCJOYvhOqXFDi5MwnLCC2iICwxIy3f9lAbGGBSIklP/aD1QgJqEtcf/EdrIZTQEPi ze0DTCA2s4CtxIU511kgbHmJ5q2zmSHqdSXevb7HOoFRYBaSFbOQtMxC0rKAkXkVo3BuYmZO erm5XmpRZnJxcX6eXnHqJkZg+B3c8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYKyY1rB/95xFZRk8Io+n818uOzHBb8uyTVosfdpNbh0xTGKPX06+Ouv1 PfE/L0Q+x8/ZOjHndc+nrIBpC2fOOi5QKlhyXa9qu3GZ28nLyxzDnn7kfrtjg+SNw57nc9xW eWVs6lJXuypjG7HopwPn5XZ+/ZVJTTc7p/3e+SMqr0L13Qo25nou7b9KLMUZiYZazEXFiQC4 QwMCDQIAAA== Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used 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, 10 Jul 2012 12:20:39 -0000 On 07/10/2012 02:18 PM, Stefan Håkansson LK wrote: > On 2012-07-06 09:00, Magnus Westerlund wrote: > > On 2012-07-05 21:14, Muthu Arul Mozhi Perumal (mperumal) wrote: > >> Hi Christer, > >> > >> I think the question boils down to whether the fallback port for RTCP > >> described in section 5.1.3 of RFC5761 could be the same as the RTP > >> port. This looks fine from a pragmatic point of view. However, the > >> following statements from RFC5761 seem to forbid it: > >> > >> On receipt of the answer, the offerer looks for the presence of the > >> "a=rtcp-mux" line for each media where multiplexing was offered. If > >> this is present, then connectivity checks proceed as if only a > >> single candidate (for RTP) were offered, and multiplexing is used > >> once the session is established. If the "a=rtcp-mux" line is not > >> present, the session proceeds with connectivity checks using both RTP > >> and RTCP candidates, eventually leading to a session being > >> established with RTP and RTCP on separate ports (as signalled by the > >> "a=rtcp:" attribute). > >> > >> Not sure if the statement "eventually leading to a session being > >> established with RTP and RTCP on separate ports" was intentional. If > >> not, it needs to be fixed. > >> > > > > As co-author of RFC5761 I think that sentence reflects how we perceived > > it would be used. In other words we only thought of the current legacy, > > not what could happen when someone made additional proposals that > > interacts with the RTP and RTCP port multiplexing. And based on that you > > would fall back to having different ports. > > > > However, I think I have found an issue that prevents one from using the > > same port for RTP and RTCP on one side. What I can figure out there > > exist nothing in a STUN binding request that are different between a > > binding request targeted to the ICE candidate for component ID=0 and > > component ID=1. If those two ICE candidates are co-located on the same > > port then you don't know which component the binding request is targeted > > for. It appears that the only thing keeping those separate is that the > > different components would not be present at the same base address+port. > > I forgot one thing when writing this. When the offerer gets the SDP > answer and the candidates it contains it will know the source > address+port for any candidate that matches the ones the answerer > provided. Thus most of the answers binding requests will be correctly > determined and bound to the right component. Unfortunately there exist > peer-reflexive candidates and those can't be correctly bound at this stage. So, now I am confused. Are we OK as is, or should the Bundle draft be updated, or something else? (To me it sound like the Bundle draft should be updated.) Stefan > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com > ---------------------------------------------------------------------- > From magnus.westerlund@ericsson.com Tue Jul 10 05:30:56 2012 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 4A57621F8702 for ; Tue, 10 Jul 2012 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.607 X-Spam-Level: X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_74=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 KwCiCVRhmshD for ; Tue, 10 Jul 2012 05:30:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 284EA21F8602 for ; Tue, 10 Jul 2012 05:30:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-9d-4ffc2099e7d1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D5.EF.03067.9902CFF4; Tue, 10 Jul 2012 14:31:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Tue, 10 Jul 2012 14:31:21 +0200 Message-ID: <4FFC2099.7020702@ericsson.com> Date: Tue, 10 Jul 2012 14:31:21 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <4FFC1D96.107@ericsson.com> <4FFC1E2E.6090509@ericsson.com> In-Reply-To: <4FFC1E2E.6090509@ericsson.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3VneWwh9/g+sTeCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIWf77IW3FOsON69i7WB8ZJUFyMnh4SAiUTr6TdMELaYxIV7 69m6GLk4hAROMUpsafrCDOEsZ5Q4Ob2BHaSKV0Bb4uCMhYwgNouAqsTcrd/AbDYBC4mbPxrZ QGxRgWCJadPvQdULSpyc+YQFxBYREJaY8fYvWI2wQKTEkh/7wWqEBNwlHjetYgaxOQV0JM79 vMsCcZGkxL321WD1zAJ6ElOutjBC2PISzVtnM0P0aks0NHWwTmAUnIVk3SwkLbOQtCxgZF7F KJybmJmTXm6ul1qUmVxcnJ+nV5y6iREYmAe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGGN3db2v37FeaKbJ0+tijkFx1efM98vffTRB8jRTscnD42xq d3sl15ZLX5kVc1EzY6HybGPv3jN+XQWSIV5aGzcbW8uarJlvp9y1Z76yZ+N5x/JOdc071fwm C8zv8f4s3XB742OFSReYXNbbeP94n9xwKej/4fn823VfrLdblCDK8ffa/PknPZVYijMSDbWY i4oTAVeG0RIaAgAA Subject: Re: [MMUSIC] BUNDLE and separate RTP and RTCP ports even when rtcp-mux is used 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, 10 Jul 2012 12:30:56 -0000 On 2012-07-10 14:21, Stefan Hakansson LK wrote: > On 07/10/2012 02:18 PM, Stefan Håkansson LK wrote: >> On 2012-07-06 09:00, Magnus Westerlund wrote: >> > On 2012-07-05 21:14, Muthu Arul Mozhi Perumal (mperumal) wrote: >> >> Hi Christer, >> >> >> >> I think the question boils down to whether the fallback port for RTCP >> >> described in section 5.1.3 of RFC5761 could be the same as the RTP >> >> port. This looks fine from a pragmatic point of view. However, the >> >> following statements from RFC5761 seem to forbid it: >> >> >> >> On receipt of the answer, the offerer looks for the presence of the >> >> "a=rtcp-mux" line for each media where multiplexing was offered. If >> >> this is present, then connectivity checks proceed as if only a >> >> single candidate (for RTP) were offered, and multiplexing is used >> >> once the session is established. If the "a=rtcp-mux" line is not >> >> present, the session proceeds with connectivity checks using both RTP >> >> and RTCP candidates, eventually leading to a session being >> >> established with RTP and RTCP on separate ports (as signalled by the >> >> "a=rtcp:" attribute). >> >> >> >> Not sure if the statement "eventually leading to a session being >> >> established with RTP and RTCP on separate ports" was intentional. If >> >> not, it needs to be fixed. >> >> >> > >> > As co-author of RFC5761 I think that sentence reflects how we perceived >> > it would be used. In other words we only thought of the current legacy, >> > not what could happen when someone made additional proposals that >> > interacts with the RTP and RTCP port multiplexing. And based on that you >> > would fall back to having different ports. >> > >> > However, I think I have found an issue that prevents one from using the >> > same port for RTP and RTCP on one side. What I can figure out there >> > exist nothing in a STUN binding request that are different between a >> > binding request targeted to the ICE candidate for component ID=0 and >> > component ID=1. If those two ICE candidates are co-located on the same >> > port then you don't know which component the binding request is targeted >> > for. It appears that the only thing keeping those separate is that the >> > different components would not be present at the same base address+port. >> >> I forgot one thing when writing this. When the offerer gets the SDP >> answer and the candidates it contains it will know the source >> address+port for any candidate that matches the ones the answerer >> provided. Thus most of the answers binding requests will be correctly >> determined and bound to the right component. Unfortunately there exist >> peer-reflexive candidates and those can't be correctly bound at this stage. > > So, now I am confused. Are we OK as is, or should the Bundle draft be > updated, or something else? (To me it sound like the Bundle draft should > be updated.) Yes, I think there is need for an update. But there is actually two issues here. One is the question of how a bundle implementation sending an offer to a non-bundle capable answerer deals with determining which m= lines particular received binding requests are related to in the case of peer-reflexive candidates. This appears to be possible to resolve by having different ufrags per m=line in the offer. The second question is how to handle RTP-RTCP mux fallback. This does not appear to be able to be resolved by using the ufrag as that is either per session level or media level. Thus some other solution is needed. One is to simply have to allocate and gather candidates for two local ports even when supporting bundle. It is at least better than 2*N where N is the number of bundled m= lines. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From mary.ietf.barnes@gmail.com Tue Jul 10 16:37:34 2012 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 9C79011E80A4; Tue, 10 Jul 2012 16:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 KCt17g5Apjgr; Tue, 10 Jul 2012 16:37:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5811E8087; Tue, 10 Jul 2012 16:37:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so649964obb.31 for ; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2eZAFEs9bEjwxfu6kVYXdKTRFE+RHAuVSMy079j8b/w=; b=kPwEeMxJX5zc/+6mwEa0OZ6umUlKlKFrLLET4PVA0CRANJZuy8fJcjSZmEy+DffeKP 2dmxv7ikOrIi7BA2MLnMNesyr1efQOfW67LqU0EVRQti51Agg27o4xOkvZeGFuGM6Jqi /BKPgmjssuQR5SCKqK4eyxhzW6qCs5V70MCcmU/qJSJkRIHAmAfVaRypb7H6kPpXyLJr AW6UerabPJw+sdKkIa71uqxer8wl4BkaUMjoHlu3/VdsXcvOr5MxsMUwjVJRVpXWUJuo 3LEOe7kmWKHbBRRR60eA/yFKQfhf3Abslm2szVLAlHp/GSo5jOVaKwGfov4Pr/8rPqZi 30lA== MIME-Version: 1.0 Received: by 10.182.14.101 with SMTP id o5mr1569393obc.1.1341963472177; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Tue, 10 Jul 2012 16:37:52 -0700 (PDT) Date: Tue, 10 Jul 2012 18:37:52 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=14dae9399bad0f88a204c482380a Subject: [MMUSIC] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) 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, 10 Jul 2012 23:37:34 -0000 --14dae9399bad0f88a204c482380a Content-Type: text/plain; charset=ISO-8859-1 Hi all, Apologies to the many of you that are receiving this multiple times. Unfortunately, the RAI list is not a superset of participants in WGs that might be interested in this. Folks that aren't on the RAI list might want to subscribe here: https://www.ietf.org/mailman/listinfo/rai Please note the important update below with regards to (no) lunch. We are planning a lunchtime tutorial on Monday, July 30th. The primary objective is to provide more background on telepresence as well as an update of the work in CLUE to the broader RAI and IETF community. This will hopefully facilitate the process of completing the CLUE protocol work as it gets broader community review. Here's the proposed outline: 1) Introduction to telepresence 2) Example telepresence scenarios 3) Introduction to the CLUE work 4) High level introduction of framework 5) One or two use cases as examples of how the CLUE framework is realized - showing how existing protocols (e.g., SDP, RTP) are integral to the solution along with additional signaling for CLUE. We have reserved a room for around 50 and attendance will be FCFS, so please RSVP by Friday, July 13th, 2012 (5pm Pacific) http://www.doodle.com/mzu3nmdeehkxkiys **Important update*: * Please note that we do not have a sponsor for lunch, thus folks will have to grab something before the tutorial (sorry, I tried). However, we will have some cookies and veggies/fruit available so folks will have something to munch. Please send any questions/comments to me (or to the CLUE WG mailing list) rather than reply all. Regards, Mary CLUE WG co-chair --14dae9399bad0f88a204c482380a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important update*: =A0Please note that we do not have = a sponsor for lunch, thus folks will have to grab something before the tuto= rial (sorry, I tried). =A0However, we will have some cookies and veggies/fr= uit available so folks will have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair

--14dae9399bad0f88a204c482380a-- From internet-drafts@ietf.org Tue Jul 10 22:00:42 2012 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 9CE5711E80CE; Tue, 10 Jul 2012 22:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWMNuROqWRDi; Tue, 10 Jul 2012 22:00:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C262A11E80C5; Tue, 10 Jul 2012 22:00:41 -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: 4.30p3 Message-ID: <20120711050041.7340.18492.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 22:00:41 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-05.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, 11 Jul 2012 05:00:42 -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 Wor= king Group of the IETF. Title : Analysis of Middlebox Interactions for Signaling Protoco= l Communication along the Media Path Author(s) : Brian Stucker Hannes Tschofenig Gonzalo Salgueiro Filename : draft-ietf-mmusic-media-path-middleboxes-05.txt Pages : 22 Date : 2012-07-10 Abstract: Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middlebox= es-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gsalguei@cisco.com Tue Jul 10 22:06:43 2012 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 8224811E8072 for ; Tue, 10 Jul 2012 22:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S44PWLWt014y for ; Tue, 10 Jul 2012 22:06:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCC211E8099 for ; Tue, 10 Jul 2012 22:06:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6B57Aa8022390 for ; Wed, 11 Jul 2012 01:07:10 -0400 (EDT) Received: from rtp-gsalguei-8718.cisco.com (rtp-gsalguei-8718.cisco.com [10.116.61.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6B576rp011954 for ; Wed, 11 Jul 2012 01:07:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Gonzalo Salgueiro In-Reply-To: <20120711050041.7340.18492.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 01:07:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4879093D-0118-40D3-9D3B-C76871C4C1E0@cisco.com> References: <20120711050041.7340.18492.idtracker@ietfa.amsl.com> To: mmusic X-Mailer: Apple Mail (2.1278) Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-middleboxes-05.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, 11 Jul 2012 05:06:43 -0000 Only the draft version number and date were updated to prevent = expiration pending WG decision on its fate. Thanks, Gonzalo On Jul 11, 2012, at 1:00 AM, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multiparty Multimedia Session Control = Working Group of the IETF. >=20 > Title : Analysis of Middlebox Interactions for = Signaling Protocol Communication along the Media Path > Author(s) : Brian Stucker > Hannes Tschofenig > Gonzalo Salgueiro > Filename : = draft-ietf-mmusic-media-path-middleboxes-05.txt > Pages : 22 > Date : 2012-07-10 >=20 > Abstract: > Middleboxes are defined as any intermediary box performing functions > apart from normal, standard functions of an IP router on the data > path between a source host and destination host. Two such functions > are network address translation and firewalling. >=20 > When Application Layer Gateways, such as SIP entities, interact with > NATs and firewalls, as described in the MIDCOM architecture, then > problems may occur in the transport of media traffic when signaling > protocol interaction takes place along the media path, as it is the > case for recent key exchange proposals (such as DTLS-SRTP). This > document highlights problems that may arise. Unfortunately, it is > difficult for the end points to detect or predict problematic > behavior and to determine whether the media path is reliably > available for packet exchange. >=20 > This document aims to summarize the various sources and effects of > NAT and firewall control, the reasons that they exist, and possible > means of improving their behavior to allow protocols that rely upon > signaling along the media path to operate effectively. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-05 >=20 > A diff from previous version is available at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-path-middlebo= xes-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 >=20 From internet-drafts@ietf.org Thu Jul 12 21:48:23 2012 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 C568821F8564; Thu, 12 Jul 2012 21:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 oLNSOSq9qEMu; Thu, 12 Jul 2012 21:48:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1521F8557; Thu, 12 Jul 2012 21:48:23 -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: 4.30p3 Message-ID: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> Date: Thu, 12 Jul 2012 21:48:23 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-19.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: Fri, 13 Jul 2012 04:48:24 -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 Wor= king Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) a= nd Real-time Transport Protocol (RTP) for Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-19.txt Pages : 33 Date : 2012-07-12 Abstract: The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media types and attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-19 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From HKaplan@acmepacket.com Thu Jul 12 22:06:21 2012 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 7863521F8715 for ; Thu, 12 Jul 2012 22:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 HS7gAPl6tbKz for ; Thu, 12 Jul 2012 22:06:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78621F871A for ; Thu, 12 Jul 2012 22:06:20 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 13 Jul 2012 01:06:50 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.199]) by Mail1.acmepacket.com ([169.254.1.55]) with mapi id 14.02.0283.003; Fri, 13 Jul 2012 01:06:50 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: I-D Action: draft-ietf-mmusic-media-loopback-19.txt Thread-Index: AQHNYLVPVyxAmX2UqUaufwlYZWXMug== Date: Fri, 13 Jul 2012 05:06:50 +0000 Message-ID: <84E88829-8A31-48ED-B77F-7C1CE9668955@acmepacket.com> References: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> In-Reply-To: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: =?us-ascii?Q?H4sIAAAAAAAAC+NgFmpkU2LjYuFiYBDVfbXmv7/BnItLPnJaXJ+3j9niwftO?= =?us-ascii?Q?FgemAIYo1sy8pPyKBNaMI0t7WQpuylfMOXSOuYGxT7KLkZNDSGAlo0Tvv5wu?= =?us-ascii?Q?Ri4gey6jxP3+xawgCTYBXYkNe9cyg9giAuoSrZv7wOLMApUStz4+ZQSxhQUc?= =?us-ascii?Q?JO7Nfc8GUeMoseHXEShbT2Jy7xH2LkYODhYBVYkv0ytBTF6gko5LohBrHSWW?= =?us-ascii?Q?P5gIVs0p4CTx5O9MsOmMAmIS30+tYYLYJC5x68l8MFtCQFti+6t9rBC2jsSm?= =?us-ascii?Q?a6tYQEZKCFhL7L4rBhEWkFiy5zwzhK0k0Xv7HVSrqMTLx/+gWvUkzpyZxAhh?= =?us-ascii?Q?B0r86XgBVW8q8WbJJRYI21bixNq/UHF3idb1C6HivhKHFi+BsuUl/t+7D2U7?= =?us-ascii?Q?SLzdtR2qXkHi54GfzDBzJq5aDmV7S1ye+gaq3kji+tcmtgmMmrOQfAlh60gs?= =?us-ascii?Q?2P2JbRbQZ8xA7c3n6iDC2hLLFr5mBrF5BQQlTs58wrKAkXUVo2hqSW5iZo5e?= =?us-ascii?Q?YnJuakFicnZqiV5yfu4mRmCSuKEpwbaD8dE39UOMkhxMSqK8PCv/+wvxJeWn?= =?us-ascii?Q?VGYkFmfEF5XmpBYfYpTg4FES4bUHJh0h3uKCxNzizHSYlAwHh5IErxxISrAo?= =?us-ascii?Q?NT21Ii0zpyS1CCJ9ilGV49rDW7cYhVjy8vNSpcR5TUAKBUBmZJTmwdVdYhSV?= =?us-ascii?Q?EuZ9vAgox1OQWpSbWQIRv8UozPGQCaoZ6FwGINBgfMUozsGoJMzLCTKLJzOv?= =?us-ascii?Q?BO6cV0CXMgFdOuvnP5BLSxIRUlINjCWv2coXxjnPYlzm2GOqpVzcInji3l9n?= =?us-ascii?Q?9Sqv5aVOO2+cWHBvfsuy2HIrlQM/TDjvnU9nvG/7x77GMvmD5InLCsEsTmdy?= =?us-ascii?Q?l8SqXjwdf3vOtoXX3UI6Jvy9nrpkdkwhi46rvVaEcLJtaOF/G7sdE5VXPFI1?= =?us-ascii?Q?rm5reSwXNuFTsvdLsQseq2Z8vL9DVYmlOCPRUIu5qDgRAPIj2UmUAwAA?= Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-19.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: Fri, 13 Jul 2012 05:06:21 -0000 Howdy, Based on the emails/comments from the WGLC, I have posted a revised media-l= oopback draft. I believe this addresses all opened issues, and in general = covers the following changes: 1) Feedback from media mime types reviewer on section 13 (now section 14). = Changes based on: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01649.html 2) Many editorial corrections from Flemming, based on: http://www.ietf.org/mail-archive/web/mmusic/current/msg09295.html 3) Non-contentious comments from Magnus have been addressed, based on: http://www.ietf.org/mail-archive/web/mmusic/current/msg09300.html 4) Congestion control issue - it appears "let the loopback source do it" wa= s the rough consensus, so it has been changed. (well... clarified) The thr= ead started here: http://www.ietf.org/mail-archive/web/mmusic/current/msg09305.html 5) Secretly replaced the fine coffee the IETF usually serves, with Folgers = Crystals. 6) SRTP is now covered in a small new section. 7) Author list has been reduced to 5 authors. If you are not happy with the changes let me know (or rather let this maili= ng list know). -hadriel On Jul 13, 2012, at 12:48 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control Wo= rking Group of the IETF. >=20 > Title : An Extension to the Session Description Protocol (SDP)= and Real-time Transport Protocol (RTP) for Media Loopback > Author(s) : Hadriel Kaplan > Kaynam Hedayat > Nagarjuna Venna > Paul E. Jones > Nathan Stratton > Filename : draft-ietf-mmusic-media-loopback-19.txt > Pages : 33 > Date : 2012-07-12 >=20 > Abstract: > The wide deployment of Voice over IP (VoIP), Text and Video over IP > services has introduced new challenges in managing and maintaining > real-time voice/text/video quality, reliability, and overall > performance. In particular, media delivery is an area that needs > attention. One method of meeting these challenges is monitoring > the media delivery performance by looping media back to the > transmitter. This is typically referred to as "active monitoring" > of services. Media loopback is especially popular in ensuring the > quality of transport to the edge of a given VoIP, Real-time Text or > Video over IP service. Today in networks that deliver real-time > media, short of running 'ping' and 'traceroute' to the edge, > administrators are left without the necessary tools to actively > monitor, manage, and diagnose quality issues with their service. > The extension defined herein adds new SDP media types and > attributes, which enable establishment of media sessions where the > media is looped back to the transmitter. Such media sessions will > serve as monitoring and troubleshooting tools by providing the > means for measurement of more advanced VoIP, Real-time Text and > Video over IP performance metrics. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-19 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-19 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 miguel.a.garcia@ericsson.com Fri Jul 13 04:28:09 2012 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 64E6421F8467 for ; Fri, 13 Jul 2012 04:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 iHJa3Q5daDt9 for ; Fri, 13 Jul 2012 04:28:08 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F0CED21F851C for ; Fri, 13 Jul 2012 04:28:07 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-a2-5000066a54d9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E3.20.03067.A6600005; Fri, 13 Jul 2012 13:28:42 +0200 (CEST) Received: from [159.107.48.161] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 13 Jul 2012 13:28:41 +0200 Message-ID: <50000663.40707@ericsson.com> Date: Fri, 13 Jul 2012 13:28:35 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> <84E88829-8A31-48ED-B77F-7C1CE9668955@acmepacket.com> In-Reply-To: <84E88829-8A31-48ED-B77F-7C1CE9668955@acmepacket.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvrW4WG0OAQfMvE4tDq/qZLTYvns9m 8f6CrsWO92dYLOZefs5uMXX5YxYHNo9NkzezeUz5vZHVY/Gm/WweS5b8ZPKYuPgTs8eXy5/Z AtiiuGxSUnMyy1KL9O0SuDLeLBAo6FGtmPtSpIFxg2wXIyeHhICJxJk1uxkhbDGJC/fWs3Ux cnEICZxilOhsvMwM4axhlHh+qocFpIpXQFNi0q6DTCA2i4CqxMZNX8DibALmEq0bN7KD2KIC wRJnPq1nh6gXlDg58wlYjYiAtsSlSVtZQYYyC3xmkrj75AUzSEJYwFPi4NH7bCC2kEC5xNbb 08CaOQWcJB7c+cIKYjML2EpcmHOdBcKWl9j+dg4zRL2mxOSbS5knMArOQrJvFpKWWUhaFjAy r2IUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECAz8g1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MChHPZbIyVY5OSNqk1xPqvvnv8vUnj13q/dElEKddVLPZ y5x3wdSDzm2VUpc91Jy+hMXfXlF+cOqdT91ZCyZGOHxw3vp2leeUzdyiJzy2zq5iv1/YWHvT aanL7ObuWSXzbGrWrXwcs1hna71Gf3Loz+cm8s5fnzjWptR8OW7KXfavt37JV8kUJZbijERD Leai4kQAmAaQG0oCAAA= Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Magnus Westerlund , mmusic , Bjoern Hoehrmann , =?ISO-8859-1?Q?Gunnar_Hellstr?= =?ISO-8859-1?Q?=F6m?= , Flemming Andreasen Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-19.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: Fri, 13 Jul 2012 11:28:09 -0000 Hi Hadriel: Thanks a lot for getting this new revision. We are almost done!!! I hereby invite those who made comments during the WGLC to verify that they are satisfied with their resolution. If we don't here any feedback within a week (July 20th), we will understand everything is correct, and we will proceed to request publication of this draft. /Miguel On 13/07/2012 7:06, Hadriel Kaplan wrote: > > Howdy, > Based on the emails/comments from the WGLC, I have posted a revised media-loopback draft. I believe this addresses all opened issues, and in general covers the following changes: > > 1) Feedback from media mime types reviewer on section 13 (now section 14). Changes based on: > http://www.ietf.org/mail-archive/web/ietf-types/current/msg01649.html > > 2) Many editorial corrections from Flemming, based on: > http://www.ietf.org/mail-archive/web/mmusic/current/msg09295.html > > 3) Non-contentious comments from Magnus have been addressed, based on: > http://www.ietf.org/mail-archive/web/mmusic/current/msg09300.html > > 4) Congestion control issue - it appears "let the loopback source do it" was the rough consensus, so it has been changed. (well... clarified) The thread started here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg09305.html > > 5) Secretly replaced the fine coffee the IETF usually serves, with Folgers Crystals. > > 6) SRTP is now covered in a small new section. > > 7) Author list has been reduced to 5 authors. > > If you are not happy with the changes let me know (or rather let this mailing list know). > > -hadriel > > > On Jul 13, 2012, at 12:48 AM, > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >> >> Title : An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback >> Author(s) : Hadriel Kaplan >> Kaynam Hedayat >> Nagarjuna Venna >> Paul E. Jones >> Nathan Stratton >> Filename : draft-ietf-mmusic-media-loopback-19.txt >> Pages : 33 >> Date : 2012-07-12 >> >> Abstract: >> The wide deployment of Voice over IP (VoIP), Text and Video over IP >> services has introduced new challenges in managing and maintaining >> real-time voice/text/video quality, reliability, and overall >> performance. In particular, media delivery is an area that needs >> attention. One method of meeting these challenges is monitoring >> the media delivery performance by looping media back to the >> transmitter. This is typically referred to as "active monitoring" >> of services. Media loopback is especially popular in ensuring the >> quality of transport to the edge of a given VoIP, Real-time Text or >> Video over IP service. Today in networks that deliver real-time >> media, short of running 'ping' and 'traceroute' to the edge, >> administrators are left without the necessary tools to actively >> monitor, manage, and diagnose quality issues with their service. >> The extension defined herein adds new SDP media types and >> attributes, which enable establishment of media sessions where the >> media is looped back to the transmitter. Such media sessions will >> serve as monitoring and troubleshooting tools by providing the >> means for measurement of more advanced VoIP, Real-time Text and >> Video over IP performance metrics. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-19 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-media-loopback-19 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 Fri Jul 13 04:37:50 2012 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 7A4B421F8762 for ; Fri, 13 Jul 2012 04:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 qk4Uiu5mUvlG for ; Fri, 13 Jul 2012 04:37:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2E5221F8742 for ; Fri, 13 Jul 2012 04:37:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-ef-500008b0a61b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BC.CC.07365.0B800005; Fri, 13 Jul 2012 13:38:24 +0200 (CEST) Received: from [159.107.48.161] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Fri, 13 Jul 2012 13:38:24 +0200 Message-ID: <500008AD.5060704@ericsson.com> Date: Fri, 13 Jul 2012 13:38:21 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvre4GDoYAg8eb9SzeX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTH562bmgqVMFQcffmBrYHzL2MXIySEhYCKx 59ICZghbTOLCvfVsXYxcHEICpxgljn05BeWsYZRY/+EzWBWvgLbE7Z2vWEFsFgFViav754JN YhMwl2jduJEdxBYVCJY482k9O0S9oMTJmU9YQGwRARmJvZs2g81hBpoz+84sJhBbWMBaYk3L P1aIuK3EhTnXWSBseYntb+eA1QsJaEpMvrmUeQIj/ywkY2chaZmFpGUBI/MqRuHcxMyc9HJD vdSizOTi4vw8veLUTYzA0Du45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwOi58cPzna9U3nHzsb3yE6+KurHzUFCX8YrK+pYbmYprvV1mcEzKNzvL1xKx 5Ouqoj8Pc34cZvwr2T/nYawdp5DDt8Jrf0+mTW9apvTxs3vZmoy82zcNWd0uvQsz8qpkTvXS qRUWPzLLW+jGs8URAcWXl1hUnLn/kl+s4u853a0lFzL2L/H80KHEUpyRaKjFXFScCAB64H7q CwIAAA== Cc: Flemming Andreasen Subject: [MMUSIC] Agenda of MMUSIC WG meeting at IETF 84 (Vancouver) 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, 13 Jul 2012 11:37:50 -0000 Greetings. The preliminary agenda for the MMUSIC WG meeting at IETF 84 in Vancouver is available: https://datatracker.ietf.org/meeting/84/agenda/mmusic/ Please send feedback to Flemming and myself. /Miguel and Flemming. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From kevin.gross@avanw.com Sat Jul 14 14:41:02 2012 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 E6D9F21F8594 for ; Sat, 14 Jul 2012 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] 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 FHMy91KovP7o for ; Sat, 14 Jul 2012 14:41:01 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id B078A21F858D for ; Sat, 14 Jul 2012 14:41:01 -0700 (PDT) Received: (qmail 19115 invoked by uid 0); 14 Jul 2012 20:43:20 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 14 Jul 2012 20:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=U96LWim3UIokEp1R5b+a1QhsGo9eEdE35HbXgrXN6OQ=; b=nGmSQNt4lW4Mr1NkegZyjz1EctCXzgoE09oNRQj0MUJjc497hNojbcPjSY2Algat+PXTbGwfknRDXnaLqNpRytepRBRlEiXGm9co8lJG9/9pH7uwpwPZSnCD+v+1wJV2; Received: from [74.125.82.172] (port=42233 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SqA5t-0003aV-6Z for mmusic@ietf.org; Sat, 14 Jul 2012 15:41:41 -0600 Received: by weyu54 with SMTP id u54so3155991wey.31 for ; Sat, 14 Jul 2012 14:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.240.196 with SMTP id e46mr1150915wer.224.1342302099900; Sat, 14 Jul 2012 14:41:39 -0700 (PDT) Received: by 10.223.72.201 with HTTP; Sat, 14 Jul 2012 14:41:39 -0700 (PDT) In-Reply-To: <50000663.40707@ericsson.com> References: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> <84E88829-8A31-48ED-B77F-7C1CE9668955@acmepacket.com> <50000663.40707@ericsson.com> Date: Sat, 14 Jul 2012 15:41:39 -0600 Message-ID: From: Kevin Gross To: "Miguel A. Garcia" Content-Type: multipart/alternative; boundary=e0cb4e43cff1d8897104c4d10f62 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" , Magnus Westerlund , mmusic , Bjoern Hoehrmann , =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= , Flemming Andreasen Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-19.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: Sat, 14 Jul 2012 21:41:03 -0000 --e0cb4e43cff1d8897104c4d10f62 Content-Type: text/plain; charset=ISO-8859-1 I am not happy about the coffee change! Kevin Gross On Fri, Jul 13, 2012 at 5:28 AM, Miguel A. Garcia < Miguel.A.Garcia@ericsson.com> wrote: > Hi Hadriel: > > Thanks a lot for getting this new revision. We are almost done!!! > > I hereby invite those who made comments during the WGLC to verify that > they are satisfied with their resolution. If we don't here any feedback > within a week (July 20th), we will understand everything is correct, and we > will proceed to request publication of this draft. > > /Miguel > > > On 13/07/2012 7:06, Hadriel Kaplan wrote: > >> >> Howdy, >> Based on the emails/comments from the WGLC, I have posted a revised >> media-loopback draft. I believe this addresses all opened issues, and in >> general covers the following changes: >> >> 1) Feedback from media mime types reviewer on section 13 (now section >> 14). Changes based on: >> http://www.ietf.org/mail-**archive/web/ietf-types/**current/msg01649.html >> >> 2) Many editorial corrections from Flemming, based on: >> http://www.ietf.org/mail-**archive/web/mmusic/current/**msg09295.html >> >> 3) Non-contentious comments from Magnus have been addressed, based on: >> http://www.ietf.org/mail-**archive/web/mmusic/current/**msg09300.html >> >> 4) Congestion control issue - it appears "let the loopback source do it" >> was the rough consensus, so it has been changed. (well... clarified) The >> thread started here: >> http://www.ietf.org/mail-**archive/web/mmusic/current/**msg09305.html >> >> 5) Secretly replaced the fine coffee the IETF usually serves, with >> Folgers Crystals. >> >> 6) SRTP is now covered in a small new section. >> >> 7) Author list has been reduced to 5 authors. >> >> If you are not happy with the changes let me know (or rather let this >> mailing list know). >> >> -hadriel >> >> >> On Jul 13, 2012, at 12:48 AM, >> wrote: >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Multiparty Multimedia Session Control >>> Working Group of the IETF. >>> >>> Title : An Extension to the Session Description >>> Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback >>> Author(s) : Hadriel Kaplan >>> Kaynam Hedayat >>> Nagarjuna Venna >>> Paul E. Jones >>> Nathan Stratton >>> Filename : draft-ietf-mmusic-media-**loopback-19.txt >>> Pages : 33 >>> Date : 2012-07-12 >>> >>> Abstract: >>> The wide deployment of Voice over IP (VoIP), Text and Video over IP >>> services has introduced new challenges in managing and maintaining >>> real-time voice/text/video quality, reliability, and overall >>> performance. In particular, media delivery is an area that needs >>> attention. One method of meeting these challenges is monitoring >>> the media delivery performance by looping media back to the >>> transmitter. This is typically referred to as "active monitoring" >>> of services. Media loopback is especially popular in ensuring the >>> quality of transport to the edge of a given VoIP, Real-time Text or >>> Video over IP service. Today in networks that deliver real-time >>> media, short of running 'ping' and 'traceroute' to the edge, >>> administrators are left without the necessary tools to actively >>> monitor, manage, and diagnose quality issues with their service. >>> The extension defined herein adds new SDP media types and >>> attributes, which enable establishment of media sessions where the >>> media is looped back to the transmitter. Such media sessions will >>> serve as monitoring and troubleshooting tools by providing the >>> means for measurement of more advanced VoIP, Real-time Text and >>> Video over IP performance metrics. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/**doc/draft-ietf-mmusic-media-**loopback >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/**draft-ietf-mmusic-media-**loopback-19 >>> >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?**url2=draft-ietf-mmusic-media-** >>> loopback-19 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-**drafts/ >>> >>> ______________________________**_________________ >>> 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 >>> >> >> ______________________________**_________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/**listinfo/mmusic >> >> >> > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > > > > ______________________________**_________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/**listinfo/mmusic > --e0cb4e43cff1d8897104c4d10f62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not happy about the coffee change!

Kevin Gross

On Fri, Jul 13, 2012 at 5:28 AM= , Miguel A. Garcia <Miguel.A.Garcia@ericsson.com>= wrote:
Hi Hadriel:

Thanks a lot for getting this new revision. We are almost done!!!

I hereby invite those who made comments during the WGLC to verify that they= are satisfied with their resolution. If we don't here any feedback wit= hin a week (July 20th), we will understand everything is correct, and we wi= ll proceed to request publication of this draft.

/Miguel


On 13/07/2012 7:06, Hadriel Kaplan wrote:

Howdy,
Based on the emails/comments from the WGLC, I have posted a revised media-l= oopback draft. =A0I believe this addresses all opened issues, and in genera= l covers the following changes:

1) Feedback from media mime types reviewer on section 13 (now section 14). = =A0Changes based on:
http://www.ietf.org/mail-archive/web/ietf-t= ypes/current/msg01649.html

2) Many editorial corrections from Flemming, based on:
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg09295.html

3) Non-contentious comments from Magnus have been addressed, based on:
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg09300.html

4) Congestion control issue - it appears "let the loopback source do i= t" was the rough consensus, so it has been changed. (well... clarified= ) =A0The thread started here:
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg09305.html

5) Secretly replaced the fine coffee the IETF usually serves, with Folgers = Crystals.

6) SRTP is now covered in a small new section.

7) Author list has been reduced to 5 authors.

If you are not happy with the changes let me know (or rather let this maili= ng list know).

-hadriel


On Jul 13, 2012, at 12:48 AM, <internet-drafts@ietf.org>
=A0 <inter= net-drafts@ietf.org> wrote:


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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session Des= cription Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Lo= opback
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Hadriel Kaplan
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kaynam Hedayat
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nagarjuna Venna
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul E. Jones
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nathan Stratton
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-mmusic-media-lo= opback-19.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 33
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-07-12

Abstract:
=A0 =A0 The wide deployment of Voice over IP (VoIP), Text and Video over IP=
=A0 =A0 services has introduced new challenges in managing and maintaining<= br> =A0 =A0 real-time voice/text/video quality, reliability, and overall
=A0 =A0 performance. =A0In particular, media delivery is an area that needs=
=A0 =A0 attention. =A0One method of meeting these challenges is monitoring<= br> =A0 =A0 the media delivery performance by looping media back to the
=A0 =A0 transmitter. =A0This is typically referred to as "active monit= oring"
=A0 =A0 of services. =A0 Media loopback is especially popular in ensuring t= he
=A0 =A0 quality of transport to the edge of a given VoIP, Real-time Text or=
=A0 =A0 Video over IP service. =A0Today in networks that deliver real-time<= br> =A0 =A0 media, short of running 'ping' and 'traceroute' to = the edge,
=A0 =A0 administrators are left without the necessary tools to actively
=A0 =A0 monitor, manage, and diagnose quality issues with their service. =A0 =A0 The extension defined herein adds new SDP media types and
=A0 =A0 attributes, which enable establishment of media sessions where the<= br> =A0 =A0 media is looped back to the transmitter. Such media sessions will =A0 =A0 serve as monitoring and troubleshooting tools by providing the
=A0 =A0 means for measurement of more advanced VoIP, Real-time Text and
=A0 =A0 Video over IP performance metrics.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmu= sic-media-loopback

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-media= -loopback-19

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-mmusic-media-loopback-19


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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

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



--
Miguel A. Garcia
= +34-91-339-3608
Ericsson Spain



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

--e0cb4e43cff1d8897104c4d10f62-- From ari.keranen@nomadiclab.com Mon Jul 16 03:31:46 2012 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 D2EDB21F87B5 for ; Mon, 16 Jul 2012 03:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KYRBxOO7KUFk for ; Mon, 16 Jul 2012 03:31:46 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E834821F87A9 for ; Mon, 16 Jul 2012 03:31:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 8CF8D4E6E9 for ; Mon, 16 Jul 2012 13:32:28 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSh7bSxMhJcY for ; Mon, 16 Jul 2012 13:32:28 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id D81234E6E1 for ; Mon, 16 Jul 2012 13:32:26 +0300 (EEST) Message-ID: <5003ED8E.8060506@nomadiclab.com> Date: Mon, 16 Jul 2012 13:31:42 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic References: <20120716095713.25805.35392.idtracker@ietfa.amsl.com> In-Reply-To: <20120716095713.25805.35392.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120716095713.25805.35392.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-keranen-mmusic-ice-address-selection-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, 16 Jul 2012 10:31:46 -0000 Folks, We have updated the ICE address selection update draft according to comments given at the previous meeting. Give it a read and let us know what you think. Cheers, Ari -------- Original Message -------- Subject: New Version Notification for draft-keranen-mmusic-ice-address-selection-01.txt Date: Mon, 16 Jul 2012 11:57:13 +0200 A new version of I-D, draft-keranen-mmusic-ice-address-selection-01.txt has been successfully submitted by Ari Keranen and posted to the IETF repository. Filename: draft-keranen-mmusic-ice-address-selection Revision: 01 Title: Update on Candidate Address Selection for Interactive Connectivity Establishment (ICE) Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-keranen-mmusic-ice-address-selection-01.txt Status: http://datatracker.ietf.org/doc/draft-keranen-mmusic-ice-address-selection Htmlized: http://tools.ietf.org/html/draft-keranen-mmusic-ice-address-selection-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-keranen-mmusic-ice-address-selection-01 Abstract: This document revisits the rules on how candidate addresses are selected and combined when the Interactive Connectivity Establishment (ICE) NAT traversal method is used. This document updates RFCs 5245 and 6544. The IETF Secretariat From internet-drafts@ietf.org Mon Jul 16 12:51:34 2012 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 F29A621F8731; Mon, 16 Jul 2012 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 5NLQP5wR6eN0; Mon, 16 Jul 2012 12:51:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB41221F87C0; Mon, 16 Jul 2012 12:51:32 -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: 4.30p3 Message-ID: <20120716195132.1662.16487.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 12:51:32 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc2326bis-30.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, 16 Jul 2012 19:51:34 -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 Wor= king Group of the IETF. Title : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-30.txt Pages : 301 Date : 2012-07-16 Abstract: This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-30 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc2326bis-30 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Martin.Stiemerling@neclab.eu Mon Jul 16 12:58:13 2012 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 B676C21F88BA for ; Mon, 16 Jul 2012 12:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 wJ3I0jn001n8 for ; Mon, 16 Jul 2012 12:58:13 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CEACE21F87D6 for ; Mon, 16 Jul 2012 12:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 917A310185E for ; Mon, 16 Jul 2012 22:01:54 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-RpZlF-A3u1 for ; Mon, 16 Jul 2012 22:01:54 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 79E6D10185B for ; Mon, 16 Jul 2012 22:01:49 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 21:59:20 +0200 Message-ID: <50047266.1090807@neclab.eu> Date: Mon, 16 Jul 2012 21:58:30 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: References: <20120716195132.1662.16487.idtracker@ietfa.amsl.com> In-Reply-To: <20120716195132.1662.16487.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120716195132.1662.16487.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [MMUSIC] Fwd: I-D Action: draft-ietf-mmusic-rfc2326bis-30.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, 16 Jul 2012 19:58:13 -0000 Hi there, This updated version of draft-ietf-mmusic-rfc2326bis-30.txt addresses the comments of the WGLC. Regards, Martin -------- Original Message -------- Subject: I-D Action: draft-ietf-mmusic-rfc2326bis-30.txt Date: Mon, 16 Jul 2012 12:51:32 -0700 From: Reply-To: To: CC: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol 2.0 (RTSP) Author(s) : Henning Schulzrinne Anup Rao Rob Lanphier Magnus Westerlund Martin Stiemerling Filename : draft-ietf-mmusic-rfc2326bis-30.txt Pages : 301 Date : 2012-07-16 Abstract: This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-30 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc2326bis-30 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From internet-drafts@ietf.org Mon Jul 16 16:03:00 2012 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 5842B21F882D; Mon, 16 Jul 2012 16:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smu47jP3ekiO; Mon, 16 Jul 2012 16:02:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D3321F8827; Mon, 16 Jul 2012 16:02:59 -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: 4.30p3 Message-ID: <20120716230259.27904.78434.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:02:59 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-traffic-class-for-sdp-02.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, 16 Jul 2012 23:03:00 -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 Wor= king Group of the IETF. Title : The Session Description Protocol (SDP) 'trafficclass' At= tribute Author(s) : James Polk Subha Dhesikan Paul E. Jones Filename : draft-ietf-mmusic-traffic-class-for-sdp-02.txt Pages : 21 Date : 2012-07-16 Abstract: This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-traffic-class-for-sdp-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-traffic-class-for-sd= p-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmpolk@cisco.com Tue Jul 17 12:18:42 2012 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 29F8921F8665 for ; Tue, 17 Jul 2012 12:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 89Xu9sVhvnWn for ; Tue, 17 Jul 2012 12:18:40 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 750C621F8649 for ; Tue, 17 Jul 2012 12:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1230; q=dns/txt; s=iport; t=1342552767; x=1343762367; h=message-id:date:to:from:subject:mime-version; bh=ohOk8K1UtYoDhWsiu2yu/y6bmUjFvZRfsy5Ve2Ab9/Q=; b=mAtSJDbXgMYbh1qAzGLr458lfnJ1vKLTtNIDJRHBlVUl7e4alGQl39Ka qS+vZI1n0TqFbiHb7MdbeY8oPjbt0KpyutjmM81A3uVBP9FyWHHoJw6Zb UhB+GL7+H/SGhXisaW+HSQ22DwHf+3QGx2LtWBQzZf5JdkCiLhCRo9GaQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANK5BVCrRDoI/2dsb2JhbABFuQSBB4I5ASUCVjopRDWHagybaYEooDIEkg8DiEubFIFmgn0 X-IronPort-AV: E=Sophos;i="4.77,604,1336348800"; d="scan'208";a="52208512" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 17 Jul 2012 19:19:27 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6HJJQij014492 for ; Tue, 17 Jul 2012 19:19:26 GMT Message-Id: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Jul 2012 14:19:23 -0500 To: mmusic From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Trafficclass Attribute -02 submitted 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, 17 Jul 2012 19:18:42 -0000 MMUSIC We've submitted a revision of the Traffic Class Label attribute here https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp These are the following changes made between the WG -01 version and the -02 version: - converged the use of terms 'parent' and 'category' to just 'category' for consistency. - changed ABNF to reflect extensibility by not having applications and adjectives named in the ABNF, rather have them merely IANA registered. This was brought up on the list and in the Paris meeting. - merged the qualified and unqualified adjective sections into a single section on adjectives, but allowing some to have a preceding qualifier. This was brought up on the list and in the Paris meeting. - text clean-up We have one known open issue, which is related to some document structure around the categories, applications and adjectives. We have another known open issue regarding articulating better which adjectives are appropriate with which applications, as well as which applications are appropriate with which categories. Other comments and questions are solicited. James/Subha/Paul From kevin.gross@avanw.com Tue Jul 17 14:30:19 2012 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 D0A6311E80AD for ; Tue, 17 Jul 2012 14:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.473 X-Spam-Level: * X-Spam-Status: No, score=1.473 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.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 ebqlJL9UgCVc for ; Tue, 17 Jul 2012 14:30:19 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 2F10F11E80A4 for ; Tue, 17 Jul 2012 14:30:19 -0700 (PDT) Received: (qmail 24436 invoked by uid 0); 17 Jul 2012 21:31:07 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 17 Jul 2012 21:31:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=QKx8o8vA1fvvW5RnhaThsOVnX4sPnRuKnvwFvKdyClI=; b=cWJRpv+j2xebsSlvPL8qydSZ2NcEzRJ/WRxCOhVQz4KcziplSPg+vyGrzTKTduxs7IAvyo1FRWecCCDuqrN+fRuGrzizNSblV/P6EvXFRnXlUwp//ZwMfXAWi/7C9i33; Received: from [209.85.212.178] (port=64058 helo=mail-wi0-f178.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SrFMJ-0008G7-5d for mmusic@ietf.org; Tue, 17 Jul 2012 15:31:07 -0600 Received: by wibhr14 with SMTP id hr14so662136wib.13 for ; Tue, 17 Jul 2012 14:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.92.133 with SMTP id j5mr257150wef.38.1342560665867; Tue, 17 Jul 2012 14:31:05 -0700 (PDT) Received: by 10.223.72.201 with HTTP; Tue, 17 Jul 2012 14:31:05 -0700 (PDT) Date: Tue, 17 Jul 2012 15:31:05 -0600 Message-ID: From: Kevin Gross To: mmusic Content-Type: multipart/alternative; boundary=e0cb4e6ffbf79416a604c50d43c4 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.212.178 authed with kevin.gross@avanw.com} Subject: [MMUSIC] ptime precision 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, 17 Jul 2012 21:30:19 -0000 --e0cb4e6ffbf79416a604c50d43c4 Content-Type: text/plain; charset=ISO-8859-1 I am working on a high-performance RTP application (see www.x192.org) which will, in some cases, use packet times less than 1 millisecond to achieve very low latencies for live sound over high-performance local-area networks. We'd like to signal and negotiate the packet time in these applications. Unfortunately, the millisecond units of a=ptime are too coarse for this application. I've read draft-garcia-mmusic-multiple-ptimes-problem which alerted me to a=vsel in RFC 3108 which specifies packet time in units of microseconds. Unfortunately, we're not sure that microsecond resolution is sufficient as there are some useful packet times which are not an integer number of microseconds. We are currently considering using this anyway and rounding to the nearest microsecond. But, two of us working on this shortcoming have independently come to the conclusion that the most versatile way to express packet time is in units of RTP clock ticks. The RTP clock time is an 32-bit integer and appears in the header of every RTP packet. Packet time under this proposed definition is, roughly speaking, the difference in RTP clocks on successive RTP packets. There is no precision issue as, by this definition, the packet time will always be an integer. Does this seem like a good idea? Does something like this already exist? Are there any other alternatives that I haven't uncovered? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --e0cb4e6ffbf79416a604c50d43c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am working on a high-performance RTP application (see www.x192.org) which will, in some cases, use packet times = less than 1 millisecond to achieve very low latencies for live sound over h= igh-performance local-area networks. We'd like to signal and negotiate = the packet time in these applications.

Unfortunately, the millisecond units of a=3Dptime are too co= arse for this application. I've read=A0draft-garcia-mmusic-multiple-pti= mes-problem which alerted me to a=3Dvsel in RFC 3108 which specifies packet= time in units of microseconds.=A0Unfortunately, we're not sure that=A0= microsecond=A0resolution is sufficient as there are some useful packet time= s which are not an integer number of microseconds. We are currently conside= ring using this anyway and rounding to the nearest microsecond.

But, two of us working on this shortcoming have indepen= dently come to the conclusion that the most=A0versatile=A0way to express pa= cket time is in units of RTP clock ticks. The RTP clock time is an 32-bit i= nteger and appears in the header of every RTP packet. Packet time under thi= s proposed definition is, roughly speaking, the difference in RTP clocks on= =A0successive=A0RTP packets. There is no=A0precision=A0issue as, by this de= finition, the packet time will always be an integer.

Does this seem like a good idea?=A0Does something like = this already exist?=A0Are there any other alternatives that I haven't u= ncovered?

Kevin Gross
+1-303-447-0517=
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

--e0cb4e6ffbf79416a604c50d43c4-- From pkyzivat@alum.mit.edu Tue Jul 17 14:39:40 2012 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 8C5D021F8565 for ; Tue, 17 Jul 2012 14:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 aG7yvp+Njccw for ; Tue, 17 Jul 2012 14:39:39 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC1B21F8559 for ; Tue, 17 Jul 2012 14:39:39 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id bNzc1j0050SCNGk59ZgWMa; Tue, 17 Jul 2012 21:40:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id bZga1j00L3ZTu2S3VZgact; Tue, 17 Jul 2012 21:40:34 +0000 Message-ID: <5005DBCA.8040405@alum.mit.edu> Date: Tue, 17 Jul 2012 17:40:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> In-Reply-To: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted 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, 17 Jul 2012 21:39:40 -0000 Some comments on the new version: In section 3 (SDP syntax): tcl-token = %2D / %30-%39 / %41-%5A / %61-7A That only allows one character tokens. Minimally you probably want: tcl-token = 1*(%2D / %30-%39 / %41-%5A / %61-7A) But it would be more readable as: tcl-token = 1*( ALPHA / DIGIT / "-" ) (Those symbols are defined with ABNF in RFC 5234. If so you need a reference. Paraphrasing 3261, you might say: "Appendix B.1 of RFC 5234 defines a set of core rules that are used by this specification, and not repeated here.") But that allows leading and trailing, and multiple consecutive "-"s. So you could tighten it up with: tcl-token = ALPHA 0*(ALPHA / DIGIT) 0*("-" 1*(ALPHA / DIGIT)) Also, your syntax doesn't cover non-standard-adjectives. You could cover that by: adjective = standard-adjective / non-standard-adjective standard-adjective = classified-adjective / unclassified-adjective non-standard-adjective = "_" standard-adjective Sections 6.3 & 6.4: "Specification Required" implies expert review. That in turn calls for some criteria by which the expert can decide if a proposed value is appropriate to be registered. IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not* Unqualified adjectives. Rather, 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified* adjectives. Does the distinction matter for registration? Should there be different criteria for registering new qualified adjectives? Maybe so. Maybe there should be some review of whether the new 'aq:foo' is compatible with the intended meaning of 'aq'??? Thanks, Paul On 7/17/12 3:19 PM, James Polk wrote: > MMUSIC > > We've submitted a revision of the Traffic Class Label attribute here > https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp > > These are the following changes made between the WG -01 version and > the -02 version: > > - converged the use of terms 'parent' and 'category' to just > 'category' for consistency. > > - changed ABNF to reflect extensibility by not having applications > and adjectives named in the ABNF, rather have them merely IANA > registered. This was brought up on the list and in the Paris > meeting. > > - merged the qualified and unqualified adjective sections into a > single section on adjectives, but allowing some to have a > preceding qualifier. This was brought up on the list and in the > Paris meeting. > > - text clean-up > > We have one known open issue, which is related to some document > structure around the categories, applications and adjectives. > > We have another known open issue regarding articulating better which > adjectives are appropriate with which applications, as well as which > applications are appropriate with which categories. > > Other comments and questions are solicited. > > James/Subha/Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From kevin.gross@avanw.com Tue Jul 17 16:56:45 2012 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 C76DE11E80D2 for ; Tue, 17 Jul 2012 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.506 X-Spam-Level: * X-Spam-Status: No, score=1.506 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 bk+Mu6W1K+62 for ; Tue, 17 Jul 2012 16:56:45 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 3083511E80E4 for ; Tue, 17 Jul 2012 16:56:45 -0700 (PDT) Received: (qmail 24231 invoked by uid 0); 17 Jul 2012 23:57:33 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy2.bluehost.com with SMTP; 17 Jul 2012 23:57:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:MIME-Version; bh=RVOUBxYIxHCtPXXCB062/dn8coUVLVfN2WztC9k96/8=; b=QttQ5P3dKUU1q5lxHbVH1KB3jvXl7NuhLYF27JKWxiw6GpCjrOiMz9BjU0FVlWoiTCgth1FZZOq2O34qKIQuGbvWjKzxjqk4Ztf4DMIxmiZbMOG5pyoYrc90B/V5zxrp; Received: from [209.85.217.172] (port=53741 helo=mail-lb0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SrHe1-0003JP-5P for mmusic@ietf.org; Tue, 17 Jul 2012 17:57:33 -0600 Received: by lbbgo11 with SMTP id go11so1481228lbb.31 for ; Tue, 17 Jul 2012 16:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.104.77 with SMTP id gc13mr975040lab.31.1342569451560; Tue, 17 Jul 2012 16:57:31 -0700 (PDT) Received: by 10.112.100.34 with HTTP; Tue, 17 Jul 2012 16:57:31 -0700 (PDT) Date: Tue, 17 Jul 2012 17:57:31 -0600 Message-ID: From: Kevin Gross To: mmusic Content-Type: multipart/alternative; boundary=f46d04083adb3f1f0c04c50f4f54 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.217.172 authed with kevin.gross@avanw.com} Subject: [MMUSIC] Channel descriptions 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, 17 Jul 2012 23:56:45 -0000 --f46d04083adb3f1f0c04c50f4f54 Content-Type: text/plain; charset=ISO-8859-1 The i= attribute provides a means to describe a session. Sessions often have multiple media streams or channels. Although RFC 3551 (page 8) suggests a convention for ordering of channels for surround sound applications, other applications use multiple channels in different ways. It would be useful if there were a mechanism analogous to i= for describing individual channels in a session. Does such a thing exist anywhere? I've searched the archives here and didn't find anything. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org --f46d04083adb3f1f0c04c50f4f54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The i=3D attribute provides a means to describe a session. Sessions often h= ave multiple media streams or channels. Although RFC 3551 (page 8) suggests= a convention for ordering of channels for surround sound applications, oth= er applications use multiple channels in different ways. It would be useful= if there were a mechanism analogous to i=3D for describing individual chan= nels in a session. Does such a thing exist anywhere? I've searched the = archives here and didn't find anything.

Kevin Gross
+1-303-447-0517
Media Netwo= rk Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

--f46d04083adb3f1f0c04c50f4f54-- From eckelcu@cisco.com Wed Jul 18 08:57:53 2012 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 C6BCE11E808F for ; Wed, 18 Jul 2012 08:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 ztAcSwCKcsct for ; Wed, 18 Jul 2012 08:57:52 -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 A507F21F8738 for ; Wed, 18 Jul 2012 08:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1213; q=dns/txt; s=iport; t=1342627123; x=1343836723; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9k7DdEEOT/6xH32GAVGEoR5oEtInxAPn6EVCkaWKPqg=; b=EF2cpJvr9nhPAPxTRdjo91fTaos2OyK8VfZJ0CQUeBQE902CgOJkJMK2 ur5mP+YDsGNeSD4j3iZFEXqNzGYLVdFoqBJGbh5UBMsH7tMAfBnCr+Nqm A6neiCTS026tOyPqYdkZ0lxI5pskjcIcHKhmUdf/UWgizwTivUO5o14/x o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABncBlCtJXHA/2dsb2JhbABCA7kzgQeCIAEBAQQSAScPPAQCAQgHCgQBAQsUCQcyFAkIAgQBEggah2oBngegIYtAgy6CQWADo2eBZoJf X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208";a="103087231" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2012 15:58:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6IFwgPh021963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 15:58:42 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 10:58:42 -0500 From: "Charles Eckel (eckelcu)" To: Kevin Gross , mmusic Thread-Topic: [MMUSIC] Channel descriptions Thread-Index: AQHNZHfyc1XdTdXTo0CfyBNZ0pB4ZJcvMZ+g Date: Wed, 18 Jul 2012 15:58:42 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803F488@xmb-aln-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--42.279700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Channel descriptions 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, 18 Jul 2012 15:57:53 -0000 Hi Kevin, Just to clarify my understanding of what you are asking, you can already ha= ve an i-line at the session level and/or at the media level (i.e. per m-lin= e). Are you looking for something that lets you differentiate between multi= ple channels within a single m-line? Cheers, Charles =20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Kevin Gross > Sent: Tuesday, July 17, 2012 4:58 PM > To: mmusic > Subject: [MMUSIC] Channel descriptions >=20 > The i=3D attribute provides a means to describe a session. Sessions often= have > multiple media streams or channels. Although RFC 3551 (page 8) suggests a > convention for ordering of channels for surround sound applications, othe= r > applications use multiple channels in different ways. It would be useful = if > there were a mechanism analogous to i=3D for describing individual channe= ls > in a session. Does such a thing exist anywhere? I've searched the archive= s > here and didn't find anything. >=20 > Kevin Gross >=20 > +1-303-447-0517 > Media Network Consultant >=20 > AVA Networks - www.AVAnw.com , > www.X192.org From kevin.gross@avanw.com Wed Jul 18 10:34:38 2012 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 9D99C11E8147 for ; Wed, 18 Jul 2012 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.996 X-Spam-Level: X-Spam-Status: No, score=0.996 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RDNS_NONE=0.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 39KrUpKYt+CX for ; Wed, 18 Jul 2012 10:34:38 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 00C8B11E8133 for ; Wed, 18 Jul 2012 10:34:37 -0700 (PDT) Received: (qmail 13557 invoked by uid 0); 18 Jul 2012 17:35:28 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 18 Jul 2012 17:35:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=G+q36SZjf4cWCTHEu8c0BS95W+ic/SK2JyzFMz1C6VQ=; b=lF8lWYqRIifXqMUVG+1/qG2TPnHyMByRQsD3tujNf+ifhy/hwd6x3zCRSJoudaycCBzULsHrYPnHNUgsS9m12pfpuB+q6qqyXfYbYsswGWeHdEF4rwxCvWMXQR9zhdZt; Received: from [209.85.212.178] (port=37197 helo=mail-wi0-f178.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SrY9o-0001CF-2j for mmusic@ietf.org; Wed, 18 Jul 2012 11:35:28 -0600 Received: by wibhr14 with SMTP id hr14so1338312wib.13 for ; Wed, 18 Jul 2012 10:35:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.81.138 with SMTP id a10mr8532891wiy.7.1342632926806; Wed, 18 Jul 2012 10:35:26 -0700 (PDT) Received: by 10.223.72.201 with HTTP; Wed, 18 Jul 2012 10:35:26 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882803F488@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C0882803F488@xmb-aln-x08.cisco.com> Date: Wed, 18 Jul 2012 11:35:26 -0600 Message-ID: From: Kevin Gross To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=f46d044401baaa829704c51e16cb X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.212.178 authed with kevin.gross@avanw.com} Cc: mmusic Subject: Re: [MMUSIC] Channel descriptions 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, 18 Jul 2012 17:34:38 -0000 --f46d044401baaa829704c51e16cb Content-Type: text/plain; charset=ISO-8859-1 Yes. For a multichannel media specification such as: m=audio 49152 RTP/AVP 96 i=Channels 1-8 a=rtpmap:96 L24/48000/8 a=sendonly I get one description ("Channels 1-8") for all 8 channels in this stream. I'd like to also have the ability to supply a description per channel. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Jul 18, 2012 at 9:58 AM, Charles Eckel (eckelcu) wrote: > Hi Kevin, > > Just to clarify my understanding of what you are asking, you can already > have an i-line at the session level and/or at the media level (i.e. per > m-line). Are you looking for something that lets you differentiate between > multiple channels within a single m-line? > > Cheers, > Charles > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Kevin Gross > > Sent: Tuesday, July 17, 2012 4:58 PM > > To: mmusic > > Subject: [MMUSIC] Channel descriptions > > > > The i= attribute provides a means to describe a session. Sessions often > have > > multiple media streams or channels. Although RFC 3551 (page 8) suggests a > > convention for ordering of channels for surround sound applications, > other > > applications use multiple channels in different ways. It would be useful > if > > there were a mechanism analogous to i= for describing individual channels > > in a session. Does such a thing exist anywhere? I've searched the > archives > > here and didn't find anything. > > > > Kevin Gross > > > > +1-303-447-0517 > > Media Network Consultant > > > > AVA Networks - www.AVAnw.com , > > www.X192.org > > --f46d044401baaa829704c51e16cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes. For a multichannel media specification such as:
m=3Daudio 4915= 2 RTP/AVP 96
i=3DChannels 1-8
a=3Drtpmap:96 L24/48000/8=
a=3Dsendonly
I get one description ("Channels 1= -8") for all 8 channels in this stream. I'd like to also have the = ability to supply a description per channel.

Kevin G= ross
+1-303-447-0517
Media Network Consultant
AVA Network= s -=A0www.AVAnw.com= ,=A0www.X192.org



On Wed, Jul 18, 2012 at 9:58 AM, Charles= Eckel (eckelcu) <eckelcu@cisco.com> wrote:
Hi Kevin,

Just to clarify my understanding of what you are asking, you can already ha= ve an i-line at the session level and/or at the media level (i.e. per m-lin= e). Are you looking for something that lets you differentiate between multi= ple channels within a single m-line?

Cheers,
Charles

> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On
> Behalf Of Kevin Gross
> Sent: Tuesday, July 17, 2012 4:58 PM
> To: mmusic
> Subject: [MMUSIC] Channel descriptions
>
> The i=3D attribute provides a means to describe a session. Sessions of= ten have
> multiple media streams or channels. Although RFC 3551 (page 8) suggest= s a
> convention for ordering of channels for surround sound applications, o= ther
> applications use multiple channels in different ways. It would be usef= ul if
> there were a mechanism analogous to i=3D for describing individual cha= nnels
> in a session. Does such a thing exist anywhere? I've searched the = archives
> here and didn't find anything.
>
> Kevin Gross
>
> +1-303-447-05= 17
> Media Network Consultant
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/> ,
> www.X192.org


--f46d044401baaa829704c51e16cb-- From eckelcu@cisco.com Wed Jul 18 15:02:33 2012 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 B269411E8157 for ; Wed, 18 Jul 2012 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.927 X-Spam-Level: X-Spam-Status: No, score=-9.927 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, 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 P46o4GloRp4A for ; Wed, 18 Jul 2012 15:02:32 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFB311E8087 for ; Wed, 18 Jul 2012 15:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2571; q=dns/txt; s=iport; t=1342649004; x=1343858604; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JMd56IWiqYG4NqWOMdaA1WU8oM5zD74+CxTlhHYpf0c=; b=BgIetV94QmRiYsMb2EkyQRsDM4la7sMzEjDlyEl6DkNGES0bgzbYrrzH CizJsMziPmBEAadJhGSkiOLXDGnzcryovqURtx7DNvDobsz5TqdiYMtXW 0KxVC7JW+eUN6o5mcboCXCxGdk97U2eCbBSjdrCxWneNYJllNLkwG2var 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACEyB1CtJXHB/2dsb2JhbABCA7k6gQeCIAEBAQQSAScPMAwEAgEIBwoEAQEBChQJBzIUCQgCBA4FCBqHagGeBqAji0CDb4JBYAOjZ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,611,1336348800"; d="scan'208";a="103198775" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jul 2012 22:03:23 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6IM3N48010918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 22:03:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 17:03:23 -0500 From: "Charles Eckel (eckelcu)" To: Kevin Gross Thread-Topic: [MMUSIC] Channel descriptions Thread-Index: AQHNZHfyc1XdTdXTo0CfyBNZ0pB4ZJcvMZ+ggABwsQD///SC4A== Date: Wed, 18 Jul 2012 22:03:22 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803F8CB@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C0882803F488@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.000 x-tm-as-result: No--53.459700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mmusic Subject: Re: [MMUSIC] Channel descriptions 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, 18 Jul 2012 22:02:33 -0000 It looks as if RFC 3190 defines some conventions for the channels for L24. Otherwise, perhaps an extension to RFC 5576, assuming you are using differe= nt SSRCs for each channel. In general, there are ongoing discussions ongoing in AVTCORE, RTCWEB, and C= LUE regarding multiplexing and some mechanism to describe the multiplexed s= treams will likely result. Cheers, Charles > -----Original Message----- > From: Kevin Gross [mailto:kevin.gross@avanw.com] > Sent: Wednesday, July 18, 2012 10:35 AM > To: Charles Eckel (eckelcu) > Cc: mmusic > Subject: Re: [MMUSIC] Channel descriptions >=20 > Yes. For a multichannel media specification such as: >=20 >=20 > m=3Daudio 49152 RTP/AVP 96 > i=3DChannels 1-8 > a=3Drtpmap:96 L24/48000/8 > a=3Dsendonly >=20 > I get one description ("Channels 1-8") for all 8 channels in this stream.= I'd > like to also have the ability to supply a description per channel. >=20 >=20 > Kevin Gross >=20 > +1-303-447-0517 > Media Network Consultant >=20 > AVA Networks - www.AVAnw.com , > www.X192.org >=20 >=20 >=20 > On Wed, Jul 18, 2012 at 9:58 AM, Charles Eckel (eckelcu) > wrote: >=20 >=20 > Hi Kevin, >=20 > Just to clarify my understanding of what you are asking, you can > already have an i-line at the session level and/or at the media level (i.= e. per > m-line). Are you looking for something that lets you differentiate betwee= n > multiple channels within a single m-line? >=20 > Cheers, > Charles >=20 >=20 > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic- > bounces@ietf.org] On > > Behalf Of Kevin Gross > > Sent: Tuesday, July 17, 2012 4:58 PM > > To: mmusic > > Subject: [MMUSIC] Channel descriptions > > > > The i=3D attribute provides a means to describe a session. Sessions > often have > > multiple media streams or channels. Although RFC 3551 (page 8) > suggests a > > convention for ordering of channels for surround sound > applications, other > > applications use multiple channels in different ways. It would be > useful if > > there were a mechanism analogous to i=3D for describing individual > channels > > in a session. Does such a thing exist anywhere? I've searched the > archives > > here and didn't find anything. > > > > Kevin Gross > > > > +1-303-447-0517 > > Media Network Consultant > > >=20 > > AVA Networks - www.AVAnw.com , > > www.X192.org >=20 >=20 >=20 From pkyzivat@alum.mit.edu Thu Jul 19 10:31:34 2012 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 5FE6F21F87E7 for ; Thu, 19 Jul 2012 10:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 mmUIornryMpI for ; Thu, 19 Jul 2012 10:31:33 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 24A8821F87D4 for ; Thu, 19 Jul 2012 10:31:32 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id cGbj1j0021c6gX85BHYStJ; Thu, 19 Jul 2012 17:32:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id cHYF1j00p3ZTu2S3jHYFGs; Thu, 19 Jul 2012 17:32:15 +0000 Message-ID: <500844A6.6090304@alum.mit.edu> Date: Thu, 19 Jul 2012 13:32:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <201207171919.q6HJJQij014492@mtv-core-3.cisco.com> <5005DBCA.8040405@alum.mit.edu> In-Reply-To: <5005DBCA.8040405@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] Trafficclass Attribute -02 submitted 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, 19 Jul 2012 17:31:34 -0000 I have a general question about this draft: The descriptions of the five categories in 2.1-2.5 are each characterized by values for tolerance to loss, delay, and jitter. It appears that there are 64 possible combinations of values for those things. (Four values for each - very low, low, medium, high.) And the existing 5 categories cover 17 of those combinations. (Some cover more than one.) Is it intended that each combination of those values be associated with at most one defined category? (IOW, if a new category is to be defined, it must be defined with values that don't conflict with any previously defined category.) (There is a similar characterization in RFC4594. There the service class names don't have unique characterizations. But there the names are complete service classes, whereas the current draft the category name is qualified by application and attribute to construct a traffic class name.) IIUC, the category name should identify the required tolerance to loss, delay, and jitter. Then the application and attributes provide additional info about the intended use that can be taken into account for policy decisions. Do I have it right? Thanks, Paul On 7/17/12 5:40 PM, Paul Kyzivat wrote: > Some comments on the new version: > > In section 3 (SDP syntax): > > tcl-token = %2D / %30-%39 / %41-%5A / %61-7A > > That only allows one character tokens. Minimally you probably want: > > tcl-token = 1*(%2D / %30-%39 / %41-%5A / %61-7A) > > But it would be more readable as: > > tcl-token = 1*( ALPHA / DIGIT / "-" ) > > (Those symbols are defined with ABNF in RFC 5234. If so you need a > reference. Paraphrasing 3261, you might say: "Appendix B.1 of RFC 5234 > defines a set of core rules that are used by this specification, and not > repeated here.") > > But that allows leading and trailing, and multiple consecutive "-"s. So > you could tighten it up with: > > tcl-token = ALPHA 0*(ALPHA / DIGIT) 0*("-" 1*(ALPHA / DIGIT)) > > Also, your syntax doesn't cover non-standard-adjectives. You could cover > that by: > > adjective = standard-adjective / non-standard-adjective > > standard-adjective = classified-adjective / unclassified-adjective > > non-standard-adjective = "_" standard-adjective > > Sections 6.3 & 6.4: > > "Specification Required" implies expert review. That in turn calls for > some criteria by which the expert can decide if a proposed value is > appropriate to be registered. > > IIUC, 'aq', 'admitted', 'non-admitted', and 'none' are *not* Unqualified > adjectives. Rather, > > 'aq:admitted', 'aq:non-admitted', and 'aq:none' are *qualified* adjectives. > > Does the distinction matter for registration? Should there be different > criteria for registering new qualified adjectives? Maybe so. Maybe there > should be some review of whether the new 'aq:foo' is compatible with the > intended meaning of 'aq'??? > > Thanks, > Paul > > On 7/17/12 3:19 PM, James Polk wrote: >> MMUSIC >> >> We've submitted a revision of the Traffic Class Label attribute here >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-traffic-class-for-sdp >> >> These are the following changes made between the WG -01 version and >> the -02 version: >> >> - converged the use of terms 'parent' and 'category' to just >> 'category' for consistency. >> >> - changed ABNF to reflect extensibility by not having applications >> and adjectives named in the ABNF, rather have them merely IANA >> registered. This was brought up on the list and in the Paris >> meeting. >> >> - merged the qualified and unqualified adjective sections into a >> single section on adjectives, but allowing some to have a >> preceding qualifier. This was brought up on the list and in the >> Paris meeting. >> >> - text clean-up >> >> We have one known open issue, which is related to some document >> structure around the categories, applications and adjectives. >> >> We have another known open issue regarding articulating better which >> adjectives are appropriate with which applications, as well as which >> applications are appropriate with which categories. >> >> Other comments and questions are solicited. >> >> James/Subha/Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From harald@alvestrand.no Thu Jul 19 22:15:56 2012 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 7BC6621F8669 for ; Thu, 19 Jul 2012 22:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.011 X-Spam-Level: X-Spam-Status: No, score=-110.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 2p03u05UF7Cb for ; Thu, 19 Jul 2012 22:15:56 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CD10821F8668 for ; Thu, 19 Jul 2012 22:15:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE3EA39E179; Fri, 20 Jul 2012 07:16:48 +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 McqVDBbkLiWQ; Fri, 20 Jul 2012 07:16:48 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B9F6E39E091; Fri, 20 Jul 2012 07:16:47 +0200 (CEST) Message-ID: <5008E9BD.5060803@alvestrand.no> Date: Fri, 20 Jul 2012 07:16:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <500008AD.5060704@ericsson.com> In-Reply-To: <500008AD.5060704@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Agenda of MMUSIC WG meeting at IETF 84 (Vancouver) 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, 20 Jul 2012 05:15:56 -0000 On 07/13/2012 01:38 PM, Miguel A. Garcia wrote: > Greetings. > > The preliminary agenda for the MMUSIC WG meeting at IETF 84 in > Vancouver is available: > > https://datatracker.ietf.org/meeting/84/agenda/mmusic/ > > Please send feedback to Flemming and myself. > > /Miguel and Flemming. Apologies for not catching this earlier.... draft-alvestrand-rtcweb-msid-02 is a significant rework of the language of the specification in response to feedback from the F2F meeting in Paris. Is it possible to get agenda time for this one? Harald From tireddy@cisco.com Fri Jul 20 02:47:30 2012 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 5CE5A21F85A5 for ; Fri, 20 Jul 2012 02:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RJo6aN76w-0Y for ; Fri, 20 Jul 2012 02:47:29 -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 63F9021F8507 for ; Fri, 20 Jul 2012 02:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=1758; q=dns/txt; s=iport; t=1342777705; x=1343987305; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=diANZP3YIo6eTwcgq+zyreVexLLSk1bVRfncs4I3pG8=; b=NCe/eJ4q3OxFB05IwHHd501So00EoUAXFgVJEXiHROiEXh2+ObQmKGSy E1kb14zuwnpLG10V4G0Tn+93YTpP0symGKpCwm2XAz6B6A3MhfasVzo7o 6qqZlQYwplIF1GJNIcMiU2OOlwkpCOsUNlgjK2UqhWjADLiUv+7z8//UN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQIAM4oCVCtJXHA/2dsb2JhbABFhDCBRLI0gRaBB4IgAQEBBBIBEBFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEEwgBGYdrC50ugSiNGZMJgSCKLIVOMmADlleNEIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,622,1336348800"; d="scan'208";a="103734153" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jul 2012 09:48:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6K9mOCW021004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Jul 2012 09:48:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 04:48:24 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQ Date: Fri, 20 Jul 2012 09:48:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A052D65CE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.87.254] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19052.005 x-tm-as-result: No--26.346000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [MMUSIC] FW: New Version Notification for draft-wing-mmusic-ice-mobility-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: Fri, 20 Jul 2012 09:47:30 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDE3LCAyMDEyIDM6NTIgQU0NClRvOiBEYW4gV2luZyAoZHdpbmcpDQpDYzogUHJhc2hhbnRoIFBh dGlsIChwcmFzcGF0aSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5 LTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aW5nLW1tdXNpYy1pY2Ut bW9iaWxpdHktMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhbiBX aW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBNb2Jp bGl0eSB3aXRoIElDRSAoTUlDRSkNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE2DQpXRyBJRDoJ CSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTINClVSTDogICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy1tbXVz aWMtaWNlLW1vYmlsaXR5LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eQ0KSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2Ut bW9iaWxpdHktMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDENCg0KQWJzdHJhY3Q6DQog ICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGhvdyBlbmRwb2ludCBtb2JpbGl0eSBjYW4g YmUgYWNoaWV2ZWQNCiAgIHVzaW5nIElDRS4gIFR3byBtZWNoYW5pc21zIGFyZSBzaG93biwgb25l IHdoZXJlIGJvdGggZW5kcG9pbnRzDQogICBzdXBwb3J0IElDRSBhbmQgYW5vdGhlciB3aGVyZSBv bmx5IG9uZSBlbmRwb2ludCBzdXBwb3J0cyBJQ0UuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From tireddy@cisco.com Fri Jul 20 03:35:53 2012 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 1942021F858D for ; Fri, 20 Jul 2012 03:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HuBzTXb1DWWn for ; Fri, 20 Jul 2012 03:35:51 -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 7CB5B21F8577 for ; Fri, 20 Jul 2012 03:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=2730; q=dns/txt; s=iport; t=1342780607; x=1343990207; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=onA3jsuQqx8s8lcREasgw/YGUzHqWrYh/VGOuVa10ZI=; b=Iwx3xFFTZ/Ia7Xj0z+Wrli1NMh6Nds6NHo2JvdUmcuY1tPibVbG8SUaz Y0Hwbs0wWtUoV5WwAXaO37G6M6tSqnfJIoKgPQihqbBY1Z+/JFdO1CXvJ LBX/UDV09UicUc/YgaQWOQVIY7G+kbyPDyFZGmPQPGTp9i87sCOWPTxcB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMIAGAzCVCtJXHA/2dsb2JhbABFhDCBRLI0gRaBB4IgAQEBBBIBEBFDDgYBCBEEAQEDAgYdAwIEMBQBCAoEEwgBGYdrC50qgSiNGZMKgSCKLIVOMmADlleNEIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,622,1336348800"; d="scan'208";a="103774736" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jul 2012 10:36:47 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6KAakWN021010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Jul 2012 10:36:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 05:36:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQgAAM1pA= Date: Fri, 20 Jul 2012 10:36:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.87.254] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19052.005 x-tm-as-result: No--34.241000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-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: Fri, 20 Jul 2012 10:35:53 -0000 SGkgYWxsLA0KDQpEYW4sIFByYXNoYW50aCBhbmQgSSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRo YXQgZXhwbGFpbnMgaG93IGVuZHBvaW50IG1vYmlsaXR5IGNhbiBiZSBhY2hpZXZlZCB1c2luZyBJ Q0UuICBUd28gbWVjaGFuaXNtcyBhcmUgc2hvd24sIG9uZSB3aGVyZSBib3RoIGVuZHBvaW50cyBz dXBwb3J0IElDRSBhbmQgYW5vdGhlciB3aGVyZSBvbmx5IG9uZSBlbmRwb2ludCBzdXBwb3J0cyBJ Q0UuIFdoZW4gb25seSBvbmUgZW5kcG9pbnQgc3VwcG9ydHMgSUNFLCBhIFRVUk4gc2VydmVyIHBy b3ZpZGVzIG1vYmlsaXR5Lg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDEudHh0DQoNClBsZWFzZSBsZXQga25vdyB5 b3VyIGNvbW1lbnRzLiBJZiB0aW1lIHBlcm1pdHMgd2UnZCBwcmVzZW50IHRoZSBkcmFmdCBpbiBW YW5jb3V2ZXIuDQoNClJlZ2FyZHMsDQpUaXJ1Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gU2VudDogRnJpZGF5 LCBKdWx5IDIwLCAyMDEyIDM6MTggUE0NCj4gVG86IG1tdXNpY0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW5nLW1tdXNpYy1pY2Ut DQo+IG1vYmlsaXR5LTAxLnR4dA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAyMDEyIDM6NTIgQU0NCj4gVG86IERh biBXaW5nIChkd2luZykNCj4gQ2M6IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LQ0KPiAwMS50eHQNCj4gDQo+IA0K PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTAx LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhbiBXaW5nIGFuZCBw b3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQt d2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5DQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgTW9i aWxpdHkgd2l0aCBJQ0UgKE1JQ0UpDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE2DQo+IFdH IElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDEyDQo+IFVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt d2luZy1tbXVzaWMtDQo+IGljZS1tb2JpbGl0eS0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbmctbW11c2ljLWljZS0NCj4g bW9iaWxpdHkNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC13aW5nLW1tdXNpYy1pY2UtDQo+IG1vYmlsaXR5LTAxDQo+IERpZmY6ICAgICAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13aW5nLW1tdXNpYy0NCj4g aWNlLW1vYmlsaXR5LTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBzcGVjaWZpY2F0aW9u IGRlc2NyaWJlcyBob3cgZW5kcG9pbnQgbW9iaWxpdHkgY2FuIGJlIGFjaGlldmVkDQo+ICAgIHVz aW5nIElDRS4gIFR3byBtZWNoYW5pc21zIGFyZSBzaG93biwgb25lIHdoZXJlIGJvdGggZW5kcG9p bnRzDQo+ICAgIHN1cHBvcnQgSUNFIGFuZCBhbm90aGVyIHdoZXJlIG9ubHkgb25lIGVuZHBvaW50 IHN1cHBvcnRzIElDRS4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From miguel.a.garcia@ericsson.com Fri Jul 20 04:47:19 2012 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 5DAB221F85A3 for ; Fri, 20 Jul 2012 04:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 9MZt2-uatsf8 for ; Fri, 20 Jul 2012 04:47:18 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAB521F8593 for ; Fri, 20 Jul 2012 04:47:07 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-31-5009457133d8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EE.44.03067.17549005; Fri, 20 Jul 2012 13:48:01 +0200 (CEST) Received: from [159.107.48.3] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Fri, 20 Jul 2012 13:47:59 +0200 Message-ID: <50094567.8000100@ericsson.com> Date: Fri, 20 Jul 2012 13:47:51 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Hadriel Kaplan , "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" References: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> <84E88829-8A31-48ED-B77F-7C1CE9668955@acmepacket.com> <50000663.40707@ericsson.com> In-Reply-To: <50000663.40707@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvrW6hK2eAwcQpFhaHVvUzW2xePJ/N 4v0FXYsd78+wWMy9/JzdYuryxywObB6bJm9m85jyeyOrx+JN+9k8liz5yeQxcfEnZo8vlz+z BbBFcdmkpOZklqUW6dslcGWc3aVZ8F+94vr9Q6wNjNfkuxg5OCQETCRWLGfpYuQEMsUkLtxb z9bFyMUhJHCKUeJY/0sWCGcVo0Trs0dMIFW8AtoSD342MoPYLAKqEvc6T4B1swmYS7Ru3MgO YosKBEo8n72FHaJeUOLkzCdgg0QEljBK7Fx6kxHEYRb4xSjx8/BPsKnCAp4SB4/eh9o9lVGi f34XK0iCU0BLYs+po2BFzAK2EhfmXGeBsOUltr+dA3aGkICmxOSbS5knMArOQrJxFpKWWUha FjAyr2IUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECAz+g1t+G+xg3HRf7BCjNAeLkjivnup+fyGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mhg0x316J9B3fVpzgsHuf/ts7U6Rv7951nf85j92V /tAFRRZzZ3NHv/wQeGtpxeMZj2eq7/g6gWunzyavrlUH76c9unaxvmB+0JqGFzbT0+YIhjzb uVv/Xrm0n46sfPmrux1B932yz7wX6z9u3bisJHt25pqlfN73P++7tWyDOqt7dk7GVdZvBkos xRmJhlrMRcWJAL6bLk9MAgAA Cc: Flemming Andreasen , Magnus Westerlund , Bjoern Hoehrmann , =?ISO-8859-1?Q?Gunnar_Hellstr=F6?= =?ISO-8859-1?Q?m?= , mmusic Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-19.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: Fri, 20 Jul 2012 11:47:19 -0000 We haven't received any comments on this week of review of the changes of this last version of the media loopback. We believe the draft is ready for publication request now. /Miguel On 13/07/2012 13:28, Miguel A. Garcia wrote: > Hi Hadriel: > > Thanks a lot for getting this new revision. We are almost done!!! > > I hereby invite those who made comments during the WGLC to verify that > they are satisfied with their resolution. If we don't here any feedback > within a week (July 20th), we will understand everything is correct, and > we will proceed to request publication of this draft. > > /Miguel > > On 13/07/2012 7:06, Hadriel Kaplan wrote: >> >> Howdy, >> Based on the emails/comments from the WGLC, I have posted a revised media-loopback draft. I believe this addresses all opened issues, and in general covers the following changes: >> >> 1) Feedback from media mime types reviewer on section 13 (now section 14). Changes based on: >> http://www.ietf.org/mail-archive/web/ietf-types/current/msg01649.html >> >> 2) Many editorial corrections from Flemming, based on: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09295.html >> >> 3) Non-contentious comments from Magnus have been addressed, based on: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09300.html >> >> 4) Congestion control issue - it appears "let the loopback source do it" was the rough consensus, so it has been changed. (well... clarified) The thread started here: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09305.html >> >> 5) Secretly replaced the fine coffee the IETF usually serves, with Folgers Crystals. >> >> 6) SRTP is now covered in a small new section. >> >> 7) Author list has been reduced to 5 authors. >> >> If you are not happy with the changes let me know (or rather let this mailing list know). >> >> -hadriel >> >> >> On Jul 13, 2012, at 12:48 AM, >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. >>> >>> Title : An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback >>> Author(s) : Hadriel Kaplan >>> Kaynam Hedayat >>> Nagarjuna Venna >>> Paul E. Jones >>> Nathan Stratton >>> Filename : draft-ietf-mmusic-media-loopback-19.txt >>> Pages : 33 >>> Date : 2012-07-12 >>> >>> Abstract: >>> The wide deployment of Voice over IP (VoIP), Text and Video over IP >>> services has introduced new challenges in managing and maintaining >>> real-time voice/text/video quality, reliability, and overall >>> performance. In particular, media delivery is an area that needs >>> attention. One method of meeting these challenges is monitoring >>> the media delivery performance by looping media back to the >>> transmitter. This is typically referred to as "active monitoring" >>> of services. Media loopback is especially popular in ensuring the >>> quality of transport to the edge of a given VoIP, Real-time Text or >>> Video over IP service. Today in networks that deliver real-time >>> media, short of running 'ping' and 'traceroute' to the edge, >>> administrators are left without the necessary tools to actively >>> monitor, manage, and diagnose quality issues with their service. >>> The extension defined herein adds new SDP media types and >>> attributes, which enable establishment of media sessions where the >>> media is looped back to the transmitter. Such media sessions will >>> serve as monitoring and troubleshooting tools by providing the >>> means for measurement of more advanced VoIP, Real-time Text and >>> Video over IP performance metrics. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-19 >>> >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-media-loopback-19 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From harald@alvestrand.no Fri Jul 20 05:13:05 2012 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 BDFBF21F8570 for ; Fri, 20 Jul 2012 05:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.187 X-Spam-Level: X-Spam-Status: No, score=-110.187 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7IAAqHvbqSe0 for ; Fri, 20 Jul 2012 05:13:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7150721F856D for ; Fri, 20 Jul 2012 05:13:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0066B39E179 for ; Fri, 20 Jul 2012 14:13:59 +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 Nk4TDaxsmsuz for ; Fri, 20 Jul 2012 14:13:57 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 529F439E091 for ; Fri, 20 Jul 2012 14:13:57 +0200 (CEST) Message-ID: <50094B84.6040506@alvestrand.no> Date: Fri, 20 Jul 2012 14:13:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080806030107000308030302" Subject: Re: [MMUSIC] Channel descriptions 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, 20 Jul 2012 12:13:05 -0000 This is a multi-part message in MIME format. --------------080806030107000308030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kevin, can you clarify what you mean by "channel" here? The term is used most often for components of a multisource audio signal, such as stereo, 5+1 or 22+2 - in most cases, those will be carried in a single SSRC, using an encoding that implicitly defines which channels go where. In WebRTC, we've converged on the word "track" for a single media flow such as one audio signal (mostly) carried in a single SSRC, and the word "stream" for multiple media flows (such as audio and video) that are related to each other in some fashion. If you have a definition you would like to use, please point to it - the discussion can get to be almighty confusing if we're not talking about the same thing! On 07/18/2012 01:57 AM, Kevin Gross wrote: > The i= attribute provides a means to describe a session. Sessions > often have multiple media streams or channels. Although RFC 3551 (page > 8) suggests a convention for ordering of channels for surround sound > applications, other applications use multiple channels in different > ways. It would be useful if there were a mechanism analogous to i= for > describing individual channels in a session. Does such a thing exist > anywhere? I've searched the archives here and didn't find anything. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------080806030107000308030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Kevin,

can you clarify what you mean by "channel" here?

The term is used most often for components of a multisource audio signal, such as stereo, 5+1 or 22+2 - in most cases, those will be carried in a single SSRC, using an encoding that implicitly defines which channels go where.

In WebRTC, we've converged on the word "track" for a single media flow such as one audio signal (mostly) carried in a single SSRC, and the word "stream" for multiple media flows (such as audio and video) that are related to each other in some fashion.

If you have a definition you would like to use, please point to it - the discussion can get to be almighty confusing if we're not talking about the same thing!

On 07/18/2012 01:57 AM, Kevin Gross wrote:
The i= attribute provides a means to describe a session. Sessions often have multiple media streams or channels. Although RFC 3551 (page 8) suggests a convention for ordering of channels for surround sound applications, other applications use multiple channels in different ways. It would be useful if there were a mechanism analogous to i= for describing individual channels in a session. Does such a thing exist anywhere? I've searched the archives here and didn't find anything.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org



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


--------------080806030107000308030302-- From harald@alvestrand.no Fri Jul 20 05:14:32 2012 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 7975821F8570 for ; Fri, 20 Jul 2012 05:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.224 X-Spam-Level: X-Spam-Status: No, score=-110.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 q5SMMPpaVcFh for ; Fri, 20 Jul 2012 05:14:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D712B21F84C2 for ; Fri, 20 Jul 2012 05:14:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EDBDB39E179 for ; Fri, 20 Jul 2012 14:15:26 +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 cwqk0AqTA6ea for ; Fri, 20 Jul 2012 14:15:26 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14] (unknown [IPv6:2001:470:de0a:27:221:6aff:fe8f:cf14]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6034F39E091 for ; Fri, 20 Jul 2012 14:15:26 +0200 (CEST) Message-ID: <50094BDD.5070207@alvestrand.no> Date: Fri, 20 Jul 2012 14:15:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Media Stream ID: draft-alvestrand-rtcweb-msid-02 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, 20 Jul 2012 12:14:32 -0000 Hello, after the Paris meeting, when there was much good feedback on this draft in MMUSIC, I updated it to be a more general mechanism with a specific description of its application to RTCWEB's use case. I hope you like it better now..... any feedback that comes in ahead of the IETF meeting would be most welcome! Harald From miguel.a.garcia@ericsson.com Fri Jul 20 05:55:11 2012 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 1C13121F8596 for ; Fri, 20 Jul 2012 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 lYQXjU6-Kr3o for ; Fri, 20 Jul 2012 05:55:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27ED421F8570 for ; Fri, 20 Jul 2012 05:55:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-18-500955647a21 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8A.65.07365.46559005; Fri, 20 Jul 2012 14:56:04 +0200 (CEST) Received: from [159.107.48.3] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Fri, 20 Jul 2012 14:56:04 +0200 Message-ID: <50095561.2080404@ericsson.com> Date: Fri, 20 Jul 2012 14:56:01 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mmusic References: <50094BDD.5070207@alvestrand.no> In-Reply-To: <50094BDD.5070207@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+JvrW5qKGeAwRRui/cXdC2O9XWxWUxd /pjFgdnjyoQrrB5Tfm9k9Viy5CdTAHMUl01Kak5mWWqRvl0CV8aquXuYCjaxV3z/sou5gfEx axcjJ4eEgInEzksnoWwxiQv31rOB2EICpxglvk3Q72LkArJXMUos3trIBJLgFdCW+PX+CFgR i4CqxJsdi8FsNgFzidaNG9lBbFGBQInns7ewQ9QLSpyc+YQFxBYRkJHYu2kzM4jNLBAhcWT5 D0YQW1jATWL/7JmsEIt1JHY8ew5WwymgK7Fk0WQmiHpbiQtzrrNA2PIS29/OYYao15SYfHMp 8wRGwVlI1s1C0jILScsCRuZVjMK5iZk56eWGeqlFmcnFxfl5esWpmxiBoXtwy2/dHYynzokc YpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHKYt1b2xc+/7ep/MrU2916 cv7GnrMiN+48y353qe9s9W2jdqEw+dTAtMtHtBVj3cXPTJv+t8hZxVBC+82bZ6duvC/XNZn7 yuKX6oXX95tP/5fNzHFbcP/3nqtLVZ84XrrHMWN33TnHf0pf4+e9vS6utPMOm83UBMeeljcv rzZd9k5uvjjpl/9RJZbijERDLeai4kQAsyWZrSsCAAA= Cc: Flemming Andreasen Subject: Re: [MMUSIC] Media Stream ID: draft-alvestrand-rtcweb-msid-02 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, 20 Jul 2012 12:55:11 -0000 As a chair, I believe this draft should have been addressed to MMUSIC (please Harald, confirm it). So, I would suggest that we treat this draft as if it had been submitted to MMUSIC. Perhaps when the blackout period is over the authors should resubmitted as draft-alvestrand-mmusic-msid-00. /Miguel On 20/07/2012 14:15, Harald Alvestrand wrote: > Hello, > > after the Paris meeting, when there was much good feedback on this draft > in MMUSIC, I updated it to be a more general mechanism with a specific > description of its application to RTCWEB's use case. > > I hope you like it better now..... any feedback that comes in ahead of > the IETF meeting would be most welcome! > > Harald > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From harald@alvestrand.no Fri Jul 20 06:01:42 2012 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 30A7B21F8630 for ; Fri, 20 Jul 2012 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.256 X-Spam-Level: X-Spam-Status: No, score=-110.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 5b02cFzhhvv2 for ; Fri, 20 Jul 2012 06:01:40 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A8F5021F8643 for ; Fri, 20 Jul 2012 06:01:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8FDA39E182; Fri, 20 Jul 2012 15:02:32 +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 Go9SHwgYuFNa; Fri, 20 Jul 2012 15:02:31 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:2cec:59ab:e707:b894] (unknown [IPv6:2001:470:de0a:27:2cec:59ab:e707:b894]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 6E8E639E179; Fri, 20 Jul 2012 15:02:31 +0200 (CEST) Message-ID: <500956F1.1080706@alvestrand.no> Date: Fri, 20 Jul 2012 15:02:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <50094BDD.5070207@alvestrand.no> <50095561.2080404@ericsson.com> In-Reply-To: <50095561.2080404@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Media Stream ID: draft-alvestrand-rtcweb-msid-02 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, 20 Jul 2012 13:01:42 -0000 On 07/20/2012 02:56 PM, Miguel A. Garcia wrote: > As a chair, > > I believe this draft should have been addressed to MMUSIC (please > Harald, confirm it). > > So, I would suggest that we treat this draft as if it had been > submitted to MMUSIC. Perhaps when the blackout period is over the > authors should resubmitted as draft-alvestrand-mmusic-msid-00. If there's no objection in the meeting, perhaps it can be submitted as draft-ietf-mmusic-msid-00? > > /Miguel > > On 20/07/2012 14:15, Harald Alvestrand wrote: >> Hello, >> >> after the Paris meeting, when there was much good feedback on this draft >> in MMUSIC, I updated it to be a more general mechanism with a specific >> description of its application to RTCWEB's use case. >> >> I hope you like it better now..... any feedback that comes in ahead of >> the IETF meeting would be most welcome! >> >> Harald >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > From harald@alvestrand.no Fri Jul 20 06:02:54 2012 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 A361B21F8643 for ; Fri, 20 Jul 2012 06:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 YXOtQG02ksBE for ; Fri, 20 Jul 2012 06:02:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D458121F863D for ; Fri, 20 Jul 2012 06:02:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA4D239E179; Fri, 20 Jul 2012 15:03:47 +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 qsrJe2jNrTKc; Fri, 20 Jul 2012 15:03:47 +0200 (CEST) Received: from [192.168.1.16] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E9A8539E091; Fri, 20 Jul 2012 15:03:46 +0200 (CEST) Message-ID: <5009573D.40407@alvestrand.no> Date: Fri, 20 Jul 2012 15:03:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <50094BDD.5070207@alvestrand.no> <50095561.2080404@ericsson.com> In-Reply-To: <50095561.2080404@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] Media Stream ID: draft-alvestrand-rtcweb-msid-02 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, 20 Jul 2012 13:02:54 -0000 On 07/20/2012 02:56 PM, Miguel A. Garcia wrote: > As a chair, > > I believe this draft should have been addressed to MMUSIC (please > Harald, confirm it). > > So, I would suggest that we treat this draft as if it had been > submitted to MMUSIC. Perhaps when the blackout period is over the > authors should resubmitted as draft-alvestrand-mmusic-msid-00. Thank you! If the WG accepts it, we could go straight to draft-ietf-mmusic-msid-00, to avoid so many draft names for the same content. Harald > > /Miguel > > On 20/07/2012 14:15, Harald Alvestrand wrote: >> Hello, >> >> after the Paris meeting, when there was much good feedback on this draft >> in MMUSIC, I updated it to be a more general mechanism with a specific >> description of its application to RTCWEB's use case. >> >> I hope you like it better now..... any feedback that comes in ahead of >> the IETF meeting would be most welcome! >> >> Harald >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > From kevin.gross@avanw.com Fri Jul 20 07:43:34 2012 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 2AA3C21F8552 for ; Fri, 20 Jul 2012 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 kVOPSrFXk8LC for ; Fri, 20 Jul 2012 07:43:33 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.55]) by ietfa.amsl.com (Postfix) with SMTP id F2AA321F854D for ; Fri, 20 Jul 2012 07:43:32 -0700 (PDT) Received: (qmail 30916 invoked by uid 0); 20 Jul 2012 14:44:07 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy2.bluehost.com with SMTP; 20 Jul 2012 14:44:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=a+MwcYpIABb3frWE90ZoaIQQ7GA7PAWIaItOIHNkNLk=; b=ToH2NmYl2aIZvS1ZiE7m2Iw9KRkHhg02t49fYPytXgBISFbbqAsLj7IZx9m+xMXvOpYM0O7nybxQXX2DfjcTcfEiKsl9GwUMtYtSn9VGlVF6ZN3CMvKJ/yKG1Jpu5Xja; Received: from [74.125.82.172] (port=46295 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1SsER5-0002yK-4u for mmusic@ietf.org; Fri, 20 Jul 2012 08:44:07 -0600 Received: by weyu54 with SMTP id u54so3031767wey.31 for ; Fri, 20 Jul 2012 07:44:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.81.138 with SMTP id a10mr15111685wiy.7.1342795445721; Fri, 20 Jul 2012 07:44:05 -0700 (PDT) Received: by 10.223.72.201 with HTTP; Fri, 20 Jul 2012 07:44:05 -0700 (PDT) In-Reply-To: <50094B84.6040506@alvestrand.no> References: <50094B84.6040506@alvestrand.no> Date: Fri, 20 Jul 2012 08:44:05 -0600 Message-ID: From: Kevin Gross To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d044401ba8c599904c543eddb X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Channel descriptions 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, 20 Jul 2012 14:43:34 -0000 --f46d044401ba8c599904c543eddb Content-Type: text/plain; charset=ISO-8859-1 I'm talking about a single audio signals. It a surround stream, a single signal would be, for instance, the left front. Track is also a reasonable description but people tend to associate that term with recording and reproduction. The ability to label individual channels in surround formats is important to distinguish the many formats and conventions in use. See http://tech.ebu.ch/docs/r/r123.pdf. In commercial applications, it is common, for efficiency, for multiple loosely related channels to be carried in the same stream, e.g. different background music source, paging signals for different zones. Active audio crossover networks (http://en.wikipedia.org/wiki/Audio_crossover#Active) are often used in large sound reinforcement systems and different frequency components are carried to the speakers as separate channels in the same stream. In all cases it is important to correctly connect the channels to their intended destinations. There are too many possibilities in most of these use cases for the i= description to resolve the potential ambiguity. Kevin Gross On Fri, Jul 20, 2012 at 6:13 AM, Harald Alvestrand wrote: > Kevin, > > can you clarify what you mean by "channel" here? > > The term is used most often for components of a multisource audio signal, > such as stereo, 5+1 or 22+2 - in most cases, those will be carried in a > single SSRC, using an encoding that implicitly defines which channels go > where. > > In WebRTC, we've converged on the word "track" for a single media flow > such as one audio signal (mostly) carried in a single SSRC, and the word > "stream" for multiple media flows (such as audio and video) that are > related to each other in some fashion. > > If you have a definition you would like to use, please point to it - the > discussion can get to be almighty confusing if we're not talking about the > same thing! > > > On 07/18/2012 01:57 AM, Kevin Gross wrote: > > The i= attribute provides a means to describe a session. Sessions often > have multiple media streams or channels. Although RFC 3551 (page 8) > suggests a convention for ordering of channels for surround sound > applications, other applications use multiple channels in different ways. > It would be useful if there were a mechanism analogous to i= for describing > individual channels in a session. Does such a thing exist anywhere? I've > searched the archives here and didn't find anything. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > _______________________________________________ > mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --f46d044401ba8c599904c543eddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm talking about a single audio signals. It a surround stream, a singl= e signal would be, for instance, the left front. Track is also a reasonable= description but people tend to associate that term with recording and repr= oduction. The ability to label individual channels in surround formats is i= mportant to distinguish the many formats and conventions in use. See=A0http://tech.ebu.ch/docs/r/r123.p= df.

In commercial applications, it is common, for efficiency, fo= r multiple loosely related channels to be carried in the same stream, e.g. = different background music source, paging signals for different zones. Acti= ve audio crossover networks (http://en.wikipedia.org/wiki/Audio_crossover#Active)= =A0are often used in large sound reinforcement systems and different freque= ncy components are carried to the speakers as separate channels in the same= stream.

In all cases it is important to correctly connect the c= hannels to their intended destinations. There are too many possibilities in= most of these use cases for the i=3D description to resolve the potential = ambiguity.

Kevin Gross

On Fri, Jul 20, 2012 at 6:13 AM, Harald Alvestrand <harald@al= vestrand.no> wrote:
=20 =20 =20
Kevin,

can you clarify what you mean by "channel" here?

The term is used most often for components of a multisource audio signal, such as stereo, 5+1 or 22+2 - in most cases, those will be carried in a single SSRC, using an encoding that implicitly defines which channels go where.

In WebRTC, we've converged on the word "track" for a si= ngle media flow such as one audio signal (mostly) carried in a single SSRC, and the word "stream" for multiple media flows (such as aud= io and video) that are related to each other in some fashion.

If you have a definition you would like to use, please point to it - the discussion can get to be almighty confusing if we're not talking about the same thing!


On 07/18/2012 01:57 AM, Kevin Gross wrote:
The i=3D attribute pro= vides a means to describe a session. Sessions often have multiple media streams or channels. Although RFC 3551 (page 8) suggests a convention for ordering of channels for surround sound applications, other applications use multiple channels in different ways. It would be useful if there were a mechanism analogous to i=3D for describing individual channels in a session. Does such a thing exist anywhere? I've searched the archives here and didn't find anything.

Kevin Gross
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org



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



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


--f46d044401ba8c599904c543eddb-- From gunnar.hellstrom@omnitor.se Fri Jul 20 11:56:31 2012 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 B098611E80C0 for ; Fri, 20 Jul 2012 11:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908] 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 HfQF+ADNbQGh for ; Fri, 20 Jul 2012 11:56:31 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 2C4D611E807F for ; Fri, 20 Jul 2012 11:56:29 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 20 Jul 2012 20:57:18 +0200 (CEST) Received: from [192.168.43.175] (2.70.73.207.mobile.tre.se [2.70.73.207]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 3E93C3A0F6 for ; Fri, 20 Jul 2012 20:57:17 +0200 (CEST) Message-ID: <5009AA0B.7030708@omnitor.se> Date: Fri, 20 Jul 2012 20:57:15 +0200 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <20120713044823.19632.15218.idtracker@ietfa.amsl.com> <84E88829-8A31-48ED-B77F-7C1CE9668955@acmepacket.com> <50000663.40707@ericsson.com> <50094567.8000100@ericsson.com> In-Reply-To: <50094567.8000100@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-19.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: Fri, 20 Jul 2012 18:56:31 -0000 I am happy with the resolution and glad to see the progress. /Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se On 2012-07-20 13:47, Miguel A. Garcia wrote: > We haven't received any comments on this week of review of the changes > of this last version of the media loopback. We believe the draft is > ready for publication request now. > > /Miguel > > On 13/07/2012 13:28, Miguel A. Garcia wrote: >> Hi Hadriel: >> >> Thanks a lot for getting this new revision. We are almost done!!! >> >> I hereby invite those who made comments during the WGLC to verify that >> they are satisfied with their resolution. If we don't here any feedback >> within a week (July 20th), we will understand everything is correct, and >> we will proceed to request publication of this draft. >> >> /Miguel >> >> On 13/07/2012 7:06, Hadriel Kaplan wrote: >>> >>> Howdy, >>> Based on the emails/comments from the WGLC, I have posted a revised >>> media-loopback draft. I believe this addresses all opened issues, >>> and in general covers the following changes: >>> >>> 1) Feedback from media mime types reviewer on section 13 (now >>> section 14). Changes based on: >>> http://www.ietf.org/mail-archive/web/ietf-types/current/msg01649.html >>> >>> 2) Many editorial corrections from Flemming, based on: >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09295.html >>> >>> 3) Non-contentious comments from Magnus have been addressed, based on: >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09300.html >>> >>> 4) Congestion control issue - it appears "let the loopback source do >>> it" was the rough consensus, so it has been changed. (well... >>> clarified) The thread started here: >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09305.html >>> >>> 5) Secretly replaced the fine coffee the IETF usually serves, with >>> Folgers Crystals. >>> >>> 6) SRTP is now covered in a small new section. >>> >>> 7) Author list has been reduced to 5 authors. >>> >>> If you are not happy with the changes let me know (or rather let >>> this mailing list know). >>> >>> -hadriel >>> >>> >>> On Jul 13, 2012, at 12:48 AM, >>> wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Multiparty Multimedia Session >>>> Control Working Group of the IETF. >>>> >>>> Title : An Extension to the Session Description >>>> Protocol (SDP) and Real-time Transport Protocol (RTP) for Media >>>> Loopback >>>> Author(s) : Hadriel Kaplan >>>> Kaynam Hedayat >>>> Nagarjuna Venna >>>> Paul E. Jones >>>> Nathan Stratton >>>> Filename : draft-ietf-mmusic-media-loopback-19.txt >>>> Pages : 33 >>>> Date : 2012-07-12 >>>> >>>> Abstract: >>>> The wide deployment of Voice over IP (VoIP), Text and Video >>>> over IP >>>> services has introduced new challenges in managing and >>>> maintaining >>>> real-time voice/text/video quality, reliability, and overall >>>> performance. In particular, media delivery is an area that needs >>>> attention. One method of meeting these challenges is monitoring >>>> the media delivery performance by looping media back to the >>>> transmitter. This is typically referred to as "active >>>> monitoring" >>>> of services. Media loopback is especially popular in >>>> ensuring the >>>> quality of transport to the edge of a given VoIP, Real-time >>>> Text or >>>> Video over IP service. Today in networks that deliver real-time >>>> media, short of running 'ping' and 'traceroute' to the edge, >>>> administrators are left without the necessary tools to actively >>>> monitor, manage, and diagnose quality issues with their service. >>>> The extension defined herein adds new SDP media types and >>>> attributes, which enable establishment of media sessions where >>>> the >>>> media is looped back to the transmitter. Such media sessions will >>>> serve as monitoring and troubleshooting tools by providing the >>>> means for measurement of more advanced VoIP, Real-time Text and >>>> Video over IP performance metrics. >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-19 >>>> >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mmusic-media-loopback-19 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> > From miguel.a.garcia@ericsson.com Mon Jul 23 00:38:13 2012 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 9B5CF21F8694 for ; Mon, 23 Jul 2012 00:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 qQRv5ewDvy7j for ; Mon, 23 Jul 2012 00:38:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ABF2721F8697 for ; Mon, 23 Jul 2012 00:38:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-ec-500cff62954c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 16.62.03067.26FFC005; Mon, 23 Jul 2012 09:38:10 +0200 (CEST) Received: from [159.107.105.153] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Mon, 23 Jul 2012 09:38:09 +0200 Message-ID: <500CFF5A.3030802@ericsson.com> Date: Mon, 23 Jul 2012 09:38:02 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mmusic References: <500008AD.5060704@ericsson.com> In-Reply-To: <500008AD.5060704@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VjfpP0+Awc4V5hbvL+haTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyri87x9bwXXWipevdrE2MO5n6WLk5JAQMJHY tvkdE4QtJnHh3nq2LkYuDiGBU4wSxze+Y4Rw1jJKLLyyiBmkildAW+LXu9tgHSwCqhJLZ54C s9kEzCVaN25kB7FFBQIlns/ewg5RLyhxcuYTsG0iAjISezdtBpvDDDRn9p1ZQL0cHMICHhIv JlqBhIWAwrf2zGEDsTkFdCTerP7ABFFuK3FhznUWCFteYvvbOcwQ9ZoSk28uZZ7AKDgLybZZ SFpmIWlZwMi8ilE4NzEzJ73cXC+1KDO5uDg/T684dRMjMFAPbvltsINx032xQ4zSHCxK4rx6 qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBGPlto2bxiyaSzvgXeC58e+aMgsPBZ7lOD aZ/z93eGPN0SM93qY59URfwhZpFaYdc7N9rSXzyUal7br+DKHef1/ahS2XevKEGV/bfDwqNU d/hb3pCc33xA1Z/10+EjM9WcOB4HT0q9/fVbY4Hx5mVTlaJnLmfoSJCezukxkcmSVXkXi/ht 87tKLMUZiYZazEXFiQCrEp0MIgIAAA== Cc: Flemming Andreasen Subject: Re: [MMUSIC] Agenda of MMUSIC WG meeting at IETF 84 (Vancouver) 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, 23 Jul 2012 07:38:13 -0000 Hi: We have updated the MMUSIC agenda to accommodate a couple of last minute requests. We have grouped related drafts by topic. And the last section of drafts does not have detailed time schedule, but we can assume a 5 minute presentation followed by 5 minutes of discussion. However, we might have trouble to reach the bottom of the agenda. /Miguel On 13/07/2012 13:38, Miguel A. Garcia wrote: > Greetings. > > The preliminary agenda for the MMUSIC WG meeting at IETF 84 in Vancouver > is available: > > https://datatracker.ietf.org/meeting/84/agenda/mmusic/ > > Please send feedback to Flemming and myself. > > /Miguel and Flemming. > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From dwing@cisco.com Tue Jul 24 17:19:52 2012 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 3E63011E8080 for ; Tue, 24 Jul 2012 17:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.501 X-Spam-Level: X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 Q5jGkIggOQGB for ; Tue, 24 Jul 2012 17:19:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A00F421F84A5 for ; Tue, 24 Jul 2012 17:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1057; q=dns/txt; s=iport; t=1343175591; x=1344385191; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=tCkz/86rAZc/qdvTEuTQHpAFCGOyui4tWvfQlj4l/ss=; b=GT17Kno+HjE0/n5vIEbIUhYsCh6xvEX1Tpgnmo0rmq6nQdnRCWOo7sv4 ptl0jr2lHdc87amxVXUKayvhlrRyGTTzLuKbuh5frBuQLRp9/edwxMGFH aqGDHfZurTzylGpFmA2WUtcPjjIWXQoinigRwq5Zq5T8KmVf01lX5q/ow M=; X-IronPort-AV: E=Sophos;i="4.77,649,1336348800"; d="scan'208";a="50354993" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 25 Jul 2012 00:19:51 +0000 Received: from dwingWS ([10.21.78.151]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6P0JpHv029677; Wed, 25 Jul 2012 00:19:51 GMT From: "Dan Wing" To: Date: Tue, 24 Jul 2012 17:19:51 -0700 Message-ID: <048b01cd69fb$35469ba0$9fd3d2e0$@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: Ac1p+zUFva24pK9+Re6kqju1dkzYXA== Content-Language: en-us Cc: "'Prashanth Patil \(praspati\)'" , "'Tirumaleswar Reddy \(tireddy\)'" Subject: [MMUSIC] ICE Mobility 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, 25 Jul 2012 00:19:52 -0000 MMUSIC, Losing or acquiring an interface often happens with mobile devices, such as when a device gets within WiFi range or leaves 3G range. Today the industry generally relies on techniques below layer 3 to hide the IP address change from the remote endpoint (e.g., LISP, Mobile IP). These existing techniques have some drawbacks, such as requiring support in the network infrastructure. ICE Mobility explores how to accomplish a similar function for ICE-initiated flows without needing support in the endpoint or in the network. Instead, the mobility support is provided at the ICE layer (such as RTP, SRTP, or RTCWEB's data channel (SRTP over UDP)). The document discusses how two approaches: (a) when both endpoints support ICE Mobility, and (b) when only one endpoint supports ICE Mobility, which uses a TURN server -- a different sort of network infrastructure. http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility We are unlikely to get time in MMUSIC to present this draft, but are interested in feedback. -d From lishitao@huawei.com Tue Jul 24 20:45:23 2012 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 9526E11E8080 for ; Tue, 24 Jul 2012 20:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.077 X-Spam-Level: ** X-Spam-Status: No, score=2.077 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_73=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 PtmiGuxTfaAg for ; Tue, 24 Jul 2012 20:45:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6018811E807F for ; Tue, 24 Jul 2012 20:45:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB00171; Tue, 24 Jul 2012 23:45:22 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 20:43:29 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 20:43:27 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 11:43:24 +0800 From: Lishitao To: Dan Wing , "mmusic@ietf.org" Thread-Topic: [MMUSIC] ICE Mobility Thread-Index: Ac1p+zUFva24pK9+Re6kqju1dkzYXAAFXwSA Date: Wed, 25 Jul 2012 03:43:24 +0000 Message-ID: References: <048b01cd69fb$35469ba0$9fd3d2e0$@com> In-Reply-To: <048b01cd69fb$35469ba0$9fd3d2e0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.39] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'Prashanth Patil \(praspati\)'" , "'Tirumaleswar Reddy \(tireddy\)'" Subject: [MMUSIC] =?gb2312?b?tPC4tDogIElDRSBNb2JpbGl0eQ==?= 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, 25 Jul 2012 03:45:23 -0000 SGkgRGFuIA0KDQpJIHJlYWQgdGhpcyBkcmFmdCwgYW5kIEkgdGhpbmsgdGhlIGlkZWEgb2YgdGhp cyBkcmFmdCBpcyB1c2VmdWwuIFJlZ2FyZGluZyB0aGUgdHdvIG1ldGhvZHMgbWVudGlvbmVkIGlu IHRoZSBkcmFmdCwgSSB0aGluayB0aGUgVFVSTiBvbmUgaXMgYmV0dGVyIHRoYW4gdGhlIElDRSBv bmUsIA0KDQplc3BlY2lhbGx5IGlmIHRoZSBUVVJOIHNlcnZlciBoYXMgdGhlIGNhY2hlIGNhcGFi aWxpdHksIHRoZSBkYXRhIGxvc2Ugd2lsbCBiZSBxdWl0ZSBzbWFsbC4gDQoNCkZvciB0aGUgbW9i aWxpdHkgdXNpbmcgSUNFIEkgZ290IHNvbWUgY29tbWVudHMsDQoxKSwgaW4gc2VjdGlvbiAzLjEs IEkgYmVsaWV2ZSB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBoZXJlIGlzIGFsbCBhYm91dCB0aGUg ZW5kcG9pbnQgd2hvIG1lZXQgdGhlIG1vYmlsaXR5IHNpdHVhdGlvbiwgc28gaW4gc3RlcCA2LCB0 aGUgSUNFIGNvbm5lY3Rpdml0eSBjaGVjayBpcyBvbmx5IGRvbmUgYnkgdGhpcyBzaWRlLCBkbyB5 b3UgbmVlZCB0byB3YWl0IHRoZSBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrIGZpbmlzaGVkIGJ5IGFu b3RoZXIgc2lkZSAocHJvYmFibHkgdGhlIHByb2NlZHVyZSBpbiBzZWN0aW9uIDMuMiApIGJlZm9y ZSB5b3Ugbm9taW5hdGUgdGhlIGNoZWNrIHJlc3VsdD8NCg0KMiksIGluIHNlY3Rpb24gMy4yLCBp dCBzYWlkIHRoYXQgIkEgU1RVTiBCaW5kaW5nIFJlcXVlc3QgY29udGFpbmluZyB0aGUgTU9CSUxJ VFktRVZFTlQgYXR0cmlidXRlIE1BWSBiZSByZWNlaXZlZCBieSBhbiBJQ0UgZW5kcG9pbnQuICIg IHdoeSBpcyBNQVkgYmUgaGVyZT8gQW5kIHdoZW4gICAgIGRvZXMgdGhpcyBNT0JJTElUWS1FVkVO VCBhdHRyaWJ1dGUgbmVlZD8NCg0KMykgLCAgd2hhdCBkbyB5b3UgbWVhbiBieSB0aGlzIHdvcmRz ICIgSWYgdGhpcyBpcyByZWNlaXZlZCBiZWZvcmUgdGhlIGVuZHBvaW50IGlzIGluIHRoZSBJQ0Ug Q29uY2x1ZGVkIHN0YXRlLCBpdCBzaG91bGQgYmUgc2lsZW50bHkgZGlzY2FyZGVkLiAiID8NCg0K NCksIHNlY3Rpb24gMy4zLCBsb3NpbmcgYW4gaW50ZXJmYWNlLCBpdCByZWNvbW1lbmRzIHRoYXQg bm90IHRvIHNlbmQgdGhlIFNEUCB0byByZW1vdmUgdGhlIGxvc3QgaW50ZXJmYWNlLCBpbnN0ZWFk IGl0IGlzIGJldHRlciB0byBtYWludGFpbiBpdCBhY3RpdmUuIEZvciBteSB1bmRlcnN0YW5kaW5n LCB3aGVuIHRoZSBtb2JpbGUgZGV2aWNlIHN3aXRjaCBmcm9tIG9uZSBpbnRlcmZhY2UgdG8gYW5v dGhlcihmb3IgZXhhbXBsZSwgd2lmaSB0byAzRyksIHRoZSBnYXRld2F5IGFuZCBOQVQgYmVmb3Jl IHRoZSBkZXZpY2Ugd2lsbCBjaGFuZ2UgdG9vLCBob3cgY2FuIGl0IG1haW50YWluIHRoZSBwcmV2 aW91cyBpbnRlcmZhY2UgYWN0aXZlPyBUaGUgb25seSB3YXksIEkgY2FuIGNvbnNpZGVyIGlzIHRo YXQgdGhlIHByZXZpb3VzIGludGVyZmFjZSBpcyBub3QgdG90YWxseSBsb3N0LCBpdCBzdGlsbCBh Y3RpdmUgb24gdGhlIGRldmljZSwgdGhhdCBtZWFucyB0aGUgdHdvIGludGVyZmFjZXMgYWxsIGV4 aXN0IGF0IHRoZSBzYW1lIHRpbWUsIGJ1dCB0aGUgZGV2aWNlIGNhbiBjaG9vc2UgdG8gdXNlIHRo ZSBuZXcgb25lIGJlY2F1c2UgaXRzIHNpZ25hbCBpcyBiZXR0ZXIgdGhhbiB0aGUgcHJldmlvdXMg b25lLiANCg0KUmVnYXJkcw0KU2hpdGFvDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6 IG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gRGFuIFdpbmcNCreiy83KsbzkOiAyMDEyxOo31MIyNcjVIDg6MjANCsrVvP7IyzogbW11 c2ljQGlldGYub3JnDQqzrcvNOiAnUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSknOyAnVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KScNCtb3zOI6IFtNTVVTSUNdIElDRSBNb2JpbGl0eQ0KDQpN TVVTSUMsDQoNCkxvc2luZyBvciBhY3F1aXJpbmcgYW4gaW50ZXJmYWNlIG9mdGVuIGhhcHBlbnMg d2l0aCBtb2JpbGUgZGV2aWNlcywgc3VjaCBhcw0Kd2hlbiBhIGRldmljZSBnZXRzIHdpdGhpbiBX aUZpIHJhbmdlIG9yIGxlYXZlcyAzRyByYW5nZS4gIFRvZGF5IHRoZSBpbmR1c3RyeQ0KZ2VuZXJh bGx5IHJlbGllcyBvbiB0ZWNobmlxdWVzIGJlbG93IGxheWVyIDMgdG8gaGlkZSB0aGUgSVAgYWRk cmVzcyBjaGFuZ2UNCmZyb20gdGhlIHJlbW90ZSBlbmRwb2ludCAoZS5nLiwgTElTUCwgTW9iaWxl IElQKS4gIFRoZXNlIGV4aXN0aW5nIHRlY2huaXF1ZXMNCmhhdmUgc29tZSBkcmF3YmFja3MsIHN1 Y2ggYXMgcmVxdWlyaW5nIHN1cHBvcnQgaW4gdGhlIG5ldHdvcmsNCmluZnJhc3RydWN0dXJlLg0K DQpJQ0UgTW9iaWxpdHkgZXhwbG9yZXMgaG93IHRvIGFjY29tcGxpc2ggYSBzaW1pbGFyIGZ1bmN0 aW9uIGZvciBJQ0UtaW5pdGlhdGVkDQpmbG93cyB3aXRob3V0IG5lZWRpbmcgc3VwcG9ydCBpbiB0 aGUgZW5kcG9pbnQgb3IgaW4gdGhlIG5ldHdvcmsuICBJbnN0ZWFkLA0KdGhlIG1vYmlsaXR5IHN1 cHBvcnQgaXMgcHJvdmlkZWQgYXQgdGhlIElDRSBsYXllciAoc3VjaCBhcyBSVFAsIFNSVFAsIG9y DQpSVENXRUIncyBkYXRhIGNoYW5uZWwgKFNSVFAgb3ZlciBVRFApKS4gIFRoZSBkb2N1bWVudCBk aXNjdXNzZXMgaG93IHR3bw0KYXBwcm9hY2hlczogIChhKSB3aGVuIGJvdGggZW5kcG9pbnRzIHN1 cHBvcnQgSUNFIE1vYmlsaXR5LCBhbmQgKGIpIHdoZW4gb25seQ0Kb25lIGVuZHBvaW50IHN1cHBv cnRzIElDRSBNb2JpbGl0eSwgd2hpY2ggdXNlcyBhIFRVUk4gc2VydmVyIC0tIGEgZGlmZmVyZW50 DQpzb3J0IG9mIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2JpbGl0eQ0KDQoNCldlIGFyZSB1bmxpa2Vs eSB0byBnZXQgdGltZSBpbiBNTVVTSUMgdG8gcHJlc2VudCB0aGlzIGRyYWZ0LCBidXQgYXJlDQpp bnRlcmVzdGVkIGluIGZlZWRiYWNrLg0KDQotZA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= From zhou.sujing@zte.com.cn Thu Jul 26 04:59:22 2012 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 68B6121F8734; Thu, 26 Jul 2012 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.147 X-Spam-Level: X-Spam-Status: No, score=-93.147 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 wzw25jyfEG7i; Thu, 26 Jul 2012 04:59:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3065121F870A; Thu, 26 Jul 2012 04:59:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231201904546; Thu, 26 Jul 2012 19:49:16 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 57026.3982996254; Thu, 26 Jul 2012 19:59:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6QBxAEM091957; Thu, 26 Jul 2012 19:59:10 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <048b01cd69fb$35469ba0$9fd3d2e0$@com> To: "Dan Wing" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 26 Jul 2012 19:58:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-26 19:59:06, Serialize complete at 2012-07-26 19:59:06 Content-Type: multipart/alternative; boundary="=_alternative 0041E56648257A47_=" X-MAIL: mse02.zte.com.cn q6QBxAEM091957 Cc: "'Prashanth Patil \(praspati\)'" , mmusic@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , mmusic-bounces@ietf.org Subject: [MMUSIC] =?gb2312?b?tPC4tDogIElDRSBNb2JpbGl0eQ==?= 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, 26 Jul 2012 11:59:22 -0000 This is a multipart message in MIME format. --=_alternative 0041E56648257A47_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksRGFuDQoNCiBIYXZlIHNpbXVsdGFuZW91cyBtb2JpbGl0eSBiZWVuIGNvbnNpZGVyZWQgaW4g dGhpcyBkcmFmdD8gDQoNCg0KUmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KDQoNCiJEYW4g V2luZyIgPGR3aW5nQGNpc2NvLmNvbT4gDQq3orz+yMs6ICBtbXVzaWMtYm91bmNlc0BpZXRmLm9y Zw0KMjAxMi0wNy0yNSAwODoxOQ0KDQrK1bz+yMsNCjxtbXVzaWNAaWV0Zi5vcmc+DQqzrcvNDQoi J1ByYXNoYW50aCBQYXRpbCBcKHByYXNwYXRpXCknIiA8cHJhc3BhdGlAY2lzY28uY29tPiwgIidU aXJ1bWFsZXN3YXIgDQpSZWRkeSBcKHRpcmVkZHlcKSciIDx0aXJlZGR5QGNpc2NvLmNvbT4NCtb3 zOINCltNTVVTSUNdIElDRSBNb2JpbGl0eQ0KDQoNCg0KDQoNCg0KTU1VU0lDLA0KDQpMb3Npbmcg b3IgYWNxdWlyaW5nIGFuIGludGVyZmFjZSBvZnRlbiBoYXBwZW5zIHdpdGggbW9iaWxlIGRldmlj ZXMsIHN1Y2ggDQphcw0Kd2hlbiBhIGRldmljZSBnZXRzIHdpdGhpbiBXaUZpIHJhbmdlIG9yIGxl YXZlcyAzRyByYW5nZS4gIFRvZGF5IHRoZSANCmluZHVzdHJ5DQpnZW5lcmFsbHkgcmVsaWVzIG9u IHRlY2huaXF1ZXMgYmVsb3cgbGF5ZXIgMyB0byBoaWRlIHRoZSBJUCBhZGRyZXNzIGNoYW5nZQ0K ZnJvbSB0aGUgcmVtb3RlIGVuZHBvaW50IChlLmcuLCBMSVNQLCBNb2JpbGUgSVApLiAgVGhlc2Ug ZXhpc3RpbmcgDQp0ZWNobmlxdWVzDQpoYXZlIHNvbWUgZHJhd2JhY2tzLCBzdWNoIGFzIHJlcXVp cmluZyBzdXBwb3J0IGluIHRoZSBuZXR3b3JrDQppbmZyYXN0cnVjdHVyZS4NCg0KSUNFIE1vYmls aXR5IGV4cGxvcmVzIGhvdyB0byBhY2NvbXBsaXNoIGEgc2ltaWxhciBmdW5jdGlvbiBmb3IgDQpJ Q0UtaW5pdGlhdGVkDQpmbG93cyB3aXRob3V0IG5lZWRpbmcgc3VwcG9ydCBpbiB0aGUgZW5kcG9p bnQgb3IgaW4gdGhlIG5ldHdvcmsuICBJbnN0ZWFkLA0KdGhlIG1vYmlsaXR5IHN1cHBvcnQgaXMg cHJvdmlkZWQgYXQgdGhlIElDRSBsYXllciAoc3VjaCBhcyBSVFAsIFNSVFAsIG9yDQpSVENXRUIn cyBkYXRhIGNoYW5uZWwgKFNSVFAgb3ZlciBVRFApKS4gIFRoZSBkb2N1bWVudCBkaXNjdXNzZXMg aG93IHR3bw0KYXBwcm9hY2hlczogIChhKSB3aGVuIGJvdGggZW5kcG9pbnRzIHN1cHBvcnQgSUNF IE1vYmlsaXR5LCBhbmQgKGIpIHdoZW4gDQpvbmx5DQpvbmUgZW5kcG9pbnQgc3VwcG9ydHMgSUNF IE1vYmlsaXR5LCB3aGljaCB1c2VzIGEgVFVSTiBzZXJ2ZXIgLS0gYSANCmRpZmZlcmVudA0Kc29y dCBvZiBuZXR3b3JrIGluZnJhc3RydWN0dXJlLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHkNCg0KDQpXZSBhcmUgdW5saWtlbHkgdG8g Z2V0IHRpbWUgaW4gTU1VU0lDIHRvIHByZXNlbnQgdGhpcyBkcmFmdCwgYnV0IGFyZQ0KaW50ZXJl c3RlZCBpbiBmZWVkYmFjay4NCg0KLWQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCg0K --=_alternative 0041E56648257A47_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLERhbjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SGF2ZSBzaW11bHRhbmVv dXMgbW9iaWxpdHkgYmVlbg0KY29uc2lkZXJlZCBpbiB0aGlzIGRyYWZ0PyA8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+ DQo8YnI+DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7RGFuIFdpbmcmcXVvdDsgJmx0O2R3aW5nQGNpc2NvLmNv bSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrei vP7IyzogJm5ic3A7bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wNy0yNSAwODoxOTwvZm9udD4NCjx0ZCB3aWR0aD02 NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7bW11c2ljQGlldGYub3Jn Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7J1ByYXNoYW50aCBQYXRpbCBcKHByYXNwYXRp XCknJnF1b3Q7DQombHQ7cHJhc3BhdGlAY2lzY28uY29tJmd0OywgJnF1b3Q7J1RpcnVtYWxlc3dh ciBSZWRkeSBcKHRpcmVkZHlcKScmcXVvdDsNCiZsdDt0aXJlZGR5QGNpc2NvLmNvbSZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPltNTVVTSUNdIElDRSBNb2JpbGl0eTwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+TU1VU0lDLDxicj4NCjxicj4N Ckxvc2luZyBvciBhY3F1aXJpbmcgYW4gaW50ZXJmYWNlIG9mdGVuIGhhcHBlbnMgd2l0aCBtb2Jp bGUgZGV2aWNlcywgc3VjaA0KYXM8YnI+DQp3aGVuIGEgZGV2aWNlIGdldHMgd2l0aGluIFdpRmkg cmFuZ2Ugb3IgbGVhdmVzIDNHIHJhbmdlLiAmbmJzcDtUb2RheSB0aGUNCmluZHVzdHJ5PGJyPg0K Z2VuZXJhbGx5IHJlbGllcyBvbiB0ZWNobmlxdWVzIGJlbG93IGxheWVyIDMgdG8gaGlkZSB0aGUg SVAgYWRkcmVzcyBjaGFuZ2U8YnI+DQpmcm9tIHRoZSByZW1vdGUgZW5kcG9pbnQgKGUuZy4sIExJ U1AsIE1vYmlsZSBJUCkuICZuYnNwO1RoZXNlIGV4aXN0aW5nDQp0ZWNobmlxdWVzPGJyPg0KaGF2 ZSBzb21lIGRyYXdiYWNrcywgc3VjaCBhcyByZXF1aXJpbmcgc3VwcG9ydCBpbiB0aGUgbmV0d29y azxicj4NCmluZnJhc3RydWN0dXJlLjxicj4NCjxicj4NCklDRSBNb2JpbGl0eSBleHBsb3JlcyBo b3cgdG8gYWNjb21wbGlzaCBhIHNpbWlsYXIgZnVuY3Rpb24gZm9yIElDRS1pbml0aWF0ZWQ8YnI+ DQpmbG93cyB3aXRob3V0IG5lZWRpbmcgc3VwcG9ydCBpbiB0aGUgZW5kcG9pbnQgb3IgaW4gdGhl IG5ldHdvcmsuICZuYnNwO0luc3RlYWQsPGJyPg0KdGhlIG1vYmlsaXR5IHN1cHBvcnQgaXMgcHJv dmlkZWQgYXQgdGhlIElDRSBsYXllciAoc3VjaCBhcyBSVFAsIFNSVFAsIG9yPGJyPg0KUlRDV0VC J3MgZGF0YSBjaGFubmVsIChTUlRQIG92ZXIgVURQKSkuICZuYnNwO1RoZSBkb2N1bWVudCBkaXNj dXNzZXMgaG93DQp0d288YnI+DQphcHByb2FjaGVzOiAmbmJzcDsoYSkgd2hlbiBib3RoIGVuZHBv aW50cyBzdXBwb3J0IElDRSBNb2JpbGl0eSwgYW5kIChiKQ0Kd2hlbiBvbmx5PGJyPg0Kb25lIGVu ZHBvaW50IHN1cHBvcnRzIElDRSBNb2JpbGl0eSwgd2hpY2ggdXNlcyBhIFRVUk4gc2VydmVyIC0t IGEgZGlmZmVyZW50PGJyPg0Kc29ydCBvZiBuZXR3b3JrIGluZnJhc3RydWN0dXJlLjxicj4NCjxi cj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctbW11c2ljLWljZS1tb2Jp bGl0eTxicj4NCjxicj4NCjxicj4NCldlIGFyZSB1bmxpa2VseSB0byBnZXQgdGltZSBpbiBNTVVT SUMgdG8gcHJlc2VudCB0aGlzIGRyYWZ0LCBidXQgYXJlPGJyPg0KaW50ZXJlc3RlZCBpbiBmZWVk YmFjay48YnI+DQo8YnI+DQotZDxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4N Cm1tdXNpY0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW11c2ljPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0041E56648257A47_=-- From dwing@cisco.com Thu Jul 26 10:16:20 2012 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 5600421F8625; Thu, 26 Jul 2012 10:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.978 X-Spam-Level: X-Spam-Status: No, score=-108.978 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_CHARSET_FARAWAY=2.45, 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 k1mfY0t4xnYl; Thu, 26 Jul 2012 10:16:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8FA21F85C4; Thu, 26 Jul 2012 10:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2756; q=dns/txt; s=iport; t=1343322979; x=1344532579; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=zg0Cnfxv+CIa8xfJ7AY1s8OrY2ugtA3r/H9u/Jm4FKQ=; b=H2UmZO1jKoC5mzLEdp1fLwpcMiZWYugDx0OxQsxJv0s2Ah3PiA00Y5YN umd3sX2hA+U3NSDzAkpcZeZ0V+nWhDnQPFIAnR1hDB2TekWMhWScNNgE3 SR/WX0cOC2CELpQQ/yY/50qMDPGhUe0PbiUn4YpRwJNKu5Mrlw7vfc7wt E=; X-IronPort-AV: E=Sophos;i="4.77,660,1336348800"; d="scan'208";a="49993680" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 26 Jul 2012 17:16:18 +0000 Received: from dwingWS ([10.21.78.151]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6QHGIWb005006; Thu, 26 Jul 2012 17:16:18 GMT From: "Dan Wing" To: References: <048b01cd69fb$35469ba0$9fd3d2e0$@com> In-Reply-To: Date: Thu, 26 Jul 2012 10:16:17 -0700 Message-ID: <053301cd6b52$5e4d58b0$1ae80a10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1rJhnWFU5Y0bxNT+OcYUaPvUGzLgAK+SgQ Content-Language: en-us Cc: "'Prashanth Patil \(praspati\)'" , mmusic@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , mmusic-bounces@ietf.org Subject: Re: [MMUSIC] ICE Mobility 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, 26 Jul 2012 17:16:20 -0000 > -----Original Message----- > From: zhou.sujing@zte.com.cn [mailto:zhou.sujing@zte.com.cn] > Sent: Thursday, July 26, 2012 4:59 AM > To: Dan Wing > Cc: mmusic@ietf.org; mmusic-bounces@ietf.org; 'Prashanth Patil > (praspati)'; 'Tirumaleswar Reddy (tireddy)' > Subject: =B4=F0=B8=B4: [MMUSIC] ICE Mobility >=20 >=20 > Hi,Dan >=20 > Have simultaneous mobility been considered in this draft? No. A TURN server would be safe if both endpoints are losing IP address at = the same time, so that the TURN server can be the stable address. But that = is not yet discussed in the draft. Transitioning from TURN to p2p, during = a mobility event, is something we plan to add to the document. First we wanted to discuss TURN (and the new attributes) and discuss ICE (and the = new attributes). Combining the two, into the most complex scenario where = both endpoints experience loss of IP interface at the same time, is what we wanted to describe last after the easier scenarios are clearer. -d >=20 > Regards~~~ >=20 > -Sujing Zhou >=20 >=20 >=20 > "Dan Wing" > =B7=A2=BC=FE=C8=CB: mmusic-bounces@ietf.org >=20 > 2012-07-25 08:19 =CA=D5=BC=FE=C8=CB > > =B3=AD=CB=CD > "'Prashanth Patil \(praspati\)'" , "'Tirumaleswar > Reddy \(tireddy\)'" > =D6=F7=CC=E2 > [MMUSIC] ICE Mobility >=20 >=20 >=20 >=20 >=20 >=20 > MMUSIC, >=20 > Losing or acquiring an interface often happens with mobile devices, > such as > when a device gets within WiFi range or leaves 3G range. Today the > industry > generally relies on techniques below layer 3 to hide the IP address > change > from the remote endpoint (e.g., LISP, Mobile IP). These existing > techniques > have some drawbacks, such as requiring support in the network > infrastructure. >=20 > ICE Mobility explores how to accomplish a similar function for ICE- > initiated > flows without needing support in the endpoint or in the network. > Instead, > the mobility support is provided at the ICE layer (such as RTP, SRTP, > or > RTCWEB's data channel (SRTP over UDP)). The document discusses how = two > approaches: (a) when both endpoints support ICE Mobility, and (b) = when > only > one endpoint supports ICE Mobility, which uses a TURN server -- a > different > sort of network infrastructure. >=20 > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility >=20 >=20 > We are unlikely to get time in MMUSIC to present this draft, but are > interested in feedback. >=20 > -d >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 From prvs=7554170d8a=aallen@rim.com Thu Jul 26 14:27:09 2012 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 11BC511E80B3 for ; Thu, 26 Jul 2012 14:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 a-slSQfxa6DC for ; Thu, 26 Jul 2012 14:27:08 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2C611E80A4 for ; Thu, 26 Jul 2012 14:27:07 -0700 (PDT) X-AuditID: 0a412830-b7f406d000002ae0-5a-5011b62a0758 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id D1.C6.10976.B26B1105; Thu, 26 Jul 2012 21:27:07 +0000 (GMT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 16:27:06 -0500 From: Andrew Allen To: "Miguel A. Garcia" , mmusic Thread-Topic: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-media-capabilities-14 Thread-Index: AQHNXmoKGiHr6ysY002JA110GAvlTZc8LdUQ Date: Thu, 26 Jul 2012 21:27:06 +0000 Message-ID: References: <4FFBD398.9050706@ericsson.com> In-Reply-To: <4FFBD398.9050706@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXC5Zyvq6u9TTDA4OASLov9j0It1nxawW4x dfljFgdmj19fr7J5LFnyk8njy+XPbAHMUQ2MNkmJJWXBmel5+nY2iXl5+SWJJakKKanFybZK PqnpiTkKAUWZZYnJlQoumcXJOYmZualFSgqZKbZKJkoKBTmJyam5qXkltkqJBQWpeSlKdlwK GMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMlON6GTJ2PuzpVMBc/YKw6vfcvewLifrYuR k0NCwETi0rdpLBC2mMSFe+vB4kICvUwSE3vduhi5gOwtjBI3lk9nB0mwCShLLP89gxHEFhEI lHhx+iUjSBGzQCejxM5py8ASwgKeEt/WPmODKPKSuHz6NSuEbSSx5u5vsBoWAVWJ7tnfwWxe AQ+JBb1TWSA2a0t8bNgJtoxTQEfi0MZrzCA2I9B130+tYQKxmQXEJW49mc8EcbWAxJI955kh bFGJl4//sULYihJ/935nhajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydhZSFpmIWmZ haRlASPLKkbB3IxiAzPD5LxkvaLMXL281JJNjKDU4ahhsIPx/XuLQ4wCHIxKPLz7lwsGCLEm lhVX5h5ilOBgVhLh9QYJ8aYkVlalFuXHF5XmpBYfYrQAhspEZinu5HxgWssriTc2MEDhKInz ZnzjCxASSAcmn+zU1ILUIphWJg5OkNFcUiLFwBSSWpRYWpIRD0p08cXAVCfVwKi/fFVpl5Ff /YolVttmqJaud3rWtuCI7TRu5lUxvGt9dgoU1tc/K59bcyLUNDoiweJazqv1ye2iYooaX97L sESkxSiybojfclHwKOuW9LTXt3ZyLZG+zcwWMJM/XWIbX+SRXe+3ZvIX3W26FS+fErl2gRRf oZzcC077sMxry15K/YzzzPVhVGIpzkg01GIuKk4EABWH3MhRAwAA Cc: "draft-ietf-mmusic-sdp-media-capabilities.authors@tools.ietf.org" Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-media-capabilities-14 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, 26 Jul 2012 21:27:09 -0000 I have reviewed this and think it's ready to be published > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Miguel A. Garcia > Sent: Tuesday, July 10, 2012 2:03 AM > To: mmusic > Cc: draft-ietf-mmusic-sdp-media-capabilities.authors@tools.ietf.org > Subject: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-media-capabilities-14 > > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-sdp-media-capabilities-14 > > available at: > http://www.ietf.org/id/draft-ietf-mmusic-sdp-media-capabilities-14.txt > > The WGLC ends on July 25th, 2012. > > Please reply to this e-mail to send comments, so that the authors and > the > mailing list are all copied. > > /Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------------------------------------------------------------- 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 zhou.sujing@zte.com.cn Sun Jul 29 20:18:38 2012 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 3BB3121F8606 for ; Sun, 29 Jul 2012 20:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.413 X-Spam-Level: X-Spam-Status: No, score=-96.413 tagged_above=-999 required=5 tests=[AWL=3.011, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 S6W1zA3+qNHH for ; Sun, 29 Jul 2012 20:18:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4B10821F8585 for ; Sun, 29 Jul 2012 20:18:37 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723978252052; Mon, 30 Jul 2012 11:07:51 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 41138.978252052; Mon, 30 Jul 2012 11:18:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6U3IUob031383 for ; Mon, 30 Jul 2012 11:18:30 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: mmusic@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 30 Jul 2012 11:18:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-30 11:18:29, Serialize complete at 2012-07-30 11:18:29 Content-Type: multipart/alternative; boundary="=_alternative 001229AD48257A4B_=" X-MAIL: mse02.zte.com.cn q6U3IUob031383 Subject: [MMUSIC] Any body have interest in draft-zhou-mmusic-sdes-keymod-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, 30 Jul 2012 03:18:38 -0000 This is a multipart message in MIME format. --=_alternative 001229AD48257A4B_= Content-Type: text/plain; charset="US-ASCII" Pls give comments. Regards~~~ -Sujing Zhou --=_alternative 001229AD48257A4B_= Content-Type: text/html; charset="US-ASCII"
Pls give comments.

Regards~~~

-Sujing Zhou --=_alternative 001229AD48257A4B_=-- From mary.ietf.barnes@gmail.com Mon Jul 30 09:01:52 2012 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 4BFE611E80A2; Mon, 30 Jul 2012 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 AZMb63bC+WGJ; Mon, 30 Jul 2012 09:01:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD51811E8091; Mon, 30 Jul 2012 09:01:38 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3756685lbb.31 for ; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PId8U94hGEYbu5smaElfkBUjb1gvpuDGTWoqh9zUkwE=; b=r9iy1q1yXoxn/VCdB6qwt8oVHTTwJuEfMOnfn4NFb96x0Xm8VQuHv90LzQq2CWoBmM 9k4w2x7MY7UoUUJWbzqsQxXvmd86aEizyY4aOBW0pyNDL/ooaemoU4Qs740s29AOjC7+ tINCt5vkaa3b2G34PeCsVSK+yiXSpsuCXyq9C+5DBpvbZZN1YdaYyVHRi9cF6EZiyBk0 pEI1qTMeoLSXrZk7OcLlwTwb4SqXcjZ2N/XqfP3zYawE8Y7zhm3cQ3MxEqsXvoHS/kDj Eky7RYNfG++5LxD1a98Qyt71Ut7vFiBubdxE2MwoOMMHDXCH/JyOJ3ILFtpInokJgOQy z/0Q== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr11865796lab.8.1343664097632; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 11:01:37 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043745473ca27b04c60e2ddb Subject: Re: [MMUSIC] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) 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, 30 Jul 2012 16:01:52 -0000 --f46d043745473ca27b04c60e2ddb Content-Type: text/plain; charset=ISO-8859-1 Tutorial is in Georgia A. On Tue, Jul 10, 2012 at 6:37 PM, Mary Barnes wrote: > Hi all, > > Apologies to the many of you that are receiving this multiple times. > Unfortunately, the RAI list is not a superset of participants in WGs > that might be interested in this. Folks that aren't on the RAI list > might want to subscribe here: > https://www.ietf.org/mailman/listinfo/rai > > Please note the important update below with regards to (no) lunch. > > We are planning a lunchtime tutorial on Monday, July 30th. The > primary objective is to provide more background on telepresence as > well as an update of the work in CLUE to the broader RAI and IETF > community. This will hopefully facilitate the process of completing > the CLUE protocol work as it gets broader community review. > > Here's the proposed outline: > 1) Introduction to telepresence > 2) Example telepresence scenarios > 3) Introduction to the CLUE work > 4) High level introduction of framework > 5) One or two use cases as examples of how the CLUE framework is > realized - showing how existing protocols (e.g., SDP, RTP) are > integral to the solution along > with additional signaling for CLUE. > > We have reserved a room for around 50 and attendance will be FCFS, so > please RSVP by Friday, July 13th, 2012 (5pm Pacific) > http://www.doodle.com/mzu3nmdeehkxkiys > > **Important update*: * Please note that we do not have a sponsor for > lunch, thus folks will have to grab something before the tutorial (sorry, I > tried). However, we will have some cookies and veggies/fruit available so > folks will have something to munch. > > Please send any questions/comments to me (or to the CLUE WG mailing list) > rather than reply all. > > Regards, > Mary > CLUE WG co-chair > > --f46d043745473ca27b04c60e2ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tutorial is in Georgia A.=A0

On Tue, Jul = 10, 2012 at 6:37 PM, Mary Barnes <mary.ietf.barnes@gmail.com&= gt; wrote:
Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important= update*: =A0Please note that we do not have a sponsor for lunch, thus = folks will have to grab something before the tutorial (sorry, I tried). =A0= However, we will have some cookies and veggies/fruit available so folks wil= l have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair


--f46d043745473ca27b04c60e2ddb-- From miguel.a.garcia@ericsson.com Mon Jul 30 10:02:33 2012 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 87C4721F85C4 for ; Mon, 30 Jul 2012 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 XrZI8hagCN0D for ; Mon, 30 Jul 2012 10:02:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B545421F8567 for ; Mon, 30 Jul 2012 10:02:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-5c-5016be27f157 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 33.DE.07365.72EB6105; Mon, 30 Jul 2012 19:02:31 +0200 (CEST) Received: from [159.107.48.10] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Mon, 30 Jul 2012 19:02:31 +0200 Message-ID: <5016BE23.6050001@ericsson.com> Date: Mon, 30 Jul 2012 19:02:27 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <4FFBD398.9050706@ericsson.com> In-Reply-To: <4FFBD398.9050706@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvra76PrEAgw1frCz2Pwq1mLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfFv4yXmgiesFT3bH7A3MJ5l6WLk5JAQMJH4 sHEiG4QtJnHh3nogm4tDSOAUo8SRu99YIZzVjBLrTtxjAqniFdCWmHHhCpjNIqAqserbfzCb TcBconXjRnYQW1QgUOL57C3sEPWCEidnPgHbJiJgKtE2awsLyFBmgaWMEiufdDKDJIQFPCXe H7wDViQEtOBjw06wZk4BHYlDG6+B1TAL2EpcmHOdBcKWl9j+dg4zRL2mxOSbS5knMArOQrJv FpKWWUhaFjAyr2IUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECAzWg1t+6+5gPHVO5BCjNAeLkjgv V9J+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MzAL2L2MtchznRDo+dVzPaXRv2bq7S/13 7Pq5sSiKdfmGDV3sDH/TI3qZTnqmhaxtOVCcftpXTFmnsuaiWtNEyxjx/nWtcWec+RTmnDcK lF197nJNo0j05Yfrj29wYg8+WtngWR7a7CIovsOvbHLNR0+FH0kHZfr474ftvzj1zmQGBZsj jP5KLMUZiYZazEXFiQB3s0ZvJAIAAA== Cc: mmusic , "draft-ietf-mmusic-sdp-media-capabilities.authors@tools.ietf.org" Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-sdp-media-capabilities-14 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, 30 Jul 2012 17:02:33 -0000 The WGLC of draft-ietf-mmusic-sdp-media-capabilities-14 is over now. This draft has been around for quite some time, so it is expected that people are sufficiently happy with the current version. We will proceed to request publication. /Miguel On 10/07/2012 9:02, Miguel A. Garcia wrote: > This is to start a 2-week Working Group Last Call for > > draft-ietf-mmusic-sdp-media-capabilities-14 > > available at: > http://www.ietf.org/id/draft-ietf-mmusic-sdp-media-capabilities-14.txt > > The WGLC ends on July 25th, 2012. > > Please reply to this e-mail to send comments, so that the authors and the > mailing list are all copied. > > /Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From internet-drafts@ietf.org Mon Jul 30 14:23:20 2012 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 0CFD511E80E4; Mon, 30 Jul 2012 14:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 U5UJ5oGUWjuX; Mon, 30 Jul 2012 14:23:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B101411E80EE; Mon, 30 Jul 2012 14:23:18 -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: 4.32 Message-ID: <20120730212318.9036.78590.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 14:23:18 -0700 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-20.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, 30 Jul 2012 21:23:20 -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 Wor= king Group of the IETF. Title : An Extension to the Session Description Protocol (SDP) a= nd Real-time Transport Protocol (RTP) for Media Loopback Author(s) : Hadriel Kaplan Kaynam Hedayat Nagarjuna Venna Paul E. Jones Nathan Stratton Filename : draft-ietf-mmusic-media-loopback-20.txt Pages : 33 Date : 2012-07-30 Abstract: The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media types and attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-20 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From HKaplan@acmepacket.com Mon Jul 30 14:30:00 2012 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 8713811E8109 for ; Mon, 30 Jul 2012 14:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rV3PhH9w5qym for ; Mon, 30 Jul 2012 14:29:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87511E80F6 for ; Mon, 30 Jul 2012 14:29:59 -0700 (PDT) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 30 Jul 2012 17:29:55 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.53]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Mon, 30 Jul 2012 17:29:55 -0400 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: I-D Action: draft-ietf-mmusic-media-loopback-20.txt Thread-Index: AQHNbpp1sSLECum1rkWJtYWpxSIvCA== Date: Mon, 30 Jul 2012 21:29:54 +0000 Message-ID: <9BC1C0BB-642A-4CC6-8484-5C0C0841B862@acmepacket.com> References: <20120730212318.9036.78590.idtracker@ietfa.amsl.com> In-Reply-To: <20120730212318.9036.78590.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <28DB2B97D425B64387EDE260F94C1F26@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAC+NgFvrEqsTGxcLFwCCqe/mPWIDBs83PTvJbXJ+3j9mBMYAhijUzLym/IoE143dnI1PBZvGKS8cKGxinCnUxcnEICaxklFjwfSk7hDOHUWJx63zGLkZODjYBXYkNe9cyg9giAuoSrZv7WEFsZgFHiZOPJgI1cHAICzhIvNjpC1HiKHH1wwxWCFtP4nzXejCbRUBVovPJXbCRvEA11zrvMIHYQkCtb55sB6vhBIq//fURzGYUEJP4fmoNE8QqcYlbT+aD2RIC2hLbX+1jhbB1JDZdW8UCcoKEgLXE7rtiEGEBiSV7zjND2EoSvbffQbWKSrx8/A+qVU/iS/cBNgg7UOLaxh52CNtU4s2SSywQtq3EibV/oea4S7SuXwgV95U4tHgJlC0v8f/efSjbQeLtru1Q9QoSPw/8ZIaZM3HVcijbW+Ly1DdQ9UYS1782sU1g1JyF5EsIW0diwe5PbBC2rcTa5rPMELa2xLKFr8FsXgFBiZMzn7AsYGRdxSiaWpKbmJmjl5icm1qQmJydWqKXnJ+7iRGYHm5oSrDtYHz0Tf0QoyQHk5Io76FvYgFCfEn5KZUZicUZ8UWlOanFhxglOHiURHgFgOlGiLe4IDG3ODMdJiXDwaEkwfv+N1BKsCg1PbUiLTOnJLUIIn2KUVJKnPcGSFIApC+jNA8ud4lRVEqY1+s9UI6nILUoN7MEIn6LUZjjIZMQS15+XqoU0IkMQKDB+IpRnINRSZj3Lsgsnsy8ErgTXgFdxwR0XYgD2HUliQgpqQbG7JNxrq72Uz5GqB5af1XvfdjpBbuE1ly9nWmq9Lvcf1PBr/Kb0fqeM3Z6NWjLCM/5vU6aXXUW04r0mXWMqiYH16qVr/M1rJwp+1/GWL9jto3agzPTPzG772hwWF+72Ffqrdv7dd6hK6aIhD95Edhhxnr9/hHLuSbrfkfw16xki+Ft+nmqb7awEktxRqKhFnNRcSIAs3TBw 4UDAAA= Cc: "mmusic-chairs@tools.ietf.org" Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-20.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, 30 Jul 2012 21:30:00 -0000 FYI - this new version merely corrects the acknowledgements section. No re= al changes were made. -hadriel On Jul 30, 2012, at 5:23 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control Wo= rking Group of the IETF. >=20 > Title : An Extension to the Session Description Protocol (SDP)= and Real-time Transport Protocol (RTP) for Media Loopback > Author(s) : Hadriel Kaplan > Kaynam Hedayat > Nagarjuna Venna > Paul E. Jones > Nathan Stratton > Filename : draft-ietf-mmusic-media-loopback-20.txt > Pages : 33 > Date : 2012-07-30 >=20 > Abstract: > The wide deployment of Voice over IP (VoIP), Text and Video over IP > services has introduced new challenges in managing and maintaining > real-time voice/text/video quality, reliability, and overall > performance. In particular, media delivery is an area that needs > attention. One method of meeting these challenges is monitoring > the media delivery performance by looping media back to the > transmitter. This is typically referred to as "active monitoring" > of services. Media loopback is especially popular in ensuring the > quality of transport to the edge of a given VoIP, Real-time Text or > Video over IP service. Today in networks that deliver real-time > media, short of running 'ping' and 'traceroute' to the edge, > administrators are left without the necessary tools to actively > monitor, manage, and diagnose quality issues with their service. > The extension defined herein adds new SDP media types and > attributes, which enable establishment of media sessions where the > media is looped back to the transmitter. Such media sessions will > serve as monitoring and troubleshooting tools by providing the > means for measurement of more advanced VoIP, Real-time Text and > Video over IP performance metrics. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-20 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 magnus.westerlund@ericsson.com Tue Jul 31 18:36:12 2012 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 E28D111E8192 for ; Tue, 31 Jul 2012 18:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.197 X-Spam-Level: X-Spam-Status: No, score=-106.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 opX-jcHmj2f2 for ; Tue, 31 Jul 2012 18:36:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BB22A11E818E for ; Tue, 31 Jul 2012 18:36:11 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-a1-5018880a3f86 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C5.E6.12641.A0888105; Wed, 1 Aug 2012 03:36:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Wed, 1 Aug 2012 03:36:09 +0200 Message-ID: <501887FF.7020203@ericsson.com> Date: Tue, 31 Jul 2012 18:35:59 -0700 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mmusic (E-mail)" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+JvrS5Xh0SAwe4dEhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsf9jcwFD+UrfmxewtjA+FSyi5GTQ0LAROLvpvOsELaYxIV7 69m6GLk4hAROMUrMfPqXHSQhJLCMUeLwlRAQm1dAW2Lmkl9gDSwCqhJLZ3xjA7HZBCwkbv5o BLNFBQIlvm09zgpRLyhxcuYTFhBbREBdonVzH1hcWMBZovfFXSCbA2ixpMTtAykgYWYBPYkp V1sYIWx5ieats5khTtCWaGjqYJ3AyD8LydRZSFpmIWlZwMi8ilE4NzEzJ73cXC+1KDO5uDg/ T684dRMjMMgObvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTDO+eC8Ul1X+WTWd/EYycd+J8JLvlWf3PlpFouKqG7XsRX3lHdW8FuuTFY4qJ/J4yS0SXuW 7/nj4W8KC400khNm2Tfy7dl6WVf9o9KSzfrXbDPfrJjL5x9+56jn0vmPfoi0/rNlPGY+eW2O b/ktnQKNo0x/dZsWrVmeunvBlwXabv9Tzq9YwXpEiaU4I9FQi7moOBEAF5oF4wACAAA= Subject: [MMUSIC] Proposal for LS reply regarding RTCP bandwidth negotiation 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, 01 Aug 2012 01:36:13 -0000 MMUSIC WG, Below you find my proposal for a reply to the LS we received from 3GPP SA4 WG. https://datatracker.ietf.org/liaison/1159/ This is intended as a starting point for a discussion of what reply we as WG want to send. So please review it and send comments on this. I would highly appreciate any insights how this issues is currently dealt with in any implementations. If we have knowledge of multiple different solutions then that is something we should indicate. Also if any existing solution clashes with SA4's proposed solution. I also raise the question if we should initiate any update of RFC 3556. And if we can come to such an agreement and have volunteers we may be able to strengthen the language in the last paragraph. Otherwise that language is intended to signal a preference for the driving parties in SA4 to come help us update the RFC in MMUSIC WG. === Source: IETF MMUSIC WG To: 3GPP TSG SA WG4 (SA4) Title: Reply regarding On RTCP Bandwidth Negotiation MMUSIC WG thanks SA4 for seeking our input on this topic. We agree with SA4's identification that there exist no well defined behavior for the negotiation of the RTCP bandwidth parameters RR and RS when used in Offer/Answer context to negotiate a unicast transported RTP session. It is clear that the RTP session participating end-points do need to agree on common values or there exist a potential for interoperability failures. Regarding the proposed recommendations for negotiation MMUSIC WG has the following comments. 1. Based on the limitations of Offer/Answer and the requirement on arriving at a common RTCP bandwidth value for RR and RS respectively there exist only two possible choices. A. that the Offerer dictates the bandwidth values without any possibilities for B to change the values, or B. as proposed in the LS that the Offerer suggest a value that the Answerer may modify. On that high level MMUSIC WG considers the proposed solution appropriate 2. However, we do consider the limitation that the answerer only can keep or reduce the bandwidth values to a be a potential issue in the proposed recommendation. The reason is that the answering party then have no way of increasing the value if the peer agent is not willing to accept the higher suggested values in a subsequent Offer. This may appear a reasonable behavior in many cases and considering limited total bandwidth on the path between the agents. However, when an agent requires a higher RTCP bandwidth due to its usage of some RTCP based extensions this could prevent such functionality from being used. And the bandwidth usage could be addressed by having the answering party to reduce the total RTP session bandwidth in its answer and be forced to reduce the bit-rate delivered to the other agent in proportion to the increase of the RTCP bandwidth. 3. Has any special consideration been taken around the usage of RR or RS parameter values of 0. If either offerer or answerer intended to turn off RTCP completely or for receivers only, it is questionable that this should have precedence over the other agents desire to use RTCP. MMUSIC may consider to update RFC 3556 to amend the lack of Offer/Answer rules for the RR and RS bandwidth parameters. This would be to provide all users of the RTCP bandwidth parameter with guidance on this issue. If the participants in SA4 WG considers that appropriate, MMUSIC WG would highly appreciate any engagement from the SA4 participants in the MMUSIC WG. Actions: None -- end of proposed LS reply -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------