D.5 XML schema for access transfer events
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
D.5.1 General
This subclause defines XML schema and MIME type for transport of events related to access transfer of a session.
D.5.2 XML schema
<?xml version="1.0"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="events" type="eventsType"/>
<xs:complexType name="eventsType">
<xs:sequence>
<xs:element name="event" type="eventType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="eventType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="event-type" type="xs:unsignedInt"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:element name="STNResp-params" type="STNResp-paramsType"/>
<xs:complexType name="STNResp-paramsType">
<xs:sequence>
<xs:element name="transfer-details" type="xs:base64Binary"/>
<xs:element name="redirect-speech" type="xs:boolean"/>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:schema>
D.5.3 Semantic
D.5.3.1 General
The <events> element is the root element of the XML document and contains one or more <event> elements.
Each <event> element describes one event occuring in session and:
1) contains the "event-type" attribute which indicates the event type; and
2) can contain subelements related to the event type indicated by the "event-type" attribute.
NOTE: The subelements of the <event> are validated by the <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> particle of the <event> element.
The following applies for the "event-type" attribute of the <event> element:
– sender of the XML does not set the "event-type" attribute to any value other than those described in this section; and
– recipient of the XML ignores the <event> element with "event-type" attribute containing a value other than those described in this section.
Recipient of the XML ignores any unknown element and any unknown attribute.
D.5.3.2 Requirements for individual events
If the "event-type" attribute of the <event> element is 1, then the <event> element indicates the session transfer notification request.
If the "event-type" attribute of the <event> element is 2, then the <event> element indicates the session transfer notification response and the <event> element contains the <STNResp-params> element. The <STNResp-params> element contains <transfer-details> element and the <redirect-speech> element. The <transfer-details> element contains the content according to subclause D.5.3.3. The <redirect-speech> element indicates whether the ATCF requires the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer.
NOTE 1: Binary data are encoded according to the XML type base64Binary.
NOTE 2: MIME body with the "event-type" attribute of the <event> element equal to 2 is provided after receiving the MIME body with the "event-type" attribute of the <event> element equal to 1.
If the "event-type" attribute of the <event> element is 3, then the <event> element indicates the session transfer preparation.
NOTE 3: MIME body with the "event-type" attribute of the <event> element equal to 3 is provided after receiving the MIME body with the "event-type" attribute of the <event> element equal to 2.
If the "event-type" attribute of the <event> element is 4, then the <event> element indicates the session transfer cancellation.
NOTE 4: MIME body with the "event-type" attribute of the <event> element equal to 4 is provided either after receiving the MIME body with the "event-type" attribute of the <event> element equal to 2 or after providing the MIME body with the "event-type" attribute of the <event> element equal to 3.
D.5.3.3 ATGW transfer details
The ATGW transfer details indicate the ATGW media configuration to be used by SC UE when sending the speech media of the session transferred by the CS to PS SRVCC access transfer.
The ATGW transfer details are encoded in the structure shown in the figure D.5.3.3-1 and table D.5.3.3-1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Reserved |
Reserved |
Reserved |
Reserved |
Reserved |
Reserved |
ATGW transfer details content type |
octet 1 |
|
ATGW transfer details content |
octet 2 |
Figure D.5.3.3-1: ATGW transfer details structure
Table D.5.3.3-1: ATGW transfer details structure
In this version of specification, the sender sets the Reserved field to zero and the recipient ignores the Reserved field. The ATGW transfer details content type field indicates type of the ATGW transfer details content. Bit 2 of the ATGW transfer details content type field contains the most significant bit. In this version of the specification, the following ATGW transfer details content type values are specified: – 0 (ATGW-IPv4-address-and-port); – 1 (ATGW-IPv6-address-and-port). – 2 (ATGW-not-available). When the ATGW transfer details content type field indicates value other than those specified in this version of the specification, the ATGW Transfer details content field is ignored by the recipient. The sender sets the ATGW transfer details content type field only to a value specified in this version of the specification. When the ATGW transfer details content type field indicates ATGW-IPv4-address-and-port, the ATGW Transfer details content field is structured as in figure D.5.3.3-2 and table D.5.3.3-2. When the ATGW transfer details content type field indicates ATGW-IPv6-address-and-port, the ATGW Transfer details content field is structured as in figure D.5.3.3-3 and table D.5.3.3-3. When the ATGW transfer details content type field indicates ATGW-not-available, the ATGW Transfer details content field is not included. |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
ATGW UDP port |
octet 2 |
|||||||
ATGW IPv4 address |
octet 4 : |
|||||||
Extensions |
octet 8 |
Figure D.5.3.3-2: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv4-address-and-port
Table D.5.3.3-2: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv4-address-and-port
The ATGW UDP port field indicates the ATGW UDP port to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW UDP port field contains the most significant bit and bit 1 of the second octet of the ATGW UDP port field contains the least significant bit. The ATGW IPv4 address field indicates the ATGW IPv4 address to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW IPv4 address field contains the most significant bit and bit 1 of the fourth octet of the ATGW IPv4 address field contains the least significant bit. In this version of specification, the sender does not include the Extensions field and the recipient ignores the Extensions field. See NOTE. |
NOTE: Inclusion of Extensions field enlarges the access stratum handover command, which can result in longer duration of handover procedure and in message being larger than maximum size of the access stratum messages. Thus, inclusion of Extensions field is not recommended. |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
ATGW UDP port |
octet 2 |
|||||||
ATGW IPv6 address |
octet 4 : |
|||||||
Extensions |
octet 20 |
Figure D.5.3.3-3: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv6-address-and-port
Table D.5.3.3-3: ATGW transfer details content structure when the ATGW transfer details content type field indicates ATGW-IPv6-address-and-port
The ATGW UDP port field indicates the ATGW UDP port to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW UDP port field contains the most significant bit and bit 1 of the second octet of the ATGW UDP port field contains the least significant bit. The ATGW IPv6 address field indicates the ATGW IPv6 address to be used by SC UE to send the speech media of the session transferred by the CS to PS SRVCC access transfer. Bit 8 of the first octet of the ATGW IPv6 address field contains the most significant bit and bit 1 of the sixteenth octet of the ATGW IPv6 address field contains the least significant bit. In this version of specification, the sender does not include the Extensions field and the recipient ignores the Extensions field. See NOTE. |
NOTE: Inclusion of Extensions field enlarges the access stratum handover command, which can result in longer duration of handover procedure and in message being larger than maximum size of the access stratum messages. Thus, inclusion of Extensions field is not recommended. |
D.5.4 IANA registration template
Your Name:
<MCC name>
Your Email Address:
<MCC email address>
Media Type Name:
Application
Subtype name:
vnd.3gpp.access-transfer-events+xml
Required parameters:
None
Optional parameters:
"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in section 9.1 of IETF RFC 7303.
"et" when the MIME type is included in the Accept header field, the "et" parameter value is a comma delimited list of the values of the "event-type" attribute of the <event> element of the <events> root element which the sender of the Accept header field is able to receive. The <events> root element is defined by XML schema described in the Published specification.
Encoding considerations:
binary.
Security considerations:
Same as general security considerations for application/xml media type as specified in section 9.1 of IETF RFC 7303. In addition, this media type provides a format for exchanging information in SIP, so the security considerations from IETF RFC 3261apply.
The information transported in this media type does not include active or executable content.
Mechanisms for privacy and integrity protection of protocol parameters exist. Those mechanisms as well as authentication and further security mechanisms are described in 3GPP TS 24.229.
This media type does not include provisions for directives that institute actions on a recipient’s files or other resources.
This media type does not include provisions for directives that institute actions that, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient’s privacy in any way.
This media type does not employ compression.
Interoperability considerations:
Same as general interoperability considerations for application/xml media type as specified in section 9.1 of IETF RFC 7303. Any unknown XML elements and any unknown XML attributes are to be ignored by recipient of the MIME body.
Published specification:
3GPP TS 24.237 "IP Multimedia Subsystem (IMS) Service Continuity", version 13.1.0, available via http://www.3gpp.org/specs/numbering.htm.
Applications which use this media type:
Applications supporting the service continuity as described in the published specification.
Fragment identifier considerations:
The handling in section 5 of IETF RFC 7303 applies.
Restrictions on usage:
None
Provisional registration? (standards tree only):
N/A
Additional information:
1. Deprecated alias names for this type: none
2. Magic number(s): none
3. File extension(s): none
4. Macintosh File Type Code(s): none
5. Object Identifier(s) or OID(s): none
Intended usage:
Common
Person to contact for further information:
– Name: <MCC name>
– Email: <MCC email address>
– Author/Change controller:
i) Author: 3GPP CT1 Working Group/3GPP_TSG_CT_WG1@LIST.ETSI.ORG
ii) Change controller: <MCC name>/<MCC email address>