Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt

From: [email-masked]
Date: Tue, 06 Oct 2015 11:09:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Using Simulcast in SDP and RTP Sessions
        Authors         : Bo Burman
                          Magnus Westerlund
                          Suhas Nandakumar
                          Mo Zanaty
	Filename        : draft-ietf-mmusic-sdp-simulcast-02.txt
	Pages           : 24
	Date            : 2015-10-06

Abstract:
   In some application scenarios it may be desirable to send multiple
   differently encoded versions of the same media source in different
   RTP streams.  This is called simulcast.  This document discusses the
   best way of accomplishing simulcast in RTP and how to signal it in
   SDP.  A solution is defined by making an extension to SDP, and using
   RTP/RTCP identification methods to relate RTP streams belonging to
   the same media source.  The SDP extension consists of a new media
   level SDP attribute that expresses capability to send and/or receive
   simulcast RTP streams.  RTP/RTCP identification using either payload
   types or a separately defined method for RTP stream configuration are
   defined.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-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: Bo Burman <[email-masked]>
Date: Wed, 7 Oct 2015 14:59:23 +0000

The main update in this version is to introduce use of RTP stream ID (RID) as identifier in addition to SDP format (RTP payload type), and aligns its use in simulcast with that draft (draft-pthatcher-mmusic-rid-00).

Summary of changes from -01:

   o  Relying on the new RID solution for codec constraints and
      configuration identification.  This has resulted in changes in
      syntax to identify if pt or RID is used to describe the simulcast
      stream.

   o  Renamed simulcast version and simulcast version alternative to
      simulcast stream and simulcast format respectively, and improved
      definitions for them.

   o  Clarification that it is possible to switch between simulcast
      version alternatives, but that only a single one be used at any
      point in time.

   o  Changed the definition so that ordering of simulcast formats for a
      specific simulcast stream do have a preference order.

There are still a few open issues that need discussion (also included as editor's notes, except for the last one):

1) There is currently the possibility to set a simulcast as "sendrecv", but this is not a good match considering the uni-directionality of both PT and RID simulcast stream identifiers. I expect some complexity in this mismatch, requiring additional description, but was not able to investigate it further. It is also just an optimization to save a few bytes of SDP text in case simulcast send and receive direction is exactly the same for a certain simulcast stream identifier. I propose to remove "sendrecv" and just keep "send" and "recv", for simplicity.

2) There is a brief section on declarative use in SDP, but the RID specification currently lacks this, so it is not really possible to define in a good way. Should we add declarative use to RID, or should it be removed here?

3) With the chosen approach (only defining simulcast on SDP media level), it is not possible to spread simulcast streams onto different media transports, thus also making it impossible to use different flow-based QoS, or separate simulcast streams onto different multicast groups. Since this is described as being one potential motivation for using simulcast, either we have to state that the current solution deliberately does not deal with it, remove that motivation, or add the possibility for media transport separation of simulcast streams. The latter approach could possibly involve defining use of the simulcast attribute on SDP session level.

4) Since there are two alternative ways of identifying simulcast streams, should we require all implementations of simulcast to support both, or is one mandatory, and how is use of the optional one negotiated in that case?

Cheers,
Bo

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: den 6 oktober 2015 20:10
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
> 
> 
> 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.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christian Groves <[email-masked]>
Date: Fri, 9 Oct 2015 13:54:55 +1100

Hello Bo,

I think the updated draft captures most of my earlier comments regarding 
the stream version/alternatives etc.
One place that may be worth updating still is cl.6.1.2. It talks about 
stream formats as being alternatives but does not talk about offerers or 
answerers being prepared to send/receive multiple concurrent streams.

Also just to reinforce the terminology it may be good to change the ABNF 
from "sc-dir-list" to "sc-str-list" indicate "simultaneous streams", eg.
sc-attr     = "a=simulcast:" 1*3( WSP sc-str-list )
sc-str-list = sc-dir WSP sc-id-type "=" sc-alt-list *( ";" sc-alt-list )

Nit: There a WSP that should be removed after the colon in all the 
figures with a=simulcast: .

Regards, Christian

---

From: Bo Burman <[email-masked]>
Date: Fri, 9 Oct 2015 07:58:44 +0000

Thanks Christian, your comments look good to me and I'll take them into account in the next version.

> From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: den 9 oktober 2015 04:55
> To: [email-masked]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
> 
> Hello Bo,
> 
> I think the updated draft captures most of my earlier comments regarding the stream version/alternatives etc.
> One place that may be worth updating still is cl.6.1.2. It talks about stream formats as being alternatives but does not talk
> about offerers or answerers being prepared to send/receive multiple concurrent streams.
> 
> Also just to reinforce the terminology it may be good to change the ABNF from "sc-dir-list" to "sc-str-list" indicate
> "simultaneous streams", eg.
> Nit: There a WSP that should be removed after the colon in all the figures with a=simulcast: .
> 
> Regards, Christian
> > The main update in this version is to introduce use of RTP stream ID (RID) as identifier in addition to SDP format (RTP
> payload type), and aligns its use in simulcast with that draft (draft-pthatcher-mmusic-rid-00).
> >
> > 1) There is currently the possibility to set a simulcast as "sendrecv", but this is not a good match considering the uni-
> directionality of both PT and RID simulcast stream identifiers. I expect some complexity in this mismatch, requiring
> additional description, but was not able to investigate it further. It is also just an optimization to save a few bytes of SDP
> text in case simulcast send and receive direction is exactly the same for a certain simulcast stream identifier. I propose to
> remove "sendrecv" and just keep "send" and "recv", for simplicity.
> >
> > 2) There is a brief section on declarative use in SDP, but the RID specification currently lacks this, so it is not really
> possible to define in a good way. Should we add declarative use to RID, or should it be removed here?
> >
> > 3) With the chosen approach (only defining simulcast on SDP media level), it is not possible to spread simulcast streams
> onto different media transports, thus also making it impossible to use different flow-based QoS, or separate simulcast
> streams onto different multicast groups. Since this is described as being one potential motivation for using simulcast,
> either we have to state that the current solution deliberately does not deal with it, remove that motivation, or add the
> possibility for media transport separation of simulcast streams. The latter approach could possibly involve defining use of
> the simulcast attribute on SDP session level.
> >
> > 4) Since there are two alternative ways of identifying simulcast streams, should we require all implementations of
> simulcast to support both, or is one mandatory, and how is use of the optional one negotiated in that case?
> >
> > Cheers,
> > Bo
> >
> >> 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.
> >>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Oct 2015 14:46:51 +0000

> On Oct 7, 2015, at 8:59 AM, Bo Burman <[email-masked]> wrote:
> 
> 3) With the chosen approach (only defining simulcast on SDP media level), it is not possible to spread simulcast streams onto different media transports, thus also making it impossible to use different flow-based QoS

I don't think that not quite right. 

We can send within in the same AF4x family on the same congestion context. So the one video stream could be AF42 and one could be AF41 (or AF43), but we could not have one be AF43 and the other be CS1 when they are in the same reliable transport protocol (like over the same TCP connection to a TURN server).  

Full details can be found in draft-ietf-dart-dscp-rtp-10 but basically I think this solution does allow enough flexibility for different QoS for the different layers in many cases.