Re: [MMUSIC] [rtcweb] No Plan

Emil Ivov <emcho@jitsi.org> Thu, 06 June 2013 15:30 UTC

Return-Path: <emil@sip-communicator.org>
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 F1B0621F999E for <mmusic@ietfa.amsl.com>; Thu, 6 Jun 2013 08:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 7DOm9DKrDsFT for <mmusic@ietfa.amsl.com>; Thu, 6 Jun 2013 08:30:40 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6721F997A for <mmusic@ietf.org>; Thu, 6 Jun 2013 08:30:39 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id p58so2111812wes.26 for <mmusic@ietf.org>; Thu, 06 Jun 2013 08:30:38 -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=YeGAD1cKzM6ustrZmD70mJpm2bzV2kRiZwc1c2LGg+w=; b=S93tR7qu9ESoqsWsPK4goWZWOmmmPy1+7EYlQTDr7xvKfVh5RyS96DldiCL2ymnQyS RNPo4XRquGM+zABIdQuuz7hSUCEnitG94Ku/Gm3dn52CfhbYvr3tmy/nAPJETx7YvKtS 1xtj7lwfY4wfCSsUUhbYcs7bbNIa9XsGwg8biSqVgGq0DzKR4ixP39qbM0DhLcKbYza1 C5MNHWEXPpuqoiRV0NENpAUHwpFmKD2G17AjjyaBN05zguCU9cFP0C5vQHJ6rnya92Hn Xnk+60BQB7HUQGYpsZ+B+DUEcmIcblhODelyvuSVERJsYz3BXZSxtZJglIa7amLB9+oq I29g==
X-Received: by 10.180.88.231 with SMTP id bj7mr10516684wib.5.1370532638592; Thu, 06 Jun 2013 08:30:38 -0700 (PDT)
Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:e0d6:b52f:9f43:4c3f]) by mx.google.com with ESMTPSA id m3sm16525700wij.5.2013.06.06.08.30.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 08:30:37 -0700 (PDT)
Message-ID: <51B0AB1C.9050606@jitsi.org>
Date: Thu, 06 Jun 2013 17:30:36 +0200
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> <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> <51AE10C2.5010807@alum.mit.edu> <51AF6789.40500@jitsi.org> <51B09F7E.7040709@alum.mit.edu>
In-Reply-To: <51B09F7E.7040709@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn4aYIQ6peUNWG3L8m3aPdMu8XD1K1aJDx77kKPB2edlZAnOV88KT6iGWT9Ylrbhvexq3T6
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: Thu, 06 Jun 2013 15:30:44 -0000

Hey Paul,

On 06.06.13, 16:41, Paul Kyzivat wrote:
> Hi Emil - more inline.
>
> On 6/5/13 12:30 PM, Emil Ivov wrote:
>> Hey Paul,
>>
>> On 04.06.13, 18:07, Paul Kyzivat wrote:
>>> 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.
>>
>> Well I suppose a browser could always support a decoupled device if it
>> were made available as local through some driver. Something like a
>> virtual local device. In that case however, this driver would still have
>> to bring the media to the local host so that it can be placed within a
>> track, a stream and a peer connection. At this point it wouldn't matter
>> to WebRTC that the device is actually decoupled, would it?
>>
>> There is still the other option where this device is controlled by
>> proprietary JS and for this you'd need to have your own signalling and
>> your own control interfaces.
>>
>>> At the very least you can have an app that gateways between a browser
>>> and some non-browser device.
>>
>> Let me make sure I understand this. This gateway app, is it running on
>> X, is it on a box between X and Y, or is it a controlling entity of the
>> decoupled Y?
>
> Consider it to be a web server coupled to a sip GW. So in the webrtc
> "triangle" view, X is a browser, Y is a SIP device, and the GW is the
> web server driving the broswer. For the moment lets assume that Y
> supports ICE, and bundle, and DTLS/SRTP, so that the GW need only be a
> signaling gw, not a media gw.

OK.

>>> 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?
>>
>> Without knowing the specifics of your scenario I'd say that you have the
>> following options:
>>
>> 1) Y relays RTP from its decoupled camera toward X. In this case X is
>> getting everything on the same 5-tuple, so no extra m= lines are
>> necessary. (You'd have a similar situation in the case above where the
>> camera is somehow presented as a virtual local device on Y)
>
> (1) doesn't fit what I'm concerned with.
>
>> 2) Y just wants to handle signalling and it would like that video from
>> the decoupled camera reaches X directly from there. Y also wants to have
>> everything handled within the same Offer/Answer dialog. In this case:
>> 2.1) When Y calls X, it would add a second video m= line in a second
>> bundle (or with no bundle at all) when sending its offer to X
>
> This is more what I had in mind.
> So at least you are ok with two separate video m-lines on different
> 5-tuples in this case, where it is initiated from the sip device.
> It wasn't evident to me if this fit into your model.

OK, I'll make sure it's clarified. The basic idea of No Plan is to use 
SDP for setting up transport channels and codec chains. The SDP way of 
setting up two transport channels is by having 2 m= lines so this has to 
be and *is* OK with No Plan.

>> 2.2) When X calls Y with a single lined offer, Y would also answer with
>> a single m= line and would then re-Offer with two lines.
>
> Lets consider a more complex variant of this scenario:
>
> - the initial o/a is just for audio. That gets set up in obvious way.
>     There is only an audio m-line. (Maybe in a degenerate bundle,
>     maybe not.) I guess there is no data channel, because the gw doesn't
>     expect sip devices to support one.

OK

> - then X (or the app in the gw driving X) decides to add video.
>     So it creates second offer, including a video m-line bundled with
>     the audio m-line.

OK.

> - that offer goes to Y. But Y can't handle the audio and video as
>     a bundle. In this case it can simply refuse the bundle while
>     accepting the video unbundled.

Yes, this is OK.

Obviously, if the offer originated at the GW (and not X) then the 
session update has to reach X at some point because we are adding a new 
m= line.

> If that is ok with No Plan then I think I am ok with it.

Great!

Emil
>
> 	Thanks,
> 	Paul
>
>> In both 2.1 and 2.2 the browser on X would see two independent,
>> unbundled streams and handle them appropriately.
>>
>> Is any of the above close to what you have in mind? Or is it completely
>> off?
>>
>> Emil
>>>
>>>> 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
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> .
>>>
>>
>
>

-- 
https://jitsi.org