Hey Cullen, Paul, all

On 31.05.13, 22:19, Cullen Jennings (fluffy) wrote:
> On 31.05.2013, at 12:23 PM, Emil Ivov <emcho@jitsi.org> 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


-- 
https://jitsi.org