Christer Holmberg <christer.holmberg@ericsson.com> Fri, 31 May 2013 10:31 UTC

Return-Path: <prvs=28632c56aa=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 ED11321F92FC for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 03:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.985
X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mibdIhA2DUaP for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 03:30:58 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0021F9433 for <mmusic@ietf.org>; Fri, 31 May 2013 03:30:56 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-84-51a87bdfa21b
Received: from ESESSHC014.ericsson.se (Unknown_Domain []) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1F.16.15700.FDB78A15; Fri, 31 May 2013 12:30:55 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC014.ericsson.se ([]) with mapi id 14.02.0328.009; Fri, 31 May 2013 12:30:55 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: mmusic <mmusic@ietf.org>
Thread-Topic: BUNDLE: SDP Offer Types
Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6Pg==
Date: Fri, 31 May 2013 10:30:54 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37F87C@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C37F87CESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvre796hWBBntemVlMXf6YxYHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3BkNH9+yFewPqZh8YB5jA+Nhzy5GTg4JAROJpbtmMULYYhIX 7q1n62Lk4hASOMwosX/jVCYIZwmjxMJde1m6GDk42AQsJLr/aYM0iAjISOzdtJkZxBYWUJBY 8/YWM0RcVeLKihXsELaexMk5i5lAWlmA4idWGYOYvAK+Ert2cIFUMAKt/X5qDROIzSwgLnHr yXwmiHMEJJbsOc8MYYtKvHz8jxWkVUJAUWJ5vxxEeb5Ex9FzLCA2r4CgxMmZT1gmMArNQjJp FpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG9tzEzJz0csNNjMCQP7jlt+4O xlPnRA4xSnOwKInz6vEuDhQSSE8sSc1OTS1ILYovKs1JLT7EyMTBCSK4pBoYeadkH/zHvZj5 oVL1hWUHV3fZGLxO0OD9/Dg+dPZUHYO0AzfXXBdjkWF6W7qLjdezqysz2FLqC5/TNu2Ekh01 7u5b2bY/M193vbSfs9ONN1vFtkWxNHDlJoXizPYH804uCeb5VZetHWbzyt89sOWtyhSefxeU VlgunmycaRoa9StwybfESc+VWIozEg21mIuKEwHybCj2TAIAAA==
Subject: [MMUSIC] BUNDLE: SDP Offer Types
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: Fri, 31 May 2013 10:31:05 -0000


As we know, BUNDLE currently uses two main "types" of SDP Offers: one where each m- line in the BUNDLE group has a different port number value, and one where each m- line has the same port value.

Often we refer to these as "the first offer" resp. "the second offer".

Now, this works fine when we talk about the session establishment, but as we know a session can contain multiple additional offers, and with BUNDLE those can be of either type.

So, my question is whether we should come up with some better wording.

I'll throw the ball out with suggesting the following ones:

-          Bundle restart offer (different port value, currently referred to as "first offer")

The reason I use "restart" wording is because this is used, no matter whether in the beginning of the session or mid-session, to (re-)negotiate the usage of BUNDLE, and the bundle address information selection.

-          Bundle sync offer (identical port value, currently referred to as "second offer")

The reason I used "sync" wording is because this is used to ensure that intermediaries have correct address information for each m- line.

Keep in mind that we may even need to split the sync offer into more sub types, when we get into the details of adding new m- lines etc, but I'd like to agree a base to start from :)