Content for TS 23.231 Word version: 17.0.0
9 Compatibility Issues
10 General (G)MSC server-MGW Procedures
11 Identities
12 Operational Aspects
...
...
9 Compatibility Issues p. 48
9.1 Compatibility Issues for Nc Interface p. 48
A Release 8 (or later) (G)MSC-S implementing a SIP-I based Nc interface, according to 3GPP TS 23.231, is backward compatible with a Release 7 (or earlier) (G)MSC-S or (G)MSC by implementing the interworking procedures defined in TS 29.235.
9.2 Compatibility Issues for Mc Interface p. 48
A Release 8 (or later) (G)MSC-S implementing a SIP-I based Nc interface, according to 3GPP TS 23.231, shall be deployed with a Release 8 (or later) MGW implementing at least Version 4 of the 3GPP Mc Profile Name "Threegbicsn" defined in TS 29.232.
10 General (G)MSC server-MGW Procedures p. 48
10.1 MGW Unavailable p. 48
10.2 MGW Available p. 48
10.3 MGW Recovery p. 48
10.4 (G)MSC server Recovery p. 48
10.5 MGW Re-register p. 48
10.6 MGW Re-registration Ordered by (G)MSC server p. 48
10.7 Removal from Service of a Physical Termination p. 48
10.8 Restoration to Service of a Physical Termination p. 49
See clause 10.8 of TS 23.205..
10.9 Audit of MGW p. 49
10.10 MGW Capability Change p. 49
10.11 (G)MSC Server Out of service p. 49
10.12 MGW Resource Congestion Handling - Activate p. 49
10.13 MGW Resource Congestion Handling -Indication p. 49
10.14 Control association monitoring p. 49
10.15 Hanging termination detection p. 49
11 Identities p. 49
11.1 Telephone numbering schemes p. 49
(G)MSC-Servers shall support the receipt of Tel-URI and SIP URI (user=phone) and the sending of Tel-URI. The sending of SIP URI (user=phone) may be supported as an option. Both global and local telephone numbering formats shall be supported as per RFC 3966.
11.2 (G)MSC Server Identity p. 49
11.3 Sub-addressing p. 49
When using a Tel URI or a SIP-URI, the "isub" parameter defined within RFC 3966 may be used to include the ISDN sub-address as may be required within the MSISDN. See TS 23.003. When the "isub" parameter is present, the "isub-encoding" parameter defined within RFC 4715 shall be used to define the ISDN subaddress encoding type.
The procedures specified within ITU-T Q.1912.5 [9] Annex B.5 for profile C shall be applied for Sub-addressing.
12 Operational Aspects p. 50
12.1 Charging p. 50
No impacts.
12.2 SIP session continuity p. 50
12.2.1 Use of SIP session timer p. 50
The basic SIP as defined by RFC 3261 does not include a "keep alive" mechanism. As such, it is possible that one end of a session may fail and be unable to signal the release of the session. One possible scenario where this may occur is in the cases where an internal fault on a remote node results in the call instance being lost on the remote node. This would result in no further signalling from the remote node associated with that call instance. The local node would have no indication from the remote node should that party release the call.
(G)MSC Servers may support the SIP Session Timer as specified in RFC 4028 as a means to determine whether a SIP session is still active by attempting to perform a session refresh, and therefore as a means to know when resources may be released if one end of the session fails.
The procedure negotiates the rate at which the session refresh occurs. The procedure is compatible and still operational should the far end or other SIP entity not support the Session Timer procedure.
12.2.2 Example call flow p. 50
Figure 12.2.2.1 shows a message sequence example for the optional use of the SIP Session Timer procedures. During call origination each MSC Server may negotiate the use of the SIP Session Timer. This is accomplished through the exchange of the Session-Expires and Min-SE SIP header in the INVITE request and 2xx response. Support of the session timer extension procedure is indicated by placing the "timer" tag in the Supported header in the INVITE request. The use of session continuity and the session expiration timer value may be negotiated independently between each MSC Server pair. The session refresh request may be either an INVITE request or UPDATE request. The use of the UPDATE request does not require the exchange of SDP and is recommended by RFC 4028.
When a failure of the session continuity is detected, the call will be cleared by the MSC servers independently on either side of the failure point according to the normal call clearing procedures (see clause 7).
