5.15 Mandatory support of SDP and Annex C information elements

29.3343GPPIMS Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW)Iq InterfaceRelease 17Stage 3TS

Table 5.15.1: Mandatory Annex C and SDP information elements

Information Element

Annex C Support

SDP Support

v-line

"SDP_V "

The value must always be equal to zero: v=0

c-line

"SDP_C "

<nettype> <addrtype> and <connection address> are required.

The network type shall be set to "IN".

The address type may be IPv4 or IPv6.

The MGC may apply parameter underspecification to the <connection address> subfield.

m-line

"SDP_M "

There are four fields (or SDP values) <media>, <port>, <proto> and <fmt> in the "m=" line (see IETF RFC 4566 [17];NOTE 1).

The "m=" line may be omitted from SDP.

<media>, <port>, <proto > and <fmt-list> are required if the "m=" line is included.

Media type <media> :

The <media> field shall be set to "audio", "video", "message", "application", "text" or "-". When "-" is used for the media value then no media resources are required to be reserved at this stage (NOTE 1). If the MG does not support the requested media value it shall reject the command with error code 515.

Transport port <port>

The port value may be underspecified with CHOOSE wildcard.

Transport protocol <proto>

As in table 5.15.2.

Media format <fmt>

Various values may be used for media-format, dependent on the related <media> (NOTE 3).

"-" may be used for the format list value if no media reservation is required at this stage.

If the MG does not support the requested media format value the MG shall reject the command with error code 449.

b-line

"SDP_B "

Shall not be used without a "m=" line.

The modifier values shall be "AS", "RS" and "RR".

The AS modifier implies that the bandwidth-value represents the ""maximum bandwidth" (see clause 5.8/ IETF RFC 4566 [17]). The bandwidth-value relates therefore to the peak bitrate (NOTE 2).

The bandwidth-value value defines the IP layer bandwidth for the specific H.248 Stream.

For RTP flows, where RTCP resources are reserved together with the RTP resources using the "RTP Specific Behaviour" property of the Gate Management package (gm) property, the IMS-ALG may also supply additional RTCP bandwidth modifiers (i.e. RR and RS, see IETF RFC 3556 [28]). The AS bandwidth value will include the bandwidth used by RTP. In the absence of the RTCP bandwidth modifiers the IMS-AGW shall allow an additional 5% of the AS bandwidth value for the bandwidth for RTCP, in accordance with IETF RFC 3556 [28].

o-line

"SDP_O"

The origin line consists of six fields:

(<username>, <sess-id>, <sess-version>, <nettype>, <addrtype> and <unicast-address>).

The MGC is not required to supply this line but shall accept it (see clause 7.1.8/ITU-T Recommendation H.248.1 [10]).

The MG shall return the value received from the MGC or if there is no o-line sent by the MGC, the MG shall populate this line as follows:

– <user name> should contain an hyphen

– <session ID> and <version> should contain one or mode digits as described in IETF RFC 4566 [17]

– <network type> shall be set to IN

– <address type> shall be set to IP4 or IP6 The Address Type shall be set to "IP4" or "IP6" depending on the addressing scheme used by the network to which the MG is connected.

– <address> should contain the fully qualified domain name or IP address of the gateway.

s-line

"SDP_S"

The session name "s=" line contains a single field

s= <session name>.

The MGC is not required to supply this line but shall accept it (see clause 7.1.8/ITU-T Recommendation H.248.1 [10]).

The MG shall return the value received from the MGC or if there is no s-line sent by the MGC, the MG shall populate this line as follows:

– "s=-"

t-line

"SDP_T"

The time "t=" line consists of two fields

t= <start time> and <stop time>.

The MGC is not required to supply this line but shall accept it (see clause 7.1.8/ITU-T Recommendation H.248.1 [10]).

The MG shall return the value received from the MGC or if there is no t-line sent by the MGC, the MG shall populate this line as follows:

"t=0 0"

NOTE 1: IETF RFC 4566 [17] enables "-" as a valid character.

NOTE 2: The unit for the bandwidth-value (peak bitrate) is "kbit/s". The "b=" line is not providing any information about the traffic characteristic, i.e. whether the traffic flow has a Constant BitRate (CBR) or Variable BitRate (VBR). The bandwidth-value is thus independent of the traffic characteristic and relates to the peak bitrate for CBR and VBR traffic.

NOTE 3: In particular, WebRTC uses value "webrtc-datachannel" in case of WebRTC data applications.

Table 5.15.2: Transport Protocol

Transport Protocol <proto> in m-line:

If the MG does not support the requested transport protocol, it shall reject the command with error code 449.

RTP/AVP

RTP profile according IETF RFC 3551 [19]. Allow only L4 protocol = UDP (see NOTE 1).

RTP/AVPF

Extended RTP profile for RTCP-based Feedback (RTP/AVPF) according IETF RFC 4585 [25]. See 3GPP TS 26.114 [26]. Allow only L4 protocol = UDP (see NOTE 1).

RTP/SAVP

SRTP profile according IETF RFC 3711 [30] (NOTE 3). Allow only L4 protocol = UDP (see NOTE 1).

RTP/SAVPF

Extended SRTP profile for RTCP-based Feedback (RTP/SAVPF) according IETF RFC 5124 [31] (NOTE 3). Allow only L4 protocol = UDP (see NOTE 1).

TCP

Allow only L4 protocol = TCP (NOTE 2)

TCP/MSRP

Message service using IETF RFC 4975 [18] (NOTE 6).

TCP/TLS

Application agnostic indication with L4 protocol = TCP (NOTE 4).

TCP/TLS/MSRP

Application-specific indication with L4 protocol = TCP and TLS-based transport security (SDP codepoint see IETF RFC 4975 [18]) (NOTE 6).

udptl

Allow only L4 protocol = UDP

udp

Allow only L4 protocol = UDP (NOTE 1, NOTE 7).

UDP/DTLS

Application agnostic indication with L4 protocol = UDP and DTLS-based transport security (NOTE 5).

UDP/TLS/RTP/SAVP

Indication for WebRTC end-to-access edge transport security using DTLS-SRTP, where DTLS is used to establish keys for SRTP according to IETF RFC 5763 [60] and IETF RFC 5764 [61].

UDP/TLS/RTP/SAVPF

Indication for WebRTC end-to-access edge transport security using DTLS-SRTP, where DTLS is used to establish keys for extended SRTP according to IETF RFC 5763 [60] and IETF RFC 5764 [61].

UDP/DTLS/SCTP

See IETF RFC 8841 [68]. For WebRTC data channel support (for the indication of the protocol stack segment "SCTP-over-DTLS").

NOTE 1: Parameter "udp" is introduced by IETF RFC 4566 [17].

NOTE 2: Upper case TCP is defined by IETF RFC 4145 [20] and registered by IANA.

NOTE 3: The IMS AGW does not need to reserve resources for end-to-access edge media (e2ae) security en-/decryption at this stage if RTP profile identifiers "RTP/SAVP" or "RTP/SAVPF" are signalled without the "a=crypto" property for that stream. For e2e media security either "RTP/SAVP" is signalled at all terminations in a context, or "RTP/SAVPF" is signalled at all terminations in a context and no media attribute will be signalled; the IMS AGW shall then not terminate the SRTP / SRTCP protocol, but shall pass the encrypted media and control flows (as indicated with the rtcph/rsb property) transparently.

NOTE 4: Parameter "TCP/TLS" is defined by IETF RFC 8122 [55] for the TLS protocol according to 3GPP TS 33.210 [27].

NOTE 5: Parameter "UDP/DTLS" is introduced by IETF draft-schwarz-mmusic-sdp-for-gw [54] (based on ITU-T Recommendation H.248.93 [50]).

NOTE 6: Conditional support, dependent on application-aware interworking.

NOTE 7: Codepoint used for e.g. "UDP payload transparent forwarding" (such as DTLS-encrypted end-to-end WebRTC bearer traffic).