Subject: [Megaco] 3GPP [RTCP-MUX] / ITU-T [H.248.57, H.248.RTPMUX] RTCP port allocation rules in case of RTP transport multiplexing

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 23 Jan 2014 07:24:56 +0000

Dear All,
we spent some time in the meanwhile how H.248.57 could be upgraded. The proceeding isn’t straightforward because we need to decide on some rule interaction issues.
Our discussion and change proposals are now available (as part of ITU-T Q.3/16 March meeting):

AVD-4489

H.248.57: RTCP port allocation rules in context of RTP transport multiplexing - Discussion

AVD-4490

H.248.57: RTCP port allocation rules in context of RTP transport multiplexing - Change proposal for a revised H.248.57

Download:
http://wftp3.itu.int/av-arch/avc-site/2013-2016/1403_Gen/AVD-4489.zip
http://wftp3.itu.int/av-arch/avc-site/2013-2016/1403_Gen/AVD-4490.zip

The results of the Q.3/16 discussions will be the baseline for our 3GPP [RTCP-MUX] CRs for Iq (April meeting).

Any feedback would be appreciated,
Jürgen & Albrecht

From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: Sonntag, 10. November 2013 15:38
To: Nevenka Biondic; Kall, Jan (NSN - FI/Espoo); Tommy Young; Belling, Thomas (NSN - DE/Munich); LANDAIS, BRUNO (BRUNO); [email-masked]
Cc: DRAGE, Keith (Keith); [email-masked]; Arturo Martin De Nicolas; 박주영; Shaikh, Viqar A
Subject: [H.248.57, H.248.RTPMUX] RTCP port allocation rules in case of RTP transport multiplexing

Dear All,

the addition of SDP „a=rtcp-mux” to H.248 Iq profile (23.334/29.334) leads to RTCP port allocation rules which are not yet defined (due to the fact that Iq supports also “a=rtcp” besides the rsb property).

NOTE: Iq allows “a=rtcp” only in the H.248 RD, not in the H.248 LD, but there remains still open semantics.

Normative baseline is Table 1/H.248.57 (in case of “a=rtcp” support).

You know that the consideration of “a=rtcp-mux” is still an open action for H.248.57.

Like to recall again that there are four principal connection endpoints for RTP transport multiplexing: the LS, LD, RS and RD connection endpoints:

…

H.248.57/Figure 1 – Connection endpoint naming conventions – the four
RTCP ports of a bidirectional RTP/RTCP session

Please find attach an evaluation of additional support of “a=rtcp-mux”, extending Table 1/H.248.57 by additional cells.

NOTE: RFC 5761 is NOT EXPLICIT on the usage of “a=rtcp” together with “a=rtcp-mux”! It’s mentioned twice in the text. My INTERPRETATION of RFC 5761: there is an IMPLICIT assumption that the SDP Offerer/Answerer SHALL NOT use both SDP attributes together. However, a different interpretation is that the parallel usage is allowed, and the receiving side is then applying “semantic of ignore”. Both interpretations might be valid. However, would prefer rather an explicit specification.

Any comments, proposals?

Albrecht

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 24 Jan 2014 16:26:52 +0000

Albrecht,

> NOTE: RFC 5761 is NOT EXPLICIT on the usage of “a=rtcp” together with >“a=rtcp-mux”! It’s mentioned twice in the text. My INTERPRETATION of RFC >5761: there is an IMPLICIT assumption that the SDP Offerer/Answerer SHALL >NOT use both SDP attributes together. However, a different interpretation >is that the parallel usage is allowed, and the receiving side is then >applying “semantic of ignore”. Both interpretations might be valid. >However, would prefer rather an explicit specification.

[Raju] The way I read RFC 5761, a=rtcp and a=rtcp-mux can be used in any combination and no single combination being manadating as there are clear semntics for all combinations.
But then the ICE RFC 5245, kind of mandating a=rtcp. Please see below. This RFC, though does not apply to 3gpp, is kind of trying to influence similar rule.
So, I agree with you that an explicit specification indicating “any combination is possible” is better.

4.3<http://tools.ietf.org/html/rfc5245#section-4.3>.  Encoding the SDP
The default candidates are added to the SDP as the default
   destination for media.  For streams based on RTP, this is done by
   placing the IP address and port of the RTP candidate into the c and m
   lines, respectively.  If the agent is utilizing RTCP, it MUST encode
   the RTCP candidate using the a=rtcp attribute as defined in RFC 3605<http://tools.ietf.org/html/rfc3605>
   [RFC3605<http://tools.ietf.org/html/rfc3605>].  If RTCP is not in use, the agent MUST signal that using
   b=RS:0 and b=RR:0 as defined in RFC 3556<http://tools.ietf.org/html/rfc3556> [RFC3556<http://tools.ietf.org/html/rfc3556>].

Thanks
Raju

From: Megaco [mailto:[email-masked]] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: Thursday, January 23, 2014 1:25 AM
To: Nevenka Biondic; Kall, Jan (NSN - FI/Espoo); Tommy Young; Belling, Thomas (NSN - DE/Munich); LANDAIS, BRUNO (BRUNO); [email-masked]; Arturo Martin De Nicolas
Cc: Shaikh, Viqar A; 박주영; DRAGE, Keith (Keith); [email-masked]; [email-masked]
Subject: [Megaco] 3GPP [RTCP-MUX] / ITU-T [H.248.57, H.248.RTPMUX] RTCP port allocation rules in case of RTP transport multiplexing

Dear All,

AVD-4489

AVD-4490

Download:

Dear All,

…

Any comments, proposals?

Albrecht