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

Emil Ivov <emcho@jitsi.org> Mon, 03 June 2013 17:32 UTC

Return-Path: <emil@sip-communicator.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500A21F8FDC for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 10:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyZq48LxzuJ7 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 10:32:04 -0700 (PDT)
Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id ADBFE21F86CB for <rtcweb@ietf.org>; Mon, 3 Jun 2013 10:28:08 -0700 (PDT)
Received: by mail-bk0-f41.google.com with SMTP id jc3so344762bkc.14 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 10:28:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=rP5XCiMJqG+udECwgBPaJ6/qBjrOMjz1sRwRdRTtj2c=; b=KsqGHWIiI0Rlx3h7Wj+/shDmEIbKHudbaeQStpF4bOkd+hOgLsQvFS+HqHoqT6SVpM a/6a28bDxKL+IHaLGiKZOtlvUObNzwp3tzzVX0ZS+sxe+4cu5Ms4MYIdEBjEeKksAPuC lh+irv1mXtaQHYjwTI11+CA0/UffeZuQZi1qsNWHwXNXAyX2u1/nG78ApQVkRk0B39Mc wKvqBphC4kIU9b4ZGMsGboEkX0Gkd6Q5U1sB9p8K8HQ3DU6eF4FuM5mz5dF/eCoxbdaZ 13edoOLmecDzLm+clvXLLaP8t9NrVX028CmugIl6Nn17CFcwcoUBvCZCazq1ixQM7Brz LHNg==
X-Received: by 10.204.183.16 with SMTP id ce16mr6685598bkb.91.1370280487221; Mon, 03 Jun 2013 10:28:07 -0700 (PDT)
Received: from [192.168.1.118] ([88.203.232.9]) by mx.google.com with ESMTPSA id cm9sm20727477bkb.4.2013.06.03.10.28.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 10:28:06 -0700 (PDT)
Message-ID: <51ACD224.8080100@jitsi.org>
Date: Mon, 03 Jun 2013 20:28:04 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113528171@xmb-aln-x02.cisco.com> <51A8EAB7.8080206@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB11352940B@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11352940B@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQm5BxDLKP/IXtjCU/pi24NrsyfNBe4gB/XcSsSZ1+GZwXvWb71vW+kzJC5CDxKuzmtWoQ8d
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [rtcweb] Translating Plan A into No Plan (Was: No Plan)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 17:32:14 -0000

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