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

Hi Suhas,

I have the same understanding as you: the offerer indicates support of RTP/RTCP-mux, and the answerer decides whether to use it or not. And, if used, it will be used in BOTH directions – i.e. the usage of RTP/RTCP is not per direction.

Colin? Magnus?

Regards,

Christer

From: Suhas Nandakumar <suhasietf@gmail.com<mailto:suhasietf@gmail.com>>
Date: Friday 27 May 2016 at 04:25
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Cc: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>, "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>>, Colin Perkins <csp@csperkins.org<mailto:csp@csperkins.org>>
Subject: Re: [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

Going along O/A negotiation procedures, i would lean towards your former conclusion that the offer needs to include the rtcp-mux ability.
If the offer doesn't include a=rtcp-mux and the answerer wants to mux , then it needs a new O/A from the answerer's perspectives.

If we make a=rtcp-mux a declarative SDP it might solve the other use-case ..

thanks
Suhas

On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
(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

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org<mailto:avt@ietf.org>
https://www.ietf.org/mailman/listinfo/avt