[MMUSIC] BUNDLE: Updated offer procedures

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 28 May 2013 07:58 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CFACB21F925A for <mmusic@ietfa.amsl.com>; Tue, 28 May 2013 00:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.848
X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jhGyTnFWZ+xV for <mmusic@ietfa.amsl.com>; Tue, 28 May 2013 00:58:31 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 5386121F91BF for <mmusic@ietf.org>; Tue, 28 May 2013 00:58:30 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fe36d000007102-76-51a463a56491
Received: from ESESSHC011.ericsson.se (Unknown_Domain []) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BD.93.28930.5A364A15; Tue, 28 May 2013 09:58:29 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC011.ericsson.se ([]) with mapi id 14.02.0328.009; Tue, 28 May 2013 09:58:29 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE: Updated offer procedures
Thread-Index: Ac5beKfpSruus8OIRHSvbTVCpmVX7Q==
Date: Tue, 28 May 2013 07:58:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37A880@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre7S5CWBBscvy1tMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGdduXWUuuMBTsWfxRuYGxhecXYwcHBICJhItvyS7GDmBTDGJ C/fWs3UxcnEICRxmlLj89QA7SEJIYAmjxIp13CD1bAIWEt3/tEHCIgLqEl/39jCD2MICmhLf Tl9hh4jrSWzcfoQVpBzE/rOuFCTMIqAqMf3dIyYQm1fAV+L78ftgNiPQ2u+n1oDZzALiEree zGeCOEdAYsme88wQtqjEy8f/WCEuVpRY3i8HUa4jsWD3JzYIW1ti2cLXzBDjBSVOznzCMoFR eBaSqbOQtMxC0jILScsCRpZVjOy5iZk56eWGmxiB4Xtwy2/dHYynzokcYpTmYFES59XjXRwo JJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVF9dY/y1yUrn5/7GeiyrCI867pzmeJrzaobbxLC +bdP/WnReWpj7rvO9OdzW9f8m+jBXH2O53mrenjxjnm2HQxbPtrsuJzkWVC0XaXh1OfgBS+O 7n1m8UBOcvEKrmsTtW5v6F/rXslvNyMxR23lZ0mxJXxRW5b3/p7XI372vLtyvMIZ+Qk72HSV WIozEg21mIuKEwEX/hXILQIAAA==
Subject: [MMUSIC] BUNDLE: Updated offer procedures
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2013 07:58:38 -0000


There has been some discussions about updated bundle offers, especially in cases where a new m- line is added to a bundle group, or when a port-zero-m-line within a bundle group is "taken back to use". In this e-mail, I refer to both cases as "adding a new m- line".

When the updated offer is sent, the offerer has two choices:

1)	The port value of the new m- line is identical to the port values of the other m- lines in the bundle:

This should be rather straight forward. According to answer restriction #4, the answerer can either accept the new m- line within the bundle group, or reject the m- line by setting the port to zero.

2)	The port value of the new m- line is NOT identical to the port values of the other m- lines in the bundle:

In this case, the answer has the possibility to remove the m- line from the bundle group, as it has a individual port number in the offer.

Now, there are two "sub cases":

2a)	The new m- line(s) have individual port numbers, but the old m- lines have the previously negotiated single bundle port value

I guess this case is the one we need to focus most on.

In my opinion, if the answerer accepts the new m- line, it must use the previously negotiated bundle port. IF the offerer (or answerer) wants to re-negotiate the bundle port, it must act according to 2b (see below).

2b)	The new m- line(s), AND, the old ones, have individual port numbers

In my opinion, this is a "bundle restart", where the port (and, then bundle in general) is re-negotiated.