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

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 May 2016 20:01:38 +0000

(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: Suhas Nandakumar <[email-masked]>
Date: Thu, 26 May 2016 18:25:43 -0700

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 <
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 May 2016 09:10:03 +0000

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: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2016 08:08:12 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday 27 May 2016 at 04:25
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Magnus Westerlund <[email-masked]<mailto:[email-masked]>>, Colin Perkins <[email-masked]<mailto:[email-masked]>>
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.

thanks
Suhas

On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
(Sorry for the cross-posting)

Hi,

Section 5.1.1 says:

5.1.1.  SDP Signalling

       v=0

Regards,

Christer

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: "Roni Even" <[email-masked]>
Date: Mon, 30 May 2016 17:18:09 +0300

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:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: Friday, May 27, 2016 4:26 AM
To: Christer Holmberg
Cc: Magnus Westerlund; Colin Perkins ([email-masked]); [email-masked]; [email-masked]
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

 

thanks

Suhas

On Thu, May 26, 2016 at 1:01 PM, Christer Holmberg <[email-masked]> wrote:

Hi,

Section 5.1.1 says:

5.1.1.  SDP Signalling

       v=0

       s=-

       t=1153134164 1153137764

       m=audio 49170 RTP/AVP 97

       a=rtpmap:97 iLBC/8000

       a=rtcp-mux

   Section 4.

   attribute.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2016 14:25:30 +0000

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:[email-masked]>
Sent: ‎30/‎05/‎2016 17:19
To: 'Suhas Nandakumar'<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>
Cc: Magnus Westerlund<mailto:[email-masked]>; 'Colin Perkins'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

Hi,

Roni

thanks
Suhas

Hi,

Section 5.1.1 says:

5.1.1.  SDP Signalling

       v=0

Regards,

Christer