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

Harald Alvestrand <> Tue, 19 March 2013 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70F2621F8CF5; Tue, 19 Mar 2013 15:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.699
X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AVJSdYUQ3BAI; Tue, 19 Mar 2013 15:19:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8EB4B21F8CEC; Tue, 19 Mar 2013 15:19:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26CC039E1EE; Tue, 19 Mar 2013 23:19:57 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eNosivuv1Tj8; Tue, 19 Mar 2013 23:19:56 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTPSA id 1B2B139E0A7; Tue, 19 Mar 2013 23:19:56 +0100 (CET)
Message-ID: <>
Date: Tue, 19 Mar 2013 23:19:54 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
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: Tue, 19 Mar 2013 22:20:00 -0000

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?