From bo.burman@ericsson.com Mon Dec 2 02:52:18 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415FC1AE2DC for ; Mon, 2 Dec 2013 02:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whzSabhfTGKh for ; Mon, 2 Dec 2013 02:52:14 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DB40B1AE140 for ; Mon, 2 Dec 2013 02:52:13 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-0f-529c665aa2c9 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C0.92.27941.A566C925; Mon, 2 Dec 2013 11:52:11 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.236]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 11:52:10 +0100 From: Bo Burman To: Bernard Aboba , Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Thread-Index: AQHO7HThAQ8rSNEoVE2qFCbMYyib85o9ZdUAgAC1wYCAApmEgA== Date: Mon, 2 Dec 2013 10:52:09 +0000 Message-ID: References: , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E061AB2ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+JvrW502pwgg43NbBb7l1xmtpi6/DGL A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4MrobMgpOLySsWLTtK1MDYwLJjB2MXJySAiY SPTtn88EYYtJXLi3ng3EFhI4wihxagGQzQVkL2aUaHl3FyzBJqAhMX/HXUaQhIhAB6PE2jnv 2LsYOTiEBTwkpp53B6kREfCUeLmzhRXCdpL4MOM8mM0ioCKx8k0DC0g5r4CvxI+HXhDzVzJK 7Or4BnYQp4C1ROeun2A2o4CsxP3v91hAbGYBcYlbT2AOFZBYsuc8M4QtKvHy8T9WCFtRov1p AyNEfb7E59XNYDavgKDEyZlPWCYwisxCMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCY CVl8ASP7KkaO4tTipNx0I4NNjMD4Objlt8UOxst/bQ4xSnOwKInzfnzrHCQkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qB0eOthW1f1rQU+VOmCUtz7B913zhcHWnbEG38p8DvmLz639Tny2Ku +TyK7PWdsGPRVJEXO3OmfSypzWWcptU6v/O/jVt1y2aF00dmMl3R9dlVvFNaer+QVcHmJrXU TQe3l/QmhGY/3D7x+4SS98smS7reX5khs+P+voKiqqB9c703LS/av3tjuBJLcUaioRZzUXEi ADt3xChtAgAA Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:52:18 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E061AB2ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Should a simulcast-capable endpoint be restricted to be a simulcast-sender-= only or a simulcast-receiver-only, or do we envision endpoints that are cap= able of both sending and receiving simulcast? One example would be if simul= cast streams are to be forwarded between different SFU (using Bernard's ter= minology below). If so and assuming that we define a new 5888-type simulcast grouping, do we= need separate groupings for send direction simulcast and receive direction= simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-g= rouped media blocks fully sufficient? Also, I think the way to use this approach for simulcast in combination wit= h multiple separate media sources (like multiple cameras) or media sinks (l= ike multiple displays) would be pretty straightforward; just add one simulc= ast grouping per media source/sink. From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 30 november 2013 20:31 To: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Christer asked: "In your example, how does the answerer know that the offered m- lines are = for simulcast? As far as O/A is concerned, it could just be a number of com= pletely separate (different content etc) uni-directional streams." [BA] The most obvious way would be grouping. Looking at RFC 5888/5583, it = doesn't appear that either FID or DDP grouping would apply to simulcast. = So perhaps a new group type would be needed. Bernard Aboba >= wrote: At IETF 88, a number of participants (including myself) expressed the view= that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below, I= will attempt to explain how simulcast might be negotiated in a simplified = Offer/Answer exchange based on the principles of Unified Plan. Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU), while receiving one among a se= t of potential streams from the SFU, with the SFU being able to switch betw= een the streams that it is sending to the endpoint without signaling. RFC = 3264 describes how to handle each of these situations. With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following: If the offerer wishes to only send media on a stream to its peer, it MUST m= ark the stream as sendonly with the "a=3Dsendonly" attribute. We refer to= a stream as being marked with a certain direction if a direction attribute= was present as either a media stream attribute or a session attribute. For= sendonly RTP streams, the payload type numbers indicate the value of the p= ayload type field in RTP packet the offerer is planning to send for that co= dec... In all cases, the formats in the "m=3D" line MUST be listed in orde= r of preference, with the first format listed being preferred. In this cas= e, preferred means that the recipient of the offer SHOULD use the format wi= th the highest preference that is acceptable to it. If multiple media strea= ms of different types are present, it means that the offerer wishes to use = those streams at the same time. A typical case is an audio and a video str= eam as part of a videoconference. If multiple media streams of the same type are present in an offer, it mea= ns that the offerer wishes to send (and/or receive) multiple streams of tha= t type at the same time... Each stream MAY use different encodings. With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says: If the offerer wishes to only receive media from its peer, it MUST mark the= stream as recvonly... If multiple formats are listed, it means that the of= ferer is capable of making use of any of those formats during the session. = In other words, the answerer MAY change formats in the middle of the sessi= on, making use of any of the formats listed, without sending a new offer. = For a sendonly stream, the offer SHOULD indicate those formats the offerer = is willing to send for this stream. For a recvonly stream, the offer SHOU= LD indicate those formats the offerer is willing to receive for this stream= .... For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to receive fo= r that codec. Based on the above: 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line. = The offer would also include a single m=3Dline (with a=3Drecvonly) describ= ing the streams that the endpoint is prepared to receive, each with their o= wn payload type. 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition, the answer would include a single m=3Dline (with a= =3Dsendonly) indicating the streams from among those proposed by the endpoi= nt that the SFU is prepared to send. The SFU can then switch between those= streams without having to signal the endpoint. Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send, an Answerer can indicate how man= y streams it is prepared to receive (might only be one if simulcast isn't s= upported). Similarly, an Answerer can select those simulcast streams it i= s prepared to send (might only be one if simulcast isn't supported). Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640,y=3D360] m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320,y=3D180] m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320,y=3D180] Example Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640,y=3D360] m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320,y=3D180] m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D320,y=3D180] --_000_BBE9739C2C302046BD34B42713A1E2A22E061AB2ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Should a simulcast-capabl= e endpoint be restricted to be a simulcast-sender-only or a simulcast-recei= ver-only, or do we envision endpoints that are capable of both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard’s term= inology below).

 <= /p>

If so and assuming that w= e define a new 5888-type simulcast grouping, do we need separate groupings = for send direction simulcast and receive direction simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?

 <= /p>

Also, I think the way to = use this approach for simulcast in combination with multiple separate media= sources (like multiple cameras) or media sinks (like multiple displays) would be pretty straightforward; just add one simulcast grouping= per media source/sink.

 <= /p>

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 30 november 2013 20:31
To: Christer Holmberg; mmusic@ietf.org
Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Christer asked:
"In your example, how does =
the answerer know that the offered m- lines are for simulcast? As far as O/=
A is concerned, it could just be a number of completely separate (different=
 content etc) uni-directional streams."
[BA] The most obvious way would =
be grouping.  Looking at RFC 5888/5583, it doesn't appear that either =
FID or DDP grouping would apply to simulcast.   So perhaps a new =
group type would be needed. 
 
 
Bernard Aboba <=
bernard_aboba@hotmail.com> wrote:
 

At IETF 88, a number of  participants (including my= self) expressed the view that draft-westerlund-avtcore-rtp-simulcast was to= o complicated.  Below, I will attempt to explain how simulcast might be negotiated in a simplified Offer/Answer exchange based = on the principles of Unified Plan.
 
Typically in simulcast we have an endpoint sending multiple streams in= parallel to the Selective Forwarding Unit (SFU), while receiving one = among a set of potential streams from the SFU, with the SFU being able to s= witch between the streams that it is sending to the endpoint without signaling.  RFC 3264 describes how to ha= ndle each of these situations.
 
With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following:
 

If the offerer wishes to only send media on a stream to = its peer, it MUST mark the stream as sendonly with the "a=3Dsendo= nly" attribute.  We  refer to a stream as being marked with = a certain direction if a direction attribute was present as either a media stre= am attribute or a session attribute. For sendonly RTP streams, the pay= load type numbers indicate the value of the payload type field in RTP packe= t the offerer is planning to send for that codec...  In all cases, the formats in the "m=3D" line MUST= be listed in order of preference, with the first format listed being = preferred.  In this case, preferred means that the recipient of t= he offer SHOULD use the format with the highest preference that is acceptable to it. If multiple media streams of different types are pres= ent, it means that the offerer wishes to use those streams at the same time= .  A typical case is an audio and a video stream as part of a vid= eoconference.
 
If multiple media streams of the same type are present in an offer,  i= t means that the offerer wishes to send (and/or receive) multiple streams o= f that type at the same time...  Each stream MAY use different en= codings.

 
With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says:
 

If the offerer wishes to only receive media from its pee= r, it MUST mark the stream as recvonly... If multiple formats are listed, i= t means that the offerer is capable of making use of any of those formats during the session.  In other words, the answer= er MAY change formats in the middle of the session, making use of any of th= e formats listed, without sending a new offer.  For a sendonly st= ream, the offer SHOULD indicate those formats the offerer is willing to send for this stream.  For a recvonly stream,  the= offer SHOULD indicate those formats the offerer is willing to receive for = this stream....
  
For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to  recei= ve for that codec. 

 
Based on the above:
 
1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line.&= nbsp; The offer would also include a single m=3Dline (with a=3Drecvonly) de= scribing the streams that the endpoint is prepared to receive, each with their own payload type.
 
2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line).  In addition, the answer would include a single m=3Dline (w= ith a=3Dsendonly) indicating the streams from among those proposed by the endpoint that the SFU is prepared to send.&nbs= p; The SFU can then switch between those streams without having to signal t= he endpoint.
 
Since it is possible for the Answerer to accept/reject each of the pro= posed streams the Offerer is proposing to send, an Answerer can indica= te how many streams it is prepared to receive (might only be one if simulca= st isn't supported).   Similarly, an Answerer can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).
 
Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio):
 
   v=3D0
   o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
   s=3DSimulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.156
   b=3DAS:665
   m=3Dvideo 49300 RTP/AVP 97
   a=3Dsendonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 send [x=3D640,y=3D360]
   m=3Dvideo 49302 RTP/AVP 98
   a=3Dsendonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 send [x=3D320,y=3D180]
   m=3Dvideo 49304 RTP/AVP 100 99
   a=3Drecvonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 recv [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:99 recv [x=3D320,y=3D180]
 
 
Example Answer:
 
   v=3D0
   o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
   s=3DAnswer to Simulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.43
   b=3DAS:665
   m=3Dvideo 48000 RTP/AVP 97
   a=3Drecvonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 recv [x=3D640,y=3D360]
   m=3Dvideo 48002 RTP/AVP 98
   a=3Drecvonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 recv [x=3D320,y=3D180]
   m=3Dvideo 48004 RTP/AVP 100 99
   a=3Dsendonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D320,y=3D180]
 

--_000_BBE9739C2C302046BD34B42713A1E2A22E061AB2ESESSMB105erics_-- From christer.holmberg@ericsson.com Mon Dec 2 03:13:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED011AE35B for ; Mon, 2 Dec 2013 03:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcCVlZ_DCJy8 for ; Mon, 2 Dec 2013 03:13:04 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C817E1AE343 for ; Mon, 2 Dec 2013 03:13:03 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-21-529c6b3c447b Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 47.F5.27941.C3B6C925; Mon, 2 Dec 2013 12:13:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 12:13:00 +0100 From: Christer Holmberg To: Bo Burman , Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Thread-Index: AQHO7HThG+X2tMt6m0yojy1/V4PWfZo9dplHgACk/YCAApPVgIAAFcSQ Date: Mon, 2 Dec 2013 11:12:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se> References: , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5659AAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvra5t9pwggyt32Sz2L7nMbDF1+WMW ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJXRv3YTe8G1U4wVPbsvsDUwrlzH2MXIySEh YCLxeFc3K4QtJnHh3nq2LkYuDiGBI4wSzY82MEM4ixgl9t+dxd7FyMHBJmAh0f1PG6RBRKBC 4sf82YwgYWEBD4mp590hwp4SL3e2sELYbhKLnqxhASlhEVCROL6SCSTMK+ArcfvLXSaI6W8Z JSYc7WMBSXAK+ElMnnaFHcRmBLrn+6k1YA3MAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/+g7leU uDp9ORPILmaBfInuW0IQuwQlTs58wjKBUWQWkkmzEKpmIamCKNGRWLD7ExuErS2xbOFrZhj7 zIHHTMjiCxjZVzFyFKcWJ+WmGxlsYgTGzsEtvy12MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjAsOf7MruHTu5XVb1s0/NohPE3sgnX5FT7UrxMyH8Y35DPZ6 1itaD6R+nG9mLqvS69AunP6DZ0VmsrXZb70ug2OX83ZETd3KddLx/7uaWzuCXXZWOu+bu2e/ c8OJnZbZnb9M1+7nKAgxTbrmaahZ4FznebzIOsV4T7tLUn2DpoLhI70txa6OSizFGYmGWsxF xYkAEvzLTGsCAAA= Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:13:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5659AAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If the answerer does NOT support simulcast, it will see an Offer with multi= ple uni-directional streams. The behavior is difficult to predict. So, even with a mechanism based on grouping, the question is still: should = the support of the simulcast feature be negotiated between the endpoints fi= rst, before it is enabled? Most likely it would require 2 O/A transactions. Regards, Christer From: Bo Burman Sent: 2. joulukuuta 2013 12:52 To: Bernard Aboba; Christer Holmberg; mmusic@ietf.org Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Should a simulcast-capable endpoint be restricted to be a simulcast-sender-= only or a simulcast-receiver-only, or do we envision endpoints that are cap= able of both sending and receiving simulcast? One example would be if simul= cast streams are to be forwarded between different SFU (using Bernard's ter= minology below). If so and assuming that we define a new 5888-type simulcast grouping, do we= need separate groupings for send direction simulcast and receive direction= simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-g= rouped media blocks fully sufficient? Also, I think the way to use this approach for simulcast in combination wit= h multiple separate media sources (like multiple cameras) or media sinks (l= ike multiple displays) would be pretty straightforward; just add one simulc= ast grouping per media source/sink. From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 30 november 2013 20:31 To: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Christer asked: "In your example, how does the answerer know that the offered m- lines are = for simulcast? As far as O/A is concerned, it could just be a number of com= pletely separate (different content etc) uni-directional streams." [BA] The most obvious way would be grouping. Looking at RFC 5888/5583, it = doesn't appear that either FID or DDP grouping would apply to simulcast. = So perhaps a new group type would be needed. Bernard Aboba >= wrote: At IETF 88, a number of participants (including myself) expressed the view= that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below, I= will attempt to explain how simulcast might be negotiated in a simplified = Offer/Answer exchange based on the principles of Unified Plan. Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU), while receiving one among a se= t of potential streams from the SFU, with the SFU being able to switch betw= een the streams that it is sending to the endpoint without signaling. RFC = 3264 describes how to handle each of these situations. With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following: If the offerer wishes to only send media on a stream to its peer, it MUST m= ark the stream as sendonly with the "a=3Dsendonly" attribute. We refer to= a stream as being marked with a certain direction if a direction attribute= was present as either a media stream attribute or a session attribute. For= sendonly RTP streams, the payload type numbers indicate the value of the p= ayload type field in RTP packet the offerer is planning to send for that co= dec... In all cases, the formats in the "m=3D" line MUST be listed in orde= r of preference, with the first format listed being preferred. In this cas= e, preferred means that the recipient of the offer SHOULD use the format wi= th the highest preference that is acceptable to it. If multiple media strea= ms of different types are present, it means that the offerer wishes to use = those streams at the same time. A typical case is an audio and a video str= eam as part of a videoconference. If multiple media streams of the same type are present in an offer, it mea= ns that the offerer wishes to send (and/or receive) multiple streams of tha= t type at the same time... Each stream MAY use different encodings. With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says: If the offerer wishes to only receive media from its peer, it MUST mark the= stream as recvonly... If multiple formats are listed, it means that the of= ferer is capable of making use of any of those formats during the session. = In other words, the answerer MAY change formats in the middle of the sessi= on, making use of any of the formats listed, without sending a new offer. = For a sendonly stream, the offer SHOULD indicate those formats the offerer = is willing to send for this stream. For a recvonly stream, the offer SHOU= LD indicate those formats the offerer is willing to receive for this stream= .... For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to receive fo= r that codec. Based on the above: 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line. = The offer would also include a single m=3Dline (with a=3Drecvonly) describ= ing the streams that the endpoint is prepared to receive, each with their o= wn payload type. 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition, the answer would include a single m=3Dline (with a= =3Dsendonly) indicating the streams from among those proposed by the endpoi= nt that the SFU is prepared to send. The SFU can then switch between those= streams without having to signal the endpoint. Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send, an Answerer can indicate how man= y streams it is prepared to receive (might only be one if simulcast isn't s= upported). Similarly, an Answerer can select those simulcast streams it i= s prepared to send (might only be one if simulcast isn't supported). Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640,y=3D360] m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320,y=3D180] m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320,y=3D180] Example Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640,y=3D360] m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320,y=3D180] m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D320,y=3D180] --_000_7594FB04B1934943A5C02806D1A2204B1C5659AAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

If the answerer does NOT = support simulcast, it will see an Offer with multiple uni-directional strea= ms. The behavior is difficult to predict.

 <= /p>

So, even with a mechanism= based on grouping, the question is still: should the support of the simulc= ast feature be negotiated between the endpoints first, before it is enabled? Most likely it would require 2 O/A transactions.=

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Bo Burma= n
Sent: 2. joulukuuta 2013 12:52
To: Bernard Aboba; Christer Holmberg; mmusic@ietf.org
Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Should a simulcast-capabl= e endpoint be restricted to be a simulcast-sender-only or a simulcast-recei= ver-only, or do we envision endpoints that are capable of both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard’s term= inology below).

 <= /p>

If so and assuming that w= e define a new 5888-type simulcast grouping, do we need separate groupings = for send direction simulcast and receive direction simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?

 <= /p>

Also, I think the way to = use this approach for simulcast in combination with multiple separate media= sources (like multiple cameras) or media sinks (like multiple displays) would be pretty straightforward; just add one simulcast grouping= per media source/sink.

 <= /p>

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 30 november 2013 20:31
To: Christer Holmberg; mmusic@iet= f.org
Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Christer asked:
"In your example, how does =
the answerer know that the offered m- lines are for simulcast? As far as O/=
A is concerned, it could just be a number of completely separate (different=
 content etc) uni-directional streams."
[BA] The most obvious way would =
be grouping.  Looking at RFC 5888/5583, it doesn't appear that either =
FID or DDP grouping would apply to simulcast.   So perhaps a new =
group type would be needed. 
 
 
Bernard Aboba <=
bernard_aboba@hotmail.com> wrote:
 

At IETF 88, a number of  participants (including my= self) expressed the view that draft-westerlund-avtcore-rtp-simulcast was to= o complicated.  Below, I will attempt to explain how simulcast might be negotiated in a simplified Offer/Answer exchange based = on the principles of Unified Plan.
 
Typically in simulcast we have an endpoint sending multiple streams in= parallel to the Selective Forwarding Unit (SFU), while receiving one = among a set of potential streams from the SFU, with the SFU being able to s= witch between the streams that it is sending to the endpoint without signaling.  RFC 3264 describes how to ha= ndle each of these situations.
 
With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following:
 

If the offerer wishes to only send media on a stream to = its peer, it MUST mark the stream as sendonly with the "a=3Dsendo= nly" attribute.  We  refer to a stream as being marked with = a certain direction if a direction attribute was present as either a media stre= am attribute or a session attribute. For sendonly RTP streams, the pay= load type numbers indicate the value of the payload type field in RTP packe= t the offerer is planning to send for that codec...  In all cases, the formats in the "m=3D" line MUST= be listed in order of preference, with the first format listed being = preferred.  In this case, preferred means that the recipient of t= he offer SHOULD use the format with the highest preference that is acceptable to it. If multiple media streams of different types are pres= ent, it means that the offerer wishes to use those streams at the same time= .  A typical case is an audio and a video stream as part of a vid= eoconference.
 
If multiple media streams of the same type are present in an offer,  i= t means that the offerer wishes to send (and/or receive) multiple streams o= f that type at the same time...  Each stream MAY use different en= codings.

 
With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says:
 

If the offerer wishes to only receive media from its pee= r, it MUST mark the stream as recvonly... If multiple formats are listed, i= t means that the offerer is capable of making use of any of those formats during the session.  In other words, the answer= er MAY change formats in the middle of the session, making use of any of th= e formats listed, without sending a new offer.  For a sendonly st= ream, the offer SHOULD indicate those formats the offerer is willing to send for this stream.  For a recvonly stream,  the= offer SHOULD indicate those formats the offerer is willing to receive for = this stream....
  
For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to  recei= ve for that codec. 

 
Based on the above:
 
1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line.&= nbsp; The offer would also include a single m=3Dline (with a=3Drecvonly) de= scribing the streams that the endpoint is prepared to receive, each with their own payload type.
 
2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line).  In addition, the answer would include a single m=3Dline (w= ith a=3Dsendonly) indicating the streams from among those proposed by the endpoint that the SFU is prepared to send.&nbs= p; The SFU can then switch between those streams without having to signal t= he endpoint.
 
Since it is possible for the Answerer to accept/reject each of the pro= posed streams the Offerer is proposing to send, an Answerer can indica= te how many streams it is prepared to receive (might only be one if simulca= st isn't supported).   Similarly, an Answerer can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).
 
Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio):
 
   v=3D0
   o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
   s=3DSimulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.156
   b=3DAS:665
   m=3Dvideo 49300 RTP/AVP 97
   a=3Dsendonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 send [x=3D640,y=3D360]
   m=3Dvideo 49302 RTP/AVP 98
   a=3Dsendonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 send [x=3D320,y=3D180]
   m=3Dvideo 49304 RTP/AVP 100 99
   a=3Drecvonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 recv [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:99 recv [x=3D320,y=3D180]
 
 
Example Answer:
 
   v=3D0
   o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
   s=3DAnswer to Simulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.43
   b=3DAS:665
   m=3Dvideo 48000 RTP/AVP 97
   a=3Drecvonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 recv [x=3D640,y=3D360]
   m=3Dvideo 48002 RTP/AVP 98
   a=3Drecvonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 recv [x=3D320,y=3D180]
   m=3Dvideo 48004 RTP/AVP 100 99
   a=3Dsendonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D320,y=3D180]
 

--_000_7594FB04B1934943A5C02806D1A2204B1C5659AAESESSMB209erics_-- From wwwrun@rfc-editor.org Mon Dec 2 03:46:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D81AE3E9 for ; Mon, 2 Dec 2013 03:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc7TWtXmiyW5 for ; Mon, 2 Dec 2013 03:46:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF811AE3EC for ; Mon, 2 Dec 2013 03:46:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B335079E002; Mon, 2 Dec 2013 03:45:59 -0800 (PST) To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, ari.keranen@ericsson.com From: RFC Errata System Message-Id: <20131202114559.B335079E002@rfc-editor.org> Date: Mon, 2 Dec 2013 03:45:59 -0800 (PST) Cc: rfc-editor@rfc-editor.org, Jorgen.Axell@ericsson.com, mmusic@ietf.org Subject: [MMUSIC] [Technical Errata Reported] RFC3264 (3818) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:46:38 -0000 The following errata report has been submitted for RFC3264, "An Offer/Answer Model with Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3264&eid=3818 -------------------------------------- Type: Technical Reported by: Jörgen Axell Section: 4 Original Text ------------- The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). Corrected Text -------------- The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the offer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). Notes ----- You can't reject an answer. When the answer is received the SDP negotiation is completed. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02) -------------------------------------- Title : An Offer/Answer Model with Session Description Protocol (SDP) Publication Date : June 2002 Author(s) : J. Rosenberg, H. Schulzrinne Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From bo.burman@ericsson.com Mon Dec 2 03:55:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72E31AE3FC for ; Mon, 2 Dec 2013 03:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_Olrak5DKA4 for ; Mon, 2 Dec 2013 03:55:15 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 58C5F1ADEA6 for ; Mon, 2 Dec 2013 03:55:14 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-07-529c751fc8fd Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 87.E3.03802.F157C925; Mon, 2 Dec 2013 12:55:11 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.236]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 12:55:10 +0100 From: Bo Burman To: Christer Holmberg , Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Thread-Index: AQHO7HThAQ8rSNEoVE2qFCbMYyib85o9ZdUAgAC1wYCAApmEgIAAACOAgAAb0pA= Date: Mon, 2 Dec 2013 11:55:10 +0000 Message-ID: References: , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E061B74ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvra586Zwgg1d/RS32L7nMbDF1+WMW ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJVxrm0Kc8Gnm4wVH9asYGxgfLqbsYuRk0NC wERi0ZY/TBC2mMSFe+vZuhi5OIQEDjFK/D81mQXCWcwocWHHIrAONgENifk77jKCJEQEOhgl 5hw5BNTOwSEs4CEx9bw7SI2IgKfEy50trBC2n8TkmxPBbBYBFYlrDw6BbeMV8JVY+GkrI8SC jUwSt/pOsoEkOIEaHixaDlbEKCArcf/7PRYQm1lAXOLWk/lQpwpILNlznhnCFpV4+fgfK4St KNH+tIER5B5mgXyJPSuKIHYJSpyc+YRlAqPILCSTZiFUzUJSBVGiI7Fg9yc2CFtbYtnC18ww 9pkDj5mQxRcwsq9iZM9NzMxJLzfaxAiMn4NbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGFPZizYLzGAuaFzhFmopH+Cezcsc2tBpOH861yZBmQ/Bkj9Z pURunEw7sOVHTvlh7cYpyRLNR4NLnC88nf+cXcy64TSvyLf9dfXvhRPunfnNdfOQVs/O2Xu9 DENXTlvcqq3mP+2CiEmTxJul085+1Ch/a+X/YNXcwIdqE3/NV7nvx6QRECLWrMRSnJFoqMVc VJwIANDyUxBtAgAA Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:55:20 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E061B74ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. This approach with having the ability to negotiate "the simulcast fe= ature" in a first O/A is already present in draft-westerlund-avtcore-rtp-si= mulcast. It is however not required to use 2 O/A, in case simulcast support= is somehow known or at least very likely. From: Christer Holmberg Sent: den 2 december 2013 12:13 To: Bo Burman; Bernard Aboba; mmusic@ietf.org Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Hi, If the answerer does NOT support simulcast, it will see an Offer with multi= ple uni-directional streams. The behavior is difficult to predict. So, even with a mechanism based on grouping, the question is still: should = the support of the simulcast feature be negotiated between the endpoints fi= rst, before it is enabled? Most likely it would require 2 O/A transactions. Regards, Christer From: Bo Burman Sent: 2. joulukuuta 2013 12:52 To: Bernard Aboba; Christer Holmberg; mmusic@ietf.org Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Should a simulcast-capable endpoint be restricted to be a simulcast-sender-= only or a simulcast-receiver-only, or do we envision endpoints that are cap= able of both sending and receiving simulcast? One example would be if simul= cast streams are to be forwarded between different SFU (using Bernard's ter= minology below). If so and assuming that we define a new 5888-type simulcast grouping, do we= need separate groupings for send direction simulcast and receive direction= simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-g= rouped media blocks fully sufficient? Also, I think the way to use this approach for simulcast in combination wit= h multiple separate media sources (like multiple cameras) or media sinks (l= ike multiple displays) would be pretty straightforward; just add one simulc= ast grouping per media source/sink. From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 30 november 2013 20:31 To: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Christer asked: "In your example, how does the answerer know that the offered m- lines are = for simulcast? As far as O/A is concerned, it could just be a number of com= pletely separate (different content etc) uni-directional streams." [BA] The most obvious way would be grouping. Looking at RFC 5888/5583, it = doesn't appear that either FID or DDP grouping would apply to simulcast. = So perhaps a new group type would be needed. Bernard Aboba >= wrote: At IETF 88, a number of participants (including myself) expressed the view= that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below, I= will attempt to explain how simulcast might be negotiated in a simplified = Offer/Answer exchange based on the principles of Unified Plan. Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU), while receiving one among a se= t of potential streams from the SFU, with the SFU being able to switch betw= een the streams that it is sending to the endpoint without signaling. RFC = 3264 describes how to handle each of these situations. With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following: If the offerer wishes to only send media on a stream to its peer, it MUST m= ark the stream as sendonly with the "a=3Dsendonly" attribute. We refer to= a stream as being marked with a certain direction if a direction attribute= was present as either a media stream attribute or a session attribute. For= sendonly RTP streams, the payload type numbers indicate the value of the p= ayload type field in RTP packet the offerer is planning to send for that co= dec... In all cases, the formats in the "m=3D" line MUST be listed in orde= r of preference, with the first format listed being preferred. In this cas= e, preferred means that the recipient of the offer SHOULD use the format wi= th the highest preference that is acceptable to it. If multiple media strea= ms of different types are present, it means that the offerer wishes to use = those streams at the same time. A typical case is an audio and a video str= eam as part of a videoconference. If multiple media streams of the same type are present in an offer, it mea= ns that the offerer wishes to send (and/or receive) multiple streams of tha= t type at the same time... Each stream MAY use different encodings. With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says: If the offerer wishes to only receive media from its peer, it MUST mark the= stream as recvonly... If multiple formats are listed, it means that the of= ferer is capable of making use of any of those formats during the session. = In other words, the answerer MAY change formats in the middle of the sessi= on, making use of any of the formats listed, without sending a new offer. = For a sendonly stream, the offer SHOULD indicate those formats the offerer = is willing to send for this stream. For a recvonly stream, the offer SHOU= LD indicate those formats the offerer is willing to receive for this stream= .... For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to receive fo= r that codec. Based on the above: 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line. = The offer would also include a single m=3Dline (with a=3Drecvonly) describ= ing the streams that the endpoint is prepared to receive, each with their o= wn payload type. 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition, the answer would include a single m=3Dline (with a= =3Dsendonly) indicating the streams from among those proposed by the endpoi= nt that the SFU is prepared to send. The SFU can then switch between those= streams without having to signal the endpoint. Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send, an Answerer can indicate how man= y streams it is prepared to receive (might only be one if simulcast isn't s= upported). Similarly, an Answerer can select those simulcast streams it i= s prepared to send (might only be one if simulcast isn't supported). Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640,y=3D360] m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320,y=3D180] m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320,y=3D180] Example Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640,y=3D360] m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320,y=3D180] m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D320,y=3D180] --_000_BBE9739C2C302046BD34B42713A1E2A22E061B74ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree. This approach with= having the ability to negotiate “the simulcast feature” in a f= irst O/A is already present in draft-westerlund-avtcore-rtp-simulcast. It is however not required to use 2 O/A, in case simulcast support is some= how known or at least very likely.

 <= /p>

From: Christer= Holmberg
Sent: den 2 december 2013 12:13
To: Bo Burman; Bernard Aboba; mmusic@ietf.org
Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Hi,

 <= /p>

If the answerer does NOT = support simulcast, it will see an Offer with multiple uni-directional strea= ms. The behavior is difficult to predict.

 <= /p>

So, even with a mechanism= based on grouping, the question is still: should the support of the simulc= ast feature be negotiated between the endpoints first, before it is enabled? Most likely it would require 2 O/A transactions.=

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Bo Burma= n
Sent: 2. joulukuuta 2013 12:52
To: Bernard Aboba; Christer Holmberg; mmusic@ietf.org
Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Should a simulcast-capabl= e endpoint be restricted to be a simulcast-sender-only or a simulcast-recei= ver-only, or do we envision endpoints that are capable of both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard’s term= inology below).

 <= /p>

If so and assuming that w= e define a new 5888-type simulcast grouping, do we need separate groupings = for send direction simulcast and receive direction simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?

 <= /p>

Also, I think the way to = use this approach for simulcast in combination with multiple separate media= sources (like multiple cameras) or media sinks (like multiple displays) would be pretty straightforward; just add one simulcast grouping= per media source/sink.

 <= /p>

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 30 november 2013 20:31
To: Christer Holmberg; mmusic@iet= f.org
Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Christer asked:
"In your example, how does =
the answerer know that the offered m- lines are for simulcast? As far as O/=
A is concerned, it could just be a number of completely separate (different=
 content etc) uni-directional streams."
[BA] The most obvious way would =
be grouping.  Looking at RFC 5888/5583, it doesn't appear that either =
FID or DDP grouping would apply to simulcast.   So perhaps a new =
group type would be needed. 
 
 
Bernard Aboba <=
bernard_aboba@hotmail.com> wrote:
 

At IETF 88, a number of  participants (including my= self) expressed the view that draft-westerlund-avtcore-rtp-simulcast was to= o complicated.  Below, I will attempt to explain how simulcast might be negotiated in a simplified Offer/Answer exchange based = on the principles of Unified Plan.
 
Typically in simulcast we have an endpoint sending multiple streams in= parallel to the Selective Forwarding Unit (SFU), while receiving one = among a set of potential streams from the SFU, with the SFU being able to s= witch between the streams that it is sending to the endpoint without signaling.  RFC 3264 describes how to ha= ndle each of these situations.
 
With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following:
 

If the offerer wishes to only send media on a stream to = its peer, it MUST mark the stream as sendonly with the "a=3Dsendo= nly" attribute.  We  refer to a stream as being marked with = a certain direction if a direction attribute was present as either a media stre= am attribute or a session attribute. For sendonly RTP streams, the pay= load type numbers indicate the value of the payload type field in RTP packe= t the offerer is planning to send for that codec...  In all cases, the formats in the "m=3D" line MUST= be listed in order of preference, with the first format listed being = preferred.  In this case, preferred means that the recipient of t= he offer SHOULD use the format with the highest preference that is acceptable to it. If multiple media streams of different types are pres= ent, it means that the offerer wishes to use those streams at the same time= .  A typical case is an audio and a video stream as part of a vid= eoconference.
 
If multiple media streams of the same type are present in an offer,  i= t means that the offerer wishes to send (and/or receive) multiple streams o= f that type at the same time...  Each stream MAY use different en= codings.

 
With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says:
 

If the offerer wishes to only receive media from its pee= r, it MUST mark the stream as recvonly... If multiple formats are listed, i= t means that the offerer is capable of making use of any of those formats during the session.  In other words, the answer= er MAY change formats in the middle of the session, making use of any of th= e formats listed, without sending a new offer.  For a sendonly st= ream, the offer SHOULD indicate those formats the offerer is willing to send for this stream.  For a recvonly stream,  the= offer SHOULD indicate those formats the offerer is willing to receive for = this stream....
  
For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to  recei= ve for that codec. 

 
Based on the above:
 
1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line.&= nbsp; The offer would also include a single m=3Dline (with a=3Drecvonly) de= scribing the streams that the endpoint is prepared to receive, each with their own payload type.
 
2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line).  In addition, the answer would include a single m=3Dline (w= ith a=3Dsendonly) indicating the streams from among those proposed by the endpoint that the SFU is prepared to send.&nbs= p; The SFU can then switch between those streams without having to signal t= he endpoint.
 
Since it is possible for the Answerer to accept/reject each of the pro= posed streams the Offerer is proposing to send, an Answerer can indica= te how many streams it is prepared to receive (might only be one if simulca= st isn't supported).   Similarly, an Answerer can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).
 
Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio):
 
   v=3D0
   o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
   s=3DSimulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.156
   b=3DAS:665
   m=3Dvideo 49300 RTP/AVP 97
   a=3Dsendonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 send [x=3D640,y=3D360]
   m=3Dvideo 49302 RTP/AVP 98
   a=3Dsendonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 send [x=3D320,y=3D180]
   m=3Dvideo 49304 RTP/AVP 100 99
   a=3Drecvonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 recv [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:99 recv [x=3D320,y=3D180]
 
 
Example Answer:
 
   v=3D0
   o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
   s=3DAnswer to Simulcast Enabled Unified Plan Client
   t=3D0 0
   c=3DIN IP4 192.0.2.43
   b=3DAS:665
   m=3Dvideo 48000 RTP/AVP 97
   a=3Drecvonly
   b=3DAS:520
   a=3Drtpmap:97 H264/90000
   a=3Dfmtp:97 profile-level-id=3D42c01e
   a=3Dimageattr:97 recv [x=3D640,y=3D360]
   m=3Dvideo 48002 RTP/AVP 98
   a=3Drecvonly
   a=3Drtpmap:98 H264/90000
   a=3Dfmtp:98 profile-level-id=3D42c01e
   a=3Dimageattr:98 recv [x=3D320,y=3D180]
   m=3Dvideo 48004 RTP/AVP 100 99
   a=3Dsendonly
   a=3Drtpmap:100 H264/90000
   a=3Dfmtp:100 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D640,y=3D360]
   a=3Drtpmap:99 H264/90000
   a=3Dfmtp:99 profile-level-id=3D42c01e
   a=3Dimageattr:100 send [x=3D320,y=3D180]
 

--_000_BBE9739C2C302046BD34B42713A1E2A22E061B74ESESSMB105erics_-- From mperumal@cisco.com Mon Dec 2 05:51:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388FD1AE025 for ; Mon, 2 Dec 2013 05:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDkibYGYJ1oI for ; Mon, 2 Dec 2013 05:51:41 -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 391BE1ADF8D for ; Mon, 2 Dec 2013 05:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3055; q=dns/txt; s=iport; t=1385992299; x=1387201899; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+YdUQMx2Nc3S33xBbch/w/qH8UJx+hhqwSLuzeDiNO0=; b=Q2FaQu1hkvVzSzt99d03fM48oihtvmw7J9UmLMGpq8u1VdU7XlstM9DY CBr4xc8+fa5dergy7SLrI7Di9LLSRD3N14eqx+OG6EmUzCkjElb3E0ip7 d80UPA3A1ImDleccaYiXMn54oB/JDftP3blNhZnqGZcuXgxsHBW0CVzMN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABmQnFKtJXHA/2dsb2JhbABZgwc4U7gTToEkFnSCJQEBAQQBAQFrCwwEAgEIEQQBAQsZBAcnCxQJCAIEAQ0FCAESh2YNv2wXjjcBAR4PIgIFBoMagRMDiQqhHYFrgT6BcTk X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208";a="288834891" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 02 Dec 2013 13:51:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB2DpFLs013669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 13:51:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 07:51:15 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: SM , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO7iKd46CkCCVDPEKJVrLcL8GKUppA6t6g Date: Mon, 2 Dec 2013 13:51:15 +0000 Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> In-Reply-To: <6.2.5.6.2.20131130003721.0d65a980@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 13:51:43 -0000 |Media type registrations are usually published as Informational RFCs. =20 |I suggest publishing draft-ietf-mmusic-sdp-g723-g729-04 as an Information = RFC. Registered audio media types are listed here: http://www.iana.org/assignments/media-types/audio As you can see most of them are described in Standards Track RFCs, so your = observation is incorrect. Muthu |-----Original Message----- |From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of SM |Sent: Saturday, November 30, 2013 2:24 PM |To: Ari Ker=E4nen |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |Subject: Re: [MMUSIC] Last Call: = (Offer/Answer Considerations |for G723 Annex A and G729 Annex B) to Proposed Standard | |Hi Ari, | |I read the PROTO write-up. There isn't any answer to the following questi= on: | | "Why is this the proper type of RFC?" | |At 10:34 29-11-2013, Parthasarathi R wrote: |>The draft-ietf-mmusic-sdp-g723-g729-04.txt related minutes of IETF84 is |>given below for your reference: |> |>"draft-muthu-mmusic-offer-answer-g723-g729-00.txt - Parthasarathi Ravindr= an |> |>Hadriel had clarifying questions on the proposed solution. |> |>Christer asked why this isn't addressed by change to the document that |>defined this payload (RFC 4856), to include the o/a considerations. IOW d= o a |>bis of that document. Cullen said this should either be an update or a bi= s |>to the original doc =AD it should not be a BCP. |> |>Jonathan agreed with doing a bis. Roni said that when discussed in PAYLOA= D |>WG (with many of same people) they suggested bringing it to MMUSIC and do= ing |>as BCP. Robert said BCP is almost certainly wrong. |> |>Chairs noted that nobody disagrees there is an issue. Chairs will discuss |>with PAYLOAD WG chairs and ADs about what the proper process should be fo= r |>resolving and documenting it." |> |>The related link is |>http://www.ietf.org/proceedings/84/minutes/minutes-84-mmusic. The draft i= s |>submitted as "Standards track" as per WG chairs & AD instructions after t= he |>meeting and the relevant link is |>http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html. |> |>Your other comments are related to RFC 4856 and I have initiated in the m= ail |>thread to discuss those comments separately. | |According to the message quoted above: | | (a) Cullen said that the document should either be an update or a bis t= o | the original document. | | (b) Robert said that BCP was certainly wrong. | | (c) The draft was submitted as "Standards track" as that was the | instructions given by the WG Chairs and Area Director. | |There isn't any explanation. Media type |registrations are usually published as |Informational RFCs. I suggest publishing |draft-ietf-mmusic-sdp-g723-g729-04 as an Information RFC. | |Regards, |-sm | |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From ari.keranen@ericsson.com Mon Dec 2 07:28:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543C41AE018 for ; Mon, 2 Dec 2013 07:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOF8WUair2Hq for ; Mon, 2 Dec 2013 07:28:30 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 612F91A1F5B for ; Mon, 2 Dec 2013 07:28:30 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-42-529ca71b00c4 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6A.5A.27941.B17AC925; Mon, 2 Dec 2013 16:28:27 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.347.0; Mon, 2 Dec 2013 16:28:27 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0303111048A; Mon, 2 Dec 2013 17:28:27 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E2FA755259; Mon, 2 Dec 2013 17:28:24 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8C8AD4E977; Mon, 2 Dec 2013 17:28:24 +0200 (EET) Message-ID: <529CA719.3090007@ericsson.com> Date: Mon, 2 Dec 2013 17:28:25 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: SM References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> In-Reply-To: <6.2.5.6.2.20131130003721.0d65a980@resistor.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvra708jlBBhMfKVm8v6BrMXX5YxaL yZ/6WC2ObzjE7sDiMeX3RlaPJUt+Mnl8mP+F3eN99zO2AJYoLpuU1JzMstQifbsErox/G6UK jglXnJ8wm7mBcTd/FyMnh4SAicSjVadZIWwxiQv31rN1MXJxCAkcYZTovbMEylnPKDH1bycT hLOHUeLE3wXMEM5aRomZM49COcsZJbrmPmcEGcYroC3R+7SDHcRmEVCRuNF9kgnEZhOwl7g5 4TpYXFQgWWJzWw8zRL2gxMmZT1hAbBEBCYm9G1eC1TML5Enc2L0TbLWwwCJGiZs3H0MdtYRZ 4sLU32CncwrYShzuec4K0WErcWHOdRYIW16ieetsZoj31CSuntsEZgsJqEpc/feKcQKj6Cwk y2chaZ+FpH0BI/MqRo7i1OKk3HQjg02MwCg5uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoFRyClWzKBXrL39o1V5oNS8n3XPJAP0wrNPKm9ZZR4058D6 HQy5zpPDJdo+zC8yX+Kp/7yDUyJq5ln5959XLKzI2r1wPrv1f/+X66dN2jXRqzz74pNiXhXt mwc2syg+v7grN9/vcMCOg4+85tmsYhTxjU7mDNEVnvwsYR77/H8ppu7CfBssru9TYinOSDTU Yi4qTgQAMC/HJGACAAA= Cc: Flemming Andreasen , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:28:32 -0000 Hi, As Partha & Muthu already mentioned, there was discussion and a consensus call on the type of the document and the consensus was that PS is the correct type. Admittedly the proto write-up could have been a bit more elaborate on that. Cheers, Ari On 11/30/13 10:54 AM, SM wrote: > Hi Ari, > > I read the PROTO write-up. There isn't any answer to the following > question: > > "Why is this the proper type of RFC?" > > At 10:34 29-11-2013, Parthasarathi R wrote: >> The draft-ietf-mmusic-sdp-g723-g729-04.txt related minutes of IETF84 is >> given below for your reference: >> >> "draft-muthu-mmusic-offer-answer-g723-g729-00.txt - Parthasarathi >> Ravindran >> >> Hadriel had clarifying questions on the proposed solution. >> >> Christer asked why this isn't addressed by change to the document that >> defined this payload (RFC 4856), to include the o/a considerations. >> IOW do a >> bis of that document. Cullen said this should either be an update or a >> bis >> to the original doc ­ it should not be a BCP. >> >> Jonathan agreed with doing a bis. Roni said that when discussed in >> PAYLOAD >> WG (with many of same people) they suggested bringing it to MMUSIC and >> doing >> as BCP. Robert said BCP is almost certainly wrong. >> >> Chairs noted that nobody disagrees there is an issue. Chairs will discuss >> with PAYLOAD WG chairs and ADs about what the proper process should be >> for >> resolving and documenting it." >> >> The related link is >> http://www.ietf.org/proceedings/84/minutes/minutes-84-mmusic. The >> draft is >> submitted as "Standards track" as per WG chairs & AD instructions >> after the >> meeting and the relevant link is >> http://www.ietf.org/mail-archive/web/mmusic/current/msg09590.html. >> >> Your other comments are related to RFC 4856 and I have initiated in >> the mail >> thread to discuss those comments separately. > > According to the message quoted above: > > (a) Cullen said that the document should either be an update or a bis to > the original document. > > (b) Robert said that BCP was certainly wrong. > > (c) The draft was submitted as "Standards track" as that was the > instructions given by the WG Chairs and Area Director. > > There isn't any explanation. Media type registrations are usually > published as Informational RFCs. I suggest publishing > draft-ietf-mmusic-sdp-g723-g729-04 as an Information RFC. > > Regards, > -sm > From casner@acm.org Mon Dec 2 08:52:20 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C021AD698 for ; Mon, 2 Dec 2013 08:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSMYFS5txckW for ; Mon, 2 Dec 2013 08:52:18 -0800 (PST) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id 828D31AD694 for ; Mon, 2 Dec 2013 08:52:18 -0800 (PST) Received: from packetdesign.com (vpn2-int.packetdesign.com [192.168.0.181]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id rB2Gq4jM000321; Mon, 2 Dec 2013 08:52:06 -0800 Date: Mon, 2 Dec 2013 08:52:05 -0800 (PST) From: Stephen Casner To: Parthasarathi R In-Reply-To: <016b01ceed2f$0be29e90$23a7dbb0$@co.in> Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <016b01ceed2f$0be29e90$23a7dbb0$@co.in> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: 'Flemming Andreasen' , 'SM' , 'Ari Kerdnen' , mmusic@ietf.org Subject: Re: [MMUSIC] RFC 4856 is in the correct RFC category - Errata query? [was RE: Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:52:20 -0000 On Fri, 29 Nov 2013, Parthasarathi R wrote: > Hi Casner/Ari/Flemming, > > As part of draft-ietf-mmusic-sdp-g723-g729-04 draft last call comments, the > following comments from sm are relevant to RFC 4856 category > > 1) > > The fact that RFC 4856 is > > published as a Proposed Standard does not mean that it is the correct > > status. There are a lot of oddities in the IETF Stream. I prefer > > not to ask about those oddities. :-) > > > The authors of draft-ietf-mmusic-sdp-g723-g729-04 (Muthu & Myself) are of > the opinion that RFC 4856 is in the correct category as it describes about > codec like G.723 and G.729. I believe the status of RFC 4856 is correct. It updates RFC 3555 to define and register the media types for the RTP profile RFC 3551. What other status would be more appropriate for that ? > 2) > > draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 > > Annex B. There aren't any references for them. > > > draft-ietf-mmusic-sdp-g723-g729-04 updates RFC 4856 w.r.t offer/answer(O/A) > mechanism of G723 Annex A and G729 Annex B. RFC 4856 does not have reference > for G723 Annex A and G729 Annex B. IMO if the codec reference has to be > mentioned, it has to be mentioned in RFC 4856 and not required in > draft-ietf-mmusic-sdp-g723-g729-04 as it updates only O/A of RFC 4856. RFC 4856 is not a specification of any payload format; it refers to other documents that specify the payload formats (and SDP usage). It only specifies how a MIME media type is used to refer to a payload format that carries an encoding. RFC 4856 refers to RFC 3551 for the payload format of G723 and G729, which in turn refers to the ITU Recommendations. If the draft is providing more details about how the packetizations of G723 and G729 should be negotiated and used, then the draft is updating RFC 3551. -- Steve > > -----Original Message----- > > From: SM [mailto:sm@resistor.net] > > Sent: Wednesday, November 20, 2013 12:57 AM > > To: Parthasarathi R > > Cc: mmusic@ietf.org > > Subject: RE: [MMUSIC] Last Call: > 04.txt> (Offer/Answer Considerations for G723 Annex A and G729 Annex B) > > to Proposed Standard > > > > Hi Partha, > > > > I forgot to mention that I am not subscribed to the MMUSIC mailing > > list. > > > > At 10:27 19-11-2013, Parthasarathi R wrote: > > >I have clarified all your below queries. Could you please let me know > > in > > >case you still see any specific issue with the draft. > > > > In my humble opinion RFC 4856 is more about a media type registration > > request instead of a technical specification about > > interoperability. It is mentioned in Section 1 of that RFC that it > > updates the media type registrations. The fact that RFC 4856 is > > published as a Proposed Standard does not mean that it is the correct > > status. There are a lot of oddities in the IETF Stream. I prefer > > not to ask about those oddities. :-) > > > > draft-ietf-mmusic-sdp-g723-g729-04 mentions G723 Annex A and G729 > > Annex B. There aren't any references for them. The problem with the > > draft is that it builds upon RFC 4856 instead of the technical > > specification where the protocol is specified. Is G723 Annex A and > > G729 Annex B needed to implement what the draft tries to do? In my > > opinion, yes. > > > > The document shepherd write-up has the following question: > > > > "Why is this the proper type of RFC?" > > > > The answer provided is: > > > > "Proposed Standard. The title page notes the document as Standards > > Track" > > > > That does not answer the question. > > > > Regards, > > -sm > From christer.holmberg@ericsson.com Mon Dec 2 11:44:27 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3AC1ADE71 for ; Mon, 2 Dec 2013 11:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc17oZoiOxQr for ; Mon, 2 Dec 2013 11:44:26 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E3EBF1ADAEA for ; Mon, 2 Dec 2013 11:44:25 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-c4-529ce316163d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EC.45.23787.613EC925; Mon, 2 Dec 2013 20:44:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0347.000; Mon, 2 Dec 2013 20:44:22 +0100 From: Christer Holmberg To: Oscar Ohlsson , "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Thread-Index: Ac7mkSk0zo3yfrWATZqATJzetabOTAAyKbLgAg8wB0A= Date: Mon, 2 Dec 2013 19:44:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C566971@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra744zlBBguusVtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYs6+ApmSFfs+buTpYHxvmgXIyeHhICJxPPlB5kgbDGJC/fW s4HYQgKHGCVuTKmFsBcxSly4C1TDwcEmYCHR/U8bJCwiECrR1TWNEcQWFnCQODS9jRki7ijx pHUtO4RtJdFx+gZYnEVARWLds2ZWEJtXwFfi+uUlQDYX0PiJjBKPt3eBNXAK+EncWvkazGYE uuf7qTVgtzELiEt8OHidGeJOAYkle85D2aISLx//Y4WwlSRWbL/ECFGvJ3Fj6hQ2CFtbYtnC 18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenlhpsYgSF/cMtv3R2Mp86J HGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjfMHHy9c++x97tlj55+ur S1Jink9rr3w6z8b1d52LjW3UuV1t6+J2iZe8Pf9ZYv3bGaaFTPsksib+Kzb2P/qtfu/1tpor bFHTJv5c+q3/GGvVRIEoHlFpZ/UpnrnHmSy+ccjcj5z8JczRN/pbdavYpL2FrVKGcblm5S6S FZqPKy4nPr7N+vm4EktxRqKhFnNRcSIAIVgaAEcCAAA= Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:44:28 -0000 Hi Oscar, In section 3.1, I suggest to modify/replace the third, fourth and fifth bul= lets with the 2 following bullets: "o If the endpoint supports, and is willing to use, a ciphersuite with an= associated certificate, it MUST include an SDP fingerprint attribute [RFC4572] in the SDP. o If a ciphersuite with an associated certificate is selected during the = DTLS handshake, the certificate=20 received during the DTLS handshake MUST match the fingerprint received in the SDP fingerprint attribute. If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects." Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Oscar Ohlsson=20 L=E4hetetty: 22. marraskuuta 2013 11:19 Vastaanottaja: Christer Holmberg; mmusic@ietf.org Aihe: RE: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Hi, I have a comment on the usage of the fingerprint attribute in draft-ietf-mm= usic-udptl-dtls-01. In future versions of 3GPP TS 33.328 we would like to u= se UDPTL-DTLS in combination with MIKEY-TICKET. In that case there is no e= xchange of certificate fingerprints; instead the offerer and answerer negot= iates a secret key over SDP and then runs a DTLS-PSK handshake. The problem= is that draft-ietf-mmusic-udptl-dtls-01 currently forbids other types of k= ey management protocols: o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. o If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects. I would suggest that you make the requirements related to certificate finge= rprints conditional, e.g. by adding a statement similar to this: In case DTLS is used with a pre-shared key ciphersuite (RFC 4279) the re= quirements related to certificate verification=20 and inclusion of certificate fingerprints do not apply. How the pre-shar= ed key is made available to the endpoints=20 is out of scope of this specification.=20 Regards, Oscar Ohlsson From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: den 21 november 2013 09:15 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 Hi fax lovers, We've submitted a new version (-01) of draft-ietf-mmusic-udptl-dtls. CHANGES: In addition to some editorial fixes, the changes, based on e-mail discussio= ns, are: - SDP offerer is allowed to assign an a=3Dsetup:active or a=3Dsetup:passive= value, in addition to the recommended a=3Dsetup:actpass=20 - The example for secure fax replacing audio stream in audio-only session a= dded=20 - Editor's note on the connection attribute resolved by prohibiting usage o= f the SDP connection attribute=20 OPEN ISSUES: There is still an open issue in section 4.2, which is more editorial than t= echnical. Comments and input is welcome. Regards, Christer From internet-drafts@ietf.org Mon Dec 2 15:13:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1541ADF46; Mon, 2 Dec 2013 15:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAWPTYGpoDO2; Mon, 2 Dec 2013 15:13:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A13E1ADF97; Mon, 2 Dec 2013 15:13:38 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131202231338.15762.62097.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2013 15:13:38 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-delayed-duplication-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:13:40 -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 : Delayed Duplication Attribute in the Session Description= Protocol Author(s) : Ali Begen Yiqun Cai Heidi Ou Filename : draft-ietf-mmusic-delayed-duplication-03.txt Pages : 11 Date : 2013-12-02 Abstract: A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-delayed-duplication-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-delayed-duplication-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bernard_aboba@hotmail.com Mon Dec 2 18:14:37 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116481AE00B for ; Mon, 2 Dec 2013 18:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufxBSbVc-nYf for ; Mon, 2 Dec 2013 18:14:35 -0800 (PST) Received: from blu0-omc1-s3.blu0.hotmail.com (blu0-omc1-s3.blu0.hotmail.com [65.55.116.14]) by ietfa.amsl.com (Postfix) with ESMTP id 892141ADFAD for ; Mon, 2 Dec 2013 18:14:35 -0800 (PST) Received: from BLU169-W50 ([65.55.116.7]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 18:14:33 -0800 X-TMN: [aWpbpCq3UnuBXxNSgexZra1yTqI8pswN5Pa9y3vudTY=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_0f31c3b4-696b-4482-a758-6954e2600409_" From: Bernard Aboba To: Bo Burman , Christer Holmberg , "mmusic@ietf.org" Date: Mon, 2 Dec 2013 18:14:32 -0800 Importance: Normal In-Reply-To: References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2013 02:14:33.0550 (UTC) FILETIME=[682DF6E0:01CEEFCD] Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 02:14:37 -0000 --_0f31c3b4-696b-4482-a758-6954e2600409_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bo Burman said:=20 =20 "Should a simulcast-capable endpoint be restricted to be a simulcast-sender= -only or a simulcast-receiver-only=2C or do we envision endpoints that are = capable of both sending and receiving simulcast? One example would be if si= mulcast streams are to be forwarded between different SFU (using Bernard=92= s terminology below). =20 If so and assuming that we define a new 5888-type simulcast grouping=2C do = we need separate groupings for send direction simulcast and receive directi= on simulcast=2C or is a=3Dsendonly and a=3Drecvonly information for simulca= st-grouped media blocks fully sufficient? =20 Also=2C I think the way to use this approach for simulcast in combination w= ith multiple separate media sources (like multiple cameras) or media sinks = (like multiple displays) would be pretty straightforward=3B just add one si= mulcast grouping per media source/sink." =20 [BA] In the case where parallel simulcast streams are being both sent and r= eceived (e.g. between SFUs)=2C there wouldn't be a need for a=3Dsendonly or= a=3Drecvonly lines=3B each m=3Dline would apply to both sending and recei= ving. So it seems like a single simulcast group would suffice. If you ha= ve multiple sources or sinks=2C then yes=2C I believe you would have one si= mulcast grouping per media source/sink. A simple SFU1-SFU2 exchange would l= ook like this:=20 =20 Offer:=20 =20 v=3D0 o=3DSFU1 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled SFU1 t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 a=3Dgroup:SC S1 S2 m=3Dvideo 49300 RTP/AVP 97 b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640=2Cy=3D360] a=3Dmid:S1 m=3Dvideo 49302 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320=2Cy=3D180] a=3Dmid:S2 =20 Answer:=20 =20 v=3D0 o=3DSFU2 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled SFU1 t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 a=3Dgroup:SC S1 S2 m=3Dvideo 48000 RTP/AVP 97 b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640=2Cy=3D360] a=3Dmid:S1=20 m=3Dvideo 48002 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320=2Cy=3D180] a=3Dmid:S2 =0A= =0A= =0A= =0A= =0A= =0A= = --_0f31c3b4-696b-4482-a758-6954e2600409_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Bo Burman said:
 =3B
"Should a simulca= st-capable endpoint be restricted to be a simulcast-sender-only or a simulc= ast-receiver-only=2C or do we envision endpoints that are capable of both s= ending and receiving simulcast? One example would be if simulcast streams a= re to be forwarded between different SFU (using Bernard=92s terminology bel= ow).
 =3B
If= so and assuming that we define a new 5888-type simulcast grouping=2C do we= need separate groupings for send direction simulcast and receive direction= simulcast=2C or is a=3Dsendonly and a=3Drecvonly information for simulcast= -grouped media blocks fully sufficient?
 =3B
Also=2C I think the way to use this approa= ch for simulcast in combination with multiple separate media sources (like = multiple cameras) or media sinks (like multiple displays) would be pretty s= traightforward=3B just add one simulcast grouping per media source/sink."
&n= bsp=3B
[BA] In = the case where parallel simulcast streams are being both sent and received = (e.g. between SFUs)=2C there wouldn't be a need for a=3Dsendonly or a=3Drec= vonly lines=3B =3B each m=3Dline would apply to both sending and receiv= ing. =3B So it seems like a single simulcast group would suffice. = =3B =3B If you have multiple sources or sinks=2C then yes=2C I believe = you would have one simulcast grouping per media source/sink. A simple SFU1-SFU2 exchan= ge would look like this:
 =3B
Offer:
 =3B
v=3D0
o=3DSFU1 2362969037 2362969040 IN IP4 192.0.= 2.156
s=3DSimulcast Enabled SFU1
t=3D0 0
c=3DIN IP4 192.0.2.156b=3DAS:665
a=3Dgroup:SC S1 S2
m=3Dvideo 49300 RTP/AVP 97
b=3DAS:5= 20
a=3Drtpmap:97 H264/90000
a=3Dfmtp:97 profile-level-id=3D42c01e
= a=3Dimageattr:97 send [x=3D640=2Cy=3D360]
a=3Dmid:S1
m=3Dvideo 49302 = RTP/AVP 98
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 profile-level-id=3D42= c01e
a=3Dimageattr:98 send [x=3D320=2Cy=3D180]
a=3Dmid:S2
<= span style=3D'font-family: "Calibri"=2C"sans-serif"=3B'> =3B
= Answer:  =3Bv=3D0
o=3DSFU= 2 823479283 1209384938 IN IP4 192.0.2.2
s=3DAnswer to Simulcast Enabled = SFU1
t=3D0 0
c=3DIN IP4 192.0.2.43
b=3DAS:665
a=3Dgroup:SC S1 S= 2
m=3Dvideo 48000 RTP/AVP 97
b=3DAS:520
a=3Drtpmap:97 H264/90000a=3Dfmtp:97 profile-level-id=3D42c01e
a=3Dimageattr:97 recv [x=3D640= =2Cy=3D360]
a=3Dmid:S1
m=3Dvideo 48002 RTP/AVP 98
a=3Drtpmap:98 H= 264/90000
a=3Dfmtp:98 profile-level-id=3D42c01e
a=3Dimageattr:98 recv= [x=3D320=2Cy=3D180]
a=3Dmid:S2
=0A= =0A= =0A= =0A= =0A= =0A=
= --_0f31c3b4-696b-4482-a758-6954e2600409_-- From bernard_aboba@hotmail.com Mon Dec 2 18:17:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD461AE00A for ; Mon, 2 Dec 2013 18:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.5 X-Spam-Level: ** X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t1jaMbqPW1U for ; Mon, 2 Dec 2013 18:17:20 -0800 (PST) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 922301ADFAD for ; Mon, 2 Dec 2013 18:17:20 -0800 (PST) Received: from BLU169-W72 ([65.55.116.73]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 18:17:18 -0800 X-TMN: [R2z7qRM1HIsK5sZSoAjjWRIKpX7Lya6HJaiyYrHSZR8=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b4a68e6f-80d7-4dbd-a249-63124a34aa4f_" From: Bernard Aboba To: Christer Holmberg , "mmusic@ietf.org" Date: Mon, 2 Dec 2013 18:17:17 -0800 Importance: Normal In-Reply-To: References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , , <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se>, MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2013 02:17:18.0274 (UTC) FILETIME=[CA5CDA20:01CEEFCD] Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 02:17:22 -0000 --_b4a68e6f-80d7-4dbd-a249-63124a34aa4f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer said:=20 =20 "If the answerer does NOT support simulcast=2C it will see an Offer with mu= ltiple uni-directional streams. The behavior is difficult to predict. So=2C= even with a mechanism based on grouping=2C the question is still: should t= he support of the simulcast feature be negotiated between the endpoints fir= st=2C before it is enabled? Most likely it would require 2 O/A transactions= ." =20 [BA] If the answerer does NOT support simulcast=2C it would not respond wit= h an a=3Dgroup:SC line=2C so the Offerer will know that simulcast is not su= pported. If the Answerer accepted more than one of the m=3D lines offered = by the Offerer=2C but didn't include an a=3Dgroup:SC line=2C then the Offer= er could send a modified offer in order to avoid confusion on the part of t= he Answerer. A similar scenario can occur in draft-westerlund-avtcore-rtp= -simulcast=2C since the Answerer may not understand the a=3Dsim-send-cap or= a=3Dsim-recv-cap lines. =20 =20 In an O/A exchange where both the Offerer and Answerer support simulcast=2C= the exchange would look like this:=20 =20 Offer:=20 =20 v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 a=3Dgroup:SC S1 S2 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640=2Cy=3D360] a=3Dmid:S1 m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320=2Cy=3D180] a=3Dmid:S2 m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]=20 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320=2Cy=3D180] a=3Dmid:S3 =20 Answer:=20 =20 v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 a=3Dgroup:SC S1 S2 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640=2Cy=3D360] a=3Dmid:S1=20 m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320=2Cy=3D180] a=3Dmid:S2 m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640=2Cy=3D360]=20 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 send [x=3D320=2Cy=3D180] a=3Dmid:S3 =0A= =0A= =0A= =0A= =0A= =0A= = --_b4a68e6f-80d7-4dbd-a249-63124a34aa4f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Christer said:
 =3B
"If the answerer does NOT support simulca= st=2C it will see an Offer with multiple uni-directional streams. The behav= ior is difficult to predict. So=2C even with a mechanism based on grouping=2C the qu= estion is still: should the support of the simulcast feature be negotiated = between the endpoints first=2C before it is enabled? Most likely it would r= equire 2 O/A transactions."
 =3B
[BA] If the answerer does NOT support simulcast=2C it = would not respond with an a=3Dgroup:SC line=2C so the Offerer will know tha= t simulcast is not supported. =3B If the Answerer accepted more than on= e of the m=3D lines offered by the Offerer=2C but didn't include an a=3Dgro= up:SC line=2C then the Offerer could send a modified offer in order to avoi= d confusion on the part of the Answerer. =3B =3B A similar scenario can occur = in draft-westerlund-avtcore-rtp-simulcast=2C since the Answerer may not und= erstand the a=3Dsim-send-cap or a=3Dsim-recv-cap lines. =3B
=  =3BIn an O/A exchange where bot= h the Offerer and Answerer support simulcast=2C the exchange would look lik= e this:
 =3B
Offer:
 =3B
v=3D0
o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
s=3DSim= ulcast Enabled Client
t=3D0 0
c=3DIN IP4 192.0.2.156
b=3DAS:665a=3Dgroup:SC S1 S2
m=3Dvideo 49300 RTP/AVP 97
a=3Dsendonly
b=3DAS= :520
a=3Drtpmap:97 H264/90000
a=3Dfmtp:97 profile-level-id=3D42c01ea=3Dimageattr:97 send [x=3D640=2Cy=3D360]
a=3Dmid:S1
m=3Dvideo 4930= 2 RTP/AVP 98
a=3Dsendonly
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 pro= file-level-id=3D42c01e
a=3Dimageattr:98 send [x=3D320=2Cy=3D180]
a=3D= mid:S2
m=3Dvideo 49304 RTP/AVP 100 99
a=3Drecvonly
a=3Drtpmap:100 = H264/90000
a=3Dfmtp:100 profile-level-id=3D42c01e
a=3Dimageattr:100 r= ecv [x=3D640=2Cy=3D360]
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 profile= -level-id=3D42c01e
a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]
a=3Dmid:= S3
 =3B
Answ= er:
 =3B
v= =3D0
o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
s=3DAnswer to S= imulcast Enabled Client
t=3D0 0
c=3DIN IP4 192.0.2.43
b=3DAS:665a=3Dgroup:SC S1 S2
m=3Dvideo 48000 RTP/AVP 97
a=3Drecvonly
b=3DA= S:520
a=3Drtpmap:97 H264/90000
a=3Dfmtp:97 profile-level-id=3D42c01e<= br>a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]
a=3Dmid:S1
m=3Dvideo 48= 002 RTP/AVP 98
a=3Drecvonly
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 p= rofile-level-id=3D42c01e
a=3Dimageattr:98 recv [x=3D320=2Cy=3D180]
a= =3Dmid:S2
m=3Dvideo 48004 RTP/AVP 100 99
a=3Dsendonly
a=3Drtpmap:1= 00 H264/90000
a=3Dfmtp:100 profile-level-id=3D42c01e
a=3Dimageattr:10= 0 send [x=3D640=2Cy=3D360]
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 prof= ile-level-id=3D42c01e
a=3Dimageattr:99 send [x=3D320=2Cy=3D180]
a=3Dm= id:S3
=0A= =0A= =0A= =0A= =0A= =0A=
= --_b4a68e6f-80d7-4dbd-a249-63124a34aa4f_-- From wwwrun@rfc-editor.org Tue Dec 3 00:44:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7451AE08E; Tue, 3 Dec 2013 00:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrEG74WUOCo5; Tue, 3 Dec 2013 00:44:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E215D1AE094; Tue, 3 Dec 2013 00:44:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 745F579E001; Tue, 3 Dec 2013 00:43:48 -0800 (PST) To: Jorgen.Axell@ericsson.com, jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu From: RFC Errata System Message-Id: <20131203084348.745F579E001@rfc-editor.org> Date: Tue, 3 Dec 2013 00:43:48 -0800 (PST) Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org, gonzalo.camarillo@ericsson.com, iesg@ietf.org Subject: [MMUSIC] [Errata Verified] RFC3264 (3818) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:44:22 -0000 The following errata report has been verified for RFC3264, "An Offer/Answer Model with Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3264&eid=3818 -------------------------------------- Status: Verified Type: Technical Reported by: Jörgen Axell Date Reported: 2013-12-02 Verified by: Gonzalo Camarillo (IESG) Section: 4 Original Text ------------- The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). Corrected Text -------------- The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the offer is rejected, the session reverts to the state prior to the offer (which may be absence of a session). Notes ----- You can't reject an answer. When the answer is received the SDP negotiation is completed. -------------------------------------- RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02) -------------------------------------- Title : An Offer/Answer Model with Session Description Protocol (SDP) Publication Date : June 2002 Author(s) : J. Rosenberg, H. Schulzrinne Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From oscar.ohlsson@ericsson.com Tue Dec 3 01:22:13 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E071AE0E4 for ; Tue, 3 Dec 2013 01:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxT5_LnFRY8y for ; Tue, 3 Dec 2013 01:22:11 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id C8A241AE0DC for ; Tue, 3 Dec 2013 01:22:10 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-78-529da2bf1182 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E6.77.27941.FB2AD925; Tue, 3 Dec 2013 10:22:07 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.247]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 10:22:06 +0100 From: Oscar Ohlsson To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Thread-Index: Ac7mkSk0zo3yfrWATZqATJzetabOTAAyKbLgAg8wB0AAHEjjEA== Date: Tue, 3 Dec 2013 09:22:06 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C54A8AC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C566971@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C566971@ESESSMB209.ericsson.se> Accept-Language: sv-SE, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvre7+RXODDA51G1hMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGa82LWYpmCNbMfHeM5YGxk3iXYycHBICJhITL2xjhrDFJC7c W8/WxcjFISRwhFGi+18jM4SzmFFi4flbbCBVbAIGErfun2QBsUUEYiW+rnvPBGILCzhIzDy9 kAki7ijxpHUtO4TtJHGo9xcriM0ioCKxYdMisDm8Ar4SXy4vAKsXErjKKNH5qwDE5hTwk/jU thZsPqOArMT97/fAbGYBcYlbT+YzQVwqILFkz3moq0UlXj7+BzSfA8hWlFjeLwdRridxY+oU NghbW2LZwtfMEGsFJU7OfMIygVF0FpKps5C0zELSMgtJywJGllWMHMWpxUm56UYGmxiBgX9w y2+LHYyX/9ocYpTmYFES5/341jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PD55dXZ6cF nXjxNPdVaWu89A+1gGpVp8ab71dtspi0/+nbfVZp+w7K3/+wbn7H1Sjx0jVhrCvVtv1NfP7g nMmiFZ+vf5a+89h7Y9i1xK2xC+fl/tl0859tZVZBi96EtqePZM/zTFqfb6Rosbh7CX/z5Hs7 FftfqE+a3JO5+Hr+LrE+NsbDIt++KbEUZyQaajEXFScCAC0PAh1KAgAA Subject: Re: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:22:13 -0000 Hi Christer I'm fine with your proposal. Regards, Oscar -----Original Message----- From: Christer Holmberg=20 Sent: den 2 december 2013 20:44 To: Oscar Ohlsson; mmusic@ietf.org Subject: VS: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Hi Oscar, In section 3.1, I suggest to modify/replace the third, fourth and fifth bul= lets with the 2 following bullets: "o If the endpoint supports, and is willing to use, a ciphersuite with an= associated certificate, it MUST include an SDP fingerprint attribute [RFC4572] in the SDP. o If a ciphersuite with an associated certificate is selected during the = DTLS handshake, the certificate=20 received during the DTLS handshake MUST match the fingerprint received in the SDP fingerprint attribute. If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects." Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Oscar Ohlsson=20 L=E4hetetty: 22. marraskuuta 2013 11:19 Vastaanottaja: Christer Holmberg; mmusic@ietf.org Aihe: RE: Draft new version: draft-ietf-mmusic-udptl-dtls-01 Hi, I have a comment on the usage of the fingerprint attribute in draft-ietf-mm= usic-udptl-dtls-01. In future versions of 3GPP TS 33.328 we would like to u= se UDPTL-DTLS in combination with MIKEY-TICKET. In that case there is no e= xchange of certificate fingerprints; instead the offerer and answerer negot= iates a secret key over SDP and then runs a DTLS-PSK handshake. The problem= is that draft-ietf-mmusic-udptl-dtls-01 currently forbids other types of k= ey management protocols: o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. o If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side's fingerprint has been received before establishing the connection; however, this may have undesirable latency effects. I would suggest that you make the requirements related to certificate finge= rprints conditional, e.g. by adding a statement similar to this: In case DTLS is used with a pre-shared key ciphersuite (RFC 4279) the re= quirements related to certificate verification=20 and inclusion of certificate fingerprints do not apply. How the pre-shar= ed key is made available to the endpoints=20 is out of scope of this specification.=20 Regards, Oscar Ohlsson From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: den 21 november 2013 09:15 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-01 Hi fax lovers, We've submitted a new version (-01) of draft-ietf-mmusic-udptl-dtls. CHANGES: In addition to some editorial fixes, the changes, based on e-mail discussio= ns, are: - SDP offerer is allowed to assign an a=3Dsetup:active or a=3Dsetup:passive= value, in addition to the recommended a=3Dsetup:actpass=20 - The example for secure fax replacing audio stream in audio-only session a= dded=20 - Editor's note on the connection attribute resolved by prohibiting usage o= f the SDP connection attribute=20 OPEN ISSUES: There is still an open issue in section 4.2, which is more editorial than t= echnical. Comments and input is welcome. Regards, Christer From christer.holmberg@ericsson.com Tue Dec 3 01:56:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334D1AE0E1 for ; Tue, 3 Dec 2013 01:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEBg1VAqomOh for ; Tue, 3 Dec 2013 01:55:57 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4787E1AE0E2 for ; Tue, 3 Dec 2013 01:55:56 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-4a-529daaa8841c Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D9.D5.23787.8AAAD925; Tue, 3 Dec 2013 10:55:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 10:55:52 +0100 From: Christer Holmberg To: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Thread-Index: AQHO7HThG+X2tMt6m0yojy1/V4PWfZo9dplHgACk/YCAApPVgIAAFcSQgADH6QCAALTY8A== Date: Tue, 3 Dec 2013 09:55:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C56738F@ESESSMB209.ericsson.se> References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , , <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C56738FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre7KVXODDGbu5rDYv+Qys8XU5Y9Z HJg8HvecYfNYsuQnUwBTFJdNSmpOZllqkb5dAlfGkrU/WQueHGCqWH5lBmMD44bZTF2MnBwS AiYSR9rfsEDYYhIX7q1n62Lk4hASOMQo8fZ0DxOEs4hRYteb2UBVHBxsAhYS3f+0QRpEBEIk 5qzYywQSFhbwkJh63h0i7CnxcmcLK4QdJnFn+i5GEJtFQEXi3MTj7CA2r4CvxJWv61khxt9i knj97i9YEaeAtUTH7V9sIDYj0EHfT60BO5RZQFzi1pP5UEcLSCzZc54ZwhaVePn4HyuErShx dfpysHuYBfIl/k4ygtglKHFy5hOWCYwis5BMmoVQNQtJFUSJjsSC3Z/YIGxtiWULXzPD2GcO PGZCFl/AyL6KkT03MTMnvdxwEyMwdg5u+a27g/HUOZFDjNIcLErivB/eOgcJCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYBQRn3V3mXmA/Mx9EwOe9/x3Wpv7fKfNMoe3CjfCVe7PsS7M1bpp dNpRoLae8f+jjsX5CmfWtR9yETh6s+8fv1LKi8KuExunZGUubrD/KFg57/em2ZbmDw4nTGrV 27n0Ra2jvKKZ4Rm2z6t6lj9JK+MrODZj44adQasCp06wjZus8rt7rRBbSbYSS3FGoqEWc1Fx IgCu1INoawIAAA== Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 09:56:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C56738FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >Christer said: > >"If the answerer does NOT support simulcast, it will see an Offer with mul= tiple uni-directional streams. The behavior is difficult to predict. > >So, even with a mechanism based on grouping, the question is still: should= the support of the simulcast feature be negotiated between the endpoints f= irst, before it is enabled? Most likely it would require 2 O/A transactions= ." > >[BA] If the answerer does NOT support simulcast, it would not respond with= an a=3Dgroup:SC line, so the Offerer will know that simulcast is not suppo= rted. If the Answerer accepted more than one of the m=3D lines offered by = the Offerer, but >didn't include an a=3Dgroup:SC line, then the Offerer cou= ld send a modified offer in order to avoid confusion on the part of the Ans= werer. A similar scenario can occur in draft-westerlund-avtcore-rtp-simul= cast, since the Answerer may not >understand the a=3Dsim-send-cap or a=3Dsi= m-recv-cap lines. Sure. My comment was on the usage of the bundle mechanism in general, not a= comparison with draft-westerlund :) Regards, Christer In an O/A exchange where both the Offerer and Answerer support simulcast, t= he exchange would look like this: Offer: v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 a=3Dgroup:SC S1 S2 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640,y=3D360] a=3Dmid:S1 m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320,y=3D180] a=3Dmid:S2 m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320,y=3D180] a=3Dmid:S3 Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 a=3Dgroup:SC S1 S2 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640,y=3D360] a=3Dmid:S1 m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320,y=3D180] a=3Dmid:S2 m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 send [x=3D320,y=3D180] a=3Dmid:S3 From: Bo Burman Sent: 2. joulukuuta 2013 12:52 To: Bernard Aboba; Christer Holmberg; mmusic@ietf.org Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Should a simulcast-capable endpoint be restricted to be a simulcast-sender-= only or a simulcast-receiver-only, or do we envision endpoints that are cap= able of both sending and receiving simulcast? One example would be if simul= cast streams are to be forwarded between different SFU (using Bernard's ter= minology below). If so and assuming that we define a new 5888-type simulcast grouping, do we= need separate groupings for send direction simulcast and receive direction= simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-g= rouped media blocks fully sufficient? Also, I think the way to use this approach for simulcast in combination wit= h multiple separate media sources (like multiple cameras) or media sinks (l= ike multiple displays) would be pretty straightforward; just add one simulc= ast grouping per media source/sink. From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 30 november 2013 20:31 To: Christer Holmberg; mmusic@ietf.org Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast Christer asked: "In your example, how does the answerer know that the offered m- lines are = for simulcast? As far as O/A is concerned, it could just be a number of com= pletely separate (different content etc) uni-directional streams." [BA] The most obvious way would be grouping. Looking at RFC 5888/5583, it = doesn't appear that either FID or DDP grouping would apply to simulcast. = So perhaps a new group type would be needed. Bernard Aboba >= wrote: At IETF 88, a number of participants (including myself) expressed the view= that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below, I= will attempt to explain how simulcast might be negotiated in a simplified = Offer/Answer exchange based on the principles of Unified Plan. Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU), while receiving one among a se= t of potential streams from the SFU, with the SFU being able to switch betw= een the streams that it is sending to the endpoint without signaling. RFC = 3264 describes how to handle each of these situations. With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 = states the following: If the offerer wishes to only send media on a stream to its peer, it MUST m= ark the stream as sendonly with the "a=3Dsendonly" attribute. We refer to= a stream as being marked with a certain direction if a direction attribute= was present as either a media stream attribute or a session attribute. For= sendonly RTP streams, the payload type numbers indicate the value of the p= ayload type field in RTP packet the offerer is planning to send for that co= dec... In all cases, the formats in the "m=3D" line MUST be listed in orde= r of preference, with the first format listed being preferred. In this cas= e, preferred means that the recipient of the offer SHOULD use the format wi= th the highest preference that is acceptable to it. If multiple media strea= ms of different types are present, it means that the offerer wishes to use = those streams at the same time. A typical case is an audio and a video str= eam as part of a videoconference. If multiple media streams of the same type are present in an offer, it mea= ns that the offerer wishes to send (and/or receive) multiple streams of tha= t type at the same time... Each stream MAY use different encodings. With respect to receiving one among a set of potential streams, here is wha= t RFC 3264 Section 5.1 says: If the offerer wishes to only receive media from its peer, it MUST mark the= stream as recvonly... If multiple formats are listed, it means that the of= ferer is capable of making use of any of those formats during the session. = In other words, the answerer MAY change formats in the middle of the sessi= on, making use of any of the formats listed, without sending a new offer. = For a sendonly stream, the offer SHOULD indicate those formats the offerer = is willing to send for this stream. For a recvonly stream, the offer SHOU= LD indicate those formats the offerer is willing to receive for this stream= .... For recvonly RTP streams, the payload type numbers indicate the value of th= e payload type field in RTP packets the offerer is expecting to receive fo= r that codec. Based on the above: 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent, each including an a=3Dsendonly line. = The offer would also include a single m=3Dline (with a=3Drecvonly) describ= ing the streams that the endpoint is prepared to receive, each with their o= wn payload type. 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition, the answer would include a single m=3Dline (with a= =3Dsendonly) indicating the streams from among those proposed by the endpoi= nt that the SFU is prepared to send. The SFU can then switch between those= streams without having to signal the endpoint. Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send, an Answerer can indicate how man= y streams it is prepared to receive (might only be one if simulcast isn't s= upported). Similarly, an Answerer can select those simulcast streams it i= s prepared to send (might only be one if simulcast isn't supported). Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640,y=3D360] m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320,y=3D180] m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320,y=3D180] Example Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Unified Plan Client t=3D0 0 c=3DIN IP4 192.0.2.43 b=3DAS:665 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520 a=3Drtpmap:97 H264/90000 a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640,y=3D360] m=3Dvideo 48002 RTP/AVP 98 a=3Drecvonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320,y=3D180] m=3Dvideo 48004 RTP/AVP 100 99 a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640,y=3D360] a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D320,y=3D180] --_000_7594FB04B1934943A5C02806D1A2204B1C56738FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

>Christer said:

> 

>"If the answerer does NOT support simulcast, it will see = an Offer with multiple uni-directional streams. The behavior is difficult to predict.=

> <= /span>

>So, even with a mechanism based on grouping, the question is s= till: should the support of the simulcast feature be negotiated between the endp= oints first, before it is enabled? Most likely it would require 2 O/A trans= actions."

> 

>[BA] If the answerer does NOT support simulcast, it would not = respond with an a=3Dgroup:SC line, so the Offerer will know that simulcast is not = supported.  If the Answerer accepted more than one of the m= =3D lines offered by the Offerer, but >did= n't include an a=3Dgroup:SC line, then the Offerer could send a modified of= fer in order to avoid confusion on the part of the Answerer.   A simila= r scenario can occur in draft-westerlund-avtcore-rtp-simulcast, since = the Answerer may not >und= erstand the a=3Dsim-send-cap or a=3Dsim-recv-cap lines.

 <= /p>

Sure. My comment was on the u= sage of the bundle mechanism in general, not a comparison with draft-wester= lund :)

 

Regards,

 

Christer

 <= /p>

 <= /p>

 

In an O/A exchange where = both the Offerer and Answerer support simulcast, the exchange would look li= ke this:

 <= /p>

Offer:

v=3D0
o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
s=3DSimulcast Enabled Client
t=3D0 0
c=3DIN IP4 192.0.2.156
b=3DAS:665

a=3Dgroup:SC= S1 S2
m=3Dvideo 49300 RTP/AVP 97
a=3Dsendonly
b=3DAS:520
a=3Drtpmap:97 H264/90000

a=3Dfmtp:97 p= rofile-level-id=3D42c01e
a=3Dimageattr:97 send [x=3D640,y=3D360]

a=3Dmid:S1 m=3Dvideo 49302 RTP/AVP 98
a=3Dsendonly
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 profile-level-id=3D42c01e
a=3Dimageattr:98 send [x=3D320,y=3D180]

a=3Dmid:S2 m=3Dvideo 49304 RTP/AVP 100 99
a=3Drecvonly
a=3Drtpmap:100 H264/90000
a=3Dfmtp:100 profile-level-id=3D42c01e
a=3Dimageattr:100 recv [x=3D640,y=3D360]
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 profile-level-id=3D42c01e
a=3Dimageattr:99 recv [x=3D320,y=3D180]

a=3Dmid:S3

Answer:

v=3D0
o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
s=3DAnswer to Simulcast Enabled Client

t=3D0 0
c=3DIN IP4 192.0.2.43

b=3DAS:665

a=3Dgroup:SC= S1 S2
m=3Dvideo 48000 RTP/AVP 97
a=3Drecvonly
b=3DAS:520

a=3Drtpmap:97= H264/90000

a=3Dfmtp:97 p= rofile-level-id=3D42c01e
a=3Dimageattr:97 recv [x=3D640,y=3D360]

a=3Dmid:S1

m=3Dvideo 480= 02 RTP/AVP 98
a=3Drecvonly
a=3Drtpmap:98 H264/90000

a=3Dfmtp:98 p= rofile-level-id=3D42c01e
a=3Dimageattr:98 recv [x=3D320,y=3D180]

a=3Dmid:S2 m=3Dvideo 48004 RTP/AVP 100 99=

a=3Dsendonly<= br> a=3Drtpmap:100 H264/90000
a=3Dfmtp:100 profile-level-id=3D42c01e
a=3Dimageattr:100 send [x=3D640,y=3D360]
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 profile-level-id=3D42c01e
a=3Dimageattr:99 send [x=3D320,y=3D180]

a=3Dmid:S3

 

 

 

 

 

From: Bo Burma= n
Sent: 2. joulukuuta 2013 12:52
To: Bernard Aboba; Christer Holmberg; mmusic@ietf.org
Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Should a simulcast-capabl= e endpoint be restricted to be a simulcast-sender-only or a simulcast-recei= ver-only, or do we envision endpoints that are capable of both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard’s term= inology below).

 

If so and assuming that w= e define a new 5888-type simulcast grouping, do we need separate groupings = for send direction simulcast and receive direction simulcast, or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?

 

Also, I think the way to = use this approach for simulcast in combination with multiple separate media= sources (like multiple cameras) or media sinks (like multiple displays) would be pretty straightforward; just add one simulcast grouping= per media source/sink.

 

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 30 november 2013 20:31
To: Christer Holmberg; mmusic@iet= f.org
Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

 

Christer asked:
"In your example, how =
does the answerer know that the offered m- lines are for simulcast? As far =
as O/A is concerned, it could just be a number of completely separate (diff=
erent content etc) uni-directional streams."
[BA] The most obvious way w=
ould be grouping.  Looking at RFC 5888/5583, it doesn't appear that ei=
ther FID or DDP grouping would apply to simulcast.   So perhaps a=
 new group type would be needed. 
 

 


Bernard Aboba <=
bernard_aboba@hotmail.com> wrote:


 






At IETF 88, a number of  participants (including my=
self) expressed the view that draft-westerlund-avtcore-rtp-simulcast was to=
o complicated.  Below, I will attempt to explain how simulcast
 might be negotiated in a simplified Offer/Answer exchange based =
on the principles of Unified Plan.


 

Typically in simulcast we have an endpoint sending multiple streams in=
 parallel to the Selective Forwarding Unit (SFU), while receiving one =
among a set of potential streams from the SFU, with the SFU being able to s=
witch between the streams that it is sending
 to the endpoint without signaling.  RFC 3264 describes how to ha=
ndle each of these situations.


 

With respect to sending multiple streams in parallel, RFC 3264 Section 5.1 =
states the following:


 


If the offerer wishes to only send media on a stream to =
its peer, it MUST mark the stream as sendonly with the "a=3Dsendo=
nly" attribute.  We  refer to a stream as being marked with =
a certain
 direction if a direction attribute was present as either a media stre=
am attribute or a session attribute. For sendonly RTP streams, the pay=
load type numbers indicate the value of the payload type field in RTP packe=
t the offerer is planning to send for that
 codec...  In all cases, the formats in the "m=3D" line MUST=
 be listed in order of preference, with the first format listed being =
preferred.  In this case, preferred means that the recipient of t=
he offer SHOULD use the format with the highest preference that
 is acceptable to it. If multiple media streams of different types are pres=
ent, it means that the offerer wishes to use those streams at the same time=
.  A typical case is an audio and a video stream as part of a vid=
eoconference.

 

If multiple media streams of the same type are present in an offer,  i=
t means that the offerer wishes to send (and/or receive) multiple streams o=
f that type at the same time...  Each stream MAY use different en=
codings.



 

With respect to receiving one among a set of potential streams, here is wha=
t RFC 3264 Section 5.1 says:


 


If the offerer wishes to only receive media from its pee=
r, it MUST mark the stream as recvonly... If multiple formats are listed, i=
t means that the offerer is capable of making use of any
 of those formats during the session.  In other words, the answer=
er MAY change formats in the middle of the session, making use of any of th=
e formats listed, without sending a new offer.  For a sendonly st=
ream, the offer SHOULD indicate those formats the offerer
 is willing to send for this stream.  For a recvonly stream,  the=
 offer SHOULD indicate those formats the offerer is willing to receive for =
this stream....

   

For recvonly RTP streams, the payload type numbers indicate the value of th=
e payload type field in RTP packets the offerer is expecting to  recei=
ve for that codec. 



 

Based on the above:

 

1. An offer from an endpoint to an SFU would include an m=3Dline for each p=
otential simulcast stream to be sent, each including an a=3Dsendonly line.&=
nbsp; The offer would also include a single m=3Dline (with a=3Drecvonly) de=
scribing the streams that the endpoint is prepared
 to receive, each with their own payload type. 

 

2. An answer from an SFU to an endpoint would accept or reject each of the =
simulcast streams that the endpoint is proposing to send (with an a=3Drecvo=
nly line).  In addition, the answer would include a single m=3Dline (w=
ith a=3Dsendonly) indicating the streams from
 among those proposed by the endpoint that the SFU is prepared to send.&nbs=
p; The SFU can then switch between those streams without having to signal t=
he endpoint.


 

Since it is possible for the Answerer to accept/reject each of the pro=
posed streams the Offerer is proposing to send, an Answerer can indica=
te how many streams it is prepared to receive (might only be one if simulca=
st isn't supported).   Similarly, an Answerer
 can select those simulcast streams it is prepared to send (might only be o=
ne if simulcast isn't supported).


 

Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): 

 

   v=3D0

   o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156

   s=3DSimulcast Enabled Unified Plan Client

   t=3D0 0

   c=3DIN IP4 192.0.2.156

   b=3DAS:665

   m=3Dvideo 49300 RTP/AVP 97

   a=3Dsendonly

   b=3DAS:520

   a=3Drtpmap:97 H264/90000

   a=3Dfmtp:97 profile-level-id=3D42c01e

   a=3Dimageattr:97 send [x=3D640,y=3D360] 

   m=3Dvideo 49302 RTP/AVP 98

   a=3Dsendonly

   a=3Drtpmap:98 H264/90000

   a=3Dfmtp:98 profile-level-id=3D42c01e

   a=3Dimageattr:98 send [x=3D320,y=3D180]

   m=3Dvideo 49304 RTP/AVP 100 99

   a=3Drecvonly

   a=3Drtpmap:100 H264/90000

   a=3Dfmtp:100 profile-level-id=3D42c01e

   a=3Dimageattr:100 recv [x=3D640,y=3D360] 

   a=3Drtpmap:99 H264/90000

   a=3Dfmtp:99 profile-level-id=3D42c01e

   a=3Dimageattr:99 recv [x=3D320,y=3D180]

 

 

Example Answer: 

 

   v=3D0

   o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2

   s=3DAnswer to Simulcast Enabled Unified Plan Client

   t=3D0 0

   c=3DIN IP4 192.0.2.43

   b=3DAS:665

   m=3Dvideo 48000 RTP/AVP 97

   a=3Drecvonly

   b=3DAS:520

   a=3Drtpmap:97 H264/90000

   a=3Dfmtp:97 profile-level-id=3D42c01e

   a=3Dimageattr:97 recv [x=3D640,y=3D360] 

   m=3Dvideo 48002 RTP/AVP 98

   a=3Drecvonly

   a=3Drtpmap:98 H264/90000

   a=3Dfmtp:98 profile-level-id=3D42c01e

   a=3Dimageattr:98 recv [x=3D320,y=3D180]

   m=3Dvideo 48004 RTP/AVP 100 99

   a=3Dsendonly

   a=3Drtpmap:100 H264/90000

   a=3Dfmtp:100 profile-level-id=3D42c01e

   a=3Dimageattr:100 send [x=3D640,y=3D360] 

   a=3Drtpmap:99 H264/90000

   a=3Dfmtp:99 profile-level-id=3D42c01e

   a=3Dimageattr:100 send [x=3D320,y=3D180] 

 
--_000_7594FB04B1934943A5C02806D1A2204B1C56738FESESSMB209erics_-- From sm@resistor.net Tue Dec 3 02:00:04 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB51AE0F5 for ; Tue, 3 Dec 2013 02:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrQeUk4XYErx for ; Tue, 3 Dec 2013 02:00:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 302741AE0F4 for ; Tue, 3 Dec 2013 02:00:03 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB39xlk9009808; Tue, 3 Dec 2013 01:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386064795; bh=0hMhyf4AFNbHpkh+4CzQ/5WMQlPzDHdDGkqV2VrtMRo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gV400h5YnfdTF1UtKv3sylg438dhBmcT5ecnY+PDQ4NIh9Ip4H1C4SLlu5VQS/Hfy n2FpLVCJvz4ShDk5ozwQroU7HUgOJtVPcmHr4AN03yHaRDgzv6ZdcxMfharTzT16oK YgF+M0DfgkixkslOc/gT65nW4oLup7JLySNwP0P8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386064795; i=@resistor.net; bh=0hMhyf4AFNbHpkh+4CzQ/5WMQlPzDHdDGkqV2VrtMRo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lwLAGC9Cgv/jwBmdgcr5fJtQr/XgmwK2zgUudtG6g9hUXdee0i2158/wAaFB3AaJX hrawBVFSfpLZ5gUEbfmebsaH4xMBurWoVuXqbH3GixbYySTwrq2fA05OAgnh4T60el 6pc/fbgfvuV1zXmJYNd10s9kDFc5gZ09FYrHJR/4= Message-Id: <6.2.5.6.2.20131203010105.0db5d630@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Dec 2013 01:10:28 -0800 To: Stephen Casner From: SM In-Reply-To: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <016b01ceed2f$0be29e90$23a7dbb0$@co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Flemming Andreasen , Ari Kerdnen , mmusic@ietf.org Subject: Re: [MMUSIC] RFC 4856 is in the correct RFC category - Errata query? [was RE: Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:00:04 -0000 Hi Stephen, At 08:52 02-12-2013, Stephen Casner wrote: >I believe the status of RFC 4856 is correct. It updates RFC 3555 to >define and register the media types for the RTP profile RFC 3551. >What other status would be more appropriate for that ? There was an assumption that the status chosen for some previous RFC is correct. The problem might have been with RFC 3555. It is better not to look at the details of those old RFCs too closely. :-) >RFC 4856 is not a specification of any payload format; it refers to >other documents that specify the payload formats (and SDP usage). It >only specifies how a MIME media type is used to refer to a payload >format that carries an encoding. RFC 4856 refers to RFC 3551 for the >payload format of G723 and G729, which in turn refers to the ITU >Recommendations. My short response would be yes. Please note that I did not verify all the details. Regards, -sm From sm@resistor.net Tue Dec 3 02:00:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4BE1AE0FD for ; Tue, 3 Dec 2013 02:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl2Hiu2glsq2 for ; Tue, 3 Dec 2013 02:00:07 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF891AE0FC for ; Tue, 3 Dec 2013 02:00:07 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB39xlkB009808; Tue, 3 Dec 2013 01:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386064800; bh=VwGW5lsOKDGYul4ZHEVSmZMb7rO+6Avnz5XAbezdbwc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ym8bUZyH2c3DQxDZNUzw7Xe6aDPlASSMAqYxq+foFU0os4ubSipnTCeTUi0Luw+zi QdlBH0X0ayn2pQ2632uNeKILkPWyB4r/19Z/oWHL49wzAaiQYwPPEI+t4VyzxDZ5b5 HI78Ke2mHcBfJZy9j9HwqbRZtqlA8c2KFuuGa6EU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386064800; i=@resistor.net; bh=VwGW5lsOKDGYul4ZHEVSmZMb7rO+6Avnz5XAbezdbwc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gbYGpMJGxyKnnU+2oXYgJin5m9wpho2kcHqxdFI+bBilli6s2aWg9aGXM7xpYsVKo tujRC8Vn0SKVo9MxHgXZhp2sFZUQaMyalMovvoAGP2UjVWm7GdaHfNdwVRG7ai+ZIt TgPkJPMzXWNtn0AeZBG4SYh48m2/vGgq7OFZyF/8= Message-Id: <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Dec 2013 01:13:41 -0800 To: "Muthu Arul Mozhi Perumal (mperumal)" , Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Flemming Andreasen \(fandreas\)" , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:00:08 -0000 Hi Muthu, At 05:51 02-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: >|Media type registrations are usually published as Informational RFCs. >|I suggest publishing draft-ietf-mmusic-sdp-g723-g729-04 as an >Information RFC. > >Registered audio media types are listed here: >http://www.iana.org/assignments/media-types/audio > >As you can see most of them are described in Standards Track RFCs, >so your observation is incorrect. I was referring to media type registrations for IANA action. That is different from the intended status. Regards, -sm From sm@resistor.net Tue Dec 3 02:00:11 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC4C1AE0F4 for ; Tue, 3 Dec 2013 02:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waSaVYXi4bNr for ; Tue, 3 Dec 2013 02:00:10 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5BC1AE101 for ; Tue, 3 Dec 2013 02:00:10 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB39xlkD009808; Tue, 3 Dec 2013 02:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386064805; bh=wtD5rJOvCrFtCbnQsK25hhF8twFME053CbnZvCAT8wc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NKVSyf2nNX7I3AYSLcCVuo3X/73FOklOqy3MdP2oJYthV8X2o1TsX2EkMkDPFFn+G J7ARi65Gn1WDsOE5SUp4XUgkZQjCdssUNvESa3dTREg/NDAEQ/8xCUXPSd+pdkqSac tlnaof2D1zT0GINZob1TKmzfUlXHHwyM6cTaC1qc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386064805; i=@resistor.net; bh=wtD5rJOvCrFtCbnQsK25hhF8twFME053CbnZvCAT8wc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K2NEbLPqg8XdOEBV7XsKwaXyIH9tj+NqL9gXa9dRJRgQiKScB87RMj/sXYOjk6I9t jNAKRGLx6A1ycRG7Rl4ncpVczmblbyrXZJoCkwKiwyqPNGYOpZUk8SuQ3DT90NY4AF xhYJdf+MHL1HulYeXmhyk5cFvT+CBPiuawfRwFrA= Message-Id: <6.2.5.6.2.20131203011347.0db5d4e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Dec 2013 01:44:32 -0800 To: Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: <529CA719.3090007@ericsson.com> References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <529CA719.3090007@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Flemming Andreasen , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 10:00:11 -0000 Hi Ari, At 07:28 02-12-2013, Ari Ker=E4nen wrote: >As Partha & Muthu already mentioned, there was=20 >discussion and a consensus call on the type of=20 >the document and the consensus was that PS is=20 >the correct type. Admittedly the proto write-up=20 >could have been a bit more elaborate on that. Thanks for the response. In my humble opinion it=20 is not worth the effort to look into the details=20 of the process if that can be avoided. Regards, -sm=20 From bernard_aboba@hotmail.com Mon Dec 2 16:05:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BD21ADFAA for ; Mon, 2 Dec 2013 16:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M140Ssn8h631 for ; Mon, 2 Dec 2013 16:05:37 -0800 (PST) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7FA1ADF9A for ; Mon, 2 Dec 2013 16:05:37 -0800 (PST) Received: from BLU169-W133 ([65.55.116.73]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 16:05:35 -0800 X-TMN: [kespt+1XeF2Kqqr4jo0EE2kemYFQ1Y4MgyN4UThv0W4=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_43b58fb2-e67a-4045-8b31-6a41ccc1daea_" From: Bernard Aboba To: Christer Holmberg , "mmusic@ietf.org" Date: Mon, 2 Dec 2013 16:05:34 -0800 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se> References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , , <7594FB04B1934943A5C02806D1A2204B1C5659AA@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2013 00:05:35.0091 (UTC) FILETIME=[63B2D430:01CEEFBB] X-Mailman-Approved-At: Tue, 03 Dec 2013 05:13:06 -0800 Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:05:41 -0000 --_43b58fb2-e67a-4045-8b31-6a41ccc1daea_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Christer said:=20 =0A= =0A= "If the answerer does NOT support simulcast=2C it will see an Offer with mu= ltiple uni-directional streams. The behavior is difficult to predict.=0A= =0A= So=2C even with a mechanism based on grouping=2C the question is still: sho= uld the support of the simulcast feature be negotiated between the endpoint= s first=2C before=0A= it is enabled? Most likely it would require 2 O/A transactions." [BA] If t= he answerer does NOT support simulcast=2C it would not respond with an a=3D= group:SC line=2C so the Offerer will know that simulcast is not supported. = If the Answerer accepted more than one of the m=3D lines offered by the Of= ferer=2C but didn't include an a=3Dgroup:SC line=2C then the Offerer could = send a modified offer in order to avoid confusion on the part of the Answer= er. A similar scenario can occur in draft-westerlund-avtcore-rtp-simulcas= t=2C since the Answerer may not understand the a=3Dsim-send-cap or a=3Dsim-= recv-cap lines. In an O/A exchange where both the Offerer and Answerer sup= port simulcast=2C the exchange would look like this: Offer: v=3D0 o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 s=3DSimulcast Enabled Client t=3D0 0 c=3DIN IP4 192.0.2.156 b=3DAS:665a=3Dgroup:SC S1 S2 m=3Dvideo 49300 RTP/AVP 97 a=3Dsendonly b=3DAS:520 a=3Drtpmap:97 H264/90000a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 send [x=3D640=2Cy=3D360]a=3Dmid:S1 m=3Dvideo 49302 RTP/AVP 98 a=3Dsendonly a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 send [x=3D320=2Cy=3D180]a=3Dmid:S2 m=3Dvideo 49304 RTP/AVP 100 99 a=3Drecvonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]=20 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]a=3Dmid:S3Answer: v=3D0 o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 s=3DAnswer to Simulcast Enabled Clientt=3D0 0 c=3DIN IP4 192.0.2.43b=3DAS:665a=3Dgroup:SC S1 S2 m=3Dvideo 48000 RTP/AVP 97 a=3Drecvonly b=3DAS:520a=3Drtpmap:97 H264/90000a=3Dfmtp:97 profile-level-id=3D42c01e a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]a=3Dmid:S1 m=3Dvideo 48002 RTP/AVP= 98 a=3Drecvonly a=3Drtpmap:98 H264/90000a=3Dfmtp:98 profile-level-id=3D42c01e a=3Dimageattr:98 recv [x=3D320=2Cy=3D180]a=3Dmid:S2 m=3Dvideo 48004 RTP/AVP 100 99a=3Dsendonly a=3Drtpmap:100 H264/90000 a=3Dfmtp:100 profile-level-id=3D42c01e a=3Dimageattr:100 send [x=3D640=2Cy=3D360]=20 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 send [x=3D320=2Cy=3D180]a=3Dmid:S3 =0A= =0A= =0A= =0A= =0A= =0A= =0A= From: Bo Burman=0A= =0A= Sent: 2. joulukuuta 2013 12:52 =0A= To: Bernard Aboba=3B Christer Holmberg=3B mmusic@ietf.org =0A= Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast=0A= =0A= =0A= =0A= Should a simulcast-capable endpoint be restricted to be a simulcast-sender-= only or a simulcast-receiver-only=2C or do we envision endpoints that are c= apable of=0A= both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard=92s terminol= ogy below).=0A= =0A= If so and assuming that we define a new 5888-type simulcast grouping=2C do = we need separate groupings for send direction simulcast and receive directi= on simulcast=2C=0A= or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?=0A= =0A= Also=2C I think the way to use this approach for simulcast in combination w= ith multiple separate media sources (like multiple cameras) or media sinks = (like multiple=0A= displays) would be pretty straightforward=3B just add one simulcast groupi= ng per media source/sink.=0A= =0A= =0A= =0A= =0A= From: mmusic [mailto:mmusic-bounces@ietf.org]=0A= On Behalf Of Bernard Aboba =0A= Sent: den 30 november 2013 20:31 =0A= To: Christer Holmberg=3B mmusic@ietf.org =0A= Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast=0A= =0A= =0A= =0A= =0A= =0A= Christer asked:=0A= "In your example=2C how does the answerer know that the offered m- lines ar= e for simulcast? As far as O/A is concerned=2C it could just be a number of= completely separate (different content etc) uni-directional streams."=0A= [BA] The most obvious way would be grouping. Looking at RFC 5888/5583=2C i= t doesn't appear that either FID or DDP grouping would apply to simulcast. = So perhaps a new group type would be needed. =0A= =0A= =0A= Bernard Aboba wrote:=0A= =0A= =0A= =0A= At IETF 88=2C a number of participants (including myself) expressed the vi= ew that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below= =2C I will attempt to explain how simulcast=0A= might be negotiated in a simplified Offer/Answer exchange based on the pri= nciples of Unified Plan.=0A= =0A= =20 =0A= Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU)=2C while receiving one among a = set of potential streams from the SFU=2C with the SFU being able to switch = between the streams that it is sending=0A= to the endpoint without signaling. RFC 3264 describes how to handle each = of these situations.=0A= =0A= =20 =0A= With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=0A= =0A= =0A= If the offerer wishes to only send media on a stream to its peer=2C it MUST= mark the stream as sendonly with the "a=3Dsendonly" attribute. We refer = to a stream as being marked with a certain=0A= direction if a direction attribute was present as either a media stream at= tribute or a session attribute. For sendonly RTP streams=2C the payload typ= e numbers indicate the value of the payload type field in RTP packet the of= ferer is planning to send for that=0A= codec... In all cases=2C the formats in the "m=3D" line MUST be listed in= order of preference=2C with the first format listed being preferred. In t= his case=2C preferred means that the recipient of the offer SHOULD use the = format with the highest preference that=0A= is acceptable to it. If multiple media streams of different types are pres= ent=2C it means that the offerer wishes to use those streams at the same ti= me. A typical case is an audio and a video stream as part of a videoconfer= ence. =0A= =20 =0A= If multiple media streams of the same type are present in an offer=2C it m= eans that the offerer wishes to send (and/or receive) multiple streams of t= hat type at the same time... Each stream MAY use different encodings.=0A= =0A= =20 =0A= With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=0A= =0A= =0A= If the offerer wishes to only receive media from its peer=2C it MUST mark t= he stream as recvonly... If multiple formats are listed=2C it means that th= e offerer is capable of making use of any=0A= of those formats during the session. In other words=2C the answerer MAY c= hange formats in the middle of the session=2C making use of any of the form= ats listed=2C without sending a new offer. For a sendonly stream=2C the of= fer SHOULD indicate those formats the offerer=0A= is willing to send for this stream. For a recvonly stream=2C the offer S= HOULD indicate those formats the offerer is willing to receive for this str= eam.... =0A= =20 =0A= For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to receive = for that codec. =0A= =0A= =20 =0A= Based on the above: =0A= =20 =0A= 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . The offer would also include a single m=3Dline (with a=3Drecvonly) descr= ibing the streams that the endpoint is prepared=0A= to receive=2C each with their own payload type.=20 =0A= =20 =0A= 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition=2C the answer would include a single m=3Dline (with= a=3Dsendonly) indicating the streams from=0A= among those proposed by the endpoint that the SFU is prepared to send. Th= e SFU can then switch between those streams without having to signal the en= dpoint.=0A= =0A= =20 =0A= Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send=2C an Answerer can indicate how m= any streams it is prepared to receive (might only be one if simulcast isn't= supported). Similarly=2C an Answerer=0A= can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).=0A= =0A= =20 =0A= Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio):=20 =0A= =20 =0A= v=3D0 =0A= o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 =0A= s=3DSimulcast Enabled Unified Plan Client =0A= t=3D0 0 =0A= c=3DIN IP4 192.0.2.156 =0A= b=3DAS:665 =0A= m=3Dvideo 49300 RTP/AVP 97 =0A= a=3Dsendonly =0A= b=3DAS:520 =0A= a=3Drtpmap:97 H264/90000 =0A= a=3Dfmtp:97 profile-level-id=3D42c01e =0A= a=3Dimageattr:97 send [x=3D640=2Cy=3D360]=20 =0A= m=3Dvideo 49302 RTP/AVP 98 =0A= a=3Dsendonly =0A= a=3Drtpmap:98 H264/90000 =0A= a=3Dfmtp:98 profile-level-id=3D42c01e =0A= a=3Dimageattr:98 send [x=3D320=2Cy=3D180] =0A= m=3Dvideo 49304 RTP/AVP 100 99 =0A= a=3Drecvonly =0A= a=3Drtpmap:100 H264/90000 =0A= a=3Dfmtp:100 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]=20 =0A= a=3Drtpmap:99 H264/90000 =0A= a=3Dfmtp:99 profile-level-id=3D42c01e =0A= a=3Dimageattr:99 recv [x=3D320=2Cy=3D180] =0A= =20 =0A= =20 =0A= Example Answer:=20 =0A= =20 =0A= v=3D0 =0A= o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 =0A= s=3DAnswer to Simulcast Enabled Unified Plan Client =0A= t=3D0 0 =0A= c=3DIN IP4 192.0.2.43 =0A= b=3DAS:665 =0A= m=3Dvideo 48000 RTP/AVP 97 =0A= a=3Drecvonly =0A= b=3DAS:520 =0A= a=3Drtpmap:97 H264/90000 =0A= a=3Dfmtp:97 profile-level-id=3D42c01e =0A= a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]=20 =0A= m=3Dvideo 48002 RTP/AVP 98 =0A= a=3Drecvonly =0A= a=3Drtpmap:98 H264/90000 =0A= a=3Dfmtp:98 profile-level-id=3D42c01e =0A= a=3Dimageattr:98 recv [x=3D320=2Cy=3D180] =0A= m=3Dvideo 48004 RTP/AVP 100 99 =0A= a=3Dsendonly =0A= a=3Drtpmap:100 H264/90000 =0A= a=3Dfmtp:100 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 send [x=3D640=2Cy=3D360]=20 =0A= a=3Drtpmap:99 H264/90000 =0A= a=3Dfmtp:99 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 send [x=3D320=2Cy=3D180]=20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= = --_43b58fb2-e67a-4045-8b31-6a41ccc1daea_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Christer said:
=0A=

 =3B=0A=

"If the answerer = does NOT support simulcast=2C it will see an Offer with multiple uni-direct= ional streams. The behavior is difficult to predict.

=0A=

 =3B=0A=

So=2C even with a= mechanism based on grouping=2C the question is still: should the support o= f the simulcast feature be negotiated between the endpoints first=2C before= =0A= it is enabled? Most likely it would require 2 O/A transactions."

 =3B<= /p>

[BA] If the an= swerer does NOT support simulcast=2C it would not respond with an a=3Dgroup= :SC line=2C so the Offerer will know that simulcast is not supported. = =3B If the Answerer accepted =3Bmore than one =3Bof the m=3D lines = offered by the Offerer=2C but didn't include an a=3Dgroup:SC line=2C then t= he Offerer could send a modified offer in order to avoid confusion on the p= art of the Answerer. =3B =3B A similar =3Bscenario can occur in draft-westerlund-avtcore-rtp-simulc= ast=2C since the Answerer may not understand the a=3Dsim-send-cap or a=3Dsim-recv-cap lines.

 =3B

In an O/A exchange where both the Offerer and Answerer support= simulcast=2C the exchange would look like this:

 =3B

Offer:

v= =3D0
o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
s=3DSimulcast Enabled Client
t=3D0 0
c=3DIN IP4 192.0.2.156
b=3DAS:665=

a=3Dgroup:SC S1 = S2
m=3Dvideo 49300 RTP/AVP 97a=3Dsendonly
b=3DAS:520
a=3Drtpmap:97 H264= /90000

a=3Dfmtp:97 profile-level-id=3D42c01e
= a=3Dimageattr:97 send [x=3D640=2Cy=3D360]

a=3Dmid:S1
m=3Dvideo 49302 RTP/AVP 98
a=3D<= /span>sendonly
a=3Drtpmap:98 H264/9000= 0
a=3Dfmtp:98 profile-level-id=3D42c01e
a=3Dimageattr:9= 8 send [x=3D320=2Cy=3D180]

a=3Dmid:S2
m=3Dvideo 49304 RTP/AVP 100 99
a=3Drecvonly
a=3Drtpmap:100 H264/90000
a=3Df= mtp:100 profile-level-id=3D42c01e
a=3Dimageattr:100 recv<= /span> [x=3D640=2Cy=3D360]
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 profile-level-id= =3D42c01e
a=3Dimageattr:99 recv [x=3D320=2Cy=3D180<= span style=3D'color: black=3B font-family: "Courier New"=3B font-size: 14pt= =3B language: en-US=3B mso-ascii-font-family: "Courier New"=3B mso-fareast-= font-family: "DejaVu Sans"=3B mso-bidi-font-family: "Courier New"=3B mso-fa= reast-theme-font: minor-fareast=3B mso-color-index: 1=3B mso-font-kerning: = 12.0pt=3B mso-style-textfill-type: solid=3B mso-style-textfill-fill-themeco= lor: text1=3B mso-style-textfill-fill-color: black=3B mso-style-textfill-fi= ll-alpha: 100.0%=3B'>]

a=3Dmid:S3

Answer:

v=3D0
o=3Dserver 823479283 1209384938 IN IP4 = 192.0.2.2
s=3DAnswer to Simulcast Enabled Client

t=3D0 0
c=3DIN IP4 192.0.2.43

b=3DAS:665

a=3Dgroup:SC S1 S2
m= =3Dvideo 48000 RTP/AVP 97
a=3Drecvonly
b=3DAS:520

a=3Drtpmap:97 H264/= 90000

a=3Dfmtp:97 profile-level-id=3D42c01e
= a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]

a=3Dmid:S1

m=3Dvideo 48002 RTP/AVP 98
a=3Drecvonly
a=3Drtpmap:98 H264/90000=

a= =3Dfmtp:98 profile-level-id=3D42c01e
a=3Dimageattr:98 recv<= /span> [x=3D320=2Cy=3D180]

a
<= /span>m=3Dvideo 48004 RT= P/AVP 100 99

a=3Dse= ndonly
a=3Dr= tpmap:100 H264/90000
a=3Dfmtp:100 profile-level-id=3D42c01e=
a=3Dimageattr:100 send [x=3D640=2Cy=3D360]
a=3Drtpmap= :99 H264/90000
a=3Dfmtp:99 profile-level-id=3D42c01e
a=3Dimageattr:99 sen= d [x=3D320=2Cy=3D180]

a=3Dmid:S3

 =3B

=0A=

 =3B=0A=

 =3B=0A=

 =3B=0A=

 =3B=0A=

=0A=
=0A=

From: Bo Burman=0A=
=0A= Sent: 2. joulukuuta 2013 12:52
=0A= To: Bernard Aboba=3B Christer Holmberg=3B mmusic@ietf.org
=0A= Subject: RE: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

=0A=
=0A=
=0A=

 =3B

=0A=

Should a simulcas= t-capable endpoint be restricted to be a simulcast-sender-only or a simulca= st-receiver-only=2C or do we envision endpoints that are capable of=0A= both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard=92s terminol= ogy below).

=0A=

 =3B=0A=

If so and assumin= g that we define a new 5888-type simulcast grouping=2C do we need separate = groupings for send direction simulcast and receive direction simulcast=2C= =0A= or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?

=0A=

 =3B=0A=

Also=2C I think t= he way to use this approach for simulcast in combination with multiple sepa= rate media sources (like multiple cameras) or media sinks (like multiple=0A= displays) would be pretty straightforward=3B just add one simulcast groupi= ng per media source/sink.

=0A=

 =3B=0A=

=0A=
=0A=
=0A=

From: mmusic [mailto:mmusic-bounces@ietf.org]=0A= On Behalf Of Bernard Aboba
=0A= Sent: den 30 november 2013 20:31
=0A= To: Christer Holmberg=3B mmusic@i= etf.org
=0A= Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A= 
Christer asked:
=0A= 
"In your example=2C how does the a=
nswerer know that the offered m- lines are for simulcast? As far as O/A is =
concerned=2C it could just be a number of completely separate (different co=
ntent etc) uni-directional streams."
=0A= 
[BA] The most obvious way would be=
 grouping. =3B Looking at RFC 5888/5583=2C it doesn't appear that eithe=
r FID or DDP grouping would apply to simulcast. =3B =3B So perhaps =
a new group type would be needed.
=0A= 
 =3B
=0A= 
 =3B
=0A= 
Bernard Aboba <=3Bbernard_=
aboba@hotmail.com>=3B wrote:
=0A= 
 =3B
=0A=
=0A=
=0A=

At IETF 88=2C a number of =3B participants (including myself) e= xpressed the view that draft-westerlund-avtcore-rtp-simulcast was too compl= icated. =3B =3BBelow=2C I will attempt to explain how simulcast=0A= might be =3Bnegotiated in a simplified Offer/Answer exchange =3Bba= sed on the principles of Unified Plan.=0A=
=0A=  =3B
=0A= Typically in simulcast we have an endpoint sending multiple streams =3B= in parallel =3Bto the Selective Forwarding Unit (SFU)=2C while receivin= g one among a set of potential streams from the SFU=2C with the SFU being a= ble to switch between the streams that it is sending=0A= to the endpoint =3Bwithout signaling. =3B RFC 3264 describes how t= o handle each of these situations.=0A=
=0A=  =3B
=0A= With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=0A=
=0A=  =3B

=0A=

If the offerer wishes to only send media on a stream to its peer=2C= it =3BMUST mark the stream as sendonly with the "a=3Dsendonly" attribu= te. =3B We =3B refer to a stream as being marked with a certain=0A= direction if a =3Bdirection attribute was present as either a media st= ream attribute or a session attribute. =3BFor sendonly RTP streams=2C t= he payload type numbers indicate the value of the payload type field in RTP= packet =3Bthe offerer is planning to send for that=0A= codec... =3B In all cases=2C the formats in the "m=3D" line MUST be li= sted in order of =3Bpreference=2C with the first format listed being pr= eferred. =3B In this =3Bcase=2C preferred means that the recipient = of the offer SHOULD use the format with the highest preference that=0A= is acceptable to it. If multiple media streams of different types are pres= ent=2C it means that the offerer wishes to use those streams at the same ti= me. =3B A =3Btypical case is an audio and a video stream as part of= a videoconference.
=0A=  =3B
=0A= If multiple media streams of the same type are present in an offer=2C = =3B it means that the offerer wishes to send (and/or receive) multiple stre= ams of that type at the same time... =3B Each stream MAY use =3Bdif= ferent encodings.=0A=

=0A=

 =3B
=0A= With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=0A=
=0A=  =3B

=0A=

If the offerer wishes to only receive media from its peer=2C it MUS= T mark the stream as recvonly... If multiple formats are listed=2C it means= that the offerer is capable =3Bof making use of any=0A= of those formats during the session. =3B In other =3Bwords=2C the = answerer MAY change formats in the middle of the session=2C making use of a= ny of the formats listed=2C without sending a new offer. =3B =3BFor= a sendonly stream=2C the offer SHOULD indicate those formats the =3Bof= ferer=0A= is willing to send for this stream. =3B For a recvonly stream=2C = =3B the offer SHOULD indicate those formats the offerer is willing to recei= ve for this stream....
=0A=  =3B =3B
=0A= For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to =3B r= eceive for that codec. =3B=0A=

=0A=

 =3B
=0A= Based on the above:
=0A=  =3B
=0A= 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . =3B The offer would also include a single m=3Dline (with a=3Drecvonly= ) describing the streams that the endpoint is prepared=0A= to receive=2C each with their own payload type.
=0A=  =3B
=0A= 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). =3B In addition=2C the answer would include a single m=3Dlin= e (with a=3Dsendonly) indicating the streams from=0A= among those proposed by the endpoint that the SFU is prepared to send.&nbs= p=3B The SFU can then switch between those streams without having to signal= the endpoint.=0A=
=0A=  =3B
=0A= Since it is possible for the =3BAnswerer to accept/reject each of the p= roposed streams the Offerer is proposing to send=2C an =3BAnswerer can = indicate how many streams it is prepared to receive (might only be one if s= imulcast isn't supported). =3B =3B Similarly=2C an Answerer=0A= can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).=0A=
=0A=  =3B
=0A= Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio): <= br>=0A=  =3B
=0A=  =3B =3B v=3D0
=0A=  =3B =3B o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
=0A=  =3B =3B s=3DSimulcast Enabled Unified Plan Client
=0A=  =3B =3B t=3D0 0
=0A=  =3B =3B c=3DIN IP4 192.0.2.156
=0A=  =3B =3B b=3DAS:665
=0A=  =3B =3B m=3Dvideo 49300 RTP/AVP 97
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B b=3DAS:520
=0A=  =3B =3B a=3Drtpmap:97 H264/90000
=0A=  =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:97 send [x=3D640=2Cy=3D360]
=0A=  =3B =3B m=3Dvideo 49302 RTP/AVP 98
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B a=3Drtpmap:98 H264/90000
=0A=  =3B =3B a=3Dfmtp:98 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:98 send [x=3D320=2Cy=3D180]
=0A=  =3B =3B m=3Dvideo 49304 RTP/AVP 100 99
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B a=3Drtpmap:100 H264/90000
=0A=  =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]
=0A=  =3B =3B a=3Drtpmap:99 H264/90000
=0A=  =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]
=0A=  =3B
=0A=  =3B
=0A= Example Answer:
=0A=  =3B
=0A=  =3B =3B v=3D0
=0A=  =3B =3B o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
=0A=  =3B =3B s=3DAnswer to Simulcast Enabled Unified Plan Client
=0A=  =3B =3B t=3D0 0
=0A=  =3B =3B c=3DIN IP4 192.0.2.43
=0A=  =3B =3B b=3DAS:665
=0A=  =3B =3B m=3Dvideo 48000 RTP/AVP 97
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B b=3DAS:520
=0A=  =3B =3B a=3Drtpmap:97 H264/90000
=0A=  =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]
=0A=  =3B =3B m=3Dvideo 48002 RTP/AVP 98
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B a=3Drtpmap:98 H264/90000
=0A=  =3B =3B a=3Dfmtp:98 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:98 recv [x=3D320=2Cy=3D180]
=0A=  =3B =3B m=3Dvideo 48004 RTP/AVP 100 99
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B a=3Drtpmap:100 H264/90000
=0A=  =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 send [x=3D640=2Cy=3D360]
=0A=  =3B =3B a=3Drtpmap:99 H264/90000
=0A=  =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 send [x=3D320=2Cy=3D180]
=0A=  =3B

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
= --_43b58fb2-e67a-4045-8b31-6a41ccc1daea_-- From bernard_aboba@hotmail.com Mon Dec 2 16:15:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EE41ADFCF for ; Mon, 2 Dec 2013 16:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ8-YvX7OdWD for ; Mon, 2 Dec 2013 16:15:24 -0800 (PST) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5021ADFCB for ; Mon, 2 Dec 2013 16:15:23 -0800 (PST) Received: from BLU169-W123 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Dec 2013 16:15:21 -0800 X-TMN: [6ztQ7VYKQtOQMTBtmw7PkT5J0NCZJrCUPjZGOJw3i34=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_315a6690-c1f1-4469-acf9-158a9a513849_" From: Bernard Aboba To: Bo Burman , Christer Holmberg , "mmusic@ietf.org" Date: Mon, 2 Dec 2013 16:15:20 -0800 Importance: Normal In-Reply-To: References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2013 00:15:21.0390 (UTC) FILETIME=[C128F4E0:01CEEFBC] X-Mailman-Approved-At: Tue, 03 Dec 2013 05:13:07 -0800 Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:15:26 -0000 --_315a6690-c1f1-4469-acf9-158a9a513849_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bo Burman said:=20 =20 =0A= =0A= =0A= =0A= "Should a simulcast-capable endpoint be restricted to be a simulcast-sender= -only or a simulcast-receiver-only=2C or do we envision endpoints that are = capable of=0A= both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard=92s terminol= ogy below)." =0A= If so and assuming that we define a new 5888-type simulcast grouping=2C do = we need separate groupings for send direction simulcast and receive directi= on simulcast=2C=0A= or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient? Also=2C I think the way to use this approach for= simulcast in combination with multiple separate media sources (like multip= le cameras) or media sinks (like multiple displays) would be pretty straigh= tforward=3B just add one simulcast grouping per media source/sink." [BA] In= the case where parallel simulcast streams are being both sent and received= (e.g. between SFUs)=2C there wouldn't be a need for a=3Dsendonly or a=3Dre= cvonly lines=3B each m=3Dline would apply to both sending and receiving. = So it seems like a single simulcast group would suffice. If you have mult= iple sources or sinks=2C then yes=2C I believe you would have one simulcast= grouping per media source/sink. A simple SFU1-SFU2 exchange would look li= ke this: Offer: =0A= =0A= v=3D0 =0A= o=3DSFU1=0A= 2362969037=0A= 2362969040 IN IP4 192.0.2.156 =0A= s=3DSimulcast=0A= Enabled=0A= SFU1t=3D0=0A= 0 =0A= c=3DIN=0A= IP4=0A= 192.0.2.156 =0A= b=3DAS:665a=3Dgroup:SC S1 S2 =0A= m=3Dvideo=0A= 49300=0A= RTP/AVP 97 =0A= b=3DAS:520 =0A= a=3Drtpmap:97=0A= H264/90000a=3Dfmtp:97=0A= profile-level-id=3D42c01e =0A= a=3Dimageattr:97=0A= send=0A= [x=3D640=2Cy=3D360]a=3Dmid:S1 =0A= m=3Dvideo=0A= 49302=0A= RTP/AVP 98 =0A= a=3Drtpmap:98=0A= H264/90000 =0A= a=3Dfmtp:98=0A= profile-level-id=3D42c01e =0A= a=3Dimageattr:98=0A= send=0A= [x=3D320=2Cy=3D180]a=3Dmid:S2 =0A= =0A= =0A= Answer: =0A= =0A= v=3D0 =0A= o=3DSFU2=0A= 823479283=0A= 1209384938 IN IP4 192.0.2.2 =0A= s=3DAnswer=0A= to=0A= Simulcast Enabled=0A= SFU1t=3D0 0 =0A= c=3DIN=0A= IP4=0A= 192.0.2.43b=3DAS:665a=3Dgroup:SC S1=0A= S2 =0A= m=3Dvideo=0A= 48000=0A= RTP/AVP 97 =0A= b=3DAS:520a=3Drtpmap:97=0A= H264/90000a=3Dfmtp:97=0A= profile-level-id=3D42c01e =0A= a=3Dimageattr:97=0A= recv=0A= [x=3D640=2Cy=3D360]a=3Dmid:S1=0A= m=3Dvideo=0A= 48002=0A= RTP/AVP 98 =0A= a=3Drtpmap:98=0A= H264/90000a=3Dfmtp:98=0A= profile-level-id=3D42c01e =0A= a=3Dimageattr:98=0A= recv=0A= [x=3D320=2Cy=3D180]a=3Dmid:S2=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From: mmusic [mailto:mmusic-bounces@ietf.org]=0A= On Behalf Of Bernard Aboba =0A= Sent: den 30 november 2013 20:31 =0A= To: Christer Holmberg=3B mmusic@ietf.org =0A= Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast=0A= =0A= =0A= =0A= =0A= =0A= Christer asked:=0A= "In your example=2C how does the answerer know that the offered m- lines ar= e for simulcast? As far as O/A is concerned=2C it could just be a number of= completely separate (different content etc) uni-directional streams."=0A= [BA] The most obvious way would be grouping. Looking at RFC 5888/5583=2C i= t doesn't appear that either FID or DDP grouping would apply to simulcast. = So perhaps a new group type would be needed. =0A= =0A= =0A= Bernard Aboba wrote:=0A= =0A= =0A= =0A= At IETF 88=2C a number of participants (including myself) expressed the vi= ew that draft-westerlund-avtcore-rtp-simulcast was too complicated. Below= =2C I will attempt to explain how simulcast=0A= might be negotiated in a simplified Offer/Answer exchange based on the pri= nciples of Unified Plan.=0A= =0A= =20 =0A= Typically in simulcast we have an endpoint sending multiple streams in para= llel to the Selective Forwarding Unit (SFU)=2C while receiving one among a = set of potential streams from the SFU=2C with the SFU being able to switch = between the streams that it is sending=0A= to the endpoint without signaling. RFC 3264 describes how to handle each = of these situations.=0A= =0A= =20 =0A= With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=0A= =0A= =0A= If the offerer wishes to only send media on a stream to its peer=2C it MUST= mark the stream as sendonly with the "a=3Dsendonly" attribute. We refer = to a stream as being marked with a certain=0A= direction if a direction attribute was present as either a media stream at= tribute or a session attribute. For sendonly RTP streams=2C the payload typ= e numbers indicate the value of the payload type field in RTP packet the of= ferer is planning to send for that=0A= codec... In all cases=2C the formats in the "m=3D" line MUST be listed in= order of preference=2C with the first format listed being preferred. In t= his case=2C preferred means that the recipient of the offer SHOULD use the = format with the highest preference that=0A= is acceptable to it. If multiple media streams of different types are pres= ent=2C it means that the offerer wishes to use those streams at the same ti= me. A typical case is an audio and a video stream as part of a videoconfer= ence. =0A= =20 =0A= If multiple media streams of the same type are present in an offer=2C it m= eans that the offerer wishes to send (and/or receive) multiple streams of t= hat type at the same time... Each stream MAY use different encodings.=0A= =0A= =20 =0A= With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=0A= =0A= =0A= If the offerer wishes to only receive media from its peer=2C it MUST mark t= he stream as recvonly... If multiple formats are listed=2C it means that th= e offerer is capable of making use of any=0A= of those formats during the session. In other words=2C the answerer MAY c= hange formats in the middle of the session=2C making use of any of the form= ats listed=2C without sending a new offer. For a sendonly stream=2C the of= fer SHOULD indicate those formats the offerer=0A= is willing to send for this stream. For a recvonly stream=2C the offer S= HOULD indicate those formats the offerer is willing to receive for this str= eam.... =0A= =20 =0A= For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to receive = for that codec. =0A= =0A= =20 =0A= Based on the above: =0A= =20 =0A= 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . The offer would also include a single m=3Dline (with a=3Drecvonly) descr= ibing the streams that the endpoint is prepared=0A= to receive=2C each with their own payload type.=20 =0A= =20 =0A= 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). In addition=2C the answer would include a single m=3Dline (with= a=3Dsendonly) indicating the streams from=0A= among those proposed by the endpoint that the SFU is prepared to send. Th= e SFU can then switch between those streams without having to signal the en= dpoint.=0A= =0A= =20 =0A= Since it is possible for the Answerer to accept/reject each of the proposed= streams the Offerer is proposing to send=2C an Answerer can indicate how m= any streams it is prepared to receive (might only be one if simulcast isn't= supported). Similarly=2C an Answerer=0A= can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).=0A= =0A= =20 =0A= Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio):=20 =0A= =20 =0A= v=3D0 =0A= o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156 =0A= s=3DSimulcast Enabled Unified Plan Client =0A= t=3D0 0 =0A= c=3DIN IP4 192.0.2.156 =0A= b=3DAS:665 =0A= m=3Dvideo 49300 RTP/AVP 97 =0A= a=3Dsendonly =0A= b=3DAS:520 =0A= a=3Drtpmap:97 H264/90000 =0A= a=3Dfmtp:97 profile-level-id=3D42c01e =0A= a=3Dimageattr:97 send [x=3D640=2Cy=3D360]=20 =0A= m=3Dvideo 49302 RTP/AVP 98 =0A= a=3Dsendonly =0A= a=3Drtpmap:98 H264/90000 =0A= a=3Dfmtp:98 profile-level-id=3D42c01e =0A= a=3Dimageattr:98 send [x=3D320=2Cy=3D180] =0A= m=3Dvideo 49304 RTP/AVP 100 99 =0A= a=3Drecvonly =0A= a=3Drtpmap:100 H264/90000 =0A= a=3Dfmtp:100 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]=20 =0A= a=3Drtpmap:99 H264/90000 =0A= a=3Dfmtp:99 profile-level-id=3D42c01e =0A= a=3Dimageattr:99 recv [x=3D320=2Cy=3D180] =0A= =20 =0A= =20 =0A= Example Answer:=20 =0A= =20 =0A= v=3D0 =0A= o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2 =0A= s=3DAnswer to Simulcast Enabled Unified Plan Client =0A= t=3D0 0 =0A= c=3DIN IP4 192.0.2.43 =0A= b=3DAS:665 =0A= m=3Dvideo 48000 RTP/AVP 97 =0A= a=3Drecvonly =0A= b=3DAS:520 =0A= a=3Drtpmap:97 H264/90000 =0A= a=3Dfmtp:97 profile-level-id=3D42c01e =0A= a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]=20 =0A= m=3Dvideo 48002 RTP/AVP 98 =0A= a=3Drecvonly =0A= a=3Drtpmap:98 H264/90000 =0A= a=3Dfmtp:98 profile-level-id=3D42c01e =0A= a=3Dimageattr:98 recv [x=3D320=2Cy=3D180] =0A= m=3Dvideo 48004 RTP/AVP 100 99 =0A= a=3Dsendonly =0A= a=3Drtpmap:100 H264/90000 =0A= a=3Dfmtp:100 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 send [x=3D640=2Cy=3D360]=20 =0A= a=3Drtpmap:99 H264/90000 =0A= a=3Dfmtp:99 profile-level-id=3D42c01e =0A= a=3Dimageattr:100 send [x=3D320=2Cy=3D180]=20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= = --_315a6690-c1f1-4469-acf9-158a9a513849_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Bo Burman said:
 =3B
=0A= =0A= =0A=
=0A=

"Should a simulca= st-capable endpoint be restricted to be a simulcast-sender-only or a simulc= ast-receiver-only=2C or do we envision endpoints that are capable of=0A= both sending and receiving simulcast? One example would be if simulcast st= reams are to be forwarded between different SFU (using Bernard=92s terminol= ogy below)."

 =3B

=0A=

If so and assumin= g that we define a new 5888-type simulcast grouping=2C do we need separate = groupings for send direction simulcast and receive direction simulcast=2C= =0A= or is a=3Dsendonly and a=3Drecvonly information for simulcast-grouped medi= a blocks fully sufficient?

 =3B

Also=2C I think the= way to use this approach for simulcast in combination with multiple separa= te media sources (like multiple cameras) or media sinks (like multiple disp= lays) would be pretty straightforward=3B just add one simulcast grouping pe= r media source/sink."

 =3B

=

[BA] In the case where parallel simulcast streams are= being both sent and received (e.g. between SFUs)=2C there wouldn't be a ne= ed for a=3Dsendonly or a=3Drecvonly lines=3B =3B each m=3Dline would ap= ply to both sending and receiving. =3B So it seems like a single simulc= ast group would suffice. =3B =3B If you have multiple sources or si= nks=2C then yes=2C I believe you would have one simulcast grouping per medi= a source/sink.

 =3B

A simple SFU1-SFU2 exchange =3Bwould look like this: =

 = =3B

Offer:

=0A= =0A=

v=3D0
=0A= o=3DSFU1=0A= 2362969037=0A= 2362969040 IN IP4 192.0.2.156
=0A= s=3DSimulcast=0A= Enabled=0A= SFU1

t=3D0=0A= 0
=0A= c=3DIN=0A= IP4=0A= 192.0.2.156
=0A= b=3DAS:665

a=3D= group:SC S1 S2
=0A= m=3Dvideo=0A= 49300=0A= RTP/AVP 97
=0A= b=3DAS:520
= =0A= a=3Drtpmap:97=0A= H264/90000

a=3Dfmtp:97=0A= profile-level-id=3D42c01e
=0A= a=3Dimageattr:97=0A= send=0A= [x=3D640=2Cy=3D360]

a=3Dmid:S1
=0A= m=3Dvideo=0A= 49302=0A= RTP/AVP 98
=0A= a=3Drtpmap:98=0A= H264/90000
=0A= a=3Dfmtp:98=0A= profile-level-id=3D42c01e
=0A= a=3Dimageattr:98=0A= send=0A= [x=3D320=2Cy=3D180]

a=3Dmid:S2
=0A=

=0A= =0A=

Answer:

=0A= =0A=

v=3D0
=0A= o=3DSFU2=0A= 823479283=0A= 1209384938 IN IP4 192.0.2.2
=0A= s=3DAnswer=0A= to=0A= Simulcast Enabled=0A= SFU1

t=3D0 0
= =0A= c=3DIN=0A= IP4=0A= 192.0.2.43

b=3DAS:665

a= =3Dgroup:SC S1=0A= S2
=0A= m=3Dvideo=0A= 48000=0A= RTP/AVP 97
=0A= b=3DAS:520

a=3Drtpmap:97=0A= H264/90000

a=3Dfmtp:97=0A= profile-level-id=3D42c01e
=0A= a=3Dimageattr:97=0A= recv=0A= [x=3D640=2Cy=3D360]

a=3Dmid:S1=0A=

m= =3Dvideo=0A= 48002=0A= RTP/AVP 98
=0A= a=3Drtpmap:98=0A= H264/90000

a=3Dfmtp:98=0A= profile-level-id=3D42c01e
=0A= a=3Dimageattr:98=0A= recv=0A= [x=3D320=2Cy=3D180]

a=3Dmid:S2

=0A= =0A=

=0A=

 =3B=0A=

 =3B=0A=

 =3B=0A=

=0A=
=0A=
=0A=

From: mmusic [mailto:mmusic-bounces= @ietf.org]=0A= On Behalf Of Bernard Aboba
=0A= Sent: den 30 november 2013 20:31
=0A= To: Christer Holmberg=3B mmusic@ietf.org
=0A= Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simul= cast

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A= 
Christer asked:
=0A= 
"In your example=2C how does the a=
nswerer know that the offered m- lines are for simulcast? As far as O/A is =
concerned=2C it could just be a number of completely separate (different co=
ntent etc) uni-directional streams."
=0A= 
[BA] The most obvious way would be=
 grouping. =3B Looking at RFC 5888/5583=2C it doesn't appear that eithe=
r FID or DDP grouping would apply to simulcast. =3B =3B So perhaps =
a new group type would be needed.
=0A= 
 =3B
=0A= 
 =3B
=0A= 
Bernard Aboba <=3Bbernard_=
aboba@hotmail.com>=3B wrote:
=0A= 
 =3B
=0A=
=0A=
=0A=

At IETF 88=2C a number of =3B participants (including myself) e= xpressed the view that draft-westerlund-avtcore-rtp-simulcast was too compl= icated. =3B =3BBelow=2C I will attempt to explain how simulcast=0A= might be =3Bnegotiated in a simplified Offer/Answer exchange =3Bba= sed on the principles of Unified Plan.=0A=
=0A=  =3B
=0A= Typically in simulcast we have an endpoint sending multiple streams =3B= in parallel =3Bto the Selective Forwarding Unit (SFU)=2C while receivin= g one among a set of potential streams from the SFU=2C with the SFU being a= ble to switch between the streams that it is sending=0A= to the endpoint =3Bwithout signaling. =3B RFC 3264 describes how t= o handle each of these situations.=0A=
=0A=  =3B
=0A= With respect to sending multiple streams in parallel=2C RFC 3264 Section 5.= 1 states the following:=0A=
=0A=  =3B

=0A=

If the offerer wishes to only send media on a stream to its peer=2C= it =3BMUST mark the stream as sendonly with the "a=3Dsendonly" attribu= te. =3B We =3B refer to a stream as being marked with a certain=0A= direction if a =3Bdirection attribute was present as either a media st= ream attribute or a session attribute. =3BFor sendonly RTP streams=2C t= he payload type numbers indicate the value of the payload type field in RTP= packet =3Bthe offerer is planning to send for that=0A= codec... =3B In all cases=2C the formats in the "m=3D" line MUST be li= sted in order of =3Bpreference=2C with the first format listed being pr= eferred. =3B In this =3Bcase=2C preferred means that the recipient = of the offer SHOULD use the format with the highest preference that=0A= is acceptable to it. If multiple media streams of different types are pres= ent=2C it means that the offerer wishes to use those streams at the same ti= me. =3B A =3Btypical case is an audio and a video stream as part of= a videoconference.
=0A=  =3B
=0A= If multiple media streams of the same type are present in an offer=2C = =3B it means that the offerer wishes to send (and/or receive) multiple stre= ams of that type at the same time... =3B Each stream MAY use =3Bdif= ferent encodings.=0A=

=0A=

 =3B
=0A= With respect to receiving one among a set of potential streams=2C here is w= hat RFC 3264 Section 5.1 says:=0A=
=0A=  =3B

=0A=

If the offerer wishes to only receive media from its peer=2C it MUS= T mark the stream as recvonly... If multiple formats are listed=2C it means= that the offerer is capable =3Bof making use of any=0A= of those formats during the session. =3B In other =3Bwords=2C the = answerer MAY change formats in the middle of the session=2C making use of a= ny of the formats listed=2C without sending a new offer. =3B =3BFor= a sendonly stream=2C the offer SHOULD indicate those formats the =3Bof= ferer=0A= is willing to send for this stream. =3B For a recvonly stream=2C = =3B the offer SHOULD indicate those formats the offerer is willing to recei= ve for this stream....
=0A=  =3B =3B
=0A= For recvonly RTP streams=2C the payload type numbers indicate the value of = the payload type field in RTP packets the offerer is expecting to =3B r= eceive for that codec. =3B=0A=

=0A=

 =3B
=0A= Based on the above:
=0A=  =3B
=0A= 1. An offer from an endpoint to an SFU would include an m=3Dline for each p= otential simulcast stream to be sent=2C each including an a=3Dsendonly line= . =3B The offer would also include a single m=3Dline (with a=3Drecvonly= ) describing the streams that the endpoint is prepared=0A= to receive=2C each with their own payload type.
=0A=  =3B
=0A= 2. An answer from an SFU to an endpoint would accept or reject each of the = simulcast streams that the endpoint is proposing to send (with an a=3Drecvo= nly line). =3B In addition=2C the answer would include a single m=3Dlin= e (with a=3Dsendonly) indicating the streams from=0A= among those proposed by the endpoint that the SFU is prepared to send.&nbs= p=3B The SFU can then switch between those streams without having to signal= the endpoint.=0A=
=0A=  =3B
=0A= Since it is possible for the =3BAnswerer to accept/reject each of the p= roposed streams the Offerer is proposing to send=2C an =3BAnswerer can = indicate how many streams it is prepared to receive (might only be one if s= imulcast isn't supported). =3B =3B Similarly=2C an Answerer=0A= can select those simulcast streams it is prepared to send (might only be o= ne if simulcast isn't supported).=0A=
=0A=  =3B
=0A= Example Offer (leaving out BUNDLE=2C rtp/rtcp multiplexing=2C and audio): <= br>=0A=  =3B
=0A=  =3B =3B v=3D0
=0A=  =3B =3B o=3Dalice 2362969037 2362969040 IN IP4 192.0.2.156
=0A=  =3B =3B s=3DSimulcast Enabled Unified Plan Client
=0A=  =3B =3B t=3D0 0
=0A=  =3B =3B c=3DIN IP4 192.0.2.156
=0A=  =3B =3B b=3DAS:665
=0A=  =3B =3B m=3Dvideo 49300 RTP/AVP 97
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B b=3DAS:520
=0A=  =3B =3B a=3Drtpmap:97 H264/90000
=0A=  =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:97 send [x=3D640=2Cy=3D360]
=0A=  =3B =3B m=3Dvideo 49302 RTP/AVP 98
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B a=3Drtpmap:98 H264/90000
=0A=  =3B =3B a=3Dfmtp:98 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:98 send [x=3D320=2Cy=3D180]
=0A=  =3B =3B m=3Dvideo 49304 RTP/AVP 100 99
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B a=3Drtpmap:100 H264/90000
=0A=  =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 recv [x=3D640=2Cy=3D360]
=0A=  =3B =3B a=3Drtpmap:99 H264/90000
=0A=  =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]
=0A=  =3B
=0A=  =3B
=0A= Example Answer:
=0A=  =3B
=0A=  =3B =3B v=3D0
=0A=  =3B =3B o=3Dserver 823479283 1209384938 IN IP4 192.0.2.2
=0A=  =3B =3B s=3DAnswer to Simulcast Enabled Unified Plan Client
=0A=  =3B =3B t=3D0 0
=0A=  =3B =3B c=3DIN IP4 192.0.2.43
=0A=  =3B =3B b=3DAS:665
=0A=  =3B =3B m=3Dvideo 48000 RTP/AVP 97
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B b=3DAS:520
=0A=  =3B =3B a=3Drtpmap:97 H264/90000
=0A=  =3B =3B a=3Dfmtp:97 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:97 recv [x=3D640=2Cy=3D360]
=0A=  =3B =3B m=3Dvideo 48002 RTP/AVP 98
=0A=  =3B =3B a=3Drecvonly
=0A=  =3B =3B a=3Drtpmap:98 H264/90000
=0A=  =3B =3B a=3Dfmtp:98 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:98 recv [x=3D320=2Cy=3D180]
=0A=  =3B =3B m=3Dvideo 48004 RTP/AVP 100 99
=0A=  =3B =3B a=3Dsendonly
=0A=  =3B =3B a=3Drtpmap:100 H264/90000
=0A=  =3B =3B a=3Dfmtp:100 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 send [x=3D640=2Cy=3D360]
=0A=  =3B =3B a=3Drtpmap:99 H264/90000
=0A=  =3B =3B a=3Dfmtp:99 profile-level-id=3D42c01e
=0A=  =3B =3B a=3Dimageattr:100 send [x=3D320=2Cy=3D180]
=0A=  =3B

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
= --_315a6690-c1f1-4469-acf9-158a9a513849_-- From adam@nostrum.com Tue Dec 3 06:12:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CA41AC7F2 for ; Tue, 3 Dec 2013 06:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7ZJ5WNfLZLf for ; Tue, 3 Dec 2013 06:12:07 -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 C1A5A1ADBE5 for ; Tue, 3 Dec 2013 06:12:07 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3EC4Tw017411 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 3 Dec 2013 08:12:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529DE6AF.1060300@nostrum.com> Date: Tue, 03 Dec 2013 08:11:59 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:12:09 -0000 Based on the conversations we had during the partial offer/partial answer draft discussion in Vancouver, Martin and I put together a separate document that formally defines a group identifier for RFC 5888 SDP groups: http://tools.ietf.org/html/draft-roach-mmusic-groupid-00 We've made this a separate document because the utility of identifying groups extends beyond its (upcoming) use in the partial offer/partial answer draft. The document is mercifully short. Feedback is solicited. Thanks! /a From pkyzivat@alum.mit.edu Tue Dec 3 09:19:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640781A1F4E for ; Tue, 3 Dec 2013 09:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLElLEBfYbc7 for ; Tue, 3 Dec 2013 09:19:31 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id F04C61AC499 for ; Tue, 3 Dec 2013 09:19:30 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id wzny1m0071HzFnQ565KUbe; Tue, 03 Dec 2013 17:19:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id x5KU1m0033ZTu2S3a5KU5z; Tue, 03 Dec 2013 17:19:28 +0000 Message-ID: <529E129F.2080304@alum.mit.edu> Date: Tue, 03 Dec 2013 12:19:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: mmusic@ietf.org References: <529DE6AF.1060300@nostrum.com> In-Reply-To: <529DE6AF.1060300@nostrum.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=1386091168; bh=0ELr/9zlQawsaN1cMLuVei2pQOechVh0rFjXo+8ziik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qIYcaAMjzVIpYKBE78qXB2YY7JWXb74TCPvmCUOshvHKP7Jh76cqcXAF95LdoSJNw AjqRPP+FuTzBSGfwVokdmDhAhEmw3E918LEKGHIgvVQO+IAyPuff57iE5ZnigBHCtd cAWoTimvoik1rbvd9G4RySkNhHPE6M0fFNczRljue9iY1+VudFith8A0RgpzmK57NG WEB7D3kAW+TV7ktnO5mGxWv9tbAi9zJvcaXwjL6a5PzVBJF85SGPo1agoTaL6ft8+O MVNQEXXWgDGZ82kubm+T1SdU61SLI+ixotlZgjToHY45Y1/hBHfuGeVDOU7z/to0WP jX/Rxwrt/8sbw== Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:19:32 -0000 On 12/3/13 9:11 AM, Adam Roach wrote: > Based on the conversations we had during the partial offer/partial > answer draft discussion in Vancouver, Martin and I put together a > separate document that formally defines a group identifier for RFC 5888 > SDP groups: > > http://tools.ietf.org/html/draft-roach-mmusic-groupid-00 > > We've made this a separate document because the utility of identifying > groups extends beyond its (upcoming) use in the partial offer/partial > answer draft. > > The document is mercifully short. Feedback is solicited. This is yet another example of the contortions that we are now going through because of the inadequacy of SDP syntax. :-( I find the approach troubling because of strict ordering requirement on attributes. AFAIK this is the first time time I have seen any ordering requirements on attributes other than the session level/media level distinction. Clearly there is a need to bind a group-id to a particular group line, so there must be some ordering requirement. I see no reason that the two lines must be adjacent, but once the need for some attribute ordering has been accepted I guess there is no reason not to accept this stronger requirement. Since group-ids are required to be unique within the session, why is it necessary to include the group semantic in the in-group attribute. IOW, why not: a=in-group abc rather than a=in-group LS:abc It would be "cleaner" (to the extent that anything is clean in SDP) to just define a new alternative grouping syntax that isn't backward compatible. It could be as simple as using an a=in-group attribute (this time including the semantic tag) as the only definer of groups. Is there any great need to preserve backward compatibility here? Thanks, Paul From martin.thomson@gmail.com Tue Dec 3 09:35:46 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E959A1AE194 for ; Tue, 3 Dec 2013 09:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPwYFw6NyePM for ; Tue, 3 Dec 2013 09:35:45 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFC11AE151 for ; Tue, 3 Dec 2013 09:35:45 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u57so8313263wes.9 for ; Tue, 03 Dec 2013 09:35:42 -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=RZBIdzbaWdsx5y1K6N6mgsiWKZQn2E3fi8hxerU64y4=; b=ah0PhbOKqt86IMV1Dbk8R1ABHHcVURZvefj0j/cpUt+GkHAwblMiBtEXK4SDpUoWFw 9XK+3mpPX7S9puX85tnL6MA/KBZx2R/2C5CuXmtcNgxiFU3qMs7QTZZdLLCJDePcKW4i TbCPFDzv+MTFUOZ4hUfXL9IYR1rc5AZmJnin4gecQnDfFDq5T+KYcbsniFAliJzRM3BC WvIRb5I2IKxkyS5c5qGWES44NYVbqsKY1wUyBLMcWEkQruQwpG6bHYX/hLW2Fpin80Ot HAnaH6ppv5Eri1j/jWuqVyGs8GbVyOm6KOq4zuNTT73jp8/nLOKUaJImcrjj6Sv+RK0h fvWQ== MIME-Version: 1.0 X-Received: by 10.180.9.74 with SMTP id x10mr3516268wia.56.1386092142095; Tue, 03 Dec 2013 09:35:42 -0800 (PST) Received: by 10.227.134.195 with HTTP; Tue, 3 Dec 2013 09:35:42 -0800 (PST) In-Reply-To: <529E129F.2080304@alum.mit.edu> References: <529DE6AF.1060300@nostrum.com> <529E129F.2080304@alum.mit.edu> Date: Tue, 3 Dec 2013 09:35:42 -0800 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:35:47 -0000 On 3 December 2013 09:19, Paul Kyzivat wrote: > Is there any great need to preserve backward compatibility here? That's the key question I guess. The question is whether an offer to an unknown entity is required to include grouping semantics that a legacy implementation depends on. In that sense, having two parallel grouping mechanisms in an offer is desirable, I think. In that context, the group-id thing enables an equivalency test. It's really quite optional, and given that we are requiring complete redundancy of the grouping statements, it can be ignored too. >From my perspective, and I can't speak for Adam here, this group-id correlation thingy is the only piece of this puzzle that I'm not that attached to. We could just have a completely parallel grouping semantic. The cost there is that any attempt to maintain and use the 5888 groupings would be impossible once you move to partial offers and answers. (I'd rather keep the semantic on in-group, so that group-id remains optional in this regard.) From pkyzivat@alum.mit.edu Tue Dec 3 09:55:22 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC131AE15F for ; Tue, 3 Dec 2013 09:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.365 X-Spam-Level: ** X-Spam-Status: No, score=2.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZJ48fw_7jlb for ; Tue, 3 Dec 2013 09:55:20 -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 014161AE120 for ; Tue, 3 Dec 2013 09:55:19 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id x15C1m0031GhbT8545vH0D; Tue, 03 Dec 2013 17:55:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id x5vH1m0043ZTu2S3T5vHFE; Tue, 03 Dec 2013 17:55:17 +0000 Message-ID: <529E1B04.5030702@alum.mit.edu> Date: Tue, 03 Dec 2013 12:55:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: mmusic@ietf.org References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386093317; bh=YvYt6y+i2A8kHNMVvaidygNOla63iqgXTdvXOCWLigk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SGP/5lXou4Wx/ObMBPfORKFOwY/fozUa/HXaIUvtFqOFtuuHSyMMykgJ2yhmAOaVt G6De4S2cVBVhAP7Ul4WA91fNBzRGH7WRDImhPvT61lsdComnPrHkLTpczxXrfbNwkJ sthTrW2HjTyKX5oqHWKcqmp95p+KApuXy5rIZqFurmmMShQ9bT98l6e3yZKpKEDBX3 FBKqk5XHAxkat5eGvI/u3qNtLzhu7pVq+Ny5Ywzby6CJUvRChq91N4Zub9W8hah/yu RRy9GfDOo3z1o+++isCAstdJhBWlEUsmMjDUvbGVHAjhJklSxcGcLXaC16KHTmzJJq UkwZu4uYeBU6g== Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:55:22 -0000 ISTM there are major asymmetries here. Whether something can be simulcast can only be determined by the sender. - A sender, when making an offer, can include multiple sendonly streams marked as simulcasts of each other. - A receiver, when presented with an offer containing simulcast, can decide which of the simulcast streams it wants to receive and describe them as recvonly. - A receiver making an offer could indicate that it is interested in receiving simulcast versions of the same source, but only in special cases would it know that it makes sense to send such an offer. Using grouping, there could be an ambiguity whether the goal is simply to receive *one* of the alternative formats, or if the goal is to receive multiple simulcast streams. (Maybe treating them as alternatives can be banned because other techniques should be used to indicate that.) - A sender, when presented with an offer containing simulcast recvonly streams can decide if it is capable of satisfying more than one of those. I *think* the sendrecv case can be treated as just a combination with no new semantics. The answerer would analyze the offer once as a simulcast receiver and once as a simulcast sender. This could result in arbitrary combinations of sendrecv, sendonly, and recvonly in the answer for the m-lines in the simulcast group. Thanks, Paul On 12/2/13 7:15 PM, Bernard Aboba wrote: > Bo Burman said: > > "Should a simulcast-capable endpoint be restricted to be a > simulcast-sender-only or a simulcast-receiver-only, or do we envision > endpoints that are capable of both sending and receiving simulcast? One > example would be if simulcast streams are to be forwarded between > different SFU (using Bernard’s terminology below)." > > If so and assuming that we define a new 5888-type simulcast grouping, do > we need separate groupings for send direction simulcast and receive > direction simulcast, or is a=sendonly and a=recvonly information for > simulcast-grouped media blocks fully sufficient? > > Also, I think the way to use this approach for simulcast in combination > with multiple separate media sources (like multiple cameras) or media > sinks (like multiple displays) would be pretty straightforward; just add > one simulcast grouping per media source/sink." > > [BA] In the case where parallel simulcast streams are being both sent > and received (e.g. between SFUs), there wouldn't be a need for > a=sendonly or a=recvonly lines; each m=line would apply to both sending > and receiving. So it seems like a single simulcast group would > suffice. If you have multiple sources or sinks, then yes, I believe > you would have one simulcast grouping per media source/sink. > > A simple SFU1-SFU2 exchange would look like this: > > Offer: > > v=0 > o=SFU12362969037 2362969040 IN IP4 192.0.2.156 > s=Simulcast Enabled SFU1 > > t=0 0 > c=IN IP4 192.0.2.156 > b=AS:665 > > a=group:SCS1 S2 > m=video 49300 RTP/AVP 97 > b=AS:520 > a=rtpmap:97 H264/90000 > > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 send [x=640,y=360] > > a=mid:S1 > m=video 49302 RTP/AVP 98 > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 send [x=320,y=180] > > a=mid:S2 > > Answer: > > v=0 > o=SFU2 823479283 1209384938 IN IP4 192.0.2.2 > s=Answer to Simulcast Enabled SFU1 > > t=0 0 > c=IN IP4 192.0.2.43 > > b=AS:665 > > a=group:SCS1 S2 > m=video 48000 RTP/AVP 97 > b=AS:520 > > a=rtpmap:97 H264/90000 > > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 recv[x=640,y=360] > > a=mid:S1 > > m=video 48002 RTP/AVP 98 > a=rtpmap:98 H264/90000 > > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 recv[x=320,y=180] > > a=mid:S2 > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bernard Aboba > *Sent:* den 30 november 2013 20:31 > *To:* Christer Holmberg; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast > > Christer asked: > > "In your example, how does the answerer know that the offered m- lines are for simulcast? As far as O/A is concerned, it could just be a number of completely separate (different content etc) uni-directional streams." > > [BA] The most obvious way would be grouping. Looking at RFC 5888/5583, it doesn't appear that either FID or DDP grouping would apply to simulcast. So perhaps a new group type would be needed. > > > > > > Bernard Aboba > wrote: > > > > At IETF 88, a number of participants (including myself) expressed the > view that draft-westerlund-avtcore-rtp-simulcast was too > complicated. Below, I will attempt to explain how simulcast might > be negotiated in a simplified Offer/Answer exchange based on the > principles of Unified Plan. > > Typically in simulcast we have an endpoint sending multiple streams in > parallel to the Selective Forwarding Unit (SFU), while receiving one > among a set of potential streams from the SFU, with the SFU being able > to switch between the streams that it is sending to the endpoint without > signaling. RFC 3264 describes how to handle each of these situations. > > With respect to sending multiple streams in parallel, RFC 3264 Section > 5.1 states the following: > > If the offerer wishes to only send media on a stream to its peer, > it MUST mark the stream as sendonly with the "a=sendonly" attribute. > We refer to a stream as being marked with a certain direction if > a direction attribute was present as either a media stream attribute or > a session attribute. For sendonly RTP streams, the payload type numbers > indicate the value of the payload type field in RTP packet the offerer > is planning to send for that codec... In all cases, the formats in the > "m=" line MUST be listed in order of preference, with the first format > listed being preferred. In this case, preferred means that the > recipient of the offer SHOULD use the format with the highest preference > that is acceptable to it. If multiple media streams of different types > are present, it means that the offerer wishes to use those streams at > the same time. A typical case is an audio and a video stream as part of > a videoconference. > > If multiple media streams of the same type are present in an offer, it > means that the offerer wishes to send (and/or receive) multiple streams > of that type at the same time... Each stream MAY use different encodings. > > > With respect to receiving one among a set of potential streams, here is > what RFC 3264 Section 5.1 says: > > If the offerer wishes to only receive media from its peer, it MUST mark > the stream as recvonly... If multiple formats are listed, it means that > the offerer is capable of making use of any of those formats during the > session. In other words, the answerer MAY change formats in the middle > of the session, making use of any of the formats listed, without sending > a new offer. For a sendonly stream, the offer SHOULD indicate those > formats the offerer is willing to send for this stream. For a recvonly > stream, the offer SHOULD indicate those formats the offerer is willing > to receive for this stream.... > > For recvonly RTP streams, the payload type numbers indicate the value of > the payload type field in RTP packets the offerer is expecting to > receive for that codec. > > > Based on the above: > > 1. An offer from an endpoint to an SFU would include an m=line for each > potential simulcast stream to be sent, each including an a=sendonly > line. The offer would also include a single m=line (with a=recvonly) > describing the streams that the endpoint is prepared to receive, each > with their own payload type. > > 2. An answer from an SFU to an endpoint would accept or reject each of > the simulcast streams that the endpoint is proposing to send (with an > a=recvonly line). In addition, the answer would include a single m=line > (with a=sendonly) indicating the streams from among those proposed by > the endpoint that the SFU is prepared to send. The SFU can then switch > between those streams without having to signal the endpoint. > > Since it is possible for the Answerer to accept/reject each of the > proposed streams the Offerer is proposing to send, an Answerer can > indicate how many streams it is prepared to receive (might only be one > if simulcast isn't supported). Similarly, an Answerer can select those > simulcast streams it is prepared to send (might only be one if simulcast > isn't supported). > > Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): > > v=0 > o=alice 2362969037 2362969040 IN IP4 192.0.2.156 > s=Simulcast Enabled Unified Plan Client > t=0 0 > c=IN IP4 192.0.2.156 > b=AS:665 > m=video 49300 RTP/AVP 97 > a=sendonly > b=AS:520 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 send [x=640,y=360] > m=video 49302 RTP/AVP 98 > a=sendonly > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 send [x=320,y=180] > m=video 49304 RTP/AVP 100 99 > a=recvonly > a=rtpmap:100 H264/90000 > a=fmtp:100 profile-level-id=42c01e > a=imageattr:100 recv [x=640,y=360] > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=42c01e > a=imageattr:99 recv [x=320,y=180] > > > Example Answer: > > v=0 > o=server 823479283 1209384938 IN IP4 192.0.2.2 > s=Answer to Simulcast Enabled Unified Plan Client > t=0 0 > c=IN IP4 192.0.2.43 > b=AS:665 > m=video 48000 RTP/AVP 97 > a=recvonly > b=AS:520 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 recv [x=640,y=360] > m=video 48002 RTP/AVP 98 > a=recvonly > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 recv [x=320,y=180] > m=video 48004 RTP/AVP 100 99 > a=sendonly > a=rtpmap:100 H264/90000 > a=fmtp:100 profile-level-id=42c01e > a=imageattr:100 send [x=640,y=360] > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=42c01e > a=imageattr:100 send [x=320,y=180] > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From bernard_aboba@hotmail.com Tue Dec 3 10:34:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B591AE18B for ; Tue, 3 Dec 2013 10:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym__rz4AjRJm for ; Tue, 3 Dec 2013 10:34:24 -0800 (PST) Received: from blu0-omc3-s31.blu0.hotmail.com (blu0-omc3-s31.blu0.hotmail.com [65.55.116.106]) by ietfa.amsl.com (Postfix) with ESMTP id CF24A1A8032 for ; Tue, 3 Dec 2013 10:34:23 -0800 (PST) Received: from BLU405-EAS272 ([65.55.116.73]) by blu0-omc3-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Dec 2013 10:34:21 -0800 X-TMN: [o2cJdBgNsQDoOSaE+jveDE3qu67bcBLjT9Vd6rac38U=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Paul Kyzivat'" , References: , , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com>, , <529E1B04.5030702@alum.mit.edu> In-Reply-To: <529E1B04.5030702@alum.mit.edu> Date: Tue, 3 Dec 2013 10:34:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQABAgMEFrPAAjyhT49ee4fhSpBQUABxe2YAAFpLq9wAQh3UNAAErMF4ALgtQe+d0EwgoA== Content-Language: en-us X-OriginalArrivalTime: 03 Dec 2013 18:34:21.0274 (UTC) FILETIME=[4864C3A0:01CEF056] Subject: Re: [MMUSIC] Simplifying draft-westerlund-avtcore-rtp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:34:26 -0000 Paul said: "I *think* the sendrecv case can be treated as just a combination with no new semantics. The answerer would analyze the offer once as a simulcast receiver and once as a simulcast sender. This could result in arbitrary combinations of sendrecv, sendonly, and recvonly in the answer for the m-lines in the simulcast group." [BA] Yes. For this SFU-SFU case, the sendrecv m-lines in the Offer that represent different representations from the same source would be included on the a=group:SC line. The Answerer could then decide how many streams it wants to send and receive and mark the streams in the Answer appropriately. Paul also said: "- A receiver making an offer could indicate that it is interested in receiving simulcast versions of the same source, but only in special cases would it know that it makes sense to send such an offer." [BA] Typically a client wouldn't indicate the desire to receive multiple versions of the same source in parallel, that would be something that an SFU would Offer (to a client or another SFU). Paul also said: "Using grouping, there could be an ambiguity whether the goal is simply to receive *one* of the alternative formats, or if the goal is to receive multiple simulcast streams. (Maybe treating them as alternatives can be banned because other techniques should be used to indicate that.)" [BA] If the goal is to receive *one* of the alternative formats, then the alternatives are included on a single m-line (with a=recvonly) as per RFC 3264. If the goal is to receive alternative formats in parallel, then multiple m-lines would be used (again, as suggested in RFC 3264). As to what "mid" identifiers would be included on the a=group:SC line - to me, "simulcast" means that multiple streams from a single source are being sent (or received) in parallel. So for the asymmetric example, I didn't include the "mid" of the single m-line (with a=recvonly) on the a=group:SC line. Paul also said: "- A sender, when presented with an offer containing simulcast recvonly streams can decide if it is capable of satisfying more than one of those." [BA] If the Offer contains multiple m-lines marked "recvonly" that represent different streams from the same source to be sent in parallel, this means that the Offerer wants to receive simulcast, and so those m-lines would be included in a simulcast group. The Answerer could then decide if it wanted to send more than one stream. Thanks, Paul On 12/2/13 7:15 PM, Bernard Aboba wrote: > Bo Burman said: > > "Should a simulcast-capable endpoint be restricted to be a > simulcast-sender-only or a simulcast-receiver-only, or do we envision > endpoints that are capable of both sending and receiving simulcast? > One example would be if simulcast streams are to be forwarded between > different SFU (using Bernard's terminology below)." > > If so and assuming that we define a new 5888-type simulcast grouping, > do we need separate groupings for send direction simulcast and receive > direction simulcast, or is a=sendonly and a=recvonly information for > simulcast-grouped media blocks fully sufficient? > > Also, I think the way to use this approach for simulcast in > combination with multiple separate media sources (like multiple > cameras) or media sinks (like multiple displays) would be pretty > straightforward; just add one simulcast grouping per media source/sink." > > [BA] In the case where parallel simulcast streams are being both sent > and received (e.g. between SFUs), there wouldn't be a need for > a=sendonly or a=recvonly lines; each m=line would apply to both > sending and receiving. So it seems like a single simulcast group would > suffice. If you have multiple sources or sinks, then yes, I believe > you would have one simulcast grouping per media source/sink. > > A simple SFU1-SFU2 exchange would look like this: > > Offer: > > v=0 > o=SFU12362969037 2362969040 IN IP4 192.0.2.156 s=Simulcast Enabled > SFU1 > > t=0 0 > c=IN IP4 192.0.2.156 > b=AS:665 > > a=group:SCS1 S2 > m=video 49300 RTP/AVP 97 > b=AS:520 > a=rtpmap:97 H264/90000 > > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 send [x=640,y=360] > > a=mid:S1 > m=video 49302 RTP/AVP 98 > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 send [x=320,y=180] > > a=mid:S2 > > Answer: > > v=0 > o=SFU2 823479283 1209384938 IN IP4 192.0.2.2 s=Answer to Simulcast > Enabled SFU1 > > t=0 0 > c=IN IP4 192.0.2.43 > > b=AS:665 > > a=group:SCS1 S2 > m=video 48000 RTP/AVP 97 > b=AS:520 > > a=rtpmap:97 H264/90000 > > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 recv[x=640,y=360] > > a=mid:S1 > > m=video 48002 RTP/AVP 98 > a=rtpmap:98 H264/90000 > > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 recv[x=320,y=180] > > a=mid:S2 > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bernard > Aboba > *Sent:* den 30 november 2013 20:31 > *To:* Christer Holmberg; mmusic@ietf.org > *Subject:* Re: [MMUSIC] Simplifying > draft-westerlund-avtcore-rtp-simulcast > > Christer asked: > > "In your example, how does the answerer know that the offered m- lines are for simulcast? As far as O/A is concerned, it could just be a number of completely separate (different content etc) uni-directional streams." > > [BA] The most obvious way would be grouping. Looking at RFC 5888/5583, it doesn't appear that either FID or DDP grouping would apply to simulcast. So perhaps a new group type would be needed. > > > > > > Bernard Aboba > wrote: > > > > At IETF 88, a number of participants (including myself) expressed the > view that draft-westerlund-avtcore-rtp-simulcast was too complicated. > Below, I will attempt to explain how simulcast might be negotiated in > a simplified Offer/Answer exchange based on the principles of Unified > Plan. > > Typically in simulcast we have an endpoint sending multiple streams in > parallel to the Selective Forwarding Unit (SFU), while receiving one > among a set of potential streams from the SFU, with the SFU being able > to switch between the streams that it is sending to the endpoint > without signaling. RFC 3264 describes how to handle each of these situations. > > With respect to sending multiple streams in parallel, RFC 3264 Section > 5.1 states the following: > > If the offerer wishes to only send media on a stream to its peer, it > MUST mark the stream as sendonly with the "a=sendonly" attribute. > We refer to a stream as being marked with a certain direction if a > direction attribute was present as either a media stream attribute or > a session attribute. For sendonly RTP streams, the payload type > numbers indicate the value of the payload type field in RTP packet the > offerer is planning to send for that codec... In all cases, the > formats in the "m=" line MUST be listed in order of preference, with > the first format listed being preferred. In this case, preferred > means that the recipient of the offer SHOULD use the format with the > highest preference that is acceptable to it. If multiple media streams > of different types are present, it means that the offerer wishes to > use those streams at the same time. A typical case is an audio and a > video stream as part of a videoconference. > > If multiple media streams of the same type are present in an offer, > it means that the offerer wishes to send (and/or receive) multiple > streams of that type at the same time... Each stream MAY use different encodings. > > > With respect to receiving one among a set of potential streams, here > is what RFC 3264 Section 5.1 says: > > If the offerer wishes to only receive media from its peer, it MUST > mark the stream as recvonly... If multiple formats are listed, it > means that the offerer is capable of making use of any of those > formats during the session. In other words, the answerer MAY change > formats in the middle of the session, making use of any of the formats > listed, without sending a new offer. For a sendonly stream, the offer > SHOULD indicate those formats the offerer is willing to send for this > stream. For a recvonly stream, the offer SHOULD indicate those > formats the offerer is willing to receive for this stream.... > > For recvonly RTP streams, the payload type numbers indicate the value > of the payload type field in RTP packets the offerer is expecting to > receive for that codec. > > > Based on the above: > > 1. An offer from an endpoint to an SFU would include an m=line for > each potential simulcast stream to be sent, each including an > a=sendonly line. The offer would also include a single m=line (with > a=recvonly) describing the streams that the endpoint is prepared to > receive, each with their own payload type. > > 2. An answer from an SFU to an endpoint would accept or reject each of > the simulcast streams that the endpoint is proposing to send (with an > a=recvonly line). In addition, the answer would include a single > m=line (with a=sendonly) indicating the streams from among those > proposed by the endpoint that the SFU is prepared to send. The SFU > can then switch between those streams without having to signal the endpoint. > > Since it is possible for the Answerer to accept/reject each of the > proposed streams the Offerer is proposing to send, an Answerer can > indicate how many streams it is prepared to receive (might only be one > if simulcast isn't supported). Similarly, an Answerer can select those > simulcast streams it is prepared to send (might only be one if > simulcast isn't supported). > > Example Offer (leaving out BUNDLE, rtp/rtcp multiplexing, and audio): > > v=0 > o=alice 2362969037 2362969040 IN IP4 192.0.2.156 > s=Simulcast Enabled Unified Plan Client > t=0 0 > c=IN IP4 192.0.2.156 > b=AS:665 > m=video 49300 RTP/AVP 97 > a=sendonly > b=AS:520 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 send [x=640,y=360] > m=video 49302 RTP/AVP 98 > a=sendonly > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 send [x=320,y=180] > m=video 49304 RTP/AVP 100 99 > a=recvonly > a=rtpmap:100 H264/90000 > a=fmtp:100 profile-level-id=42c01e > a=imageattr:100 recv [x=640,y=360] > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=42c01e > a=imageattr:99 recv [x=320,y=180] > > > Example Answer: > > v=0 > o=server 823479283 1209384938 IN IP4 192.0.2.2 > s=Answer to Simulcast Enabled Unified Plan Client > t=0 0 > c=IN IP4 192.0.2.43 > b=AS:665 > m=video 48000 RTP/AVP 97 > a=recvonly > b=AS:520 > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42c01e > a=imageattr:97 recv [x=640,y=360] > m=video 48002 RTP/AVP 98 > a=recvonly > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=42c01e > a=imageattr:98 recv [x=320,y=180] > m=video 48004 RTP/AVP 100 99 > a=sendonly > a=rtpmap:100 H264/90000 > a=fmtp:100 profile-level-id=42c01e > a=imageattr:100 send [x=640,y=360] > a=rtpmap:99 H264/90000 > a=fmtp:99 profile-level-id=42c01e > a=imageattr:100 send [x=320,y=180] > > > > _______________________________________________ > 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 Tue Dec 3 10:47:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390E21AE018 for ; Tue, 3 Dec 2013 10:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKRSRg4nSuCu for ; Tue, 3 Dec 2013 10:47:31 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6521AE0C5 for ; Tue, 3 Dec 2013 10:47:30 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-69-529e273f8b2e Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id AB.6D.22496.F372E925; Tue, 3 Dec 2013 19:47:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 19:47:27 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] New Draft: SDP Grouping Identifiers Thread-Index: AQHO8DGoMkkD/YYgU0+O4sL8daxpcZpCpnyAgAAogjM= Date: Tue, 3 Dec 2013 18:47:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C569222@ESESSMB209.ericsson.se> References: <529DE6AF.1060300@nostrum.com>,<529E129F.2080304@alum.mit.edu> In-Reply-To: <529E129F.2080304@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvra69+rwgg+2dZhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx/PtSpoItwhV3O3ewNDA+4O9i5OSQEDCR 2PSznxnCFpO4cG89WxcjF4eQwAlGiQvPl0M5ixgl5i95yt7FyMHBJmAh0f1PG6RBRMBX4tnj 22wgYWEBS4l9t+UhwlYSiz/OZISxbx7sBrNZBFQkmradYgGxeYFap279xARiCwl4SRw6eJUN xOYU0JHY0PkJ7B5GoHu+n1oDVsMsIC5x68l8Jog7BSSW7DkPdbOoxMvH/1hBTpAQUJKYtjUN olxHYsHuT2wQtrbEsoWvmSHWCkqcnPmEZQKj6CwkU2chaZmFpGUWkpYFjCyrGCWLU4uLc9ON DPRy03NL9FKLMpOLi/Pz9IpTNzECY+Xglt9GOxhP7rE/xCjNwaIkznudtSZISCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA6PwqS1PHgr6FzQlnz97+osNU8bbqc6BDG//nJzcljf36ZVXGXES FxX2rbZZcfln6DcfVYbLb5efrtvlNvO/UXhnscGh4t26zzR2xl1Kn9ytr1N1YsvPK0GL5P9M ypPIzH1Qty5ZZ6GbxDr9RSyvpdlrq8oCFS0mXKr2Mvdbz1rI+MWT+fgnfSMlluKMREMt5qLi RAAsrvICYwIAAA== Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:47:33 -0000 Hi, I share Paul's concern regarding mandating a specific order. There are parsers that do not necessarily keep the order when parsing an SD= P body, why e.g. something that "enter" a SIP proxy is not necessarily what= "comes out". Regards, Christer ________________________________________ From: mmusic [mmusic-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@= alum.mit.edu] Sent: Tuesday, 03 December 2013 7:19 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers On 12/3/13 9:11 AM, Adam Roach wrote: > Based on the conversations we had during the partial offer/partial > answer draft discussion in Vancouver, Martin and I put together a > separate document that formally defines a group identifier for RFC 5888 > SDP groups: > > http://tools.ietf.org/html/draft-roach-mmusic-groupid-00 > > We've made this a separate document because the utility of identifying > groups extends beyond its (upcoming) use in the partial offer/partial > answer draft. > > The document is mercifully short. Feedback is solicited. This is yet another example of the contortions that we are now going through because of the inadequacy of SDP syntax. :-( I find the approach troubling because of strict ordering requirement on attributes. AFAIK this is the first time time I have seen any ordering requirements on attributes other than the session level/media level distinction. Clearly there is a need to bind a group-id to a particular group line, so there must be some ordering requirement. I see no reason that the two lines must be adjacent, but once the need for some attribute ordering has been accepted I guess there is no reason not to accept this stronger requirement. Since group-ids are required to be unique within the session, why is it necessary to include the group semantic in the in-group attribute. IOW, why not: a=3Din-group abc rather than a=3Din-group LS:abc It would be "cleaner" (to the extent that anything is clean in SDP) to just define a new alternative grouping syntax that isn't backward compatible. It could be as simple as using an a=3Din-group attribute (this time including the semantic tag) as the only definer of groups. Is there any great need to preserve backward compatibility here? Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From adam@nostrum.com Tue Dec 3 15:02:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4E31AE1BC for ; Tue, 3 Dec 2013 15:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBIV3A0AV83H for ; Tue, 3 Dec 2013 15:02:39 -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 C2D671ADF76 for ; Tue, 3 Dec 2013 15:02:39 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3N2X9o041928 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 17:02:33 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529E6304.6080807@nostrum.com> Date: Tue, 03 Dec 2013 17:02:28 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" References: <529DE6AF.1060300@nostrum.com>, <529E129F.2080304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C569222@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C569222@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------030207080400080303080801" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:02:40 -0000 This is a multi-part message in MIME format. --------------030207080400080303080801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/3/13 12:47, Christer Holmberg wrote: > There are parsers that do not necessarily keep the order when parsing an SDP body, why e.g. something that "enter" a SIP proxy is not necessarily what "comes out". That would be folly, as we already (even in the base spec) have the idea of order significance; e.g.: Multiple sdplang attributes can be provided either at session or media level if multiple languages in the session description or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media from most important to least important. /a --------------030207080400080303080801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 12/3/13 12:47, Christer Holmberg wrote:
There are parsers that do not necessarily keep the order when parsing an SDP body, why e.g. something that "enter" a SIP proxy is not necessarily what "comes out".

That would be folly, as we already (even in the base spec) have the idea of order significance; e.g.:

         Multiple sdplang
         attributes can be provided either at session or media level if
         multiple languages in the session description or media use
         multiple languages, in which case the order of the attributes
         indicates the order of importance of the various languages in
         the session or media from most important to least important.

/a
--------------030207080400080303080801-- From adam@nostrum.com Tue Dec 3 15:05:38 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36741AE1BC for ; Tue, 3 Dec 2013 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2aaQO13taKD for ; Tue, 3 Dec 2013 15:05:37 -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 659351AE1CF for ; Tue, 3 Dec 2013 15:05:25 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3N5IQP042054 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 17:05:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529E63A9.9090302@nostrum.com> Date: Tue, 03 Dec 2013 17:05:13 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Paul Kyzivat , mmusic@ietf.org References: <529DE6AF.1060300@nostrum.com> <529E129F.2080304@alum.mit.edu> In-Reply-To: <529E129F.2080304@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:05:38 -0000 On 12/3/13 11:19, Paul Kyzivat wrote: > Since group-ids are required to be unique within the session, why is > it necessary to include the group semantic in the in-group attribute. > IOW, > why not: > a=in-group abc > rather than > a=in-group LS:abc The idea behind the syntax here is that you can implicitly define a new group in a partial offer without having to include any session-level attributes. I'll admit that there are other ways to address this capability, but this is the one I prefer. /a From adam@nostrum.com Tue Dec 3 15:06:50 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5D21AE1BC for ; Tue, 3 Dec 2013 15:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17RN-jLA7onp for ; Tue, 3 Dec 2013 15:06:49 -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 B80A51ADF51 for ; Tue, 3 Dec 2013 15:06:49 -0800 (PST) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB3N6eD7042115 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 17:06:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <529E63FB.1060801@nostrum.com> Date: Tue, 03 Dec 2013 17:06:35 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Thomson , Paul Kyzivat References: <529DE6AF.1060300@nostrum.com> <529E129F.2080304@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:06:50 -0000 On 12/3/13 11:35, Martin Thomson wrote: > From my perspective, and I can't speak for Adam here, this group-id > correlation thingy is the only piece of this puzzle that I'm not that > attached to. We could just have a completely parallel grouping > semantic. The cost there is that any attempt to maintain and use the > 5888 groupings would be impossible once you move to partial offers and > answers. Yeah, that would make me sad. I don't want to develop a parallel grouping semantic to compete with 5888 -- just some mechanism to fix a relatively minor (but important) shortcoming. /a From casner@acm.org Tue Dec 3 20:46:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE43A1AE1C6 for ; Tue, 3 Dec 2013 20:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBgf3NRnr2cY for ; Tue, 3 Dec 2013 20:46:30 -0800 (PST) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAB1AE1BB for ; Tue, 3 Dec 2013 20:46:30 -0800 (PST) Received: from packetdesign.com (vpn2-int.packetdesign.com [192.168.0.181]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id rB44kJYI019528; Tue, 3 Dec 2013 20:46:19 -0800 Date: Tue, 3 Dec 2013 20:46:19 -0800 (PST) From: Stephen Casner To: SM In-Reply-To: <6.2.5.6.2.20131203010105.0db5d630@resistor.net> Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <016b01ceed2f$0be29e90$23a7dbb0$@co.in> <6.2.5.6.2.20131203010105.0db5d630@resistor.net> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Flemming Andreasen , Ari Kerdnen , mmusic@ietf.org Subject: Re: [MMUSIC] RFC 4856 is in the correct RFC category - Errata query? [was RE: Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 04:46:32 -0000 On Tue, 3 Dec 2013, SM wrote: > Hi Stephen, > At 08:52 02-12-2013, Stephen Casner wrote: > > I believe the status of RFC 4856 is correct. It updates RFC 3555 to > > define and register the media types for the RTP profile RFC 3551. > > What other status would be more appropriate for that ? > > There was an assumption that the status chosen for some previous RFC is > correct. The problem might have been with RFC 3555. It is better not to look > at the details of those old RFCs too closely. :-) Since I am the author of the RFCs listed above, I dispute that. I assert that standards track is correct for all of these. There is nothing about them that is merely a "best current practice". -- Steve From mperumal@cisco.com Tue Dec 3 22:28:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBD91AE04F for ; Tue, 3 Dec 2013 22:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnDus_hboijI for ; Tue, 3 Dec 2013 22:28:43 -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 122491ADBD0 for ; Tue, 3 Dec 2013 22:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1330; q=dns/txt; s=iport; t=1386138520; x=1387348120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9ycHNWdql4wXmh+nGTgLb3jHbjVavXBu8NPU/CV4ZsI=; b=W4w+roE4YDnUJxGhWroEPXBa+WgDMmVVEFTS0bE53jAgRok5+KHAgdkj RWB9uSYfblIpl2FZcjNuoZ8D0+Rzgp/UoV6h9nw+/QSHY9YxOs5bv7FBS 1QzKS7v32k+M4PlqN1esPn+7xzO1U/90ZCwioW0+QWV1CIwNRSeeFWxpB k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFACrLnlKtJV2c/2dsb2JhbABagwc4U7h1gR8WdIIlAQEBBHkMBAIBCBEEAQELGQQHMhQJCAIEAQ0FCAGHeA3BLReOTTEHBoMagRMDiQqhHYFrgT6CKg X-IronPort-AV: E=Sophos;i="4.93,822,1378857600"; d="scan'208";a="289051260" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 04 Dec 2013 06:28:40 +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 rB46SdnG019234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 06:28:39 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 00:28:39 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: SM , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO8LoRVReqMavV/kKa4DasfRoocQ== Date: Wed, 4 Dec 2013 06:28:38 +0000 Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> In-Reply-To: <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 06:28:44 -0000 |I was referring to media type registrations for IANA action. That is |different from the intended status. Sorry, not clear to me. Can you provide some examples? Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any IANA action (see = the IANA Considerations section). So, why should it be published as an Info= rmational RFC? Muthu=20 |-----Original Message----- |From: SM [mailto:sm@resistor.net] |Sent: Tuesday, December 03, 2013 2:44 PM |To: Muthu Arul Mozhi Perumal (mperumal); Ari Ker=E4nen |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |Subject: RE: [MMUSIC] Last Call: = (Offer/Answer Considerations |for G723 Annex A and G729 Annex B) to Proposed Standard | |Hi Muthu, |At 05:51 02-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: |>|Media type registrations are usually published as Informational RFCs. |>|I suggest publishing draft-ietf-mmusic-sdp-g723-g729-04 as an |>Information RFC. |> |>Registered audio media types are listed here: |>http://www.iana.org/assignments/media-types/audio |> |>As you can see most of them are described in Standards Track RFCs, |>so your observation is incorrect. | |I was referring to media type registrations for IANA action. That is |different from the intended status. | |Regards, |-sm From christer.holmberg@ericsson.com Wed Dec 4 04:11:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9111AE10C for ; Wed, 4 Dec 2013 04:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mudDbWEDv-mV for ; Wed, 4 Dec 2013 04:11:47 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 381F31ADFA0 for ; Wed, 4 Dec 2013 04:11:46 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-e4-529f1bfefcc6 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CD.2B.27941.EFB1F925; Wed, 4 Dec 2013 13:11:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0347.000; Wed, 4 Dec 2013 13:11:41 +0100 From: Christer Holmberg To: Adam Roach , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] New Draft: SDP Grouping Identifiers Thread-Index: AQHO8DGoMkkD/YYgU0+O4sL8daxpcZpCpnyAgAAogjOAADdUAIAA7O6g Date: Wed, 4 Dec 2013 12:11:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C56A189@ESESSMB209.ericsson.se> References: <529DE6AF.1060300@nostrum.com>,<529E129F.2080304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C569222@ESESSMB209.ericsson.se> <529E6304.6080807@nostrum.com> In-Reply-To: <529E6304.6080807@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C56A189ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre4/6flBBqv3qVns+buI3WLq8scs Fis2HGB1YPb4+/4Dk8eSJT+ZPGbtfMISwBzFZZOSmpNZllqkb5fAlTFpqnTBK++KK09vMzYw 3vHsYuTgkBAwkTjzUb6LkRPIFJO4cG89WxcjF4eQwBFGiY+Tt7JAOIsYJc4d/sQG0sAmYCHR /U8bpEFEIE/ix4ftLCBhYQFLiX235SHCVhKLP85khLDdJB6+6QazWQRUJLbtWMIMYvMK+Eqc frSEHWL8eqBd8w+DFXEKaEv82jcFzGYEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc8M4QtKvHy 8T9WCFtR4ur05VD1+RL/tx9ihFgmKHFy5hOWCYwis5CMmoWkbBaSsllA7zALaEqs36UPUaIo MaX7ITuErSHROmcuO7L4Akb2VYwcxanFSbnpRgabGIGxdHDLb4sdjJf/2hxilOZgURLn/fjW OUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo3pu41ShL8FuZZovox988BG/P1W4ecbXfQr6 DvuZXP4U2vgsCmuvPhT+yCLykP4cwd7au35BbRwveGwea/dbRSUuaFww19axPrszoaVdV3D6 y0sFRxf4tCmI7Px9s7qI18NC8PkMy19tJxc+PsizzHnqBpN1v7Z6Xg+M6a7mU3n3Z46y7hpd JZbijERDLeai4kQACoOeL3MCAAA= Subject: Re: [MMUSIC] New Draft: SDP Grouping Identifiers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:11:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C56A189ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkp1c3QgYmVjYXVzZSB3ZSBoYXZlIGRvbmUgc29tZXRoaW5nIHdyb25nIGluIHRoZSBw YXN0LCB3ZSBkb27igJl0IGhhdmUgdG8gZG8gaXQgYWdhaW4gOikNCg0KQWxzbywgSSBkb27igJl0 IHRoaW5rIHJlLW9yZGVyaW5nIG9mIHNkcGxhbmcgYXR0cmlidXRlcyB3b3VsZCBjYXVzZSBhIHRl Y2huaWNhbCBlcnJvci4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQWRhbSBSb2Fj aCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQpTZW50OiA0LiBqb3VsdWt1dXRhIDIwMTMgMTow Mg0KVG86IENocmlzdGVyIEhvbG1iZXJnOyBQYXVsIEt5eml2YXQ7IG1tdXNpY0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtNTVVTSUNdIE5ldyBEcmFmdDogU0RQIEdyb3VwaW5nIElkZW50aWZpZXJz DQoNCk9uIDEyLzMvMTMgMTI6NDcsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KDQpUaGVyZSBh cmUgcGFyc2VycyB0aGF0IGRvIG5vdCBuZWNlc3NhcmlseSBrZWVwIHRoZSBvcmRlciB3aGVuIHBh cnNpbmcgYW4gU0RQIGJvZHksIHdoeSBlLmcuIHNvbWV0aGluZyB0aGF0ICJlbnRlciIgYSBTSVAg cHJveHkgaXMgbm90IG5lY2Vzc2FyaWx5IHdoYXQgImNvbWVzIG91dCIuDQoNClRoYXQgd291bGQg YmUgZm9sbHksIGFzIHdlIGFscmVhZHkgKGV2ZW4gaW4gdGhlIGJhc2Ugc3BlYykgaGF2ZSB0aGUg aWRlYSBvZiBvcmRlciBzaWduaWZpY2FuY2U7IGUuZy46DQoNCiAgICAgICAgIE11bHRpcGxlIHNk cGxhbmcNCg0KICAgICAgICAgYXR0cmlidXRlcyBjYW4gYmUgcHJvdmlkZWQgZWl0aGVyIGF0IHNl c3Npb24gb3IgbWVkaWEgbGV2ZWwgaWYNCg0KICAgICAgICAgbXVsdGlwbGUgbGFuZ3VhZ2VzIGlu IHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uIG9yIG1lZGlhIHVzZQ0KDQogICAgICAgICBtdWx0aXBs ZSBsYW5ndWFnZXMsIGluIHdoaWNoIGNhc2UgdGhlIG9yZGVyIG9mIHRoZSBhdHRyaWJ1dGVzDQoN CiAgICAgICAgIGluZGljYXRlcyB0aGUgb3JkZXIgb2YgaW1wb3J0YW5jZSBvZiB0aGUgdmFyaW91 cyBsYW5ndWFnZXMgaW4NCg0KICAgICAgICAgdGhlIHNlc3Npb24gb3IgbWVkaWEgZnJvbSBtb3N0 IGltcG9ydGFudCB0byBsZWFzdCBpbXBvcnRhbnQuDQoNCi9hDQo= --_000_7594FB04B1934943A5C02806D1A2204B1C56A189ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3QgYmVjYXVzZSB3 ZSBoYXZlIGRvbmUgc29tZXRoaW5nIHdyb25nIGluIHRoZSBwYXN0LCB3ZSBkb27igJl0IGhhdmUg dG8gZG8gaXQgYWdhaW4gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28sIEkgZG9u4oCZdCB0aGluayByZS1vcmRl cmluZyBvZiBzZHBsYW5nIGF0dHJpYnV0ZXMgd291bGQgY2F1c2UgYSB0ZWNobmljYWwgZXJyb3Iu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBBZGFtIFJvYWNoIFttYWlsdG86 YWRhbUBub3N0cnVtLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiA0LiBqb3VsdWt1dXRhIDIwMTMg MTowMjxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc7IFBhdWwgS3l6aXZhdDsgbW11 c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBOZXcgRHJhZnQ6 IFNEUCBHcm91cGluZyBJZGVudGlmaWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMi8zLzEzIDEyOjQ3LCBDaHJpc3RlciBIb2xtYmVy ZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlRoZXJlIGFyZSBwYXJzZXJz IHRoYXQgZG8gbm90IG5lY2Vzc2FyaWx5IGtlZXAgdGhlIG9yZGVyIHdoZW4gcGFyc2luZyBhbiBT RFAgYm9keSwgd2h5IGUuZy4gc29tZXRoaW5nIHRoYXQgJnF1b3Q7ZW50ZXImcXVvdDsgYSBTSVAg cHJveHkgaXMgbm90IG5lY2Vzc2FyaWx5IHdoYXQgJnF1b3Q7Y29tZXMgb3V0JnF1b3Q7LjxvOnA+ PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClRoYXQgd291bGQgYmUgZm9sbHksIGFzIHdlIGFs cmVhZHkgKGV2ZW4gaW4gdGhlIGJhc2Ugc3BlYykgaGF2ZSB0aGUgaWRlYSBvZiBvcmRlciBzaWdu aWZpY2FuY2U7IGUuZy46PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNdWx0aXBsZSBzZHBsYW5nPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGF0dHJpYnV0ZXMgY2FuIGJlIHByb3ZpZGVkIGVpdGhlciBhdCBzZXNzaW9uIG9yIG1lZGlh IGxldmVsIGlmPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIGxhbmd1YWdlcyBpbiB0aGUgc2Vzc2lv biBkZXNjcmlwdGlvbiBvciBtZWRpYSB1c2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGlwbGUgbGFuZ3Vh Z2VzLCBpbiB3aGljaCBjYXNlIHRoZSBvcmRlciBvZiB0aGUgYXR0cmlidXRlczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpbmRpY2F0ZXMgdGhlIG9yZGVyIG9mIGltcG9ydGFuY2Ugb2YgdGhlIHZhcmlvdXMgbGFu Z3VhZ2VzIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBzZXNzaW9uIG9yIG1lZGlhIGZyb20gbW9zdCBp bXBvcnRhbnQgdG8gbGVhc3QgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQovYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1C56A189ESESSMB209erics_-- From ari.keranen@ericsson.com Wed Dec 4 05:15:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989471AE131 for ; Wed, 4 Dec 2013 05:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88p_5475x-1E for ; Wed, 4 Dec 2013 05:15:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB111AE128 for ; Wed, 4 Dec 2013 05:15:03 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-2d-529f2ad4aeb3 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 55.BB.03802.4DA2F925; Wed, 4 Dec 2013 14:15:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.347.0; Wed, 4 Dec 2013 14:15:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0B4F9110209; Wed, 4 Dec 2013 15:15:00 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DD52E5556D; Wed, 4 Dec 2013 15:14:57 +0200 (EET) Received: from tri60.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8A4B54E87A; Wed, 4 Dec 2013 15:14:57 +0200 (EET) Message-ID: <529F2AD3.2020205@ericsson.com> Date: Wed, 4 Dec 2013 15:14:59 +0200 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: SM References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <529CA719.3090007@ericsson.com> <6.2.5.6.2.20131203011347.0db5d4e8@resistor.net> In-Reply-To: <6.2.5.6.2.20131203011347.0db5d4e8@resistor.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvre4VrflBBp+uq1m8v6BrMXX5YxaL yZ/6WC2ObzjE7sDiMeX3RlaPJUt+Mnl8mP+F3eN99zO2AJYoLpuU1JzMstQifbsEroym37NZ Ci6wVOy5v5qtgfE0cxcjJ4eEgInE3sdX2SBsMYkL99YD2VwcQgKHGCV+Tf4K5axnlDjd+YMZ wtnDKLHq8QVGkBYhgbWMEif+OEEkljNKbLv2jAkkwSugLfHiyj+wuSwCKhJPZ85gBbHZBOwl bk64zg5iiwokS2xu62GGqBeUODnzCQuILSIgIbF340qwOcwCeRI3du9kAlkgLLCIUeLmzcdQ N31llpj0+TPYGZwCthJXFp5gg+iwlbgw5zoLhC0v0bx1NtSnahJXz21ihjhbVeLqv1eMExhF ZyFZPgtJ+ywk7QsYmVcxsucmZuaklxttYgTGyMEtv1V3MN45J3KIUZqDRUmc98Nb5yAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjAsfhAnreeZ0BCdZOHgVNZbO8Fvc08AmNkVc7sRfnZzm qZlXlrNfOhP6Y3OpVbHIqta/3dxLdY0OhMkcZ97rkZ7/uHvH1sL7xxS7UovO3ZQ5c+pTCr8U V3fZeY9FqSfC/y6wO3L3d9tB4aU2vKm/rdIsI6VfbbgxlePk9l6uRaeTD5vfO3ToihJLcUai oRZzUXEiAEb4zzdfAgAA Cc: Flemming Andreasen , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:15:06 -0000 Hi SM, On 12/3/13 11:44 AM, SM wrote: > At 07:28 02-12-2013, Ari Keränen wrote: >> As Partha & Muthu already mentioned, there was discussion and a >> consensus call on the type of the document and the consensus was that >> PS is the correct type. Admittedly the proto write-up could have been >> a bit more elaborate on that. > > Thanks for the response. In my humble opinion it is not worth the > effort to look into the details of the process if that can be avoided. Makes sense. I think it's best we go forward with the document using the current type. Cheers, Ari From sm@resistor.net Wed Dec 4 08:12:05 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B11AE155 for ; Wed, 4 Dec 2013 08:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34oTcY8fC1-j for ; Wed, 4 Dec 2013 08:12:04 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BDB1AE2D4 for ; Wed, 4 Dec 2013 08:11:58 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB4GBi57013771; Wed, 4 Dec 2013 08:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386173511; bh=zlYH4qS+HMNkrTH3LZMkq4+56AMJITZT+KOb61LhXls=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=omuvtXQTV/lZ98bpvRgAm0FrgkiJQdholtXVY8KLnlpOawfo28e+ELD4V5ilaumN0 X+5uTBmRK3BGMjjX8bYkvoWmOsKHm/zBesR9IRpCdi2yFIIWxzTtax2LUh8sEJK9rG 6K6dWsD1ngd92CK4C16BsTGzLaN6R8ymvLmENcs4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386173511; i=@resistor.net; bh=zlYH4qS+HMNkrTH3LZMkq4+56AMJITZT+KOb61LhXls=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qU4hkQgckathwOQMVkBICXFXC7pstEzjXgSmAqYw1JUqKoegGABgjljsrv5V93qIK u0LtYv4f7rmzJHMQAraz5XE6Ou3zOzsdPUoNPzJsDFh/1qJWv5vtKmT+fhF2zC5CGZ 3u0nJIWQ+LiI5Ev6PgoxFftCRZUQ7KYYhqeTOBg8= Message-Id: <6.2.5.6.2.20131204072722.0e064590@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Dec 2013 08:11:17 -0800 To: "Muthu Arul Mozhi Perumal (mperumal)" , Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:12:05 -0000 Hi Muthu, At 22:28 03-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: >Sorry, not clear to me. Can you provide some examples? As an example: "The reproduction of the [RFC4695] IANA considerations section appears directly below. This section makes a series of requests to IANA. The IANA has completed registration/assignments of the below requests." Please note that I picked one at random. >Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any IANA >action (see the IANA Considerations section). So, why should it be >published as an Informational RFC? The issue (using the word loosely) is that the draft is referring to a registration request in Section 1.1 of RFC 4856 which is about IANA Considerations. My argument is that the working group has not provide an explanation about why the proposal should be published on the Standards Track. Instead of objecting to the publication as a RFC I suggested publishing the proposal as an Informational RFC. Regards, -sm From mperumal@cisco.com Wed Dec 4 09:08:24 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8C1AE182 for ; Wed, 4 Dec 2013 09:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbc6_vgITsNq for ; Wed, 4 Dec 2013 09:08:23 -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 3C2891AE006 for ; Wed, 4 Dec 2013 09:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1933; q=dns/txt; s=iport; t=1386176900; x=1387386500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tr09wBL74NSHolSswkLkGK/rtDwQ/NAltjsS/jTN6W0=; b=k/ZYVBt4pY76njdS4Jlwwql0WDg+b6sZRMfMtu1e6FmgYGcjGyrTKKu2 b8aMQgSh6Y6h73GCO4Uor+otNuCK/ecFOeJ8ogLm/sy6L8Q5gvmA9lsyo kRzdUL5qgDpmTVKaNNyrEiTQYfDOgxAJVbiJT30QJpXvZgTNIy9wRB3+c Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMRgn1KtJV2Z/2dsb2JhbABagweBC7hjgSQWdIIlAQEBBHkMBAIBCBEEAQELGQQHMhQJCAIEAQ0FCId6wXcXjk0xBwaDGoETA4kKoR2Ba4E+gio X-IronPort-AV: E=Sophos;i="4.93,825,1378857600"; d="scan'208";a="289353132" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 04 Dec 2013 17:08:20 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB4H8KSr030811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 17:08:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:08:19 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: SM , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO8RNtfwsIvulZkESVkyH00wN6Ag== Date: Wed, 4 Dec 2013 17:08:18 +0000 Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> In-Reply-To: <6.2.5.6.2.20131204072722.0e064590@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.74] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:08:25 -0000 Hi SM, |-----Original Message----- |From: SM [mailto:sm@resistor.net] |Sent: Wednesday, December 04, 2013 9:41 PM |To: Muthu Arul Mozhi Perumal (mperumal); Ari Ker=E4nen |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |Subject: RE: [MMUSIC] Last Call: = (Offer/Answer Considerations |for G723 Annex A and G729 Annex B) to Proposed Standard | |Hi Muthu, |At 22:28 03-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: |>Sorry, not clear to me. Can you provide some examples? | |As an example: | | "The reproduction of the [RFC4695] IANA considerations section appears | directly below. | | This section makes a series of requests to IANA. The IANA has | completed registration/assignments of the below requests." | |Please note that I picked one at random. | |>Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any IANA |>action (see the IANA Considerations section). So, why should it be |>published as an Informational RFC? | |The issue (using the word loosely) is that the draft is referring to |a registration request in Section 1.1 of RFC 4856 which is about IANA |Considerations. =20 Yes, is referring to that section of RFC4856. However, the issue is not the= registration itself -- it is to do with the missing offer/answer considera= tions for the registered media parameters that impact interoperability. As = an example, RFC4352 registers AMR-WB+ and then describes the offer/answer m= odel considerations for the parameters it registers.=20 |My argument is that the working group has not |provide an explanation about why the proposal should be published on |the Standards Track. Instead of objecting to the publication as a |RFC I suggested publishing the proposal as an Informational RFC. I don't think publishing it as an Informational RFC would improve interoper= ability. Muthu | |Regards, |-sm From keith.drage@alcatel-lucent.com Wed Dec 4 11:27:34 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106EF1ACCDF for ; Wed, 4 Dec 2013 11:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM6TS71BLkcJ for ; Wed, 4 Dec 2013 11:27:31 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id F23F21AD947 for ; Wed, 4 Dec 2013 11:27:30 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rB4JRIFo006701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 13:27:20 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rB4JRHN4028391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 20:27:17 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 4 Dec 2013 20:27:17 +0100 From: "DRAGE, Keith (Keith)" To: "Muthu Arul Mozhi Perumal (mperumal)" , SM , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO8LoXkRyXUSEDek6KFCcciV8mvppENbmy///+6QCAABkmUA== Date: Wed, 4 Dec 2013 19:27:17 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 19:27:34 -0000 I think the problem here originates with RFC 4856. All RFC 4856 does is create IANA registrations within SDP. It does not contain any requirements, except by implication, of how those r= egistrations are used. An IANA registration, per se, cannot contain any nor= mative requirements, all it is a list of assigned values. As such for the scope that RFC 4856 seeks to cover, it should not have been= standards track. As it is now specified I do not believe draft-ietf-mmusic-sdp-g723-g729-04.= txt updates RFC 4856. It does not change any of the IANA registrations, and= that is pretty much all the scope of RFC 4856. If there is an update at al= l created by draft-ietf-mmusic-sdp-g723-g729, I suspect it is to RFC 3551 a= s these are the documents that actually specify such media types can be use= d within the SDP. However my preference would be to not have this document = do any update. I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the usage = of SDP in offer / answer usage and as such should be standards track. I believe the abstract of draft-ietf-mmusic-sdp-g723-g729 could be improved= to reflect this. Regards Keith > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of=20 > Muthu Arul Mozhi Perumal (mperumal) > Sent: 04 December 2013 17:08 > To: SM; Ari Ker=E4nen > Cc: Flemming Andreasen (fandreas); mmusic@ietf.org > Subject: Re: [MMUSIC] Last Call:=20 > (Offer/Answer=20 > Considerations for G723 Annex A and G729 Annex B) to Proposed Standard >=20 > Hi SM, >=20 > |-----Original Message----- > |From: SM [mailto:sm@resistor.net] > |Sent: Wednesday, December 04, 2013 9:41 PM > |To: Muthu Arul Mozhi Perumal (mperumal); Ari Ker=E4nen > |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org > |Subject: RE: [MMUSIC] Last Call:=20 > | (Offer/Answer=20 > Considerations=20 > |for G723 Annex A and G729 Annex B) to Proposed Standard > | > |Hi Muthu, > |At 22:28 03-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: > |>Sorry, not clear to me. Can you provide some examples? > | > |As an example: > | > | "The reproduction of the [RFC4695] IANA considerations=20 > section appears > | directly below. > | > | This section makes a series of requests to IANA. The IANA has > | completed registration/assignments of the below requests." > | > |Please note that I picked one at random. > | > |>Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any=20 > IANA action=20 > |>(see the IANA Considerations section). So, why should it be=20 > published=20 > |>as an Informational RFC? > | > |The issue (using the word loosely) is that the draft is=20 > referring to a=20 > |registration request in Section 1.1 of RFC 4856 which is about IANA=20 > |Considerations. >=20 > Yes, is referring to that section of RFC4856. However, the=20 > issue is not the registration itself -- it is to do with the=20 > missing offer/answer considerations for the registered media=20 > parameters that impact interoperability. As an example,=20 > RFC4352 registers AMR-WB+ and then describes the offer/answer=20 > model considerations for the parameters it registers.=20 >=20 > |My argument is that the working group has not provide an explanation=20 > |about why the proposal should be published on the Standards Track. =20 > |Instead of objecting to the publication as a RFC I suggested=20 > publishing=20 > |the proposal as an Informational RFC. >=20 > I don't think publishing it as an Informational RFC would=20 > improve interoperability. >=20 > Muthu >=20 > | > |Regards, > |-sm >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > = From sm@resistor.net Wed Dec 4 16:11:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF101ADFB9 for ; Wed, 4 Dec 2013 16:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkUG_B9w20V1 for ; Wed, 4 Dec 2013 16:11:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB251AE113 for ; Wed, 4 Dec 2013 16:11:53 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB50Bdbd003828; Wed, 4 Dec 2013 16:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386202306; bh=WEI15BvktzgLJVxpZ+L9GnlSEaxVyG2IdkEyB4YV3+4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KR8IzCo0Z3gErjRGM4d8fBDvvfzj0ym1ATGTiEQTYye5GPWx+j534/hqFtJgjmUXl ILX1WRo8YJvLdup1XXT4U5XQN1xJj9YOHmFBBoD3gTH3sCoQSweMToKSvzh+0fng0I J1xKSzfT2NwQnzml6uRkxzNA5mEK+eVndM5v1vYQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386202306; i=@resistor.net; bh=WEI15BvktzgLJVxpZ+L9GnlSEaxVyG2IdkEyB4YV3+4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2CCY0NBlbl+MzTJkGwqkjW2uRIZi2x7uapwH/kUm8sbrd392ajIUiTuTh7WzQy8NU r4sHjImnICxGi5/fYtNRIFfZ0H3pmimm+hylVQwnGEpxmRbp8YnQmPBEIw0XrVu3T+ Q/fyVVUCE4JNb9T8m7UuiV8y9ivxwSMgLDHXjS9E= Message-Id: <6.2.5.6.2.20131204150228.0d2a7170@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Dec 2013 16:03:01 -0800 To: "Muthu Arul Mozhi Perumal (mperumal)" , Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Flemming Andreasen \(fandreas\)" , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:11:55 -0000 Hi Muthu, At 09:08 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: >Yes, is referring to that section of RFC4856. However, the issue is >not the registration itself -- it is to do with the missing >offer/answer considerations for the registered media parameters that >impact interoperability. As an example, RFC4352 registers AMR-WB+ >and then describes the offer/answer model considerations for the >parameters it registers. I'll comment below. >I don't think publishing it as an Informational RFC would improve >interoperability. I was looking forward to read the above argument. :-) The Introduction section of draft-ietf-mmusic-sdp-g723-g729-04 mentions an issue which can affect interoperability. It's a valid argument for choosing Standards Track. I quote part of a message [1] from Keith Drage: "I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the usage of SDP in offer / answer usage and as such should be standards track." That describes the problem the proposal tries to solve. The proposal probably has to have some RFC 2119 key words (re. interoperability). In my opinion the interoperability question does not fit in RFC 4856. The issue is where to put the missing offer/answer considerations. I took a quick look at several related RFCs and could not find the answer. I suggest looking into what Keith Drage suggested. The registration is a separate issue. In simple terms, a person can take a look at the registry and find the appropriate specification where the media parameters are defined. Maybe you could work from where the protocol is specified, explain the interoperability issue and propose the solution. I have not been able to determine whether a registration update is needed. I'll suggest reading RFC 4855. Regards, -sm 1. http://www.ietf.org/mail-archive/web/mmusic/current/msg12856.html From mperumal@cisco.com Wed Dec 4 20:13:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0934B1AE02B for ; Wed, 4 Dec 2013 20:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.602 X-Spam-Level: X-Spam-Status: No, score=-13.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPWJ1ev73uXF for ; Wed, 4 Dec 2013 20:13:53 -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 C29711ADF6C for ; Wed, 4 Dec 2013 20:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9352; q=dns/txt; s=iport; t=1386216830; x=1387426430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nwoERI8R1kWG7yx4ePDvpRCEH1FGrBKMBn4S9Zw6dGY=; b=AxjXUHN4Q9XDgpe14OnKjnosc1kz9rHbPITbAEE1bkbztkwJcGJoyOTy HYX07CqCBnAcsQRlTJQq9xN+colw3IxUekY1EJ8/Zlzk97BsKtCJ4v/Jm g3x9CkCP0RIkB13g31WHVGLWC/wREDpxSjNNGbcqk2qRPBpJVUkzXD1hY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAOH8n1KtJV2d/2dsb2JhbABZgwc4U7geToEaFnSCJQEBAQQBAQFrCwwEAgEIEQQBAQsZBAcnCxQJCAIEAQ0FCId6DcEvEwSOTTEHBoMagRMDiQqhHYFrgT6CKg X-IronPort-AV: E=Sophos;i="4.93,830,1378857600"; d="scan'208";a="289295355" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 05 Dec 2013 04:13:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB54Dm35003686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 04:13:48 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 22:13:47 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "DRAGE, Keith (Keith)" , SM , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO8XBksVWA6H39DU+VrLLXgZIJHw== Date: Thu, 5 Dec 2013 04:13:46 +0000 Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.144] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 04:13:55 -0000 I see your point. Our opinion was that an RFC that specifies the mapping of media type parame= ters with SDP and registers the media types with IANA should also describe = its usage, especially with the offer/answer model (e.g, RFC435). In that se= nse we thought draft-ietf-mmusic-sdp-g723-g729 is an update to RFC4856. Your opinion is that they should be delinked -- one RFC can register the me= dia types and another RFC can describe the usage for the registered media t= ypes independently. I am fine with that. The abstract and introduction in d= raft-ietf-mmusic-sdp-g723-g729 can easily be changed to reflect it. ---------------------------------------------------------------------- Current Abstract: RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. New Abstract: There are no specifications that describe the offerer and answerer=20 behavior when the value of the annexa parameter of G729 or the annexb=20 parameter of G729, G729D and G729E does not match in the Session=20 Description protocol(SDP) offer and answer. This document provides the=20 offer/answer considerations for these parameters. Current Introduction: [RFC4856] describes the annexa parameter for G723 as follows: annexa: indicates that Annex A, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. Also, [RFC4856] describes the annexb parameter for G729, G729D and G729E as follows: annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. However, it does not have any normative statement for the case where the value of this parameter does not match in the SDP [RFC4566] offer and answer. For example, if the offer has G729 with annexb=3Dyes and the answer has G729 with annexb=3Dno, it can be interpreted in two different ways: o The offerer and answerer proceed as if G729 is negotiated with annexb=3Dyes, or o The offerer and answerer proceed as if G729 is negotiated with annexb=3Dno. Since [RFC4856] does not state it clearly, various implementations have interpreted the offer/answer in their own ways, resulting in a different codec being chosen to call failure, when the parameter value does not match in the offer and answer. [RFC3264] requires SDP extensions that define new fmtp parameters to specify their proper interpretation in offer/answer. But, [RFC4856] does not specify it for the Annex A flavor of G723 and the Annex B flavors of G729, G729D and G729E. This document describes the offer/answer considerations for these parameters and provides the necessary clarifications. New Introduction: [RFC4856] describes the annexa parameter for G723 as follows: annexa: indicates that Annex A, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. Also, [RFC4856] describes the annexb parameter for G729, G729D and G729E as follows: annexb: indicates that Annex B, voice activity detection, is used or preferred. Permissible values are "yes" and "no" (without the quotes); "yes" is implied if this parameter is omitted. However, there is no specification describing the case where the value=20 of this parameter does not match in the SDP [RFC4566] offer and answer. = =20 For example, if the offer has G729 with annexb=3Dyes and the answer has= =20 G729 with annexb=3Dno, it can be interpreted in two different ways: o The offerer and answerer proceed as if G729 is negotiated with annexb=3Dyes, or o The offerer and answerer proceed as if G729 is negotiated with annexb=3Dno. Since this is not clearly stated, various implementations have interpret= ed=20 the offer/answer in their own ways, resulting in a different codec being= =20 chosen to call failure, when the parameter value does not match in the=20 offer and answer. [RFC3264] requires SDP extensions that define new fmtp parameters to specify their proper interpretation in offer/answer. This document=20 describes the offer/answer considerations for these parameters and provi= des=20 the necessary clarifications. ---------------------------------------------------------------------- Do they address your concerns? Muthu |-----Original Message----- |From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] |Sent: Thursday, December 05, 2013 12:57 AM |To: Muthu Arul Mozhi Perumal (mperumal); SM; Ari Ker=E4nen |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |Subject: RE: [MMUSIC] Last Call: = (Offer/Answer Considerations |for G723 Annex A and G729 Annex B) to Proposed Standard | |I think the problem here originates with RFC 4856. | |All RFC 4856 does is create IANA registrations within SDP. | |It does not contain any requirements, except by implication, of how those = registrations are used. An |IANA registration, per se, cannot contain any normative requirements, all = it is a list of assigned |values. | |As such for the scope that RFC 4856 seeks to cover, it should not have bee= n standards track. | |As it is now specified I do not believe draft-ietf-mmusic-sdp-g723-g729-04= .txt updates RFC 4856. It |does not change any of the IANA registrations, and that is pretty much all= the scope of RFC 4856. If |there is an update at all created by draft-ietf-mmusic-sdp-g723-g729, I su= spect it is to RFC 3551 as |these are the documents that actually specify such media types can be used= within the SDP. However my |preference would be to not have this document do any update. | |I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the usage= of SDP in offer / answer |usage and as such should be standards track. | |I believe the abstract of draft-ietf-mmusic-sdp-g723-g729 could be improve= d to reflect this. | |Regards | |Keith | | |> -----Original Message----- |> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of |> Muthu Arul Mozhi Perumal (mperumal) |> Sent: 04 December 2013 17:08 |> To: SM; Ari Ker=E4nen |> Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |> Subject: Re: [MMUSIC] Last Call: |> (Offer/Answer |> Considerations for G723 Annex A and G729 Annex B) to Proposed Standard |> |> Hi SM, |> |> |-----Original Message----- |> |From: SM [mailto:sm@resistor.net] |> |Sent: Wednesday, December 04, 2013 9:41 PM |> |To: Muthu Arul Mozhi Perumal (mperumal); Ari Ker=E4nen |> |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |> |Subject: RE: [MMUSIC] Last Call: |> | (Offer/Answer |> Considerations |> |for G723 Annex A and G729 Annex B) to Proposed Standard |> | |> |Hi Muthu, |> |At 22:28 03-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: |> |>Sorry, not clear to me. Can you provide some examples? |> | |> |As an example: |> | |> | "The reproduction of the [RFC4695] IANA considerations |> section appears |> | directly below. |> | |> | This section makes a series of requests to IANA. The IANA has |> | completed registration/assignments of the below requests." |> | |> |Please note that I picked one at random. |> | |> |>Also, draft-ietf-mmusic-sdp-g723-g729-04 doesn't need any |> IANA action |> |>(see the IANA Considerations section). So, why should it be |> published |> |>as an Informational RFC? |> | |> |The issue (using the word loosely) is that the draft is |> referring to a |> |registration request in Section 1.1 of RFC 4856 which is about IANA |> |Considerations. |> |> Yes, is referring to that section of RFC4856. However, the |> issue is not the registration itself -- it is to do with the |> missing offer/answer considerations for the registered media |> parameters that impact interoperability. As an example, |> RFC4352 registers AMR-WB+ and then describes the offer/answer |> model considerations for the parameters it registers. |> |> |My argument is that the working group has not provide an explanation |> |about why the proposal should be published on the Standards Track. |> |Instead of objecting to the publication as a RFC I suggested |> publishing |> |the proposal as an Informational RFC. |> |> I don't think publishing it as an Informational RFC would |> improve interoperability. |> |> Muthu |> |> | |> |Regards, |> |-sm |> |> _______________________________________________ |> mmusic mailing list |> mmusic@ietf.org |> https://www.ietf.org/mailman/listinfo/mmusic |> From mperumal@cisco.com Wed Dec 4 20:36:54 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B171AE02A for ; Wed, 4 Dec 2013 20:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci8FSX5Tf36N for ; Wed, 4 Dec 2013 20:36:51 -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 D8E8B1ADFD9 for ; Wed, 4 Dec 2013 20:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2993; q=dns/txt; s=iport; t=1386218208; x=1387427808; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2ZgIUTstkCVExZNlHNgskqOk2SgZOS3MHoQm8fT+TjU=; b=efjlCu7DGP9O6jBM39KeXplpyv9x04U1jDgHLkK7ndSBDLUEARs5RfhS su8APLziLfZnx7rKB442j4ulz7skC3mdODh3aj41fSprKufvyWcR78k34 nXa3wRuTM81XbxGjG+DoFPOvettiv05BeRPKTbTqbszNSlkfxp9YQZHxl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAJQBoFKtJXHB/2dsb2JhbABZgwc4U7geToEbFnSCJQEBAQR5DAQCAQgRBAEBCxkEBzIUCQgCBAENBQgBEodnDcESF44tAQEeMQIFBoMagRMDiQqhHYFrgT6BcTk X-IronPort-AV: E=Sophos;i="4.93,830,1378857600"; d="scan'208";a="289568633" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 05 Dec 2013 04:36:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB54alQB016746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 04:36:47 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.34]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 22:36:46 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: SM , =?iso-8859-1?Q?Ari_Ker=E4nen?= Thread-Topic: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard Thread-Index: AQHO8XObU26/MIfss0edk6vWwjHFQw== Date: Thu, 5 Dec 2013 04:36:46 +0000 Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <6.2.5.6.2.20131204150228.0d2a7170@resistor.net> In-Reply-To: <6.2.5.6.2.20131204150228.0d2a7170@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.144] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Flemming Andreasen \(fandreas\)" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 04:36:54 -0000 Hi SM, |-----Original Message----- |From: SM [mailto:sm@resistor.net] |Sent: Thursday, December 05, 2013 5:33 AM |To: Muthu Arul Mozhi Perumal (mperumal); Ari Ker=E4nen |Cc: Flemming Andreasen (fandreas); mmusic@ietf.org |Subject: RE: [MMUSIC] Last Call: = (Offer/Answer Considerations |for G723 Annex A and G729 Annex B) to Proposed Standard | |Hi Muthu, |At 09:08 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: |>Yes, is referring to that section of RFC4856. However, the issue is |>not the registration itself -- it is to do with the missing |>offer/answer considerations for the registered media parameters that |>impact interoperability. As an example, RFC4352 registers AMR-WB+ |>and then describes the offer/answer model considerations for the |>parameters it registers. | |I'll comment below. | |>I don't think publishing it as an Informational RFC would improve |>interoperability. | |I was looking forward to read the above argument. :-) | |The Introduction section of draft-ietf-mmusic-sdp-g723-g729-04 |mentions an issue which can affect interoperability. It's a valid |argument for choosing Standards Track. We are on the same page here.. | |I quote part of a message [1] from Keith Drage: | | "I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the | usage of SDP in offer / answer usage and as such should be standards | track." | |That describes the problem the proposal tries to solve. =20 And here as well.. |The proposal probably has to have some RFC 2119 key words (re. |interoperability). In my opinion the interoperability question does |not fit in RFC 4856. The issue is where to put the missing |offer/answer considerations. I took a quick look at several related |RFCs and could not find the answer. I suggest looking into what |Keith Drage suggested. Apparently, we have different opinions here. But, I don't see an issue with= your/Kieth's opinion. I just responded to Kieth with the proposed changes = to abstract and introduction. | |The registration is a separate issue. In simple terms, a person can |take a look at the registry and find the appropriate specification |where the media parameters are defined. Same as above.. |Maybe you could work from where the protocol is specified, explain |the interoperability issue and propose the solution. =20 I am not sure if you have read daft-ietf-mmusic-sdp-g723-g729 fully, but th= e interoperability issue and the proposed solution is the crux of the draft= -- this was also the focus of discussions in the WG and we didn't pay much= attention to whether it really is an update to RFC4856 -:) |I have not been able to determine whether a registration update is needed.= =20 |I'll suggest reading RFC 4855. RFC4855 has no suggestions on that. Muthu | |Regards, |-sm | |1. http://www.ietf.org/mail-archive/web/mmusic/current/msg12856.html From sm@resistor.net Wed Dec 4 23:14:44 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128A31A1F74 for ; Wed, 4 Dec 2013 23:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aNtdBgdSdny for ; Wed, 4 Dec 2013 23:14:41 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC26F1A1F71 for ; Wed, 4 Dec 2013 23:14:41 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB57ENgD028693; Wed, 4 Dec 2013 23:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386227671; bh=MneA5aQPzglaBTOA3Wd8m9aJ7p9xetbGaFbVgUE5Ges=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JcVXbtvyfmDk50YHoncX4qpa0gqe2qOIjsSdGERgcz1epNHvhDGYQCOB/LhzoXSai zuDrjSnC3/96Oy6EVDcnkD5psKcjXHa3L/oJa+KaRi7apZiGvsN3MWsFtO2snPG6Vi MX6C/EcPIkSr7d/2EFToQ6+sZVe0zTumfJWjyEGM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386227671; i=@resistor.net; bh=MneA5aQPzglaBTOA3Wd8m9aJ7p9xetbGaFbVgUE5Ges=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TBYJrL6T4vAvqOEHqJoN1x5GCc3UEIWNMm2GLvTW3HFNhW1Tof1V6S9aRMOw7K3yl s80P3eWUPlo1nFw04QL+xgIZswy0A4QPFvo9e9AzGETcqYcFEgo6CsbLIJcwy/uskY ITp8BGlKETDTJobILcwTCDypdtFndrjyvXML12X8= Message-Id: <6.2.5.6.2.20131204204318.0b8c2430@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Dec 2013 20:54:01 -0800 To: "Muthu Arul Mozhi Perumal (mperumal)" , "DRAGE, Keith (Keith)" , Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Flemming Andreasen \(fandreas\)" , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 07:14:44 -0000 Hi Muthu, At 20:13 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: >I see your point. > >Our opinion was that an RFC that specifies the mapping of media type >parameters with SDP and registers the media types with IANA should >also describe its usage, especially with the offer/answer model >(e.g, RFC435). In that sense we thought >draft-ietf-mmusic-sdp-g723-g729 is an update to RFC4856. > >Your opinion is that they should be delinked -- one RFC can register >the media types and another RFC can describe the usage for the >registered media types independently. I am fine with that. The >abstract and introduction in draft-ietf-mmusic-sdp-g723-g729 can >easily be changed to reflect it. Yes, but you can have both in one RFC. The registration can be requested in the IANA Considerations section. >--------------------------------------------------------------------- >Current Abstract: > RFC4856 describes the annexa parameter for G723 and the annexb > parameter for G729, G729D and G729E. However, the specification does > not describe the offerer and answerer behavior when the value of the > annexa or annexb parameter does not match in the Session Description > protocol(SDP) offer and answer. This document provides the offer/ > answer considerations for these parameters and updates RFC4856. > >New Abstract: > There are no specifications that describe the offerer and answerer > behavior when the value of the annexa parameter of G729 or the annexb > parameter of G729, G729D and G729E does not match in the Session > Description protocol(SDP) offer and answer. This document provides the > offer/answer considerations for these parameters. I suggest removing "there are no specifications ..." and explain what the document specifies. >Current Introduction: > [RFC4856] describes the annexa parameter for G723 as follows: > > annexa: indicates that Annex A, voice activity detection, is used > or preferred. Permissible values are "yes" and "no" (without the > quotes); "yes" is implied if this parameter is omitted. > > Also, [RFC4856] describes the annexb parameter for G729, G729D and > G729E as follows: > > annexb: indicates that Annex B, voice activity detection, is used > or preferred. Permissible values are "yes" and "no" (without the > quotes); "yes" is implied if this parameter is omitted. The above starts with RFC 4856. I suggest starting with the RFC 4566 followed by the RFC 3264 text (I did not verify the reference). You can then specify the fmtp parameters for Annex A, etc. Once you have done that, verify whether there are some registry requirements and add text for that in a IANA Considerations section. Regards, -sm From sm@resistor.net Wed Dec 4 23:43:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395FD1AC43E for ; Wed, 4 Dec 2013 23:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQMg-FcvfTzF for ; Wed, 4 Dec 2013 23:43:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 627D11AC403 for ; Wed, 4 Dec 2013 23:43:53 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB57heQ6005200; Wed, 4 Dec 2013 23:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386229427; bh=J6oQ8fojTymHYvW8ItOv1bQsrvx8ecLluwYNazzFqEc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1j3n7pxea+F0nVzG0kLYPxgdnXWE3wUxnyPlwv3tIKWNo71kK9l8wS2ky5A/QEcdA dawSDZXvp1qpszYaZBLlOcV/HRmxL5pNr44JeqVjVj1lNmx4KZA4uLv72rr+QMtDG3 eQn3DUxsCy+MbAzeZw4+E4GPWVYY/lFs1Nt5Kvvc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386229427; i=@resistor.net; bh=J6oQ8fojTymHYvW8ItOv1bQsrvx8ecLluwYNazzFqEc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dCawQQFQ6b5Ej3IcITXXvGNtvJZIoNZAIUqvV/QopogKcHUm5XK5ePspqPsLhwTB7 z/xSGou4F4W9dVsSXe5emKrttwPQK0inHzlKJCXogbqYjasbuUkMCaCAfWKe5uHUEa bSbqFvJI/4CqAwpxNP5l74ETwzZ1wEXZ034Rov8I= Message-Id: <6.2.5.6.2.20131204225643.0bb58c80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Dec 2013 23:17:34 -0800 To: "Muthu Arul Mozhi Perumal (mperumal)" , Ari =?iso-8859-1?Q?Ker=E4nen?= From: SM In-Reply-To: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <6.2.5.6.2.20131204150228.0d2a7170@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Flemming Andreasen \(fandreas\)" , mmusic@ietf.org Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 07:43:56 -0000 Hi Muthu, At 20:36 04-12-2013, Muthu Arul Mozhi Perumal (mperumal) wrote: >I am not sure if you have read daft-ietf-mmusic-sdp-g723-g729 fully, >but the interoperability issue and the proposed solution is the crux >of the draft -- this was also the focus of discussions in the WG and >we didn't pay much attention to whether it really is an update to RFC4856 -:) I read the draft and I did somewhat of the reverse. :-) I was puzzled about why the draft was updating that RFC to address an interoperability issue. >RFC4855 has no suggestions on that. Yes. :-( Regards, -sm From internet-drafts@ietf.org Thu Dec 5 00:10:41 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6E1AC85E; Thu, 5 Dec 2013 00:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7X6H2Y0CtjC; Thu, 5 Dec 2013 00:10:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8F1AC4C5; Thu, 5 Dec 2013 00:10:40 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205081040.30715.91261.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 00:10:40 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-udptl-dtls-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:10:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control Wor= king Group of the IETF. Title : UDP Transport Layer (UDPTL) over Datagram Transport Laye= r Security (DTLS) Author(s) : Christer Holmberg Ivo Sedlacek Gonzalo Salgueiro Filename : draft-ietf-mmusic-udptl-dtls-02.txt Pages : 19 Date : 2013-12-05 Abstract: This document specifies how the UDP Transport Layer (UDPTL) protocol can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-udptl-dtls-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Thu Dec 5 00:20:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FC91AC7F3 for ; Thu, 5 Dec 2013 00:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_Ym41dfTvL4 for ; Thu, 5 Dec 2013 00:20:54 -0800 (PST) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id F3ACA1AC7F1 for ; Thu, 5 Dec 2013 00:20:53 -0800 (PST) X-AuditID: c1b4fb31-b7f118e000003145-30-52a037619e66 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id ED.81.12613.16730A25; Thu, 5 Dec 2013 09:20:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0347.000; Thu, 5 Dec 2013 09:20:48 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-udptl-dtls-02.txt Thread-Index: Ac7xkcegtEfHfgc4Q36k/WKGKg422A== Date: Thu, 5 Dec 2013 08:20:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C56C892@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C56C892ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvrW6i+YIgg7uLdS3+7U2ymLr8MYsD k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfFoyx/mgleGFbeP32dtYPyt3cXIwSEhYCIx d7p8FyMnkCkmceHeerYuRi4OIYETjBKNu9qYIZxFjBKv521mA2lgE7CQ6P6nDdIgIqAu8XVv DzOIzSzgKHH21nYmEFtYwF5i3t3drCDlIgIuEg8XSECU60lcXTGfBcRmEVCR2HOqB6ycV8BX onnTF7AxjEA3fD+1hglipLjErSfzmSBuE5BYsuc8M4QtKvHy8T9WCFtR4ur05VD1+RIznr5h hpgpKHFy5hOWCYzCs5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbI4 tTgpN93IUC83PbdEL7UoM7m4OD9Przh1EyMwgg5u+W24g3HiNftDjNIcLErivAzTO4OEBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MCb/jlxzQfp5Xv/aCbXPlj4+Zu4Q1fj8X+VxfdVnlpoX jNedmjI75LSxULX/i6htHRd4n1XoJih+qm0Xe3B8ApdA4a59S89ZVxVPD9ki3SZimrRVRV0q ePqE/WE3mhoOcsqImYdfXzf9Z3rzUQ63pwdOrvrAypy33SHeR7pEa2WKHt8KTtHQq0osxRmJ hlrMRcWJAA82oOluAgAA Cc: "mmusic-chairs@tools.ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:20:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C56C892ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi fax lovers, We've submitted a new version of (-02) draft-ietf-mmusic-udptl-dtls. The main changes are: - Usage of the SDP fingerprint attribute depends on whether a ciph= er suite with an associated certificate is used. - Editor's note in section 4.2 removed. Instead of referencing SR= TP-DTLS, we added explicit procedure text. There are currently no remaining open issues in the draft. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C56C892ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi fax lovers,

 

We’ve submitted a new version of (-02) draft-i= etf-mmusic-udptl-dtls.

 

The main changes are:

 

-     &= nbsp;    Usage of the SDP fingerprint attribute depends on w= hether a cipher suite with an associated certificate is used.

-     &= nbsp;    Editor's note in section 4.2 removed.  Instead= of referencing SRTP-DTLS, we added explicit procedure text.

 

There are currently no remaining open issues in the = draft.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C56C892ESESSMB209erics_-- From casner@acm.org Thu Dec 5 00:22:36 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C441ACC8B for ; Thu, 5 Dec 2013 00:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkCPvLg-fQZE for ; Thu, 5 Dec 2013 00:22:35 -0800 (PST) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id E906A1ACC89 for ; Thu, 5 Dec 2013 00:22:34 -0800 (PST) Received: from packetdesign.com (vpn2-int.packetdesign.com [192.168.0.181]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id rB58MICl020804; Thu, 5 Dec 2013 00:22:19 -0800 Date: Thu, 5 Dec 2013 00:22:18 -0800 (PST) From: Stephen Casner To: "DRAGE, Keith (Keith)" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Message-ID: References: <20131030131748.6987.86198.idtracker@ietfa.amsl.com> <6.2.5.6.2.20131030185231.0ddfb7a8@resistor.net> <00a101ced981$77414d60$65c3e820$@co.in> <00ab01cee555$05f53560$11dfa020$@co.in> <6.2.5.6.2.20131119110213.0cb0dd40@resistor.net> <003301cee952$852cd120$8f867360$@co.in> <6.2.5.6.2.20131129000812.0bdaa088@resistor.net> <016d01ceed31$aa7a1130$ff6e3390$@co.in> <6.2.5.6.2.20131130003721.0d65a980@resistor.net> <6.2.5.6.2.20131203011102.0db5d8c0@resistor.net> <6.2.5.6.2.20131204072722.0e064590@resistor.net> <949EF20990823C4C85C18D59AA11AD8B0F23CB@FR712WXCHMBA11.zeu.alcatel-lucent.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Flemming Andreasen \(fandreas\)" , Ari Ker?nen , "mmusic@ietf.org" , SM Subject: Re: [MMUSIC] Last Call: (Offer/Answer Considerations for G723 Annex A and G729 Annex B) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:22:36 -0000 On Wed, 4 Dec 2013, DRAGE, Keith (Keith) wrote: > I think the problem here originates with RFC 4856. > > All RFC 4856 does is create IANA registrations within SDP. > > It does not contain any requirements, except by implication, of how > those registrations are used. An IANA registration, per se, cannot > contain any normative requirements, all it is a list of assigned > values. > > As such for the scope that RFC 4856 seeks to cover, it should not > have been standards track. I disagree. Establishing the media type registrations is a valid part of the standardization process. I believe there are other examples of standard track documents written for the purpose of IANA registrations, such as 3575, 4002, 4355, 4415, although there are also a number of others that are BCP. None of that is relevant to the current I-D, though. > As it is now specified I do not believe > draft-ietf-mmusic-sdp-g723-g729-04.txt updates RFC 4856. It does not > change any of the IANA registrations, and that is pretty much all > the scope of RFC 4856. If there is an update at all created by > draft-ietf-mmusic-sdp-g723-g729, I suspect it is to RFC 3551 as > these are the documents that actually specify such media types can > be used within the SDP. However my preference would be to not have > this document do any update. Exactly. That is what I said in my email reply on Monday. > I do believe draft-ietf-mmusic-sdp-g723-g729 normatively impacts the > usage of SDP in offer / answer usage and as such should be standards > track. Right. -- Steve From christer.holmberg@ericsson.com Thu Dec 5 03:55:10 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487E01ADF7D for ; Thu, 5 Dec 2013 03:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIxkoYC9s1cb for ; Thu, 5 Dec 2013 03:55:08 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 320B91ADF79 for ; Thu, 5 Dec 2013 03:55:07 -0800 (PST) X-AuditID: c1b4fb32-b7f388e0000057e0-eb-52a06997f667 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id C7.C4.22496.79960A25; Thu, 5 Dec 2013 12:55:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0347.000; Thu, 5 Dec 2013 12:55:03 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Thread-Topic: comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3 Thread-Index: Ac7xsM5j3Tyf3U3cQ+m6qr6hn1HjnA== Date: Thu, 5 Dec 2013 11:55:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C56CEF0@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre70zAVBBstmmlpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGlct3GAt+qVasWF/ZwNgk28XIySEhYCIx cc1CJghbTOLCvfVsXYxcHEICJxglrvXeh3IWMUocX7CItYuRg4NNwEKi+582SIOIgJbEgSuX WUDCzAJqEo+uG4KEhQUKJX4tm8ICUVIkcfXOTXaQEhEBPYln7TUgYRYBFYnOW8fYQWxeAV+J Za2f2EBsRqATvp9aA3YOs4C4xK0n86FOE5BYsuc8M4QtKvHy8T9WCFtR4ur05VD1OhILdkPM YRbQlli28DUzxHxBiZMzn7BMYBSZhWTsLCQts5C0zELSsoCRZRWjZHFqcXFuupGBXm56bole alFmcnFxfp5eceomRmBEHNzy22gH48k99ocYpTlYlMR5r7PWBAkJpCeWpGanphakFsUXleak Fh9iZOLglGpgjJiwJMzu14s3ExjYfXWjhNSFL1qxMm6bcqnn+wL/ZzbS2gck5ROKmdb0d2zw 6Fj7tG4aQ2hA1KV7LwNZX8yKnCj2RPa15ZdXk7UEchL+hT779fvK/0UnJMXKHdT+28epP/OZ srKl2qdVgKdyrWvTkZ2PmZ+GnjgfXteX4/lWyHj1pkuHZexuKrEUZyQaajEXFScCAInbP11W AgAA Cc: 'IETF MMUSIC WG' Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 11:55:10 -0000 Hi Paul, I am working on a new version of BUNDLE, so I took a closer look at your co= mments on -05. I will address them in separate e-mails. I GUESS we should allow it, at least in the initial Offer, in case the Answ= erer doesn't support BUNDLE. But, in the BAS Offer I guess we should either= say that it is not used, that the value MUST be identical to the RTP port,= or that the value doesn't matter. ---------------------------- > Section 6.4.3 says: > > When an Offerer receives an Answer, in which an offered BUNDLE group > is accepted, if the Offerer in the associated Offer assigned an > address (unique or shared), that does not represent the BUNDLE > address selected for the Offerer, to an "m=3D" line within the BUNDLE > group, the Offerer MUST send a subsequent Offer, in which it assigns > the BUNDLE address selected for the Offerer to each "m=3D" line within > the BUNDLE group. This procedure is referred to as Bundle Address > Synchronization (BAS), and the Offer is referred to as a BAS Offer. > > I tried to parse it below. To do so, I had to move "that does not represe= nt the BUNDLE address selected for the Offerer,". > > When an Offerer receives an Answer, > in which an offered BUNDLE group is accepted, > if the Offerer in the associated Offer assigned an address > (unique or shared), to an "m=3D" line within the BUNDLE group, > that does not represent the BUNDLE address selected for the > Offerer, > > the Offerer MUST send a subsequent Offer, in which it assigns > the BUNDLE address selected for the Offerer to each "m=3D" line within > the BUNDLE group. This procedure is referred to as Bundle Address > Synchronization (BAS), and the Offer is referred to as a BAS Offer. > > Even so, it still doesn't quite make sense to me. The problem is with "se= lected for the Offerer". IIUC it would state that as "selected by the Answe= rer". > > And in any case I'm not sure if I then have the intended interpretation. > > I *think* the condition you are trying to describe is: > > - offer included bundle group > - answer accepted bundle group > - M is the first mid in the bundle group in the answer > - A is the media address of the m-line in the offer that > has mid M > - some m-line in offered bundle group that was accepted in the answer > doesn't have media address A > > If that is what you are trying to say, then we just have to figure out ho= w to say it intelligibly. I think trying to string it out into a sentence i= s not going to work, and so you need to break it down something like I did = above. I replied to this earlier, but I'll modify my reply a bit. The mid has nothing to do with whether a BAS Offer needs to be sent or not.= The Answerer will indicate which mid value represents the determined BUNDL= E address, and it doesn't matter if that is not the same address as the Off= erer requested to become its BUNDLE address. The only thing which matters is whether the Offer contained addresses that = are different from the determined BUNDLE address (in the initial Offer that= will always be the case, as each address with a non-zero port value must b= e unique). Never the less, I still tried to make the text more clear: ------------ 6.4.3. Bundle Address Synchronization (BAS) When an Offerer receives an Answer, in which an offered BUNDLE group has been accepted by the Answerer, it checks the following criteria: o In the Offer the Offerer assigned an address (unique or shared) to one or more "m=3D" lines within the BUNDLE group, that is different than the BUNDLE address determined by the Answerer Section 6.4.2. If the criteria is fulfilled, the Offerer MUST send a subsequent Offer, in which it assigns the BUNDLE address to each "m=3D" line within the BUNDLE group. This procedure is referred to as Bundle Address Synchronization (BAS), and the Offer is referred to as a BAS Offer. The Offerer MAY modify any SDP parameter in a BAS Offer. NOTE: It is important that the BAS Offer gets accepted by the Answerer. For that reason the Offerer needs to consider the necessity to modify SDP parameters that could get the Answerer to reject the BAS Offer. Removing "m=3D" lines, or reducing the number of codecs, in the BAS Offer used for the is considered to have a low risk of being rejected. NOTE: The main purpose of the BAS Offer is to make sure that intermediaries, that might not support the BUNDLE mechanism, have correct information regarding which address is going to be used for the bundled media. Section 12.1 shows an example of an BAS Offer. ---------------------------- Regards, Christer From pkyzivat@alum.mit.edu Thu Dec 5 09:58:56 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44B21AE111 for ; Thu, 5 Dec 2013 09:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK7xl7h40viG for ; Thu, 5 Dec 2013 09:58: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 8EB1C1A1F66 for ; Thu, 5 Dec 2013 09:58:53 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id xpiL1m0061c6gX853tyqYg; Thu, 05 Dec 2013 17:58:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id xtyp1m00L3ZTu2S3jtypmD; Thu, 05 Dec 2013 17:58:50 +0000 Message-ID: <52A0BED9.9010405@alum.mit.edu> Date: Thu, 05 Dec 2013 12:58:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C56CEF0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C56CEF0@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=1386266330; bh=mRAj55auZa+vHzGvhC29z6OPa1fVwP/DoUuuPUYaScc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mYjG36mS52u2W+oZacxmJzF41vkCzeKAsQ6EnmfqnNhnOWYFFIhFMLnbBPgA7j5sK NybArQaZZIc4vn0ALOsUX0d9gFKY6IhET2uyq6XOjkang84psq1Kfxw4xyTI/+qoVO ACgDOGO+dG1h8ui0SG0/Idvta+g55lgNoHiR5DOrMN/gUWjxa/+NHUhjY6QtlvH1Ok pNFUeLREoAJ3PVDqT6KFF3LysTkqfenUYpv5XJ1DNjK7LzlBrIdwfW3zl0YGSOUphd qOs8ZnqGS+jZ04VFgQ3yZeYd+/v9uiYYknwuAwjACa06NGdfSzjwxYlIEnjHJw+Y5D rhiRxKDKYIuMQ== Cc: 'IETF MMUSIC WG' Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:58:57 -0000 Hi Christer On 12/5/13 6:55 AM, Christer Holmberg wrote: > Hi Paul, > > I am working on a new version of BUNDLE, so I took a closer look at your comments on -05. I will address them in separate e-mails. > > I GUESS we should allow it, at least in the initial Offer, in case the Answerer doesn't support BUNDLE. But, in the BAS Offer I guess we should either say that it is not used, that the value MUST be identical to the RTP port, or that the value doesn't matter. > > ---------------------------- > >> Section 6.4.3 says: >> >> When an Offerer receives an Answer, in which an offered BUNDLE group >> is accepted, if the Offerer in the associated Offer assigned an >> address (unique or shared), that does not represent the BUNDLE >> address selected for the Offerer, to an "m=" line within the BUNDLE >> group, the Offerer MUST send a subsequent Offer, in which it assigns >> the BUNDLE address selected for the Offerer to each "m=" line within >> the BUNDLE group. This procedure is referred to as Bundle Address >> Synchronization (BAS), and the Offer is referred to as a BAS Offer. >> >> I tried to parse it below. To do so, I had to move "that does not represent the BUNDLE address selected for the Offerer,". >> >> When an Offerer receives an Answer, >> in which an offered BUNDLE group is accepted, >> if the Offerer in the associated Offer assigned an address >> (unique or shared), to an "m=" line within the BUNDLE group, >> that does not represent the BUNDLE address selected for the >> Offerer, >> >> the Offerer MUST send a subsequent Offer, in which it assigns >> the BUNDLE address selected for the Offerer to each "m=" line within >> the BUNDLE group. This procedure is referred to as Bundle Address >> Synchronization (BAS), and the Offer is referred to as a BAS Offer. >> >> Even so, it still doesn't quite make sense to me. The problem is with "selected for the Offerer". IIUC it would state that as "selected by the Answerer". >> >> And in any case I'm not sure if I then have the intended interpretation. >> >> I *think* the condition you are trying to describe is: >> >> - offer included bundle group >> - answer accepted bundle group >> - M is the first mid in the bundle group in the answer >> - A is the media address of the m-line in the offer that >> has mid M >> - some m-line in offered bundle group that was accepted in the answer >> doesn't have media address A >> >> If that is what you are trying to say, then we just have to figure out how to say it intelligibly. I think trying to string it out into a sentence is not going to work, and so you need to break it down something like I did above. > > I replied to this earlier, but I'll modify my reply a bit. > > The mid has nothing to do with whether a BAS Offer needs to be sent or not. The Answerer will indicate which mid value represents the determined BUNDLE address, and it doesn't matter if that is not the same address as the Offerer requested to become its BUNDLE address. The first mid in the bundle group in the answer determines which address in the offer will be the bundle address. This restates what you have in 6.4.2. > The only thing which matters is whether the Offer contained addresses that are different from the determined BUNDLE address (in the initial Offer that will always be the case, as each address with a non-zero port value must be unique). That isn't always true. When making this determination, the offerer should only consider m-lines that were accepted in the answer. It might have to send a BAS if all the m-lines were accepted, but not need to do so if some were rejected and all the ones that were accepted matched the bundle address. The trick is figuring out how to state that. > Never the less, I still tried to make the text more clear: > > ------------ > > 6.4.3. Bundle Address Synchronization (BAS) > > When an Offerer receives an Answer, in which an offered BUNDLE group > has been accepted by the Answerer, it checks the following criteria: > > o In the Offer the Offerer assigned an address (unique or shared) to > one or more "m=" lines within the BUNDLE group, that is different > than the BUNDLE address determined by the Answerer Section 6.4.2. > > If the criteria is fulfilled, the Offerer MUST send a subsequent > Offer, in which it assigns the BUNDLE address to each "m=" line > within the BUNDLE group. This procedure is referred to as Bundle > Address Synchronization (BAS), and the Offer is referred to as a BAS > Offer. This has the problem I just described. It may call for an unnecessary BAS offer. > The Offerer MAY modify any SDP parameter in a BAS Offer. > > NOTE: It is important that the BAS Offer gets accepted by the > Answerer. For that reason the Offerer needs to consider the > necessity to modify SDP parameters that could get the Answerer to > reject the BAS Offer. Removing "m=" lines, or reducing the number of > codecs, in the BAS Offer used for the is considered to have a low > risk of being rejected. > > NOTE: The main purpose of the BAS Offer is to make sure that > intermediaries, that might not support the BUNDLE mechanism, have > correct information regarding which address is going to be used for > the bundled media. > > Section 12.1 shows an example of an BAS Offer. > > ---------------------------- > > Regards, > > Christer > > From fandreas@cisco.com Fri Dec 6 14:49:57 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69931AE0FA for ; Fri, 6 Dec 2013 14:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ktvIh-0Eqtt for ; Fri, 6 Dec 2013 14:49:55 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8072C1AE09C for ; Fri, 6 Dec 2013 14:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=313; q=dns/txt; s=iport; t=1386370192; x=1387579792; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=wYWlF7VLrFlcDZ79sJYVKjgqI96BjhB1HNrtIoqj+84=; b=ca9PQr77Qh8zyygyMx037ZtrEFmODifG6uD3L2UQPUls5It8cXeCocOe qccdMU966FBWvDW3HdhjFg/2FiEtErjzlB+u3fzD6BQoOKDxP3EpGqO1g KEoaMbU7Mz78BNA/c/FDHU31IClApcztXeRplgk/sTn/zGhkJKyZIsXUr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcMAJ1TolKtJV2Y/2dsb2JhbABZgwc4pF0DlHeBLBZ0gmRAPRYYAwIBAgFLDQgBAQWHeQ2iDZ5sF5NKA4lCjlKSE4NHHg X-IronPort-AV: E=Sophos;i="4.93,842,1378857600"; d="scan'208";a="289927703" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 06 Dec 2013 22:49:51 +0000 Received: from bxb-fandreas-88110.cisco.com (bxb-fandreas-88110.cisco.com [10.98.149.203]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB6MnoYx006453 for ; Fri, 6 Dec 2013 22:49:51 GMT Message-ID: <52A2548E.3030400@cisco.com> Date: Fri, 06 Dec 2013 17:49:50 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Draft MMUSIC Meeting Minutes from IETF88 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 22:49:57 -0000 Greetings We have uploaded the draft meeting minutes for the two MMUSIC sessions at IETF 88 in Vancouver at: http://www.ietf.org/proceedings/88/minutes/minutes-88-mmusic Please take a look and let us know if you have any questions or comments. Thanks Ari & Flemming (MMUSIC co-chairs) From christer.holmberg@ericsson.com Sun Dec 8 10:04:31 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74C1AE058 for ; Sun, 8 Dec 2013 10:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P9CzIqQdpPx for ; Sun, 8 Dec 2013 10:04:29 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E05A91AE04A for ; Sun, 8 Dec 2013 10:04:28 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-c3-52a4b4a7f286 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0F.ED.03802.7A4B4A25; Sun, 8 Dec 2013 19:04:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.26]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0347.000; Sun, 8 Dec 2013 19:04:22 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3 Thread-Index: Ac7xsM5j3Tyf3U3cQ+m6qr6hn1HjnAAKnYiAAJkp5Y0= Date: Sun, 8 Dec 2013 18:04:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5815BC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C56CEF0@ESESSMB209.ericsson.se>, <52A0BED9.9010405@alum.mit.edu> In-Reply-To: <52A0BED9.9010405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5815BCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7yLUuCDG78lrWYuvwxi8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6MbcuiC+ZrViy6sZy9gfGOUhcjJ4eEgInE 9f/X2SFsMYkL99azdTFycQgJHGKUOPrxDDOEs4hR4lT7F6AqDg42AQuJ7n/aIKaIgIbEpK1q IL3MAnISGya/ZAOxhQUKJc7u3AM2U0SgSOLqnZtQtpXElCvfWUBsFgEVibuvvzOB2LwCvhI9 v+czgthCArkSL5ZuAZvDKaAjcXhNP1gvI9Bt30+tYYLYJS5x68l8JoibBSSW7DnPDGGLSrx8 /I8VoiZfYvKfeawQ8wUlTs58wjKBUWQWkvZZSMpmISmDiBtIvD83nxnC1pZYtvA1lK0vsfHL WUZk8QWM7KsY2XMTM3PSy402MQLj5uCW36o7GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxm3nmU49fa3waebUvb8WfGApkv6X2tkVv/njqhvyblOefrt1RSQy KWeic08Yy9w+1ex7nzP0003Udm1gqJi7bofWG+1JP9ds3Hs+uueO/1ErjQVszJ90zL1WGC5q 2Pvqyc/Jy651XZi9tfbjgyt+WY7rZ0w+YbDN6MnqYs2urZHP1+bfK9TpYE1QYinOSDTUYi4q TgQA2XIGD2kCAAA= Cc: 'mmusic' Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2013 18:04:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5815BCESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Paul, =85 =85 =85 > The first mid in the bundle group in the answer determines which address > in the offer will be the bundle address. This restates what you have in > 6.4.2. Correct. >> The only thing which matters is whether the Offer contained addresses th= at are different >> from the determined BUNDLE address (in the initial Offer that will alway= s be the case, as >> each address with a non-zero port value must be unique). > > That isn't always true. When making this determination, the offerer > should only consider m-lines that were accepted in the answer. Ok, I hear you. That is correct, and must be clear in the text. > It might have to send a BAS if all the m-lines were accepted, but not > need to do so if some were rejected and all the ones that were accepted > matched the bundle address. Yes. >The trick is figuring out how to state that. Perhaps something like: =93When an Offerer receives an Answer, in which an offered BUNDLE group has been accepted by the Answerer, the Offer checks each =93m=3D=94 line within= the accepted BUNDLE group against the following criteria: o In the Offer the Offerer assigned an address (unique or shared) to the "m=3D" line, that is different than the BUNDLE address determined by the Answerer Section 6.4.2.=94 Regards, Christer (from LH404, somewhere over the English channel) --_000_7594FB04B1934943A5C02806D1A2204B1C5815BCESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Paul,

=85
=85
=85

> The first mid in the bundle group in the answer determines which addre= ss
> in the offer will be the bundle address. This restates what you have i= n
> 6.4.2.

Correct.

>> The only thing which matters is whether the Offer contained addres= ses that are different
>> from the determined BUNDLE address (in the initial Offer that= will always be the case, as
>> each address with a non-zero port value must be unique).=
>
> That isn't always true. When making this determination, the offerer > should only consider m-lines that were accepted in the answer.

Ok, I hear you. That is correct, and must be clear in the text.
> It might have to send a BAS if all the m-lines were accepted, but not =
> need to do so if some were rejected and all the ones that were accepte= d
> matched the bundle address.

Yes.

>The trick is figuring out how to state that.

Perhaps something like:

=93When an Offerer receives an Answer, in which an offered BUNDLE = group has
been accepted by the Answerer, the Offer checks each =93= m=3D=94 line within the
accepted BUNDLE group against the following criteria:

o  In the Offer the Offerer assigned an address (unique or sh= ared) to
    the "m=3D" line, that is different than t= he BUNDLE address determined
    by the Answerer Section 6.4.2.=94

Regards,

Christer (from LH404, somewhere over the English channel)

--_000_7594FB04B1934943A5C02806D1A2204B1C5815BCESESSMB209erics_-- From palmarti@cisco.com Mon Dec 9 05:01:03 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00A01AE2C0 for ; Mon, 9 Dec 2013 05:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKGFiOCUFWhb for ; Mon, 9 Dec 2013 05:01:01 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 314A51AE2BD for ; Mon, 9 Dec 2013 05:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2189; q=dns/txt; s=iport; t=1386594057; x=1387803657; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=UIv2DnbxhPV25aQoB+XJ5vEOxkiZ3E/JXwd8eQQAoiU=; b=T4q0z5FgG31xi4Ajyx+KnaxGYe6rz8ABScfP8iMr8AzuF6LHJpoSdocW KWwnFzr6TF12N3HQ5/y7gsEIc7TZi88v4Evk4butHrppuoDzqXQGB5dgv Vrlpftk1YNdaGshG46ceXIK6vgXkAgMYJeem+Dd8XHQdGpNi4MzyaEaQr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAKq9pVKtJXG+/2dsb2JhbABZgwc4TQa5FIEuFnSCJQEBAQMBdwIFCwIBGQMBAi8yGwIIAgQOBQmHcwYIBcEpF48QDYMagRMDiQqPCoEwkGODKYIq X-IronPort-AV: E=Sophos;i="4.93,857,1378857600"; d="scan'208";a="290276502" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 09 Dec 2013 13:00:56 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9D0u9l024531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 13:00:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.52]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 07:00:55 -0600 From: "Pal Martinsen (palmarti)" To: mmusic Thread-Topic: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt Thread-Index: AQHO9Nf3LTmEmk2oB0mZBhTvCzfE0A== Date: Mon, 9 Dec 2013 13:00:55 +0000 Message-ID: <540B748E-8B51-4763-B75F-F80ACCFB53D7@cisco.com> References: <20131209121243.31704.62698.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.202.207] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: [MMUSIC] Fwd: New Version Notification for draft-reddy-mmusic-ice-happy-eyeballs-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:01:03 -0000 Hi, We have updated the Happy Eyeballs for ICE document based on feedback from = the MMUSIC session at IETF88. The draft is now simplified and only contains hints on how to solve the pro= blem. No algorithms are proposed. This should be enough to get readers to u= nderstand the problem, and how it can be solved in their ICE implementation= .=20 For the curious people of you I wrote some quick and dirty code to play wit= h the candidate priorities. It can be found at: https://github.com/palerikm/HappyE-ICE-Test. =20 (Disclaimer: Most of the code was written at various airports on the way ho= me from Vancouver..) Below follows the links to the updated draft. .-. P=E5l-Erik Begin forwarded message: > From: > Subject: New Version Notification for draft-reddy-mmusic-ice-happy-eyebal= ls-04.txt > Date: 9 Dec 2013 13:12:43 pm GMT+1 > To: Tirumaleswar Reddy , Prashanth Patil , Paal-Erik Martinsen >=20 >=20 > A new version of I-D, draft-reddy-mmusic-ice-happy-eyeballs-04.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. >=20 > Filename: draft-reddy-mmusic-ice-happy-eyeballs > Revision: 04 > Title: Happy Eyeballs Extension for ICE > Creation date: 2013-12-09 > Group: Individual Submission > Number of pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-reddy-mmusic-i= ce-happy-eyeballs-04.txt > Status: http://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-h= appy-eyeballs > Htmlized: http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-= eyeballs-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-mmusic-ic= e-happy-eyeballs-04 >=20 > Abstract: > This document provides guidelines on how to make ICE [RFC5245] > conclude faster in IPv4/IPv6 dual-stack scenarios where broken paths > exists. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From dwing@cisco.com Mon Dec 9 18:57:26 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123261AE10A for ; Mon, 9 Dec 2013 18:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydvMNasEb-6P for ; Mon, 9 Dec 2013 18:57:24 -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 D20DD1AE107 for ; Mon, 9 Dec 2013 18:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=996; q=dns/txt; s=iport; t=1386644240; x=1387853840; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wlQpY9OsC14tW+zWYskeRmZ1TWy/RiyfWiLHlkCxqTw=; b=O+/JvXZm3GIHIs6yqnWiqwxkQ2sCdscDK8M2DeoCHXr+mzvV8CqJj7Bk /u/dw5Q8kNzEsQOjBiTf1pjBt9Qz4JHI30yWiz3MJoM66DSJk06UPP7ZB rr9RbdQ2yb0tIJxEE/b7CGmMknUdUtZShOOppSZu19p355J8gfxwr36GZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHyCplKrRDoH/2dsb2JhbABZgwc4uWaBIhZ0giUBAQECAQFnEgULUVcGEwmHcwUOwE0XjxAHgyCBEwOJQo5SkhOBa4FfGw X-IronPort-AV: E=Sophos;i="4.93,862,1378857600"; d="scan'208";a="97462763" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 10 Dec 2013 02:57:20 +0000 Received: from sjc-vpn2-347.cisco.com (sjc-vpn2-347.cisco.com [10.21.113.91]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBA2vHW5024842; Tue, 10 Dec 2013 02:57:17 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <52A2548E.3030400@cisco.com> Date: Mon, 9 Dec 2013 18:57:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1BD2AAA8-6FC3-46B1-9435-F138EFA7B1A6@cisco.com> References: <52A2548E.3030400@cisco.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.1510) Cc: mmusic WG Subject: [MMUSIC] PCP implementation status [was Re: Draft MMUSIC Meeting Minutes from IETF88] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:57:26 -0000 On Dec 6, 2013, at 2:49 PM, Flemming Andreasen = wrote: > Greetings >=20 > We have uploaded the draft meeting minutes for the two MMUSIC sessions = at IETF 88 in Vancouver at: >=20 > http://www.ietf.org/proceedings/88/minutes/minutes-88-mmusic >=20 > Please take a look and let us know if you have any questions or = comments. Perhaps not to add to your meeting minutes, but I remembered this while = reviewing the minutes: "Lennox: Is PCP seeing substantial deployment at this point ? =95 Dan: Some for PCP but none for this extension. There is a = document in RTCWeb describing the value. Vendors making Carrier Grade = NATs are interested/supporting. Can be implemented entirely in = user-space." at the PCP meeting on Friday morning, Stuart Cheshire presented that iOS = 7, OS X 10.9 (Mavericks), and Apple Airports implement PCP with NAT-PMP = feature parity, = http://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf.=20 -d From internet-drafts@ietf.org Fri Dec 13 04:47:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B991AE24F; Fri, 13 Dec 2013 04:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smy3rzMex4j1; Fri, 13 Dec 2013 04:47:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B43A71A1F76; Fri, 13 Dec 2013 04:47:47 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131213124747.24314.62113.idtracker@ietfa.amsl.com> Date: Fri, 13 Dec 2013 04:47:47 -0800 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-mux-attributes-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 12:47:49 -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 : A Framework for SDP Attributes when Multiplexing Author(s) : Suhas Nandakumar Filename : draft-ietf-mmusic-sdp-mux-attributes-00.txt Pages : 56 Date : 2013-12-12 Abstract: The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=3D" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Sessions multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Mon Dec 16 10:38:49 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96831AE0C6 for ; Mon, 16 Dec 2013 10:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XyQ9ALlQLbw for ; Mon, 16 Dec 2013 10:38:48 -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 F12A51AE031 for ; Mon, 16 Dec 2013 10:38:47 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id 2D3U1n00227AodY5AJenR2; Mon, 16 Dec 2013 18:38:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 2Jem1n01F3ZTu2S3fJemEF; Mon, 16 Dec 2013 18:38:47 +0000 Message-ID: <52AF48B6.8060107@alum.mit.edu> Date: Mon, 16 Dec 2013 13:38:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: IETF MMUSIC WG References: <52AEF91E.3030101@ericsson.com> In-Reply-To: <52AEF91E.3030101@ericsson.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=1387219127; bh=EXVLIdqE7+LyGgoo1w/KRcHOHQGE1mv14Cnnc9U7NLw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Z0ElP5t8zsrQlnH9sR9qlhNh1WlBXxkzYbfd6gB6ZBJI0LcXy4WNUzTBCkVNkvf07 QJE7b7qnJVLQmi3I8L/q7Zi7s0Wegt+p5v4qYW5cyu5n+Vi6R/rBsBgHFZOjH+70b7 MzRI/GZOMhERzb+tiZ6ZNEP4wvpp0v9GCWp9Ibo8B7kCnmFBKTItcCzlpNrl7sd6Z9 kBJB19g8XNNiVa0M8sG8YslP0fzI27y5E1OAkxoXkFcJ63K+npu/PVHmAeK6HbsjcO SKY6ZfuFYLyC7Paerm4V7pKZ9zyyDrUPMVZB9mYpHyYLK8BMZe1siHSvpaCnyJJ72l AIH5A0+8q+y4A== Subject: Re: [MMUSIC] Reviewing the SCTP SDP draft - draft-ietf-mmusic-sctp-sdp-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 18:38:49 -0000 Here is the review I promised of draft-ietf-mmusic-sctp-sdp-05. (This isn't a full WGLC-like review. I focused on things that popped up in the diff from the prior version. That gave me enough.) There are a number of problems in section 5.1: > sctpmap-attr = "a=sctpmap:" sctpmap-number media-subtypes [streams] Nit: This line is too long. > sctpmap-number = 1*DIGIT > protocol = labelstring > labelstring = text > text = byte-string > streams = 1*DIGIT The "media-subtypes" in this draft replaces "protocol" in the prior version. But this change is incomplete. The symbol "media-subtypes" is not defined, but the old symbol "protocol" is still defined but unreferenced. Just renaming the definition of "protocol" isn't a sufficient fix - that definition has its own problems. It is currently ultimately defined as a byte-string. This allows almost anything, and so it is incompatible with allowing anything else on the line after it. (Such as "[streams]".) A more restrictive definition is needed. (E.g., "token".) I note that "media-subtypes" is plural. Is that intended? Is there a desire to allow more than one? There is *no* discussion of "media-subtypes" in the document. That also needs to be fixed. While I understand the intent, IMO the symbol "streams" is not ideal. It sounds like something intended to identify specific streams rather than a bound on the number of streams. I suggest renaming this to something like "max-streams". A possibility to clean up some of the things above is: sctpmap-attr = "a=sctpmap:" sctpmap-number media-subtypes [max-streams] sctpmap-number = 1*DIGIT media-subtypes = token max-streams = 1*DIGIT My first thought was that "media-subtypes" was intended to specify a mime-type, such as is used to define a codec. And the examples using T38 suggest that. But if that is so, it needs to have both type and subtype (e.g., "image/t38"), and that would require a further syntax change. But I don't think that works. ISTM that the protocol needs to be defined per sctp-stream-id. Defining it for an entire sctp port would mean that all the streams would have the same mime-type. That is generally unrealistic. I think addressing that means defining a new attribute. And that is already being addressed by draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00. Perhaps "media-subtypes" isn't needed at all. Thanks, Paul On 12/16/13 7:59 AM, Ari Keränen wrote: > Hi Ekr, Paul, and Roni, > > Thanks once more for volunteering at the Vancouver meeting to review the > SCTP SDP draft. We hope to see your reviews soon so that we can move the > draft forward. > > Here's a link to the latest revision: > http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05 > > > Cheers, > Ari > From pkyzivat@alum.mit.edu Tue Dec 17 14:01:08 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45AE1AC82B for ; Tue, 17 Dec 2013 14:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTWgi4t0JGgU for ; Tue, 17 Dec 2013 14:01:07 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 040E81A1F19 for ; Tue, 17 Dec 2013 14:01:06 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id 2lap1n0040Fqzac56m15NM; Tue, 17 Dec 2013 22:01:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 2m151n0063ZTu2S3Um151e; Tue, 17 Dec 2013 22:01:05 +0000 Message-ID: <52B0C9A1.6060301@alum.mit.edu> Date: Tue, 17 Dec 2013 17:01:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Harald Alvestrand References: <52AF101F.2000007@ericsson.com> <52AF115F.2070803@alvestrand.no> <52B0428F.2040905@ericsson.com> In-Reply-To: <52B0428F.2040905@ericsson.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=1387317665; bh=HesEvlYyQyBFgTtDInK8dDVK46CC0Xxoc8DEyWxZSWw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WSylD4lZiQAqjjSplniRZDo7sr4oPbGEp0gBxEtAPaHg4CcDGDGTPsOYMbvZ1/2JN YAjmTxaaZE5uT7J3gEJl3u2zv4OCyuKmT9umH5pwNHDMOontiMlD3/OCP/Ampmt8Kp m1gyHn2PU/W/MDJlgq8y5aHNMkzTSE3PIGbuD5QcPefmihuwBCufJpId+wFKXajy1n +JTdXJHXsrI4aHpYzpYkH0IQD53Dml9gThIDGgHiuYengB4rNx4LSZJwAZiW9GZIzv C37Oz40Kevm82voT6darLnReckrlwNYgxyo/2QGQFR0cZiww5p/kFD6kKkgZjgdpF0 PIt2abJWgnARg== Cc: IETF MMUSIC WG Subject: [MMUSIC] Some comments on draft-ietf-mmusic-msid-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 22:01:09 -0000 In Vancouver I volunteered to look at this version of the msid draft, especially wrt its relationship to the app-token draft. After looking, IMO some things can be done to this draft that will not effect its substance, but will more clearly separate its concerns from those of app-token and unified-plan. The unified-plan has gotten us to a point where individual source streams each have their own m-line. The app-token draft is defining a mechanism that will provide allow a level of indirection to SSRCs. That hasn't matured to the point of being picked up in unified-plan, but I hope it eventually will be. The problem I see now is that this msid draft is still filled with lots of reference to SSRCs, even though the mechanism it specifies no longer is at all dependent on SSRCs. The mechanism is solely for the purpose of attaching related identifiers to m-lines and groups of m-lines. How those m-lines are associated with SSRCs and/or appids is better left to other documents. If it is so decoupled, then it will be easy to progress this one. Then we can leave it to unified-plan and app-token to do their thing. And in the future, if new mechanisms are defined to bind streams to m-lines, then this document will remain valid. Some specifics: * Section 1.2: The SDP grouping framework [RFC5888] can be used to group m-lines. However, there is sometimes the need for an application to specify some application-level information about the association between the SSRC and the group. This is not possible using the SDP grouping framework. s/SSRC/m-line/ * Section 1.3: In the RTP specification, media streams are identified using the SSRC field. Streams are grouped into RTP Sessions, and also carry a CNAME. Neither CNAME nor RTP session correspond to a MediaStream. Therefore, the association of an RTP media stream to MediaStreams need to be explicitly signaled. I think this entire paragraph can be dropped. The following paragraph is sufficient. * Section 2: Endpoints can update the associations between SSRCs as expressed by msid attributes at any time; the semantics and restrictions of such grouping and ungrouping are application dependent. s/SSRCs/m-lines/ * Section 4: This section creates a new semantic for use with the framework defined in Section 2, to be used for associating SSRCs representing MediaStreamTracks within MediaStreams as defined in [W3C.WD-webrtc-20120209]. s/SSRCs/m-lines/ In a WebRTC-compatible SDP description, all SSRCs intending to be sent from one peer will be identified in the SDP generated by that entity. I'm not sure about the above. It's true now based on unified-plan. It might be altered by the use of app-token. In addition to signaling that the track is closed when it disappears from the SDP, the track will also be signaled as being closed when all associated SSRCs have disappeared by the rules of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout). Another one I'm not sure about. If app-token is used to define m-lines, then it ceases to be so clear when the track should close. Maybe it should close if a BYE or timeout is received on the last SSRC bound to the app-token. Or maybe not. This probably needs more work. But is this the right draft to specify that? * Section 5: o The attribute gives an association over a set of m-lines. It can be used to signal the relationship between a WebRTC MediaStream and a set of SSRCs. s/SSRCs/m-lines/ * Appendices: I'm ignoring them. Thanks, Paul On 12/17/13 7:24 AM, Ari Keränen wrote: > On 12/16/13 4:42 PM, Harald Alvestrand wrote: >> On 12/16/2013 03:37 PM, Ari Keränen wrote: >>> Hi Roni and Paul, >>> >>> At the Vancouver meeting we discussed that the MSID draft would need >>> more review and input, also regarding it's relationship with the >>> app-token draft. You guys volunteered to have a look at the new >>> version Harald submitted during the meeting: >>> http://tools.ietf.org/html/draft-ietf-mmusic-msid-02 >>> >>> When you have a chance, would be great if you can check out the draft >>> and post your comments on the list. >>> >>> >>> Thanks, >>> Ari >> There was also significant input on the document in the WEBRTC WG >> meeting in Shenzhen - especially around the subject of non-signalled >> SSRCs. >> >> I'll issue an updated version based on that; if you can get feedback in >> soon I can incorporate that too. >> > > Thanks for the update Harald! Could you summarize that input to the > mailing list so that the WG is up to speed with the discussion? > > > Cheers, > Ari > From pkyzivat@alum.mit.edu Tue Dec 17 15:17:52 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1462B1ACCE8 for ; Tue, 17 Dec 2013 15:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNQNvTzC6F0Q for ; Tue, 17 Dec 2013 15:17:51 -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 CAC0D1A1F5B for ; Tue, 17 Dec 2013 15:17:50 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2jSH1n00E27AodY53nHpgj; Tue, 17 Dec 2013 23:17:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 2nHp1n0013ZTu2S3fnHpar; Tue, 17 Dec 2013 23:17:49 +0000 Message-ID: <52B0DB9C.2000405@alum.mit.edu> Date: Tue, 17 Dec 2013 18:17:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C56CEF0@ESESSMB209.ericsson.se>, <52A0BED9.9010405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C5815BC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5815BC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387322269; bh=azUMbH3faL9aLrzI9wO0oDAs8WQT1Y1AyrGf1Dog+1I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jqG48RWe22ZISrzSDfogHx/WNCOqvehGg/rorndOAdYWF8ewNc+0PGLFqTyfIFeW9 jIZNZZ529lkW4taWYTxNvlKZq1EZnxxVc1A01io8RvXQZjycTBqo3wIk7bzT5jQsJG oS9/hjI2aD1Dm987hintLGmG0VmV7C2tEHudaEFQN+n4qF0cxDjtaqtwjv0e6YT1ij TF81gOz2qwbxsdiMbqoke30xwXvFTxOKfzBsRmvO4KcNmFTnK/MT2fh/qV9ssDyv80 XcowZnTlcecU//hqkw0igMVOjFZHRbU7BHD1N+d7UZ7FsZgqZA3lPtDdqDmL/U+4Bi KmAXbYnnOld0Q== Cc: 'mmusic' Subject: Re: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-05 - Paul's comments 20131027 - Section 6.4.3 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 23:17:52 -0000 I guess this will work. Thanks, Paul On 12/8/13 1:04 PM, Christer Holmberg wrote: > Hi Paul, > > … > … > … > > > The first mid in the bundle group in the answer determines which address > > in the offer will be the bundle address. This restates what you have in > > 6.4.2. > > Correct. > > >> The only thing which matters is whether the Offer contained > addresses that are different > >> from the determined BUNDLE address (in the initial Offer that will > always be the case, as > >> each address with a non-zero port value must be unique). > > > > That isn't always true. When making this determination, the offerer > > should only consider m-lines that were accepted in the answer. > > Ok, I hear you. That is correct, and must be clear in the text. > > > It might have to send a BAS if all the m-lines were accepted, but not > > need to do so if some were rejected and all the ones that were accepted > > matched the bundle address. > > Yes. > > >The trick is figuring out how to state that. > > Perhaps something like: > > /“When an Offerer receives an Answer, in which an offered BUNDLE group has / > /been accepted by the Answerer, the Offer checks each “m=” line within the / > /accepted BUNDLE group against the following criteria:/ > // > /o In the Offer the Offerer assigned an address (unique or shared) to > the "m=" line, that is different than the BUNDLE address determined / > / by the Answerer Section 6.4.2.” > / > > Regards, > > Christer (from LH404, somewhere over the English channel) > From bernard_aboba@hotmail.com Tue Dec 17 15:46:40 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C093D1AD937 for ; Tue, 17 Dec 2013 15:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXBF0QEpcY4j for ; Tue, 17 Dec 2013 15:46:39 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfa.amsl.com (Postfix) with ESMTP id 091E31A1F5B for ; Tue, 17 Dec 2013 15:46:38 -0800 (PST) Received: from BLU169-W23 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Dec 2013 15:46:38 -0800 X-TMN: [b3/dN0n7SD36aA0zaRoV9WoQ2kb7+jzv] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c15992a5-97df-4505-928f-10f5b6abd2fe_" From: Bernard Aboba To: "mmusic@ietf.org" Date: Tue, 17 Dec 2013 15:46:37 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2013 23:46:38.0274 (UTC) FILETIME=[3A4C9220:01CEFB82] Subject: [MMUSIC] Review of draft-even-mmusic-application-token X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 23:46:41 -0000 --_c15992a5-97df-4505-928f-10f5b6abd2fe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Overall=2C the focus of this document seems to be more on appID than on rec= v-appID. This puzzles me=2C because I had assumed that most of the value = was in the recv-appID=2C since that allows the Offerer to demultiplex by ap= pID=2C even before the Answer is received. Yet appID is used in many of th= e Offers in situations where the Answerer would be able to demultiplex by P= ayload Type. =20 =20 Perhaps the issue is that the a=3Drecv-appID syntax is not yet expressive e= nough to provide a solution in situations where the same payload type is us= ed to receive multiple resolutions. =20 =20 A revised syntax was hinted at during IETF 88 which seems like it would rep= resent an improvement: =20 a=3DappID:1 imageattr:98 send [x=3D480=2Cy=3D320] =20 =20 =20 =20 Some specific comments:=20 =20 Section 1 =20 a=3Dssrc-group:DDP 1000 1010 In this case all video streams are from the same source and can be described using a single m-line. The grouping relations are specified using the SSRCs values that need to be available in the offer. It is also not clear based on the offer which SSRC is mapped to each of the PT numbers. =20 [BA] Unless I'm mis-reading the SDP=2C it would appear that distinct SSRCs = are being used for the base layer and the extension layer (isn't that what = the a=3Dssrc-group:DDP line is for?). This would imply that the Offer is = for H.264/SVC MST=2C no? =20 =20 Section 3.1 =20 The second example is when the application usage of the RTP steam is specified using SDP to provide different image resolutions. The media receiver can map the received SSRC to the specific resolution based on the appId. a=3Dgroup:SCR 1 2 m=3Dvideo 49200 RTP/AVP 98 a=3Drtpmap:98 H264/90000 imageattr:98 send [x=3D640=2Cy=3D360] recv[[x=3D640=2Cy=3D360] [x=3D320=2C= y=3D180] a=3Dmsid:ma ta a=3DappID:2 a=3Dmid:1 m=3Dvideo 49200 RTP/AVP 99 a=3Drtpmap:99 H264/90000 imageattr:99 send [x=3D320=2Cy=3D180] a=3Dmsid:ma ta a=3DappID:3 a=3Dmid:2 a=3Dsendonly =20 [BA] Aside from the syntactic issues (e.g. s/appId/appID/=2C a=3Dimageattr= =2C [[)=2C I am missing the point of this example. When sending=2C the reso= lutions can be distinguished by payload type=2C but on receiving both 640 b= y 320 and 320 by 180 resolutions use the same payload type 98=2C so isn't t= he problem really on the receiving side? Perhaps the revised syntax propos= ed at IETF 88 would help: =20 Offer =20 a=3Dgroup:SCR 1 2 m=3Dvideo 49200 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3DappID:2 send [x=3D640=2Cy=3D360] a=3Drecv-appID:10 recv [x=3D640=2Cy=3D320] a=3Drecv-appID:20 recv [x=3D320=2Cy=3D180] a=3Dmid:1 m=3Dvideo 49202 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 send [x=3D320=2Cy=3D180]=20 a=3DappID:3 a=3Dsendonly a=3Dmid:2 =20 Answer =20 a=3Dgroup:SCR 1 2 m=3Dvideo 28000 RTP/AVP 98 a=3Drtpmap:98 H264/90000 a=3Dfmtp:98 profile-level-id=3D42c01e a=3Drecv-appID:2 recv [x=3D640=2Cy=3D360] a=3DappID:10 send [x=3D640=2Cy=3D320] a=3DappID:20 send [x=3D320=2Cy=3D180] a=3Dmid:1 m=3Dvideo 28002 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3Dfmtp:99 profile-level-id=3D42c01e a=3Dimageattr:99 recv [x=3D320=2Cy=3D180] a=3Drecv-appID:3 a=3Drecvonly a=3Dmid:2 =20 Section 4 =20 m=3Dvideo 49200 RTP/AVP 99 a=3Drtpmap:99 H264/90000 a=3DappID 2 a=3Drecv-appId 10 a=3Dssrc:20010 CNAME:v1@example.com m=3Dvideo 49200 RTP/AVP 100 a=3Drtpmap:100 H264/90000 a=3DappID 3 a=3Drecv-appId 20 a=3Dssrc:20010 CNAME:v2@example.com =20 [BA] Shouldn't the example look more like this? (for a second BUNDLE offer)= : =20 a=3Dgroup:BUNDLE 1 2 m=3Dvideo 49200 RTP/AVP 99 a=3Dmid:1 a=3Drtpmap:99 H264/90000 a=3DappID:2 a=3Drecv-appID:10 a=3Dssrc:20010 CNAME:v1@example.com m=3Dvideo 49200 RTP/AVP 100 a=3Dmid:2 a=3Drtpmap:100 H264/90000 a=3DappID:3 a=3Drecv-appID:20 a=3Dssrc:20010 CNAME:v2@example.com =20 Section 4=2C second example =20 [BA] The example should look like this=2C no? (for a first BUNDLE offer) =20 a=3Dgroup:BUNDLE m1 m2 m3 m4 R1 a=3Dgroup:FEC-FR m2 m3 m4 R1 m=3Daudio 56600 RTP/SAVPF 109 a=3Dmid:m1 a=3Dmsid:ma ta a=3DappID:1 a=3Dssrc:53280 a=3Drtpmap:109 opus/48000 m=3Dvideo 56602 RTP/AVPF 100 - left camera a=3Dmid:m2 a=3Dmsid:ma tb a=3DappID:2 a=3Drtpmap:100 H264/90000 a=3Dssrc:1000 cname:MSTFEC@example.com m=3Dvideo 56604 RTP/AVPF 101- Middle camera a=3Dmid:m3 a=3Dmsid:ma tc a=3DappID:3 a=3Drtpmap:101 H264/90000 a=3Dssrc:1010 cname:MSTFEC@example.com m=3Dvideo 56606 RTP/AVPF 102 - Right camera a=3Dmid:m4 a=3Dmsid:ma td a=3DappID:4 a=3Drtpmap:102 H264/90000 a=3Dssrc:1020 cname:MSTFEC@example.com m=3Dvideo 56608 RTP/AVP 110 a=3Drtpmap:110 1d-interleaved-parityfec/90000 a=3Dfmtp:110 L=3D5=3B D=3D10=3B repair-window=3D200000 a=3Dmid:R1 a=3DappID:5 =0A= =0A= =0A= =0A= = --_c15992a5-97df-4505-928f-10f5b6abd2fe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Overall=2C the focus of this doc= ument seems to be more on appID than on recv-appID. =3B =3B This pu= zzles me=2C because I had assumed that most of the value was in the recv-ap= pID=2C since that allows the Offerer to demultiplex by appID=2C even before= the Answer is received. =3B Yet appID is used in many of the Offers in= situations where the Answerer would be able to demultiplex by Payload Type= . =3B
 =3B
Perhaps the issue is that the a=3Drecv-appID synt= ax is not yet expressive enough to provide a solution in situations where t= he same payload type is used to receive multiple resolutions. =3B = =3B
 =3B
A revised syntax was hinted at during IETF 88 which see= ms like it would represent an improvement:
 =3B
a=3DappID:1 image= attr:98 send [x=3D480=2Cy=3D320]
 =3B
 =3B
=  =3B
 =3B
Some specific comments:
 =3B<= BR>Section 1
 =3B
 =3B =3B =3B =3B =3B a=3Dss= rc-group:DDP 1000 1010

 =3B =3B In this case all video strea= ms are from the same source and can be
 =3B =3B described using = a single m-line. =3B The grouping relations are
 =3B =3B spe= cified using the SSRCs values that need to be available in the
 =3B&= nbsp=3B offer. =3B It is also not clear based on the offer which SSRC i= s mapped
 =3B =3B to each of the PT numbers.
 =3B
[BA]= Unless I'm mis-reading the SDP=2C it would appear that distinct SSRCs are = being used for the base layer and the extension layer (isn't that what the = a=3Dssrc-group:DDP line is for?). =3B =3B This would imply that the= Offer is for H.264/SVC MST=2C no? =3B
 =3B
Section 3.1
&= nbsp=3B
 =3B =3B The second example is when the application usag= e of the RTP steam is
 =3B =3B specified using SDP to provide di= fferent image resolutions. =3B The
 =3B =3B media receiver c= an map the received SSRC to the specific resolution
 =3B =3B bas= ed on the appId.

a=3Dgroup:SCR 1 2
m=3Dvideo 49200 RTP/AVP 98
= a=3Drtpmap:98 H264/90000
imageattr:98 send [x=3D640=2Cy=3D360] =3B r= ecv[[x=3D640=2Cy=3D360] [x=3D320=2Cy=3D180]
a=3Dmsid:ma ta
a=3DappID:= 2
a=3Dmid:1
m=3Dvideo 49200 RTP/AVP 99
a=3Drtpmap:99 H264/90000imageattr:99 send [x=3D320=2Cy=3D180]
a=3Dmsid:ma ta
a=3DappID:3
= a=3Dmid:2
a=3Dsendonly
 =3B
[BA] =3B Aside from the syntac= tic issues (e.g. s/appId/appID/=2C a=3Dimageattr=2C [[)=2C I am missing the= point of this example. =3BWhen sending=2C the resolutions can be disti= nguished by payload type=2C but on receiving both 640 by 320 and 320 by 180= resolutions use the same payload type 98=2C so isn't the problem really on= the receiving side? =3B Perhaps the revised syntax proposed at IETF 88= would help:
 =3B
Offer
 =3B
a=3Dgroup:SCR 1 2
m=3Dv= ideo 49200 RTP/AVP 98
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 profile-le= vel-id=3D42c01e
a=3DappID:2 send [x=3D640=2Cy=3D360]
a=3Drecv-appID:1= 0 recv [x=3D640=2Cy=3D320]
a=3Drecv-appID:20 recv [x=3D320=2Cy=3D180]a=3Dmid:1
m=3Dvideo 49202 RTP/AVP 99
a=3Drtpmap:99 H264/90000
a= =3Dfmtp:99 profile-level-id=3D42c01e
a=3Dimageattr:99 send [x=3D320=2Cy= =3D180] =3B
a=3DappID:3
a=3Dsendonly
a=3Dmid:2
 =3B
= Answer
 =3B
a=3Dgroup:SCR 1 2
m=3Dvideo 28000 RTP/AVP 98
a= =3Drtpmap:98 H264/90000
a=3Dfmtp:98 profile-level-id=3D42c01e
a=3Drec= v-appID:2 recv [x=3D640=2Cy=3D360]
a=3DappID:10 =3Bsend [x=3D640=2Cy= =3D320]
a=3DappID:20 send [x=3D320=2Cy=3D180]
a=3Dmid:1
m=3Dvideo = 28002 RTP/AVP 99
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 profile-level-i= d=3D42c01e
a=3Dimageattr:99 recv [x=3D320=2Cy=3D180]
a=3Drecv-appID:3=
a=3Drecvonly
a=3Dmid:2
 =3B
Section 4
 =3B
m=3Dv= ideo 49200 RTP/AVP 99
a=3Drtpmap:99 H264/90000
a=3DappID 2
a=3Drec= v-appId 10
a=3Dssrc:20010 CNAME:v1@example.com
m=3Dvideo 49200 RTP/AV= P 100
a=3Drtpmap:100 H264/90000
a=3DappID 3
a=3Drecv-appId 20
a= =3Dssrc:20010 CNAME:v2@example.com
 =3B
[BA] Shouldn't the exampl= e look more like this? (for a =3Bsecond BUNDLE offer):
 =3B
a= =3Dgroup:BUNDLE 1 2
m=3Dvideo 49200 RTP/AVP 99
a=3Dmid:1
a=3Drtpma= p:99 H264/90000
a=3DappID:2
a=3Drecv-appID:10
a=3Dssrc:20010 CNAME= :v1@example.com
m=3Dvideo 49200 RTP/AVP 100
a=3Dmid:2
a=3Drtpmap:1= 00 H264/90000
a=3DappID:3
a=3Drecv-appID:20
a=3Dssrc:20010 CNAME:v= 2@example.com
 =3B
Section 4=2C second example
 =3B
[BA= ] The example should look like this=2C no? (for =3Ba first =3BBUNDL= E offer)
 =3B
a=3Dgroup:BUNDLE m1 m2 m3 m4 R1
a=3Dgroup:FEC-FR= m2 m3 m4 R1
m=3Daudio 56600 RTP/SAVPF 109
a=3Dmid:m1
a=3Dmsid:ma = ta
a=3DappID:1
a=3Dssrc:53280
a=3Drtpmap:109 opus/48000
m=3Dvid= eo 56602 RTP/AVPF 100 - left camera
a=3Dmid:m2
a=3Dmsid:ma tb
a=3D= appID:2
a=3Drtpmap:100 H264/90000
a=3Dssrc:1000 cname:MSTFEC@example.= com
m=3Dvideo 56604 RTP/AVPF 101- Middle camera
a=3Dmid:m3
a=3Dmsi= d:ma tc
a=3DappID:3
a=3Drtpmap:101 H264/90000
a=3Dssrc:1010 cname:= MSTFEC@example.com
m=3Dvideo 56606 RTP/AVPF 102 - Right camera
a=3Dmi= d:m4
a=3Dmsid:ma td
a=3DappID:4
a=3Drtpmap:102 H264/90000
a=3Ds= src:1020 cname:MSTFEC@example.com
m=3Dvideo 56608 RTP/AVP 110
a=3Drtp= map:110 1d-interleaved-parityfec/90000
a=3Dfmtp:110 L=3D5=3B D=3D10=3B r= epair-window=3D200000
a=3Dmid:R1
a=3DappID:5
=0A= =0A=

=  =3B

=0A= =0A=
= --_c15992a5-97df-4505-928f-10f5b6abd2fe_-- From martin.thomson@gmail.com Tue Dec 17 16:27:59 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C611ADEC0 for ; Tue, 17 Dec 2013 16:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy20fs83Bqqh for ; Tue, 17 Dec 2013 16:27:57 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 464E81ADF50 for ; Tue, 17 Dec 2013 16:27:57 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so6803292wes.41 for ; Tue, 17 Dec 2013 16:27:55 -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=GJ+gOC5IoaqMPj/56DrR7zjf9vW2S3o8Wl6wNY4LaBY=; b=LgrbEr5Ir3WCPk7Qp4lTbdTlccd96sy9HcoGez0J6s1xW9szeyYCT083VlrZwojvWP 5BglZ4Zsqrb4H/6FOrYLtkvcFRJN99smiaq7YlRAD/j0wDX+5V702pLkU3zNtJvTwFZM yJjX9fxqTZrbxzSNCD61J1q2uyk/7fOEhovDI5k21JY36w38JuaTNH4JpVl2fzrdbadJ ZI7oYn7WrVAGzxJmSP0KPf3ZZXByEWwJM/feAd42gJYgcpiLq1b2HMRQMgZJPSX+JwOp yvME4tPTdRs2VLY3VvWP6nKqsW2407N72D+tZAZDkop66Ee5AlrOKHxnUUTuCiRbBzSA bZHg== MIME-Version: 1.0 X-Received: by 10.194.85.75 with SMTP id f11mr22060609wjz.14.1387326475632; Tue, 17 Dec 2013 16:27:55 -0800 (PST) Received: by 10.227.134.195 with HTTP; Tue, 17 Dec 2013 16:27:55 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Dec 2013 16:27:55 -0800 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-even-mmusic-application-token X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 00:27:59 -0000 On 17 December 2013 15:46, Bernard Aboba wrote: > a=appID:1 imageattr:98 send [x=480,y=320] I don't know, I thought that that was a terrible idea. It means that in order to perform the correlation to signaling, you have to start decoding at least as far as you need to get resolution. Architecturally, that's going to involve all sorts of contortions to get right. From bernard_aboba@hotmail.com Tue Dec 17 23:02:02 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC961AE111 for ; Tue, 17 Dec 2013 23:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_n9yoSdOez3 for ; Tue, 17 Dec 2013 23:02:01 -0800 (PST) Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id D9D1F1AE06B for ; Tue, 17 Dec 2013 23:02:00 -0800 (PST) Received: from BLU169-W18 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Dec 2013 23:01:59 -0800 X-TMN: [OaUOKLWNAHLDK0+1QKtKoD9l7ObZTc+L] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_93bfd51c-69e4-422c-90fd-f5037d553311_" From: Bernard Aboba To: Martin Thomson Date: Tue, 17 Dec 2013 23:01:59 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 18 Dec 2013 07:01:59.0954 (UTC) FILETIME=[0C089F20:01CEFBBF] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-even-mmusic-application-token X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 07:02:02 -0000 --_93bfd51c-69e4-422c-90fd-f5037d553311_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin said:=20 > Architecturally=2C that's going to involve all sorts of contortions to ge= t right. =20 [BA] No doubt=2C given that adding attributes to appID goes back down the r= oad that Unified Plan attempted to avoid.=20 =20 However=2C that's what I thought the presentation at IETF 88 was saying.=20 =20 To my mind=2C the major benefit was to enable de-multiplexing of media rece= ived prior to the Answer=2C which requires recv-appID.=20 =20 But most of the existing examples either don't illustrate the use of recv-a= ppID=2C or seem like they would work without an a=3DappID line at all=2C a= s long as the PT is unique. In particular=2C in the simulcast example it = doesn't seem like appID adds value (as long as the SSRCs for the simulcast = streams are unique).=20 =20 = --_93bfd51c-69e4-422c-90fd-f5037d553311_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Martin said:

>=3B Arch= itecturally=2C that's going to involve all sorts of contortions to get righ= t.
 =3B
[BA] No doubt=2C given that adding attributes to appID go= es back down the road that Unified Plan attempted to avoid.
 =3BHowever=2C that's what I thought the presentation at IETF 88 was saying. <= BR> =3B
To my mind=2C the major benefit was to enable de-multiplexin= g of media received prior to the Answer=2C which requires recv-appID.
&= nbsp=3B
But most of the existing examples either don't illustrate the us= e of recv-appID=2C =3B or seem like they would work without an a=3DappI= D line at all=2C as long as the PT is unique. =3B =3B In particular= =2C in the simulcast example it doesn't seem like appID adds value (as long= as the SSRCs for the simulcast streams are unique).

 =3B
=
= --_93bfd51c-69e4-422c-90fd-f5037d553311_-- From ron.even.tlv@gmail.com Tue Dec 17 23:56:09 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657591AE2D8 for ; Tue, 17 Dec 2013 23:56:09 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djbP_opzoNB1 for ; Tue, 17 Dec 2013 23:56:07 -0800 (PST) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9F1AE2D6 for ; Tue, 17 Dec 2013 23:56:06 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id b57so3347335eek.40 for ; Tue, 17 Dec 2013 23:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=rDPe1273I8PHmRdy5Xbv/O+X3zPNrzpw27vwub8BbMQ=; b=DC7TQXBaFz9UORVY/dMCQzGNAmyx7Sbrz3Bw0gZvhqxOH6tsRahMHRfm2rPN9eFUJX 8PpEmwPE+2AgtHgF0UBBOXleYt4hHLCodcVX85v6O9CMPuhack3aznr7Y7l7hA42c8JQ EHJeUTmLBWk/veNK9FOu5MNB7JGUDcjOd0y0aXMjs8eLgN96oa4WuoEV6FbVBmki+SJg s6fQDM/nOHssaYSpapNrxsCdjK0ZxGXoJ7f44iTG4JQrnzxcxVXEq7JC/p4YKyAkgtz5 DkuPMCC1eA7rfTalOyGmdu1pyop9gPcBkYqATYKWu0dmAT0+0VPJl+S3v105QacALWsd OPxw== X-Received: by 10.14.184.198 with SMTP id s46mr16199954eem.111.1387353364861; Tue, 17 Dec 2013 23:56:04 -0800 (PST) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id z42sm60056315eeo.17.2013.12.17.23.56.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 Dec 2013 23:56:03 -0800 (PST) From: "Roni Even" To: "'Bernard Aboba'" , References: In-Reply-To: Date: Wed, 18 Dec 2013 09:52:28 +0200 Message-ID: <04f201cefbc6$1bcd9f80$5368de80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F3_01CEFBD6.DF581D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI9UB/Zh6ER9Mz4cDRvYRpLft9f+pl84zVQ Content-Language: en-us Subject: Re: [MMUSIC] Review of draft-even-mmusic-application-token X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 07:56:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F3_01CEFBD6.DF581D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bernard, Thanks for the review, we are currently working on a new revision that will include the appId, recv-appId and appId-group. The authors view is that if we have a single RTP stream described by a single m-line multiplexed using different transport address (not bundled or unify) as seems to be what RFC3264 is about there is no need for any identifier, no use also for a=ssrc When the multiplexing is based on SSRC like in the bundle case or unified if there is more than one RTP stream from a single source we will need some identifier to be able to map the RTP stream to a description in SDP or to an application protocol (CLUE media encoding). This can be done using SSRC but requires that the SSRC will be known or assigned by the signaling layer. We prefer to define a token that will be used to map from the SDP to the RTP layer in the RTP using the SDES and RTP header extensions. For the early media example in the unified document we also need to allow the offerer to specify the receive token. As for your comments see inline Roni From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 18 December, 2013 1:47 AM To: mmusic@ietf.org Subject: [MMUSIC] Review of draft-even-mmusic-application-token Overall, the focus of this document seems to be more on appID than on recv-appID. This puzzles me, because I had assumed that most of the value was in the recv-appID, since that allows the Offerer to demultiplex by appID, even before the Answer is received. Yet appID is used in many of the Offers in situations where the Answerer would be able to demultiplex by Payload Type. Perhaps the issue is that the a=recv-appID syntax is not yet expressive enough to provide a solution in situations where the same payload type is used to receive multiple resolutions. A revised syntax was hinted at during IETF 88 which seems like it would represent an improvement: a=appID:1 imageattr:98 send [x=480,y=320] [Roni Even] We are currently not sure that we will need this type of syntax where the appId will have attributes. We are looking at the simulcast work and will see how it relates to the appId. Some specific comments: Section 1 a=ssrc-group:DDP 1000 1010 In this case all video streams are from the same source and can be described using a single m-line. The grouping relations are specified using the SSRCs values that need to be available in the offer. It is also not clear based on the offer which SSRC is mapped to each of the PT numbers. [BA] Unless I'm mis-reading the SDP, it would appear that distinct SSRCs are being used for the base layer and the extension layer (isn't that what the a=ssrc-group:DDP line is for?). This would imply that the Offer is for H.264/SVC MST, no? [Roni Even] The offer in the example is for H.264/SVC with two FEC streams so there are four possible RTP streams available in the m-line. There are four SSRCs but from the SDP it is not clear how the four SSRCs are mapped to the pt. Section 3.1 The second example is when the application usage of the RTP steam is specified using SDP to provide different image resolutions. The media receiver can map the received SSRC to the specific resolution based on the appId. a=group:SCR 1 2 m=video 49200 RTP/AVP 98 a=rtpmap:98 H264/90000 imageattr:98 send [x=640,y=360] recv[[x=640,y=360] [x=320,y=180] a=msid:ma ta a=appID:2 a=mid:1 m=video 49200 RTP/AVP 99 a=rtpmap:99 H264/90000 imageattr:99 send [x=320,y=180] a=msid:ma ta a=appID:3 a=mid:2 a=sendonly [BA] Aside from the syntactic issues (e.g. s/appId/appID/, a=imageattr, [[), I am missing the point of this example. When sending, the resolutions can be distinguished by payload type, but on receiving both 640 by 320 and 320 by 180 resolutions use the same payload type 98, so isn't the problem really on the receiving side? Perhaps the revised syntax proposed at IETF 88 would help: [Roni Even] I agree and the example was based on a previous version of the simulcast draft from Magnus. We are taking this example out and will look at simulcast when we have a better understanding about it from the currently on going work. There was a presentation at IETF88 by Bo and Magnus and there were comments on the direction, Jonathan and I are discussing with them if and how simulcast may use appId. [Roni Even] your examples on the simulcast are correct Offer a=group:SCR 1 2 m=video 49200 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42c01e a=appID:2 send [x=640,y=360] a=recv-appID:10 recv [x=640,y=320] a=recv-appID:20 recv [x=320,y=180] a=mid:1 m=video 49202 RTP/AVP 99 a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=42c01e a=imageattr:99 send [x=320,y=180] a=appID:3 a=sendonly a=mid:2 Answer a=group:SCR 1 2 m=video 28000 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42c01e a=recv-appID:2 recv [x=640,y=360] a=appID:10 send [x=640,y=320] a=appID:20 send [x=320,y=180] a=mid:1 m=video 28002 RTP/AVP 99 a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=42c01e a=imageattr:99 recv [x=320,y=180] a=recv-appID:3 a=recvonly a=mid:2 Section 4 m=video 49200 RTP/AVP 99 a=rtpmap:99 H264/90000 a=appID 2 a=recv-appId 10 a=ssrc:20010 CNAME:v1@example.com m=video 49200 RTP/AVP 100 a=rtpmap:100 H264/90000 a=appID 3 a=recv-appId 20 a=ssrc:20010 CNAME:v2@example.com [BA] Shouldn't the example look more like this? (for a second BUNDLE offer): a=group:BUNDLE 1 2 m=video 49200 RTP/AVP 99 a=mid:1 a=rtpmap:99 H264/90000 a=appID:2 a=recv-appID:10 a=ssrc:20010 CNAME:v1@example.com m=video 49200 RTP/AVP 100 a=mid:2 a=rtpmap:100 H264/90000 a=appID:3 a=recv-appID:20 a=ssrc:20010 CNAME:v2@example.com Section 4, second example [BA] The example should look like this, no? (for a first BUNDLE offer) [Roni Even] note that the three RTP streams from the three cameras in this example suing bundle can have the same payload type number if they have the same parameters according to bundle. In this case the appId will be used to distinguish between them. There is no need for the a=ssrc in this case. a=group:BUNDLE m1 m2 m3 m4 R1 a=group:FEC-FR m2 m3 m4 R1 m=audio 56600 RTP/SAVPF 109 a=mid:m1 a=msid:ma ta a=appID:1 a=ssrc:53280 a=rtpmap:109 opus/48000 m=video 56602 RTP/AVPF 100 - left camera a=mid:m2 a=msid:ma tb a=appID:2 a=rtpmap:100 H264/90000 a=ssrc:1000 cname:MSTFEC@example.com m=video 56604 RTP/AVPF 101- Middle camera a=mid:m3 a=msid:ma tc a=appID:3 a=rtpmap:101 H264/90000 a=ssrc:1010 cname:MSTFEC@example.com m=video 56606 RTP/AVPF 102 - Right camera a=mid:m4 a=msid:ma td a=appID:4 a=rtpmap:102 H264/90000 a=ssrc:1020 cname:MSTFEC@example.com m=video 56608 RTP/AVP 110 a=rtpmap:110 1d-interleaved-parityfec/90000 a=fmtp:110 L=5; D=10; repair-window=200000 a=mid:R1 a=appID:5 ------=_NextPart_000_04F3_01CEFBD6.DF581D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

Thanks for the review, we are currently working on a new revision = that will include the appId, recv-appId and = appId-group.

 

The authors view is that if we have a single RTP stream described by = a single m-line multiplexed using different transport address (not = bundled or unify) as seems to be what RFC3264 is about there is no need = for any identifier, no use also for a=3Dssrc

When the multiplexing is based on SSRC like in the bundle case or = unified if there is more than one RTP stream from a single source we = will need some identifier to be able to map the RTP stream to a = description in SDP or to an application protocol (CLUE media encoding). = This can be done using SSRC but requires that the SSRC will be known or = assigned by the signaling layer. We prefer to define a token that will = be used to map from the SDP to the RTP layer in the RTP using the SDES = and RTP header extensions.

For the early media example in the unified document we also need to = allow the offerer to specify the receive token.

 

As for your comments see inline

Roni

 

From:= = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard = Aboba
Sent: 18 December, 2013 1:47 AM
To: = mmusic@ietf.org
Subject: [MMUSIC] Review of = draft-even-mmusic-application-token

 

Overall, the focus of this = document seems to be more on appID than on recv-appID.   This = puzzles me, because I had assumed that most of the value was in the = recv-appID, since that allows the Offerer to demultiplex by appID, even = before the Answer is received.  Yet appID is used in many of the = Offers in situations where the Answerer would be able to demultiplex by = Payload Type. 
 
Perhaps the issue is that the = a=3Drecv-appID syntax is not yet expressive enough to provide a solution = in situations where the same payload type is used to receive multiple = resolutions.  
 
A revised syntax was hinted at = during IETF 88 which seems like it would represent an = improvement:
 
a=3DappID:1 imageattr:98 send = [x=3D480,y=3D320]

[Roni Even] We are currently not sure that we will need this type of = syntax where the appId will have attributes. We are looking at the = simulcast work and will see how it relates to the = appId.


 =  
Some = specific comments:
 
Section = 1
 
      a=3Dssrc-group:DDP 1000 = 1010

   In this case all video streams are from the = same source and can be
   described using a single = m-line.  The grouping relations are
   specified using = the SSRCs values that need to be available in the
   = offer.  It is also not clear based on the offer which SSRC is = mapped
   to each of the PT numbers.
 
[BA] = Unless I'm mis-reading the SDP, it would appear that distinct SSRCs are = being used for the base layer and the extension layer (isn't that what = the a=3Dssrc-group:DDP line is for?).   This would imply that = the Offer is for H.264/SVC MST, no? 

[Roni Even] The offer in the example is for H.264/SVC with two FEC = streams so there are four possible RTP streams available in the m-line. = There are four SSRCs but from the SDP it is not clear how the four SSRCs = are mapped to the pt.


 
Section = 3.1
 
   The second example is when the application = usage of the RTP steam is
   specified using SDP to provide = different image resolutions.  The
   media receiver = can map the received SSRC to the specific resolution
   = based on the appId.

a=3Dgroup:SCR 1 2
m=3Dvideo 49200 RTP/AVP = 98
a=3Drtpmap:98 H264/90000
imageattr:98 send = [x=3D640,y=3D360]  recv[[x=3D640,y=3D360] = [x=3D320,y=3D180]
a=3Dmsid:ma = ta
a=3DappID:2
a=3Dmid:1
m=3Dvideo 49200 RTP/AVP = 99
a=3Drtpmap:99 H264/90000
imageattr:99 send = [x=3D320,y=3D180]
a=3Dmsid:ma = ta
a=3DappID:3
a=3Dmid:2
a=3Dsendonly
 
[BA]  = Aside from the syntactic issues (e.g. s/appId/appID/, a=3Dimageattr, = [[), I am missing the point of this example. When sending, the = resolutions can be distinguished by payload type, but on receiving both = 640 by 320 and 320 by 180 resolutions use the same payload type 98, so = isn't the problem really on the receiving side?  Perhaps the = revised syntax proposed at IETF 88 would help:

[Roni Even] I agree and the example was based on a previous version = of the simulcast draft from Magnus. We are taking this example out and = will look at simulcast when we have a better understanding about it from = the currently on going work.  There was a presentation at IETF88 by = Bo and Magnus and there were comments on the direction, Jonathan and I = are discussing with them if and how simulcast may use = appId.


 [Roni Even] your examples on the simulcast are = correct
Offer
 
a=3Dgroup:SCR 1 2
m=3Dvideo = 49200 RTP/AVP 98
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 = profile-level-id=3D42c01e
a=3DappID:2 send = [x=3D640,y=3D360]
a=3Drecv-appID:10 recv = [x=3D640,y=3D320]
a=3Drecv-appID:20 recv = [x=3D320,y=3D180]
a=3Dmid:1
m=3Dvideo 49202 RTP/AVP = 99
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 = profile-level-id=3D42c01e
a=3Dimageattr:99 send = [x=3D320,y=3D180] 
a=3DappID:3
a=3Dsendonly
a=3Dmid:2
&n= bsp;
Answer
 
a=3Dgroup:SCR 1 2
m=3Dvideo 28000 RTP/AVP = 98
a=3Drtpmap:98 H264/90000
a=3Dfmtp:98 = profile-level-id=3D42c01e
a=3Drecv-appID:2 recv = [x=3D640,y=3D360]
a=3DappID:10 send = [x=3D640,y=3D320]
a=3DappID:20 send = [x=3D320,y=3D180]
a=3Dmid:1
m=3Dvideo 28002 RTP/AVP = 99
a=3Drtpmap:99 H264/90000
a=3Dfmtp:99 = profile-level-id=3D42c01e
a=3Dimageattr:99 recv = [x=3D320,y=3D180]
a=3Drecv-appID:3
a=3Drecvonly
a=3Dmid:2
&nb= sp;
Section 4
 
m=3Dvideo 49200 RTP/AVP = 99
a=3Drtpmap:99 H264/90000
a=3DappID 2
a=3Drecv-appId = 10
a=3Dssrc:20010 CNAME:v1@example.com
m=3Dvideo 49200 RTP/AVP = 100
a=3Drtpmap:100 H264/90000
a=3DappID 3
a=3Drecv-appId = 20
a=3Dssrc:20010 CNAME:v2@example.com
 
[BA] Shouldn't = the example look more like this? (for a second BUNDLE = offer):
 
a=3Dgroup:BUNDLE 1 2
m=3Dvideo 49200 RTP/AVP = 99
a=3Dmid:1
a=3Drtpmap:99 = H264/90000
a=3DappID:2
a=3Drecv-appID:10
a=3Dssrc:20010 = CNAME:v1@example.com
m=3Dvideo 49200 RTP/AVP = 100
a=3Dmid:2
a=3Drtpmap:100 = H264/90000
a=3DappID:3
a=3Drecv-appID:20
a=3Dssrc:20010 = CNAME:v2@example.com
 
Section 4, second = example
 
[BA] The example should look like this, no? = (for a first BUNDLE offer)

[Roni Even] note that the three RTP streams from the three cameras in = this example suing bundle can have the same payload type number if they = have the same parameters according to bundle. In this case the appId = will be used to distinguish between them. There is no need for the = a=3Dssrc in this case.
 
a=3Dgroup:BUND= LE m1 m2 m3 m4 R1
a=3Dgroup:FEC-FR m2 m3 m4 R1
m=3Daudio 56600 = RTP/SAVPF 109
a=3Dmid:m1
a=3Dmsid:ma = ta
a=3DappID:1
a=3Dssrc:53280
a=3Drtpmap:109 = opus/48000
m=3Dvideo 56602 RTP/AVPF 100 - left = camera
a=3Dmid:m2
a=3Dmsid:ma tb
a=3DappID:2
a=3Drtpmap:100 = H264/90000
a=3Dssrc:1000 cname:MSTFEC@example.com
m=3Dvideo 56604 = RTP/AVPF 101- Middle camera
a=3Dmid:m3
a=3Dmsid:ma = tc
a=3DappID:3
a=3Drtpmap:101 H264/90000
a=3Dssrc:1010 = cname:MSTFEC@example.com
m=3Dvideo 56606 RTP/AVPF 102 - Right = camera
a=3Dmid:m4
a=3Dmsid:ma td
a=3DappID:4
a=3Drtpmap:102 = H264/90000
a=3Dssrc:1020 cname:MSTFEC@example.com
m=3Dvideo 56608 = RTP/AVP 110
a=3Drtpmap:110 = 1d-interleaved-parityfec/90000
a=3Dfmtp:110 L=3D5; D=3D10; = repair-window=3D200000
a=3Dmid:R1
a=3DappID:5


=

 

=

 

=
------=_NextPart_000_04F3_01CEFBD6.DF581D30-- From oscar.ohlsson@ericsson.com Wed Dec 18 05:46:39 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1E1AE117 for ; Wed, 18 Dec 2013 05:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqryxq86U5mK for ; Wed, 18 Dec 2013 05:46:37 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE31AE39D for ; Wed, 18 Dec 2013 05:46:35 -0800 (PST) X-AuditID: c1b4fb32-b7f2b8e0000073bf-6b-52b1a739ed30 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 33.D4.29631.937A1B25; Wed, 18 Dec 2013 14:46:34 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.140]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0347.000; Wed, 18 Dec 2013 14:46:19 +0100 From: Oscar Ohlsson To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-02 Thread-Index: Ac7793c0Hub88/JyQHOuPWr4QODOFw== Date: Wed, 18 Dec 2013 13:46:19 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_C643F355C8D33C48B983F1C1EA702A45127CD6E5ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvra7V8o1BBrOWcVlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGX9WL2AtOFBZceNPM0sD48eMLkZODgkBE4mlL84xQ9hiEhfu rWfrYuTiEBI4wShx9tF/KGcJo0TL/G3sIFVsAgYSt+6fZAGxRQRiJb6ue88EYgsLGEmsW/2A CSJuLrHo8T02CFtPYnVTN1Ccg4NFQFXi/wpjkDCvgK/E60U7GUFsRgFZifvf74GNZBYQl7j1 ZD4TxEECEkv2nIc6TlTi5eN/rCBjJAQUJZb3y0GU50ssXPeTFWKkoMTJmU9YJjAKzUIyaRaS sllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRsni1OLi3HQjA73c9NwSvdSizOTi 4vw8veLUTYzAyDi45bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwKgcMGEa224p+Tg76QMsU5IffvGbPsWfLfwSc2zpsefzbXy+1/b8/z9JtaJOnc82o4fj QXLCCu6oFXMk7jBn3eaKcvFn2rrsl2kJ925+O6P77w7o1NvVz3g/+cIrjy3lkVLO9yZsrz7I 0qv+ZuJv1SCvEte4pTmm0kxvHK9pVaq3vpnGtOj4FiWW4oxEQy3mouJEAMr+Cl1aAgAA Subject: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 13:46:39 -0000 --_000_C643F355C8D33C48B983F1C1EA702A45127CD6E5ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed draft-ietf-mmusic-udptl-dtls-02, and overall the document l= ooks good. A couple of comments and suggestions are included below. Regards, Oscar ---------------------------------------------------------------------------= ----- Abstract - To introduce the reader to the topic, maybe you should mention already in= the abstract that UDTPL is used for T38 fax transmission. Section 1 - Remove the topmost row "Protocol" in Table 1 and Table 2 or somehow indic= ate that is a header. - Not sure "DTLS association" is the correct term. I've seen other document= s using the term "DTLS connection" instead, for example RFC 5238, Section 3= .4: DTLS uses the concepts of sessions and connections. A DTLS connection is used by upper-layer endpoints to exchange data over a transport protocol. DTLS sessions contain cached state information that is used to reduce the number of roundtrips and computation required to create multiple DTLS connections between the same endpoints. If you decide to change it, then make sure to change all occurences in th= e document. Section 3.1 - To me "DTLS over UDP" sounds better than "DTLS over the UDP" - The third bullet "If the endpoint supports ..." implies that a fingerprin= t has to be included also in the case when the endpoint certificate is not = self signed, which is unnecessary. Is this what you intended? Section 4.3 - Regarding the sentence: The duration of maintaining the previous set of keys after the finish o= f the DTLS handshake is out of scope for this document. Instead of leaving the timer out of scope you do could do the same way a= s in RFC 5764, Section 5.2 and use the UDP maximum segment lifetime (MSL). Appendix A - The title should be changed from "Example" to "Examples" Appendix A.1 - I don't see why you think it's important to add SIP Identity (RFC4474) to= the example. In my opinion it just makes the example longer and does not h= ave much to with the main content of the document. I would suggest to remov= e it and instead add a sentence saying that it is possible to combine the m= essage flow in the example with SIP Identity. Also I think it is questionab= le how much security SIP Identity provides when it is only used in one of t= he directions. If you remove SIP Identity from the example, then also make sure to change = the reference to the example in Section 5. Appendix A.2 - The STUN connectivity check described in Section 4.2.2 is missing from th= e message flow in Figure 1. The same is true for Figure 6 in A.3. - The description of the individual message is incomplete ("Message (1):"). - Change "indicates" to "contains" in the sentence "The SDP fingerprint att= ribute in the SDP offer indicates". The same sentence occurs in three more = places in the appendix. - In the description of message 4, remove "the" in the sentence "...from t= he Alice's certificate... " Appendix A.3 - Add "the" in front of "DTLS association" in the sentence: In this example flow, Alice acts as the passive endpoint of DTLS association and Bob acts as the active endpoint of DTLS association. - Add "the" in front of "SDP offer and "is" before "shown" in the sentence: SDP offer included in the SIP re-INVITE request shown in Figure 7. ---------------------------------------------------------------------------= ----- --_000_C643F355C8D33C48B983F1C1EA702A45127CD6E5ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-ietf-m= music-udptl-dtls-02, and overall the document looks good. A couple of comme= nts and suggestions are included below.

 

Regards,

 

Oscar

 

----------------------------= ----------------------------------------------------

 

Abstract

 

- To introduce the reader to= the topic, maybe you should mention already in the abstract that UDTPL is = used for T38 fax transmission.

 

Section 1<= /p>

 

- Remove the topmost row &qu= ot;Protocol" in Table 1 and Table 2 or somehow indicate that is a head= er.

 

- Not sure "DTLS associ= ation" is the correct term. I've seen other documents using the term &= quot;DTLS connection" instead, for example RFC 5238, Section 3.4:

 

    &nbs= p;  DTLS uses the concepts of sessions and connections.  A DTLS

    &nbs= p;  connection is used by upper-layer endpoints to exchange data over = a

    &nbs= p;  transport protocol.  DTLS sessions contain cached state infor= mation

    &nbs= p;  that is used to reduce the number of roundtrips and computation

    &nbs= p;  required to create multiple DTLS connections between the same=

    &nbs= p;  endpoints.

 

  If you decide to chan= ge it, then make sure to change all occurences in the document.<= /span>

 

Section 3.1

 

- To me "DTLS over UDP&= quot; sounds better than "DTLS over the UDP"

 

- The third bullet "If = the endpoint supports ..." implies that a fingerprint has to be includ= ed also in the case when the endpoint certificate is not self signed, which= is unnecessary. Is this what you intended?

 

Section 4.3

 

- Regarding the sentence:

 

    The durat= ion of maintaining the previous set of keys after the finish of the DTLS

    handshake= is out of scope for this document.

 

   Instead of leav= ing the timer out of scope you do could do the same way as in RFC 5764, Sec= tion 5.2 and use the UDP maximum segment lifetime (MSL).<= /p>

 

Appendix A=

 

- The title should be change= d from "Example" to "Examples"

 

Appendix A.1

 

- I don't see why you think = it's important to add SIP Identity (RFC4474) to the example. In my opinion = it just makes the example longer and does not have much to with the main co= ntent of the document. I would suggest to remove it and instead add a sentence saying that it is possible to comb= ine the message flow in the example with SIP Identity. Also I think it is q= uestionable how much security SIP Identity provides when it is only used in= one of the directions.

 

If you remove SIP Identity f= rom the example, then also make sure to change the reference to the example= in Section 5.

 

Appendix A.2

 

- The STUN connectivity chec= k described in Section 4.2.2 is missing from the message flow in Figure 1. = The same is true for Figure 6 in A.3.

 

- The description of the ind= ividual message is incomplete ("Message (1):").=

 

- Change "indicates&quo= t; to "contains" in the sentence "The SDP fingerprint attrib= ute in the SDP offer indicates". The same sentence occurs in three mor= e places in the appendix.

 

- In the description of mess= age 4, remove "the" in the sentence  "...from the Alice= 's certificate... "

 

Appendix A.3

 

- Add "the" in fro= nt of "DTLS association" in the sentence:

 

    In this e= xample flow, Alice acts as the passive endpoint of DTLS

    associati= on and Bob acts as the active endpoint of DTLS association.

 

- Add "the" in fro= nt of "SDP offer and "is" before "shown" in the se= ntence:

 

     SDP= offer included in the SIP re-INVITE request shown in Figure 7.<= /span>

 

-------------------------------------------------= -------------------------------

 

--_000_C643F355C8D33C48B983F1C1EA702A45127CD6E5ESESSMB301erics_-- From albrecht.schwarz@alcatel-lucent.com Wed Dec 18 07:29:29 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB251AE40F for ; Wed, 18 Dec 2013 07:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b078oGt58ONx for ; Wed, 18 Dec 2013 07:29:26 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1E42C1AE189 for ; Wed, 18 Dec 2013 07:29:26 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rBIFTMwq018468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Dec 2013 09:29:23 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rBIFTLxd027524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Dec 2013 16:29:21 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 18 Dec 2013 16:29:21 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "mmusic@ietf.org" Thread-Topic: Review (by Albrecht) of draft-ietf-mmusic-udptl-dtls-02 Thread-Index: Ac78BetKtAzG5MiCRciuBhIxNigaaw== Date: Wed, 18 Dec 2013 15:29:20 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC1230F3@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC1230F3FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [MMUSIC] Review (by Albrecht) of draft-ietf-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 15:29:29 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC1230F3FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, did a review of the -02 draft version. The content is technically pretty complete in my opinion. Like to propose three comments concerning the addition of complementary inf= ormation, see below. Regards, Albrecht to 3.1. Secure Channel Establishment Paragraph: In addition to the usual contents of an SDP media description ("m=3D" line) specified for UDPTL over the UDP, each SDP media description for UDPTL over DTLS over the UDP will also contain several SDP attributes, as specified in [RFC4145= ] and [RFC4572]. proposed to be detailed by: In addition to the usual contents of an SDP media description ("m=3D" line) specified for UDPTL over the UDP, each SDP media description for UDPTL over DTLS over the UDP will also contain several SDP attributes, which were introduced in the context of TCP and TLS (but reu= sed here for DTLS-over-UDP), as specified in [RFC4145] (TCP) and [RFC4572] (TL= S). List item: o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer SHOULD assign the SDP setup attribute with a setup:actpass value, and MAY assign the SDP setup attribute with a setup:active value or setup:passive value. The offerer MUST NOT assign the SDP setup attribute with a setup:holdconn value. If the offerer ... proposed to add further background information: o The endpoint MUST use the SDP setup attribute [RFC4145]. The offerer SHOULD assign the SDP setup attribute with a setup:actpass value, and MAY assign the SDP setup attribute with a setup:active value or setup:passive value (NOTE: these rules allow to decouple the= establishment direction of the DTLS session from the establishment directi= on of the SIP session (which may be demanded due to security considerations= , NAT traversal aspects, etc.)). The offerer MUST NOT assign the SDP setup attribute with a setup:holdconn value. If the offerer .... to 3.2. Secure Channel Usage Paragraph: DTLS is used as specified in [RFC6347]. Once the DTLS handshake is completed, the UDPTL packets SHALL be transported in DTLS record layer "application_data" packets. proposed to be detailed by: DTLS is used as specified in [RFC6347]. Once the DTLS handshake is successfully completed, the UDPTL packets SHALL be transported in DTLS r= ecord layer "application_data" packets. NOTE: such a proceeding ensures that the application (i.e., T.38) does not = start to transmit facsimile data already during an ongoing underlying DTLS = session establishment. This aspect might be important for end-to-end scenar= ios with gateway equipment and a possible "UDPTL/DTLS/UDP-to-UDPTL/UDP" int= erworking function). __________________________________________________ Dr. Albrecht Schwarz Alcatel-Lucent Albrecht.Schwarz@alcatel-lucent.com --_000_786615F3A85DF44AA2A76164A71FE1AC1230F3FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,<= /o:p>

did a review of= the -02 draft version.

The content is = technically pretty complete in my opinion.

 

Like to propose= three comments concerning the addition of complementary information, see b= elow.

 

Regards,

Albrecht

 

 

to 3.1.  Secure Channel Establ= ishment

  &nb= sp;   Paragraph:

   In addition to the usual contents of an SDP media descrip=
tion ("m=3D"
   line) specified for UDPTL over the UDP, each SDP media de=
scription
   for UDPTL over DTLS over the UDP will also contain severa=
l SDP
   attributes, as specified in [RFC4145] and [RFC4572].

 

proposed to be detailed by:

 

   In addition to the usual contents of an SDP media descrip=
tion ("m=3D"
   line) specified for UDPTL over the UDP, each SDP media de=
scription
   for UDPTL over DTLS over the UDP will also contain severa=
l SDP
   attributes, which were introduc=
ed in the context of TCP and TLS (but reused here for DTLS-over-UDP), as specified in [RFC4145] (TCP) and [RFC4572] (T=
LS).

 

 

List item:= 

   o  The endpoint MUST use the SDP setup attribute [RFC4145].&n=
bsp; The
      offerer SHOULD assign the SDP setup att=
ribute with a setup:actpass
      value, and MAY assign the SDP setup att=
ribute with a setup:active
      value or setup:passive value.  The=
 offerer MUST NOT assign the SDP
      setup attribute with a setup:holdconn v=
alue.  If the offerer …

 

proposed to add= further background information:

   o  The endpoint MUST use the SDP setup attribute [RFC4145].&n=
bsp; The
      offerer SHOULD assign the SDP setup att=
ribute with a setup:actpass
      value, and MAY assign the SDP setup att=
ribute with a setup:active
      value or setup:passive value (NOTE: these rules allow to decouple the establishment dire=
ction of the DTLS session from the establishment direction of the SIP sessi=
on (which may be demanded due to security considerations, NAT traversal asp=
ects, etc.)).  
The offerer MUST NOT assign the SDP
      setup attribute with a setup:holdconn v=
alue.  If the offerer ….

 

 

to 3.2.  Secure Channel Usage

 <= /o:p>

  &nb= sp;   Paragraph:

   DTLS is used as specified in [RFC6347].  Once the DTLS handshake is

   completed, the UDPTL packets SHALL be transported in DTLS=
 record


   layer "application_data" packets.

 


proposed to be detailed by:


   DTLS is used as specified in [RFC6347].  Once the DTLS handshake is

   successfully completed, =
the UDPTL packets SHALL be transported in DTLS record


   layer "application_data" packets.
NOTE: such a proceeding ensures that the application (i.e.,=
 T.38) does not start to transmit facsimile data already during an ongoing =
underlying DTLS session establishment. This aspect might be important for e=
nd-to-end scenarios with gateway equipment and a possible “UDPTL/DTLS=
/UDP-to-UDPTL/UDP” interworking function).


 


 


 


 


________________________________________________=
__


Dr. Albrecht Schwarz


Alcatel-Lucent


Albrecht.Schwarz@alcatel-lucent.com



 
--_000_786615F3A85DF44AA2A76164A71FE1AC1230F3FR711WXCHMBA03zeu_-- From dhanes@cisco.com Thu Dec 19 11:17:42 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C455C1AE59F for ; Thu, 19 Dec 2013 11:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGM_LuIdwkB9 for ; Thu, 19 Dec 2013 11:17:40 -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 D65571AE59C for ; Thu, 19 Dec 2013 11:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16970; q=dns/txt; s=iport; t=1387480658; x=1388690258; h=from:to:subject:date:message-id:mime-version; bh=z+iwbZdAwXNtUW09IeytYvtefTNiCZjUPOCeOcMZwRo=; b=i6Dcj3i0Ji3hdNCVsqprMBk02alaF97TOmHb5mLjFmHRmKWJ0XUZMZAA 0lSAzvOmXJ7PiBQ+VRW9qjZTe0aEO9RG8JngpWcCzFkmculjbXw2bsakm Pifbw77UzPFaWOduEQnzHliVBs09tc4doMH0ZXObRB+TQ4aDvK0Tndhlv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIZFs1KtJXG+/2dsb2JhbABZgkdEgQ26RRZ0gixxGgGBACcEAS2Hacp9F5NPBJgWkhSDK4Iq X-IronPort-AV: E=Sophos;i="4.95,514,1384300800"; d="scan'208,217";a="292713099" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 19 Dec 2013 19:17:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBJJHbGv018325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 19:17:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.179]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 13:17:37 -0600 From: "David Hanes (dhanes)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 Thread-Index: AQHO/O75QCuznshz40mgGM8qEOtflw== Date: Thu, 19 Dec 2013 19:17:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.39.202] Content-Type: multipart/alternative; boundary="_000_CED8B089BDADdhanesciscocom_" MIME-Version: 1.0 Subject: [MMUSIC] Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 19:17:43 -0000 --_000_CED8B089BDADdhanesciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Overall this is a well written document. It is clear and concise and the te= chnical aspect is solid. My comments are below: -David 1) For some reason, I can't seem to get past the wording on this first sent= ence in Section 1. I feel like it could be stated a bit clearer. The point = I think is that there are means to send faxes across the PSTN in a secure m= anner but it was never a priority due to the barrier of physical access. Th= is is probably just personal preference but I feel a wording similar to the= following gets the point across better: "While it is possible to transmit highly sensitive documents using traditio= nal telephony encryption devices, secure fax on the Public Switched Telephone Network (PSTN) was never widely considered or prioritized. This w= as mainly because of the challenges involved with physical access to teleph= ony equipment." 2) In the last sentence of the first paragraph of Section 1, the following = statement is made "Some of the security mechanisms for securing fax include= :" and then a T.30 and T.38 scheme is mentioned. I think that this has been= brought up before but SRTP using fax passthrough is more widely deployed i= n my experience than either of the other secure faxing methods. I realize t= hat this document is written under the context of UDPTL-based fax but here = in the introduction the topic so far is secure fax in a general sense and i= t has yet to be narrowed down to just UDPTL-based fax. It seems like a glar= ing omission that SRTP fax solutions are not mentioned here. I think SRTP n= eeds to be added if this is kept in its present form and wording. Or this s= ection could be changed in a manner similar to the following. This will ad= dress the omission of SRTP from my perspective: While telephony encryption devices have been traditionally used for highly sensitive documents, secure fax on the Public Switched Telephone Network (PSTN) was not as widely considered or prioritized because of the challenges involved with physical access to telephony equipment. As real-time communications transition to IP networks, where information might potentially be intercepted or spoofed, an appropriate level of security for fax that offers integrity and confidentiality protection is vital. The overwhelmingly predominant fax transport protocol today is UDPTL-based. The protocol stack for fax transport using UDPTL is shown in Table 1. +-----------------------------+ | Protocol | +-----------------------------+ | Internet facsimile protocol | +-----------------------------+ | UDPTL | +-----------------------------+ | UDP | +-----------------------------+ | IP | +-----------------------------+ Table 1: Protocol stack for UDPTL over UDP Implementations exist today for securing this fax transport type. Some o= f these mechanisms are: o [ITU.T30.2005] Annex H specifies integrity and confidentiality protection of fax in application layer, independent of protocol for fax transport. o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables integrity and confidentiality protection of fax in IP network. Despite these mechanisms to secure fax, there is no transport layer security offering integrity and confidentiality protection for UDPTL. Th= is issue was addressed in a study by the 3rd Generation Partnership Project (3GPP= ) on how to provide secure fax in the IP Multimedia Subsystem (IMS). They concluded that secure fax shall be transported using UDPTL over DTLS. My rewrite here simply places the current secure fax options for UDPTL afte= r the introduction of UDPTL itself. I think this builds better from a gener= al discussion on secure fax, to an introduction of UDPTL, to an explanation= of current UDPTL secure fax offerings, to the 3GPP study recommendation. 3) Shouldn't the title for Table 2 be "Protocol stack for UDPTL over DTLS" = and not "Protocol stack for UDPTL over UDP"? --_000_CED8B089BDADdhanesciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Overall= this is a well written document. It is clear and concise and the technical= aspect is solid. My comments are below:


-David<= /p>






1) For = some reason, I can't seem to get past the wording on this first sentence in= Section 1. I feel like it could be stated a bit clearer. The point I think= is that there are means to send faxes across the PSTN in a secure manner but it was never a priority due to the = barrier of physical access. This is probably just personal preference but I= feel a wording similar to the following gets the point across better:


"W= hile it is possible to transmit highly sensitive documents using traditiona= l telephony encryption devices, secure fax on the Public Switched

Telepho= ne Network (PSTN) was never widely considered or prioritized. This was main= ly because of the challenges involved with physical access to telephony equ= ipment."





2) In t= he last sentence of the first paragraph of Section 1, the following stateme= nt is made "Some of the security mechanisms for securing fax include:&= quot; and then a T.30 and T.38 scheme is mentioned. I think that this has been brought up before but SRTP using fax passthroug= h is more widely deployed in my experience than either of the other secure = faxing methods. I realize that this document is written under the context o= f UDPTL-based fax but here in the introduction the topic so far is secure fax in a general sense and it has = yet to be narrowed down to just UDPTL-based fax. It seems like a glaring om= ission that SRTP fax solutions are not mentioned here. I think SRTP needs t= o be added if this is kept in its present form and wording. Or this section could be changed in a manner sim= ilar to the following.  This will address the omission of SRTP from my= perspective:


 &= nbsp; 

  =  While telephony encryption devices have been traditionally used for

 &= nbsp; highly sensitive documents, secure fax on the Public Switched

 &= nbsp; Telephone Network (PSTN) was not as widely considered or prioritized<= /p>

 &= nbsp; because of the challenges involved with physical access to telephony<= /p>

 &= nbsp; equipment.  As real-time communications transition to IP network= s,

 &= nbsp; where information might potentially be intercepted or spoofed, an

 &= nbsp; appropriate level of security for fax that offers integrity and

 &= nbsp; confidentiality protection is vital.  


 &= nbsp; The overwhelmingly predominant fax transport protocol today is

  =  UDPTL-based. The protocol stack for fax transport using UDPTL is show= n

 &= nbsp; in Table 1.


  =                     += -----------------------------+

  =                     | &nb= sp;         Protocol          = |

  =                     += -----------------------------+

  =                     | Int= ernet facsimile protocol |

  =                     += -----------------------------+

  =                     |&nbs= p;           UDPTL        &nbs= p;   |

  =                     += -----------------------------+

  =                     | &nb= sp;           UDP         &nbs= p;   |

  =                     += -----------------------------+

  =                     |&nbs= p;             IP        =     |

  =                     += -----------------------------+


  =               Table 1: Protocol stack fo= r UDPTL over UDP


  =  Implementations exist today for securing this fax transport type. Som= e of these

  =  mechanisms are: 


 &= nbsp; o  [ITU.T30.2005] Annex H specifies integrity and confidentialit= y

  =     protection of fax in application layer, independent of protoc= ol

  =     for fax transport.

 &= nbsp; o  [ITU.T38.2010] specifies fax transport over RTP/SAVP which en= ables

  =     integrity and confidentiality protection of fax in IP network= .


 &= nbsp; Despite these mechanisms to secure fax, there is no transport layer

 &= nbsp; security offering integrity and confidentiality protection for UDPTL.= This issue

  =  was addressed in a study by the 3rd Generation Partnership Project (3= GPP)

  =  on how to provide secure fax in the IP Multimedia Subsystem (IMS). Th= ey

  =  concluded that secure fax shall be transported using UDPTL over DTLS.=



My rewr= ite here simply places the current secure fax options for UDPTL after = the introduction of UDPTL itself. I think this builds better from a general= discussion on secure fax, to an introduction of UDPTL, to an explanation of current UDPTL secure fax offerings, to the = 3GPP study recommendation.





3) Shou= ldn't the title for Table 2 be "Protocol stack for UDPTL over DTLS&quo= t; and not "Protocol stack for UDPTL over UDP"?




--_000_CED8B089BDADdhanesciscocom_-- From christer.holmberg@ericsson.com Thu Dec 19 23:59:43 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F521AF708 for ; Thu, 19 Dec 2013 23:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVjJyfDvJCPb for ; Thu, 19 Dec 2013 23:59:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4E00E1AF700 for ; Thu, 19 Dec 2013 23:59:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-9e-52b3f8e1d957 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.56.23787.1E8F3B25; Fri, 20 Dec 2013 08:59:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0347.000; Fri, 20 Dec 2013 08:59:11 +0100 From: Christer Holmberg To: Oscar Ohlsson , "mmusic@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-02 Thread-Index: Ac7793c0Hub88/JyQHOuPWr4QODOFwAMyBYc Date: Fri, 20 Dec 2013 07:59:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5DB975@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvre7DH5uDDLqe6VhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGe9OBRd81aqYc6CVtYGxSamLkZNDQsBEYvmF4+wQtpjEhXvr 2boYuTiEBA4xSlybtZEJwlnCKHHy6xcgh4ODTcBCovufNkiDiECoRFfXNEYQW1jATOLXg4vs EHFziUWP77FB2EYSs5ZvYQKxWQRUJc4dXMoGMoZXwFfiSR8nSFgIyDy1uYkZxOYU8JPY39EA 1soIdM/3U2vAWpkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHqdSQW7P7EBmFr Syxb+BqsnldAUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm64iREY8ge3/Nbd wXjqnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME6ONduQXbh7yc1Z nOX7uHcaSlpPLCopdaz8m3VSd9o1+dsxBZrvVAuULB6cudbp5b5vdSLXrilLz/9jefSnf8sz Lm3dO+yzKmaYf3IXuPtJ7QiDfrng+iOfn7YmnmcrYTlc97i8derPFft2S3T1nHzW8X7ltJpz CpPai7oPlVe8nJd//kdrsIYSS3FGoqEWc1FxIgDMv5skRwIAAA== Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 07:59:44 -0000 Hi Oscar, Thank You for the review! Comments inline. ---------------------------------------------------------------------------= ----- > Abstract > > - To introduce the reader to the topic, maybe you should mention already = in the abstract that UDTPL is used for T38 fax transmission. I suggest something like: "Abstract This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax,=20 can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP)." ---------------------------------------------------------------------------= ----- > Section 1 > > - Remove the topmost row "Protocol" in Table 1 and Table 2 or somehow ind= icate that is a header. I can remove it. > - Not sure "DTLS association" is the correct term. I've seen other docume= nts using the term "DTLS connection" instead, for example RFC 5238, Section= 3.4: > > DTLS uses the concepts of sessions and connections. A DTLS > connection is used by upper-layer endpoints to exchange data over a > transport protocol. DTLS sessions contain cached state information > that is used to reduce the number of roundtrips and computation > required to create multiple DTLS connections between the same > endpoints. > > If you decide to change it, then make sure to change all occurrences in = the document. RFC 5763 uses "DTLS association" terminology, so I would suggest we keep it= . ---------------------------------------------------------------------------= ----- > Section 3.1 > > - To me "DTLS over UDP" sounds better than "DTLS over the UDP" Correct. I tried to remove the "the: s" earlier, but it seems like I missed= this one :) > - The third bullet "If the endpoint supports ..." implies that a fingerpr= int has to be included also in the case when the endpoint certificate is no= t self signed, which is unnecessary. Is this what you intended? We can never be sure that the remote UE has certificate of the certificatio= n authority which signed the certificated used by the local UE. Thus, a=3Df= ingerprint should always be provided.=20 I suggest that we keep the existing text. ---------------------------------------------------------------------------= ----- > Section 4.3 > > - Regarding the sentence: > > The duration of maintaining the previous set of keys after the finish = of the DTLS > handshake is out of scope for this document. > > Instead of leaving the timer out of scope you do could do the same way = as in RFC 5764, Section 5.2 and use the UDP maximum segment lifetime (MSL). We did take a look at 5764, but I haven't managed to find a definition for = MSL when used with UDP. We'll look into it. ---------------------------------------------------------------------------= ----- > Appendix A > > - The title should be changed from "Example" to "Examples" We'll change it as suggested. ---------------------------------------------------------------------------= ----- > Appendix A.1 > > - I don't see why you think it's important to add SIP Identity (RFC4474) = to the example. In my opinion it just makes the example=20 > longer and does not have much to with the main content of the document. I= would suggest to remove it and instead add a sentence=20 > saying that it is possible to combine the message flow in the example wit= h SIP Identity. Also I think it is questionable how much security=20 > SIP Identity provides when it is only used in one of the directions. > > If you remove SIP Identity from the example, then also make sure to chang= e the reference to the example in Section 5. We can remove it, and add a statement, as suggested. ---------------------------------------------------------------------------= ----- > Appendix A.2 > > - The STUN connectivity check described in Section 4.2.2 is missing from = the message flow in Figure 1. The same is true for Figure 6 in A.3. Will look into that. > - The description of the individual message is incomplete ("Message (1):"= ). I don't think it's incomplete (note that there is a page-break), but I'll d= ouble check. =20 > - Change "indicates" to "contains" in the sentence "The SDP fingerprint a= ttribute in the SDP offer indicates". The same sentence occurs in three mor= e places in the appendix. We'll fix as suggested. > - In the description of message 4, remove "the" in the sentence "...from= the Alice's certificate... " We'll fix as suggested. ---------------------------------------------------------------------------= ----- > Appendix A.3 > > - Add "the" in front of "DTLS association" in the sentence: > > In this example flow, Alice acts as the passive endpoint of DTLS > association and Bob acts as the active endpoint of DTLS association. We'll fix as suggested. > - Add "the" in front of "SDP offer and "is" before "shown" in the sentenc= e: > > SDP offer included in the SIP re-INVITE request shown in Figure 7. We'll fix as suggested. ---------------------------------------------------------------------------= ----- Thanks! Regards, Christer From christer.holmberg@ericsson.com Fri Dec 20 05:07:55 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF7C1AE272 for ; Fri, 20 Dec 2013 05:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvAvQLi0ztBJ for ; Fri, 20 Dec 2013 05:07:52 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4AA1A1F6F for ; Fri, 20 Dec 2013 05:07:51 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-0c-52b44124ce27 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id FA.B6.27941.42144B25; Fri, 20 Dec 2013 14:07:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0347.000; Fri, 20 Dec 2013 14:07:29 +0100 From: Christer Holmberg To: "David Hanes (dhanes)" , "mmusic@ietf.org" Thread-Topic: Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 Thread-Index: AQHO/O75QCuznshz40mgGM8qEOtfl5pdDurw Date: Fri, 20 Dec 2013 13:07:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5DBF8A@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5DBF8AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvra6K45Ygg4ePlSwurfjEYjF1+WMW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjwZ9XzAW37zBWnH9/kq2B8c4hxi5GTg4J AROJ5af2sELYYhIX7q1n62Lk4hASOMIosWZfGyOEs4RR4t3C18xdjBwcbAIWEt3/tEEaRARC JPpPtTCB2MICbhK7l01hhYi7S5zf/Z8RwjaS2LzpIBuIzSKgKnGo/w0ziM0r4Cvx4vgCdpCR QgI6EutOxYGEOQV0JXbPvwBWwgh0z/dTa8DGMwuIS3w4eJ0Z4k4BiSV7zkPZohIvH/+Dul9J onHJE1aI+nyJl/9mskCsEpQ4OfMJywRGkVlIRs1CUjYLSRlEXE/ixtQpbBC2tsQyoOchbF2J Gf8OsSCLL2BkX8XIUZxanJSbbmSwiREYPwe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MGafmL1NwS2qfrfwUq0NoRFO67Yu/mqqsqfMUL0+TPGsiKyE 5UvD6ebnLrD6P/NazZD74O+1SNe6yakWKoWnpyyQneiwKyZSzmPeRlFdTrE9e/9H/ObZZRWZ tcJ3nQvb0XvbeCKXdfE+VtzwuPpxmv4N1R8rOta9ext6n8tyep/AAamZQo9TjyixFGckGmox FxUnAgBd1AmebQIAAA== Subject: Re: [MMUSIC] Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:07:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C5DBF8AESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, Thanks for your comments! Due to xmas/new year vacations, it may take a whi= le before I get a chance to reply. Just to let you know :) Regards, Christer L=E4hett=E4j=E4: David Hanes (dhanes) [mailto:dhanes@cisco.com] L=E4hetetty: 19. joulukuuta 2013 21:18 Vastaanottaja: Christer Holmberg; mmusic@ietf.org Aihe: Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 Overall this is a well written document. It is clear and concise and the te= chnical aspect is solid. My comments are below: -David 1) For some reason, I can't seem to get past the wording on this first sent= ence in Section 1. I feel like it could be stated a bit clearer. The point = I think is that there are means to send faxes across the PSTN in a secure m= anner but it was never a priority due to the barrier of physical access. Th= is is probably just personal preference but I feel a wording similar to the= following gets the point across better: "While it is possible to transmit highly sensitive documents using traditio= nal telephony encryption devices, secure fax on the Public Switched Telephone Network (PSTN) was never widely considered or prioritized. This w= as mainly because of the challenges involved with physical access to teleph= ony equipment." 2) In the last sentence of the first paragraph of Section 1, the following = statement is made "Some of the security mechanisms for securing fax include= :" and then a T.30 and T.38 scheme is mentioned. I think that this has been= brought up before but SRTP using fax passthrough is more widely deployed i= n my experience than either of the other secure faxing methods. I realize t= hat this document is written under the context of UDPTL-based fax but here = in the introduction the topic so far is secure fax in a general sense and i= t has yet to be narrowed down to just UDPTL-based fax. It seems like a glar= ing omission that SRTP fax solutions are not mentioned here. I think SRTP n= eeds to be added if this is kept in its present form and wording. Or this s= ection could be changed in a manner similar to the following. This will ad= dress the omission of SRTP from my perspective: While telephony encryption devices have been traditionally used for highly sensitive documents, secure fax on the Public Switched Telephone Network (PSTN) was not as widely considered or prioritized because of the challenges involved with physical access to telephony equipment. As real-time communications transition to IP networks, where information might potentially be intercepted or spoofed, an appropriate level of security for fax that offers integrity and confidentiality protection is vital. The overwhelmingly predominant fax transport protocol today is UDPTL-based. The protocol stack for fax transport using UDPTL is shown in Table 1. +-----------------------------+ | Protocol | +-----------------------------+ | Internet facsimile protocol | +-----------------------------+ | UDPTL | +-----------------------------+ | UDP | +-----------------------------+ | IP | +-----------------------------+ Table 1: Protocol stack for UDPTL over UDP Implementations exist today for securing this fax transport type. Some o= f these mechanisms are: o [ITU.T30.2005] Annex H specifies integrity and confidentiality protection of fax in application layer, independent of protocol for fax transport. o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables integrity and confidentiality protection of fax in IP network. Despite these mechanisms to secure fax, there is no transport layer security offering integrity and confidentiality protection for UDPTL. Th= is issue was addressed in a study by the 3rd Generation Partnership Project (3GPP= ) on how to provide secure fax in the IP Multimedia Subsystem (IMS). They concluded that secure fax shall be transported using UDPTL over DTLS. My rewrite here simply places the current secure fax options for UDPTL afte= r the introduction of UDPTL itself. I think this builds better from a gener= al discussion on secure fax, to an introduction of UDPTL, to an explanation= of current UDPTL secure fax offerings, to the 3GPP study recommendation. 3) Shouldn't the title for Table 2 be "Protocol stack for UDPTL over DTLS" = and not "Protocol stack for UDPTL over UDP"? --_000_7594FB04B1934943A5C02806D1A2204B1C5DBF8AESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi David,<= o:p>

 = ;

Thanks for= your comments! Due to xmas/new year vacations, it may take a while before = I get a chance to reply. Just to let you know :)

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: David Hanes (dhanes) [mailto:dhanes@cisco.com]
L=E4hetetty: 19. joulukuuta 2013 21:18
Vastaanottaja: Christer Holmberg; mmusic@ietf.org
Aihe: Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02=

 

Ove= rall this is a well written document. It is clear and concise and the techn= ical aspect is solid. My comments are below:

 

-Da= vid

 

 

 

 

 

1) = For some reason, I can't seem to get past the wording on this first sentenc= e in Section 1. I feel like it could be stated a bit clearer. The point I think is that there are means to send faxes across the PSTN in= a secure manner but it was never a priority due to the barrier of physical= access. This is probably just personal preference but I feel a wording sim= ilar to the following gets the point across better:

 

&qu= ot;While it is possible to transmit highly sensitive documents using tradit= ional telephony encryption devices, secure fax on the Public Switched

Tel= ephone Network (PSTN) was never widely considered or prioritized. This was = mainly because of the challenges involved with physical access to telephony equipment."

 

 

 

 

2) = In the last sentence of the first paragraph of Section 1, the following sta= tement is made "Some of the security mechanisms for securing fax include:" and then a T.30 and T.38 scheme is mentioned. I think t= hat this has been brought up before but SRTP using fax passthrough is more = widely deployed in my experience than either of the other secure faxing met= hods. I realize that this document is written under the context of UDPTL-based fax but here in the introduction = the topic so far is secure fax in a general sense and it has yet to be narr= owed down to just UDPTL-based fax. It seems like a glaring omission that SR= TP fax solutions are not mentioned here. I think SRTP needs to be added if this is kept in its present form a= nd wording. Or this section could be changed in a manner similar to the fol= lowing.  This will address the omission of SRTP from my perspective:

 

&nb= sp;  

&nb= sp;  While telephony encryption devices have been traditionally used f= or

&nb= sp;  highly sensitive documents, secure fax on the Public Switched

&nb= sp;  Telephone Network (PSTN) was not as widely considered or prioriti= zed

&nb= sp;  because of the challenges involved with physical access to teleph= ony

&nb= sp;  equipment.  As real-time communications transition to IP net= works,

&nb= sp;  where information might potentially be intercepted or spoofed, an=

&nb= sp;  appropriate level of security for fax that offers integrity and

&nb= sp;  confidentiality protection is vital.  

 

&nb= sp;  The overwhelmingly predominant fax transport protocol today is

&nb= sp;  UDPTL-based. The protocol stack for fax transport using UDPTL is = shown

&nb= sp;  in Table 1.

 

&nb= sp;                     &= #43;-----------------------------+

&nb= sp;                     |=           Protocol        &nb= sp; |

&nb= sp;                     &= #43;-----------------------------+

&nb= sp;                     |= Internet facsimile protocol |

&nb= sp;                     &= #43;-----------------------------+

&nb= sp;                     |=             UDPTL        =     |

&nb= sp;                     &= #43;-----------------------------+

&nb= sp;                     |=             UDP         =     |

&nb= sp;                     &= #43;-----------------------------+

&nb= sp;                     |=               IP       &n= bsp;     |

&nb= sp;                     &= #43;-----------------------------+

 

&nb= sp;               Table 1: Protocol stac= k for UDPTL over UDP

 

&nb= sp;  Implementations exist today for securing this fax transport type.= Some of these

&nb= sp;  mechanisms are: 

 

&nb= sp;  o  [ITU.T30.2005] Annex H specifies integrity and confidenti= ality

&nb= sp;     protection of fax in application layer, independent of pr= otocol

&nb= sp;     for fax transport.

&nb= sp;  o  [ITU.T38.2010] specifies fax transport over RTP/SAVP whic= h enables

&nb= sp;     integrity and confidentiality protection of fax in IP net= work.

 

&nb= sp;  Despite these mechanisms to secure fax, there is no transport lay= er

&nb= sp;  security offering integrity and confidentiality protection for UD= PTL. This issue

&nb= sp;  was addressed in a study by the 3rd Generation Partnership Projec= t (3GPP)

&nb= sp;  on how to provide secure fax in the IP Multimedia Subsystem (IMS)= . They

&nb= sp;  concluded that secure fax shall be transported using UDPTL over D= TLS.

 

 

My = rewrite here simply places the current secure fax options for UDPTL af= ter the introduction of UDPTL itself. I think this builds better from a general discussion on secure fax, to an introduction of UDPTL, to a= n explanation of current UDPTL secure fax offerings, to the 3GPP study reco= mmendation.

 

 

 

 

3) = Shouldn't the title for Table 2 be "Protocol stack for UDPTL over DTLS= " and not "Protocol stack for UDPTL over UDP"?

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C5DBF8AESESSMB209erics_-- From abegen@cisco.com Fri Dec 20 05:26:32 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5661AE2A8 for ; Fri, 20 Dec 2013 05:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYHwQNyPC05I for ; Fri, 20 Dec 2013 05:26:30 -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 C7EFD1A1F7B for ; Fri, 20 Dec 2013 05:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1505; q=dns/txt; s=iport; t=1387545989; x=1388755589; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=psk2nhOcWlT57VO8B58wrs2uR+pYs77ef1ME6BP+0z0=; b=N4PD3bU3n1bQc2RoiN0SgN//94ttCgAHROqwWun/GvThj0266PichA4d OjoNPQF1sD0BL3cM+iSKfB7IyeswId/LBBt0xLUspYYYXSTKpcsSuHGeN qTdnYKhLLWGnpanqw2059fr645/7NlmauJ0qBAD7Gj07LQUrGfoD47Xg9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACFFtFKtJV2c/2dsb2JhbABZgmohOFW5NoEaFnSCLDo/EgE+QicEAQ0Oh3sBDMp3F48SAoMogRMEmBaSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,520,1384300800"; d="scan'208";a="292988129" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 20 Dec 2013 13:26:28 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBKDQSVf025648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Dec 2013 13:26:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 20 Dec 2013 07:26:28 -0600 From: "Ali C. Begen (abegen)" To: "bfcpbis-chairs@tools.ietf.org" , "draft-ietf-bfcpbis-rfc4583bis@tools.ietf.org" Thread-Topic: SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 Thread-Index: AQHO/YcWZ2DzntYTsE+pusHe8am5zQ== Date: Fri, 20 Dec 2013 13:26:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.202] Content-Type: text/plain; charset="us-ascii" Content-ID: <6169D9BD02E631498416624D3F57ED32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:26:33 -0000 I am the assigned SDP directorate reviewer for this draft. For background o= n the SDP directorate, please see the FAQ at http://www.ietf.org/iesg/directorate/sdp.html Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Summary: - There are a few minor issues as indicated below. Issues: 1) Section 3 uses m=3D and refers to 4566 b= ut 4566 actually uses m=3D .=20 The newly defined 4 values (TCP/BFCP, TCP/TLS/BFCP and the UDP equivalents)= are actually the proto values that are registered with IANA (not transport= values). Thus, I recommend changing the text to reflect this. 2) Definition of "floorctrl" attribute. I think the answer has to include o= nly one role if the offer had this attribute. If that is correct, I suggest= the following change: OLD:=20 If an SDP media description in an offer contains a 'floorctrl' attribute, the answerer accepting that media MUST include one in the corresponding media description of the answer.=20 NEW: If an SDP media description in an offer contains a 'floorctrl' attribute, the answerer accepting that media MUST include only one in th= e corresponding media description of the answer.=20 3) There are a few "SHOULD"s. I think they are OK but it is not clear when = it is OK to ignore that SHOULD. If there are no such use cases, maybe they = can be replaced with a "MUST"? From gsalguei@cisco.com Fri Dec 20 14:41:33 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6181A1F5E for ; Fri, 20 Dec 2013 14:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBXQcUmT37rH for ; Fri, 20 Dec 2013 14:41:31 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3971A1F3F for ; Fri, 20 Dec 2013 14:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2932; q=dns/txt; s=iport; t=1387579289; x=1388788889; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z0h40TloYT9zILkvIFLwHA9SAopg/mSM05DGmq9uSqU=; b=J1hsypNVOC21AtrxhAmesLA4nuyYaeGLqCIN8KDFuDgDg+W1GiqYkh9X Q4Mfp3aqUXa92/s4ka8yJwbnCdxim+9aAfK+TI1rMN8rjb8p+YqWHkDf6 RyJV0MT1eCorTsEPtzCmdqNGliwhmC4C076HewVG7tTgEIXYOeh3OM1tQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAF7GtFKtJXG9/2dsb2JhbABPCoMLgQ25RIEfFnSCJQEBAQMBKVAFCwIBAgYOODIlAgQOBRQHh2EIyjkXjjYpMweDI4ETAQOJC4sog2OSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,523,1384300800"; d="scan'208";a="8278819" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-8.cisco.com with ESMTP; 20 Dec 2013 22:41:29 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBKMfSjG000437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Dec 2013 22:41:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 20 Dec 2013 16:41:28 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: James Rafferty Thread-Topic: [MMUSIC] Review (Rafferty) of draft-ietf-mmusic-udptl-dtls-02 Thread-Index: AQHO/dN3RKU0VvAAH0GrbZoZo9sdYZpeEiiA Importance: high X-Priority: 1 Date: Fri, 20 Dec 2013 22:41:27 +0000 Message-ID: <4F818DFA-15BE-4D25-B4A6-5D8EAB2F1277@cisco.com> References: <52B4C55D.5060708@humancomm.com> In-Reply-To: <52B4C55D.5060708@humancomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.61] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <655FDA0BE38E2B4FB6C54B9B32CFBB73@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christer Holmberg , mmusic Subject: Re: [MMUSIC] Review (Rafferty) of draft-ietf-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 22:41:33 -0000 Thanks very much, James. We'll go through your review comments and respond= to each of the individually. Expect some delay in response due to the upc= oming Holidays. Happy Holidays! Gonzalo On Dec 20, 2013, at 5:31 PM, James Rafferty wrote= : > This is a review ofdraft-ietf-mmusic-udptl-dtls-02. In general, the dra= ft is in good shape. My comments and suggestions are included below. >=20 > Section 1 - first bullet: add "the" before application layer >=20 > Section 1, Page 2 - On the paragraph before Table 2, the current last se= ntence reads: "The protocol stack for integrity and confidentiality protec= ted fax transport using UDPTL over DTLS is shown in Table 2." >=20 > A couple of word changes would make it read more clearly: > "The protocol stack which enhances fax transport to offer integrity and c= onfidentiality using UDPTL over DTLS is shown in Table 2." >=20 > Section 1, Page 3: Under the "primary motivations" , I'd suggest broaden= ing the applicability of the last bullet point to read: >=20 > "3GPP and the IP fax community need a mechanism to transport UDPTL over D= TLS in order to provide secure fax in IMS and other SIP-based networks." >=20 > Section 2 >=20 > for the 2nd sentence of the second paragraph, clarify by replacing "it" b= y "session" >=20 > Section 5 - Security Considerations >=20 > I think it would help to pull in material about the threat model before j= umping directly into the solution (my latest draft got dinged in the IESG s= ecurity review on this point). >=20 > From a fax community perspective, the relevant threats seem to be: >=20 > 1. Confidentiality - Address potential for 3rd parties to intercept and = decode messages >=20 > 2. Integrity - Ensure that the parties exchanging the messages are prope= rly authenticated and that the message has not been altered during transpor= t. >=20 > These points are addressed somewhat in the body of this section, but it w= ould be useful to start with the threats model and then identify how the so= lution meets the requirements. >=20 > Section 6 - IANA Considerations >=20 > For consistency with the IANA content for "proto" in RFC 4566, it looks = like the entry for the SDP name in Table 3 should be in quotes or "UDP/TLS/= UDPTL" >=20 > Example A.3 >=20 > This is an important example, since most (if not all) current UDPTL sessi= ons will start as audio sessions. >=20 > To highlight this point, I'd suggest adding a second sentence in this sec= tion such as: >=20 > "By current conventions, most non-secured UDPTL sessions are initiated vi= a a re-INVITE after the SIP session has begun as an audio session and this = example shows to address this scenario for initiating UDPTL sessions secure= d via DTLS." >=20 > That concludes my comments on this draft. >=20 > Regards, >=20 > James >=20 >=20 From christer.holmberg@ericsson.com Mon Dec 23 05:09:06 2013 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00461ADFDD for ; Mon, 23 Dec 2013 05:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdWsmrQxK7fT for ; Mon, 23 Dec 2013 05:09:03 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6C1ADFDC for ; Mon, 23 Dec 2013 05:09:02 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-80-52b835eac5bd Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 39.62.23787.AE538B25; Mon, 23 Dec 2013 14:08:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0347.000; Mon, 23 Dec 2013 14:08:56 +0100 From: Christer Holmberg To: "David Hanes (dhanes)" , "mmusic@ietf.org" Thread-Topic: Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 Thread-Index: AQHO/O75QCuznshz40mgGM8qEOtfl5phwtf/ Date: Mon, 23 Dec 2013 13:08:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5E28F7@ESESSMB209.ericsson.se> References: In-Reply-To: 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+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre4r0x1BBp1XLSwurfjEYjF1+WMW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjyOMNzAX/lCoW7/vC0sC4X7KLkZNDQsBE YtLDDkYIW0ziwr31bF2MXBxCAocYJa7NO8kK4SxhlJh8cjGQw8HBJmAh0f1PG6RBRCBEov9U CxOILSzgJvHm8Wk2iLi7xPnd/xkhbCOJO6dngNWwCKhKbNl/mx3E5hXwldjSu48ZZKSQgI7E ulNxIGFOAV2J3fMvMIPYjED3fD+1BqyVWUBc4taT+UwQdwpILNlznhnCFpV4+fgf2GUSAooS y/vlIMp1JBbs/sQGYWtLLFv4mhliq6DEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyipE9NzEz J73ccBMjMA4Obvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amCMcimKfBy5iXP2/5hZtbrCz4pYWPrmREeyPfGx1Ul8LSZesvHOasW/r+L1D977fjbnXimf yvPEF1lqWiGPA2tPvJ6dL7bzw7a648/nOV38b9AlzHjgfdmWXQe97MKXPet92lZVtyGc16v8 4M76Sp2S/dyubrUdT34rd8o1BP5fbZAewaPgLKXEUpyRaKjFXFScCAA2E+PgUQIAAA== Subject: Re: [MMUSIC] Review (by dhanes) of draft-holmberg-mmusic-udptl-dtls-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 13:09:06 -0000 Hi David, Again, thanks for your comments! Reply inline. > 1) For some reason, I can't seem to get past the wording on this first se= ntence in Section 1. I feel like it could be stated a bit clearer. The poin= t=20 > I think is that there are means to send faxes across the PSTN in a secure= manner but it was never a priority due to the barrier of physical=20 > access. This is probably just personal preference but I feel a wording si= milar to the following gets the point across better: > > > "While it is possible to transmit highly sensitive documents using tradit= ional telephony encryption devices, secure fax on the Public Switched > Telephone Network (PSTN) was never widely considered or prioritized. This= was mainly because of the challenges involved with physical access to tele= phony equipment." I am ok with your suggested change. ----------------------- > 2) In the last sentence of the first paragraph of Section 1, the followin= g statement is made "Some of the security mechanisms for securing fax inclu= de:" and then a T.30 and T.38=20 > scheme is mentioned. I think that this has been brought up before but SRT= P using fax passthrough is more widely deployed in my experience than eithe= r of the other secure=20 > faxing methods. I realize that this document is written under the context= of UDPTL-based fax but here in the introduction the topic so far is secure= fax in a general sense and it=20 > has yet to be narrowed down to just UDPTL-based fax. It seems like a glar= ing omission that SRTP fax solutions are not mentioned here. I think SRTP n= eeds to be added if this is=20 > kept in its present form and wording. Or this section could be changed in= a manner similar to the following. This will address the omission of SRTP= from my perspective: I am ok with your suggested rewrite. Note, though, that [ITU.T38.2010] does define the usage of T.38 over RTP. > While telephony encryption devices have been traditionally used for > highly sensitive documents, secure fax on the Public Switched > Telephone Network (PSTN) was not as widely considered or prioritized > because of the challenges involved with physical access to telephony > equipment. As real-time communications transition to IP networks, > where information might potentially be intercepted or spoofed, an > appropriate level of security for fax that offers integrity and > confidentiality protection is vital. > > The overwhelmingly predominant fax transport protocol today is > UDPTL-based. The protocol stack for fax transport using UDPTL is shown > in Table 1. > > > +-----------------------------+ > > | Protocol | > > +-----------------------------+ > > | Internet facsimile protocol | > > +-----------------------------+ > > | UDPTL | > > +-----------------------------+ > > | UDP | > > +-----------------------------+ > > | IP | > > +-----------------------------+ > > > Table 1: Protocol stack for UDPTL over UDP > > > Implementations exist today for securing this fax transport type. Some = of these > mechanisms are: > > > o [ITU.T30.2005] Annex H specifies integrity and confidentiality > protection of fax in application layer, independent of protocol > for fax transport. > > o [ITU.T38.2010] specifies fax transport over RTP/SAVP which enables > integrity and confidentiality protection of fax in IP network. > > > Despite these mechanisms to secure fax, there is no transport layer > security offering integrity and confidentiality protection for UDPTL. T= his issue > was addressed in a study by the 3rd Generation Partnership Project (3GP= P) > on how to provide secure fax in the IP Multimedia Subsystem (IMS). They > concluded that secure fax shall be transported using UDPTL over DTLS. ------------------ >3) Shouldn't the title for Table 2 be "Protocol stack for UDPTL over DTLS"= and not "Protocol stack for UDPTL over UDP"? I guess it should be "Protocol stack for UDPTL over DTLS over UDP" Regards, Christer