Re: [rtcweb] A problem with both A and B

[Kevin Dempsey <[e-mail]>]

Adding or removing a source generally doesn't need a SDP O/A. The offerer
has indicated where media of a given type should be sent. The answerer can
arrange for any source it wants to send to that destination. It is unusual
for an answerer to send more that one SSRC at a time, but changing  the
source (and SSRC) is not uncommon.

How the offerer handles the change of SSRC, or receiving multiple SSRCs is
application specific. I believe most SIP endpoints I have used render only
one SSRC per m= line at a time and have some mechanism to switch SSRC when
the one they were rendering stops.


On 23 May 2013 09:03, Suhas Nandakumar <[e-mail]> wrote:

> Great Summarization Paul.
>
> My 2 cents
>
> SDP O/A enables parties in a session to decide on a compatible view of the
> session. This implies setting up appropriate transport  , media stack
> (encoders, decoders) context and alike in a way that the parties involved
> can have a successful session.
>
> Regardless of Plan A or Plan B , any modifications to session parameters (
> adding new source, removing a source, modifying existing parameters) that
> impacts resources managed, needs to be negotiated and O/A helps in this
> regard.
>
> Thanks
> Suhas
>
>
> On Wed, May 22, 2013 at 9:08 AM, Stefan Håkansson LK <
> [e-mail]> wrote:
>
>> On 5/22/13 5:41 PM, Paul Kyzivat wrote:
>> > On 5/22/13 4:50 AM, Stefan Håkansson LK wrote:
>> >> I think this was a good summary.
>> >>
>> >> But regarding "a mechanism for describing the role and intent of each
>> >> RTP stream in the RTP session.", do we really need that? Isn't the
>> >> combination of ssrc and the msid draft sufficient?
>> >>
>> >> Together the clearly identify how ssrc's map into PC-streams and
>> >> PC-tracks, and the application can convey the remaining info (e.g.
>> >> PC-stream xx represents the speaker audio+video, yy the room video
>> etc.)
>> >> needed in any way it likes .
>> >
>> > My statements were not intended to be rtcweb-specific. The bundling
>> > stuff is going to be a more general SDP extension. IMO the problems that
>> > rtcweb and clue have encountered that need this are just the tip of the
>> > iceberg.
>>
>> You're probably right in this (and I have to admit my comments are
>> usually quite rtcweb centric).
>>
>> >
>> > My point about the role/intent is that the application must have some
>> > means to determine this. It doesn't always need to be in SDP. But the
>> > old approach that is mostly based on the cases being so simple that it
>> > is always obvious without signaling are now breaking down. And in the
>> > case of SIP apps there are few mechanisms to build on other than SDP.
>>
>> I agree to the above.
>>
>> But taking my usual rtcweb shortcut, could we imagine that rtcweb solves
>> this with something like msid (i.e. you just provide the identity of
>> each stream, and leave it up to the app to exchange what content it
>> represents)?
>>
>> Once we have something that is usable in a SIP world (an agreed way to
>> signal this in SDP), perhaps the web app could add that to the SDP. (Not
>> that clean, but could work).
>>
>> >
>> >       Thanks,
>> >       Paul
>> >
>> >> Stefan
>> >>
>> >> On 2013-05-21 22:13, Paul Kyzivat wrote:
>> >>> On 5/21/13 3:20 AM, Christer Holmberg wrote:
>> >>>> Hi,
>> >>>>
>> >>>>>> I don't think it's a BUNDLE issue whether adding/removing of
>> streams
>> >>>>>> require an O/A exchange or not. It's an SDP, and SDP O/A, issue.
>> >>>>>>
>> >>>>>> BUNDLE is about sharing a 5-tuple.
>> >>>>>
>> >>>>> I don't agree.
>> >>>>>
>> >>>>> RTP is already able to support multiple RTP streams sharing an RTP
>> >>>>> session (and 5-tuple).
>> >>>>>
>> >>>>> What BUNDLE is about is describing that in SDP.
>> >>>>> And that includes how SDP O/A works.
>> >>>>
>> >>>> Multiple RTP streams can already share an RTP session today, using
>> >>>> multiple SSRCs per m- line :)
>> >>>>
>> >>>> If adding a new stream means adding a new m- line, then an SDP O/A is
>> >>>> obviously needed - bundle or no bundle.
>> >>>>
>> >>>> If adding a new stream means adding a new SSRC, within an existing
>> m-,
>> >>>> then it is also an SDP O/A issue - bundle or no bundle.
>> >>>
>> >>> AFAIK there is wide agreement that an RTP *session* can carry multiple
>> >>> RTP streams.
>> >>>
>> >>> An SDP O/A exchange negotiating an RTP m-line pair establishes an RTP
>> >>> session. There is disagreement whether it is permissible for the
>> >>> resulting RTP session to carry multiple RTP streams. The specs are
>> >>> ambiguous on this point. Clearly there are well identified cases where
>> >>> they do, and we aren't likely to rule those incorrect. Its also clear
>> >>> that some of these cases start out sending a single SSRC, and then
>> later
>> >>> "add" another. (It may actually be a substitution.)
>> >>>
>> >>> So it seems clear to me that you may add an RTP stream to an RTP
>> session
>> >>> described by an m-line without doing another O/A exchange.
>> >>>
>> >>> What is lacking in such cases is a mechanism for describing the role
>> and
>> >>> intent of each RTP stream in the RTP session. In some cases it is
>> >>> possible to get by without this, by assuming that the two ends have
>> >>> consistent *assumptions* about how to infer the role/intent. But there
>> >>> are many cases where this isn't enough.
>> >>>
>> >>> Extra SDP syntax has been defined in an ad hoc way to get at bits and
>> >>> pieces of this problem. E.g., the a=ssrc attribute. What has already
>> >>> been defined doesn't seem suficient for all the new cases we are no
>> >>> discussing.
>> >>>
>> >>> BUNDLE is *another* proposal for addressing part or all of this
>> problem.
>> >>> But BUNDLE brings along another problem: for BUNDLE to be useful, it
>> >>> must be possible to associate each RTP packet with one of the bundled
>> >>> m-lines. Without BUNDLE we don't have that problem.
>> >>>
>> >>> To summarize:
>> >>>
>> >>> - without bundle, we need a mechanism for describing the role/intent
>> >>>     of each RTP stream in the RTP session. *If* we choose to describe
>> >>>     that with SDP, then we need an O/A exchange each time we add
>> >>>     an RTP stream.
>> >>>
>> >>> - with BUNDLE and Plan A, the assumption is that each m-line in the
>> >>>     bundle describes a single RTP stream, and so the other SDP stuff
>> >>>     in that media section can be used to describe the role/intent of
>> >>>     that RTP stream. By design this requires a new m-line for each
>> >>>     RTP stream, so adding one requires an O/A. We then assume that
>> there
>> >>>     is enough stuff in each media section to decide which m-line each
>> >>>     packet should be associated with.
>> >>>
>> >>> - with BUNDLE and Plan B, there may be multiple RTP streams per
>> >>>     m-line. As in Plan A we need to associate each packet with one of
>> >>>     the m-lines. Like the no-bundle case we still need some mechanism
>> >>>     to describe the role/intent if the individual RTP streams.
>> >>>     In some cases (e.g., a=ssrc) the same info that classifies to
>> >>>     an m-line may also specify the role of each stream. That case
>> >>>     also leads to an O/A for each stream add.
>> >>>
>> >>>     If you have a non-SDP way to discover the role/intent of each
>> >>>     RTP stream, and you use a way of classifying to one of the
>> >>>     bundled m-lines *without* enumerating every RTP stream, then
>> >>>     you can perhaps avoid an O/A for each stream add. E.g., if you
>> >>>     just bundle one audio and one video m-line, and use PT to
>> >>>     distinguish those.
>> >>>
>> >>> Note: in above I said Plan A uses an m-line for each RTP stream. That
>> >>> isn't always the case. There are some cases (at least in clue) where
>> >>> each m-line is intended to describe a "flow" (clue capture) that may
>> >>> correspond to different RTP streams over time, or that might include
>> >>> supporting FEC streams, etc. Depending on your assumptions about this
>> >>> case it may start to take on some of the characteristics of Plan B.
>> >>>
>> >>>       Thanks,
>> >>>       Paul
>> >>>
>> >>> _______________________________________________
>> >>> rtcweb mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/rtcweb
>> >>
>> >> _______________________________________________
>> >> rtcweb mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/rtcweb
>> >>
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>