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

"Cullen Jennings (fluffy)" <> Thu, 23 May 2013 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4436F11E80E9 for <>; Thu, 23 May 2013 06:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.382
X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vRvH7zornJws for <>; Thu, 23 May 2013 06:42:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9428321F9501 for <>; Thu, 23 May 2013 06:42:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1719; q=dns/txt; s=iport; t=1369316539; x=1370526139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oqTyaEwIsS0EYXeDXjX79KHSHeN9Al/5435ddsHSixc=; b=DpWTFQECviI6iD99gOpv9CtJYnGGSiCxrUCaGGRb9SfTodDGYayCsHPU 0ET9cFnujYZZH5SxS2rpuBt8IYfRcq1uEcHP10cyUkxBUErO8c9AREYW7 htS3ID4LJzABe7gQuI0opS9PHfo/dXBnLwN6ltOdvMMa3uuTndqX2MxuH M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFABccnlGtJXG8/2dsb2JhbABagwjCW4EKFnSCIwEBAQMBOj8FCwIBCA4UFBAyJQIEDgUIh38GulmNW4EPAjEHgnNhA6h4gw+BcTU
X-IronPort-AV: E=Sophos;i="4.87,728,1363132800"; d="scan'208";a="211144608"
Received: from ([]) by with ESMTP; 23 May 2013 13:42:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4NDgJrM031490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 13:42:19 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 23 May 2013 08:42:18 -0500
From: "Cullen Jennings (fluffy)" <>
To: Justin Uberti <>
Thread-Topic: [MMUSIC] Bundle offer with different ports - where to expect media?
Thread-Index: AQHOV7tXnw9Y3/7qwkiw+0gqKiqo3A==
Date: Thu, 23 May 2013 13:41:55 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic <>, Paul Kyzivat <>, 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: Thu, 23 May 2013 13:42:25 -0000

On May 21, 2013, at 11:00 PM, Justin Uberti <> wrote:

> 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.

I'm fine with this but would be just as happy without the "except last one"

> 2) Once the answer is received, the decision on bundled/unbundled and which ports to use is finalized.

Yes, as long as we keen final answer. For provisional answer you need to not free the resources. Yes, I expect to get emails from folks telling me that provisioning and final aren't defined but you know what I mean and this is the clearest way to say it for this email. 

> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in the bundle.

Again, we could go this way or the using the group syntax to do 

> 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.

yes, I would change "bundle answer" to "bundle group in the answer" 
> 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.

uh, no, not on aboard with this part. As we have discussed many times, having multiple m line in the original offer with the same port won't work. I think EKR's proposal of allowing m-lines with 0 port in offer will work well. 

> 3.3) m= lines that are rejected are omitted from the bundle answer, per RFC 5888.