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

"Mo Zanaty (mzanaty)" <> Thu, 21 March 2013 06:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D733421F8F7B; Wed, 20 Mar 2013 23:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.649
X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_55=1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rgVRoFD3ZlmB; Wed, 20 Mar 2013 23:51:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4A8DE21F8F44; Wed, 20 Mar 2013 23:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20618; q=dns/txt; s=iport; t=1363848675; x=1365058275; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L+O9c9uyk1S7VTVQbPOh55mmEkIUnf17SqFTTWt539s=; b=ZYUhWwpu1IUDduRs/T2F11cSwE7PfM212AzErM4fipg7AdxSyCz1WUgu WWw3Iqb75P+o8KVH/noby+Haw6JZTsLqZY3rCEMH3K6TaI02ACreCn4bB 7i0FzJJiHJsSeVeAqYIcm6kSj/yFoXXaasDQWyAy+NuFAKQKCivtYIOKy g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.84,884,1355097600"; d="scan'208,217"; a="189833620"
Received: from ([]) by with ESMTP; 21 Mar 2013 06:51:14 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r2L6pEfE029796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 06:51:14 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 01:51:14 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] [MMUSIC] Is bundle just a port override?
Thread-Index: Ac4kHg5Y6RAUfNpKQfaYxrqiVMYCTQAjG6gAAAGCK8AADz+6gAAJ0yXg//+IxWj///4R0IACiFsAgABCeCA=
Date: Thu, 21 Mar 2013 06:51:13 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D90F695235xmbrcdx14ciscoc_"
MIME-Version: 1.0
Cc: "" <>, "" <>
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: Thu, 21 Mar 2013 06:51:17 -0000

Hi Justin,

I understand the potential problems with legacy endpoints as described in A.2 of Christer’s draft, not just intermediaries (A.4) which I thought Dale was specifically commenting about. The constraints of legacy peers and intermediaries is obviously important to the overall solution, but orthogonal to how we signal the desired port in a new way (as a single attribute or using the grouping framework).

BTW, has anyone actually observed failures? I ask because I could not get products to fail (when simply offering the same ports) in my (limited) interop lab. SIPit 30 was on my campus last month, I wish I would have tested it there for more data points. I can try at SuperOp next month. Just checking if someone hit a real problem before starting this bundle party.


From: Justin Uberti []
Sent: Thursday, March 21, 2013 1:11 AM
To: Mo Zanaty (mzanaty)
Cc: Dale R. Worley;;
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

The point of the different ports is not just to make intermediaries happy, but to ensure that we're successful when talking to an endpoint who doesn't support BUNDLE. There are a litany of problems that have been identified when the same ports are used on the offerer side and the answerer is BUNDLE-unaware.

On Wed, Mar 20, 2013 at 9:43 PM, Mo Zanaty (mzanaty) <<>> wrote:
Hi Dale,

In your draft (and Richard's), I understand your motivation to answer with port 0 (or 9 or IP 0), to plug the nostrils of intermediaries that sniff ports so they don't smell anything fishy. I won't comment on whether they will react better to nostril-plugging than fishy smells, because I don't know, but that is orthogonal to what I'm describing here.

Your bundle alternatives (and Richard's) also work fine with a simple attribute without complex grouping semantics.

Offer to mux audio and video on the same port:
m=audio 10000 RTP/AVP 0
m=video 10002 RTP/AVP 31
a=port 10000
i=I really want 10000, but lied on the m-line for fear of confusing you. Confused yet?

Answer supports the port override attribute and agrees to mux audio and video:
m=audio 40000 RTP/AVP 0
m=video 0 RTP/AVP 31         <-- Dale's variant to answer with port 0
a=port 40000 audio and video ports are 10000<->40000.
Answer doesn't support the port override attribute, or doesn't want to mux:
m=audio 40000 RTP/AVP 0
m=video 40002 RTP/AVP 31 audio ports are 10000<->40000 and video ports are 10002<->40002.

-----Original Message-----
From: Dale R. Worley [<>]
Sent: Tuesday, March 19, 2013 3:37 PM
To: Mo Zanaty (mzanaty)
Subject: Re: [rtcweb] [MMUSIC] Is bundle just a port override?

> 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

rtcweb mailing list<>