Re: [rtcweb] No Plan

[Jim Barnett <[e-mail]>]

Just checking if I understand No Plan:  since the bundling is added via JS APIs, and not SDP, then if the app looks at 
The localDescription and remoteDescription attributes of the PeerConnection, it won't be able to tell if sources are bundled or not (since localDescription and remoteDescription are defined to contain SDP)

- Jim
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jonathan Lennox
Sent: Monday, June 03, 2013 6:03 PM
To: Paul Kyzivat
Cc: [e-mail]
Subject: Re: [rtcweb] No Plan


On Jun 3, 2013, at 4:40 PM, Paul Kyzivat <[e-mail]> wrote:

> +1
> 
> The more we dig into this the more it looks like Plan B.
> 
> 	Thanks,
> 	Paul

I think No Plan and Plan B are largely isomorphic in a WebRTC context.  The primary difference is that rather than using a=ssrc and a=receive-ssrc (and whatever other Plan B attributes would be needed) to control sources within an m-line, instead direct Javascript APIs are used for the same semantics. It's up to the application to communicate the relevant information end-to-end, in parallel to however it communicates the SDP blob.

As I see it, the primary advantages of No Plan, then, are that:

a) It allows "implicit" signaling of sources -- where that's sufficient -- by just sending RTP traffic.  This prevents problems related to the timing and synchronization between signaling and media.  (Note that Plan B probably actually needs this as well, for legacy interop.)

b) It carves a Comment 22 corner out of the SDP-based APIs, thus decoupling source signaling from SDP offer/answer.  This is for a scenario where there aren't any issues of legacy compatibility, and there isn't any (or at least much) existing IETF standardization -- as best I can recall, legacy compatibility and existing standardization were the primary motivations for using SDP as the WebRTC API.

Other than that, I think the two proposals are pretty similar for WebRTC, and it would probably be a Simple Matter of Programming to translate between the two (though you have to worry about the O/A state on the Plan B side).

In particular, if you have disaggregated media, you need multiple m-lines of the same type.  The No Plan document's suggestion that you offer only one m-line of a given media type is guidance on how to avoid interop failures on initial offers to legacy devices, I think, not an essential aspect of the proposal.


In a SIP context, No Plan requires defining a separate signaling channel for this source information, in scenarios where something beyond implicit signaling is needed.  As Emil has stated, I think that something like the SIP/XCon conference package, or something like the CLUE channel, would be the obvious places to start.

I think SIP, even more than RTCWeb, is where you'd want something lighter-weight and better-designed than SDP offer/answer to signal source changes.

> On 6/1/13 7:05 AM, Christer Holmberg wrote:
>> 
>> Hi,
>> 
>>>> The draft says:
>>>> 
>>>>       "For the sake of interoperability this specification strongly advises
>>>>       against the use of multiple m= lines for a single media type."
>>> 
>>> This should probably be clarified. The above referred mostly to a 
>>> browser's expectations and default offers. Multiple m= lines can 
>>> confuse a number of existing legacy endpoints which is why they 
>>> should be avoided when initiating a session that could reach a 
>>> similar device (and by default this should be assumed for any session).
>>> 
>>> If applications *know* that they need to have multiple m= lines of a 
>>> given type they can request this the same way they could do it with Plan B:
>>> 
>>>    If the application wishes, it can request that a given
>>>    media source be placed onto a separate m= line, by setting a new
>>>    .content property on the desired MediaStreamTrack; the values for the
>>>    .content property are those defined for the a=content attribute in
>>>    [RFC4796].
>>> 
>>> I'll make sure this is part of the next version.
>>> 
>>> Does this make sense?
>> 
>> I have nothing against a general recommendation to, for a given media type, have as few m- lines as possible.
>> 
>> But, I do think the draft need to point out that it is not always possible, e.g. because:
>> 
>> 1) m- lines have different characteristics (normally indicated using 
>> SDP attributes) that does not "fit" all content for the given media 
>> type;
>> 2) different protocols are used for different m- lines, even if the 
>> media type is the same; or
>> 3) the remote endpoint only supports a single (or, another given number) of sources per m- line.
>> 
>> Etc.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> 
>>> My understanding is that the usage of multiple m= lines for a single 
>>> media type would not affect the mechanism as such, but I just want 
>>> to verify that :)
>>> 
>>> Also, there ARE "legacy" implementations that use multiple m= lines for a single media type (e.g. video enabled devices using two video m= lines: one for camera content, and one for slides).
>>> 
>>> So, while I definitely think that legacy interoperability shall be taken into consideration, I would not like to make such strong statements. In my opinion (the draft also talks about it), the usage of multiple simultaneous SSRCs per m- line is a much bigger issue when it comes to legacy interoperability.
>>> 
>>> Also, in CLUE we have been working on signaling scenarios with multiple m= lines per media type.
>>> 
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On 
>>> Behalf Of Emil Ivov
>>> Sent: 29. toukokuuta 2013 22:00
>>> To: [e-mail]
>>> Subject: [rtcweb] No Plan
>>> 
>>> Hey all,
>>> 
>>> Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less.
>>> 
>>> The following "no plan" draft attempts to present one such approach:
>>> 
>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>> 
>>> The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP.
>>> 
>>> Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways.
>>> 
>>> Comments are welcome!
>>> 
>>> Cheers,
>>> Emil
>>> 
>>> --
>>> https://jitsi.org
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> .
>>> 
>> 
>> --
>> https://jitsi.org
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

--
Jonathan Lennox
[e-mail]


_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb