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

[Emil Ivov <[e-mail]>]

Hey Paul,

On 21.05.13, 20:57, Paul Kyzivat wrote:
> On 5/21/13 4:45 AM, Emil Ivov wrote:
>> Hey Paul,
>>
>> On 20.05.13, 18:09, Paul Kyzivat wrote:
>>> On 5/20/13 10:51 AM, Emil Ivov wrote:
>>>> Hey Christer,
>>>>
>>>> On 20.05.13, 17:16, Christer Holmberg wrote:
>>>>> Hi,
>>>>>
>>>>>>>> What happens when the offerer knows the answerer has bundle
>>>>>>>> support, sends all m-lines with the same port, then the
>>>>>>>> answerer splits the first line away from the bundle? Would the
>>>>>>>> answerer still send everything to the same port?
>>>>>>>
>>>>>>> We discussed this week,
>>>>>>>
>>>>>> Yes, sorry, I didn't follow this closely.
>>>>>>
>>>>>>> and the outcome (at least my read of it :) was that the answerer
>>>>>>> is not allowed to split any m- lines away from the bundle in this
>>>>>>> case. Instead the answerer will have to send a new offer for the
>>>>>>> split, allowing new ports to be negotiated at both ends.
>>>>>>
>>>>>> OK, so shouldn't the same thing happen in the case with different
>>>>>> ports?
>>>>>
>>>>> I suggested that it should never be allowed to split an m- line from
>>>>> a bundle group in an answer, but others had other opinions.
>>>>
>>>> I don't see how we could allow it in one case and disallow it in the
>>>> other. The only difference between the two cases is how informed the
>>>> offerer is about the answerers bundle support capabilities and I don't
>>>> really understand why this would influence the decision to allow
>>>> splitting bundles one way or the other.
>>>
>>> It is a different case because the same port *can't* both be used as the
>>> bundle port and a port for an unbundled m-line.
>>
>> Why not? Obviously the offerer was prepared to demultiplex traffic
>> there. Why wouldn't it be able to continue doing so even if the answerer
>> would prefer to receive it separately?
> 
> 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. But we 
> investigated that approach early in the bundle discussions, and gave it up.

No I don't and I suspect you misunderstood me.

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.

>> Note that I am not defending such an approach. I'd much prefer that
>> splitting is only allowed when re-offering.
>>
>>>>> HOWEVER, it would still not help in the case where the 1st m- line is
>>>>> rejected.
>>>>
>>>> Well, how about looking at it this way: the offerer specifies a bundle
>>>> port in the first m=line. This also happens to be the port for the first
>>>> media line but the two are different things and just happen to have the
>>>> same value for reasons related to syntax and convenience.
>>>>
>>>> A bundle supporting answerer should understand this. After receiving the
>>>> offer that answerer has learned the bundle port number. Rejecting the
>>>> first m=line in the answer does not change this.
>>>
>>> There are many reasons that an answerer may reject an m-line.
>>> It is *possible* that it is rejecting it because it has a problem with
>>> the address (c=) for the m-line in the offer. If so, then if you insist
>>> on using it as the bundle address, even if the m-line is refused, then
>>> there is no way for the answerer to refuse it.
>>>
>>> (*Why* it would have a problem is an open question. Maybe its IPv6 and
>>> the answerer can't use it, or maybe its an FQDN and it can't be
>>> resolved. I realize this is unlikely. But making the assumption that the
>>> address must be acceptable to the answerer is IMO not a good idea.)
>>
>> Aha! That's a good point.
>>
>> 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.

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

Emil

-- 
https://jitsi.org