Subject: Re: [MMUSIC] Multicast support in simulcast ? [Re: Simulcast draft review neede

From: Ron Even <[email-masked]>
Date: Wed, 28 Sep 2016 08:15:02 +0300

Hi,
I responded in a different thread, I have an interest in multicast support
which in my view is more relevant and is not based on MRST. I will to work
on a proposal but I asked for clarifying text in the current simulcast
draft that will say that it is only addressing offer/answer usage and that
declarative and multicast support solution my require a different SDP
attribute since it is probably not an extension to this solution.
I also believe that using a separate rtp session for each simulcast
configuration is simpler.

Roni

On Tuesday, September 27, 2016, Mo Zanaty (mzanaty) <[email-masked]>
wrote:

> I do not think we should expand the scope of the current simulcast or rid
> specs to include multicast. If there is enough interest in multicast (which
> has not been the case each time folks have asked), a more wholistic effort
> is needed as there are more fundamental gaps before addressing simulcast,
> and the simulcast draft is certainly not the right place for those more
> fundamental issues.
>
> Mo
>
> On Sep 26, 2016, at 2:47 PM, Flemming Andreasen (fandreas) <
> [email-masked] <javascript:;>> wrote:
>
> Greetings MMUSIC
>
> I'd like to hear from more people on this topic before we decide one way
> or the other.
>
> I will note that multicast was removed in the -03 version almost a year
> ago (as noted in the change log). Similarly, Adam Roach asked a related
> question on the -rid draft about 6 months ago, which didn't generate any
> interest in further work either (see https://mailarchive.ietf.org/
> arch/msg/mmusic/kEsBZLBW5exDK25bMvB3YHofm8o).
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
>
> > On 9/26/16 5:34 AM, Magnus Westerlund wrote:
> > Hi Roni,
> >
> > I can understand your view, but I don't see that I as document editor
> are performing this change unless the chairs declare that there are at
> least rough consensus to include it. My view is that we need to finish
> simulcast for WebRTC. Taking on a task that is going to delay the work a
> year or so is not viable in my opinion.
> >
> > So about the different solution. Yes, that is actually likely, but not
> easily addressable. In fact the underlying issue here is the underlying
> assumption that an m= line is a media source for SDP O/A. That is not the
> classical multicast interpretation. And it is clear that for multicast one
> actually have to tackle this discrepancy.
> >
> > From my perspective the multicast usage of SDP is something that is
> lagging significantly when it comes to features that has been defined for
> O/A unicast. There are a lot of clarifications and decisions that needs to
> be made. I don't see that we can do any better than to open up a WG item to
> clarify multicast and declarative usages in SDP and then build an simulcast
> extension.
> >
> > The big question is if there exist sufficient interest in the WG to
> tackle this.
> >
> > Cheers
> >
> > Magnus
> >
> >> Den 2016-09-26 kl. 11:25, skrev Ron Even:
> >> Hi,
> >> I am sorry for noticing at this stage but in my view this is something
> >> that we need to look at now since we need to be sure that this solution
> >> can support the multicast declarative case or we will end up with a
> >> different simulcast solution for multicast, which is not a good
> >> direction. Support for multicast is something that is defintly required
> >> Roni
> >>
> >> On Monday, September 26, 2016, Magnus Westerlund
> >> <[email-masked] <javascript:;> <mailto:
> [email-masked] <javascript:;>>>
> >> wrote:
> >>
> >>    Den 2016-09-24 kl. 08:06, skrev Ron Even:
> >>
> >>        Hi Bo,
> >>        My suggestion is that multicast is very important case for
> simulcast
> >>        usage and it must be supported, in the initial document. My
> >>        reading of
> >>        the current text was that the dicument provide limited support
> for
> >>        multicast and that is wrong approach
> >>        Roni
> >>
> >>
> >>    Roni,
> >>
> >>    I would have been fine with including multicast support and
> >>    declarative usages, if we known there was actually an interest in
> >>    multicast earlier. Then we could have ensured that we had a solution
> >>    in place for it. However, that has not been expressed and the
> >>    individual version that was adopted as WG item
> >> (https://www.ietf.org/archive/id/draft-burman-mmusic-sdp-
> simulcast-00.txt
> >> <https://www.ietf.org/archive/id/draft-burman-mmusic-sdp-
> simulcast-00.txt>)
> >>    says:
> >>
> >>       Multicast:  Multiple RTP sessions will be required to enable
> >>          combining simulcast with multicast.  Different simulcast
> versions
> >>          have to be separated to different multicast groups to allow a
> >>          multicast receiver to pick the version it wants, rather than
> >>          receive all of them.  In this case, the only reasonable
> >>          implementation is to use different RTP sessions for each
> multicast
> >>          group so that reporting and other RTCP functions operate as
> >>          intended.  The proposed solution can be extended to support
> this
> >>          functionality with an optional mid: prefix before the RTP
> payload
> >>          types of a simulcast version, to describe simulcast across
> >>          multiple media descriptions.
> >>
> >>    Note the "extended to support this functionality".
> >>
> >>    Thus, this was adopted as a work item multicast support was a future
> >>    extension. The general declarative usage will need to be removed
> >>    from the simulcast draft in the next version due to that RID is
> >>    missing that support. The removal of declarative usage was discussed
> >>    twice I think as a result of my feedback on RID. The end result was
> >>    that as I didn't have the time to propose text, and Adam didn't feel
> >>    he had the expertise it didn't get written up.
> >>
> >>    The only way forward with simulcast in multicast and declarative use
> >>    is to start working on extension specifications for both the RID and
> >>    simulcast documents. There is no way we can shoehorn it in at this
> >>    stage.
> >>
> >>    Cheers
> >>
> >>    Magnus
> >>
> >>
> >>        On Friday, September 23, 2016, Bo Burman <[email-masked]
> <javascript:;>
> >>        <mailto:[email-masked] <javascript:;>>> wrote:
> >>
> >>            Hi Roni,____
> >>
> >>            __ __
> >>
> >>            You did indeed send such review, thank you. My apologies,
> >>        but that
> >>            somehow fell off my radar until now.____
> >>
> >>            __ __
> >>
> >>            I include your comments from July 24:____
> >>
> >>            __ __
> >>
> >>            > This solution is partial since it does not support all
> >>        simulcast use____
> >>
> >>            > cases. The document in section 6.4 talk about declarative
> >>        usage and point to____
> >>
> >>            > section 8 about limitation of supporting this case. In
> >>        section 8 the____
> >>
> >>            > document says that the solution does not support multiple
> >>        multicast groups____
> >>
> >>            > and as such claiming support for declarative usage is very
> >>        limited or does____
> >>
> >>            > not exist.____
> >>
> >>            __ __
> >>
> >>            So, you suggest that there is no point even mentioning
> >>        declarative
> >>            usage? If that helps, I have no problem to remove any
> >>        mentioning of
> >>            declarative usage.____
> >>
> >>            __ __
> >>
> >>            > The question is why does the document support the
> >>        simulcast attribute only____
> >>
> >>            > on the media level and does not define usage for the
> >>        session level to allow____
> >>
> >>            > multiple multicast groups each as a separate RTP
> session.____
> >>
> >>            __ __
> >>
> >>            This was an early design choice, which in my view is mainly
> >>        related
> >>            to two things:____
> >>
> >>            __1)      __RFC 7656 states that an m= block in SDP (an m=
> >>        line and
> >>            all lines up to but not including the next m= line, or the
> >>        end of
> >>            the SDP) generally corresponds to a (single) media source____
> >>
> >>            __2)      __the definition of simulcast to mean sending
> >>        differently
> >>            encoded representations of a media source (thus restricted
> to a
> >>            single m= block)____
> >>
> >>            __ __
> >>
> >>            So, the reason is simply that use of multicast groups does
> >>        not fit
> >>            well with the above. No immediate need for use of simulcast
> with
> >>            multicast was expressed, so the design decision was to
> basically
> >>            leave it out of scope for this draft. We could probably make
> >>        that
> >>            even more clear.____
> >>
> >>            __ __
> >>
> >>            I believe it should be possible to define multicast usage of
> >>            simulcast as a separate document (updating
> >>            draft-ietf-mmusic-sdp-simulcast) at some later point in
> time. It
> >>            seems very straightforward to build a simulcast for
> multicast on
> >>            explicitly allowing a=simulcast on session level in SDP.
> >>        Such update
> >>            document would have to relax the guideline to restrict a
> media
> >>            source to an m= block, probably with a clear motivation and
> >>            explanation that this is specific for multicast (and other
> RTP
> >>            usages where use of multiple different transports is the
> >>        foremost
> >>            concern). Without thinking this through entirely, I also
> >>        believe it
> >>            would be necessary to make an additional restriction to keep
> the
> >>            simulcast stream-identifying RID values unique across the SDP
> >>            (instead of being localized to an m= line), but it would
> >>        probably be
> >>            sufficient to make it work. That RID uniqueness requirement
> >>        should
> >>            hardly be any problem to meet in practice, since the
> >>        possible RID
> >>            value space is much larger than e.g. RTP payload types.____
> >>
> >>            __ __
> >>
> >>            Cheers,____
> >>
> >>            Bo (as individual)____
> >>
> >>            __ __
> >>
> >>            *From:*mmusic [mailto:[email-masked] <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>');>]
> *On
> >>            Behalf Of *Ron Even
> >>            *Sent:* den 23 september 2016 06:44
> >>            *To:* Flemming Andreasen <[email-masked] <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>');>>
> >>            *Cc:* mmusic <[email-masked] <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>');>>
> >>            *Subject:* Re: [MMUSIC] Simulcast draft review needed____
> >>
> >>            __ __
> >>
> >>            Hi,____
> >>
> >>            I sent my review to the list and had no feedback.____
> >>
> >>            Roni
> >>
> >>            On Thursday, September 22, 2016, Flemming Andreasen
> >>            <[email-masked] <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>');>>
> wrote:____
> >>
> >>                Thank you to all that reviewed the -rid draft so far.
> >>
> >>                Please note that we also have the simulcast draft
> >>
> >>
> >>
> >> https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt
> >> <https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt>
> >>
> >> <https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt
> >> <https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt>>
> >>
> >>                to go along with this, and we really need some reviews
> >>        of that
> >>                one too. If you have some time to review it, please do
> >>        so and
> >>                send your comments to the list (incl. "looks good").
> >>
> >>                Thanks
> >>
> >>                -- Flemming
> >>
> >>
> >>                _______________________________________________
> >>                mmusic mailing list
> >>                [email-masked] <javascript:;>
> >>        <javascript:_e(%7B%7D,'cvml',[email-masked] <javascript:;>');>
> >>                https://www.ietf.org/mailman/listinfo/mmusic
> >>        <https://www.ietf.org/mailman/listinfo/mmusic>
> >>                <https://www.ietf.org/mailman/listinfo/mmusic
> >> <https://www.ietf.org/mailman/listinfo/mmusic>>____
> >>
> >>
> >>
> >>    --
> >>
> >>    Magnus Westerlund
> >>
> >> ----------------------------------------------------------------------
> >>    Services, Media and Network features, Ericsson Research EAB/TXM
> >> ----------------------------------------------------------------------
> >>    Ericsson AB                 | Phone  +46 10 7148287
> >>    Färögatan 6                 | Mobile +46 73 0949079
> >>    SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> <javascript:;>
> >> ----------------------------------------------------------------------
>
>