E.2.4 CS network originated session

29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS

E.2.4.1 Interactions between SIP/SDP and H.245 or MONA

E.2.4.1.1 Normal Call setup

Figure E.2.4.1.1 shows examples of interactions between H.245 or MONA and SIP/SDP for the CS network originated session. Most SIP and ISUP or BICC messages are intentionally omitted, since the SDP may be embedded in various SIP messages and since the in‑band H.245 Messages are not tightly coupled with out-of-band ISUP or BICC messages.

NOTE: Messages 3 and 5 may be combined in some scenarios.

Figure E.2.4.1.1: Interactions between H.245 and SIP/SDP for CS network originated session

Upon receipt of an IAM request for a multimedia Call (signal 1 in figure E.2.4.1.1) the Interworking Node (consisting of MGCF and IM-MGW) starts the call set-up for multimedia call at the IM CN subsystem side by sending an INVITE request (signal 2 in figure E.2.4.1.1). For the INVITE request, the Interworking Node selects codecs supported by the IM-MGW and likely to be supported within the CS Network. The Interworking Node should select the H.263 codec and may select other codec in addition. The interworking node should add a b:AS bandwidth modifier with a bandwidth suitable for the selected codec(s), but not higher than 64kbit/s plus RTP/UDP/IP overhead, in the SDP offer to request that the peer does not send media with a higher bandwidth.

NOTE: The SDP coding to express that either a combined voice and video call, or a voice call, or a Clearmode codec, or some other data call is desired is not defined in the present release.

The Interworking Node shall engage in an H.223 bearer setup (step 7 in figure E.2.4.1.1). If the interworking Node supports MONA (Media Oriented Negotiation Acceleration), it shall first attempt a MONA Channel establishment method negotiation according to Annex K of ITU-T Recommendation H.324 [81]. If the interworking node does not support MONA, it shall use the multiplexing level negotiation procedures of Annex C of H.324 [81]. If the Interworking Node supports MONA, but the remote peer does not do so, a fallback to the multiplexing level negotiation procedures of Annex C of H.324 [81] will occur.

If both the Interworking Node and the remote CS terminal support MONA procedures, the MONA procedures as per ITU-T Recommendation H.324 [81] Annex K may be used to replace the H.245 negotiation (signals 8, 11 and 12) as shown in figure E.2.4.1.1. Furthermore, the SIP codec renegotiation in signals 9 and 10 is then also not applicable.

If MONA procedures are not used, the following applies:

– After the completion of the H.223 bearer setup at the CS side the Interworking Node will receive a H.245 Terminal Capability Set message describing the supported Codecs at the peer’s side (signal 8 in figure E.2.4.1.1).

– Due to information received in a Terminal Capability Set message (signal 8 in figure E.2.4.1.1), the Interworking node may send an SDP offer at the IMS side (signal 9 in figure E.2.4.1.1), to offer additional codecs supported at the CS side but not contained in the first SDP offer (signal 2 in figure E.2.4.1.1), or to restrict the selected codecs at the IMS side to codecs which are available at the CS side.

NOTE: It is not clear if the addition of codecs not included in previous SDP exchange has any impacts on IMS procedures, e.g. resource reservation related procedures.

– The Interworking Node shall send a Terminal Capability Set message describing its own capabilities (signal 11 in figure E.2.4.1.1). Unless the Interworking Node supports transcoding, the Interworking node shall only send codecs that are also negotiated at the IM CN subsystem side (as received in signal 3 in figure E.2.4.1.1) within this message. The Interworking Node may defer sending the Terminal Capability Set message for some time to attempt to receive the peer’s Terminal Capability set message and perform a possible IMS-side codec re-negotiation. However, to avoid blocking situations, the Interworking Node shall not defer sending the Terminal Capability Set message for an excessive period of time.

– The codecs contained both in the sent and received Terminal Capability Set message may be selected at the CS side. The final decision of the selected codecs at the CS side is taken when the H.245 open logical Channels message (signal 12 in figure E.2.4.1.1) is sent or received. The direction of this message is determined by the procedure in H.245 [82] Annex C.2.

If the Interworking Node does not transcode, it should indicate the codecs selected within the H.245 negotiation or within MONA procedures after the completion of the H.245 negotiation (signal 13 in figure E.2.4.1.1) or MONA procedures.

The interworking node should include in Step 11 of figure E.2.4.1.1 the SDP "a" attribute "3gpp_MaxRecvSDUSize" indicating the maximum SDU size of the application data that can be transmitted to the receiver without segmentation, as specified in clause 12.2.4.6 of 3GPP TS 26.114 [104].

E.2.4.1.2 Call setup if multimedia call can not be recognized in an unambiguous manner

If the Interworking Node is not able to determine from the information within the IAM request whether a multimedia call or some other type of data call is requested (for example, if only TMR=UDI but no BC IE is contained in the IAM), the Interworking Node may also include appropriate codecs for other possible types of data call it supports in the INVITE request. If video and audio codecs are contained in the first SDP answer (signal 3), the Interworking Node should continue to attempt to set up a multimedia call as described in clause E.2.4.1.1. Otherwise, calls are set up as described in clause 7.2.3.2.

E.2.4.1.3 Fallback to speech during call setup

The called party can reject the video component in the SDP offer (signal 2 in figure E.2.4.1.1) by returning an SDP answer where the video related m-line is disabled (in signal 3 in figure E.2.4.1.1).

If the MGCF receives an SDP answer during call setup where the video related m-line is disabled, it shall react as follows:

– If the MGCF has received a SCUDIF call setup from the CS side (MuMe and speech codecs in IAM message, see 3GPP TS 23.172 [121]), the MGCF shall apply a SCUDIF fallback to speech on the CS side. The MGCF shall use a speech codec as Selected Codec and exclude the MuMe codec from the available codec list.

– If the MGCF has received a multimedia call setup without SCUDIF from the CS side, and the CS network supports CS fallback, the MGCF should terminate the call.

NOTE 1: A call termination can trigger the caller’s device to set up a new speech call.

NOTE 2: Other procedures to maintain the CS call, e.g. disabling the video component on the CS side or providing a suitable video announcement and discarding received video media from the CS side, are FFS.

E.2.4.2 CS originated – IM CN transit – CS terminated

Figure E.2.4.2.1 describes ISUP and SIP/SDP interactions in a CS originated – IM CN transit – CS terminated case with a clear channel through the IM CN. An interworking node A receives an IAM message with a UDI H.223 & H.245 video call request (message 1). If the interworking node A supports both CS/IMS video interworking and a clearmode codec / clear channel, it may send both audio and video codecs and a clearmode codec and a UDI & H.223 & H.245 video indication in the INVITE message towards the IMS (message 2). The message is received by an interworking node B. The interworking node B sends an IAM message with a UDI & H.223 & H.245 video call request to the terminating CS network (message 3). If the interworking node B supports a clearmode codec / clear channel, it may send a SIP response with a clearmode codec towards the calling side to indicate that a clear channel can be established between the IMS interworking nodes (message 5). After the called party answers, the interworking node B sends a SIP 200 OK (Invite) with the clearmode codec to the calling node to indicate that a clear channel can be established (message 11). After the called party has answered the call, either MONA procedures are performed and the H.223 bearer is established or the H.223 bearer is established and the H.245 signalling is performed (step 14 in figure E.2.4.2.1).

If the interworking node A does not support CS-IMS video interworking, but supports a clearmode codec / clear channel, it sends the INVITE message with a clearmode codec and UDI & H.223 & H.245 indication, but without a video codec, to allow the establishment of a CS video call through a clear channel. The interworking node A may also send an audio codec (alone or with a clearmode codec) to allow a fallback to speech. The interworking node B either accepts the clearmode and sends the corresponding IAM message with a UDI & H.223 & H.245 request (message 3) and SIP response with a clearmode codec (message 5 or 11), or accepts the speech mode and sends the corresponding IAM message with a speech request (message 3) and SIP response with a speech codec (messages 5, 11), or rejects the INVITE message if the requested codec(s) cannot be supported.

The format of the indication of UDI & H.223 & H.245 from interworking node A to interworking node B is defined in Annex F "PSTN XML Scheme". UDI & H.223 & H.245 indication is conveyed in PSTN XML body within "BearerCapabilty" ("InformationTransferCapability" and "UserInfoLayerProtocol") and "LowLayerCompatibility" elements. Elements are defined in ETSI EN 300 403‑1 (V1.3.2) [96] clause 4.5.5 and in ISUP transported in the ATP is in Q.761-Q.764 [4] clause 3.5.

Figure E.2.4.2.1: ISUP and SIP/SDP interactions in a CS originated – IM CN transit
– CS terminated case with a clear channel through the IM CN