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

Christer Holmberg <> Fri, 03 August 2012 18:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05D2321F8DBA for <>; Fri, 3 Aug 2012 11:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.277
X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yPbZUrtDhJcH for <>; Fri, 3 Aug 2012 11:54:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9942321F8D9D for <>; Fri, 3 Aug 2012 11:54:54 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fd66d0000004ad-c2-501c1e7d26c5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 39.D5.01197.D7E1C105; Fri, 3 Aug 2012 20:54:53 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 3 Aug 2012 20:54:53 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>, "" <>
Date: Fri, 03 Aug 2012 20:54:52 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac1xQeMAOq/xcN7sQxWbf/5GiHpQ8gAZgqb4
Message-ID: <>
References: <>, <>
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+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW6tnEyAQct6KYupyx+zWKzYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo3dDPXHDSoGJbfzdLA+Mb1S5GTg4JAROJ C4fXsULYYhIX7q1n62Lk4hASOMUoMfXzAhYIZz6jxOOGmYxdjBwcbAIWEt3/tEEaRAR8JZ49 vs0GYrMIqEj8/DUBzBYWiJdYsW0pM0RNgsSuSWsZIWwjiQV9p8DivALhEt9fnwZbLCQQI3Hk TQ87iM0poCMxZctzsDgj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9B1YtK3Glf zwhRryOxYPcnNghbW2LZwtdQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenl hnqpRZnJxcX5eXrFqZsYgTFycMtv3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFRvGyb9t2HD+t1+n6wOk3MW3Cq5mHPNfePeqvnL9H+XhacxtW+aJrZ5pQ3 D2fyJ6leKloU8LluZruF32Tj6oWF/aonyp6HhnVXmb1+t+7QtMbGMypch9aFVl1evSso7Hdc 7N+tN3I9L/Js1+ta/nqxkuL3HzN2/pp8xSAnUPEKa+feu/ttlIPTlFiKMxINtZiLihMBKSpY 7F8CAAA=
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: Fri, 03 Aug 2012 18:54:57 -0000


> This proposal is interesting.
> IIUC, if answerer supports and accepts the bundle, then everything from
> the other bundled m-lines is ignored. Right?
> If so, then *everything* that would have been specified in each of those
> media sections is ignored, and must be restated after the bundle m-line.
> But isn't one of the points of this allow separate settings for things
> per-m-line? The directionality is one of those things that you mention,
> but there are lots of others. I think we decided there were at least
> three categories:
> - those that are independent for each bundled media sections
> - those that are summed across all the bundled media sections
> - those that are the max across each of the bundled media sections
> - (are there other possibilities?)
> Clearly your proposal can handle those that are summed, and those where
> the max is used. But not those that are independent. (The directionality
> attributes are an example that you mentioned.)
> A potential alternative would be for the answer to reject the bundled
> m-lines other than m=bundle, but then both sides would still honor the
> attributes and other things from the rejected bundled m-lines. But this
> might not be feasible, since I think there is a normative requirement in
> O/A to ignore all the stuff from rejected m-lines.

I am not sure whether there is such requirement, but I guess it depends on how one reads the spec and how you define "ignore" :)

But, it IS an issue that we need to think about, whether we "duplicate" information into the m=bundle line, or whether we
can "reference" information in the other m= lines (even if their ports are set to zero).

In any case I do think that we will need SOME information in the m=bundle line, e.g. information that intermedairies need (bandwidth etc



On 8/1/12 11:56 AM, Jonathan Lennox wrote:
> As I mentioned at the mic, BUNDLE currently generates an implicit combined description of the bundled RTP session, and a lot of the problems and standardization issues we're having relate to the fact that the bundled session's media description is implicit.  Therefore, you need a lot of language specifying when parts of bundled m=lines must be the same, when they must be different, and when they may be independent.  Such specifications would need to be defined for every existing SDP attribute used in offer-answer, and every new SDP attribute going forward.
> The alternative to having an implicit description, I think, would be to have an explicit description.  The basic idea is to have a new m-line representing the bundled session explicitly, defined in a way that a non-bundle-aware endpoint should see it as an unknown type of m-line and reject it.  The BUNDLE grouping semantic then says that you either use all the traditional m-lines, rejecting the bundled one, or you use the one bundled m-line, rejecting all the others.
> As a straw man example, a variant of bundle-negotiation-00's example offer with ICE:
>         v=0
>         o=alice 2890844526 2890844526 IN IP4
>         s=
>         c=IN IP4
>         t=0 0
>         a=group:BUNDLE foo bar baz
>         m=audio 10000 RTP/AVP 0 8 97
>         a=mid:foo
>         b=AS:200
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         a=rtpmap:97 iLBC/8000
>         a=candidate:1 1 UDP 1694498815 10000 typ host
>         m=video 10002 RTP/AVP 31 32
>         a=mid:bar
>         b=AS:1000
>         a=rtpmap:31 H261/90000
>         a=rtpmap:32 MPV/90000
>         a=candidate:1 1 UDP 1694498815 10002 typ host
>         m=bundle 10000 RTP/AVP 0 8 97 31 32
>         a=mid:baz
>         b=AS:1200
>         a=full-rtpmap:0 audio/PCMU/8000
>         a=full-rtpmap:8 audio/PCMA/8000
>         a=full-rtpmap:97 audio/iLBC/8000
>         a=full-rtpmap:31 video/H261/90000
>         a=full-rtpmap:32 video/MPV/90000
>         a=candidate:1 1 UDP 1694498815 10000 typ host
> Points to note:
> * Outside the m=bundle line and its attributes, this is entirely current-standard SDP.
> * The m=bundle is a complete description of an entirely separate m-line; if it's used, the other m-lines in the group are rejected and the information they carry is ignored.
> * We'll need to make sure that we have a syntax for this new m-line (what I've called m=bundle) that existing implementations will reject (with port 0), rather than interpreting as an SDP syntax error.  We'll need input from interop people to know what's safe to do here.
> * The ports and ICE candidates specified in the m=bundle line are entirely up to the whim of the offerer; they may overlap with one of the other m-lines, but don't have to.
> * Because the media type of the payload types isn't given by the m-line, we need new syntax to specify the top-level media type.  I've called this "full-rtpmap", but this is just a strawman.
> * Because there's one list of payload types, the RFC 3264 payload preference order needs a bit of finessing. I'd suggest saying that the preference order should be interpreted independently per media type.
> * There's obviously no way to do a=sendonly/recvonly independently for audio and video; you'd need to do it on the source level, with (if you're doing it in SDP) something like my source-selection draft.
> * There's an obvious syntax to send an offer that means "support BUNDLE, or fail" -- just send the m=bundle line, without the grouped independent lines.  Whether we'd want to allow such an offer is a separate question.
> --
> Jonathan Lennox
> _______________________________________________
> mmusic mailing list

mmusic mailing list