Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  18.5.0

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

 

5.7.2  Application Server (AS) acting as terminating UA, or redirect serverp. 333

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.
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.
If resource priority in accordance with RFC 4412 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.
Up

5.7.3  Application Server (AS) acting as originating UAp. 334

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 TS 32.260 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 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.
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.
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.
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
  • 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
  • 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.
The AS can indicate privacy of the P-Asserted-Identity in accordance with RFC 3323, and the additional requirements contained within RFC 3325.
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 and set an addr-spec of the From header field to Anonymous User Identity as specified in TS 23.003.
If resource priority in accordance with RFC 4412 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.
Up

5.7.4  Application Server (AS) acting as a SIP proxyp. 336

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

5.7.5  Application Server (AS) performing 3rd party call controlp. 337

5.7.5.1  Generalp. 337

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.
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.
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.
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.
If resource priority in accordance with RFC 4412 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.
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.
Up

5.7.5.2  Call initiationp. 338

5.7.5.2.1  Initial INVITEp. 338
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 TS 23.218;
  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
  7. if no Route header field is present (e.g. the AS may be acting on behalf of a PSI):
    1. 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
    2. 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.
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.
Up
5.7.5.2.2  Subsequent requestsp. 339
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.
Up

5.7.5.3  Call releasep. 339

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

5.7.5.4  Call-related requestsp. 339

Void.

5.7.5.5  Further initial requestsp. 339

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 |R9|p. 339

An AS may invoke transcoding at an MRFC by the use of RFC 4117, if the MRFC supports acting as the transcoding server described in RFC 4117.
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, 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.
Up

5.7.6Void


Up   Top   ToC