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

Emil Ivov <emcho@jitsi.org> Mon, 03 June 2013 21:40 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 CD0BF11E80BA for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, 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 yORB6Xf0sz+L for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:40:16 -0700 (PDT)
Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id D4DBB11E8110 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:36:31 -0700 (PDT)
Received: by mail-ee0-f41.google.com with SMTP id d4so1245766eek.28 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 14:36:31 -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=lLyWFIWkyfvQNpQn9mnOFSl/EDSOpRKLlX3jw/AbhoU=; b=nYaowk30nQWfp2R+4F7ASYWc6rlB69YIXBRJtRXnWrwEelVGnKJRp7463lSHOKQx+j bb/eenXkwYzKbSNe3wipgBAq5NAuywW3nLzT4Ki666BKCADFRsUMaL6UDnm+/58z+X3U jIeCFOm37LloQ9k+DFOQSRA4CGYzf9PCyo/d2tz+ynWCw2Y2auY1lm/TxQErzn7ymzoG s+J6i6x9NBz8VKfxsi6c8bF/EgmFTi2N83RSbKsMFdMCmdmZ+hrObgFGyxuWht43m1fC NS7/W4AZ/WEpzkR9NfvFLnauIPEEL53hMGQwMOPjdGwZAruSoDzqYntugmD81wvSJwDY 36Yw==
X-Received: by 10.15.23.73 with SMTP id g49mr21715eeu.8.1370295390876; Mon, 03 Jun 2013 14:36:30 -0700 (PDT)
Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id y44sm5813234eel.10.2013.06.03.14.36.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:36:30 -0700 (PDT)
Message-ID: <51AD0C5B.6080508@jitsi.org>
Date: Tue, 04 Jun 2013 00:36:27 +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: Paul Kyzivat <pkyzivat@alum.mit.edu>
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> <51ACD224.8080100@jitsi.org> <51AD07B4.3070702@alum.mit.edu>
In-Reply-To: <51AD07B4.3070702@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlrVApGmtf/rj0PGH49NM/ZyaJ8k9KWHxj+Bt0wDwl0FOZaUslmsDU81smtaAY5OzleZbmU
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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 21:40:27 -0000

On 04.06.13, 00:16, Paul Kyzivat wrote:
> 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.

Emil

>
> 	Thanks,
> 	Paul
>
> 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 <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