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

[Emil Ivov <[e-mail]>]

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?

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?

>> Of course the answer would come with the first m=line having a 0 port
>> but the offerer would then just learn the bundle port number at the
>> first m=line with a non-zero port.
> 
> I presume you must have a motivation for wanting to go this way.
> Are you thinking this will simplify the implementation?

No. The implementation is going to be slightly more complicated indeed
because instead of having one bundle demuxing socket and two regular
ones (well ... if rtcp demuxing counts as regular) you would have three
of them. I don't think this would be particularly horrifying in terms of
complexity though.

Still, I think being consistent about the ports where one could get
multiplexed data is a good thing, and it could help (humans) when
analysing traffic and debugging network issues.

Emil

-- 
https://jitsi.org