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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 03 June 2013 21:48 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 16EBA11E812D for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1]
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 B2f2f594eJ3q for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:48:18 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id BBDCC11E80F4 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:45:30 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id jnHU1l0050bG4ec5AxlWkS; Mon, 03 Jun 2013 21:45:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id jxlV1l01J3ZTu2S3PxlWjm; Mon, 03 Jun 2013 21:45:30 +0000
Message-ID: <51AD0E78.8050100@alum.mit.edu>
Date: Mon, 03 Jun 2013 17:45:28 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
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> <51AD0C5B.6080508@jitsi.org>
In-Reply-To: <51AD0C5B.6080508@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370295930; bh=vUflZPJP8xjJ1AK1x1wMf/Xvmxx4XC3Ks+EhUtW/mxI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZrLrleRTCXvJUsYcC95Y7gXnmgkTjx5g4/ooH5M6R3mg635g6vuOFrl2OlJOll7Kx DgjhMoOQox0jGc+iRCGkMD71pV5yjhBwIWJczzXcwYlxIvY5i9fHcZfTIgDgQxrnck Y8Aywbj8kd9ubAgZH5VenXK469eYEEbrRETlggxLOLhKjVCKrkdFjxyH1EOc1bekEQ B7cQMfSDzUZ3P2WNlxD0qNGTQyNW9a/K+jGQJboO6cpya3WiHdke1WvF++jVK4TI2u zqdPIcRQ4fzFw5xIqBpTiooVQMlX/L4Py8Vn8RE2qZxKFeY93WQjvnDZjnbmKHzw0J ehH2Jx9gu6cMA==
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:48:33 -0000

On 6/3/13 5:36 PM, Emil Ivov wrote:
> 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.

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.

But that is not Plan A. You can view it as a special case of what I just 
responded to you on another thread (now on mmusic) where one end 
requires that a new media stream be on a different 5-tuple than those 
existing.

	Thanks,
	Paul

> 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
>>>
>>>
>>
>>
>