Tech-invite3GPPspaceIETF RFCsSIP

Content for  TS 23.231  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   4.4.2   4.4.3   4.4.4   4.4.5…   6…   6.1.2…   6.2…   6.2.2…   7…   7.2.3   7.2.4…   7.3…   8…   9…   13…   14…   15…


9  Compatibility Issuesp. 48

9.1  Compatibility Issues for Nc Interfacep. 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 Interfacep. 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 Proceduresp. 48

11  Identitiesp. 49

11.1  Telephone numbering schemesp. 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 Identityp. 49

11.3  Sub-addressingp. 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 Aspectsp. 50

12.1  Chargingp. 50

No impacts.

12.2  SIP session continuityp. 50

12.2.1  Use of SIP session timerp. 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 flowp. 50

Figure 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).
Copy of original 3GPP image for 3GPP TS 23.231, Fig. SIP Session Timer
Figure SIP Session Timer
(⇒ copy of original 3GPP image)

Up   Top   ToC