Re: [rtcweb] No Plan

Emil Ivov <> Mon, 03 June 2013 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1FB411E80F4 for <>; Mon, 3 Jun 2013 14:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OcdD3uCBZcVi for <>; Mon, 3 Jun 2013 14:14:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) by (Postfix) with ESMTP id A504A11E80F5 for <>; Mon, 3 Jun 2013 14:09:46 -0700 (PDT)
Received: by with SMTP id hr14so3135370wib.3 for <>; Mon, 03 Jun 2013 14:09:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id wy1mr10346838wjc.47.1370293785756; Mon, 03 Jun 2013 14:09:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ff10sm26188335wib.10.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:09:44 -0700 (PDT)
Message-ID: <>
Date: Tue, 04 Jun 2013 00:09:42 +0300
From: Emil Ivov <>
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 <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn3khdAkfP/LnoOOTTb2lIElxZztYahNnpr9lblvTqnQi2X3PdrsThyOj4ly8B2YwTug1iw
Subject: Re: [rtcweb] No Plan
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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