From salvatore.loreto@ericsson.com Sat Dec 1 03:03:14 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 65AA721F84DC for ; Sat, 1 Dec 2012 03:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR3QcKDXC3NA for ; Sat, 1 Dec 2012 03:03:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1816421F8485 for ; Sat, 1 Dec 2012 03:03:12 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-57-50b9e3efe853 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 54.88.26143.FE3E9B05; Sat, 1 Dec 2012 12:03:11 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sat, 1 Dec 2012 12:03:10 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E68F62420 for ; Sat, 1 Dec 2012 13:03:10 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C1F0B53D1D for ; Sat, 1 Dec 2012 13:03:09 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6B46153D1C for ; Sat, 1 Dec 2012 13:03:09 +0200 (EET) Message-ID: <50B9E3ED.6010604@ericsson.com> Date: Sat, 1 Dec 2012 13:03:09 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> In-Reply-To: <5093A2C9.9040001@alvestrand.no> Content-Type: multipart/alternative; boundary="------------030003070604020701090703" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvje77xzsDDDadlbOYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4MrYuW8Be8NCu4kfHROYGxln6XYycHBICJhIz+2czQ9hiEhfu rWfrYuTiEBI4yShx9u4OdghnPaPE7v7zUJkLjBIHZl9kgXAOM0rM3DWVCcI5wyjx9VAzC8gw XgFtiZ5lb8AGswioSGxbuBYsziZgJvH84RawuKhArMTWS5fZIOoFJU7OfAJWIyIgLDHj7V+w uLCArcSRpZNZQWwhAR2JbRP/gPVyCuhKfP85jQnEZhYIkzjd+oUd4gk1iavnNjFD1GtJ9J7t ZJrAKDwLyYpZSFogbFuJC3OuQ8XlJba/ncMMYetKXPg/BUV8ASPbKkb23MTMnPRyo02MwPA/ uOW36g7GO+dEDjFKc7AoifNab93jLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRPvhw0M9v Ku0ZzjLvnulk3V2q8ntixplaXn3xfYJTttZ/VC2b0xrw6cuH43d4Ez+/WcJXfWHljqlKorwc bmcz5O02Vcs4lb2MYNO9sO58/qcK/ood727M4NvK+u6LeIrPazHvzmtnL678tH9u7ArtcEuO lf8uGzU/TfrOL9TteqayPuXcd+lOJZbijERDLeai4kQAJyUxU00CAAA= Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 01 Dec 2012 11:03:14 -0000 --------------030003070604020701090703 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Harald, sorry to be late on this and thanks a lot for raising the question IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" traffic is something that belongs to the BUNDLE discussion, and there won't be anything about how to bundle in this draft. To answer your question at present I don't think there should be anything special for DTLS/SCTP However, what I have in my working copy on the draft (I will publish it at some point next week) and it can be interesting to you is the possibility to have multiple SCTP associations on top of the same DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios): Running SCTP over DTLS make possible to have multiple SCTP associations on top of the same DTLS connection; each SCTP association make use of a distinct port number that is mainly used to demultiplex the associations. If the sub-field is 'DTLS/ SCTP' the sub-fields contain SCTP association port numbers. When a list of port number identifiers is given, this implies that all of these associations MUST run on top of the DTLS connection. For the payload type assignments the "a=sctpmap:" attribute SHOULD be used to map from a port number to a media encoding name that identifies the payload format transported by the association or the actual application protocol running on top of it. m=application 54111 DTLS/SCTP 5000 5001 5002 c=IN IP4 79.97.215.79 a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16 a=sctpmap:5001 protocol=XXX;streams=2 a=sctpmap:5002 protocol=YYY;streams=1 best regards Salvatore On 11/2/12 12:39 PM, Harald Alvestrand wrote: > As currently specified, the DTLS/SCTP protocol is carefully specified > in such a way that it can ride on the same 5-tuple as an SRTP session. > I'd like to keep that property when we SDP-negotiate it. > > The proposed syntax for DTLS/SCTP seems to be > > m= DTLS/SCTP mostly meaningless> > > I see two ways to define this as a multiplex: > > - Give the same port number as another m= line in the same SDP session > - Give a meaningless port number, and use the a=group:BUNDLE (of > whatever flavor) to give which port number it's actually multiplexed > together with. > > The best way to do this may be obvious after the BUNDLE discussion, > but in case there are other considerations .... are there thoughts? > > Harald > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Salvatore Loreto, PhD www.sloreto.com --------------030003070604020701090703 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi Harald,

sorry to be late on this
and thanks a lot for raising the question

IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" traffic is something that belongs
to the BUNDLE discussion, and there won't be anything about how to bundle in this draft.
To answer your question at present I don't think there should be anything special for DTLS/SCTP

However, what I have in my working copy on the draft (I will publish it at some point next week)
and it can be interesting to you is the possibility to have multiple SCTP associations on top of the same
DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios):

   Running SCTP over DTLS make possible to have multiple SCTP
   associations on top of the same DTLS connection; each SCTP
   association make use of a distinct port number that is mainly used to
   demultiplex the associations.  If the <proto> sub-field is 'DTLS/
   SCTP' the <fmt> sub-fields contain SCTP association port numbers.
   When a list of port number identifiers is given, this implies that
   all of these associations MUST run on top of the DTLS connection.
   For the payload type assignments the "a=sctpmap:" attribute
   SHOULD be used to map from a port number to a media
   encoding name that identifies the payload format transported by the
   association or the actual application protocol running on top of it.


              m=application 54111 DTLS/SCTP 5000 5001 5002
              c=IN IP4 79.97.215.79
              a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16
              a=sctpmap:5001 protocol=XXX;streams=2
              a=sctpmap:5002 protocol=YYY;streams=1
           
best regards
Salvatore



On 11/2/12 12:39 PM, Harald Alvestrand wrote:
As currently specified, the DTLS/SCTP protocol is carefully specified in such a way that it can ride on the same 5-tuple as an SRTP session. I'd like to keep that property when we SDP-negotiate it.

The proposed syntax for DTLS/SCTP seems to be

m=<something, likely application> <port number> DTLS/SCTP <fmt data, mostly meaningless>

I see two ways to define this as a multiplex:

- Give the same port number as another m= line in the same SDP session
- Give a meaningless port number, and use the a=group:BUNDLE (of whatever flavor) to give which port number it's actually multiplexed together with.

The best way to do this may be obvious after the BUNDLE discussion, but in case there are other considerations .... are there thoughts?

               Harald

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



-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------030003070604020701090703-- From harald@alvestrand.no Sat Dec 1 06:53: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 09DE221F8CB0 for ; Sat, 1 Dec 2012 06:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.398 X-Spam-Level: X-Spam-Status: No, score=-109.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAGSPpFJEucC for ; Sat, 1 Dec 2012 06:53:51 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A99D221F8CAB for ; Sat, 1 Dec 2012 06:53:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6DE239E19D for ; Sat, 1 Dec 2012 15:53:47 +0100 (CET) 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 A6ulOVtIlXK2 for ; Sat, 1 Dec 2012 15:53:46 +0100 (CET) Received: from [192.168.10.97] (unknown [193.214.121.5]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2656439E090 for ; Sat, 1 Dec 2012 15:53:46 +0100 (CET) Message-ID: <50BA19F9.4040701@alvestrand.no> Date: Sat, 01 Dec 2012 15:53:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> In-Reply-To: <50B9E3ED.6010604@ericsson.com> Content-Type: multipart/alternative; boundary="------------070302030106040309020501" Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 01 Dec 2012 14:53:52 -0000 This is a multi-part message in MIME format. --------------070302030106040309020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/01/2012 12:03 PM, Salvatore Loreto wrote: > Hi Harald, > > sorry to be late on this > and thanks a lot for raising the question > > IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" > traffic is something that belongs > to the BUNDLE discussion, and there won't be anything about how to > bundle in this draft. > To answer your question at present I don't think there should be > anything special for DTLS/SCTP The interesting difference is that the multiplexing between DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried in SSRCs, which means: - There can be only one DTLS/SCTP stream in a bundle (which may have multiple associations, as you state below); you can't have multiple lines with proto DTLS/SCTP in a bundle. - None of the ordinary BUNDLE considerations about colliding parameters apply Since the ability to multiplex was thought an important factor for selecting this stacking, we'd better make sure we specify how it's being done. > > However, what I have in my working copy on the draft (I will publish > it at some point next week) > and it can be interesting to you is the possibility to have multiple > SCTP associations on top of the same > DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios): > > Running SCTP over DTLS make possible to have multiple SCTP > associations on top of the same DTLS connection; each SCTP > association make use of a distinct port number that is mainly > used to > demultiplex the associations. If the sub-field is 'DTLS/ > SCTP' the sub-fields contain SCTP association port numbers. > that's a sentence fragment I can't parse, so I hope you revise that before submission. If there's a comma before "the sub-fields" it parses. > > When a list of port number identifiers is given, this implies that > all of these associations MUST run on top of the DTLS connection. > For the payload type assignments the "a=sctpmap:" attribute > SHOULD be used to map from a port number to a media > encoding name that identifies the payload format transported by the > association or the actual application protocol running on top > of it. > > > m=application 54111 DTLS/SCTP 5000 5001 5002 > c=IN IP4 79.97.215.79 > a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16 > a=sctpmap:5001 protocol=XXX;streams=2 > a=sctpmap:5002 protocol=YYY;streams=1 > > > best regards > Salvatore > > > > On 11/2/12 12:39 PM, Harald Alvestrand wrote: >> As currently specified, the DTLS/SCTP protocol is carefully specified >> in such a way that it can ride on the same 5-tuple as an SRTP >> session. I'd like to keep that property when we SDP-negotiate it. >> >> The proposed syntax for DTLS/SCTP seems to be >> >> m= DTLS/SCTP > mostly meaningless> >> >> I see two ways to define this as a multiplex: >> >> - Give the same port number as another m= line in the same SDP session >> - Give a meaningless port number, and use the a=group:BUNDLE (of >> whatever flavor) to give which port number it's actually multiplexed >> together with. >> >> The best way to do this may be obvious after the BUNDLE discussion, >> but in case there are other considerations .... are there thoughts? >> >> Harald >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > -- > Salvatore Loreto, PhD > www.sloreto.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------070302030106040309020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/01/2012 12:03 PM, Salvatore Loreto wrote:
Hi Harald,

sorry to be late on this
and thanks a lot for raising the question

IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" traffic is something that belongs
to the BUNDLE discussion, and there won't be anything about how to bundle in this draft.
To answer your question at present I don't think there should be anything special for DTLS/SCTP
The interesting difference is that the multiplexing between DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried in SSRCs, which means:

- There can be only one DTLS/SCTP stream in a bundle (which may have multiple associations, as you state below); you can't have multiple lines with proto DTLS/SCTP in a bundle.
- None of the ordinary BUNDLE considerations about colliding parameters apply

Since the ability to multiplex was thought an important factor for selecting this stacking, we'd better make sure we specify how it's being done.


However, what I have in my working copy on the draft (I will publish it at some point next week)
and it can be interesting to you is the possibility to have multiple SCTP associations on top of the same
DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios):

   Running SCTP over DTLS make possible to have multiple SCTP
   associations on top of the same DTLS connection; each SCTP
   association make use of a distinct port number that is mainly used to
   demultiplex the associations.  If the <proto> sub-field is 'DTLS/
   SCTP' the <fmt> sub-fields contain SCTP association port numbers.
that's a sentence fragment I can't parse, so I hope you revise that before submission. If there's a comma before "the <fmt> sub-fields" it parses.
   When a list of port number identifiers is given, this implies that
   all of these associations MUST run on top of the DTLS connection.
   For the payload type assignments the "a=sctpmap:" attribute
   SHOULD be used to map from a port number to a media
   encoding name that identifies the payload format transported by the
   association or the actual application protocol running on top of it.


              m=application 54111 DTLS/SCTP 5000 5001 5002
              c=IN IP4 79.97.215.79
              a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16
              a=sctpmap:5001 protocol=XXX;streams=2
              a=sctpmap:5002 protocol=YYY;streams=1
           
best regards
Salvatore



On 11/2/12 12:39 PM, Harald Alvestrand wrote:
As currently specified, the DTLS/SCTP protocol is carefully specified in such a way that it can ride on the same 5-tuple as an SRTP session. I'd like to keep that property when we SDP-negotiate it.

The proposed syntax for DTLS/SCTP seems to be

m=<something, likely application> <port number> DTLS/SCTP <fmt data, mostly meaningless>

I see two ways to define this as a multiplex:

- Give the same port number as another m= line in the same SDP session
- Give a meaningless port number, and use the a=group:BUNDLE (of whatever flavor) to give which port number it's actually multiplexed together with.

The best way to do this may be obvious after the BUNDLE discussion, but in case there are other considerations .... are there thoughts?

               Harald

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



-- 
Salvatore Loreto, PhD
www.sloreto.com


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

--------------070302030106040309020501-- From harald@alvestrand.no Sat Dec 1 07:00: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 B3A3C21E8091 for ; Sat, 1 Dec 2012 07:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoUL9jeQBFfE for ; Sat, 1 Dec 2012 07:00:37 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 80FE221E805F for ; Sat, 1 Dec 2012 07:00:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9380F39E19D for ; Sat, 1 Dec 2012 16:00:35 +0100 (CET) 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 clDHFlCgtgq5 for ; Sat, 1 Dec 2012 16:00:33 +0100 (CET) Received: from [192.168.10.97] (unknown [193.214.121.5]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 27BDB39E090 for ; Sat, 1 Dec 2012 16:00:33 +0100 (CET) Message-ID: <50BA1B90.2010905@alvestrand.no> Date: Sat, 01 Dec 2012 16:00:32 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50B624CC.4010501@alvestrand.no> <50B6704F.2000108@alum.mit.edu> In-Reply-To: <50B6704F.2000108@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 01 Dec 2012 15:00:38 -0000 On 11/28/2012 09:13 PM, Paul Kyzivat wrote: > Inline > > On 11/28/12 9:50 AM, Harald Alvestrand wrote: >> Perhaps we can do some real work rather than just disagreeing on >> principles. >> >> Perhaps the most contentious issue now is "what should an M-line be". >> As far as I can tell, M-lines and their parameters describe 3 things: >> >> - Properties of the transport flow / RTP session (Transport, or T for >> short) >> - Properties that make sense to apply to an individual media stream, and >> may need to be different for different media streams in the same >> combined RTP session (Flow, or F for short) >> - Properties that make sense to apply to all streams of a given type >> (Media, or M for short) >> >> The properties that can be represented in M-lines are found in two IANA >> registries, both on >> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: >> >> - att-field (both session and media level) >> - att-field (media level only) >> >> I make it 179 entries in these categories, combined. >> >> I see the same kind of work being necessary no matter which way we go: >> >> - If we go with M-lines describing a whole RTP session (the MMT >> proposal), each property of the "F" class that we stil need needs to be >> copied onto a property in the "att-field (source level)" registry. >> >> - If we go with M-lines describing groups of media streams, degenerating >> to a single media stream in the case of using "a=inactive" for stream >> muting (the BUNDLE and TOGETHER proposals), each property of the "T" >> class needs to be described as "MUST have consistent values for all the >> combined M-lines", "MUST be taken only from the first M-line in the >> bundle argument", or "must get special treatment". >> >> - In both cases, the "M"-class lines don't need any special treatment. >> They just need to be present in all the M-lines where they're relevant. >> >> I've created a spreadsheet here: >> >> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE >> >> >> with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for >> "necessary" and 0 for "will never matter"). >> >> Anyone should be able to write it. >> If a few of us do a quick job of markup on it, I think we should be able >> to have a more realistic assessment in a few days. >> >> I've started, but much of this is unknown to me. Can others help? > > Don't forget the media formats listed in the m-line itself. The > meaning of these depends on the param. The focus of this > discussion is on those values that correspond to various > flavors of RTP. There are a bunch of values that don't > correspond to RTP, and that assign different meanings to the format > parameters. I'm happy to ignore anything but RTP. BUNDLE isn't defined for anything else (while, in the parallel discussion, we may get DTLS/SCTP within its scope too, the RTP parameter set is our current problem). > > AFAIK, of the currently defined proto values only the RTP-related ones > have the notion of multiple flows within the session. But the sdp > extensions for SCTP media are currently being defined. That certainly > has the potential to be considered as multiple flows, and should be > considered in this discussion. > > For RTP transports, the formats are payload type numbers, and these > are mapped to actual formats (codecs) via a=rtpmap. I see that you > have proposed that rtpmap be per-media, not transport or flow. I guess > this means that the same payload type number could mean one thing for > all audio flows over the transport, and something different for all > video flows over the same transport. Absolutely not; that would violate both common sense and the BUNDLE draft as specified. The BUNDLE drafts explicitly say that a payload type number can only be used for one thing. > But the payload numbers to be used (specified on the m-line) is > negotiated in O/A. How would that work for audio vs. video? ISTM it > would be preferred to negotiate payload numbers and types > independently per flow. See above. They can't collide. > > Regarding the "importance" column in the table: I don't understand how > you have assigned values. In what frame of reference is importance to > be assessed? My completely subjective opinion, for RTCWEB. If others disagree, please change and add a comment. If we all agree, it becomes consensus. > > Regarding a=label: This could be any of T/F/M, depending on > application use. I think we must assume T, and consider an alternative > for F. (And for M if we think it is needed.) The claim that a=label can be used to mark flows makes it F. If the people making that claim are willing to let go of the claim, we can change it to T. But at the moment its proponents are clearly calling for F. > > (I'm not convinced we need to identify an "M" scope distinct from T > and F.) Please consider the ones marked as such and tell me the argument for why it's obviously one or the other. In particular, a=rtpmap: is clearly not T, but when we have multiple flows on an RTP session utilizing the same codec, I'd hate to be forced to create multiple identical payload types just because it was classified as an F field. > > Thanks, > Paul > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Sat Dec 1 10:09:47 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 3727521E8095 for ; Sat, 1 Dec 2012 10:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.202 X-Spam-Level: X-Spam-Status: No, score=0.202 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQkj1tkoTFrv for ; Sat, 1 Dec 2012 10:09:46 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E249621E803A for ; Sat, 1 Dec 2012 10:09:45 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id WFQ81k0020xGWP851J9lsq; Sat, 01 Dec 2012 18:09:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id WJ9k1k00Y3ZTu2S3YJ9lgZ; Sat, 01 Dec 2012 18:09:45 +0000 Message-ID: <50BA47E8.4010909@alum.mit.edu> Date: Sat, 01 Dec 2012 13:09:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> In-Reply-To: <50BA19F9.4040701@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354385385; bh=S4QoN4/YxvXm1Vz58jXt70v1pp0gencyUVIDzAnCi1I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QCORNk0nQiSwX9ebX23ZlFtVUsncMVXorSVxZp9QDo/jd/YUmVnKMZS5mz+/usoRb 7pmrSvO1KuP1EgLq0OKOE/Ln5uJ2KdG15XuMg5wL1VCHScq5Amcsk9noYogqeglLkd zXRd+oWpD8hvrLvbuCgj0do6/WRHSD0USFTOG7cM1fXzlaAVbMbR4EmgwcAj24BFLB /fYcLIsIS0f/8m4v81hGt65DYyFzUXXW6NbGXienzwk5MHExkCo3/UaA6H+pACPS7J +wl/YPe57q+veuqGFi07a7cLemD4bTpA5AMgHtbhxbsfkvnYtm+m+aBVr8rCKOQWWb NffvFN3H+g2mQ== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 01 Dec 2012 18:09:47 -0000 I must say that I am getting confused about what is being multiplexed here. We must be very careful to be precise. SCTP defines an *association*, which in simple cases is bound to a 5-tuple. (For now lets not talk about the cases where each end can have more than one address.) SCTP multiplexes multiple one-way *streams* over an association. (These are not RTP streams.) RTCWEB binds pairs of sctp-streams together into *channels*. A channel could be used like a TCP connection. Or like a UDP connection. Where we currently use SDP to negotiate the application level use of a UDP or TCP connection, we might (probably will) also like to use SDP to negotiate the application level use of an SCTP stream or channel. For instance, we might want to negotiate one channel for use with the CLUE protocol and another for the BFCP channel. (We might want that in a pure sip environment - no rtcweb.) But we might also want do the same thing when one or both ends rtcweb clients. And in that case they might also want to dynamically assign other channels for rtcweb-specific use. It could also be useful to define an RTP session over a channel. And in fact, define multiple RTP sessions, each over a distinct channel. For *each* such RTP session we would want to negotiate payload numbers and the mappings of those numbers to codec attributes, etc. This starts to look like a fractal structure, which could present some problems for describing in SDP. Here are some examples of different ways multiplexing the same set of media belonging to a single sip session/call or rtcweb PeerConnection. (I'm intentionally not using SDP to describe this, in order to show the similarities between the alternatives and to avoid arguments of hypothetical SDP.) For instance, we could have a sip session/call that has the following media: - audio RTP session - a set of payload numbers for use in this audio RTP session - mappings for each payload number to codec parameters - several audio RTP streams within the audio RTP session - video RTP session - a set of payload numbers for use in this audio RTP session - mappings for each payload number to codec parameters - several video RTP streams within the video RTP session - a BFCP over TCP connection - an SCTP association over DTLS over UDP - an SCTP channel used for the CLUE protocol But we could also multiplex the same stuff differently: - a single RTP session for audio/video - a set of payload numbers, some for audio and some for video - mappings for each payload number to codec a/v codec parameters - several audio RTP streams - several video RTP streams - an SCTP association over DTLS over UDP - an SCTP channel used for BFCP - an SCTP channel used for the CLUE protocol Or in principle the same stuff could be multiplexed as: - an SCTP association over DTLS over UDP - an SCTP channel used for BFCP - an SCTP channel used for the CLUE protocol - an SCTP channel used for audio RTP - a set of payload numbers for use in this audio RTP session - mappings for each payload number to codec parameters - several audio RTP streams within the audio RTP session - an SCTP channel used for video RTP - a set of payload numbers for use in this video RTP session - mappings for each payload number to codec parameters - several video RTP streams within the video RTP session Or: - an SCTP association over DTLS over UDP - an SCTP channel used for BFCP - an SCTP channel used for the CLUE protocol - an SCTP channel used for a single audio session & stream - a set of payload numbers for use in this RTP session/stream - mappings for each payload number to codec parameters - an SCTP channel used for a single audio session & stream - a set of payload numbers for use in this RTP session/stream - mappings for each payload number to codec parameters - an SCTP channel used for a single audio session & stream - a set of payload numbers for use in this RTP session/stream - mappings for each payload number to codec parameters - an SCTP channel used for a single video session & stream - a set of payload numbers for use in this RTP session/stream - mappings for each payload number to codec parameters - an SCTP channel used for a single video session & stream - a set of payload numbers for use in this RTP session/stream - mappings for each payload number to codec parameters - an SCTP channel used for a single video session & stream - a set of payload numbers for use in this RTP session/stream - mappings for each payload number to codec parameters Note that multiplexing multiple RTP sessions over SCTP channels is topologically equivalent to Magnus' proposal for a shim layer to multiplex multiple RTP sessions over a single UDP 5-tuple. So I could sketch out some added alternatives based on that. But I won't. Of course not all of these are currently possible because we don't have all the necessary mappings defined. But they could be. For instance, I think we will *need* BFCP over a channel if we want to support an rtcweb client that has full functionality in a conference. It may be harder to motivate a need for RTP over an sctp channel. My point in bringing this up is that I think we must be very clear about which of these various forms of multiplexing we are trying to represent *now*, and which we at least want to leave room to support in the future. Without at least thinking about it we are likely to come up with something that won't extend to a case we might later wish to support. Thanks, Paul On 12/1/12 9:53 AM, Harald Alvestrand wrote: > On 12/01/2012 12:03 PM, Salvatore Loreto wrote: >> Hi Harald, >> >> sorry to be late on this >> and thanks a lot for raising the question >> >> IMO how to multiplex DTLS/SCTP traffic with te rest of the "WebRTC" >> traffic is something that belongs >> to the BUNDLE discussion, and there won't be anything about how to >> bundle in this draft. >> To answer your question at present I don't think there should be >> anything special for DTLS/SCTP > The interesting difference is that the multiplexing between DTLS/SCTP > traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried > in SSRCs, which means: > > - There can be only one DTLS/SCTP stream in a bundle (which may have > multiple associations, as you state below); you can't have multiple > lines with proto DTLS/SCTP in a bundle. I originally thought this, but after some discussions in Atlanta I am not sure about this. IIUC, SCTP has its own port concept. In a kernel implementation that would be used to demux multiple SCTP associations to the processes that own them, etc. But in a user mode implementation over another transport this should be available to the application to demux multiple SCTP associations. So I think you might indeed be able to have multiple SCTP associations over the same DTLS/SCTP instance. > - None of the ordinary BUNDLE considerations about colliding parameters > apply > > Since the ability to multiplex was thought an important factor for > selecting this stacking, we'd better make sure we specify how it's being > done. > >> >> However, what I have in my working copy on the draft (I will publish >> it at some point next week) >> and it can be interesting to you is the possibility to have multiple >> SCTP associations on top of the same >> DTLS connection (for future WebRTC scenarios, or non WebRTC scenarios): >> >> Running SCTP over DTLS make possible to have multiple SCTP >> associations on top of the same DTLS connection; each SCTP >> association make use of a distinct port number that is mainly >> used to >> demultiplex the associations. If the sub-field is 'DTLS/ >> SCTP' the sub-fields contain SCTP association port numbers. >> > that's a sentence fragment I can't parse, so I hope you revise that > before submission. If there's a comma before "the sub-fields" it > parses. >> >> When a list of port number identifiers is given, this implies that >> all of these associations MUST run on top of the DTLS connection. >> For the payload type assignments the "a=sctpmap:" attribute >> SHOULD be used to map from a port number to a media >> encoding name that identifies the payload format transported by the >> association or the actual application protocol running on top >> of it. >> >> >> m=application 54111 DTLS/SCTP 5000 5001 5002 >> c=IN IP4 79.97.215.79 >> a=sctpmap:5000 protocol=webrtc-DataChannel;streams=16 >> a=sctpmap:5001 protocol=XXX;streams=2 >> a=sctpmap:5002 protocol=YYY;streams=1 >> >> >> best regards >> Salvatore >> >> >> >> On 11/2/12 12:39 PM, Harald Alvestrand wrote: >>> As currently specified, the DTLS/SCTP protocol is carefully specified >>> in such a way that it can ride on the same 5-tuple as an SRTP >>> session. I'd like to keep that property when we SDP-negotiate it. >>> >>> The proposed syntax for DTLS/SCTP seems to be >>> >>> m= DTLS/SCTP >> mostly meaningless> >>> >>> I see two ways to define this as a multiplex: >>> >>> - Give the same port number as another m= line in the same SDP session >>> - Give a meaningless port number, and use the a=group:BUNDLE (of >>> whatever flavor) to give which port number it's actually multiplexed >>> together with. >>> >>> The best way to do this may be obvious after the BUNDLE discussion, >>> but in case there are other considerations .... are there thoughts? >>> >>> Harald >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com >> >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Sat Dec 1 11:54:17 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 83DFF1F0C73 for ; Sat, 1 Dec 2012 11:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xg4+o+lyb1j for ; Sat, 1 Dec 2012 11:54:16 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC91F0C72 for ; Sat, 1 Dec 2012 11:54:14 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id WKXF1k0031swQuc51KuEjP; Sat, 01 Dec 2012 19:54:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id WKuD1k00l3ZTu2S3bKuEQe; Sat, 01 Dec 2012 19:54:14 +0000 Message-ID: <50BA6065.3090000@alum.mit.edu> Date: Sat, 01 Dec 2012 14:54:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <50B624CC.4010501@alvestrand.no> <50B6704F.2000108@alum.mit.edu> <50BA1B90.2010905@alvestrand.no> In-Reply-To: <50BA1B90.2010905@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354391654; bh=IMc7+JvBFXyL7MIAdfNMjB4z3x0dmty6MZL34me+ETQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c6iY9KbzslRWt+BXceIYbttI9g7XJDtIKx1mP1aGtlbEdqMgTTw1bCzmId6miPqnR 175v7Fe/4D9faMDNnKI/eFaUaH/hq4kDYkDC/MrIqapAjCOr1lCm11VcvCDtIXkARL 0jcItbFYJRGN9Eiek3fz1C5swmlA0LL9IO1tVo/GDmHd5FP7qiubcC/4fVkszblneR YiUwzJ8EwMUlU/f20Z9Pmqen3zZUMepApgBz6xxl3YGc4O9d91cHUT68BumPaMpOPx cI8beQID/1qtk2/3zZfZzSvb5UsF1PU2N67asUyRPofg+RnJisj6Hd8ZympYUvsMTX ohnsKfiGV8EGA== Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 01 Dec 2012 19:54:17 -0000 inline On 12/1/12 10:00 AM, Harald Alvestrand wrote: > On 11/28/2012 09:13 PM, Paul Kyzivat wrote: >> Inline >> >> On 11/28/12 9:50 AM, Harald Alvestrand wrote: >>> Perhaps we can do some real work rather than just disagreeing on >>> principles. >>> >>> Perhaps the most contentious issue now is "what should an M-line be". >>> As far as I can tell, M-lines and their parameters describe 3 things: >>> >>> - Properties of the transport flow / RTP session (Transport, or T for >>> short) >>> - Properties that make sense to apply to an individual media stream, and >>> may need to be different for different media streams in the same >>> combined RTP session (Flow, or F for short) >>> - Properties that make sense to apply to all streams of a given type >>> (Media, or M for short) >>> >>> The properties that can be represented in M-lines are found in two IANA >>> registries, both on >>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: >>> >>> - att-field (both session and media level) >>> - att-field (media level only) >>> >>> I make it 179 entries in these categories, combined. >>> >>> I see the same kind of work being necessary no matter which way we go: >>> >>> - If we go with M-lines describing a whole RTP session (the MMT >>> proposal), each property of the "F" class that we stil need needs to be >>> copied onto a property in the "att-field (source level)" registry. >>> >>> - If we go with M-lines describing groups of media streams, degenerating >>> to a single media stream in the case of using "a=inactive" for stream >>> muting (the BUNDLE and TOGETHER proposals), each property of the "T" >>> class needs to be described as "MUST have consistent values for all the >>> combined M-lines", "MUST be taken only from the first M-line in the >>> bundle argument", or "must get special treatment". >>> >>> - In both cases, the "M"-class lines don't need any special treatment. >>> They just need to be present in all the M-lines where they're relevant. >>> >>> I've created a spreadsheet here: >>> >>> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE >>> >>> >>> with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for >>> "necessary" and 0 for "will never matter"). >>> >>> Anyone should be able to write it. >>> If a few of us do a quick job of markup on it, I think we should be able >>> to have a more realistic assessment in a few days. >>> >>> I've started, but much of this is unknown to me. Can others help? >> >> Don't forget the media formats listed in the m-line itself. The >> meaning of these depends on the param. The focus of this >> discussion is on those values that correspond to various >> flavors of RTP. There are a bunch of values that don't >> correspond to RTP, and that assign different meanings to the format >> parameters. > I'm happy to ignore anything but RTP. BUNDLE isn't defined for anything > else (while, in the parallel discussion, we may get DTLS/SCTP within its > scope too, the RTP parameter set is our current problem). Hmm. OK, I went looking for something that says that. Section 7.1 does say that, though I can find no text that talks about which m-line values may be bundled together. >> AFAIK, of the currently defined proto values only the RTP-related ones >> have the notion of multiple flows within the session. But the sdp >> extensions for SCTP media are currently being defined. That certainly >> has the potential to be considered as multiple flows, and should be >> considered in this discussion. >> >> For RTP transports, the formats are payload type numbers, and these >> are mapped to actual formats (codecs) via a=rtpmap. I see that you >> have proposed that rtpmap be per-media, not transport or flow. I guess >> this means that the same payload type number could mean one thing for >> all audio flows over the transport, and something different for all >> video flows over the same transport. > Absolutely not; that would violate both common sense and the BUNDLE > draft as specified. The BUNDLE drafts explicitly say that a payload type > number can only be used for one thing. >> But the payload numbers to be used (specified on the m-line) is >> negotiated in O/A. How would that work for audio vs. video? ISTM it >> would be preferred to negotiate payload numbers and types >> independently per flow. > See above. They can't collide. >> >> Regarding the "importance" column in the table: I don't understand how >> you have assigned values. In what frame of reference is importance to >> be assessed? > My completely subjective opinion, for RTCWEB. If others disagree, please > change and add a comment. If we all agree, it becomes consensus. Frankly I don't even know what most of the parameters in the list are. But I assume that most of them were at one time important to somebody - at least those who defined it. Perhaps some are now obsolete, but most likely not all of them. It isn't helpful if we all agree on what is important and what is not if we don't agree on the criterion for importance. A couple of meanings that could be useful here: - those that might be used in an rtcweb context vs. those that nobody thinks make any sense to use with rtcweb - those that make sense to use in a bundle/mmt vs. those that may only be used outside a bundle/mmt. I guess I would prefer the latter. It has the benefit that those nobody understands can be put in the unimportant category, and they won't be broken by bundle/mmt. >> Regarding a=label: This could be any of T/F/M, depending on >> application use. I think we must assume T, and consider an alternative >> for F. (And for M if we think it is needed.) I may have misunderstood your intended meaning for M. I assume you meant all RTP streams of the same media type (audio or video) within a single 5-tuple. > The claim that a=label can be used to mark flows makes it F. a=label is a media-level attribute, so it is bound to an m-line. In the absence of bundle, regardless of whether the corresponding RTP session has one or several flows. The m-line has a particular media type, so I guess it could be viewed as either T or M. Some applications of a=label may assume or require that the labeled m-line contain only one RTP stream. If so, then perhaps the label could be considered to be F. But we can't really know that. > If the > people making that claim are willing to let go of the claim, we can > change it to T. But at the moment its proponents are clearly calling for F. Is your point that you know of cases where there is a desire to label an individual RTP-stream, and you would like to have a way to do that when RTP-streams are multiplexed in an RTP session? I'm ok with that. >> (I'm not convinced we need to identify an "M" scope distinct from T >> and F.) > Please consider the ones marked as such and tell me the argument for why > it's obviously one or the other. > > In particular, a=rtpmap: is clearly not T, but when we have > multiple flows on an RTP session utilizing the same codec, I'd hate to > be forced to create multiple identical payload types just because it was > classified as an F field. a=rtpmap is the *only* one currently marked M. And ISTM that it clearly is a T. I say this because, as you have said elsewhere, each payload type number is tied to a particular codec of a particular codec, whether audio or video. It isn't possible to have payload type number 100 mean one thing for audio and a different thing for video. OTOH, when multiplexing audio and video on the same 5-tuple it is necessary to know whether a particular a=rtpmap is intended to be audio or video. Normally it inherits that from the m-line it belongs to. That still works for bundle. It doesn't work for mmt. So, I still think there is no need for M. But a=rtpmap is "special" in that it requires an extra datum. Unless there are other attributes that have the same issue I think this is just a special case. Thanks, Paul From christer.holmberg@ericsson.com Sun Dec 2 10:37: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 BE86721F85BC for ; Sun, 2 Dec 2012 10:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAGVq7atdk4C for ; Sun, 2 Dec 2012 10:37:33 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DE08A21F8669 for ; Sun, 2 Dec 2012 10:37:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-32-50bb9feb0ad8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.58.11564.BEF9BB05; Sun, 2 Dec 2012 19:37:31 +0100 (CET) Received: from ESESSHC022.ericsson.se (153.88.183.84) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 2 Dec 2012 19:37:31 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 19:37:30 +0100 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] M-lines: Wikifying it - importance column Thread-Index: AQHN0LwWkU9ZE3XtWUeddfwi2cgeNQ== Date: Sun, 2 Dec 2012 18:37:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04C917@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvje7r+bsDDN51aVsc6+tis5i6/DGL A5PHlQlXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJXR/fE/a8EF1oqGzia2BsbtLF2M7BwSAiYS nUFdjJxAlpjEhXvr2boYuTiEBE4ySvRtmswE4exglJjSfwwqs5hRYv3q28xdjBwcbAIWEt3/ tEG6RQSCJZZ/2s4EYgsL2Es86NjMDhF3kDi5+BMrSLmIgJ5E77RKEJNFQEVi6vIIkApeAW+J /isTwToZgW74fmoNmM0sIC5x68l8JojbBCSW7DnPDGGLSrx8/A9sooSAosTyfjmIch2JBbs/ sUHY2hLLFr5mhhgvKHFy5hMWEFsIKN6yeAL7BEbRWUg2zELSPgtJ+ywk7QsYWVYxsucmZuak lxtuYgTGwMEtv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xsBd57aEbrIIvXXn4pL9sbEnlmq8nCqv2cDwqSHrpXfztxUWSie2zUhS5HRv2rbw1VzhPNl0 QV3vezE8ttz+mRVV5RvStmyKODr1gnCgcl7fi7u/mPK/bJ8UcCuqyP++T5CZ5tJPbbsD1K4+ uvGy13ZfRniUxeevtlZ/750t//y7NFhmX1j5VSWW4oxEQy3mouJEAIasvc1PAgAA Subject: Re: [MMUSIC] M-lines: Wikifying it - importance column 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, 02 Dec 2012 18:37:33 -0000 Hi, >> Regarding the "importance" column in the table: I don't understand how >> you have assigned values. In what frame of reference is importance to >> be assessed? > My completely subjective opinion, for RTCWEB. If others disagree, please > change and add a comment. If we all agree, it becomes consensus. Maybe we should not spend too much time on the importance column at this po= int. Keep in mind that, as we do this in MMUSIC, RTCWEB is technically seen as o= nly one customer among others. The impotance becomes important if we run into trouble, and can't find a wa= y how to deal with a specific parameter. But, let's have that discussion on= ce/if we get there. Regards, Christer From harald@alvestrand.no Sun Dec 2 23:53:41 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 65F5E21F86FD for ; Sun, 2 Dec 2012 23:53:41 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At9-HzXySeWA for ; Sun, 2 Dec 2012 23:53:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BED4D21F857E for ; Sun, 2 Dec 2012 23:53:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10BEC39E0FD for ; Mon, 3 Dec 2012 08:53:38 +0100 (CET) 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 o7BEQhBAVJT2 for ; Mon, 3 Dec 2012 08:53:37 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7001839E04C for ; Mon, 3 Dec 2012 08:53:37 +0100 (CET) Message-ID: <50BC5A81.6050503@alvestrand.no> Date: Mon, 03 Dec 2012 08:53:37 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> In-Reply-To: <50BA47E8.4010909@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 07:53:41 -0000 On 12/01/2012 07:09 PM, Paul Kyzivat wrote: > I must say that I am getting confused about what is being multiplexed > here. We must be very careful to be precise. > > SCTP defines an *association*, which in simple cases is bound to a > 5-tuple. (For now lets not talk about the cases where each end can > have more than one address.) > > SCTP multiplexes multiple one-way *streams* over an association. > (These are not RTP streams.) > > RTCWEB binds pairs of sctp-streams together into *channels*. I'm not talking about any of these levels. I'm talking about the reuse of the RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764 section 5.1.2. I said the same thing earlier on this thread (Nov 5), when you first responded (thanks for being the first responder!) You do make the point that the term "multiplex" is so over-used, it should probably be abandoned altogether - but that section talks about (de)multiplexing, so changing terminology is probably too late for that particular usage. Harald From christer.holmberg@ericsson.com Mon Dec 3 00:01: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 EB1DD21F87B9 for ; Mon, 3 Dec 2012 00:01:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+Zr4a805Piw for ; Mon, 3 Dec 2012 00:01:10 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E3F0C21F870E for ; Mon, 3 Dec 2012 00:01:09 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-97-50bc5c37b3a3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.E2.11564.73C5CB05; Mon, 3 Dec 2012 09:00:55 +0100 (CET) Received: from ESESSHC001.ericsson.se (153.88.183.21) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 09:00:55 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 09:00:55 +0100 From: Christer Holmberg To: Harald Alvestrand , "mmusic@ietf.org" Thread-Topic: [MMUSIC] SCTP question: Where does it multiplex? Thread-Index: AQHNuOZOfTvjBV7D20u9zqAifYT++pgD5FSAgABAboCAADbCAIACeIWAgAARPpA= Date: Mon, 3 Dec 2012 08:00:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> In-Reply-To: <50BC5A81.6050503@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvja55zJ4Ag8PfBS2O9XWxWUxd/pjF gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4seEBU8Ez3opXz5YwNTC2c3cxcnJICJhI /Fl5gB3CFpO4cG89WxcjF4eQwElGiTvv1jJBODsYJU5NvccM4SxmlHj6bTZrFyMHB5uAhUT3 P22QbhGBYInln7YzgdjCArYSb098ZoOI20nc/LeIHcL2kzj1/REriM0ioCKxYmc/WA2vgLfE sylHwXqFBDYxSsy/LQdicwroSjy5f4cRxGYEuu77qTVgNcwC4hK3nsxngrhaQGLJnvPMELao xMvH/1ghbEWJnWfbmSHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gg9mpLtCyewD6BUXwWkhWz kLTPQtI+C0n7AkaWVYzsuYmZOenlhpsYgdFzcMtv3R2Mp86JHGKU5mBREuflStrvLySQnliS mp2aWpBaFF9UmpNafIiRiYNTqoFxhst3D/m93XqHzX++jIj/LnCp1P/kx2sMJtkPbt5sibqw hsn6/eTQ7/PmxNb2v58avOazRo+j7lzHa3+SDh2x7StJiuFr7c9bPEOn9Gn8ipIvm388jtx1 48OG5MLfgtZ/jdX/Ptb8tScmyWNNc++vJIWptoFKq0Uzmk/+P///sWob5/lwlq3rlFiKMxIN tZiLihMBPZSZeGwCAAA= Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 08:01:11 -0000 Hi, I guess it would be nice to hear from the browser/endpoint people whether t= hey see a need for covering non-RTP in BUNDLE. If NOT, it would mean a minimum of two 5-tuples, instead of one (one for th= e bundled RTP media, and one for the data channel). Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 3. joulukuuta 2012 9:54 To: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? On 12/01/2012 07:09 PM, Paul Kyzivat wrote: > I must say that I am getting confused about what is being multiplexed=20 > here. We must be very careful to be precise. > > SCTP defines an *association*, which in simple cases is bound to a=20 > 5-tuple. (For now lets not talk about the cases where each end can=20 > have more than one address.) > > SCTP multiplexes multiple one-way *streams* over an association.=20 > (These are not RTP streams.) > > RTCWEB binds pairs of sctp-streams together into *channels*. I'm not talking about any of these levels. I'm talking about the reuse of t= he RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 576= 4 section 5.1.2. I said the same thing earlier on this thread (Nov 5), when you first respon= ded (thanks for being the first responder!) You do make the point that the term "multiplex" is so over-used, it should = probably be abandoned altogether - but that section talks about (de)multipl= exing, so changing terminology is probably too late for that particular usa= ge. Harald _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Mon Dec 3 00:10: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 67FC421F887C for ; Mon, 3 Dec 2012 00:10:45 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG8R144MwJPI for ; Mon, 3 Dec 2012 00:10:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 494E621F8876 for ; Mon, 3 Dec 2012 00:10:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B039039E0FD; Mon, 3 Dec 2012 09:10:42 +0100 (CET) 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 wHDh0NXr+sUN; Mon, 3 Dec 2012 09:10:42 +0100 (CET) Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4C72D39E04C; Mon, 3 Dec 2012 09:10:41 +0100 (CET) Message-ID: <50BC5E80.4090006@alvestrand.no> Date: Mon, 03 Dec 2012 09:10:40 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 08:10:45 -0000 On 12/03/2012 09:00 AM, Christer Holmberg wrote: > Hi, > > I guess it would be nice to hear from the browser/endpoint people whether they see a need for covering non-RTP in BUNDLE. > > If NOT, it would mean a minimum of two 5-tuples, instead of one (one for the bundled RTP media, and one for the data channel). Speaking with my browser implementor hat on, I want to avoid adding an extra 5-tuple for data channels. Our stats on improvement from the introduction of rtcp-mux were pretty compelling that the issue is real. > > Regards, > > Christer > > > > > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand > Sent: 3. joulukuuta 2012 9:54 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > On 12/01/2012 07:09 PM, Paul Kyzivat wrote: >> I must say that I am getting confused about what is being multiplexed >> here. We must be very careful to be precise. >> >> SCTP defines an *association*, which in simple cases is bound to a >> 5-tuple. (For now lets not talk about the cases where each end can >> have more than one address.) >> >> SCTP multiplexes multiple one-way *streams* over an association. >> (These are not RTP streams.) >> >> RTCWEB binds pairs of sctp-streams together into *channels*. > I'm not talking about any of these levels. I'm talking about the reuse of the RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764 section 5.1.2. > > I said the same thing earlier on this thread (Nov 5), when you first responded (thanks for being the first responder!) > > You do make the point that the term "multiplex" is so over-used, it should probably be abandoned altogether - but that section talks about (de)multiplexing, so changing terminology is probably too late for that particular usage. > > Harald > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From Markus.Isomaki@nokia.com Mon Dec 3 01:03: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 353FB21F86D2 for ; Mon, 3 Dec 2012 01:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxIao3acVDBy for ; Mon, 3 Dec 2012 01:03:23 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 83C1021F8661 for ; Mon, 3 Dec 2012 01:03:23 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB392jo4001514; Mon, 3 Dec 2012 11:02:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 11:02:45 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.131]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0318.003; Mon, 3 Dec 2012 09:02:44 +0000 From: To: , Thread-Topic: [MMUSIC] SCTP question: Where does it multiplex? Thread-Index: AQHNz7N6WgV/cieAmkiYZjuifDh2VZgEB+uAgAA2wgCAAniGgIAAAgkAgAACugCAAAro0A== Date: Mon, 3 Dec 2012 09:02:44 +0000 Message-ID: References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> In-Reply-To: <50BC5E80.4090006@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2012 09:02:45.0357 (UTC) FILETIME=[F5A861D0:01CDD134] X-Nokia-AV: Clean Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 09:03:24 -0000 Hi, I agree that it would be useful to be able to run data channel on the same = 5-tuple as RTP/RTCP, and even making it the default and must-implement way = for the browsers. QoS/prioritization comes to mind as the only potential drawback. The endpoi= nt can naturally still give different priorities to the different component= s (audio, video, "data") it is sending. I assume SCTP also has TCP-style re= ceiver window that can be used to throttle reception if needed. And presuma= bly RMCAT will find solutions to congestion control in genenral. But from t= he network perspective there is only one flow, and the only(?) way to diffe= rentiate the components is to use DSCP. I don't think our QoS (or API) draf= t yet clearly explains how DSCP's are learned and set, or whether that is e= ven going to be a realistic solution.=20 Markus >-----Original Message----- >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >Behalf Of ext Harald Alvestrand >Sent: 03 December, 2012 10:11 >To: Christer Holmberg >Cc: mmusic@ietf.org >Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >On 12/03/2012 09:00 AM, Christer Holmberg wrote: >> Hi, >> >> I guess it would be nice to hear from the browser/endpoint people whethe= r >they see a need for covering non-RTP in BUNDLE. >> >> If NOT, it would mean a minimum of two 5-tuples, instead of one (one for >the bundled RTP media, and one for the data channel). > >Speaking with my browser implementor hat on, I want to avoid adding an >extra 5-tuple for data channels. > >Our stats on improvement from the introduction of rtcp-mux were pretty >compelling that the issue is real. > >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >> Sent: 3. joulukuuta 2012 9:54 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >> >> On 12/01/2012 07:09 PM, Paul Kyzivat wrote: >>> I must say that I am getting confused about what is being multiplexed >>> here. We must be very careful to be precise. >>> >>> SCTP defines an *association*, which in simple cases is bound to a >>> 5-tuple. (For now lets not talk about the cases where each end can >>> have more than one address.) >>> >>> SCTP multiplexes multiple one-way *streams* over an association. >>> (These are not RTP streams.) >>> >>> RTCWEB binds pairs of sctp-streams together into *channels*. >> I'm not talking about any of these levels. I'm talking about the reuse o= f the >RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764 >section 5.1.2. >> >> I said the same thing earlier on this thread (Nov 5), when you first >> responded (thanks for being the first responder!) >> >> You do make the point that the term "multiplex" is so over-used, it shou= ld >probably be abandoned altogether - but that section talks about >(de)multiplexing, so changing terminology is probably too late for that >particular usage. >> >> Harald >> >> _______________________________________________ >> 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 christer.holmberg@ericsson.com Mon Dec 3 02:23: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 A545921F8668 for ; Mon, 3 Dec 2012 02:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.891 X-Spam-Level: X-Spam-Status: No, score=-5.891 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVAa5ilftPKy for ; Mon, 3 Dec 2012 02:23:32 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DA5EA21F8661 for ; Mon, 3 Dec 2012 02:23:31 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-dc-50bc7da2ec39 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.60.06323.2AD7CB05; Mon, 3 Dec 2012 11:23:30 +0100 (CET) Received: from ESESSHC006.ericsson.se (153.88.183.36) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 11:23:29 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 11:23:29 +0100 From: Christer Holmberg To: Harald Alvestrand , mmusic Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA Date: Mon, 3 Dec 2012 10:23:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> In-Reply-To: <50B624CC.4010501@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B04D1FEESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje6i2j0BBk1bzSyO9XWxWUxd/pjF gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYvGwlU8GykIqOb2uZGxgPeHQxcnJICJhI bFu4lwXCFpO4cG89WxcjF4eQwElGiXn7z7FDODsYJd79nssI4SxmlFjy+jeQw8HBJmAh0f1P G6RbRMBN4tg8kG5ODmEBbYkHa/+xQMR1JM6v6GGGsI0kHp49B2azCKhIPOq5BlbPK+AtMXlL B5gtBFT//MNhRhCbU0BX4vrVJWBzGIGu+35qDROIzSwgLnHryXwmiKsFJJbsOc8MYYtKvHz8 jxXCVpTYebadGaI+X+JpYyMrxC5BiZMzn7BA7NKWaFk8gX0Co9gsJGNnIWmZhaQFIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jkz03MzEkvN9/ECIy2g1t+G+xg3HRf7BCjNAeLkjiv nup+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MoSrqf5SspdnZa6Z9cuNy3v+vWjDrTXyz U+r+0Cfn9KZsbYiZWS4peNLA+Bu7sojhy+7f2mZ+2ot7Pm9/eFxsk4b1pk/3Z/6dH83PGjjj z4xj7243tLknvn+yKNPtQdF1p/byDTY7F7yV3xppXN6Uu0rRq+NP64ZplSJvfbsqz8p6fM1J KFJWYinOSDTUYi4qTgQATawpNIQCAAA= Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 10:23:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B04D1FEESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A question for clarification: When talking about the "F" class, what do you mean by "stream"? Do you mean= individual sources associated with the m- line? Or, do you mean all source= s associated with the m- line? I ASSUME you mean all sources associated with the m- line, because otherwis= e you will need the a=3Dssrc attribute. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 28. marraskuuta 2012 16:51 To: mmusic Subject: [MMUSIC] M-lines: Wikifying it Perhaps we can do some real work rather than just disagreeing on principles= . Perhaps the most contentious issue now is "what should an M-line be". As far as I can tell, M-lines and their parameters describe 3 things: - Properties of the transport flow / RTP session (Transport, or T for short= ) - Properties that make sense to apply to an individual media stream, and ma= y need to be different for different media streams in the same combined RTP= session (Flow, or F for short) - Properties that make sense to apply to all streams of a given type (Media= , or M for short) The properties that can be represented in M-lines are found in two IANA reg= istries, both on http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: - att-field (both session and media level) - att-field (media level only) I make it 179 entries in these categories, combined. I see the same kind of work being necessary no matter which way we go: - If we go with M-lines describing a whole RTP session (the MMT proposal), = each property of the "F" class that we stil need needs to be copied onto a = property in the "att-field (source level)" registry. - If we go with M-lines describing groups of media streams, degenerating to= a single media stream in the case of using "a=3Dinactive" for stream mutin= g (the BUNDLE and TOGETHER proposals), each property of the "T" class needs= to be described as "MUST have consistent values for all the combined M-lin= es", "MUST be taken only from the first M-line in the bundle argument", or = "must get special treatment". - In both cases, the "M"-class lines don't need any special treatment. They= just need to be present in all the M-lines where they're relevant. I've created a spreadsheet here: https://docs.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVG= NV9lUFI3cHlIRFE with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for "necessar= y" and 0 for "will never matter"). Anyone should be able to write it. If a few of us do a quick job of markup on it, I think we should be able to= have a more realistic assessment in a few days. I've started, but much of this is unknown to me. Can others help? Harald --_000_7594FB04B1934943A5C02806D1A2204B04D1FEESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

A question for clarificat= ion:

 <= /p>

When talking about the &#= 8220;F” class, what do you mean by “stream”? Do you mean = individual sources associated with the m- line? Or, do you mean all sources= associated with the m- line?

 <= /p>

I ASSUME you mean all sou= rces associated with the m- line, because otherwise you will need the a=3Ds= src attribute.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ie= tf.org] On Behalf Of Harald Alvestrand
Sent: 28. marraskuuta 2012 16:51
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

 

Perhaps we can do som= e real work rather than just disagreeing on principles.

Perhaps the most contentious issue now is "what should an M-line be&qu= ot;.
As far as I can tell, M-lines and their parameters describe 3 things:

- Properties of the transport flow / RTP session (Transport, or T for short= )
- Properties that make sense to apply to an individual media stream, and ma= y need to be different for different media streams in the same combined RTP= session (Flow, or F for short)
- Properties that make sense to apply to all streams of a given type (Media= , or M for short)

The properties that can be represented in M-lines are found in two IANA reg= istries, both on
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:
- att-field (both session and media level)
- att-field (media level only)

I make it 179 entries in these categories, combined.

I see the same kind of work being necessary no matter which way we go:

- If we go with M-lines describing a whole RTP session (the MMT proposal), = each property of the "F" class that we stil need needs to be copi= ed onto a property in the "att-field (source level)" registry.
- If we go with M-lines describing groups of media streams, degenerating to= a single media stream in the case of using "a=3Dinactive" for st= ream muting (the BUNDLE and TOGETHER proposals), each property of the "= ;T" class needs to be described as "MUST have consistent values for all the combined M-lines", "MUST be taken only from t= he first M-line in the bundle argument", or "must get special tre= atment".

- In both cases, the "M"-class lines don't need any special treat= ment. They just need to be present in all the M-lines where they're relevan= t.

I've created a spreadsheet here:

https://docs.google.com/spreadsheet/ccc?key=3D0= Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

with 2 extra columns: "Class" (M, F or T) and "Importance&qu= ot; (1 for "necessary" and 0 for "will never matter").<= br>
Anyone should be able to write it.
If a few of us do a quick job of markup on it, I think we should be able to= have a more realistic assessment in a few days.

I've started, but much of this is unknown to me. Can others help?

            &nb= sp;         Harald




--_000_7594FB04B1934943A5C02806D1A2204B04D1FEESESSMB209ericsso_-- From harald@alvestrand.no Mon Dec 3 02:55: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 4321921F86BE for ; Mon, 3 Dec 2012 02:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5RgqVcNpKFI for ; Mon, 3 Dec 2012 02:55:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CA5FB21F86B5 for ; Mon, 3 Dec 2012 02:55:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 521E239E04C; Mon, 3 Dec 2012 11:55:32 +0100 (CET) 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 tq-55bDSVQ0J; Mon, 3 Dec 2012 11:55:28 +0100 (CET) Received: from [158.38.97.117] (unknown [158.38.97.117]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AE74939E0FD; Mon, 3 Dec 2012 11:55:28 +0100 (CET) Message-ID: <50BC84AC.4040201@alvestrand.no> Date: Mon, 03 Dec 2012 11:53:32 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------080609090808090403020406" Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 10:55:37 -0000 This is a multi-part message in MIME format. --------------080609090808090403020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/03/2012 11:23 AM, Christer Holmberg wrote: > > Hi, > > A question for clarification: > > When talking about the "F" class, what do you mean by "stream"? Do you > mean individual sources associated with the m- line? Or, do you mean > all sources associated with the m- line? > > I ASSUME you mean all sources associated with the m- line, because > otherwise you will need the a=ssrc attribute. > The purpose of the exercise is to figure out what attributes we need to redefine if we define the M-line to be an RTP session (the MMT and the all-videos-under-one-M-line approach) as opposed to what attributes we need to redefine if we define the M-line to be a group of sources that, in turn, may be associated with an RTP session (the BUNDLE approach). F-lines need redefinition under the first approach, T-lines need redefinition (or adjustment) under the second, M-lines may be able to work in both cases. > Regards, > > Christer > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *Harald Alvestrand > *Sent:* 28. marraskuuta 2012 16:51 > *To:* mmusic > *Subject:* [MMUSIC] M-lines: Wikifying it > > Perhaps we can do some real work rather than just disagreeing on > principles. > > Perhaps the most contentious issue now is "what should an M-line be". > As far as I can tell, M-lines and their parameters describe 3 things: > > - Properties of the transport flow / RTP session (Transport, or T for > short) > - Properties that make sense to apply to an individual media stream, > and may need to be different for different media streams in the same > combined RTP session (Flow, or F for short) > - Properties that make sense to apply to all streams of a given type > (Media, or M for short) > > The properties that can be represented in M-lines are found in two > IANA registries, both on > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: > > - att-field (both session and media level) > - att-field (media level only) > > I make it 179 entries in these categories, combined. > > I see the same kind of work being necessary no matter which way we go: > > - If we go with M-lines describing a whole RTP session (the MMT > proposal), each property of the "F" class that we stil need needs to > be copied onto a property in the "att-field (source level)" registry. > > - If we go with M-lines describing groups of media streams, > degenerating to a single media stream in the case of using > "a=inactive" for stream muting (the BUNDLE and TOGETHER proposals), > each property of the "T" class needs to be described as "MUST have > consistent values for all the combined M-lines", "MUST be taken only > from the first M-line in the bundle argument", or "must get special > treatment". > > - In both cases, the "M"-class lines don't need any special treatment. > They just need to be present in all the M-lines where they're relevant. > > I've created a spreadsheet here: > > https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE > > with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for > "necessary" and 0 for "will never matter"). > > Anyone should be able to write it. > If a few of us do a quick job of markup on it, I think we should be > able to have a more realistic assessment in a few days. > > I've started, but much of this is unknown to me. Can others help? > > Harald > > > > --------------080609090808090403020406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/03/2012 11:23 AM, Christer Holmberg wrote:

Hi,

 

A question for clarification:

 

When talking about the “F” class, what do you mean by “stream”? Do you mean individual sources associated with the m- line? Or, do you mean all sources associated with the m- line?

 

I ASSUME you mean all sources associated with the m- line, because otherwise you will need the a=ssrc attribute.


The purpose of the exercise is to figure out what attributes we need to redefine if we define the M-line to be an RTP session (the MMT and the all-videos-under-one-M-line approach) as opposed to what attributes we need to redefine if we define the M-line to be a group of sources that, in turn, may be associated with an RTP session (the BUNDLE approach).

F-lines need redefinition under the first approach, T-lines need redefinition (or adjustment) under the second, M-lines may be able to work in both cases.

 

Regards,

 

Christer

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 28. marraskuuta 2012 16:51
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

 

Perhaps we can do some real work rather than just disagreeing on principles.

Perhaps the most contentious issue now is "what should an M-line be".
As far as I can tell, M-lines and their parameters describe 3 things:

- Properties of the transport flow / RTP session (Transport, or T for short)
- Properties that make sense to apply to an individual media stream, and may need to be different for different media streams in the same combined RTP session (Flow, or F for short)
- Properties that make sense to apply to all streams of a given type (Media, or M for short)

The properties that can be represented in M-lines are found in two IANA registries, both on
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:

- att-field (both session and media level)
- att-field (media level only)

I make it 179 entries in these categories, combined.

I see the same kind of work being necessary no matter which way we go:

- If we go with M-lines describing a whole RTP session (the MMT proposal), each property of the "F" class that we stil need needs to be copied onto a property in the "att-field (source level)" registry.

- If we go with M-lines describing groups of media streams, degenerating to a single media stream in the case of using "a=inactive" for stream muting (the BUNDLE and TOGETHER proposals), each property of the "T" class needs to be described as "MUST have consistent values for all the combined M-lines", "MUST be taken only from the first M-line in the bundle argument", or "must get special treatment".

- In both cases, the "M"-class lines don't need any special treatment. They just need to be present in all the M-lines where they're relevant.

I've created a spreadsheet here:

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for "necessary" and 0 for "will never matter").

Anyone should be able to write it.
If a few of us do a quick job of markup on it, I think we should be able to have a more realistic assessment in a few days.

I've started, but much of this is unknown to me. Can others help?

                      Harald





--------------080609090808090403020406-- From christer.holmberg@ericsson.com Mon Dec 3 03:06: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 C2FC721F841E for ; Mon, 3 Dec 2012 03:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJBD+sZ50IgU for ; Mon, 3 Dec 2012 03:06:03 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBCE21F86D2 for ; Mon, 3 Dec 2012 03:05:56 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-a5-50bc879375b3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FE.3A.06323.3978CB05; Mon, 3 Dec 2012 12:05:56 +0100 (CET) Received: from ESESSHC002.ericsson.se (153.88.183.24) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 12:05:49 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 12:05:49 +0100 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA///5IgCAABQFMA== Date: Mon, 3 Dec 2012 11:05:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> In-Reply-To: <50BC84AC.4040201@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B04D2C6ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvje6U9j0BBgdXMVoc6+tis5i6/DGL A5PHlQlXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJXx9/tGpoKZZRV/74c1MG5L62Lk5JAQMJHY /+wOG4QtJnHh3nogm4tDSOAko8TlKdNZIJwdjBK9jx5AZRYzSvyc8YKpi5GDg03AQqL7nzZI t4iAjsTD/Q1MIDazgIzEjLONYLawgLbEg7X/WGBqzq/oYYawnSRWv/7CAjKGRUBFYtV6sBJe AW+JtRNuskOsmsgo8XLTFLA5nAK6EjMW3gCzGYEu/X5qDdQucYlbT+YzQXwgILFkz3lmCFtU 4uXjf6wQtqLEzrPtzBD1+RITlrcyQywTlDg58wnYYiGgO1sWT2CfwCg+C8nYWUhaZiFpgYjr SCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsY2XMTM3PSy803MQJj8OCW3wY7GDfdFzvEKM3B oiTOq6e6319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY9jf3Xvra39ESCxa7v3Z4H/QQ6ar 6aIbBV9sfshy5MZeBtWoE//S9oQaGR5JT9C5msuy4nqeN6/Vqkkdoj9+K+3u/dLOeWWVWlnx 9gez7eamnDv68srtAtemsmMX8+VT5+4+L1V3u1D4Wc7q2jB9gV+arUocPxa8evaU2WdPiJtN c+mN9PQdSUosxRmJhlrMRcWJAE3VNCSPAgAA Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 11:06:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B04D2C6ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, So, the exercise is NOT about how to apply attributes to individual sources= ? Regards, Christer From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 3. joulukuuta 2012 12:54 To: Christer Holmberg Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it On 12/03/2012 11:23 AM, Christer Holmberg wrote: Hi, A question for clarification: When talking about the "F" class, what do you mean by "stream"? Do you mean= individual sources associated with the m- line? Or, do you mean all source= s associated with the m- line? I ASSUME you mean all sources associated with the m- line, because otherwis= e you will need the a=3Dssrc attribute. The purpose of the exercise is to figure out what attributes we need to red= efine if we define the M-line to be an RTP session (the MMT and the all-vid= eos-under-one-M-line approach) as opposed to what attributes we need to red= efine if we define the M-line to be a group of sources that, in turn, may b= e associated with an RTP session (the BUNDLE approach). F-lines need redefinition under the first approach, T-lines need redefiniti= on (or adjustment) under the second, M-lines may be able to work in both ca= ses. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 28. marraskuuta 2012 16:51 To: mmusic Subject: [MMUSIC] M-lines: Wikifying it Perhaps we can do some real work rather than just disagreeing on principles= . Perhaps the most contentious issue now is "what should an M-line be". As far as I can tell, M-lines and their parameters describe 3 things: - Properties of the transport flow / RTP session (Transport, or T for short= ) - Properties that make sense to apply to an individual media stream, and ma= y need to be different for different media streams in the same combined RTP= session (Flow, or F for short) - Properties that make sense to apply to all streams of a given type (Media= , or M for short) The properties that can be represented in M-lines are found in two IANA reg= istries, both on http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: - att-field (both session and media level) - att-field (media level only) I make it 179 entries in these categories, combined. I see the same kind of work being necessary no matter which way we go: - If we go with M-lines describing a whole RTP session (the MMT proposal), = each property of the "F" class that we stil need needs to be copied onto a = property in the "att-field (source level)" registry. - If we go with M-lines describing groups of media streams, degenerating to= a single media stream in the case of using "a=3Dinactive" for stream mutin= g (the BUNDLE and TOGETHER proposals), each property of the "T" class needs= to be described as "MUST have consistent values for all the combined M-lin= es", "MUST be taken only from the first M-line in the bundle argument", or = "must get special treatment". - In both cases, the "M"-class lines don't need any special treatment. They= just need to be present in all the M-lines where they're relevant. I've created a spreadsheet here: https://docs.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVG= NV9lUFI3cHlIRFE with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for "necessar= y" and 0 for "will never matter"). Anyone should be able to write it. If a few of us do a quick job of markup on it, I think we should be able to= have a more realistic assessment in a few days. I've started, but much of this is unknown to me. Can others help? Harald --_000_7594FB04B1934943A5C02806D1A2204B04D2C6ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

So, the exercise is NOT a= bout how to apply attributes to individual sources?

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: 3. joulukuuta 2012 12:54
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] M-lines: Wikifying it

 

On 12/03/2012 11:23 AM, Christer Holmberg wrote:

Hi,

 <= /p>

A question for clarificat= ion:

 <= /p>

When talking about the &#= 8220;F” class, what do you mean by “stream”? Do you mean = individual sources associated with the m- line? Or, do you mean all sources= associated with the m- line?

 <= /p>

I ASSUME you mean all sou= rces associated with the m- line, because otherwise you will need the a=3Ds= src attribute.


The purpose of the exercise is to figure out what attributes we need to red= efine if we define the M-line to be an RTP session (the MMT and the all-vid= eos-under-one-M-line approach) as opposed to what attributes we need to red= efine if we define the M-line to be a group of sources that, in turn, may be associated with an RTP session= (the BUNDLE approach).

F-lines need redefinition under the first approach, T-lines need redefiniti= on (or adjustment) under the second, M-lines may be able to work in both ca= ses.


 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 28. marraskuuta 2012 16:51
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

 

Perhaps we can do som= e real work rather than just disagreeing on principles.

Perhaps the most contentious issue now is "what should an M-line be&qu= ot;.
As far as I can tell, M-lines and their parameters describe 3 things:

- Properties of the transport flow / RTP session (Transport, or T for short= )
- Properties that make sense to apply to an individual media stream, and ma= y need to be different for different media streams in the same combined RTP= session (Flow, or F for short)
- Properties that make sense to apply to all streams of a given type (Media= , or M for short)

The properties that can be represented in M-lines are found in two IANA reg= istries, both on
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:
- att-field (both session and media level)
- att-field (media level only)

I make it 179 entries in these categories, combined.

I see the same kind of work being necessary no matter which way we go:

- If we go with M-lines describing a whole RTP session (the MMT proposal), = each property of the "F" class that we stil need needs to be copi= ed onto a property in the "att-field (source level)" registry.
- If we go with M-lines describing groups of media streams, degenerating to= a single media stream in the case of using "a=3Dinactive" for st= ream muting (the BUNDLE and TOGETHER proposals), each property of the "= ;T" class needs to be described as "MUST have consistent values for all the combined M-lines", "MUST be taken only from t= he first M-line in the bundle argument", or "must get special tre= atment".

- In both cases, the "M"-class lines don't need any special treat= ment. They just need to be present in all the M-lines where they're relevan= t.

I've created a spreadsheet here:

https://docs.google.com/spreadsheet/ccc?key=3D0= Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

with 2 extra columns: "Class" (M, F or T) and "Importance&qu= ot; (1 for "necessary" and 0 for "will never matter").<= br>
Anyone should be able to write it.
If a few of us do a quick job of markup on it, I think we should be able to= have a more realistic assessment in a few days.

I've started, but much of this is unknown to me. Can others help?

            &nb= sp;         Harald





 

--_000_7594FB04B1934943A5C02806D1A2204B04D2C6ESESSMB209ericsso_-- From harald@alvestrand.no Mon Dec 3 03:06:55 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 2D70221F8593 for ; Mon, 3 Dec 2012 03:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.649 X-Spam-Level: X-Spam-Status: No, score=-109.649 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgT7gAkjTv6J for ; Mon, 3 Dec 2012 03:06:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEA121F841E for ; Mon, 3 Dec 2012 03:06:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4585739E1FC for ; Mon, 3 Dec 2012 12:06:51 +0100 (CET) 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 YZYPV8Xs13Ww for ; Mon, 3 Dec 2012 12:06:49 +0100 (CET) Received: from [158.38.97.117] (unknown [158.38.97.117]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 4759139E04C for ; Mon, 3 Dec 2012 12:06:46 +0100 (CET) Message-ID: <50BC87C6.9030600@alvestrand.no> Date: Mon, 03 Dec 2012 12:06:46 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50B624CC.4010501@alvestrand.no> <50B6704F.2000108@alum.mit.edu> <50BA1B90.2010905@alvestrand.no> <50BA6065.3090000@alum.mit.edu> In-Reply-To: <50BA6065.3090000@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 11:06:55 -0000 On 12/01/2012 08:54 PM, Paul Kyzivat wrote: > inline > > On 12/1/12 10:00 AM, Harald Alvestrand wrote: >> On 11/28/2012 09:13 PM, Paul Kyzivat wrote: >>> Inline >>> >>> On 11/28/12 9:50 AM, Harald Alvestrand wrote: >>>> Perhaps we can do some real work rather than just disagreeing on >>>> principles. >>>> >>>> Perhaps the most contentious issue now is "what should an M-line be". >>>> As far as I can tell, M-lines and their parameters describe 3 things: >>>> >>>> - Properties of the transport flow / RTP session (Transport, or T for >>>> short) >>>> - Properties that make sense to apply to an individual media >>>> stream, and >>>> may need to be different for different media streams in the same >>>> combined RTP session (Flow, or F for short) >>>> - Properties that make sense to apply to all streams of a given type >>>> (Media, or M for short) >>>> >>>> The properties that can be represented in M-lines are found in two >>>> IANA >>>> registries, both on >>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: >>>> >>>> - att-field (both session and media level) >>>> - att-field (media level only) >>>> >>>> I make it 179 entries in these categories, combined. >>>> >>>> I see the same kind of work being necessary no matter which way we go: >>>> >>>> - If we go with M-lines describing a whole RTP session (the MMT >>>> proposal), each property of the "F" class that we stil need needs >>>> to be >>>> copied onto a property in the "att-field (source level)" registry. >>>> >>>> - If we go with M-lines describing groups of media streams, >>>> degenerating >>>> to a single media stream in the case of using "a=inactive" for stream >>>> muting (the BUNDLE and TOGETHER proposals), each property of the "T" >>>> class needs to be described as "MUST have consistent values for all >>>> the >>>> combined M-lines", "MUST be taken only from the first M-line in the >>>> bundle argument", or "must get special treatment". >>>> >>>> - In both cases, the "M"-class lines don't need any special treatment. >>>> They just need to be present in all the M-lines where they're >>>> relevant. >>>> >>>> I've created a spreadsheet here: >>>> >>>> https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE >>>> >>>> >>>> >>>> with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for >>>> "necessary" and 0 for "will never matter"). >>>> >>>> Anyone should be able to write it. >>>> If a few of us do a quick job of markup on it, I think we should be >>>> able >>>> to have a more realistic assessment in a few days. >>>> >>>> I've started, but much of this is unknown to me. Can others help? >>> >>> Don't forget the media formats listed in the m-line itself. The >>> meaning of these depends on the param. The focus of this >>> discussion is on those values that correspond to various >>> flavors of RTP. There are a bunch of values that don't >>> correspond to RTP, and that assign different meanings to the format >>> parameters. >> I'm happy to ignore anything but RTP. BUNDLE isn't defined for anything >> else (while, in the parallel discussion, we may get DTLS/SCTP within its >> scope too, the RTP parameter set is our current problem). > > Hmm. OK, I went looking for something that says that. Section 7.1 does > say that, though I can find no text that talks about which m-line > values may be bundled together. Section 7.2 of draft-ietf-mmusic-sdp-bundle says that: o - The "proto" value in each "m=" line MUST be identical (e.g. RTP/AVPF). > >>> AFAIK, of the currently defined proto values only the RTP-related ones >>> have the notion of multiple flows within the session. But the sdp >>> extensions for SCTP media are currently being defined. That certainly >>> has the potential to be considered as multiple flows, and should be >>> considered in this discussion. >>> >>> For RTP transports, the formats are payload type numbers, and these >>> are mapped to actual formats (codecs) via a=rtpmap. I see that you >>> have proposed that rtpmap be per-media, not transport or flow. I guess >>> this means that the same payload type number could mean one thing for >>> all audio flows over the transport, and something different for all >>> video flows over the same transport. >> Absolutely not; that would violate both common sense and the BUNDLE >> draft as specified. The BUNDLE drafts explicitly say that a payload type >> number can only be used for one thing. >>> But the payload numbers to be used (specified on the m-line) is >>> negotiated in O/A. How would that work for audio vs. video? ISTM it >>> would be preferred to negotiate payload numbers and types >>> independently per flow. >> See above. They can't collide. >>> >>> Regarding the "importance" column in the table: I don't understand how >>> you have assigned values. In what frame of reference is importance to >>> be assessed? >> My completely subjective opinion, for RTCWEB. If others disagree, please >> change and add a comment. If we all agree, it becomes consensus. > > Frankly I don't even know what most of the parameters in the list are. > But I assume that most of them were at one time important to somebody > - at least those who defined it. Perhaps some are now obsolete, but > most likely not all of them. > > It isn't helpful if we all agree on what is important and what is not > if we don't agree on the criterion for importance. > > A couple of meanings that could be useful here: > > - those that might be used in an rtcweb context vs. those that nobody > thinks make any sense to use with rtcweb > > - those that make sense to use in a bundle/mmt vs. those that may only > be used outside a bundle/mmt. > > I guess I would prefer the latter. It has the benefit that those > nobody understands can be put in the unimportant category, and they > won't be broken by bundle/mmt. I changed the column title to "Importance to RTCWEB". Feel free to add new columns if you feel they are useful. > >>> Regarding a=label: This could be any of T/F/M, depending on >>> application use. I think we must assume T, and consider an alternative >>> for F. (And for M if we think it is needed.) > > I may have misunderstood your intended meaning for M. I assume you > meant all RTP streams of the same media type (audio or video) within a > single 5-tuple. I was thinking "same payload type", since the payload type is the distinguisher used for groups of flows that should have the same parameters in many cases. > >> The claim that a=label can be used to mark flows makes it F. > > a=label is a media-level attribute, so it is bound to an m-line. > > In the absence of bundle, regardless of whether the corresponding RTP > session has one or several flows. The m-line has a particular media > type, so I guess it could be viewed as either T or M. The reason why we're having the discussion is that we have two competing definitons of what an M-line should be, and need to choose one. So arguing from whether or not something associates with an M-line is not useful. > > Some applications of a=label may assume or require that the labeled > m-line contain only one RTP stream. If so, then perhaps the label > could be considered to be F. But we can't really know that. What applications of a=label do you know about? > >> If the >> people making that claim are willing to let go of the claim, we can >> change it to T. But at the moment its proponents are clearly calling >> for F. > > Is your point that you know of cases where there is a desire to label > an individual RTP-stream, and you would like to have a way to do that > when RTP-streams are multiplexed in an RTP session? Yes, that's how I've interpreted statements made (mostly from Cullen) about a=label. > > I'm ok with that. > >>> (I'm not convinced we need to identify an "M" scope distinct from T >>> and F.) >> Please consider the ones marked as such and tell me the argument for why >> it's obviously one or the other. >> >> In particular, a=rtpmap: is clearly not T, but when we have >> multiple flows on an RTP session utilizing the same codec, I'd hate to >> be forced to create multiple identical payload types just because it was >> classified as an F field. > > a=rtpmap is the *only* one currently marked M. And ISTM that it > clearly is a T. The a=imageattr attribute is also indexed by payload type. I just haven't gotten to it yet. > > I say this because, as you have said elsewhere, each payload type > number is tied to a particular codec of a particular codec, whether > audio or video. It isn't possible to have payload type number 100 mean > one thing for audio and a different thing for video. > > OTOH, when multiplexing audio and video on the same 5-tuple it is > necessary to know whether a particular a=rtpmap is intended to be > audio or video. Normally it inherits that from the m-line it belongs > to. That still works for bundle. It doesn't work for mmt. > > So, I still think there is no need for M. But a=rtpmap is "special" in > that it requires an extra datum. Unless there are other attributes > that have the same issue I think this is just a special case. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From harald@alvestrand.no Mon Dec 3 03:13:49 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 C4DCF21F85D7 for ; Mon, 3 Dec 2012 03:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDWkCVjmQNkl for ; Mon, 3 Dec 2012 03:13:49 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D327021F8596 for ; Mon, 3 Dec 2012 03:13:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6FED39E1FC; Mon, 3 Dec 2012 12:13:47 +0100 (CET) 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 KPZc9P7820aV; Mon, 3 Dec 2012 12:13:46 +0100 (CET) Received: from [158.38.97.117] (unknown [158.38.97.117]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A16DF39E04C; Mon, 3 Dec 2012 12:13:45 +0100 (CET) Message-ID: <50BC8969.6010101@alvestrand.no> Date: Mon, 03 Dec 2012 12:13:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Markus.Isomaki@nokia.com References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org, christer.holmberg@ericsson.com Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 11:13:49 -0000 On 12/03/2012 10:02 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > I agree that it would be useful to be able to run data channel on the same 5-tuple as RTP/RTCP, and even making it the default and must-implement way for the browsers. > > QoS/prioritization comes to mind as the only potential drawback. The endpoint can naturally still give different priorities to the different components (audio, video, "data") it is sending. I assume SCTP also has TCP-style receiver window that can be used to throttle reception if needed. And presumably RMCAT will find solutions to congestion control in genenral. But from the network perspective there is only one flow, and the only(?) way to differentiate the components is to use DSCP. I don't think our QoS (or API) draft yet clearly explains how DSCP's are learned and set, or whether that is even going to be a realistic solution. That is indeed the only reason I can think of to specify multiple m-lines for DTLS/SCTP (and we don't need to bundle them together). At the moment, the MMUSIC API doesn't define a way to control which m-line a DTLS assocation gets mapped onto. This may be more complexity than is really needed, though. > > Markus > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of ext Harald Alvestrand >> Sent: 03 December, 2012 10:11 >> To: Christer Holmberg >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >> >> On 12/03/2012 09:00 AM, Christer Holmberg wrote: >>> Hi, >>> >>> I guess it would be nice to hear from the browser/endpoint people whether >> they see a need for covering non-RTP in BUNDLE. >>> If NOT, it would mean a minimum of two 5-tuples, instead of one (one for >> the bundled RTP media, and one for the data channel). >> >> Speaking with my browser implementor hat on, I want to avoid adding an >> extra 5-tuple for data channels. >> >> Our stats on improvement from the introduction of rtcp-mux were pretty >> compelling that the issue is real. >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> -----Original Message----- >>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf Of Harald Alvestrand >>> Sent: 3. joulukuuta 2012 9:54 >>> To: mmusic@ietf.org >>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >>> >>> On 12/01/2012 07:09 PM, Paul Kyzivat wrote: >>>> I must say that I am getting confused about what is being multiplexed >>>> here. We must be very careful to be precise. >>>> >>>> SCTP defines an *association*, which in simple cases is bound to a >>>> 5-tuple. (For now lets not talk about the cases where each end can >>>> have more than one address.) >>>> >>>> SCTP multiplexes multiple one-way *streams* over an association. >>>> (These are not RTP streams.) >>>> >>>> RTCWEB binds pairs of sctp-streams together into *channels*. >>> I'm not talking about any of these levels. I'm talking about the reuse of the >> RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in RFC 5764 >> section 5.1.2. >>> I said the same thing earlier on this thread (Nov 5), when you first >>> responded (thanks for being the first responder!) >>> >>> You do make the point that the term "multiplex" is so over-used, it should >> probably be abandoned altogether - but that section talks about >> (de)multiplexing, so changing terminology is probably too late for that >> particular usage. >>> Harald >>> >>> _______________________________________________ >>> 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 Mon Dec 3 03:14: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 DF8C621F8596 for ; Mon, 3 Dec 2012 03:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.148 X-Spam-Level: X-Spam-Status: No, score=-110.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAo0H-X0BA0n for ; Mon, 3 Dec 2012 03:14:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4395A21F86BE for ; Mon, 3 Dec 2012 03:14:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26BDC39E1FC; Mon, 3 Dec 2012 12:14:42 +0100 (CET) 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 p13O93Gf4rSA; Mon, 3 Dec 2012 12:14:40 +0100 (CET) Received: from [158.38.97.117] (unknown [158.38.97.117]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 170A539E04C; Mon, 3 Dec 2012 12:14:40 +0100 (CET) Message-ID: <50BC89A0.1030104@alvestrand.no> Date: Mon, 03 Dec 2012 12:14:40 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------030806030205050208080509" Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 11:14:47 -0000 This is a multi-part message in MIME format. --------------030806030205050208080509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/03/2012 12:05 PM, Christer Holmberg wrote: > > Hi, > > So, the exercise is NOT about how to apply attributes to individual > sources? > Only in the sense that it is about figuring out which attributes need to be applied to individual sources. > Regards, > > Christer > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* 3. joulukuuta 2012 12:54 > *To:* Christer Holmberg > *Cc:* mmusic > *Subject:* Re: [MMUSIC] M-lines: Wikifying it > > On 12/03/2012 11:23 AM, Christer Holmberg wrote: > > Hi, > > A question for clarification: > > When talking about the "F" class, what do you mean by "stream"? Do > you mean individual sources associated with the m- line? Or, do > you mean all sources associated with the m- line? > > I ASSUME you mean all sources associated with the m- line, because > otherwise you will need the a=ssrc attribute. > > > The purpose of the exercise is to figure out what attributes we need > to redefine if we define the M-line to be an RTP session (the MMT and > the all-videos-under-one-M-line approach) as opposed to what > attributes we need to redefine if we define the M-line to be a group > of sources that, in turn, may be associated with an RTP session (the > BUNDLE approach). > > F-lines need redefinition under the first approach, T-lines need > redefinition (or adjustment) under the second, M-lines may be able to > work in both cases. > > > Regards, > > Christer > > *From:*mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Harald Alvestrand > *Sent:* 28. marraskuuta 2012 16:51 > *To:* mmusic > *Subject:* [MMUSIC] M-lines: Wikifying it > > Perhaps we can do some real work rather than just disagreeing on > principles. > > Perhaps the most contentious issue now is "what should an M-line be". > As far as I can tell, M-lines and their parameters describe 3 things: > > - Properties of the transport flow / RTP session (Transport, or T for > short) > - Properties that make sense to apply to an individual media stream, > and may need to be different for different media streams in the same > combined RTP session (Flow, or F for short) > - Properties that make sense to apply to all streams of a given type > (Media, or M for short) > > The properties that can be represented in M-lines are found in two > IANA registries, both on > http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: > > - att-field (both session and media level) > - att-field (media level only) > > I make it 179 entries in these categories, combined. > > I see the same kind of work being necessary no matter which way we go: > > - If we go with M-lines describing a whole RTP session (the MMT > proposal), each property of the "F" class that we stil need needs to > be copied onto a property in the "att-field (source level)" registry. > > - If we go with M-lines describing groups of media streams, > degenerating to a single media stream in the case of using > "a=inactive" for stream muting (the BUNDLE and TOGETHER proposals), > each property of the "T" class needs to be described as "MUST have > consistent values for all the combined M-lines", "MUST be taken only > from the first M-line in the bundle argument", or "must get special > treatment". > > - In both cases, the "M"-class lines don't need any special treatment. > They just need to be present in all the M-lines where they're relevant. > > I've created a spreadsheet here: > > https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE > > with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for > "necessary" and 0 for "will never matter"). > > Anyone should be able to write it. > If a few of us do a quick job of markup on it, I think we should be > able to have a more realistic assessment in a few days. > > I've started, but much of this is unknown to me. Can others help? > > Harald > > > > > --------------030806030205050208080509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/03/2012 12:05 PM, Christer Holmberg wrote:

Hi,

 

So, the exercise is NOT about how to apply attributes to individual sources?


Only in the sense that it is about figuring out which attributes need to be applied to individual sources.

 

Regards,

 

Christer

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: 3. joulukuuta 2012 12:54
To: Christer Holmberg
Cc: mmusic
Subject: Re: [MMUSIC] M-lines: Wikifying it

 

On 12/03/2012 11:23 AM, Christer Holmberg wrote:

Hi,

 

A question for clarification:

 

When talking about the “F” class, what do you mean by “stream”? Do you mean individual sources associated with the m- line? Or, do you mean all sources associated with the m- line?

 

I ASSUME you mean all sources associated with the m- line, because otherwise you will need the a=ssrc attribute.


The purpose of the exercise is to figure out what attributes we need to redefine if we define the M-line to be an RTP session (the MMT and the all-videos-under-one-M-line approach) as opposed to what attributes we need to redefine if we define the M-line to be a group of sources that, in turn, may be associated with an RTP session (the BUNDLE approach).

F-lines need redefinition under the first approach, T-lines need redefinition (or adjustment) under the second, M-lines may be able to work in both cases.


 

Regards,

 

Christer

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 28. marraskuuta 2012 16:51
To: mmusic
Subject: [MMUSIC] M-lines: Wikifying it

 

Perhaps we can do some real work rather than just disagreeing on principles.

Perhaps the most contentious issue now is "what should an M-line be".
As far as I can tell, M-lines and their parameters describe 3 things:

- Properties of the transport flow / RTP session (Transport, or T for short)
- Properties that make sense to apply to an individual media stream, and may need to be different for different media streams in the same combined RTP session (Flow, or F for short)
- Properties that make sense to apply to all streams of a given type (Media, or M for short)

The properties that can be represented in M-lines are found in two IANA registries, both on
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml:

- att-field (both session and media level)
- att-field (media level only)

I make it 179 entries in these categories, combined.

I see the same kind of work being necessary no matter which way we go:

- If we go with M-lines describing a whole RTP session (the MMT proposal), each property of the "F" class that we stil need needs to be copied onto a property in the "att-field (source level)" registry.

- If we go with M-lines describing groups of media streams, degenerating to a single media stream in the case of using "a=inactive" for stream muting (the BUNDLE and TOGETHER proposals), each property of the "T" class needs to be described as "MUST have consistent values for all the combined M-lines", "MUST be taken only from the first M-line in the bundle argument", or "must get special treatment".

- In both cases, the "M"-class lines don't need any special treatment. They just need to be present in all the M-lines where they're relevant.

I've created a spreadsheet here:

https://docs.google.com/spreadsheet/ccc?key=0Av-aF69sk5C6dDhPblpRV2pkbXVGNV9lUFI3cHlIRFE

with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for "necessary" and 0 for "will never matter").

Anyone should be able to write it.
If a few of us do a quick job of markup on it, I think we should be able to have a more realistic assessment in a few days.

I've started, but much of this is unknown to me. Can others help?

                      Harald





 


--------------030806030205050208080509-- From christer.holmberg@ericsson.com Mon Dec 3 03:16: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 8E90D21F86A2 for ; Mon, 3 Dec 2012 03:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDjlEU0U-EMl for ; Mon, 3 Dec 2012 03:16:45 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6363A21F8639 for ; Mon, 3 Dec 2012 03:16:44 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-33-50bc8a1b89bc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7E.0D.06323.B1A8CB05; Mon, 3 Dec 2012 12:16:43 +0100 (CET) Received: from ESESSHC006.ericsson.se (153.88.183.36) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 12:16:43 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 12:16:42 +0100 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA///5IgCAABQFMP//8eMAgAAREeA= Date: Mon, 3 Dec 2012 11:16:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> In-Reply-To: <50BC89A0.1030104@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja50154Ag/+PFS2O9XWxWUxd/pjF gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY/u4kS8Fb+YrjP3gbGA9KdjFyckgImEhc /byADcIWk7hwbz2QzcUhJHCSUWLn2sesEM4ORokphxuYIZzFjBJ/Zl8FynBwsAlYSHT/0wbp FhHQkXi4v4EJxGYWkJGYcbYRzBYW0JZ4sPYfC0zN+RU9zBC2n8TBzTvAxrAIqEh0bJABMXkF vCUWz3KE2PSNUWLlm+9gYzgFdCVeLFvCDmIzAh36/dQaqFXiEreezGeCeEBAYsme88wQtqjE y8f/WCFsRYmdZ9uZIer1JG5MncIGYWtLLFv4GizOKyAocXLmE7AzhYDiLYsnsE9glJiFZMUs JO2zkLTPQtK+gJFlFSN7bmJmTnq5+SZGYEQd3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamBM9/Fdk9U3b1vnj+avB/L+v3q/0TBy1eEN1wIX7i88ysfr Vti315xFZEOunEh2+ryLtx79vlMZzXW5vc7f9Zd8Z0FH4u/ZE3+LeMju+dQpvLRHx3lNwuQF J3lk+zrnqe6akrNJfeWaRxFXeD5Je2byHLY31wt+wHle0DZSMf7yD8W8KabrUyYrsRRnJBpq MRcVJwIAj9FXanYCAAA= Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 11:16:45 -0000 Hi, =A0 >>So, the exercise is NOT about how to apply attributes to individual sourc= es? > >Only in the sense that it is about figuring out which attributes need to b= e applied to individual sources. Well, I believe that was my original question :) If you want to apply an attribute to an individual source, you must use the= ssrc attribute.=20 =A0 Regards, =A0 Christer=20 =A0 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: 3. joulukuuta 2012 12:54 To: Christer Holmberg Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it =A0 On 12/03/2012 11:23 AM, Christer Holmberg wrote: Hi, =A0 A question for clarification: =A0 When talking about the "F" class, what do you mean by "stream"? Do you mean= individual sources associated with the m- line? Or, do you mean all source= s associated with the m- line? =A0 I ASSUME you mean all sources associated with the m- line, because otherwis= e you will need the a=3Dssrc attribute. The purpose of the exercise is to figure out what attributes we need to red= efine if we define the M-line to be an RTP session (the MMT and the all-vid= eos-under-one-M-line approach) as opposed to what attributes we need to red= efine if we define the M-line to be a group of sources that, in turn, may b= e associated with an RTP session (the BUNDLE approach). F-lines need redefinition under the first approach, T-lines need redefiniti= on (or adjustment) under the second, M-lines may be able to work in both ca= ses. =A0 Regards, =A0 Christer =A0 From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 28. marraskuuta 2012 16:51 To: mmusic Subject: [MMUSIC] M-lines: Wikifying it =A0 Perhaps we can do some real work rather than just disagreeing on principles= . Perhaps the most contentious issue now is "what should an M-line be". As far as I can tell, M-lines and their parameters describe 3 things: - Properties of the transport flow / RTP session (Transport, or T for short= ) - Properties that make sense to apply to an individual media stream, and ma= y need to be different for different media streams in the same combined RTP= session (Flow, or F for short) - Properties that make sense to apply to all streams of a given type (Media= , or M for short) The properties that can be represented in M-lines are found in two IANA reg= istries, both on http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml: - att-field (both session and media level) - att-field (media level only) I make it 179 entries in these categories, combined. I see the same kind of work being necessary no matter which way we go: - If we go with M-lines describing a whole RTP session (the MMT proposal), = each property of the "F" class that we stil need needs to be copied onto a = property in the "att-field (source level)" registry. - If we go with M-lines describing groups of media streams, degenerating to= a single media stream in the case of using "a=3Dinactive" for stream mutin= g (the BUNDLE and TOGETHER proposals), each property of the "T" class needs= to be described as "MUST have consistent values for all the combined M-lin= es", "MUST be taken only from the first M-line in the bundle argument", or = "must get special treatment". - In both cases, the "M"-class lines don't need any special treatment. They= just need to be present in all the M-lines where they're relevant. I've created a spreadsheet here: https://docs.google.com/spreadsheet/ccc?key=3D0Av-aF69sk5C6dDhPblpRV2pkbXVG= NV9lUFI3cHlIRFE with 2 extra columns: "Class" (M, F or T) and "Importance" (1 for "necessar= y" and 0 for "will never matter"). Anyone should be able to write it. If a few of us do a quick job of markup on it, I think we should be able to= have a more realistic assessment in a few days. I've started, but much of this is unknown to me. Can others help? =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald =A0 From harald@alvestrand.no Mon Dec 3 07:48:57 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 7B66321F86F3 for ; Mon, 3 Dec 2012 07:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.432 X-Spam-Level: X-Spam-Status: No, score=-110.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us+GrRICtLuQ for ; Mon, 3 Dec 2012 07:48:56 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2C521F8441 for ; Mon, 3 Dec 2012 07:48:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3783139E130; Mon, 3 Dec 2012 16:48:55 +0100 (CET) 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 qQwLrhgJR1CD; Mon, 3 Dec 2012 16:48:54 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736] (unknown [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E636C39E04C; Mon, 3 Dec 2012 16:48:53 +0100 (CET) Message-ID: <50BCC9E5.60903@alvestrand.no> Date: Mon, 03 Dec 2012 16:48:53 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 15:48:57 -0000 On 12/03/2012 12:16 PM, Christer Holmberg wrote: > Hi, > >>> So, the exercise is NOT about how to apply attributes to individual sources? >> Only in the sense that it is about figuring out which attributes need to be applied to individual sources. > Well, I believe that was my original question :) > > If you want to apply an attribute to an individual source, you must use the ssrc attribute. If you are in the camp that believes that there should be more than one independent source per M-line. That camp seemed to me to be in the minority in Atlanta; it was absolutely not the consensus opinion. From christer.holmberg@ericsson.com Mon Dec 3 08:12: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 2599D21F86CE for ; Mon, 3 Dec 2012 08:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64UxRjOCK2pQ for ; Mon, 3 Dec 2012 08:12:36 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1370021F86C3 for ; Mon, 3 Dec 2012 08:12:35 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-f1-50bccf72d1b3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1E.BE.26143.27FCCB05; Mon, 3 Dec 2012 17:12:35 +0100 (CET) Received: from ESESSHC010.ericsson.se (153.88.183.48) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 17:12:34 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 17:12:34 +0100 From: Christer Holmberg To: Harald Alvestrand Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA///5IgCAABQFMP//8eMAgAAREeCAADuMgIAAFtQu Date: Mon, 3 Dec 2012 16:12:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se>, <50BCC9E5.60903@alvestrand.no> In-Reply-To: <50BCC9E5.60903@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvjW7x+T0BBotkLI71dbFZTF3+mMWB yePKhCusHkuW/GQKYIrisklJzcksSy3St0vgynje+p+xYBVbxfRrV5gaGD+zdDFyckgImEg0 nd3HCGGLSVy4t56ti5GLQ0jgJKPE+p1bWCCcHYwSZ048Y4JwFjNKHFq+DKiMg4NNwEKi+582 SLeIgI7Ew/0NTCA2s4CMxIyzjWC2sIC2xIO1/1hgas6v6GGGsKMkJm7dzQIyhkVAReJWhxZI mFfAW6L1+nZGiFXXmSS+P+liBUlwAs25+WMV2ExGoEu/n1oDtUtc4taT+UwQHwhILNlznhnC FpV4+fgfK4StKPHxFcSXzEA3LNj9iQ3C1pZYtvA1M8RiQYmTM5+A3SkEFG9ZPIF9AqPELCQr ZiFpn4WkfRaS9gWMLKsY2XMTM3PSy402MQJj6uCW36o7GO+cEznEKM3BoiTOa711j7+QQHpi SWp2ampBalF8UWlOavEhRiYOTqkGRr6rool8588mpR6LPCspVNAsryl8N2CeSaS1b356WXT9 9w2bp0nUznfQ0P/+N2XqUt4bSxey7mG+GZ+h5LfY4+nTZY4iJ7LMu6dUc77wPf3hhvefy9n/ Otbvtlo/xbjn/8nkbcIs6/tMHAyEBZzW5W432XKt1cqys6g+pHFGeIvCnp8dirJ2SizFGYmG WsxFxYkA7H3x/3cCAAA= Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 16:12:37 -0000 Hi, >>>> So, the exercise is NOT about how to apply attributes to individual so= urces? >>> Only in the sense that it is about figuring out which attributes need t= o be applied to individual sources. >> Well, I believe that was my original question :) >> >> If you want to apply an attribute to an individual source, you must use = the ssrc attribute. > > If you are in the camp that believes that there should be more than onein= dependent source per M-line. > > That camp seemed to me to be in the minority in Atlanta; it was absolutel= y not the consensus opinion. It's not about in which camp someone is, it's about the assumptions we make= in the wiki study. If the assumption is one source per m- line, than I thi= nk it should be explicitly stated. Regards, Christer From harald@alvestrand.no Mon Dec 3 08:38:28 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 2B63E21F8863 for ; Mon, 3 Dec 2012 08:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn2W6p1zuVaA for ; Mon, 3 Dec 2012 08:38:27 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 91DBD21F86F3 for ; Mon, 3 Dec 2012 08:38:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 31A5E39E130; Mon, 3 Dec 2012 17:38:25 +0100 (CET) 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 ByA9nhzzQAOm; Mon, 3 Dec 2012 17:38:24 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736] (unknown [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 2CE9239E04C; Mon, 3 Dec 2012 17:38:24 +0100 (CET) Message-ID: <50BCD57E.4040505@alvestrand.no> Date: Mon, 03 Dec 2012 17:38:22 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se>, <50BCC9E5.60903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 16:38:28 -0000 On 12/03/2012 05:12 PM, Christer Holmberg wrote: > Hi, > >>>>> So, the exercise is NOT about how to apply attributes to individual sources? >>>> Only in the sense that it is about figuring out which attributes need to be applied to individual sources. >>> Well, I believe that was my original question :) >>> >>> If you want to apply an attribute to an individual source, you must use the ssrc attribute. >> If you are in the camp that believes that there should be more than oneindependent source per M-line. >> >> That camp seemed to me to be in the minority in Atlanta; it was absolutely not the consensus opinion. > It's not about in which camp someone is, it's about the assumptions we make in the wiki study. If the assumption is one source per m- line, than I think it should be explicitly stated. Trying again, since I'm obviously not making myself clear: The two alternative approaches are: - Everything that needs to be controlled separately is in its own M-line. Everything that needs to go on the same RTP session uses BUNDLE to get there. Transport parameters get figured out somehow. - Everything that goes on the same RTP session goes on the same M-line. Due to backwards compatible SDP, we may choose to use BUNDLE to lump video and audio together - or we may choose MMT if that works for people. Anything that needs separate control uses a=ssrc. In Atlanta, the room was clearly split between the two. I'm trying to get real data on how many things need to be redefined for each case. > > Regards, > > Christer > > > From christer.holmberg@ericsson.com Mon Dec 3 08:45: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 5DD5321F85C8 for ; Mon, 3 Dec 2012 08:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORUl3HtG3j2M for ; Mon, 3 Dec 2012 08:44:59 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 047EC21F85A8 for ; Mon, 3 Dec 2012 08:44:53 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-b5-50bcd704cbd5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 63.77.06323.407DCB05; Mon, 3 Dec 2012 17:44:52 +0100 (CET) Received: from ESESSHC022.ericsson.se (153.88.183.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 17:44:52 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 17:44:52 +0100 From: Christer Holmberg To: 'Harald Alvestrand' Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA///5IgCAABQFMP//8eMAgAAREeCAADuMgIAAFtQu///3AAAAAjRjIA== Date: Mon, 3 Dec 2012 16:44:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04D715@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se>, <50BCC9E5.60903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> <50BCD57E.4040505@alvestrand.no> In-Reply-To: <50BCD57E.4040505@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvjS7L9T0BBovnmVgc6+tis5i6/DGL A5PHlQlXWD2WLPnJFMAUxWWTkpqTWZZapG+XwJUx7f0qxoLvPBWPnn1nbGDs4+pi5OSQEDCR eLbyKzuELSZx4d56ti5GLg4hgZOMEodPfmOFcHYwSnS9u88C4SxmlFi/ewNQCwcHm4CFRPc/ bZBuEQE9iQ/NixhBbGYBGYkZZxuZQGxhAW2JB2v/sUDU6EicX9HDDGFnSZz62QBmswioSDx6 eYgJZCSvgLfE0u9xEKv2MEtsPXgKbA6ngK7EtgX3wOYzAl36/dQaJohd4hK3nsxngvhAQGLJ nvPMELaoxMvH/1hBZkoIKEos75eDKNeRWLD7ExuErS2xbOFrsHJeAUGJkzOfgJ0pBBRvWTyB fQKjxCwkG2YhaZ+FpH0WkvYFjCyrGNlzEzNz0svNNzECY+rglt8GOxg33Rc7xCjNwaIkzqun ut9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+Myc5bV0leW972fuCEqeIE403qmFPfOFN1C dpV5/163bbpyvjLutGboZZVX8QzT2dYe2qOy4k/4B0GveVWC31bolrbfjZ7ixvp4QYvCwXdm G8L5+tReGyhbLbbvSZGyeGYtrH05dxKztt2klc+66xgXOC7iz7AQbpVc7jHl2Kvz0ans87wt viqxFGckGmoxFxUnAgBAJAR2dwIAAA== Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 16:45:00 -0000 Hi,=20 >>>>>> So, the exercise is NOT about how to apply attributes to individual = sources? >>>>> Only in the sense that it is about figuring out which attributes need= to be applied to individual sources. >>>> Well, I believe that was my original question :) >>>> >>>> If you want to apply an attribute to an individual source, you must us= e the ssrc attribute. >>> If you are in the camp that believes that there should be more than one= independent source per M-line. >>> >>> That camp seemed to me to be in the minority in Atlanta; it was absolut= ely not the consensus opinion. >> It's not about in which camp someone is, it's about the assumptions we m= ake in the wiki study. If the assumption is one source per m- line, than I = think it should be explicitly stated. >> Trying again, since I'm obviously not making myself clear: > > The two alternative approaches are: > > - Everything that needs to be controlled separately is in its own M-line.= Everything that needs to go on the same RTP session uses BUNDLE to get the= re. Transport parameters get figured out somehow. > > - Everything that goes on the same RTP session goes on the same M-line.=20 > Due to backwards compatible SDP, we may choose to use BUNDLE to lump vide= o and audio together - or we may choose MMT if that works for people. Anyth= ing that needs separate control uses a=3Dssrc. Exactly! So, which (if any) approach do you assume in the wiki? :) Regards, Christer > In Atlanta, the room was clearly split between the two. I'm trying to get= real data on how many things need to be redefined for each case. From harald@alvestrand.no Mon Dec 3 08:59:18 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 896B721F886C for ; Mon, 3 Dec 2012 08:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.135 X-Spam-Level: X-Spam-Status: No, score=-110.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxcig3M-LRiF for ; Mon, 3 Dec 2012 08:59:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 332FB21F84F5 for ; Mon, 3 Dec 2012 08:59:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4888939E130; Mon, 3 Dec 2012 17:59:13 +0100 (CET) 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 P7Arhfm3VuuV; Mon, 3 Dec 2012 17:59:12 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736] (unknown [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C138939E04C; Mon, 3 Dec 2012 17:59:11 +0100 (CET) Message-ID: <50BCDA5F.2050306@alvestrand.no> Date: Mon, 03 Dec 2012 17:59:11 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se>, <50BCC9E5.60903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> <50BCD57E.4040505@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D715@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D715@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 16:59:18 -0000 On 12/03/2012 05:44 PM, Christer Holmberg wrote: > Hi, > >>>>>>> So, the exercise is NOT about how to apply attributes to individual sources? >>>>>> Only in the sense that it is about figuring out which attributes need to be applied to individual sources. >>>>> Well, I believe that was my original question :) >>>>> >>>>> If you want to apply an attribute to an individual source, you must use the ssrc attribute. >>>> If you are in the camp that believes that there should be more than oneindependent source per M-line. >>>> >>>> That camp seemed to me to be in the minority in Atlanta; it was absolutely not the consensus opinion. >>> It's not about in which camp someone is, it's about the assumptions we make in the wiki study. If the assumption is one source per m- line, than I think it should be explicitly stated. >>> Trying again, since I'm obviously not making myself clear: >> The two alternative approaches are: >> >> - Everything that needs to be controlled separately is in its own M-line. Everything that needs to go on the same RTP session uses BUNDLE to get there. Transport parameters get figured out somehow. >> >> - Everything that goes on the same RTP session goes on the same M-line. >> Due to backwards compatible SDP, we may choose to use BUNDLE to lump video and audio together - or we may choose MMT if that works for people. Anything that needs separate control uses a=ssrc. > Exactly! > > So, which (if any) approach do you assume in the wiki? :) For the 5th time: I'm NOT assuming one or the other approach. I'm trying to gather information that people can use to decide which approach to follow. That REQUIRES that the wiki does NOT assume one approach. Do you hear me now? From christer.holmberg@ericsson.com Mon Dec 3 09:18:49 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 DD1B521F87EB for ; Mon, 3 Dec 2012 09:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JggA+9YdDlSn for ; Mon, 3 Dec 2012 09:18:49 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DADB721F87DB for ; Mon, 3 Dec 2012 09:18:48 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-3f-50bcdef716cd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AF.8A.06323.7FEDCB05; Mon, 3 Dec 2012 18:18:48 +0100 (CET) Received: from ESESSHC002.ericsson.se (153.88.183.24) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 18:18:47 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 18:18:47 +0100 From: Christer Holmberg To: 'Harald Alvestrand' Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA///5IgCAABQFMP//8eMAgAAREeCAADuMgIAAFtQu///3AAAAAjRjIP//9C2A///qe7A= Date: Mon, 3 Dec 2012 17:18:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04D862@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se>, <50BCC9E5.60903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> <50BCD57E.4040505@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D715@ESESSMB209.ericsson.se> <50BCDA5F.2050306@alvestrand.no> In-Reply-To: <50BCDA5F.2050306@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje6Pe3sCDLb8ZLY41tfFZjF1+WMW ByaPKxOusHosWfKTKYApissmJTUnsyy1SN8ugSvj7dV1bAVb+CvePVjE3sA4h6eLkZNDQsBE YuLWn+wQtpjEhXvr2boYuTiEBE4ySnzZdIsdwtnBKLF+1xXmLkYOIGcxo8RZcxCTTcBCovuf NkiviICexIfmRYwgNrOAjMSMs41MILawgLbEg7X/WCBqdCTOr+hhhrDLJNYf7GYFsVkEVCRO /+5jA7F5BbwlJv75zgKxdiGLxJtrZ8GKOAV0JU79XALWzAh06PdTa5gglolL3HoynwniAQGJ JXvOM0PYohIvH/9jBblTQkBRYnm/HES5jsSC3Z/YIGxtiWULXzND7BWUODnzCdidQkDxlsUT 2CcwSsxCsmEWkvZZSNpnIWlfwMiyipE9NzEzJ73cfBMjMKIObvltsINx032xQ4zSHCxK4rx6 qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAG6tytlPS8f+/GVYm6o7d38G3YW/Ul1XPD giecfnk/T8+5z/SfgdVF9pqL86Fwt7mW922uJvrbby2v6D1edIjxiFlQ/8QTXJZndsSm6HLr H1B/G5Un1HuA/6bnDOVr1lc/N/l0O9/cJvvA9cOD2qP7OFpTtgXeXjI5y2bCtz+L+laY75y6 crqLEktxRqKhFnNRcSIANygzLnYCAAA= Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 17:18:50 -0000 Hi,=20 >>>>>>>> So, the exercise is NOT about how to apply attributes to individua= l sources? >>>>>>> Only in the sense that it is about figuring out which attributes ne= ed to be applied to individual sources. >>>>>> Well, I believe that was my original question :) >>>>>> >>>>>> If you want to apply an attribute to an individual source, you must = use the ssrc attribute. >>>>> If you are in the camp that believes that there should be more than o= neindependent source per M-line. >>>>> >>>>> That camp seemed to me to be in the minority in Atlanta; it was absol= utely not the consensus opinion. >>>> It's not about in which camp someone is, it's about the assumptions we= make in the wiki study. If the assumption is one source per m- line, than = I think it should be explicitly stated. >>>> Trying again, since I'm obviously not making myself clear: >>> The two alternative approaches are: >>> >>> - Everything that needs to be controlled separately is in its own M-lin= e. Everything that needs to go on the same RTP session uses BUNDLE to get t= here. Transport parameters get figured out somehow. >>> >>> - Everything that goes on the same RTP session goes on the same M-line. >>> Due to backwards compatible SDP, we may choose to use BUNDLE to lump vi= deo and audio together - or we may choose MMT if that works for people. Any= thing that needs separate control uses a=3Dssrc. >> Exactly! >> >> So, which (if any) approach do you assume in the wiki? :) > For the 5th time: I'm NOT assuming one or the other approach. > I'm trying to gather information that people can use to decide which appr= oach to follow. > That REQUIRES that the wiki does NOT assume one approach. > > Do you hear me now? So, coming back to my original question: For "F", a *stream* refers to an i= ndividual source (and is not related to whether one m- line will or will no= t contain multiple sources). Correct? Regards, Christer From pkyzivat@alum.mit.edu Mon Dec 3 11:36: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 A2B9E21F8574 for ; Mon, 3 Dec 2012 11:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.359 X-Spam-Level: X-Spam-Status: No, score=-0.359 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blP0XxPvQhf2 for ; Mon, 3 Dec 2012 11:36:20 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 100FD21F849A for ; Mon, 3 Dec 2012 11:36:19 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id X7Cz1k0020bG4ec5A7cKzL; Mon, 03 Dec 2012 19:36:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id X7cJ1k00r3ZTu2S3P7cKC8; Mon, 03 Dec 2012 19:36:19 +0000 Message-ID: <50BCFF32.2030600@alum.mit.edu> Date: Mon, 03 Dec 2012 14:36:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> In-Reply-To: <50BC5A81.6050503@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354563379; bh=X43ELlTiP0TdZh0RDpKuhb/bN+uhTCWhY/B7CoJymG4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=W/JL8xM4TSvyaN2Uz6jzU0HeN2HjgSjhvd51i9OZLLtjGR+fL1fuBoqvg76e5EkTu 8NKoCNNoNKtsTIBuq6aSUchd62UUVTHbxPDHMULStlWq2fj4zFblipT5k+pBikaPfJ cfa1yRt+ydbQsg+P/qh+It9B0AtfrQ4wEHQQyFYN6h2ZO32+IVgHgN7UwuXmgFuPh6 gI0Fi75Uf7HrRNR9SStzAG/dPt9L83rkUY61oB3CoG2usEZQUBskNtJSRQ8ky10obD 5zwjFdazHkAWJS2+BmFqWVUqNidCEUeH5d2nhHHd0atp4jm1SADVzaiL+gkUjV019+ 1+XPD50LVgtBA== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 19:36:20 -0000 On 12/3/12 2:53 AM, Harald Alvestrand wrote: > On 12/01/2012 07:09 PM, Paul Kyzivat wrote: >> I must say that I am getting confused about what is being multiplexed >> here. We must be very careful to be precise. >> >> SCTP defines an *association*, which in simple cases is bound to a >> 5-tuple. (For now lets not talk about the cases where each end can >> have more than one address.) >> >> SCTP multiplexes multiple one-way *streams* over an association. >> (These are not RTP streams.) >> >> RTCWEB binds pairs of sctp-streams together into *channels*. > > I'm not talking about any of these levels. I'm talking about the reuse > of the RTP session's 5-tuple for the DTLS/SRTP 5-tuple, as described in > RFC 5764 section 5.1.2. These are all related. We are making even more of a mess of SDP than it already is by patching on a new hack for each sort of multiplexing somebody comes up with. But focusing on just this: How do you imagine this multiplexing will be signaled in SDP? The obvious way would be to bundle the DTLS/SCTP m-line with the RTP m-lines. But that will violate the rule that all the bundled m-lines have the same . (And there is an even worst fit between this and mmt.) Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 3 12:00: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 1812321F8917 for ; Mon, 3 Dec 2012 12:00:21 -0800 (PST) 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.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGJ6HjsAu7Bl for ; Mon, 3 Dec 2012 12:00:19 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBD21F8920 for ; Mon, 3 Dec 2012 12:00:19 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta04.westchester.pa.mail.comcast.net with comcast id X69v1k00B0bG4ec5480JTZ; Mon, 03 Dec 2012 20:00:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id X80J1k00v3ZTu2S3P80JDm; Mon, 03 Dec 2012 20:00:18 +0000 Message-ID: <50BD04D2.7090207@alum.mit.edu> Date: Mon, 03 Dec 2012 15:00:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> In-Reply-To: <50BA19F9.4040701@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354564818; bh=JRO1FKLm+3+cy1oZo1D3dpgqmO4ZgmTHz+acRGf4k10=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m5TJOjB2uwBuBhSNog30b30R7qVdx4c+pdwm5zjHfvnShhs/08CrcUgwSKR+0bdjG PR4GODY9ad0DtQdWVAg55IjyNFS4cPj1jhpsxib+i8vMSJR2UVEarUlWDMatr8w+NQ XXTRNuDZFYVW/cr4rSY7iF4DtcoFQ3K7Iwr4mkEUbx3j5IRsmrh7SAG3oqllrFja0O cWOAogJ3i35E4YikVcpbpE6vRsqjK8o01utddptw67xV2vAPEdHomebeJxMJjtXT7/ HALJlBnWPnpDx6RRU/mL7KOl00R0VHp9bTE4ZzPb/m26OS1zafgE1F63z/TwFfhPsG cN4DeHQOlGHyQ== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 20:00:21 -0000 Commenting on a different point On 12/1/12 9:53 AM, Harald Alvestrand wrote: > The interesting difference is that the multiplexing between DTLS/SCTP > traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried > in SSRCs, which means: > > - There can be only one DTLS/SCTP stream in a bundle (which may have > multiple associations, as you state below); you can't have multiple > lines with proto DTLS/SCTP in a bundle. I am not an SCTP expert. But IIUC, SCTP was designed to run directly over IP. It has its own notion of port used to demux multiple SCTP associations over the same IP address. I presume that that same mechanism is still there when SCTP is run over DTLS over UDP. So, the traffic coming over DTLS must first be demuxed into RTP traffic and SCTP traffic. Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic can be demuxed based on SCTP port. And once the traffic for a single SCTP port is identified, it can be demuxed based on stream number. Representing this in SDP is a challenge. Some variant of the bundle proposal might allow bundling together several RTP m-lines and some DTLS/SCTP m-lines. This would require a mechanism for specifying the SCTP port number - already an open issue (#3) in draft-ietf-mmusic-sctp-sdp-02. Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 3 12:13: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 6751021F885B for ; Mon, 3 Dec 2012 12:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMXP-umZwmv6 for ; Mon, 3 Dec 2012 12:13:52 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id AE38921F8775 for ; Mon, 3 Dec 2012 12:13:52 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta05.westchester.pa.mail.comcast.net with comcast id Wz9z1k0050cZkys558Dq1U; Mon, 03 Dec 2012 20:13:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id X8Dp1k01V3ZTu2S3W8DpSq; Mon, 03 Dec 2012 20:13:50 +0000 Message-ID: <50BD07FC.30809@alum.mit.edu> Date: Mon, 03 Dec 2012 15:13:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <50BC8969.6010101@alvestrand.no> In-Reply-To: <50BC8969.6010101@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354565630; bh=JwrP47Vz4x2dgQLt0GZZLDAuTYBxdyjLs2A9Xrurqqk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IMavRNyCW8I1mNt3KNgSBMiZ7lyWx7Nn2T/V2KNoq1S/Iyrdzb9fK2AUwXLwl/o2k esVR7g/QjFxY04ivAD9JVXGlo3jpek67VlN62y6WtoMU4G+Gz81j70hLqXNvwSjApG kK6iP6GNH3JDI1nsd4hylRVmJ4+BbJ2H5ig7iwkM89c6vlR0TdqqPnxhaUbRSGgda0 ub4/oRz9BdMOxqJGS1C7nq8MJAxGvLuOvsYw00XYwXWTMTm1Fv99tRCo+Kz6PP9IHS IW0BAsHxpGiR9r8jruDmcVqjXYnYY/OwVKbJ16aFIHzpUJg9uzQg6Y0eXnnSNF08X/ et9QvE3MFkh+w== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 20:13:53 -0000 On 12/3/12 6:13 AM, Harald Alvestrand wrote: > On 12/03/2012 10:02 AM, Markus.Isomaki@nokia.com wrote: >> Hi, >> >> I agree that it would be useful to be able to run data channel on the >> same 5-tuple as RTP/RTCP, and even making it the default and >> must-implement way for the browsers. >> >> QoS/prioritization comes to mind as the only potential drawback. The >> endpoint can naturally still give different priorities to the >> different components (audio, video, "data") it is sending. I assume >> SCTP also has TCP-style receiver window that can be used to throttle >> reception if needed. And presumably RMCAT will find solutions to >> congestion control in genenral. But from the network perspective there >> is only one flow, and the only(?) way to differentiate the components >> is to use DSCP. I don't think our QoS (or API) draft yet clearly >> explains how DSCP's are learned and set, or whether that is even going >> to be a realistic solution. > > That is indeed the only reason I can think of to specify multiple > m-lines for DTLS/SCTP (and we don't need to bundle them together). > > At the moment, the MMUSIC API doesn't define a way to control which > m-line a DTLS assocation gets mapped onto. MMUSIC *API*??? Do you mean the SDP signaling for this? (draft-ietf-mmusic-sctp-sdp-02) It specifies a new m-line format for this. Thanks, Paul From Markus.Isomaki@nokia.com Mon Dec 3 12:23: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 ED0AC21F87E7 for ; Mon, 3 Dec 2012 12:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YibrzJjIuWxy for ; Mon, 3 Dec 2012 12:23:40 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2F52921F86EE for ; Mon, 3 Dec 2012 12:23:39 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB3KNXad015832; Mon, 3 Dec 2012 22:23:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 22:23:32 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.131]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0318.003; Mon, 3 Dec 2012 20:23:32 +0000 From: To: , Thread-Topic: [MMUSIC] SCTP question: Where does it multiplex? Thread-Index: AQHNz7N6WgV/cieAmkiYZjuifDh2VZgEB+uAgAA2wgCAAniGgIAAAgkAgAACugCAAAro0IAAKD+AgACW5ACAAAGfgA== Date: Mon, 3 Dec 2012 20:23:32 +0000 Message-ID: References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <50BC8969.6010101@alvestrand.no> <50BD07FC.30809@alum.mit.edu> In-Reply-To: <50BD07FC.30809@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.167.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2012 20:23:32.0842 (UTC) FILETIME=[10A7F4A0:01CDD194] X-Nokia-AV: Clean Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 03 Dec 2012 20:23:41 -0000 Hi, Paul Kyzivat wrote: >On 12/3/12 6:13 AM, Harald Alvestrand wrote: >> On 12/03/2012 10:02 AM, Markus.Isomaki@nokia.com wrote: >>> Hi, >>>I don't think our QoS (or API) draft yet >>> clearly explains how DSCP's are learned and set, or whether that is >>> even going to be a realistic solution. >> >> That is indeed the only reason I can think of to specify multiple >> m-lines for DTLS/SCTP (and we don't need to bundle them together). >> >> At the moment, the MMUSIC API doesn't define a way to control which >> m-line a DTLS assocation gets mapped onto. > >MMUSIC *API*??? > >Do you mean the SDP signaling for this? (draft-ietf-mmusic-sctp-sdp-02) > >It specifies a new m-line format for this. > Sorry about starting the confusion. I thought this was on rtcweb mailing li= st and with API I was in my reply actually referring to the QoS/prioritizat= ion related APIs in W3C related to WebRTC. Don't know which API Harald is r= eferring to, though :-) Markus From pkyzivat@alum.mit.edu Mon Dec 3 12:29: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 AC88A21F881F for ; Mon, 3 Dec 2012 12:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_111=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaxOOx71cx2Z for ; Mon, 3 Dec 2012 12:29:31 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 077B321F87EE for ; Mon, 3 Dec 2012 12:29:30 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id Wylr1k00317dt5G558VW9a; Mon, 03 Dec 2012 20:29:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id X8VW1k0013ZTu2S3Z8VWt2; Mon, 03 Dec 2012 20:29:30 +0000 Message-ID: <50BD0BA8.3010901@alum.mit.edu> Date: Mon, 03 Dec 2012 15:29:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Salvatore Loreto (JO/LMF)" , Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354566570; bh=Z2NymZEjiuoSfVzwIXJ0IpN3IHfxJkz2e1HuoE+jBIc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pepxWk6oPKb+4rLkFs0im7LnBrFzsyfXYVEaPgb1pggblv3EvCZz0fTSY/FyNYE6T EGS+qnBFiXakHbXYnTeSr4T1w7+dIM0ainR0MCl5PiIlbTW09Xw12JDFJbviyjliYB 5Ce9F21NGSh85t0jaOpvRI+4BxDpDGcOeAAaXclBiCuKq/K8oTZHS8R4vzEa9iiU84 15dDdkZAJb/axlBoibro2rXZCUthHK2+Ev4ZOSwjG7ox6x3tWP2AheQ+A09Z+ABnx8 E4yrXcpIY28/VWHRuBNpujfyr25NHDxQ1W+bEVAj67INWGhLst+teIoE7uDSA4rE4+ ZUrGcAtm0AGeQ== Cc: IETF MMUSIC WG Subject: [MMUSIC] Some issues with draft-ietf-mmusic-sctp-sdp-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: Mon, 03 Dec 2012 20:29:32 -0000 While commenting on some related discussions I had occasion to look at this draft again and I found a few issues: First, some very specific ones:: Section 4.1 says: If the sub-field is 'SCTP' or ... This is a typo. s/port/proto/ But the major issue is that this draft doesn't explain the semantics of the field. The only things I can find that touch on this are: - section 10.1 refers to "SCTP port 54111" and then shows an m-line with: m=application 54111 SCTP 0 1 2 But this is just an example, not normative text. - section 4.1 says: [OPEN ISSUE 3] do we need also an attribute to specify the SCTP port number for the SCTP over DTLS scenario? that can be useful in the case where multiple association are running on top of the same DTLS session. This implies that the SCTP port number is *not* what is in the port field in this case. Presumably because the UDP port number is in that field. ISTM that there needs to be a clear discussion of all the required port numbers for each case, and how they are specified. When there is more than one (namely in the SCTP/DTLS and DTLS/SCTP cases), *one* of them can be in the m-line and the other one must be somewhere else. And if the one that is not in the m-line is optional, then I guess there must be a default. Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 3 13:37: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 B005E21F893A for ; Mon, 3 Dec 2012 13:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0hqdVSBltks for ; Mon, 3 Dec 2012 13:37:54 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id E64A621F85B8 for ; Mon, 3 Dec 2012 13:37:53 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id X0pQ1k0011ap0As599dtQe; Mon, 03 Dec 2012 21:37:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id X9dt1k00E3ZTu2S3i9dtYk; Mon, 03 Dec 2012 21:37:53 +0000 Message-ID: <50BD1BB0.90307@alum.mit.edu> Date: Mon, 03 Dec 2012 16:37:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50B624CC.4010501@alvestrand.no> <50B6704F.2000108@alum.mit.edu> <50BA1B90.2010905@alvestrand.no> <50BA6065.3090000@alum.mit.edu> <50BC87C6.9030600@alvestrand.no> In-Reply-To: <50BC87C6.9030600@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354570673; bh=aPN6hF0rEg/cpG9YDx1dwtzFs54yTLSlxKltv6S5Dt4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nHW/6hvEcyTIHDNamzn2XCTNq5kQtb9b7P2qcwBn/Zm/9fgVOIE2D+aWANMJRpmNA REGCS1gprkGNCpI6JA8Z9PlfdkeUvc1/BEZ4VJp0D2EEW9VPMIhgz0zzkfXspG+/t8 +PvqMiZfew1Eu3RIpDOZ7HWg5QNZGvOe49QmEPcJN2zlPpUn9alOMd8rd+G8/oCoBH fiXBH8j835NYfZ8+bPkhLoi22kqMxte7jshHN5LVmJnKzQ4+aKf7HIRClhRkCBm1lv e4RJmm3uBraqW36PiO1AO5sUfQYDL4O/WPNAOT9R92xxxNFnsSltVxOi/62OTe8KHn AurjefU8hFKog== Subject: Re: [MMUSIC] M-lines: Wikifying it - a=label 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, 03 Dec 2012 21:37:54 -0000 On 12/3/12 6:06 AM, Harald Alvestrand wrote: >>>> Regarding a=label: This could be any of T/F/M, depending on >>>> application use. I think we must assume T, and consider an alternative >>>> for F. (And for M if we think it is needed.) >> >> I may have misunderstood your intended meaning for M. I assume you >> meant all RTP streams of the same media type (audio or video) within a >> single 5-tuple. > I was thinking "same payload type", since the payload type is the > distinguisher used for groups of flows that should have the same > parameters in many cases. >> >>> The claim that a=label can be used to mark flows makes it F. >> >> a=label is a media-level attribute, so it is bound to an m-line. >> >> In the absence of bundle, regardless of whether the corresponding RTP >> session has one or several flows. The m-line has a particular media >> type, so I guess it could be viewed as either T or M. > The reason why we're having the discussion is that we have two competing > definitons of what an M-line should be, and need to choose one. > So arguing from whether or not something associates with an M-line is > not useful. >> >> Some applications of a=label may assume or require that the labeled >> m-line contain only one RTP stream. If so, then perhaps the label >> could be considered to be F. But we can't really know that. > What applications of a=label do you know about? I know of two: BFCP and SIPREC. In BFCP the label is used to associate a bfcp floor with an m-line. I don't think it matters whether that m-line carries one or several RTP streams. We can speculate how we would want this to work in the case that several media m-lines were bundled together. I don't know - too many hypotheticals. In SIPREC, the label is used to associate an m-line with certain metadata that describes the source of the media being sent via that m-line. The siprec group has intentionally kept the question of whether the content in that m-line is a single RTP stream or if it can be several multiplexed together. There is nothing to forbid multiplexing, but no specification of what it means either. SIPREC *might* have specified use of bundle, or explicitly specified multiplexing of RTP streams over a single m-line, if those things were better defined. But how it might eventually use bundle or mmt is again a hypothetical right now. A problem for siprec is that it is recording media from existing sip sessions, without any knowledge of how they use SDP and RTP. We could find it recording a call initiated with RTCWEB that uses bundle or mmt. Most likely siprec will need to be extended to support that, though I wish that wasn't so. Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 3 13:44:36 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 7EC1F21F86A2 for ; Mon, 3 Dec 2012 13:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOjIScPeOHsZ for ; Mon, 3 Dec 2012 13:44:34 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 21F0E21F867D for ; Mon, 3 Dec 2012 13:44:33 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id X5t71k0030Fqzac599kZsa; Mon, 03 Dec 2012 21:44:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id X9kZ1k00J3ZTu2S3U9kZS0; Mon, 03 Dec 2012 21:44:33 +0000 Message-ID: <50BD1D40.3090407@alum.mit.edu> Date: Mon, 03 Dec 2012 16:44:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se> <50BCC9E5.60903@alvestrand.no> In-Reply-To: <50BCC9E5.60903@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354571073; bh=gVXChCllatI/4JW+MT0GUQOyvJai9Zw8HxHLe9q+CbA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Pxcfxkf79U7wSRUh9IeykNgX4IyBwa/g5NAod6D1lFo5KtQU/iMOTbLzuRq6lhF+E Ojyho6BUvFlkBqlvGWFhwkJ6U151RzhKu6oGklrnejKeUqo4RHQ9jXALrMCtBvwszu 4M9x5CMQILHn5XYH4U9Wy1zLzbtH52LUtm28aVCOcmI3uMQ5/POUwrFZoV40xBfFQD FyXKU0SAJtJ7xWyb4EU9Q5E3yj3DZMdtoU4p/08P0FWqLjQgOzi+RxIvYeO7huriF4 ayUPkUYb7eJDdYITiVMKOVJp2e7gkpuhQCEUVFDQuWueMGIIPZe/MGygMI5Y8rLY/I vqHWnVOUSHUbA== Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 03 Dec 2012 21:44:36 -0000 On 12/3/12 10:48 AM, Harald Alvestrand wrote: > On 12/03/2012 12:16 PM, Christer Holmberg wrote: >> Hi, >>>> So, the exercise is NOT about how to apply attributes to individual >>>> sources? >>> Only in the sense that it is about figuring out which attributes need >>> to be applied to individual sources. >> Well, I believe that was my original question :) >> >> If you want to apply an attribute to an individual source, you must >> use the ssrc attribute. > > If you are in the camp that believes that there should be more than one > independent source per M-line. > That camp seemed to me to be in the minority in Atlanta; it was > absolutely not the consensus opinion. There were certainly competing camps supporting bundle and mmt. It was not my understanding that supporting bundle means believing that each source gets its own m-line. (I was going to check the mmusic minutes, but they aren't posted yet.) Thanks, Paul From christer.holmberg@ericsson.com Tue Dec 4 00:08: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 4A11221F89C9 for ; Tue, 4 Dec 2012 00:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksa9qZEgzRK5 for ; Tue, 4 Dec 2012 00:08:45 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E509221F89C6 for ; Tue, 4 Dec 2012 00:08:44 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-34-50bdaf8b10dd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B8.C8.06323.B8FADB05; Tue, 4 Dec 2012 09:08:43 +0100 (CET) Received: from ESESSHC011.ericsson.se (153.88.183.51) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Dec 2012 09:08:43 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 09:08:43 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] M-lines: Wikifying it Thread-Index: AQHNzXfLf68XUJVyMEaaKo/W5rPZGpgG5AmA///5IgCAABQFMP//8eMAgAAREeCAADuMgIAAY14AgAC+azA= Date: Tue, 4 Dec 2012 08:08:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04DCDA@ESESSMB209.ericsson.se> References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se> <50BCC9E5.60903@alvestrand.no> <50BD1D40.3090407@alum.mit.edu> In-Reply-To: <50BD1D40.3090407@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW73+r0BBndPaVlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGhPOdTAUf2Cumdl1naWCcw9bFyMEhIWAi 8etkShcjJ5ApJnHh3nqgMBeHkMBJRonfM1cxgiSEBHYwSqxcxAyRWMwocaL9AAtIM5uAhUT3 P22QGhEBX4lnj2+zgdjCAtoSD9b+Y4GI60icX9HDDGEnSSxtO8sEYrMIqEj0zpvADmLzCnhL XJywgBVi108miVv3K0BsTqDeZTO+g9UzAh33/dQaMJtZQFzi1pP5TBBHC0gs2XOeGcIWlXj5 +B8rhK0osfNsOzNEvY7Egt2f2CBsbYllC18zQ+wVlDg58wkLxF5tiZbFE9gnMIrPQrJiFpL2 WUjaZyFpX8DIsoqRPTcxMye93HwTIzByDm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwTnxY+K3y/bqqNue1hVMePO9s3LR/Z/RaY6E9c/dpf5nf8Ldm o8x+lkhV8Vd/A1t+3rhrVb2y8XNJYLNJssmii9baRi/yBSVNxCpYzE936vnJ+ewTe6vy+L56 UsnnedZ/3uQftHXffMsu94DNo1McSUvnLVE/YT9PLP7x94vFEX3Oz93M+RkclViKMxINtZiL ihMBFU8E3moCAAA= Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 04 Dec 2012 08:08:46 -0000 Hi, >>>>> So, the exercise is NOT about how to apply attributes to individual=20 >>>>> sources? >>>> Only in the sense that it is about figuring out which attributes=20 >>>> need to be applied to individual sources. >>> Well, I believe that was my original question :) >>> >>> If you want to apply an attribute to an individual source, you must=20 >>> use the ssrc attribute. >> >> If you are in the camp that believes that there should be more than=20 >> one independent source per M-line. >> That camp seemed to me to be in the minority in Atlanta; it was=20 >> absolutely not the consensus opinion. > > There were certainly competing camps supporting bundle and mmt. > > It was not my understanding that supporting bundle means believing that e= ach source gets its own m-line. Correct. However, I think the "BUNDLE vs MMT" issue is separate from the "single- vs= multiple source per m- line" issue, which I guess is what Harald was refer= ring to. Regards, Christer From harald@alvestrand.no Tue Dec 4 01:22: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 49C3D21F868D for ; Tue, 4 Dec 2012 01:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.124 X-Spam-Level: X-Spam-Status: No, score=-110.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SPiSXnejWom for ; Tue, 4 Dec 2012 01:22:52 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B78B921F86B7 for ; Tue, 4 Dec 2012 01:22:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35AA439E0FD; Tue, 4 Dec 2012 10:22:48 +0100 (CET) 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 q3KVgGo3pgAV; Tue, 4 Dec 2012 10:22:47 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736] (unknown [IPv6:2001:470:de0a:27:99c7:ec3c:d07d:2736]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id E177039E070; Tue, 4 Dec 2012 10:22:46 +0100 (CET) Message-ID: <50BDC0E5.6070700@alvestrand.no> Date: Tue, 04 Dec 2012 10:22:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50B624CC.4010501@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D1FE@ESESSMB209.ericsson.se> <50BC84AC.4040201@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2C6@ESESSMB209.ericsson.se> <50BC89A0.1030104@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D2F9@ESESSMB209.ericsson.se>, <50BCC9E5.60903@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D602@ESESSMB209.ericsson.se> <50BCD57E.4040505@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D715@ESESSMB209.ericsson.se> <50BCDA5F.2050306@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04D862@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04D862@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: Re: [MMUSIC] M-lines: Wikifying it 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, 04 Dec 2012 09:22:53 -0000 On 12/03/2012 06:18 PM, Christer Holmberg wrote: > Hi, > >>>>>>>>> So, the exercise is NOT about how to apply attributes to individual sources? >>>>>>>> Only in the sense that it is about figuring out which attributes need to be applied to individual sources. >>>>>>> Well, I believe that was my original question :) >>>>>>> >>>>>>> If you want to apply an attribute to an individual source, you must use the ssrc attribute. >>>>>> If you are in the camp that believes that there should be more than oneindependent source per M-line. >>>>>> >>>>>> That camp seemed to me to be in the minority in Atlanta; it was absolutely not the consensus opinion. >>>>> It's not about in which camp someone is, it's about the assumptions we make in the wiki study. If the assumption is one source per m- line, than I think it should be explicitly stated. >>>>> Trying again, since I'm obviously not making myself clear: >>>> The two alternative approaches are: >>>> >>>> - Everything that needs to be controlled separately is in its own M-line. Everything that needs to go on the same RTP session uses BUNDLE to get there. Transport parameters get figured out somehow. >>>> >>>> - Everything that goes on the same RTP session goes on the same M-line. >>>> Due to backwards compatible SDP, we may choose to use BUNDLE to lump video and audio together - or we may choose MMT if that works for people. Anything that needs separate control uses a=ssrc. >>> Exactly! >>> >>> So, which (if any) approach do you assume in the wiki? :) >> For the 5th time: I'm NOT assuming one or the other approach. >> I'm trying to gather information that people can use to decide which approach to follow. >> That REQUIRES that the wiki does NOT assume one approach. >> >> Do you hear me now? > So, coming back to my original question: For "F", a *stream* refers to an individual source (and is not related to whether one m- line will or will not contain multiple sources). Correct? I don't want to mix in the "source" word (CLUE has talked about sources that originate multiple streams enough to confuse that term), but if you want to think in terms of sources, yes. > > Regards, > > Christer > From adam@nostrum.com Tue Dec 4 07:47: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 4B28721F8C36 for ; Tue, 4 Dec 2012 07:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHptx2A2rUdd for ; Tue, 4 Dec 2012 07:47:50 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9BB21F8C35 for ; Tue, 4 Dec 2012 07:47:50 -0800 (PST) Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB4FlnWA076612 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 4 Dec 2012 09:47:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50BE1B22.90105@nostrum.com> Date: Tue, 04 Dec 2012 09:47:46 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org, draft-ietf-xrblock-rtcp-xr-burst-gap-loss@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060805080809080809080509" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [MMUSIC] SDP Directorate Feedback for draft-ietf-xrblock-rtcp-xr-burst-gap-loss 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, 04 Dec 2012 15:47:51 -0000 This is a multi-part message in MIME format. --------------060805080809080809080509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have been asked to perform the SDP Directorate review for draft-ietf-xrblock-rtcp-xr-burst-gap-loss. I reviewed the -05 version of the document. In general, the syntax looks fine -- this document makes use of a defined extension point in RFC 3611. I find no mismatch between the proposed semantics of this document and what appears to be intended by xrblock usage. I found a handful of tiny nits in the IANA section: 1. The first line of section 6.1 says "NDEL" where it means "NBGL." I would imagine this gets cleaned up during IANA review, but there's no point leaving it confusing. 2. Section 6.2 refers to the "RTCP XR SDP Parameters Registry," whereas IANA has titled the registry "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry" (cf. http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xml). It would help readers of this document who wish to locate the registry if the precise IANA name were used. 3. Section 6.1 has a similar mismatch, using "RTCP XR Block Type Registry" rather than "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" Thanks. /a --------------060805080809080809080509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have been asked to perform the SDP Directorate review for draft-ietf-xrblock-rtcp-xr-burst-gap-loss. I reviewed the -05 version of the document.

In general, the syntax looks fine -- this document makes use of a defined extension point in RFC 3611. I find no mismatch between the proposed semantics of this document and what appears to be intended by xrblock usage.

I found a handful of tiny nits in the IANA section:

  1. The first line of section 6.1 says "NDEL" where it means "NBGL." I would imagine this gets cleaned up during IANA review, but there's no point leaving it confusing.

  2. Section 6.2 refers to the "RTCP XR SDP Parameters Registry," whereas IANA has titled the registry "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry" (cf. http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xml).  It would help readers of this document who wish to locate the registry if the precise IANA name were used.

  3. Section 6.1 has a similar mismatch, using "RTCP XR Block Type Registry" rather than "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry"

Thanks.

/a
--------------060805080809080809080509-- From bill.wu@huawei.com Tue Dec 4 19:29: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 DCC9721F8BE4; Tue, 4 Dec 2012 19:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqA8PqYmGMT9; Tue, 4 Dec 2012 19:29:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB0021F8BCD; Tue, 4 Dec 2012 19:29:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANM50193; Wed, 05 Dec 2012 03:28:56 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 03:27:54 +0000 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 03:28:21 +0000 Received: from w53375 (10.138.41.149) by szxeml405-hub.china.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 11:28:16 +0800 Message-ID: <8C652E86259649529BAA16CA8DAB3C9B@china.huawei.com> From: Qin Wu To: Adam Roach , , References: <50BE1B22.90105@nostrum.com> Date: Wed, 5 Dec 2012 11:28:16 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DD_01CDD2DB.9E785750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: xrblock@ietf.org Subject: Re: [MMUSIC] SDP Directorate Feedback fordraft-ietf-xrblock-rtcp-xr-burst-gap-loss 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, 05 Dec 2012 03:29:04 -0000 ------=_NextPart_000_01DD_01CDD2DB.9E785750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksQWRhbToNClRoYW5rIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3IG9uIGJlaGFsZiBvZiBTRFAg RGlyZWN0b3JhdGUuIFdlIHdpbGwgZml4IHRoZXNlIHRocmVlIG5pdHMgeW91IHNwb3QgaW4gdGhl IG5leHQgdmVyc2lvbi4NClRoYW5rcyBhZ2Fpbi4NCg0KUmVnYXJkcyENCi1RaW4NCiAgLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogQWRhbSBSb2FjaCANCiAgVG86IG1tdXNp Y0BpZXRmLm9yZyA7IGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1cnN0LWdhcC1sb3NzQHRv b2xzLmlldGYub3JnIA0KICBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNCwgMjAxMiAxMTo0NyBQ TQ0KICBTdWJqZWN0OiBbTU1VU0lDXSBTRFAgRGlyZWN0b3JhdGUgRmVlZGJhY2sgZm9yZHJhZnQt aWV0Zi14cmJsb2NrLXJ0Y3AteHItYnVyc3QtZ2FwLWxvc3MNCg0KDQogIEkgaGF2ZSBiZWVuIGFz a2VkIHRvIHBlcmZvcm0gdGhlIFNEUCBEaXJlY3RvcmF0ZSByZXZpZXcgZm9yIGRyYWZ0LWlldGYt eHJibG9jay1ydGNwLXhyLWJ1cnN0LWdhcC1sb3NzLiBJIHJldmlld2VkIHRoZSAtMDUgdmVyc2lv biBvZiB0aGUgZG9jdW1lbnQuDQoNCiAgSW4gZ2VuZXJhbCwgdGhlIHN5bnRheCBsb29rcyBmaW5l IC0tIHRoaXMgZG9jdW1lbnQgbWFrZXMgdXNlIG9mIGEgZGVmaW5lZCBleHRlbnNpb24gcG9pbnQg aW4gUkZDIDM2MTEuIEkgZmluZCBubyBtaXNtYXRjaCBiZXR3ZWVuIHRoZSBwcm9wb3NlZCBzZW1h bnRpY3Mgb2YgdGhpcyBkb2N1bWVudCBhbmQgd2hhdCBhcHBlYXJzIHRvIGJlIGludGVuZGVkIGJ5 IHhyYmxvY2sgdXNhZ2UuDQoNCiAgSSBmb3VuZCBhIGhhbmRmdWwgb2YgdGlueSBuaXRzIGluIHRo ZSBJQU5BIHNlY3Rpb246DQoNCg0KICAgIDEuLiBUaGUgZmlyc3QgbGluZSBvZiBzZWN0aW9uIDYu MSBzYXlzICJOREVMIiB3aGVyZSBpdCBtZWFucyAiTkJHTC4iIEkgd291bGQgaW1hZ2luZSB0aGlz IGdldHMgY2xlYW5lZCB1cCBkdXJpbmcgSUFOQSByZXZpZXcsIGJ1dCB0aGVyZSdzIG5vIHBvaW50 IGxlYXZpbmcgaXQgY29uZnVzaW5nLg0KDQoNCltRaW5dOkdvb2QgY2F0Y2gsIHRoYW5rcy4NCiAg ICAxLi4gU2VjdGlvbiA2LjIgcmVmZXJzIHRvIHRoZSAiUlRDUCBYUiBTRFAgUGFyYW1ldGVycyBS ZWdpc3RyeSwiIHdoZXJlYXMgSUFOQSBoYXMgdGl0bGVkIHRoZSByZWdpc3RyeSAiUlRQIENvbnRy b2wgUHJvdG9jb2wgRXh0ZW5kZWQgUmVwb3J0cyAoUlRDUCBYUikgU2Vzc2lvbiBEZXNjcmlwdGlv biBQcm90b2NvbCAoU0RQKSBQYXJhbWV0ZXJzIFJlZ2lzdHJ5IiAoY2YuIGh0dHA6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvcnRjcC14ci1zZHAtcGFyYW1ldGVycy9ydGNwLXhyLXNkcC1wYXJh bWV0ZXJzLnhtbCkuICBJdCB3b3VsZCBoZWxwIHJlYWRlcnMgb2YgdGhpcyBkb2N1bWVudCB3aG8g d2lzaCB0byBsb2NhdGUgdGhlIHJlZ2lzdHJ5IGlmIHRoZSBwcmVjaXNlIElBTkEgbmFtZSB3ZXJl IHVzZWQuDQoNCltRaW5dOiBva2F5Lg0KDQogICAgMS4uIFNlY3Rpb24gNi4xIGhhcyBhIHNpbWls YXIgbWlzbWF0Y2gsIHVzaW5nICJSVENQIFhSIEJsb2NrIFR5cGUgUmVnaXN0cnkiIHJhdGhlciB0 aGFuICJSVFAgQ29udHJvbCBQcm90b2NvbCBFeHRlbmRlZCBSZXBvcnRzIChSVENQIFhSKSBCbG9j ayBUeXBlIFJlZ2lzdHJ5IiANCg0KW1Fpbl06IE9rYXkuDQpUaGFua3MuDQoNCi9hDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogIG1tdXNpYyBtYWlsaW5nIGxpc3QNCiAgbW11c2ljQGlldGYu b3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= ------=_NextPart_000_01DD_01CDD2DB.9E785750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTI5OCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZiB0ZXh0PSMwMDAwMDA+DQo8RElWPkhpLEFkYW06PC9E SVY+DQo8RElWPlRoYW5rIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3IG9uIGJlaGFsZiBvZiBTRFAg RGlyZWN0b3JhdGUuIFdlIHdpbGwgZml4IA0KdGhlc2UgdGhyZWUgbml0cyB5b3Ugc3BvdCBpbiB0 aGUgbmV4dCB2ZXJzaW9uLjwvRElWPg0KPERJVj5UaGFua3MgYWdhaW4uPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5SZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8QkxPQ0tR VU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVG VDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAm IzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+ PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1hZGFtQG5vc3RydW0uY29tIGhyZWY9Im1haWx0bzph ZGFtQG5vc3RydW0uY29tIj5BZGFtIFJvYWNoPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9O VDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9bW11c2ljQGlldGYu b3JnIA0KICBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L0E+ IDsgPEEgDQogIHRpdGxlPWRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1cnN0LWdhcC1sb3Nz QHRvb2xzLmlldGYub3JnIA0KICBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3At eHItYnVyc3QtZ2FwLWxvc3NAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYteHJibG9jay1ydGNw LXhyLWJ1cnN0LWdhcC1sb3NzQHRvb2xzLmlldGYub3JnPC9BPiANCiAgPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVHVlc2RheSwg RGVjZW1iZXIgMDQsIDIwMTIgMTE6NDcgDQogIFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gW01NVVNJQ10gU0RQIERpcmVj dG9yYXRlIEZlZWRiYWNrIA0KICBmb3JkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1idXJzdC1n YXAtbG9zczwvRElWPg0KICA8RElWPjxCUj48L0RJVj5JIGhhdmUgYmVlbiBhc2tlZCB0byBwZXJm b3JtIHRoZSBTRFAgRGlyZWN0b3JhdGUgcmV2aWV3IGZvciANCiAgZHJhZnQtaWV0Zi14cmJsb2Nr LXJ0Y3AteHItYnVyc3QtZ2FwLWxvc3MuIEkgcmV2aWV3ZWQgdGhlIC0wNSB2ZXJzaW9uIG9mIHRo ZSANCiAgZG9jdW1lbnQuPEJSPjxCUj5JbiBnZW5lcmFsLCB0aGUgc3ludGF4IGxvb2tzIGZpbmUg LS0gdGhpcyBkb2N1bWVudCBtYWtlcyB1c2UgDQogIG9mIGEgZGVmaW5lZCBleHRlbnNpb24gcG9p bnQgaW4gUkZDIDM2MTEuIEkgZmluZCBubyBtaXNtYXRjaCBiZXR3ZWVuIHRoZSANCiAgcHJvcG9z ZWQgc2VtYW50aWNzIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHdoYXQgYXBwZWFycyB0byBiZSBpbnRl bmRlZCBieSB4cmJsb2NrIA0KICB1c2FnZS48QlI+PEJSPkkgZm91bmQgYSBoYW5kZnVsIG9mIHRp bnkgbml0cyBpbiB0aGUgSUFOQSBzZWN0aW9uOjxCUj48QlI+DQogIDxPTD4NCiAgICA8TEk+VGhl IGZpcnN0IGxpbmUgb2Ygc2VjdGlvbiA2LjEgc2F5cyAiTkRFTCIgd2hlcmUgaXQgbWVhbnMgIk5C R0wuIiBJIHdvdWxkIA0KICAgIGltYWdpbmUgdGhpcyBnZXRzIGNsZWFuZWQgdXAgZHVyaW5nIElB TkEgcmV2aWV3LCBidXQgdGhlcmUncyBubyBwb2ludCANCiAgICBsZWF2aW5nIGl0IGNvbmZ1c2lu Zy48QlI+PEJSPjwvTEk+PC9PTD48L0JMT0NLUVVPVEU+DQo8RElWPltRaW5dOkdvb2QgY2F0Y2gs IHRoYW5rcy48L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAw IDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lO LUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8T0w+DQogICAgPExJPlNlY3Rpb24g Ni4yIHJlZmVycyB0byB0aGUgIlJUQ1AgWFIgU0RQIFBhcmFtZXRlcnMgUmVnaXN0cnksIiB3aGVy ZWFzIA0KICAgIElBTkEgaGFzIHRpdGxlZCB0aGUgcmVnaXN0cnkgIlJUUCBDb250cm9sIFByb3Rv Y29sIEV4dGVuZGVkIFJlcG9ydHMgKFJUQ1AgDQogICAgWFIpIFNlc3Npb24gRGVzY3JpcHRpb24g UHJvdG9jb2wgKFNEUCkgUGFyYW1ldGVycyBSZWdpc3RyeSIgKGNmLiA8QSANCiAgICBjbGFzcz1t b3otdHh0LWxpbmstZnJlZXRleHQgDQogICAgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9ydGNwLXhyLXNkcC1wYXJhbWV0ZXJzL3J0Y3AteHItc2RwLXBhcmFtZXRlcnMueG1s Ij5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3J0Y3AteHItc2RwLXBhcmFtZXRlcnMv cnRjcC14ci1zZHAtcGFyYW1ldGVycy54bWw8L0E+KS4mbmJzcDsgDQogICAgSXQgd291bGQgaGVs cCByZWFkZXJzIG9mIHRoaXMgZG9jdW1lbnQgd2hvIHdpc2ggdG8gbG9jYXRlIHRoZSByZWdpc3Ry eSBpZiANCiAgICB0aGUgcHJlY2lzZSBJQU5BIG5hbWUgd2VyZSB1c2VkLjxCUj48L0xJPjwvT0w+ PC9CTE9DS1FVT1RFPg0KPERJVj5bUWluXTogb2theS48QlI+PC9ESVY+DQo8QkxPQ0tRVU9URSAN CnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4 OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4 Ij4NCiAgPE9MPg0KICAgIDxMST5TZWN0aW9uIDYuMSBoYXMgYSBzaW1pbGFyIG1pc21hdGNoLCB1 c2luZyAiUlRDUCBYUiBCbG9jayBUeXBlIFJlZ2lzdHJ5IiANCiAgICByYXRoZXIgdGhhbiAiUlRQ IENvbnRyb2wgUHJvdG9jb2wgRXh0ZW5kZWQgUmVwb3J0cyAoUlRDUCBYUikgQmxvY2sgVHlwZSAN CiAgICBSZWdpc3RyeSIgPC9MST48L09MPg0KICA8RElWPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9U RT4NCjxESVY+W1Fpbl06IE9rYXkuPEJSPlRoYW5rcy48QlI+PEJSPi9hPEJSPjwvRElWPg0KPEJM T0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5H LUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4t UklHSFQ6IDBweCI+DQogIDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPm1tdXNpYyBtYWlsaW5nIA0KICBsaXN0 PEJSPm1tdXNpY0BpZXRmLm9yZzxCUj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYzxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_01DD_01CDD2DB.9E785750-- From ari.keranen@nomadiclab.com Wed Dec 5 13:22: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 72CEC21F8B9E for ; Wed, 5 Dec 2012 13:22:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uzcH7Rw9dv1 for ; Wed, 5 Dec 2012 13:22:05 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id CCA9421F8AF1 for ; Wed, 5 Dec 2012 13:22:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6A94D4E6ED; Wed, 5 Dec 2012 23:22:02 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuPubsXHDyNr; Wed, 5 Dec 2012 23:22:01 +0200 (EET) Received: from as-macbook-air.p-661hnu-f1 (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 93ABE4E6EC; Wed, 5 Dec 2012 23:22:01 +0200 (EET) Message-ID: <50BFBAFC.8080106@nomadiclab.com> Date: Wed, 05 Dec 2012 23:22:04 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: draft-ietf-mmusic-rtsp-nat@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmusic Subject: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 05 Dec 2012 21:22:05 -0000 Hi, I reviewed the draft-ietf-mmusic-rtsp-nat-14 and I think the document is in pretty good shape and ready to move forward. Some (mostly editorial) comments to consider: 3. Solution Overview The client then installs the STUN servers on each of the local candidates transport addresses it has gathered I would rather say "The client then prepares to act as a STUN server on each [...]" If the server has a public IP address, then a single candidate per address family In some cases (e.g., certain ISPs, I've heard) even "public" IP address does not mean you're not behind a NAT. Maybe it's better to say here "If the server is not behind a NAT". Same issue in step 8. If the server has a public IP address with a single candidate per media stream, component and address family, then the server may be configured to not initiate connectivity checks. This is the "ICE-RTSP", right? Maybe one (small) subsection defining this "feature" would make sense. Now it's a bit trickled around in this section, sec 4.8.1, 5.4, etc. For someone not familiar with ICE-RTSP, it looks like you're talking about ICE lite. the NAT need to be refreshed by the client to server traffic provided by the STUN keep-alive. s/keep-alive/keep-alive mechanism/ (or messages). Also in section 5.11. 5.7. Client to Server ICE Connectivity Check The client receives the SETUP response and learns the candidate address to use for the connectivity checks. s/address/addresses/ (right?) Aggressive nomination SHALL be used with RTSP. This doesn't have the negative impact that it has in offer/answer as media playing only starts after issuing a PLAY request. But it does have the downside of possibly selecting a lower-priority pair due to single dropped (e.g., due to congestion) connectivity check message for a higher priority pair. That said, probably SHALL is appropriate here, just wanted to make sure the implications are understood. 5.12. Re-SETUP If the client decides to change any parameters related to the media stream setup Could clarify (again) here that we talk about ICE parameters. Cheers, Ari From harald@alvestrand.no Thu Dec 6 05:02: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 718BB21F8626 for ; Thu, 6 Dec 2012 05:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kT5vvkPXIxs for ; Thu, 6 Dec 2012 05:02:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D228421F874D for ; Thu, 6 Dec 2012 05:02:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F7AC39E27D for ; Thu, 6 Dec 2012 14:02:41 +0100 (CET) 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 cLrjxKo10OH2 for ; Thu, 6 Dec 2012 14:02:40 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:a184:710a:187:1564] (unknown [IPv6:2001:470:de0a:27:a184:710a:187:1564]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 709B139E235 for ; Thu, 6 Dec 2012 14:02:40 +0100 (CET) Message-ID: <50C0976F.5020907@alvestrand.no> Date: Thu, 06 Dec 2012 14:02:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <50BC8969.6010101@alvestrand.no> <50BD07FC.30809@alum.mit.edu> In-Reply-To: <50BD07FC.30809@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 06 Dec 2012 13:02:43 -0000 On 12/03/2012 09:13 PM, Paul Kyzivat wrote: > On 12/3/12 6:13 AM, Harald Alvestrand wrote: >> On 12/03/2012 10:02 AM, Markus.Isomaki@nokia.com wrote: >>> Hi, >>> >>> I agree that it would be useful to be able to run data channel on the >>> same 5-tuple as RTP/RTCP, and even making it the default and >>> must-implement way for the browsers. >>> >>> QoS/prioritization comes to mind as the only potential drawback. The >>> endpoint can naturally still give different priorities to the >>> different components (audio, video, "data") it is sending. I assume >>> SCTP also has TCP-style receiver window that can be used to throttle >>> reception if needed. And presumably RMCAT will find solutions to >>> congestion control in genenral. But from the network perspective there >>> is only one flow, and the only(?) way to differentiate the components >>> is to use DSCP. I don't think our QoS (or API) draft yet clearly >>> explains how DSCP's are learned and set, or whether that is even going >>> to be a realistic solution. >> >> That is indeed the only reason I can think of to specify multiple >> m-lines for DTLS/SCTP (and we don't need to bundle them together). >> >> At the moment, the MMUSIC API doesn't define a way to control which >> m-line a DTLS assocation gets mapped onto. > > MMUSIC *API*??? Sorry, I was writing at a non-awake time. I meant the WebRTC API (Javascript, specified in the W3C WG). I From magnus.westerlund@ericsson.com Thu Dec 6 07:03:14 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 A36E621F86DD for ; Thu, 6 Dec 2012 07:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhqqSzDkW3Nv for ; Thu, 6 Dec 2012 07:03:14 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11321F86CC for ; Thu, 6 Dec 2012 07:03:13 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-c4-50c0b3b0f3a4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A4.23.26143.0B3B0C05; Thu, 6 Dec 2012 16:03:12 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Dec 2012 16:03:11 +0100 Message-ID: <50C0B3AB.4010509@ericsson.com> Date: Thu, 6 Dec 2012 16:03:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ari Keranen References: <50BFBAFC.8080106@nomadiclab.com> In-Reply-To: <50BFBAFC.8080106@nomadiclab.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje6GzQcCDD7tELFoe/OLzaL9zREm i6nLH7M4MHssWfKTyaNzUbTHl8uf2QKYo7hsUlJzMstSi/TtErgyFvavZS24KF8x+dJXxgbG YxJdjJwcEgImEgt2zmaGsMUkLtxbz9bFyMUhJHCSUWLN0zYmCGcZo8TBU78ZQap4BbQlrk79 yAZiswioSNz9+58dxGYTsJC4+aMRLC4q4Csxa88vJoh6QYmTM5+wgNgiAjoS3dvugsWZBdwl jh76DrZZWMBKYv+7flYQW0hAV2LhjGlgNqeAnsSBjZOgrpOUWDStkwWiV09iytUWRghbXqJ5 K8QHQkC3NTR1sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15utIkRGL4Ht/xW3cF455zIIUZp DhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAu/Tnty9QWhojAUOv8rA2e1yLv uvC2Gdycwdl7MmTPsZf92deXtDU+WBL/+Rz7BKPk9l18aSHr/N+y2Dh8erB88b3czLR8o9Xb Dmi+2xUd7NlinPpsT/qfT+LTWl3tN7vuuiDI+VIzm+HX9cfPk/hS3n9mjFA9EJ/wvapLzV1X ou0c92Wz6Z1KLMUZiYZazEXFiQAXHcBFLQIAAA== Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 06 Dec 2012 15:03:14 -0000 Hi Ari, Thanks for the review. I feel much more confident now that we haven't significantly screwed up any ICE details. On 2012-12-05 22:22, Ari Keranen wrote: > Hi, > > I reviewed the draft-ietf-mmusic-rtsp-nat-14 and I think the document is > in pretty good shape and ready to move forward. Some (mostly editorial) > comments to consider: > > > 3. Solution Overview > > The client then installs the STUN servers on each of > the local candidates transport addresses it has gathered > > I would rather say "The client then prepares to act as a STUN server on > each [...]" Sure, maybe "runs STUN servers" is better than both "installs" and "act". They are STUN server, but with limited utility. Act as STUN servers sounds like it is impersonating STUN, rather than actually being STUN servers. > > > If the server has a public > IP address, then a single candidate per address family > > In some cases (e.g., certain ISPs, I've heard) even "public" IP address > does not mean you're not behind a NAT. Maybe it's better to say here "If > the server is not behind a NAT". Same issue in step 8. Sure, maybe we need to define what we mean with not being behind a NAT. It is a matter of being reachable from the top anchorin address domain in regards to the clients. > > > If the server has a public IP address with a single candidate > per media stream, component and address family, then the server > may be configured to not initiate connectivity checks. > > This is the "ICE-RTSP", right? Maybe one (small) subsection defining > this "feature" would make sense. Now it's a bit trickled around in this > section, sec 4.8.1, 5.4, etc. For someone not familiar with ICE-RTSP, it > looks like you're talking about ICE lite. Yes, this is definitely ICE-RTSP. It is still doing triggered checks. > > > the NAT need to be refreshed by the client to server traffic provided > by the STUN keep-alive. > > s/keep-alive/keep-alive mechanism/ (or messages). > Also in section 5.11. Will address. > > > 5.7. Client to Server ICE Connectivity Check > > The client receives the SETUP response and learns the candidate > address to use for the connectivity checks. > > s/address/addresses/ (right?) > > > Aggressive nomination SHALL be used with RTSP. This doesn't have the > negative impact that it has in offer/answer as media playing only > starts after issuing a PLAY request. > > But it does have the downside of possibly selecting a lower-priority > pair due to single dropped (e.g., due to congestion) connectivity check > message for a higher priority pair. That said, probably SHALL is > appropriate here, just wanted to make sure the implications are understood. Yes, but with ICE-RTSP you will retransmit the higher priority also, thus if that works and you get a response that alternative is nominated and will be used. But we probably should clarify what it means when multiple candidate pairs are nominated, and in worse case the server will use different paths for different media streams. > > > 5.12. Re-SETUP > > If the client decides to change any parameters related to the media > stream setup > > Could clarify (again) here that we talk about ICE parameters. Yes, definitely. I actually had to think a long time if this was only ICE parameters or also RTSP parameters. But, it is so unnecessary to restart ICE for most RTSP parameter changes. 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 pkyzivat@alum.mit.edu Thu Dec 6 09:04: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 E11DF21F8703 for ; Thu, 6 Dec 2012 09:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNDbJxsABvNA for ; Thu, 6 Dec 2012 09:04:02 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6E021F865C for ; Thu, 6 Dec 2012 09:04:02 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id YCMv1k0010mv7h054H41vq; Thu, 06 Dec 2012 17:04:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id YH411k00S3ZTu2S3XH41r5; Thu, 06 Dec 2012 17:04:01 +0000 Message-ID: <50C0D000.2060102@alum.mit.edu> Date: Thu, 06 Dec 2012 12:04:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <50BC8969.6010101@alvestrand.no> <50BD07FC.30809@alum.mit.edu> <50C0976F.5020907@alvestrand.no> In-Reply-To: <50C0976F.5020907@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354813441; bh=hjBkQKovrLVfttKt8K/9+P7rd25qQho8ETW+9fbmWKI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZvJ2XHLdK1pSa2aONNNhuhntTJXZ0nZpT2focssbtIlAdd+EPQm99liJXYpQehMry qDvsebl5d2yJe2wFIsnWSWliDhN1DYwSxYUFwhafXekm1TolgQCYglx9YnwthIwYXm wG3zji+h8fs3iAHejKnfCxydlxLuRIGoRv7JomlISFEr2oYz4/oDTweQ3HiFlRmHSO F28fcAbpC2uGb3TMl4RSnIOKlYQENL+l8ADaDgQPLhYhechBYjXvniEHvPA34xjG7S mVwKTRal9UveQz30aGwH35nVkzv0zbZgEHf12Hta07yymjbC+VU4z48opeRywKPq/Z CFFoANthTQm1g== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 06 Dec 2012 17:04:03 -0000 Harald - comment at end. On 12/6/12 8:02 AM, Harald Alvestrand wrote: > On 12/03/2012 09:13 PM, Paul Kyzivat wrote: >> On 12/3/12 6:13 AM, Harald Alvestrand wrote: >>> On 12/03/2012 10:02 AM, Markus.Isomaki@nokia.com wrote: >>>> Hi, >>>> >>>> I agree that it would be useful to be able to run data channel on the >>>> same 5-tuple as RTP/RTCP, and even making it the default and >>>> must-implement way for the browsers. >>>> >>>> QoS/prioritization comes to mind as the only potential drawback. The >>>> endpoint can naturally still give different priorities to the >>>> different components (audio, video, "data") it is sending. I assume >>>> SCTP also has TCP-style receiver window that can be used to throttle >>>> reception if needed. And presumably RMCAT will find solutions to >>>> congestion control in genenral. But from the network perspective there >>>> is only one flow, and the only(?) way to differentiate the components >>>> is to use DSCP. I don't think our QoS (or API) draft yet clearly >>>> explains how DSCP's are learned and set, or whether that is even going >>>> to be a realistic solution. >>> >>> That is indeed the only reason I can think of to specify multiple >>> m-lines for DTLS/SCTP (and we don't need to bundle them together). >>> >>> At the moment, the MMUSIC API doesn't define a way to control which >>> m-line a DTLS assocation gets mapped onto. >> >> MMUSIC *API*??? > > Sorry, I was writing at a non-awake time. > I meant the WebRTC API (Javascript, specified in the W3C WG). OK. That makes more sense. Well, there are two solutions to that: - enhance the API to provide that capability, perhaps with a default to make it simple in common cases. - limit WebRTC to follow a convention for which only supports a subset of what is possible in SDP. IMO the first is the wiser choice. In any case we are not defining this in SDP solely for WebRTC. We need to specify this in a way that works for everybody that wants to use it. One way or another the SDP must define the SCTP association, and if it is to share a 5-tuple then the grouping to do that needs to be defined. IIUC, the current bundle draft isn't capable of doing that. Thanks, Paul From christer.holmberg@ericsson.com Thu Dec 6 10:01:17 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 C0C9F21F8829 for ; Thu, 6 Dec 2012 10:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jghCrU+p5-2W for ; Thu, 6 Dec 2012 10:01:17 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DED4821F8827 for ; Thu, 6 Dec 2012 10:01:16 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-e2-50c0dd6bc9e9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 36.30.11564.B6DD0C05; Thu, 6 Dec 2012 19:01:15 +0100 (CET) Received: from ESESSHC024.ericsson.se (153.88.183.90) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Dec 2012 19:01:14 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Thu, 6 Dec 2012 19:01:14 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] SCTP question: Where does it multiplex? Thread-Index: AQHNuOZOfTvjBV7D20u9zqAifYT++pgD5FSAgABAboCAADbCAIACeIWAgAARPpD///OGAIAADowAgAAkm4CAAJbjAIAEPomAgABDbgCAACAj1Q== Date: Thu, 6 Dec 2012 18:01:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B050092@ESESSMB209.ericsson.se> References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <50BC8969.6010101@alvestrand.no> <50BD07FC.30809@alum.mit.edu> <50C0976F.5020907@alvestrand.no>,<50C0D000.2060102@alum.mit.edu> In-Reply-To: <50C0D000.2060102@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvjW723QMBBnualSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj/8QXpoJTzBXv3t5jbmB8wdTFyMkhIWAi sW3zVXYIW0ziwr31bF2MXBxCAicZJU7cfcgK4exglGj4fooFwlnMKPF9Uy9zFyMHB5uAhUT3 P22QbhEBX4lnj2+zgdjCArYSb098ZoOI20nc/LeIHcKuk9hx/SALiM0ioCJxu/85K4jNK+At ser7VmaI+c+ZJe7s3MgIkuAU0JG4f+oHM4jNCHTe91NrwM5mFhCXuPVkPtQLAhJL9pxnhrBF JV4+/scKYStK7DzbzgxRryOxYPcnNghbW2LZwtfMEIsFJU7OfAJ2kBBQvGXxBPYJjOKzkKyY haR9FpL2WUjaFzCyrGJkz03MzEkvN9zECIyfg1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MkyJM7U/FuJ1Im9EV8dWTYfbtk583RO/deoerW+p4dk/Y rX/nDPeu3OkvdUNgUsyxtRsOrdGIPnPpwL5/56T/W137NoV32uyC4hsFG6TFl81S9b3+d0es /fnZ3jFp2bYTRO+a6ygdqbS81DXt4v5EvdSKQL9XXyatb18SZrYk4+DD4m1TA19pbVJiKc5I NNRiLipOBAAoZMCwbQIAAA== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 06 Dec 2012 18:01:17 -0000 Hi, >One way or another the SDP must define the SCTP association, and if it >is to share a 5-tuple then the grouping to do that needs to be defined. >IIUC, the current bundle draft isn't capable of doing that. The current bundle draft needs additional work, mainly regarding the handli= ng of SDP attributes etc, even to share a 5-tuple for RTP. But, in general, what problems do you see with using bundle also for SCTP? Regards, Christer From pkyzivat@alum.mit.edu Thu Dec 6 13:44: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 A708A21E8040 for ; Thu, 6 Dec 2012 13:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXxLsW78Y3My for ; Thu, 6 Dec 2012 13:44:51 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id D17CE21F8919 for ; Thu, 6 Dec 2012 13:44:49 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id YET91k0031YDfWL54Mkm4g; Thu, 06 Dec 2012 21:44:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id YMkl1k00g3ZTu2S3gMkmVG; Thu, 06 Dec 2012 21:44:46 +0000 Message-ID: <50C111CD.601@alum.mit.edu> Date: Thu, 06 Dec 2012 16:44:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BA47E8.4010909@alum.mit.edu> <50BC5A81.6050503@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B04CC3A@ESESSMB209.ericsson.se> <50BC5E80.4090006@alvestrand.no> <50BC8969.6010101@alvestrand.no> <50BD07FC.30809@alum.mit.edu> <50C0976F.5020907@alvestrand.no>, <50C0D000.2060102@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B050092@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B050092@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354830286; bh=FF/TjFrX7tlPmUEEralx1UXo99Qo/NhuIbDapX085TU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jjAU5xZDeIcomKbOkMiXRI7YleSyQMXmHnQVgHDj+y21V2ww8Iz3JJzWrwb9IOi2V uWO2qxVok6jJZozJNr4m2B11UD5ybAY5LfDhyHvZo7xdWAmY/QL9VIG/F8N2LmVj1C vnifaxsWPfRZtZlY/E4b22oeywZpU2NocTPndYCBLAwjOzNHHS0y2pqDzTn4CWNEt9 XAkg9UobfNy+qy3/V7WGebTsY5CVn+rx0Xwe8B2qKA6lVNXe7TGNGKwElEYgiDiLCz EH1xBvLed4SnrVv1iUMT4wkB2MQP4G5WcXB8R5pGUYO1C5RjSOPT09p4rN1lOHs/Wp Ee6Kpi+6PY0iA== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 06 Dec 2012 21:44:51 -0000 On 12/6/12 1:01 PM, Christer Holmberg wrote: > Hi, > >> One way or another the SDP must define the SCTP association, and if it >> is to share a 5-tuple then the grouping to do that needs to be defined. >> IIUC, the current bundle draft isn't capable of doing that. > > The current bundle draft needs additional work, mainly regarding the handling of SDP attributes etc, even to share a 5-tuple for RTP. The current draft requires the fields of all the bundled m-lines to be the same. It also strongly implies that all of them must be RTP-related. To include the SCTP m-line for support of the data channels, it will be necessary dissimilar fields to be bundled. But not all combinations are valid. So it needs some additional text to explain which other cases may be bundled. The simple way out would be to simply enumerate the different combinations of s that may be bundled and any other constraints that may apply. Better would be to define some more general criteria for those that may be bundled, so that it might survive future extensions. An obvious constraint is that there must be some way of demuxing them. I am still trying to understand the details of how the DTLS/SRTP is multiplexed with RTP (actually I guess it will be UDP/TLS/RTP/SAVP(F)). Is there some place that explains that? RFC 5764 explains how RTP, DTLS, and STUN are demuxed for DTLS/SRTP. And draft-tuexen-tsvwg-sctp-dtls-encaps explains how to run SCTP over DTLS. But those two mappings don't seem to be compatible. Has anyone written down a proposal for how that will work? Thanks, Paul From brian.rosen@neustar.biz Thu Dec 6 17:50: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 8073511E80AD for ; Thu, 6 Dec 2012 17:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeQ9oiWqvodV for ; Thu, 6 Dec 2012 17:50:52 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50311E80A6 for ; Thu, 6 Dec 2012 17:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1354845024; x=1670195649; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=DQ1MZzmYh/L2bUzKQ2w8KgTort1CP58Ax19DXGyzo0Y=; b=AE36QJOQh6RxGXv+1V7qW7s8kFSL3wxle7ajTe6cSd5VEbewROYfH0w5yClQk2 GcC5uadDNgbQN+TG+GPWf/Yg== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.12676311; Thu, 06 Dec 2012 20:50:23 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 6 Dec 2012 20:50:49 -0500 From: "Rosen, Brian" To: "Klatsky, Carl" Date: Thu, 6 Dec 2012 20:50:47 -0500 Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-24 Thread-Index: Ac3UHUe6KoMRb0ryTeqtbVQzBfZdYQ== Message-ID: <6C6819F4-6CBD-4B40-B6C7-65918F179D52@neustar.biz> References: <6C15A6B88541034E912E94C2D8BC3E8772B4C899@PACDCEXMB15.cable.comcast.com> In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E8772B4C899@PACDCEXMB15.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: DuH9X9EMTHt6zoLgS9r4Sg== Content-Type: multipart/alternative; boundary="_000_6C6819F46CBD4B40B6C765918F179D52neustarbiz_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 07 Dec 2012 00:48:56 -0800 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-24 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, 07 Dec 2012 01:50:53 -0000 --_000_6C6819F46CBD4B40B6C765918F179D52neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No one replied to you. I believe there is no restriction, any codec could be used in theory. We j= ust had a conversation about if any media streams were looped, did all of t= hem have to be, and the consensus on that was no. Not sure any device woul= d choose to allow loopback of telephone-events, but it could I suppose. I don't think it could reasonably be extended to hack caller id in the way = you describe. Brian On Nov 12, 2012, at 3:46 PM, "Klatsky, Carl" > wrote: Hi, A colleague of mine forwarded me this draft and I had two comments if someo= ne on the distro has input: 1) When setting up the media loopback, are there any restrictions on t= ype of codec used? Could even telephone-events codec be specified? 2) Although this draft is centered around media, can it be extended to= for use as means to test the caller ID set connected to an analog telephon= y interface? The approach outlined in this draft seems to imply no interac= tion with the end subscriber is needed. If the network operator wanted to = silently send a test pattern to the caller ID set, perhaps this same loopba= ck mechanism can be used with either an additional SDP attribute or some ch= ange in the SIP header itself. A related application would be to advance t= he timestamp on the caller ID set following Daylight Savings Time transitio= n. Typically that is not updated until the next inbound call following the= DST change. A loopback call could signal to the device to update the call= er ID set but without ringing / alerting the end subscriber without the nee= d to wait for an inbound call. Regards, Carl Klatsky Comcast _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_6C6819F46CBD4B40B6C765918F179D52neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No one replied to you.

I believe there is no restric= tion, any codec could be used in theory.  We just had a conversation a= bout if any media streams were looped, did all of them have to be, and the = consensus on that was no.  Not sure any device would choose to allow l= oopback of telephone-events, but it could I suppose.

I don't think it could reasonably be extended to hack caller id in the w= ay you describe.  

Brian

=

On Nov 12, 2012, at 3:46 PM, "Klatsky, Carl" <Carl_Klatsky@cable.comcast.com> wrote:

Hi,
 
A colleague of mine forwarded me thi= s draft and I had two comments if someone on the distro has input:
 
1)      When setting up the media lo= opback, are there any restrictions on type of codec used?  Could even = telephone-events codec be specified?
2)      Although this draft is c= entered around media, can it be extended to for use as means to test the ca= ller ID set connected to an analog telephony interface?  The approach = outlined in this draft seems to imply no interaction with the end subscribe= r is needed.  If the network operator wanted to silently send a test p= attern to the caller ID set, perhaps this same loopback mechanism can be us= ed with either an additional SDP attribute or some change in the SIP header= itself.  A related application would be to advance the timestamp on t= he caller ID set following Daylight Savings Time transition.  Typicall= y that is not updated until the next inbound call following the DST change.=   A loopback call could signal to the device to update the caller ID s= et but without ringing / alerting the end subscriber without the need to wa= it for an inbound call.
 =
 
Regards,
 
Carl Klatsky=
Comcast
_____= __________________________________________
mmusic mailing list
mmusic@ietf.org
https://= www.ietf.org/mailman/listinfo/mmusic

= --_000_6C6819F46CBD4B40B6C765918F179D52neustarbiz_-- From fandreas@cisco.com Sat Dec 8 07:22: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 0AF1121F8812 for ; Sat, 8 Dec 2012 07:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am2P6HBqfYfa for ; Sat, 8 Dec 2012 07:22:44 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6035421F86FF for ; Sat, 8 Dec 2012 07:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=280; q=dns/txt; s=iport; t=1354980164; x=1356189764; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=KbomSQxef4ShxJXsvBepTpI4oIW0P4n1VrRqdUNg9g8=; b=en4OjVhBCHiTvLxb/aWKBySXQoavm72oDqi1593dfMVEfic7nYtpM1J1 Jntlf3zxD860d7Ti3vEZNPjrw95sFA8AUKc9gHrTFa780rMUvmGJhGxYE s0IXQqcvVq1v679RkJlgQbLRwC2o1/3mBVjGEG/U/xo/+JF1R45c51tA3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUNAHlaw1CtJXG9/2dsb2JhbABEg0eCJ7duBAN8FnOCXUABPBYYAwIBAgFLDQEHAQEFiAgMv0SRAgOIX40mkEiDEQ X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150842014" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 08 Dec 2012 15:22:43 +0000 Received: from rtp-fandreas-8717.cisco.com (rtp-fandreas-8717.cisco.com [10.117.7.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB8FMh30023315; Sat, 8 Dec 2012 15:22:43 GMT Message-ID: <50C35B43.9010001@cisco.com> Date: Sat, 08 Dec 2012 10:22:43 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat Subject: [MMUSIC] Draft Minutes of MMUSIC WG meeting at IETF 85, Atlanta 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, 08 Dec 2012 15:22:45 -0000 Hi The draft minutes of the MMUSIC WG meeting at IETF 85 (Atlanta) have been posted at: http://www.ietf.org/proceedings/85/minutes/minutes-85-mmusic Please review the minutes and let us know of any comments or corrections. Thanks -- Miguel, Paul & Flemming From fluffy@cisco.com Sat Dec 8 14:41: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 C447321F849E for ; Sat, 8 Dec 2012 14:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuPclxQZ4mfv for ; Sat, 8 Dec 2012 14:41:51 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0879121F8480 for ; Sat, 8 Dec 2012 14:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1316; q=dns/txt; s=iport; t=1355006511; x=1356216111; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=edQkXSO4lWbG6uSiLS/CZ5X6mb7giSVhOGWUPrZU7hY=; b=g/gSlZHZ5riM8nzP9Zmfq//y4537AbC6FA80AX7aI1BuvwpPF+pWl3RW ztBbIgkdRfFvCkf3Wo3awZd8VlrcHZnRxPz4ddQty4J9O1RU9L15RUIqJ v0Lvf1VJsAWbF8bkacZXKLLlhk1ayJCdmyKG+LQp9ybqmn823ZFavsdar E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIrBw1CtJXHB/2dsb2JhbABEvmIWc4IgAQQ6UQEqFEInBBuICZ52oEKQIWEDpk6Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150901549" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 08 Dec 2012 22:41:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB8MfoVq016261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Dec 2012 22:41:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 16:41:49 -0600 From: "Cullen Jennings (fluffy)" To: mmusic WG Thread-Topic: SDP work needed for WebRTC stuff Thread-Index: AQHN1ZU1Fc6yOoYKsUCg42zOIJ6ecA== Date: Sat, 8 Dec 2012 22:41:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [MMUSIC] SDP work needed for WebRTC stuff 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, 08 Dec 2012 22:41:52 -0000 I was looking over everything that needs to be completed to finish a fist c= ut of the WebRTC related work. There are a handful of big SDP problems that= are currently blocking some of the WebRTC work and I'd like to figure out = how to make some progress on them.=20 Let me loosely characterize them as=20 1) If we have several video streams, how do theses map up to 1 or more m li= nes.=20 2) if we are doing port multiplexing, what does the SDP look like (the bund= le problem)=20 3) How do we map the RTCWeb track and stream label concepts to identifiers = in SDP 3) SDP for application running over SCTP/DTLS=20 I don't want to speak for all the various chairs but I am under the impress= ion that most of chairs of related groups in W3C and IETF believe these are= issues that need to be resolved primarily in the MMUSIC WG and that they i= mpact both WebRTC and CLUE as well as the general long term use of SDP in S= IP and other protocols.=20 I'd like to get some discussion going on how we can make some progress on t= hese. I don't think we are going to solve these in 20 minutes of discussion= at an IETF meeting so I think we probably need some interim (virtual or fa= ce to face) to sort this out.=20 Thoughts? Cullen =20 From ekr@rtfm.com Sat Dec 8 15:21:58 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 200F621F852C for ; Sat, 8 Dec 2012 15:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN3SihXHCp2G for ; Sat, 8 Dec 2012 15:21:48 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBE8A21F8441 for ; Sat, 8 Dec 2012 15:21:47 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1689468oag.31 for ; Sat, 08 Dec 2012 15:21:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=s/zS9vfKbLrKUylonva5+6ZiPEpEmYR9fOqNFwL57J8=; b=WEuFYLskA3asrFTo3x1TZwmqDdRI9nd6+PtB4AUZHcxhkCFcJ6PZ8lwGp3YVWhRidF P/ld7DQjpS+s98XZYKyIsFl6MrZ20xyyhWffZXQBefX0lyo6rIF7CEZ6dIRmgNBpjnYv XcYbhmOwdVu1yzIrnqillZrlrkj54hQt5piwMoTi0HO4EtKFOwYMK98YmEcAv1YqD5ad HWDRch0ucDUts8yQvkNLaeC+E6ICRzcmS3wZEfi/732dlEjzSPT7idmPsRNvmlImRNnf Zs0spxlhXIwQX357nXfcKG//C/d0Sdq8sOhVULno8VlAHqb04ZS1/SkNi67PBveRZEkI lokw== Received: by 10.182.52.100 with SMTP id s4mr5232473obo.70.1355008906144; Sat, 08 Dec 2012 15:21:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.59.45 with HTTP; Sat, 8 Dec 2012 15:21:06 -0800 (PST) X-Originating-IP: [74.95.2.174] In-Reply-To: References: From: Eric Rescorla Date: Sat, 8 Dec 2012 15:21:06 -0800 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=14dae939996984aaee04d05f98b6 X-Gm-Message-State: ALoCoQlkMicIclQiIVmIV+MNv+stMrys9o+y1Rq2aCTwaTbYB8fhXDo1VKGy2gvvuNjkhQpES9jm Cc: rtcweb@ietf.org, mmusic WG , public-webrtc@w3.org Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 08 Dec 2012 23:21:58 -0000 --14dae939996984aaee04d05f98b6 Content-Type: text/plain; charset=ISO-8859-1 +rtcweb On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) wrote: > > I was looking over everything that needs to be completed to finish a fist > cut of the WebRTC related work. There are a handful of big SDP problems > that are currently blocking some of the WebRTC work and I'd like to figure > out how to make some progress on them. > > Let me loosely characterize them as > > 1) If we have several video streams, how do theses map up to 1 or more m > lines. > > 2) if we are doing port multiplexing, what does the SDP look like (the > bundle problem) > > 3) How do we map the RTCWeb track and stream label concepts to identifiers > in SDP > > 3) SDP for application running over SCTP/DTLS > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term use > of SDP in SIP and other protocols. > > I'd like to get some discussion going on how we can make some progress on > these. I don't think we are going to solve these in 20 minutes of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. > > Thoughts? > Wow, I'm totally confused here. I had assumed that the SDP-related issues were going to be the main topics at the WebRTC/RTCWEB interim in January. Is that not the case? IMO the lack of clarity around how to encode various media configurations into SDP is the major thing blocking progress here. In particular, Firefox has opted not to implement multiplexing of media streams over the same transport flow (whether of the bundle or multiple m-line variety) until the SDP for it is well-defined. The same thing applies to the question of how to map multiple m-lines to incoming MediaStreams/Tracks. We really need to cover these issues in the interim. -Ekr --14dae939996984aaee04d05f98b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +rtcweb

On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:

I was looking over everything that needs to be completed to finish a fist c= ut of the WebRTC related work. There are a handful of big SDP problems that= are currently blocking some of the WebRTC work and I'd like to figure = out how to make some progress on them.

Let me loosely characterize them as

1) If we have several video streams, how do theses map up to 1 or more m li= nes.

2) if we are doing port multiplexing, what does the SDP look like (the bund= le problem)

3) How do we map the RTCWeb track and stream label concepts to identifiers = in SDP

3) SDP for application running over SCTP/DTLS

I don't want to speak for all the various chairs but I am under the imp= ression that most of chairs of related groups in W3C and IETF believe these= are issues that need to be resolved primarily in the MMUSIC WG and that th= ey impact both WebRTC and CLUE as well as the general long term use of SDP = in SIP and other protocols.

I'd like to get some discussion going on how we can make some progress = on these. I don't think we are going to solve these in 20 minutes of di= scussion at an IETF meeting so I think we probably need some interim (virtu= al or face to face) to sort this out.

Thoughts?

Wow, I&= #39;m totally confused here.

I had assumed that the SDP-related issues were going= to be the main
topics at the WebRTC/RTCWEB interim in January. = Is that not the case?

IMO the lack of clarity around how to encode various media=
configurations into SDP is the major thing block= ing progress here. In
particular, Firefox h= as opted not to implement multiplexing of media
streams over the same transport flow (whether of the bundle or
multiple m-line variety) until the SDP for it is well-d= efined. The
same thing applies to the quest= ion of how to map multiple m-lines to
incoming MediaStreams/Tracks.

We really need to cover = these issues in the interim.

-Ekr


--14dae939996984aaee04d05f98b6-- From martin.thomson@gmail.com Sat Dec 8 15:27: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 75CEB21F8540; Sat, 8 Dec 2012 15:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYHHFeLV+zGv; Sat, 8 Dec 2012 15:27:52 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6318521F8531; Sat, 8 Dec 2012 15:27:51 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1342777lbk.31 for ; Sat, 08 Dec 2012 15:27:50 -0800 (PST) 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=m94x4+3KTzJd0a3ODWF4qJxGafW2jHUf7NYIXDUSDf4=; b=TLvDXB0hVgtQegNseZW56IXEXL0Gg5wPIAhH82J2+ayjJrNX2GT711PZuZ1dSjt5AL 6+KBtaKctOOAjUDswoA/9NavTM1hld54RutsDCs9uqQh1VRyo/5YUCSijhmGA6DbAz9C CUzBp6ctDRoyNymLOKsuYs4Pu0/LfnzWAcRUrnY3+0meZRSIA7/YKJdtidHrGaXOdIAj q0qHEDL5BopjZqSG1vPI27Q9OLvm+B3h+tZpNign+SSdg0knd0RxRKW1soszhLoMyiYQ J12xfEIaWoXNe/6FuYZidBUnFeM/i7iaPOlmk6bA2Ks5N/GN97MeLRloqBdJNx6CQvB9 doPw== MIME-Version: 1.0 Received: by 10.112.43.134 with SMTP id w6mr3648814lbl.21.1355009270327; Sat, 08 Dec 2012 15:27:50 -0800 (PST) Received: by 10.112.98.200 with HTTP; Sat, 8 Dec 2012 15:27:50 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Dec 2012 15:27:50 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" , mmusic WG , "public-webrtc@w3.org" Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff 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, 08 Dec 2012 23:27:52 -0000 On 8 December 2012 15:21, Eric Rescorla wrote: > We really need to cover these issues in the interim. +1. I would have said *resolve* rather than cover, but I'm learning not to be too optimistic in these matters. Still, an outcome of one form or other would be nice. From fluffy@cisco.com Sat Dec 8 16:19:49 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 09BF321F8AEA; Sat, 8 Dec 2012 16:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNrqKDp+gij5; Sat, 8 Dec 2012 16:19:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC921F8ADF; Sat, 8 Dec 2012 16:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2402; q=dns/txt; s=iport; t=1355012388; x=1356221988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Nc0Laq5KqESAbVg4cXK4ac8TweDr2vrfHs8pN5/NDdM=; b=ehCulsR7xXhp5FqUFV/2CiC71VFsDpCvMqLADjqg3MG+lhC8UBRVBZvJ 48XQX5XToA/TxjS2y9JQEFBP+R1iGEPFAApUGu6X/lVUFx/wBpXrVcW7H 3Dws0RKGsPxsnJZ1EAo2OTQP63ugQytFB0xb/Pl+jO9Sp+a1rLR2l8CjK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN7Yw1CtJV2c/2dsb2JhbABEvmIWc4IeAQEBAwF5EAIBCA4KCiQyJQIEDgUIiAMGvyyMP4NiYQOIKp4kgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="150877202" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2012 00:19:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB90JkUA014590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Dec 2012 00:19:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sat, 8 Dec 2012 18:19:46 -0600 From: "Cullen Jennings (fluffy)" To: Eric Rescorla Thread-Topic: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1ZrLc7vRdGyb+kCXOHgISQGSp5gP/yeA Date: Sun, 9 Dec 2012 00:19:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.167] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , mmusic WG , "" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 09 Dec 2012 00:19:49 -0000 On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: > +rtcweb >=20 > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) wrote: >=20 > I was looking over everything that needs to be completed to finish a fist= cut of the WebRTC related work. There are a handful of big SDP problems th= at are currently blocking some of the WebRTC work and I'd like to figure ou= t how to make some progress on them. >=20 > Let me loosely characterize them as >=20 > 1) If we have several video streams, how do theses map up to 1 or more m = lines. >=20 > 2) if we are doing port multiplexing, what does the SDP look like (the bu= ndle problem) >=20 > 3) How do we map the RTCWeb track and stream label concepts to identifier= s in SDP >=20 > 3) SDP for application running over SCTP/DTLS >=20 > I don't want to speak for all the various chairs but I am under the impre= ssion that most of chairs of related groups in W3C and IETF believe these a= re issues that need to be resolved primarily in the MMUSIC WG and that they= impact both WebRTC and CLUE as well as the general long term use of SDP in= SIP and other protocols. >=20 > I'd like to get some discussion going on how we can make some progress on= these. I don't think we are going to solve these in 20 minutes of discussi= on at an IETF meeting so I think we probably need some interim (virtual or = face to face) to sort this out. >=20 > Thoughts? >=20 > Wow, I'm totally confused here. >=20 > I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case? So far the interim was only talking about being a WebRTC & RTCWeb so this S= DP stuff would be out of scope. Perhaps it would be better to have some of = the time for mmusic topics?=20 >=20 > IMO the lack of clarity around how to encode various media > configurations into SDP is the major thing blocking progress here. In > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or > multiple m-line variety) until the SDP for it is well-defined. The > same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks. >=20 > We really need to cover these issues in the interim. >=20 > -Ekr >=20 >=20 From ron.even.tlv@gmail.com Sat Dec 8 23:10: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 9D62921F8BE5; Sat, 8 Dec 2012 23:10:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyIn7-BdKjVF; Sat, 8 Dec 2012 23:10:45 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACC8C21F8BE1; Sat, 8 Dec 2012 23:10:45 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1819805oag.31 for ; Sat, 08 Dec 2012 23:10:45 -0800 (PST) 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=qxohVwu0zYob980fFRcZsiOy+igW1a22KNJmXSYXTDc=; b=QVYtXI1ofAXfYHaiwi4GCd9rjJUgWfqbW+fBaPHDIlpCeXmphD5tuyM4tiG4BKo1d3 0d5aRLLtyq3htWy1E2kCneEBsLcffrKznlAhDKuFYe0j+NT27jAxZ9FvYJ1vOZVvU9tM mEvkNK59NkmK22eIdRWJ8vZtNyfSeSvfWnwMXumTj8aj40OsYIXttZvRD5LjfMkJT8cA 39s/65jrATno2sFKjy1M9vgkxKLFVNBYt5O91y21VV9QPzF93bKO+Qw/Mg1SYWhCVmHW ICzZ85PcUD3bGSe1IwuV96OaFC2tueJSz4/DmrCiofDu4fBW+c9l3qU6j8pfYe4641ZE r8TQ== MIME-Version: 1.0 Received: by 10.182.95.133 with SMTP id dk5mr5908866obb.14.1355037045308; Sat, 08 Dec 2012 23:10:45 -0800 (PST) Received: by 10.76.171.103 with HTTP; Sat, 8 Dec 2012 23:10:45 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Dec 2012 09:10:45 +0200 Message-ID: From: Ron Even To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=14dae93b62a2be3d2d04d0662536 Cc: "" , mmusic WG , "" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 09 Dec 2012 07:10:46 -0000 --14dae93b62a2be3d2d04d0662536 Content-Type: text/plain; charset=ISO-8859-1 Hi Cullen, I agree that we need to put more effort into this work and am willing to be part of it. You mentioned CLUE and we have the mapping of RTP streams to CLUE media captures as a topic, discussed in CLUE. We started some work during the Atlanta meeting and it is supposed to be discussed on the RAI mailing list since it involves multiple RAI WGs but this is just the formality Roni Even On Sunday, December 9, 2012, Cullen Jennings (fluffy) wrote: > > On Dec 8, 2012, at 4:21 PM, Eric Rescorla > > wrote: > > > +rtcweb > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com > wrote: > > > > I was looking over everything that needs to be completed to finish a > fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'd like > to figure out how to make some progress on them. > > > > Let me loosely characterize them as > > > > 1) If we have several video streams, how do theses map up to 1 or more m > lines. > > > > 2) if we are doing port multiplexing, what does the SDP look like (the > bundle problem) > > > > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP > > > > 3) SDP for application running over SCTP/DTLS > > > > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term use > of SDP in SIP and other protocols. > > > > I'd like to get some discussion going on how we can make some progress > on these. I don't think we are going to solve these in 20 minutes of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. > > > > Thoughts? > > > > Wow, I'm totally confused here. > > > > I had assumed that the SDP-related issues were going to be the main > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > So far the interim was only talking about being a WebRTC & RTCWeb so this > SDP stuff would be out of scope. Perhaps it would be better to have some of > the time for mmusic topics? > > > > > > IMO the lack of clarity around how to encode various media > > configurations into SDP is the major thing blocking progress here. In > > particular, Firefox has opted not to implement multiplexing of media > > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. The > > same thing applies to the question of how to map multiple m-lines to > > incoming MediaStreams/Tracks. > > > > We really need to cover these issues in the interim. > > > > -Ekr > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --14dae93b62a2be3d2d04d0662536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cullen,
I agree that we need to put more effort into this work and a= m willing to be part of it.
You mentioned CLUE and we have the ma= pping of RTP streams to CLUE media captures as a topic, discussed in CLUE.<= span>
=A0We started some work during the Atlanta meeting and it is supposed = to be discussed on the RAI mailing list since it involves multiple RAI WGs = but this is just the formality
Roni Even

On Sunday, Decemb= er 9, 2012, Cullen Jennings (fluffy) wrote:

On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:

> +rtcweb
>
> On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> I was looking over everything that needs to be completed to finish a f= ist cut of the WebRTC related work. There are a handful of big SDP problems= that are currently blocking some of the WebRTC work and I'd like to fi= gure out how to make some progress on them.
>
> Let me loosely characterize them as
>
> 1) If we have several video streams, how do theses map up to 1 or more= m lines.
>
> 2) if we are doing port multiplexing, what does the SDP look like (the= bundle problem)
>
> 3) How do we map the RTCWeb track and stream label concepts to identif= iers in SDP
>
> 3) SDP for application running over SCTP/DTLS
>
> I don't want to speak for all the various chairs but I am under th= e impression that most of chairs of related groups in W3C and IETF believe = these are issues that need to be resolved primarily in the MMUSIC WG and th= at they impact both WebRTC and CLUE as well as the general long term use of= SDP in SIP and other protocols.
>
> I'd like to get some discussion going on how we can make some prog= ress on these. I don't think we are going to solve these in 20 minutes = of discussion at an IETF meeting so I think we probably need some interim (= virtual or face to face) to sort this out.
>
> Thoughts?
>
> Wow, I'm totally confused here.
>
> I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case?<= br>
So far the interim was only talking about being a WebRTC & RTCWeb so th= is SDP stuff would be out of scope. Perhaps it would be better to have some= of the time for mmusic topics?


>
> IMO the lack of clarity around how to encode various media
> configurations into SDP is the major thing blocking progress here. In<= br> > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or
> multiple m-line variety) until the SDP for it is well-defined. The
> same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks.
>
> We really need to cover these issues in the interim.
>
> -Ekr
>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--14dae93b62a2be3d2d04d0662536-- From harald@alvestrand.no Sun Dec 9 23:57:47 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 2254F21F8F4A for ; Sun, 9 Dec 2012 23:57:47 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hamDDWetdjDw for ; Sun, 9 Dec 2012 23:57:46 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7648521F8E7A for ; Sun, 9 Dec 2012 23:57:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1507939E0FD for ; Mon, 10 Dec 2012 08:57:44 +0100 (CET) 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 5cMtKBZ08CPy for ; Mon, 10 Dec 2012 08:57:43 +0100 (CET) Received: from [172.30.42.102] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 44CD739E01E for ; Mon, 10 Dec 2012 08:57:43 +0100 (CET) Message-ID: <50C595F6.9050603@alvestrand.no> Date: Mon, 10 Dec 2012 08:57:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 10 Dec 2012 07:57:47 -0000 I agree that these are the important topics that need to be settled, and agree that it's urgent to settle them. I'm willing to spend time going to interims (virtual or physical, although I have a preference for virtual) if there's any sign of them being useful to progress. I would like to see us move on these issues before the RTCWEB interim in early February, if possible. On 12/08/2012 11:41 PM, Cullen Jennings (fluffy) wrote: > I was looking over everything that needs to be completed to finish a fist cut of the WebRTC related work. There are a handful of big SDP problems that are currently blocking some of the WebRTC work and I'd like to figure out how to make some progress on them. > > Let me loosely characterize them as > > 1) If we have several video streams, how do theses map up to 1 or more m lines. > > 2) if we are doing port multiplexing, what does the SDP look like (the bundle problem) > > 3) How do we map the RTCWeb track and stream label concepts to identifiers in SDP > > 3) SDP for application running over SCTP/DTLS > > I don't want to speak for all the various chairs but I am under the impression that most of chairs of related groups in W3C and IETF believe these are issues that need to be resolved primarily in the MMUSIC WG and that they impact both WebRTC and CLUE as well as the general long term use of SDP in SIP and other protocols. > > I'd like to get some discussion going on how we can make some progress on these. I don't think we are going to solve these in 20 minutes of discussion at an IETF meeting so I think we probably need some interim (virtual or face to face) to sort this out. > > Thoughts? > > Cullen > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From bernard_aboba@hotmail.com Mon Dec 10 00:31: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 CF26621F861D for ; Mon, 10 Dec 2012 00:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.53 X-Spam-Level: X-Spam-Status: No, score=-101.53 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksV0s9tu8kAe for ; Mon, 10 Dec 2012 00:31:51 -0800 (PST) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by ietfa.amsl.com (Postfix) with ESMTP id 435EC21F8496 for ; Mon, 10 Dec 2012 00:31:51 -0800 (PST) Received: from BLU403-EAS303 ([65.55.111.73]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Dec 2012 00:31:50 -0800 X-Originating-IP: [24.16.96.166] X-EIP: [EOHRQc/djhsshtIAFZ+VKcRlTtvaXmbQ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <50C595F6.9050603@alvestrand.no> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <50C595F6.9050603@alvestrand.no> Date: Mon, 10 Dec 2012 00:31:56 -0800 To: Harald Alvestrand X-OriginalArrivalTime: 10 Dec 2012 08:31:50.0222 (UTC) FILETIME=[CCCD7EE0:01CDD6B0] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 10 Dec 2012 08:31:51 -0000 I agree that accelerated progress in MMUSIC should be a goal. If there are e= nough cycles to spare, monthly virtual interims might do the trick. This is= a painful way to go about it, but it has worked before (MARTINI) and concen= trated pain now is preferable to years of chronic aches. On Dec 9, 2012, at 23:57, "Harald Alvestrand" wrote: > I agree that these are the important topics that need to be settled, and a= gree that it's urgent to settle them. > I'm willing to spend time going to interims (virtual or physical, although= I have a preference for is virtual) if there's any sign of them being usefu= l to progress. >=20 > I would like to see us move on these issues before the RTCWEB interim in e= arly February, if possible. >=20 > On 12/08/2012 11:41 PM, Cullen Jennings (fluffy) wrote: >> I was looking over everything that needs to be completed to finish a fist= cut of the WebRTC related work. There are a handful of big SDP problems tha= t are currently blocking some of the WebRTC work and I'd like to figure out h= ow to make some progress on them. >>=20 >> Let me loosely characterize them as >>=20 >> 1) If we have several video streams, how do theses map up to 1 or more m l= ines. >>=20 >> 2) if we are doing port multiplexing, what does the SDP look like (the bu= ndle problem) >>=20 >> 3) How do we map the RTCWeb track and stream label concepts to identifier= s in SDP >>=20 >> 3) SDP for application running over SCTP/DTLS >>=20 >> I don't want to speak for all the various chairs but I am under the impre= ssion that most of chairs of related groups in W3C and IETF believe these ar= e issues that need to be resolved primarily in the MMUSIC WG and that they i= mpact both WebRTC and CLUE as well as the general long term use of SDP in SI= P and other protocols. >>=20 >> I'd like to get some discussion going on how we can make some progress on= these. I don't think we are going to solve these in 20 minutes of discussio= n at an IETF meeting so I think we probably need some interim (virtual or fa= ce to face) to sort this out. >>=20 >> Thoughts? >>=20 >> Cullen >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From keith.drage@alcatel-lucent.com Mon Dec 10 05:16: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 BD6B821F8D23; Mon, 10 Dec 2012 05:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.116 X-Spam-Level: X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L-mWsUbBy37; Mon, 10 Dec 2012 05:16:42 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCE21F8E92; Mon, 10 Dec 2012 05:16:41 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBADCWWx013741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Dec 2012 14:16:34 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 10 Dec 2012 14:16:27 +0100 From: "DRAGE, Keith (Keith)" To: "Cullen Jennings (fluffy)" , Eric Rescorla Date: Mon, 10 Dec 2012 14:16:27 +0100 Thread-Topic: [MMUSIC] SDP work needed for WebRTC stuff Thread-Index: AQHN1ZrLc7vRdGyb+kCXOHgISQGSp5gP/yeAgAIFimA= Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "" , mmusic WG , "" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 10 Dec 2012 13:16:42 -0000 This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well. And I don't see how you can suddenly extend the interim of RTCWEB to the sc= ope of other working groups, without even having a discussion with all the = relevant chairs. I'd further note that Jonathan Lennox has an action (with the support of qu= ite a number of other people) to produce an internet draft on trying to sor= t out the terminology concents that exist within RTP at the moment. This wo= uld be the basis for progressing a number of these issues. That would proba= bly have to be an RAI wide draft. There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed. Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Cullen Jennings (fluffy) > Sent: 09 December 2012 00:20 > To: Eric Rescorla > Cc: ; mmusic WG; > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >=20 >=20 > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: >=20 > > +rtcweb > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > wrote: > > > > I was looking over everything that needs to be completed to finish a > fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'd like > to figure out how to make some progress on them. > > > > Let me loosely characterize them as > > > > 1) If we have several video streams, how do theses map up to 1 or more = m > lines. > > > > 2) if we are doing port multiplexing, what does the SDP look like (the > bundle problem) > > > > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP > > > > 3) SDP for application running over SCTP/DTLS > > > > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term us= e > of SDP in SIP and other protocols. > > > > I'd like to get some discussion going on how we can make some progress > on these. I don't think we are going to solve these in 20 minutes of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. > > > > Thoughts? > > > > Wow, I'm totally confused here. > > > > I had assumed that the SDP-related issues were going to be the main > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? >=20 > So far the interim was only talking about being a WebRTC & RTCWeb so this > SDP stuff would be out of scope. Perhaps it would be better to have some > of the time for mmusic topics? >=20 >=20 > > > > IMO the lack of clarity around how to encode various media > > configurations into SDP is the major thing blocking progress here. In > > particular, Firefox has opted not to implement multiplexing of media > > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. The > > same thing applies to the question of how to map multiple m-lines to > > incoming MediaStreams/Tracks. > > > > We really need to cover these issues in the interim. > > > > -Ekr > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From ted.ietf@gmail.com Mon Dec 10 09:36: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 E5C4621F857C; Mon, 10 Dec 2012 09:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjH-XKqeZ24N; Mon, 10 Dec 2012 09:36:28 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89E9F21F856D; Mon, 10 Dec 2012 09:36:28 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3018030vcb.31 for ; Mon, 10 Dec 2012 09:36:28 -0800 (PST) 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=Foi2RanzwiqbE5WYY2GLyDI0tPPDtH5H9TNrQoRLccY=; b=yqa4qZAWc6Ad7bSYFMVqrgX0Cr3KqcNk6smYVtKsXxK7umlUIP8a5qtuia5lfQbKfT 3UOOozUW1mGE5LXmwx96DOllwdB6zhsFYl8ROMztRDUrLCyaXJG/GTdLdUMOBXzL/fO+ CA815yCQ9jFazdK+S5OV31Euyzkb5QeDGV+qFcbiYkfFuBhlr/X6O772zWuAAlttamfW Epxn6xaRCC5BkThdH1RmXtOtyU4WTF+4EZYYYAc0n+H6aGeR46D3rU+f9pVHiKjqcKSN 4a3u3WbYmngdOSkSxH+PzKW00smtb6uABGc2uu06iQNZwmTmEW36Q+g5JUfPB5pjuRcL +CNg== MIME-Version: 1.0 Received: by 10.52.36.167 with SMTP id r7mr8190625vdj.108.1355160987960; Mon, 10 Dec 2012 09:36:27 -0800 (PST) Received: by 10.58.164.35 with HTTP; Mon, 10 Dec 2012 09:36:27 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 09:36:27 -0800 Message-ID: From: Ted Hardie To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf30780ca44d069a04d08301c7 Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 10 Dec 2012 17:36:30 -0000 --20cf30780ca44d069a04d08301c7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > This is not just MMUSIC, there are bits of AVTCORE and AVTEXT > responsibility in there as well. > > And I don't see how you can suddenly extend the interim of RTCWEB to the > scope of other working groups, without even having a discussion with all > the relevant chairs. > > That's not how I read the overall sentiment--people are simply saying that they need this work done and are willing to put in the effort to get it done. It would, in fact, be ideal if some of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what is decided. Put another way, I take it as encouragement to MMUSIC folks that they would find a January virtual interim very well received/attended. Ted > I'd further note that Jonathan Lennox has an action (with the support of > quite a number of other people) to produce an internet draft on trying to > sort out the terminology concents that exist within RTP at the moment. This > would be the basis for progressing a number of these issues. That would > probably have to be an RAI wide draft. > > There has been some progress on this - maybe Jonathan can report on where > this now is. I know he was waiting on volunteers for some of the sections > and on input from others where volunteers already existed. > > Keith > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > > Of Cullen Jennings (fluffy) > > Sent: 09 December 2012 00:20 > > To: Eric Rescorla > > Cc: ; mmusic WG; > > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff > > > > > > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: > > > > > +rtcweb > > > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > > wrote: > > > > > > I was looking over everything that needs to be completed to finish a > > fist cut of the WebRTC related work. There are a handful of big SDP > > problems that are currently blocking some of the WebRTC work and I'd like > > to figure out how to make some progress on them. > > > > > > Let me loosely characterize them as > > > > > > 1) If we have several video streams, how do theses map up to 1 or more > m > > lines. > > > > > > 2) if we are doing port multiplexing, what does the SDP look like (the > > bundle problem) > > > > > > 3) How do we map the RTCWeb track and stream label concepts to > > identifiers in SDP > > > > > > 3) SDP for application running over SCTP/DTLS > > > > > > I don't want to speak for all the various chairs but I am under the > > impression that most of chairs of related groups in W3C and IETF believe > > these are issues that need to be resolved primarily in the MMUSIC WG and > > that they impact both WebRTC and CLUE as well as the general long term > use > > of SDP in SIP and other protocols. > > > > > > I'd like to get some discussion going on how we can make some progress > > on these. I don't think we are going to solve these in 20 minutes of > > discussion at an IETF meeting so I think we probably need some interim > > (virtual or face to face) to sort this out. > > > > > > Thoughts? > > > > > > Wow, I'm totally confused here. > > > > > > I had assumed that the SDP-related issues were going to be the main > > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > > > So far the interim was only talking about being a WebRTC & RTCWeb so this > > SDP stuff would be out of scope. Perhaps it would be better to have some > > of the time for mmusic topics? > > > > > > > > > > IMO the lack of clarity around how to encode various media > > > configurations into SDP is the major thing blocking progress here. In > > > particular, Firefox has opted not to implement multiplexing of media > > > streams over the same transport flow (whether of the bundle or > > > multiple m-line variety) until the SDP for it is well-defined. The > > > same thing applies to the question of how to map multiple m-lines to > > > incoming MediaStreams/Tracks. > > > > > > We really need to cover these issues in the interim. > > > > > > -Ekr > > > > > > > > > > _______________________________________________ > > 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 > --20cf30780ca44d069a04d08301c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <= ;keith.= drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to th= e scope of other working groups, without even having a discussion with all = the relevant chairs.


That's not how I read the overall sentiment--= people are simply saying that they need this work done and are willing to p= ut in the effort to get it done.=A0 It would, in fact, be ideal if some of = the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, as we = can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they w= ould find a January virtual interim very well received/attended.

Ted=

=A0
I'd further note that Jonathan Lennox has an action (with the support o= f quite a number of other people) to produce an internet draft on trying to= sort out the terminology concents that exist within RTP at the moment. Thi= s would be the basis for progressing a number of these issues. That would p= robably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.o= rg [mailto:mmusic-bounces@ie= tf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ietf.org>; mm= usic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco.com> wrote= :
> >
> > I was looking over everything that needs to be completed to finis= h a
> fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'= ;d like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or= more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like= (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am und= er the
> impression that most of chairs of related groups in W3C and IETF belie= ve
> these are issues that need to be resolved primarily in the MMUSIC WG a= nd
> that they impact both WebRTC and CLUE as well as the general long term= use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some= progress
> on these. I don't think we are going to solve these in 20 minutes = of
> discussion at an IETF meeting so I think we probably need some interim=
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the ma= in
> > topics at the WebRTC/RTCWEB interim in January. Is that not the c= ase?
>
> So far the interim was only talking about being a WebRTC & RTCWeb = so this
> SDP stuff would be out of scope. Perhaps it would be better to have so= me
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here= . In
> > particular, Firefox has opted not to implement multiplexing of me= dia
> > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. Th= e
> > same thing applies to the question of how to map multiple m-lines= to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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

--20cf30780ca44d069a04d08301c7-- From fluffy@iii.ca Mon Dec 10 11:29: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 3AC8B21F84B9; Mon, 10 Dec 2012 11:29:02 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUTWoriF6D3h; Mon, 10 Dec 2012 11:29:01 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7BAF21F84B5; Mon, 10 Dec 2012 11:29:01 -0800 (PST) Received: from dhcp-171-68-20-206.cisco.com (unknown [171.68.20.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B5F5522E253; Mon, 10 Dec 2012 14:28:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Cullen Jennings In-Reply-To: Date: Mon, 10 Dec 2012 11:31:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <410943E1-0F5F-4A7E-B7C1-4E418E6C4E48@iii.ca> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1499) Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 10 Dec 2012 19:29:02 -0000 On Dec 10, 2012, at 5:16 , "DRAGE, Keith (Keith)" = wrote: > This is not just MMUSIC, there are bits of AVTCORE and AVTEXT = responsibility in there as well. can you add a bit on what is needed in these WG just so I can keep track = of it all >=20 > And I don't see how you can suddenly extend the interim of RTCWEB to = the scope of other working groups, without even having a discussion with = all the relevant chairs. I did not mean to do any such thing - obviously the MMUSIC WG would need = to decide what to how it was going to do the work. All I was trying to = say is there are some things that I think needs to be done in MMUSIC and = I view it as out of scope for rtcweb. This clearly came as a surprise to = some people who thought that was the main thing the interim meeting was = going to be about. As an individual contributor for to the MMUSIC wg, I = think that mmusic needs to figure out a substantial block of face to = face time to sort out these SDP issues. I look forward to proposals on = how to do that.=20 From ekr@rtfm.com Mon Dec 10 17:18: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 E72E621F8716 for ; Mon, 10 Dec 2012 17:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWGSbW1H8TOz for ; Mon, 10 Dec 2012 17:18:58 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8D5821F870C for ; Mon, 10 Dec 2012 17:18:58 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3482953oag.31 for ; Mon, 10 Dec 2012 17:18:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Jz93l6XxDHlhAAovN4Rf7KRozbwkq6pgqhkhezfmZGc=; b=MTtJo1DLFGcipRP/PGaw6fde/Ev7p55OIhJvDtHu9pdmK6O5hH7OAh0pWIpOmxt/77 +A6MqmuHA0uCMPO02Iv/kWLgsRC1DHnGwOF3/bESYResjgdeP5tWo/epNFGm2g+LXcHH +LRmTzJZmBO3p7GDpBClDu92I7N45ZUMWz7pr+Y/UFwS4WAOkjGMaPq73w14w1LBgwC8 NjmhfZ0WoExqm/RqfHOI7W2XWUMhDIrMogFsBtEd674RybpbwedzGim1GEyJs2tfYaaP FwDTokSLNkGAwyZYTbMhxNs1e8XIfs8f7zMDjnF3mfyn3ggKAapxaheC2ODJjOJWu+jL CTIA== Received: by 10.182.164.103 with SMTP id yp7mr8383725obb.74.1355188738242; Mon, 10 Dec 2012 17:18:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.59.45 with HTTP; Mon, 10 Dec 2012 17:18:17 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 10 Dec 2012 17:18:17 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=e89a8f64355658ba5404d0897766 X-Gm-Message-State: ALoCoQnkWo6+vxESY5S2Lw8KsPVeJ8hRA6w9kZpxsbHB3HutnQ7zueR3nUlxPClj3EAXTOjUfGGO Cc: "Cullen Jennings \(fluffy\)" , "DRAGE, Keith \(Keith\)" , "" , mmusic WG , "" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 11 Dec 2012 01:19:00 -0000 --e89a8f64355658ba5404d0897766 Content-Type: text/plain; charset=ISO-8859-1 I feel like the priorities here are kind of confused. It seems to me that the purpose of having a physical interim is to resolve issues that are hard to resolve on the list or teleconferences. As I mentioned earlier, the SDP issues are the most important to resolve now and have also proven to be among the most intractable. How does it make sense to try to resolve those at a "virtual" interim while having people fly to a "physical" interim for three days? I would strongly encourage the chairs to figure out how to have at least one of the days of this interim devoted solely to resolving the SDP issues (really, my preference would be to take these issues one at a time and do nothing else until they are resolved!). I'm not expert enough at the RAI WG mechanics to know what's required, so perhaps this requires making this also an MMUSIC interim or a mini-RAI interim, but if so that's what we should do, even if it means we need to reschedule or move it. Best, -Ekr On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie wrote: > On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > >> This is not just MMUSIC, there are bits of AVTCORE and AVTEXT >> responsibility in there as well. >> >> And I don't see how you can suddenly extend the interim of RTCWEB to the >> scope of other working groups, without even having a discussion with all >> the relevant chairs. >> >> > That's not how I read the overall sentiment--people are simply saying that > they need this work done and are willing to put in the effort to get it > done. It would, in fact, be ideal if some of the MMUSIC questions were > resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what > is decided. > > Put another way, I take it as encouragement to MMUSIC folks that they > would find a January virtual interim very well received/attended. > > Ted > > > >> I'd further note that Jonathan Lennox has an action (with the support of >> quite a number of other people) to produce an internet draft on trying to >> sort out the terminology concents that exist within RTP at the moment. This >> would be the basis for progressing a number of these issues. That would >> probably have to be an RAI wide draft. >> >> There has been some progress on this - maybe Jonathan can report on where >> this now is. I know he was waiting on volunteers for some of the sections >> and on input from others where volunteers already existed. >> >> Keith >> >> > -----Original Message----- >> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf >> > Of Cullen Jennings (fluffy) >> > Sent: 09 December 2012 00:20 >> > To: Eric Rescorla >> > Cc: ; mmusic WG; >> > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >> > >> > >> > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: >> > >> > > +rtcweb >> > > >> > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) >> > wrote: >> > > >> > > I was looking over everything that needs to be completed to finish a >> > fist cut of the WebRTC related work. There are a handful of big SDP >> > problems that are currently blocking some of the WebRTC work and I'd >> like >> > to figure out how to make some progress on them. >> > > >> > > Let me loosely characterize them as >> > > >> > > 1) If we have several video streams, how do theses map up to 1 or >> more m >> > lines. >> > > >> > > 2) if we are doing port multiplexing, what does the SDP look like (the >> > bundle problem) >> > > >> > > 3) How do we map the RTCWeb track and stream label concepts to >> > identifiers in SDP >> > > >> > > 3) SDP for application running over SCTP/DTLS >> > > >> > > I don't want to speak for all the various chairs but I am under the >> > impression that most of chairs of related groups in W3C and IETF believe >> > these are issues that need to be resolved primarily in the MMUSIC WG and >> > that they impact both WebRTC and CLUE as well as the general long term >> use >> > of SDP in SIP and other protocols. >> > > >> > > I'd like to get some discussion going on how we can make some progress >> > on these. I don't think we are going to solve these in 20 minutes of >> > discussion at an IETF meeting so I think we probably need some interim >> > (virtual or face to face) to sort this out. >> > > >> > > Thoughts? >> > > >> > > Wow, I'm totally confused here. >> > > >> > > I had assumed that the SDP-related issues were going to be the main >> > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? >> > >> > So far the interim was only talking about being a WebRTC & RTCWeb so >> this >> > SDP stuff would be out of scope. Perhaps it would be better to have some >> > of the time for mmusic topics? >> > >> > >> > > >> > > IMO the lack of clarity around how to encode various media >> > > configurations into SDP is the major thing blocking progress here. In >> > > particular, Firefox has opted not to implement multiplexing of media >> > > streams over the same transport flow (whether of the bundle or >> > > multiple m-line variety) until the SDP for it is well-defined. The >> > > same thing applies to the question of how to map multiple m-lines to >> > > incoming MediaStreams/Tracks. >> > > >> > > We really need to cover these issues in the interim. >> > > >> > > -Ekr >> > > >> > > >> > >> > _______________________________________________ >> > 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 >> > > --e89a8f64355658ba5404d0897766 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I feel like the priorities here are kind of confused.

It= seems to me that the purpose of having a physical interim is to resolve
issues that are hard to resolve on the list or teleconferences. As = I mentioned
earlier, the SDP issues are the most important to resolve now and have=
also proven to be among the most intractable. How does it make s= ense
to try to resolve those at a "virtual" interim whi= le having people fly
to a "physical" interim for three days?

=
I would strongly encourage the chairs to figure out how to have at lea= st
one of the days of this interim devoted solely to resolving th= e SDP=A0
issues (really, my preference would be to take these issues one at
a time and do nothing else until they are resolved!). I'm not ex= pert
enough at the RAI WG mechanics to know what's required, = so perhaps
this requires making this also an MMUSIC interim or a mini-RAI interim= ,
but if so that's what we should do, even if it means we nee= d to reschedule
or move it.

Best,
-Ekr

On Mon, Dec 1= 0, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:<= br>
On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <k= eith.drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to th= e scope of other working groups, without even having a discussion with all = the relevant chairs.


That's not how I read the overall senti= ment--people are simply saying that they need this work done and are willin= g to put in the effort to get it done.=A0 It would, in fact, be ideal if so= me of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, = as we can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they w= ould find a January virtual interim very well received/attended.

Ted

=A0
I'd further note that Jonathan Lennox has an action (with the support o= f quite a number of other people) to produce an internet draft on trying to= sort out the terminology concents that exist within RTP at the moment. Thi= s would be the basis for progressing a number of these issues. That would p= robably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmu= sic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ie= tf.org>; mmusic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco= .com> wrote:
> >
> > I was looking over everything that needs to be completed to finis= h a
> fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'= ;d like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or= more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like= (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am und= er the
> impression that most of chairs of related groups in W3C and IETF belie= ve
> these are issues that need to be resolved primarily in the MMUSIC WG a= nd
> that they impact both WebRTC and CLUE as well as the general long term= use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some= progress
> on these. I don't think we are going to solve these in 20 minutes = of
> discussion at an IETF meeting so I think we probably need some interim=
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the ma= in
> > topics at the WebRTC/RTCWEB interim in January. Is that not the c= ase?
>
> So far the interim was only talking about being a WebRTC & RTCWeb = so this
> SDP stuff would be out of scope. Perhaps it would be better to have so= me
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here= . In
> > particular, Firefox has opted not to implement multiplexing of me= dia
> > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. Th= e
> > same thing applies to the question of how to map multiple m-lines= to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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


--e89a8f64355658ba5404d0897766-- From martin.thomson@gmail.com Mon Dec 10 17:29: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 BFDE121F8713; Mon, 10 Dec 2012 17:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4Bm2kmR5eXb; Mon, 10 Dec 2012 17:29:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEEEF21F871D; Mon, 10 Dec 2012 17:29:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2721943lah.31 for ; Mon, 10 Dec 2012 17:29:26 -0800 (PST) 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=sJMdp6+ksJ7rH4SC7PlUk2PwFObJNNWZkptMdZoT9ls=; b=nA0/S/Hc7f1owTI6hR/MKWUr11McHpqEWICK4cGYS8MtzAwX2WbJmpMvbW5yZiiKm2 kt9V8yZtwjEIMJchfXlQowoPn7oeTuvVOdBgxL6VCqwmI6alwPABYVN7R+Ioo58RFwPM PTf+EVAlXdkhtAJmkGXvMheXoSJNmCnLFe62LAP98NvVWyDRTjwjqrQM4o+F54I3Ye27 fxnqoceR6+5GIJIb4xgbnxONuMPuQzzzJ9cA5M2K81FhG5ujw4OXOpYfbavXHIdvNsgR dw7mDJaBrKT/YqMBgSc3k3EGuQ8Bqr7tEjgqOfapssVpl/Fe25FYLt75Tg8OpL+DXnrX 6mlQ== MIME-Version: 1.0 Received: by 10.152.106.212 with SMTP id gw20mr15662525lab.8.1355189366774; Mon, 10 Dec 2012 17:29:26 -0800 (PST) Received: by 10.112.98.200 with HTTP; Mon, 10 Dec 2012 17:29:26 -0800 (PST) Received: by 10.112.98.200 with HTTP; Mon, 10 Dec 2012 17:29:26 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Dec 2012 17:29:26 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d0420a695cf5d7e04d0899c81 Cc: "Cullen Jennings \(fluffy\)" , mmusic@ietf.org, "DRAGE, Keith \(Keith\)" , "<, rtcweb@ietf.org>, " , "<, public-webrtc@w3.org>, " Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 11 Dec 2012 01:29:29 -0000 --f46d0420a695cf5d7e04d0899c81 Content-Type: text/plain; charset=UTF-8 If there is a way to make this happen, that would be good. If not, then I think the only realistic option available to rtcweb would be to drop bundle, etc... That wouldn't be popular. On Dec 10, 2012 5:19 PM, "Eric Rescorla" wrote: > I feel like the priorities here are kind of confused. > > It seems to me that the purpose of having a physical interim is to resolve > issues that are hard to resolve on the list or teleconferences. As I > mentioned > earlier, the SDP issues are the most important to resolve now and have > also proven to be among the most intractable. How does it make sense > to try to resolve those at a "virtual" interim while having people fly > to a "physical" interim for three days? > > I would strongly encourage the chairs to figure out how to have at least > one of the days of this interim devoted solely to resolving the SDP > issues (really, my preference would be to take these issues one at > a time and do nothing else until they are resolved!). I'm not expert > enough at the RAI WG mechanics to know what's required, so perhaps > this requires making this also an MMUSIC interim or a mini-RAI interim, > but if so that's what we should do, even if it means we need to reschedule > or move it. > > Best, > -Ekr > > On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie wrote: > >> On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) < >> keith.drage@alcatel-lucent.com> wrote: >> >>> This is not just MMUSIC, there are bits of AVTCORE and AVTEXT >>> responsibility in there as well. >>> >>> And I don't see how you can suddenly extend the interim of RTCWEB to the >>> scope of other working groups, without even having a discussion with all >>> the relevant chairs. >>> >>> >> That's not how I read the overall sentiment--people are simply saying >> that they need this work done and are willing to put in the effort to get >> it done. It would, in fact, be ideal if some of the MMUSIC questions were >> resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what >> is decided. >> >> Put another way, I take it as encouragement to MMUSIC folks that they >> would find a January virtual interim very well received/attended. >> >> Ted >> >> >> >>> I'd further note that Jonathan Lennox has an action (with the support of >>> quite a number of other people) to produce an internet draft on trying to >>> sort out the terminology concents that exist within RTP at the moment. This >>> would be the basis for progressing a number of these issues. That would >>> probably have to be an RAI wide draft. >>> >>> There has been some progress on this - maybe Jonathan can report on >>> where this now is. I know he was waiting on volunteers for some of the >>> sections and on input from others where volunteers already existed. >>> >>> Keith >>> >>> > -----Original Message----- >>> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>> Behalf >>> > Of Cullen Jennings (fluffy) >>> > Sent: 09 December 2012 00:20 >>> > To: Eric Rescorla >>> > Cc: ; mmusic WG; >>> > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff >>> > >>> > >>> > On Dec 8, 2012, at 4:21 PM, Eric Rescorla wrote: >>> > >>> > > +rtcweb >>> > > >>> > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) >>> > wrote: >>> > > >>> > > I was looking over everything that needs to be completed to finish a >>> > fist cut of the WebRTC related work. There are a handful of big SDP >>> > problems that are currently blocking some of the WebRTC work and I'd >>> like >>> > to figure out how to make some progress on them. >>> > > >>> > > Let me loosely characterize them as >>> > > >>> > > 1) If we have several video streams, how do theses map up to 1 or >>> more m >>> > lines. >>> > > >>> > > 2) if we are doing port multiplexing, what does the SDP look like >>> (the >>> > bundle problem) >>> > > >>> > > 3) How do we map the RTCWeb track and stream label concepts to >>> > identifiers in SDP >>> > > >>> > > 3) SDP for application running over SCTP/DTLS >>> > > >>> > > I don't want to speak for all the various chairs but I am under the >>> > impression that most of chairs of related groups in W3C and IETF >>> believe >>> > these are issues that need to be resolved primarily in the MMUSIC WG >>> and >>> > that they impact both WebRTC and CLUE as well as the general long term >>> use >>> > of SDP in SIP and other protocols. >>> > > >>> > > I'd like to get some discussion going on how we can make some >>> progress >>> > on these. I don't think we are going to solve these in 20 minutes of >>> > discussion at an IETF meeting so I think we probably need some interim >>> > (virtual or face to face) to sort this out. >>> > > >>> > > Thoughts? >>> > > >>> > > Wow, I'm totally confused here. >>> > > >>> > > I had assumed that the SDP-related issues were going to be the main >>> > > topics at the WebRTC/RTCWEB interim in January. Is that not the case? >>> > >>> > So far the interim was only talking about being a WebRTC & RTCWeb so >>> this >>> > SDP stuff would be out of scope. Perhaps it would be better to have >>> some >>> > of the time for mmusic topics? >>> > >>> > >>> > > >>> > > IMO the lack of clarity around how to encode various media >>> > > configurations into SDP is the major thing blocking progress here. In >>> > > particular, Firefox has opted not to implement multiplexing of media >>> > > streams over the same transport flow (whether of the bundle or >>> > > multiple m-line variety) until the SDP for it is well-defined. The >>> > > same thing applies to the question of how to map multiple m-lines to >>> > > incoming MediaStreams/Tracks. >>> > > >>> > > We really need to cover these issues in the interim. >>> > > >>> > > -Ekr >>> > > >>> > > >>> > >>> > _______________________________________________ >>> > mmusic mailing list >>> > mmusic@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mmusic >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --f46d0420a695cf5d7e04d0899c81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If there is a way to make this happen, that would be good.=C2=A0 If not,= then I think the only realistic option available to rtcweb would be to dro= p bundle, etc... That wouldn't be popular.

On Dec 10, 2012 5:19 PM, "Eric Rescorla&quo= t; <ekr@rtfm.com> wrote:
I feel like the priorities here are kind of confused.

It= seems to me that the purpose of having a physical interim is to resolve
issues that are hard to resolve on the list or teleconferences. As = I mentioned
earlier, the SDP issues are the most important to resolve now and have=
also proven to be among the most intractable. How does it make s= ense
to try to resolve those at a "virtual" interim whi= le having people fly
to a "physical" interim for three days?

=
I would strongly encourage the chairs to figure out how to have at lea= st
one of the days of this interim devoted solely to resolving th= e SDP=C2=A0
issues (really, my preference would be to take these issues one at
a time and do nothing else until they are resolved!). I'm not ex= pert
enough at the RAI WG mechanics to know what's required, = so perhaps
this requires making this also an MMUSIC interim or a mini-RAI interim= ,
but if so that's what we should do, even if it means we nee= d to reschedule
or move it.

Best,
-Ekr

On Mon, Dec 1= 0, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:<= br>
On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <k= eith.drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibilit= y in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to th= e scope of other working groups, without even having a discussion with all = the relevant chairs.


That's not how I read the overall senti= ment--people are simply saying that they need this work done and are willin= g to put in the effort to get it done.=C2=A0 It would, in fact, be ideal if= some of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interi= m, as we can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they w= ould find a January virtual interim very well received/attended.

Ted

=C2=A0
I'd further note that Jonathan Lennox has an action (with the support o= f quite a number of other people) to produce an internet draft on trying to= sort out the terminology concents that exist within RTP at the moment. Thi= s would be the basis for progressing a number of these issues. That would p= robably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where t= his now is. I know he was waiting on volunteers for some of the sections an= d on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmu= sic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ie= tf.org>; mmusic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco= .com> wrote:
> >
> > I was looking over everything that needs to be completed to finis= h a
> fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'= ;d like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or= more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like= (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am und= er the
> impression that most of chairs of related groups in W3C and IETF belie= ve
> these are issues that need to be resolved primarily in the MMUSIC WG a= nd
> that they impact both WebRTC and CLUE as well as the general long term= use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some= progress
> on these. I don't think we are going to solve these in 20 minutes = of
> discussion at an IETF meeting so I think we probably need some interim=
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the ma= in
> > topics at the WebRTC/RTCWEB interim in January. Is that not the c= ase?
>
> So far the interim was only talking about being a WebRTC & RTCWeb = so this
> SDP stuff would be out of scope. Perhaps it would be better to have so= me
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here= . In
> > particular, Firefox has opted not to implement multiplexing of me= dia
> > streams over the same transport flow (whether of the bundle or > > multiple m-line variety) until the SDP for it is well-defined. Th= e
> > same thing applies to the question of how to map multiple m-lines= to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic



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

--f46d0420a695cf5d7e04d0899c81-- From mdr@reavy.org Mon Dec 10 19:08:25 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 5F79721F8701; Mon, 10 Dec 2012 19:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[AWL=2.909, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PblTV5QG6jV1; Mon, 10 Dec 2012 19:08:24 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E09E121F872D; Mon, 10 Dec 2012 19:08:23 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:64145 helo=[192.168.1.18]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TiGCj-0009pO-3l; Mon, 10 Dec 2012 21:08:21 -0600 Message-ID: <50C6A3A5.3060009@reavy.org> Date: Mon, 10 Dec 2012 22:08:21 -0500 From: Maire Reavy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090000030303080504060307" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - reavy.org X-Source: X-Source-Args: X-Source-Dir: Cc: "Cullen Jennings \(fluffy\)" , "" , mmusic WG , "" Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff 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, 11 Dec 2012 03:08:25 -0000 This is a multi-part message in MIME format. --------------090000030303080504060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with Ekr on all points. We have put off resolving the SDP issues as long as we can, and the lack of resolution has started to impact our WebRTC implementation (in Firefox) already. I feel we need to maximize our chances of resolving the SDP issues as soon as we can. To me that means meeting in person as soon as possible to hammer this stuff out. Please let's find a way to discuss this in person. I think it's a big mistake if we rely on a virtual meeting only. Thanks. -Maire On 12/10/2012 8:18 PM, Eric Rescorla wrote: > I feel like the priorities here are kind of confused. > > It seems to me that the purpose of having a physical interim is to resolve > issues that are hard to resolve on the list or teleconferences. As I > mentioned > earlier, the SDP issues are the most important to resolve now and have > also proven to be among the most intractable. How does it make sense > to try to resolve those at a "virtual" interim while having people fly > to a "physical" interim for three days? > > I would strongly encourage the chairs to figure out how to have at least > one of the days of this interim devoted solely to resolving the SDP > issues (really, my preference would be to take these issues one at > a time and do nothing else until they are resolved!). I'm not expert > enough at the RAI WG mechanics to know what's required, so perhaps > this requires making this also an MMUSIC interim or a mini-RAI interim, > but if so that's what we should do, even if it means we need to reschedule > or move it. > > Best, > -Ekr > > On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie > wrote: > > On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) > > wrote: > > This is not just MMUSIC, there are bits of AVTCORE and AVTEXT > responsibility in there as well. > > And I don't see how you can suddenly extend the interim of > RTCWEB to the scope of other working groups, without even > having a discussion with all the relevant chairs. > > > That's not how I read the overall sentiment--people are simply > saying that they need this work done and are willing to put in the > effort to get it done. It would, in fact, be ideal if some of the > MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, > as we can then work through what is decided. > > Put another way, I take it as encouragement to MMUSIC folks that > they would find a January virtual interim very well received/attended. > > Ted > > I'd further note that Jonathan Lennox has an action (with the > support of quite a number of other people) to produce an > internet draft on trying to sort out the terminology concents > that exist within RTP at the moment. This would be the basis > for progressing a number of these issues. That would probably > have to be an RAI wide draft. > > There has been some progress on this - maybe Jonathan can > report on where this now is. I know he was waiting on > volunteers for some of the sections and on input from others > where volunteers already existed. > > Keith > > > -----Original Message----- > > From: mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org > ] On Behalf > > Of Cullen Jennings (fluffy) > > Sent: 09 December 2012 00:20 > > To: Eric Rescorla > > Cc: >; mmusic WG; > > > > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff > > > > > > On Dec 8, 2012, at 4:21 PM, Eric Rescorla > wrote: > > > > > +rtcweb > > > > > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > > > wrote: > > > > > > I was looking over everything that needs to be completed > to finish a > > fist cut of the WebRTC related work. There are a handful of > big SDP > > problems that are currently blocking some of the WebRTC work > and I'd like > > to figure out how to make some progress on them. > > > > > > Let me loosely characterize them as > > > > > > 1) If we have several video streams, how do theses map up > to 1 or more m > > lines. > > > > > > 2) if we are doing port multiplexing, what does the SDP > look like (the > > bundle problem) > > > > > > 3) How do we map the RTCWeb track and stream label concepts to > > identifiers in SDP > > > > > > 3) SDP for application running over SCTP/DTLS > > > > > > I don't want to speak for all the various chairs but I am > under the > > impression that most of chairs of related groups in W3C and > IETF believe > > these are issues that need to be resolved primarily in the > MMUSIC WG and > > that they impact both WebRTC and CLUE as well as the general > long term use > > of SDP in SIP and other protocols. > > > > > > I'd like to get some discussion going on how we can make > some progress > > on these. I don't think we are going to solve these in 20 > minutes of > > discussion at an IETF meeting so I think we probably need > some interim > > (virtual or face to face) to sort this out. > > > > > > Thoughts? > > > > > > Wow, I'm totally confused here. > > > > > > I had assumed that the SDP-related issues were going to be > the main > > > topics at the WebRTC/RTCWEB interim in January. Is that > not the case? > > > > So far the interim was only talking about being a WebRTC & > RTCWeb so this > > SDP stuff would be out of scope. Perhaps it would be better > to have some > > of the time for mmusic topics? > > > > > > > > > > IMO the lack of clarity around how to encode various media > > > configurations into SDP is the major thing blocking > progress here. In > > > particular, Firefox has opted not to implement > multiplexing of media > > > streams over the same transport flow (whether of the bundle or > > > multiple m-line variety) until the SDP for it is > well-defined. The > > > same thing applies to the question of how to map multiple > m-lines to > > > incoming MediaStreams/Tracks. > > > > > > We really need to cover these issues in the interim. > > > > > > -Ekr > > > > > > > > > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090000030303080504060307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I agree with Ekr on all points.  We have put off resolving the SDP issues as long as we can, and the lack of resolution has started to impact our WebRTC implementation (in Firefox) already.  I feel we need to maximize our chances of resolving the SDP issues as soon as we can. 

To me that means meeting in person as soon as possible to hammer this stuff out. 

Please let's find a way to discuss this in person.  I think it's a big mistake if we rely on a virtual meeting only.

Thanks.
-Maire


On 12/10/2012 8:18 PM, Eric Rescorla wrote:
I feel like the priorities here are kind of confused.

It seems to me that the purpose of having a physical interim is to resolve
issues that are hard to resolve on the list or teleconferences. As I mentioned
earlier, the SDP issues are the most important to resolve now and have
also proven to be among the most intractable. How does it make sense
to try to resolve those at a "virtual" interim while having people fly
to a "physical" interim for three days?

I would strongly encourage the chairs to figure out how to have at least
one of the days of this interim devoted solely to resolving the SDP 
issues (really, my preference would be to take these issues one at
a time and do nothing else until they are resolved!). I'm not expert
enough at the RAI WG mechanics to know what's required, so perhaps
this requires making this also an MMUSIC interim or a mini-RAI interim,
but if so that's what we should do, even if it means we need to reschedule
or move it.

Best,
-Ekr

On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
This is not just MMUSIC, there are bits of AVTCORE and AVTEXT responsibility in there as well.

And I don't see how you can suddenly extend the interim of RTCWEB to the scope of other working groups, without even having a discussion with all the relevant chairs.


That's not how I read the overall sentiment--people are simply saying that they need this work done and are willing to put in the effort to get it done.  It would, in fact, be ideal if some of the MMUSIC questions were resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what is decided.

Put another way, I take it as encouragement to MMUSIC folks that they would find a January virtual interim very well received/attended.

Ted

 
I'd further note that Jonathan Lennox has an action (with the support of quite a number of other people) to produce an internet draft on trying to sort out the terminology concents that exist within RTP at the moment. This would be the basis for progressing a number of these issues. That would probably have to be an RAI wide draft.

There has been some progress on this - maybe Jonathan can report on where this now is. I know he was waiting on volunteers for some of the sections and on input from others where volunteers already existed.

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings (fluffy)
> Sent: 09 December 2012 00:20
> To: Eric Rescorla
> Cc: <rtcweb@ietf.org>; mmusic WG; <public-webrtc@w3.org>
> Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>
>
> On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > +rtcweb
> >
> > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy)
> <fluffy@cisco.com> wrote:
> >
> > I was looking over everything that needs to be completed to finish a
> fist cut of the WebRTC related work. There are a handful of big SDP
> problems that are currently blocking some of the WebRTC work and I'd like
> to figure out how to make some progress on them.
> >
> > Let me loosely characterize them as
> >
> > 1) If we have several video streams, how do theses map up to 1 or more m
> lines.
> >
> > 2) if we are doing port multiplexing, what does the SDP look like (the
> bundle problem)
> >
> > 3) How do we map the RTCWeb track and stream label concepts to
> identifiers in SDP
> >
> > 3) SDP for application running over SCTP/DTLS
> >
> > I don't want to speak for all the various chairs but I am under the
> impression that most of chairs of related groups in W3C and IETF believe
> these are issues that need to be resolved primarily in the MMUSIC WG and
> that they impact both WebRTC and CLUE as well as the general long term use
> of SDP in SIP and other protocols.
> >
> > I'd like to get some discussion going on how we can make some progress
> on these. I don't think we are going to solve these in 20 minutes of
> discussion at an IETF meeting so I think we probably need some interim
> (virtual or face to face) to sort this out.
> >
> > Thoughts?
> >
> > Wow, I'm totally confused here.
> >
> > I had assumed that the SDP-related issues were going to be the main
> > topics at the WebRTC/RTCWEB interim in January. Is that not the case?
>
> So far the interim was only talking about being a WebRTC & RTCWeb so this
> SDP stuff would be out of scope. Perhaps it would be better to have some
> of the time for mmusic topics?
>
>
> >
> > IMO the lack of clarity around how to encode various media
> > configurations into SDP is the major thing blocking progress here. In
> > particular, Firefox has opted not to implement multiplexing of media
> > streams over the same transport flow (whether of the bundle or
> > multiple m-line variety) until the SDP for it is well-defined. The
> > same thing applies to the question of how to map multiple m-lines to
> > incoming MediaStreams/Tracks.
> >
> > We really need to cover these issues in the interim.
> >
> > -Ekr
> >
> >
>
> _______________________________________________
> 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




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

--------------090000030303080504060307-- From bernard_aboba@hotmail.com Mon Dec 10 21:01: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 C98AE21F855A; Mon, 10 Dec 2012 21:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAeExKPajl3O; Mon, 10 Dec 2012 21:01:55 -0800 (PST) Received: from blu0-omc4-s21.blu0.hotmail.com (blu0-omc4-s21.blu0.hotmail.com [65.55.111.160]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18521F84E8; Mon, 10 Dec 2012 21:01:55 -0800 (PST) Received: from BLU405-EAS266 ([65.55.111.135]) by blu0-omc4-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Dec 2012 21:01:54 -0800 X-Originating-IP: [24.16.96.166] X-EIP: [yjRvDdFj8sNRAlINp3pj8KtaEyT/BrCe] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Eric Rescorla'" References: <50C6A3A5.3060009@reavy.org> In-Reply-To: <50C6A3A5.3060009@reavy.org> Date: Mon, 10 Dec 2012 21:01:52 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01CDD719.948598B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgME29FzdihW/3vtGuW7IuVOVACLVV02ABlmw/UAW7LKGAArmp1VAJrlbzCbnngYcA== Content-Language: en-us X-OriginalArrivalTime: 11 Dec 2012 05:01:54.0421 (UTC) FILETIME=[A3888A50:01CDD75C] Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org, 'mmusic WG' Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bernard_aboba@hotmail.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 05:01:56 -0000 ------=_NextPart_000_00C0_01CDD719.948598B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not think that a single meeting, virtual or actual, will suffice to get things back on track. We need a fundamental change of approach. The basic problem is that WebRTC work items have been dispersed between a number of WGs other than RTCWEB. Within these WGs, WebRTC is only a sideline. As a result, work items such as BUNDLE (which require non-trivial analysis and discussion) have found themselves a needle in a haystack of other items, getting a fraction of the attention that they need to move forward. While allocating some substantial time at an in-person RTCWEB/MMUSIC interim can help, for that time to be well spent will require substantial preparation. As an example, I could see a virtual AVTEXT interim being scheduled for mid-January at which Jonathan Lennox's hierarchy draft could be given substantial time and an MMUSIC virtual interim in the same time frame which could be devoted to one or two important topics (e.g. BUNDLE, SCTP). If that is done, then the issues requiring additional intensive work might be narrowed to the point where an in-person meeting in early February might be able to finish some of them off, with others handled another round of virtual interims two weeks later. Bernard "MARTINI was hell - but it only lasted a year" Aboba On 12/10/2012 8:18 PM, Eric Rescorla wrote: I'm not expert enough at the RAI WG mechanics to know what's required, so perhaps this requires making this also an MMUSIC interim or a mini-RAI interim, but if so that's what we should do, even if it means we need to reschedule or move it. ------=_NextPart_000_00C0_01CDD719.948598B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not think that a = single meeting, virtual or actual, will suffice to get things back on = track.  We need a fundamental change of approach. =

 

The basic problem is = that WebRTC work items have been dispersed between a number of WGs other = than RTCWEB.  Within these WGs, WebRTC is only a sideline. =

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     

As a result, work items = such as BUNDLE (which require non-trivial analysis and discussion) have = found themselves a needle in a haystack of other items, getting a = fraction of the attention that they need to move forward. =  

 

While allocating some = substantial time at an in-person RTCWEB/MMUSIC interim can help, for = that time to be well spent will require substantial preparation. =  As an example, I could see a virtual AVTEXT interim being = scheduled for mid-January at which Jonathan Lennox’s hierarchy = draft could be given substantial time and an MMUSIC virtual interim in = the same time frame which could be devoted to one or two important = topics (e.g. BUNDLE, SCTP).

 

If that is done, then = the issues requiring additional intensive work might be narrowed to the = point where an in-person meeting in early February might be able to = finish some of them off, with others handled another round of virtual = interims two weeks later.

 

Bernard “MARTINI = was hell – but it only lasted a year” = Aboba

 



On 12/10/2012 8:18 PM, Eric Rescorla = wrote:

I'm not expert = enough at the RAI WG mechanics to know what's required, so = perhaps

this requires making this also an MMUSIC interim or a = mini-RAI interim,

but if = so that's what we should do, even if it means we need to = reschedule

or move = it.

 

 

------=_NextPart_000_00C0_01CDD719.948598B0-- From salvatore.loreto@ericsson.com Tue Dec 11 01:08: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 EDC6F21F8962 for ; Tue, 11 Dec 2012 01:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.163 X-Spam-Level: X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6snCFc8QsfB for ; Tue, 11 Dec 2012 01:08:37 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19421F8870 for ; Tue, 11 Dec 2012 01:08:36 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-42-50c6f802a43d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B2.40.24873.208F6C05; Tue, 11 Dec 2012 10:08:18 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 11 Dec 2012 10:08:18 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C4BAA244F; Tue, 11 Dec 2012 11:08:17 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7947B53D77; Tue, 11 Dec 2012 11:08:16 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2C82853C40; Tue, 11 Dec 2012 11:08:16 +0200 (EET) Message-ID: <50C6F800.1080500@ericsson.com> Date: Tue, 11 Dec 2012 11:08:16 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> In-Reply-To: <50BD04D2.7090207@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvja7wj2MBBtefsFlMXf6YxaJx8jtm ByaPJUt+Mnl8WL6OLYApissmJTUnsyy1SN8ugStj6b6lbAVvBCrOzGtlbmCcytvFyMkhIWAi sW/CX0YIW0ziwr31bF2MXBxCAicZJd5e/A7lbGCU2PlkAguEs4tR4ufZ28wQzlpGidZdHxkh nG2MElcWfmPvYuTg4BXQluhfwgIyl0VAVeLk1zlMIDabgJnE84dbmEFsUYFYia2XLrOB2LwC ghInZz4BqxcREJaY8fYvG8gYZqDe3+80QMLCArYSR5ZOZoVY1csocfvoTVaQBKeAjsSrZyfB epmBii7MuQ5ly0tsfzuHGeI3NYmr5zaB2UICWhK9ZzuZJjCKzkKyehaS9llI2hcwMq9iZM9N zMxJLzfaxAgM/INbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGEt2hiYpPJjTEf10N/uRGvbADnW3vftkdm9v38lRd9L68PPjv9Z43zd/94Vhp65o7Yfj gSyv+CQX/HLQE+7+9pKZ44fT9YJtiut1pA8c6pJ+cLFn+rPP+ZnNK1S/vWKO/N7072jkrqXP Jocb2y7ktane4PTr1L1FfZtOOWYp7JrJUV6/jMdqRrISS3FGoqEWc1FxIgDKzUJsSgIAAA== Cc: Randell Jesup Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 09:08:38 -0000 Hi Paul, see in line! On 12/3/12 10:00 PM, Paul Kyzivat wrote: > Commenting on a different point > > On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >> The interesting difference is that the multiplexing between DTLS/SCTP >> traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried >> in SSRCs, which means: >> >> - There can be only one DTLS/SCTP stream in a bundle (which may have >> multiple associations, as you state below); you can't have multiple >> lines with proto DTLS/SCTP in a bundle. > > I am not an SCTP expert. But IIUC, SCTP was designed to run directly > over IP. It has its own notion of port used to demux multiple SCTP > associations over the same IP address. > > I presume that that same mechanism is still there when SCTP is run > over DTLS over UDP. > > So, the traffic coming over DTLS must first be demuxed into RTP > traffic and SCTP traffic. based on the current stack the SCTP traffic is the only traffic that runs directly over the DTLS stack. What I am trying to do is to include the Randell Jesup (I am including him in CC as I am not sure he is subscribed to this mailing list) suggestion to give the possibility to have multiple SCTP *associations* running on top of the same DTLS session and of course providing a way to signal it in SDP. to be clear: at moment WebRTC allows only one SCTP association per PC, so this is something that would be nice to define just to be ready for the future. > Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic > can be demuxed based on SCTP port. And once the traffic for a single > SCTP port is identified, it can be demuxed based on stream number. > > Representing this in SDP is a challenge. Some variant of the bundle > proposal might allow bundling together several RTP m-lines and some > DTLS/SCTP m-lines. This would require a mechanism for specifying the > SCTP port number - already an open issue (#3) in > draft-ietf-mmusic-sctp-sdp-02. I agree that it is a challange how then to bundle everything together Salvatore -- Salvatore Loreto, PhD www.sloreto.com From Markus.Isomaki@nokia.com Tue Dec 11 02: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 BE59521F86BE for ; Tue, 11 Dec 2012 02:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U199rmbj8P16 for ; Tue, 11 Dec 2012 02:34:38 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3521F84E6 for ; Tue, 11 Dec 2012 02:34:37 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBBAYUoF028093; Tue, 11 Dec 2012 12:34:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Dec 2012 12:34:30 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.185]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 10:34:30 +0000 From: To: , Thread-Topic: [MMUSIC] SCTP question: Where does it multiplex? Thread-Index: AQHNz7N6WgV/cieAmkiYZjuifDh2VZgEB+uAgAN6UACAC9x6AIAAE26w Date: Tue, 11 Dec 2012 10:34:28 +0000 Message-ID: References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> In-Reply-To: <50C6F800.1080500@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Dec 2012 10:34:30.0746 (UTC) FILETIME=[1A6E13A0:01CDD78B] X-Nokia-AV: Clean Cc: randell@jesup.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 10:34:38 -0000 Hi Sal, Salvatore Loreto wrote: > >based on the current stack the SCTP traffic is the only traffic that runs = directly >over the DTLS stack. >What I am trying to do is to include the Randell Jesup (I am including him= in CC >as I am not sure he is subscribed to this mailing list) > suggestion to give the possibility to have multiple SCTP >*associations* running on top of the same DTLS session and of course >providing a way to signal it in SDP. > >to be clear: at moment WebRTC allows only one SCTP association per PC, so >this is something that would be nice to define just to be ready for the fu= ture. > It's a bit unclear to me what the benefit of this would be. SCTP itself all= ows multiple streams to be transported in parallel within a single SCTP ass= ociation. So, in what type of situations would we need multiple parallel SC= TP associations? I thought the main point of SCTP is that it provides the p= arallelism and multiplexing by itself. In other words: I do understand the desire to multiplex RTP and SCTP within= the same UDP flow, so we can for instance reduce the number of needed NAT/= FW bindings. I also understand why multiple independent non-HOL blocking st= reams within SCTP are useful for applications. But I don't yet understand t= he additional benefit of multiple parallel SCTP associations. No doubt it c= an be technically done, but to what purposes? Markus=20 From stefan.lk.hakansson@ericsson.com Tue Dec 11 02:59: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 58A3021F87EE; Tue, 11 Dec 2012 02:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.137 X-Spam-Level: X-Spam-Status: No, score=-6.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7rbUjiL5x03; Tue, 11 Dec 2012 02:59:33 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7A21F87E6; Tue, 11 Dec 2012 02:59:33 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-26-50c71213675d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5D.0C.04318.31217C05; Tue, 11 Dec 2012 11:59:32 +0100 (CET) Received: from [150.132.142.225] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 11 Dec 2012 11:59:31 +0100 Message-ID: <50C71211.4070603@ericsson.com> Date: Tue, 11 Dec 2012 11:59:29 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: bernard_aboba@hotmail.com References: <50C6A3A5.3060009@reavy.org> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvja6I0PEAgzUzeC32L7nMbLHi9Tl2 i47JbBZTlz9msVj7r53dgdVjyu+NrB6Pe86weSxZ8pPJY/LjNuYAligum5TUnMyy1CJ9uwSu jEkP3jEX3OeqeLB1GnMD43GOLkZODgkBE4kJM/rZIGwxiQv31gPZXBxCAicZJf4deMwE4axl lHi19zUTSBWvgLbEvRv97CA2i4CqxJL5c1hAbDYBG4m13VPAakQFAiQWLznHDlEvKHFy5hOw GhEBWYnOi6tYQYYyC3QwShze84QZJCEsYC+xZO0Ldoht/5gl2r/uAOvgFLCV+LX7J1AHB1CH vcSDrWUgYWYBeYnmrbPBeoUEdCXevb7HOoFRcBaSfbMQOmYh6VjAyLyKkT03MTMnvdx8EyMw iA9u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNrGLjy0 bc2n/Rbuvp9CVsSt/22/w2K277rLzZlMcwLsdWL7bhtlhuQc9//koMW2ROhOcUkT04fm2Phz QcrdsX6ZLVoNWi7vnMoiOhuWMs2VPdX3/4MPi8fy4pbZ725c9NH5d0pbfrNUEMvud5Ncpu7S u84qm5LzemKZbLX4ny5no+I5TBxFSizFGYmGWsxFxYkADpZ6/DACAAA= Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org, 'mmusic WG' Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff 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, 11 Dec 2012 10:59:34 -0000 On 12/11/2012 06:01 AM, Bernard Aboba wrote: > I do not think that a single meeting, virtual or actual, will suffice to > get things back on track. We need a fundamental change of approach. > > The basic problem is that WebRTC work items have been dispersed between > a number of WGs other than RTCWEB. Within these WGs, WebRTC is only a > sideline. > > As a result, work items such as BUNDLE (which require non-trivial > analysis and discussion) have found themselves a needle in a haystack of > other items, getting a fraction of the attention that they need to move > forward. I'd say that Bundle is something that comes on top of more fundamental things (such as the representation of multiple streams and transports in SDP) needing resolution. If I have to prioritize I would do the fundamentals first and worry about Bundle later. > > While allocating some substantial time at an in-person RTCWEB/MMUSIC > interim can help, for that time to be well spent will require > substantial preparation. As an example, I could see a virtual AVTEXT > interim being scheduled for mid-January at which Jonathan Lennox’s > hierarchy draft could be given substantial time and an MMUSIC virtual > interim in the same time frame which could be devoted to one or two > important topics (e.g. BUNDLE, SCTP). I think this is a great idea! Stefan From pkyzivat@alum.mit.edu Tue Dec 11 07:43: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 C117421F8543 for ; Tue, 11 Dec 2012 07:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k0cAhbgiuRl for ; Tue, 11 Dec 2012 07:43:10 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC0121F8540 for ; Tue, 11 Dec 2012 07:43:09 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id aBmY1k0020xGWP851Fj9DM; Tue, 11 Dec 2012 15:43:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id aFj91k0043ZTu2S3YFj9f1; Tue, 11 Dec 2012 15:43:09 +0000 Message-ID: <50C7548C.3090807@alum.mit.edu> Date: Tue, 11 Dec 2012 10:43:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> In-Reply-To: <50C6F800.1080500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355240589; bh=YhLAQK/6Er0CO6tgsVwgHhtoqA98FroGqGBI0p4wvOs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NtbWxd/g51hhaAGMJtnZZem37vlPYx65I5TabEV4H05gw+vHiD0VLlmQxDH4zAfZn 6gUz/G5RQJl9BiMzhWFV0H4T+mqGKkm20wFsY0GJsVphTxQ009YR7/J6icWSo5kzKC 4AswQconQLgcjNLlfF9PFgSe7bz4HfWgpcTS9T/c5IrfqNiTCndw/QvP5jzdm0776U i8Tol4oMLj6KANkabKmMuNl/0w2vUsqxLDD/8EOSNZ07mVq5Hozafz5lfAtclB/LXP p1LB1NysAdI2X9OddQAVJfl+ey5HM1uP1DuFgGZzVxqBq0IgKdin58WWI5/AsFFiM8 +SiUK+qxSengA== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 15:43:10 -0000 More inline. On 12/11/12 4:08 AM, Salvatore Loreto wrote: > Hi Paul, > > see in line! > > On 12/3/12 10:00 PM, Paul Kyzivat wrote: >> Commenting on a different point >> >> On 12/1/12 9:53 AM, Harald Alvestrand wrote: >> >>> The interesting difference is that the multiplexing between DTLS/SCTP >>> traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not carried >>> in SSRCs, which means: >>> >>> - There can be only one DTLS/SCTP stream in a bundle (which may have >>> multiple associations, as you state below); you can't have multiple >>> lines with proto DTLS/SCTP in a bundle. >> >> I am not an SCTP expert. But IIUC, SCTP was designed to run directly >> over IP. It has its own notion of port used to demux multiple SCTP >> associations over the same IP address. >> >> I presume that that same mechanism is still there when SCTP is run >> over DTLS over UDP. >> >> So, the traffic coming over DTLS must first be demuxed into RTP >> traffic and SCTP traffic. > based on the current stack the SCTP traffic is the only traffic that > runs directly over the DTLS stack. Yes, that is what I thought. But Harald has been asking about multiplexing this with RTP traffic. (Actually I think it would be DTLS/SRTP traffic that it would be multiplexed with.) > What I am trying to do is to include the Randell Jesup (I am including > him in CC as I am not sure he is subscribed to this mailing list) > suggestion to give the possibility to have multiple SCTP > *associations* running on top of the same DTLS session > and of course providing a way to signal it in SDP. IIUC, SCTP (having been designed as a transport layer protocol) defines its own notion of port, and has fields in its protocol to carry the local and remote port number. Presumably those fields are still there when run over UDP or DTLS. So it should be possible to support multiple SCTP associations over the same DTLS connection, each distinguished by its own port pair. That of course depends on having a signaling mechanism to set it up. > to be clear: at moment WebRTC allows only one SCTP association per PC, > so this is something that would be nice to define just to be ready for > the future. AFAIK WebRTC is just one possible user of this mechanism. The SDP mechanism shouldn't be limited by the constraints of WebRTC. It would be very difficult to define the SDP so that it was impossible to set up multiple SCTP associations over different 5-tuples. >> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic >> can be demuxed based on SCTP port. And once the traffic for a single >> SCTP port is identified, it can be demuxed based on stream number. >> >> Representing this in SDP is a challenge. Some variant of the bundle >> proposal might allow bundling together several RTP m-lines and some >> DTLS/SCTP m-lines. This would require a mechanism for specifying the >> SCTP port number - already an open issue (#3) in >> draft-ietf-mmusic-sctp-sdp-02. > I agree that it is a challange how then to bundle everything together But it is a challenge that needs to be tackled if we are to realize Harald's dream. Thanks, Paul From harald@alvestrand.no Tue Dec 11 07:58:36 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 5517321F8540 for ; Tue, 11 Dec 2012 07:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNR9SIQzY6Q6 for ; Tue, 11 Dec 2012 07:58:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B840121F8526 for ; Tue, 11 Dec 2012 07:58:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF46139E179 for ; Tue, 11 Dec 2012 16:58:34 +0100 (CET) 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 s5siBwN8clRn for ; Tue, 11 Dec 2012 16:58:33 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 86D0839E0A7 for ; Tue, 11 Dec 2012 16:58:27 +0100 (CET) Message-ID: <50C75822.10804@alvestrand.no> Date: Tue, 11 Dec 2012 16:58:26 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> In-Reply-To: <50C7548C.3090807@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 15:58:36 -0000 On 12/11/2012 04:43 PM, Paul Kyzivat wrote: > More inline. > > On 12/11/12 4:08 AM, Salvatore Loreto wrote: >> Hi Paul, >> >> see in line! >> >> On 12/3/12 10:00 PM, Paul Kyzivat wrote: >>> Commenting on a different point >>> >>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: >>> >>>> The interesting difference is that the multiplexing between DTLS/SCTP >>>> traffic and BUNDLE multiplexing is that DTLS/SCTP traffic is not >>>> carried >>>> in SSRCs, which means: >>>> >>>> - There can be only one DTLS/SCTP stream in a bundle (which may have >>>> multiple associations, as you state below); you can't have multiple >>>> lines with proto DTLS/SCTP in a bundle. >>> >>> I am not an SCTP expert. But IIUC, SCTP was designed to run directly >>> over IP. It has its own notion of port used to demux multiple SCTP >>> associations over the same IP address. >>> >>> I presume that that same mechanism is still there when SCTP is run >>> over DTLS over UDP. >>> >>> So, the traffic coming over DTLS must first be demuxed into RTP >>> traffic and SCTP traffic. >> based on the current stack the SCTP traffic is the only traffic that >> runs directly over the DTLS stack. > > Yes, that is what I thought. But Harald has been asking about > multiplexing this with RTP traffic. (Actually I think it would be > DTLS/SRTP traffic that it would be multiplexed with.) Yes, it's SRTP traffic that the DTLS/SCTP traffic will be multiplexed with (the DTLS part of DTLS/SRTP is just a key negotiation mechanism, unlike the DTLS part of DTLS/SCTP, which is an actual encapsulation). From harald@alvestrand.no Tue Dec 11 08: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 0F52E21F84E9 for ; Tue, 11 Dec 2012 08:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.478 X-Spam-Level: X-Spam-Status: No, score=-110.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYVddLVZ8hzr for ; Tue, 11 Dec 2012 08:51:50 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 950BE21F8895 for ; Tue, 11 Dec 2012 08:51:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4085B39E179 for ; Tue, 11 Dec 2012 17:51:47 +0100 (CET) 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 ESz6utJ9xbdt for ; Tue, 11 Dec 2012 17:51:45 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 844EE39E0A7 for ; Tue, 11 Dec 2012 17:51:45 +0100 (CET) Message-ID: <50C764A0.7060908@alvestrand.no> Date: Tue, 11 Dec 2012 17:51:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50C6A3A5.3060009@reavy.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050204050101090105050301" Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff 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, 11 Dec 2012 16:51:51 -0000 This is a multi-part message in MIME format. --------------050204050101090105050301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/11/2012 06:01 AM, Bernard Aboba wrote: > > I do not think that a single meeting, virtual or actual, will suffice > to get things back on track. We need a fundamental change of approach. > I see the main purpose of meetings to serve as stopping points for discussions. In order to be effective, the proposals for solutions have to be created before the meeting, and the meeting serves to accept, reject or modify the proposals. > > The basic problem is that WebRTC work items have been dispersed > between a number of WGs other than RTCWEB. Within these WGs, WebRTC > is only a sideline. > > As a result, work items such as BUNDLE (which require non-trivial > analysis and discussion) have found themselves a needle in a haystack > of other items, getting a fraction of the attention that they need to > move forward. > Indeed. > > While allocating some substantial time at an in-person RTCWEB/MMUSIC > interim can help, for that time to be well spent will require > substantial preparation. As an example, I could see a virtual AVTEXT > interim being scheduled for mid-January at which Jonathan Lennox's > hierarchy draft could be given substantial time and an MMUSIC virtual > interim in the same time frame which could be devoted to one or two > important topics (e.g. BUNDLE, SCTP). > > If that is done, then the issues requiring additional intensive work > might be narrowed to the point where an in-person meeting in early > February might be able to finish some of them off, with others handled > another round of virtual interims two weeks later. > > Bernard "MARTINI was hell -- but it only lasted a year" Aboba > > > > On 12/10/2012 8:18 PM, Eric Rescorla wrote: > > I'm not expertenough at the RAI WG mechanics to know what's > required, so perhaps > > this requires making this also an MMUSIC interim or a mini-RAI > interim, > > but if so that's what we should do, even if it means we need to > reschedule > > or move it. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------050204050101090105050301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/11/2012 06:01 AM, Bernard Aboba wrote:

I do not think that a single meeting, virtual or actual, will suffice to get things back on track.  We need a fundamental change of approach.

I see the main purpose of meetings to serve as stopping points for discussions.
In order to be effective, the proposals for solutions have to be created before the meeting, and the meeting serves to accept, reject or modify the proposals.

 

The basic problem is that WebRTC work items have been dispersed between a number of WGs other than RTCWEB.  Within these WGs, WebRTC is only a sideline.

                                                                                                                           

As a result, work items such as BUNDLE (which require non-trivial analysis and discussion) have found themselves a needle in a haystack of other items, getting a fraction of the attention that they need to move forward. 

Indeed.

 

While allocating some substantial time at an in-person RTCWEB/MMUSIC interim can help, for that time to be well spent will require substantial preparation.  As an example, I could see a virtual AVTEXT interim being scheduled for mid-January at which Jonathan Lennox’s hierarchy draft could be given substantial time and an MMUSIC virtual interim in the same time frame which could be devoted to one or two important topics (e.g. BUNDLE, SCTP).

 

If that is done, then the issues requiring additional intensive work might be narrowed to the point where an in-person meeting in early February might be able to finish some of them off, with others handled another round of virtual interims two weeks later.

 

Bernard “MARTINI was hell – but it only lasted a year” Aboba

 



On 12/10/2012 8:18 PM, Eric Rescorla wrote:

I'm not expert enough at the RAI WG mechanics to know what's required, so perhaps

this requires making this also an MMUSIC interim or a mini-RAI interim,

but if so that's what we should do, even if it means we need to reschedule

or move it.

 

 



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

--------------050204050101090105050301-- From pkyzivat@alum.mit.edu Tue Dec 11 09:05: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 A04BD21F84DC for ; Tue, 11 Dec 2012 09:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npTDls38uKpk for ; Tue, 11 Dec 2012 09:05:53 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E165321F84D9 for ; Tue, 11 Dec 2012 09:05:52 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id aB5n1k00C1wpRvQ53H5sf5; Tue, 11 Dec 2012 17:05:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id aH5r1k00i3ZTu2S3eH5sPg; Tue, 11 Dec 2012 17:05:52 +0000 Message-ID: <50C767EE.4080701@alum.mit.edu> Date: Tue, 11 Dec 2012 12:05:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355245552; bh=7zZldqD6u5XtiHzrU1BGxb3Ua319GqKmASSLKmZwIGc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V93r8RpZ9TkIgA+cts7cWsmgYZPnYBwM4aHN4VZaCqPzhVJe1YB5xyZS8F6xZARek kQx/A5x7MNgIHLcwuvz5M/Hq4WdlZPz6buoQCAUDhfgGqv8SFnnGU0+gmoF16MQPw+ 6kzMdeYiZGr9WWnIqSn3hrYm03yfSmmXMRk1VIQ1LgMOFwMkVjcVE4hAlSgLfYuhHX GJUUAYxvBHbgt+5G2ebLnPvcNpsl41zk8jhyWrhuZ3P0JscVMhXewHPYpuRG2BPLUX zKzhZkin5l4AtNK075mY3G4i/B5f+uIqSvizF+rT3rO5h+O5Mm8NZBbRxTYntr0VoC yaAKFnUJUND9Q== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 17:05:53 -0000 On 12/11/12 5:34 AM, Markus.Isomaki@nokia.com wrote: > Hi Sal, > > Salvatore Loreto wrote: >> >> based on the current stack the SCTP traffic is the only traffic that runs directly >> over the DTLS stack. >> What I am trying to do is to include the Randell Jesup (I am including him in CC >> as I am not sure he is subscribed to this mailing list) >> suggestion to give the possibility to have multiple SCTP >> *associations* running on top of the same DTLS session and of course >> providing a way to signal it in SDP. >> >> to be clear: at moment WebRTC allows only one SCTP association per PC, so >> this is something that would be nice to define just to be ready for the future. >> > > It's a bit unclear to me what the benefit of this would be. SCTP itself allows multiple streams to be transported in parallel within a single SCTP association. So, in what type of situations would we need multiple parallel SCTP associations? I thought the main point of SCTP is that it provides the parallelism and multiplexing by itself. It may not provide any benefit for WebRTC. To provide some benefit it would need to be exposed in the WebRTC API. If every stream/channel within the SCTP session is always negotiated in SDP then there is less likely to be benefit in general. But if (as planned, I think) the streams/channels within the SCTP association can be managed dynamically, then having two associations means you could have two separate pools of streams to dynamically manage. This could be helpful if you have multiple components within your application that want their own control over dynamic data streams. Whether the multiple SCTP associations are over the same DTLS connection or different ones is an independent question. > In other words: I do understand the desire to multiplex RTP and SCTP within the same UDP flow, so we can for instance reduce the number of needed NAT/FW bindings. I also understand why multiple independent non-HOL blocking streams within SCTP are useful for applications. But I don't yet understand the additional benefit of multiple parallel SCTP associations. No doubt it can be technically done, but to what purposes? IIUC this is a mechanism that is already latent in the SCTP. It is a matter of whether to expose the capability. Not exposing it just means that the latent capability isn't being used - everyone will be operating on a default SCTP port. Exposing it needs to occur at two levels, and the decision whether to do so or not can be made separately: IIUC the SCTP *protocol* already has this capability. The proposed SDP currently provides no way to specify the SCTP port. If it is to continue that way then it minimally needs to specify which port value is to be used in the protocol. (Otherwise we can have interoperability failures.) It should be very simple to provide an attribute to explicitly specify the SCTP port, while still specifying a default value if not specified. By itself this would not be very useful if you could only specify one. More complex would be to specify use of multiple SCTP ports over the same DTLS connection. That starts to look like a bundle problem again because they share the same address and UDP port, while having a number of attributes to specify about each. If we want to keep this simple for now, then I suggest that draft-ietf-mmusic-sctp-sdp simply specify that implementations of this draft always use SCTP port zero, and that use of other ports is out of scope. Thanks, Paul From martin.thomson@gmail.com Tue Dec 11 10:20: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 73DC821F8738 for ; Tue, 11 Dec 2012 10:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.674 X-Spam-Level: X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KruZDvyVGrhJ for ; Tue, 11 Dec 2012 10:20:45 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14EFC21F8701 for ; Tue, 11 Dec 2012 10:20:36 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3458934lah.31 for ; Tue, 11 Dec 2012 10:20:36 -0800 (PST) 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=ulh2NYRhpHsavUSxQdUT37+wAXR09EBErhuCCFulKdk=; b=q+vRs3jRLBnQYxeNxegIuyz3ywp7l81D6CVElgmmdNvnYMn056cva1U4AYkUR9QfeK YoYU+7rLcT+Ge0flDZLgNmtF+4kphfrLoAgUiLmpdrVdVNVX/O2DY+JNYsO0jNSV4P8G Un5tpbNGcMbnztna5fhgTAqtHRfLxdR8R0h8wxmozQex2za4WhFXhPwgrah18gohUQvP ySxUEYYxdxfjXhGyScmM4cegBsZsLN7Yil+R1tR8N+pzhgcdC269+e1nex8B7DYueKoZ UB4QRlpjZJ9AyJ4E8DwSDt+WUi4JkNZwu0k6DVn6jVh2ZVC2nwlpj8JNCDaGU3yNpiOQ Q8TQ== MIME-Version: 1.0 Received: by 10.112.49.65 with SMTP id s1mr7939214lbn.123.1355250035868; Tue, 11 Dec 2012 10:20:35 -0800 (PST) Received: by 10.112.98.200 with HTTP; Tue, 11 Dec 2012 10:20:35 -0800 (PST) In-Reply-To: <50C764A0.7060908@alvestrand.no> References: <50C6A3A5.3060009@reavy.org> <50C764A0.7060908@alvestrand.no> Date: Tue, 11 Dec 2012 10:20:35 -0800 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff 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, 11 Dec 2012 18:20:45 -0000 On 11 December 2012 08:51, Harald Alvestrand wrote: > In order to be effective, the proposals for solutions have to be created > before the meeting, and the meeting serves to accept, reject or modify the > proposals. That's true, but it's also true that scheduled meetings tend to act as an effective form of stimulus. I really don't want more meetings, but this could be a contributing factor. I don't think that it's the main one. At the current time, the main reason for lack of progress is the impotence of the rtcweb working group. From dwing@cisco.com Tue Dec 11 10:53: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 E846E21F85D6 for ; Tue, 11 Dec 2012 10:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.393 X-Spam-Level: X-Spam-Status: No, score=-110.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98V3eQPQUadF for ; Tue, 11 Dec 2012 10:53:32 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9B21F855F for ; Tue, 11 Dec 2012 10:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4479; q=dns/txt; s=iport; t=1355252012; x=1356461612; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=NIvZ1XRX2KT0JMJaNvIochwjl2PklSWCCBZ1l4A9+v4=; b=TS11urRfT32QQYP/9hOtA/hOS3Jc8X4hQ3pQNBjje6f0rNFRmZns9h8w em6NO428giywfB//370q6V4A+To6u9PieMQB1akJ4ET/H7b8sfsjDhzLm 3NWgsEdLdaVDF5dFLwdRSzCDaWAub0M4+lzgT0nXFbQJtJJBqnRf1y/KX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwGABaAx1CrRDoG/2dsb2JhbABEDoM6un0Wc4IeAQEBAwEIAjAtBAMQBwEDAgkOAwQBAQEnBxktCQgCBAESCwWHewWrI5BajEoVhC4DiGCFHIgLkEiCNV+BQw X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="63720055" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Dec 2012 18:53:31 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBIrUKY020842; Tue, 11 Dec 2012 18:53:30 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> In-Reply-To: <50C7548C.3090807@alum.mit.edu> Date: Tue, 11 Dec 2012 10:53:30 -0800 Message-ID: <010401cdd7d0$d006d310$70147930$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jSYF41PAA== Content-Language: en-us Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 18:53:33 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, December 11, 2012 7:43 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > More inline. > > On 12/11/12 4:08 AM, Salvatore Loreto wrote: > > Hi Paul, > > > > see in line! > > > > On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >> Commenting on a different point > >> > >> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >> > >>> The interesting difference is that the multiplexing between > >>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP traffic > >>> is not carried in SSRCs, which means: > >>> > >>> - There can be only one DTLS/SCTP stream in a bundle (which may have > >>> multiple associations, as you state below); you can't have multiple > >>> lines with proto DTLS/SCTP in a bundle. > >> > >> I am not an SCTP expert. But IIUC, SCTP was designed to run directly > >> over IP. It has its own notion of port used to demux multiple SCTP > >> associations over the same IP address. > >> > >> I presume that that same mechanism is still there when SCTP is run > >> over DTLS over UDP. > >> > >> So, the traffic coming over DTLS must first be demuxed into RTP > >> traffic and SCTP traffic. > > based on the current stack the SCTP traffic is the only traffic that > > runs directly over the DTLS stack. > > Yes, that is what I thought. But Harald has been asking about > multiplexing this with RTP traffic. (Actually I think it would be > DTLS/SRTP traffic that it would be multiplexed with.) > > > What I am trying to do is to include the Randell Jesup (I am including > > him in CC as I am not sure he is subscribed to this mailing list) > > suggestion to give the possibility to have multiple SCTP > > *associations* running on top of the same DTLS session and of course > > providing a way to signal it in SDP. > > IIUC, SCTP (having been designed as a transport layer protocol) defines > its own notion of port, and has fields in its protocol to carry the > local and remote port number. Presumably those fields are still there > when run over UDP or DTLS. So it should be possible to support multiple > SCTP associations over the same DTLS connection, each distinguished by > its own port pair. Yes, SCTP has its own notion of ports. How this works when SCTP is carried over UDP is not quite clear, especially because SCTP assumes a NAPT will not rewrite the SCTP port number (SCTP endeavors to make such port rewriting difficult). But of course a NAPT (and the MAP techniques) rewrite UDP port numbers. I believe SCTP would only be able to successfully convey its UDP port numbers for a device that is not behind a NAT (that is, a server sitting directly on the Internet, rather than a remote peer that is behind a NAT). Creative use of PCP, NAT-PMP, or UPnP IGD would improve that situation in the future. > That of course depends on having a signaling mechanism to set it up. After the initial SCTP association is created, SCTP could be allowed to do its own thing (that is, chose to find and use other ports). SCTP's behavior in this regard is similar to MPRTP (multipath RTP), but of course they are not identical. > > to be clear: at moment WebRTC allows only one SCTP association per PC, > > so this is something that would be nice to define just to be ready for > > the future. > > AFAIK WebRTC is just one possible user of this mechanism. The SDP > mechanism shouldn't be limited by the constraints of WebRTC. It would be > very difficult to define the SDP so that it was impossible to set up > multiple SCTP associations over different 5-tuples. > > >> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic > >> can be demuxed based on SCTP port. And once the traffic for a single > >> SCTP port is identified, it can be demuxed based on stream number. > >> > >> Representing this in SDP is a challenge. Some variant of the bundle > >> proposal might allow bundling together several RTP m-lines and some > >> DTLS/SCTP m-lines. This would require a mechanism for specifying the > >> SCTP port number - already an open issue (#3) in > >> draft-ietf-mmusic-sctp-sdp-02. > > I agree that it is a challange how then to bundle everything together > > But it is a challenge that needs to be tackled if we are to realize > Harald's dream. -d From dwing@cisco.com Tue Dec 11 10:53: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 09A0821F855F for ; Tue, 11 Dec 2012 10:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-TxDT3+Ih9v for ; Tue, 11 Dec 2012 10:53:32 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF4421F8563 for ; Tue, 11 Dec 2012 10:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2063; q=dns/txt; s=iport; t=1355252012; x=1356461612; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qfkempr6D+84LbCVGFtTXNnQGo2EJavkcUGC2Pvp2S4=; b=iFVReRLckhNCdsHnAIWzP+eXxo1QfmwpW1YzXhkx3M55kmkUAaExGxrO cDAZ4JKThQVlfhT5BnPITUpW2j9MZt8KQ2fm4Rxz3vIrCvEsFWSu/CChU v3L5I3m4JQfYCVxAmNcYNfFtEiNGF+Vq0Ru58rF4C8H6ArkVlluV+TMpp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsGAHaAx1CrRDoG/2dsb2JhbABEg0i6fRZzgh4BAQEDAQgCMDQLBQcBAwIJEQQBAQEnBxktCQgCBAEJCQsFh3sFqyWQWoxKhEMDiGCFHIgLkEiDFA X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="66219457" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Dec 2012 18:53:31 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBIrUKZ020842; Tue, 11 Dec 2012 18:53:30 GMT From: "Dan Wing" To: , , References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> In-Reply-To: Date: Tue, 11 Dec 2012 10:53:30 -0800 Message-ID: <010501cdd7d0$d02dbc00$70893400$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmAVOm4FeYFs5M0A== Content-Language: en-us Cc: randell@jesup.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 18:53:33 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Markus.Isomaki@nokia.com > Sent: Tuesday, December 11, 2012 2:34 AM > To: salvatore.loreto@ericsson.com; mmusic@ietf.org > Cc: randell@jesup.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > Hi Sal, > > Salvatore Loreto wrote: > > > >based on the current stack the SCTP traffic is the only traffic that > >runs directly over the DTLS stack. > >What I am trying to do is to include the Randell Jesup (I am including > >him in CC as I am not sure he is subscribed to this mailing list) > > suggestion to give the possibility to have multiple SCTP > >*associations* running on top of the same DTLS session and of course > >providing a way to signal it in SDP. > > > >to be clear: at moment WebRTC allows only one SCTP association per PC, > >so this is something that would be nice to define just to be ready for > the future. > > > > It's a bit unclear to me what the benefit of this would be. SCTP itself > allows multiple streams to be transported in parallel within a single > SCTP association. So, in what type of situations would we need multiple > parallel SCTP associations? I thought the main point of SCTP is that it > provides the parallelism and multiplexing by itself. > > In other words: I do understand the desire to multiplex RTP and SCTP > within the same UDP flow, so we can for instance reduce the number of > needed NAT/FW bindings. Sending bulk data (SCTP) and interactive audio/video over the same port will break prioritization of the audio/video flow above the bulk data. > I also understand why multiple independent non- > HOL blocking streams within SCTP are useful for applications. But I > don't yet understand the additional benefit of multiple parallel SCTP > associations. No doubt it can be technically done, but to what purposes? One example: transferring a big file while, at the same time, doing screen sharing or an instant message chat. -d From pkyzivat@alum.mit.edu Tue Dec 11 11:17: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 2D8E121F8467 for ; Tue, 11 Dec 2012 11:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBEXxDONQM5Q for ; Tue, 11 Dec 2012 11:17:37 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6521F84D3 for ; Tue, 11 Dec 2012 11:17:29 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id aByQ1k00B1ei1Bg53KHUvx; Tue, 11 Dec 2012 19:17:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id aKHU1k00u3ZTu2S3kKHUah; Tue, 11 Dec 2012 19:17:28 +0000 Message-ID: <50C786C8.2010403@alum.mit.edu> Date: Tue, 11 Dec 2012 14:17:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> <010401cdd7d0$d006d310$70147930$@cisco.com> In-Reply-To: <010401cdd7d0$d006d310$70147930$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355253448; bh=uFOg5yJvpCHILSfU+JXoEjPlSjbj5woUKmPNPJR9lUk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CROGT78SG7BL3CKh94Ls3RNn4LgEZnWkFak+GXsZoul8cGAD+A2s5TZmgQ7KbmQQv SD/GqxOKAgyxjZbNXZKMNVWs8kesslYW6L2zSGBWGgSeRm9IOXSUh0ACBAOx/KHPIx NM8i+mIn0iZgIZgeUjHElxjRdmt80wAeDYjc4x8sqIpwck+Bcm2jifHiGaXOS1PNmz ZGLeHozmYqiLOmSKzbtv5NgxFUoz91qKSQt92eyfKH++Di6BkjxXeBh8N4Fwp+wsiS fU9bzHyN2OBhQJLKp+kvs29FyqszhSkK1ElxY8I1vDXwy+dJuLaqbl7enK3ozlOyk6 vlZQ/vrfSA+tQ== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 19:17:38 -0000 Hi Dan, Comments inline On 12/11/12 1:53 PM, Dan Wing wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, December 11, 2012 7:43 AM >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >> >> More inline. >> >> On 12/11/12 4:08 AM, Salvatore Loreto wrote: >>> Hi Paul, >>> >>> see in line! >>> >>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: >>>> Commenting on a different point >>>> >>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: >>>> >>>>> The interesting difference is that the multiplexing between >>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP traffic >>>>> is not carried in SSRCs, which means: >>>>> >>>>> - There can be only one DTLS/SCTP stream in a bundle (which may have >>>>> multiple associations, as you state below); you can't have multiple >>>>> lines with proto DTLS/SCTP in a bundle. >>>> >>>> I am not an SCTP expert. But IIUC, SCTP was designed to run directly >>>> over IP. It has its own notion of port used to demux multiple SCTP >>>> associations over the same IP address. >>>> >>>> I presume that that same mechanism is still there when SCTP is run >>>> over DTLS over UDP. >>>> >>>> So, the traffic coming over DTLS must first be demuxed into RTP >>>> traffic and SCTP traffic. >>> based on the current stack the SCTP traffic is the only traffic that >>> runs directly over the DTLS stack. >> >> Yes, that is what I thought. But Harald has been asking about >> multiplexing this with RTP traffic. (Actually I think it would be >> DTLS/SRTP traffic that it would be multiplexed with.) >> >>> What I am trying to do is to include the Randell Jesup (I am including >>> him in CC as I am not sure he is subscribed to this mailing list) >>> suggestion to give the possibility to have multiple SCTP >>> *associations* running on top of the same DTLS session and of course >>> providing a way to signal it in SDP. >> >> IIUC, SCTP (having been designed as a transport layer protocol) defines >> its own notion of port, and has fields in its protocol to carry the >> local and remote port number. Presumably those fields are still there >> when run over UDP or DTLS. So it should be possible to support multiple >> SCTP associations over the same DTLS connection, each distinguished by >> its own port pair. > > Yes, SCTP has its own notion of ports. How this works when SCTP is > carried over UDP is not quite clear, especially because SCTP assumes > a NAPT will not rewrite the SCTP port number (SCTP endeavors to make > such port rewriting difficult). But of course a NAPT (and the MAP > techniques) rewrite UDP port numbers. I believe SCTP would only be > able to successfully convey its UDP port numbers for a device that > is not behind a NAT (that is, a server sitting directly on the > Internet, rather than a remote peer that is behind a NAT). Creative > use of PCP, NAT-PMP, or UPnP IGD would improve that situation in > the future. I find what you say above confusing. SCTP running naked over IP would still have its own ports. If that ran over a path with a NAPT, then I could see why the NAPT might want to do the same as it does with UDP and TCP, and so replace addr/port pairs to minimize addr usage. (That's if the NAPT supported SCTP at all - I gather most don't.) But with SCTP over DTLS over UDP, there is a UDP port, and then presumably a separate SCTP port carried in the SCTP protocol within the UDP message. An NAPT on the path would presumably be messing with the UDP port. Given use of DTLS, the NAPT won't even be able to tell that SCTP is being used, much less mess with the SCTP port. >> That of course depends on having a signaling mechanism to set it up. > > After the initial SCTP association is created, SCTP could be allowed > to do its own thing (that is, chose to find and use other ports). Here you are talking about finding and using other UDP addr/port pairs? That is explicitly excluded in the DTLS/SCTP mapping. Thanks, Paul > SCTP's behavior in this regard is similar to MPRTP (multipath RTP), > but of course they are not identical. > >>> to be clear: at moment WebRTC allows only one SCTP association per PC, >>> so this is something that would be nice to define just to be ready for >>> the future. >> >> AFAIK WebRTC is just one possible user of this mechanism. The SDP >> mechanism shouldn't be limited by the constraints of WebRTC. It would be >> very difficult to define the SDP so that it was impossible to set up >> multiple SCTP associations over different 5-tuples. >> >>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic >>>> can be demuxed based on SCTP port. And once the traffic for a single >>>> SCTP port is identified, it can be demuxed based on stream number. >>>> >>>> Representing this in SDP is a challenge. Some variant of the bundle >>>> proposal might allow bundling together several RTP m-lines and some >>>> DTLS/SCTP m-lines. This would require a mechanism for specifying the >>>> SCTP port number - already an open issue (#3) in >>>> draft-ietf-mmusic-sctp-sdp-02. >>> I agree that it is a challange how then to bundle everything together >> >> But it is a challenge that needs to be tackled if we are to realize >> Harald's dream. > > -d > > > From dwing@cisco.com Tue Dec 11 11:25: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 9EBAB21F8482 for ; Tue, 11 Dec 2012 11:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.434 X-Spam-Level: X-Spam-Status: No, score=-110.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nfPeALOo3Eu for ; Tue, 11 Dec 2012 11:25:34 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99821F847C for ; Tue, 11 Dec 2012 11:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6898; q=dns/txt; s=iport; t=1355253934; x=1356463534; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=PiphU//hkfEvvCOgUq+4i03W3BXSVSQgwjpNtmYqYd8=; b=Z3K7DsuuL19zETdokzRfX58S1xsaTBXfOMsrTocHBcIiVOon/Vx3fbVf uXiKoRDDWmbjYSJDC8q4g5Rt9w7xk3w2P/2pB/xaPlkmykhvpfxnBlUye W1+k23JgHfpKgvFsU9no3h6ZZCt//GK8aIznEPUtVcv1mcqJVf7lIKlYd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQHAJyHx1CrRDoG/2dsb2JhbABEDoM6uwYWc4IeAQEBAwEIAjAtBAMEBwUHAQMCCQ4DBAEBAScHGS0JCAIEEwsFh3sFqymQVYxKFYQuA4hghRyIC5BIgjVfgUM X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="66297998" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 11 Dec 2012 19:25:31 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBJPVnc009578; Tue, 11 Dec 2012 19:25:31 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> <010401cdd7d0$d006d310$70147930$@cisco.com> <50C786C8.2010403@alum.mit.edu> In-Reply-To: <50C786C8.2010403@alum.mit.edu> Date: Tue, 11 Dec 2012 11:25:31 -0800 Message-ID: <023f01cdd7d5$48e33c70$daa9b550$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAHHwb56l/rBTqA= Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 19:25:35 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, December 11, 2012 11:17 AM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > Hi Dan, > > Comments inline > > On 12/11/12 1:53 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Tuesday, December 11, 2012 7:43 AM > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >> > >> More inline. > >> > >> On 12/11/12 4:08 AM, Salvatore Loreto wrote: > >>> Hi Paul, > >>> > >>> see in line! > >>> > >>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >>>> Commenting on a different point > >>>> > >>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >>>> > >>>>> The interesting difference is that the multiplexing between > >>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP > >>>>> traffic is not carried in SSRCs, which means: > >>>>> > >>>>> - There can be only one DTLS/SCTP stream in a bundle (which may > >>>>> have multiple associations, as you state below); you can't have > >>>>> multiple lines with proto DTLS/SCTP in a bundle. > >>>> > >>>> I am not an SCTP expert. But IIUC, SCTP was designed to run > >>>> directly over IP. It has its own notion of port used to demux > >>>> multiple SCTP associations over the same IP address. > >>>> > >>>> I presume that that same mechanism is still there when SCTP is run > >>>> over DTLS over UDP. > >>>> > >>>> So, the traffic coming over DTLS must first be demuxed into RTP > >>>> traffic and SCTP traffic. > >>> based on the current stack the SCTP traffic is the only traffic that > >>> runs directly over the DTLS stack. > >> > >> Yes, that is what I thought. But Harald has been asking about > >> multiplexing this with RTP traffic. (Actually I think it would be > >> DTLS/SRTP traffic that it would be multiplexed with.) > >> > >>> What I am trying to do is to include the Randell Jesup (I am > >>> including him in CC as I am not sure he is subscribed to this > mailing list) > >>> suggestion to give the possibility to have multiple SCTP > >>> *associations* running on top of the same DTLS session and of > >>> course providing a way to signal it in SDP. > >> > >> IIUC, SCTP (having been designed as a transport layer protocol) > >> defines its own notion of port, and has fields in its protocol to > >> carry the local and remote port number. Presumably those fields are > >> still there when run over UDP or DTLS. So it should be possible to > >> support multiple SCTP associations over the same DTLS connection, > >> each distinguished by its own port pair. > > > > Yes, SCTP has its own notion of ports. How this works when SCTP is > > carried over UDP is not quite clear, especially because SCTP assumes a > > NAPT will not rewrite the SCTP port number (SCTP endeavors to make > > such port rewriting difficult). But of course a NAPT (and the MAP > > techniques) rewrite UDP port numbers. I believe SCTP would only be > > able to successfully convey its UDP port numbers for a device that is > > not behind a NAT (that is, a server sitting directly on the Internet, > > rather than a remote peer that is behind a NAT). Creative use of PCP, > > NAT-PMP, or UPnP IGD would improve that situation in the future. > > I find what you say above confusing. It is confusing, because SCTP's specifications require different things of a NAPT than UDP, TCP, or DCCP. Specifically, SCTP's specifications require the NAPT to not rewrite (not change) the source port number of outgoing SCTP-over-IP packets. Reference draft-ietf-behave-sctpnat. > SCTP running naked over IP would still have its own ports. > If that ran over a path with a NAPT, then I could see why the NAPT might > want to do the same as it does with UDP and TCP, and so replace > addr/port pairs to minimize addr usage. (That's if the NAPT supported > SCTP at all - I gather most don't.) I am not aware of any shipping NAPT that supports SCTP. > But with SCTP over DTLS over UDP, there is a UDP port, and then > presumably a separate SCTP port carried in the SCTP protocol within the > UDP message. Right. And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some relationship, but I do not understand how it works. Reference draft-ietf-tsvwg-sctp-udp-encaps. > An NAPT on the path would presumably be messing with the UDP port. Given > use of DTLS, the NAPT won't even be able to tell that SCTP is being > used, much less mess with the SCTP port. Right. > >> That of course depends on having a signaling mechanism to set it up. > > > > After the initial SCTP association is created, SCTP could be allowed > > to do its own thing (that is, chose to find and use other ports). > > Here you are talking about finding and using other UDP addr/port pairs? Yes, for mobility. > That is explicitly excluded in the DTLS/SCTP mapping. I am thinking about where to layer mobility and multipath for RTP (MPRTP) and for SCTP. Do we do that with MICE (draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself? If we do it with MICE, we need to disable or prevent SCTP from adding / removing interfaces itself, which is why SCTP includes its own ability to signal IP addresses and ports in SCTP itself. -d > Thanks, > Paul > > > SCTP's behavior in this regard is similar to MPRTP (multipath RTP), > > but of course they are not identical. > > > >>> to be clear: at moment WebRTC allows only one SCTP association per > >>> PC, so this is something that would be nice to define just to be > >>> ready for the future. > >> > >> AFAIK WebRTC is just one possible user of this mechanism. The SDP > >> mechanism shouldn't be limited by the constraints of WebRTC. It would > >> be very difficult to define the SDP so that it was impossible to set > >> up multiple SCTP associations over different 5-tuples. > >> > >>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic > >>>> can be demuxed based on SCTP port. And once the traffic for a > >>>> single SCTP port is identified, it can be demuxed based on stream > number. > >>>> > >>>> Representing this in SDP is a challenge. Some variant of the bundle > >>>> proposal might allow bundling together several RTP m-lines and some > >>>> DTLS/SCTP m-lines. This would require a mechanism for specifying > >>>> the SCTP port number - already an open issue (#3) in > >>>> draft-ietf-mmusic-sctp-sdp-02. > >>> I agree that it is a challange how then to bundle everything > >>> together > >> > >> But it is a challenge that needs to be tackled if we are to realize > >> Harald's dream. > > > > -d > > > > > > From pkyzivat@alum.mit.edu Tue Dec 11 11:26:57 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 5242F21F84F3 for ; Tue, 11 Dec 2012 11:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hTpKDSx1ZDT for ; Tue, 11 Dec 2012 11:26:56 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 9869521F8482 for ; Tue, 11 Dec 2012 11:26:56 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id aKQ81k0050ldTLk5EKSwKT; Tue, 11 Dec 2012 19:26:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id aKSv1k00o3ZTu2S3QKSvew; Tue, 11 Dec 2012 19:26:55 +0000 Message-ID: <50C788FE.6000505@alum.mit.edu> Date: Tue, 11 Dec 2012 14:26:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <010501cdd7d0$d02dbc00$70893400$@cisco.com> In-Reply-To: <010501cdd7d0$d02dbc00$70893400$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355254016; bh=K6sgng+92qFZMgp0a2vCfa7AgaD+z9oALGzdYGINjgw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NC/oqo0RMIggujGavgYb0anQ+/TQGlOmM0ptNDntgIkW6w9BTwcuQn1Ypo+KHg0vU U9dHWsMXlGTJZjQC3uakYtiAzS2tR+l7d8QgGheCarspgbNgXJZ4bZqOo7rtstYFs9 sOjYRVXLzF+YS3wmBoOkrzZLArgSnckp3pE8GU+V95J7tQxh6fFLi5bGX46q5iXZxq zDXXt7E67X8AO8jQjVEhnextihaUub9Ljt4Paykkyvv3xdT6O07Rb3sn5VAA1pRG4L tJS9rbMFaIRq+G3fupCE4BXnYNMVoRh2p1uNVEuXEZuXjkcKchrBJtx1Ymqq7Afiv8 IAsCIyDUQSEcQ== Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 19:26:57 -0000 On 12/11/12 1:53 PM, Dan Wing wrote: >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Markus.Isomaki@nokia.com >> Sent: Tuesday, December 11, 2012 2:34 AM >> To: salvatore.loreto@ericsson.com; mmusic@ietf.org >> Cc: randell@jesup.org >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >> >> Hi Sal, >> >> Salvatore Loreto wrote: >>> >>> based on the current stack the SCTP traffic is the only traffic that >>> runs directly over the DTLS stack. >>> What I am trying to do is to include the Randell Jesup (I am including >>> him in CC as I am not sure he is subscribed to this mailing list) >>> suggestion to give the possibility to have multiple SCTP >>> *associations* running on top of the same DTLS session and of course >>> providing a way to signal it in SDP. >>> >>> to be clear: at moment WebRTC allows only one SCTP association per PC, >>> so this is something that would be nice to define just to be ready for >> the future. >>> >> >> It's a bit unclear to me what the benefit of this would be. SCTP itself >> allows multiple streams to be transported in parallel within a single >> SCTP association. So, in what type of situations would we need multiple >> parallel SCTP associations? I thought the main point of SCTP is that it >> provides the parallelism and multiplexing by itself. >> >> In other words: I do understand the desire to multiplex RTP and SCTP >> within the same UDP flow, so we can for instance reduce the number of >> needed NAT/FW bindings. > > Sending bulk data (SCTP) and interactive audio/video over the same port > will break prioritization of the audio/video flow above the bulk data. Yeah, probably. In theory you could use DSCP to mark the packets differently. This indeed might be a reason to *not* multiplex the SCTP association for data channels with the media. Assuming we find a way to do that multiplexing, this would be an argument for making that multiplexing *optional*. >> I also understand why multiple independent non- >> HOL blocking streams within SCTP are useful for applications. But I >> don't yet understand the additional benefit of multiple parallel SCTP >> associations. No doubt it can be technically done, but to what purposes? > > One example: transferring a big file while, at the same time, doing > screen sharing or an instant message chat. When using DTLS/SCTP this is an argument for using SCTP associations over separate DTLS connections. Two SCTP associations (differing by SCTP port) over the same DTLS connection wouldn't solve this problem. Thanks, Paul From pkyzivat@alum.mit.edu Tue Dec 11 12:20: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 E7B5711E8099 for ; Tue, 11 Dec 2012 12:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRcBTrB0D4Iq for ; Tue, 11 Dec 2012 12:20:05 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB811E8097 for ; Tue, 11 Dec 2012 12:20:04 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id aKve1k0031ZXKqc57LL4rD; Tue, 11 Dec 2012 20:20:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id aLL31k01Y3ZTu2S3hLL4SW; Tue, 11 Dec 2012 20:20:04 +0000 Message-ID: <50C79573.1000007@alum.mit.edu> Date: Tue, 11 Dec 2012 15:20:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> <010401cdd7d0$d006d310$70147930$@cisco.com> <50C786C8.2010403@alum.mit.edu> <023f01cdd7d5$48e33c70$daa9b550$@cisco.com> In-Reply-To: <023f01cdd7d5$48e33c70$daa9b550$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355257204; bh=yy8UseKF1wAPGL59KFeelhANl9zP7wqOnQO9IFK8bn0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RO+tn9c/UUIVoltg/DwLK57l0jXyEL3yLliqEjGrxC/0Z448+8tTkchBp12TydR2J MU8oQYRwlBQS6rc5suMUvp3BE9LWyVt+7cuZUsADVfquiknb+NcjVGweolIgmUDlOv prB5t8YZ+bWsgjF3am0tJdjZlB9/M4RfLQdh/a7z7W1KQfK9YR7FW6i1f8dDx7LhmO ozh9KwKIIE/DZvDkJv14tW3YaTs2FQ98Ak9p71IPNkDZqExHpvJCrCNsK6htFe46OV hOaTZtB3hStecikBnpT6rREevdjda+p6ERDvG6QSmVzXT1QL/27WpKysDw0+ZAlNw8 Z1FcZH5APBjIw== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 20:20:06 -0000 Inline On 12/11/12 2:25 PM, Dan Wing wrote: >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, December 11, 2012 11:17 AM >> To: Dan Wing >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >> >> Hi Dan, >> >> Comments inline >> >> On 12/11/12 1:53 PM, Dan Wing wrote: >>>> -----Original Message----- >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Tuesday, December 11, 2012 7:43 AM >>>> To: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? >>>> >>>> More inline. >>>> >>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: >>>>> Hi Paul, >>>>> >>>>> see in line! >>>>> >>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: >>>>>> Commenting on a different point >>>>>> >>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: >>>>>> >>>>>>> The interesting difference is that the multiplexing between >>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP >>>>>>> traffic is not carried in SSRCs, which means: >>>>>>> >>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may >>>>>>> have multiple associations, as you state below); you can't have >>>>>>> multiple lines with proto DTLS/SCTP in a bundle. >>>>>> >>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run >>>>>> directly over IP. It has its own notion of port used to demux >>>>>> multiple SCTP associations over the same IP address. >>>>>> >>>>>> I presume that that same mechanism is still there when SCTP is run >>>>>> over DTLS over UDP. >>>>>> >>>>>> So, the traffic coming over DTLS must first be demuxed into RTP >>>>>> traffic and SCTP traffic. >>>>> based on the current stack the SCTP traffic is the only traffic that >>>>> runs directly over the DTLS stack. >>>> >>>> Yes, that is what I thought. But Harald has been asking about >>>> multiplexing this with RTP traffic. (Actually I think it would be >>>> DTLS/SRTP traffic that it would be multiplexed with.) >>>> >>>>> What I am trying to do is to include the Randell Jesup (I am >>>>> including him in CC as I am not sure he is subscribed to this >> mailing list) >>>>> suggestion to give the possibility to have multiple SCTP >>>>> *associations* running on top of the same DTLS session and of >>>>> course providing a way to signal it in SDP. >>>> >>>> IIUC, SCTP (having been designed as a transport layer protocol) >>>> defines its own notion of port, and has fields in its protocol to >>>> carry the local and remote port number. Presumably those fields are >>>> still there when run over UDP or DTLS. So it should be possible to >>>> support multiple SCTP associations over the same DTLS connection, >>>> each distinguished by its own port pair. >>> >>> Yes, SCTP has its own notion of ports. How this works when SCTP is >>> carried over UDP is not quite clear, especially because SCTP assumes a >>> NAPT will not rewrite the SCTP port number (SCTP endeavors to make >>> such port rewriting difficult). But of course a NAPT (and the MAP >>> techniques) rewrite UDP port numbers. I believe SCTP would only be >>> able to successfully convey its UDP port numbers for a device that is >>> not behind a NAT (that is, a server sitting directly on the Internet, >>> rather than a remote peer that is behind a NAT). Creative use of PCP, >>> NAT-PMP, or UPnP IGD would improve that situation in the future. >> >> I find what you say above confusing. > > It is confusing, because SCTP's specifications require different > things of a NAPT than UDP, TCP, or DCCP. Specifically, SCTP's > specifications require the NAPT to not rewrite (not change) the > source port number of outgoing SCTP-over-IP packets. Reference > draft-ietf-behave-sctpnat. > >> SCTP running naked over IP would still have its own ports. >> If that ran over a path with a NAPT, then I could see why the NAPT might >> want to do the same as it does with UDP and TCP, and so replace >> addr/port pairs to minimize addr usage. (That's if the NAPT supported >> SCTP at all - I gather most don't.) > > I am not aware of any shipping NAPT that supports SCTP. > > >> But with SCTP over DTLS over UDP, there is a UDP port, and then >> presumably a separate SCTP port carried in the SCTP protocol within the >> UDP message. > > Right. > > And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some > relationship, but I do not understand how it works. Reference > draft-ietf-tsvwg-sctp-udp-encaps. 1) draft-ietf-tsvwg-sctp-udp-encaps doesn't seem to cover SCTP over DTLS 2) I guess that would only apply for a kernel implementation of SCTP over UDP, accessed via the socket interface. So I don't think it is relevant for the immediate future plans for user mode implementations over UDP. >> An NAPT on the path would presumably be messing with the UDP port. Given >> use of DTLS, the NAPT won't even be able to tell that SCTP is being >> used, much less mess with the SCTP port. > > Right. > >>>> That of course depends on having a signaling mechanism to set it up. >>> >>> After the initial SCTP association is created, SCTP could be allowed >>> to do its own thing (that is, chose to find and use other ports). >> >> Here you are talking about finding and using other UDP addr/port pairs? > > Yes, for mobility. > >> That is explicitly excluded in the DTLS/SCTP mapping. > > I am thinking about where to layer mobility and multipath for RTP > (MPRTP) and for SCTP. Do we do that with MICE > (draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself? If > we do it with MICE, we need to disable or prevent SCTP from adding > / removing interfaces itself, which is why SCTP includes its own > ability to signal IP addresses and ports in SCTP itself. OK. That will require extensions here and there over what drafts currently say. Thanks, Paul > -d > > >> Thanks, >> Paul >> >>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP), >>> but of course they are not identical. >>> >>>>> to be clear: at moment WebRTC allows only one SCTP association per >>>>> PC, so this is something that would be nice to define just to be >>>>> ready for the future. >>>> >>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP >>>> mechanism shouldn't be limited by the constraints of WebRTC. It would >>>> be very difficult to define the SDP so that it was impossible to set >>>> up multiple SCTP associations over different 5-tuples. >>>> >>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP traffic >>>>>> can be demuxed based on SCTP port. And once the traffic for a >>>>>> single SCTP port is identified, it can be demuxed based on stream >> number. >>>>>> >>>>>> Representing this in SDP is a challenge. Some variant of the bundle >>>>>> proposal might allow bundling together several RTP m-lines and some >>>>>> DTLS/SCTP m-lines. This would require a mechanism for specifying >>>>>> the SCTP port number - already an open issue (#3) in >>>>>> draft-ietf-mmusic-sctp-sdp-02. >>>>> I agree that it is a challange how then to bundle everything >>>>> together >>>> >>>> But it is a challenge that needs to be tackled if we are to realize >>>> Harald's dream. >>> >>> -d >>> >>> >>> > > From dwing@cisco.com Tue Dec 11 12:53: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 631D221F84D9 for ; Tue, 11 Dec 2012 12:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJy5gHIo98R2 for ; Tue, 11 Dec 2012 12:53:20 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 77A0C21F84DE for ; Tue, 11 Dec 2012 12:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8644; q=dns/txt; s=iport; t=1355259200; x=1356468800; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6UUrqZB8WbjenAuM3HbdPSepGvDw54mdNNSTU80rwPY=; b=hSXIxga8V6ahhUHNWLaB7At91AA1NORRjq8y5JZI0LYv/JM6EILhLC50 SRZGKP6sE76c8hWJxccJMlWD8L9rM1DLUURreQU2N74fbJ0D3I9UQvZ2T Wfe+efY9j+/wTTMdLpvR2Dcq2yTy9dTnW70KLBRJw0TRXm0PUCbHa8HGv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQHAFycx1CrRDoH/2dsb2JhbABEDoM6uwYWc4IeAQEBAwEIAjAtBAMEBwUHAQMCCQ4DBAEBAScHGS0JCAIEEwsFh3sFqy+QTYxKFYQuA4hghRyIC5BIgjVfgUM X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="63729389" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Dec 2012 20:53:20 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBBKrJPq004760; Tue, 11 Dec 2012 20:53:19 GMT From: "Dan Wing" To: "'Paul Kyzivat'" References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <50C7548C.3090807@alum.mit.edu> <010401cdd7d0$d006d310$70147930$@cisco.com> <50C786C8.2010403@alum.mit.edu> <023f01cdd7d5$48e33c70$daa9b550$@cisco.com> <50C79573.1000007@alum.mit.edu> In-Reply-To: <50C79573.1000007@alum.mit.edu> Date: Tue, 11 Dec 2012 12:53:19 -0800 Message-ID: <02b001cdd7e1$8d2184d0$a7648e70$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlNUoiDi8ItBUA8zunPWFLx+5pWALXFbmGAbkvJqYBA93guALjhCBmATyC1jQB06oIXAHHwb56AgT7b64BylS47pfcX3zw Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 20:53:21 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, December 11, 2012 12:20 PM > To: Dan Wing > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > > Inline > > On 12/11/12 2:25 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Tuesday, December 11, 2012 11:17 AM > >> To: Dan Wing > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >> > >> Hi Dan, > >> > >> Comments inline > >> > >> On 12/11/12 1:53 PM, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Tuesday, December 11, 2012 7:43 AM > >>>> To: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? > >>>> > >>>> More inline. > >>>> > >>>> On 12/11/12 4:08 AM, Salvatore Loreto wrote: > >>>>> Hi Paul, > >>>>> > >>>>> see in line! > >>>>> > >>>>> On 12/3/12 10:00 PM, Paul Kyzivat wrote: > >>>>>> Commenting on a different point > >>>>>> > >>>>>> On 12/1/12 9:53 AM, Harald Alvestrand wrote: > >>>>>> > >>>>>>> The interesting difference is that the multiplexing between > >>>>>>> DTLS/SCTP traffic and BUNDLE multiplexing is that DTLS/SCTP > >>>>>>> traffic is not carried in SSRCs, which means: > >>>>>>> > >>>>>>> - There can be only one DTLS/SCTP stream in a bundle (which may > >>>>>>> have multiple associations, as you state below); you can't have > >>>>>>> multiple lines with proto DTLS/SCTP in a bundle. > >>>>>> > >>>>>> I am not an SCTP expert. But IIUC, SCTP was designed to run > >>>>>> directly over IP. It has its own notion of port used to demux > >>>>>> multiple SCTP associations over the same IP address. > >>>>>> > >>>>>> I presume that that same mechanism is still there when SCTP is > >>>>>> run over DTLS over UDP. > >>>>>> > >>>>>> So, the traffic coming over DTLS must first be demuxed into RTP > >>>>>> traffic and SCTP traffic. > >>>>> based on the current stack the SCTP traffic is the only traffic > >>>>> that runs directly over the DTLS stack. > >>>> > >>>> Yes, that is what I thought. But Harald has been asking about > >>>> multiplexing this with RTP traffic. (Actually I think it would be > >>>> DTLS/SRTP traffic that it would be multiplexed with.) > >>>> > >>>>> What I am trying to do is to include the Randell Jesup (I am > >>>>> including him in CC as I am not sure he is subscribed to this > >> mailing list) > >>>>> suggestion to give the possibility to have multiple SCTP > >>>>> *associations* running on top of the same DTLS session and of > >>>>> course providing a way to signal it in SDP. > >>>> > >>>> IIUC, SCTP (having been designed as a transport layer protocol) > >>>> defines its own notion of port, and has fields in its protocol to > >>>> carry the local and remote port number. Presumably those fields are > >>>> still there when run over UDP or DTLS. So it should be possible to > >>>> support multiple SCTP associations over the same DTLS connection, > >>>> each distinguished by its own port pair. > >>> > >>> Yes, SCTP has its own notion of ports. How this works when SCTP is > >>> carried over UDP is not quite clear, especially because SCTP assumes > >>> a NAPT will not rewrite the SCTP port number (SCTP endeavors to make > >>> such port rewriting difficult). But of course a NAPT (and the MAP > >>> techniques) rewrite UDP port numbers. I believe SCTP would only be > >>> able to successfully convey its UDP port numbers for a device that > >>> is not behind a NAT (that is, a server sitting directly on the > >>> Internet, rather than a remote peer that is behind a NAT). Creative > >>> use of PCP, NAT-PMP, or UPnP IGD would improve that situation in the > future. > >> > >> I find what you say above confusing. > > > > It is confusing, because SCTP's specifications require different > > things of a NAPT than UDP, TCP, or DCCP. Specifically, SCTP's > > specifications require the NAPT to not rewrite (not change) the source > > port number of outgoing SCTP-over-IP packets. Reference > > draft-ietf-behave-sctpnat. > > > >> SCTP running naked over IP would still have its own ports. > >> If that ran over a path with a NAPT, then I could see why the NAPT > >> might want to do the same as it does with UDP and TCP, and so replace > >> addr/port pairs to minimize addr usage. (That's if the NAPT supported > >> SCTP at all - I gather most don't.) > > > > I am not aware of any shipping NAPT that supports SCTP. > > > > > >> But with SCTP over DTLS over UDP, there is a UDP port, and then > >> presumably a separate SCTP port carried in the SCTP protocol within > >> the UDP message. > > > > Right. > > > > And the new SCTP_REMOTE_UDP_ENCAPS_PORT socket option has some > > relationship, but I do not understand how it works. Reference > > draft-ietf-tsvwg-sctp-udp-encaps. > > 1) draft-ietf-tsvwg-sctp-udp-encaps doesn't seem to cover SCTP over DTLS Agreed. > 2) I guess that would only apply for a kernel implementation of SCTP > over UDP, accessed via the socket interface. > So I don't think it is relevant for the immediate future plans for user > mode implementations over UDP. The SCTP_REMOTE_UDP_ENCAPS_PORT socket option should work fine with user-mode SCTP over UDP. It causes the SCTP stack to send that additional (meta) data to the remote peer. > >> An NAPT on the path would presumably be messing with the UDP port. > >> Given use of DTLS, the NAPT won't even be able to tell that SCTP is > >> being used, much less mess with the SCTP port. > > > > Right. > > > >>>> That of course depends on having a signaling mechanism to set it > up. > >>> > >>> After the initial SCTP association is created, SCTP could be allowed > >>> to do its own thing (that is, chose to find and use other ports). > >> > >> Here you are talking about finding and using other UDP addr/port > pairs? > > > > Yes, for mobility. > > > >> That is explicitly excluded in the DTLS/SCTP mapping. > > > > I am thinking about where to layer mobility and multipath for RTP > > (MPRTP) and for SCTP. Do we do that with MICE > > (draft-wing-mmusic-ice-mobility) or does SCTP do mobility itself? If > > we do it with MICE, we need to disable or prevent SCTP from adding / > > removing interfaces itself, which is why SCTP includes its own ability > > to signal IP addresses and ports in SCTP itself. > > OK. That will require extensions here and there over what drafts > currently say. Yes. But the greater question is how does the industry want such mobility to function when the mobility can be instantiated or disabled at different layers of this deep X-over-Y stack of tunneled protocols. That decision has a pretty significant impact on SDP, especially if we want to follow DTLS-SRTP's lead of using "UDP/TLS/RTP/SAVP" of enumerating every layer in the tunnels. -d > Thanks, > Paul > > > -d > > > > > >> Thanks, > >> Paul > >> > >>> SCTP's behavior in this regard is similar to MPRTP (multipath RTP), > >>> but of course they are not identical. > >>> > >>>>> to be clear: at moment WebRTC allows only one SCTP association per > >>>>> PC, so this is something that would be nice to define just to be > >>>>> ready for the future. > >>>> > >>>> AFAIK WebRTC is just one possible user of this mechanism. The SDP > >>>> mechanism shouldn't be limited by the constraints of WebRTC. It > >>>> would be very difficult to define the SDP so that it was impossible > >>>> to set up multiple SCTP associations over different 5-tuples. > >>>> > >>>>>> Then the RTP traffic can be demuxed based on SSRC, and SCTP > >>>>>> traffic can be demuxed based on SCTP port. And once the traffic > >>>>>> for a single SCTP port is identified, it can be demuxed based on > >>>>>> stream > >> number. > >>>>>> > >>>>>> Representing this in SDP is a challenge. Some variant of the > >>>>>> bundle proposal might allow bundling together several RTP m-lines > >>>>>> and some DTLS/SCTP m-lines. This would require a mechanism for > >>>>>> specifying the SCTP port number - already an open issue (#3) in > >>>>>> draft-ietf-mmusic-sctp-sdp-02. > >>>>> I agree that it is a challange how then to bundle everything > >>>>> together > >>>> > >>>> But it is a challenge that needs to be tackled if we are to realize > >>>> Harald's dream. > >>> > >>> -d > >>> > >>> > >>> > > > > From randell-ietf@jesup.org Tue Dec 11 14:50:01 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 1DCE021F879F for ; Tue, 11 Dec 2012 14:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzQnWBLPh65S for ; Tue, 11 Dec 2012 14:50:00 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8C32321F878B for ; Tue, 11 Dec 2012 14:50:00 -0800 (PST) Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:4100 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TiYeE-000CWv-Nm; Tue, 11 Dec 2012 16:49:58 -0600 Message-ID: <50C7B85D.7080906@jesup.org> Date: Tue, 11 Dec 2012 17:49:01 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dan Wing References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <010501cdd7d0$d02dbc00$70893400$@cisco.com> In-Reply-To: <010501cdd7d0$d02dbc00$70893400$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 22:50:01 -0000 On 12/11/2012 1:53 PM, Dan Wing wrote: >> >> to be clear: at moment WebRTC allows only one SCTP association per PC, >> so this is something that would be nice to define just to be ready for >> the future. Right. We're defining SDP for SCTP here, not *just* for WebRTC. (and direct use of rtcweb without WebRTC could allow for multiple associations in theory). >> It's a bit unclear to me what the benefit of this would be. SCTP itself >> allows multiple streams to be transported in parallel within a single >> SCTP association. So, in what type of situations would we need multiple >> parallel SCTP associations? I thought the main point of SCTP is that it >> provides the parallelism and multiplexing by itself. >> >> In other words: I do understand the desire to multiplex RTP and SCTP >> within the same UDP flow, so we can for instance reduce the number of >> needed NAT/FW bindings. > Sending bulk data (SCTP) and interactive audio/video over the same port > will break prioritization of the audio/video flow above the bulk data. For the general case, you could provide different DSCP markings, etc, per Dan's suggestion. And also you could run different protocols on top of SCTP, each in an association. One could run DataChannels, another could run BFCP, etc. That way they don't conflict (in how they allocate streams, etc). >> I also understand why multiple independent non- >> HOL blocking streams within SCTP are useful for applications. But I >> don't yet understand the additional benefit of multiple parallel SCTP >> associations. No doubt it can be technically done, but to what purposes? > One example: transferring a big file while, at the same time, doing > screen sharing or an instant message chat. Right - until we create a new draft, there are buffer-hogging issues with large transfers (transfer a 270MB file, like I did at IETF, and all other streams are starved until the transfer finishes). Separate associations would also deal with the case without needing draft. (We'll want the draft for rtcweb). They might use different congestion priorities, etc. -- Randell Jesup randell-ietf@jesup.org From matthew@matthew.at Tue Dec 11 15:12: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 5E84D21E8091 for ; Tue, 11 Dec 2012 15:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAm4cWodEfs7 for ; Tue, 11 Dec 2012 15:12:20 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DBA21E8090 for ; Tue, 11 Dec 2012 15:12:20 -0800 (PST) Received: from [10.252.226.81] (unknown [198.134.88.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 90CF8148068 for ; Tue, 11 Dec 2012 15:12:18 -0800 (PST) Message-ID: <50C7BDCA.6090704@matthew.at> Date: Tue, 11 Dec 2012 15:12:10 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: <5093A2C9.9040001@alvestrand.no> <50B9E3ED.6010604@ericsson.com> <50BA19F9.4040701@alvestrand.no> <50BD04D2.7090207@alum.mit.edu> <50C6F800.1080500@ericsson.com> <010501cdd7d0$d02dbc00$70893400$@cisco.com> In-Reply-To: <010501cdd7d0$d02dbc00$70893400$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] SCTP question: Where does it multiplex? 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, 11 Dec 2012 23:12:21 -0000 On 12/11/2012 10:53 AM, Dan Wing wrote: > Sending bulk data (SCTP) and interactive audio/video over the same port > will break prioritization of the audio/video flow above the bulk data. In Lyon, we made the assertion that a browser network stack MUST be able to maintain a common congestion state that is shared between the various streams (1 or more RTP, at least 1 SCTP, etc.) and which is used to prioritize the dispatching of packets onto the network appropriate across at least 3 (I recommended 4) priority levels. This is *in addition* to the idea that these 3 (or 4) levels are also diffserv marked in a way that the network can apply different treatments to them. (I recommended at least 4 levels to cover data-that-is-more-important-than-anything, audio, video, and data-that-is-less-important-than-anything) > >> I also understand why multiple independent non- >> HOL blocking streams within SCTP are useful for applications. But I >> don't yet understand the additional benefit of multiple parallel SCTP >> associations. No doubt it can be technically done, but to what purposes? > One example: transferring a big file while, at the same time, doing > screen sharing or an instant message chat. The fact that SCTP also suffers from a head-of-line blocking issue because its flow control is per-association not per-flow (ref: http://www.ietf.org/mail-archive/web/rtcweb/current/msg02787.html ) does suggest that until that is resolved one might want to use >1 SCTP association between peers as well. Matthew Kaufman From matthew@matthew.at Tue Dec 11 15:16: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 C5A0621E8096 for ; Tue, 11 Dec 2012 15:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvDZq-PRAsga for ; Tue, 11 Dec 2012 15:16:29 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449021E808D for ; Tue, 11 Dec 2012 15:16:29 -0800 (PST) Received: from [10.252.226.81] (unknown [198.134.88.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 69DC3148068 for ; Tue, 11 Dec 2012 15:16:29 -0800 (PST) Message-ID: <50C7BECB.7050802@matthew.at> Date: Tue, 11 Dec 2012 15:16:27 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000407000307080104090209" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff 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, 11 Dec 2012 23:16:30 -0000 This is a multi-part message in MIME format. --------------000407000307080104090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/8/2012 3:21 PM, Eric Rescorla wrote: > +rtcweb > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > > wrote: > > > I was looking over everything that needs to be completed to finish > a fist cut of the WebRTC related work. There are a handful of big > SDP problems that are currently blocking some of the WebRTC work > and I'd like to figure out how to make some progress on them. > > Let me loosely characterize them as > > 1) If we have several video streams, how do theses map up to 1 or > more m lines. > > 2) if we are doing port multiplexing, what does the SDP look like > (the bundle problem) > > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP > > 3) SDP for application running over SCTP/DTLS > > > I don't want to speak for all the various chairs but I am under > the impression that most of chairs of related groups in W3C and > IETF believe these are issues that need to be resolved primarily > in the MMUSIC WG and that they impact both WebRTC and CLUE as well > as the general long term use of SDP in SIP and other protocols. > > I'd like to get some discussion going on how we can make some > progress on these. I don't think we are going to solve these in 20 > minutes of discussion at an IETF meeting so I think we probably > need some interim (virtual or face to face) to sort this out. > > Thoughts? > > > Wow, I'm totally confused here. > > I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > IMO the lack of clarity around how to encode various media > configurations into SDP is the major thing blocking progress here. In > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or > multiple m-line variety) until the SDP for it is well-defined. The > same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks. > > We really need to cover these issues in the interim. > > -Ekr > > We only need to cover these issues soon if RTCWEB continues to insist that SDP is a good idea for an API *and* that changes to SDP are necessary in order for RTCWEB to then be successful. I would posit that if SDP as used in (and referenced from) RFC3264 was the appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would be required in order to ship RTCWEB 1.0. Matthew Kaufman --------------000407000307080104090209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/8/2012 3:21 PM, Eric Rescorla wrote:
+rtcweb

On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

I was looking over everything that needs to be completed to finish a fist cut of the WebRTC related work. There are a handful of big SDP problems that are currently blocking some of the WebRTC work and I'd like to figure out how to make some progress on them.

Let me loosely characterize them as

1) If we have several video streams, how do theses map up to 1 or more m lines.

2) if we are doing port multiplexing, what does the SDP look like (the bundle problem)

3) How do we map the RTCWeb track and stream label concepts to identifiers in SDP

3) SDP for application running over SCTP/DTLS

I don't want to speak for all the various chairs but I am under the impression that most of chairs of related groups in W3C and IETF believe these are issues that need to be resolved primarily in the MMUSIC WG and that they impact both WebRTC and CLUE as well as the general long term use of SDP in SIP and other protocols.

I'd like to get some discussion going on how we can make some progress on these. I don't think we are going to solve these in 20 minutes of discussion at an IETF meeting so I think we probably need some interim (virtual or face to face) to sort this out.

Thoughts?

Wow, I'm totally confused here.

I had assumed that the SDP-related issues were going to be the main
topics at the WebRTC/RTCWEB interim in January. Is that not the case?

IMO the lack of clarity around how to encode various media
configurations into SDP is the major thing blocking progress here. In
particular, Firefox has opted not to implement multiplexing of media
streams over the same transport flow (whether of the bundle or
multiple m-line variety) until the SDP for it is well-defined. The
same thing applies to the question of how to map multiple m-lines to
incoming MediaStreams/Tracks.

We really need to cover these issues in the interim.

-Ekr



We only need to cover these issues soon if RTCWEB continues to insist that SDP is a good idea for an API *and* that changes to SDP are necessary in order for RTCWEB to then be successful.

I would posit that if SDP as used in (and referenced from) RFC3264 was the appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would be required in order to ship RTCWEB 1.0.

Matthew Kaufman

--------------000407000307080104090209-- From magnus.westerlund@ericsson.com Wed Dec 12 01:55: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 DE10021F8977 for ; Wed, 12 Dec 2012 01:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.631 X-Spam-Level: X-Spam-Status: No, score=-105.631 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQRw5CozRRqZ for ; Wed, 12 Dec 2012 01:55:34 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F1D3021F8978 for ; Wed, 12 Dec 2012 01:55:31 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-8a-50c8548cd8c0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.89.24873.C8458C05; Wed, 12 Dec 2012 10:55:24 +0100 (CET) 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.279.1; Wed, 12 Dec 2012 10:55:24 +0100 Message-ID: <50C8548B.5040306@ericsson.com> Date: Wed, 12 Dec 2012 10:55:23 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> <5097DF12.2020209@alvestrand.no> <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjW5PyIkAg1WrpCw2zfrCZnGsr4vN YuryxywOzB5XJlxh9ZjyeyOrx5IlP5kCmKO4bFJSczLLUov07RK4Mqb8XsdesIy74tM3lQbG qZxdjJwcEgImEq0HtrJC2GISF+6tZ+ti5OIQEjjJKNE+8zIzhLOcUWLisbMsIFW8AtoSP+5t ZQOxWQRUJY7OfswIYrMJWEjc/NEIFhcV8JWYtecXE0S9oMTJmU/AekUEDCUWTVoHZHNwMAuE SJw6mwESFhbIldh6cxsrxK5VjBIzvrxmBklwCnhLPGvewA5xnaTEommdYHOYBfQkplxtYYSw 5SWat84GqxcCuq2hqYN1AqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cqNNjMDwPbjlt+oOxjvn RA4xSnOwKInzWm/d4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUWqX+VSjqXF3sm/WHLrP d+LvDYOT20JEb6ql3rcM+OvfraZ90beiNubqT57HvDOuZk3QX78kiKvsz4H7faf29M3XPRp9 cXNbUNT5Wz8/ZATOcDIQKeE9/y1/4leNBKkiGfZdlrOOy2e6remMtrrQ0DyjYMn1JMa93y/J Lzt/N+/119J5heE7niuxFGckGmoxFxUnAgD+j9+uLQIAAA== Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 09:55:36 -0000 Hi, Going through old emails. One important comment: On 2012-11-05 21:04, Charles Eckel (eckelcu) wrote: >> >> Last time I looked b=CT was scoped to a whole conference ("supplied for >> the session"), while b=AS was scoped to a single RTP session. But I may >> be misinterpreting RFC 4566 section 5.8. > > I recommend using b=TIAS, as defined in RFC 3890. This parameter may be used at either the session or the media level, and it scope accordingly. > What needs to be avoided is summing up the b=TIAS/AS values from the bundled media lines and using that as that bandwidth for the bundle even if it exceeds the b=TIAS/AS/CT value from the session level. > I would note that TIAS has no definition in Offer/Answer context. It is soley defined for Declarative usage. Yes, I know it is being used in O/A contexts, but I still don't understand how a receiver can state the actual packet rate to be used by the sender to enable correct calculation. 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 magnus.westerlund@ericsson.com Wed Dec 12 02:37:28 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 964B221F84FD; Wed, 12 Dec 2012 02:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQQ8QzGVCHzI; Wed, 12 Dec 2012 02:37:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4183C21F84FB; Wed, 12 Dec 2012 02:37:27 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-37-50c85e65c6a4 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A5.41.24873.56E58C05; Wed, 12 Dec 2012 11:37:26 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 12 Dec 2012 11:37:24 +0100 Message-ID: <50C85E64.3010801@ericsson.com> Date: Wed, 12 Dec 2012 11:37:24 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: bernard_aboba@hotmail.com References: <50C6A3A5.3060009@reavy.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvjW5a3IkAg52TOCz2L7nMbLHi9Tl2 i47JbBZTlz9msVj7r53dgdVjyu+NrB6Pe86weSxZ8pPJY/LjNuYAligum5TUnMyy1CJ9uwSu jIdfrrEUXFOsePb2NHsD4zapLkZODgkBE4lPHw4yQ9hiEhfurWfrYuTiEBI4yShx8MELFghn OaPEjTs3GEGqeAW0JW5O283UxcjBwSKgKjFvWS1ImE3AQuLmj0Y2EFtUwFdi1p5fTBDlghIn Zz5hAbFFBGQlOi+uYgWZySzQwShxeM8TsM3CAg4Sx9b+gdr8j1mi/esOsA5OAVuJX7t/skKc JymxaFonWJxZwEDiyKI5rBC2vETz1tlgg4SAjmto6mCdwCg0C8nyWUhaZiFpWcDIvIqRPTcx Mye93GgTIzC8D275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLg lGpg5Ct8WalgdrTH5eSGR0Z/Vu2doJ/oVGfX1m4merKgOl+3yCl5frL0B+6pOy2Ysy7d7zdy Zq35KbO799tx/r0VSXfP/QstqJPq+5p1sKPj8+o5YmyPp74oTT+TsOhpw5xDJd457Gf2BO/X 3f+haatJll+Zp40yR0xXm+pEodW3z59NFe1cGr1aiaU4I9FQi7moOBEA2oFXBD0CAAA= Cc: "'Cullen Jennings \(fluffy\)'" , rtcweb@ietf.org, 'mmusic WG' Subject: Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff 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, 12 Dec 2012 10:37:28 -0000 Hi, My Personal view on this topics. On 2012-12-11 06:01, Bernard Aboba wrote: > I do not think that a single meeting, virtual or actual, will suffice to > get things back on track. We need a fundamental change of approach. > Fully agreed. One of the issues, is that not a single individual of use across 5-6 WG have a complete picture of the issues we are stepping into with the fundamental issues that are in the center of this. This will require multiple individuals having knowledge on different aspects to fill in details and educate the others on the diverse issues. > > > The basic problem is that WebRTC work items have been dispersed between > a number of WGs other than RTCWEB. Within these WGs, WebRTC is only a > sideline. I am not certain that is the fundamental issue here. I think the very basic problem is that we are attempting for fork lift SDP into a clear specification supporting multi-stream RTP sessions and dealing with the diverse landscape of relationships that exists in multi-media applications between a large number of terminologies that include concepts such as: - Multi-party - Multiple media sources, i.e. camera microphones - Media Mixes or Compositions - Synchronization Contexts - End-point concepts, virtual, distributed, etc. - Diverse signalling models - Simulcast - Layered Encoding - Transport robustification, i.e RTP Retransmission, Duplications, FEC. - Different transports, aggregated over single unicast, multiple unicast flows, multicast - Different security mechanisms This coupled with that the people putting in requirements on this are working on different type of systems or applications, RTCWEB/WebRTC and CLUE just being two. We also have existing users of RTP that made different assumptions in extensions and signalling. It was very evident in RTCWEB and AVTEXT that we are lacking common terminology to even discuss the above and what it means in different contexts. Then we haven't even discussed what happens the minute you drag the word "Legacy" into any of the above debates for actual solutions. But now I am getting ahead of myself. I think the most important is to build a good description of the different functionalities and their relationships that we today believe are necessary to deal with currently and in the near future. > > > > > As a result, work items such as BUNDLE (which require non-trivial > analysis and discussion) have found themselves a needle in a haystack of > other items, getting a fraction of the attention that they need to move > forward. Yes, bundle is something that covers parts of the above and clearly related. I, however think more close to the core of the issues is the multiple stream issues and how we deal with relationships. However, I think failing to take the related topics into account and think that this will be quickly resolved will only result in generating even more mess. I also believe that in the end we are going to have to take some though decisions when it comes how to deal with existing definitions. Either replace them or basically deprecate some behaviors. > > While allocating some substantial time at an in-person RTCWEB/MMUSIC > interim can help, for that time to be well spent will require > substantial preparation. As an example, I could see a virtual AVTEXT > interim being scheduled for mid-January at which Jonathan Lennox’s > hierarchy draft could be given substantial time and an MMUSIC virtual > interim in the same time frame which could be devoted to one or two > important topics (e.g. BUNDLE, SCTP). > Fully agreed. This takes preparations and hard work. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Wed Dec 12 03:29: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 5621321F898C for ; Wed, 12 Dec 2012 03:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+de6Opha4yC for ; Wed, 12 Dec 2012 03:29:44 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8AB21F8973 for ; Wed, 12 Dec 2012 03:29:44 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-69-50c86aa66859 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 41.95.04318.6AA68C05; Wed, 12 Dec 2012 12:29:43 +0100 (CET) Received: from [131.160.126.41] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 12 Dec 2012 12:29:42 +0100 Message-ID: <50C86AA6.50809@ericsson.com> Date: Wed, 12 Dec 2012 13:29:42 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje7yrBMBBkuncFnc62litph7+Tm7 xdTlj1kcmD02Td7M5rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZdw6fZa54BpnxbvuNuYG xvfsXYycHBICJhJ/mj8xQthiEhfurWfrYuTiEBI4yShxveU1E4SzhlFiRs8yFpAqXgFNia9z LzGB2CwCqhJHzlwG62YTsJDYcus+WI2oQJTEoY0H2SHqBSVOznwCFhcR0Ja4NGkrK8hQZoEZ jBLXNq9jBkkICzhInLk6BWyQkICjxMWe1UALODg4BZwknv6sgLhOUuLt+1dg5cwCehJTrrYw QtjyEtvfzmGGaNWWWP6shWUCo9AsJKtnIWmZhaRlASPzKkb23MTMnPRy802MwAA+uOW3wQ7G TffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoGvf5atxiS3lNtwu1 O3XZil2viJxV+GPzwGnCa/VIvbtyGxYUx/K2GuVvv9/G8HXyU93g0JbDh40ebq+ptH0VnVO2 9ofJbu6a+b/fP9wUaMN9i+du8qZdhtMLtkaxTdGcaLz8z8mtNR9vfv95LJL1Zb3NxznOTU97 81frFDy+wKr260Lil0nhSizFGYmGWsxFxYkAel3Rgi4CAAA= Cc: "mmusic@ietf.org \(E-mail\)" , "draft-ietf-mmusic-media-loopback@tools.ietf.org" Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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, 12 Dec 2012 11:29:45 -0000 Hi Hadriel, the seems to be consensus around the "NO" path. Could you please revise the draft accordingly so that we can also clear the last discuss? Thanks, Gonzalo On 20/11/2012 8:16 PM, Hadriel Kaplan wrote: > Howdy, > during IESG review of the media-loopback draft, a discussion arose regarding the language around indicating media-loopback support per media description (i.e., per m-line), in sections 3.1 and 3.2. > > My interpretation/understanding was we were requiring ALL m-lines to indicate media-loopback; in other words it's an all-or-nothing in both the offer+answer, and either every media stream is looped back, or none are. However the text currently doesn't make this clear, and it could be argued either way, with pro's/con's either way too; so I'd like the WG's consensus on whether it should in fact be an all-or-none approach, or not. > > Please respond to this email by **Tuesday, December 4th** with a "YES" if the draft should mandate ALL media be looped-back, or "NO" if it should allow a hybrid approach of some streams being looped while others are not. > > For reference, the draft is here: > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 > > -hadriel > > From internet-drafts@ietf.org Wed Dec 12 14:06: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 0884F1F0CB2; Wed, 12 Dec 2012 14:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZwgWIBps5aw; Wed, 12 Dec 2012 14:06:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4871F0CB9; Wed, 12 Dec 2012 14:06:20 -0800 (PST) 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.36 Message-ID: <20121212220620.28059.35732.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 14:06:20 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-media-capabilities-16.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, 12 Dec 2012 22:06:32 -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 : Session Description Protocol (SDP) Media Capabilities Ne= gotiation Author(s) : Robert R Gilman Roni Even Flemming Andreasen Filename : draft-ietf-mmusic-sdp-media-capabilities-16.txt Pages : 64 Date : 2012-12-12 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. This document updates the IANA Considerations of RFC 5939. 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-media-capabilities= -16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 12 14:14: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 2E50C21E8055; Wed, 12 Dec 2012 14:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTuG90SNH0Fm; Wed, 12 Dec 2012 14:14:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8289421F8849; Wed, 12 Dec 2012 14:14:34 -0800 (PST) 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.36 Message-ID: <20121212221434.22961.99233.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 14:14:34 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-03.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, 12 Dec 2012 22:14:35 -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 : Miscellaneous Capabilities Negotiation in the Session De= scription Protocol (SDP) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Robert R. Gilman Filename : draft-ietf-mmusic-sdp-miscellaneous-caps-03.txt Pages : 20 Date : 2012-12-12 Abstract: SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=3D' line), connection data ('c=3D' line), and titles ('i=3D' line for each session or media). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-miscellaneous-caps= -03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dushyant2u@gmail.com Thu Dec 13 02:42:44 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 7D91D21F8929 for ; Thu, 13 Dec 2012 02:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkWzuFlojnvg for ; Thu, 13 Dec 2012 02:42:43 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C66D921F8952 for ; Thu, 13 Dec 2012 02:42:43 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so2020682vcb.31 for ; Thu, 13 Dec 2012 02:42:43 -0800 (PST) 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=Wjo5ZHm1Xm0mYa3gqHbRAGOnYkmi7XpT2IdXFsZnmfU=; b=PgKZjFDZrWFRNNNoFyPCnzgw/kTCB3utfa7jOdWh2B8xM+oQADki3sjPQR3J21G86/ dXMVjl/gnHQu2a4lsIiCvo6wLIoOYy1+n460xqAUJDoEv5q421uJyfAsDV0ukT+J9E+O 2B0ZXKv9nWaHkbhlHYfDCmbNovAHSMhSz/phydWjg9ygagIIGL9MZcvJSWZ+5/LM+B46 vAT2YvSgqWwDVX9E+8eZRav1dX+GcrGi/fL9/N8MJIUE+7iNZ4v0a7cz8CmN+tOsxg4I xf6PnlSSo4EFwPHczmfUUpXm4WMkGU03QZ0ivlcLRlZUtpTa9WKkdER7IejirCSDoQEC q/nQ== MIME-Version: 1.0 Received: by 10.52.88.33 with SMTP id bd1mr1985638vdb.70.1355395363191; Thu, 13 Dec 2012 02:42:43 -0800 (PST) Received: by 10.220.79.143 with HTTP; Thu, 13 Dec 2012 02:42:43 -0800 (PST) Date: Thu, 13 Dec 2012 16:12:43 +0530 Message-ID: From: Dushyant Joshi To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 13 Dec 2012 02:54:43 -0800 Subject: [MMUSIC] RTSP "alt-ports" are not mentioned in the RFC. 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, 13 Dec 2012 10:43:50 -0000 Hello team, I could see RTSP alt-ports are not defined in either RFC 2326 or RFC 6064 if you see IANA http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml we have defined port 8554 as the alternate RTSP port rtsp 554/tcp Real Time Stream Control Protocol rtsp 554/udp Real Time Stream Control Protocol rtsp-alt 8554/tcp RTSP Alternate (see port 554) rtsp-alt 8554/udp RTSP Alternate (see port 554) The RTSP 2.0 specification is still an Internet Draft and could add text. can we add this as an informative mentioning that there do exist an alternative registered port. Regards, Dushyant Joshi 91-9886886757 From magnus.westerlund@ericsson.com Fri Dec 14 01:13: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 62BFC21F84FA for ; Fri, 14 Dec 2012 01:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U46OIIZzZu49 for ; Fri, 14 Dec 2012 01:13:19 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 213D821F84F8 for ; Fri, 14 Dec 2012 01:13:15 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-48-50caedaa5581 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.F3.24873.AADEAC05; Fri, 14 Dec 2012 10:13:15 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Dec 2012 10:13:14 +0100 Message-ID: <50CAEDAA.3080803@ericsson.com> Date: Fri, 14 Dec 2012 10:13:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> In-Reply-To: <50C0B3AB.4010509@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje7qt6cCDHYv4bJoe/OLzaL9zREm i6nLH7M4MHssWfKTyaNzUbTHl8uf2QKYo7hsUlJzMstSi/TtErgynt7+wVrQblpxqHUaWwPj Ic0uRk4OCQETieV/fjBC2GISF+6tZ+ti5OIQEjjJKNH9eC0zhLOcUeL+mYPsXYwcHLwC2hKv /4eBNLAIqEocPXGRFcRmE7CQuPmjkQ3EFhXwlZi15xcTiM0rIChxcuYTFhBbRMBM4uGE/WA1 zAIlEpdntIHVCAtYSex/1w82Rwiod+2rXWA2p4COxKODu9ggjpOUWDStkwWiV09iytUWRghb XqJ562xmiF5tiYamDtYJjEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLjTYxAoP34JbfqjsY75wT OcQozcGiJM5rvXWPv5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGnjDB1jDtXz/lb9oqKjV0 TWrItZw7Nc5676T8SxM+6Ul53Hu1Z/2j0BMGHm2nnyw5VNZ2kcl40f+rlrdjs3/Py9281OJ7 OndDXegOLTZvteIpoQJVHJM7xKa2/bkpydj/K4Vp/+rdH+/s236XRYLZ8VZCTfqKcL+fFx8z Lo9e0bXzblfl+bXrlFiKMxINtZiLihMB79qVhSwCAAA= Cc: mmusic , draft-ietf-mmusic-rtsp-nat@tools.ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 14 Dec 2012 09:13:21 -0000 Hi, Follow up on comments as I have edited proposals to resolve the issues. I have the general set of changes on review with my co-authors. Hope to be able to submit next week. On 2012-12-06 16:03, Magnus Westerlund wrote: > > On 2012-12-05 22:22, Ari Keranen wrote: >> >> >> If the server has a public IP address with a single candidate >> per media stream, component and address family, then the server >> may be configured to not initiate connectivity checks. >> >> This is the "ICE-RTSP", right? Maybe one (small) subsection defining >> this "feature" would make sense. Now it's a bit trickled around in this >> section, sec 4.8.1, 5.4, etc. For someone not familiar with ICE-RTSP, it >> looks like you're talking about ICE lite. > > Yes, this is definitely ICE-RTSP. It is still doing triggered checks. However, I think you might have misinterpreted what ICE-RTSP really is. It is the full usage of ICE as defined by this specification. The high reachability configuration of the RTSP server is a variant of the normal ICE-RTSP behavior. I have tried to clarify this and created a special section for discussing the differences, this include the text in the old 4.8. 5. ICE-RTSP This Section discusses differences to the regular ICE usage defined in [RFC5245]. The basic for the modifications in the general procedures are in the clearer client/server roles that RTSP provides and how the RTSP Session establishment signalling occurs within RTSP compared to SIP/SDP Offer/Answer. 5.1. ICE Features Not Required A number of ICE signalling features are not needed with RTSP and are discussed below. 5.1.1. ICE-Lite The ICE-Lite attribute shall not be used in the context of RTSP. The ICE specification describes two implementations of ICE: Full and Lite, where hosts that are not behind a NAT are allowed to implement only Lite. For RTSP, the Lite implementation is insufficient because it does not cause the media server to send a connectivity check, which is used to protect against making the RTSP server a denial of service tool. 5.1.2. ICE-Mismatch The ice-mismatch parameter indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. This is not needed for RTSP as the ICE based lower layer transport specification either is supported or another alternative transport is used. This is always explicitly indicated in the SETUP request and response. 5.1.3. ICE Remote Candidate Transport Header Parameter The Remote candidate attribute is not needed for RTSP for the following reasons. Each SETUP results in an independent ICE processing chain which either fails or results in promoting a single candidate pair to usage. If a new SETUP request for the same media is sent, this needs to use a new username fragment and password to avoid any race conditions or uncertainty about which round of processing the STUN requests relate to. 5.2. High-Reachability Configuration ICE-RTSP contains one variant for RTSP Servers that are not behind NATs, i.e. are highly reachable by the clients. Similar to ICE-Lite this allows for some reductions in the servers burden. However, due to the need to still verify that the client is actually present where it claims the server must also initiate binding requests and await binding responses. The reduction for the high-reachability configuration of ICE-RTSP is that they don't need to initiate its own checks, and instead rely on triggered checks for verification. This also removes a denial of service threat where a RTSP SETUP request will trigger large amount of STUN connectivity checks towards provided candidate addresses. >> >> 5.12. Re-SETUP >> >> If the client decides to change any parameters related to the media >> stream setup >> >> Could clarify (again) here that we talk about ICE parameters. > > Yes, definitely. I actually had to think a long time if this was only > ICE parameters or also RTSP parameters. But, it is so unnecessary to > restart ICE for most RTSP parameter changes. When looking at this again, I though it unclear enough that I have attempted a bit of rewording. I propose the section should read like this: 6.12. Re-SETUP A client that decides to change any parameters related to the media stream setup it will send a new SETUP request. In this new SETUP request the client MAY include a new different username fragment and password to use in the ICE processing. New username and password SHALL cause the ICE processing to start from the beginning again, i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]). The client SHALL in case of ICE restart gather candidates and include the candidates in the transport specification for D-ICE. ICE restarts may be triggered due to changes of clients or servers attachment to the network, i.e. changes to the media streams destination or source address or port. Most RTSP parameter changes would not require an ICE restart, instead existing mechanisms in RTSP for indicating from where in the RTP stream they apply should be used. These include performing a pause prior to the parameter change and then resume or if server supports in do SETUP during PLAY state, and thus use RTP-Info header (Section 18.43 of [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media stream the change apply. The server SHALL support SETUP requests in PLAY state, as long as the SETUP changes only the ICE parameters, which are: ICE-Password, ICE- ufrag and the content of ICE candidates. If the RTSP session is in playing state at the time of sending the SETUP request requiring ICE restart, then the ICE connectivity checks SHALL use Regular nomination. Any ongoing media delivery continues on the previously nominated candidate pairs until the new pairs have been nominated for the individual candidate. Once the nomination of the new candidate pair has completed, all unused candidates may be released. 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 magnus.westerlund@ericsson.com Fri Dec 14 01:13: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 701A521F8501 for ; Fri, 14 Dec 2012 01:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU--MjTt-ROW for ; Fri, 14 Dec 2012 01:13:22 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCF021F84F8 for ; Fri, 14 Dec 2012 01:13:22 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f1-50caedb128b9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3F.8B.10459.1BDEAC05; Fri, 14 Dec 2012 10:13:21 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Dec 2012 10:13:20 +0100 Message-ID: <50CAEDB0.1030208@ericsson.com> Date: Fri, 14 Dec 2012 10:13:20 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <50ABFC68.8040001@cisco.com> In-Reply-To: <50ABFC68.8040001@cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje7Gt6cCDBYtErOYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4MvYuuMZa0ChTcWL7FcYGxmOiXYycHBICJhKTl/5ihrDFJC7c W8/WxcjFISRwklFi675tTBDOckaJxlMHgTIcHLwC2hJ/Z+aANLAIqEq8ffCXDcRmE7CQuPmj EcwWFfCVmLXnFxOIzSsgKHFy5hMWEFtEQFhixluIemEBG4ktOz+xgthCAhoSS3dNZAexOQU0 JdqO3YU6SFJi0bROsF5mAT2JKVdbGCFseYnmrbOZIXq1JRqaOlgnMArOQrJuFpKWWUhaFjAy r2Jkz03MzEkvN9zECAy/g1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2M/RXTu7umHJq/4aVS/r0sdclCyX3LlCV8hR7GbjVQ6n6oEf72Ac9/y+VVnLr6 Bwqyb85e5yImmvro8pspH2/v6zF49+VXsc5vyRRBlljD3hK9jXXX/I7arQr+N3Hqw4KZJ+f7 rm9cversHsuavmcSygxWV4znrnK4uMtNkSfDtWdrbZCet1SWEktxRqKhFnNRcSIAU1wFbQ0C AAA= Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-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: Fri, 14 Dec 2012 09:13:24 -0000 Hi, In the editing of Ari's comments I found the following issue that I have attempted to address: Section 4.2: : identifies the specific component of the media stream for which this is a candidate and is a positive integer between 1 and 256. It MUST start at 1 and MUST increment by 1 for each component of a particular candidate. For media streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2. The last sentence MUST is not compatible with RTP/RTCP multiplexing using RFC 5761 as defined by Section 7. Thus I have reworded it to: For media streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2 unless RTP and RTCP Multiplexing (Section 7) is used when the second component is omitted and RTP and RTCP is both transported over the first component. Feedback on this change would be appreciated. Cheers Magnus On 2012-11-20 22:55, Flemming Andreasen wrote: > This is to announce a 2 week Working Group Last Call for > > draft-ietf-mmusic-rtsp-nat-14 > > as Proposed Standard. Please review and provide any comments you may > have on the document by December 5, 2012. Comments should be sent to the > document authors and the MMUSIC WG list. If you review the document but > do not have any comments, please send a note to that effect as well. > > > Thanks > > Flemming > > > Draft Info: > > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) > Author(s) : Jeff Goldberg > Magnus Westerlund > Thomas Zeng > Filename : draft-ietf-mmusic-rtsp-nat-14.txt > Pages : 31 > Date : 2012-11-15 > > Abstract: > This document defines a solution for Network Address Translation > (NAT) traversal for datagram based media streams setup and controlled > with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses > Interactive Connectivity Establishment (ICE) adapted to use RTSP as a > signalling channel, defining the necessary extra RTSP extensions and > procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-14 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-14 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- 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 eckelcu@cisco.com Fri Dec 14 09:29: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 313AF21F8B55 for ; Fri, 14 Dec 2012 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5JuYYpf-8K2 for ; Fri, 14 Dec 2012 09:29:45 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 33CE621F8B3B for ; Fri, 14 Dec 2012 09:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1355506185; x=1356715785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NRCq4wTrqo509fEA0oaeA8GFu7cWqhQ4eNNg6aRXY98=; b=OTYBpkE1GZy5Ho/d6XPhcG3wfw7elaLPWNXoKRMFASTJCYYE5NKzvEAT GV94eWs8M8HZSX5SKRrx9y6PjA/Jp6bnSccnQ8kIR7SEO6JTYaHL+vVwM L4PzxyStPgR2+ARUdiAO7zsfcPYKxg9SvLF6rsqH3P2fj0JyEMTPziaDR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANNgy1CtJV2Z/2dsb2JhbABFvwUWc4IeAQEBAwEMXBEFBwICAgEIEQQBAQEKGQQHGxcUCQgCBA4FCIgFBQG9FASMU4NiYQOIK54mgnOCIg X-IronPort-AV: E=Sophos;i="4.84,282,1355097600"; d="scan'208";a="153065176" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 14 Dec 2012 17:29:44 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBEHTiCc002381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 17:29:44 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 11:29:44 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund Thread-Topic: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01) Thread-Index: AQHNu2yZJyuQHhZlfUCEbmtj3UUmnZfbqLRggDniooCAAzujsA== Date: Fri, 14 Dec 2012 17:29:44 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EB88F@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> <5097DF12.2020209@alvestrand.no> <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> <50C8548B.5040306@ericsson.com> In-Reply-To: <50C8548B.5040306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-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: Fri, 14 Dec 2012 17:29:46 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, December 12, 2012 1:55 AM > To: Charles Eckel (eckelcu) > Cc: Harald Alvestrand; mmusic@ietf.org > Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft- > ietf-mmusic-sdp-bundle-negotiation-01) >=20 > Hi, >=20 > Going through old emails. One important comment: >=20 > On 2012-11-05 21:04, Charles Eckel (eckelcu) wrote: > >> > >> Last time I looked b=3DCT was scoped to a whole conference ("supplied = for > >> the session"), while b=3DAS was scoped to a single RTP session. But I = may > >> be misinterpreting RFC 4566 section 5.8. > > > > I recommend using b=3DTIAS, as defined in RFC 3890. This parameter may = be > used at either the session or the media level, and it scope accordingly. > > What needs to be avoided is summing up the b=3DTIAS/AS values from the > bundled media lines and using that as that bandwidth for the bundle even = if > it exceeds the b=3DTIAS/AS/CT value from the session level. > > >=20 > I would note that TIAS has no definition in Offer/Answer context. It is > soley defined for Declarative usage. Yes, I know it is being used in O/A > contexts, but I still don't understand how a receiver can state the > actual packet rate to be used by the sender to enable correct calculation= . Agreed, TIAS is a declaration of the maximum bandwidth the declarer is will= ing to receive. It does not say anything about what the declarer is going t= o send. The same is true for AS and CT.=20 If we want something that indicates the maximum bandwidth the declarer is p= lanning to send, we would need to extend an existing attribute or define a = new attribute. However, the restriction I mentioned above regarding bundled streams not vi= olating limits declared by the corresponding b=3DTIAS/AS/CT attributes stil= l applies. Cheers, Charles > Cheers >=20 > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From dwing@cisco.com Fri Dec 14 14:29:41 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 012D821F8AAC for ; Fri, 14 Dec 2012 14:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaSaXzBYktDO for ; Fri, 14 Dec 2012 14:29:36 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 95D3B21F8AA9 for ; Fri, 14 Dec 2012 14:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1355524176; x=1356733776; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=p+p7P+hi/F+/qprwj2LLSNDm4m9N3ePsm1eGxls1eSI=; b=mxYeADVUaxH0jVmaobjb9E9WOa1N2upL3xPSpQueOZn9+VvmprkiWyX2 8DI+dXof62miJQBwRi6hZ2IrfktZQ4SZiBqmdykh0UyLBsC+QXIBnXV3y Yg52c4miJyldr7vlrovvNtUb2XRP/a5k4Zlu2ifvzwepOHICkI5mEUZGT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngIACWny1CrRDoG/2dsb2JhbABFg0i7QhZzgiUIAjA/DQVoPwEEHgWIAg29Co1xgykDiGCFHIgNgRyPLIMU X-IronPort-AV: E=Sophos;i="4.84,284,1355097600"; d="scan'208";a="63489394" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 14 Dec 2012 22:29:35 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBEMTZd2021288; Fri, 14 Dec 2012 22:29:35 GMT From: "Dan Wing" To: Date: Fri, 14 Dec 2012 14:29:35 -0800 Message-ID: <053001cdda4a$7eea6ce0$7cbf46a0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3aSCtAs73c0EdzS3SSzI+PgXhD8w== Content-Language: en-us Cc: jo@comnet.tkk.fi, draft-ietf-xrblock-rtcp-xr-discard-rle-metrics@tools.ietf.org, varun@comnet.tkk.fi Subject: [MMUSIC] draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 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, 14 Dec 2012 22:29:41 -0000 This is my SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04. Section 6 of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 left me a bit puzzled. It was not clear until the very end of that section that including the defined SDP lines was entirely optional (MAY). This does not align with RFC3611 (RTCP-XR), which says: "If a participant receives an SDP offer and understands the "rtcp-xr" attribute but does not wish to implement XR functionality offered, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing so, the party declares that, at a minimum, is capable of understanding the signaling." I would like the authors to consider: * A shorter SDP section, something like http://tools.ietf.org/html/rfc5725#section-4 * adding an explanation of the benefits (or harm) of including the new discard-rle and discard-bytes formats on the a=rtcp-xr line, so that implementers can weigh the benefit (or harm) of including one or both of those new formats on the a=rtcp-xr line. * align the document with RFC3611 (RTCP-XR), especially that the new discard-rle and discard-bytes are negotiated in SDP when doing Offer/Answer, or describe in the document why RFC3611's Offer/Answer model is inappropriate for discard-rle and for discard-bytes. -d From harald@alvestrand.no Mon Dec 17 01:22: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 DFAB821F8A4B for ; Mon, 17 Dec 2012 01:22:43 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPg-ywy9-hA5 for ; Mon, 17 Dec 2012 01:22:40 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6082F21F8A69 for ; Mon, 17 Dec 2012 01:22:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6909339E1C9 for ; Mon, 17 Dec 2012 10:22:38 +0100 (CET) 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 CHwxqEMPZz8e for ; Mon, 17 Dec 2012 10:22:37 +0100 (CET) Received: from [172.28.90.88] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 50FD139E129 for ; Mon, 17 Dec 2012 10:22:37 +0100 (CET) Message-ID: <50CEE45A.3000502@alvestrand.no> Date: Mon, 17 Dec 2012 10:22:34 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [MMUSIC] RTSP "alt-ports" are not mentioned in the RFC. 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, 17 Dec 2012 09:22:45 -0000 On 12/13/2012 11:42 AM, Dushyant Joshi wrote: > Hello team, > > I could see RTSP alt-ports are not defined in either RFC 2326 or RFC 6064 What is the point of defining an RTSP alt-port? Usually, in port numbers, two is worse than one; one should either have a single port or have protocol/uri syntax to describe using any port. > > if you see IANA > > http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml > > we have defined port 8554 as the alternate RTSP port > > rtsp 554/tcp Real Time Stream Control Protocol > rtsp 554/udp Real Time Stream Control Protocol > rtsp-alt 8554/tcp RTSP Alternate (see port 554) > rtsp-alt 8554/udp RTSP Alternate (see port 554) > > The RTSP 2.0 specification is still an Internet Draft and could add text. > can we add this as an informative mentioning that there do exist an > alternative registered port. > > Regards, > Dushyant Joshi > 91-9886886757 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Mon Dec 17 01:31: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 8009521F8A59 for ; Mon, 17 Dec 2012 01:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rulqlLZMrKQb for ; Mon, 17 Dec 2012 01:31:32 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2724521F8A49 for ; Mon, 17 Dec 2012 01:31:31 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-dc-50cee6706456 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7B.BD.10459.076EEC05; Mon, 17 Dec 2012 10:31:28 +0100 (CET) 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.279.1; Mon, 17 Dec 2012 10:31:28 +0100 Message-ID: <50CEE66F.8020902@ericsson.com> Date: Mon, 17 Dec 2012 10:31:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Harald Alvestrand References: <50CEE45A.3000502@alvestrand.no> In-Reply-To: <50CEE45A.3000502@alvestrand.no> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvjW7Bs3MBBlfn61icXbqK2eJYXxeb xdTlj1kcmD2uTLjC6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcz6/5mp4JtIRcfqG8wN jFcEuhg5OSQETCQezv7FCmGLSVy4t56ti5GLQ0jgJKPEore/WCCc5YwSm7t62EGqeAW0JX7/ fsECYrMIqEr0Hl7JBmKzCVhI3PzRCGaLCvhKzNrziwmiXlDi5MwnYPUiAjoSD/c3gMWZBcIl Nr2ZDLZZWMBFYseeLrAaIYFCibu3p4DZnAK6Eh8mdDNCXCcpsWhaJwtEr57ElKstjBC2vETz 1tnMEL3aEg1NHawTGIVmIVk9C0nLLCQtCxiZVzGy5yZm5qSXG25iBAbwwS2/dXcwnjoncohR moNFSZyXK2m/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG3oLsqBeHtjwRZLTMc6wVvfr0 kvDe0tVcqZ9vXJe4O21X/uVbJfKBjvoRay4cXXmwyvbTpv4VE+5WXJM626Z91ffh/UAN5w8P aljEzt/dU8STVyjhKPP2fNc7mUnzze5ytvCanjRb0+isHPG+x9jl87nLQs9mmDVbyb0valTQ y/UI8l/BvWWZEktxRqKhFnNRcSIAmf+x4C4CAAA= Cc: "dushyant2u@gmail.com >> Dushyant Joshi" , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP "alt-ports" are not mentioned in the RFC. 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, 17 Dec 2012 09:31:33 -0000 On 2012-12-17 10:22, Harald Alvestrand wrote: > On 12/13/2012 11:42 AM, Dushyant Joshi wrote: >> Hello team, >> >> I could see RTSP alt-ports are not defined in either RFC 2326 or RFC 6064 > What is the point of defining an RTSP alt-port? It appears to be old legacy. I assume the motivation was that it was difficult to deploy on the <1024 port number and wanted an alternative that still was prevented to be used by other services. > > Usually, in port numbers, two is worse than one; one should either have > a single port or have protocol/uri syntax to describe using any port. The question is if this port number has any benefit at all. Any port number for RTSP that isn't the default needs to be explicitly called out in the URI anyway, thus I see little different between 8554 and 7892 for example. If it is a matter of deploying security policies I would believe that you need to coordinate that anyway. Or is this for the cases of outbound policies where you want to say, general TCP isn't ok, but RTSP is, but only to port 554 and 8554? Still I think this is strange and I do question if even a informative reference in the RTSP 2.0 spec is of benefit. Cheers Magnus > >> >> if you see IANA >> >> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml >> >> >> we have defined port 8554 as the alternate RTSP port >> >> rtsp 554/tcp Real Time Stream Control Protocol >> rtsp 554/udp Real Time Stream Control Protocol >> rtsp-alt 8554/tcp RTSP Alternate (see port 554) >> rtsp-alt 8554/udp RTSP Alternate (see port 554) >> >> The RTSP 2.0 specification is still an Internet Draft and could add text. >> can we add this as an informative mentioning that there do exist an >> alternative registered port. >> >> Regards, >> Dushyant Joshi >> 91-9886886757 >> _______________________________________________ >> 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 > > -- 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 ari.keranen@nomadiclab.com Mon Dec 17 07:36: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 0195221F889B for ; Mon, 17 Dec 2012 07:36:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B24d8Wol3Zeq for ; Mon, 17 Dec 2012 07:36:37 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0A21F886B for ; Mon, 17 Dec 2012 07:36:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id F324A4E6FA; Mon, 17 Dec 2012 17:36:35 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVoEUdhIcKA6; Mon, 17 Dec 2012 17:36:35 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 665C54E6F8; Mon, 17 Dec 2012 17:36:35 +0200 (EET) Message-ID: <50CF3C03.4050205@nomadiclab.com> Date: Mon, 17 Dec 2012 17:36:35 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> In-Reply-To: <50C0B3AB.4010509@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 17 Dec 2012 15:36:38 -0000 Hi Magnus, On 12/6/12 5:03 PM, Magnus Westerlund wrote: > On 2012-12-05 22:22, Ari Keranen wrote: >> 3. Solution Overview >> >> The client then installs the STUN servers on each of >> the local candidates transport addresses it has gathered >> >> I would rather say "The client then prepares to act as a STUN server on >> each [...]" > > Sure, maybe "runs STUN servers" is better than both "installs" and > "act". They are STUN server, but with limited utility. Act as STUN > servers sounds like it is impersonating STUN, rather than actually being > STUN servers. "runs" sounds good to me. >> >> >> If the server has a public >> IP address, then a single candidate per address family >> >> In some cases (e.g., certain ISPs, I've heard) even "public" IP address >> does not mean you're not behind a NAT. Maybe it's better to say here "If >> the server is not behind a NAT". Same issue in step 8. > > Sure, maybe we need to define what we mean with not being behind a NAT. > It is a matter of being reachable from the top anchorin address domain > in regards to the clients. Yes, that would be good. [...] >> Aggressive nomination SHALL be used with RTSP. This doesn't have the >> negative impact that it has in offer/answer as media playing only >> starts after issuing a PLAY request. >> >> But it does have the downside of possibly selecting a lower-priority >> pair due to single dropped (e.g., due to congestion) connectivity check >> message for a higher priority pair. That said, probably SHALL is >> appropriate here, just wanted to make sure the implications are understood. > > Yes, but with ICE-RTSP you will retransmit the higher priority also, > thus if that works and you get a response that alternative is nominated > and will be used. But we probably should clarify what it means when > multiple candidate pairs are nominated, and in worse case the server > will use different paths for different media streams. According to ICE RFC, if multiple pairs end up nominated due to aggressive nomination, the highest priority one will be used (you get some transient behavior). But do you mean that you will keep retransmitting on a higher priority pair even if a lower priority pair has been (aggressively) selected and all check lists are in Completed state? Cheers, Ari From ari.keranen@nomadiclab.com Mon Dec 17 07:38: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 F273021F895E for ; Mon, 17 Dec 2012 07:38:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRU-Ei8DpE5v for ; Mon, 17 Dec 2012 07:38:21 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC90A21F8946 for ; Mon, 17 Dec 2012 07:38:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 06CF94E6FA; Mon, 17 Dec 2012 17:38:20 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoS0xsY-kflE; Mon, 17 Dec 2012 17:38:18 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id B6BE24E6F8; Mon, 17 Dec 2012 17:38:18 +0200 (EET) Message-ID: <50CF3C6A.6080901@nomadiclab.com> Date: Mon, 17 Dec 2012 17:38:18 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> <50CAEDAA.3080803@ericsson.com> In-Reply-To: <50CAEDAA.3080803@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 17 Dec 2012 15:38:22 -0000 Hi Magnus, These changes look good to me. And please add forward-reference(s) to the ICE-RTSP section where applicable. Couple of nits inline. Cheers, Ari On 12/14/12 11:13 AM, Magnus Westerlund wrote: > On 2012-12-06 16:03, Magnus Westerlund wrote: >> On 2012-12-05 22:22, Ari Keranen wrote: >>> >>> If the server has a public IP address with a single candidate >>> per media stream, component and address family, then the server >>> may be configured to not initiate connectivity checks. >>> >>> This is the "ICE-RTSP", right? Maybe one (small) subsection defining >>> this "feature" would make sense. Now it's a bit trickled around in this >>> section, sec 4.8.1, 5.4, etc. For someone not familiar with ICE-RTSP, it >>> looks like you're talking about ICE lite. >> >> Yes, this is definitely ICE-RTSP. It is still doing triggered checks. > > However, I think you might have misinterpreted what ICE-RTSP really is. > It is the full usage of ICE as defined by this specification. The high > reachability configuration of the RTSP server is a variant of the normal > ICE-RTSP behavior. > > I have tried to clarify this and created a special section for > discussing the differences, this include the text in the old 4.8. > 5. ICE-RTSP > > This Section discusses differences to the regular ICE usage defined > in [RFC5245]. The basic for the modifications in the general > procedures are in the clearer client/server roles that RTSP provides > and how the RTSP Session establishment signalling occurs within RTSP > compared to SIP/SDP Offer/Answer. > > 5.1. ICE Features Not Required > > A number of ICE signalling features are not needed with RTSP and are > discussed below. > > 5.1.1. ICE-Lite > > The ICE-Lite attribute shall not be used in the context of RTSP. The > ICE specification describes two implementations of ICE: Full and > Lite, where hosts that are not behind a NAT are allowed to implement > only Lite. For RTSP, the Lite implementation is insufficient because > it does not cause the media server to send a connectivity check, > which is used to protect against making the RTSP server a denial of > service tool. > > 5.1.2. ICE-Mismatch > > The ice-mismatch parameter indicates that the offer arrived with a > default destination for a media component that didn't have a > corresponding candidate attribute. This is not needed for RTSP as > the ICE based lower layer transport specification either is supported > or another alternative transport is used. This is always explicitly > indicated in the SETUP request and response. > > 5.1.3. ICE Remote Candidate Transport Header Parameter > > The Remote candidate attribute is not needed for RTSP for the > following reasons. Each SETUP results in an independent ICE > processing chain which either fails or results in promoting a single > candidate pair to usage. If a new SETUP request for the same media > is sent, this needs to use a new username fragment and password to > avoid any race conditions or uncertainty about which round of > processing the STUN requests relate to. > > 5.2. High-Reachability Configuration > > ICE-RTSP contains one variant for RTSP Servers that are not behind > NATs, i.e. are highly reachable by the clients. Similar to ICE-Lite > this allows for some reductions in the servers burden. However, due > to the need to still verify that the client is actually present where > it claims the server must also initiate binding requests and await > binding responses. The reduction for the high-reachability > configuration of ICE-RTSP is that they don't need to initiate its own > checks, and instead rely on triggered checks for verification. This > also removes a denial of service threat where a RTSP SETUP request > will trigger large amount of STUN connectivity checks towards > provided candidate addresses. > > > >>> >>> 5.12. Re-SETUP >>> >>> If the client decides to change any parameters related to the media >>> stream setup >>> >>> Could clarify (again) here that we talk about ICE parameters. >> >> Yes, definitely. I actually had to think a long time if this was only >> ICE parameters or also RTSP parameters. But, it is so unnecessary to >> restart ICE for most RTSP parameter changes. > > When looking at this again, I though it unclear enough that I have > attempted a bit of rewording. I propose the section should read like this: > > 6.12. Re-SETUP > > A client that decides to change any parameters related to the media > stream setup it will send a new SETUP request. In this new SETUP (remove "it") > request the client MAY include a new different username fragment and > password to use in the ICE processing. New username and password > SHALL cause the ICE processing to start from the beginning again, > i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]). The client SHALL > in case of ICE restart gather candidates and include the candidates > in the transport specification for D-ICE. > > ICE restarts may be triggered due to changes of clients or servers > attachment to the network, i.e. changes to the media streams > destination or source address or port. Most RTSP parameter changes > would not require an ICE restart, instead existing mechanisms in RTSP > for indicating from where in the RTP stream they apply should be > used. These include performing a pause prior to the parameter change > and then resume or if server supports in do SETUP during PLAY state, "in do SETUP" ? > and thus use RTP-Info header (Section 18.43 of > [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media > stream the change apply. > > The server SHALL support SETUP requests in PLAY state, as long as the > SETUP changes only the ICE parameters, which are: ICE-Password, ICE- > ufrag and the content of ICE candidates. > > If the RTSP session is in playing state at the time of sending the > SETUP request requiring ICE restart, then the ICE connectivity checks > SHALL use Regular nomination. Any ongoing media delivery continues > on the previously nominated candidate pairs until the new pairs have > been nominated for the individual candidate. Once the nomination of > the new candidate pair has completed, all unused candidates may be > released. From jonathan@vidyo.com Mon Dec 17 07:50:01 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 BD15521F8B03 for ; Mon, 17 Dec 2012 07:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRrqBepN15xj for ; Mon, 17 Dec 2012 07:49:59 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF421F8AB9 for ; Mon, 17 Dec 2012 07:49:59 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9052E416990; Mon, 17 Dec 2012 04:48:25 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D29434169ED; Mon, 17 Dec 2012 04:48:10 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Mon, 17 Dec 2012 10:49:42 -0500 From: Jonathan Lennox To: "mmusic@ietf.org" , "draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org" Date: Mon, 17 Dec 2012 10:49:41 -0500 Thread-Topic: SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard Thread-Index: Ac3cbfjzJEY5mo6KTkmb8kup78CGAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C3759687E4991243A1A0BD44EAC823034DFB915B07BE235maillan_" MIME-Version: 1.0 Subject: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard 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, 17 Dec 2012 15:50:01 -0000 --_000_C3759687E4991243A1A0BD44EAC823034DFB915B07BE235maillan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been asked to perform the SDP Directorate review for draft-ietf-xrbl= ock-rtcp-xr-discard. I reviewed the -10 version of the document. Syntactically, the SDP usage in this document seems fine. It is a simple a= nd correct usage of an extension point defined in RFC 3711. However, the statement in Section 4 that "XR blocks MAY be used without exp= licit signaling" is confusing, as it implies that the entire SDP section is= entirely optional. This document should at least reference Section 5 of R= FC 3711, which gives guidance as to when SDP signaling of the use of XR blo= cks is recommended. In the IANA considerations section, I echo Adam Roach's comments on the bur= st-gap-lost draft: the full and proper names of the IANA registries should = be spelled out. These are the "RTP Control Protocol Extended Reports (RTCP= XR) Block Type Registry" in Section 5.1, and the "RTP Control Protocol Ext= ended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Regis= try" in Section 5.2. Additionally, the last sentence of section 4.2 is not correct English. The= sentence For detailed usage in Offer/Answer for unilateral parameter, refer to se= ction 5.2 of [RFC3611]. should be For detailed usage of Offer/Answer for unilateral parameters, refer to s= ection 5.2 of [RFC3611]. -- Jonathan Lennox jonathan@vidyo.com --_000_C3759687E4991243A1A0BD44EAC823034DFB915B07BE235maillan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been aske= d to perform the SDP Directorate review for draft-ietf-xrblock-rtcp-xr-disc= ard. I reviewed the -10 version of the document.

 

Syntactically, the SDP u= sage in this document seems fine.  It is a simple and correct usage of= an extension point defined in RFC 3711.

 

However, the statement in Sectio= n 4 that "XR blocks MAY be used without explicit signaling" is co= nfusing, as it implies that the entire SDP section is entirely optional.&nb= sp; This document should at least reference Section 5 of RFC 3711, which gi= ves guidance as to when SDP signaling of the use of XR blocks is recommende= d.

 

In the IANA considerations section, I echo Adam Roach's comments on th= e burst-gap-lost draft: the full and proper names of the IANA registries sh= ould be spelled out.  These are the "RTP Control Protocol Extende= d Reports (RTCP XR) Block Type Registry" in Section 5.1, and the "= ;RTP Control Protocol Extended Reports (RTCP XR) Session Description Protoc= ol (SDP) Parameters Registry" in Section 5.2.

 

Additionally, the la= st sentence of section 4.2 is not correct English.  The sentence<= /o:p>

 

&nb= sp;  For detailed usage in Offer/Answer for unilateral parameter, refe= r to section 5.2 of [RFC3611].

&nbs= p;

should be

 

   For detailed usag= e of Offer/Answer for unilateral parameters, refer to section 5.2 of [RFC36= 11].

 

--

Jonathan Lennox

jonathan@vidyo.com

 

= --_000_C3759687E4991243A1A0BD44EAC823034DFB915B07BE235maillan_-- From magnus.westerlund@ericsson.com Mon Dec 17 08:07: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 8559B21F8B44 for ; Mon, 17 Dec 2012 08:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nd0iR0DV03P for ; Mon, 17 Dec 2012 08:07:40 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB321F8B3B for ; Mon, 17 Dec 2012 08:07:38 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-fe-50cf4349f3e4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5E.ED.24873.9434FC05; Mon, 17 Dec 2012 17:07:37 +0100 (CET) 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.279.1; Mon, 17 Dec 2012 17:07:37 +0100 Message-ID: <50CF4349.5010100@ericsson.com> Date: Mon, 17 Dec 2012 17:07:37 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ari Keranen References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> <50CF3C03.4050205@nomadiclab.com> In-Reply-To: <50CF3C03.4050205@nomadiclab.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja6n8/kAgxX39S3a3vxis2h/c4TJ YuryxywOzB5Llvxk8uhcFO3x5fJntgDmKC6blNSczLLUIn27BK6MXTu/sBY0Slc8uHWLtYFx kWgXIyeHhICJxMebV5ggbDGJC/fWs3UxcnEICZxklJh6bD1YQkhgOaPE6Y8GIDavgLbEpQtP wOIsAqoSN388Zgax2QQsgOxGNhBbVMBXYtaeX0wQ9YISJ2c+YQGxRQR0JLq33QWLMwu4Sxw9 9B2sV1jASmL/u35WiF35Ep9ffmXsYuTg4BTQk3i9xwPiNkmJRdM6WSBa9SSmXG1hhLDlJZq3 zmaGaNWWaGjqYJ3AKDQLyeZZSFpmIWlZwMi8ipE9NzEzJ73caBMjMHQPbvmtuoPxzjmRQ4zS HCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBsMltSpjYnd4n5j5SdH3afmsF8 pvdBwpn2pvx7AQ8rCtpnPa7QnaX1SsMzgd2wmut10iJOnVMPpu59XtXkO93d5MXM6z4n28XF Na6VJt57Y+T8Tk9je0aB8Iv56v17HBZ4ZO5TP++YmSlmwfDgGtM1fR//vOe6c74YG20r2KMp N9ePn0d50WwlluKMREMt5qLiRADyD/qfKwIAAA== Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 17 Dec 2012 16:07:40 -0000 On 2012-12-17 16:36, Ari Keranen wrote: > Hi Magnus, > > On 12/6/12 5:03 PM, Magnus Westerlund wrote: >> On 2012-12-05 22:22, Ari Keranen wrote: >>> 3. Solution Overview >>> >>> The client then installs the STUN servers on each of >>> the local candidates transport addresses it has gathered >>> >>> I would rather say "The client then prepares to act as a STUN server on >>> each [...]" >> >> Sure, maybe "runs STUN servers" is better than both "installs" and >> "act". They are STUN server, but with limited utility. Act as STUN >> servers sounds like it is impersonating STUN, rather than actually being >> STUN servers. > > "runs" sounds good to me. > >>> >>> >>> If the server has a public >>> IP address, then a single candidate per address family >>> >>> In some cases (e.g., certain ISPs, I've heard) even "public" IP address >>> does not mean you're not behind a NAT. Maybe it's better to say here "If >>> the server is not behind a NAT". Same issue in step 8. >> >> Sure, maybe we need to define what we mean with not being behind a NAT. >> It is a matter of being reachable from the top anchorin address domain >> in regards to the clients. > > Yes, that would be good. OK, so far I haven't actually done such an addition to the modified texts. But I will see what I can do before submitting the update. > > [...] >>> Aggressive nomination SHALL be used with RTSP. This doesn't have >>> the >>> negative impact that it has in offer/answer as media playing only >>> starts after issuing a PLAY request. >>> >>> But it does have the downside of possibly selecting a lower-priority >>> pair due to single dropped (e.g., due to congestion) connectivity check >>> message for a higher priority pair. That said, probably SHALL is >>> appropriate here, just wanted to make sure the implications are >>> understood. >> >> Yes, but with ICE-RTSP you will retransmit the higher priority also, >> thus if that works and you get a response that alternative is nominated >> and will be used. But we probably should clarify what it means when >> multiple candidate pairs are nominated, and in worse case the server >> will use different paths for different media streams. > > According to ICE RFC, if multiple pairs end up nominated due to > aggressive nomination, the highest priority one will be used (you get > some transient behavior). > > But do you mean that you will keep retransmitting on a higher priority > pair even if a lower priority pair has been (aggressively) selected and > all check lists are in Completed state? I guess this needs to be expanded a bit. What I mean is that if due to some reason one get a lower prioritized pair to respond and then get an answer from the more prioritized then it actually makes sense to unlock the full checklist for the more prioritized and let it run to completion prior to sending the PLAY request. 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 btv1==69844116b32==HKaplan@acmepacket.com Mon Dec 17 09:04: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 D5DFE21F87DC for ; Mon, 17 Dec 2012 09:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AepcCOm78DaR for ; Mon, 17 Dec 2012 09:04:38 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBCB21F87C8 for ; Mon, 17 Dec 2012 09:04:37 -0800 (PST) X-ASG-Debug-ID: 1355763876-03fc200e9330020001-mNOVBD Received: from Mail2.acmepacket.com (mail2.acmepacket.com [10.0.0.22]) by mx1.acmepacket.com with ESMTP id 9TD9CZzRvRWCxYv1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 12:04:36 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL1.acmepacket.com ([169.254.1.21]) by Mail2.acmepacket.com ([169.254.2.189]) with mapi id 14.02.0283.003; Mon, 17 Dec 2012 12:04:36 -0500 From: Hadriel Kaplan To: "mmusic@ietf.org (E-mail)" Thread-Topic: NEED WG CONSENSUS: media-loopback is all-or-nothing X-ASG-Orig-Subj: Re: NEED WG CONSENSUS: media-loopback is all-or-nothing Thread-Index: AQHN3HiX7WOSh8FeHEK2zkuJdXrgIw== Date: Mon, 17 Dec 2012 17:04:35 +0000 Message-ID: <1C60A79B-11BC-4593-8E89-B99A7A151B1F@acmepacket.com> References: <50C86AA6.50809@ericsson.com> In-Reply-To: <50C86AA6.50809@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7ECFB09E9B150A4A84B60F73B57891CB@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail2.acmepacket.com[10.0.0.22] X-Barracuda-Start-Time: 1355763876 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.117283 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: Gonzalo Camarillo , "draft-ietf-mmusic-media-loopback@tools.ietf.org" Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing 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, 17 Dec 2012 17:20:24 -0000 Howdy, WG consensus is the "NO" path, and therefore section 3.1 of draft-24 will b= e changed from this: "An SDP offerer compliant to this specification and attempting to establish= a media session with media loopback MUST include "loopback" media attribut= es for each individual media description in the offer message. The offerer= will look for the "loopback" media attributes in the media description(s) = of the response from the answer for confirmation that the request is accept= ed." To this in draft-25: "An SDP offerer compliant to this specification and attempting to establish= a media session with media loopback will include "loopback" media attribut= es for each individual media description in the offer message that it wishe= s to have looped back. Note that the offerer may choose to only request lo= op back for some media descriptions/streams but not others. For example it= might wish to request loopback for a video stream but not audio, or vice-v= ersa. =20 The offerer will look for the "loopback" media attributes in the media desc= ription(s) of the response from the SDP answer for confirmation that the re= quest is accepted." -hadriel On Dec 12, 2012, at 6:29 AM, Gonzalo Camarillo wrote: > Hi Hadriel, >=20 > the seems to be consensus around the "NO" path. Could you please revise > the draft accordingly so that we can also clear the last discuss? >=20 > Thanks, >=20 > Gonzalo >=20 > On 20/11/2012 8:16 PM, Hadriel Kaplan wrote: >> Howdy, >> during IESG review of the media-loopback draft, a discussion arose regar= ding the language around indicating media-loopback support per media descri= ption (i.e., per m-line), in sections 3.1 and 3.2. >>=20 >> My interpretation/understanding was we were requiring ALL m-lines to ind= icate media-loopback; in other words it's an all-or-nothing in both the off= er+answer, and either every media stream is looped back, or none are. Howe= ver the text currently doesn't make this clear, and it could be argued eith= er way, with pro's/con's either way too; so I'd like the WG's consensus on = whether it should in fact be an all-or-none approach, or not. >>=20 >> Please respond to this email by **Tuesday, December 4th** with a "YES" i= f the draft should mandate ALL media be looped-back, or "NO" if it should a= llow a hybrid approach of some streams being looped while others are not. >>=20 >> For reference, the draft is here: >> http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 >>=20 >> -hadriel >>=20 >>=20 >=20 From internet-drafts@ietf.org Mon Dec 17 09:42: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 0682B21F8B48; Mon, 17 Dec 2012 09:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5fwpStP2McP; Mon, 17 Dec 2012 09:42:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6977321F8B66; Mon, 17 Dec 2012 09:42:22 -0800 (PST) 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.37 Message-ID: <20121217174222.27152.63102.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 09:42:22 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-media-loopback-25.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, 17 Dec 2012 17:42:23 -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-25.txt Pages : 34 Date : 2012-12-17 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-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-media-loopback-25 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bill.wu@huawei.com Mon Dec 17 18:20: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 C0E9C11E8097; Mon, 17 Dec 2012 18:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.674 X-Spam-Level: X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVx9UCUcP1XH; Mon, 17 Dec 2012 18:20:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4DA21F8584; Mon, 17 Dec 2012 18:20:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMO97833; Tue, 18 Dec 2012 02:20:29 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 02:20:22 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 02:20:28 +0000 Received: from w53375 (10.138.41.149) by szxeml459-hub.china.huawei.com (10.82.67.202) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 10:20:24 +0800 Message-ID: From: Qin Wu To: Glen Zorn , Jonathan Lennox References: <50CFCBF9.3070301@net-zen.net> Date: Tue, 18 Dec 2012 10:20:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: xrblock@ietf.org, draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org, mmusic@ietf.org, gwz@net-zen.net Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard 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, 18 Dec 2012 02:20:35 -0000 SSBndWVzcyB0aGUgcmVmZXJlbmNlICJSRkMzNzExIHNlY3Rpb24gNSIgSm9uYXRoYW4gbWVudGlv bmVkIHNob3VsZCBiZSBjb3JyZWN0ZWQgYXMgIlJGQzM2MTEgc2VjdGlvbiA1Ii4NCklmIG15IHVu ZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgd2hhdCBKb25hdGhhbiBzdWdnZXN0ZWQgaXMgdG8gaGF2 ZSB0aGUgZm9sbG93aW5nIGNoYW5nZToNCk9MRCBURVhUOg0KIg0KICAgUkZDIDM2MTEgZGVmaW5l cyB0aGUgdXNlIG9mIFNEUCAoU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCkNCiAgIFtSRkM0 NTY2XSBmb3Igc2lnbmFsaW5nIHRoZSB1c2Ugb2YgUlRDUCBYUiBibG9ja3MuICBYUiBibG9ja3Mg TUFZIGJlDQogICB1c2VkIHdpdGhvdXQgcHJpb3Igc2lnbmFsaW5nLg0KDQoiDQpORVcgVEVYVDoN CiINCiAgIFJGQyAzNjExIGRlZmluZXMgdGhlIHVzZSBvZiBTRFAgKFNlc3Npb24gRGVzY3JpcHRp b24gUHJvdG9jb2wpDQogICBbUkZDNDU2Nl0gZm9yIHNpZ25hbGluZyB0aGUgdXNlIG9mIFJUQ1Ag WFIgYmxvY2tzLiAgSG93ZXZlciBYUiBibG9ja3MgTUFZIGJlDQogICB1c2VkIHdpdGhvdXQgcHJp b3Igc2lnbmFsaW5nIChzZWUgc2VjdGlvbiA1IG9mIFJGQzM2MTEpLg0KIg0KUGxlYXNlIGNvcnJl Y3QgbWUgaWYgSSBhbSB3cm9uZy4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQpGcm9tOiAiR2xlbiBab3JuIiA8Z3d6QG5ldC16ZW4ubmV0Pg0KVG86ICJK b25hdGhhbiBMZW5ub3giIDxqb25hdGhhbkB2aWR5by5jb20+DQpDYzogPG1tdXNpY0BpZXRmLm9y Zz47IDxkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kaXNjYXJkQHRvb2xzLmlldGYub3JnPjsg PGd3ekBuZXQtemVuLm5ldD4NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAyMDEyIDk6NTAg QU0NClN1YmplY3Q6IFJlOiBTRFAgRGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJi bG9jay1ydGNwLXhyLWRpc2NhcmQNCg0KDQo+IE9uIDEyLzE3LzIwMTIgMTA6NDkgUE0sIEpvbmF0 aGFuIExlbm5veCB3cm90ZToNCj4gDQo+PiBJIGhhdmUgYmVlbiBhc2tlZCB0byBwZXJmb3JtICB0 aGUgU0RQIERpcmVjdG9yYXRlIHJldmlldyBmb3INCj4gPiBkcmFmdC1pZXRmLXhyYmxvY2stcnRj cC14ci1kaXNjYXJkLiBJIHJldmlld2VkIHRoZSAtMTAgdmVyc2lvbiBvZiB0aGUNCj4gPiBkb2N1 bWVudC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBTeW50YWN0aWNhbGx5LCB0aGUgU0RQIHVzYWdlIGlu IHRoaXMgZG9jdW1lbnQgc2VlbXMgZmluZS4gSXQgaXMgYQ0KPiA+IHNpbXBsZSBhbmQgY29ycmVj dCB1c2FnZSBvZiBhbiBleHRlbnNpb24gcG9pbnQgZGVmaW5lZCBpbiBSRkMgMzcxMS4NCj4gPg0K PiA+DQo+ID4NCj4gPiBIb3dldmVyLCB0aGUgc3RhdGVtZW50IGluIFNlY3Rpb24gNCB0aGF0ICJY UiBibG9ja3MgTUFZIGJlIHVzZWQNCj4gPiB3aXRob3V0IGV4cGxpY2l0IHNpZ25hbGluZyIgaXMg Y29uZnVzaW5nLCBhcyBpdCBpbXBsaWVzIHRoYXQgdGhlDQo+ID4gZW50aXJlIFNEUCBzZWN0aW9u IGlzIGVudGlyZWx5IG9wdGlvbmFsLiBUaGlzIGRvY3VtZW50IHNob3VsZCBhdA0KPiA+IGxlYXN0 IHJlZmVyZW5jZSBTZWN0aW9uIDUgb2YgUkZDIDM3MTEsIHdoaWNoIGdpdmVzIGd1aWRhbmNlIGFz IHRvDQo+ID4gd2hlbiBTRFAgc2lnbmFsaW5nIG9mIHRoZSB1c2Ugb2YgWFIgYmxvY2tzIGlzIHJl Y29tbWVuZGVkLg0KPiA+DQo+IA0KPiBJJ20gbm90IHN1cmUgd2h5IHRoaXMgaXMgY29uZnVzaW5n IChhc2lkZSBmcm9tIGZhY3QgdGhhdCBSRkMgMzcxMSBpcyANCj4gaXRzZWxmIGNvbmZ1c2luZzog aXQgc2F5cyAiYWx0aG91Z2ggdGhlIHVzZSBvZiBTRFAgc2lnbmFsaW5nIGZvciBYUiANCj4gYmxv Y2tzIG1heSBiZSBvcHRpb25hbCwgaWYgdXNlZCwgaXQgTVVTVCBiZSB1c2VkIGFzIGRlZmluZWQg aGVyZSIuIC9NYXkvIA0KPiBiZSBvcHRpb25hbD8gIE9wdGlvbmFsaXR5IHNlZW1zIHByZXR0eSBi bGFjayBhbmQgd2hpdGUgdG8gbWUgOy0pLiAgVGhhdCANCj4gc2FpZCwgaG93ZXZlciwgaXQgZG9l cyBzZWVtIHRvIGJlIHJlbGF0aXZlbHkgY2xlYXIgdGhhdCB0aGUgdXNhZ2Ugb2YgU0RQIA0KPiAv aXMvIG9wdGlvbmFsICYgYWxvbmcgd2l0aCBpdCB0aGUgc2VjdGlvbiBvbiBTRFAgaW4gdGhpcyBh bmQgb3RoZXIgDQo+IHNpbWlsYXIgZHJhZnRzLiAgV2hhdCBhbSBJIG1pc3Npbmc/DQo+IA0KPiAu Li4NCj4= From finlayson@live555.com Mon Dec 17 19:17: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 D5E1721F87DE for ; Mon, 17 Dec 2012 19:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+XxRPGGGp21 for ; Mon, 17 Dec 2012 19:17:22 -0800 (PST) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 35ADC21F87D8 for ; Mon, 17 Dec 2012 19:17:22 -0800 (PST) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id qBI3HJkY089056 for ; Mon, 17 Dec 2012 19:17:20 -0800 (PST) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_B26309B0-3548-4B0B-A6E0-5C1B6F56DDC1" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Tue, 18 Dec 2012 13:17:26 +1000 References: <50CEE45A.3000502@alvestrand.no> <50CEE66F.8020902@ericsson.com> To: mmusic@ietf.org In-Reply-To: <50CEE66F.8020902@ericsson.com> X-Mailer: Apple Mail (2.1499) Subject: Re: [MMUSIC] RTSP "alt-ports" are not mentioned in the RFC. 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, 18 Dec 2012 03:17:23 -0000 --Apple-Mail=_B26309B0-3548-4B0B-A6E0-5C1B6F56DDC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (Grumple... I wish this mailing list were set up so that replies went to = the mailing list by default. Resending to the whole mailing list = instead of just Magnus.) > The question is if this port number has any benefit at all. Yes it does. If a RTSP server cannot use port 554 (most likely because = it is running on a Unix system, but not as 'root'), then it can try = using port 8554 instead. (FWIW, our RTSP server implementation - widely = used on the Internet - does this.) As you noted, if a server uses port = 8554 (or any port other than 554), then this port number will need to be = included in the "rtsp://" URLs that clients use. But it's beneficial to = know - e.g., if you're managing a network's 'security' policy - that = RTSP will likely be used on either port 554 or port 8554 (rather than = either port 554 or some unspecified other port number). Similarly, it's = useful for network monitoring tools to know that traffic on port 8554 is = likely to be RTSP. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_B26309B0-3548-4B0B-A6E0-5C1B6F56DDC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
(Grumple... I wish this = mailing list were set up so that replies went to the mailing list by = default.  Resending to the whole mailing list instead of just = Magnus.)

The question is if this = port number has any benefit at all.

Yes it = does.  If a RTSP server cannot use port 554 (most likely because it = is running on a Unix system, but not as 'root'), then it can try using = port 8554 instead.  (FWIW, our RTSP server implementation - widely = used on the Internet - does this.)  As you noted, if a server uses = port 8554 (or any port other than 554), then this port number will need = to be included in the "rtsp://" URLs that clients use.  But it's = beneficial to know - e.g., if you're managing a network's 'security' = policy - that RTSP will likely be used on either port 554 or port 8554 = (rather than either port 554 or some unspecified other port number). =  Similarly, it's useful for network monitoring tools to know that = traffic on port 8554 is likely to be RTSP.

Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/

= --Apple-Mail=_B26309B0-3548-4B0B-A6E0-5C1B6F56DDC1-- From gwz@net-zen.net Mon Dec 17 17:50: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 B58FA11E8097 for ; Mon, 17 Dec 2012 17:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aBCsij3nisk for ; Mon, 17 Dec 2012 17:50:56 -0800 (PST) Received: from sg2plout10-01.prod.sin2.secureserver.net (sg2plout10-01.prod.sin2.secureserver.net [182.50.145.4]) by ietfa.amsl.com (Postfix) with SMTP id 7A21B21F882B for ; Mon, 17 Dec 2012 17:50:54 -0800 (PST) Received: (qmail 27839 invoked from network); 18 Dec 2012 01:50:50 -0000 Received: from unknown (110.169.202.60) by sg2plout10-01.prod.sin2.secureserver.net (182.50.145.4) with ESMTP; 18 Dec 2012 01:50:50 -0000 Message-ID: <50CFCBF9.3070301@net-zen.net> Date: Tue, 18 Dec 2012 08:50:49 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jonathan Lennox References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Dec 2012 22:27:58 -0800 Cc: "draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org" , "mmusic@ietf.org" , gwz@net-zen.net Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard 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, 18 Dec 2012 01:50:56 -0000 On 12/17/2012 10:49 PM, Jonathan Lennox wrote: > I have been asked to perform the SDP Directorate review for > draft-ietf-xrblock-rtcp-xr-discard. I reviewed the -10 version of the > document. > > > > Syntactically, the SDP usage in this document seems fine. It is a > simple and correct usage of an extension point defined in RFC 3711. > > > > However, the statement in Section 4 that "XR blocks MAY be used > without explicit signaling" is confusing, as it implies that the > entire SDP section is entirely optional. This document should at > least reference Section 5 of RFC 3711, which gives guidance as to > when SDP signaling of the use of XR blocks is recommended. > I'm not sure why this is confusing (aside from fact that RFC 3711 is itself confusing: it says "although the use of SDP signaling for XR blocks may be optional, if used, it MUST be used as defined here". /May/ be optional? Optionality seems pretty black and white to me ;-). That said, however, it does seem to be relatively clear that the usage of SDP /is/ optional & along with it the section on SDP in this and other similar drafts. What am I missing? ... From gwz@net-zen.net Mon Dec 17 19:03: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 2C58221F848B for ; Mon, 17 Dec 2012 19:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJmhL2yzFTlV for ; Mon, 17 Dec 2012 19:03:31 -0800 (PST) Received: from sg2plout10-01.prod.sin2.secureserver.net (sg2plout10-01.prod.sin2.secureserver.net [182.50.145.4]) by ietfa.amsl.com (Postfix) with SMTP id 3893621F8490 for ; Mon, 17 Dec 2012 19:03:31 -0800 (PST) Received: (qmail 5246 invoked from network); 18 Dec 2012 03:03:24 -0000 Received: from unknown (110.169.202.60) by sg2plout10-01.prod.sin2.secureserver.net (182.50.145.4) with ESMTP; 18 Dec 2012 03:03:24 -0000 Message-ID: <50CFDCFA.6020301@net-zen.net> Date: Tue, 18 Dec 2012 10:03:22 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Qin Wu References: <50CFCBF9.3070301@net-zen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Dec 2012 22:28:26 -0800 Cc: Jonathan Lennox , xrblock@ietf.org, draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org, Glen Zorn , mmusic@ietf.org Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard 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, 18 Dec 2012 03:03:32 -0000 On 12/18/2012 09:20 AM, Qin Wu wrote: > I guess the reference "RFC3711 section 5" Jonathan mentioned should > be corrected as "RFC3611 section 5". If my understanding is correct, > what Jonathan suggested is to have the following change: OLD TEXT: " > RFC 3611 defines the use of SDP (Session Description Protocol) > [RFC4566] for signaling the use of RTCP XR blocks. XR blocks MAY be > used without prior signaling. > > " NEW TEXT: " RFC 3611 defines the use of SDP (Session Description > Protocol) [RFC4566] for signaling the use of RTCP XR blocks. However > XR blocks MAY be used without prior signaling (see section 5 of > RFC3611). " Please correct me if I am wrong. My comment still stands: the existing text is not confusing & needn't be changed. ... From ari.keranen@nomadiclab.com Tue Dec 18 04:43: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 5EB6221F89ED for ; Tue, 18 Dec 2012 04:43:12 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fo6uUgaOw6w for ; Tue, 18 Dec 2012 04:43:11 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id BAD5D21F8897 for ; Tue, 18 Dec 2012 04:43:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id B7D544E6F5; Tue, 18 Dec 2012 14:43:08 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omxuu-xLCi6s; Tue, 18 Dec 2012 14:43:08 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 323414E6E1; Tue, 18 Dec 2012 14:43:08 +0200 (EET) Message-ID: <50D064DC.1080000@nomadiclab.com> Date: Tue, 18 Dec 2012 14:43:08 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> <50CF3C03.4050205@nomadiclab.com> <50CF4349.5010100@ericsson.com> In-Reply-To: <50CF4349.5010100@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 18 Dec 2012 12:43:12 -0000 On 12/17/12 6:07 PM, Magnus Westerlund wrote: > On 2012-12-17 16:36, Ari Keranen wrote: >> On 12/6/12 5:03 PM, Magnus Westerlund wrote: >>> On 2012-12-05 22:22, Ari Keranen wrote: [...] >>>> Aggressive nomination SHALL be used with RTSP. This doesn't have >>>> the >>>> negative impact that it has in offer/answer as media playing only >>>> starts after issuing a PLAY request. >>>> >>>> But it does have the downside of possibly selecting a lower-priority >>>> pair due to single dropped (e.g., due to congestion) connectivity check >>>> message for a higher priority pair. That said, probably SHALL is >>>> appropriate here, just wanted to make sure the implications are >>>> understood. >>> >>> Yes, but with ICE-RTSP you will retransmit the higher priority also, >>> thus if that works and you get a response that alternative is nominated >>> and will be used. But we probably should clarify what it means when >>> multiple candidate pairs are nominated, and in worse case the server >>> will use different paths for different media streams. >> >> According to ICE RFC, if multiple pairs end up nominated due to >> aggressive nomination, the highest priority one will be used (you get >> some transient behavior). >> >> But do you mean that you will keep retransmitting on a higher priority >> pair even if a lower priority pair has been (aggressively) selected and >> all check lists are in Completed state? > > I guess this needs to be expanded a bit. What I mean is that if due to > some reason one get a lower prioritized pair to respond and then get an > answer from the more prioritized then it actually makes sense to unlock > the full checklist for the more prioritized and let it run to completion > prior to sending the PLAY request. By unlocking checklist, do you mean moving it from Completed back to Running state and continuing all running checks (until when)? And in the case you mention above, both candidates are in the same check list, right? Anyway, it would be good to clarify this. Cheers, Ari From internet-drafts@ietf.org Tue Dec 18 05:49: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 3B0B521F89A3; Tue, 18 Dec 2012 05:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkjlViv3kpgt; Tue, 18 Dec 2012 05:49:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3BA21F89C0; Tue, 18 Dec 2012 05:49:10 -0800 (PST) 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.37 Message-ID: <20121218134910.30557.92847.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 05:49:10 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-15.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: Tue, 18 Dec 2012 13:49:11 -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 : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-15.txt Pages : 37 Date : 2012-12-18 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Simo.Veikkolainen@nokia.com Tue Dec 18 06:01: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 7704E21F8A09 for ; Tue, 18 Dec 2012 06:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLybQfYOU5YV for ; Tue, 18 Dec 2012 06:01:38 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 64CD721F88DB for ; Tue, 18 Dec 2012 06:01:38 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qBIE1WMl032399 for ; Tue, 18 Dec 2012 16:01:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Dec 2012 16:01:05 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.142]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0318.003; Tue, 18 Dec 2012 14:01:04 +0000 From: To: Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-15.txt Thread-Index: AQHN3SaTEEuOlv5QQEK6PSM647n70pgek7BA Date: Tue, 18 Dec 2012 14:01:04 +0000 Message-ID: References: <20121218134910.30557.92847.idtracker@ietfa.amsl.com> In-Reply-To: <20121218134910.30557.92847.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-headerinfofordlp: None x-tituslabs-classificationhash-30: NgLgUAGhIMVcmkVcu9QCA++pacJLza70eKLlXGeFvL9wKhXSy8cPmB1O7f+1g131u+p7XQQSY5M0SND5LfihhG73G5VBZNh1ID0Bsj5cqcL5H/n6M4BvHe1wSFzsptYo5qJjFEYLF7hsBEUkP7tBf6UAPMXaEyc9S9zavP06aXM5gxm6zZm7GsMA91lAXK6P3kmQ9WK1nq5bW3YoBpax3b7LGijDDY84q6p0wSsFte0f61UxgE55/tzizKRzzqQ6YkgIBF2HyW3VGFGCYC48lg== x-originating-ip: [62.78.254.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Dec 2012 14:01:05.0915 (UTC) FILETIME=[1F6B04B0:01CDDD28] X-Nokia-AV: Clean Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-15.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: Tue, 18 Dec 2012 14:01:39 -0000 Hello, We have submitted a new version of the draft on SDP for circuit-switched be= arers. This now addresses all comments that were raised during review for p= ublication. There is one technical change in this document: instead of refe= rring to 'global-number' of RFC3966 we now refer to 'global-number-digits'.= We did not have any clear usage for the additional parameters allowed by '= global-number', and referring to the digits only makes the format simpler. Additionally, some typos were corrected. On behalf of the authors, Simo -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= ext internet-drafts@ietf.org Sent: 18. joulukuuta 2012 15:49 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-15.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : Session Description Protocol (SDP) Extension For Setting= Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Publ= ic Switched Telephone Network (PSTN) Author(s) : Miguel A. Garcia-Martin Simo Veikkolainen Filename : draft-ietf-mmusic-sdp-cs-15.txt Pages : 37 Date : 2012-12-18 Abstract: This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-cs-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From jonathan@vidyo.com Tue Dec 18 07:18: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 8D27D21F8A2F; Tue, 18 Dec 2012 07:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avbXS4+mII9u; Tue, 18 Dec 2012 07:18:23 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id D6ACE21F892E; Tue, 18 Dec 2012 07:18:22 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 039A24169C8; Tue, 18 Dec 2012 04:16:54 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 245F24169E4; Tue, 18 Dec 2012 04:16:53 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 18 Dec 2012 10:18:18 -0500 From: Jonathan Lennox To: Qin Wu , Glen Zorn Date: Tue, 18 Dec 2012 10:18:12 -0500 Thread-Topic: SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard Thread-Index: Ac3cxkH92ClQKy5JQAuJd73gbsI7bwAbGDzQ Message-ID: References: <50CFCBF9.3070301@net-zen.net> 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 Cc: "xrblock@ietf.org" , "draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org" , "mmusic@ietf.org" , "gwz@net-zen.net" Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard 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, 18 Dec 2012 15:18:23 -0000 Yes, that text addition seems reasonable to me. For people experienced with XRBlocks, Glen's point that this isn't confusin= g is taken; but I think this addition would be helpful for those (like me) = who are coming to this somewhat cold. Sorry for the typo in the RFC number. -----Original Message----- From: Qin Wu [mailto:bill.wu@huawei.com]=20 Sent: Monday, December 17, 2012 9:20 PM To: Glen Zorn; Jonathan Lennox Cc: mmusic@ietf.org; draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org; gwz= @net-zen.net; xrblock@ietf.org Subject: Re: SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard I guess the reference "RFC3711 section 5" Jonathan mentioned should be corr= ected as "RFC3611 section 5". If my understanding is correct, what Jonathan suggested is to have the foll= owing change: OLD TEXT: " RFC 3611 defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of RTCP XR blocks. XR blocks MAY be used without prior signaling. " NEW TEXT: " RFC 3611 defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of RTCP XR blocks. However XR blocks MA= Y be used without prior signaling (see section 5 of RFC3611). " Please correct me if I am wrong. Regards! -Qin ----- Original Message -----=20 From: "Glen Zorn" To: "Jonathan Lennox" Cc: ; ;= Sent: Tuesday, December 18, 2012 9:50 AM Subject: Re: SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard > On 12/17/2012 10:49 PM, Jonathan Lennox wrote: >=20 >> I have been asked to perform the SDP Directorate review for > > draft-ietf-xrblock-rtcp-xr-discard. I reviewed the -10 version of the > > document. > > > > > > > > Syntactically, the SDP usage in this document seems fine. It is a > > simple and correct usage of an extension point defined in RFC 3711. > > > > > > > > However, the statement in Section 4 that "XR blocks MAY be used > > without explicit signaling" is confusing, as it implies that the > > entire SDP section is entirely optional. This document should at > > least reference Section 5 of RFC 3711, which gives guidance as to > > when SDP signaling of the use of XR blocks is recommended. > > >=20 > I'm not sure why this is confusing (aside from fact that RFC 3711 is=20 > itself confusing: it says "although the use of SDP signaling for XR=20 > blocks may be optional, if used, it MUST be used as defined here". /May/= =20 > be optional? Optionality seems pretty black and white to me ;-). That=20 > said, however, it does seem to be relatively clear that the usage of SDP= =20 > /is/ optional & along with it the section on SDP in this and other=20 > similar drafts. What am I missing? >=20 > ... > From dwing@cisco.com Tue Dec 18 09:28: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 D268621F8633 for ; Tue, 18 Dec 2012 09:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD8-2Rd4hvhg for ; Tue, 18 Dec 2012 09:28:37 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6AE21F862D for ; Tue, 18 Dec 2012 09:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2212; q=dns/txt; s=iport; t=1355851717; x=1357061317; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eW7thKebPgd6uRPxmUur0shKozXwh106AQhGFiodqZs=; b=GDqTIgU6cz+SQTh90+lalNZNsJtRnrgXX4TpMyQpOUJQ5Gywo7r31p63 saZmTWAWWhAo2xvSI3Ac2UNqqRGmaH5IgRqV8zLAIQvbl70IVk416YHnv i18ubyT4crvNrJbkERXIKOV+lhbOW39KT6Bno5JMPNXBvAOiF8CxqcQ1a g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUGAPym0FCrRDoG/2dsb2JhbABFg0i6YRZzgh4BAQEECAIwPwwBAwIJDgMEAQEBJwcZLQkIAgQBEgsFiAKoI5BBjEmEQwOIYYUciA2QSIMU X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208";a="63778854" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 18 Dec 2012 17:28:34 +0000 Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBIHSYCf022281; Tue, 18 Dec 2012 17:28:34 GMT From: "Dan Wing" To: "'Glen Zorn'" , "'Jonathan Lennox'" References: <50CFCBF9.3070301@net-zen.net> In-Reply-To: <50CFCBF9.3070301@net-zen.net> Date: Tue, 18 Dec 2012 09:28:34 -0800 Message-ID: <0d4c01cddd45$1b443830$51cca890$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIoYaEQK4bEwygAtyzO2Ml1f9vkzwGOdUiNl11R0vA= Content-Language: en-us Cc: draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard 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, 18 Dec 2012 17:28:37 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Glen Zorn > Sent: Monday, December 17, 2012 5:51 PM > To: Jonathan Lennox > Cc: draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org; mmusic@ietf.org; > gwz@net-zen.net > Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp- > xr-discard > > On 12/17/2012 10:49 PM, Jonathan Lennox wrote: > > > I have been asked to perform the SDP Directorate review for > > draft-ietf-xrblock-rtcp-xr-discard. I reviewed the -10 version of the > > document. > > > > > > > > Syntactically, the SDP usage in this document seems fine. It is a > > simple and correct usage of an extension point defined in RFC 3711. > > > > > > > > However, the statement in Section 4 that "XR blocks MAY be used > > without explicit signaling" is confusing, as it implies that the > > entire SDP section is entirely optional. This document should at > > least reference Section 5 of RFC 3711, which gives guidance as to > > when SDP signaling of the use of XR blocks is recommended. > > > > I'm not sure why this is confusing (aside from fact that RFC 3711 is > itself confusing: it says "although the use of SDP signaling for XR > blocks may be optional, if used, it MUST be used as defined here". /May/ > be optional? Optionality seems pretty black and white to me ;-). That > said, however, it does seem to be relatively clear that the usage of SDP > /is/ optional & along with it the section on SDP in this and other > similar drafts. What am I missing? (RFC3611, you both meant to write. RFC3711 is SRTP, RFC3611 is RTCP-XR). SDP lines are supposed to be declarative or negotiated. RTCP-XR seems to have done neither: SDP is just there as a check-box. What is missing is an explanation of when and why would an endpoint would include the SDP, and when and why would it omit the SDP. But, if the endpoints are going to send RTCP-XR whenever it wants, no matter if the remote end cares to receive RTCP-XR, why do we have SDP defined at all? Just send RTCP-XR and let's save SDP implementation effort and remove the SDP definitions. -d From magnus.westerlund@ericsson.com Wed Dec 19 05:10: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 403E521F8750 for ; Wed, 19 Dec 2012 05:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtSVpyG4rc5M for ; Wed, 19 Dec 2012 05:09:59 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E833821F87BD for ; Wed, 19 Dec 2012 05:09:58 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-f2-50d1bca57fa5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7A.A9.04318.5ACB1D05; Wed, 19 Dec 2012 14:09:57 +0100 (CET) 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.279.1; Wed, 19 Dec 2012 14:09:57 +0100 Message-ID: <50D1BCA3.2030700@ericsson.com> Date: Wed, 19 Dec 2012 14:09:55 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ari Keranen References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> <50CF3C03.4050205@nomadiclab.com> <50CF4349.5010100@ericsson.com> <50D064DC.1080000@nomadiclab.com> In-Reply-To: <50D064DC.1080000@nomadiclab.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje7SPRcDDJ5f1LRoe/OLzaL9zREm i6nLH7M4MHssWfKTyaNzUbTHl8uf2QKYo7hsUlJzMstSi/TtErgylszcwlRwT6fieKNRA+NR 5S5GTg4JAROJ619mMUPYYhIX7q1n62Lk4hASOMkoserwOSYIZzmjRP/fFkaQKl4BbYnLr7Yy gdgsAqoSu87OYQOx2QQsJG7+aASzRQV8JWbt+cUEUS8ocXLmExYQW0RAR6J7212wOLOAu8TR Q9/BNgsLWEnsf9fPCrFsI6PEzhvzwIo4BfQk/r9Zwg5xnqTEommdLBDNehJTrkIcxCwgL9G8 dTbYICGg4xqaOlgnMArNQrJ7FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAzfg1t+G+xg3HRf7BCj NAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M/puXx1vdLv8XaD7NILPw/vce mcedamoB50L+8W1yd/nziq/wjI7i9FnSXImrl87TPpHy/FCW0rkjD3sPv65///DlEal2jkOv EkJW3HhsJH+ytHLR5oCJ14RFlSQf8nSK/TTrn/rrwplnwj5y7If8BNdM/9DfsEn2nJPEzFAG m0aN9eo9D9eZK7EUZyQaajEXFScCAJhlr2ctAgAA Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 19 Dec 2012 13:10:00 -0000 Ari, Thanks for keep following up on this. Please see below. On 2012-12-18 13:43, Ari Keranen wrote: > On 12/17/12 6:07 PM, Magnus Westerlund wrote: >> On 2012-12-17 16:36, Ari Keranen wrote: >>> On 12/6/12 5:03 PM, Magnus Westerlund wrote: >>>> On 2012-12-05 22:22, Ari Keranen wrote: > [...] >>>>> Aggressive nomination SHALL be used with RTSP. This doesn't have >>>>> the >>>>> negative impact that it has in offer/answer as media playing only >>>>> starts after issuing a PLAY request. >>>>> >>>>> But it does have the downside of possibly selecting a lower-priority >>>>> pair due to single dropped (e.g., due to congestion) connectivity >>>>> check >>>>> message for a higher priority pair. That said, probably SHALL is >>>>> appropriate here, just wanted to make sure the implications are >>>>> understood. >>>> >>>> Yes, but with ICE-RTSP you will retransmit the higher priority also, >>>> thus if that works and you get a response that alternative is nominated >>>> and will be used. But we probably should clarify what it means when >>>> multiple candidate pairs are nominated, and in worse case the server >>>> will use different paths for different media streams. >>> >>> According to ICE RFC, if multiple pairs end up nominated due to >>> aggressive nomination, the highest priority one will be used (you get >>> some transient behavior). >>> >>> But do you mean that you will keep retransmitting on a higher priority >>> pair even if a lower priority pair has been (aggressively) selected and >>> all check lists are in Completed state? >> >> I guess this needs to be expanded a bit. What I mean is that if due to >> some reason one get a lower prioritized pair to respond and then get an >> answer from the more prioritized then it actually makes sense to unlock >> the full checklist for the more prioritized and let it run to completion >> prior to sending the PLAY request. > > By unlocking checklist, do you mean moving it from Completed back to > Running state and continuing all running checks (until when)? And in the > case you mention above, both candidates are in the same check list, right? > > Anyway, it would be good to clarify this. I have produced a bit of new text. However, having thought about this I don't want to make any change to the ICE procedures as that could easily introduce issues and makes the changes for ICE-RTSP even bigger. Instead I propose that we change the SHALL to a SHOULD so that client implementations that see issues with using aggressive nomination can select to do regular nomination instead and always accept a bit more delay instead of possibly ending up with different network paths between different media resources SETUP in the RTSP session. Thus I have written the following text, please review and comment. 6.7. Client to Server ICE Connectivity Check The client receives the SETUP response and learns the candidate addresses to use for the connectivity checks. The client SHALL initiate its connectivity check, following the procedures in Section 6 of ICE [RFC5245]. The STUN transaction pacer SHALL be used across all media streams part of the same RTSP session. Aggressive nomination SHOULD be used with RTSP during initial SETUP for a resource. This doesn't have all the negative impact that it has in offer/answer as media playing only starts after issuing a PLAY request. Thus the issue with a change of the media path being used for delivery can be avoided by not issuing a PLAY request while STUN connectivity checks are still outstanding. Aggressive nomination can result in multiple candidate pairs having their nominated flag set but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY request is sent the media will arrive on the pair with the highest priority. Note, different media resources may still end up with different foundations. Note: The above does not change ICE and its handling of aggressive nomination. Using aggressive nomination a given media stream can have a higher priority candidate pair with an outstanding connectivity check message when its check list completes, to also move that candidate pair into Succeeded state and set the Nominated flag. Thus moving the used pair to this higher priority candidate pair. To avoid this occurring during actual media transport, the RTSP client can add an additional checks when getting the ICE processing overall is completed to indicate if there is still higher priority connectivity checks outstanding. If some check is still outstanding then some additional timeout or the completion of the outstanding checks before progressing with a PLAY request. One alternative is to accept the risk for a path change during media delivery. For RTSP clients that want to ensure that each media resource uses the same path can use regular nomination where both the ICE processing completion criteria can be controlled in addition to which media streams being nominated for use. This does not affect the RTSP server, as its role is the one of being controlled. -- 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 ari.keranen@nomadiclab.com Wed Dec 19 09:50:17 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 C203321F842C for ; Wed, 19 Dec 2012 09:50:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLt2U0bbJoqI for ; Wed, 19 Dec 2012 09:50:17 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAA421F8479 for ; Wed, 19 Dec 2012 09:50:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id C81CC4E6F2; Wed, 19 Dec 2012 19:50:14 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6Dtu20aOlaK; Wed, 19 Dec 2012 19:50:14 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 058864E6E9; Wed, 19 Dec 2012 19:50:14 +0200 (EET) Message-ID: <50D1FE55.6020108@nomadiclab.com> Date: Wed, 19 Dec 2012 19:50:13 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50BFBAFC.8080106@nomadiclab.com> <50C0B3AB.4010509@ericsson.com> <50CF3C03.4050205@nomadiclab.com> <50CF4349.5010100@ericsson.com> <50D064DC.1080000@nomadiclab.com> <50D1BCA3.2030700@ericsson.com> In-Reply-To: <50D1BCA3.2030700@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mmusic-rtsp-nat@tools.ietf.org, mmusic Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review 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, 19 Dec 2012 17:50:17 -0000 Hi Magnus, On 12/19/12 3:09 PM, Magnus Westerlund wrote: > Ari, > > Thanks for keep following up on this. Please see below. No problem! Comments inline. > On 2012-12-18 13:43, Ari Keranen wrote: >> On 12/17/12 6:07 PM, Magnus Westerlund wrote: >>> On 2012-12-17 16:36, Ari Keranen wrote: >>>> On 12/6/12 5:03 PM, Magnus Westerlund wrote: >>>>> On 2012-12-05 22:22, Ari Keranen wrote: >> [...] >>>>>> Aggressive nomination SHALL be used with RTSP. This doesn't have >>>>>> the >>>>>> negative impact that it has in offer/answer as media playing only >>>>>> starts after issuing a PLAY request. >>>>>> >>>>>> But it does have the downside of possibly selecting a lower-priority >>>>>> pair due to single dropped (e.g., due to congestion) connectivity >>>>>> check >>>>>> message for a higher priority pair. That said, probably SHALL is >>>>>> appropriate here, just wanted to make sure the implications are >>>>>> understood. >>>>> >>>>> Yes, but with ICE-RTSP you will retransmit the higher priority also, >>>>> thus if that works and you get a response that alternative is nominated >>>>> and will be used. But we probably should clarify what it means when >>>>> multiple candidate pairs are nominated, and in worse case the server >>>>> will use different paths for different media streams. >>>> >>>> According to ICE RFC, if multiple pairs end up nominated due to >>>> aggressive nomination, the highest priority one will be used (you get >>>> some transient behavior). >>>> >>>> But do you mean that you will keep retransmitting on a higher priority >>>> pair even if a lower priority pair has been (aggressively) selected and >>>> all check lists are in Completed state? >>> >>> I guess this needs to be expanded a bit. What I mean is that if due to >>> some reason one get a lower prioritized pair to respond and then get an >>> answer from the more prioritized then it actually makes sense to unlock >>> the full checklist for the more prioritized and let it run to completion >>> prior to sending the PLAY request. >> >> By unlocking checklist, do you mean moving it from Completed back to >> Running state and continuing all running checks (until when)? And in the >> case you mention above, both candidates are in the same check list, right? >> >> Anyway, it would be good to clarify this. > > I have produced a bit of new text. However, having thought about this I > don't want to make any change to the ICE procedures as that could easily > introduce issues and makes the changes for ICE-RTSP even bigger. Instead > I propose that we change the SHALL to a SHOULD so that client > implementations that see issues with using aggressive nomination can > select to do regular nomination instead and always accept a bit more > delay instead of possibly ending up with different network paths between > different media resources SETUP in the RTSP session. Makes sense. I also now remember another problem with aggressive nomination. I'll send a separate mail to the list about that. > Thus I have written the following text, please review and comment. > > 6.7. Client to Server ICE Connectivity Check > > The client receives the SETUP response and learns the candidate > addresses to use for the connectivity checks. The client SHALL > initiate its connectivity check, following the procedures in Section > 6 of ICE [RFC5245]. The STUN transaction pacer SHALL be used across > all media streams part of the same RTSP session. BTW, how is this (transaction pacer) different from regular ICE? If it's not, does it need to be mentioned? Also "(that are) part of". > Aggressive nomination SHOULD be used with RTSP during initial SETUP > for a resource. This doesn't have all the negative impact that it > has in offer/answer as media playing only starts after issuing a PLAY > request. Thus the issue with a change of the media path being used > for delivery can be avoided by not issuing a PLAY request while STUN > connectivity checks are still outstanding. Aggressive nomination can > result in multiple candidate pairs having their nominated flag set > but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY > request is sent the media will arrive on the pair with the highest > priority. Note, different media resources may still end up with > different foundations. > > Note: The above does not change ICE and its handling of aggressive > nomination. Using aggressive nomination a given media stream can > have a higher priority candidate pair with an outstanding > connectivity check message when its check list completes, to also > move that candidate pair into Succeeded state and set the Nominated Can't parse this sentence. Something missing? > flag. Thus moving the used pair to this higher priority candidate > pair. To avoid this occurring during actual media transport, the > RTSP client can add an additional checks when getting the ICE Remove "an" and "getting" Also, I guess you mean "continue sending checks" (i.e., no "new" additional checks). > processing overall is completed to indicate if there is still higher > priority connectivity checks outstanding. If some check is still > outstanding then some additional timeout or the completion of the Some word missing from this sentence. > outstanding checks before progressing with a PLAY request. One > alternative is to accept the risk for a path change during media > delivery. > > For RTSP clients that want to ensure that each media resource uses Remove "For" > the same path can use regular nomination where both the ICE > processing completion criteria can be controlled in addition to which > media streams being nominated for use. This does not affect the RTSP > server, as its role is the one of being controlled. But yes, overall the idea looks OK to me. Cheers, Ari From ari.keranen@nomadiclab.com Wed Dec 19 09:50:48 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 B947121F886B for ; Wed, 19 Dec 2012 09:50:48 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqw7VBkhQELu for ; Wed, 19 Dec 2012 09:50:48 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 03DFE21F842C for ; Wed, 19 Dec 2012 09:50:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 78FDC4E6F2 for ; Wed, 19 Dec 2012 19:50:46 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H45TC-6uELvI for ; Wed, 19 Dec 2012 19:50:46 +0200 (EET) Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 091814E6E9 for ; Wed, 19 Dec 2012 19:50:46 +0200 (EET) Message-ID: <50D1FE75.9060709@nomadiclab.com> Date: Wed, 19 Dec 2012 19:50:45 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE aggressive nomination problem 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, 19 Dec 2012 17:50:48 -0000 Hi all, Going through the ICE spec reminded me of one old problem with aggressive nomination that I discussed with Philip Matthews back when ICE was published: Two endpoints L and R. L is the offerer and controlling end. There are two possible paths, and just one component. Since L is using aggressive nomination, it sets the USE-CANDIDATE flag in each Binding request. However, the Binding response for the first path does not make it back to L. When the second check succeeds, L immediately stops ICE processing and uses the second path. However, R thinks the first path is being used. Initially, L will use path 2 for data, while R will use path 1. Eventually, both paths will fail, because L is only sending keep-alives on path 2, while R is only sending them on path 1. L R <--------- Bind req --------------------- ] ---------- Bind resp -------------------> ] Path 1 ---------- Bind req, USE-CAND ----------> ] X <-- Bind resp -------------------- ] <--------- Bind req --------------------- ] ---------- Bind resp -------------------> ] Path 2 ---------- Bind req, USE-CAND ----------> ] <--------- Bind resp -------------------- ] --- Any good ideas how to fix this? Should the controlling agent just keep retransmitting even after successful nomination (for how long)? The updated offer (if we make that MUST in all cases) will help to detect the problem though and this could also be added to the list of "reasons for not using aggressive nomination unless you really have to". Cheers, Ari From fluffy@iii.ca Mon Dec 24 06:18: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 5B7C721F891A for ; Mon, 24 Dec 2012 06:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68dhTncFyhFI for ; Mon, 24 Dec 2012 06:18:08 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id EA58421F88F3 for ; Mon, 24 Dec 2012 06:18:07 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 74F3C22E1F3 for ; Mon, 24 Dec 2012 09:18:01 -0500 (EST) From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_FD734865-79D6-4C88-B5A5-A09EE2B7D318" Date: Mon, 24 Dec 2012 07:17:58 -0700 References: <20121224073557.8F95921F8C10@ietfa.amsl.com> To: mmusic WG Message-Id: <014CF49E-8161-4017-8A21-7CB239BF7C61@iii.ca> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [MMUSIC] =?windows-1252?q?I_sent_this_long_ago_=85=2E?= 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, 24 Dec 2012 14:18:10 -0000 --Apple-Mail=_FD734865-79D6-4C88-B5A5-A09EE2B7D318 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 seems there is something wrong with mailing list=85=20 Begin forwarded message: > From: Mail Delivery System > Subject: Undelivered Mail Returned to Sender > Date: December 24, 2012 12:35:57 AM MST > To: >=20 > This is the mail system at host ietfa.amsl.com. >=20 > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. >=20 > For further assistance, please send mail to postmaster. >=20 > If you do so, please include this problem report. You can > delete your own text from the attached returned message. >=20 > The mail system >=20 > : mail forwarding loop for = mmusic@ietfa.amsl.com > Reporting-MTA: dns; ietfa.amsl.com > X-Postfix-Queue-ID: 746F321F8C0F > X-Postfix-Sender: rfc822; fluffy@cisco.com > Arrival-Date: Sun, 23 Dec 2012 23:35:57 -0800 (PST) >=20 > Final-Recipient: rfc822; mmusic@ietfa.amsl.com > Original-Recipient: rfc822;mmusic@ietf.org > Action: failed > Status: 5.4.6 > Diagnostic-Code: X-Postfix; mail forwarding loop for = mmusic@ietfa.amsl.com >=20 > From: "Cullen Jennings (fluffy)" > Subject: [MMUSIC] SDP work needed for WebRTC stuff > Date: December 8, 2012 3:41:49 PM MST > To: mmusic WG >=20 >=20 >=20 > I was looking over everything that needs to be completed to finish a = fist cut of the WebRTC related work. There are a handful of big SDP = problems that are currently blocking some of the WebRTC work and I'd = like to figure out how to make some progress on them.=20 >=20 > Let me loosely characterize them as=20 >=20 > 1) If we have several video streams, how do theses map up to 1 or more = m lines.=20 >=20 > 2) if we are doing port multiplexing, what does the SDP look like (the = bundle problem)=20 >=20 > 3) How do we map the RTCWeb track and stream label concepts to = identifiers in SDP=20 >=20 > 3) SDP for application running over SCTP/DTLS=20 >=20 > I don't want to speak for all the various chairs but I am under the = impression that most of chairs of related groups in W3C and IETF believe = these are issues that need to be resolved primarily in the MMUSIC WG and = that they impact both WebRTC and CLUE as well as the general long term = use of SDP in SIP and other protocols.=20 >=20 > I'd like to get some discussion going on how we can make some progress = on these. I don't think we are going to solve these in 20 minutes of = discussion at an IETF meeting so I think we probably need some interim = (virtual or face to face) to sort this out.=20 >=20 > Thoughts?=20 >=20 > Cullen =20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________=20 > mmusic mailing list=20 > mmusic@ietf.org=20 > https://www.ietf.org/mailman/listinfo/mmusic=20 >=20 >=20 --Apple-Mail=_FD734865-79D6-4C88-B5A5-A09EE2B7D318 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Mail Delivery = System <MAILER-DAEMON@ietfa.amsl.com<= /a>>
=
This is the mail system at host ietfa.amsl.com.

I'm sorry to = have to inform you that your message could not
be delivered to one or = more recipients. It's attached below.

For further assistance, = please send mail to postmaster.

If you do so, please include this = problem report. You can
delete your own text from the attached = returned message.

=             &n= bsp;     The mail system

<mmusic@ietfa.amsl.com>: = mail forwarding loop for mmusic@ietfa.amsl.com
Reporti= ng-MTA: dns; ietfa.amsl.com
X-Postfix-Queue-ID: = 746F321F8C0F
X-Postfix-Sender: rfc822; fluffy@cisco.com
Arrival-Date: = Sun, 23 Dec 2012 23:35:57 -0800 (PST)

Final-Recipient: rfc822; mmusic@ietfa.amsl.com
Origina= l-Recipient: rfc822;mmusic@ietf.org
Action: = failed
Status: 5.4.6
Diagnostic-Code: X-Postfix; mail forwarding = loop for mmusic@ietfa.amsl.com

From: = "Cullen Jennings (fluffy)" <fluffy@cisco.com>
=
Subject: = [MMUSIC] SDP work needed for WebRTC = stuff
Date: December 8, 2012 3:41:49 PM MST
To: = mmusic WG <mmusic@ietf.org>


I was looking over everything that needs to be completed to finish a = fist cut of the WebRTC related work. There are a handful of big SDP = problems that are currently blocking some of the WebRTC work and I'd = like to figure out how to make some progress on them.=20

Let me loosely characterize them as=20

1) If we have several video streams, how do theses map up to 1 or more m = lines.=20

2) if we are doing port multiplexing, what does the SDP look like (the = bundle problem)=20

3) How do we map the RTCWeb track and stream label concepts to = identifiers in SDP

3) SDP for application running over SCTP/DTLS=20

I don't want to speak for all the various chairs but I am under the = impression that most of chairs of related groups in W3C and IETF believe = these are issues that need to be resolved primarily in the MMUSIC WG and = that they impact both WebRTC and CLUE as well as the general long term = use of SDP in SIP and other protocols.=20

I'd like to get some discussion going on how we can make some progress = on these. I don't think we are going to solve these in 20 minutes of = discussion at an IETF meeting so I think we probably need some interim = (virtual or face to face) to sort this out.=20

Thoughts?

Cullen <in my individual contributor role>=20





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



= --Apple-Mail=_FD734865-79D6-4C88-B5A5-A09EE2B7D318-- From eckelcu@cisco.com Wed Dec 26 09:50: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 72D9921F87EA for ; Wed, 26 Dec 2012 09:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcmx-bJbn5Uc for ; Wed, 26 Dec 2012 09:50:07 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F82821F8769 for ; Wed, 26 Dec 2012 09:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11496; q=dns/txt; s=iport; t=1356544207; x=1357753807; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7+ceJJGDOiFf37fukPYxfGAxYuQyy/SH3waRMpcuEOE=; b=OjSzbt+eRj6huidwgj4ciV0uAWoosgN4q7z9OBKkM+gAu6rI4JnbLI91 FkACUVugIF0R9shZMj1lDzwBGwrAmumM2QI3qt+tFcS+dlimQRKCnuie7 uPy7J9wVuH3EVs6daqYi9AntuEv/bqDfjAS5YZS3KdY1p13SFzY5uCMdf s=; X-Files: : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFU321CtJV2c/2dsb2JhbABFvWgWc4IeAQEBBAEBAWsXBAIBCA4DAwEBAQsdBwIlCxQJCAIEARIIAQWIBQy1cYxXG4NHYQOILYZbgSKGfo8sgnSBbTU X-IronPort-AV: E=Sophos;i="4.84,357,1355097600"; d="scan'208";a="153641289" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 26 Dec 2012 17:50:06 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBQHo6WK028006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Dec 2012 17:50:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 11:50:06 -0600 From: "Charles Eckel (eckelcu)" To: Cullen Jennings , mmusic WG Thread-Topic: =?Windows-1252?Q?[MMUSIC]_I_sent_this_long_ago_=85.?= Thread-Index: AQHN4eGD30OnyxFpMUiG8drqHaCi2pgrXHiQ Date: Wed, 26 Dec 2012 17:50:05 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046F2078@xmb-aln-x08.cisco.com> References: <20121224073557.8F95921F8C10@ietfa.amsl.com> <014CF49E-8161-4017-8A21-7CB239BF7C61@iii.ca> In-Reply-To: <014CF49E-8161-4017-8A21-7CB239BF7C61@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.51] Content-Type: multipart/mixed; boundary="_002_92B7E61ADAC1BB4F941F943788C08828046F2078xmbalnx08ciscoc_" MIME-Version: 1.0 Subject: Re: [MMUSIC] =?windows-1252?q?I_sent_this_long_ago_=85=2E?= 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, 26 Dec 2012 17:50:08 -0000 --_002_92B7E61ADAC1BB4F941F943788C08828046F2078xmbalnx08ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, I can see you sent the original on Dec 8. It is captured in the archiv= es correctly as having been sent only once and on Dec 8. The resending on D= ec 23 is not shown in the archive. The same is true for a message Magnus se= nt on Dec 12 that was resent on the 23rd as well.=20 http://www.ietf.org/mail-archive/web/mmusic/current/maillist.html When I replied to Magnus's e-mail on Dec 14, it went out to the list correc= tly; however, I did receive an error report a few days later saying "Mail D= elivery System " was unable to send th= e message to Magnus's address. I have attached that e-mail in case it is useful in troubleshooting this is= sue. Cheers, Charles > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Monday, December 24, 2012 6:18 AM > To: mmusic WG > Subject: [MMUSIC] I sent this long ago =85. >=20 >=20 > seems there is something wrong with mailing list=85 >=20 >=20 > Begin forwarded message: >=20 >=20 > From: Mail Delivery System >=20 > Subject: Undelivered Mail Returned to Sender >=20 > Date: December 24, 2012 12:35:57 AM MST >=20 > To: >=20 >=20 > This is the mail system at host ietfa.amsl.com. >=20 > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. >=20 > For further assistance, please send mail to postmaster. >=20 > If you do so, please include this problem report. You can > delete your own text from the attached returned message. >=20 > The mail system >=20 > : mail forwarding loop for > mmusic@ietfa.amsl.com > Reporting-MTA: dns; ietfa.amsl.com > X-Postfix-Queue-ID: 746F321F8C0F > X-Postfix-Sender: rfc822; fluffy@cisco.com > Arrival-Date: Sun, 23 Dec 2012 23:35:57 -0800 (PST) >=20 > Final-Recipient: rfc822; mmusic@ietfa.amsl.com > Original-Recipient: rfc822;mmusic@ietf.org > Action: failed > Status: 5.4.6 > Diagnostic-Code: X-Postfix; mail forwarding loop for > mmusic@ietfa.amsl.com >=20 >=20 > From: "Cullen Jennings (fluffy)" >=20 > Subject: [MMUSIC] SDP work needed for WebRTC stuff >=20 > Date: December 8, 2012 3:41:49 PM MST >=20 > To: mmusic WG >=20 >=20 >=20 >=20 > I was looking over everything that needs to be completed to finish a > fist cut of the WebRTC related work. There are a handful of big SDP > problems that are currently blocking some of the WebRTC work and I'd like > to figure out how to make some progress on them. >=20 > Let me loosely characterize them as >=20 > 1) If we have several video streams, how do theses map up to 1 or > more m lines. >=20 > 2) if we are doing port multiplexing, what does the SDP look like > (the bundle problem) >=20 > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP >=20 > 3) SDP for application running over SCTP/DTLS >=20 > I don't want to speak for all the various chairs but I am under the > impression that most of chairs of related groups in W3C and IETF believe > these are issues that need to be resolved primarily in the MMUSIC WG and > that they impact both WebRTC and CLUE as well as the general long term > use of SDP in SIP and other protocols. >=20 > I'd like to get some discussion going on how we can make some > progress on these. I don't think we are going to solve these in 20 minute= s of > discussion at an IETF meeting so I think we probably need some interim > (virtual or face to face) to sort this out. >=20 > Thoughts? >=20 > Cullen >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 >=20 --_002_92B7E61ADAC1BB4F941F943788C08828046F2078xmbalnx08ciscoc_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 26 Dec 2012 17:50:04 GMT"; modification-date="Wed, 26 Dec 2012 17:50:04 GMT" Received: from rcdn-iport-2.cisco.com (173.37.86.73) by mail.cisco.com (173.37.183.75) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 14 Dec 2012 15:49:46 -0600 Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 14 Dec 2012 21:49:46 +0000 Received: from rcdn-inbound-d.cisco.com (rcdn-inbound-d.cisco.com [72.163.7.173]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBELnj2Y002433 for ; Fri, 14 Dec 2012 21:49:46 GMT Received: from mailgw2.ericsson.se ([193.180.251.37]) by rcdn-inbound-d.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2012 21:49:45 +0000 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2F.7B.24873.8FE9BC05; Fri, 14 Dec 2012 22:49:44 +0100 (CET) Received: from sessmg10.ericsson.net (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.89) with Microsoft SMTP Server id 8.3.279.1; Fri, 14 Dec 2012 22:49:43 +0100 From: Mail Delivery System To: "Charles Eckel (eckelcu)" Subject: Delayed Mail (still being retried) Thread-Topic: Delayed Mail (still being retried) Thread-Index: AQHN2kTvAHtlf0b8UEatmkqPZVCqUg== Date: Fri, 14 Dec 2012 21:49:43 +0000 Message-ID: Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: xhc-rcd-x01.cisco.com X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: rcdn-inbound-d.cisco.com; dkim=neutral (message not signed) header.i=none x-ironport-av: E=Sophos;i="4.84,284,1355097600"; d="scan'208";a="78743236" x-ironport-anti-spam-filtered: true x-ironport-anti-spam-result: AsUBAA2ey1DBtPsllGdsb2JhbACtIJIvFg4BAQEBCQsJCRQFIoIeAQEBgSkDAQIPZgkYCYgSBZtDmGCIcIxXG4QrlyWSIIFs x-from-outside-cisco: 193.180.251.37 Content-Type: multipart/mixed; boundary="_003_ceded94be2c04abab079bc0bccd51c08esessmw0197eemeaericsso_" MIME-Version: 1.0 --_003_ceded94be2c04abab079bc0bccd51c08esessmw0197eemeaericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable #################################################################### # THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. # #################################################################### Your message could not be delivered for 0 days, 4 hours, 0 minutes. It will be retried until it is 5 days, 0 hours, 0 minutes old. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. : 421 4.4.0 [internal] no MXs for this doma= in could be reached at this time --_003_ceded94be2c04abab079bc0bccd51c08esessmw0197eemeaericsso_ Content-Type: message/delivery-status; name="Delivery report" Content-Description: Delivery report Content-Disposition: attachment; filename="Delivery report"; size=456; creation-date="Fri, 14 Dec 2012 21:49:47 GMT"; modification-date="Fri, 14 Dec 2012 21:49:47 GMT" Content-ID: <1E4DE62B1A98E04494EB0B001372D10F@cisco.com> Content-Transfer-Encoding: base64 WC1TeW1hbnRlYy1NZXNzYWdpbmctR2F0ZXdheS1RdWV1ZS1JRDogNEMvM0YtMTYxMTMtN0I2NkJD MDUNClgtU3ltYW50ZWMtTWVzc2FnaW5nLUdhdGV3YXktU2VuZGVyOiByZmM4MjI7IGVja2VsY3VA Y2lzY28uY29tDQpSZXBvcnRpbmctTVRBOiBkbnM7IHNlc3NtZzEwLmVyaWNzc29uLm5ldA0KQXJy aXZhbC1EYXRlOiBGcmksIDE0IERlYyAyMDEyIDIyOjQ5OjQzICswMTAwDQoNCkZpbmFsLVJlY2lw aWVudDogcmZjODIyOyBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NClN0YXR1czogNC40 LjANCkFjdGlvbjogZGVsYXllZA0KTGFzdC1BdHRlbXB0LURhdGU6IEZyaSwgMTQgRGVjIDIwMTIg MjI6NDk6NDMgKzAxMDANCkRpYWdub3N0aWMtQ29kZTogc210cDsgNDIxIDQuNC4wIFtpbnRlcm5h bF0gbm8gTVhzIGZvciB0aGlzIGRvbWFpbiBjb3VsZCBiZSByZWFjaGVkIGF0IHRoaXMgdGltZQ0K --_003_ceded94be2c04abab079bc0bccd51c08esessmw0197eemeaericsso_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 14 Dec 2012 21:49:47 GMT"; modification-date="Fri, 14 Dec 2012 21:49:47 GMT" Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLS with cipher RC4-SHA (RC4-SHA/128 bits)) (Client did not present a certificate) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id BD.EB.16113.ED26BC05; Fri, 14 Dec 2012 18:49:43 +0100 (CET) Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 14 Dec 2012 17:29:44 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBEHTiCc002381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 17:29:44 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 11:29:44 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund CC: Harald Alvestrand , "mmusic@ietf.org" Subject: RE: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01) Thread-Topic: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01) Thread-Index: AQHNu2yZJyuQHhZlfUCEbmtj3UUmnZfbqLRggDniooCAAzujsA== Date: Fri, 14 Dec 2012 17:29:44 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EB88F@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com> <5097DF12.2020209@alvestrand.no> <92B7E61ADAC1BB4F941F943788C08828107CCF@xmb-aln-x08.cisco.com> <50C8548B.5040306@ericsson.com> In-Reply-To: <50C8548B.5040306@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ironport-av: E=Sophos;i="4.84,282,1355097600"; d="scan'208";a="153065176" x-ironport-anti-spam-filtered: true x-ironport-anti-spam-result: AgAFANNgy1CtJV2Z/2dsb2JhbABFvwUWc4IeAQEBAwEMXBEFBwICAgEIEQQBAQEKGQQHGxcUCQgCBA4FCIgFBQG9FASMU4NiYQOIK54mgnOCIg x-originating-ip: [171.68.16.69] dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1355506404; x=1356716004; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NRCq4wTrqo509fEA0oaeA8GFu7cWqhQ4eNNg6aRXY98=; b=i6yeURCp1TXSmQbqQbnUt7+RpvkMFpo2vW+9+246FG+w/bQhmBcoOGGe z26ijCDhzfU9IJzerppe7c8hlLEWWchobkdLgBJXVr/GdFMRLQLdFB78A u5kfDx9AssFAD5InSUwrZn1RXHXN15x4idGJQvMcrMBkWEFzt63MDE8cc M=; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 --_003_ceded94be2c04abab079bc0bccd51c08esessmw0197eemeaericsso_-- --_002_92B7E61ADAC1BB4F941F943788C08828046F2078xmbalnx08ciscoc_-- From abegen@cisco.com Sat Dec 29 14:55: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 C026621F8810 for ; Sat, 29 Dec 2012 14:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyFMtzOmXrGQ for ; Sat, 29 Dec 2012 14:55:29 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 16D3E21F87E0 for ; Sat, 29 Dec 2012 14:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1511; q=dns/txt; s=iport; t=1356821729; x=1358031329; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jEXwk4AGO2iUyI4cS467lNyAY6b3pNDFI3tfWtIffIE=; b=hFj4baooXfqY+UUqyAcAJ/L/WyjnlnGOLOoktrIbY9o+xthWH1V6EH2O d0rc5Bf2CmoKSdWotG/SBOTdrNAV03r9BdRkcWfD1AP2Rl/L/0Kwkfrb4 GRxIp9jPdBCPYj1zGkIeQklILIYsaEKX7jg4a+WnK6JXZqX8uGDIsiIl8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKJ031CtJV2a/2dsb2JhbABEgmyoKZJPFnOCHgEBAQR5DAYBCBEDAQILVh0IAgQOBQgBh3gDDwELtnSLbWolgz1hA5Q3gnGKGwOFDoJ0giY X-IronPort-AV: E=Sophos;i="4.84,379,1355097600"; d="scan'208";a="154391676" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 29 Dec 2012 22:55:28 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBTMtSTu032395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Dec 2012 22:55:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 16:55:28 -0600 From: "Ali C. Begen (abegen)" To: "bernard_aboba@hotmail.com" Thread-Topic: [mmusic] #13: Section 5.14 Thread-Index: AQHNmQOl8f4p7o+W3kOC3iEXNbfIoJgxDemA Date: Sat, 29 Dec 2012 22:55:27 +0000 Message-ID: In-Reply-To: <066.685c700e85270f9f6c394ad153378d7b@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.245.254] Content-Type: text/plain; charset="Windows-1252" Content-ID: <97191F8334FC6445B821B33445CCC5E0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] [mmusic] #13: Section 5.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: Sat, 29 Dec 2012 22:55:29 -0000 Hi Bernard, Do you think this is necessary? http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-param eters-2 lists bunch of other protos that we don't list in 5.14. The text in 8.2.2 is clear saying that: If other RTP profiles are defined in the future, their "proto" name SHOULD be specified in the same manner. For example, an RTP profile whose short name is "XYZ" would be denoted by a "proto" field of "RTP/XYZ". I don't think we need to clutter the text with more examples. -acbegen -----Original Message----- From: mmusic issue tracker Date: Saturday, September 22, 2012 3:48 PM To: "Ali C. Begen" , Bernard Aboba Cc: "mmusic@ietf.org" Subject: [mmusic] #13: Section 5.14 >#13: Section 5.14 > > In Section 5.14 the description only mentions RTP/AVP and > RTP/SAVP. RTP/AVPF and RTP/SAVPF should also be mentioned. > >--=20 >--------------------------------+------------------------ > Reporter: bernard_aboba@=8A | Owner: abegen@=8A > Type: defect | Status: new > Priority: major | Milestone: milestone1 >Component: rfc4566bis | Version: 1.0 > Severity: Active WG Document | Keywords: >--------------------------------+------------------------ > >Ticket URL: >mmusic > From abegen@cisco.com Sat Dec 29 15:03:55 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 A334021F881A for ; Sat, 29 Dec 2012 15:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6rCS9P+iFpw for ; Sat, 29 Dec 2012 15:03:54 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9814921F8818 for ; Sat, 29 Dec 2012 15:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6795; q=dns/txt; s=iport; t=1356822234; x=1358031834; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=raScSi1V9ZfhxSSVVA5noBRUu1VZ7sz3rvFcw51i/W4=; b=bFHA1a9hBYbql+6ZJv1XH0GkXyT28uqsR2scLkrv4l3afpShbBpU87Kq +q2GTFaimKjQ6qlOSrrI4Ly+eZ7uOW7olYK7E98qHSVsqStpJlWrqdLuO jn27Ri3gCKOntVYwMLdicj70i1BDhPogS4xS+dPUc/cNtmcux6eblvolE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIB231CtJV2d/2dsb2JhbAA6Cg6CXrp4FnOCHgEBAQQBAQFlBhcGAQgOAwMBAQEBCh0uCxQJCAIEARIIiAsBC7ZwBIxXAg8Fg0xhA4gtnieCNj6BaT0 X-IronPort-AV: E=Sophos;i="4.84,379,1355097600"; d="scan'208";a="157369559" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 29 Dec 2012 23:03:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBTN3rZr031590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Dec 2012 23:03:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 17:03:53 -0600 From: "Ali C. Begen (abegen)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5hjFjCNGGSDp8U2ifDVcy1cLpQ== Date: Sat, 29 Dec 2012 23:03:52 +0000 Message-ID: In-Reply-To: <503BA87D.10203@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.245.254] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <700211871B98F74F8F7D99B83BDB621F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes 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, 29 Dec 2012 23:03:55 -0000 I don=B9t remember us reaching a consensus regarding the text proposed by Brett. One thing certain is that we don't wanna break anything that complies with 4566 but we should also make the text as clear as possible. I am OK with Brett's suggestion as I don't recall an attribute like what Paul might have seen. But, even if such an attribute exists, the current text would be incorrect, too (This would indicate a problem with that particular attribute not 4566 or 4566bis). Brett's proposal does not make the text any worse. So, I am planning to incorporate this change. Any objections? -acbegen -----Original Message----- From: Paul Kyzivat Date: Monday, August 27, 2012 12:03 PM To: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes >I've always thought this should be the way things work, for all >attributes. But somewhere I came across an attribute (sorry, don't >remember which one) where the attribute at session level means something >different than the attribute at media level, and so can't be treated as >a default for media level. (E.g. the session level is an aggregate limit >for something, while the media level is a limit for a single m-line.) > >Am I just dreaming this? Or can someone identify specific attributes >that behave this way? > >If there are existing attributes that behave this way, then we can't >make a blanket statement like this. There will need to be an escape >hatch. For example: > >"The connection ("c=3D") information in the > session-level section applies to all the media of that session unless > overridden by connection information > in the media description. For instance, in the example > below, TBD..." > >"The attribute ("a=3D") information in the > session-level section applies to all the media of that session unless > overridden by connection information or an attribute of the same name > or choice in the media description, or the specification of that > attribute calls for a different treatment. > For instance, in the example > below, each media behaves as if it were given a "recvonly" attribute. > If the example had additionally contained a "sendrecv" media-level > attribute for audio, only the video media would behave as if it were > given a "recvonly" attribute." > >Even this could have some backward compatibility consequences. I think >there are some attributes that are only defined for media level. This >revision would mean that a session level value could override a default >for media level. Implementations that aren't prepared for that might >break. > > Thanks, > Paul > >On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: >> Brett suggested the following change in the SDP draft. Any objections? >> >> -acbegen >> >> Current text: >> >> "The connection ("c=3D") and attribute ("a=3D") information in the >> session-level section applies to all the media of that session unless >> overridden by connection information or an attribute of the same name >> in the media description. For instance, in the example below, each >> media behaves as if it were given a "recvonly" attribute." >> >> Proposed text: >> >> "The connection ("c=3D") and attribute ("a=3D") information in the >> session-level section applies to all the media of that session unless >> overridden by connection information or an attribute of the same name >> or choice in the media description. For instance, in the example >> below, each media behaves as if it were given a "recvonly" attribute. >> If the example had additionally contained a "sendrecv" media-level >> attribute for audio, only the video media would behave as if it were >> given a "recvonly" attribute." >> >>> -----Original Message----- >>> From: Brett Tate [mailto:brett@broadsoft.com] >>> Sent: Wednesday, August 08, 2012 7:54 AM >>> To: Ali C. Begen (abegen); mmusic@ietf.org >>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes >>> >>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the >>>>> following. >>>>> >>>>> "In general, session-level values are the default for all >>>>> media unless overridden by an equivalent media-level value." >>>>> >>>>> "The connection ("c=3D") and attribute ("a=3D") information >>>>> in the session-level section applies to all the media of >>>>> that session unless overridden by connection information >>>>> or an attribute of the same name in the media description. >>>>> For instance, in the example below, each media behaves >>>>> as if it were given a "recvonly" attribute." >>>>> >>>>> If the attributes are related but with different names >>>>> (such as "inactive" and "sendrecv"), does the attribute >>>>> at the media-level have precedence over the value at the >>>>> session-level? If so, I recommend that the draft be >>>>> updated to clarify the topic. >>>> >>>> I believe so. at least that is my understanding from the >>>> text. Does it really need clarification? Thoughts? >>> >>> I think that it should be clarified because it is unclear if "an >>>attribute of the same name" indicates the typical situation or only >>> situation concerning application of "unless overridden by an >>>equivalent media-level value". For instance if I sent "a=3Dinactive" >>> at session-level and "a=3Dsendrecv" at media-level, I'd be concerned >>>that the receiver may interpret the SDP as being >>> abnormal (such as including both values at media-level) instead of >>>allowing "a=3Dsendrecv" to override "a=3Dinactive". >>> >>> In case it matters from an extendibility perspective, requiring the >>>same name might make it easier to recognize the override. >>> However since section 6 already introduces complications with >>>defaulting to "sendrecv" if a new option is defined/used and >>> unknown, allowing the override even when the names are not the same >>>doesn't make things too much worse; it actually >>> allows communication of a backup attribute (such as "a=3Dinactive") if >>>they don't understand the preferred new attribute (such >>> as "a=3Dfoo"). >>> >>> "If none of the attributes "sendonly", "recvonly", "inactive", >>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the >>> default for sessions that are not of the conference type >>> "broadcast" or "H332" (see below)." >>> >>> Thanks for the response, >>> Brett >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Sat Dec 29 16:36: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 5EC2B21F882B for ; Sat, 29 Dec 2012 16:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNnNm1ylQ4eh for ; Sat, 29 Dec 2012 16:36:45 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 63D5421F8795 for ; Sat, 29 Dec 2012 16:36:43 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id hcPw1k0021ei1Bg5CccjHX; Sun, 30 Dec 2012 00:36:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id hcci1k00H3ZTu2S3kcciR4; Sun, 30 Dec 2012 00:36:43 +0000 Message-ID: <50DF8C9A.5040603@alum.mit.edu> Date: Sat, 29 Dec 2012 19:36:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <1.a57ca2dbcae58b0531f5@cisco.com> In-Reply-To: <1.a57ca2dbcae58b0531f5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1356827803; bh=J31yD0rIsdITG+dz+15RwxYBB3yySGeTZfxGaNV+IMs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T123MV2WwzOi15OfJFzwpCl9l1ktm9+lum1Eo9OB0Z1pn17VQNFxsin1cy5dW9912 BW9AvhJqYxj+Pj0HWYyNXUKVUdBvTwRLmMMrW6Q3RTv0TnhLIp0mLKo4giCpfPnOi+ Kgp13XwObL2sIEKvMghe25Tlaku82zra5wmKagY7XnALdF9sBP0bBfWNCY7wD1WO5F 7BxvjPaLnikzab42e4nv6qI2U28zwz+OCmnmJiFEjAEWxbSiVHExY+GsfXbeN2+tm2 C8SrK2k2a0X6L08BGlwSAGsz5WYjGZlDyqb8jX8dWh3zEAMx67VlD76i4WgMigflIG lue+xekKwoKYA== Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes 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, 30 Dec 2012 00:36:46 -0000 On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote: > I donıt remember us reaching a consensus regarding the text proposed by > Brett. One thing certain is that we don't wanna break anything that > complies with 4566 but we should also make the text as clear as possible. > > I am OK with Brett's suggestion as I don't recall an attribute like what > Paul might have seen. But, even if such an attribute exists, the current > text would be incorrect, too (This would indicate a problem with that > particular attribute not 4566 or 4566bis). I found one: a=maxprate in RFC3890. Thanks, Paul > Brett's proposal does not make the text any worse. So, I am planning to > incorporate this change. > > Any objections? > > -acbegen > > -----Original Message----- > From: Paul Kyzivat > Date: Monday, August 27, 2012 12:03 PM > To: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: > session-level attributes > > >I've always thought this should be the way things work, for all > >attributes. But somewhere I came across an attribute (sorry, don't > >remember which one) where the attribute at session level means something > >different than the attribute at media level, and so can't be treated as > >a default for media level. (E.g. the session level is an aggregate limit > >for something, while the media level is a limit for a single m-line.) > > > >Am I just dreaming this? Or can someone identify specific attributes > >that behave this way? > > > >If there are existing attributes that behave this way, then we can't > >make a blanket statement like this. There will need to be an escape > >hatch. For example: > > > >"The connection ("c=") information in the > > session-level section applies to all the media of that session unless > > overridden by connection information > > in the media description. For instance, in the example > > below, TBD..." > > > >"The attribute ("a=") information in the > > session-level section applies to all the media of that session unless > > overridden by connection information or an attribute of the same name > > or choice in the media description, or the specification of that > > attribute calls for a different treatment. > > For instance, in the example > > below, each media behaves as if it were given a "recvonly" attribute. > > If the example had additionally contained a "sendrecv" media-level > > attribute for audio, only the video media would behave as if it were > > given a "recvonly" attribute." > > > >Even this could have some backward compatibility consequences. I think > >there are some attributes that are only defined for media level. This > >revision would mean that a session level value could override a default > >for media level. Implementations that aren't prepared for that might > >break. > > > > Thanks, > > Paul > > > >On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: > >> Brett suggested the following change in the SDP draft. Any objections? > >> > >> -acbegen > >> > >> Current text: > >> > >> "The connection ("c=") and attribute ("a=") information in the > >> session-level section applies to all the media of that session unless > >> overridden by connection information or an attribute of the same name > >> in the media description. For instance, in the example below, each > >> media behaves as if it were given a "recvonly" attribute." > >> > >> Proposed text: > >> > >> "The connection ("c=") and attribute ("a=") information in the > >> session-level section applies to all the media of that session unless > >> overridden by connection information or an attribute of the same name > >> or choice in the media description. For instance, in the example > >> below, each media behaves as if it were given a "recvonly" attribute. > >> If the example had additionally contained a "sendrecv" media-level > >> attribute for audio, only the video media would behave as if it were > >> given a "recvonly" attribute." > >> > >>> -----Original Message----- > >>> From: Brett Tate [mailto:brett@broadsoft.com] > >>> Sent: Wednesday, August 08, 2012 7:54 AM > >>> To: Ali C. Begen (abegen); mmusic@ietf.org > >>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes > >>> > >>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the > >>>>> following. > >>>>> > >>>>> "In general, session-level values are the default for all > >>>>> media unless overridden by an equivalent media-level value." > >>>>> > >>>>> "The connection ("c=") and attribute ("a=") information > >>>>> in the session-level section applies to all the media of > >>>>> that session unless overridden by connection information > >>>>> or an attribute of the same name in the media description. > >>>>> For instance, in the example below, each media behaves > >>>>> as if it were given a "recvonly" attribute." > >>>>> > >>>>> If the attributes are related but with different names > >>>>> (such as "inactive" and "sendrecv"), does the attribute > >>>>> at the media-level have precedence over the value at the > >>>>> session-level? If so, I recommend that the draft be > >>>>> updated to clarify the topic. > >>>> > >>>> I believe so. at least that is my understanding from the > >>>> text. Does it really need clarification? Thoughts? > >>> > >>> I think that it should be clarified because it is unclear if "an > >>>attribute of the same name" indicates the typical situation or only > >>> situation concerning application of "unless overridden by an > >>>equivalent media-level value". For instance if I sent "a=inactive" > >>> at session-level and "a=sendrecv" at media-level, I'd be concerned > >>>that the receiver may interpret the SDP as being > >>> abnormal (such as including both values at media-level) instead of > >>>allowing "a=sendrecv" to override "a=inactive". > >>> > >>> In case it matters from an extendibility perspective, requiring the > >>>same name might make it easier to recognize the override. > >>> However since section 6 already introduces complications with > >>>defaulting to "sendrecv" if a new option is defined/used and > >>> unknown, allowing the override even when the names are not the same > >>>doesn't make things too much worse; it actually > >>> allows communication of a backup attribute (such as "a=inactive") if > >>>they don't understand the preferred new attribute (such > >>> as "a=foo"). > >>> > >>> "If none of the attributes "sendonly", "recvonly", "inactive", > >>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the > >>> default for sessions that are not of the conference type > >>> "broadcast" or "H332" (see below)." > >>> > >>> Thanks for the response, > >>> Brett > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From abegen@cisco.com Sat Dec 29 16:45: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 50DE921F86A5 for ; Sat, 29 Dec 2012 16:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.363 X-Spam-Level: X-Spam-Status: No, score=-9.363 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyW0ykzPluyU for ; Sat, 29 Dec 2012 16:45:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1196321F8610 for ; Sat, 29 Dec 2012 16:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11082; q=dns/txt; s=iport; t=1356828315; x=1358037915; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=twpNCIIkp8fxYJ1L7as60P/WcTFbCIT2TrVCMGG8uEE=; b=fZahgKyC8sSkC99IU4HO+Q1CjBsy7tJLPuDDV2rNLV/5XkL9UMqHbWli S2kI763d8mFoa/piUqqfvtJo7mgnu/w0PootM/NMfa7APs+l61i/7Uz+q ZZImsVlhB2GEZNzwKQWuVxkLhjYhQWEYxSU0V0rlpt43cS3DsjVD6LFtH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJON31CtJXHB/2dsb2JhbAA6Cg6CXoNOtjJ0FnOCHgEBAQMBAQEBMTQGFwYBCA4DAwEBAQEEBh0FBCULFAkIAgQBEgiIBQYBC4snmm0GkFQEgRyLOwIPBYMUOGEDplSCNj6BaT0 X-IronPort-AV: E=Sophos;i="4.84,379,1355097600"; d="scan'208";a="157180964" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 30 Dec 2012 00:45:14 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBU0jEMQ008311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Dec 2012 00:45:14 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 18:45:13 -0600 From: "Ali C. Begen (abegen)" To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes Thread-Index: AQHN5ibtjKlj+bwH1kq6U0T1+4e24g== Date: Sun, 30 Dec 2012 00:45:13 +0000 Message-ID: In-Reply-To: <50DF8C9A.5040603@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.245.254] Content-Type: text/plain; charset="euc-kr" Content-ID: <87080664EB3F7A4F86FAC96A7020BD37@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes 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, 30 Dec 2012 00:45:16 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgPHBreXpp dmF0QGFsdW0ubWl0LmVkdT4NCkRhdGU6IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiA3OjM2 IFBNDQpUbzogIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbTU1VU0lDXSBEcmFmdC1pZXRmLW1tdXNpYy1yZmM0NTY2YmlzLTA1Og0Kc2Vzc2lvbi1sZXZl bAlhdHRyaWJ1dGVzDQoNCj5PbiAxMi8yOS8xMiA2OjAzIFBNLCBBbGkgQy4gQmVnZW4gKGFiZWdl bikgd3JvdGU6DQo+PiBJIGRvbqn2dCByZW1lbWJlciB1cyByZWFjaGluZyBhIGNvbnNlbnN1cyBy ZWdhcmRpbmcgdGhlIHRleHQgcHJvcG9zZWQgYnkNCj4+IEJyZXR0LiBPbmUgdGhpbmcgY2VydGFp biBpcyB0aGF0IHdlIGRvbid0IHdhbm5hIGJyZWFrIGFueXRoaW5nIHRoYXQNCj4+IGNvbXBsaWVz IHdpdGggNDU2NiBidXQgd2Ugc2hvdWxkIGFsc28gbWFrZSB0aGUgdGV4dCBhcyBjbGVhciBhcw0K Pj5wb3NzaWJsZS4NCj4+DQo+PiBJIGFtIE9LIHdpdGggQnJldHQncyBzdWdnZXN0aW9uIGFzIEkg ZG9uJ3QgcmVjYWxsIGFuIGF0dHJpYnV0ZSBsaWtlIHdoYXQNCj4+IFBhdWwgbWlnaHQgaGF2ZSBz ZWVuLiBCdXQsIGV2ZW4gaWYgc3VjaCBhbiBhdHRyaWJ1dGUgZXhpc3RzLCB0aGUgY3VycmVudA0K Pj4gdGV4dCB3b3VsZCBiZSBpbmNvcnJlY3QsIHRvbyAoVGhpcyB3b3VsZCBpbmRpY2F0ZSBhIHBy b2JsZW0gd2l0aCB0aGF0DQo+PiBwYXJ0aWN1bGFyIGF0dHJpYnV0ZSBub3QgNDU2NiBvciA0NTY2 YmlzKS4NCj4NCj5JIGZvdW5kIG9uZTogYT1tYXhwcmF0ZSBpbiBSRkMzODkwLg0KDQpXZWxsLCBJ IHN0aWxsIGRvbid0IHNlZSBhIHByb2JsZW0gaW4gcmVwbGFjaW5nIHRoZSBjdXJyZW50IHRleHQg d2l0aCB0aGUNCnByb3Bvc2VkIHRleHQuIERvIHlvdT8NCg0KPg0KPglUaGFua3MsDQo+CVBhdWwN Cj4NCj4+IEJyZXR0J3MgcHJvcG9zYWwgZG9lcyBub3QgbWFrZSB0aGUgdGV4dCBhbnkgd29yc2Uu IFNvLCBJIGFtIHBsYW5uaW5nIHRvDQo+PiBpbmNvcnBvcmF0ZSB0aGlzIGNoYW5nZS4NCj4+DQo+ PiBBbnkgb2JqZWN0aW9ucz8NCj4+DQo+PiAtYWNiZWdlbg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVk dT4NCj4+IERhdGU6IE1vbmRheSwgQXVndXN0IDI3LCAyMDEyIDEyOjAzIFBNDQo+PiBUbzogIm1t dXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbTU1VU0lD XSBEcmFmdC1pZXRmLW1tdXNpYy1yZmM0NTY2YmlzLTA1Og0KPj4gc2Vzc2lvbi1sZXZlbCBhdHRy aWJ1dGVzDQo+Pg0KPj4gID5JJ3ZlIGFsd2F5cyB0aG91Z2h0IHRoaXMgc2hvdWxkIGJlIHRoZSB3 YXkgdGhpbmdzIHdvcmssIGZvciBhbGwNCj4+ICA+YXR0cmlidXRlcy4gQnV0IHNvbWV3aGVyZSBJ IGNhbWUgYWNyb3NzIGFuIGF0dHJpYnV0ZSAoc29ycnksIGRvbid0DQo+PiAgPnJlbWVtYmVyIHdo aWNoIG9uZSkgd2hlcmUgdGhlIGF0dHJpYnV0ZSBhdCBzZXNzaW9uIGxldmVsIG1lYW5zDQo+PnNv bWV0aGluZw0KPj4gID5kaWZmZXJlbnQgdGhhbiB0aGUgYXR0cmlidXRlIGF0IG1lZGlhIGxldmVs LCBhbmQgc28gY2FuJ3QgYmUgdHJlYXRlZA0KPj5hcw0KPj4gID5hIGRlZmF1bHQgZm9yIG1lZGlh IGxldmVsLiAoRS5nLiB0aGUgc2Vzc2lvbiBsZXZlbCBpcyBhbiBhZ2dyZWdhdGUNCj4+bGltaXQN Cj4+ICA+Zm9yIHNvbWV0aGluZywgd2hpbGUgdGhlIG1lZGlhIGxldmVsIGlzIGEgbGltaXQgZm9y IGEgc2luZ2xlIG0tbGluZS4pDQo+PiAgPg0KPj4gID5BbSBJIGp1c3QgZHJlYW1pbmcgdGhpcz8g T3IgY2FuIHNvbWVvbmUgaWRlbnRpZnkgc3BlY2lmaWMgYXR0cmlidXRlcw0KPj4gID50aGF0IGJl aGF2ZSB0aGlzIHdheT8NCj4+ICA+DQo+PiAgPklmIHRoZXJlIGFyZSBleGlzdGluZyBhdHRyaWJ1 dGVzIHRoYXQgYmVoYXZlIHRoaXMgd2F5LCB0aGVuIHdlIGNhbid0DQo+PiAgPm1ha2UgYSBibGFu a2V0IHN0YXRlbWVudCBsaWtlIHRoaXMuIFRoZXJlIHdpbGwgbmVlZCB0byBiZSBhbiBlc2NhcGUN Cj4+ICA+aGF0Y2guIEZvciBleGFtcGxlOg0KPj4gID4NCj4+ICA+IlRoZSBjb25uZWN0aW9uICgi Yz0iKSBpbmZvcm1hdGlvbiBpbiB0aGUNCj4+ICA+IHNlc3Npb24tbGV2ZWwgc2VjdGlvbiBhcHBs aWVzIHRvIGFsbCB0aGUgbWVkaWEgb2YgdGhhdCBzZXNzaW9uIHVubGVzcw0KPj4gID4gb3ZlcnJp ZGRlbiBieSBjb25uZWN0aW9uIGluZm9ybWF0aW9uDQo+PiAgPiBpbiB0aGUgbWVkaWEgZGVzY3Jp cHRpb24uIEZvciBpbnN0YW5jZSwgaW4gdGhlIGV4YW1wbGUNCj4+ICA+IGJlbG93LCBUQkQuLi4i DQo+PiAgPg0KPj4gID4iVGhlIGF0dHJpYnV0ZSAoImE9IikgaW5mb3JtYXRpb24gaW4gdGhlDQo+ PiAgPiBzZXNzaW9uLWxldmVsIHNlY3Rpb24gYXBwbGllcyB0byBhbGwgdGhlIG1lZGlhIG9mIHRo YXQgc2Vzc2lvbiB1bmxlc3MNCj4+ICA+IG92ZXJyaWRkZW4gYnkgY29ubmVjdGlvbiBpbmZvcm1h dGlvbiBvciBhbiBhdHRyaWJ1dGUgb2YgdGhlIHNhbWUgbmFtZQ0KPj4gID4gb3IgY2hvaWNlIGlu IHRoZSBtZWRpYSBkZXNjcmlwdGlvbiwgb3IgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhhdA0KPj4g ID4gYXR0cmlidXRlIGNhbGxzIGZvciBhIGRpZmZlcmVudCB0cmVhdG1lbnQuDQo+PiAgPiBGb3Ig aW5zdGFuY2UsIGluIHRoZSBleGFtcGxlDQo+PiAgPiBiZWxvdywgZWFjaCBtZWRpYSBiZWhhdmVz IGFzIGlmIGl0IHdlcmUgZ2l2ZW4gYSAicmVjdm9ubHkiIGF0dHJpYnV0ZS4NCj4+ICA+IElmIHRo ZSBleGFtcGxlIGhhZCBhZGRpdGlvbmFsbHkgY29udGFpbmVkIGEgInNlbmRyZWN2IiBtZWRpYS1s ZXZlbA0KPj4gID4gYXR0cmlidXRlIGZvciBhdWRpbywgb25seSB0aGUgdmlkZW8gbWVkaWEgd291 bGQgYmVoYXZlIGFzIGlmIGl0IHdlcmUNCj4+ICA+IGdpdmVuIGEgInJlY3Zvbmx5IiBhdHRyaWJ1 dGUuIg0KPj4gID4NCj4+ICA+RXZlbiB0aGlzIGNvdWxkIGhhdmUgc29tZSBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IGNvbnNlcXVlbmNlcy4gSSB0aGluaw0KPj4gID50aGVyZSBhcmUgc29tZSBhdHRy aWJ1dGVzIHRoYXQgYXJlIG9ubHkgZGVmaW5lZCBmb3IgbWVkaWEgbGV2ZWwuIFRoaXMNCj4+ICA+ cmV2aXNpb24gd291bGQgbWVhbiB0aGF0IGEgc2Vzc2lvbiBsZXZlbCB2YWx1ZSBjb3VsZCBvdmVy cmlkZSBhDQo+PmRlZmF1bHQNCj4+ICA+Zm9yIG1lZGlhIGxldmVsLiBJbXBsZW1lbnRhdGlvbnMg dGhhdCBhcmVuJ3QgcHJlcGFyZWQgZm9yIHRoYXQgbWlnaHQNCj4+ICA+YnJlYWsuDQo+PiAgPg0K Pj4gID4gVGhhbmtzLA0KPj4gID4gUGF1bA0KPj4gID4NCj4+ICA+T24gOC8yNy8xMiAxMjowNCBQ TSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPj4gID4+IEJyZXR0IHN1Z2dlc3RlZCB0 aGUgZm9sbG93aW5nIGNoYW5nZSBpbiB0aGUgU0RQIGRyYWZ0LiBBbnkNCj4+b2JqZWN0aW9ucz8N Cj4+ICA+Pg0KPj4gID4+IC1hY2JlZ2VuDQo+PiAgPj4NCj4+ICA+PiBDdXJyZW50IHRleHQ6DQo+ PiAgPj4NCj4+ICA+PiAiVGhlIGNvbm5lY3Rpb24gKCJjPSIpIGFuZCBhdHRyaWJ1dGUgKCJhPSIp IGluZm9ybWF0aW9uIGluIHRoZQ0KPj4gID4+IHNlc3Npb24tbGV2ZWwgc2VjdGlvbiBhcHBsaWVz IHRvIGFsbCB0aGUgbWVkaWEgb2YgdGhhdCBzZXNzaW9uDQo+PnVubGVzcw0KPj4gID4+IG92ZXJy aWRkZW4gYnkgY29ubmVjdGlvbiBpbmZvcm1hdGlvbiBvciBhbiBhdHRyaWJ1dGUgb2YgdGhlIHNh bWUNCj4+bmFtZQ0KPj4gID4+IGluIHRoZSBtZWRpYSBkZXNjcmlwdGlvbi4gRm9yIGluc3RhbmNl LCBpbiB0aGUgZXhhbXBsZSBiZWxvdywgZWFjaA0KPj4gID4+IG1lZGlhIGJlaGF2ZXMgYXMgaWYg aXQgd2VyZSBnaXZlbiBhICJyZWN2b25seSIgYXR0cmlidXRlLiINCj4+ICA+Pg0KPj4gID4+IFBy b3Bvc2VkIHRleHQ6DQo+PiAgPj4NCj4+ICA+PiAiVGhlIGNvbm5lY3Rpb24gKCJjPSIpIGFuZCBh dHRyaWJ1dGUgKCJhPSIpIGluZm9ybWF0aW9uIGluIHRoZQ0KPj4gID4+IHNlc3Npb24tbGV2ZWwg c2VjdGlvbiBhcHBsaWVzIHRvIGFsbCB0aGUgbWVkaWEgb2YgdGhhdCBzZXNzaW9uDQo+PnVubGVz cw0KPj4gID4+IG92ZXJyaWRkZW4gYnkgY29ubmVjdGlvbiBpbmZvcm1hdGlvbiBvciBhbiBhdHRy aWJ1dGUgb2YgdGhlIHNhbWUNCj4+bmFtZQ0KPj4gID4+IG9yIGNob2ljZSBpbiB0aGUgbWVkaWEg ZGVzY3JpcHRpb24uIEZvciBpbnN0YW5jZSwgaW4gdGhlIGV4YW1wbGUNCj4+ICA+PiBiZWxvdywg ZWFjaCBtZWRpYSBiZWhhdmVzIGFzIGlmIGl0IHdlcmUgZ2l2ZW4gYSAicmVjdm9ubHkiDQo+PmF0 dHJpYnV0ZS4NCj4+ICA+PiBJZiB0aGUgZXhhbXBsZSBoYWQgYWRkaXRpb25hbGx5IGNvbnRhaW5l ZCBhICJzZW5kcmVjdiIgbWVkaWEtbGV2ZWwNCj4+ICA+PiBhdHRyaWJ1dGUgZm9yIGF1ZGlvLCBv bmx5IHRoZSB2aWRlbyBtZWRpYSB3b3VsZCBiZWhhdmUgYXMgaWYgaXQgd2VyZQ0KPj4gID4+IGdp dmVuIGEgInJlY3Zvbmx5IiBhdHRyaWJ1dGUuIg0KPj4gID4+DQo+PiAgPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiAgPj4+IEZyb206IEJyZXR0IFRhdGUgW21haWx0bzpicmV0dEBi cm9hZHNvZnQuY29tXQ0KPj4gID4+PiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwOCwgMjAxMiA3 OjU0IEFNDQo+PiAgPj4+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik7IG1tdXNpY0BpZXRmLm9y Zw0KPj4gID4+PiBTdWJqZWN0OiBSRTogRHJhZnQtaWV0Zi1tbXVzaWMtcmZjNDU2NmJpcy0wNTog c2Vzc2lvbi1sZXZlbA0KPj5hdHRyaWJ1dGVzDQo+PiAgPj4+DQo+PiAgPj4+Pj4gRHJhZnQtaWV0 Zi1tbXVzaWMtcmZjNDU2NmJpcy0wNSBzZWN0aW9uIDUgaW5kaWNhdGVzIHRoZQ0KPj4gID4+Pj4+ IGZvbGxvd2luZy4NCj4+ICA+Pj4+Pg0KPj4gID4+Pj4+ICJJbiBnZW5lcmFsLCBzZXNzaW9uLWxl dmVsIHZhbHVlcyBhcmUgdGhlIGRlZmF1bHQgZm9yIGFsbA0KPj4gID4+Pj4+IG1lZGlhIHVubGVz cyBvdmVycmlkZGVuIGJ5IGFuIGVxdWl2YWxlbnQgbWVkaWEtbGV2ZWwgdmFsdWUuIg0KPj4gID4+ Pj4+DQo+PiAgPj4+Pj4gIlRoZSBjb25uZWN0aW9uICgiYz0iKSBhbmQgYXR0cmlidXRlICgiYT0i KSBpbmZvcm1hdGlvbg0KPj4gID4+Pj4+IGluIHRoZSBzZXNzaW9uLWxldmVsIHNlY3Rpb24gYXBw bGllcyB0byBhbGwgdGhlIG1lZGlhIG9mDQo+PiAgPj4+Pj4gdGhhdCBzZXNzaW9uIHVubGVzcyBv dmVycmlkZGVuIGJ5IGNvbm5lY3Rpb24gaW5mb3JtYXRpb24NCj4+ICA+Pj4+PiBvciBhbiBhdHRy aWJ1dGUgb2YgdGhlIHNhbWUgbmFtZSBpbiB0aGUgbWVkaWEgZGVzY3JpcHRpb24uDQo+PiAgPj4+ Pj4gRm9yIGluc3RhbmNlLCBpbiB0aGUgZXhhbXBsZSBiZWxvdywgZWFjaCBtZWRpYSBiZWhhdmVz DQo+PiAgPj4+Pj4gYXMgaWYgaXQgd2VyZSBnaXZlbiBhICJyZWN2b25seSIgYXR0cmlidXRlLiIN Cj4+ICA+Pj4+Pg0KPj4gID4+Pj4+IElmIHRoZSBhdHRyaWJ1dGVzIGFyZSByZWxhdGVkIGJ1dCB3 aXRoIGRpZmZlcmVudCBuYW1lcw0KPj4gID4+Pj4+IChzdWNoIGFzICJpbmFjdGl2ZSIgYW5kICJz ZW5kcmVjdiIpLCBkb2VzIHRoZSBhdHRyaWJ1dGUNCj4+ICA+Pj4+PiBhdCB0aGUgbWVkaWEtbGV2 ZWwgaGF2ZSBwcmVjZWRlbmNlIG92ZXIgdGhlIHZhbHVlIGF0IHRoZQ0KPj4gID4+Pj4+IHNlc3Np b24tbGV2ZWw/IElmIHNvLCBJIHJlY29tbWVuZCB0aGF0IHRoZSBkcmFmdCBiZQ0KPj4gID4+Pj4+ IHVwZGF0ZWQgdG8gY2xhcmlmeSB0aGUgdG9waWMuDQo+PiAgPj4+Pg0KPj4gID4+Pj4gSSBiZWxp ZXZlIHNvLiBhdCBsZWFzdCB0aGF0IGlzIG15IHVuZGVyc3RhbmRpbmcgZnJvbSB0aGUNCj4+ICA+ Pj4+IHRleHQuIERvZXMgaXQgcmVhbGx5IG5lZWQgY2xhcmlmaWNhdGlvbj8gVGhvdWdodHM/DQo+ PiAgPj4+DQo+PiAgPj4+IEkgdGhpbmsgdGhhdCBpdCBzaG91bGQgYmUgY2xhcmlmaWVkIGJlY2F1 c2UgaXQgaXMgdW5jbGVhciBpZiAiYW4NCj4+ICA+Pj5hdHRyaWJ1dGUgb2YgdGhlIHNhbWUgbmFt ZSIgaW5kaWNhdGVzIHRoZSB0eXBpY2FsIHNpdHVhdGlvbiBvciBvbmx5DQo+PiAgPj4+IHNpdHVh dGlvbiBjb25jZXJuaW5nIGFwcGxpY2F0aW9uIG9mICJ1bmxlc3Mgb3ZlcnJpZGRlbiBieSBhbg0K Pj4gID4+PmVxdWl2YWxlbnQgbWVkaWEtbGV2ZWwgdmFsdWUiLiBGb3IgaW5zdGFuY2UgaWYgSSBz ZW50ICJhPWluYWN0aXZlIg0KPj4gID4+PiBhdCBzZXNzaW9uLWxldmVsIGFuZCAiYT1zZW5kcmVj diIgYXQgbWVkaWEtbGV2ZWwsIEknZCBiZSBjb25jZXJuZWQNCj4+ICA+Pj50aGF0IHRoZSByZWNl aXZlciBtYXkgaW50ZXJwcmV0IHRoZSBTRFAgYXMgYmVpbmcNCj4+ICA+Pj4gYWJub3JtYWwgKHN1 Y2ggYXMgaW5jbHVkaW5nIGJvdGggdmFsdWVzIGF0IG1lZGlhLWxldmVsKSBpbnN0ZWFkIG9mDQo+ PiAgPj4+YWxsb3dpbmcgImE9c2VuZHJlY3YiIHRvIG92ZXJyaWRlICJhPWluYWN0aXZlIi4NCj4+ ICA+Pj4NCj4+ICA+Pj4gSW4gY2FzZSBpdCBtYXR0ZXJzIGZyb20gYW4gZXh0ZW5kaWJpbGl0eSBw ZXJzcGVjdGl2ZSwgcmVxdWlyaW5nIHRoZQ0KPj4gID4+PnNhbWUgbmFtZSBtaWdodCBtYWtlIGl0 IGVhc2llciB0byByZWNvZ25pemUgdGhlIG92ZXJyaWRlLg0KPj4gID4+PiBIb3dldmVyIHNpbmNl IHNlY3Rpb24gNiBhbHJlYWR5IGludHJvZHVjZXMgY29tcGxpY2F0aW9ucyB3aXRoDQo+PiAgPj4+ ZGVmYXVsdGluZyB0byAic2VuZHJlY3YiIGlmIGEgbmV3IG9wdGlvbiBpcyBkZWZpbmVkL3VzZWQg YW5kDQo+PiAgPj4+IHVua25vd24sIGFsbG93aW5nIHRoZSBvdmVycmlkZSBldmVuIHdoZW4gdGhl IG5hbWVzIGFyZSBub3QgdGhlIHNhbWUNCj4+ICA+Pj5kb2Vzbid0IG1ha2UgdGhpbmdzIHRvbyBt dWNoIHdvcnNlOyBpdCBhY3R1YWxseQ0KPj4gID4+PiBhbGxvd3MgY29tbXVuaWNhdGlvbiBvZiBh IGJhY2t1cCBhdHRyaWJ1dGUgKHN1Y2ggYXMgImE9aW5hY3RpdmUiKQ0KPj5pZg0KPj4gID4+PnRo ZXkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcHJlZmVycmVkIG5ldyBhdHRyaWJ1dGUgKHN1Y2gNCj4+ ICA+Pj4gYXMgImE9Zm9vIikuDQo+PiAgPj4+DQo+PiAgPj4+ICJJZiBub25lIG9mIHRoZSBhdHRy aWJ1dGVzICJzZW5kb25seSIsICJyZWN2b25seSIsICJpbmFjdGl2ZSIsDQo+PiAgPj4+IGFuZCAi c2VuZHJlY3YiIGlzIHByZXNlbnQsICJzZW5kcmVjdiIgU0hPVUxEIGJlIGFzc3VtZWQgYXMgdGhl DQo+PiAgPj4+IGRlZmF1bHQgZm9yIHNlc3Npb25zIHRoYXQgYXJlIG5vdCBvZiB0aGUgY29uZmVy ZW5jZSB0eXBlDQo+PiAgPj4+ICJicm9hZGNhc3QiIG9yICJIMzMyIiAoc2VlIGJlbG93KS4iDQo+ PiAgPj4+DQo+PiAgPj4+IFRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLA0KPj4gID4+PiBCcmV0dA0K Pj4gID4+DQo+PiAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ICA+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+PiAgPj4gbW11c2ljQGlldGYub3Jn DQo+PiAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4+ ICA+Pg0KPj4gID4NCj4+ICA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+ICA+bW11c2ljIG1haWxpbmcgbGlzdA0KPj4gID5tbXVzaWNAaWV0Zi5vcmcN Cj4+ICA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbW11 c2ljIG1haWxpbmcgbGlzdA0KPj4gbW11c2ljQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+bW11c2ljIG1haWxpbmcgbGlzdA0KPm1tdXNpY0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoN Cg== From pkyzivat@alum.mit.edu Mon Dec 31 14:06:01 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 A5FDE21F8781 for ; Mon, 31 Dec 2012 14:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.088 X-Spam-Level: * X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[AWL=-1.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqRog0xSNTOg for ; Mon, 31 Dec 2012 14:06:00 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A721F8738 for ; Mon, 31 Dec 2012 14:06:00 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta09.westchester.pa.mail.comcast.net with comcast id iK9L1k0031GhbT859N5z3b; Mon, 31 Dec 2012 22:05:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id iN5z1k0093ZTu2S3TN5zz5; Mon, 31 Dec 2012 22:05:59 +0000 Message-ID: <50E20C46.8000102@alum.mit.edu> Date: Mon, 31 Dec 2012 17:05:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <1.589bc0ea592cb7a6f399@cisco.com> In-Reply-To: <1.589bc0ea592cb7a6f399@cisco.com> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1356991559; bh=+OoUXWj6UULMea41oqLtn0hDgqDKJb1up105YVfPMtY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fdBwBWJmurenaKjfM0389eJmh0Tboyc1/E2lcoLRZHAnIOi7sn5+GRGN6tmnoXCKv XkWz+TFAAhqsof27e8j0lxLoshK9b7dtalSGMOEnDLVwBvC1tCW/BQHk0fW4Y1LF0s /zL/i2td6Pg6AGqrOZDLcefkpRwIFT8Hi26120BeCEaYmQ8q/Uf1p+6M4hr0P9bV8V wbiJ7mUg6YSI4u20238m1iiTX5bAYJGBtxGF7J754z9NIxaxsrpw7kDllc0vTBpusW nl16VR0rJvRt2xq3wiVGle0qeRCgRDw7s+1cPJIrhWBVqIcpN5+cijXCVqrDY7YRvh SltYe0xKonOFQ== Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes 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, 31 Dec 2012 22:06:01 -0000 Inline. On 12/29/12 7:45 PM, Ali C. Begen (abegen) wrote: > > > -----Original Message----- > From: Paul Kyzivat > Date: Saturday, December 29, 2012 7:36 PM > To: "mmusic@ietf.org" > Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: > session-level attributes > > >On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote: > >> I donİöt remember us reaching a consensus regarding the text proposed by > >> Brett. One thing certain is that we don't wanna break anything that > >> complies with 4566 but we should also make the text as clear as > >>possible. > >> > >> I am OK with Brett's suggestion as I don't recall an attribute like > what > >> Paul might have seen. But, even if such an attribute exists, the > current > >> text would be incorrect, too (This would indicate a problem with that > >> particular attribute not 4566 or 4566bis). > > > >I found one: a=maxprate in RFC3890. > Well, I still don't see a problem in replacing the current text with the > proposed text. Do you? Yes - I do see a problem. I wish I didn't. IMO it was intended to work this way. (The text we are proposing to revise was present in RFC2327.) But it is a little bit confusing when you start to talk about attributes that are session-only, or are explicitly defined for both session and media level, as maxprate is. ISTM that one way to move forward while retaining backward compatibility is to make clear that this only applies to attributes defined as valid for both session and media level, and and that has no special syntax or semantics defined for session level. But even this is a bit of a risk for backward compatibility, because some existing implementations may not work this way. I'm ambivalent about whether to take the hit on this. We could argue that such implementations have always been broken. I'll also note that of the attributes defined in this draft, the only ones defined as both media and session level are sendrecv/sendonly/recvonly/inactive, sdplang, and lang. So these are the only ones eligible to be used in an example here. And all of these have special issues that make them bad examples: The sendrecv, sendonly, ... attributes override each other: a sendonly at media level overrides sendrecv at session level. This requires special per-attribute description of the interaction between session and media level, so they aren't a good example for the general override principle. (The descriptions of these in section 6 should be updated to discuss this.) And a=lang and a=sdplang may appear multiple times to specify multiple languages. E.g. suppose I have: a=lang:en a=lang:fr m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=lang:de Presumably this means the audio has both English and French. But oes the "a=lang:de" *override* those? Or does it add a third language for the video stream? ISTM that the specifications of these in section 6 need to be beefed up to make this clear. And once they are, they probably preempt the default rule. And once that is done, we have no attributes defined at both media and session level that are good to use in an example of the general principle of session level providing a default for media level. (Certainly there are others, but they aren't defined in this document.) Now we *could* say this session-level default rule also applies to attributes that are defined as media-level-only attributes. But then I think we would incur a significant backward compatibility issue. (E.g. if I use a=rtpmap at session level.) I had hoped to provide some alternative wording here, but now I don't think I'm ready to do that. I think this needs more discussion, and we need to work out improvements to the description of a=sendrecv, ... a=lang, ... I am willing to take a crack at proposing new language for them, but lets have this discussion play out first. Thanks, Paul > > Thanks, > > Paul > > > >> Brett's proposal does not make the text any worse. So, I am planning to > >> incorporate this change. > >> > >> Any objections? > >> > >> -acbegen > >> > >> -----Original Message----- > >> From: Paul Kyzivat > >> Date: Monday, August 27, 2012 12:03 PM > >> To: "mmusic@ietf.org" > >> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: > >> session-level attributes > >> > >> >I've always thought this should be the way things work, for all > >> >attributes. But somewhere I came across an attribute (sorry, don't > >> >remember which one) where the attribute at session level means > >>something > >> >different than the attribute at media level, and so can't be treated > >>as > >> >a default for media level. (E.g. the session level is an aggregate > >>limit > >> >for something, while the media level is a limit for a single m-line.) > >> > > >> >Am I just dreaming this? Or can someone identify specific attributes > >> >that behave this way? > >> > > >> >If there are existing attributes that behave this way, then we can't > >> >make a blanket statement like this. There will need to be an escape > >> >hatch. For example: > >> > > >> >"The connection ("c=") information in the > >> > session-level section applies to all the media of that session unless > >> > overridden by connection information > >> > in the media description. For instance, in the example > >> > below, TBD..." > >> > > >> >"The attribute ("a=") information in the > >> > session-level section applies to all the media of that session unless > >> > overridden by connection information or an attribute of the same name > >> > or choice in the media description, or the specification of that > >> > attribute calls for a different treatment. > >> > For instance, in the example > >> > below, each media behaves as if it were given a "recvonly" attribute. > >> > If the example had additionally contained a "sendrecv" media-level > >> > attribute for audio, only the video media would behave as if it were > >> > given a "recvonly" attribute." > >> > > >> >Even this could have some backward compatibility consequences I think > >> >there are some attributes that are only defined for media level. This > >> >revision would mean that a session level value could override a > >>default > >> >for media level. Implementations that aren't prepared for that might > >> >break. > >> > > >> > Thanks, > >> > Paul > >> > > >> >On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote: > >> >> Brett suggested the following change in the SDP draft. Any > >>objections? > >> >> > >> >> -acbegen > >> >> > >> >> Current text: > >> >> > >> >> "The connection ("c=") and attribute ("a=") information in the > >> >> session-level section applies to all the media of that session > >>unless > >> >> overridden by connection information or an attribute of the same > >>name > >> >> in the media description. For instance, in the example below, each > >> >> media behaves as if it were given a "recvonly" attribute." > >> >> > >> >> Proposed text: > >> >> > >> >> "The connection ("c=") and attribute ("a=") information in the > >> >> session-level section applies to all the media of that session > >>unless > >> >> overridden by connection information or an attribute of the same > >>name > >> >> or choice in the media description. For instance, in the example > >> >> below, each media behaves as if it were given a "recvonly" > >>attribute. > >> >> If the example had additionally contained a "sendrecv" media-level > >> >> attribute for audio, only the video media would behave as if it were > >> >> given a "recvonly" attribute." > >> >> > >> >>> -----Original Message----- > >> >>> From: Brett Tate [mailto:brett@broadsoft.com] > >> >>> Sent: Wednesday, August 08, 2012 7:54 AM > >> >>> To: Ali C. Begen (abegen); mmusic@ietf.org > >> >>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level > >>attributes > >> >>> > >> >>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the > >> >>>>> following. > >> >>>>> > >> >>>>> "In general, session-level values are the default for all > >> >>>>> media unless overridden by an equivalent media-level value." > >> >>>>> > >> >>>>> "The connection ("c=") and attribute ("a=") information > >> >>>>> in the session-level section applies to all the media of > >> >>>>> that session unless overridden by connection information > >> >>>>> or an attribute of the same name in the media description. > >> >>>>> For instance, in the example below, each media behaves > >> >>>>> as if it were given a "recvonly" attribute." > >> >>>>> > >> >>>>> If the attributes are related but with different names > >> >>>>> (such as "inactive" and "sendrecv"), does the attribute > >> >>>>> at the media-level have precedence over the value at the > >> >>>>> session-level? If so, I recommend that the draft be > >> >>>>> updated to clarify the topic. > >> >>>> > >> >>>> I believe so. at least that is my understanding from the > >> >>>> text. Does it really need clarification? Thoughts? > >> >>> > >> >>> I think that it should be clarified because it is unclear if "an > >> >>>attribute of the same name" indicates the typical situation or only > >> >>> situation concerning application of "unless overridden by an > >> >>>equivalent media-level value". For instance if I sent "a=inactive" > >> >>> at session-level and "a=sendrecv" at media-level, I'd be concerned > >> >>>that the receiver may interpret the SDP as being > >> >>> abnormal (such as including both values at media-level) instead of > >> >>>allowing "a=sendrecv" to override "a=inactive". > >> >>> > >> >>> In case it matters from an extendibility perspective, requiring the > >> >>>same name might make it easier to recognize the override. > >> >>> However since section 6 already introduces complications with > >> >>>defaulting to "sendrecv" if a new option is defined/used and > >> >>> unknown, allowing the override even when the names are not the same > >> >>>doesn't make things too much worse; it actually > >> >>> allows communication of a backup attribute (such as "a=inactive") > >>if > >> >>>they don't understand the preferred new attribute (such > >> >>> as "a=foo"). > >> >>> > >> >>> "If none of the attributes "sendonly", "recvonly", "inactive", > >> >>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the > >> >>> default for sessions that are not of the conference type > >> >>> "broadcast" or "H332" (see below)." > >> >>> > >> >>> Thanks for the response, > >> >>> Brett > >> >> > >> >> _______________________________________________ > >> >> mmusic mailing list > >> >> mmusic@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mmusic > >> >> > >> > > >> >_______________________________________________ > >> >mmusic mailing list > >> >mmusic@ietf.org > >> >https://www.ietf.org/mailman/listinfo/mmusic > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic