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 1DB481AE1BF for ; Sat, 30 Nov 2013 11:30:35 -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 MKcO8nAT0Rj1 for ; Sat, 30 Nov 2013 11:30:33 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1438E1AE1BC for ; Sat, 30 Nov 2013 11:30:33 -0800 (PST) Received: from BLU169-W119 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Nov 2013 11:30:31 -0800 X-TMN: [zZr/UotrZ0IVGDpGaVgF1C0DmuUttLlJ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_458fb067-642a-4ab4-a551-5d1a1751e310_" From: Bernard Aboba To: Christer Holmberg , "mmusic@ietf.org" Date: Sat, 30 Nov 2013 11:30:31 -0800 Importance: Normal In-Reply-To: <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> References: , <867vuen3mevy8h0fwtss4hta.1385800798144@email.android.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2013 19:30:31.0609 (UTC) FILETIME=[A207D290:01CEEE02] 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: Sat, 30 Nov 2013 19:30:35 -0000 --_458fb067-642a-4ab4-a551-5d1a1751e310_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer asked:"In your example=2C how does the answerer know that the offe= red m- lines are 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."[BA] The most obvious way would be grouping. Looking at RFC 5888= /5583=2C it doesn't appear that either FID or DDP grouping would apply to s= imulcast. So perhaps a new group type would be needed. =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 might be negotiated in a simpli= fied Offer/Answer exchange based=0A= on the principles of Unified Plan.=20 =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= =20 =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 direction if a direction=0A= attribute was present as either a media stream attribute or a session attr= ibute. For sendonly RTP streams=2C the payload type numbers indicate the va= lue of the payload type field in RTP packet the offerer is planning to send= for that codec... In all cases=2C=0A= the formats in the "m=3D" line MUST be listed in order of preference=2C wi= th the first format listed being preferred. In this case=2C preferred mean= s that the recipient of the offer SHOULD use the format with the highest pr= eference that is acceptable to it. If=0A= multiple media streams of different types are present=2C it means that the= offerer wishes to use those streams at the same time. A typical case is a= n audio and a video stream as part of a videoconference. =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= =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= =20 =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 of those formats during=0A= the session. In other words=2C the answerer MAY change formats in the mid= dle of the session=2C making use of any of the formats listed=2C without se= nding a new offer. For a sendonly stream=2C the offer SHOULD indicate thos= e formats the offerer is willing to send=0A= for this stream. For a recvonly stream=2C the offer SHOULD indicate thos= e formats the offerer is willing to receive for this stream.... =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= =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= =20 =0A= =0A= = --_458fb067-642a-4ab4-a551-5d1a1751e310_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Christer =
asked:
"In your e=
xample=2C how does the answerer know that the offered m- lines are for simu=
lcast? As far as O/A is concerned=2C it could just be a number of completel=
y separate (different content etc) uni-directional streams."
[BA] The most obvious way would be grouping. Looking at RF= C 5888/5583=2C it doesn't appear that either FID or DDP grouping would appl= y to simulcast. So perhaps a new group type would be needed. 
=0A=
=0A=
Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B wrote:=0A=
=0A=
=0A=
=0A=
At IETF 88=2C a number of =3B participants (including = myself) expressed the view that draft-westerlund-avtcore-rtp-simulcast was = too complicated. =3B =3BBelow=2C I will attempt to explain how simu= lcast might be =3Bnegotiated in a simplified Offer/Answer exchange = =3Bbased=0A= on the principles of Unified Plan.
=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" attribute. =3B We =3B refer to a stream as bein= g marked with a certain direction if a =3Bdirection=0A= attribute was present as either a media stream attribute or a session attr= ibute. =3BFor sendonly RTP streams=2C the payload type numbers indicate= the value of the payload type field in RTP packet =3Bthe offerer is pl= anning to send for that codec... =3B In all cases=2C=0A= the formats in the "m=3D" line MUST be listed in order of =3Bpreferenc= e=2C with the first format listed being preferred. =3B In this =3Bc= ase=2C preferred means that the recipient of the offer SHOULD use the forma= t with the highest preference that is acceptable to it. If=0A= multiple media streams of different types are present=2C it means that the= offerer wishes to use those streams at the same time. =3B A =3Btyp= ical 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=
=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 me= dia from its peer=2C it MUST mark the stream as recvonly... If multiple for= mats are listed=2C it means that the offerer is capable =3Bof making us= e of any of those formats during=0A= the session. =3B In other =3Bwords=2C the answerer MAY change form= ats in the middle of the session=2C making use of any of the formats listed= =2C without sending a new offer. =3B =3BFor a sendonly stream=2C th= e offer SHOULD indicate those formats the =3Bofferer is willing to send= =0A= for this stream. =3B For a recvonly stream=2C =3B the offer SHOULD= indicate those formats the offerer is willing to receive 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=
=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=
= --_458fb067-642a-4ab4-a551-5d1a1751e310_--