Subject: [MMUSIC] BUNDLE: Updated offer procedures

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 May 2013 07:58:28 +0000

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.

Comments?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 May 2013 12:15:43 -0400

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

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

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

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 May 2013 07:35:45 +0000

Hi,

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

>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