Re: Sending a=rtcp-mux-only w/o a=rtcp-mux

Hi,

Also, if the offerer receives an answer, without a=rtcp-mux, it must take proper action for disabling the RTP session associated with the m- line.

Regards,

Christer

From: mmusic [mailto:[email protected]] On Behalf Of Roman Shpount
Sent: 14 February 2017 20:45
To: Paul Kyzivat <[email protected]>
Cc: [email protected]
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux

On Tue, Feb 14, 2017 at 1:14 PM, Paul Kyzivat <[email protected]<mailto:[email protected]>> wrote:
On 2/14/17 12:29 PM, Roman Shpount wrote:
Hi,

1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included
2. In the answer rtcp-mux MUST be included or the session should be
terminated. rtcp-mux-only MUST NOT be included.

Do you mean the RTP session must be terminated, or the *signaling* session?

Requiring the signaling session to be terminated is overreaching. But I would agree that refusing the m-line (with port=0) is the proper alternative to accepting the rtcp-mux.

This should be handled the same way as getting back unexpected or error answer for a specific m= line. Either RTP session associated with the specific m= line needs to be terminated with port=0 or the whole signaling session should be terminated. Most importantly, RTP session associated with m= line MUST not continue to run expecting RTCP on rtp port + 1. Essentially, rtcp-mux-only should be treated as a promise by the offering party that it will not accept an answer without rtcp-mux.

Regards,
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic