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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Jun 2016 10:58:58 +0200

Den 2016-05-30 kl. 10:08, skrev Christer Holmberg:
> 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?

Yes, I do agree with your interpretations here. Both that it applies 
bi-directional after mutual agreement, and that if the answer would like 
to use it, it will have to do a re-invite with an offer including 
a=rtcp-mux attribute to see if the peer accepts that.

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

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 09:45:18 +0000

Hi,

>> used, it will be used in BOTH directions  i.e. the usage of RTP/RTCP is
>> not per direction.
>>
>> Colin? Magnus?
>

How could we clarify that? Errata? Clarification RFC?

Regards,

Christer

>>     even if it¹s not included in the offer? If so, how will the offerer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jun 2016 18:35:59 +0300

Hi Christer,

I am not sure I understand you answer. I was wondering if the answerer can
ask to receive RTP/RTCP multiplex even if the offer did not include the
rtp/rtcp-mux attribute by providing in an

A=rtcp the port of for the RTP stream?

Roni

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, May 30, 2016 5:26 PM
To: Roni Even; 'Suhas Nandakumar'
Cc: Magnus Westerlund; 'Colin Perkins'; [email-masked]; [email-masked]
Subject: RE: [MMUSIC] [AVTCORE] 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:[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]; [email-masked]
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:[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?

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]> 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

[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 17:29:36 +0000

Hi,

I don’t think one should use a=rtcp to request RTP/RTCP multiplex.

Regards,

Christer

From: Roni Even [mailto:[email-masked]]
Sent: 22 June 2016 18:36
To: Christer Holmberg <[email-masked]>; 'Suhas Nandakumar' <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>; 'Colin Perkins' <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [MMUSIC] [AVTCORE] RTP/RTCP-mux: Attribute in answer if not included in offer?

Hi Christer,
I am not sure I understand you answer. I was wondering if the answerer can ask to receive RTP/RTCP multiplex even if the offer did not include the rtp/rtcp-mux attribute by providing in an
A=rtcp the port of for the RTP stream?
Roni

From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, May 30, 2016 5:26 PM
To: Roni Even; 'Suhas Nandakumar'
Cc: Magnus Westerlund; 'Colin Perkins'; [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,

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,
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]<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?

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

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 22 Jun 2016 13:56:17 -0400

> A=rtcp the port of for the RTP stream?
Setting a=rtcp to the same port as RTP port effectively can enable one way
RTP/RTCP mux. So, it can work in an answer, but there is a big problem with
it: end point has no way of knowing in advance that a=rtcp will be honored.
It would typically mean that end point should be prepared to work without
RTCP with RTCP sent to the wrong port. I would assume this is not a
solution you would want for any new service.

Regards,
_____________
Roman Shpount