Re: [MMUSIC] BUNDLE: Updated offer procedures

Christer Holmberg <> Wed, 29 May 2013 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1049021F8555 for <>; Wed, 29 May 2013 00:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.618
X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QEKTiPxp4xKD for <>; Wed, 29 May 2013 00:35:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8536121F8F29 for <>; Wed, 29 May 2013 00:35:47 -0700 (PDT)
X-AuditID: c1b4fb30-b7f8a6d000001a2d-85-51a5afd232c7
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 85.F4.06701.2DFA5A15; Wed, 29 May 2013 09:35:46 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Wed, 29 May 2013 09:35:46 +0200
From: Christer Holmberg <>
To: 'Paul Kyzivat' <>, "" <>
Thread-Topic: [MMUSIC] BUNDLE: Updated offer procedures
Thread-Index: Ac5beKfpSruus8OIRHSvbTVCpmVX7QANS7OAAAbsi4A=
Date: Wed, 29 May 2013 07:35:45 +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-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM+Jvre6l9UsDDVonaVpMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFLdNUmJJWXBmep6+XQJ3xrqT9xgL9ktXfH3Sw9rAuF+0i5GTQ0LA RKLl9F5mCFtM4sK99WxdjFwcQgKHGSU2n93CApIQEljCKHG43auLkYODTcBCovufNkhYRCBQ 4sr1W4wgtrCAmcTVbSC9IHFziduv1zJC2FYSs9ubmEBsFgFViZs3j7GCjOEV8JVY/sUYYnq+ xPPdX8FKOAV0JE7M2ALWygh0zvdTa8DizALiEreezGeCOFNAYsme81Ani0q8fPwPbKSEgKLE 8n45iHIdiQW7P7FB2NoSyxa+BivnFRCUODnzCcsERtFZSKbOQtIyC0nLLCQtCxhZVjGy5yZm 5qSXm29iBMbBwS2/DXYwbrovdohRmoNFSZxXn3dxoJBAemJJanZqakFqUXxRaU5q8SFGJg5O EMEl1cDYHaL3TffBLDVjzf1O7fY7/6zfKdPfb/f0TWf8l589MZImh+5PnDaVwzl++WLr9qaP mio9Xk9ubHZSv8Nxx107JOWSU0dhfvIetj7bxk6RhU0fxUIOpb48neYv3nHzeVrF7P9i7v1v W8JDqpi/6Lnxys3V8vtzW41Za7e6w72YJzy2kcs9EpVYijMSDbWYi4oTAQe6Kt5WAgAA
Subject: Re: [MMUSIC] BUNDLE: Updated offer procedures
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, 29 May 2013 07:35:55 -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.
>I agree with all you say above.
>But those aren't all the cases. Some other possibilities:
>- new offer has all m-lines with identical ports, but answerer wants to
>   replace its own addr/port while preserving the bundle. So it puts
>   the (new) identical addr/port in all m-lines.

That's a good catch. But, I think it's more related to the "answer procedures", so I'll move it to that thread :)

I guess the question is whether we want to allow the answerer to change its bundle port in other than "bundle restart" cases (2b).

> - hybrids of the above with your other cases.
> Also, a somewhat different aspect of this:
>In the first answer establishing a bundle the a=group identifies which m-line contains the bundle port.
>Then a new O/A fills in that single port value in all the m-lines of the bundle. Is there any significance to the order 
>of the mid values in that offer and answer? (No matter which one it is, it presumably still points to an m-line with identical 
>port, so I don't see any need for rules.)

I agree. I don't think the order is significant, as all mids are associated with the same port in the new O/A.

>Then in a subsequent O/A that changes the bundle in some way, are there rules for which m-line the first mid points to? E.g., consider your case
>(2) above. Can the offer or answer designate one of the new m-lines (with unique ports) as the bundle port? (I can argue this one either way.)

2b allows the answerer to designate one of the new m- lines as the offerer bundle port (2b also allows to answerer to reject the whole bundle group).

We COULD allow the answerer to designate a new port also in case 2a. In the case of 2a, however, the answerer cannot reject the whole bundle group, as only the new m- line has a unique port.