Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

7.9A  Feature-capability indicators defined within the current document |R11|Word‑p. 466

7.9A.1  General

This subclause describes the feature-capability indicators definitions, according to RFC 6809, that are applicable for the 3GPP IM CN subsystem.

7.9A.2  Definition of feature-capability indicator g.3gpp.icsi-ref

Feature-capability indicator name:
g.3gpp.icsi-ref.
Summary of the feature indicated by this feature-capability indicator:
Each value of the Service Reference feature-capability indicator indicates the software applications supported by the entity. The values for this feature-capability indicator equal the IMS communication Service Identifier (ICSI) values supported by the entity.
Multiple feature-capability indicator values can be included in the Service Reference feature-capability indicators.
When included in the Feature-Caps header field, according to RFC 6809, the value of this feature-capability indicator contains the IMS communication service identifier (ICSI) of the IMS communication service supported for use:
  • in the standalone transaction (if included in a request for a standalone transaction or a response associated with it); or
  • in the dialog (if included in an initial request for dialog or a response associated with it);
by the entity which included the Feature-Caps header field.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
When used in a Feature-Caps header field, the g.3gpp-icsi-ref feature-capability indicator is encoded using the feature-cap header field rules specified in clause 6.3 of RFC 6809, where the feature-capability indicator value is an instance of fcap-value-list, listing one or more token values, as specified in RFC 6809.
Examples of typical use:
Indicating support of IMS Communication Services to other network entities.
Security Considerations
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.3  Definition of feature-capability indicators g.3gpp.trf

Feature-capability indicator name:
g.3gpp.trf
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator, when included in a Feature-Caps header field as specified in RFC 6809 in a SIP INVITE request, indicates that in a roaming scenario, the visited network supports a transit and roaming functionality in order to allow loopback of session requests to the visited network from the home network. When used, it may indicate the URI of the transit and roaming functionality.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
None or string with an equality relationship. When used in a Feature-Caps header field, the value is string and follows the syntax as described in table 7.9A.1 for g-3gpp-trf. The value of g-3gpp-trf parameter is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate visited network support of the roaming architecture for voice over IMS with local breakout and to transport the TRF address.
Examples of typical use:
A visited network indicating the presence and support of a TRF in a visited network to the home network.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.4  Definition of feature-capability indicator g.3gpp.loopbackWord‑p. 467
Feature-capability indicator name:
g.3gpp.loopback
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator, when included in a Feature-Caps header field as specified in RFC 6809 in a SIP INVITE request, indicates the support of the roaming architecture for voice over IMS with local breakout.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
None or a string with an equality relationship.
When used in a Feature-Caps header field, the value is a string identifying the home network and follows the syntax as described in table 7.9A.4-1 for g-3gpp-loopback. The value of g-3gpp-loopback parameter is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate support of the roaming architecture for voice over IMS with local breakout and that the INVITE request is a loopback request.
Examples of typical use:
The home network indicating when a loopback INVITE request is sent to a visited network.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.5  Definition of feature-capability indicator g.3gpp.home-visited

Feature-capability indicator name:
g.3gpp.home-visited
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator, when included in a Feature-Caps header field as specified in RFC 6809 in a SIP INVITE request, indicates that the home network supports loopback to the identified visited network for this session. The loopback is expected to be applied at some subsequent entity to the insertion point. The feature-capability indicator carries a parameter value which indicates the visited network.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
String with an equality relationship. When used in a Feature-Caps header field, the value follows the syntax as described in table 7.9A.2 for g-3gpp-home-visited. The value of g-3gpp-home-visited parameter is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809.
The value follows that used in the P-Visited-Network-ID header field.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate the home network supports loopback to the identified visited network for this session. The loopback is expected to be applied at some subsequent entity to the insertion point. The feature-capability indicator carries a parameter which indicates the visited network.
Examples of typical use:
A home network indicating the home network supports loopback to the identified visited network for this session.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.6  Definition of feature-capability indicator g.3gpp.mrbWord‑p. 468
Feature-capability indicator name:
g.3gpp.mrb
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator when included in a Feature-Caps header field as specified in RFC 6809 in a SIP INVITE request indicates that in a roaming scenario, the visited network supports media resource broker functionality for the allocation of multimedia resources in the visited network. When used, it indicates the URI of the visited network MRB.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
String with an equality relationship. When used in a Feature-Caps header field, the value is string and follows the syntax as described in table 7.9A.3 for g-3gpp-mrb. The value of g-3gpp-mrb parameter is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate the URI of the media resource broker.
Examples of typical use:
Indicating the URI of the visited network MRB to the home network.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of draft-ietf-sipcore-proxy-feature [190].
Up

7.9A.7Void

7.9A.8  Definition of feature-capability indicator g.3gpp.registration-token |R12|Word‑p. 469
Feature-capability indicator name:
g.3gpp. registration-token
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator, when included in a Feature-Caps header field as specified in RFC 6809, indicates the support of using a token to identify the registration used for the request.
This feature-capability indicator can be included in an originating initial request for a dialog or a request for a standalone transaction to identify which registration was used for this request by setting the indicator to the same value as in the g.3gpp.registration-token media feature tag in the Contact header field of the REGISTER request.
This feature-capability indicator can be included in 1xx or 2xx response to a terminating initial request for a dialog or a 2xx response to a request for a standalone transaction to identify which registration was used for the response by setting the indicator to the same value as in the g.3gpp.registration-token media feature tag in the Contact header field of the REGISTER request.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
String with an equality relationship.
When used in a Feature-Caps header field, the value is a string identifying the used registration and follows the syntax as described in table 7.9A.8-1 for g-3gpp-registration-token. The value of g-3gpp-registration-token parameter is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate support of using a token to identify the registration used for the current request or response.
Examples of typical use:
The S-CSCF includes a media feature tag in a third-party REGISTER request to indicate support of this feature. The value is a unique value identifying this registration among the set of registrations for the registered URI. The S-CSCF includes this token with an identical value as in the previous REGISTER request in subsequent initial requests and responses to indicate its continuous support. An AS supporting this feature can use the value of the token to identify the used registration.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.9  Definition of feature-capability indicator g.3gpp.thig-path |R13|

Feature-capability indicator name:
g.3gpp.thig-path
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator when included in a Feature-Caps header field as specified in RFC 6809 in a 200 (OK) response to the REGISTER request indicates that in a roaming scenario, the visited network IBCF supports topology hiding of a Path header field.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
String with an equality relationship. When used in a Feature-Caps header field, the value is string and follows the syntax as described in table 7.9A.y for g-3gpp-thig-path. The value of g-3gpp-thig-path parameter is an instance of fcap-string-value of Feature-Caps header field specified in RFC 6809.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate that the visited network IBCF supports topology hiding of a Path header field and to pass to the P-CSCF a SIP URI of the visited network IBCF which applied topology hiding on the Path header field.
Examples of typical use:
The visited network IBCF includes the g.3gpp.thig-path feature-capability indicator in a 200 (OK) response to the REGISTER request to pass to the P-CSCF a SIP URI of the visited network IBCF which applied topology hiding on the Path header field contained in the REGISTER request.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.10  Definition of feature-capability indicator g.3gpp.priority-share |R13|Word‑p. 470
Feature-capability indicator name:
g.3gpp.priority-share.
Summary of the feature indicated by this feature-capability indicator: When included in a Feature-Caps header field in SIP requests or SIP responses the sender indicates that priority sharing is supported.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
When used in a Feature-Caps header field, the g.3gpp.priority-share feature-capability indicator is encoded using the feature-cap header field rules specified in subclause 6.3 of RFC 6809, where the feature-capability indicator value is an instance of fcap-value-list, listing one or more token values, as specified in RFC 6809.
Examples of typical use:
Indicating support of priority sharing to other network entities.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.11  Definition of feature-capability indicator g.3gpp.verstat |R14|

Feature-capability indicator name:
g.3gpp.verstat
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator, when included in a Feature-Caps header field as specified in RFC 6809 in a 200 (OK) response to a REGISTER request, indicates that the home network supports calling party number verification, as described in RFC 8224.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
Not applicable.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate the support of calling party number verification functionality.
Examples of typical use:
Indicating the support of calling number verification in the home network.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.9A.12  Definition of feature-capability indicator g.3gpp.anbr |R16|Word‑p. 471
Feature-capability indicator name:
g.3gpp.anbr
Summary of the feature indicated by this feature-capability indicator:
This feature-capability indicator, when included in a Feature-Caps header field as specified in RFC 6809 in a 200 (OK) response to a REGISTER request, indicates that the network supports ANBR as specified in TS 26.114.
Feature-capability indicator specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this feature-capability indicator:
Not applicable.
The feature-capability indicator is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-capability indicator is used to indicate the support of ANBR.
Examples of typical use:
Indicating the support of ANBR.
Security Considerations:
Security considerations for this feature-capability indicator are discussed in clause 9 of RFC 6809.
Up

7.10  Reg-event package extensions defined within the current document |R8|

7.10.1  General

This subclause describes the reg-event package extensions that are applicable for the IM CN subsystem.

7.10.2  Reg-Event package extension to transport wildcarded public user identities

7.10.2.1  Structure and data semantics

This subclause defines an extension to the event registration package (RFC 3680) to transport policy to transport wildcarded public user identities that are encoded using regular expression.
In order to include a wildcared public user identity in the event registration package, the notifier shall
  1. if the registration set of the identity whose registration status is notified contains a wildcarded public user identity, add a <wildcardedIdentity> sub-element defined in subclause 7.10.2.2 of this document to the <registration> element of the wildcarded identiy;
  2. for the <registration> element containing a <wildcardedIdentity> sub-element:
    1. set the aor attribute to any public user identity that is represented by the wildcarded identity; and
    2. set the <wildcardedIdentity> sub-element inside of the <registration> element to the wildcarded identity as received via the Cx interface.
Up

7.10.2.2  XML SchemaWord‑p. 472
Table 7.10.1 in this subclause defines the XML Schema describing the extension to transport wildcarded public user identities which can be included in the reg event package sent from the S-CSCF in NOTIFY requests.
Up

7.10.3  Reg-event package extension for policy transport |R10|

7.10.3.1  Scope

This subclause describes coding which extends the registration event package defined in RFC 3680 to transport policy associated with a public user identity.

7.10.3.2  Structure and data semantics

The policy associated with a public user identity shall be encoded as follows:
  1. add an <actions> element defined in the RFC 4745 in the <registration> element of the public user identity in the registration information;
  2. if the policy to the usage of the communication resource priority (see RFC 4412) is associated with the public user identity, then for each allowed usage:
    1. include <rph> child element in the <actions> child element of the <registration> element;
    2. set the 'ns' attribute of the <rph> child element of the <actions> child element of the <registration> element to the allowed resource priority namespace as specified in RFC 4412 and as registered in IANA; and
    3. set the 'val' attribute of the <rph> child element of the <actions> child element of the <registration> element to the allowed resource priority value within the allowed resource priority namespace;
  3. if the policy to act as privileged sender (the P-CSCF passes identities for all calls) is associated with the public user identity, then include a <privSender> child element in the <actions> child element of the <registration> element;
  4. if the policy for special treatment of the P-Private-Network-Indication header field (the P-CSCF allows the UE to make private calls) is associated with the public user identity, then include a <pni> child element in the <actions> child element of the <registration> element, and shall:
    1. if a P-Private-Network-Indication header field shall be forwarded, if received from the attached equipment, set the "insert" attribute of the <pni> element to a "fwd" value;
    2. if a P-Private-Network-Indication header field shall be inserted in all requests received from the attached equipment, insert an "insert" attribute of the <pni> element to a "ins" value; and
    3. if the value of the "insert" attribute is "ins", insert a "domain" attribute with the value of the URI to be set in the P-Private-Network-Indication header field; and
  5. if the policy to act as privileged sender for the calls with the P-Private-Network-Indication header field (the P-CSCF allows the UE to make private calls, and the P-CSCF passes identities only for private calls) is associated with the public user identity, then include a <privSenderPNI> child element in the <actions> child element of the <registration> element.
Up

7.10.3.3  XML SchemaWord‑p. 473
Table 7.10.2 in this subclause defines the XML Schema describing the individual policies which can be delivered to the P-CSCF or UE using the reg event package extension for policy transport.
Up

7.11  URNs defined within the present document |R12|

7.11.1  Country specific emergency service URN

7.11.1.1  Introduction

The country specific emergency service URN is intended to uniquely identify a type of emergency service for which an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031, registered by IANA is not available.
The country specific emergency service URN is intended to be used only when an emergency service URN for a given type of emergency service, with approximately the same caller expectation in terms of services rendered, is not registered by IANA.
The country specific emergency service URN is intended to be used only inside the country where the national regulatory authority defines emergency services only by national numbers. The country specific emergency service URN is not intended to be used by the UE except when indicated by the network.
Up

7.11.1.2  SyntaxWord‑p. 474
The country specific emergency service URN is a service URN with:
  1. the top-level service type of "sos" as specified in RFC 5031;
  2. the first sub-service of "country-specific";
  3. the second sub-service indicating the country where the type of emergency service is deployed. The format of second sub-service is an ISO 3166-1 alpha-2 code as specified in ISO 3166-1 [207]; and
  4. the third sub-service uniquely identifying the type of emergency service in the country where the type of emergency service is deployed. The third sub-service is defined by the national regulation of the country where the type of emergency service is deployed. The set of allowable characters for the third sub-service is the same as that for domain names (see RFC 5031) and the number of characters for the third sub-service shall be less than 64.
EXAMPLE:
urn:service:sos.country-specific.xy.567 can identify a type of emergency service identified by an emergency number 567 in a country identified by "xy" ISO 3166-1 alpha-2 code as specified in ISO 3166-1 [207].
Up

7.11.1.3  Operation

Unless explicitly prohibited, wherever an emergency service URN i.e. a service URN with the top-level service type of "sos" as specified in RFC 5031 can be used, the country specific emergency service URN can also be used.

7.11.1.4Void

7.11.2  ICSI value for RLOS |R16|

7.11.2.1  Introduction

This subclause describes the IMS communications service identifier definitions that is applicable for the usage of restricted local operator service (RLOS).

7.11.2.2  URN

urn:urn-7:3gpp-service.ims.icsi.rlos

7.11.2.3  Description

This URN indicates that the device has the capabilities to support the restricted local operator service (RLOS).

7.11.2.4  Reference

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

7.11.2.5  ContactWord‑p. 475
Name:
<MCC name>
Email:
<MCC email address>

7.11.2.6  Registration of subtype

Yes

7.11.2.7  Remarks

None

7.12  Info package definitions and associated MIME type definitions |R8|

7.12.1  DTMF info package and session-info MIME type

7.12.1.1  DTMF info package

7.12.1.1.1  General |R9|
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.
7.12.1.1.2  Overall description |R9|
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.
Up
7.12.1.1.3  Applicability |R9|
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 |R9|
The name of the DTMF info package is: infoDtmf
7.12.1.1.5  Info package parameters |R9|
No parameters are defined for the DTMF info package.
7.12.1.1.6  SIP option tags |R9|Word‑p. 476
No SIP option tags are defined for the DTMF info package.
7.12.1.1.7  INFO message body parts |R9|
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).
Up
7.12.1.1.8  Info package usage restrictions |R9|
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 |R9|
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 |R9|
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) 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.
Up
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
7.12.1.2.4  IANA registration templateWord‑p. 477
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.
Up

7.12.1.3  Implementation details and examples |R9|Word‑p. 478
Examples of the DTMF info package usage can be found in the following specification:
  • 3GPP TS 24.182: "Customized Alerting Tones; Protocol specification".

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

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.
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.
  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 [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.
Up
7.12.2.1.4  Info package nameWord‑p. 479
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 requestsWord‑p. 480
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
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.
Up
7.12.2.2.2  XML schema
The XML Schema, is defined in table 7.12.2.2.2.1.
Up
7.12.2.2.3  Additional syntax rulesWord‑p. 481
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.
Up
7.12.2.2.4  SemanticWord‑p. 482
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:
<MCC name>
Your email address:
<MCC email>
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 RFC 7303.
Encoding considerations:
binary.
Security considerations:
same as general security considerations for application/xml media type as specified in RFC 7303. In addition, this media type provides a format for exchanging information in SIP, so the security considerations from RFC 3261 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 RFC 7303.
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 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
  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>
Up

7.13  JSON Web Token claims defined within the present document |R12|Word‑p. 483

7.13.1  General

This subclause contains definitions for JSON Web Token claims RFC 7519 usage in the 3GPP IM CN subsystem.

7.13.2  3GPP-WAFWord‑p. 484
The 3gpp-waf claim is used to transport the identity of the WAF.
Claim name:
3gpp-waf
Claim value:
String
Claim description:
WAF identity

7.13.3  3GPP-WWSF

The 3gpp-wwsf claim is used to transport the identity of the WAF.
Claim name:
3gpp-wwsf
Claim value:
String
Claim description:
WWSF identity

7.13.4  identityHeader |R15|

The identityHeader claim is used to transport a SIP Identity header field.
Claim name:
identityHeader
Claim value:
String
Claim description:
Contents of an Identity header field

7.13.5  verstatValue |R15|

The verstatValue claim is used to transport the value of a verstat tel URI parameter.
Claim name:
verstatValue
Claim value:
String
Claim description:
The value of a verstat tel URI parameter.

7.13.6  identityHeaders |R15|

The identityHeaders claim is used to transport one or more SIP Identity header field(s).
Claim name:
identityHeaders
Claim value:
Array of strings
Claim description:
Array of Identity header fields needed to verify diverting users.

7.13.7  divResult |R15|

The divResult claim is used to transport the result for the verified div claims and related identities.
Claim name:
divResult
Claim value:
Array of one or more [div, verstatValue] tuples
Claim description:
The value of a verstat tel URI parameter.


Up   Top   ToC