7  Extensions within the present document  Word‑p. 397

7.1  SIP methods defined within the present document

There are no SIP methods defined within the present document over and above those defined in the referenced IETF specifications.

7.2  SIP header fields defined within the present document

7.2.0  General

This subclause defines additional header fields.

7.2.1  Void

7.2.2  Void

7.2.3  Void

7.2.4  Void

7.2.5  Void

7.2.6  Void

7.2.7  Void

7.2.8  Void

7.2.9  Void

7.2.10  Void

7.2.11  Definition of Restoration-Info header field |R12|

7.2.11.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Restoration-Info

Usage:

The Restoration-Info header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

In case of a node failure there are cases where an upstream node can use information about a node failure. The upstream node can use this information for error reporting, or possibly for error recovery.

An upstream node can inform a downstream node about supported error recovery mechanisms. The downstream node can use this information for error recovery.

7.2.11.2  Applicability statement for the Restoration-Info header field  Word‑p. 398

The Restoration-Info header field is applicable within a single private administrative domain or between different administrative domains.

The Restoration-Info header field is applicable when:

1. a node has failed and the SIP node detecting this failure needs to inform a proxy in the administrative domain of the terminating user about the failure; or
2. a proxy located in the private administrative domain of a user wants to send information about the subscriber to a downstream proxy for error recovery.

For case 1) the SIP node detecting the failure can include the Restoration-Info header field set to the value "noresponse" in a 408 (Request Timeout) response to an INVITE request or a 504 (Server Time-out) response to a dialog forming request or standalone transaction,

For case 2) the Restoration-Info header field is included in an initial INVITE request with an "IMSI" header field parameter set to a value identifying the user.

7.2.11.3  Usage of the Restoration-Info header field

A SIP entity that does not receive a response from the next SIP node, may include a Restoration-Info header field in the error response to inform upstream nodes or networks about the downstream node failure. The upstream nodes or networks may use this information to either inform the originating user, to report the failure or to initiate restoration.

A SIP entity in the home network domain may use the Restoration-Info header field to transport an IMSI value to downstream SIP entities. The downstream SIP entity can use this information to initiate restoration for this user.

7.2.11.4  Procedures at the UA

There are no specific procedures specified for a UA. A UAC in a B2BUA may use the information in the Restoration-Info header field for error reporting, or take this information into account when deciding on re-attempting the request. A UAS may include a Retoration-Info header field in an error respons to inform upstream nodes or networks about the downstream node failure.

7.2.11.5  Procedures at the proxy

A SIP proxy that supports this extension and receives a request may insert a Restoration-Info header field prior to forwarding the request. The header field is populated with the IMSI value received in the body of a DIAMETER request as per TS 29.228 within the quoted string .

A SIP proxy that supports this extension and receives a request with the Restoration-Info header field, may retrieve the IMSI value from the header field and use it to poulate a DIAMETER request as per TS 29.214 for the purposes of performing PCRF restoration procedures.

A SIP proxy that supports this extension and receives a 408 response with this header field present can use this information for restoration procedures or reporting.

7.2.11.6  Security considerations

The Restoration-Info header field can contain sensitive information. When the Restoration-Info header field contains the IMSI value, it shall be sent only to trusted entities.

A UE is not expected to receive this information.

7.2.11.7  Syntax

The syntax for Restoration-Info header field is specified in table 7.2.11-1.

Table 7.2.11-1: Syntax of Restoration-Info

7.2.11.8  Examples of usage  Word‑p. 399

The Restoration-Info header field can be inserted by the neighbouring upstream SIP node to the SIP node that does not respond. The header field value "noresponse" can be used to inform the upstream SIP entity about the failure. The upstream SIP entity such as a 3GPP S-CSCF can use this information to initiate restoration procedures. The restoration can be in the form of a lower layer message to the terminating UE to indicate that the UE needs to perform a new SIP registration.

The Restoration-Info header field can be used to transport the IMSI value from the S-CSCF to a P-CSCF. The S-CSCF obtains the IMSI value as a string over the 3GPP Cx interface specified in TS 29.228. The downstream node can include the IMSI string received in a diameter request specified in TS 29.214. The receiver of this diameter request uses the information to find the UE and indicate that the UE needs to perform a new SIP registration.

The indication to the UE that it needs to perform a new SIP registration is sent over a lower layer.

7.2.12  Relayed-Charge header field |R12|

7.2.12.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Relayed-Charge

Usage:

The Relayed-Charge header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

The P-Charging-Vector header field is used to carry information relating to charging as it accumulates to various entities within the IM CN subsystem. The information within that header field is applicable to the current dialog or transaction at the point where it is received. Sometimes it is appropriate to carry this accumulated charging information, relating to the same dialog or transaction to other entities within the IM CN subsystem. The Relayed-Charge header field is defined to relay the current contents of the P-Charging-Vector header field as known by one entity to another entity with an indication of the Source entity.

7.2.12.2  Applicability statement for the Relayed-Charge header field

The Relayed-Charge header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.

The Relayed-Charge header field is not included in a SIP message sent to another network if there is no trust relationship.

The Relayed-Charge header field is applicable whenever the P-Charging-Vector header field would be applicable, as defined by RFC 7315.

7.2.12.3  Usage of the Relayed-Charge header field

A SIP entity that receives a P-Charging-Vector header field may take appropriate fields from the received header field and encode them in the equivalent field within the Relayed-Charge header field, along with a value in the relay-source to indicate the relaying SIP entity.

A SIP UA or SIP proxy that receives a SIP request or response that contains a Relayed-Charge header field can use the values, to produce charging records.

A SIP proxy may remove the Relayed-Charge header field if it is known there is no intended collector of the Relayed-Charge header field subsequent in the path of the request or response.

7.2.12.4  Procedures at the UA  Word‑p. 400

This document does not specify any procedure at a UA located outside the administrative domain of a private network (e.g., PSTN gateway or conference mixer), with regard to the Relayed-Charge header field. UAs need not understand this header field.

However, it might be possible that a UA be located within the administrative domain of a private network (e.g., a PSTN gateway, or conference mixer), and it may interact with the charging entities.

In this case, a UA may insert the Relayed-Charge header field in a SIP request or response when the next hop for the message is a proxy or UA located in the same administrative domain. Similarly, such a UA may use the contents of the Relayed-Charge header field in communicating with the charging entities.

7.2.12.5  Procedures at the proxy

A SIP proxy that supports this extension and receives a request or response without the Relayed-Charge header field MAY insert a Relayed-Charge header field prior to forwarding the message. The header is populated with one or more parameters, as described in the syntax, including but not limited to, a globally unique charging identifier.

If a proxy that supports this extension receives a request or response with the Relayed-Charge header field, it may retrieve the information from the header value to use with application-specific logic, i.e., charging. If the next hop for the message is within the trusted domain, then the proxy should include the Relayed-Charge header field in the outbound message. If the next hop for the message is outside the trusted domain, then the proxy may remove the Relayed-Charge header field.

Per local application-specific logic, the proxy may modify the contents of the Relayed-Charge header field prior to sending the message.

7.2.12.6  Security considerations

It is expected as normal behavior that proxies within a closed network will modify the values of the Relayed-Charge header field and insert it into a SIP request or response. However, these proxies that share this information shall have a trust relationship.

If an untrusted entity were inserted between trusted entities, it could potentially interfere with the charging correlation mechanism. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms shall be applied in order to prevent such attacks. Since each trusted proxy may need to view or modify the values in the Relayed-Charge header field, the protection should be applied on a hop-by-hop basis.

7.2.12.7  Syntax

The syntax for Relayed-Charge header field is specified in table 7.2.12.1

Table 7.2.12.1: Syntax of Relayed-Charge

charge-params are as defined for the P-Charging-Vector header field

7.2.12.8  Examples of usage

The Relayed-Charge header field is used in situations where there is a need to carry charging information applicable to a dialog or transaction which is not directly pertinent to the next hop. So for example, at the S-CSCF the accumulation of the "transit-ioi" header field parameter for an incoming call is removed and a new accumulation of "transit-ioi" header field parameters started. The received transit-ioi header field parameter accumulation can be passed to the online charging server (acting as an AS in the IM CN subsystem) using the Relayed-Charge header field.

7.2.13  Resource-Share header field |R13|  Word‑p. 401

7.2.13.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Resource-Share

Usage:

The Resource-Share header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

The P-CSCF in the 3GPP architecture is responsible for reserving resources in the media plane. The resources reservation procedure includes the possibility to allow resources to be shared between sessions involving the same UE. The possibility to share resources can be dependent on services controlled by application servers.

Since the P-CSCF is service unaware the P-CSCF can benefit from receiving information from application servers regarding potential resource sharing options.

7.2.13.2  Applicability statement for the Resource-Share header field

The Resource-Share header field is applicable within a single private administrative domain or between different administrative domains.

7.2.13.3  Usage of the Resource-Share header field

The P-CSCF can include the Resource-Share header field in the REGISTER request to indicate the support of receiving resource sharing information from application servers in the user's home network or in an subsequent request or response within an existing dialog created by an INVITE request to indicate that resource sharing no longer is possible.

An application server in a user's home network acting as a SIP proxy or a UA may use a Resource-Share header field to transport resource sharing information in any request or response destined for the served user.

The P-CSCF receiving a request or response destined for a served UE containing a Resource-Share header field can use the resource sharing information when reserving resources in the media plane.

7.2.13.4  Procedures at the UA

An application server acting as a UA that supports this extension and receives a request or response destined for the served user containing an SDP offer or answer may insert a Resource-Share header field prior to forwarding the request or response. The value of the header field set to "media-sharing" or "no-media-sharing". When set to "media-sharing" the header field shall further be populated with the "rules" and "timestamp" header field parameters.

7.2.13.5  Procedures at the proxy

When a P-CSCF supporting this extension receives a REGISTER request from a served UE, the P-CSCF may insert a Resource-Share header field prior to forwarding the REGISTER request. The value of the header field is then set to "supported".

When the P-CSCF receives an SDP offer or answer from the served UE in a subsequent request or response within an existing dialog and if the SDP offer or answer contains information conflicting with the applied resource sharing, the P-CSCF may include the Resource-Share header field set to "no-media-sharing" in the request or response sent towards the application server.

When an application server acting as a SIP proxy supporting this extension receives a request or response destined for the served user containing an SDP offer or answer, the SIP proxy may insert a Resource-Share header field prior to forwarding the request or response. The value of the header field set to "media-sharing" or "no-media-sharing". When set to "media-sharing" the header field shall further be populated with the "rules" and "timestamp" header field parameters.

When the P-CSCF supporting this extension receives a request or response destined for the served UE containing the Resource-Share header field with the value "media-sharing", the P-CSCF may extract resource sharing rules from the "rules" header field parameter and use the extracted resource sharing rules to populate a DIAMETER request as per TS 29.214 for the purposes of performing resource sharing procedures.

7.2.13.6  Security considerations  Word‑p. 402

The Resource-Share header field does not contain any information that can disclose user information or the topology of nodes within an operator network.

7.2.13.7  Syntax

The syntax for Resource-Share header field is specified in table 7.2.13.1

Table 7.2.13.1: Syntax of Resource-Share

7.2.13.8  Operation

7.2.13.8.1  General

The values in the "resource-share" header field field are defined as follows:

"supported"

indicates that the sender would like to receive information about resource sharing options for sessions involving the UE identified by the "+sip.instance" header field parameter in the Contact header field.

"media-sharing"

indicates that an application server has determined that one or more media streams in the session can be subject for resource sharing.

"no-media-sharing"

indicates that an application server or the P-CSCF has determined that none of the media streams in the session are subjects for resource sharing.

The Resource-Share header field contains the "origin", "rules" and "timestamp" header field parameters.

7.2.13.8.2  The "origin" header field parameter

The "origin" header field parameter is used to identify the source of the resource sharing information. The values in the "origin" header field field are defined as follows:

"session-initiator"

indicates that the application server or the P-CSCF that included the Resource-Share header field is serving the UE sending the initial INVITE request.

"session-receiver"

indicates that the application server or the P-CSCF that included the Resource-Share header field is serving the UE receiving the initial INVITE request.

7.2.13.8.3  The "rules" header field parameter  Word‑p. 403

The "rules" header field parameter carries one or more rules for resource sharing. Each rule is included in the same order as the corresponding m-line in the SDP offer/answer and consists of the following parts:

"new-sharing-key"

this part is mandatory and identifies a media stream in an exisiting ongoing session or is a new sharing key value when the UE is not already involved in a session subject for resource sharing. The same value of the "new-sharing-key" can only appear in one media stream.

"existing-sharing-key-list"

this part is optional and is only included in the INVITE request when the request is forked and if there are UEs (registered via a P-CSCF indicating that receiving resource sharing option information would be useful) already involved in sessions where the media-stream can be shared. Each value in the "existing-sharing-list" identifies a media stream in the ongoing session. In the forking case the "new-sharing-key" includes a new sharing key value to be used by UEs not involved in a session yet. The same value of a sharing key in the "existing-sharing-key-list" can only appear in one media stream.

"directionality"

this part indicates in which direction resource sharing applies. "UL" indicates that resource sharing can be applied in the direction from the UE. "DL" indicates that resource sharing can be applied in the direction towards the UE. "UL-DL" indicates that resource sharing can be applied in both directions.

7.2.13.8.4  The "timestamp" header field parameter

The "timestamp" header field parameter indicates when the application server determined the resource sharing rules and is used to determine the most applicable resource sharing option.

The value is a counter unique for each user and is increased and inserted in the header field each time the application server includes a Resource-Share header field in a request or response involving a UE registered by the user.

When the P-CSCF receives a Resorce-Share header field, the P-CSCF extracts and stores the extracted resource sharing rule along with the value of the received "timestamp" header field as follows:

1. if a resource sharing rule identified by the sharing key is not already stored, store the extracted resource sharing rule along with the value of the received "timestamp" header field;
2. if a resource sharing rule identified by the sharing key is already stored with a lower timestamp value than the value of the received "timestamp" header field, replace the stored resource sharing rule with the extracted resource sharing rule along with the value of the received "timestamp" header field; or
3. if a resource sharing rule identified by the sharing key is stored with a higher timestamp value than the value of the received "timestamp" header field, discard the extracted resource sharing rule.

The "timestamp" header field can be reset to "0" when none of the UEs registered by the user is involved in a session any longer.

7.2.13.9  Examples of usage

7.2.13.9.1  Example overview

The following subclauses describe examples on how:

• the P-CSCF indicates in the REGISTER request that P-CSCF supports receiving information about resource sharing;
• the application server sends information about potential resource sharing to the P-CSCF; and
• the P-CSCF extracts resource sharing information for media-streams.

7.2.13.9.2  The P-CSCF indicates in the REGISTER request that P-CSCF supports receiving information about resource sharing  Word‑p. 404

When P-CSCF receives a REGISTER request from a UE served by the P-CSCF, the P-CSCF can include a Resource-Share header field indicating that the P-CSCF supports receiving information about resource sharing.

The example 1 shows the coding when the P-CSCF indicates that the P-CSCF is interested in receiving information about resource sharing in a REGISTER request.

EXAMPLE 1:

Resouce-Share: supported

7.2.13.9.3  The application server sends information about potential resource sharing to the P-CSCF

When the application server receives a request or response containing an initial SDP offer/answer with media streams subject for resource sharing, the application server includes the Resource-Share header field with the value "media-sharing" and includes a "origin" header field parameter set to "session-initiator" or "session-receiver" depending on if the application server is serving the user that initiated the session invitation or if the application server is serving the user receiving the session invitation.

The application server includes resource sharing information in a "rules" header field parameter with one resource sharing rule per media stream in the same order the corresponding m-line appears in the SDP. Each resource sharing rule is constructed as follows:

1. if the media stream is subject for resource sharing, the application server:
   • includes a "new-sharing-key" part;
   • if it is the INVITE request and the request will be sent to more than one UE, includes an "existing-resource-sharing-list" part containing one or more sharing keys already in use in other sessions involving UEs that potentially can receive the session invitation due to the forking of the INVITE request; and
   • includes a "directionality" part indicating in which direction resources sharing can apply; or
2. if the media stream can never be shared, includes an empty string.

Finally, the application server includes a "timestamp" header field parameter with a value higher than included in any other Resource-Share header field involving any of the UEs registered by the user.

The example 1 shows the Resource-Share header field when included in the initial SDP answer on the originating side. The SDP answer contains two media streams and both media streams are subject to resource sharing.

EXAMPLE 1:

Resouce-Share: media-sharing; session-initiator; rules="k1::UL, k20::UL-DL"; timestamp=55688

The example 2 shows the Resource-Share header field when included in the initial SDP offer on the terminating side. The user has several UEs registered where three UEs are already involved in sessions with media streams subject to resource sharing. The SDP offer contains three media streams where only the first and third media stream is subject to resource sharing identified by K2,K3 and K4 for the first media stream and K21, K22 and k23 for the third media stream in already ongoing sessions. The fact that the second media stream is not subject to resource sharing is indicated as an empty string in second position in the comma delimited list of resource sharing rules in the "rules" header field parameter.

EXAMPLE 2:

Resouce-Share: media-sharing; session-receiver; rules="k1:k2/k3/k4:UL,, k20:k21/k22/k23:UL-DL"; timestamp=45678

The example 3 shows the Resource-Share header field when included in a SIP request or SIP response on the originating side when an application server indicates that resources can not be shared due to some service specific reason. This indication can be included already from the beginning of the session or at any point during a session if the SIP proxy or UA determines that resource sharing is not possible any longer.

EXAMPLE 3:

Resource-Share: no-media-sharing; session-initiator

7.2.13.9.4  The P-CSCF extracts resource sharing information for media-streams  Word‑p. 405

When the P-CSCF receives an initial SDP answer destined for the served UE in a request or response containing the Resource-Share header field, the P-CSCF extracts the resource sharing rules for each media stream from the "rules" header field parameter in the same order that the corresponding m-line appear in the SDP. The P-CSCF stores and uses the value in the "new-sharing-key" to identify the resource sharing rule for a media stream.

When the P-CSCF receives an initial SDP offer destined for the served UE in a request, the P-CSCF extracts the resource sharing rules for each media stream from the "rules" header field parameter in the same order that the corresponding m-line appear in the SDP. For each extracted resource sharing rule the P-CSCF checks if the UE is involved in any session using a sharing key in the "existing-sharing-key-list" to identify a media-stream, and

• if the UE is involved in a session using a sharing key in the "existing-sharing-key-list" to identify a media-stream, the P-CSCF stores and uses that sharing key value to identify this resource sharing rule for the media stream in this session; or
• if none of the sharing keys in the "existing-sharing-key-list" is used by any session involving the UE or if the "existing-sharing-key-list" is empty, the P-CSCF stores and uses the value in the "new-sharing-key" to identify this resource sharing rule for this media stream in this session.

If the P-CSCF receives a Resource-Share header field with the value "no-media-sharing" for media streams where resource sharing is already applied due to receipt of a Resource-Share header field with the value "media-sharing" prior to receiving "no-media-sharing" value, the SIP proxy stops media sharing as specified in TS 29.214 annex A.

7.2.14  Definition of Service-Interact-Info header field |R13|

7.2.14.1  Introduction

IANA registry:

Header Field Parameter Registry for the Session Initiation Protocol (SIP)

Header field name:

Service-Interact-Info

Usage:

The Service Interact-Infor header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

One subscriber can subscribe to one or more services provided by different ASs, and one service may be in conflict with one or more other service. Since the conflict can be subject to the status of the service execution, it cannot be avoided during the service provisioning phase.

To avoid such service conflicts, it is needed to have a mechanism to convey information about services executed between the ASes, and an AS can take such information into account to avoid conflicts when executing the local service logic.

7.2.14.2  Applicability statement for the Service-Interact-Info header field

The Service-Interact-Info header field is applicable within a trust domain. The Service-Interact-Info header field can be included in initial SIP requests and responses to initial SIP requests.

AS can include the service identity which has been executed into the Service-Interact-Info header field and also insert service identities which is in conflict with the already executed service.

7.2.14.3  Usage of the Service-Interact-Info header field

Upon receiving a SIP message and executing service logic, the AS should take the information contained in the Service-Interact-Info header field into account. If

1. the executed services indicated in the Service-Interact-Info header field is in conflict with the local service logic; or
2. the local service logic indicated the Service-Interact-Info header field is inconflict with a previously executed service;

the AS should based on local policy decide whether or not to execute the local service.

When certain service logic has been executed, the AS should include the corresponding service identity into the Service-Interact-Info header field. Additionally, the AS can also include identities of any service which may be in conflicit with the executed service.

7.2.14.4  Procedures at the UA  Word‑p. 406

There are no specific procedures specified for a UA. A UAC in a B2BUA can add a Service-Interact-Info header field into the SIP message, or insert a service identity into the Service-Interact-Info header field, or remove the Service-Interact-Info header field when sending a SIP message

7.2.14.5  Procedures at the proxy

A SIP proxy that supports this extension can add a Service-Interact-Info header field into a SIP message, insert a service identity into the Service-Interact-Info header field, or remove the Service-Interact-Info header field when forwarding the SIP message.

7.2.14.6  Security considerations

The Service-Interact-Info header field can contain sensitive information. The Service-Interact-Info header field should be removed when sent outside the trust domain.

A UE is not expected to receive the Service-Interact-Info header field.

7.2.14.7  Syntax

The syntax for Service-Interact-Info header field is specified in table 7.2.14-1.

Table 7.2.14-1: Syntax of Service-Interact-Info

7.2.15  Definition of Cellular-Network-Info header field |R13|

7.2.15.1  Introduction

A User Agent (UA) supporting one or more cellular radio access technology (e.g. E-UTRAN) but using a non-cellular IP-CAN to access the IM CN subsystem can use this header field to relay information to its service provider about the radio cell identity of the cellular radio access network the UE most recently camped on. For example, a UE making an emergency call using the Evolved Packet Core (EPC) via Untrusted Wireless Local Access Network (WLAN) as IP-CAN to access the IM CN subsystem uses this header field to convey location information to its service provider.

7.2.15.2  Applicability statement for the Cellular-Network-Info header field

The Cellular-Network-Info field is applicable within a trust domain. The Cellular-Network-Info header field can be included in any SIP requests and responses in which the P-Access-Network-Info header field is present.

7.2.15.3  Usage of the Cellular-Network-Info header field  Word‑p. 407

The Cellular-Network-Info header field is populated with the following contents:

1. the access-type field is set to one of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD", "3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "3GPP2-1X-Femto" as appropriate to the additional access technology the information is provided about;
2. if the access-type field is set to "3GPP-GERAN", a cgi-3gpp parameter set to the Cell Global Identity obtained from lower layers of the UE. The Cell Global Identity is a concatenation of MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadeciaml digits) and CI (as described in TS 23.003. The "cgi-3gpp" parameter is encoded in ASCII as defined in RFC 20;
3. if the access-type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in TS 23.003 and the UMTS Cell Identity (7 hexadecimal digits) as described in TS 25.331), obtained from lower layers of the UE. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
4. if the access-type field is equal to "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (4 hexadecimal digits when accessing to EPC and 6 hexadecimal digits when accessing to 5GCN) as described in TS 23.003) and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in TS 23.003). The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
   EXAMPLE:

   If MCC is 111, MNC is 22, TAC is 33C4 and ECI is 76B4321, then Cellular-Network-Info header field looks like follows: Cellular-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1112233C476B4321
5. if the access-type field is equal to "3GPP-E-UTRAN-ProSe-UNR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in TS 23.003 obtained from the ProSe-UE-to-network relay that the UE is connected to as specified in TS 24.334. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20;
   EXAMPLE:

   If MCC is 111, MNC is 22 and ECI is 76B4321, then Cellular-Network-Info header field looks like follows: Cellular-Network-Info: 3GPP-E-UTRAN-ProSe-UNR;utran-cell-id-3gpp=1112276B4321.
6. if the access-type field is set to "3GPP2-1X", a ci-3gpp2 parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of SID (16 bits), NID (16 bits), PZID (8 bits) and BASE_ID (16 bits) (see 3GPP2 C.S0005-D [85]) in the specified order. The length of the ci-3gpp2 parameter shall be 14 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters. If the UE does not know the values for any of the above parameters, the UE shall use the value of 0 for that parameter. For example, if the SID is unknown, the UE shall represent the SID as 0x0000;
   EXAMPLE:

   If SID = 0x1234, NID = 0x5678, PZID = 0x12, BASE_ID = 0xFFFF, the ci-3gpp2 value is set to the string "1234567812FFFF".
7. if the access-type field is set to "3GPP2-1X-HRPD", a ci-3gpp2 parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of Sector ID (128 bits) and Subnet length (8 bits) (see 3GPP2 C.S0024-B [86]) and Carrier-ID, if available, (see 3GPP2 X.S0060 [86B]) in the specified order. The length of the ci-3gpp2 parameter shall be 34 or 40 hexadecimal characters depending on whether the Carrier-ID is included. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters;
   EXAMPLE:

   If the Sector ID = 0x12341234123412341234123412341234, Subnet length = 0x11, and the Carrier-ID=0x555444, the ci-3gpp2 value is set to the string "1234123412341234123412341234123411555444".
8. if the access-type field is set to "3GPP2-UMB" 3GPP2 C.S0084-000 [86A], a ci-3gpp2 parameter is set to the ASCII representation of the hexadecimal value of the Sector ID (128 bits) defined in 3GPP2 C.S0084-000 [86A]. The length of the ci-3gpp2 parameter shall be 32 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters;
   EXAMPLE:

   If the Sector ID = 0x12341234123412341234123412341234, the ci-3gpp2 value is set to the string "12341234123412341234123412341234".
9. if the access-type field is set to "3GPP2-1X-Femto", a ci-3gpp2-femto parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of femto MSCID (24 bit), femto CellID (16 bit), FEID (64bit), macro MSCID (24 bits) and macro CellID (16 bits) (3GPP2 X.P0059-200 [86E]) in the specified order. The length of the ci-3gpp2-femto parameter is 36 hexadecimal characters. The hexadecimal characters (A through F) are coded using the uppercase ASCII characters;
10. the cell-info-age parameter indicates the relative time since the information about the cell identity was collected by the UE. The value of the parameter is a number indicating seconds; and
11. if the access-type field is equal to "3GPP-NR-FDD" or "3GPP-NR-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003 and the NR Cell Identity (NCI) (9 hexadecimal digits). The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20.
12. if the access-type field is equal to "3GPP-NR-U-FDD" or "3GPP-NR-U-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in TS 23.003 and the NR Cell Identity (NCI) (9 hexadecimal digits). The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20.

7.2.15.4  Procedures at the UA  Word‑p. 408

A UA that supports this extension and is willing to disclose the related parameters may insert the Cellular-Network-Info header field in any SIP request or response in which the P-Access-Network-Info header field is allowed to be present.

7.2.15.5  Procedures at the proxy

A SIP proxy shall not modify the value of the Cellular-Network-Info header field.

A SIP proxy shall remove the Cellular-Network-Info header field when the SIP signaling is forwarded to a SIP server located in an untrusted administrative network domain.

A SIP proxy that is providing services to the UA, can act upon the information present in the Cellular-Network-Info header field value, if present, to provide a different service depending on the network or the location through which the UA is accessing the server.A SIP proxy can determine the age of the cell identity information from the cell-info-age parameter. Depending on the recentness of the information the SIP proxy can perform different procedures.

7.2.15.6  Security considerations

The Cellular-Network-Info header field contains sensitive information. The Cellular-Network-Info header field should be removed when sent outside the trust domain.

A UE is not expected to receive the Cellular-Network-Info header field.

7.2.15.7  Syntax

The syntax for Cellular-Network-Info header field is specified in table 7.2.15-1.

Table 7.2.15-1: Syntax of Cellular-Network-Info

7.2.16  Priority-Share header field |R13|  Word‑p. 409

7.2.16.1  Introduction

IANA registry:

Header Field Parameter Registry for the Session Initiation Protocol (SIP)

Header field name:

Priority-Share

Usage:

The Priority-Share header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

The Priority-Share header field is used to carry information relating to the possibility to use priority sharing. Priority sharing allows the P-CSCF to instruct the access gateway to use the same bearer for several sessions regardless of the priority of the sessions. When priority sharing is not allowed the P-CSCF will instruct the access gateway to not use priority sharing.

7.2.16.2  Applicability statement for the Priority-Share header field

The Priority-Share header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.

The Priority-Share header field is not included in a SIP message sent to another network if there is no trust relationship.

The Priority-Share header field is applicable whenever an application/sdp MIME body would be applicable, as defined by RFC 3261.

7.2.16.3  Usage of the Priority-Share header field

A SIP UA or SIP proxy that receives a SIP request or response that contains a Priority-Share header field can use the values as appropriate.

A SIP proxy may remove the Priority-Share header field according to local policy.

7.2.16.4  Procedures at the UA

An application server acting as a UA that supports this extension and receives a request or response without the Priority-Share header field may insert a Priority-Share header field prior to forwarding the message. The header is populated as described in subclause 7.2.16.7.

If an application server acting as a UA that supports this extension receives a request or response with the Priority-Share header field, it may use the information from the header field for application-specific logic, i.e., resource reservation. If information from the header field is used, the header field shall be removed from the request or response.

7.2.16.5  Procedures at the proxy  Word‑p. 410

A SIP proxy that supports this extension and receives a request or response without the Priority-Share header field may insert a Priority-Share header field prior to forwarding the message. The header is populated as described in subclause 7.2.16.7.

If a proxy that supports this extension receives a request or response with the Priority-Share header field, it may use the information from the header field for application-specific logic, i.e., resource reservation. If information from the header field is used, the header field shall be removed from the request or response.

7.2.16.6  Security considerations

The Priority-Share header field does not contain any information that can disclose user information or the topology of nodes within an operator network.

7.2.16.7  Syntax

The syntax for Priority-Share header field is specified in table 7.2.16.1

Table 7.2.16.1: Syntax of Priority-Share

7.2.16.8  Examples of usage

The Priority-Share header field is included by an application server in the home network to inform about the possibility to share resources between session regardless of the priority of a session.

7.2.17  Definition of Response-Source header field |R14|

7.2.17.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Response-Source

Usage:

the Response-Source header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

The Response-Source header field is used to carry information related to the originator of an error response. The receiving entities may possibly use this information to decide a more appropriate procedure to invoke in regards with the failure response.

7.2.17.2  Applicability statement for the Response-Source header field

The Response-Source header field is applicable within a single private administrative domain or between different administrative domains where there is a trust relationship between the domains.

7.2.17.3  Usage of the Response-Source header field  Word‑p. 411

A SIP UA or SIP proxy may include the Response-Source header field when responding to a SIP request with an error response to provide the information on who is the sender of the error response using the appropriate URN value as defined in subclause 7.2.17.7.

A SIP UA or SIP proxy that receives a SIP response that contains a Response-Source header field can use the values as appropriate.

7.2.17.4  Procedures at the UA

A UA that supports this extension and rejects a request with an error response may insert a Response-Source header field within the response message. The header is populated as described in subclause 7.2.17.7.

If a UA that supports this extension receives a response with the Response-Source header field, it may take the information from the Response-Source header field into account when handling the response.

7.2.17.5  Procedures at the proxy

A proxy that supports this extension and receives a request for which its internal logic leads to reject the request with an error response may insert a Response-Source header field within the response message. The header is populated as described in subclause 7.2.17.7.

If a proxy that supports this extension receives a response with the Response-Source header field, it may use the information from the header field for its internal logic for error reponses handling.

7.2.17.6  Security considerations

The Response-Source header field will contain a URN identifying the sender that may be considered as sensitive information. The Response-Source header field may be removed when received from outside the trust domain depending on the network policy.

7.2.17.7  Syntax

The ABNF syntax for Response-Source header field is specified in table 7.2.17.7-1.

Table 7.2.17.7-1: Syntax of Response-Source header field

The source-urn-val of the source-urn parameter is coded as a URN. The URN identifies the SIP capable functional entity sending a SIP response.

A URN is defined under the "urn:3gpp" label defined in RFC 5279.

The extension of 3gpp-urn is:

urn:3gpp:fe

A formal reference to the publicly available specification:

3GPP TS 24.229 []

A short phrase describing the function of the extension:

The namespace "fe" is for indicating an IMS functional-entity. See the coding for the namespace extension ns-ext in table 7.2.17.7-2:

Table 7.2.17.7-2: Syntax of urn:3gpp:fe

Contact information for the organization or person making the registration

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

The following fe-id values are defined:

• ue: represents the UE;
• p-cscf: represents the P-CSCF;
• i-cscf: represents the I-CSCF;
• s-cscf: represents the S-CSCF;
• e-cscf: represents the E-CSCF;
• mgcf: represents the MGCF;
• bgcf: represents the BGCF;
• ibcf: represents the IBCF;
• trf: represents the TRF;
• atcf: represents the ATCF;
• agcf: represents the AGCF;
• mrfc: represents the MRFC;
• lrf: represents the LRF;
• msc-server: represents the MSC server; and
• as: represents the AS.

The following fe-param values are defined:

• role:
  1. mmtel-as: indicates that the AS is performing the MMTel services role;
  2. scc-as: indicates that the AS is performing the SCC AS role;
  3. ip-sm-gw: indicates that the AS is performing the IP-SM-GW role;
  4. pf-mcptt-server: indicates that the AS is performing the participating MCPTT server role;
  5. cf-mcptt-server: indicates that the AS is performing the controling MCPTT server role;
  6. ncf-mcptt-server: indicates that the AS is performing the non-controling MCPTT server role;
  7. cms: indicates that the AS is performing the configuration management server role;
  8. gms: indicates that the AS is performing the group management server role;
  9. tads: indicates that the AS is performing the terminating access domain selection role;
  10. iua: indicates that the AS is performing the ICS User Agent role; and
  11. msc-server-ics: indicates that the MSC is performing the MSC server enhanced for ICS role.
• side:
  1. orig: indicates that this functional entity is in the originating network;
  2. term: indicates that this functional entity is in the terminating network;and
  3. transit: indicates that this functional entity is in a transit network.

An example of the source-urn header field parameter value is: fe=<urn:3gpp:fe:p-cscf.orig>.

7.2.18  Definition of Attestation-Info header field |R15|  Word‑p. 413

7.2.18.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Attestation-Info

Usage:

The Attestation-Info header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

When a node has performed attestation of an identity in an incoming request or has attested the origin of the request, the node can inform a downstream node about what kind of attestation the node has performed. A downstream node such as an application server can use this information to provide the user with more accurate information regarding the attested identity.

7.2.18.2  Applicability statement for the Attestation-Info header field

The Attestation-Info header field is applicable within a single private administrative domain or between different administrative domains.

The Attestation-Info header field is applicable when:

1. a node has performed attestation of an identity in an incoming request; or
2. has performed gateway attestation of the request itself.

Case 1) is when a node has knowledge about the originating identity and can attest this identity based on this knowledge.

Case 2) is when a border node in a network receives a request where the border node has no relation to the originating user and the border node adds a value identifying the source of the request.

7.2.18.3  Usage of the Attestation-Info header field

A node in the originating network attesting the identity of the originating user can add an Attestation-Info header field to inform what relation the network has with the originating user. A node at a border of a network can add an identifier identifying from where the request was received. The Attestation-Info header field informs that this procedure has been performed.

A downstream node can use the Attestation-Info header field when providing analytics functions to inform the terminating user the trust level of the originating identity.

7.2.18.4  Procedures at the UA  Word‑p. 414

There are no specific procedures specified for a UA.

7.2.18.5  Procedures at the proxy

A SIP proxy that supports this extension and receives a request may as part of its procedures insert an Attestation-Info header field prior to forwarding the request. The header field is populated with a value as specified in Table 7.2.18-1.

7.2.18.6  Security considerations

The Attestation-Info header field does not contain any sensitive information.

A UE is not expected to receive this information.

7.2.18.7  Syntax

The syntax for Attestation-Info header field is specified in table 7.2.18-1.

Table 7.2.18-1: Syntax of Attestation-Info

The meaning of the values "A", "B" and "C" is as defined in RFC 8588 and references therein.

7.2.18.8  Examples of usage

A node in the originating network, such as a 3GPP S-CSCF or an application server, can when attesting the identity of an originating user insert an Attestation-Info header field to provide information on the relation the network has to the originating user. This information can be used when inserting an Identity header field, or can be taken into account when informing the terminating user about the identity of the originating user.

An edge node, such as a 3GPP entry IBCF, receiving a message withouth any Identity header field can use the Attestation-Info header field to inform that the edge node has performed a gateway attestation as specified in RFC 8588.

7.2.19  Definition of Origination-Id header field |R15|

7.2.19.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Origination-Id

Usage:

The Origination-Id header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

When a node has performed attestation of an identity in an incoming request the node can add a unique identifier to inform about who attested the identity. When a node has attested from where it received the request, the node can send a unique identifier identifying from where the request was received. A downstream node such as an application server can use this information to provide the user with more accurate information regarding the attested identity.

7.2.19.2  Applicability statement for the Origination-Id header field  Word‑p. 415

The Origination-Id header field is applicable within a single private administrative domain or between different administrative domains.

The Origination-Id header field is applicable when:

1. a node has performed attestation of an identity in an incoming request; or
2. has performed gateway attestation of the request itself.

Case 1) is when a node has knowledge about the originating identity and can attest this identity based on this knowledge.

Case 2) is when a border node in a network receives a request where the border node has no relation to the originating user and the border node adds a value identifying the source of the request.

7.2.19.3  Usage of the Origination-Id header field

A node in the originating network attesting the identity of the originating user can add an Origination-Id header field to identify the node that performed the identity attestation. This value is based on local configuration and regulation. A node at a border of a network can add an Origination-Id header field with a unique identifier identifying from where the request was received.

A downstream node can use the Origination-Id header field when providing analytics functions to inform the terminating user the trust level of the originating identity.

7.2.19.4  Procedures at the UA

There are no specific procedures specified for a UA.

7.2.19.5  Procedures at the proxy

A SIP proxy that supports this extension and receives a request may as part of its procedures insert an Origination-ID header field prior to forwarding the request. The header field is populated with a value as specified in Table 7.2.19-1.

7.2.19.6  Security considerations

The Origination-Id header field can contain a unique value identifying a specific node in the network. A network operator may want to remove this information before transporting to an utrusted entity.

A UE is not expected to receive this information.

7.2.19.7  Syntax

The syntax for Origination-Id header field is specified in table 7.2.19-1.

Table 7.2.19-1: Syntax of Origination-Id

The format of the UUID is as defined as in RFC 4122.

7.2.19.8  Examples of usage

A node in the originating network, such as a 3GPP S-CSCF or an application server, can when attesting the identity of an originating user insert an Origination-Id header field to provide information on who attested the identity of the originating user. This information can be used when inserting an Identity header field, or can be taken into account when informing the terminating user about the identity of the originating user.

An edge node, such as a 3GPP entry IBCF, receiving a message without any Identity header field can use the Origination-Id header field to a unique identifier of from where the request is received.

7.2.20  Definition of Additional-Identity header field |R16|  Word‑p. 416

7.2.20.1  Introduction

IANA registry:

Header Fields registry for the Session Initiation Protocol (SIP)

Header field name:

Additional-Identity

Usage:

The Additional-Identity header field is used only for informative purposes.

Header field specification reference:

3GPP TS 24.229 [], http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/

The Additional-Identity header field is used to convey an originating identity on the originating side or a target identity on the terminating side where the served user is not registering this identity but is authorized by the network to use this identity.

On the originating side, when a user has requested such an additional identity to be used for an originating request, the UA can insert this identity in the Additional-Identity header field. When the identity in the Additional-Identity header field has been authorized by the network, the network can remove, ignore or use the Additional-Identity header field. A downstream node such as an application server or UA can use this information to identify the not registered identity on whose behalf the originating user is sending the request.

On the terminating side, when a user is contacted with such an additional identity, and the network decides to inform the terminating user that the user was contacted with this identity, the network can insert this identity in the Additional-Identity header field. A terminating request to the UA can hence contain the Additional-Identity header field with the identity used to reach the terminating user.

7.2.20.2  Applicability statement for the Additional-Identity header field

The Additional-Identity header field is applicable within a single private administrative domain or between different administrative domains.

The Additional-Identity header field is applicable when:

• an originating UA wants to indicate the identity to be used as an originating identity in a multi-identity service;
• a node performs the multi-identity service for an originating UA in an incoming request;
• a node has performed the multi-identity service for a terminating identity in an incoming request; or
• a terminating UA wants to identify the identity used to contact the terminating user.

7.2.20.3  Usage of the Additional-Identity header field

A SIP UA or SIP proxy may include the Additional-Identity header field to indicate:

• in the originating network, the identity to be used for originating requests when the originating user is subscribed to the multi-identity service; and
• in the terminating network, the identity to which the terminating user is contacted when the terminating user is subscribed to the multi-identity service.

7.2.20.4  Procedures at the UA

A SIP UA that supports this extension may as part of its procedures insert the Additional-Identity header field prior to sending the request. The header field is populated with a value as specified in table 7.2.20.7-1.

7.2.20.5  Procedures at the proxy  Word‑p. 417

A SIP proxy that supports this extension and receives a request may as part of its procedures insert an Additional-Identity header field prior to forwarding the request. The header field is populated with a value as specified in table 7.2.20.7-1.

7.2.20.6  Security considerations

Within a 3GPP environment, the Additional-Identity header field is exchanged between a SIP UA and a SIP proxy in the same network. The Additional-Identity header field may also be exchanged between networks when there is a trust relationship for the Additional-Identity header field.

A functional entity at the boundary of the trust domain will remove the Additional-Identity header field when SIP signalling crosses the boundary of the trust domain.

7.2.20.7  Syntax

The syntax for Additional-Identity header field is specified in table 7.2.20.7-1.

Table 7.2.20.7-1: Syntax of the Additional-Identity Header Field

7.2.20.8  Examples of usage

A node in the originating network, such as a UA, can use the Additional-Identity header field to provide to a multi-identity service the information about which identity of the originating user is to be used for this originating request.

A node in the terminating network, such as an application server, when performing the multi-identity service for a terminating user, can insert the Additional-Identity header field to provide information about which identity of the terminating user is to be used as a contacted identity.

---