E.2 INFO package for transfer of state-and-event info

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

E.2.1 Scope

This annex defines an info package in accordance with IETF RFC 6086 [54] for sending state and event information during PS to CS SRVCC access transfer using SIP INFO requests.

E.2.2 state-and-event info package

E.2.2.1 General

This subclause contains the information required for the IANA registration of an info package.

E.2.2.2 Overall description

When PS to CS SRVCC access transfer from PS to CS access is applied for a session with an active full duplex speech component and the related dialog is in early state there is a need to deliver state information from an SCC AS to an MSC server. Further it is requested that an MSC server supporting PS to CS SRVCC for calls in alerting phase informs the SCC AS about a UE having accepted a terminating call.

E.2.2.3 Applicability

This package is used to transport session state information and related event information when a session in alerting phase is transferred from PS to CS using SRVCC access transfer procedures.

The mechanism allows that information about the session that is subject to PS to CS SRVCC and related events to be sent inside an existing dialog due to the session transfer SIP INVITE request.

E.2.2.3A Appropriateness of INFO Package Usage

A number of solutions for the transportation of event and state related information between the SCC AS (a B2BUA) and MSC server (a UA). The solutions considered were:

1. Use of session related SIP methods for transporting event and state information, e.g. SIP 183 response, SIP UPDATE request.

2. Use of subscription to the dialog-event package as described in IETF RFC 4325.

3. Use of SIP MESSAGE method.

4. Use of media plane mechanisms.

5. Use of SIP INFO method as decribed in IETF RFC 6086, by defining a new info package.

Furthermore, each of the solutions was evaluated.

The use of session related SIP methods was discounted as it was concluded that bodies should not be included in SIP responses and the SIP UPDATE method is not appropriate since the session is not modified.

The use of the dialog-event package was discounted for the following reasons:

a) When an access transfer needs to occur, the MSC server sends a particular SIP INVITE request to the SCC AS to initiate the access transfer of the dialog-to-be-transferred. Upon reception of the particular SIP INVITE request, the SCC AS ensures that the media of the session supported by the dialog-to-be-transferred are redirected from an original UA served by SCC AS to the MSC server. The access transfer procedure requires the MSC server to be aware of the state related information of the dialog-to-be-transferred. This can be provided implicitly or explicitly to the MSC server. When the dialog-to-be-transferred happens to be a confirmed dialog, the SCC AS implicitly informs the MSC server about the state related information of the dialog-to-be-transferred by accepting the particular SIP INVITE request. When the dialog-to-be-transferred happens to be an early dialog, the access transfer procedure requires the SCC AS to explicitly provide the state related information of the dialog-to-be-transferred to the MSC server. In the majority of cases of access transfer, the dialog-to-be-transferred will be a confirmed dialog. If the MSC server sent the SIP SUBSCRIBE request before sending the particular SIP INVITE request, then the MSC will receive the state related information of the dialog-to-be-transferred explicitly in the majority of cases when such explicit information is not required.

b) If the MSC server sent the SIP SUBSCRIBE request before sending the particular SIP INVITE request, then four messages (a SIP SUBSCRIBE request, a SIP 2xx response to the SIP SUBSCRIBE request, a SIP NOTIFY request, a SIP 2xx response to the SIP NOTIFY request) would be exchanged between the MSC server and the SCC AS. In comparison, zero messages (if the dialog-to-be-transferred happens to be a confirmed dialog) or only two messages (a SIP INFO request, a SIP 2xx response to the SIP INFO request, if the dialog-to-be-transferred happens to be an early dialog) are exchanged when using the SIP INFO method.c) If the MSC server sent the SIP SUBSCRIBE request after receiving a particular provisional response to the particular SIP INVITE request, then four messages (a SIP SUBSCRIBE request, a SIP 2xx response to the SIP SUBSCRIBE request, a SIP NOTIFY request, a SIP 2xx response to the SIP NOTIFY request) would be exchanged between the MSC server and the SCC AS. In comparison, only two messages (a SIP INFO request, a SIP 2xx response to the SIP INFO request) are exchanged when using the SIP INFO method.

d) In the SIP INFO method based solution, it is simpler to associate the event and state related information of the dialog-to-be-transferred with the particular SIP INVITE request as SCC AS associates the particular SIP INVITE request with a dialog-to-be-transferred and the SIP INFO request is sent as an in-dialog request in a dialog created as result of the particular SIP INVITE request. In the use of the dialog-event package, the SIP SUBSCRIBE request and the particular SIP INVITE request are not related on SIP level and SCC AS might associate the SIP SUBSCRIBE request with a dialog-to-be-transferred different than the one associated with the SIP INVITE request.

Use of the SIP MESSAGE method was discounted since the use of the SIP INFO method enables negotiation of supported event packages in the SIP INVITE transaction while the use of the SIP MESSAGE method does not.

Use of the media plane mechanisms was discounted since the amount of information transferred between the SCC AS and the MSC server is limited and set up of TCP based media stream would generate extra messages.

Based on the above analyses, the SIP INFO method was chosen.

E.2.2.4 Info package name

The name of the info package is g.3gpp.state-and-event.

E.2.2.5 Info package parameters

No parameters are defined for the g.3gpp.state-and-event info package.

E.2.2.6 SIP option tags

No SIP option tags are defined for the g.3gpp.state-and-event info package.

E.2.2.7 INFO message body parts

E.2.2.7.1 General

The state-and-event information is carried in the state-and-event-info message body, defined in annex D of 3GPP TS 24.237.

E.2.2.7.2 MIME type

The MIME type value for the message body is "application/vnd.3gpp.state-and-event-info+xml", defined in annex D of 3GPP TS 24.237.

E.2.2.7.3 Content disposition

The Content Disposition value for the message body, when associated with the g.3gpp.state-and-event info package, is "info-package" as defined in IETF RFC 6086.

E.2.2.8 Info package usage restrictions

No usage restrictions are defined for the g.3gpp.state-and-event info package.

E.2.2.9 Rate of INFO requests

No maximum rate or minimum rate is defined for sending SIP INFO requests associated with the g.3gpp.state-and-event info package.

When PS to CS SRVCC for calls in alerting phase is applied, then a single SIP INFO request is generated after the session transfer SIP INVITE request. This can be followed by one more additional SIP INFO request.

E.2.2.10 Info package security considerations

No additional security mechanism is defined for the g.3gpp.state-and-event info package.

The security of the g.3gpp.state-and-event info package is based on the generic security mechanism provided for the underlying SIP signalling.

E.2.2.11 Implementation details and examples

See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3"