E.2.3 IM CN subsystem originated session

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

E.2.3.1 Preconditions used at IMS side

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

Figure E.2.3.1.1.1 shows examples of interactions between H.245 or MONA procedures and SIP/SDP for IM CN subsystem 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.

Figure E.2.3.1.1.1 assumes that the IMS peer uses the SIP precondition extension to indicate that preconditions have not yet been met.

Figure E.2.3.1.1.1: Interactions between H.245 and SIP/SDP for IM CN subsystem originated session
IMS peer indicates unmet local preconditions

Upon receipt of a SIP INVITE request containing speech and video Codecs (signal 1 in figure E.2.3.1.1.1) the Interworking Node (consisting of MGCF and IM-MGW) starts the call set-up for multimedia call at the CS side by sending an IAM requesting an UDI bearer (signal 2 in figure E.2.3.1.1.1).

If SDP local preconditions, which are not yet met, are contained in signal 1, the Interworking node should immediately send an SDP answer to allow for the IMS-side bearer set-up to progress. The Interworking node selects codecs supported by the IM-MGW and likely to be supported within the CS network and communicates the selected codecs towards the IMS side within an SDP answer message (signal 3 in figure E.2.3.1.1.1). If theses codecs are contained in the SDP offer, the Interworking Node should select the H.263 codec and may select other codec from the SDP offer in addition. The interworking node should include 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 answer to request that the peer does not send media with a higher bandwidth.

The Interworking Node shall engage in an H.223 bearer setup (step 6 in figure E.2.3.1.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 Annex K [81] may be used to replace the H.245 negotiation (signals 7 – 9) as shown in figure E.2.3.1.1.1.

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 shall send a Terminal Capability Set message describing its own capabilities (signal 7 in figure E.2.3.1.1.1). Unless the Interworking Node supports transcoding, the Interworking Node shall only send codecs that have been offered at the IM CN subsystem side (as received in signal 1 in figure E.2.3.1.1.1) within this message.

– The Interworking Node will receive an H.245 Terminal Capability Set message describing the supported Codecs at the peer’s side (signal 8 in figure E.2.3.1.1.1).

– The codecs contained both in the sent and received terminal capability set messages 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 9 in figure E.2.3.1.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 (signal 11 in figure E.2.3.1.1.1) or within the MONA procedures and enable any media that have previously been put on hold at the IMS side after the completion of the H.245 negotiation or MONA procedures.

The interworking node should include in step 11 of figure E.2.3.1.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.3.2 Preconditions not used at IMS side

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

Figure E.2.3.2.1.1 shows examples of interactions between H.245 or MONA procedures and SIP/SDP for IM CN subsystem 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.

Figure E.2.3.2.1.1 assumes that the IMS peer does not use the SIP precondition extension.

Figure E.2.3.2.1.1 Interactions between H.245 and SIP/SDP for IM CN subsystem originated session
IMS peer does not use SIP preconditions

Upon receipt of a SIP INVITE request containing speech and video Codecs (signal 1 in figure E.2.3.2.1.1) the Interworking Node (consisting of MGCF and IM-MGW) starts the call set-up for multimedia call at the CS side by sending an IAM requesting an UDI bearer (signal 2 in figure E.2.3.2.1.1).

If no unmet local SDP preconditions are contained in signal 1, the Interworking node should defer sending an SDP answer until the H.245 negotiation or MONA procedures is/are completed.

The Interworking Node shall engage in an H.223 bearer setup (step 5 in figure E.2.3.2.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 Recommenation H.324 [81] Annex K may be used to replace the H.245 negotiation (signals 6 – 8) as shown in figure E.2.3.2.1.1.

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 shall send a Terminal Capability Set message describing its own capabilities (signal 6 in figure E.2.3.2.1.1). Unless the Interworking Node supports transcoding, the Interworking Node shall only send codecs that have been offered at the IM CN subsystem side (as received in signal 1 in figure E.2.3.2.1.1) within this message.

– The Interworking Node will receive an H.245 Terminal Capability Set message describing the supported Codecs at the peer’s side (signal 7 in figure E.2.3.2.1.1).

– 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 8 in figure E.2.3.2.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 shall send an SDP answer (signal 9 in figure E.2.3.2.1.1) indicating the codecs selected within the H.245 negotiation or within the MONA procedures after the completion of the H.245 negotiation or MONA procedures. The interworking node should include 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 answer to request that the peer does not send media with a higher bandwidth.

The interworking node should include in Step 9 of figure E.2.3.2.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.3.3 Fallback to speech at session establishment

If SCUDIF Fallback (see 3GPP TS 23.172 [121]) occurs on the CS side, the APM message contains a speech codec as "Selected Codec". The MGCF shall then disable the video "m-line" in the first SDP answer, if not yet sent, and complete the call-setup in the same way as for a normal speech call. If the SDP answer was already sent (precondition used), the MGCF shall update the SIP session to speech by sending a SIP UPDATE message with a relevant SDP.

If in a non-SCUDIF case (ISUP or BICC without SCUDIF) the called CS terminal or network rejects the video call setup by sending a REL message to the MGCF, the MGCF releases the CS video call being established, re-establishes the CS call in a speech only mode sending a new IAM with a speech BCIE to the CS network and updates the IM CN leg codecs to a speech only codec. Then the call/session continues as in a speech only case. If the interworking node does not support the fallback, it shall release the session.