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…

 

5.7  Procedures at the Application Server (AS)Word‑p. 308

5.7.1  Common Application Server (AS) procedures

5.7.1.0  General |R14|

When sending a failure response to any received request, depending on operator policy, the AS may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "as" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. An AS when sending a failure response will add in the URN the "role" header field parameter set to the corresponding AS role listed in subclause 7.2.17.
Up

5.7.1.1  Notification about registration status

The AS may support the REGISTER method in order to discover the registration status of the user. If a REGISTER request arrives and the AS supports the REGISTER method, the AS shall store the registration expiration interval value from the request and generate a 200 (OK) response or an appropriate failure response. For the success case, the 200 (OK) response shall contain a registration expiration interval value equal to the value received in the REGISTER request. The AS shall store the values received in P-Charging-Function-Addresses header field. Also, the AS shall store the values of the "icid-value" header field parameter and "orig-ioi" header field parameter if present in the P-Charging-Vector header field from the REGISTER request.
If a Contact header field is included in the REGISTER request including a "+g.3gpp.registration-token" header field parameter as defined in subclause 7.9.7, the AS supporting this feature shall store the value of the "+g.3gpp.registration-token" header field parameter.
The AS shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the REGISTER request, a type 3 "term-ioi" header field parameter in the response to REGISTER and the "icid-value" header field parameter. The AS shall set the type 3 "term-ioi" header field parameter to a value that identifies the service provider from which the response is sent, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request.
Upon receipt of a third-party REGISTER request, with the Content-Type header field or with a MIME body part's Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field or a MIME body part's Content-Type header field, independent of the value or presence of Content-Disposition parameters or MIME body part's Content-Disposition parameters, then the following treatment is applied:
  • if the third-party REGISTER request includes an IM CN subsystem XML body with an <ims-3gpp> element, including a version attribute, with the <service-info> child element or a MIME body part containing an <ims-3gpp> element with a <service-info> XML child element as described in subclause 7.6, then the AS may retrieve the service information within the <service-info> XML child element of the <ims-3gpp> element.
Upon receipt of a third-party REGISTER request, with the Content-Type header field or with a body part's Content-Type header field set to "message/sip" and including a "message/sip" MIME body of the incoming REGISTER request, or the 200 (OK) response to the incoming REGISTER request then the AS may retrieve information from the "message/sip" MIME body or body part.
Upon receipt of a third-party REGISTER request, the AS may subscribe to the reg event package for the public user identity registered at the user's registrar (S-CSCF) as described in RFC 3680 and RFC 6665.
On sending a SUBSCRIBE request, the AS shall populate the header fields as follows:
  1. a Request-URI set to the resource to which the AS wants to be subscribed to, i.e. to a SIP URI that contains the public user identity of the user that was received in the To header field of the third-party REGISTER request;
  2. a From header field set to the AS's SIP URI;
  3. a To header field, set to a SIP URI that contains the public user identity of the user that was received in the To header field of the third-party REGISTER request;
  4. an Event header field set to the "reg" event package;
  5. a P-Asserted-Identity header field set to the SIP URI of the AS; and
  6. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter.
Upon receipt of a dialog establishing NOTIFY request, as specified in RFC 6665, associated with the SUBSCRIBE request, the AS shall:
  1. store the information for the so established dialog;
  2. store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request; and
  3. follow the procedures specified in RFC 6665.
Upon receipt of any response, the AS shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field if present.
Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package, the AS shall:
  • store the information for the established dialog;
  • store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request;
  • store the value of the "orig-ioi" header field parameters if present in the P-Charging-Vector header field. The AS shall insert a P-Charging-Vector header field in the response to the NOTIFY request containing the "orig-ioi" header field parameter, if received in the NOTIFY request, a type 3 "term-ioi" header field and the "icid-value" header field parameter;
  • set the type 3 "term-ioi" header field parameter to a value that identifies the service provider from which the response is sent, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request; and
  • follow the procedures specified in RFC 6665.
Up

5.7.1.2  Extracting charging correlation informationWord‑p. 310
When an AS receives an initial request for a dialog or a request for a standalone transaction, the AS shall store the values received in the P-Charging-Vector header field, e.g. "orig-ioi" header field parameter, if present, and "icid-value" header field parameter, and retain the P-Charging-Vector header field in the message. The AS shall store the values received in the P-Charging-Function-Addresses header field and retain the P-Charging-Function-Addresses header field in the message.
When an AS sends any request or response related to a dialog or standalone transaction, the AS shall insert previously saved values into the P-Charging-Vector header field and may insert previously saved values into the P-Charging-Function-Addresses header field before sending the message.
Up

5.7.1.3  Access-Network-Info and Visited-Network-ID

The AS may receive information about the served user core network in REGISTER requests from S-CSCF. This information can be obtained either from the P-Access-Network-Info header field and P-Visited-Network-ID header field in the REGISTER request or can be obtained from those header fields in the body of the REGISTER request.
The AS may also receive information about the served user access network in other requests (excluding CANCEL requests and responses). This information can be obtained from the P-Access-Network-Info header field.
The AS can use the P-Access-Network-Info and P-Visited-Network-ID header fields to provide an appropriate service to the user.
Up

5.7.1.3A  Determination of the served user |R8|

5.7.1.3A.1  General
The determination of the served user is different per session:
If the AS supports the P-Served-User header field as defined in RFC 5502 and RFC 8498 and the P-Served-User header field is included in the received request, the AS can determine the session case related to the request, as specified in TS 29.228, from the P-Served-User header field parameters if available.
Up
5.7.1.3A.2  AS serving an originating user
If an AS receives a request on behalf of an originating user:
  • and the AS supports the P-Served-User header field as defined in RFC 5502, the AS shall determine the served user by taking the identity contained in the P-Served-User header field if available;
  • otherwise, if the AS supports the History-Info header field as defined in RFC 7044 the AS shall determine the served user from the content of the History-Info header field if available; and
  • otherwise, the AS shall determine the served user by taking the identity contained in P-Asserted-Identity header field.
Up
5.7.1.3A.3  AS serving a terminating user
If an AS receives a request on behalf of a terminating user:
  • and the AS supports the P-Served-User header field as defined in RFC 5502, the AS shall determine the served user by taking the identity contained in the P-Served-User header field if available;
  • otherwise, if the AS supports the History-Info header field as defined in RFC 7044 the AS shall determine the served user from the content of the History-Info header field if available; and
  • otherwise, the AS shall determine the served user from the content of the Request-URI.
Up

5.7.1.3B  Determination of the used registration |R12|Word‑p. 311
A prerequisite for the procedure in this subclause is that a REGISTER request has been received including a Contact header field with a "+g.3gpp.registration-token" header field parameter and that the AS supports using this token to identify the registration.
When receiving an initial request for a dialog or a request for a standalone transaction, or a response to such request the AS shall if a "+g.3gpp.registration-token" header field parameter as defined in subclause 7.9A.8 is included in a Feature-Caps header field use this value to identify the registration used for this initial request for a dialog or this request for a standalone transaction or a response to such request by comparing it to the value of the "+g.3gpp.registration-token" Contact header field parameter stored when the user registered.
If the AS routes the originating request to another entity than the S-CSCF, the AS shall remove the "+g.3gpp.registration-token" header field parameter from the Feature-Caps header field before forwarding the request.
Up

5.7.1.4  User identity verification at the AS |R6|

The procedures at the AS to accomplish user identity verification are described with the help of figure 5-1. Procedures for user identity verification using the Identity header field are specified in subclause 5.7.1.25.
When the AS receives a SIP initial or standalone request, excluding REGISTER request, that does not contain credentials, the AS shall:
  1. if a Privacy header field is present in the initial or standalone request and the Privacy header field value is set to "id" or "user", then the user and the request are considered as anonymous, and no further actions are required. The AS shall consider the request as authenticated;
  2. if there is no Privacy header field present in the initial or standalone request, or if the Privacy header field contains a value other than "id" or "user", then the AS shall check for the presence of a P-Asserted-Identity header field in the initial or standalone request. Two cases exist:
    1. the initial or standalone request contains a P-Asserted-Identity header field. This is typically the case when the user is located inside a trusted domain as defined by subclause 4.4. In this case, the AS is aware of the identity of the user and no extra actions are needed. The AS shall consider the request as authenticated; and
    2. the initial or standalone request does not contain a P-Asserted-Identity header field. This is typically the case when the user is located outside a trusted domain as defined by subclause 4.4. In this case, the AS does not have a verified identity of the user. The AS shall check the From header field of the initial or standalone request. If the From header field value in the initial or standalone request is set to "Anonymous" as specified in RFC 3261, then the user and the request are considered as anonymous and no further actions are required. If the From header field value does not indicate anonymity, then the AS shall challenge the user by issuing a 401 (Unauthorized) response including a challenge as per procedures described in RFC 3261.
When the AS receives a SIP initial or standalone request that contains credentials but it does not contain a P-Asserted-Identity header field the AS shall check the correctness of the credentials as follows:
  1. If the credentials are correct, then the AS shall consider the identity of the user verified, and the AS shall consider the request as authenticated;
  2. If the credentials are not correct, the AS may either rechallenge the user by issuing a 401 (Unauthorized) response including a challenge as per procedures described in RFC 3261 (up to a predetermined maximum number of times predefined in the AS configuration data), or consider the user as anonymous. If the user is considered anonymous, the AS shall consider the request as authenticated.
Reproduction of 3GPP TS 24.229, Figure 5-1: User identity verification flow at the AS
Up

5.7.1.5  Request authorization |R6|Word‑p. 313
Once the AS have tried to verify the identity of the user, the AS either has a verified identity of the user or it considers the user as anonymous.
If the user is considered anonymous, the AS shall check whether the authorization policy defined for this request allows anonymous requests. If anonymous requests are allowed, then the AS can proceed with the requested functionality, otherwise, the AS shall not proceed with the requested functionality.
If the user is identified by an identity, the AS shall apply the authorization policy related to the requested functionality to detect whether the particular user is allowed to request the functionality. The authorization policy may require a verified identity of a user.
If the request is authorized then the AS shall continue with the procedures as defined for that request.
If the request is not authorized, the AS shall either:
  • reject the request according to the procedures defined for that request e.g., by issuing a 403 (Forbidden) response; or
  • send a 2xx final response if the authorization policy requires to deny the requested functionality, whilst appearing to the user as if the request has been granted.
Up

5.7.1.6  Event notification throttling |R6|

If the AS has a local configuration information limiting the rate at which notification generation is allowed, then the AS shall take that information into account. Such local configuration information could be e.g. the shortest time period between issuing consecutive NOTIFY requests.

5.7.1.7  Local numbering |R7|

5.7.1.7.1  Interpretation of the numbers in a non-international format
If home operator's local policy defines a prefix string(s) to enable subscribers to differentiate dialling a geo-local number and/or a home-local number and if the phone number in a non-international format in the Request-URI includes such a prefix, the AS shall interpret the received number in a non-international format as a geo-local number or as a home-local number according to the prefix.
If the phone number in a non-international format in the Request-URI includes a "phone-context" tel URI parameter, the AS shall:
  1. if the "phone-context" tel URI parameter contains access technology information or the home network domain name prefixed by the "geo-local." string, interpret it as a geo-local number;
  2. if the "phone-context" tel URI parameter contains the home network domain name, interpret it as a home-local number; or
  3. if the "phone-context" tel URI parameter contains any other value, apply general procedures for translation.
If the phone number in a non-international format in the Request-URI includes both operator defined prefix and a "phone-context" tel URI parameter and those information are contradictory, the AS shall ignore either the prefix or the "phone-context" tel URI parameter according to operator policy.
If the phone number in a non-international format in the Request-URI does not include either a "phone-context" tel URI parameter or an operator defined prefix, the AS shall interpret the phone number in a non-international format either as a geo-local number or as a home-local number according to operator policy.
Up
5.7.1.7.2  Translation of the numbers in a non-international formatWord‑p. 314
When an AS receives a request having a geo-local number in a non-international format in the Request-URI, the AS shall use the "phone-context" tel URI parameter to determine the visited access network, if the "phone-context" tel URI parameter in the Request-URI is available. If the "phone-context" tel URI parameter in the Request-URI is not available, the AS may determine the visited access network based on the available P-Access-Network-Info header fields containing the access-type field, if it is available in the received request, or by means outside the scope of this document.
If the visited access network is determined:
  1. if the home network supports the roaming architecture for voice over IMS with local breakout, and an incoming INVITE request contains a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter, the AS may choose to not attempt translation of some geo-local numbers and defer the translation to the visited network after loopback has been performed; or
  2. the AS shall attempt to determine whether the geo-local number:
    1. corresponds to a home local service number that can be used by a roaming user;
    2. is used to access a service in the visited network; or
    3. is used to access the local addressing plan of the visited network
  • and translate the received geo-local number to a globally routeable SIP URI or an international tel URI:
When an AS receives a request having a home-local number in a non-international format in the Request-URI, the AS shall determine whether the home-local number is used to access a service or the local addressing plan and translate the received home-local number to a globally routeable SIP URI or an international tel URI:
When an AS receives a request having any other number in a non-international format in the Request-URI, the AS shall attempt to determine whether it is used to access a service in the third network or the local addressing plan of the third network and translate the received number in a non-international format to a globally routeable SIP URI or an international tel URI:
If the translation at the AS fails, the AS shall either send an appropriate SIP response or leave the Request-URI unmodified and route the request based on the topmost Route header field, based on local policy.
Up

5.7.1.8  GRUU assignment and usage |R7|

It is possible for an AS to use a GRUU referring to itself when inserting a contact address in a dialog establishing or target refreshing SIP message.
This specification does not define how GRUUs are created by the AS; they can be provisioned by the operator or obtained by any other mechanism. The GRUU shall remain valid for the time period in which features addressed to it remain meaningful.
The AS shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which the GRUU was provided.
EXAMPLE:
Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and containing a Replaces header field referencing that dialog, the AS will be able to establish the new call replacing the old one, if that is appropriate for the features being provided by the AS.
When an AS is acting as a routeing B2BUA (as defined in subclause 5.7.5) it may provide a contact address that is not a GRUU when the contact address in the incoming message that is being replaced is not a GRUU.
When an AS is acting as a routeing B2BUA forwards a SIP request it shall transparently forward a received Contact header field when the Contact header field contains a GRUU. When transparently forwarding a received Contact header field of a dialog-forming request, the AS shall include its own URI in a Record-Route header field in order to ensure that it is included on the route of subsequent requests.
When an AS acts as UA or Initiating B2BUA it shall use a GRUU as the contact address if the AS acts as a notifier per RFC 6665 and RFC 7647, otherwise the AS may provide a contact address that is not a GRUU in cases where it can ascertain that valid requests that could result from the use of that contact and follow the usage rules of RFC 5627 will reach the element. In all other cases the AS shall use a GRUU.
An AS acting as a UA or an initiating B2BUA on behalf of a public user identity can provide a GRUU in the contact address referring to itself as described above. When the AS provides a GRUU on behalf of a user, subsequent dialog-initiating requests sent to that GRUU will be routed directly to the AS, thus bypassing terminating services assigned to the user. If the AS wishes to have terminating services applied for the user, the AS may generate a new terminating request addressed to a public GRUU associated with the public user identity of the user.
When an AS acts as a UA or an initiating B2BUA, and is originating or terminating a request on behalf of a public user identity, and privacy is required, the AS shall ensure that any GRUU provided in the contact address in the request does not reveal the public user identity of the user.
Up

5.7.1.9  Use of ICSI and IARI values |R7|Word‑p. 315
Based on service logic, an AS can validate an ICSI value received in an Accept-Contact header field or received in a P-Asserted-Service header field and reject the request if necessary.
A trusted AS may insert a P-Asserted-Service header field in a request for a new dialog or standalone transaction. An untrusted AS may insert a P-Preferred-Service header field in a request for a new dialog or standalone transaction. If the request is related to an IMS communication service that requires the use of an ICSI then the AS:
  • shall include the ICSI value (coded as specified in subclause 7.2A.8.2), for the IMS communication service that is related to the request in either a P-Asserted-Service header field or a P-Preferred-Service header field depending whether the AS is trusted or not according to RFC 6050.
When an AS that is acting as a UA or initiating B2BUA or routeing B2BUA sends an initial request for a dialog or a request for a standalone transaction, the AS may include an Accept-Contact header field containing:
if the ICSI or IARIs for the IMS communication service and IMS application are known.
The AS may:
  • include the received ICSI and IARI values;
  • replace or remove received ICSI and IARI values; or
  • include new ICSI and IARI values.
When the AS acting as a UA or initiating B2BUA or routeing B2BUA sends a SIP request or a SIP response related to an IMS communication service, the AS may include in the Contact header field:
if the ICSI or IARIs for the IMS communication service and IMS application are known. The AS may:
  • include the received ICSI and IARI values;
  • replace or remove received ICSI values; or
  • include new ICSI and IARI values.
When sending a 18x or 2xx response to a request on behalf of an originating user, then the AS may insert a Feature-Caps header field with the "+g.3gpp.icsi-ref" header field parameter into the response, as specified in RFC 6809. The parameter value is set according to subclause 7.9A.2.
When sending a request on behalf of a terminating user, then the AS may insert a Feature-Caps header field with the "+g.3gpp.icsi-ref" header field parameter. The parameter value is set according to subclause 7.9A.2.
If the AS inserted the header field parameters in the Feature-Caps header field in the request or in 18x or 2xx response to request then the AS shall include the header field parameters with the same parameter values into the Feature-Caps header field in any target refresh request, and in each 1xx or 2xx response to target refresh request sent in the same direction.
Up

5.7.1.10  Carrier selection |R8|Word‑p. 316
An AS may play a role in support of carrier selection as defined in RFC 4694.
When an AS that supports carrier selection receives an initial request with a Request-URI in the form of a tel-URI that contains a "cic" tel-URI parameter inserted by the UE and if configured per operator policy, the AS may validate the value of the "cic" parameter. If an AS that supports carrier selection determines the "cic" parameter received in the initial request to be valid, as configured per operator policy, the AS shall process the request accordingly. If an AS supports carrier selecton and determines the "cic" parameter received in the initial request to be invalid, then the AS shall remove the "cic" parameter and process the request as if no "cic" had been received from the UE.
When an AS that support carrier selection receives an initial request with a Request-URI in the form of a tel-URI, the AS may, based on operator policy, insert an appropriate value for the "cic" tel-URI parameter as defined in RFC 4694.
When an AS that support carrier selection receives an initial request with a Request-URI in the form of a SIP URI user=dialstring (see RFC 4967), the AS may translate the SIP URI to a valid tel-URI or a valid SIP URI user=phone comprising a userinfo part containing the tel-URI and a domain matching the domain of the original SIP URI user=dialstring. If the received SIP URI user=dialstring is successfully converted, then the AS shall replace the Request-URI with the newly created tel-URI or SIP URI user=phone. The AS shall then process the request as if it had arrived from the UE containing this tel-URI or SIP URI user=phone in the Request-URI.
The AS carrier selection procedures also apply when the request contains a Request-URI in the form of a SIP URI user=phone, where the "cic" tel-URI parameter is contained in the userinfo part of the SIP URI.
Up

5.7.1.11  Tracing |R14|Word‑p. 317
An AS can retrieve tracing configuration information from the HSS via the Sh reference point. The AS tracing configuration can use the parameters specified in TS 24.323 but need not structure them as a management object.

5.7.1.12  Delivery of original destination identity |R9|

If the service the AS provides needs to deliver the original destination identity to the UE, the AS shall insert a new hi-entry to the last hi-entry of History-Info header field including "mp" header field parameter as specified in RFC 7044.
Up

5.7.1.13  CPC and OLI |R7|

The AS may populate the "cpc" and "oli" URI parameters in each initial request for a dialog or a request for a standalone transaction in the tel URI or SIP URI representation of telephone numbers in the P-Asserted-Identity header field based on their origin source.

5.7.1.14  Emergency transactions |R10|

Identification of emergency transactions for termination in the public network by an AS are outside the scope of this document, and are dependent on many application specific considerations.
Where an AS decides to generate an emergency request on behalf of its served user, the AS shall meet the following conditions:
  1. the UE is in the same network as the S-CSCF (i.e. that the UE is not roaming).
The AS generate the request with the following contents:
  1. include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031. An additional sub-service type can be added if information on the type of emergency service is known;
  2. a Route header field with the topmost Route header field set to the URI associated with an E-CSCF;
  3. if the AS is part of the trust domain of the network, a P-Asserted-Identity header field containing the identity of the UE served by the AS;
  4. if the AS is not part of the trust domain of the network, a P-Preferred-Identity header field containing the identity of the UE served by the AS;
  5. if a GRUU is available for the UE served by the AS, provide the GRUU as part of a Contact header field;
  6. if a location is available at the AS in any form, include a Geolocation header field with that location; and
  7. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260.
If the AS does not receive any response to the INVITE request (including its retransmissions); or receives a 3xx response or 480 (Temporarily Unavailable) response to an INVITE request, the AS shall select a new E-CSCF and forward the INVITE request.
Up

5.7.1.15  Protecting against attacks using 3xx responses |R11|Word‑p. 318
The AS upon receiving a 3xx response to a request from the served UE that contains a Contact header field may remove the Contact header field or modify the response code from 3xx to an appropriate non 2xx response code (e.g. 5xx response code) based on operator policy before sending the response towards the UE.
Up

5.7.1.16  Support of Roaming Architecture for Voice over IMS with Local Breakout |R11|

5.7.1.16.1  Preservation of parameters
An AS in a network supporting the roaming architecture for voice over IMS with local breakout shall not change the value of the "icid-value" header field parameter in the P-Charging-Vector header field received in the INVITE request when the AS sends any request or response related to an INVITE transaction.
5.7.1.16.2  Preference for loopback routeing not to occur
When the AS is accessed by a network supporting roaming architecture for voice over IMS with local breakout, and the incoming INVITE request contains a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter, the AS can indicate to the S-CSCF its preference for loopback routeing not to occur by removing the "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field from any outgoing INVITE request back to the S-CSCF. Reasons for such an indication might include the need to terminate media streams at an MRF in the home network.
Up

5.7.1.17  Delivery of network provided location information |R11|Word‑p. 319
If the AS supports delivery of network provided location information, and the AS performs the retrieval of cell id and/or UE time zone via Sh interface, the AS shall insert the P-Access-Network-Info header field with the cell id, local-time-zone parameter and/or the "daylight-saving-time" parameter, including a "network-provided" parameter in the incoming request or response. Additionally, if required by local operator policy and the AS is able to deduce a Geographical Identifier from the Cell Global Identity (CGI) or form the Service Area Identifier (SAI), the AS shall include an operator-specific-GI header field parameter. The P-Access-Network-Info header field shall only be inserted if there is not already a network provided information.
When the AS receives, in a SIP request or response, a P-Access-Network-Info header field which does not contain the operator-specific-GI header field parameter, contains a Cell Global Identity (CGI) or a Service Area Identifier (SAI) information and contains the "network provided" header field parameter, if required by local operator policy and if the AS is able to deduce a Geographical Identifier from the contained Cell Global Identity (CGI) or form the contained Service Area Identifier (SAI), the AS shall instert an operator-specific-GI header field parameter in that received network provided P-Access-Network-Info header field.
The AS can obtain a Geographical Identifier from the CLF by using the e2 interface (see ETSI ES 283 035 [98]).
Up

5.7.1.18  Delivery of MRB address information |R11|

A visited MRB address can be received during session establishment. If an AS receives the URI of an MRB in a "+g.3gpp.mrb" header field parameter included in a Feature-Caps header field of an INVITE request, it shall store this URI. If the AS requests allocation of MRF resources from an MRB in its own network, either in in-line or query mode, the AS shall forward the visited network MRB URI in the request.

5.7.1.19  Overload control |R11|

5.7.1.19.1  Outgoing subscriptions to load-control event
Based on operator policy, the AS may subscribe to the load-control event package with one ore more target SIP entities. The list of target SIP entities is provisioned.
Subscription to the load-control event package is triggered by internal events (e.g. the physical device hosting the SIP entity is power-cycled) or through a management interface.
The AS shall perform subscriptions to the load-control event package to a target entity in accordance with RFC 6665 and with RFC 7200. When subscribing to the load-control event, the AS shall:
  1. Send a SUBSCRIBE request in accordance with RFC 6665 and with RFC 7200 to the target entity, with the following elements:
    • an Expires header field set to a network specific value;
  2. If the target entity is located in a different network and local policy requires the application of IBCF capabilities, forward the request to an IBCF acting as an exit point.
The AS shall automatically refresh ongoing subscriptions to the load-control event package either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less.
The AS can terminate a subscription according to RFC 6665.
Up
5.7.1.19.2  Incoming subscriptions to load-control eventWord‑p. 320
If subscriptions to load-control event package is supported, the AS shall handle incoming subscriptions to the load-control event package in accordance with RFC 6665 and with RFC 7200. When the AS receives a SUBCRIBE request for the load-control event from an unauthorised or unexpected source, the AS shall generate a "403 forbidden" response to the SUBSCRIBE request.
If the AS receives a SUBSCRIBE request from an authorised source the AS shall:
  1. Generate a "200 OK" response to the SUBSCRIBE request with the following settings:
    • an Expires header field, set to either the same or a decreased value as the Expires header field in SUBSCRIBE request; and
    • the Contact header field set to an identifier uniquely associated to the SUBSCRIBE request that may help correlating refreshes.
  2. In case of an initial subscription, determine the list of load filters applicable to the subscriber, create an XML document to represent this information and send it as an attachement to a NOTIFY request towards the subscriber. If no applicable load filters are identified when the subscription request is received, an empty document is attached to the NOTIFY request.
Subsequent NOTIFY requests with updated or new filters may then be sent as the actual load of the target entity evolves.
Up

5.7.1.20  Procedures in the AS for resource sharing |R13|

5.7.1.20.1  General
An AS supporting resource sharing shall use the "+g.3gpp.registration-token" header field parameter in the Contact header field of the incoming third-party REGISTER request and the "+g.3gpp.registration-token" header field parameter in the Feature-Caps header field in the initial INVITE request or provisional responses to the initial INVITE to identify the UE.
The AS supporting resource sharing shall only include the Resource-Share header field in requests and responses destined to the served user and in all other cases remove the header field.
Up
5.7.1.20.2  UE-originating case
If the AS supporting resource sharing receives a response or request destined to the served user containing a Resource-Share header field, the AS shall remove that header field from the outgoing response or request.
Upon receiving an SDP answer in a provisional response or a 200 (OK) response to an initial INVITE request from a UE served by a P-CSCF supporting resource sharing, the AS supporting resource sharing shall determine whether resource sharing can be applied.
If the AS:
  1. determines that at least one media stream in the initial SDP answer is subject to resource sharing, the AS shall in the outgoing response include a Resource-Share header field as described in subclause 7.2.13.4 with the following clarifications:
    1. the AS shall set the "origin" header field parameter to "session-initiator"; and
    2. if
      • a session exists that can share resources with the dialog created by the initial INVITE request involving the same UE, the AS shall include a new sharing key set to the value of the sharing key in the other session and use this sharing key to identify the resource sharing rule for this media stream in this session; and
      • no session exists that can share resources with the dialog created by the initial INVITE request, the AS shall include a new sharing key unique among all UEs registered by the user and use this sharing key to identify the resource sharing rule for this media stream in this session; and
  2. determines that resource sharing can never be applied for any of the media streams in the SDP answer, the AS shall include a Resource-Share header field set to the value "no-media-sharing" in the outgoing response.
Up
5.7.1.20.3  UE-terminating caseWord‑p. 321
5.7.1.20.3.1  Determine resource sharing using the initial SDP offer
Upon receiving an initial INVITE request containing an initial SDP offer destined for the served user, the AS supporting resource sharing shall if at least one registered UE is served by a P-CSCF supporting resource sharingdetermine if resource sharing can be applied.
If the AS:
  1. determines that at least one media stream in the initial SDP answer is subject to resource sharing, the AS shall in the outgoing request include a Resource-Share header field as described in subclause 7.2.13.4 with the following clarifications:
    1. the AS shall set the "origin" header field parameter to "session-receiver";
    2. the AS shall include a new sharing key part that is determined as follows:
      1. if the AS is aware of only one registered contact:
        1. if a session exists where media in the existing session can be shared with media in the new SDP offer, the sharing key in the INVITE request shall be set to the value of the sharing key used in the existing session and the AS shall use this sharing key to identify the resource sharing rules for each media stream in the session; or
        2. if no session exists where media in the existing session can be shared with media in the new SDP offer, the AS shall create a new sharing key that is unique among all sessions that exist on the UE. This new sharing key shall be included in the INVITE request and is used to identify the resource sharing rules for each media stream in this session; and
      2. if the AS is aware of more than one registered contacts:
        1. if the AS is using an Accept-Contact header field, Reject-Contact header field, and/or a GRUU in the request URI to target a specific registered UE and a session exists on the target UE where media in the existing session can be shared with media in the new SDP offer, the sharing key in the INVITE request shall be set to the value of the sharing key used in the existing session and the AS shall use this sharing key to identify the resource sharing rules for each media stream in the session; or
        2. if no session exists on the target UE (or on the set of UEs when more than one UE is registered and the S-CSCF can fork the INVITE request to more than one UE) where media in the existing session can be shared with media in the new SDP offer, the AS shall create a new sharing key that is unique among all sessions that exist for all UEs registered for the server user. This new sharing key shall be included in the INVITE request and is used to identify the resource sharing rules for each media stream in this session; and
    3. if the AS is aware of more than one registered contact and the AS is not using an Accept-Contact header field, Reject-Contact header field, and/or a GRUU in the request URI to target a specific registered UE (so that the S-CSCF is allowed to fork the INVITE request to one or more UEs) and sessions exist with any registered UE where media in an existing session can be shared with media in the new SDP offer, the existing-sharing-key-list part in the INVITE shall be set to the value of the sharing keys used in the existing sessions; and
  2. determines that resource sharing can not be applied, the AS shall include a Resource-Share header field set to the value "no-media-sharing" in the outgoing request.
Up
5.7.1.20.3.2  Determine resource sharing using the initial SDP answerWord‑p. 322
Upon receiving a PRACK request or an ACK request destined to a UE served by a P-CSCF supporting resource sharing that contains an initial SDP answer, the AS supporting resource sharing shall determine if resource sharing can be applied.
If the AS:
  1. determines that at least one media stream in the initial SDP answer is subject to resource sharing, the AS shall in the outgoing request include a Resource-Share header field as described in subclause 7.2.13.4 with the following clarifications:
    1. the "origin" header field parameter shall be set to "session-receiver"; and
    2. if
      • a session exists that can share resources involving the same UE, the AS shall include a new sharing key set to the value of the sharing key in the other session and use this sharing key to identify the resource sharing rule for this media stream in this dialog; and
      • no session exists that can share resources, the AS shall include a new sharing key unique among all UEs registered by the user and use this sharing key to identify the resource sharing rule for this media stream in this dialog; and
  2. determines that resource sharing can never be applied for any of the media streams in the SDP answer, the AS shall include a Resource-Share header field with the value "no-media-sharing" as described in subclause 7.2.13.4 in the outgoing response.
Up
5.7.1.20.4  Updating the resource sharing options
If the AS during the duration of the call determines that the resource sharing options needs to be changed (e.g. if media streams are added by the UE), then the AS shall include a Resource-Share header field with the updated resource sharing options as specified in subclause 7.2.13, in the outgoing request or response causing the reason for change.
Up
5.7.1.20.5  Abnormal cases
If the AS receives a request or response from a served user containing a Resource-Share field with the value "no-media-sharing", the AS shall no longer apply resource sharing with sessions involving the UE sending the request or response.
If the AS receives a request or response from a served user containg an SDP offer conflicting with an earlier decision to share resources, the AS shall include in the response carrying the SDP answer towards the served user a Resource-Share header field with the value "no-media-sharing" along with the "origin" header field parameter set to "session-initiator" or "session-receiver" as appropriate and no longer apply resource sharing with sessions involving the UE sending the request or response.
Up

5.7.1.21  Dynamic Service Interaction |R13|Word‑p. 323
If an AS supports dynamic service interaction, the AS should insert the Service-Interact-Info header field into the SIP messages before those messages are sent out. The Service-Interact-Info field is filled with the service identities of the services which have been executed. Additionally, the AS may insert into the Service-Interact-Info header field with the identities of the services which may have confliction with the executed services according to local policy.
If the AS supports dynamic service interaction, it should take the information contained in any received Service-Interact-Info header field into account when executing service logic.
If the AS does not recognize the service identities contained in the Service-Interact-Info header field, they should be ignored.
Up

5.7.1.22  Service access number translation |R13|

When the AS is accessed by a service access number (e.g. toll free, premium service) and performes a translation of this number into a routeable number, the AS shall include in the outgoing request:
  1. the Request-URI set to the targeted SIP URI containing the "cause" SIP URI parameter, defined in RFC 4458, set to the value "380" defined in RFC 8119; and
  2. the History-Info header field constructed according to RFC 7044 in which the hi-targeted-to-uri of the last hi-entry is set to the new Request-URI with the "cause" SIP URI parameter, defined in RFC 4458, set to the value "380" defined in RFC 8119.
A service access number does not constrain the number format. A local service number as defined in TS 23.228 and described in subclause 5.7.1.7 can be a service access number.
Up

5.7.1.23  Procedures in the AS for priority sharing |R13|

5.7.1.23.1  General
An AS supporting priority sharing and if according to local policy shall apply priority sharing as specified in the following subclauses.
An AS supporting priority sharing shall only include a Priority-Share header field in requests and responses destined to the served user and in all other cases remove the header field.
5.7.1.23.2  Session originating procedures
If the Feature-Caps header field with the g.3gpp.priority-share feature-capability indicator was included in the "message/sip" MIME body in the third-party REGISTER request and when the AS determines that priority sharing can be applied, the AS supporting priority sharing shall:
  1. include the Priority-Share header field with the value "allowed" defined in subclause 7.2.16 in a 18x and 2xx response to the initial INVITE request; or
  2. include the Priority-Share header field with the value "allowed" defined in subclause 7.2.16 in a subsequent request or a response to subsequent requests destined to the served user.
If priority sharing can not be applied any longer, the AS shall include the Priority-Share header field, defined in subclause 7.2.16, with the value "not-allowed" in a request or response destined to the served user.
Up
5.7.1.23.3  Session terminating proceduresWord‑p. 324
If the incoming REGISTER request contained in the "message/sip" MIME body of a third-party REGISTER request the g.3gpp.priority-share feature-capability indicator in a Feature-Caps header field and when the AS determines that priority sharing can be applied, the AS supporting priority sharing shall:
  1. include the Priority-Share header field with the value "allowed" defined in subclause 7.2.16 in the initial INVITE request destined to the served user; or
  2. include Priority-Share header field with the value "allowed" defined subclause 7.2.16 in a subsequent request or responses to a subsequent request destined to the served user.
If priority sharing can not be applied any longer, the AS shall include the Priority-Share header field, defined in subclause 7.2.16, with the value "not-allowed" in a request or response destined to the served user.
Up

5.7.1.24  Handling re-INVITE request collisions |R14|

An AS shall handle re-INVITE request collisions as specified in RFC 3261 with the clarification in this subclause.
When the AS receives a SIP 491 (Request Pending) response to a re-INVITE request initiated by the AS and sent towards the remote user, the AS shall:
  1. if the AS is serving the user at the originating side of the call, act as the the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 2.1 and 4 seconds in units of 10 ms; and
  2. if the AS is serving the user at the terminating side of the call, act as not being the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 0 and 2 seconds in units of 10 ms.
    When the AS receives a SIP 491 (Request Pending) response to a re-INVITE request initiated by the AS and sent towards the served user, the AS shall:
    1. if the AS is serving the user at the originating side of the call, act as not being the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 0 and 2 seconds in units of 10 ms; and
    2. if the AS is serving the user at the terminating side of the call, act as the owner of the Call-ID of the dialog ID and should select a randomly choosen time to be between 2.1 and 4 seconds in units of 10 ms.
Up

5.7.1.25  User verification using the Identity header field |R14|

5.7.1.25.1  General
RFC 8224 describes a mechanism where an authentication service after verifying the calling number identity inserts a signature over selected header fields. A verification service can then use this signature to trust the correctness of the identity.
draft-ietf-stir-passport-divert [265] describes a mechanism where an authentication service after verifying the diverting number identity inserts a signature over selected header fields. A verification service can then use this signature to trust the correctness of the diverting identity.
Up
5.7.1.25.2  Originating procedures
An originating AS supporting the calling number verification using signature verification and attestation information, as defined in subclause 3.1:
1) may based on local policy insert an Identity header field as specified in RFC 8224 for all initial INVITE requests and MESSAGE requests and shall for this purpose use the identity in the P-Asserted-Identity header field or the From header field; or
2) may based on local policy perform attestation of the identity of the served user by:
a) inserting a "verstat" tel URI parameter, specified in subclause 7.2A.20; in the From header field or the P-Asserted-Identity header field if not already present; and
b) insert an Origination-Id header field as specified in subclause 7.2.19 and an Attestation-Info header field specified in subclause 7.2.18, if not alredy present.
If the AS performs originating services on behalf of a diverting user, the AS may assert the identity of the diverting user by inserting a "verstat" tel URI parameter, specified in subclause 7.2A.20, in the History-Info hi-entry representing the diverting user.
Up
5.7.1.25.3  Terminating proceduresWord‑p. 325
Upon receiving an initial INVITE request or a MESSAGE request containing one or more Identity header fields, an AS supporting the calling number verification using signature verification and attestation information, as defined in subclause 3.1, shall if the network indicated support for the calling number verification during registration:
  • if no "verstat" tel URI parameter is present for the identity to be verified in the From or P-Asserted-Identity header field, perform user identity verification of the originating user identity using the Identity header field containing a PASSporT SHAKEN JSON Web Token, specified in RFC 8588 and based on local policy all Identity header fields containing a PASSporT div JSON Web Token, specified in draft-ietf-stir-passport-divert [265], in the received request.Based on the outcome of the verification insert a "verstat" tel URI parameter, specified in subclause 7.2A.20, with a value representing the outcome of the verification in the tel URI or SIP URI with the user=phone parameter of each P-Asserted-Identity header field or From header field where the URI contains the calling number that was tested for verification and based on local policy in all verified identities in the History-Info header field.
If no Identity header field is present in the received INVITE or MESSAGE request, but an Origination-Id header field along with an Attestation-Info header field set either to "B" or "C" is present, the AS shall set the verstat tel URI parameter to the value "No-TN-Validation".
Up
5.7.1.25.4  Procedures over the Ms reference point |R15|
If the AS receives a verificationRequest as specified in Annex V, the AS verifies the request and when verified generates a verificationResponse, as specified in Annex V, including a "verstat" claim for the verified identity.
If the AS receives a signingRequest, specified in Annex V, the AS sends the signed information in a signingResponse as specified in Annex V.

5.7.1.26  Procedures in the AS for 3GPP PS data off |R14|

An AS that supports 3GPP PS data off can receive in the message/SIP MIME body in a third party REGISTER request the REGISTER request sent by the UE. If this REGISTER request contains a "+g.3gpp.ps-data-off" Contact header field parameter the AS can determine that the UE supports 3GPP PS data off, and the value of the parameter indicates the 3GPP PS data off status. When the AS receives an initial request for a dialog or a standalone transaction destined to the served user, if:
  • the latest "+g.3gpp.ps-data-off" Contact header field parameter, specified in subclauce 7.9.8, that was received in a third party REGISTER request, as specified above, was set to "active" in the UE; and
  • the service the AS supports is not configured as a 3GPP PS data off exempt service to be used in the HPLMN or the EHPLMN, or the service the AS support is not configured as a 3GPP PS data off exempt service to be used in the VPLMN;
the AS shall not send the request to the UE via GPRS IP-CAN, EPS IP-CAN or 5GS IP-CAN.
Up


Up   Top   ToC