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

[Christer Holmberg <[e-mail]>]

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