Re: [MMUSIC] BUNDLE: Updated offer procedures

[Christer Holmberg <[e-mail]>]

Hi,

>> 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.

Regards,

Christer