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

[Bo Burman <[e-mail]>]

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

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Christian Groves
> Sent: den 9 oktober 2015 04:55
> To: [e-mail]
> 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.
> 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
> On 8/10/2015 1:59 AM, Bo Burman wrote:
> > 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:[e-mail]] On Behalf Of
> >> [e-mail]
> >> Sent: den 6 oktober 2015 20:10
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic