Subject: Re: [MMUSIC] FW: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2016 08:12:43 +0000

Anyone?

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday 27 May 2016 at 12:10
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] FW: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

(Sorry for the cross-posting)

Hi,

There has been a discussion in 3GPP regarding RFC 5761 (RTP/RTCP-mux).

Section 5.1.1 says:

5.1.1.  SDP Signalling

   When the Session Description Protocol (SDP) [8] is used to negotiate
   RTP sessions following the offer/answer model [9], the "a=rtcp-mux"
   attribute (see Section 8) indicates the desire to multiplex RTP and
   RTCP onto a single port.  The initial SDP offer MUST include this
   attribute at the media level to request multiplexing of RTP and RTCP
   on a single port.  For example:

       v=0
       o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
       s=-
       c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
       t=1153134164 1153137764
       m=audio 49170 RTP/AVP 97
       a=rtpmap:97 iLBC/8000
       a=rtcp-mux

   This offer denotes a unicast voice-over-IP session using the RTP/AVP
   profile with iLBC coding.  The answerer is requested to send both RTP
   and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.

   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.

Q: The question is whether it is allowed to include a=rtcp-mux in an answer if the associated offer did NOT contain a=rtcp-mux.

The second last paragraph in the text above does say that, if the answer wishes to do RTP/RTCP-mux, it includes a=rtcp-mux in the answer.

BUT, in my view that is it based on the first paragraph, which assumes a=rtcp-mux is also included in the offer.

Or, am I wrong? Is it allowed to include a=rtcp-mux in the answer, even if it’s not included in the offer? If so, how will the offerer then indicate whether mux is used or not.

Regards,

Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 31 May 2016 16:24:30 +0000

Hi Christer,

My understanding is the same as yours, if rtcp-mux was not included in the offer, it cannot be included in the answer.

Cheers,
Charles

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 30, 2016 at 1:12 AM
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] FW: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

Anyone?

Regards,

Christer

Hi,

Section 5.1.1 says:

5.1.1.  SDP Signalling

       v=0

Or, am I wrong? Is it allowed to include a=rtcp-mux in the answer, even if it's not included in the offer? If so, how will the offerer then indicate whether mux is used or not.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 31 May 2016 12:45:01 -0400

Christer,

Technically speaking RFC5761 does not prohibit including rtcp-mux in the
answer if it was not present in the offer. This being said, if offerer
supports rtcp-mux, according to RFC5761 it must include rtcp-mux in the
offer. This means including rtcp-mux in the answer will imply sending this
attribute to the end point which does not support it. I would also say,
that since offerer did not send rtcp-mux attribute it should pretend not to
support rtcp-mux and ignore rtcp-mux in the answer to be compliant with
RFC5761.

Regards,
_____________
Roman Shpount