Re: [rtcweb] No Plan

Paul Kyzivat <> Wed, 29 May 2013 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12EBE21F8F27 for <>; Wed, 29 May 2013 12:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.208
X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=0.229, 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 65mt+8teZc6J for <>; Wed, 29 May 2013 12:57:47 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:56]) by (Postfix) with ESMTP id 3515821F8F28 for <>; Wed, 29 May 2013 12:57:46 -0700 (PDT)
Received: from ([]) by with comcast id huxY1l0091wpRvQ56vxmNE; Wed, 29 May 2013 19:57:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id hvxm1l00K3ZTu2S3evxmMw; Wed, 29 May 2013 19:57:46 +0000
Message-ID: <>
Date: Wed, 29 May 2013 15:57:44 -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
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1369857466; bh=VrTekUqvCXC/lz8uQGEZzE0LiACmXVqHfpJbIkVWDLY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FrjRX9OA1ilyGg4BVXgqkv5yz0+Dl/BXd0qDAt4xQbCqcQxD1ta79d3pECFy6jVDg 0WE6p9WGfT3gHwEW7pfiwujcxa+ofK1L2cjSHNCotbpHlV5cmPrYsDJZ/ANxYzGEvt vBepH2sPKY+hjzPj4d5lyIiTswD5XYtkYrpX4OoqzJSjec1oIh8F2kbsulBf475PGE WSNrDKfVSEBdwa398eFXJPqxB3qAaWJb7uOPZlAo8m+/o9IkDHyAeke0DGmlv6jXIN fXvSeHUi84ehvr+beu4pu9enr0jHH0lvCnbTV975G/cOq1VsXEhVvybHEvLrmP2+ZE kku9i5s3N4b5w==
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: Wed, 29 May 2013 19:57:52 -0000


I'm going to reserve judgment on this pending further discussion.
I think this *might* work for CLUE, but I want to be certain.

The following statements (culled from various places in the text) leave 
me confused about your intent:

    This is exactly what the use of Offer/Answer discussed here strives
    to achieve.  Audio/Video offers originating from WebRTC endpoints
    will always have a maximum of one audio and one video m= line.  It
    will be up to applications to determine exactly how many streams they
    can afford to send once such a session has been established.  The
    exact mechanism to do this is outside the scope of this document (or
    WebRTC in general).

    For the sake of interoperability this specification strongly advises
    against the use of multiple m= lines for a single media type.  Not
    only would such use be meaningless to a large number of legacy
    endpoints but it is also likely to be mishandled by many of them and
    to cause unexpected behaviour.

    ...  Whatever the reason, offerers that find
    they need more than the available payload type numbers, will simply
    need to either use a second bundle group or not use BUNDLE at all
    (which in the case of a single audio and a single video m= line
    amounts to roughly the same thing).  ...

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.

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?


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