5.7 Procedures at the Application Server (AS)

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

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

5.7.1 Common Application Server (AS) procedures

5.7.1.0 General

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.

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.

NOTE 1: The user can have one or more contacts registered after a 3^rd party REGISTER request with an Expires header field set to a value "0" has been received. If an AS needs more detailed knowledge of the user registration status, the AS can subscribe to the reg event package.

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.

NOTE 2: The S-CSCF can set this token to the same value as used in the "id" parameter identifying the contact in the "reg" event package, allowing the AS to retrieve the value from the "reg" event package. The AS can know by configuration or other means if the S-CSCF uses this value.

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 [43] and RFC 6665 [28].

On sending a SUBSCRIBE request, the AS shall populate the header fields as follows:

a) 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;

b) a From header field set to the AS’s SIP URI;

c) 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;

d) an Event header field set to the "reg" event package;

e) a P-Asserted-Identity header field set to the SIP URI of the AS; and

NOTE 3: The S-CSCF expects the SIP URI used in the P-Asserted-Identity header field to correspond to the SIP URI, which identified this AS in the initial filter criteria of the user to whose registration state the AS subscribes to.

f) a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] 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 [28], 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 [28].

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.

NOTE 4: Any received term-ioi parameter will be a type 3 term-ioi. The type 3 term-ioi identifies the network operator from which the response was sent.

NOTE 5: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header field set to "terminated", the AS considers the subscription to the reg event package terminated, i.e. as if the AS had sent a SUBSCRIBE request with an Expires header field containing a value of zero.

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

5.7.1.2 Extracting charging correlation information

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.

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.

5.7.1.3A Determination of the served user

5.7.1.3A.1 General

The determination of the served user is different per session:

– for an originating session, the procedure is described in subclause 5.7.1.3A.2; and

– for a terminating session the procedure is described in subclause 5.7.1.3A.3.

If the AS supports the P-Served-User header field as defined in RFC 5502 [133] and RFC 8498 [239] 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 3GPP TS 29.228 [14], from the P-Served-User header field parameters if available.

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 [133], 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 [66] 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.

5.7.1.3A.3 AS serving a terminating user

If an AS receives a request on behalf of a terminating user:

– otherwise, if the AS supports the History-Info header field as defined in RFC 7044 [66] 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.

5.7.1.3B Determination of the used registration

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.

NOTE: The Include Register Request or Include Register Response indication in the initial Filter Criteria can be used to provide the incoming REGISTER request or 200 (OK) response to the incoming REGISTER request containing the instance ID to the AS. The AS can use the mechanism in this subclause to determine the instance ID for subsequent requests and responses.

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.

5.7.1.4 User identity verification at the AS

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.

NOTE: Different means can be used to represent or transport the credentials. Such mechanisms are subject to operator policy and can e.g. include the P-Asserted-Identity header field, the Authorization header field or other mechanisms not specified by 3GPP TS 24.229.

When the AS receives a SIP initial or standalone request, excluding REGISTER request, that does not contain credentials, the AS shall:

a) 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;

b) 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:

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

ii) 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 [26], 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 [26].

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:

a) 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;

b) 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 [26] (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.

Figure 5-1: User identity verification flow at the AS

5.7.1.5 Request authorization

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.

5.7.1.6 Event notification throttling

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

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.

NOTE 1: If business communication services are provided to the calling user, and the "phone-context" tel URI parameter contains a value associated with a private numbers, it is expected that any needed translation of the number information is handled by the corresponding business communication AS.

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.

NOTE 2: Operator must ensure that service setting dialling strings do not reach local numbering AS by setting appropriately the precedences of the initial filter criteria.

5.7.1.7.2 Translation of the numbers in a non-international format

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:

a) corresponds to a home local service number that can be used by a roaming user;

b) is used to access a service in the visited network; or

c) 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:

NOTE 1: During the translation the AS can contact an entity in the visited access network for getting the needed information. The protocol and procedures for this is outside the scope of this specification.

NOTE 2: The AS can translate the tel URI to a SIP URI by including the ‘telephone-subscriber’ part of the received tel URI to the user part of the SIP URI and setting the domain name of the SIP URI to indicate the domain name of the network of the phone number based on the received "phone-context" tel URI parameter.

NOTE 3: In addition to the service numbers corresponding to a service in the visited network the home network can also support service numbers corresponding to services in the home network as geo-local service numbers.

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:

NOTE 4: The AS can translate the tel URI to a SIP URI by including the ‘telephone-subscriber’ part of the received tel URI to the user part of the SIP URI and setting the domain name of the SIP URI to indicate the domain name of the network of the phone number based on the received "phone-context" tel URI parameter;

NOTE 5: If business communication services are provided to the calling user, and the "phone-context" tel URI parameter contains a value associated with a private numbers, it is expected that any needed translation of the number information is handled by the corresponding business communication AS.

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.

5.7.1.8 GRUU assignment and usage

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 [28] and RFC 7647 [231], 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 [93] 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.

NOTE 1: If the AS wishes to have terminating services applied when the public user identity on whose behalf the AS is acting is unregistered, then the options available to the AS depend on whether or not the subscriber has ever previously registered with the IM CN subsystem. In the case where the public user identity had previously registered with the IM CN subsystem, then the AS can use the most recently allocated public GRUU if available. In the case where the user has never registered with the IM CN subsystem, then the AS can use the public user identity itself.

NOTE 2: Once terminating services have been applied, it is assumed that the terminating S-CSCF will route the request back to this AS via the initial filter criteria. In order for this to work, the initial filter criteria of the target user need to be configured so that the AS is invoked at the appropriate time relative to other terminating ASs (say, after the required terminating services have been applied). The mechanism to ensure that the AS is invoked by the initial filter criteria at the appropriate time is outside the scope of this specification (e.g. the user’s filter criteria could be statically configured to invoke the AS at the correct time, or the AS could use the Dynamic Service Activation Information mechanism to activate the appropriate filter criteria).

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.

5.7.1.9 Use of ICSI and IARI values

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

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:

– an ICSI value (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3841 [56B]; and

– one or more IARI values (coded as specified in subclause 7.2A.9.2) that are related to the request in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3841 [56B];

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:

– in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 one or more ICSI values (coded as specified in subclause 7.2A.8.2); and

– one or more IARI values (coded as specified in subclause 7.2A.9.2) in a g.3gpp.iari-ref media feature tag, for the IMS applications, that are related to the request as defined in subclause 7.9.2 and RFC 3840 [62];

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 [190]. The parameter value is set according to subclause 7.9A.2.

NOTE 3: The AS can insert the Feature-Caps header field e.g. based on operator policy, IMS communication service specification or depending whether other AS already inserted the Feature-Caps header field with the "+g.3gpp.icsi-ref" header field parameter in the response.

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.

NOTE 4: The AS can insert the Feature-Caps header field e.g. based on operator policy, IMS communication service specification or depending whether other AS already inserted the Feature-Caps header field with the "+g.3gpp.icsi-ref" header field parameter in the request.

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.

5.7.1.10 Carrier selection

An AS may play a role in support of carrier selection as defined in RFC 4694 [112].

NOTE 1: In general, ASs do not need to support carrier selection, Rather a specific AS or a few ASs in a network will be used for carrier selection,

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

NOTE 2: For example, the AS that supports preferred carrier could insert a "cic" tel-URI parameter that identifies the originating user’s preassigned carrier, or the carrier assigned to a called freephone number.

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 [103]), 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.

NOTE 3: This specification does not make any assumptions regarding how these procedures are mapped to ASs; whether all procedures are supported by a single AS or spread across multiple ASs. However, this specification does assume that the responsibility for ensuring that the UE complies with the carrier selection procedures defined in RFC 4694 [112] will be performed by a single AS (e.g. validate "cic"), and the filter criteria will be configured so that this AS is invoked before other ASs that have carrier selection responsibilities.

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.

5.7.1.11 Tracing

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 3GPP TS 24.323 [8K] but need not structure them as a management object.

5.7.1.12 Delivery of original destination identity

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

NOTE: If the "mp" header field parameter is present in the hi-entries within the History-Info header field, the information of the original destination number or URI, e.g. the service number for freephone, will be found in the hi-entry whose index-val matches the value of the first hi-entry with "mp" header field parameter.

5.7.1.13 CPC and OLI

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

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

NOTE 1: How the above is determined is outside the scope of this document and will depend on the application supported. Possible mechanisms could be: 1) that the AS only receives requests that are from non-roaming UEs; 2) analysis of the P-Access-Network-Info header field in a received request from the UE.

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 [69]. 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;

NOTE 2: If the AS is not already aware of the GRUU of the UE due to previously receiving it in a Contact header, and the UE is registered, the GRUU can be obtained using either the subscription to the reg events package or using the third-party registration procedure with the REGISTER request including a "message/sip" MIME body of the 200 (OK) response for the REGISTER request as described in subclause 5.7.1.1.

6) if a location is available at the AS in any form, include a Geolocation header field with that location;

7) a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17];

8) if the AS supports calling number verification using signature verification and attestation information as specified in subclause 3.1 and if required by operator policy, the AS shall perform attestation of the user identity by inserting:

– a "verstat" tel URI parameter, specified in subclause 7.2A.20, to the tel URI or SIP URI with a user=phone parameter in the From header field or the P-Asserted-Identity header field;

– an Attestation-Info header field, specified in subclause 7.2.18; and

an Origination-Id header field, specified in subclause 7.2.19, set to a UUID identifying the AS which is configured based on local policy and requirements from national regulation; and

9) if the AS supports priority verification using assertion of priority information as specified in subclause 3.1 and if required by operator policy, the AS shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197].

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.

5.7.1.15 Protecting against attacks using 3xx responses

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.

NOTE: Automatically recursing on untrusted 3xx responses opens up the UE to being redirected to premium rate URIs without the user’s consent. An AS that protects against attacks using 3xx responses needs to ensure that it doesn’t break services that depend on 3xx responses being passed to the UE. Subclause 5.1.2A.1.1 specifies how a UE protects itself against attacks using 3xx responses. For some services an AS could automatically recurse on a 3xx response.

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

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.

NOTE: An AS that determines that loopback is not a viable option can change or remove any of the above parameters if required by the application logic performed by the AS.

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.

NOTE: If the original dialog identifier sent by the S-CSCF is not preserved by the AS in the outgoing requests, then loopback routeing will not occur.

5.7.1.17 Delivery of network provided location information

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

NOTE: ETSI ES 283 035 [98] Release 3 enables querying a CLF using the User-Data-Request command in which the Global-Access-Id AVP contains the 3GPP-User-Location-Info AVP with a CGI or a SAI value to get a corresponding Geographical Identifier. If multiple CLFs are deployed, the AS can dertermine which CLF to query based on the CGI or the SAI values or can use a DIAMETER proxy if deployed.

5.7.1.18 Delivery of MRB address information

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

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 [28] and with RFC 7200 [201]. When subscribing to the load-control event, the AS shall:

1) Send a SUBSCRIBE request in accordance with RFC 6665 [28] and with RFC 7200 [201] 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 [28].

5.7.1.19.2 Incoming subscriptions to load-control event

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 [28] and with RFC 7200 [201]. 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:

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

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

5.7.1.20 Procedures in the AS for resource sharing

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.

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.

NOTE 1: An AS can learn that a P-CSCF supports resource sharing from the Resource-Share header field with the value "supported" in the initial REGISTER request that is contained in the "message/sip" MIME body of the third-party REGISTER request received when the UE registered.

NOTE 2: The conditions for resource sharing are outside the scope of the present document.

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:

a) the AS shall set the "origin" header field parameter to "session-initiator"; and

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

5.7.1.20.3 UE-terminating case

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.

NOTE 2: The condition for resource sharing is outside the scope of the present document.

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:

a) the AS shall set the "origin" header field parameter to "session-receiver";

b) the AS shall include a new sharing key part that is determined as follows:

A) if the AS is aware of only one registered contact:

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

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

B) if the AS is aware of more than one registered contacts:

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

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

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

5.7.1.20.3.2 Determine resource sharing using the initial SDP answer

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.

NOTE 1: An AS can learn that a P-CSCF supports resource sharing from the Resource-Share header field with the value "supported" in the initial REGISTER request when that is contained in the "message/sip" MIME body of the third-party REGISTER request received the UE registered.

NOTE 2: The condition for resource sharing is outside the scope of this technical specification.

If the AS:

a) the "origin" header field parameter shall be set to "session-receiver"; and

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

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.

NOTE: If more than one dialog exists and the update is sent before the session invitation is accepted by the terminating user, the resource sharing options are determined per individual dialog.

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.

NOTE: A typical example when this can happen is the communication waiting use case. If the UE sends a 200 (OK) response to the INVITE request without putting the first call on hold, the UE’s behaviour is then regarded as unpredictable and resource sharing cannot be used towards that UE.

5.7.1.21 Dynamic Service Interaction

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.

Editor’s Note: [WI:IMSProtoc7, CR#5264]: How the service identies are defined is for further study.

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.

5.7.1.22 Service access number translation

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 [68], set to the value "380" defined in RFC 8119 [230]; and

2) the History-Info header field constructed according to RFC 7044 [66] 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 [68], set to the value "380" defined in RFC 8119 [230].

A service access number does not constrain the number format. A local service number as defined in TS 23.228 [7] and described in subclause 5.7.1.7 can be a service access number.

5.7.1.23 Procedures in the AS for priority sharing

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.

NOTE: The MCPTT server is the only AS in the present document defined to use priority sharing (see 3GPP TS 24.379 [8ZE]).

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.

NOTE: The AS can enable or disable priority sharing by including the Priority-Share header field with the value "allowed" or "not-allowed" as specified above until the session is released.

5.7.1.23.3 Session terminating procedures

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.

NOTE: The AS can enable or disable priority sharing by including the Priority-Share header field with the value "allowed" or "not-allowed" as specified above until the session is released.

5.7.1.24 Handling re-INVITE request collisions

An AS shall handle re-INVITE request collisions as specified in RFC 3261 [26] 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.

5.7.1.25 Assertion verification using the Identity header field

5.7.1.25.1 General

RFC 8224 [252] 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.

RFC 8946 [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.

RFC 8443 [279] describes a mechanism where an authentication service after verifying the Resource-Priority header field inserts a signature over the Resource-Priority header field. A verification service can then use this signature to trust the correctness of the Resource-Priority header field.

RFC 9027 [278] extends a mechanism defined in RFC 8443 [279] to enable authentication of the header field value "psap-callback" of the Priority header field and inserts a signature over the Resource-Priority header field and the header field value "psap-callback" provided in the Priority header field. A verification service can then use this signature to trust the correctness of the Resource-Priority header field and header field value "psap-callback" of the Priority header field.

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 [252] 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

NOTE 1: This option is kept from the original release-14 functionality. If the AS knows the IBCF supports invoking an AS for providing an Identity header field the below actions are more efficient.

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.

If the AS supports priority verification using assertion of priority information as specified in subclause 3.1 and if allowed by local operator policy, the AS may insert an Identity header field as described in RFC 8443 [279] and RFC 9027 [278], and shall for this purpose use the resource priority of the Resource-Priority header field in the received initial INVITE or re-INVITE request.

NOTE 2: For sessions terminating in another domain, only one of the following entities needs to be configured to provide an Identity header field for the resource priority: the IBCF or the AS. Which functional entity inserts the Identity header field is subject to network configuration and local policy.

NOTE 3: How the AS asserts the authenticity of the Resource-Priority header field value is out of scope of the present document.

5.7.1.25.3 Terminating procedures

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 [261] and based on local policy all Identity header fields containing a PASSporT div JSON Web Token, specified in RFC 8946 [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".

If the AS supports priority verification using assertion of priority information as specified in subclause 3.1 and if allowed by local operator policy, the AS may verify that the Priority and Resource-Priority header field values are authorized. To do so, the AS:

verifies the Identity header fields containing a PASSporT rph JSON Web Token as specified in RFC 8443 [279] and RFC 9027 [278] if included in the initial INVITE or re-INVITE request; and
verifies that the Priority and Resource-Priority header field values are authorized by valid "rph" PASSporT claims.

The AS shall populate the Priority-Verstat header field associated with the Resource-Priority header field and include the Priority-Verstat header field in the forwarded SIP request.

The AS may report any verification failure of an Identity header field to the appropriate upstream signing service by populating for each reported Identity header field verification error a Reason header field in the next provisional or final response to the INVITE or MESSAGE request, where the Reason header field "protocol" value is set to "STIR", as specified in draft-ietf-stir-identity-header-errors-handling [294] and draft-ietf-sipcore-multiple-reasons [296], and the "cause" header field parameter contains the 4xx response code of the failing PASSporT, as defined in RFC 8224 [252]. Additionally, the AS may include the "ppi" header field parameter containing the failing PASSporT.

NOTE 1: For sessions originating in another domain, only one of the following entities needs to be configured to verify the Identity header field for the resource priority: the IBCF or the AS. Which functional entity inserts the Identity header field verification is subject to network configuration and local policy.

NOTE 2: Multiple Reason header fields with the protocol value set to "STIR" are not supported in the present document.

5.7.1.25.4 Procedures over the Ms reference point

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

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,the EHPLMN or the subscribed SNPN, or the service the AS support is not configured as a 3GPP PS data off exempt service to be used in the VPLMN or the non-subscribed SNPN;

the AS shall not send the request to the UE via GPRS IP-CAN, EPS IP-CAN or 5GS IP-CAN.

5.7.1.27 AS support for in-call access update procedures

5.7.1.27.1 General

The AS can indicate that it supports in-call access update procedures by sending a feature-capability indicator including a public service identity indicating to where to send the updates.

When the AS receives a MESSAGE request with a P-Charging-Vector header field containing an "icid-value" header field parameter matching the "icid-value" header field parameter of an existing dialog, the AS can use the location information in the received MESSAGE request to update the location information for the dialog identified by the Call-Id.

5.7.1.27.2 Originating procedures

If the AS supports in-call access update procedures and the AS is interested in receiving updates of changes of IP-CAN or PLMN the AS shall include in responses to an initial INVITE request a g.3gpp.in-call-access-update feature-capability indicator with a value set to a public service identity resolving to the AS.

5.7.1.27.3 Terminating procedures

If the AS supports in-call access update procedures and the AS is interested in receiving updates of changes of IP-CAN or PLMN the AS shall include in the INVITE request a g.3gpp.in-call-access-update feature-capability indicator with a value set to a public service identity resolving to the AS.

5.7.2 Application Server (AS) acting as terminating UA, or redirect server

When acting as a terminating UA the AS shall behave as defined for a UE in subclause 5.1.4, with the exceptions identified in this subclause.

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem.

If the AS requires knowledge of the served user it shall determine the served user according to the applicable procedure in subclause 5.7.1.3A.

An AS acting as redirect server shall propagate any received IM CN subsystem XML message body in the redirected message.

When an AS acting as a terminating UA generates a subsequent request for a dialog, the AS shall insert a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter.

When the AS acting as terminating UA receives a request, the AS shall store the value of the "orig-ioi" header field parameters received in the P-Charging-Vector header field if present.

NOTE 1: Any received orig-ioi parameter will be a type 3 orig-ioi. The orig-ioi identifies the network operator from which the request was sent.

When the AS acting as terminating UA generates a response to a request, the AS shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter 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.

The AS acting as terminating UA receiving an initial request with a P-Charging-Vector header field shall, based on local policy, store the "fe-identifier" header field parameter of the P-Charging-Vector header field.

The AS acting as terminating UA shall, based on local policy, include the stored "fe-identifier" header field parameter in the P-Charging-Vector header field, add its address or identifier and application id to the "as-addr" and "as-id" elements of the "fe-identifier" header field parameter of the P-Charging-Vector header field and send the P-Charging-Vector header field in the related final response.

NOTE 2: An AS hosting multiple applications can add multiple pairs of "as-addr" and "as-id" header field parameters when executing these applications.

If resource priority in accordance with RFC 4412 [116] is required for a dialog, then the AS shall include the Resource-Priority header field in all requests associated with that dialog. If priority is supported, the AS shall take into account that subsequent received SIP requests or responses within the same dialog or transaction may have added or changed the Resource-Priority header field or backwards indication.

NOTE 3: An AS can modify the priority using the Resource-Priority header field in a dialog on behalf of a user. The mechanism for a user to invoke this AS action is out of scope of this release of the specification.

5.7.3 Application Server (AS) acting as originating UA

In order to support an AS acting as an originating UA, the AS has to be within the same trust domain as the S-CSCF to which requests will be sent.

When acting as an originating UA the AS shall behave as defined for a UE in subclause 5.1.3, with the exceptions identified in this subclause.

The AS, although acting as a UA, does not initiate any registration of its associated addresses and does not participate in any authentication procedures defined for a UE. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem.

When an AS acting as an originating UA generates an initial request for a dialog or a request for a standalone transaction, the AS shall insert a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17] and a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter.

NOTE 1: The AS can retrieve CDF and/or ODF addresses from HSS on Sh interface.

When the AS acting as an originating UA receives any response to a request, the AS shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field if present.

NOTE 2: Any received "term-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the network operator from which the response was sent.

When an AS acting as an originating UA generates a subsequent request for a dialog, the AS shall insert a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter.

Based on local policy, the AS acting as an originating UA or application(s) hosted by the AS acting as originating UA shall add an "as-addr" and an "as-id" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier and application identifier to an initial request.

NOTE 3: An AS hosting multiple applications can add multiple pairs of "as-addr" and "as-id" header field parameters when executing these applications for an initial request.

The AS shall extract charging function addresses from any P-Charging-Function-Addresses header field that is received in any 1xx or 2xx responses to the requests.

The AS may also indicate that the proxies should not fork the request by including a "no-fork" directive within the Request-Disposition header field in the request as described in RFC 3841 [56B].

When sending any initial request, an identity is needed that will correlate with the service profile to be used at the S-CSCF. If the identity for that service profile corresponds to the value to be used to identify the caller to the destination user, include the identity in the P-Asserted-Identity header field. If the identity for that service profile does not correspond to the value to be used to identify the caller to the destination user, and the P-Served-User header field is supported by the S-CSCF, include the identity in the P-Served-User header field. This leaves the P-Asserted-Identity header field for the identity to be used to identify the caller to the destination user. If the identity for that service profile matches a wildcarded identity and the P-Profile-Key header field is supported by the AS, include the wildcarded identity in the P-Profile-Key header field.

When sending an initial request on behalf of a PSI that is hosted by the AS, the AS shall:

– insert a Request-URI as determined by the service logic;

– insert a P-Asserted-Identity header field and possibly a P-Served-User header field containing the PSI as indicated earlier in this subclause;

– if the AS is not able to resolve the next hop address by itself or the operator policy does not allow it, insert a Route header field pointing either to the S-CSCF where the PSI is hosted, or to the entry point of the home network of the PSI or to the transit function. The AS shall append the "orig" parameter to the URI in the topmost Route header field; and

NOTE 4: The address of the S-CSCF hosting the PSI can be obtained by querying the HSS on the Sh interface.

NOTE 5: AS can only send the initial request to the entry point of the home network of the PSI only if the AS can assume (e.g. based on local configuration) that the receiving entry point will be able to process the request as an originating request.

– if the AS is able to resolve the next hop address by itself and the operator policy allows it, forward the originating request directly to the destination without involving any S‑CSCF in the originating IM CN subsystem.

When sending an initial request on behalf of a public user identity, the AS shall:

– insert a Request-URI as determined by the service logic;

– insert a P-Asserted-Identity header field and possibly a P-Served-User header field containing the public user identity as indicated earlier in this subclause;

– if the AS intends to send the originating request to the home network of the public user identity or the operator policy requires it, insert a Route header field pointing to the S-CSCF where the public user identity on whose behalf the request is generated is registered or hosted (unregistered case) or to the entry point of the public user identity’s network. The AS shall append the "orig" parameter to the URI in the topmost Route header field; and

NOTE 6: The address of the S-CSCF can be obtained either by querying the HSS on the Sh interface or during third-party registration.

NOTE 7: AS can send the initial request to the entry point of the public user identity’s network or to the entry point of the home network of the PSI only if the AS can assume (e.g. based on local configuration) that the receiving entry point will be able to process the request as an originating request.

– if the AS intends to send the originating request directly to the terminating network and the operator policy allows it, forward the originating request directly to the destination without involving any S‑CSCF in the originating IM CN subsystem.

When sending an initial request to a served public user identity, the AS shall insert:

– a Request-URI containing the served public user identity;

– a P-Asserted-Identity as determined by the service logic (e.g. the URI of the AS or the URI of the entity that triggered the SIP request, if the sending of the initial request is triggered by a non-SIP request); and

– a Route header field pointing to the S-CSCF where the public user identity to whom the request is generated is registered or hosted (unregistered case) or to the entry point of the public user identity’s network. The AS shall not append the "orig" parameter to the URI in the topmost Route header field.

NOTE 8: The address of the S-CSCF can be obtained either by querying the HSS on the Sh interface or during third-party registration.

The AS can indicate privacy of the P-Asserted-Identity in accordance with RFC 3323 [33], and the additional requirements contained within RFC 3325 [34].

Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the AS shall set a display-name of the From header field to "Anonymous" as specified in RFC 3261 [26] and set an addr-spec of the From header field to Anonymous User Identity as specified in 3GPP TS 23.003 [3].

NOTE 9: The contents of the From header field cannot be relied upon to be modified by the network based on any privacy specified by the user either within the AS indication of privacy or by network subscription or network policy. Therefore the AS includes the value "Anonymous" whenever privacy is explicitly required.

NOTE 10: An AS can modify the priority using the Resource-Priority header field in a dialog on behalf of a user. The mechanism for a user to invoke this AS action is out of scope of this release of the specification.

5.7.4 Application Server (AS) acting as a SIP proxy

When the AS acting as a SIP proxy receives a request from the S-CSCF, prior to forwarding the request, the AS shall:

– remove its own URI from the topmost Route header field;

– if the request contains a "logme" header field parameter in the SIP Session-ID header field then log the request if required by local policy; and

– after executing the required services, route the request based on the topmost Route header field.

When the AS acting as a SIP proxy receives any response to the above request, the AS shall:

– if the response contains a "logme" header field parameter in the SIP Session-ID header field then log the request if required by local policy.

The AS may modify the SIP requests based on service logic, prior to forwarding the request back to the S-CSCF.

The AS shall not fork the request if the fork-directive in the Request-Disposition header field is set to "no-fork" as described in RFC 3841 [56B].

If the AS requires knowledge of the served user it shall determine the served user according to the applicable procedure in subclause 5.7.1.3A.

An AS acting as a SIP proxy shall propagate any received IM CN subsystem XML message body in the forwarded message.

When the AS acting as a SIP proxy receives a request, the AS shall store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present. The AS shall remove the "orig-ioi" header field parameter from the forwarded request and insert a type 3 "orig-ioi" header field parameter. The AS shall set the type 3 "orig-ioi" header field parameter to a value that identifies the service provider from which the request is sent. The AS shall not include the type 3 "term-ioi" header field parameter.

NOTE 1: A received orig-ioi parameter will be a type 3 orig-ioi. The orig-ioi identifies the network operator from which the request was sent.

When the AS acting as a SIP proxy forwards a response to a request, the AS shall remove any received "orig-ioi" and "term-ioi" header field parameters, and insert a P-Charging-Vector header field containing the previously stored "orig-ioi" header field parameter, if received in the request and a type 3 "term-ioi" 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 and the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter. Any values of "orig-ioi" or "term-ioi" header field parameters received in any response that is being forwarded are not used.

Based on local policy, the AS acting as a SIP proxy shall add an "as-addr" and an "as-id" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier and application identifier.

NOTE 2: An AS hosting multiple applications can add multiple pairs of "as-addr" and "as-id" header field parameters when executing these applications for an initial request.

5.7.5 Application Server (AS) performing 3rd party call control

5.7.5.1 General

The AS performing 3rd party call control acts as a B2BUA. There are two kinds of 3rd party call control:

– Routeing B2BUA: an AS receives a request, terminates it and generates a new request, which is based on the received request.

– Initiating B2BUA: an AS initiates two requests, which are logically connected together at the AS, or an AS receives a request and initiates a new request that is logically connected but unrelated to the incoming request from the originating user (e.g. the P-Asserted-Identity of the incoming request is changed by the AS). AS can initiate additional requests and associate them with a related incoming request.

When the AS acting as an initiating B2BUA receives a request and initiates a new request that is logically connected but unrelated to the incoming request from the originating user, the AS can include an original dialog identifier in the Route header field for the S-CSCF that it learned from the incoming request, per service logic needs.

NOTE 1: If the AS does not include the original dialog identifier in an initiated request, the S-CSCF can apply the default handling procedure relating to the incoming request if after a certain time no 1xx response is sent by the AS to the incoming request or if the AS forwards a 408 (Request Timeout) response or a 5xx response received from downstream as a response to the incoming request. To avoid the application of the default handling procedure by the S-CSCF when the AS is waiting for a SIP response for an initiated request, the AS can generate a SIP provisional response to the incoming request.

If the AS requires knowledge of the served user the AS shall determine the served user according to the applicable procedure in subclause 5.7.1.3A.

When the AS receives a terminated call and generates a new call, and dependent on whether the service allows the AS to change the P-Asserted-Identity for outgoing requests compared with the incoming request, the AS will select appropriate kind of 3rd party call control.

The B2BUA AS will internally map the message header fields between the two dialogs that it manages. It is responsible for correlating the dialog identifiers and will decide when to simply translate a message from one dialog to the other, or when to perform other functions. These decisions are specific to each AS and are outside the scope of the present document.

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem.

For standalone transactions, when the AS is acting as a Routeing B2BUA, the AS shall copy the remaining Route header field(s) unchanged from the received request for a standalone transaction to the new request for a standalone transaction.

When the AS receives a Replaces header field within an initial request for a dialog, the AS should check, whether the AS acts as a routeing B2BUA for the dialog identified in the Replaces header field. The AS should:

– if the AS acts as routeing B2BUA for the dialog indicated in the Replaces header field, include in the forwarded request a Replaces header field, indicating the dialog on the outgoing side that corresponds to the dialog identified in the received Replaces header field; or

– if the AS does not act as a routeing B2BUA for the dialog indicated in the Replaces header field, include in the forwarded request the Replaces header field as received in the incoming request.

When the AS receives a Target-Dialog header field within an initial request or a standalone transaction for a dialog, the AS shall:

– if the AS acts as routeing B2BUA for the dialog indicated in the Target-Dialog header field, include in the forwarded request a Target-Dialog header field, indicating the dialog on the outgoing side that corresponds to the dialog identified in the received Target-Dialog header field.

When the AS acting as a routeing B2BUA receives a request, the AS shall:

– store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present; and

– remove the "orig-ioi" header field parameter from the forwarded request.

NOTE 2: Any received orig-ioi parameter will be a type 3 orig-ioi. The orig-ioi identifies the network operator from which the request was sent.

When an AS acts as a routeing B2BUA and the received Contact header field contains a media feature tag indicating a capability for which the Contact URI can be used by the remote party, the AS shall transparently forward the Contact header field. 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.

NOTE 3: One example of such a media feature tag is the isfocus media feature tag where the URI in the Contact header field is used by conference services to transport the temporary conference identity that can be used when rejoining an ongoing conference.

When the AS acting as a routeing B2BUA generates a response to a request, the AS shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter 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. Any values of "orig-ioi" or "term-ioi" header field parameter received in any response that is being forwarded are not used.

The AS shall transparently pass supported and unsupported signalling elements (e.g. SIP headers, SIP messages bodies), except signalling elements that are modified or deleted as part of the hosted service logic, or based on service provider policy.

The AS shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field if required by local policy.

5.7.5.2 Call initiation

5.7.5.2.1 Initial INVITE

When the AS acting as a Routeing B2BUA receives an initial INVITE request, the AS shall:

1) remove its own SIP URI from the topmost Route header field of the received INVITE request;

2) perform the AS specific functions. See 3GPP TS 23.218 [5];

3) if successful, generate and send a new INVITE request to establish a new dialog;

4) copy the remaining Route header field(s) unchanged from the received INVITE request to the new INVITE request;

5) copy the P-Asserted-Identity to the outgoing request;

6) if a Route header field is present, route the new INVITE request based on the topmost Route header field; and

NOTE 1: The topmost Route header field of the received INVITE request will contain the AS’s SIP URI. The following Route header field will contain the SIP URI of the S-CSCF.

7) if no Route header field is present (e.g. the AS may be acting on behalf of a PSI):

a) insert a Route header field pointing either to the S-CSCF where the PSI is hosted or to the entry point of the home network of the PSI or to the transit function, if the AS is not able to resolve the next hop address by itself or the operator policy requires it; or

b) forward the originating request directly to the destination without involving any S‑CSCF in the originating IM CN subsystem, if the AS is able to resolve the next hop address by itself, and the operator policy allows it.

NOTE 2: The address of the S-CSCF hosting the PSI can be obtained by querying the HSS on the Sh interface.

When the AS is acting as an Initiating B2BUA, the AS shall apply the procedures described in subclause 5.7.3 for any outgoing requests. The AS shall either set the "icid-value" header field parameter in the P-Charging-Vector header field to be the same as received or different.

NOTE 3: The AS can retrieve CDF and/or ODF adresses from HSS on Sh interface.

5.7.5.2.2 Subsequent requests

If the policy or service logic requires the AS to check whether the session is still alive, the AS shall send UPDATE requests periodically to the served UE. The UPDATE requests shall not contain SDP offer.

NOTE: The exact timing of sending the UPDATE requests is out of scope of this specification. Sending UPDATE requests too frequently can increase the load on the network and increase the probability of interactions delaying urgent requests (e.g., those related to session transfers). RFC 4028 [58] provides additional information on the problems caused by sending too frequest SIP "keep alives" and provides recommendations on suitable timer values to avoid such issues.

5.7.5.3 Call release

An AS may initiate a call release. See 3GPP TS 23.218 [5] for possible reasons. The AS shall simultaneously send the BYE request for both dialogs managed by the B2BUA.

5.7.5.4 Call-related requests

Void.

5.7.5.5 Further initial requests

When the AS is acting as an Initiating B2BUA the AS shall apply the procedures described in subclause 5.7.3 for the requests. The AS shall either set the "icid-value" header field parameter in the P-Charging-Vector header field to be the same as received or different. The AS may initiate any number of requests, per service logic needs.

5.7.5.6 Transcoding services invocation using third-party call control

An AS may invoke transcoding at an MRFC by the use of RFC 4117 [166], if the MRFC supports acting as the transcoding server described in RFC 4117 [166].

During the call setup, an AS may decide proactively to invoke transcoding when receiving an INVITE request, or reactively when the callee rejects the call setup using a 488 (Not Acceptable Here) response. To invoke transcoding using RFC 4117 [166], the AS shall act as a B2BUA between caller and callee and establish a third SIP dialogue towards the MRFC, supporting the transcoding as defined in subclause 6.6.

The SIP messages relating to the dialogue between AS and MRFC are sent either via the S-CSCF over the ISC and Mr interfaces, or directly over the Mr’ interface.

5.7.1 Common Application Server (AS) procedures

5.7.1.0 General

5.7.1.1 Notification about registration status

5.7.1.2 Extracting charging correlation information

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

5.7.1.3A Determination of the served user

5.7.1.3A.1 General

5.7.1.3A.2 AS serving an originating user

5.7.1.3A.3 AS serving a terminating user

5.7.1.3B Determination of the used registration

5.7.1.4 User identity verification at the AS

5.7.1.5 Request authorization

5.7.1.6 Event notification throttling

5.7.1.7 Local numbering

5.7.1.7.1 Interpretation of the numbers in a non-international format

5.7.1.7.2 Translation of the numbers in a non-international format

5.7.1.8 GRUU assignment and usage

5.7.1.9 Use of ICSI and IARI values

5.7.1.10 Carrier selection

5.7.1.11 Tracing

5.7.1.12 Delivery of original destination identity

5.7.1.13 CPC and OLI

5.7.1.14 Emergency transactions

5.7.1.15 Protecting against attacks using 3xx responses

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

5.7.1.16.1 Preservation of parameters

5.7.1.16.2 Preference for loopback routeing not to occur

5.7.1.17 Delivery of network provided location information

5.7.1.18 Delivery of MRB address information

5.7.1.19 Overload control

5.7.1.19.1 Outgoing subscriptions to load-control event

5.7.1.19.2 Incoming subscriptions to load-control event

5.7.1.20 Procedures in the AS for resource sharing

5.7.1.20.1 General

5.7.1.20.2 UE-originating case

5.7.1.20.3 UE-terminating case

5.7.1.20.3.1 Determine resource sharing using the initial SDP offer

5.7.1.20.3.2 Determine resource sharing using the initial SDP answer

5.7.1.20.4 Updating the resource sharing options

5.7.1.20.5 Abnormal cases

5.7.1.21 Dynamic Service Interaction

5.7.1.22 Service access number translation

5.7.1.23 Procedures in the AS for priority sharing

5.7.1.23.1 General

5.7.1.23.2 Session originating procedures

5.7.1.23.3 Session terminating procedures

5.7.1.24 Handling re-INVITE request collisions

5.7.1.25 Assertion verification using the Identity header field

5.7.1.25.1 General

5.7.1.25.2 Originating procedures

5.7.1.25.3 Terminating procedures

5.7.1.25.4 Procedures over the Ms reference point

5.7.1.26 Procedures in the AS for 3GPP PS data off

5.7.1.27 AS support for in-call access update procedures

5.7.1.27.1 General

5.7.1.27.2 Originating procedures

5.7.1.27.3 Terminating procedures

5.7.2 Application Server (AS) acting as terminating UA, or redirect server

5.7.3 Application Server (AS) acting as originating UA

5.7.4 Application Server (AS) acting as a SIP proxy

5.7.5 Application Server (AS) performing 3rd party call control

5.7.5.1 General

5.7.5.2 Call initiation

5.7.5.2.1 Initial INVITE

5.7.5.2.2 Subsequent requests

5.7.5.3 Call release

5.7.5.4 Call-related requests

5.7.5.5 Further initial requests

5.7.5.6 Transcoding services invocation using third-party call control

5.7.6 Void