Re: [MMUSIC] Simultanous usage of a=rtcp and a=rtcp-mux

[Paul Kyzivat <[e-mail]>]

On 8/2/12 4:31 PM, Christer Holmberg wrote:
> Hi,
>
> One of the issues which was raised during the MMUSIC BUNDLE presentation, but which is not BUNDLE specfic, was the case when an offer contains both a=rtcp and a=rtcp-mux.
>
> A case where this can happen is ICE, which requires the inclusion of the a=rtcp attribute.
>
>        "If the agent is utilizing RTCP, it MUST encode the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 [RFC3605]." (RFC 5245/Section 4.3)
>
> Example:
>
> m=audio 20000
> a=rtcp: 25000
> a=rtcp-mux
>
>
> Q: If the receiver supports both attributes, to which port would it send RTCP?
>
> As indicated during the meeting, in theory this could be solved by using a=rtcp: 20000 (ie same port as RTP), but people indicated that it is not allowed (eventhough not explicitly forbidden, afaik).
>
> As also indicated, another way to solve this could be by saying: "If the receiver supports a=rtcp-mux, use that, otherwise use a=rtcp". But, I have not found any text which would support such intepretion.

RFC 5761 says:

    If the answerer wishes to multiplex RTP and RTCP onto a single port,
    it MUST include a media-level "a=rtcp-mux" attribute in the answer.
    The RTP payload types used in the answer MUST conform to the rules in
    Section 4.

    If the answer does not contain an "a=rtcp-mux" attribute, the offerer
    MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
    it should send and receive RTCP on a port allocated according to the
    usual port-selection rules (either the port pair, or a signalled port
    if the "a=rtcp:" attribute [10] is also included).  This will occur
    when talking to a peer that does not understand the "a=rtcp-mux"
    attribute.

Seems pretty explicit to me. Also, I don't see how it could work 
otherwise and still obey the standard SDP backward compatibility rule 
for unknown attributes.

	Thanks,
	Paul