Content for TS 23.334 Word version: 18.1.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.14 Multimedia Priority Service (MPS) Support 5.15 Coordination of Video Orientation 5.16 Generic image attributes 5.17 TCP bearer connection control 5.17.1 Stateless TCP handling 5.17.2 State-aware TCP handling 5.17.2.1 General 5.17.2.2 State-aware TCP handling without support of modifying the TCP setup direction 5.17.2.3 State-aware TCP handling with support of modifying the TCP setup direction
...

5.14 Multimedia Priority Service (MPS) Support |R11| p. 61

The Multimedia Priority Service (MPS) is specified in TS 22.153. The IMS-ALG and IMS-AGW may support the priority treatment of a call/session identified as an MPS call/session. If MPS is supported, the following functional requirements apply:

Upon receipt of the MPS priority information in the call control signalling:
The IMS-ALG shall recognise the call/session as having priority.
The IMS-ALG shall send the priority information for a context to the IMS-AGW to enable the priority treatment described below related to the IMS-AGW.
The IMS-ALG shall apply priority handling to H.248 transactions related to priority calls/sessions when network resources are congested , e.g., preferential treatment in any queues or buffers.
The IMS-ALG may send the updated priority information and, if DiffServ is used, provision a suitable DSCP marking for the updated MPS priority level to the IMS-AGW if it needs to change the priority information previously communicated to the IMS-AGW for an MPS call/session.
If the H.248 control association utilises a transport with the possibility for prioritisation, the IMS-ALG may apply priority using the appropriate prioritisation procedures.
If the MPS Priority service requires a specific MPS DSCP setting the IMS-ALG shall configure the IMS-AGW to apply a specific MPS DSCP marking to the user data transport packets to indicate that the packets are of a higher priority than those for normal calls.
If the IMS-AGW receives an indication to apply a specific MPS DSCP marking to the user data transport packets, it shall apply this DSCP marking to the IP headers.

NOTE 1:
Support of Diffserv procedures by the IMS-AGW assumes an operator uses Diffserv for prioritising user plane traffic related to an MPS call/session.
When the IMS-ALG marks a Context with priority information, the IMS-AGW may use the priority information for selecting resources for the media and signaling transport with priority. The following actions may be taken by the IMS-AGW if it has reached a congested state:
1. seize priority reserved resources; or
2. if resources are congested, indicate that in aCommand Response error code.
NOTE 2:
The Priority information can be used to derive Layer 2 QoS marking and trigger priority identification and priority treatment for other QoS technologies than Diffserv.

5.15 Coordination of Video Orientation |R12| p. 62

The IMS-ALG and the IMS-AGW may support the Coordination of Video Orientation (CVO) as defined in TS 26.114.

If the IMS-ALG receives an SDP body containing "a=extmap" attribute(s), as defined in RFC 5285, and the "a=extmap" attribute(s) contain CVO URN(s) (i.e. the CVO URN for a 2 bit granularity of rotation and/or the CVO URN for a higher granularity of rotation) as defined in TS 26.114, then:

if the IMS-ALG and the IMS-AGW support the CVO feature:
- the IMS-ALG shall include the "extended RTP header for CVO" information element when seizing resources in the IMS-AGW to indicate the IMS-AGW that it shall allow the RTP header extension for CVO to pass; and
  
  Editor's note:
  It is ffs if the IMS-ALG needs to include the "extended RTP header for CVO" information element when seizing terminations of a media agnostic IMS-AGW, or if a media agnostic IMS-AGW always passes any RTP header extension.
- the IMS-ALG shall forward within SIP signalling, the SDP body received from the preceding node with unmodified "a=extmap" attribute(s) to the succeeding node; or
if the IMS-AGW does not support the CVO feature, the IMS-ALG shall forward within SIP signalling, the SDP body received from the preceding node without any "a=extmap" attributes to the succeeding node.

If the IMS-AGW supports the CVO feature and has been instructed to pass on the extended RTP header for CVO as described above for both incoming and outgoing terminations then:

if the IMS AGW does not apply video transcoding, it shall pass any received RTP CVO header extension to succeeding RTP streams; or
if the IMS-AGW applies video transcoding, it shall keep the video orientation unchanged during the transcoding and copy the received RTP CVO header extension to the succeeding outgoing RTP stream(s) after transcoding the associated group of packets.

5.16 Generic image attributes |R12| p. 63

The IMS-ALG and the IMS-AGW may support a media-level SDP image attribute "a=imageattr" defined in RFC 6236 to negotiate the image size for sending and receiving video as required by TS 26.114.

If the IMS-ALG:

supports the negotiation of the image size;
receives an SDP body containing the image attribute(s) "imageattr" defined in RFC 6236; and
does not support or does not apply the video transcoding procedure defined in clause 5.13;

the IMS-ALG shall forward the SDP body with unmodified image attribute(s).

If the IMS-ALG and the IMS-AGW support the ATCF/ATGW functions then during the access transfer procedures the IMS-ALG may apply the procedure described in clause 6.2.14.6 to negotiate and adjust the image size for sending and receiving video of the session.

5.17 TCP bearer connection control |R12| p. 63

5.17.1 Stateless TCP handling p. 63

An IMS ALG and IMS AGW that supports TCP as transport protocol (see RFC 793 and RFC 4145) shall support the following procedures.

When receiving an SDP offer or answer containing a media line for a new TCP based media stream (e.g. with "TCP", "TCP/MSRP" as transport protocol), the IMS ALG:

shall indicate "TCP" (for application-agnostic interworking) or "TCP/MSRP" (for application-aware MSRP interworking) as transport protocol to the IMS AGW;
shall indicate the TCP port numbers received in the SDP from the remote peer as destination port in the remote descriptor at the termination towards the SDP sender;
shall request the IMS AGW to allocate a TCP port number at the destination towards the SDP receiver;
shall replace the TCP port in the received SDP with the TCP port number allocated by the IMS AGW and forward the SDP; and
shall indicate to the IMS AGW to perform TCP stateless handling by not including the TCP session setup direction attribute at the interconnected terminations in the same context.

An IMS AGW receiving an indication of "TCP", or "TCP/MSRP" as transport protocol, but no indication to perform TCP state-aware handling (via information about the directionality of the TCP session setup):

shall send a TCP SYN when receiving a TCP SYN at the interconnected termination in the same context;
shall forward received TCP payload; and
shall use its own port number as TCP source port numbers and the remote port number received from the IMS ALG as TCP destination port numbers and calculate a new TCP checksum for all TCP packets it sends.

5.17.2 State-aware TCP handling p. 64

5.17.2.1 General p. 64

An IMS ALG and IMS AGW that supports TCP as transport protocol (see RFC 793 and RFC 4145) may support the procedures specified in clause 5.17.2 for state-aware TCP handling.

An IMS ALG and IMS AGW that supports state aware TCP handling shall support the procedures specified in clause 5.17.2.2 and may additionally support the procedures specified in clause 5.17.2.3.

5.17.2.2 State-aware TCP handling without support of modifying the TCP setup direction p. 64

When the IMS ALG receives an SDP offer containing a media line for a new TCP based media stream (e.g. with "TCP", "TCP/MSRP" as transport protocol), for that TCP based media stream the IMS ALG:

if no media security is applied, shall indicate "TCP" (for application-agnostic interworking) or "TCP/MSRP" (for application-aware MSRP interworking) as transport protocol to the IMS AGW;
if media security is applied, shall indicate a transport protocol according to clause 5.11 to the IMS AGW;
shall request the IMS AGW to allocate a TCP port at the destination towards the SDP answerer;
shall request the IMS AGW to allocate a TCP port at the destination towards the SDP offerer;
shall indicate the TCP port numbers received in the SDP offer as destination in the remote descriptor at the termination towards the SDP offerer;
shall indicate to the IMS AGW to perform TCP state-aware handling (by indicating the "actpass" TCP session setup direction at both interconnected terminations in the same context in the local descriptor);
if supported by the IMS AGW, may indicate to the IMS AGW for a given termination to use an incoming TCP connection establishment request (TCP SYN) at that termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context;
if supported by the IMS AGW, may indicate to the IMS AGW to discard incoming TCP connection establishment requests; and
shall replace the TCP port in the received SDP offer with the TCP port number allocated by the IMS AGW at the termination towards the SDP answerer, shall maintain a received "a=setup:active" or "a=setup:passsive" SDP attribute (see RFC 4145) in the SDP offer without modification, and shall forward the SDP offer.

When the IMS ALG then receives the SDP answer containing a media line for a new TCP based media stream, for that TCP based media stream the IMS ALG:

shall indicate the TCP port numbers received in the SDP answer as destination in the remote descriptor at the termination towards the SDP answerer;
if supported by the IMS AGW, may indicate to the IMS AGW for a given termination to use an incoming TCP connection establishment request (TCP SYN) at that termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context;
if the IMS ALG did not indicate to the IMS AGW to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context,
- if the SDP answer contains an "a=setup:active" SDP attribute (see RFC 4145), shall indicate to the IMS AGW to start a TCP connection establishment at the termination towards the SDP offerer; and
- if the SDP answer contains an "a=setup:passive" SDP attribute, shall indicate to the IMS AGW to start a TCP connection establishment at the termination towards the SDP answerer;
NOTE 1:
Clients only supporting MSRP according to RFC 4975 will not use the SDP "a=setup" attribute, but will assign the TCP client role to the SDP offerer. However, in 3GPP (Release 8 onwards), OMA and GSMA the support of RFC 6135 is mandated, and the "a=setup" attribute will thus be used.
if the IMS ALG previously indicated to the IMS AGW to discard incoming TCP connection establishment requests, shall indicate to the IMS AGW to process incoming TCP connection establishment requests; and
shall replace the destination TCP port in the received SDP answer with the TCP port number allocated by the IMS AGW at the termination towards the SDP offerer, shall maintain the received "a=setup" SDP attribute (RFC 4145) in the SDP answer without modification, and shall forward the SDP answer.

An IMS AGW receiving an indication of "TCP", or "TCP/MSRP" as transport protocol and an indication to perform TCP state-aware handling (via information about the directionality of the TCP session setup):

if the IMS ALG indicated to start a TCP connection establishment at a given termination, shall start the TCP connection establishment at that TCP termination by sending a TCP SYN;
if the IMS ALG indicated to discard incoming TCP connection establishment requests, shall discard any incoming TCP connection establishment requests (support optional for the IMS AGW);
if
1. the IMS ALG indicated to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context, and
2. the IMS ALG did not indicate to discard incoming TCP connection establishment requests,
shall send a TCP SYN when receiving a TCP SYN at the interconnected termination in the same context (support optional for the IMS AGW);
if
1. the IMS ALG did not indicate to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context, and
2. the IMS ALG did not indicate to discard incoming TCP connection establishment requests, and
3. the IMS ALG already configured the remote IP address and port or requested latching,
shall answer any received TCP SYN at a given termination with appropriate messages according to TCP procedures;
shall forward received TCP payload, performing any required modifications on the TCP payload according to procedures in other parts of this specification; and
shall use its own port number as TCP source port and the remote port number indicated by the IMS ALG as TCP destination port numbers and shall calculate a new TCP checksum for all TCP packets it sends.

5.17.2.3 State-aware TCP handling with support of modifying the TCP setup direction p. 66

The IMS ALG and IMS AGW shall perform the same procedures as in clause 5.17.2.2 with modification according to the present clause.

When the IMS ALG receives an SDP offer containing a media line for a new TCP based media stream (e.g. with "TCP", "TCP/MSRP" as transport protocol), for that TCP based media stream the IMS ALG:

if an "a=setup:active" SDP attribute (see RFC 4145) is received in an SDP offer towards a served UE that is possibly behind a remote NAT, the IMS ALG
- should replace this attribute with a "a=setup:actpass" or "a=setup:passive" SDP attribute; and
- shall then not indicate to the IMS AGW to use the incoming TCP connection establishment request (TCP SYN) at the termination towards the offerer as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context towards the answerer;
if an "a=setup:active" SDP attribute (see RFC 4145) is received in an SDP offer from a served UE, the IMS ALG
- may replace this attribute with a "a=setup:actpass" SDP attribute; and
- shall then not indicate to the IMS AGW to use the incoming TCP connection establishment request (TCP SYN) at the termination towards the answerer as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context towards the offerer;
NOTE 1:
Clients only supporting MSRP according to RFC 4975 will not use the SDP "a=setup" attribute, but will assign the TCP client role to the SDP offerer. However, in 3GPP (Release 8 onwards), OMA and GSMA the support of RFC 6135 is mandated, and the "a=setup" attribute will thus be used.
shall indicate to the IMS AGW to perform TCP state-aware handling, either by indicating the "actpass" TCP session setup direction at both interconnected terminations in the same context in the local descriptors, or by indicating the "passive" TCP session setup direction at both interconnected terminations in the same context.

When the IMS ALG then receives the SDP answer containing a media line for a new TCP based media stream, for that TCP based media stream the IMS ALG:

if
1. the IMS ALG received an "a=setup:active" SDP attribute in the SDP offer, and
2. the SDP answer containes an "a=setup:active" SDP attribute,
then
- if the IMS ALG previously indicated "actpass" TCP session setup direction at both interconnected terminations to the IMS AGW, shall indicate to the IMS AGW the "passive" TCP session setup direction at both interconnected terminations in the same context in the local descriptors, and
- shall replace the "a=setup:active" SDP attribute in the SDP answer with an "a=setup:passive" SDP attribute before forwarding the answer.
if
1. the IMS ALG received an "a=setup:active" SDP attribute in the SDP offer, and
2. the SDP answer containes an "a=setup:passive" SDP attribute,
then
- if the IMS ALG previously indicated "passive" TCP session setup direction at both interconnected terminations to the IMS AGW, shall indicate to the IMS AGW the "actpass" TCP session setup direction at both interconnected terminations in the same context in the local descriptors, and
- shall retain the "a=setup:passive" SDP attribute in the forwarded SDP answer;
if the IMS ALG did not indicate to the IMS AGW to use the incoming TCP connection establishment request (TCP SYN) at one termination as a trigger for sending a TCP connection establishment request at the interconnected termination in the same context,
- if the sent SDP answer towards the offerer contains an "a=setup:active" SDP attribute (RFC 4145), indicate to the IMS AGW to start a TCP connection establishment at the termination towards the SDP offerer; and
- if the received SDP answer contains an "a=setup:passive" SDP attribute, indicate to the IMS AGW to start a TCP connection establishment at the termination towards the SDP answerer.
When the IMS ALG indicated a "passive" TCP setup direction for a termination, the IMS-AGW shall wait for an incoming TCP connection establishment at that termination and shall not start a TCP connection establishment on its own.