Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

Christer Holmberg <> Thu, 20 September 2012 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94ED921F872E for <>; Thu, 20 Sep 2012 10:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.837
X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3KijVHfoxpNu for <>; Thu, 20 Sep 2012 10:14:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9638021F872A for <>; Thu, 20 Sep 2012 10:14:32 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-20-505b4ef72a3c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A9.E9.17130.7FE4B505; Thu, 20 Sep 2012 19:14:31 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 20 Sep 2012 19:14:31 +0200
From: Christer Holmberg <>
To: "Ejzak, Richard P (Richard)" <>, "" <>
Date: Thu, 20 Sep 2012 19:14:30 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Message-ID: <>
References: <> <> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl> <> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <> <>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl> <> <>, <> <>, <> <>, <> <>, <> <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre53v+gAg/dN0hZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGe173zMXfOer2D71O3sD4xfuLkZODgkBE4mZ Wy+zQNhiEhfurWfrYuTiEBI4xSjx/vEmJpCEkMACRok/Bzm7GDk42AQsJLr/aYOERQSyJLae 6gfrZRFQlfj5egYbiC0sEC+xYttSZoiaBIldk9YyQthlEjvXdIHZvALhErMb5jFD7JrIJdH/ by7YLk6BWImbnYtYQWxGoIO+n1oDFmcWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/gdVLypxp309 I0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjEK5yZm5qSX m+ulFmUmFxfn5+kVp25iBEbIwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxR aU5q8SFGJg5OqQZGhjb17PWX2JPybJmmWBTrvM6cmKBt1SR/40b24s97OgX1RH6c7yuwXXPx n7Dtg9K/0S/MJvYLX7C0577gq+wwYYmhzAceoyc1ccIHWlKkpy7ZVVe5O2yF4ss9N6w3V2jv q+48ti9N9EeWRd0UrvQJgbz3t53eX533IdFmgo1Hl6f15mA984VKLMUZiYZazEXFiQAgwZ4/ XgIAAA==
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
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, 20 Sep 2012 17:14:33 -0000


>> And how is the m=bundle mechanism not going to be handled correctly by
>> endpoints? An endpoint that doesn't support it would reject it, and an
>> endpoint that supports it can accept it.
> This is true, although Cullen has the not unreasonable concern that some endpoints may choke on something this far removed from normal syntax.

I am not sure what "normal syntax" means. The receiver sees an m- line media type that it doesn't support, so I am not sure whether it's even going to look deeper into it.

But, IF the endpoint "chokes", the offerer can send a new offer, without bundle. I don't see why we should specify our mechanism based on how badly implemented endpoints will act...

> m=bundle requires significant extensions to the syntax and also a near doubling in the size of the SDP.  It is harder to specify allowed 
> combinations of codecs and other options that are normally associated with a single m line. 

Please give an example.

> I think we should avoid having duplicate syntax to express all these things that can already be represented in SDP.

We DID have a discussion about whether it should be possible, inside the m=bundle line, to "reference" information existing in the audio/video/etc m- lines, in order to avoid duplication.

> The only issue identified with the original approach is that some endpoints may choke on using the same port for multiple media lines.  Why don't we focus on the simplest fix for that one identified problem?

You have said that we need a second offer/answer, with the same port numbers, in order to handle intermediaries. I don't understand why the first offer could not be without bundle, and the second offer (once you know that the remove endpoint supports bundle) according to the current mechanism, with the same port numbers.