Content for  TS 24.229  Word version:  18.4.0

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.

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.

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).

The name of the DTMF info package is: infoDtmf

No parameters are defined for the DTMF info package.

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

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).

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.

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.

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.

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) 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. The support of this message body is a network option.

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".

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 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.

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

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.

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.
6. Use of SIP INFO method as decribed in RFC 6086, 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. 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.

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

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

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

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".

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

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

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.

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.

The XML Schema, is defined in Table 7.12.2.2.2.1.

The <requestForLocationInformation> element is the root element. The <requestForLocationInformation> root element contains:

1. one of the following elements:
   1. the <oneShot> element;
   2. the <anyExt> element;and
   3. 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.

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.

Your name: <MCC name> Your email address: Media type name: Subtype name: Required parameters: 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 RFC 7303. Encoding considerations: Security considerations: 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: Published specification: Applications which use this media type: Fragment identifier considerations: Restrictions on usage: Provisional registration? (standards tree only): 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: Person to contact for further information

1. Name: <MCC>
2. Email: <MCC email>
3. Author/change controller:
   1. Author: 3GPP CT1 Working Group/3GPP_TSG_CT_WG1@LIST.ETSI.ORG
   2. Change controller: <MCC name>/<MCC email address>