Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)

Christer Holmberg <> Tue, 11 June 2013 09:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 603F521F8F24 for <>; Tue, 11 Jun 2013 02:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.116
X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qrhTSjfznPP8 for <>; Tue, 11 Jun 2013 02:15:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5AE321F8EC6 for <>; Tue, 11 Jun 2013 02:15:21 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-90-51b6eaa847b6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C7.B0.15700.8AAE6B15; Tue, 11 Jun 2013 11:15:20 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 11:15:20 +0200
From: Christer Holmberg <>
To: Martin Thomson <>, Paul Kyzivat <>
Thread-Topic: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
Thread-Index: Ac5iprZaCgBOn7ljRxaMYhEaRiO+KgAHcYEAAMTTumAABIV6AAAAlecAACJhoQA=
Date: Tue, 11 Jun 2013 09:15:18 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvre6KV9sCDZ5Mlbe4duYfo8XU5Y9Z LFZsOMDqwOzx9/0HJo+ds+6yeyxZ8pMpgDmK2yYpsaQsODM9T98ugTvj1tM9TAU/uCrWNho2 MF7h6mLk5JAQMJE4vOYEE4QtJnHh3nq2LkYuDiGBw4wSfdMaWSCcJYwSl/bvZu5i5OBgE7CQ 6P6nDdIgIhAq0XZxHyNImFlAXeLq4iCQsLCAg8SWDZNYIUocJQ782sIGYftJHN08jQXEZhFQ ldj0awcjiM0r4CvxaU8jE8SqOUwS0xdeYQZJcAoESpzYvQjMZgQ67vupNWCHMguIS9x6Mh/q aAGJJXvOM0PYohIvH/9jBblHQkBRYnm/HMRpmhLrd+lDdCpKTOl+yA6xVlDi5MwnLBMYxWYh GToLoWMWko5ZSDoWMLKsYmTPTczMSS833MQIjJiDW37r7mA8dU7kEKM0B4uSOK8e7+JAIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJwggkuqgdF59/qInSU8rfpNu0vPrZx8svaO+/yvXO0qxh99 W2df2vaEI3Wrsmt+vsvq68FGh3bvvqdv5pTodTNUSEFP443FrLS/nQmiNXHJjy1PL9BevGNN 094KTuYHDbPuz51urLVAVSX54TPbXNEX9qpTbbTMFz/yKt0Rvera4rK4iv/T0iwdJdmUZymx FGckGmoxFxUnAgBfRf5VawIAAA==
Cc: "" <>
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
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: Tue, 11 Jun 2013 09:15:29 -0000


>> For example, assume I am adding a new "m=" line, with a unique 
>> address, and I would like that address to become the new bundle address.
>That's two things:
>1. Add a new m-line, but allow it to be accepted and unbundled.
>2. Change the transport parameters of the existing bundle, but permit the change to be rejected.
>I would be perfectly happy to require that this take two rounds of offer/answer to perform.
>I understand how that might be useful in theory, but I don't think that you can make this change without accepting a lot of additional 
>complexity in the rest of the solution.  I liked the constraint because it simplifies the rules around creation and acceptance significantly.  
>Remove that constraint and I don't know where we are any more.

Personally, I think the case where the Offerer wants to re-negotiate the bundle address will be very rare. In practice, I think it will only happen if the Offerer uses a re-INVITE to perform a transfer.