Re: [MMUSIC] [rtcweb] No Plan

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 04 June 2013 17:35 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28F421F9C89 for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 10:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.229
X-Spam-Level:
X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 1wxzp0ct8Bhl for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 10:35:34 -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 CBDBE21F9622 for <mmusic@ietf.org>; Tue, 4 Jun 2013 09:07:31 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id kG3Q1l0071vXlb85AG7XPm; Tue, 04 Jun 2013 16:07:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id kG7X1l0023ZTu2S3dG7XFl; Tue, 04 Jun 2013 16:07:31 +0000
Message-ID: <51AE10C2.5010807@alum.mit.edu>
Date: Tue, 04 Jun 2013 12:07:30 -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> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu> <51AD0616.5040008@jitsi.org> <51AD0C53.7030406@alum.mit.edu> <51AD1617.9020501@jitsi.org>
In-Reply-To: <51AD1617.9020501@jitsi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370362051; bh=/bhvWQxUg6osN/yspy69zHQJWEgT9A4Kw9kV0wHDLTw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sQGW9OsxyBO/mkla3P9TiMXQcoO76HB6yx2x1LBNymS/WwHM1Z1d1ExDMvLpWMt6E oeDWK0JGrH+oCSWh+m6nfVLwL61tcyerfr3rC65CIfS1JxRoh4b71hor/msylj5d/n HmM+kRrzi+VCkCEJU3v2Rpk9f5T8zC5dA+Clv8T5Wgl8i7Z9b+hmElumjmkdHynuPM KsS0C5i/1EawZ3Vdr03WS5Mb4fNd/k80kkRIXDDwTPqTh5j5fm4NDLcrKEuTd15lDN IZRPFZUHq82S2Q94Y5Fx7yuufheFHbVm3BmRfNSSTPis7466ju9o3EQX/DfvQcxVLn sc6Gd+qZSey0g==
Cc: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] No Plan
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 17:35:39 -0000

On 6/3/13 6:17 PM, Emil Ivov wrote:

[snip]
>>>> I'm just pointing out that for decomposed endpoints one 5-tuple may not
>>>> be enough. And the need for this might not be known a priori. One side
>>>> may be ready to add another stream for some purpose, and be
>>>> willing/able
>>>> to use private signaling to negotiate that. But the other side may not
>>>> be able to handle that stream on the same 5-tuple. That in turn may
>>>> result in a need to negotiate SDP changes to establish an additional
>>>> 5-tuple that can then be used for that new stream.
>>>
>>> I think I see ... but not completely. Could you please post an SDP offer
>>> with BUNDLE and the corresponding answer?
>>
>> The issue can be discussed without bundle, and without detailing the O/A.
>
> We can certainly try. I am not sure if I am following though. Let's see:
>
>> Assume we have had an O/A already between X and Y, with a single (video)
>> m-line, resulting in a single 5-tuple. Over this we have a single audio
>> RTP stream and mediaStreamtrack.
>>
>> The user of X interacts with the app, indicating a desire to receive
>> another video stream from Y. This causes the app to trigger the JS in Y
>> to set up another mediaStreamTrack. But the camera on Y has a separate
>> IP address. So it is necessary to first set up another video m-line with
>> the new address on Y's end. (X's end can use its single IP address.)
>
> This is the part that I can't quite picture. How can Y's camera be on a
> separate IP, but still appear as a regular device to Y's javascript and
> still generate a regular stream track? All this with a generic browser?

I'm not a browser guy, so maybe I am imagining things that are out of 
scope for webrtc, but maybe not.

At the very least you can have an app that gateways between a browser 
and some non-browser device. So assume that X is a browser and Y is not. 
What does the app tell the browser to do so that the new stream is on a 
different 5-tuple?

> Wouldn't it be much more likely that such a separate camera will be
> controlled by a proprietary interface that is not directly related to
> WebRTC?

Can somebody who knows more about these things comment if this is 
entirely impossible for two devices accessible to the browser to be 
accessible only via distinct IP address/port, or if it might occur for a 
sufficiently sophisticated device?

	Thanks,
	Paul

> If so, then the additional signalling for this camera would obviously
> need to be generated by Y's javascript (i.e. not the browser). That
> additional signalling can then be merged into the one from Y's browser
> by Y's JS or a gateway.
>
> X would indeed need to handle an offer with two video m= lines at that
> point, but that's because they would negotiate different 5-tuples. So
> this is fine.
>
> Another option would be to handle the new camera with an independent
> Offer/Answer that would yield a new PeerConnection. I don't know if that
> works for your case but I thought I'd mention it. In this case any
> additional information required for the synchronization of the two peer
> connections would be exchanged in an app-specific way.
>
> Cheers,
> Emil
>
>
>> Once that is done the new mediaStreamTrack can be established on the new
>> m-line.
>>
>> How does this fit into No Plan?
>>
>>> (This might be a good point to move this to mmusic)
>>
>> Done.
>
> Thanks,
> Emil
>
>>
>>     Thanks,
>>     Paul
>>
>>> Thanks,
>>> Emil
>>>
>>>
>>>>>
>>>>>
>>>>>>
>>>>>>       Thanks,
>>>>>>       Paul
>>>>>>
>>>>>>> If you'd like for that signalling to be in SDP, I
>>>>>>> don't see any problem with it. However it would be best for this
>>>>>>> extra
>>>>>>> layer of SDP signalling to appear at either the application layer
>>>>>>> or in
>>>>>>> a signalling gateway (that is going to be there anyway).
>>>>>>>
>>>>>>> Does this make sense?
>>>>>>>
>>>>>>> Emil
>>>>>>>
>>>>>>>>
>>>>>>>> Further questions:
>>>>>>>>
>>>>>>>> I presume that you expect bandwidth in the SDP to be an aggregate
>>>>>>>> per-m-line, with application specific signaling for bandwidth at
>>>>>>>> the
>>>>>>>> per-RTP-stream level?
>>>>>>>>
>>>>>>>>        Thanks,
>>>>>>>>        Paul
>>>>>>>>
>>>>>>>> On 5/29/13 2:59 PM, Emil Ivov wrote:
>>>>>>>>> Hey all,
>>>>>>>>>
>>>>>>>>> Based on many of the discussions that we've had here, as well as
>>>>>>>>> many
>>>>>>>>> others that we've had offlist, it seemed like a good idea to
>>>>>>>>> investigate
>>>>>>>>> a negotiation alternative that relies on SDP and Offer/Answer
>>>>>>>>> just a
>>>>>>>>> little bit less.
>>>>>>>>>
>>>>>>>>> The following "no plan" draft attempts to present one such
>>>>>>>>> approach:
>>>>>>>>>
>>>>>>>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>>>>>>>
>>>>>>>>> The draft relies on conventional use of SDP O/A but leaves the
>>>>>>>>> intricacies of multi-source scenarios to application-specific
>>>>>>>>> signalling, with potentially a little help from RTP.
>>>>>>>>>
>>>>>>>>> Hopefully, proponents of Plans A and B would find that the
>>>>>>>>> interoperability requirements that concerned them can still be met
>>>>>>>>> with
>>>>>>>>> "no plan". Of course they would have to be addressed by
>>>>>>>>> application-specific signalling and/or signalling gateways.
>>>>>>>>>
>>>>>>>>> Comments are welcome!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Emil
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rtcweb mailing list
>>>>>>>> rtcweb@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>>>> .
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>