Re: [MMUSIC] Bundle offer with different ports - where to expect media?

Paul Kyzivat <> Wed, 22 May 2013 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DF4C21F915C for <>; Wed, 22 May 2013 06:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.308
X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PRvruxW8vIqT for <>; Wed, 22 May 2013 06:55:38 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:80]) by (Postfix) with ESMTP id 689B921F91A0 for <>; Wed, 22 May 2013 06:55:37 -0700 (PDT)
Received: from ([]) by with comcast id f0Ll1l0081uE5Es581vdey; Wed, 22 May 2013 13:55:37 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id f1vc1l01U3ZTu2S3c1vco3; Wed, 22 May 2013 13:55:37 +0000
Message-ID: <>
Date: Wed, 22 May 2013 09:55:36 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Justin Uberti <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1369230937; bh=VTmffE+Snu7oul4Ruj278hYHqkhJMXpET5F8R17P1M8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F32Hvh0DI9xFq+StnnuR8GDCLRbpkKuSaO+ku+iiBrxmnycB67mpdkrWHJB/0bIfX VnXmHlHLm3WBbXJPznsrvETJUKwS9Rnn/6tl22O6bsQ0RxarPCLbCFNSF2FI+fdyFa XbrlBXd9TxW/VuXq989oJpuBACm98FvTGx37FmW5V24+cpN4YDP5w4ZOntd0Eo8jji jwQ0Oozz8wmRpPQT0mx+/et4iitpqPlKrindz1hQbJLqimmkhW5u73srnJFG/hMP0z wLxDcbqWF4alhqAyp8cHcvFE4d/l4y5bsjyuGi/7Hk0ChWXy91i3SWbgr9j+PqIC8v LuhR73Kn+kYUA==
Cc: mmusic <>, Christer Holmberg <>
Subject: Re: [MMUSIC] Bundle offer with different ports - where to expect media?
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: Wed, 22 May 2013 13:55:44 -0000

On 5/22/13 1:00 AM, Justin Uberti wrote:

> Taking into account Emil's suggestion as well, this leads to this
> restatement of the rules:
> 1.1) An offerer must be prepared to receive unbundled traffic on the
> offered ports, as if talking to a legacy endpoint.
> 1.2) An offerer must be prepared to receive bundled traffic on any port,
> except the port associated with the last m= line.
> 2) Once the answer is received, the decision on bundled/unbundled and
> which ports to use is finalized.
> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in
> the bundle.
> 2.2) Unused ports can be discarded at this point.
> 3.1) m= lines offered with distinct ports may be omitted from the bundle
> answer, in line with RFC 5888.
> 3.2) m= lines offered with the same port may not be omitted from the
> bundle answer, since there is no unbundled port from them to fall back to.
> 3.3) m= lines that are rejected are omitted from the bundle answer, per
> RFC 5888.
> Quick check on 2.1: are we using the m= line that appears first in the
> SDP, or the m= line that appears first in the a=group:BUNDLE?

IMO it would be best to use the lexically first m-line that has a 
non-zero port and that appears in the bundle group of the answer.

Alternately, it *could* be the m-line with non-zero port that appears 
first in the bundle group of the answer. But if so, the exception in 1.2 
would also need to be correspondingly adjusted.

AFAICT the only reason to mention that exception in 1.2 is that might 
provide an opportunity for optimization, by setting up the port with 
simpler code that doesn't support bundling. I don't see a requirement in 
5888 that the bundle group in the answer be ordered the same way as in 
the offer. So the one m-line guaranteed not to receive bundled traffic 
would then not be predictable at the time of the offer, so could not be 
exploited. This problem doesn't exist if the lexical ordering of m-lines 
is used.