Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01

Hi,

>> One question related to this: is there are reason we need to use the SDP 'rtcp' attribute for trickle to begin with? What purpose does it serve?
>>
>> If someone sends "9 IN IP4 0.0.0.0" I think it is pretty clear it also applies to RTCP...
>
> Interestingly, the meaning of this is a bit subtle. Port 9 was chosen because it is the discard port. But technically, if there is no
> separate designation of the RTCP port, then (according to rfc3550) we need an even/odd pair, and so 9 is reduced to 8 for 
> rtp, and 9 is used for the rtcp.

In that case someone could say that, if you send port 0 in order to disable an m- line, you could still send RTCP on port 1...

I think one should assume that port numbers with special meaning apply to both RTP and RTCP.

> That means that rtp is not being targeted to the discard port, but rather to an unassigned port. But of course this is moot since you 
> can't send traffic to 0.0.0.0. So the effect is still as intended - the rtp/rtcp doesn't go anywhere.

Correct.

>But it doesn't mean "don't send rtcp", nor does it mean "multiplex rtp and rtcp".
>
>So then you still need to specify rtcp-mux so that ICE doesn't gather separate rtcp candidates. But I don't think you need to specify a=rtcp.

I agree.

Then we could use a=rtcp to indicate mux-exclusve, while "9 IN IP4 0.0.0.0" *without* a=rtcp would indicate trickle.

Regards,

Christer 

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer 
> Holmberg
> Sent: 12 December 2015 16:33
> To: Roman Shpount <roman@telurix.com>
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] Draft new version: 
> draft-holmberg-mmusic-mux-exclusive-01
>
> Hi,
>
>>>> 1. Are you stating the rtcp attribute for mux-exclusive MUST not 
>>>> contain the optional [nettype space addrtype space connection-address] or that it may contain this address and it should be set to the value from the c= line?
>>>
>>> Good question.
>>>
>>> My idea was that the attribute only contains the port, but I do agree that we should say something about the optional parts. Either we:
>>>
>>> 1)       say MUST NOT use it; or
>>> 2)      we say MUST use the value from the c= line; or
>>> 3       we allow both 1) and 2).
>>
>> Unless there is a reason, we should go with 3. Any endpoint that 
>> supports this draft should fully support SDP rtcp attribute and must be able to parse rtcp attribute with and without the optional address.
>> After the attribute is parsed there is no additional burden to determine that rtcp attribute points to the same address/port as c= and m= lines.
>
> Correct.
>
> Then text is needed, saying that the address information must also be the same as for the associated c- line address.
>
>> We can also specify that 1 SHOULD be preferred, simply to send less redundant data in SDP.
>
> Sounds ok.
>
> ---------
>
>>>> 2. In cases when trickle ICE is used, should rtcp SDP attribute 
>>>> contain "9 IN IP4 0.0.0.0" per draft-ietf-rtcweb-jsep section 5.2.1 or "9" per your draft? Does this mean that JSEP complaint offer is always rtcp-mux exclusive?
>>>
>>> Good question.
>>>
>>> In that case, if you are yet not providing any candidates to begin with, I assume you don't know.
>>>
>>> Of course, if we want to distinguish the cases, one option would be to e.g. use a port value of zero for mux-exclusive?
>>>
>>> Perhaps the b=RR/RS bandwidth indicators could also be used somehow, but I hope we can avoid that.
>>>
>> This is a tricky situation. When no initial candidates are collected, 
>> rtcp attribute set to port 9 can either mean that no rtcp candidates 
>> are yet available or that mux exclusive is used. I do not know what 
>> is the solution here. We definitely do not want to change mux only to require rtcp attribute with port 0, since this will break legacy interop with end points that support rtcp attribute but do not rtcp-mux. We might need an additional SDP attribute to indicate that rtcp mux exclusive is required.
>
> Would we then need to require trickle UAs to understand such attributes?
>
> (Of course, if the trickle agent is an WebRTC entity, it will support 
> the attribute)
>
> Regards,
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic