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

[Christer Holmberg <[e-mail]>]

Hi Martin,

Thanks for your comments! See inline.

> This document needs to more clearly articulate the reason for the attribute.  An implementation that fails to generate 
> unique RTCP port numbers (on a=rtcp or a=candidate lines) AND checks for a=rtcp-mux attributes will produce the same effect as with this attribute.

Perhaps, but there are at least a couple of semantical issues with that:

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


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.


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 :)


> Can we mandate either mandatory inclusion of a=rtcp with matching transport parameters, or mandatory omission of a=rtcp?  If 
> there is a reason to allow this choice, it might be wise to document it.  Since we're exclusive, I see no reason to waste bytes and 
> cycles on a=rtcp; I'd prefer to have it omitted.  We're highly unlikely to be compatible with anyone expecting to rely on a=rtcp in any case.

The only reason is if the mux-exclusive mechanism is used together with some other mechanism that requires usage of a=rtcp. As mentioned earlier, draft-ietf-mmusic-ice-sip-sdp currently requires usage of a=rtcp with RTCP.

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.

-------------------

> Editorial:
>
> Rather than:
>
>   The RTCWEB WG has defined that support of the fallback mentioned
>   above is optional.  Therefore, there is a need for a mechanism that
>   allows an endpoint to indicate exclusive support of RTP/RTCP
>   multiplexing, meaning that endpoint only supports RTP/RTCP
>   multiplexing and is not able to fallback to usage of separate ports
>   for RTP and RTCP.
>
>Say:
>
>   Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not 
>   implement separation of RTP and RTCP.  For those applications, this document defines an SDP attribute to signal intent to require multiplexing.

Looks good.

Thanks!

Regards,

Christer