Re: [MMUSIC] [rtcweb] No Plan

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 03 June 2013 21:40 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 4AF2711E810D for <mmusic@ietfa.amsl.com>; Mon, 3 Jun 2013 14:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Level:
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, 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 WxpByWjFSu1Q for <mmusic@ietfa.amsl.com>; Mon, 3 Jun 2013 14:39:57 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B011E810A for <mmusic@ietf.org>; Mon, 3 Jun 2013 14:36:21 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id jn0g1l0050SCNGk56xcMbC; Mon, 03 Jun 2013 21:36:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id jxcL1l00d3ZTu2S3VxcLfe; Mon, 03 Jun 2013 21:36:21 +0000
Message-ID: <51AD0C53.7030406@alum.mit.edu>
Date: Mon, 03 Jun 2013 17:36:19 -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>
In-Reply-To: <51AD0616.5040008@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=1370295381; bh=mNLSg+33yMYcHHRC4F01N2JzTHm2a/TDVgHXD8qyGLw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GVUw8VNoOjMqxOhDIWttfLUmAE1ITrhAwXzjdLSBladysuxO0WvGsqZyxGUjj2F4s 3I4yhRvRuaYzYx8W3JYahMtcQzqCoKp7HdBgvfxTbTnQpql5vB13GMVNqNa4IPaEwL aG91y9zZj5bHOjgoEjH2aoRahkGtidJ+V4aUQotug82NKM09zbUJdhtzfXmWY0OsAz RpDg97n/9FuZ++9D7wkOEwjwMeDVfGkv7SVNDoDu9wf281KAQNjBNUeTLee7RNycmT 9UdzOf2Hgy852AtWeTirjmQywX+QJDvvsr/4dJT/yyOVnFfO9yslgFsV0b/3dHYDWq H0Q+Kox0DJaXg==
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: Mon, 03 Jun 2013 21:40:12 -0000

On 6/3/13 5:09 PM, Emil Ivov wrote:
> Hey Paul,
>
> On 03.06.13, 23:37, Paul Kyzivat wrote:
>> On 6/1/13 1:40 AM, Emil Ivov wrote:
>>>
>>>
>>> On 31.05.13, 22:11, Paul Kyzivat wrote:
>>>> On 5/31/13 6:51 AM, Emil Ivov wrote:
>>>>> Hey Paul,
>>>>>
>>>>> On 29.05.13, 22:57, Paul Kyzivat wrote:
>>>>>> Emil,
>>>>>>
>>>>>> I'm going to reserve judgment on this pending further discussion.
>>>>>> I think this *might* work for CLUE, but I want to be certain.
>>>>>
>>>>> Sure!
>>>>>
>>>>>> I'm concerned with decomposed endpoints that can't manage all the
>>>>>> streams on the same address/port. They will need multiple independent
>>>>>> m-lines and/or bundle groups.
>>>>>
>>>>> This is obviously open for debate but the general idea of No Plan is
>>>>> that: Offer/Answer is used for configuring media and RTP stacks and
>>>>> additional signalling is not the browser's concern.
>>>>>
>>>>> Having extra m= lines, particularly when using BUNDLE, is in many ways
>>>>> just extra signalling.
>>>>
>>>> You may be able to argue that adding extra m-lines into an existing
>>>> bundle is "just extra signaling". But introducing an additional 5-tuple
>>>> is more substantial. It requires configuring a new RTP stack and media.
>>>
>>> Indeed, this would require BUNDLE to work.
>>
>> I don't understand what that means - what point you are trying to make.
>
> Sorry about this. What I was trying to say was: yes, you are right,
> introducing a new 5-tuple is more substantial. Therefore adding a new m=
> line to an SDP is a lot simpler if it didn't also imply adding a new
> 5-tuple. This would only be possible when m= lines are bundled.

No. The problem arises without bundle. It gets more complex in 
combination with bundle.

> This is
> why I said: "Indeed, this would require BUNDLE to work."
>
> Is this clearer?

Maybe not. Still some disconnect here.

>> You seem to have some criterion for what requires sdp and what does not.
>> And AFAIK you are already assuming bundle works - you are simply using
>> it less.
>
> No, not really. The assumption is only necessary when trying to talk to
> Plan A devices and you want to have new m= lines added en route.

I thought you were assuming bundle what there to combine audio and video 
on a single 5-tuple. I don't think this need have anything to do with 
Plan A.

> No such assumption is necessary, for example, when talking to legacy SIP
> phones that will only show one video and one audio stream.

Of course, in such a degenerate case where there is only one m-line for 
each media type, and only one stream per m-line.

>> As best I can tell, you acknowledge that you need SDP to:
>> - negotiate a 5-tuple over which media will flow
>> - specify which types of media can be carried and the codec info
>>     they may use.
>
> Yes.
>
>> 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.

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

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