7 Protocol specification and implementation

24.2943GPPIP Multimedia Subsystem (IMS) Centralized Services (ICS) protocol via I1 interfaceRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 Overview of I1 protocol functionality

The I1 protocol includes the procedures for establishing, maintaining, and clearing the I1 sessions between the ICS UE and the SCC AS (see figure 7.1).

Figure 7.1 UE session signalling and bearer path using I1 interface for Service Control Signalling Path

NOTE 1: Figure 7.1 illustrates an MSC server that is not enhanced for ICS. I1 can also be used when deploying an MSC server enhanced for ICS as specified in 3GPP TS 23.292 [2].

The I1 protocol is a message based point-to-point protocol. The I1 protocol messages are wrapped in a point-to-point transport layer connection protocol (e.g. USSD) and are exchanged between the ICS UE and the SCC AS. Therefore, the I1 protocol does not include any routing capabilities. To address the ICS UE in CS network and establish a transport-layer connection, (the IUA of) the SCC AS shall convert the called party identity (i.e., IMS public user identity) to the CS domain party identity that is required to route the transport layer protocol(i.e., MSISDN, MDN, etc.).

The I1 protocol assumes that there is an associated connection-control protocol that incorporates media negotiation capabilities and provides the setting up and clearing of the connection over which the media will be exchanged. Therefore, any signalling between the UE and the CS access domain (see figure 7.1), as well as the SIP signalling between the MGCF and the SCC AS should be viewed as a procedure to establish a media connection rather then a call control signalling. Obviously, the I1 endpoints will correlate and synchronize the progress of the I1 session establishment and clearing of the I1 session with the associated media-establishing procedures.

NOTE 2: The primitives that are used to communicate between the I1 protocol I1 session entity and the associated connection-control protocol entity, internally in the UE and SCC AS, respectively, are not specified in this document.

The I1 protocol assumes that the application level segmentation of the I1 protocol messages is not supported. The size of the I1 protocol messages is constrained by the limits of the transport-layer message size. For example, USSD allows for a message size of 160 octets. This means that it is not possible to send an I1 protocol message greater than 160 octets, unless message segmentation is designed into the I1 protocol. A USSD dialogue is already segmented by the use of USSD sub-dialogues as a USSD conversation, and this usage of USSD is inappropriate for the I1 protocol.

The I1 protocol is a transport-independent protocol, i.e. the I1 protocol I1 session control entities can exchange the I1 protocol messages over any transport-layer connection that connects the ICS UE and the SCC AS. The ICS UE sends the I1 protocol messages to the SCC AS over a transport-layer connection (e.g. USSD) that the ICS UE knows it will reach the SCC AS. Likewise, The SCC AS sends the I1 protocol messages to the ICS UE over a transport-layer connection (e.g. USSD) that the SCC AS knows that it will reach the ICS UE. For example, the SCC AS forwards the I1 protocol message to the ICS UE over the same transport-layer connection (e.g. USSD) over which it received the previous I1 protocol message from the ICS UE.

The I1 protocol message are self-identifying, i.e. the information contained in the I1 protocol message uniquely identifies the call to which the I1 protocol message pertains to.

The I1 protocol assumes that when the transport-layer connection is established between the UE and SCC, the UE’s E.164 number is bound to the respective transport-layer connection at both the UE and SCC AS (e.g. the establishment of an USSD channel can implicitly bind the UE’s E.164 number to this transport-layer connection). Subsequently, the request for an I1 session destined for the respective E.164 number will be passed to the UE over the respective transport-layer connection.

NOTE 3: Since the binding between the transport-layer connection and the E.164 number is performed when the transport-layer connection is established, the I1 protocol does not include any registration procedure.

The I1 protocol is a binary-oriented protocol (i.e. the I1 messages are binary encoded). The bit-map tables are used to describe the I1 messages and associated information elements.

In this release of this document, it is assumed that the ICS UE, when establishing a transport-layer connection (e.g. USSD channel) to the SCC AS, will have been authenticated by the CS domain. Due to a relationship between the SCC AS and the CS domain, the ICS UE is not authenticated (e.g. challenged) by the SCC AS when sending any I1 protocol message to the SCC AS. However, the SCC AS will check the UE identity for potential invalid IMS public user identity included by the ICS UE. The CS domain number received from the transport-layer is trustable and will be used by (the IUA of) the SCC AS to check the URI of the UE before the SCC AS provides SIP UA behaviour on behalf of the ICS UE.

7.2 I1-protocol messages and functional definition

7.2.1 I1-protocol messages

7.2.1.1 General

This subclause provides the list of I1-protocol messages (see table 7.2.1) and brief description of each I1-protocol message. Based on their function the I1-protocol messages can be grouped into five categories:

– I1-Session establishment messages;

– I1-Stable Session messages;

– I1-Session clearing messages;

– I1-Error messages;

– I1- Supplementary Service -Invocation messages; and

– I1-Other messages.

Table 7.2.1.1: I1-protocol messages

Message type	Description and content (subclause)
*Session establishment messages:*	7.2.1.2
I1 Invite message
I1 Progress message
I1 Success message

Stable Session messages:	7.2.1.3
I1 Refer message

Session clearing messages:	7.2.1.4
I1 Bye message
I1 Success message

Error messages:	7.2.1.5
I1 Failure message

Supplementary Service Invocation messages:	7.2.1.6
I1 Mid Call Request message
I1 Redirection message

*Other messages:*	7.2.1.7
I1 Notify message
I1 Dummy message

7.2.1.2 Session establishment messages

The session establishment I1 messages can be sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE.

I1 Invite message

The I1 Invite message is sent either by the calling UE to the SCC AS or by the SCC AS to the called UE to initiate session establishment.

I1 Progress message

The I1 Progress message is a general purpose provisional response, semantically similar to SIP 1xx class responses. The binary Reason field value (per figure 7.3.1) corresponds with the received SIP 1xx response’s numeric status-code value.

I1 Success message

The I1 Success message indicates that the action requested in the respective I1 message has been accomplished successfully.

The I1 Success message:

– is transmitted by the SCC AS to the calling UE to indicate that the session has been accepted; or

– is transmitted by the called UE to the SCC AS to indicate that the called UE has accepted the session.

The Reason’s corresponding to the I1 Success message are specified in table 7.3.1 and correspond with a SIP 2xx response’s numeric status-code.

7.2.1.3 Stable session messages

I1 Refer message

The I1 Refer message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE to indicate that the recipient of the I1 Refer message should contact the target identified in the Refer-to information element included in the I1 Refer message.

7.2.1.4 Session clearing messages

I1 Bye message

The I1 Bye message:

– is transmitted by the SCC AS to the ICS UE to clear the I1 session; or

– is transmitted by the ICS UE to the SCC AS to clear the I1 session.

7.2.1.5 Error messages

I1 Failure message

An I1 Failure response message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE, to indicate that an error has occurred. The additional parameters included in the I1-Failure message indicate the type of the error that has occurred. The reason value field is a direct one to one mapping to the status code in the status line as specified in subclause 7.2 of RFC 3261 [6].

7.2.1.6 Supplementary Services Invocation related messages

The following section details the messages that are used to request the invocation of a supplementary service.

I1 Mid Call Request message

The I1 Mid Call Message is used for the invocation of mid-call supplementary services. For example: user wishes to hold or resume a call.

I1 Redirection message

The I1 Redirection message is used by the ICS UE to inform the SCC AS of the desire to invoke a supplementary service, in response to incoming signalling. For example: desire for the called user to deflect the call to a third party. The SCC AS interworks the I1 response to the appropriate SIP response to send to the SIP AS.

7.2.1.7 Other messages

I1 Notify message

The I1 Notify message may be used to notifyeither by the ICS UE or the SCC AS to inform its peer about some event that has occurred or to convey some information to its peer, e.g.of events related to the invocation of supplementary services. For example:

– Notification that a call has been forwarded to a third party;

– Notifications related to Explicit Call Transfer; or

– Notifications related to requests to join a Conference.

I1 Dummy message

The I1 Dummy message is only used for those specific transport-layer connections (e.g., USSD) which provide two-way-alternative interactive service. If the party which has the turn hasn’t sent an application level protocol message for a specific time, an I1 Dummy message shall be delivered to the counterpart to transfer the turn with the consideration of not delaying its transmission of application protocol message.

7.2.2 I1 message structure and common field encoding

7.2.2.1 General

7.2.2.1.1 Message Header structure

The I1 message structure is shown in figure 7.2.2.1. Each I1 messages consists of two parts, i.e. the first part referred to as the I1 message common part and the second part consisting of zero or more I1 information elements. The I1 message common part is included in every I1 message. The I1 information elements that are included in an I1 message depend on a type of I1 message being sent.

The text in this clause describes the content of the I1 message common part. The octet number 1 (shown at the top of the figure 7.2.2.1) is sent first followed by octet 2, 3, etc. Within each octet, the bit designated "bit 1" is transmitted first, followed by bits 2, 3, 4, etc.

8	7	6	5	4	3	2		1	Octet
Protocol version number				Protocol identifier					1
Message type					R		Reason		2
Reason									3
Call-Identifier (Part-1)									4
Call-Identifier (Part-2)									5
Call-Identifier (Part-2)									6
Sequence-ID									7
Information element #1
Information element #2

Figure 7.2.2.1: I1 message structure

7.2.2.1.2 Protocol Version information

The first octet is divided into two four-bit subfields, i.e. the Protocol identifier and the Protocol version number. The Protocol identifier for I1 protocol is "0001" and indicates that the respective message, transported across the transport-layer connection, is an I1 protocol message. The Protocol version number indicates that this is the first version of this specification and the respective value of the Protocol version number subfield is "0001".

7.2.2.1.3 Message Type and Reason

The second octet and third consists of five-bit Message Type field that identifies the type of the I1 message, while the ten-bit Reason fields provide additional information about the respective I1 message, e.g., Progress reason value, as specified in table 7.2.2.1. The bit number 3 in the second octet (marked "R") is reserved for future use.

7.2.2.1.4 Call Identifier

The three octets (i.e. the octet number 4, 5, and 6) that follow the Reason field contain the Call-Identifier field. The Call-Identifier field uniquely specify the I1 session across all I1 interfaces (i.e. between the ICS AS and all ICS UEs connected to the ICS AS). The Call-Identifier field is divided into two subfields, i.e. the part-1 subfield consisting of one octet and the part-2 subfield consisting of two octets. The part 1 subfield is always filled by the UE, while the part-2 subfield is always filled by the ICS AS. The part-1 and part-2 subfields are analogous to the SIP tags inserted in the From and To header fields. The values of all "0" inserted in the octet 3 (i.e. in the Call-Identifier Part-1) indicates that the Call-Identifier (Part-1) subfield is empty (i.e. it has no value). Likewise, values of all "0" inserted in the octet 4 and 5 (i.e., in the Call-Identifier Part-2) indicates that the Call-Identifier Part-2 subfield is empty (i.e., it has no value). When the UE forwards the first I1 message pertaining to an I1 session that is being established (e.g., an I1 Invite or an I1 Progress) to the ICS AS, the UE inserts a new value into the Call-Identifier (Part-1) subfield (i.e., a value that is currently not being unused). Likewise, when the ICS AS forwards the first I1 message pertaining to an I1 session that is being established (e.g., an I1 Invite or an I1 Progress) to the UE, the ICS AS inserts a value into the part-2 subfield. When inserting a value into the Call-Identifier (Part-2) subfield, the ICS AS has to insure that the resulting Call-Identifier field is unique across all I1 interfaces. For example, the ICS AS, upon receiving the first I1 message from the ICS UE, may insert into the Call-Identifier (Part-2) subfield a value that it is currently using in some other I1 sessions, only if the resulting Call-Identifier field is unique across all I1 interfaces (i.e. between the ICS AS and all ICS UEs).

Some values inserted into the Call-Identifier (Part-1 and Part-2) field are reserved. The Call-Identifier (Part-1 and Part-2) subfield with all bits set to values "1" is a reserved and it is used to identify the I1 session that was automatically bound to a CS bearer that was previously set up without using the I1 protocol. For example, a single CS call that was established using SRVCC may be automatically bound to the I1 session identified with the Call-Identifier (Part-1 and Part-2) subfield with all bits set to values "1" without the ICS UE and the SCC AS exchanging the I1session establishing messages. The usage of the reserved Call-Identifier values is specified in the respective clauses in this document.

7.2.2.1.5 Sequence-ID

The Sequence-ID field value (i.e., the octet number 7) guarantees the proper ordering of the I1 message. The sender of the I1 message increments the Message sequence number value by one for each new I1 message forwarded to its peer. The sequence number value is expressible as an 8-bit unsigned integer. Once the count reaches the value of 2**8, it wraps around back to one.

7.3 Messages

7.3.1 General Messages

Table 7.3.1 lists the I1messages and their encoding. The prefix "0x" indicates that what follows is a bit stream represented as a hexadecimal number.

Table 7.3.1: General Message types

Message	Message Type value (5 bit)	Reason value (10 bit)
I1 Invite (MO)	0x1	0x000
I1 Invite (MT)	0x1	0x001
I1 Invite (Augmentation)	0x1	0x002
I1 Invite (use existing CS bearer)	0x1	0x003
I1 Invite (CW)	0x1	0x005
I1 Bye	0x2	0x000
I1 Notify (used for synchronization)	0x3	0x001
I1 Notify	0x3	0x002 – 0x64
I1 Refer	0x9	0x000
I1 Progress	0x00	0x64 – 0xC7 (NOTE 1)
I1 Success	0x00	0xC8 – 0x12B
I1 Mid Call Request message	0x4	0x001
I1 Failure	0x00	0x12C – 0x25E (NOTE 2)
I1 Dummy	0x00	0x3FF
NOTE 1: The value in the Reason field corresponds to the hex-encoded SIP 1xx values, as specified in subclause 21.1 of RFC 3261[6]. NOTE 2: The value in the Reason field corresponds to the hex-encoded SIP 3xx, 4xx, 5xx, and 6xx values, as specified in subclauses 21.4, 21.5, and 25.6 of RFC 3261[6].

7.3.2 I1 INVITE – ICS UE initiated

7.3.2.1 General

This message is sent by the ICE UE to the network to establishment of a session. See table 7.3.2.1.

Message type: I1 INVITE

Direction: ICS UE to SCC AS

Table 7.3.2.1: I1 INVITE message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – INVITE	M	V	2
	7.2.2.2.1.2
Call ID	Call-Id	M	V	2
	7.2.2.1.4
Message Sequence Number	Sequence-Id	M	V	1
	7.2.2.1.5
Timestamp	Timestamp	O	TLV	1
	7.3.2.8
To-id	To-id	M	TLV	3-X
	7.3.2.3			Note 1
From-id	From-id	M	TLV	3-X
	7.3.2.4			Note 1
Accept Contact	Accept Contact	O	TLV	5
	7.3.2.5
ERAccept Contact	ERAccept Contact	O	TLV	3-X
	7.3.2.6			Note 1
Reject Contact	Reject Contact	O	TLV	5
	7.3.2.7
Note 1 – The length of this information element in combination with the other information elements cannot exceed the length of the transport protocol information element to transport the I1 message.

7.3.2.2 Message Type

Identifies that the message is:

i) a Mobile Originated I1 INVITE.

7.3.2.3 To-id

This information element shall be included, it identifies the logical identity of the recipient for the request according to the procedures specified in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3A.

7.3.2.4 From-id

This information element shall be included, it identifies the logical identity that the dialogue originates from according to the procedures specified in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3.

7.3.2.5 Accept Contact

This information element shall be optionally included, if feature tags are indicated.

7.3.2.6 ERAccept Contact

This information element shall be optionally included, if feature tags that have been qualified with the parameter tag "explicit" or "require" are indicated.

7.3.2.7 Reject Contact

This information element shall be optionally included, if feature tags are indicated.

7.3.2.8 Timestamp

This information element shall be included if using a transport layer protocol that is not a real-time transport layer protocol; it provides the SCC AS local time to the ICS UE.

7.3.3 INVITE – SCC AS initiated

7.3.3.1 General

This message is sent by the SCC AS to the ICS UE to establishment of a session. See table 7.3.3.1.

Message type: I1 INVITE.

Direction: SCC AS to ICS UE

Table 7.3.3.1: I1 INVITE message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – INVITE	M	V	2
	7.2.2.2.2.2
CallID	Call-Id	M	V	2
	7.2.2.1.4
Message Sequence Number	Sequence-Id	M	V	1
	7.2.2.1.5
Timestamp	Timestamp	O	TLV	1
	7.3.3.6
From-id	From-id	M	TLV	3-X
	7.3.3.3			Note 1
SCC AS PSI DN	SCC AS PSI DN	M	LV	3-15
	7.3.3.5
To-id	To-id	M	TLV	3-X
	7.3.3.4			Note 1
Conference-id	Conference-id	O	LV	FFS
	7.4.2.16
Note 1 – The length of this information element in combination with the other information elements cannot exceed the length of the transport protocol information element to transport the I1 message.

7.3.3.2 Message Type

Identifies that the message is:

i) a Mobile Terminated I1 INVITE.

7.3.3.3 From-id

This information element shall be included; it identifies the logical identity that the dialogue originates from. It is the same as that defined in RFC 3261 [6] however no display name is included. For the coding of this information element please see subclause 7.4.2.3.

7.3.3.4 To-id

This information element shall be included; it identifies the logical identity of the recipient for the request. It is the same as that defined in RFC 3261 [6]. For the coding of this information element please see subclause 7.4.2.3A.

7.3.3.5 SCC AS PSI DN

This information element, as specified in subclause 7.4.2.5, shall be included; it uniquely identifies the SCC AS and session on that AS.

7.3.3.6 Timestamp

This information element,as specified in subclause 7.4.2.14, shall be included if using a transport layer protocol that is not a real-time transport layer protocol, it provides the SCC AS local time to the ICS UE.

7.3.3.7 Conference-id

This information element, as specified in subclause 7.4.2.16, is included when the SCC AS invites an ICS UE to join a conference.

7.3.4 BYE – ICS UE initiated

7.3.4.1 General

This message is sent by the ICS UE to the SCC AS to establishment of a session. See table 7.3.4.1.

Message type: I1 BYE

Direction: ICS UE to SCC AS

Table 7.3.4.1: I1 BYE message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – BYE	M	V	2
	7.3.4.2
CallID	Call-Id	M	V	2
	7.2.2.1.4

7.3.4.2 Message Type

Identifies that the message is:

i) an I1 BYE.

7.3.5 BYE – SCC AS initiated

7.3.5.1 General

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.5.1.

Message type: I1 BYE

Direction: SCC AS to ICS UE

Table 7.3.5.1: I1 BYE message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – BYE	M	V	2
	7.3.5.2
CallID	Call-Id	M	V	2
	7.2.2.1.4

7.3.5.2 Message Type

Identifies that the message is:

i) an I1 BYE.

7.3.6 I1 PROGRESS – ICS UE initiated

7.3.6.1 General

This message is sent by the ICE UE to the network to establish of a session. See table 7.3.6.1.

Message type: I1 PROGRESS

Direction: ICS UE to SCC AS

Table 7.3.6.1: I1 PROGRESS message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – PROGRESS	M	V	2
	7.3.6.2
CallID	Call-Id	M	V	2
	7.2.2.1.4
Message Sequence Number	Sequence-Id	M	V	1
	7.2.2.1.5

7.3.6.2 Message Type

Identifies that the message is

i) an I1 PROGRESS.

7.3.7 I1 PROGRESS – SCC AS initiated

7.3.7.1 General

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.3.1.

Message type: I1 PROGRESS

Direction: SCC AS to ICS UE

Table 7.3.3.1: I1 PROGRESS message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – PROGRESS	M	V	2
	7.3.7.2
CallID	Call-Id	M	V	2
	7.2.2.1.4
Message Sequence Number	Sequence-Id	M	V	1
	7.2.2.1.5
SCC AS PSI DN	SCC AS PSI DN	M	LV	3-15
	7.3.7.3

7.3.7.2 Message Type

Identifies that the message is:

i) an I1 PROGRESS.

7.3.7.3 SCC AS PSI DN

This information element, as specified in subclause 7.4.2.5, shall be included; it uniquely identifies the SCC AS and session on that AS.

7.3.8 I1 FAILURE

7.3.8.1 General

This message is sent by the ICE UE to the network or from the network to the ICS UE to identify that an error has occurred. See table 7.3.8.1.

Message type: I1 Failure

Direction: ICS UE to SCC AS and SCC AS to ICS UE

Table 7.3.8.1: I1 Failure message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – FAILURE	M	V	2
	7.3.8.2
Call ID	Call-Id	M	V	2
	7.2.2.1.4
Message Sequence Number	Sequence-Id	M	V	1
	7.2.2.1.5
To-id	To-id	O	TLV	3-X
	7.3.8.3			Note 1
Reason Phrase	Phrase	O	TLV
	7.3.8.4
Note 1 – The length of the To-id information element in combination with the other information elements cannot exceed the length of the transport protocol information element to transport the I1 message.

7.3.8.2 Message Type

Identifies that the message is:

i) an I1 FAILURE.

7.3.8.3 To-id

This information element, as specified in subclause 7.4.2.3, may optionally be included and can appear multiple times. It identifies alternative address’s that the UE should attempt to use. It is the same as the contact header field that is defined in sections 21.3 of RFC 3261 [6].

7.3.8.4 Reason Phrase

This information element, as specified in subclause 7.4.2.13, may optionally be included and can appear multiple time. It is the same as the Reason-Phrase header field that is defined in RFC 3261 [6].

7.3.9 REFER – UE initiated

7.3.9.1 General

This message is sent by the ICS UE to the SCC AS to refer the session to another party. See table 7.3.9.1.

Message type: I1 REFER.

Direction: ICS UE to SCC AS

Table 7.3.9.1: I1 REFER message content

Information element	Type/Reference	Presence	Format	Length
Protocol Information	Protocol Information	M	V	1
	7.2.2.1.2
Message Type	Request Message – REFER	M	V	2
	7.3.9.2
CallID	Call-Id	M	V	2
	7.2.2.1.4
Message Sequence Number	Sequence-Id	M	V	1
	7.2.2.1.5
From-id	From-id 7.3.3.3	O	TLV	3-X Note 1
To-id	To-id 7.3.3.4	O	TLV	3-X Note 1
Refer-to-id	Refer-to-id	M	TLV	3-X
	7.3.9.3			Note 1
Replaces	Replaces 7.3.9.4	O	TLV	3-X Note 1
NOTE 1 The length of this information element in combination with the other information elements cannot exceed the length of the transport protocol information element to transport the I1 message.

7.3.9.2 Message Type

Identifies that the message is:

i) an I1 REFER.

7.3.9.3 Refer-to-id

This information element shall be included; it identifies the party that the session shall be referred to. For the coding of this information element please see subclause 7.4.2.15.

7.3.9.4 Replaces

This information element shall be optionally included. It identifies to the party that an existing dialogue as identified in this information element shall be replaced. For the coding of this information element please see subclause 7.4.2.8.

7.4 I1 information elements and functional definition

7.4.1 I1 information elements

The list of the I1 information elements is shown in table 7.4.1.

Table 7.4.1 I1-information elements

I1 information element Name	Description and content (subclauses)
Error-code	7.4.2.2
From-id	7.4.2.3
To-id	7.4.2.3A
Privacy	7.4.2.4
SCC-AS-id	7.4.2.5
Session-identifier	7.4.2.6
Replaces	7.4.2.8
Accept Contact	7.3.2.9
ERAccept Contact	7.3.2.10
Reject Contact	7.3.2.11
Mid-Call	7.4.2.12
Reason Phrase	7.4.2.13
Timestamp	7.4.2.14
Refer-to	7.4.2.15
Conference-id	7.4.2.16

Error-code

The Error-code information element is included in every I1-Error response message. The Error-code information element is binary encoded SIP failure response. The SIP 4xx request failure responses, the 5xx server failure responses, and the 6xx global failure responses are binary encoded and included in the Error-code information element as specified in subclause 7.4.2.1 and table 7.4.2.1. The interpretation of each binary encoded failure response is analogous to the interpretation of associated SIP failure response.

From-id Information

The From-id Information IE specifies a public user identity of the calling user, e.g., the calling party number, either as an E.164, Identifier or a SIP URI.

The From-id information element may contain either an E.164, a SIP URI or a identifier that identifies a public user identity to be used (see annex A).

To-id Information

The To-id Information IE specifies a public user identity of the called user, e.g., the called party number.

The To-id information element may contain either an E.164, a SIP URI or a identifier that identifies a public user identity to be used (see annex A).

Privacy

The UE uses the Privacy information element to indicate to the SCC AS how to handle the SIP header fields when the SCC AS forwards the SIP requests and responses on behalf of the UE to the far-end UA. The Privacy information element when sent by the UE to the SCC AS contains binary encoded "priv-value" (as specified in the RFC 3323 [8] and RFC 3325 [9]). When the SCC AS, upon receiving a Privacy information element over I1 interface, forwards a SIP request or a response to the far-end UA, the SCC AS behaves as specified in the RFC 3323 [8] and RFC 3325 [9] e.g. the SCC AS inserts a P-Asserted-Identity header field into SIP message as requested by the Privacy information element.

SCC-AS-id

The SCC-AS-id information element contains an International E.164 number representation of the SCC AS PSI DN that points to the SCC AS. When the UE sets up a CS bearer connection by sending a SETUP message to the MSC server, the UE specifies the respective International E.164 number as the called party number. Subsequently the call will be routed to the respective SCC AS via a MGCF where the SCC-AS-PSI-DN will be treated as a wildcard PSI as specified in 3GPP TS 23.003 [15] and procedures as specified in 3GPP TS 24.229 [12] subclause 5.3,2.1 item 3.

Session-identifier

The Session-identifier information element is an identifier used either by the UE or the SCC AS to uniquely and globally identify a I1 session across all interface (i.e. the I1 interface, Gm interface and the IMS). The Session identifier is dynamically allocated by the SCC AS to identify the I1 session that is being established. The SCC AS includes the Session-identifier information element in the first I1 message sent by the SCC AS to the UE. The Session-identifier information element may contain different values, e.g. the Session Transfer Identifier (STI), as specified in subclause 7.4.2.1 and associated subclause 7.4.2.1.

Replaces

The Replaces information element is used by the UE to identify an existing call or a SIP dialog that will be replaced with an I1 session being established over the I1 interface. When the UE wants to replace an existing call or a SIP dialog with a new I1 session, the UE sends an I1 Invite request message to the SCC AS with the Replaces information element that contains the identity of the SIP dialog or a call that will be replaced with a new call being established. In the case of UE assisted T-ADS, the SCC AS may send an I1 Invite request message to the terminating ICS UE with Replaces information element that contains the identity of the SIP dialog to change the service control for the session from Gm to I1.

Accept Contact

The Accept contact information element is used by the UE to identify the SIP feature tags that the UE are included in a SIP Accept Contact header per procedures in RFC 3841 [14]. However if the feature tags are to be appended with "explicit" and or the "require" parameter tags then the SIP feature tag shall not be sent in the Accept Contact but in the ERAccept Contact header information element.

ERAccept Contact

The ERAccept contact information element is used by the UE to identify those SIP feature tags that either "explicit" or "require" parameter tags added per procedures in RFC 3841 [14]. If "explicit" and or "require" parameter tag is required then the feature tag is not included in the Accept Contact information element.

Reject Contact

The Reject contact information element is used by the UE to identify the SIP feature tags that the UE would normally send in a SIP Reject contact header per procedures in RFC 3841 [14].

Mid-Call

The Mid-Call information element is used between ICS UE and the SCC AS to exchange the Mid-call supplementary services control information, e.g. hold, resume, conference.

Timestamp

The Timestamp information element specifies a local time on the I1 message sender. The local time is measured in seconds and it is 32 bits long.

Refer-to

The I1 Refer message indicates that the recipient should contact a third party using the contact information provided in the Refer-to information element and included in the I1 Refer message. The third party is identified either with an E.164 number or a SIP URI and it is included in the Refer-to information element.

Conference-id

The Conference-id information element is used by the SCC AS to convey to the ICS UE the identity of the conference focus (i.e. SIP URI or an E.164 number) that will handle the requested conference call.

Upon a request to create a conference with a conference factory URI, the SCC AS includes in the I1 Success message the Conference-id information element that contains the conference URI (i.e. the E.164 number or a SIP URI of the conference focus). The inclusion of the Conference-id information element in the I1 Success message indicates to the ICS UE that the requested conference has been set and the identity of the conference focus that is handling the respective conference.

When the SCC AS invites an ICS UE to join a conference, the SCC AS sends an I1 Invite message to the invited ICS UE that includes the Conference-id information element. The inclusion of the Conference-id information element in the I1 Invite message indicates to the ICS UE that it has been invited to join a conference and the identity of the conference focus that is handling the respective conference. Subsequently, this ICS UE may use the received Conference-id information element to e.g. leave the indicated conference, invite another ICS UE to the indicated conference, etc.

7.4.2 I1 Information elements encoding

7.4.2.1 General

The structure of the I1 information elements is shown in figure 7.4.2.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
Information Element length (in octets)								2
Information Element body (as required)								3
								etc.

Figure 7.4.2.1: I1 information element format

Each I1 information element contains a common two-octet field followed by a variable-size body. The first octet contains the Information Element code and Code specific values. Each I1 information element is uniquely identified with the respective Information Element code (i.e., encoded with bits numbered 4, 5, to 8 of the first octet). The Code specific value (i.e., encoded with bits numbered 1, 2, and 3 of the first octet) provide additional information about respective I1 information element. For example, if the Information Element code specifies that this is a To-id I1 information element, then the Code specific value will indicate whether the Information Element body contains an E.164 number or SIP URI. The Code specific values for each respective I1 information element are described in the respective subclauses.

The second octet i.e. the Information Element length specifies the length of the I1 information element body (i.e., the number of octets following the Information Element length) in binary format. The bit number 1 of octet number 2 is the list significant bit and bit number 8 of the octet number 2 is the most significant bit. The table 7.4.2.1 specifies the Information Element code for each I1 information element.

Table 7.4.2.1: I1-information element coding

Information Element code	I1 information element Name	Reference subclause
Bits 8 7 6 5 4
1 0 0 1 1	From-id	7.4.2.3
1 0 1 0 0	Privacy	7.4.2.4
1 0 1 0 1	SCC-AS-id	7.4.2.5
1 0 1 1 0	Session-identifier	7.4.2.6
1 0 0 1 0	Replaces	7.4.2.8
1 0 1 1 1	Accept Contact	7.4.2.9
1 0 0 0 1	ERAccept Contact	7.4.2.10
1 1 0 1 1	Reject Contact	7.4.2.11
1 1 0 0 0	Mid-Call	7.4.2.12
1 1 1 0 0	Reason-Phrase	7.4.2.13
1 1 0 0 1	Timestamp	7.4.2.14
1 1 1 0 0	To-id	7.4.2.3A
1 1 1 0 1	Refer-to	7.4.2.15
1 1 1 1 0	Conference-id	7.4.2.16

7.4.2.2 Void

7.4.2.3 From-id Information

The purpose of the From-id information element is to transport a public identity of the From Party. The From-id information element may contain either a SIP URI or a telephone number (e.g. international number, national number) or an identifier value that identifies a known public identity. The Code specific field as specified in table 7.4.2.3.1, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information contained in the From-id information element.

If the From-id Information is a SIP URI username@domainname then the Code specific field as specified in table 7.4.2.3.1 bits 3,2, and 1 shall be set to "010" and shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16].

When bits 3, 2, and 1 of the octet number 1 are to be set to "001" to indicate that the From-id information element contains an E.164 number (see table 7.4.2.3.1). This is deduced when the From-id Information to be used by is a tel URI or a SIP URI with URI parameter User=Phone then the Code specific field and if a tel or SIP URI is identified as being globally unique identified by the presence of "+" character at the start of the digit string.

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the From-id information element contains a number whose type of number is unspecified (see table 7.4.2.3.1) e.g. local or national number. This is deduced when the Identity Information to be used by is a tel URI or a SIP URI with URI parameter User=Phone and if a tel or SIP URI is not identified as being globally unique identified by the presence of "+" character at the start of the digit string.

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the From-id information element contains a public user identity that is an identifier and can be can be derived (see annex A).

When the From-id information element contains an International number (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as follows:

– the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the E.164 digit-string;

– the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the E.164 digit-string;

– the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the E.164 digit-string; and so on until the entire E.164 digit-string is included in the From-id information element; and

– the bit-pattern "1111"iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of the E.164 digit-string, i.e. the bit-pattern of "1111" is used as the end-delimiter for the E.164 digit-string.

When the From-id information element contains an local or national number, the digit-string is included in the octet 3, octet 4, octet 5, etc. as follows:

– the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the digit-string;

– the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the digit-string;

– the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the digit-string; and so on until the entire digit-string is included in the From-id information element; and

– the bit-pattern "1111"iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of the digit-string, i.e. the bit-pattern of "1111" is used as the end-delimiter for the digit-string.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	0	1	1
Information Element length (in octets)								2
Information Element body								3-Y

Figure 7.4.2.3.1-1: From-id information element

Table 7.4.2.3.1: From-id information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	International number, i.e. E.164 number (Note 1)
0 1 0	SIP URI
0 1 1	Identifier (See Annex A)
	Other values are reserved for future use
(octet 3)
SIP URI
	The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16]
(octet 3)
Identifier
	Contains one octet body coded with identifier value that identifies the public user identity.
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(next octet)
Bits (Note 2)
(Note 3)
Note 1 – Prefix or escape digits shall not be included. Note 2 – the next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. Note 3 – The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.4.2.3A To-id Information

The purpose of the To-id information element is to transport a public identity of the To Party. The To-id information element may contain either a SIP URI or a telephone number (e.g. international number, national number) or an identifier value that identifies a known public identity. The Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information contained in the To-id information element,.

If the To-id Information is a SIP URI username@domainname then the Code specific fields bits 3,2, and 1 shall be set to "010" and shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16].

When bits 3, 2, and 1 of the octet number 1 are to be set to "001" it indicates that the To-id information element contains an E.164 number (see table 7.4.2.3.1-2). This is deduced when the To-id to be used by is a tel URI or a SIP URI with URI parameter User=Phone then the Code specific field and if a tel or SIP URI is identified as being globally unique identified by the presence of "+" character at the start of the digit string.

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the To-id information element contains a number whose type of number is unspecified(see table 7.4.2.3.1-2) e.g. local or national number. This is deduced when the To-id to be used by is a tel URI or a SIP URI with URI parameter User=Phone and if a tel or SIP URI is not identified as being globally unique identified by the presence of "+" character at the start of the digit string.

When bits 3, 2, and 1 of the octet number 1 are to be set to "000" it indicates that the To-id information element contains a public user identity that is an identifier and can be can be derived (see annex A).

When the To-id information element contains an International number (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as follows:

– the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the E.164 digit-string;

– the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the E.164 digit-string;

When the To-id information element contains an local or national number, the digit-string is included in the octet 3, octet 4, octet 5, etc. as follows:

– the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the digit-string;

– the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the digit-string;

Table 7.4.2.3A.1-1: To-id information element

8	7	6	5	4	3	2	1	Octet
Information Element code 1 1 1 0 0					Code specific			1
Information Element length (in octets)								2
Information Element body								3
Information Element body								etc.

Table 7.4.2.3A.1-2: To-id information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	International number, i.e. E.164 number (Note 1)
0 1 0	SIP URI
0 1 1	Identifier (See Annex A)
	Other values are reserved for future use
(octet 3)
SIP URI
	The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16]
(octet 3)
Identifier
	Contains one octet body coded with identifier value that identifies the public user identity.
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(next octet)
Bits (Note 2)
(Note 3)
Note 1: Prefix or escape digits shall not be included. Note 2: The next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. Note 3: The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.4.2.4 Privacy

The ICS UE may include the Privacy information element in the I1 Invite message to indicate its privacy preferences that the SCC AS should apply to the SIP session toward the remote UE. When the SCC AS sets up a SIP session on behalf of the UE, the SCC AS sends a SIP INVITE request that includes the privacy information that the SCC AS received in the Privacy information element.

The Privacy information element when sent by the ICS UE to the SCC AS contains binary encoded "priv-value" (with the same semantics as specified in the RFC 3323 [8] and RFC 3325 [9]). The UE may request multiple types of privacy for the same call (see RFC 3323 [8]). Hence, the UE include all of the requested privacy types in its Privacy information element by setting the respective bits as shown in table 7.4.2.4.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	1	0	0
Information Element length (in octets)								2
Information Element body								3

Figure 7.4.2.4.1: Privacy information element

Table 7.4.2.4.1: Privacy information element

(octet 1) Code specific
Bits
3 2 1
0 0 1	(NOTE 1)
	Other values are reserved for future use
(octet 3)
Bit 8
1	The UE indicates to the SCCAS that "Privacy: id" (as specified in the RFC 3325 [9]) is requested (NOTE 2).
Bit 7
1	The UE indicates to the SCCAS that "Privacy: header" (as specified in the RFC 3323 [8]) is requested (NOTE 2)
Bit 6
1	The UE indicates to the SCCAS that "Privacy: session" (as specified in the RFC 3323 [8]) is requested (NOTE 2)
Bit 5
1	The UE indicates to the SCCAS that "Privacy: user" (as specified in the RFC 3323 [8]) is requested (NOTE 2)
Bit 4
1	The UE indicates to the SCCAS that "Privacy: none" (as specified in the RFC 3323 [8]) is requested (NOTE 2)
Bit 3
1	The UE indicates to the SCCAS that "Privacy: critical" (as specified in the RFC 3323 [8]) is requested (NOTE 2)
Bits 2 and 1 reserved for future use

NOTE 1: If the Code specific value is set to "001" it indicates that the Privacy information element consists of three octets and each bit in octet number 3 is interpreted as specified in this table. NOTE 2: The value of "0" in this bit indicates that corresponding "priv-value" (with the same semantics as specified in the RFC 3323 [8] and RFC 3325 [9]) is not used and respective privacy is not requested.

7.4.2.5 SCC-AS-id

The SCC-AS-id information element contains an International E.164 Number representation of the SCC AS PSI DN that points to the SCC AS. The SCC AS PSI DN information element has a minimum length of 3 octets and a maximum length of 10 octets.

The SCC-AS-id information element may contain either a SIP URI or an international telephone number (i.e. an E.164 national number). The Code specific field as specified in table 7.4.2.5.1, the bits 3, 2, and 1 of the octet number 1 specify the type of information that is used to identify the SCC AS. When the SCC AS forwards a SCC AS PSI DN associated with the SCC AS to the UE, the SCC AS will include the SCC AS PSI DN in the SCC-AS-id information element. The PSI DN is an E.164 number.

When the Code specific field as specified in table 7.4.2.5.1, bits 3, 2, and 1 of the octet number 1 shall be set to "001" it indicates that the SCC-AS-id information element contains a SCC AS PSI DN (i.e. an E.164 number). When the SCC-AS-id information element contains a PSI DN (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as shown in table 7.4.2.5.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	1	0	1
Information Element length (in octets)								2
Information Element body								4

Figure 7.4.2.5.1: SCC-AS-id information element

Table 7.4.2.5.1: SCC-AS-id information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	PSI DN, i.e. E.164 number (Note 1)
	Other values are reserved for future use
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(next octet)
Bits
(Note 3)
Note 1 – Prefix or escape digits shall not be included. Note 2 – the next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. Note 3 – The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.4.2.6 Session-identifier

The Session-identifier information element is used either by the ICS UE or the SCC AS to covey the identity of the session being established. The Code specific subfield, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information that is used to identify the session across.

When a SIP dialog or an I1 session is identified with an E.164 number (e.g. with a STI), then this identifier is conveyed across the I1 interface in a Session-identifier information element. In this case, the Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001", as shown in figure 7.4.2.6.1 and table 7.4.2.6.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	1	1	0
Information Element length (in octets)								2
Information Element body								3

Figure 7.4.2.6.1: Session-identifier information element

Table 7.4.2.6.1: Session-identifier information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	Session or a dialog identified with an E.164 number (Note 1)
	Other values are reserved for future use
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(next octet)
Bits
(Note 3)
Note 1 – Prefix or escape digits shall not be included. Note 2 – the next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. Note 3 – The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.4.2.7 Void

7.4.2.8 Replaces

The Replaces information element is included in the I1 Invite message to indicate to the recipient that the I1 session being established will replace the existing SIP dialog identified by the Replaces information element. The Replaces information element also contains the identity of the dialog that will be replaced.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	0	1	0
Information Element length (in octets)								2
								3
								4

Figure 7.4.2.8.1: Replaces information element

Table 7.4.2.8.1: Replaces information element

(octet 1)		Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	The Code specific value set to "001" Specifies that the SIP dialog that will be replaced is identified with a STI that is an E.164 number. (NOTE 1)
	Other values are reserved for future use
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (NOTE 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (NOTE 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (NOTE 2)
(next octet)
Bits
		(NOTE 3)
NOTE 1: Prefix or escape digits shall not be included. NOTE 2: The next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. NOTE 3: The E.164 digit-string terminates with delimiter "1111" either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet, hence indicating the end of the E.164 digit-string.

7.4.2.9 Accept Contact

The UE may include the Accept Contact element in the I1 Invite message to indicate any called feature preferences per RFC 3841 [14]. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set to "001" as specified in table 7.4.2.9.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	0	1	1
Information Element length (in octets)								2
Information Element body								3_Y

Figure 7.4.2.9: Accept Contact information element

Table 7.4.2.9: Accept Contact information element

(octet 1)		Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	Accept Contact
	All other values reserved
(octet 3) Bit Specific
Bits
1	sip.audio as defined in RFC 3840 [15]
2	sip.application as defined in RFC 3840 [15]
3	sip.data as defined in RFC 3840 [15]
4	sip.control as defined in RFC 3840 [15]
5	sip.video as defined in RFC 3840 [15]
6	sip.text as defined in RFC 3840 [15]
7	sip.automata as defined in RFC 3840 [15]
8	sip.duplex = full as defined in RFC 3840 [15]

(octet 4) Bit Specific
Bits
1	sip.duplex = half, as defined in RFC 3840 [15]
2	sip.duplex = receive only as defined in RFC 3840 [15]
3	sip.duplex = send only as defined in RFC 3840 [15]
4	sip.mobility = fixed as defined in RFC 3840 [15]
5	sip.mobility = mobile as defined in RFC 3840 [15]
6	sip.actor =principal, as defined in RFC 3840 [15]
7	sip.actor =attendant, as defined in RFC 3840 [15]
8	sip.actor = msg-taker, as defined in RFC 3840 [15]

(octet 5) Bit Specific
Bits
1	sip.actor – information as defined in RFC 3840 [15]
2	sip.isfocus as defined in RFC 3840 [15]
3	sip.byeless as defined in RFC 3840 [15]
4	sip.rendering – yes as defined in RFC 4235 [16]
5	sip.rendering – no as defined in RFC 4235 [16]
6	sip.rendering – unknown as defined in RFC 4235 [16]
7	sip.message as defined in RFC 4569 [17]
8	sip.ice

(octet 6) Bit Specific
Bits
1	Reserved
2	Reserved
3	Reserved
4	Reserved
5	Reserved
6	Reserved
7	Reserved
8	Extension

7.4.2.10 ERAccept Contact

The UE may include the ERAccept Contact element in the I1 Invite message to indicate any called feature preferences per RFC 3841 [14] that require the "explicit" and or "require" parameter tag appended to them. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set to "001" as specified in table 7.4.2.10.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	1	0	0
Information Element length (in octets)								2
E	R	Feature Tag Value						3-Y

Figure 7.4.2.10: ERAccept Contact information element

Table 7.4.2.10: ERAccept Contact information element

(octet 1)		Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	ERAccept
	All other values reserved
(octet 3-Y) Feature Tag Value
Bit
8	Value 1 "explicit" required as defined in RFC 3841 [14]
7	Value 1 "require" required. as defined in RFC 3841 [14]
6-1	Feature Tag

(octet -3-Y) Bit Specific
Bits
6 5 4 3 2 1
0 0 0 0 0 0	sip.audio as defined in RFC 3840 [15]
0 0 0 0 0 1	sip.application as defined in RFC 3840 [15]
0 0 0 0 1 0	sip.data as defined in RFC 3840 [15]
0 0 0 0 1 1	sip.control as defined in RFC 3840 [15]
0 0 0 1 0 0	sip.video as defined in RFC 3840 [15]
0 0 0 1 0 1	sip.text as defined in RFC 3840 [15]
0 0 0 1 1 0	sip.automata as defined in RFC 3840 [15]
0 0 0 1 1 1	sip.duplex = full as defined in RFC 3840 [15]
0 0 1 0 0 0	sip.duplex = half, as defined in RFC 3840 [15]
0 0 1 0 0 1	sip.duplex = receive only as defined in RFC 3840 [15]
0 0 1 0 1 0	sip.duplex = send only as defined in RFC 3840 [15]
0 0 1 0 1 1	sip.mobility = fixed as defined in RFC 3840 [15]
0 0 1 1 0 0	sip.mobility = mobile as defined in RFC 3840 [15]
0 0 1 1 0 1	sip.actor = principal, as defined in RFC 3840 [15]
0 0 1 1 1 0	sip.actor = attendant, as defined in RFC 3840 [15]
0 0 1 1 1 1	sip.actor -= msg-taker, as defined in RFC 3840 [15]
0 1 0 0 0 0	sip.actor = information as defined in RFC 3840 [15]
0 1 0 0 0 1	sip.isfocus as defined in RFC 3840 [15]
0 1 0 0 1 0	sip.byeless as defined in RFC 4235 [16]
0 1 0 0 1 1	sip.rendering = yes as defined in RFC 4235 [16]
0 1 0 1 0 0	sip.rendering =no as defined in RFC 4235 [16]
0 1 0 1 0 1	sip.rendering = unknown as defined in RFC 4235 [16]
0 1 0 1 1 0	sip.message as defined in RFC 4569 [17]
0 1 0 1 1 1	sip.ice
0 1 1 0 0 0 to 1 1 1 1 1 1	Reserved

7.4.2.11 Reject Contact

The UE may include the Reject Contact element in the I1 Invite message to indicate any called feature preferences per RFC 3841 [15]. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set to "000" as specified in table 7.4.2.11.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	0	0	1	0
Information Element length (in octets)								2
Information Element Body								3-6

Figure 7.4.2.11: Reject Contact information element

Table 7.4.2.11: Reject Contact information element

(octet 3) Bit Specific
Bits
1	sip.audio as defined in RFC 3840 [15]
2	sip.application as defined in RFC 3840 [15]
3	sip.data as defined in RFC 3840 [15]
4	sip.control as defined in RFC 3840 [15]
5	sip.video as defined in RFC 3840 [15]
6	sip.text as defined in RFC 3840 [15]
7	sip.automata as defined in RFC 3840 [15]
8	sip.duplex = full as defined in RFC 3840 [15]

(octet 4) Bit Specific
Bits
1	sip.duplex = half, as defined in RFC 3840 [15]
2	sip.duplex = receive only as defined in RFC 3840 [15]
3	sip.duplex = send only as defined in RFC 3840 [15]
4	sip.mobility = fixed as defined in RFC 3840 [15]
5	sip.mobility = mobile as defined in RFC 3840 [15]
6	sip.actor =principal, as defined in RFC 3840 [15]
7	sip.actor =attendant, as defined in RFC 3840 [15]
8	sip.actor = msg-taker, as defined in RFC 3840 [15]

(octet 5) Bit Specific
Bits
1	sip.actor – information as defined in RFC 3840 [15]
2	sip.isfocus as defined in RFC 3840 [15]
3	sip.byeless as defined in RFC 4235 [16]
4	sip.rendering – yes as defined in RFC 4235 [16]
5	sip.rendering – no as defined in RFC 4235 [16]
6	sip.rendering – unknown as defined in RFC 4235 [16]
7	sip.message as defined in RFC 4569 [17]
8	sip.ice

(octet 6) Bit Specific
Bits
1	Reserved
2	Reserved
3	Reserved
4	Reserved
5	Reserved
6	Reserved
7	Reserved
8	Extension

7.4.2.12 Mid-Call

The Mid-Call information element is used either by the ICS UE or the SCC AS to covey the supplementary services control information. The Code specific subfield, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information that is used to identify the services control type.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	1	0	0	0
Information Element length (in octets)								2
Information Element Body								3

Figure 7.4.2.12.1: Mid-Call information element

Table 7.4.2.12.1: Mid-Call information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	Place the call on hold, see subclause 6.3.4 (NOTE 1, NOTE 2)
0 1 0	Resume the call, see subclause 6.3.4 (NOTE 1, NOTE 2)
0 1 1	Add the third party to an active point-to-point call (NOTE 3)
	Other values are reserved for future use
NOTE 1: When this Code specific value is used, the Information Element body is empty and the Information Element length value is set to zero. NOTE 2: When included by ICS UE, the element indicates that ICS UE puts the call on hold. When included by SCC AS, the element indicates that remote UE puts the call on hold. NOTE 3: If the ICS UE, that has an active end-to-end call with a remote party, wants to add a third party to this end-to-end call (i.e. to format three way conference call), the ICS UE will send an I1 Mid Call message to the SCC AS that includes an I1 Mid-Call information element as shown in the table 7.4.2.12.2. In the I1 Mid-Call information element, the ICS UE sets the Code specific value to "011" and identifies the third party (that will be added to the active end-to-end call) with the third party E.164 number as shown in the table 7.4.2.12.2. The I1 Mid call message is sent to the SCC AS over the I1 session associated with the active end-to-end call. In the returned I1 Success message the SCC AS includes the Conference-id information element that identifies the conference focus that will handle the resulting conference call. Subsequently, the ICS UE may request the conference focus to add additional participants to the conference call.

Table 7.4.2.12.2: Mid-Call information element

(octet 1)
Bits
87654	Information Element code
10110	Indicates that this is a Mid-call information element
3 2 1	Code specific
	The Code specific values as shown in Table 7.4.2.12.1
(octet 2)
Bits
87654321	Specify Information Element length (in octets)
	The URI shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16]
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string (Note 1)
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 1, Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 1, Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 1, Note 2)
(next octet)
Bits (Note 1, Note 2)
(Note 3)
Note 1 – Prefix or escape digits shall not be included. Note 2 – the next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1. Note 3 – The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.4.2.13 Reason-Phrase

The purpose of the Reason-Phrase field is as defined in RFC 3261[6].

The information element body as specified in table 7.4.2.13.1 shall be encoded to an octet string according to UTF-8 encoding rules as specified in RFC 3629 [16]. The Code Specific value the bits 3, 2, and 1 of the octet number 1 is set to "001" as specified in table 7.4.2.13.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	1	1	0	0
Information Element length (in octets)								2
Information Element Body								3-Y

Figure 7.4.2.13.1: Reason-Phrase information element Table 7.4.2.13.1: Reason-Phrase information element

(octet 1)		Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	Reason Phrase
	All other values reserved
(octet 3-Y)
	Reason encoded as specified in RFC 3629 [16].

7.4.2.14 Time Stamp

The Timestamp information element is used by the ICS UE and the SCC AS to convey local time. The Timestamp information element contains local time measured in seconds.

When the Code specific field as specified in table 7.4.2.14.1, bits 3, 2, and 1 of the octet number 1 shall be set to "001", it indicates that the Timestamp information element contains local time measured in seconds in 32 bits format. The time is conveyed across the I1 interface in a Timestamp information element.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	1	0	0	1
Information Element length (in octets)								2
Information Element body								3-6

Figure 7.4.2.14.1: Timestamp information element

Table 7.4.2.14.1: Timestamp information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	Timestamp (Note 1)
	Other values are reserved for future use
(octet 3)
Bits
8 7 6 5 4 3 2 1	the first (right) 8 bits of the Timestamp
(octet 4)
Bits
8 7 6 5 4 3 2 1	the next 8 bits of the Timestamp
(octet 5)
Bits
8 7 6 5 4 3 2 1	the next 8 bits of the Timestamp
(octet 6)
Bits
8 7 6 5 4 3 2 1	the next 8 bits of the Timestamp

Note 1 – Timestamp in 32 bits format.

7.4.2.15 Refer-to

The Refer-to information element included in the I1 Refer message identifies a third party that the recipient of the I1 Refer message should contact. The third party is identified either with an E.164 number or a SIP URI and it is included in the Refer-to information element as shown in figure 7.4.2.15.1 and table 7.4.2.15.1.

The Code specific field as specified in table 7.4.2.15.1, the bits 3, 2, and 1 of the octet number 1 specify the type of information that is used to identify the third party to be contacted.

When the Code specific field (bits 3, 2, and 1 of the octet number 1) is set to "001", as shown in table 7.4.2.15.1, it indicates that the Refer-to information element contains an E.164 number, i.e. the third party is identified with an E.164 number. When the Refer-to information element contains an E.164 number, the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as shown in table 7.4.2.15.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	1	1	0	1
Information Element length (in octets)								2
Information Element body								4

Figure 7.4.2.15.1: Refer-to information element

Table 7.4.2.15.1: Refer-to information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	The third party to be contacted is identified with an E.164 number (Note 1)
	Other values are reserved for future use
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(next octet)
Bits
(Note 3)
Note 1 – Prefix or escape digits shall not be included. Note 2 – The next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. Note 3 – The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.4.2.16 Conference-id

The Conference-id information element may contain either a SIP URI or an international telephone number (i.e. an E.164 national number). The Code specific field as specified in table 7.4.2.16.1, the bits 3, 2, and 1 of the octet number 1 specify the type of information that is used to identify the conference focus.

When the Code specific field (bits 3, 2, and 1 of the octet number 1) is set to "001", as shown in table 7.4.2.16.1, it indicates that the Conference-id information element contains an E.164 number, i.e. the conference focus is identified with an E.164 number. When the Conference-id information element contains an E.164 number, the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as shown in table 7.4.2.16.1.

8	7	6	5	4	3	2	1	Octet
Information Element code					Code specific			1
1	1	1	1	0
Information Element length (in octets)								2
Information Element body								4

Figure 7.4.2.16.1: Conference-id information element

Table 7.4.2.16.1: Conference-id information element

(octet 1) Code specific
Bits
3 2 1
0 0 0	Unspecified
0 0 1	Conference focus is identified with an E.164 number (Note 1)
	Other values are reserved for future use
(octet 3)
Bits
8 7 6 5	the most significant digit of the E.164 digit-string
(octet 3)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
8 7 6 5	the next significant digit of the E.164 digit-string (Note 2)
(octet 4)
Bits
4 3 2 1	the next significant digit of the E.164 digit-string (Note 2)
(next octet)
Bits
(Note 3)
Note 1 – Prefix or escape digits shall not be included. Note 2 – The next significant digits of the E.164 digit-string are included in subsequent bits 8, 7, 6, and 5 or bits 4, 3, 2. Note 3 – The E.164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicating the end of the E.164 digit-string.

7.5 Session states and Session control procedures

7.5.1 General

This clause defines the basic session control states that an individual session may acquire. Since several sessions may exist simultaneously across the I1 interface and each session may be in a different state, the session states describe the state of a particular session rather then describing the state of the I1 interface. The procedures for session control are given in subclause 7.5.3.

7.5.2 Session states

7.5.2.1 Session originated by the ICS UE

7.5.2.1.1 Session states at ICS UE – ICS UE originated call

This subclause lists the session states that may exist at the UE for a session originated by the ICS UE.

– null: No I1 session exists.

– trying: This state exists for an UE originated session, when the ICS UE has requested a session establishment by sending an I1Invite message but has not yet received any response.

– proceeding: This state exists for an UE originated session when the ICS UE has received an I1 Progress message with Progress reason set to Call progressing from the SCC AS acknowledging that the SCC AS has received the I1 Invite message.

– alerted: This state exists for an UE originated session when the calling ICS UE has received an I1 Progress message with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated.

– confirmed: This state exists for an UE originated session when the ICS UE has received an I1 Success message indicating that the remote endpoint has accepted the session.

7.5.2.1.2 Session states at SCC AS – ICS UE originated call

This subclause lists the I1 session states that may exist at the SCC AS for a I1 session originated by the ICS UE.

– null: No I1 session exists.

– initiated: This state exists for an UE originated I1 session when the SCC AS has received an I1 Invite message but has not yet responded.

– progressing: This state exists for an UE originated I1 session when the SCC AS has sent an I1 Progress message with Progress reason set to Call progressing acknowledging that the SCC AS has received the I1Invite message.

– alerting: This state exists for an UE originated I1 session when the SCC AS has sent an I1 Progress message with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated.

– confirmed: This state exists for an UE originated I1 session when the SCC AS has sent an I1 Success message indicating that the I1 session has been accepted.

7.5.2.2 Session terminated at the ICS UE

7.5.2.2.1 Session states at UE – ICS UE terminated call

This subclause lists the I1 session states that may exist in the UE for a I1 session terminated at the ICS UE.

– null: No I1 session exists.

– initiated: This state exists for a I1 session terminated at the UE when the ICS UE has received an I1Invite message but has not yet responded.

– progressing: This state exists for a I1 session terminated at the UE when the ICS UE has sent an I1 Progress message with Progress reason set to Call progressing acknowledging that the ICS UE has received the I1Invite message.

– alerting: This state exists for a I1 session terminated at the UE when the ICS UE has sent an I1 Progress message with Progress reason set to Ringing indicating that local alerting has been initiated but the offered call has not yet answered.

– confirmed: This state exists for a I1 session terminated at the UE when the ICS UE has sent an I1 Success message indicating that the I1 session has been accepted.

7.5.2.2.2 Session states at SCC AS – ICS UE terminated session

This subclause lists the session states that may exist in the UE for a session terminated at the ICS UE.

– null: No I1 session exists.

– trying: This state exists for a session terminated at the ICS UE when the SCC AS has requested a session establishment by sending an I1 Invite message but has not yet received a response.

– proceeding: This state exists for a session terminated at the ICS UE when the SCC AS has received an I1 Progress message with Progress reason set to Call progressing from the UE acknowledging that the ICS UE has received the I1Invite message.

– alerted: This state exists for an UE terminated session when the SCC AS has received an I1 Progress message with Progress reason set to Ringing indicating that the UE has initiated local alerting.

– confirmed: This state exists for a session terminated at the UE when the SCC AS has received an I1 Success message indicating that the ICS UE has accepted the session.

7.5.2.3 Session release

7.5.2.3.1 Session states at ICS UE

This subclause lists the session states that may exist at the UE for a session released either by the ICS UE or SCC AS.

– release-requested: This state exists when the ICS UE has requested the SCC AS to clear the session by sending an I1 Bye message and the CS bearer has not been cleared using receipt of a DISCONNECT message, in accordance with 3GPP TS 24.008 [3]. Upon determining that the CS bearer has cleared using a DISCONNECT message or determining that an I1 Success message was received, the UE transits to a "null" state. The ICS UE attempts to clear the CS bearer if a retransmission timer fires.

– release-indication: This state exists when the ICS UE has received an I1 Bye message from the SCC AS requesting the UE to clear the session. Per subclause 6.2.3.1.2, upon subsequent clearing the CS bearer using a DISCONNECT message, in accordance with 3GPP TS 24.008 [3], or upon subsequent sending of an I1 Success message, the ICS UE transits to a "null" state.

NOTE: The retransmission timer, which is not defined in this specification, is selected appropriately for the transport layer in use.

7.5.2.3.2 Session states at SCC AS

This subclause lists the session states that may exist at the SCC AS for a session released either by the ICS UE or SCC AS.

– release-requested: This state exists when the SCC AS has requested the ICS UE to clear the session by sending an I1 Bye message and the CS bearer has not been cleared. Upon determining that the CS bearer has cleared using a DISCONNECT message, in accordance with 3GPP TS 24.008 [3] and 3GPP TS 24.292 [5] or determining that a I1 Success message was received, the SCC AS transits to a "null" state. The SCC AS attempts to clear the CS bearer if a retransmission timer fires.

– release-indication: This state exists when the SCC AS has received an I1Bye message from the ICS UE requesting the SCC AS to clear the session. Upon subsequent clearing the CS bearer using a SIP BYE request sent towards the MGCF or upon subsequent sending of an I1 Success message in accordance with 3GPP TS 24.292 [5], the SCC AS transits to a "null" state.

NOTE: The retransmission timer, which is not defined in this specification, is selected appropriately for the transport layer in use.

7.5.3 Session control procedures

7.5.3.1 General

Before the I1 session establishment procedures are invoked, a transport-layer connection must be established between the ICS UE and the SCC AS.

7.5.3.2 Session establishment

7.5.3.2.1 UE-originating case

7.5.3.2.1.1 Procedure at ICS UE

7.5.3.2.1.1.1 Session request

The ICS UE initiates I1 session establishment procedure by sending an I1 Invite message to the SCC AS across the I1 interface. The I1 Invite message shall contain the I1 information elements as specified in subclause 6.2.1.2.1. Following the transmission of the I1 Invite message the I1 session shall transit to the "trying" state. When the I1 session identified by the Call-Identifier field (see subclause 7.2.2.1.4) enters the "trying" state, the ICS UE sets timer F to fire in T3 seconds and timer F1 to fire in T4 seconds.

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, the ICS UE sets timer E to fire in T1 seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the I1 session is still in the "trying" state, the original I1 Invite message (with the same Call-Identifier field and sequence number) is retransmitted and the timer E is reset to value of MIN(2*T1, T2). If the timer E fires again, the original I1 Invite message (with the same sequence number) is retransmitted again and the timer E is reset to a MIN (4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2.

NOTE 1: Since the values for the timers T1, T2 and T3 depend on the technology that is used to implement the transport-layer connection (e.g. USSD), the values for the timers T1, T2 and T3 will be specified for each technology.

If timer F fires or timer F1 fires while the session is still in the "trying" state, or timer E has fired 5 times the sessioncall establishment has failed, and the ICS UE clears the I1 session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the SCC AS is used, the ICS UE disables timer E.

7.5.3.2.1.1.2 Session proceeding

If an I1 Progress message with Progress reason set to Call progressing and containing an SCC AS PSI DN is received at the ICS UE while the I1 session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "trying" state, the I1 session shall transit to the "proceeding" state and timer F1 shall be stopped and cleared. If an an unreliable transport-layer connection between the ICS UE and the SCC AS is used timer E shall be stopped and cleared.

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the "proceeding" state the ICS UE sets the timer E to fire in T2 seconds. If timer E fires while the session is in the "proceeding" state, the original I1 Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 seconds. This process continues so that retransmissions of the original I1 Invite message occur every T2 seconds.

If timer F fires while the session is in the "proceeding" state, or timer E has fired 5 times the session establishment has failed, and the ICS UE clears the call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the ICS UE and the SCC AS is used, the ICS UE disables timer E.

Upon receiving the I1 Progress message with Progress reason set to Call progressing from the SCC AS, the ICS UE initiates the setting up of the CS bearer connection toward the SCC AS by sending a SETUP message to the MSC Server as specified in subclause 6.2.1.2.1.

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the I1 Progress message with Progress reason set to Call progressing has been received by the UE. Subsequently, the SCC AS can progress the I1 session toward the far end by sending a SIP INVITE request to the far end.

7.5.3.2.1.1.3 Alerting indication

If an I1 Progress message with Progress reason set to Ringing is received while the I1 session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "proceeding" state, the I1 session shall transit to the "alerted" state.

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the "alerted" state the ICS UE sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, the original I1 Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 seconds. This process continues so that retransmissions of the original I1 Invite request occur every T2 seconds.

If timer F fires while the session is in the "alerted" state, or timer E has fired 5 times the session establishment has failed, and the ICS UE clears the call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the ICS UE and the SCC AS is used, the ICS UE disables timer E.

If the ICS UE receives an I1 Progress message with Progress reason set to Ringing, the ICS UE may begin a locally-generated alerting procedure.

7.5.3.2.1.1.4 Session connected

If an I1 Success message is received from the SCC AS while the I1 session at the UE is either in the "proceeding" state or "alerted" state, the I1 session shall transit to the "confirmed" state (i.e., the I1 session has been established) and the timer F is disabled. The ICS UE shall stop any locally generated alerting procedures (if applied).

If an unreliable transport-layer connection between the ICS UE and the SCC AS was used, the timer E is disabled, hence the ICS UE stops retransmitting the I1 Invite message. In addition, the ICS UE discards any subsequent I1 Success message, if it is received over the unreliable transport-layer connection.

7.5.3.2.1.2 Procedure at SCC AS

7.5.3.2.1.2.1 Session request

Upon receiving an I1 Invite message from the ICS UE over the I1 interface, the session at the SCC AS shall transit to the "initiated" state. Once in the "initiated" state, the SCC AS shall immediately respond by sending an I1 Progress message with Progress reason set to Call progressing to the UE and the session enters the "progressing" state, The I1 Progress message with Progress reason set to Call progressing shall contain the I1 information elements as specified in subclause 6.2.1.3.1.

NOTE: The receipt of the I1 Progress message with Progress reason set to Call progressing at the UE, will trigger the UE to set up a CS bearer connection toward the SCC AS by sending a SETUP message to the MSC Server as specified in subclause 6.2.1.2.1.

7.5.3.2.1.2.2 Session progressing

If the SCC AS receives a retransmitted I1 Invite message from the ICS UE, while the I1 session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "progressing" state, the SCC AS shall retransmit the previously sent I1 Progress message with Progress reason set to Call progressing to the ICS UE.

NOTE: The SCC AS receives a retransmitted I1 Invite message only if the transport-layer connection between the ICS UE and the SCC AS is an unreliable transport-layer connection. While the I1 session is in the "progressing" state, the SCC AS may send to the ICS UE either an I1 Progress message with Progress reason set to Ringing, an I1 Success message indicating that the I1 session has been accepted, or a new I1 Progress response with Progress reason set to Call progressing.

If timer F fires while the session is in the "progressing" state, the I1 session establishment has failed, and the SCC AS clears the I1 session, as described in subclause 6.2.3.

7.5.3.2.1.2.3 Alerting indication

If the SCC AS sends an I1 Progress message with Progress reason set to Ringing to the ICS UE, the session state at the SCC AS shall transit to the "alerting" state.

If the SCC AS receives a retransmitted I1 Invite message from the ICS UE identified by a valid Call-Identifier field (see subclause 7.2.2.1.4), while the session is in the "alerting" state, the SCC AS shall retransmit the previously sent I1 Progress message with Progress reason set to Ringing to the ICS UE.

NOTE: The SCC AS receives a retransmitted I1 Invite message only if the transport-layer connection between the UE and the SCC AS is an unreliable transport-layer connection.

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the SCC AS clears the session, as described in subclause 6.2.3.

7.5.3.2.1.2.4 Session connected

If the SCC AS sends an I1 Success message to the ICS UE indicating that the session has been accepted, the session state at the SCC AS shall transit to the "confirmed" state.

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the "confirmed" state the SCC AS sets timer G to fire in (n*T2) seconds. For reliable transport-layer connection timer G is not used. If a retransmitted I1 Invite message is received while the timer G is running, the timer G is reset to fire in (n*T2) seconds, and the I1 Success message is retransmitted. The firing of the timer G indicates that the ICS UE has received the I1 Success message and the ICS UE has stopped the retransmission of the I1 Invite message.

If timer G fires while the session is in the "confirmed" state, the timer F is disabled.

If timer F fires while the session is in the "proceeding" state, or timer G has fired 5 times the session establishment has failed, and the SCC AS resets timer G and clears the session, as described in subclause 6.2.3.

7.5.3.2.2 UE-terminating case

7.5.3.2.2.1 Procedure at ICS UE

7.5.3.2.2.1.1 Session request

Upon receiving an I1 Invite message from the SCC AS over the I1 interface, the session at the ICS UE shall transit to the "initiated" state. Once in the "initiated" state, the ICS UE shall immediately respond by sending an I1 Progress message with Progress reason set to Call progressing to the SCC AS and enter the "progressing" state. The I1 Progress message with Progress reason set to Call progressing shall contain the I1 information elements as specified in subclause 6.2.1.2.2.

NOTE: The receipt of the I1 Invite message at the UE will trigger the UE to set up a CS bearer connection toward the SCC AS by sending a SETUP message to the MSC Server as specified in subclause 6.2.1.2.1.

When the session enters the "initiated" state, the ICS UE also sets timer F to fire in T3 seconds.

7.5.3.2.2.1.2 Session progressing

If the ICS UE receives a retransmitted I1 Invite message from the SCC AS, while the I1 session is in the "progressing" state, the ICS UE shall retransmits the previously sent I1 Progress message with Progress reason set to Call progressing to the UE.

NOTE: The UE receives a retransmitted I1 Invite message only if the transport-layer connection between the UE and the SCC AS is an unreliable transport-layer connection.

While the session is in the "progressing" state, the ICS UE may send to the SCC AS with the same Call-Identifier field (see subclause 7.2.2.1.4), either an I1 Progress message with Progress reason set to Ringing, an I1 Success message indicating that the call has been accepted, or a new I1 Progress message with Progress reason set to Call progressing.

If timer F fires while the session is in the "progressing" state, the session establishment has failed, and the ICS UE clears the call, as described in subclause 6.2.3.

7.5.3.2.2.1.3 Alerting indication

If the ICS UE sends an I1 Progress message with Progress reason set to Ringing, the session state at the ICS UE shall transit to the "alerting" state.

If the ICS UE receives a retransmitted I1 Invite message from the SCC AS with the same Call-Identifier field (see subclause 7.2.2.1.4), while the session is in the "alerting" state, the ICS UE shall retransmit the previously sent I1 Progress message with Progress reason set to Ringing to the SCC AS.

NOTE: The UE receive a retransmitted I1 Invite message only if the transport-layer connection between the UE and the SCC AS is an unreliable transport-layer connection.

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the UE clears the session, as described in subclause 6.2.3.

7.5.3.2.2.1.4 Session connected

If the ICS UE sends an I1 Success message with a valid Call-Identifier field (see subclause 7.2.2.1.4) indicating that the session has been accepted, the session state at the UE transits to the "confirmed" state.

If an unreliable transport-layer connection between the UE and the SCC AS is used, the ICS UE sets timer G to fire in (n*T2) seconds. For reliable transport-layer connection timer G is not used. If an I1 Invite message is received while the timer G is running, the timer G is reset to (n*T2) seconds, and the I1 Success message is retransmitted. The firing of the timer G indicates that the SCC AS has received the Success message and has stopped the retransmission of the I1 Invite message.

If timer G fires while the session is in the "confirmed" state or timer G has fired 5 times, the timer F is disabled.

If timer F fires while the session is in the "confirmed" state, the session establishment has failed, and the ICS UE clears the session, as described in subclause 6.2.3.

7.5.3.2.2.2 Procedure at SCC AS

7.5.3.2.2.2.1 Session request

The SCC AS initiates a session establishment procedure by sending an I1 Invite message to the UE across the I1 interface. The I1 Invite message shall contain the I1 information elements as specified in subclause 6.2.1.3.2. Following the transmission of the I1 Invite message the session shall transit to the "trying" state. When the session enters the "trying" state, the SCC AS sets timer F to fire in T3 seconds timer F1 to fire in T4 seconds.

If an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS sets timer E to fire in T1 seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the session is still in the "trying" state, the original I1 Invite message (with the same sequence number) is retransmitted and the timer E is reset to value of MIN(2*T1, T2). If the timer E fires again, the original I1 Invite message (with the same Call-Identifier field and sequence number) is retransmitted again and the timer E is reset to a MIN (4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2.

If timer F fires or timer F1 fires while the session is still in the "trying" state or timer E has fired 5 times, the session establishment has failed, and the SCC AS clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS disables timer E.

7.5.3.2.2.2.2 Call proceeding

If an I1 Progress message with Progress reason set to Call progressing is received at the SCC AS while the session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "trying" state, the session shall transit to the "proceeding" state and timer F1 shall be stopped and cleared.

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the "proceeding" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the "proceeding" state, the original I1 Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 seconds. This process continues so that retransmissions of the original I1 Invite message occur every T2 seconds.

If timer F fires while the session is in the "proceeding" state or timer E has fired 5 times, the session establishment has failed, and the SCC AS clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS disables timer E.

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the I1 Invite message has been received by the UE.

7.5.3.2.2.2.3 Alerting indication

If an I1 Progress message with Progress reason set to Ringing is received while the session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) is in the "proceeding" state, the session shall transit to the "alerted" state.

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the "alerted" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, the original I1 Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 seconds. This process continues so that retransmissions of the original I1 Invite message occur every T2 seconds.

If timer F fires while the session is in the "alerted" state or timer E has fired 5 times, the session establishment has failed, and the SCC AS clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS disables timer E.

7.5.3.2.2.2.4 Session connected

If an I1 Success message is received from the ICS UE while the I1 session identified by a valid Call-Identifier field (see subclause 7.2.2.1.4) at the SCC AS is either in the "proceeding" state or "alerted" state, the I1 session shall transit to the "confirmed" state (i.e., the I1 session has been established) and the timer F is disabled.

If an unreliable transport-layer connection between the UE and the SCC AS was used, the timer E is disabled, hence the SCC AS stops retransmitting the I1 Invite message. In addition, the SCC AS discards any subsequent I1 Success message, if it is received over the unreliable transport-layer connection.

7.5.3.3 I1 service control signalling release

7.5.3.3.1 Initiating release of I1 service control signalling

The ICS UE or the SCC AS can release a I1 service control signalling session at any time irrespective of its state. The ICS UE or the SCC AS releases the I1 service control signalling session by sending an I1 Bye message across the I1 interface. The I1 Bye message shall contain the I1 information elements as specified in subclause 6.2.3.

If an I1 Success message is received while the I1 service control signalling session is in the "release-requested" state, it transits to the "null" state (i.e., the I1 service control signalling session has been released).

7.5.3.3.2 Responding to release of I1 service control signalling

If either the ICS UE or the SCC AS receives an I1 Bye message across the I1 interface that contains a Call-Identifier field (see subclause 7.2.2.1.4) for a Call-Identifier field value identifying an I1 session that is any state other than null state, the state of the I1 service control signalling session at the recipient side of the I1 Bye message (i.e. either at the ICS UE or the SCC AS) shall transit to the "release-indication" state. If there are more I1 service control signalling sessions, once in the "release-indication" state, the recipient side of the I1 Bye message shall immediately respond by sending an I1 Success message.

7.5.3.4 Receipt of a transport protocol error

7.5.3.4.1 USSD Transport

If the ICS UE or SCC AS receives "systemFailure" or "unexpectedDataValue" as specified in 3GPP TS 24.080 [24] then:

a) the I1 session is cleared, as described in subclause 6.2.3; and

b) I1 shall be disabled until:

i) the UE changes PLMNs identified by MNC received in the Location area identification IE as specified in 3GPP TS 24.008 subclause 10.5.1.3 in the Location updating accept message as defined in 3GPP TS 24.008 subclause 9.2.13; or

ii) the UE is turned off.

Annex A (normative):
Data structure associating keys with values

A.1 General

A UE and a SCC AS maintain a hash table associating keys with values. The keys shall be hashes resulting of applying a hashing function to string values. SHA-1 shall be used as the hash algorithm.

A.2 Associating keys with values

The UE and the SCC AS shall have one or more tables associating keys with values.

A.2.1 Associating keys with public user identities

The UE and the SCC AS shall create a hash table of the SIP URIs present in the P-Associated-URI header field. If the UE and SCC AS also subscriber to the Reg-Event package as documented in 3GPP TS 24.229 [12] the UE and SCC AS shall create a hash table of the GRUU’s for URIs received in the Reg-Event package in addition to those received in the P-Associated-URI header field.

NOTE: The 200 (OK) response to a incoming REGISTER request includes a P-Associated-URI header field and is delivered to the SCC AS as part of the third party registration procedures documented in 3GPP TS 24.229 [12].

Annex B (informative):
Change history

Change history
Date	TSG #	TSG Doc.	CR	Rev	Subject/Comment	Old	New
2009-04	CT1#58	C1-092099			Initial skeleton from rapporteur	–	0.0.0
2009-04	CT1#58	C1-092097			Scope of TS 24.294	0.0.0	0.1.0
2009-06	CT1#59	C1-092980			I1 messages	0.1.0	0.2.0
2009-06	CT1#59	C1-092981			Text for introduction	0.1.0	0.2.0
2009-06	CT1#59	C1-093056			Procedures for session setup when terminated in ICS UE	0.1.0	0.2.0
2009-06	CT1#59	C1-093067			I1 protocol overview	0.1.0	0.2.0
2009-06	CT1#59	C1-093068			Text for session setup	0.1.0	0.2.0
2009-08	CT1#60	C1-093244			I1 Call States	0.2.0	0.3.0
2009-08	CT1#60	C1-093368			Procedure for adding I1 control to existing CS session (I1 augmentation)	0.2.0	0.3.0
2009-08	CT1#60	C1-093727			Corrections to I1 protocol overview	0.2.0	0.3.0
2009-08	CT1#60	C1-093728			I1 message encoding	0.2.0	0.3.0
2009-08	CT1#60	C1-093729			I1 for Supplementary Service Invocation	0.2.0	0.3.0
2009-08	CT1#60	C1-093734			I1 Call origination at UE	0.2.0	0.3.0
2009-08	CT1#60	C1-093735			I1 Call origination at SCC AS	0.2.0	0.3.0
2009-08	CT1#60	C1-093736			I1 Call terminated at UE	0.2.0	0.3.0
2009-08	CT1#60	C1-093741			Procedure for session termination with UE assisted T-ADS	0.2.0	0.3.0
2009-08	CT1#60	C1-093742			Procedure for Gm fallback to I1	0.2.0	0.3.0
2009-08	CT1#60	C1-093743			I1 protocol functionality	0.2.0	0.3.0
2009-08	CT1#60	C1-093922			I1 Refer	0.2.0	0.3.0
2009-08	CT1#60	C1-093924			I1 information elements	0.2.0	0.3.0
2009-08	CT1#60	C1-093929			I1 information element format	0.2.0	0.3.0
2009-08	CT1#60	C1-093936			I1 message structure	0.2.0	0.3.0
2009-09					Editorial fixes	0.3.0	0.3.1
2009-10	CT1#61	C1-094053			Call origination at UE	0.3.1	0.4.0
2009-10	CT1#61	C1-094056			Call termination at UE	0.3.1	0.4.0
2009-10	CT1#61	C1-094058			From-id and To-id encoding	0.3.1	0.4.0
2009-10	CT1#61	C1-094060			Replaces informat element	0.3.1	0.4.0
2009-10	CT1#61	C1-094352			Cleanup of TS 24.294	0.3.1	0.4.0
2009-10	CT1#61	C1-094502			Message Formats	0.3.1	0.4.0
2009-10	CT1#61	C1-094503			Call origination at SCC AS	0.3.1	0.4.0
2009-10	CT1#61	C1-094504			Call termination at SCC AS	0.3.1	0.4.0
2009-10	CT1#61	C1-094505			Error-code information element	0.3.1	0.4.0
2009-10	CT1#61	C1-094506			Privacy, SCC-AS-id, and Session-identifier encoding	0.3.1	0.4.0
2009-10	CT1#61	C1-094507			I1 Call release	0.3.1	0.4.0
2009-10	CT1#61	C1-094587			Alignment with TS 24.292	0.3.1	0.4.0
2009-10					Editorial fixes	0.4.0	0.4.1
2009-11	CT1#62	C1-094892			Conveying the STI to the UE	0.4.1	0.5.0
2009-11	CT1#62	C1-094893			SCC AS assigning the dynamic STI	0.4.1	0.5.0
2009-11	CT1#62	C1-094894			Conveying the STI for call termination	0.4.1	0.5.0
2009-11	CT1#62	C1-095127			Removal and correction of redundant Editor’s Notes	0.4.1	0.5.0
2009-11	CT1#62	C1-095128			Functional entities	0.4.1	0.5.0
2009-11	CT1#62	C1-095133			Correction of tables	0.4.1	0.5.0
2009-11	CT1#62	C1-095135			Resolve Editor’s notes with including SDP information	0.4.1	0.5.0
2009-11	CT1#62	C1-095414			Session-identifier	0.4.1	0.5.0
2009-11	CT1#62	C1-095415			Definitions	0.4.1	0.5.0
2009-11	CT1#62	C1-095460			Remove the description of the USSD in 7.1	0.4.1	0.5.0
2009-11	CT1#62	C1-095461			General behaviour of ICS UE and SCC AS	0.4.1	0.5.0
2009-11	CT1#62	C1-095462			Correction of the introduction of I1 protocol	0.4.1	0.5.0
2009-11	CT1#62	C1-095463			Session release	0.4.1	0.5.0
2009-11	CT1#62	C1-095464			On Replaces information element	0.4.1	0.5.0
2009-11	CT1#62	C1-095465			I1 Bye procedures	0.4.1	0.5.0
2009-11					Editorial fixes	0.5.0	0.5.1
2009-12	CT#46				V1.0.0 created by MCC for presentation to CT-46 for information and approval	0.5.1	1.0.0
2009-12	CT#46				V9.0.0 created by MCC after approval at CT-46	1.0.0	9.0.0
2010-03	CT#47	CP-100137	0001	1	No STN	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0002	1	No forking for I1 protocol	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0005	1	Call-Identifier	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0006	1	Clean up of linkage between I1 specifications	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0008	1	Clarification of call set-up procedures	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0009	1	Completion of setting BCD calling parameter for I1 calls	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0012	1	Add missing references	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0013	1	Delete unneeded definitions	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0014	1	Delete unneeded Editor’s Notes	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0015		Privacy information element	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0016		Replaces information element	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0017		Gm fallback to I1	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0018	1	Retaining the use of CS access – procedure at UE	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0019	1	Retaining the use of CS access – procedure at SCC AS	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0020	2	Media-transfer from PS to CS access	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0021	2	Transferring the media from PS to CS domain – procedure at UE	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0022	1	Transferring the media from PS to CS domain – procedure at SCC AS	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0023		Removal of editor’s note	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0024		Editor’s note removal	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0025	1	State machine clarifications	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0026	2	Ability to send reduced SIP/Tel URIs	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0027	1	Inclusion of Accept / Reject contact capabilities	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0028		Remove unneeded Editor’s Notes	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0029		Editorial modification	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0030		Session Modification	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0031		Address the I1 dummy message related Editor’s Note	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0032		Supplementary services control procedures	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0033		I1 Mid Call information element	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0034		I1 SIP Error cause handling	9.0.0	9.1.0
2010-03	CT#47	CP-100137	0036		Detection of stale message	9.0.0	9.1.0
2010-06	CT#48	CP-100357	0037	1	Removal editors note on inclusion of calling party identity in setup message	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0038	1	Identification how IE’s are encoded.	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0039	2	Clarification of code specific values in IE’s.	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0041		Removal of Editors notes on URI coding	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0042	2	Ability to support local and national number dialing	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0043		Reference updates	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0044		Removal of unneeded Editor’s Notes	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0045	1	Retransmission timer	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0046	1	Definition of stable I1 session	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0047	1	USSD as transport layer protocol	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0048	1	Optional Timestamp information element	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0049	2	Consistent use of To-id and From-id information elements	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0050		Conference calling service	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0051	1	Communication waiting service	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0052		Use of short message as a transport layer protocol	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0053	1	Removal of undefined information elements from procedures	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0055	1	Service control transfer (Gm fallback to I1) – Service continuity after transferring multiple calls from PS access to CS access using SRVCC	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0056	2	Privacy requested	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0057		Augmentting an existing CS call	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0058		Augmentation correction	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0059	1	Single CS bearer for multiple I1 sessions	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0060		Executing supplementary service	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0061		Invoking mid-call supplementary service	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0062	1	Mid-Call information element	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0063	1	Hold-Resume	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0064	1	I1 message encoding	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0065		Synchronization	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0068		Editorial corrections to introductory clauses	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0069		Editorial corrections to subclause 6.2	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0070		Editorial corrections to subclause 6.3	9.1.0	9.2.0
2010-06	CT#48	CP-100357	0071		Editorial corrections to subclause 6.4	9.1.0	9.2.0
2010-09	CT#49	CP-100503	0072		Conference-id IE	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0073		I1 Refer-to information element	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0074	2	Asserted-ID usage in I1	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0075		I1 session setup	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0076		Corrections to From-id	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0077	2	Corrections of information element lengths	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0078		Removal of duplicate I1 Notify Message	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0079		Corrections to To-id	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0080	1	Mid-Call information element	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0083		Clarification of timer handling	9.2.0	9.3.0
2010-09	CT#49	CP-100503	0084	2	Clarification USSD unreliable transport	9.2.0	9.3.0
2010-12	CT#50	CP-100743	0088		Remote leg release	9.3.0	9.4.0
2011-03	CT#51	CP-110175	0089	1	State machine correlation corrections	9.4.0	9.5.0
2011-03	CT#51	CP-110175	0090		Clarification of Service control	9.4.0	9.5.0
2011-03	CT#51				Upgrade to Rel-10	9.5.0	10.0.0
2011-09	CT#53	CP-110671	0092	2	Failure Message corrections	10.0.0	10.1.0
2011-09	CT#53	CP-110671	0094	2	Missing reason codes	10.0.0	10.1.0
2011-09	CT#53	CP-110671	0100	3	Missing Definition I1 Refer	10.0.0	10.1.0
2011-09	CT#53	CP-110671	0102	1	Conferencing behaviour	10.0.0	10.1.0
2012-09	CT#57				Upgrade to Rel-11	10.1.0	11.0.0
2014-09	CT#65				Upgrade to Rel-12	11.0.0	12.0.0
2015-12	CT#70				Upgrade to Rel-13	12.0.0	13.0.0

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
2017-03	CT-75					Upgrade to Rel-14	14.0.0
2018-06	SA-80	–	–	–		Update to Rel-15 version (MCC)	15.0.0
2020-07	SA-88e	–	–	–		Update to Rel-16 version (MCC)	16.0.0
2022-04	–	–	–	–	–	Update to Rel-17 version (MCC)	17.0.0