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_--