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

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:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: den 6 oktober 2015 20:10
> To: i-d-announce@ietf.org
> Cc: mmusic@ietf.org
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
> 
> 
> 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/
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic