Re: [rtcweb] [MMUSIC] Is bundle just a port override? (Dale R. Worley) Tue, 19 March 2013 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC90521F8D85 for <>; Tue, 19 Mar 2013 12:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U3IKR698Wm-0 for <>; Tue, 19 Mar 2013 12:37:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 562B221F8CD9 for <>; Tue, 19 Mar 2013 12:37:37 -0700 (PDT)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r2JJam06021311; Tue, 19 Mar 2013 15:36:50 -0400
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id r2JJalv9764565; Tue, 19 Mar 2013 14:36:47 -0500 (EST)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id r2JJakU4763611; Tue, 19 Mar 2013 15:36:46 -0400 (EDT)
Date: Tue, 19 Mar 2013 15:36:46 -0400
Message-Id: <>
To: "Mo Zanaty (mzanaty)" <>
In-reply-to: <> (
References: <> <> <> <> <>
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Mar 2013 19:37:39 -0000

> From: "Mo Zanaty (mzanaty)" <>
> 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.)
> Regarding the concern about non-use of the discarded RTP ports
> confusing SBCs, see this part of my original message [with
> clarifications], which is what the current bundle draft also
> suggests:
> > Either end can re-offer without lies about ports on the m-line after
> > confirming the peer is not confused by muxing, if they want to avoid
> > confusing intermediaries [that may monitor the unused ports].

It's messier than that, unfortunately.

One requirement is that after negotiation is completed, the negotiated
transport associations (as seen by a legacy intermediary) must match
the actual media flows.

Another requirement is that two media descriptions shouldn't use the
same port (because a lot of legacy SBCs can't handle that).  This
applies to offer/answer updates as well as original offers/answers.

So what we want is a way for a media description to say, "I'm
reporting port zero so SBCs think this MD is rejected, but I'm
actually using port 1234 (which is officially reported in another

There are also situations where the we want to signal perferences as
to which media descriptions share ports with which other media