Content for TS 23.334 Word version: 17.2.0

1… 4… 5… 5.11… 5.12… 5.14… 5.18… 5.19… 5.20… 5.21… 6… 6.1.6… 6.1.11… 6.2… 6.2.10… 6.2.10.3.1.2 6.2.10.3.2 6.2.10.4… 6.2.10.4.3… 6.2.10.5 6.2.10.6… 6.2.10A… 6.2.13… 6.2.14… 6.2.14.3 6.2.14.4… 6.2.15… 6.2.17… 6.2.17.3… 6.2.17.5… 6.2.18… 6.2.20 6.2.21… 6.2.22… 6.2.22.3… 6.2.22.3.2 6.2.23 6.2.24 6.2.25 7 8… 8.3 8.4 8.5… 8.23…

5.1 General 5.2 Gate Control & Local NAT 5.3 IP realm indication and availability 5.4 Remote NAT traversal support 5.5 Remote Source Address/Port Filtering 5.6 Traffic Policing 5.7 Hanging Termination Detection 5.8 QoS Packet Marking 5.9 Handling of RTCP streams 5.10 Media Inactivity Detection
...

5 Functional Requirements p. 18

5.1 General p. 18

A single IMS-ALG may control one or multiple IMS-AGW(s).

5.2 Gate Control & Local NAT p. 18

The IMS-ALG shall provide the NAPT control function, i.e. obtain the address binding information (according to RFC 2663) and perform the NAPT policy control along with gate control (i.e. instruct the opening/closing of a gate).

The IMS-ALG shall request the IMS-AGW to allocate transport addresses/resources to enable media to traverse the IMS-AGW. The IMS-ALG may indicate the corresponding IP realm to the IMS-AGW - see clause 5.3. The IMS-AGW shall provide the corresponding external transport addresses to the IMS-ALG.

Terminations for the Iq interface may be pre-defined with different levels of granularity for specific IP ports, interfaces, or groups of interfaces. These may then be defined as an IP realm (see clause 5.3) known by both the IMS-ALG and the IMS-AGW, however IP Realms may also be defined for multiple physical interfaces. In order to efficiently report a failure affecting a large number of terminations associated to specific physical interfaces, the IMS-AGW shall, when allocating a new termination, return to the IMS-ALG an associated Interface ID.

An IMS-AGW not supporting this procedure may allocate the same Interface ID for all IP terminations.

An IMS-AGW supporting the Termination Out-of-Service procedure (see clause 6.1.15) shall maintain a local mapping of Interface ID to its internal resources.

The IMS-AGW shall provide the NAPT enforcement function, i.e. change the address and port number of the media packets as they traverse the IMS-AGW, along with gate control (i.e. open/close a gate under the control of the IMS-ALG).

The IMS-AGW may provide IP version interworking. If the IP version interworking is performed and the IMS-ALG passes an SDP offer or answer, the IMS-ALG may adjust any SDP bandwidth information contained in the SDP offer or answer in accordance with clause 9.1.5 of TS 29.162.

The IMS-ALG shall request the IMS-AGW to release its transport resources at the end of a session.

5.3 IP realm indication and availability p. 18

The IMS-ALG and the IMS-AGW shall support IP realm indication.

The IMS-ALG, when requesting the allocation of transport resources at the IMS-AGW, may indicate the correspondent IP realm to the IMS-AGW. The IMS-AGW shall assign the IP termination in the IP realm indicated. The same IP realm shall be applied to all media streams associated with the termination. The IP realm identifier cannot be changed after the initial assignment.

A default IP realm may be configured such that if the IMS-AGW has not received the IP realm identifier and the IMS-AGW supports multiple IP realms then the default IP realm shall be used.

In order to prevent the IMS-ALG requesting an unavailable IP Realm, the IMS-ALG may audit the list of currently available realms on the IMS-AGW and may request the IMS-AGW to report any changes to that list as they occur over time.

The monitoring of IP realm availability is optional and if supported by IMS-AGW may be requested by the IMS-ALG.

5.4 Remote NAT traversal support p. 19

The IMS-ALG and the IMS-AGW shall support remote NA(P)T traversal support using procedures according to the present clause. In addition they may support remote NA(P)T traversal support using Interactive Connectivity Establishment (ICE) according to clause 5.17.

The IMS-ALG is responsible for determining whether there is a remote NAT device (the mechanism by which this achieved is out of scope of the current document).

If a remote NAT device is present, the IMS-ALG shall request the IMS-AGW to perform latching or re-latching when requesting the IMS-AGW to reserve transport addresses/resources.

If remote NAT is applicable, the IMS-AGW shall not use the remote media address/port information (supplied by the IMS-ALG) as the destination address for outgoing media. Instead, the IMS-AGW shall dynamically learn the required destination address via the source address/port of incoming media. This mechanism is known as "latching".

When remote NAT Traversal is applied to a stream associated with multiple flows (e.g. RTP and RTCP), the IMS-AGW shall perform individual latching and/or re-latching on the various flows. This means that an RTP and an RTCP flow of a single stream can be latched to different remote addresses and/or ports.

5.5 Remote Source Address/Port Filtering p. 19

The IMS-ALG may support and the IMS-AGW shall support policing of the remote source address/port of incoming media flow(s).

The IMS-ALG may determine that the source address/port of received media packets should be policed.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that policing of source address and/or port of received media packets is required.

If such policing is applicable, the IMS-AGW shall check the source address and/or port of all received media packets and silently discard any packets that do not conform to the expected source address and/or port.

5.6 Traffic Policing p. 19

The IMS-ALG may support traffic policing of incoming media flows.

The IMS-AGW shall support traffic policing of the maximum average bitrate, defined as sustainable data rate (see RFC 2216) of incoming media flows and may support traffic policing of the peak data rate of incoming media flows.

The IMS-ALG may require the IMS-AGW to police the media flows to ensure that they conform to the expected data rates.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that policing of the related media streams is required and provide traffic policing related parameters as detailed in clause 6.2.5.

If such policing is requested, the IMS-AGW shall police the corresponding media streams as detailed in clause 6.2.5 by measuring the data rate for the received packets within that media stream. If the permissible data rate provided by the IMS-ALG is exceeded, the IMS-AGW shall discard packets to reduce their data rate to the permissible data rate.

For RTP flows where RTCP resources are reserved together with the RTP resources (see clause 5.9), the permissible data rate shall include the bandwidth used by RTP and RTCP together.

5.7 Hanging Termination Detection p. 20

The IMS-ALG and the IMS-AGW shall support detection of hanging termination.

The IMS-ALG, when requesting the IMS-AGW to reserve an AGW connection point, shall indicate to the IMS-AGW to perform detection of hanging terminations.

The IMS-AGW shall determine a termination to be hanging if there is no signalling sent/received within a specified period.

On being informed of the hanging termination, the IMS-ALG shall check/determine whether the cited termination is valid and initiate any appropriate corrective action, e.g. release an invalid termination.

5.8 QoS Packet Marking p. 20

The IMS-ALG may support and the IMS-AGW shall support control via the Iq interface of the setting of the DiffServ Code Point (DSCP) for media packets sent on a termination.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that the DSCP of outgoing media packets shall be explicitly set or copied from the DSCP of the corresponding received packet.

If such modification of the DSCP is required by the IMS-ALG, the IMS-AGW shall set the DSCP for outgoing packets on a termination.

5.9 Handling of RTCP streams p. 20

5.9.1 General |R14| p. 20

The IMS-ALG and the IMS-AGW shall support control via the Iq interface of the specific RTCP behaviour associated to an RTP flow.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for an RTP flow, the IMS-ALG should also request the IMS-AGW to reserve resources for the corresponding RTCP flow, but may alternatively request the IMS-AGW not to reserve resources for the corresponding RTCP flow. When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for a non-RTP flow, the IMS-ALG shall not request the IMS-AGW to reserve resources for an RTCP flow.

To request the IMS-AGW to reserve resources for an RTCP flow, the IMS ALG shall provide the RTCP handling information element with a value indicating that resources for RTCP shall be reserved.

To request the IMS-AGW not to reserve resources for an RTCP flow, the IMS ALG shall either provide the RTCP handling information element with a value indicating that resources for RTCP shall not be reserved or omit the RTCP handling information element.

If the IMS-AGW receives the indication to reserve RTCP resources, the IMS-AGW shall allocate a local port with even number for an RTP flow and shall allocate the consecutive local port with odd number for the associated RTCP flow, and it shall send and be prepared to receive RTCP packets.

If the IMS-AGW receives the indication to not reserve RTCP resources, or if it does not receive any indication at all, it shall not allocate an RTCP port when allocating a port for an RTP flow. The IMS-AGW shall not send any RTCP packets and shall silently discard any received RTCP packets.

When RTCP resources are requested, the IMS-ALG may also specify:

the explicit RTCP transport address information element containing the remote RTCP port, and optionally the remote address, where to send RTCP packets; if not specified, the IMS-AGW shall send RCTP packets to the port contiguous to the remote RTP port; and
bandwidth allocation requirements for RTCP, if the RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556.

The explicit RTCP transport address information element contains the "a=rtcp" SDP attribute (as specified in RFC 3605) received within the SDP body. The explicit RTCP transport address information element is only allowed for remote endpoints and shall not be used for the local endpoint. When the IMS-ALG requests the IMS-AGW to reserve resources for an RTCP flow and provides in addition the explicit RTCP port information element, then the IMS-AGW shall use this network address and transport port as destination when sending RTCP packets towards the remote endpoint.

The IMS-AGW shall return an error if it can not allocate the requested RTCP resources.

5.9.2 RTP/RTCP transport multiplexing |R14| p. 21

The procedure in clause 5.9.1 describing the default case of RTP/RTCP transport non-multiplexed scenarios may be extended for the transport multiplexed mode by addition of the RTP/RTCP transport multiplexing information element to indicate to the IMS-AGW that RTP and RTCP traffic shall be multiplexed on a single port (as described in RFC 5761). The RTP/RTCP transport multiplexing information element may only be sent to the IMS-AGW in combination with the RTCP handling information element with the value indicating that resources for RTCP shall be reserved. The support of these procedures is optional for the IMS ALG and the IMS-AGW. The IMS-ALG shall only use these procedures when knowing support at IMS-AGW side (e.g., via configuration management).

The usage is conditional, given by following restrictions:

The transport multiplexed mode may be only supported for terminations at the access network side of the IMS-AGW.
The transport multiplexed mode shall be only enabled for the local connection endpoint if agreed via SIP SDP offer/answer negotiation with the served UE using:
- the "a=rtcp-mux" SDP attribute, see RFC 5761, as updated by RFC 8035; and/or
- the "a=rtcp-mux-only" SDP attribute, see RFC 8858.
  
  NOTE 1:
  Usage of an "rtcp-mux-only" attribute in an SDP answer is forbidden, see RFC 8858. If the associated SDP answer does not contain an SDP "rtcp-mux" attribute, the offerer (the IMS ALG or the UE) needs to disable the associated RTP based media by sending a new SDP offer:
  - with a zero port value associated with the SDP media description ("m=" line); or
  - without associating an SDP "rtcp-mux-only" attribute with the SDP media description ("m=" line).
When transport multiplexed mode is agreed with the served UE, then it may be applied in both traffic directions.

5.10 Media Inactivity Detection p. 21

The IMS-ALG and the IMS-AGW may support the detection of inactive media flows.

The IMS-ALG may require an IMS-AGW that supports media inactivity detection to detect if a media flow is inactive.

When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources, the IMS-ALG may indicate to the IMS-AGW that detection of an inactive media flow is required and may additional specify inactivity detection time and inactivity detection direction.

The IMS-AGW shall determine a media flow on termination to be inactive if there is no media sent and/or received within the inactivity detection time period.

On being informed of the inactive media, the IMS-ALG shall initiate any appropriate corrective action.