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

Hi,

In an offer a=rtcp is used to provide a fallback port, in case the answerer does not support RTP/RTCP-mux (but does support a=rtcp).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roni Even<mailto:ron.even.tlv@gmail.com>
Sent: ‎30/‎05/‎2016 17:19
To: 'Suhas Nandakumar'<mailto:suhasietf@gmail.com>; Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: Magnus Westerlund<mailto:magnus.westerlund@ericsson.com>; 'Colin Perkins'<mailto:csp@csperkins.org>; avt@ietf.org<mailto:avt@ietf.org>; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

Hi,
Agree with Suhas but have a question
What if the offer has an a=rtcp with a port different from the RTP one, and the response include a=rtcp using the same port as the RTP port? Is it allowed, at least in RFC3605 did not see any discussion about this

Roni

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Suhas Nandakumar
Sent: Friday, May 27, 2016 4:26 AM
To: Christer Holmberg
Cc: Magnus Westerlund; Colin Perkins (csp@csperkins.org); mmusic@ietf.org; avt@ietf.org
Subject: Re: [MMUSIC] [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