4 USSD using IMS
24.3903GPPRelease 17Stage 3TSUnstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS
4.1 Introduction
This service provides the support for UE initiated MMI-mode USSD operations and network initiated MMI-mode USSD operations, which enables the transparent transport of MMI strings entered by the user to the IM core network and enables the transparent transport of text strings from the IM core network which are displayed by the UE for user information.
Support of the UE initiated MMI-mode USSD operations, the network initiated MMI-mode USSD operations or both is optional.
The network initiated USSD can be:
– a single network initiated USSD notification;
– a single network initiated USSD request;
– a dialog consisting of multiple network initiated USSD notifications only;
– a dialog consisting of multiple network initiated USSD requests only; or
– a dialog consisting of one or more network initiated USSD notifications and one or more network initiated USSD requests in any order.
4.2 Description
There is no service description.
4.3 Operational requirements
There are no operational requirements.
4.4 Coding requirements
There are no coding requirements over and above those specified in 3GPP°TS°24.229°[6].
4.5 Signalling requirements
4.5.1 General
In the IM CN subsystem USSD messages can be transported in SIP INFO requests, SIP INVITE requests and SIP BYE requests, using a application/vnd.3gpp.ussd+xml MIME body.
Figure 4.1, figure 4.2, figure 4.3 and figure 4.4 give an overview of the supported USSD operations:
UE USSI AS
INVITE
————————————————————————————————————————>
language, ussd-String
BYE
<————————————————————————————————————————
language, ussd-String
BYE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Error
Figure 4.1: UE initiated USSD operation, network does not request further information
UE USSI AS
INVITE
————————————————————————————————————————>
language, ussd-String
INFO
<————————————————————————————————————————
language, ussd-String
INFO
————————————————————————————————————————>
language, ussd-String
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->
Error
.
.
.
BYE
<————————————————————————————————————————
language, ussd-String
BYE
<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Error
Figure 4.2: UE initiated USSD operation, network requests further information
UE USSI AS
INVITE
<————————————————————————————————————————
language, UnstructuredSS-Request, ussd-String, alertingPattern
INFO
———————————————————————————————————————— >
language, UnstructuredSS-Request, ussd-String
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >
Error
BYE
<————————————————————————————————————————
Figure 4.3: Single network initiated USSD request
UE USSI AS
INVITE
<————————————————————————————————————————
language, UnstructuredSS-Request, ussd-String, alertingPattern
INFO
————————————————————————————————————————>
language, UnstructuredSS-Request, ussd-String
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >
Error
INFO
<————————————————————————————————————————
language, UnstructuredSS-Request, ussd-String, alertingPattern
INFO
————————————————————————————————————————>
language, UnstructuredSS-Request, ussd-String
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >
Error
.
.
.
BYE
<————————————————————————————————————————
Figure 4.4: Multiple Network initiated USSD request
NOTE: The second USSD operation can also be an USSD notification. Only one additional USSD request is shown.
INVITE
<————————————————————————————————————————
language, UnstructuredSS-Notification, ussd-String, alertingPattern
INFO
———————————————————————————————————————— >
UnstructuredSS-Notification
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >
Error
BYE
<————————————————————————————————————————
Figure 4.5: Single network initiated USSD notification
UE USSI AS
INVITE
<————————————————————————————————————————
language, UnstructuredSS-Notification, ussd-String, alertingPattern
INFO
————————————————————————————————————————>
UnstructuredSS-Notification
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >
Error
INFO
<————————————————————————————————————————
language, UnstructuredSS-Notification, ussd-String, alertingPattern
INFO
————————————————————————————————————————>
UnstructuredSS-Notification
INFO
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >
Error
.
.
.
BYE
<————————————————————————————————————————
Figure 4.6: Multiple network initiated USSD notification
NOTE: The second USSD operation can also be an USSD request. Only one additional USSD notification is shown.
4.5.2 SDP Offer/Answer (user initiated)
When a UE sends an initial INVITE request, in order to establish a USSD session, it shall include an SDP offer with one media description, according to subclause 6.1.2 of 3GPP TS 24.229 [6]. The UE shall add a zero port number value to the media descriptions of the SDP offer, in order to inform network entities that media resources are not requested for the session.
A pre-existing network initiated USSD session cannot be used to carry a user initiated USSD session.
When the USSI AS sends an SDP answer, it shall also add a zero port number value to any media description received in the associated SDP offer.
4.5.2A SDP offer/answer (network initiated)
When a USSI AS sends an initial INVITE request, in order to establish a USSD session, it shall include an SDP offer with one media description, according to subclause 6.6.1 of 3GPP TS 24.229 [6], but also in accordance with the UE procedures in subclause 6.1.2 of 3GPP TS 24.229 [6]. The USSI AS shall add a zero port number value to the media descriptions of the SDP offer, in order to inform the user that media resources are not requested for the session.
A pre-existing user initiated USSD session cannot be used to carry a network initiated USSD session.
When the UE sends an SDP answer, it shall also add a zero port number value to any media description received in the associated SDP offer.
4.5.3 Activation/deactivation
If:
1) the domain selection for originating voice calls specified in 3GPP TS 23.221 [y] determines that the UE uses the IMS to originate voice calls; and
2) the UE is not configured with HPLMN operator preference for invocation of originating USSD requests using CS domain (e.g. see 3GPP TS 24.391 [13]);
or if the UE does not support the CS domain, then the UE can invoke the procedures in subclause 4.5.4, otherwise the UE shall not invoke the procedures in subclause 4.5.4.
If the network initiated USSD over IMS is supported by the UE, then when the UE registers to IM CN subsystem the UE shall include a g.3gpp.nw-init-ussi media feature tag in the Contact header field.
NOTE: The g.3gpp.nw-init-ussi media feature tag is specified in annex B.2.
For this version of this document, network domain selection procedures for network initiated USSD requests is outside the scope.
4.5.4 Invocation and operation (user initiated)
4.5.4.1 Actions at the originating UA
NOTE 1: The Content-Language SIP header field is not used to determine the language of the USSD string. Only the <language> XML element is used.
In order to send the initial USSD message, the UE shall send an initial INVITE request, according to 3GPP TS 24.229 [6]. The UE shall populate the request as follows:
1) Request-URI set to a SIP URI with user part including the USSD string and a "phone-context" parameter set to the home network domain name used in REGISTER request according to TS 24.229 [6], a host part set to the home netwok domain name used in REGISTER request as defined in TS 24.229 [6] a "user" URI parameter set to value "dialstring" as specified in RFC 4967 [7];
2) Recv-Info header field containing the g.3gpp.ussd info-package name;
3) Accept header field containing the application/vnd.3gpp.ussd+xml, application/sdp and multipart/mixed MIME types;
4) the Content-Type header, which shall contain "multipart/mixed";
5) SDP offer as described in subclause 4.5.2; and
6) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <ussd-string> element and may contain a <language> element.
When receiving an INFO request with Info-Package header field containing the g.3gpp.ussd info-package and containing application/vnd.3gpp.ussd+xml MIME body associated with the info package according to IETF RFC 6086 [2], the UE shall, in addition to the procedures specified in 3GPP TS 24.229 [6]:
1) if the UE is able to process the received information, send an INFO request within the dialog, according to 3GPP TS 24.229 [6]. The UE shall populate the INFO request as follows:
a) Info-Package header field containing the g.3gpp.ussd info-package name; and
b) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] containing the user’s response in a <ussd-string> element and optionally a <language> element; and
2) if the UE is not able to process the received information or rejects the received information, send an INFO request within the dialog, according to 3GPP TS 24.229 [6]. The UE shall populate the INFO request as follows:
a) Info-Package header field containing the g.3gpp.ussd info-package name; and
b) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] containing an <error-code> element.
When receiving a BYE request containing application/vnd.3gpp.ussd+xml MIME body, the UE shall, in addition to the procedures specified in 3GPP TS 24.229 [6], handle the application/vnd.3gpp.ussd+xml MIME body.
NOTE 2: According to 3GPP TS 24.229 [6], the UE can receive a BYE request without the application/vnd.3gpp.ussd+xml MIME body and in this case the dialog is terminated immediately.
When receiving a 404 (Not Found) response to INVITE request, the UE shall determine that an attempt to deliver the USSD request using IMS fails due to missing network support.
NOTE 3: 3GPP TS 23.221 [14] gives requirements related to failure of the USSD request using IMS due to missing network support.
4.5.4.2 Actions at the USSI AS
In addition to the procedures specified in this subclause, the USSI AS shall support the procedures specified in 3GPP TS 24.229 [6] for an AS.
NOTE 1: The Content-Language SIP header field is not used to determine the language of the USSD string. Only the <language> XML element is used.
Upon receiving an initial INVITE request with Request-URI containing the SIP URI including the USSD string and a "user" URI parameter set to value "dialstring" as specified in RFC 4967 [7], if the application/vnd.3gpp.ussd+xml MIME body contained in the request is accepted by the USSI AS, the USSI AS shall:
1) pass the USSD data received in the body of the SIP INVITE request to the USSD application handling and wait for the response of the application;
NOTE 2: How the USSD data are processed at the USSI AS is outside the scope of this specification. The USSI AS can handle the USSD dialogs or forward the USSD requests and responses to/from a legacy USSD server.
NOTE 3: The USSD string in the request-URI is not passed to the USSD application handling. In case of discrepancy between this string and the <ussd-string> element contained in the MIME body, the behaviour of the USSI AS is determined by the <ussd-string> in the MIME body.
2) send 200 (OK) response to the request following the procedures specified for AS acting as a terminating UA in 3GPP TS 24.229 [6]. The USSI AS shall populate the 200 (OK) response to the request as follows:
a) Recv-Info header field containing the g.3gpp.ussd info-package name;
b) Accept header field containing the application/vnd.3gpp.ussd+xml, application/sdp and multipart/mixed MIME types; and
c) SDP answer as described in subclause 4.5.2.
Upon receiving an ACK request associated with the INVITE request, the USSI AS shall:
1) if the network requests further information in order to perform the USSD operation, send an INFO request within the dialog created by the INVITE request. The USSI AS shall populate the INFO request as follows:
a) Info-Package header field containing the g.3gpp.ussd info-package name; and
b) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] including a <ussd-string> element and a <language> element;
2) if the network successfully performed the USSD information and does not need any further information, send a BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3 including a <ussd-string> element and a <language> element; and
3) if the network informs the UE that the network is unable to process the USSD request or the network informs the UE that the network rejects the USSD request, send a BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3, including, a <error-code> element.
Upon receiving a SIP INFO request with Info-Package header field containing the g.3gpp.ussd info-package and a application/vnd.3gpp.ussd+xml MIME body associated with the info package according to IETF RFC 6086 [2], the USSI AS shall handle the SIP INFO request following the procedures specified for AS acting as a terminating UA in 3GPP TS 24.229 [6] and generate a SIP response as described in 3GPP TS 24.229 [6]. If the SIP response is a 2xx response, the USSI AS shall:
1) pass the USSD data received in the body of the SIP INFO request to the USSD application handling and wait for the response of the application;
NOTE 4: How the USSD data are processed at the USSI AS is outside the scope of this specification. The USSI AS can handle the USSD dialogs or forward the USSD requests and responses to/from a legacy USSD server.
2) if the network requests further information in order to perform the USSD operation, send an INFO request within the dialog. The USSI AS shall populate the INFO request as follows:
a) Info-Package header field containing the g.3gpp.ussd info-package name; and
b) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] including a <ussd-string> element and a <language> element;
3) if the network successfully performed the USSD information and does not need any further information, send a BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3 including a <ussd-string> element and a <language> element; and
4) if the network informs the UE that the network is unable to process the USSD request, or the network informs the UE that the network rejects the USSD request, send a BYE request in order to terminate the dialog. The USSI AS shall populate the BYE request with application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3, including, a <error-code> element.
4.5.5 Invocation and operation (network initiated USSD request and network initiated USSD notification)
4.5.5.1 Actions at the originating USSI AS
NOTE 1: The Content-Language SIP header field is not used to determine the language of the USSD string. Only the <language> XML element is used.
In order to send the initial USSD message, the USSI AS shall send an initial INVITE request, according to 3GPP TS 24.229 [6]. The USSI AS shall populate the request as follows:
NOTE 2: Any received g.3gpp.nw-init-ussi media feature tag can be used for the USSI AS to determine whether to send the USSD message towards the UE.
1) Request-URI set to the an identity of the target UE;
2) Recv-Info header field containing the g.3gpp.ussd info-package name;
3) Accept header field containing the application/vnd.3gpp.ussd+xml, application/sdp and multipart/mixed MIME types;
4) the Content-Type header, which shall contain "multipart/mixed";
5) SDP offer as described in subclause 4.5.2A; and
6) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3. The XML document:
– shall contain a single <ussd-string> element;
– shall contain an <UnstructuredSS-Request> element or an <UnstructuredSS-Notify> element;
– may contain a <language> element; and
– may contain an <alertingPattern> element.
The USSI AS should not include an Alert-Info header field into the initial INVITE request.
NOTE 3: Information provided in the Alert-Info header field can be in conflict with the content of the <alertingPattern> element of the application/vnd.3gpp.ussd+xml MIME body of the initial INVITE request.
When receiving an INFO request with Info-Package header field containing the g.3gpp.ussd info-package and containing application/vnd.3gpp.ussd+xml MIME body associated with the info package according to IETF RFC 6086 [2], if the application/vnd.3gpp.ussd+xml MIME body contains:
– the <UnstructuredSS-Request> element; or
– the <UnstructuredSS-Notify> element;
the USSI AS shall, in addition to the procedures specified in 3GPP TS 24.229 [6]:
1) if the USSI AS is able to process the received information and needs to send further information, send an INFO request within the dialog, according to 3GPP TS 24.229 [6]. The USSI AS shall populate the INFO request as follows:
a) Info-Package header field containing the g.3gpp.ussd info-package name; and
b) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2], containing:
– the further information to be sent to the US in a <ussd-string> element;
– a <UnstructuredSS-Request> element or a <UnstructuredSS-Notify> element;
– optionally a <language> element; and
– optionally an <alertingPattern> element.
If the USSI AS considers the USSD procedure complete, then the USSI AS shall generate a BYE request.
When receiving a 415 (Unsupported Media Type) response to the initial INVITE request, the USSI AS shall determine that an attempt to deliver the USSD request using IMS fails due to missing UE support.
4.5.5.2 Actions at the UE
In addition to the procedures specified in this subclause, the UE shall support the procedures specified in 3GPP TS 24.229 [6] for an UE.
NOTE 1: The Content-Language SIP header field is not used to determine the language of the USSD string. Only the <language> XML element is used.
Upon receiving an initial INVITE request with the application/vnd.3gpp.ussd+xml MIME body, if the body contains:
– the <UnstructuredSS-Request> element; or
– the <UnstructuredSS-Notify> element;
and if the request is accepted by the UE, the UE shall:
1) pass the USSD data received in the body of the SIP INVITE request to the USSD application handling and wait for the response of the application; and
2) send 200 (OK) response to the request following the procedures specified for AS acting as a terminating UA in 3GPP TS 24.229 [6]. The UE shall populate the 200 (OK) response to the request as follows:
a) Recv-Info header field containing the g.3gpp.ussd info-package name;
b) Accept header field containing the application/vnd.3gpp.ussd+xml, application/sdp and multipart/mixed MIME types; and
c) SDP answer as described in subclause 4.5.2A.
Upon receiving an ACK request associated with the INVITE request, the UE shall:
1) if the application/vnd.3gpp.ussd+xml MIME body of the INVITE request contains the <UnstructuredSS-Request> element:
a) when the application in the UE provides further information in order to perform the USSD operation, send an INFO request within the dialog created by the INVITE request. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] including a <ussd-string> element, a <UnstructuredSS-Request> element, and a <language> element; and
b) if the UE informs the network that the UE is unable to process the USSD request or the UE informs the network that the UE rejects the USSD request, send an INFO request. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2], including a <error-code> element and a <UnstructuredSS-Request> element; and
2) if the application/vnd.3gpp.ussd+xml MIME body of the INVITE request contains the <UnstructuredSS-Notify> element:
a) if the UE acknowledges the USSD operation, send an INFO request within the dialog created by the INVITE request. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] including a <UnstructuredSS-Notify> element; and
b) if the UE informs the network that the UE is unable to process the USSD request or the UE informs the network that the UE rejects the USSD request, send an INFO request. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body, as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2], including a <error-code> element and a <UnstructuredSS-Notify> element.
Upon receiving a SIP INFO request with Info-Package header field containing the g.3gpp.ussd info-package and a application/vnd.3gpp.ussd+xml MIME body associated with the info package according to IETF RFC 6086 [2],if the MIME body contains:
– an <UnstructuredSS-Request> element; or
– an <UnstructuredSS-Notify> element;
the UE shall handle the SIP INFO request following the procedures specified for a terminating UE in 3GPP TS 24.229 [6] and generate a SIP response as described in 3GPP TS 24.229 [6]. If the SIP response is a 2xx response, the UE shall:
1) pass the USSD data received in the body of the SIP INFO request to the USSD application handling and wait for the response of the application;
2) if the application/vnd.3gpp.ussd+xml MIME body of the INFO request contains the <UnstructuredSS-Request> element:
a) when the application in the UE provides further information in order to perform the USSD operation, send an INFO request within the dialog. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] including a <ussd-string> element, a <UnstructuredSS-Request> element and optionally a <language> element; and
b) if the UE informs the network that the UE is unable to process the USSD request, or the UE informs the network that the UE rejects the USSD request, send a INFO request within the dialog. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2], including an <error-code> element; and
3) if the application/vnd.3gpp.ussd+xml MIME body of the INFO request contains the <UnstructuredSS-Notify> element:
a) if the UE acknowledges the USSD operation, send an INFO request within the dialog. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2] including a <UnstructuredSS-Notify> element; and
b) if the UE informs the network that the UE is unable to process the USSD request, or the UE informs the network that the UE rejects the USSD request, send a INFO request within the dialog. The UE shall populate the INFO request as follows:
A) Info-Package header field containing the g.3gpp.ussd info-package name; and
B) application/vnd.3gpp.ussd+xml MIME body as described in subclause 5.1.3, associated with the info package according to IETF RFC 6086 [2], including an <error-code> element and a <UnstructuredSS-Notify> element.
If:
– the UE receives a USSD operation in parallel to any call independent supplementary service transaction;
– the UE receives a USSD operation while another USSD transaction (network or mobile initiated) is in progress; or
– the UE receives a USSD operation when the UE is in a state where the MMI required is not possible (e.g. during dialling);
the UE shall inform the network that the UE is unable to process the USSD request according to the preceding procedures and shall set the <error-code> element to "USSD-busy".
The UE can terminate the dialog at any time in accordance with the procedures from 3GPP TS 24.229 [6].
4.6 Interaction with other services
4.6.1 Originating Identification Presentation (OIP)
There are no interaction requirements with OIP.
4.6.2 Originating Identification Restriction (OIR)
There are no interaction requirements with OIR.
4.6.3 Terminating Identification Presentation (TIP)
There are no interaction requirements with TIP.
4.6.4 Terminating Identification Restriction (TIR)
There are no interaction requirements with TIR.
4.6.5 Communication Diversion (CDIV)
There are no interaction requirements with CDIV. CDIV is not applicable for USSI.
4.6.6 Communication Hold (HOLD)
There are no interaction requirements with HOLD.
4.6.7 Communication Barring (CB)
There are no interaction requirements with CB. CB is not applicable for USSI.
4.6.8 Message Waiting Indication (MWI)
There are no interaction requirements with MWI.
4.6.9 Conference (CONF)
There are no interaction requirements with CONF.
4.6.10 Explicit Communication Transfer (ECT)
There are no interaction requirements with ECT.
4.6.11 Advice Of Charge (AOC)
There are no interaction requirements with AOC.
4.6.12 Closed User Groups (CUG)
There are no interaction requirements with CUG.
4.6.13 Three-Party (3PTY)
There are no interaction requirements with CUG.
4.6.14 Flexible Alerting (FA)
There are no interaction requirements with FA.
4.6.15 Communication Waiting (CW)
There are no interaction requirements with CW.
4.6.16 Completion of Communications to Busy Subscriber (CCBS)
There are no interaction requirements with CCBS.
4.6.17 Completion of Communications by No Reply (CCNR)
There are no interaction requirements with CCNR.
4.6.18 Customized Alerting Tones (CAT)
There are no interaction requirements with CAT.
4.6.19 Customized Ringing Signal (CRS)
There are no interaction requirements with CRS.
4.6.20 Personal Network Management (PNM)
There are no interaction requirements with PNM.
4.6.21 Malicious Communication Identification (MCID)
There are no interaction requirements with MCID.
4.6.22 SIP based user configuration
Based on filter criteria, an initial INVITE request including a dialstring and an optional XML body as described in subclause 4.5.1 can be forwarded either to an USSI AS supporting SIP based user configuration as specified in 3GPP TS 24.238 [8] or to an AS supporting USSI as specified in this specification.
An USSI AS and SIP based user configuration as specified in 3GPP TS 24.238 [8], shall handle an initial INVITE request as described in subclause 4.5.1 according to this specification.
NOTE: If an AS supports only SIP based user configuration as specified in 3GPP TS 24.238 [8], an initial INVITE request as described in subclause 4.5.1 is handled according to 3GPP TS 24.238 [8].
4.7 Service configuration
User self configuration is not applicable to USSD using IMS.