Re: [rtcweb] No Plan

Emil Ivov <emcho@jitsi.org> Mon, 03 June 2013 21:15 UTC

Return-Path: <emil@sip-communicator.org>
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 F1FB411E80F4 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 OcdD3uCBZcVi for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:14:50 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id A504A11E80F5 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:09:46 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id hr14so3135370wib.3 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 14:09:45 -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=9nAlLtu+EzBRjJGKLi9UXVXgS9ZOLIYAjwKq2W9aD54=; b=A3cDWAAvtHm5YCrhKyVV1+0GY81zRzzs804Ns5/fxq+JmZ1HyddD14dtNhtSy/6Mcm sOPMwdjMfaZkVIwZKZfX12yKSAjBh18FK0wylmw2woRVrROcq6GEXwpYWSgAB6OlpYjT em7dOK7EmVRSCuxplmVPVAxjL6E1t+yYbS54CvzZIgBJj53UK8NyjgyO9Osl7tlurgmi 7TJEXqwCuvhK7vonAc7krIrpLxlBi68BVxS3W8occ1g+RB7epklEzoGMe17B/cFy+Ztx Gikz+AzEVqnpcYmRiFkPSQWt9PjBnSHEZkHugwlQiI3f4Eo5piifTwHthYvry+ISGFaM CLgw==
X-Received: by 10.194.243.129 with SMTP id wy1mr10346838wjc.47.1370293785756; Mon, 03 Jun 2013 14:09:45 -0700 (PDT)
Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id ff10sm26188335wib.10.2013.06.03.14.09.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:09:44 -0700 (PDT)
Message-ID: <51AD0616.5040008@jitsi.org>
Date: Tue, 04 Jun 2013 00:09:42 +0300
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>
In-Reply-To: <51ACFE8A.8030503@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn3khdAkfP/LnoOOTTb2lIElxZztYahNnpr9lblvTqnQi2X3PdrsThyOj4ly8B2YwTug1iw
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] 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:15:01 -0000

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. This is 
why I said: "Indeed, this would require BUNDLE to work."

Is this clearer?

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

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

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

(This might be a good point to move this to mmusic)

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