E.1 Info package for transfer of the conference information

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

E.1.1 Scope

This subclause contains the information required for the IANA registration of info package g.3gpp.mid-call in accordance with IETF RFC 6086 [54].

E.1.2 g.3gpp.mid-call info package

E.1.2.1 Overall description

When PS to CS access transfer with the MSC Server assisted mid-call feature is applied for a session with conference focus there is a need to deliver participant identities from SCC AS to MSC server.

E.1.2.2 Applicability

This package is used to transport participant identities when the PS to CS access transfer with the MSC server assisted mid-call feature is applied to a session with conference focus.

E.1.2.2A Appropriateness of INFO Package Usage

A number of solutions were discussed for the transportation of identities of up to 5 conference participants from the SCC AS (a B2BUA) to the MSC server (a UA). The solutions were:

1) Use of subscription to the conference event package as specified in IETF RFC 4575.

2) Use of the session related methods (e.g. SIP 200 (OK) response to the SIP INVITE request).

3) Use of the SIP MESSAGE method.

4) Use of media plane mechanisms.

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

Furthermore, each of the solutions 1), 2), 3), 4) and 5) was evaluated.

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

1) 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 the SCC AS to the MSC server. If the dialog-to-be-transferred happens to be with a conference focus and the conference session happens to be established by the original UA served by the SCC AS, then the access transfer procedure requires the MSC server to be aware of identities of up to 5 conference participants of the conference session. In the majority of cases of access transfer, the dialog-to-be-transferred is not with a conference focus. In even fewer cases of access transfer, the conference session happens to be established by the original UA served by the SCC AS.

2) If the MSC server sent the SIP SUBSCRIBE request before sending the particular SIP INVITE request and the dialog-to-be-transferred does not happen to be with a conference focus or the conference session does not happen to be established by the original UA served by the SCC AS, then two messages (a SIP SUBSCRIBE request, a SIP 4xx response to the SIP SUBSCRIBE request) would be exchanged between the MSC server and the SCC AS. In comparison, zero messages are exchanged when using the SIP INFO method.

3) If the MSC server sent the SIP SUBSCRIBE request before sending the particular SIP INVITE request, the dialog-to-be-transferred happens to be with a conference focus and the conference session happens to be established by the original UA served by the SCC AS, 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.

4) If the MSC server sent the SIP SUBSCRIBE request after receiving a particular SIP response to the particular SIP INVITE request, the particular SIP response includes a Contact header field with sip.isfocus media feature tag indicating that the dialog-to-be-transferred happens to be with a conference focus, and the conference session happens not to be established by the original UA served by the SCC AS, then two messages (a SIP SUBSCRIBE request, a SIP 4xx response to the SIP SUBSCRIBE request) would be exchanged between the MSC server and the SCC AS. In comparison, zero messages are exchanged when using the SIP INFO method.

5) If the MSC server sent the SIP SUBSCRIBE request after receiving a particular SIP response to the particular SIP INVITE request, the particular SIP response includes a Contact header field with sip.isfocus media feature tag indicating the dialog-to-be-transferred happens to be with a conference focus, and the conference session happens to be established by the original UA served by the SCC AS, 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.

6) In the SIP INFO method based solution, it is simpler to associate the information of identities of up to 5 conference participants of the dialog-to-be-transferred with the particular SIP INVITE request as the 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 conference event package, the SIP SUBSCRIBE request and the particular SIP INVITE request are not related at the SIP level and SCC AS might associate the SIP SUBSCRIBE request with a dialog-to-be-transferred different to the one associated with the SIP INVITE request.

The use of session related 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.

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 from the SCC AS to 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 to transport the identities of up to 5 conference participants from the SCC AS to the MSC server.

E.1.2.3 Info package name

g.3gpp.mid-call

E.1.2.4 Info package parameters

None defined

E.1.2.5 SIP options tags

None defined

E.1.2.6 INFO message body parts

The MIME type of the message body carrying participant identities is application/vnd.3gpp.mid-call+xml. application/vnd.3gpp.mid-call+xml MIME type is defined in 3GPP TS 24.237.

When associated with the g.3gpp.mid-call info package, the Content-Disposition value of the message body carrying participant identities is "info-package".

E.1.2.7 Info package usage restrictions

None defined.

E.1.2.8 Rate of INFO Requests

Single INFO request generated after session set up.

E.1.2.9 Info package security considerations

The security is based on the generic security mechanism provided for the underlying SIP signalling. No additional security mechanism is defined.

E.1.2.10 Implementation details and examples

UAC generation of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3"

UAS processing of INFO requests: See 3GPP TS 24.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 3"

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