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

Christer Holmberg <> Thu, 20 September 2012 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16AF521F86E2 for <>; Thu, 20 Sep 2012 12:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.831
X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 0Fp95yyrz11O for <>; Thu, 20 Sep 2012 12:32:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B635B21F86A2 for <>; Thu, 20 Sep 2012 12:32:10 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-8e-505b6f391e3c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 89.35.17130.93F6B505; Thu, 20 Sep 2012 21:32:09 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 20 Sep 2012 21:32:09 +0200
From: Christer Holmberg <>
To: "Ejzak, Richard P (Richard)" <>, "" <>
Date: Thu, 20 Sep 2012 21:32:08 +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+Jvra5lfnSAwZfnOhZTlz9msehtCHdg 8mh9tpfVY8mSn0wBTFFcNimpOZllqUX6dglcGX8/dDIVvBWsOHXnGlsD42q+LkZODgkBE4mW HT3sELaYxIV769m6GLk4hAROMUrs6pwE5SxglLi7v4u1i5GDg03AQqL7nzZIg4hAlsTWU/0s IDaLgKpEw6v5YIOEBeIlVmxbygxRkyCxa9JaRgi7iVHi+xUNEJtXIFyi5dt9Joj5G7glJjeC LOPg4BSIlZj0ihOkhhHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1gh6kUl7rSv Z4So15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG4dzEzJz0 cnO91KLM5OLi/Dy94tRNjMAIObjlt8EOxk33xQ4xSnOwKInz6qnu9xcSSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXAKL87VfFvy9IX7y7r8ZzerHrBPiLo180vMVkqXt23y7Zerz6l6H/gH1/q FJub/Elrlxc/4ptlImRhVmy+NZJbWGX+8mMJBjMWqa/hTWqM+MroeZD781e1Wds3eBvt3DEn M1x9iUTPy+qFf6u1Hsz7cd/xY0RcaSaPD5933bmeCv7c7LAyi98PlViKMxINtZiLihMBrwTm 714CAAA=
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 19:32:12 -0000


>>> 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.
> To specify two types of audio flows with very different characteristics I would normally have separate media lines with separate codec lists and attributes.  One may require DTMF and the other silence suppression in addition to the selected (but different) 
> codecs.  We need to keep this characteristic.  We also need a way of specifying bandwidth per (old) media line, which is already supported using separate media lines but requires that something new be defined for m=bundle.  What about RTCP 
> characteristics?  We certainly want to specify them per (old) media line.
> I understand that this can be done with m=bundle, but it requires new syntax.  Why bother if we have something that can work?

I am not sure it requires new syntax, if you e.g. can use the ssrc attribute in order to map attributes to specific flows.

>> 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.
> It would seem to be attractive to support negotiation of bundle with the first offer/answer transaction else it will be delayed. 
> And some networks may not need a 2nd offer/answer if the first one successfully negotiates one of the options.

Only if you can assume that there are not intermediaries in those network - AND that there won't be additional offer/answers for other reasons (you earlier said that there in many cases WILL be additional offer/answers...).

I still think it would be wrong to reject the m=bundle proposal based on badly implemented endpoints. In that case one could claim that endpoints will "choke" if they receive SDPs with RTCWEB datachannels, CLUE channels, whatever channels...