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

Hi,

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

How could we clarify that? Errata? Clarification RFC?

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
>>
>>
>
>
>-- 
>
>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: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------
>