7.12 Info package definitions and associated MIME type definitions

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

7.12.1 DTMF info package and session-info MIME type

7.12.1.1 DTMF info package

7.12.1.1.1 General

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

The digit message body and associated MIME type can also be used as defined in other specifications in a legacy manner as defined by RFC 6086 [25].

7.12.1.1.2 Overall description

DTMF tones are normally sent when a user presses a button on the terminal. Each tone, identified by a unique frequency, represents a number (0-9) or a special character. The DTMF info package is used to transport that value. In-order delivery of the DTMF digits is not controlled by the DTMF info package, this would be controlled either by queuing in the sender or by separate interaction with the human user; such mechanisms are out of scope of this registration.

The DTMF info package can be used to transport a single DTMF tone, or a series of tones. If a series of tones is transported in a single SIP INFO request, it is not possible to indicate the duration between each tone in the series.

The DTMF info package is not defined for a specific application. Any application, where sending of DTMF tones using the SIP INFO method is required, can used the DTMF info package.

7.12.1.1.3 Applicability

The info package mechanism for transporting DTMF tones has been chosen because it allows SIP entities that do not have access to the user plane (where DTMF tones can also be transported) to send and receive tones. The mechanism also allows the tones to be sent inside an existing dialog, using the same signalling path as other SIP messages within the dialog, rather than having to establish a separate dialog (DTMF tones can also be transported using subscription event packages).

7.12.1.1.4 Info package name

The name of the DTMF info package is: infoDtmf

7.12.1.1.5 Info package parameters

No parameters are defined for the DTMF info package.

7.12.1.1.6 SIP option tags

No SIP option tags are defined for the DTMF info package.

7.12.1.1.7 INFO message body parts

The DTMF digits are carried in the Overlap digit message body, defined in subclause 7.12.1.2.

The MIME type value for the message body is "application/session-info", defined in subclause 7.12.1.2.

The Content Disposition value for the message body, when associated with the DTMF info package, is "info-package" (see RFC 6086 [25]).

7.12.1.1.8 Info package usage restrictions

No usage restrictions are defined for the DTMF info package.

If SIP entities support multiple mechanisms for sending DTMF tones they need to ensure, using negotiation mechanisms, that each entity is aware of which mechanism is used.

7.12.1.1.9 Rate of INFO requests

No maximum rate or minimum rate is defined for sending INFO requests associated with the DTMF info package.

When DTMF tones are triggered by user interaction, the DTMF tones are normally generated when the user pushes a button. Specific applications can decide upon which rate DTMF tones are generated. However, the DTMF info package does not provide a feedback mechanism to indicate to the sender that the rate of DTMF tones is too slow or fast.

7.12.1.1.10 Info package security considerations

No additional security mechanism is defined for the DTMF info package.

The security of the DTMF info package is based on the generic security mechanism provided for the underlying SIP signalling.

The mechanism should not be used for transferring any data that requires a greater level of security than the underlying SIP signalling.

7.12.1.2 Overlap digit message body

7.12.1.2.1 Scope

This section defines a message body that shall be used for sending additional digits, which have not previously been sent, in SIP INFO messages ("legacy" mode of usage of the INFO method as defined in RFC 6086 [25]) when the in-dialog method is used for overlap dialling.

The same message body can also be used for transporting Dual Tone Multi Frequency (DTMF) tones using SIP INFO requests, using the DTMF info package (see RFC 6086 [25]) defined in subclause 7.12.1.1.

The support of this message body is a network option.

7.12.1.2.2 MIME type

The message body defined in the present annex is registered at IANA as "application/session-info" MIME type.

If the message body is embedded in SIP INFO messages, the Content-Type header shall be set to "application/session-info" and the Content-Disposition header shall be set to "signal" with the handling parameter set to "optional".

7.12.1.2.3 ABNF

session-info = SubsequentDigit

SubsequentDigit = "SubsequentDigit" HCOLON phonedigits

phonedigits = 1*(HEXDIG / "*" / "#")

HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

7.12.1.2.4 IANA registration template

Within the present subclause, information required for an IANA registration at http://www.iana.org/cgi-bin/mediatypes.pl is provided.

1. Media Type Name

Application

2. Subtype name

"session-info" (Standards Tree)

3. Required parameters

none

4. Optional parameters

none

5. Encoding considerations

binary

6. Security considerations

Modifications of the MIME body by a man-in-the-middle can have severe consequences:

The overlap digits that can be transported with this MIME body influence the routeing of the SIP session that is being setup.

Dual Tone Multi Frequency (DTMF) tones that can also be transported with this MIME body will be interpreted by the application of the end points of the communication for various purposes.

However, this MIME body is used only attached to SIP INFO messages, and modifications of other parts of the SIP signalling will lead to comparable consequences. Protection of the SIP signalling will also protect the present MIME body.

The information transported in this MIME media type does not include active or executable content.

Mechanisms for privacy and intregrity protection of protocol parameters exist. Those mechanisms as well as authentication and further security mechanisms are described in 3GPP TS 24.229.

7. Interoperability considerations

none

8. Published specification

3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), stage 3".

9. Applications which use this media type

This MIME type is used as a message body within SIP INFO messages.

It is either used for sending additional digits of the callee´s number, which have not previously been sent, in SIP INFO messages ("legacy" mode of usage of the INFO method as defined in IETF RFC 6086) when the in-dialog method is used for overlap dialling.

The same message body can also be used for transporting Dual Tone Multi Frequency (DTMF) tones using SIP INFO requests, using the DTMF info package (see RFC 6086) defined in subclause 7.12.1.1.

10. Additional information

Magic number(s): none

File extension(s): none

Macintosh File Type Code(s): none

Object Identifier(s) or OID(s): none

11. Intended usage

Limited Use

12. Other Information/General Comment

none.

7.12.1.3 Implementation details and examples

Examples of the DTMF info package usage can be found in the following specification:

– 3GPP TS 24.182 [8Q]: "Customized Alerting Tones; Protocol specification".

7.12.2 g.3gpp.current-location-discovery info package and request-for-current-location body

7.12.2.1 g.3gpp.current-location-discovery info package

7.12.2.1.1 General

This subclause contains information required for registration of the g.3gpp.current-location-discovery info package with IANA.

Editor’s note (WI: SEW2-CT, CR#5707): MCC is asked to register the g.3gpp.current-location-discovery info package with IANA once the CR is incorporated into 3GPP TS 24.229.

7.12.2.1.2 Overall description

Location of a UA participating in an INVITE-initiated dialog can change during duration of the INVITE-initiated dialog.

The g.3gpp.current-location-discovery info package enables a UA participanting in an INVITE-initiated dialog to indicate a request for location information to the other UA participating in the INVITE-initiated dialog.

7.12.2.1.3 Applicability

A number of solutions for the transportation of the pieces of information identified in the overall description were identified and considered:

1) Use of session related methods for transporting event and state information, e.g. re-INVITE request, UPDATE request.

2) Use of OPTIONS request.

3) Use of SIP MESSAGE method.

4) Use of media plane mechanisms.

5) Use of subscription to the presence event package as described in RFC 3856 [74].

6) Use of SIP INFO method as decribed in RFC 6086 [25], by defining a new info package.

Furthermore, each of the solutions was evaluated.

Use of session related methods was discounted since purpose of the INVITE request and the UPDATE request was to modify the dialog, or the parameters of the session or both and neither the dialog nor the parameters of the session needed to be modified.

Use of the OPTIONS request was discounted since purpose of the OPTIONS request was to query UAS for UAS’ capabilites rather than requesting an information available at the UAS.

Use of the MESSAGE request was discounted since the use of the INFO method enabled negotiation of supported event packages in the INVITE transaction while the use of the MESSAGE method did not.

Use of the media plane mechanisms was discounted since the amount of information transferred between the UAs was limited and set up of media stream generated generate extra messages.

Use of the presence event package was discounted since the dialog reuse technique was deprecated accoding to RFC 6665 [28]. Thus, SUBSCRIBE request for the presence event package needed to be sent using a dialog other than any dialog established as result of a INVITE request. However, in some situation – e.g. an emergency session initiated by a UA without a prior registration, there was no way how to ensure delivery of a new initial request for a dialog to the UA. The remote target indicated in Contact header field of:

– the INVITE request; or

– the received response to the INVITE request;

sent by the UA was not necessarily globally routable (e.g. when the UA was behind NAT or when the UA was behind a SIP proxy with a firewall), and the route set indicated in the Record-Route header fields of:

– the INVITE request; or

– the received response to the INVITE request;

sent by the UA might be dedicated to the messages of dialogs established as result of the INVITE request.

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

7.12.2.1.4 Info package name

Info package name is: g.3gpp.current-location-discovery

7.12.2.1.5 Info package parameters

No info package parameters are defined for the g.3gpp.current-location-discovery info package.

7.12.2.1.6 SIP option tags

No SIP option tags are defined for the g.3gpp.current-location-discovery info package.

7.12.2.1.7 INFO message body parts

The MIME type of the body is application/vnd.3gpp.current-location-discovery+xml. The application/vnd.3gpp.current-location-discovery+xml MIME type is defined in 3GPP TS 24.229.

When associated with the g.3gpp.current-location-discovery info package, the Content-Disposition value of the body is "info-package".

7.12.2.1.8 Info package usage restrictions

No usage restrictions are defined for the g.3gpp.current-location-discovery info package.

7.12.2.1.9 Rate of INFO requests

No maximum rate or minimum rate is defined for sending INFO requests associated with the g.3gpp.current-location-discovery info package.

7.12.2.1.10 Info package security considerations

The security of the g.3gpp.current-location-discovery info package is based on the generic security mechanism provided for the underlaying SIP signalling.

As the location information is a sensitive information, unless the location information is requested from a UA who initiated an emergency session, the UA requested to provide the location information needs to authorize the request with the user at the UA.

7.12.2.2 Request-for-current-location body

7.12.2.2.1 General

Editor’s note (WI: SEW2-CT, CR#5707): MCC is asked to register the "application/vnd.3gpp.current-location-discovery+xml" MIME type with IANA once the CR is incorporated into 3GPP TS 24.229.

The request-for-current-location body is of "application/vnd.3gpp.current-location-discovery+xml" MIME type.

The request-for-current-location body is an XML document compliant to the XML schema defined in subclause 7.12.2.2.2, compliant to the additional syntax rules in subclause 7.12.2.2.3, with semantic defined in subclause 7.12.2.2.4.

7.12.2.2.2 XML schema

The XML Schema, is defined in table 7.12.2.2.2.1.

Table 7.12.2.2.2.1: XML schema of application/vnd.3gpp.current-location-discovery+xml MIME type

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:element name="requestForLocationInformation"

type="requestForLocationInformationType"/>

<xs:complexType name="requestForLocationInformationType">

<xs:sequence>

<xs:choice>

<xs:element name="oneShot" type="anyExtType"/>

<xs:element name="anyExt" type="anyExtType"/>

<xs:any namespace="##other" processContents="lax"/>

</xs:choice>

<xs:element name="anyExt" type="anyExtType" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

<xs:complexType name="anyExtType">

<xs:sequence>

<xs:any namespace="##any" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:schema>

7.12.2.2.3 Additional syntax rules

The <requestForLocationInformation> element is the root element.

The <requestForLocationInformation> root element contains:

1) one of the following elements:

a) the <oneShot> element;

b) the <anyExt> element;and

c) an element from another namespace for the purposes of extensibility;

2) zero or one <anyExt> element;and

3) zero or more elements from other namespaces for the purposes of extensibility; and

4) zero or more attributes from any namespaces for the purpose of extensibility.

The <oneShot> element contains:

1) zero or more elements from any namespaces for the purposes of extensibility; and

2) zero or more attributes from any namespaces for the purpose of extensibility.

The <anyExt> element contains:

1) zero or more elements from any namespaces for the purposes of extensibility; and

2) zero or more attributes from any namespaces for the purpose of extensibility.

7.12.2.2.4 Semantic

The <oneShot> child element of the <requestForLocationInformation> root element indicates that the receiving entity is requested to send the location information once.

The <anyExt> element contains elements defined in future version of this specification.

The receiving entity ignores any unknown XML element and any unknown XML attribute.

7.12.2.2.5 IANA registration

Your name:

Your email address:

Media type name:

application

Subtype name:

vnd.3gpp.current-location-discovery+xml

Required parameters:

none.

Optional parameters:

1) "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 [247].

Encoding considerations:

binary.

Security considerations:

same as general security considerations for application/xml media type as specified in section 9.1 of RFC 7303 [247]. In addition, this media type provides a format for exchanging information in SIP, so the security considerations from RFC 3261 [26] apply.

The information transported in this MIME 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 includes provisions for directives that institute actions on a recipient’s files or other resources. The action is providing the location information. The action is providing the location information of the entity receiving the body. Except when sent a part of an emergency session, the entity receiving the body needs to request the user at the entity to authorize the action.

This media type includes 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. The action is providing the location information of the entity receiving the body. Except when sent a part of an emergency session, the entity receiving the body needs to request the user at the entity to authorize the action.

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 [247].

Published specification:

3GPP TS 24.229, (http://www.3gpp.org/ftp/Specs/html-info/24229.htm)

Applications which use this media type:

This MIME type is used for a MIME body within SIP INFO requests.

Fragment identifier considerations:

The handling in section 5 of IETF RFC 7303 [247] 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

1) Name: <MCC>

2) Email: <MCC email>

3) Author/change controller:

i) Author: 3GPP CT1 Working Group/3GPP_TSG_CT_WG1@LIST.ETSI.ORG

ii) Change controller: <MCC name>/<MCC email address>