Re: [MMUSIC] Bundle offer with different ports - where to expect media?

["Cullen Jennings (fluffy)" <[e-mail]>]

On May 21, 2013, at 11:00 PM, Justin Uberti <[e-mail]> wrote:

> 
> 1.1) An offerer must be prepared to receive unbundled traffic on the offered ports, as if talking to a legacy endpoint.
> 1.2) An offerer must be prepared to receive bundled traffic on any port, except the port associated with the last m= line.

I'm fine with this but would be just as happy without the "except last one"

> 2) Once the answer is received, the decision on bundled/unbundled and which ports to use is finalized.

Yes, as long as we keen final answer. For provisional answer you need to not free the resources. Yes, I expect to get emails from folks telling me that provisioning and final aren't defined but you know what I mean and this is the clearest way to say it for this email. 

> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in the bundle.

Again, we could go this way or the using the group syntax to do 

> 2.2) Unused ports can be discarded at this point.
> 3.1) m= lines offered with distinct ports may be omitted from the bundle answer, in line with RFC 5888.

yes, I would change "bundle answer" to "bundle group in the answer" 
 
> 3.2) m= lines offered with the same port may not be omitted from the bundle answer, since there is no unbundled port from them to fall back to.

uh, no, not on aboard with this part. As we have discussed many times, having multiple m line in the original offer with the same port won't work. I think EKR's proposal of allowing m-lines with 0 port in offer will work well. 

> 3.3) m= lines that are rejected are omitted from the bundle answer, per RFC 5888.
>