Re: [MMUSIC] WGLC on draft-ietf-mmusic-mux-exclusive-03.txt

[Christer Holmberg <[e-mail]>]

Hi,

>> FIRST, section 5.1.3 of RFC 5761 says:
>>
>>    "If it is desired to use both ICE and multiplexed RTP and RTCP, the
>>    initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
>>    RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
>>    lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
>>    fallback port for RTCP in the case that the answerer does not support
>>    RTP and RTCP multiplexing.  This MUST be done for each media where
>>    RTP and RTCP multiplexing is desired."
>
> If you think that you can do this without updating RFC 5761, I'm surprised.  RFC 5761 envisages a world where mux-exclusive is an impossibility; clearly this is no longer the case.
>
> You describe a cage that we built for ourselves.  We are perfectly able to use the same power that built that cage to dismantle it.  In the end, it's just words.

We agreed earlier to not update existing mechanisms. I think we should keep 5761 it as it is, for backward compatibility, because there are deployments that use it.

>> SECOND, draft-ietf-mmusic-ice-sip-sdp mandates it. Now, that if obviously something we can change, but my understanding was that people didn't want to update 5761.
>
> Fixing ice-sip-sdp seems reasonable.  Since the patient is still on the table, we have some time to retrieve the missing forceps.

Agree. 

>> THIRD, if ICE is not used to begin with, there will be no candidates, 
>> so a=rtcp-mux will obviously not produce the same result :)
>
> By which you mean you get RTP_port+1 for RTCP?  This isn't strong motivation, since you will tear down a session immediately after discovering that they don't want mux and don't understand mux-exclusive.

People did not want a solution where one starts sending stuff and then realize it doesn't work.

Also, intermediaries will may still reserve resources for RTCP, as they don't know whether it will be used or not.

>> FOURTH, and perhaps this is more theoretical, if you use trickle then a=rtcp-mux does not indicate whether RTCP candidates will come later or not.
>
> Yes, this is the one that I thought of.  This is actually the best motivation to my mind, though again somewhat weak.  Again, you only have a problem with a peer that doesn't want mux AND doesn't understand this spec.

I think you would have problem with any peer, because they don't know if the RTCP candidate will come later (in case of trickle) or if it won't come at all (in case of exclusive-mux).

>> We could of course say that one must not include a=rtcp, unless used together with a mechanism that requires it, and then we stop defining future mechanisms that use a=rtcp.
>
> I think that would be a fine thing to do.  Again, since ice-sip-sdp is still in the working group, we should fix that while we are at it (add an exclusion for exclusive).

Agree. That we should do no matter how we indicate mux-exclusive.

> Note that again, this is a box of our own design, we can decide to update those documents here.  "The a=rtcp attribute MUST NOT be included 
>unless other documents (other than RFC 5761) mandate its inclusion.  If present, a=rtcp MUST include a port number of 9."  Or something along those lines.

Sure, I can add text like that to the draft, and we can update ice-sip-sdp.

But, again, it was earlier agreed to not update existing mechanisms (RFC 5761 etc), and I really would not like to change that decision at this point. The new attribute provides an explicit indicator, and is not dependent on ice candidates etc. Also, it's just an SDP attribute, so it's not a major thing to implement.

Regards,

Christer