Re: [MMUSIC] [rtcweb] No Plan

Paul Kyzivat <> Thu, 06 June 2013 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12D0521F99CA for <>; Thu, 6 Jun 2013 07:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HMqdLckTfe-U for <>; Thu, 6 Jun 2013 07:41:06 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:80]) by (Postfix) with ESMTP id 1CE5721F93E0 for <>; Thu, 6 Jun 2013 07:41:04 -0700 (PDT)
Received: from ([]) by with comcast id kziq1l0051uE5Es582h47l; Thu, 06 Jun 2013 14:41:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id l2h31l01K3ZTu2S3c2h47c; Thu, 06 Jun 2013 14:41:04 +0000
Message-ID: <>
Date: Thu, 06 Jun 2013 10:41:02 -0400
From: Paul Kyzivat <>
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 <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370529664; bh=s1511xQwRAhBOjOlmFeGgkronDls+1dJxJnV6b39ENk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qvQK8mkjoLl369x/ypKFsfhhc+/zMcAefGOLQN2hh1S+r7jMBmdUzKEJPDzrz9vO3 oMsTMD12SFK0cdvExj+/3rc3ZX7BJg3rzPmnnphPKHLJdIkuxcxvuqhdd/wZXNvrZ3 g6WohKHDbcx4K0fZKHoQF4IrcgJsjwLd30LsJMogmG7qZUCOCsrUkSTAKygzHb4v0c 8Q5zZaqUilEBSdTWUjrnlqppwbcSCyrMP54gNM/fNsEyw/voPpqGHN6pcZqARtW1p4 IdC9f+454bKIC05pnYuSnw1X8LcYu2Lz2Ml8MvS3gbrxDVDUiG/aUkQd3uUlQDKAwB 60sqOJ/8sW6sg==
Subject: Re: [MMUSIC] [rtcweb] No Plan
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jun 2013 14:41:11 -0000

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.

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

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

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

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

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


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