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

Paul Kyzivat <> Fri, 03 August 2012 06:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 673D621E8041 for <>; Thu, 2 Aug 2012 23:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.566
X-Spam-Status: No, score=0.566 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1N03nHSjwBBi for <>; Thu, 2 Aug 2012 23:33:18 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id 4C52821E8039 for <>; Thu, 2 Aug 2012 23:33:10 -0700 (PDT)
Received: from ([]) by with comcast id i6XY1j0020QuhwU516ZC1k; Fri, 03 Aug 2012 06:33:12 +0000
Received: from ([IPv6:2001:df8:0:64:19d6:c06f:f140:d490]) by with comcast id i6Yu1j0093NDGqc3N6YvJw; Fri, 03 Aug 2012 06:32:58 +0000
Message-ID: <>
Date: Thu, 02 Aug 2012 23:33:04 -0700
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 06:33:20 -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.

Another possibility: your proposal is starting to smell a bit like 
cap-neg. Maybe we could make cap-neg serve for this.


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