Re: Sending a=rtcp-mux-only w/o a=rtcp-mux
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxtPDUdEpmFhDZQqM0QWiXqzfM-1fB+ya8Dfj+ui2O4K2g@mail.gmail.com> |
On Tue, Feb 14, 2017 at 1:14 PM, Paul Kyzivat <[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