Re: [MMUSIC] [rtcweb] Translating Plan A into No Plan (Was: No Plan)

[Christer Holmberg <[e-mail]>]

Hi,

>>> I don't understand why we would be talking about translating from one 
>>> of these plans to another. AFAIK they are *alternatives*, and that we 
>>> will at some point agree on one, and that will be the only one implemented.
>>
>> It has been pointed out that some existing non-WebRTC endpoints expect 
>> to get SDP "the Plan A way". Cullen asked how such devices could be 
>> made to communicate with "No Plan" browsers. This was my answer.
>>
>> Personally I haven't come across such devices so I can only speculate 
>> about the reasons why they work the way they work. Still I don't see 
>> why they shouldn't be able to talk to WebRTC browsers ... hence my answer.
>
> They clearly *don'* expect to get it the Plan A way (bundled).
> >
> I accept that there must be a variety of things that employ multiple
> (unbundled) m-lines, each on its own 5-tuple with one RTP stream.

I asked about that in a separate thread, but nobody replied, so I'll ask again :)

If the JS app receives multiple unbundled m- lines on the wire, does the JS app have to "convert" it into whatever Plan/Format supported by the API?

Regards,

Christer



>> On 6/3/13 1:28 PM, Emil Ivov wrote:
>>> Hey Cullen, Paul, all
>>>
>>> On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote:
>>>> On 31.05.2013, at 12:23 PM, Emil Ivov <[e-mail]> wrote:
>>>>
>>>>> Certainly. Could you please post the SDP that you would like to 
>>>>> see translated in a way that's compatible with "No Plan"?
>>>>>
>>>>> Emil
>>>>
>>>> We can start with the SDP in plan A
>>>
>>> The example in "7.3. Many Videos" looks like a good start:
>>>
>>> http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-7.3
>>>
>>> Here it is:
>>>
>>>      v=0
>>>      o=- 20518 0 IN IP4 198.51.100.1
>>>      s=
>>>      t=0 0
>>>      c=IN IP4 203.0.113.1
>>>      a=ice-ufrag:F7gI
>>>      a=ice-pwd:x9cml/YzichV2+XlhiMu8g
>>>      a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7
>>>      a=group:BUNDLE m0 m1 m2 m3
>>>
>>>      m=audio 56600 RTP/SAVPF 0 96
>>>      a=mid:m0
>>>      a=rtpmap:0 PCMU/8000
>>>      a=rtpmap:96 opus/48000
>>>      a=ptime:20
>>>      a=sendrecv
>>>      a=rtcp-mux
>>>      [ICE Candidates]
>>>
>>>      m=video 0 RTP/SAVPF 97 98
>>>      a=mid:m1
>>>      a=rtpmap:97 H264/90000
>>>      a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>>>      a=rtpmap:98 VP8/90000
>>>      a=sendrecv
>>>      a=rtcp-mux
>>>      a=bundle-only
>>>      a=ssrc:11111 cname:45:5f:fe:cb:81:e9
>>>
>>>      m=video 0 RTP/SAVPF 97 98
>>>      a=mid:m2
>>>      a=rtpmap:97 H264/90000
>>>      a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>>>      a=rtpmap:98 VP8/90000
>>>      a=sendrecv
>>>      a=rtcp-mux
>>>      a=bundle-only
>>>      a=ssrc:22222 cname:45:5f:fe:cb:81:e9
>>>
>>>      m=video 0 RTP/SAVPF 97 98
>>>      a=mid:m3
>>>      a=rtpmap:97 H264/90000
>>>      a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>>>      a=rtpmap:98 VP8/90000
>>>      a=sendrecv
>>>      a=rtcp-mux
>>>      a=bundle-only
>>>      a=ssrc:333333 cname:45:5f:fe:cb:81:e9
>>>
>>>
>>> An offer generated by a "No Plan" browser in this case would look 
>>> something like this:
>>>
>>>      v=0
>>>      o=- 20518 0 IN IP4 198.51.100.1
>>>      s=
>>>      t=0 0
>>>      c=IN IP4 203.0.113.1
>>>      a=ice-ufrag:F7gI
>>>      a=ice-pwd:x9cml/YzichV2+XlhiMu8g
>>>      a=fingerprint:sha-1 42:89:c5:c6:55:9d:39:f9:b6:eb:e7
>>>      a=group:BUNDLE m0 m1
>>>
>>>      m=audio 56600 RTP/SAVPF 96 0
>>>      a=mid:m0
>>>      a=rtpmap:96 opus/48000
>>>      a=rtpmap:0 PCMU/8000
>>>      a=ptime:20
>>>      a=sendrecv
>>>      a=rtcp-mux
>>>      [ICE candidates]
>>>
>>>      m=video 56602 RTP/SAVPF 97 98
>>>      a=mid:m1
>>>      a=rtpmap:97 H264/90000
>>>      a=fmtp:97 profile-level-id=4d0028;packetization-mode=1
>>>      a=rtpmap:98 VP8/90000
>>>      a=sendrecv
>>>      a=rtcp-mux
>>>      [ICE candidates]
>>>
>>> I. Talking to legacy
>>>
>>> In case you need to talk to an actual legacy (as in widely deployed 
>>> SIP) endpoint, the above would translate into a regular two-stream 
>>> call. Both Plan A and No Plan would lead to essentially the same 
>>> result (if we accept that older endpoints won't throw an exception 
>>> at the sight of 4 m= lines) so not much to discuss here.
>>>
>>> II. Talking to Plan A style endpoints
>>>
>>> If you need to talk to a Plan A endpoint you basically have the 
>>> following options:
>>>
>>> 1. You use JavaScript to prettify the "No Plan" SDP and turn it into 
>>> something that looks like "Plan A". Not my favourite option, but I 
>>> am sure some would like to use it. Maybe vendors of Plan A equipment 
>>> would even distribute JS libs that do this. It would basically all 
>>> come down to generating one ssrc attribute and two additional 
>>> m=lines and appending this to the existing SDP string.
>>>
>>> 2. The application retrieves SSRCs from the browser, adds additional 
>>> application-specific signalling to it and then sends the whole thing 
>>> to a signalling gateway. The gateway (which you would also have with 
>>> Plan
>>> A) would convert the SDP into what it needs it to be.
>>>
>>> The application specific signalling can look like this:
>>>
>>> {
>>>       "firstStream":
>>>       {
>>>           "SSRC": "11111",
>>>           "CNAME": "45:5f:fe:cb:81:e9"
>>>       },
>>>       "secondStream":
>>>       {
>>>           "SSRC": "22222",
>>>           "CNAME": "45:5f:fe:cb:81:e9"
>>>       },
>>>       "thirdStream":
>>>       {
>>>           "SSRC": "333333",
>>>           "CNAME": "45:5f:fe:cb:81:e9"
>>>       },
>>> }
>>>
>>> 3. In Plan B, section 3.1 talks about generating "Plan A" style SDP 
>>> with the help of .content properties. If browser vendors are willing 
>>> to implement support for this then I suppose it would be a third option.
>>>
>>> III. Talking to other WebRTC applications
>>>
>>> This is the fun case and the one we should be most concerned with. 
>>> Let's imagine that the answerer needs to add a fourth video stream. 
>>> To make this work endpoints would need to do the following:
>>>
>>> a) with Plan A and draft-roach-rtcweb-glareless-add:
>>>      - send application specific signalling to the offerer
>>>      - have a new O/A exchange
>>>
>>> b) with Plan A:
>>>      - have a new O/A exchange
>>>      - potentially risk glare with some impact on user experience
>>>
>>> c) with No Plan:
>>>      ... nothing
>>>
>>> I am intentionally not going into how all plans would require 
>>> additional metadata that would place SSRC 1 left and 2 right as I 
>>> don't think this conveys any meaningful differences.
>>>
>>> Comments on the above are welcome. We could also move to another 
>>> scenario from the Plan A draft, if you believe that 7.3 is not 
>>> representative enough.
>>>
>>> Emil
>>>
>>>
>>
>>
>

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