Re: [MMUSIC] BUNDLE: SDP Offer Types

Christer Holmberg <> Wed, 05 June 2013 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 414E521F9C15 for <>; Wed, 5 Jun 2013 09:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.69
X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U9gSgGniHfhR for <>; Wed, 5 Jun 2013 09:53:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 29E0D21F9C0C for <>; Wed, 5 Jun 2013 09:53:10 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-e5-51af6cf5225f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FF.46.09795.5FC6FA15; Wed, 5 Jun 2013 18:53:09 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Wed, 5 Jun 2013 18:53:09 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Thread-Topic: [MMUSIC] BUNDLE: SDP Offer Types
Thread-Index: Ac5d6erED7N11c9tSI+QddHtfsU6PgADod2AAAywgioAlxfJgAAbOWHAAA6xPoAAII/SwAAR5KgAAAT9WbA=
Date: Wed, 5 Jun 2013 16:53:08 +0000
Message-ID: <>
References: <>, <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvre7XnPWBBitWmFlMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG08tbzAUX1St6tj1ka2A8It/FyMkhIWAi sfDSJTYIW0ziwr31QDYXh5DAYUaJCT87WCCcxYwSm15NBXI4ONgELCS6/2mDmCICGhKTtqqB mMwC6hJXFweBjBEW0JXo2LCTBcQWEdCT+HzrPjOEnSRx+scOJhCbRUBFYmHfPkYQm1fAV+Jq 33ywuJDAfGaJx/c4QGxOAR2JY/MWgNUwAp32/dQasBpmAXGJDwevM0OcLCCxZM95KFtU4uXj f6wQtpJE45InrBD1ehI3pk5hg7C1JZYtfM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcXInpuYmZNebr6JERgfB7f8NtjBuOm+2CFGaQ4WJXFefd7FgUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYd9w6EtJyOOTdUa030v9KphVtcPZ4OjHyomV/04IbL65WbDw97TfPte0xbxZ3 9XkVOpy+xeJ0/fulrY+zPzim6YeFxCqLdDM/nLNF8Ki5eEto5QHHRasfLOs4Im1c8UFC71HT n80RTE7zz4vN7i59OUt8Xp2lkMjPmZdvTTw7z+B7+m1hO+bou0osxRmJhlrMRcWJAAgXMO9d AgAA
Cc: "" <>
Subject: Re: [MMUSIC] BUNDLE: SDP Offer Types
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, 05 Jun 2013 16:53:23 -0000


I'll post a SDP Section tomorrow, so we have something concrete to work on :)



-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [] 
Lähetetty: 5. kesäkuuta 2013 19:29
Vastaanottaja: Christer Holmberg
Aihe: Re: [MMUSIC] BUNDLE: SDP Offer Types

I think we are now in full agreement.
(Just need the text to say this.)


On 6/5/13 2:02 AM, Christer Holmberg wrote:
> Hi,
>>>>>>> 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 :)
>>>>>> Above seems like a good start, but I'm still grappling with some 
>>>>>> things and don't know how to talk about concisely:
>>>>>> I understand that the next offer after a Bundle Restart Offer 
>>>>>> will typically be a Bundle Sync Offer. But if there is another 
>>>>>> offer after a Bundle Sync Offer, and it doesn't change anything 
>>>>>> about the bundle, then is it still a Bundle Sync Offer?
>>>>> Currently, yes.
>>>> I agree that without adjusting the terminology this is the only right choice to make. But it is a little obscure. I'm not certain this needs to be improved, but I thought I would suggest that it might.
>>>>>> Also, I don't believe the above are mutually exclusive. If I send 
>>>>>> an offer to add a new m-line to a bundle, and I give it distinct 
>>>>>> address info so that the answerer may take it out of the bundle 
>>>>>> if needed, then is that a Bundle Restart Offer or a Bundle Sync Offer?
>>>>>> It seems to be a bit of each. And of course there may be multiple 
>>>>>> bundles described by the SDP, and these terms apply independently to each.
>>>>>> Maybe we need a couple more terms for:
>>>>>> - offer that adds a new m-line to bundle using the existing bundle
>>>>>>      address info.
>>>>> Technically that is a Bundle Sync Offer, but I DO agree that the wording is not good in this case - as it's not only about synchronization.
>>>>>> - offer that adds a new m-line to an existing bundle using unique
>>>>>>      address info.
>>>>> I agree that doesn't fit the current definitions.
>>>>> However, we will have to agree on whether we allow that in the first place, or whether the offerer will have to use 1) same address information or 2) different address information for ALL m- lines (Bundle Restart Offer).
>>>> Yes, we need to settle on whether either or both of these are permitted.
>>>> But I can think of reasons why I might wish to use either one, and no good reason not to allow both. So allowing both is my preference.
>>> I personally think we should allow BOTH 1) and 2).
>>> The question is whether we should allow 3), which is new m- line with unique address, while the other m- lines use the bundle address.
>> I agree it is a valid question to ask.
>> Again, I can see how it might be useful sometimes, and I can see no reason not to allow it. Its just a special case of the bundle restart offer.
> We could modify the definition of bundle restart offer, to allow that some m- lines may use the same address information.
> It needs to be very clear, though, that such m- lines cannot be moved out of the BUNDLE group by the Answerer, as they don't have a unique address to fallback to.
> However, the Answerer MAY still change the address for such m- lines to the address of the added m- line - especially if the Offerer puts the mid value associated with the new m- line first in the SDP group:BUNDLE attribute mid value list.
>> (Note, IMO it should be ok for the very first offer to propose a bundle with address info already shared among m-lines in the proposed bundle.
>> Using that trades off potential interop issues for speed in 
>> establishing the session.)
> My intention (and, that's why I appreciate all feedback I can get :) is to make the procedures very generic, and not separate between initial and subsequent offers (other than in examples).
> Regards,
> Christer