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
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher