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

[Paul Kyzivat <[e-mail]>]

On 5/21/13 6:34 PM, Emil Ivov wrote:

>> The point of wanting the one line unbundled is so that it can be
>> *received* on a different address/port. Perhaps there is a separate
>> device or process that will be supporting that one, that must be reached
>> at its own addr/port.
>
> Yes, sure. My point was that the party that unbundled the one m= line
> can receive it separately. The party that sent the offer can keep
> getting it on the same port.
>
>> Unless you expect that this would have a common addr/port on the
>> offering side and different addr/ports on the answering side.

Your statement above seems to be exactly what my following statement says.

>> But we
>> investigated that approach early in the bundle discussions, and gave it up.
>
> No I don't and I suspect you misunderstood me.

I must be misunderstanding you. Your "no I don't" comment seems to be in 
direct conflict with what you said above.

But maybe we don't need to keep discussing this. It seems the discussion 
has moved beyond it.

> Also in all my comments I kept noting that we shouldn't be allowing the
> answer to unbundle a single m= line. In your response to Cullen you
> seemed to agree with this so I guess we are in agreement.

Its getting hard to sort out what these statements mean out of context. 
So I don't know.

>>> Still, the thing that I don't quite understand is: if the answerer has a
>>> problem with the c= line, how could that problem only apply to the first
>>> m= line and not to the entire bundle?
>>
>> Presumably this would only happen if the c= for were not all the same in
>> the offer. Certainly that is possible. When allocating "ports" for each
>> m-line one might also end up with different addresses.
>
> This makes me wonder: should we even allow for different c= addresses
> within a bundle? The reason to use different ports was a compromise, not
> a choice based on the necessity to give that option to applications.
> While falling back to different port numbers is defendable, I don't see
> how we would justify the possibility to fallback to different c= lines.

When faced with a choice of leaving something general or narrowing it, I 
opt for leaving it general unless there is some compelling reason to do 
otherwise.

IMO in the entire discussion, when we talk about "different ports" that 
is really shorthand for "different address/port pairs". (And this 
includes cases where the addresses are different and the ports are the 
same.)

If the offerer needs a bunch of address/port pairs to assign to the 
different m-lines of the bundle, it will presumably allocate them out of 
some pool available to it. That pool may include multiple addresses as 
well as ports. Restricting to a set that all share the same address may 
cause it difficulty. An example of where this might occur is if it is 
using STUN/TURN to get the address/ports.

>> Consistency is good. But isn't it just as consistent to say that the
>> first *accepted* m-line defines the bundle addr/port as it is to say
>> that the first offered m-line?
>
> The bundle suggestion started out by saying that all ports would be the
> same. We then moved to a version where we would use different ports, in
> order to prevent some non-bundle endpoints from fainting at the sight of
> port reuse. We still agreed that the first one is the bundle port and
> the others are there just for fall back. So far so good.
>
> Now we are discussing the possibility of saying: your bundle port will
> be the first one you offer, unless the answerer rejects that m= line, in
> which case it could be the port of the second m= line, or the third one ...
>
> I agree it wouldn't be the end of the world, but to me this doesn't
> sound particularly consistent.

I agree it is a complication. If the alternative is saying that the 
answer can't unbundle or reject the first m-line, or that if it 
unbundles it then it will be bundled on one end and unbundled on the 
other end, then that is also a complication. So its a value judgment 
which complication is most acceptable.

	Thanks,
	Paul