Re: [MMUSIC] Is bundle just a port override?

Harald Alvestrand <> Thu, 21 March 2013 12:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3433721F872E; Thu, 21 Mar 2013 05:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.842
X-Spam-Status: No, score=-109.842 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U7mYfeiRu08k; Thu, 21 Mar 2013 05:09:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EABD721F8700; Thu, 21 Mar 2013 05:09:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACA4039E1C9; Thu, 21 Mar 2013 13:09:39 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gD3LBMOwSDdM; Thu, 21 Mar 2013 13:09:38 +0100 (CET)
Received: from (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by (Postfix) with ESMTPSA id 4551539E125; Thu, 21 Mar 2013 13:09:38 +0100 (CET)
Message-ID: <>
Date: Thu, 21 Mar 2013 13:09:37 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Mo Zanaty (mzanaty)" <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>
Subject: Re: [MMUSIC] Is bundle just a port override?
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, 21 Mar 2013 12:09:43 -0000

On 03/21/2013 06:59 AM, Mo Zanaty (mzanaty) wrote:
> Hi Harald,
> You're right, both are essentially groupings, and all of our wheels have ugly angles. To me, the ugly angles in bundle are unnecessary indirection by grouping with artificial bindings (mid), and that it pretends to be more than it is. To me, it is just a port override, but with unnecessary indirection. Why not just say the port you want to use directly?
> m=audio 10000 RTP/AVP 0
> m=video 10002 RTP/AVP 31
> a=port 10000
> vs.
> a=group:BUNDLE foo bar
> m=audio 10000 RTP/AVP 0
> a=mid:foo
> m=video 10002 RTP/AVP 31
> a=mid:bar
> Why is the direct approach more complex? Why is ICE any different in either approach?
You don't know the port you'll be using ahead of time with ICE; you have 
to put ICE into all the M-lines in order to be able to negotiate ICE 
when you don't get the bundling.

So in addition to specifying the port on the m= line, you have to uglify 
your solution by stating rules that say "if you accept this alternate 
port, you also have to accept these special rules for ICE", and all the 
other stuff that Christer uncovered and is documented in his draft.

And nothing that looks as the SDP without knowing the special semantics 
of bundle can know that the fact that a=port in those 2 M-lines implies 
special treatment of ICE.

It's a grouping framework. I don't want to create new grouping 
frameworks; the one we have is bad enough.

I think your angles will produce a bumpier ride than mine :-)

> Cheers,
> Mo
> -----Original Message-----
> From: Harald Alvestrand []
> Sent: Tuesday, March 19, 2013 6:20 PM
> To: Mo Zanaty (mzanaty)
> Cc: Emil Ivov;;
> Subject: Re: [MMUSIC] Is bundle just a port override?
> On 03/19/2013 07:43 PM, Mo Zanaty (mzanaty) wrote:
>> Hi Emil,
>> Those drafts use the SDP grouping framework (a=group:BUNDLE/TOGETHER), which I think is unnecessary complexity and ambiguity for something which can be solved in a much simpler and clearer way with a single attribute: a=port <port>. (Or, if we want to warn humans about RTP muxing, then name it a=rtp-mux:<port>, but machines won't care about the name, and their RTP implementations already know how to deal with muxing if they use this attribute, so stronger warnings are unnecessary.)
> To me, what you're describing is a grouping (the ports with the same
> a=rtp-mux:port attribute form a single RTP session), so it seems to me
> that using the grouping framework and using matching a=rtp-mux:port
> attribute have exactly the same level of complexity - but in the case of
> a=rtp-mux:port, you lose the ability to use ICE attributes to negotiate
> the actual ports, addresses and network interfaces actually used - so
> the a=rtp-mux:port mechanism will actually turn out to be *more* complex
> than the grouping framework once you've added all the other features you
> need to take advantage of ICE and so on.
> So - after I've thought about it for a while - I think calling it a
> "port override" is not just misleading, the implementation you're
> suggesting will be more complex than using the grouping framework.
> Why invent square wheels when the pentagonal ones are doing just fine?