Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

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

 

4.5  Charging correlation principles for IM CN subsystems

4.5.1  Overview

This subclause describes charging correlation principles to aid with the readability of charging related procedures in clause 5. See TS 32.240 and TS 32.260 for further information on charging.
The IM CN subsystem generates and retrieves the following charging correlation information for later use with offline and online charging:
  1. IM CN subsystem Charging Identifier (ICID);
  2. Access network charging information;
  3. Inter Operator Identifier (IOI);
  4. Charging function addresses:
    1. Charging Data Function (CDF);
    2. Online Charging Function (OCF);
  5. IM CN subsystem Functional Entity Identifier.
How to use and where to generate the parameters in IM CN subsystems are described further in the subclauses that follow. The charging correlation information is encoded in the P-Charging-Vector header field as defined in subclause 7.2A.5 and in RFC 7315. The P-Charging-Vector header field contains the following header field parameters: "icid-value", "icid-generated-at", "related-icid", "related-icid-generated-at", "access-network-charging-info", "orig-ioi", "term-ioi", "transit-ioi" and "fe-identifier".
The offline and online charging function addresses are encoded in the P-Charging-Function-Addresses as defined in RFC 7315. The P-Charging-Function-Addresses header field contains the following header field parameters: "ccf" for CDF and "ecf" for OCF.
Up

4.5.2  IM CN subsystem charging identifier (ICID)Word‑p. 82
The ICID is the session level data shared among the IM CN subsystem entities including ASs in both the calling and called IM CN subsystems. The ICID is used also for session unrelated messages (e.g. SUBSCRIBE request, NOTIFY request, MESSAGE request) for the correlation with CDRs generated among the IM CN subsystem entities.
The first IM CN subsystem entity involved in a SIP transaction will generate the ICID and include it in the "icid-value" header field parameter of the P-Charging-Vector header field in the SIP request.
For a dialog relating to a session, the generation of the ICID will be performed only on the initial request. This ICID will be used for the initial request and any response to the initial request, and all subsequent SIP messages ina P-Charging-Vector header field.
For all other transactions, generation of the ICID will be performed on each SIP request. This ICID will be used for the SIP request and any response to the SIP request in a P-Charging-Vector header field.
The "icid-value" header field parameter is inserted in the IM CN subsystem, as summarised in table 4-2A.
Inserted in
For initial or standalone SIP message
For subsequent SIP message

Any request
The first IM CN subsystem entity receiving the request inserts the "icid-value" header field parameter populated as specified in TS 32.260.
The first IM CN subsystem entity receiving the request inserts the "icid-value" header field parameter set to the value populated in the initial request for the dialog.
Any response to the request
The first IM CN subsystem entity receiving the response inserts the "icid-value" header field parameter set to the value populated in the initial request for the dialog or the standalone request.
The first IM CN subsystem entity receiving the response inserts the "icid-value" header field parameter set to the value populated in the initial request for the dialog.

See TS 32.260 for requirements on the format of ICID. The P-CSCF will generate an ICID for UE-originated calls. The I-CSCF will generate an ICID for UE-terminated calls if there is no ICID received in the initial request (e.g. the calling party network does not behave as an IM CN subsystem). The AS will generate an ICID when acting as an originating UA. The MGCF will generate an ICID for PSTN/PLMN originated calls. The MSC server will generate an ICID for ICS and SRVCC originated calls. Each entity that processes the SIP request will extract the ICID for possible later use in a CDR. The I-CSCF and S-CSCF are also allowed to generate a new ICID for UE-terminated calls received from another network.
There is also an ICID generated by the P-CSCF with a REGISTER request that is passed in a unique instance of P-Charging-Vector header field. The valid duration of the ICID is specified in TS 32.260.
The "icid-value" header field parameter is included in any request and response that includes the P-Charging-Vector header field. However, the P-Charging-Vector (and ICID) is not passed to the UE.
The ICID is also passed from the P-CSCF to the IP-CAN via PCRF. The interface supporting this operation is outside the scope of this document.
Up

4.5.2A  Related ICID |R11|

During the process of SRVCC access transfer the MSC server or the P-CSCF generates an ICID for the target access leg. For the purpose of charging correlation between the source access leg and the target access leg when the user is roaming the SCC AS and the ATCF includes the ICID used on the source access leg in the "related-icid" header field parameter of the P-Charging-Vector header field returned in 1xx and 2xx responses to the initial INVITE request.
During the process of dual radio access transfer the MSC server or the P-CSCF generates an ICID for the target access leg. For the purpose of charging correlation between the source access leg and the target access leg when the user is roaming the SCC AS includes the ICID used on the source access leg in the "related-icid" header field parameter of the P-Charging-Vector header field returned in 1xx and 2xx responses to the initial INVITE request.
Up

4.5.3  Access network charging informationWord‑p. 83

4.5.3.1  General

The access network charging information are the media flow level data shared among the IM CN subsystem entities for one side of the session (either the calling or called side). GPRS charging information (GGSN identifier and PDP context information) is an example of access network charging information.

4.5.3.2  Access network charging information

The IP-CAN provides the access network charging information to the IM CN subsystem. This information is used to correlate IP-CAN CDRs with IM CN subsystem CDRs, i.e. the access network charging information is used to correlate the bearer level with the session level.
The access network charging information is generated at the first opportunity after the resources are allocated at the IP-CAN. The access network charging information is passed from IP-CAN to P-CSCF via PCRF, over the Rx and Gx interfaces. Access network charging information will be updated with new information during the session as media flows are added or removed. The P-CSCF provides the access network charging information to the S-CSCF. The S-CSCF may also pass the information to an AS, which may be needed for online pre-pay applications. The access network charging information for the originating network is used only within that network, and similarly the access network charging information for the terminating network is used only within that network. Thus the access network charging information are not shared between the calling and called networks. The access network charging information is not passed towards the external ASs from its own network.
The access network charging information is populated in the P-Charging-Vector header field.
The access network charging information can be included in a P-Charging-Vector header field in dialog forming requests, mid-dialog requests, and responses. This is dependant on when updated information is avialable in the P-CSCF.
Up

4.5.4  Inter operator identifier (IOI)

The Inter Operator Identifier (IOI) is a globally unique identifier to share between sending and receiving networks, service providers or content providers.
The sending network populates the "orig-ioi" header field parameter of the P-Charging-Vector header field in a request and thereby identifies the operator network from which the request was sent. The "term-ioi" header field parameter is left out of the P-Charging-Vector header field in this request. The sending network retrieves the "term-ioi" header field parameter from the P-Charging-Vector header field in a response to the request, which identifies the operator network from which the response was sent.
The receiving network retrieves the "orig-ioi" header field parameter from the P-Charging-Vector header field in the request, which identifies the operator network from which the request was sent. The receiving network populates the "term-ioi" header field parameter of the P-Charging-Vector header field in the response to the request, which identifies the operator network from which the response was sent.
The "orig-ioi" and "term-ioi" header field parameters are inserted in the IM CN subsystem, as summarised in table 4-2B.
Inserted in
For initial, standalone or subsequent SIP message

Any request
The IM CN subsystem entity in the sending network:
1) removes any received "orig-ioi" header field parameter, if present;
2) inserts the "orig-ioi" header field parameter to a value that identifies the sending network of the request; and
3) does not insert the "term-ioi" header field parameter.
Any response to the request
The IM CN subsystem entity in the receiving network:
1) removes any received "orig-ioi" and "term-ioi" header field parameters, if present;
2) inserts the "orig-ioi" header field parameter set to the previously received value of "orig-ioi" header field parameter, if received in the request; and
3) inserts the "term-ioi" header field parameter to a value that identifies the receiving network from which the response is sent.

There are three types of IOI:
  1. Type 1 IOI, between the visited network and the home network. This includes the following cases:
    • between the P-CSCF (possibly in the visited network) and the S-CSCF in the home network. This is exchanged in REGISTER requests and responses, and in all session-related and session-unrelated requests and responses;
    • between the SCC AS in the home network and the ATCF (possible in the visited network). This is exchanged in MESSAGE requests and responses;
    • when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs, between the S-CSCF of the home network and the TRF of the visited network or between the BGCF of the home network and the TRF of the visited network. This is exchanged in all session-related requests and responses.
  2. Type 2 IOI, between originating network and the terminating network. This includes the following cases:
    • between the S-CSCF of the home originating network and the S-CSCF of the home terminating network or between the S-CSCF of the home originating network and the MGCF when a call/session is terminated at the PSTN/PLMN;
    • between the MGCF and the S-CSCF of the home terminating network when a call/session is originated from the PSTN/PLMN or with a PSI AS when accessed across I-CSCF; and
    • when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs, between the TRF of the visited network and the S-CSCF of the home terminating network.
      This is exchanged in all session-related and session-unrelated requests and responses.
      Additionally, for emergency transactions, a type 2 IOI is exchanged between the E-CSCF and the MGCF or IBCF where the request is routed to a PSAP. In scenarios where the E-CSCF receives emergency requests from an S-CSCF, a type 2 IOI is exchanged. This can also occur where the E-CSCF receives emergency requests from an IBCF.
  3. Type 3 IOI, between the S-CSCF or I-CSCF of the home operator network and any AS. Type 3 IOI are also used between E-CSCF and LRF, between E-CSCF and EATF, and between transit function and AS. The type 3 IOI is exchanged in all session-related and session-unrelated requests and responses.
Each entity that processes the SIP request will extract the IOI for possible later use in a CDR. The valid duration of the IOI is specified in TS 32.240.
Up

4.5.4A  Transit inter operator identifier (Transit IOI) |R11|Word‑p. 85
The Transit Inter Operator Identifier (Transit IOI) is a globally unique identifier to share between sending, transit and receiving networks, service providers or content providers.
A network sending a request can retrieve the "transit-ioi" header field parameter value(s) from the P-Charging-Vector header field in the response to the sent request, which identify the operator network(s) which the response was transitting.
The transit network(s) populate(s) the "transit-ioi" header field parameter value(s) of the P-Charging-Vector header field in a request and thereby identify(ies) the operator network(s) which the request was transitting. The "transit-ioi" header field parameter is an indexed value that is incremented each time a value is added. When the index is calculated then "void" entries are taken into account.
The transit network(s) populate(s) the "transit-ioi" header field parameter value(s) of the P-Charging-Vector header field in the response to the request and thereby identify(ies) the operator network(s) which the response was transitting. The "transit-ioi" header field parameter is an indexed value that is incremented each time a value is added. When the index is calculated then "void" entries are taken into account.
A network receiving a request can retrieve the "transit-ioi" header field parameter value(s) from the P-Charging-Vector header field in the request, which identify the operator network(s) which the request was transitting.
EXAMPLE:
Transit-IOI in a request when arriving on the terminating side:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; transit-ioi="operatorA.1, void, operatorB.3"
Transit-IOI in the corresponding response when arriving on the originating side:
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.net; transit-ioi="operatorB.1, void, operatorA.3"
The Transit IOI is exchanged between functional entities, as summarised in table 4-3.
Item
Entities adding Transt IOI (NOTE 1)
Entities deleting Transit IOI (NOTE 1)

1
additional routeing functions as defined in Annex I or IBCF (NOTE 2) in the transit network located between the visited network and the home network
S-CSCF of the home network;
P-CSCF of the visited network; or
TRF of the visited originating network when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs
2
additional routeing functions as defined in Annex I or IBCF (NOTE 2) in the transit network located between originating network and the terminating network
S-CSCF of the home terminating network;
S-CSCF of the home originating network;
MGCF when a call/session is terminated at the PSTN/PLMN; or
TRF of the visited originating network when using Roaming Architecture for Voice over IMS with Local Breakout and loopback routeing occurs
3
additional routeing functions as defined in Annex I colocated with MGCF when a call/session was transitting the PSTN/PLMN
S-CSCF of the home terminating network


Each entity that processes the SIP requests and responses may extract the Transit IOI for charging purposes, as described in TS 32.260.
Up

4.5.5  Charging function addressesWord‑p. 86
Charging function addresses are distributed to each of the IM CN subsystem entities in the home network for one side of the session (either the calling or called side) and provide a common location for each entity to send charging information. Charging Data Function (CDF) addresses are used for offline billing. Online Charging Function (OCF) addresses are used for online billing.
There may be multiple addresses for CDF and OCF addresses populated into the P-Charging-Function-Addresses header field of the SIP request or response. The header field parameters are "ccf" and "ecf" for CDF and OCF, respectively. At least one instance of either "ccf" or "ecf" header field paramter is required. If "ccf" header field parameter is included for offline charging, then a secondary "ccf" header field paramter may be included by each network for redundancy purposes, but the first instance of "ccf" header field parameter is the primary address. If ecf address is included for online charging, then a secondary instance may also be included for redundancy.
The CDF and/or OCF addresses are retrieved from an Home Subscriber Server (HSS) via the Cx interface and passed by the S-CSCF to subsequent entities. The charging function addresses are passed from the S-CSCF to the IM CN subsystem entities in its home network, but are not passed to the visited network or the UE. When the P-CSCF is allocated in the visited network, then the charging function addresses are obtained by means outside the scope of this document. The AS receives the charging function addresses from the S-CSCF via the ISC interface. CDF and/or OCF addresses may be allocated as locally preconfigured addresses. The AS can also retrieve the charging function address from the HSS via Sh interface.
Up

4.5.6  Relayed charge parameters |R12|

Where there is a desire to pass charging information to an entity over an interface to which the charging information is not directly related, then the Relayed-Charge header field is used. This is used only in accordance with the capabilities specified in this document, which currently specify only the relay of a transit IOI to an associated AS.

4.5.7  Loopback-indication parameter |R11|

When there is a desire to send the information that loopback has been applied to an entity, then the loopback-indication parameter is used. This parameter can e.g. be evaluated when processing the P-CSCF CDR and possibly the ATCF CDR to know whether or not to attempt to locate a correlated TRF CDR even for the non-loopback scenario when no such CDR exists. It is used only in accordance with the capabilities specified in this document.

4.5.8  IM CN subsystem Functional Entity Identifier |R14|

4.5.8.1  General

Different rules for generating and processing of charging information apply. In order to inform the billing domain which IM CN subsystem functional entities have created charging information, the IM CN subsystem functional entities and ASs include an "fe-identifier" header field parameter as additional information in the P-Charging-Vector header field when generating charging information as specified in TS 32.260.
Up

4.5.8.2  Tracking of IM CN subsystem functional entities generating charging information

Each IM CN subsystem functional entity that generates charging events, includes its own address or specific IM CN subsystem functional entity identifier within the "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field into the initial SIP request to be sent from own domain.
The last element of the operator domain stores the "fe-identifier" header field parameter in the P-Charging-Vector header field and removes the "fe-identifier" header field parameter from the P-Charging-Vector header field.
When receiving the final SIP response sent back to its own domain, the last element of the operator domain deletes, if received, the "fe-identifier" header field parameter from the P-Charging-Vector header field, adds the stored "fe-identifier" and adds its own "fe-addr" to the "fe-identifier".
Up

4.5.8.3  Tracking of applications generating charging informationWord‑p. 87
Each application for which the hosting AS is generating charging events, includes the address or specific identifier of the AS within the "as-addr" element and the application identifier within the "ap-id" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field into the initial SIP request to be sent.
The final SIP response sent back by the last element of the operator domain supporting the "fe-identifier" header field contains the list of addresses and application identifiers received within the initial SIP request.
Up

4.6  Support of local service numbers |R7|

For the IM CN subsystem, the support of local service numbers is provided by an AS in the subscriber's home network as described in subclause 5.7.1.7.

4.7  Emergency service |R7|

4.7.1  Introduction |R10|

The need for support of emergency calls in the IM CN subsystem is determined by national regulatory requirements.

4.7.2  Emergency calls generated by a UE |R10|

If the UE cannot detect the emergency call attempt, the UE initiates the request as per normal procedures as described in subclause 5.1.2A. Depending on network policies, for a non-roaming UE or for a roaming UE where the P-CSCF is in the same network where the UE is roaming an emergency call attempt can succeed even if the UE did not detect that an emergency session is being requested, otherwise the network rejects the request indicating to the UE that the attempt was for an emergency service.
The UE procedures for UE detectable emergency calls are defined in subclause 5.1.6.
The P-CSCF, S-CSCF, IBCF, and E-CSCF procedures for emergency service are described in subclause 5.2.10, 5.4.8, 5.10.3.2 and 5.11, respectively.
Access dependent aspects of emergency service (e.g. whether the access technology defines emergency bearers, emergency registration support and location provision) are defined in the access technology specific annexes for each access technology.
There are a number of variants within these procedures and which variant gets used depends on a number of issues. These conditions are defined more specifically in TS 23.167 and, where appropriate, in the access technology specific annex, but are summarised as follows:
  1. if the UE knows that it is in its own home network, then an existing registration is permitted to be used for signalling the emergency call, except where item c) applies. The access technology specific annexes define the mechanism by which home network determination is made;
  2. if emergency calls are permitted without security credentials (or additionally where the authentication is not possible or has failed), then the emergency call is made directly without use of any security association created by a registration, and therefore without the registration; and
  3. where the access technology defines emergency bearers for the support of emergency calls, a new emergency registration is required so that these emergency bearers can be used for both signalling and media, unless an existing emergency registration exists on those emergency bearers.
Up

4.7.3  Emergency calls generated by an AS |R10|Word‑p. 88
In certain circumstances an AS can identify that a request is an emergency call. This may relate to a request received from a UE (or subscription-based business trunking), or may be a call generated by an AS on behalf of a UE as far as the IM CN subsystem operation is concerned. These applications are outside the scope of this document to define.
Procedures in support of an AS initiating emergency calls are provided in subclause 5.7.1.14.
Up

4.7.4  Emergency calls received from an enterprise network |R10|

An IBCF can also route emergency calls received from an enterprise network (peering-based business trunking) to an E-CSCF.

4.7.5  Location in emergency calls |R10|

A number of mechanisms also exist for providing location in support of emergency calls, both for routeing to a PSAP, and for use by the PSAP itself, in the IM CN subsystem:
  1. by the inclusion by the UE of the Geolocation header field containing a location by reference or by value (see RFC 6442);
  2. by the inclusion by the UE of a P-Access-Network-Info header field, which contains a cell identifier or location identitifier, which is subsequently mapped, potentially by the recipient, into a real location;
  3. by the inclusion by the P-CSCF of a P-Access-Network-Info header field based on information supplied by either the PCRF or the NASS, and which contains a cell identifier or location identitifier, which is subsequently mapped, potentially by the recipient, into a real location;
  4. by the allocation of a location reference that relates to the call by the LRF. Location is then supplied to the recipient over the Le interface (see TS 23.167 for a definition of the Le interface) along with other call information. The LRF can obtain the location from entities outside the IM CN subsystem, e.g. by the e2 interface from the NASS (see ETSI TS 283 035 [98] or from the Gateway Mobile Location Centre (GMLC); and
  5. by the inclusion by the S-CSCF of a P-Access-Network-Info header field based on information supplied by HSS, and which contains a location identitifier, which is subsequently mapped, potentially by the recipient, into a real location.
Mechanisms also exist for providing emergency-related information to a PSAP, in requests subsequent to routeing an initial request to a PSAP, in the IM CN subsystem:
  1. by the inclusion by the UE of the Geolocation header field containing a location by reference or by value (see RFC 6442);
  2. by the inclusion by the UE of a P-Access-Network-Info header field, which contains a cell identifier or location identitifier, which is subsequently mapped, potentially by the recipient, into a real location;
  3. by the inclusion by the P-CSCF of a P-Access-Network-Info header field based on information supplied by either the PCRF or the NASS, and which contains a cell identifier or location identitifier, which is subsequently mapped, potentially by the recipient, into a real location;
  4. by the inclusion by the UE of the emergency-related information as specified in subclause 5.1.6.10;
  5. by the inclusion by the S-CSCF of a P-Access-Network-Info header field based on information supplied by HSS, and which contains a location identitifier, which is subsequently mapped, potentially by the recipient, into a real location; and
  6. by LRF requesting the location from the UE via E-CSCF as specified in subclause 5.12.3.2, subclause 5.11.4.3, subclause 5.11.4.4, subclause 5.11.5 and subclause 5.1.6.12.
The E-CSCF routes such a subsequent request to the PSAP using normal SIP procedures.
Which means of providing location is used depends on local regulatory and operator requirements. One or more mechanisms can be used. Location can be subject to privacy constraints.
Up

4.7.6  eCall type of emergency service |R14|Word‑p. 89
A PSAP supporting eCall over IMS supports:
  • receipt of the minimum set of emergency related data (MSD) in an INVITE or INFO request;
  • the EmergencyCallData.eCall.MSD Info-Package and the ability to request an updated MSD by including an "application/EmergencyCallData.Control+xml" MIME body part containing a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to "eCall.MSD" in an INFO request as defined in RFC 8147;
  • sending of an acknowledgement for an MSD received in an INVITE request by including, in the final response to the INVITE request, an "application/EmergencyCallData.Control+xml" MIME body part with an "ack" element containing a "received" attribute set to "true" or "false" and a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE, as defined in RFC 8147;
  • receipt of the MSD using audio media stream encoded as described in TS 26.267;
  • the ability to request an updated MSD using audio media stream encoded as described in TS 26.267; and
  • the ability to request an updated MSD using audio media stream encoded as described in TS 26.267, if the remote UA modifies an IMS emergency call of the eCall type of emergency service and stops supporting the EmergencyCallData.eCall.MSD Info-Package defined in RFC 8147.
Up

4.8  Tracing of signalling |R14|

4.8.1  General

IM CN subsystem entities can log SIP signalling, for debugging or tracing purposes, as described in TS 32.422. Debugging of SIP signalling is configured using the 3GPP IMS service level tracing management object (MO), specified in TS 24.323. This management object can provide configuration data to a UE or an S-CSCF, including in a visited network. Logging always begins with the initial request that creates a dialog and ends when a pre-configured stop trigger occurs or the dialog ends, whichever occurs first, as described in RFC 8497 and configured in the trace management object defined in TS 24.323.
Up

4.8.2  Trace depth

The depth parameter in trace control and configuration indicates which SIP requests and responses are logged. If the trace depth is "maximum" then all requests and responses within a dialog or standalone transaction are logged. If the trace depth is "minimum" then all requests and responses except for non-reliable 1xx responses (including 100 (Trying) responses) and the ACK request are logged.

4.9  Overlap signalling |R8|Word‑p. 90

4.9.1  General

This subclause explains the overlap signalling impacts on the core entities of the IM CN subsystem.
The support of overlap signalling, and each of the overlap signalling method, within the IM CN subsystem, are optional and is dependent on the network policy.
Only one overlap signalling method shall be used within one IM CN subsystem.

4.9.2  Overlap signalling methods

4.9.2.1  In-dialog method

4.9.2.1.1  General
The in-dialog method uses INFO requests or INVITE requests in order to transport additional digits. Before an early dialog has been established, upon reception of a 404 (Not Found) or 484 (Address Incomplete) response to an earlier INVITE request, new INVITE requests will be sent to transfer additional digits (as specified in TS 29.163). Once an entity establishes an early dialog, by sending a provisional response to a INVITE request, INFO requests will be sent to carry additional digits on the early dialog.
The message body, and associated header values, which is used to carry additional digits in INFO requests is defined in TS 29.163.
Up

4.9.2.2  Multiple-INVITE method

4.9.2.2.1  General
The multiple-INVITE method uses INVITE requests with the same Call ID and From header in order to transport digits (as specified in TS 29.163).

4.9.3  Routeing impacts

4.9.3.1  General

If overlap dialing is supported, the IM CN subsystem needs to be configured in such a manner that erroneous routeing of INVITE requests with incomplete numbers towards others entities than the corresponding INVITE requests with full numbers is avoided, for instance towards a default destination for unknown numbers such as a PSTN. Possibly impacted nodes include the S-CSCF for the UE-originated case, the transit routeing function, the I-CSCF, and application servers.
A misrouteing can be avoided by configuring the entity sending overlap signalling in such a manner that it will send the first INVITE request with a sufficient number of digits to find a suitable entry in the translation database. If ENUM is used, the ENUM database in a typical deployment contains sufficient information about the first digits, as required to identify the destination IP domain. Therefore, ENUM is able to handle incomplete numbers in such deployments. As another alternative, the routeing entity can reject calls with unknown numbers with a 404 (Not Found) response, using entries in the routeing database to identify calls towards the PSTN. The S-CSCF for the UE-originated case could also forward calls with unknown numbers to the BGCF, if the BGCF is configured to reject calls to unknown destinations with a 404 (Not Found) response.
Up

4.9.3.2  Deterministic routeing

If the multiple-INVITE method is used for overlap signalling, if an entity receives a INVITE request outside an existing dialog with the same Call ID and From header field as a previous INVITE request during a certain period of time, the entity shall route the new INVITE request to the same next hop as the previous INVITE request.
Up

4.9.3.3  Digit collectionWord‑p. 91
Entities performing routeing decicisions may require additional digits for a decision where to route an INVITE request. These entities may interact with a routeing database to reach this decision.
If no suitable entry in a database is found for the digits received in a INVITE request, an entity can reject the INVITE request with a 404 (Not Found) or 484 (Address Incomplete) response. This method of digit collection can be performed by a SIP proxy and is suitable both for the in-dialog and multiple-INVITE overlap signalling methods. Replying with a 404 (Not Found) response avoids the need to keep apart uncomplete and unknown numbers. The 484 (Address Incomplete) response requires the recognition of incomplete numbers.
As an alternative for the in-dialogue method, the digit collection function described in Annex N.2 may be invoked. It shall be performed by an entity acting as a B2BUA. The digit collection function requires the ability to recognise incomplete number.
Up

4.10  Dialog correlation for IM CN subsystems |R9|

4.10.1  General

The Call-ID header field in combination with the tags in the From header field and in the To header field is the standard mechanism to identify SIP messages which belong to the same dialog. However the Call-ID header field is often changed by B2BUAs and other SIP intermediaries in the end-to-end message path.
To solve this problem, a Session-ID header field containing a globally unique session identifier, as defined in RFC 7989, can be used to correlate SIP messages belonging to the same session. In the case of a concatenation of dialogs, the dialog correlation mechanism indicates that these dialogs belong to the same session.
The usage of the Session-ID header field is specified in Annex A.
Up

4.10.2  CONF usage

In case of the activation of a 3PTY conference, in the INVITE request to the CONF AS the Session-ID header field is added to the URIs in the URI list, in order to indicate the dialogs which are to be included to the 3PTY conference at the CONF AS, as described in TS 24.147.

4.11  Priority mechanisms |R10|

In support of priority, the IM CN subsystem uses the mechanisms of RFC 4412. The request for prioritisation of a transaction / dialog may, for some deployments, be marked with the Resource-Priority header field by the UE. For other deployments, the request is not marked for priority by the UE, but the request is instead identified as a priority request and marked for priority (via a Resource-Priority header field) by a functional entity (e.g., P-CSCF) within the network. Subsequent to successful authorisation at an authorisation point (e.g. AS), request is considered to be authorised.
The characteristics of any priority scheme is defined by the namespace that is used. This determines how priority is applied to the SIP signalling, to the bearer carrying the SIP signalling, and to the bearers carrying any media. Different priority levels exist within each namespace. Priority levels in one namespace have no relationship to the priority levels in any other namespace, i.e. priority level "1" in namespace "A" may have an entirely different level and characteristic of priority treatment to an identically labelled priority level "1" in namespace "B".
A network can support multiple namespaces. It is up to the network operator (potentially based on regulatory or contractural obligations) to define the relationship between the priority mechanisms for each namespace, and indeed with calls that are not given any priority. It is normal that prioritised calls do not have access to 100% of any available resource and indeed are limited to a much lower figure. Priority is optional, and this document places no requirement on a conformant IM CN subsystem implementation to support priority, or indeed any namespace in a priority scheme. Regulators can however place their own requirements on an operator. Emergency transactions or dialogs (see subclause 4.7) can also have their own priority scheme.
RFC 4412 specifies several resource priority namespaces. For example, certain national MPS implementations use resource priority namespaces of ETS (Emergency Telecommunications Service) and WPS (Wireless Priority Service).
Several ways of using priority exist, depending on the authorisation mechanism adopted. These are identified as follows. In each of these authorisation means authorisation to use the service, the namespace, and the priority level within that namespace:
  1. Authorisation based on subscription in the IM CN subsystem only, priority requested by the UE using the Resource Priority header field. Whether the user is allowed to use priority or not, and the appropriate namespace and priority levels, is stored as part of the user profile in the HSS. As part of the reg event package subscription, this information is given to the P-CSCF when the contact information for any public user identity changes, and based on this information, the P-CSCF acts as the authorisation point for priority on individual requests. At the P-CSCF, when a Resource-Priority header field is received from the UE, if the requested priority equates to a value (namespace and priority level) that the P-CSCF knows is allowed for that public user identity, the priority is authorised.
  2. Authorisation based on a database deployed by an AS; priority requested by the UE using a special dialstring. In this case the user requires no priority subscription information in the HSS. Specific dialstrings are configured in the P-CSCF. When a request is received from the UE by the P-CSCF, if the request contains a specific dialstring that is recognised by the P-CSCF as being eligible for priority treatment, the request is marked for temporary priority, subject to subsequent authorisation by an authorisation point (i.e., AS). And all such requests are routed to an AS. Final authorisation is granted by the AS, based on a PIN or password exchange with the UE. Subsequent requests or responses after authorisation are only given priority by the P-CSCF and S-CSCF if some backwards indication is received for that specific dialog. The definition of this backwards indication is outside the scope of this document (because non-standardised mechanisms have already been implemented in association with this approach).
  3. Authorisation based on subscription in the IM CN subsystem and on a database deployed by an AS; priority requested by the UE using a special dialstring. Specific dialstrings are configured in the P-CSCF. When a request is received from the UE by the P-CSCF, if the request contains a specific dialstring that is recognised by the P-CSCF as being eligible for priority treatment, the request is marked for temporary priority, subject to subsequent authorisation by an authorisation point (i.e., AS). Based on iFC functionality that exists at the S-CSCF (from the users subscription in the HSS), such requests are routed to an AS. Final authorisation is granted by the AS, based on a PIN or password exchange with the UE or based on user profile. Subsequent requests or responses after authorisation are only given priority by the P-CSCF and S-CSCF if some backwards indication is received for that specific dialog. The definition of this backwards indication is outside the scope of this document (because non-standardised mechanisms have already been implemented in association with this approach).
Some administrations can require the use of multiple approaches in the same network.
For the cases of interworking with other networks, where the P-CSCF of the other network does not support priority, but it is intended or required to give users of that P-CSCF priority in the home network, provision is made for recognition of dialstrings by the IBCF and the S-CSCF. In such scenarios, when the IBCF or S-CSCF recognize that a request contains a dialstring as being eligible for priority treatment, the request is marked by the IBCF or S-CSCF for temporary priority, subject to subsequent authorisation by an authorisation point (i.e. AS). This mechanism does not have an impact on the network where the P-CSCF resides.
Where the network has a requirement to prioritise emergency calls, it can either perform this function by the use of the "esnet" namespace in the Resource-Priority header field (as defined in RFC 7135), or by recognition of the presence of the service URN relating to an emergency. Where the Resource-Priority header field is used for this purpose, it is inserted by the entity identifying the emergency call, i.e. the P-CSCF or the IBCF. There is no usage of this namespace from the UE, and when this namespace is used, the trust domain implementation is set to remove it if it occurs from the UE.
Up

4.12  Overload control |R11|Word‑p. 93
Usage of overload control is independent of the nature of any SIP using entity, i.e. there are no specific requirements for any particular IMS functional entity implementing SIP. The capability however is not extended to the UE except when performing the function of an externally attached network.
Two mechanisms are defined as follows:
  • a feedback based mechanism defined in RFC 7339, where the feedback is given in the Via header field of signalling messages supporting the traffic. RFC 7339 also defines the default algorithm for usage of the feedback based mechanism in the IM CN subsystem (i.e. loss-based algorithm). Additional algorithms are either already defined, e.g. the rate-based scheme defined in RFC 7415 or can also be defined in the future. As it is carried in the Via header fields the nature of the mechanism is hop by hop.
  • an event package for distributing load filters defined in RFC 7200, which can be either used in a hop-by-hop manner between adjacent entities in a similar manner to the feedback based mechanism, or can be used on a wider basis across the network, subject to the restrictions given in Annex A. In this manner it can be used to address expected overload situations, e.g. for voting calls initiated by a specific television programme.
When the load filters based mechanism is used in the IMS, the default algorithm is loss-based (i.e. the filter specifies the relative percentage of incoming requests that can be accepted).
The S-CSCF, application servers and entities that implement the additional routeing capability can use both mechanisms in parallel on the same interfaces.
There are no specific reasons why one protocol mechanism should be specified over another, although some discussion is given in the documents specifying the mechanisms themselves. It is regarded as a deployment issue as to which mechanisms are supported, and which algorithms are supported within those mechanisms, beyond those that the mechanisms themselves identify as mandatory. An operator will need to take a network wide view to planning their overload control strategy, it cannot be performed on ad-hoc basis as nodes are deployed.
For the distribution of load filters mechanism, typical deployments might include an S-CSCF subscribing to the load control event package at an AS, an AS subscribing to the load control event package at an AS, and an entity hosting additional routeing capabilities as specified in subclause I.3 subscribing to the load-control event package at the AS.
Based on regional/national requirements and network operator policy, priority calls (e.g., multimedia priority service) are exempted from SIP overload controls up to the point where further exemption would cause network instability. Therefore, SIP messages related to priority calls have the highest priority, and are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction. The interaction between SIP overload control and priority services is covered in RFC 7339 and RFC 7200.
Based on regional/national requirements and network operator policy, emergency calls are exempted from SIP overload controls up to a configured threshold. Therefore, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction due to overload control, SIP messages related to emergency calls are not dropped while the configured threshold regarding the amount of the ongoing emergency calls is not reached.
Mid-dialog SIP messages have higher priority with regard to initial SIP requests, and therefore are last to be dropped or rejected, when an IM CN subsystem functional entity decides it is necessary to apply traffic reduction due to overload control.
Operation between two network operators is supported. If two network operators wish to implement overload control, it is a matter for bilateral agreement as to what is supported.
Operation with enterprise networks is supported. The network operator and the enterprise operator will need to agree on the overload control options to be supported.
Up

4.13  II-NNI traversal scenario |R12|

4.13.1  General

Within the IM CN subsystem, the signalling path between a calling user and a called user can be divided into one or more traffic legs, referred to as II-NNI traversal scenarios. Each II-NNI traversal scenario can span networks belonging to different operators and will have its own characteristics that can be different from other II-NNI traversal scenarios in the same call.
Dialog creating SIP requests and standalone requests can contain an "iotl" SIP URI parameter as specified in RFC 7549 in a Request-URI or in one or more Route header fields. The "iotl" SIP URI parameter is appended to the URI representing the end of the II-NNI traversal scenario. The value of "iotl" SIP URI parameter can be used to identify the II-NNI traversal scenario.
If the "iotl" SIP URI parameter is not included in a dialog creating SIP requests or a standalone request, the II-NNI traversal scenario type can be determined by analysing the content of the SIP request or using a default II-NNI traversal scenario type.
The "iotl" SIP URI parameter is included by the start of the II-NNI traversal scenario (e.g. P-CSCF, S-CSCF, BGCF or SCC AS) and removed by the end of the II-NNI traversal scenario (e.g. S-CSCF, TRF or P-CSCF).
Up

4.13.2  Identifying the II-NNI traversal scenarioWord‑p. 94
The "iotl" SIP URI parameter specified in RFC 7549 containing traffic leg information can be used to identify the II-NNI traversal scenario type. The II-NNI traversal scenario type can be used by intermediary entities (e.g. IBCF and transit networks) to make policy decisions related to e.g. media anchoring, screening of SIP signalling, insertion of media functions (e.g. transcoder) and charging.
One example on how the "iotl" SIP URI parameter is included in the Route header field by the P-CSCF in a visited network when sending a request towards the home network is shown below.
EXAMPLE: Route: <sip:ibcf-vA1.visited-A.net;lr>,<sip:home-abc@scscf-hA1.home-A.net;lr:iotl=visitedA-homeA>
If neither the Request-URI nor any of the Route header fields included in the SIP request contains the "iotl" SIP URI parameter, the II-NNI traversal scenario type can be determined by analysing the content of the SIP request or using a default II-NNI traversal scenario type. The recommended II-NNI traversal scenario type default value is "homeA-homeB".
Up

4.13.3  Security aspects

When receiving a dialog creating SIP request or a standalone SIP request from outside the trust domain the IBCF acting as an entry point removes any "iotl" SIP URI parameter according to subclause 4.4.15 and assume the default II-NNI traversal scenario type or can use trusted elements of the SIP request to determine the II NNI traversal scenario type.
Up

4.14  Restoration procedures |R12|

4.14.1  General

The present document includes optional restoration procedures for failure of P-CSCF and S-CSCF. The general mechanism is to inform the UE that one of the entities along its registration path is not working, and hence the UE needs to perform an initial registration. For systems providing access to IM CN subsystem using a GPRS IP-CAN, EPS IP-CAN or a 5GS IP-CAN, the mechanism to trigger the UE can be to use the Protocol Configuration Options IE or extended Protocol Configuration Options IE specified in TS 24.008, include an 3GPP IM CN subsystem XML body in a 504 (Server Time-out) response, or disconnect the PDN connection.
Up

4.14.2  P-CSCF restoration proceduresWord‑p. 95
P-CSCF restoration procedures are implemented in the S-CSCF, the IBCF and the UE.
When the UE originates a session it can detect that a P-CSCF is not reachable based on no response from the P-CSCF in which case the UE selects another P-CSCF if possible and performs a new initial registration.
UDM/HSS or HSS based P-CSCF restoration applies to UE terminating requests where the SIP entity neighbouring the P-CSCF (S-CSCF, IBCF) can detect that a P-CSCF is not reachable. When the neighbouring entity is the S-CSCF, the S-CSCF can in this case initiate the P-CSCF restoration. The S-CSCF sends an indication to the HSS to initiate the restoration. If the terminating user is roaming, the neighbouring entity is an entry IBCF which uses the Restoration-Info header field to inform the S-CSCF about the failure in a 408 (Request Timeout) response for INVITE requests or a 504 (Server Time-out) response for non-INVITE requests and the S-CSCF can send an indication to the HSS to initiate the restoration.
PCF or PCRF based P-CSCF restoration applies to UE terminating INVITE requests. For PCF or PCRF based P-CSCF restoration the S-CSCF uses the Restoration-Info header field to send the IMSI in initial INVITE requests to an alternative P-CSCF. When the user is roaming, the IBCF selects an alternative P-CSCF and forwards the IMSI of the terminating user in a Restoration-Info header field.
Restoration can also be initiated when the P-CSCF has restarted, and lost all bindings for a particular user. In this case the P-CSCF rejects the incoming request with a 404 (Not Found) response. If the home network applies UDM/HSS or HSS based P-CSCF restoration the S-CSCF initiates the restoration procedure by sending an indication to the HSS. If PCF or PCRF based restoration is used, the S-CSCF initiate the PCF or PCRF based P-CSCF restoration procedure for the served user by including the IMSI in a Restoration-Header field included in an initial INVITE request.
Up

4.14.3  S-CSCF restoration procedures

The P-CSCF can inform the UE about S-CSCF failures in a 504 (Server Time-out) response using the 3GPP IM CN subsystem XML body defined in subclause 7.6, in accordance with subclause 5.2.6.3.2A, when the P-CSCF is unable to forward a request to an S-CSCF.
When the S-CSCF receives a request initiated by the served user for which the S-CSCF does not have the user profile or does not trust the data that it has (e.g. due to restart) the S-CSCF can if it fails to retrieve the data from the HSS trigger a registration by sending a 504 (Server Time-out) response using the 3GPP IM CN subsystem XML body defined in subclause 7.6 to the UE, in accordance with subclause 5.4.3.2.
An I-CSCF can reselect S-CSCF if the previously selected S-CSCF is not available.
If an IBCF acting as an entry point in the originating home network cannot forward the request the IBCF can trigger the UE to perform initial registration by including the 3GPP IM CN subsystem XML body in a 504 (Server Time-out) response, in accordance with subclause 5.10.3.5.
Up

4.15  Resource sharing |R13|

Resource sharing allows two or more sessions to use the same resources for one or more media streams in uplink, downlink or both uplink and downlink direction.
A P-CSCF that supports resource sharing can determine that there is a potential for resource sharing based on local configuration or defer the determination of potential resource sharing to an AS in the home network.
If the determination of potential resource sharing is deferred to an AS in the home network:
  • the P-CSCF on the originating side indicates that resource sharing is supported in the initial REGISTER request in the Resource-Share header field defined in subclause 7.2.13. The Resource-Share header field is included in the third-party REGISTER request towards the AS; and
  • if the "message/sip" MIME body in the third-party REGISTER request included the Resource-Share header field with the value "supported", the AS in the home network includes the Resource-Share header field containing the rules for resource sharing in responses and requests towards the P-CSCF.
If the rules for resource sharing are updated, the updated rule will be sent to P-CSCF in one of the sessions that share resources. The updated resource sharing rules will then be applied for all sessions that are sharing resources.
Up

4.16  Priority sharing |R13|Word‑p. 96
Priority sharing allows two or more sessions with different priority to share the same bearer.
The determination of the use of priority sharing is deferred to an AS in the home network:
  1. if P-CSCF supports priority sharing and if according to local policy, the P-CSCF indicate that priority sharing is supported by including the g.3gpp.priority-share feature-capability indicator defined in subclause 7.9A.10 in a Feature-Caps header field in the REGISTER request;
  2. if the "message/sip" MIME body in the third-party REGISTER request included the g.3gpp.priority-share feature-capability indicator and:
    1. if the AS determined to enable priority sharing, the AS includes the Priority-Share header field with a value "allowed" in a request or response sent towards the P-CSCF; or
    2. if the AS determined to disable priority sharing, the AS includes the Priority-Share header field with a value "not-allowed" in a request or response sent towards the P-CSCF.
Up

4.17  3GPP PS data off |R14|

The UE and the network can support the 3GPP PS data off.
When 3GPP PS data off is supported and active, IP packets that are associated with services that are not a 3GPP PS data off exempt service are prevented from transport over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN as specified in TS 23.228. The UE may be configured by the HPLMN or the EHPLMN with up to two indications whether a 3GPP IMS service is a 3GPP PS Data Off exempt service, one indication is valid for the UE is in the HPLMN or the EHPLMN and the other indication is valid for the UE is in the VPLMN. When the UE is only configured with the indication valid for the UE camping in the HPLMN or the EHPLMN, the UE shall use this indication also when the UE is in the VPLMN.
When 3GPP PS data off is supported and active and the UE is configured, either as specified in TS 24.167 or in TS 31.102, with services that are 3GPP PS data off exempt, then the UE will not send uplink IP packets related to any services that are not 3GPP PS data off exempt over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN. The UE informs the network about its 3GPP PS data off status by including a g.3gpp.ps-data-off media feature tag specified in subclauce 7.9.8 in all REGISTER requests sent over GPRS IP-CAN, EPS IP-CAN or 5GS IP-CAN. The UE reregisters over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN every time the 3GPP PS data off status is changed or the UE is provided by the network with a new list of 3GPP PS data off exempt services while the 3GPP PS data off status is "active".
An AS handling a service is configured with information whether the service is a 3GPP PS data off exempt service. If the 3GPP PS data off status is active and the service is not a 3GPP PS data off exempt service, the AS prevents downlink IP packets of the service from reaching the UE over EPS IP-CAN, GPRS IP-CAN and 5GS IP-CAN. The AS shall be configured with up to two indications whether a 3GPP IMS service is a 3GPP PS Data Off exempt service, one indication is valid for non-roaming users, and the other indication is valid for users roaming in the various VPLMNs with whom roaming agreements exist. When the AS is only configured with the indication valid for the UE camping in the HPLMN or the EHPLMN, the AS shall use this indication also when the UE is in the VPLMN.
Up

4.18  Dynamic Service Interaction |R13|Word‑p. 97
Dynamic Service Interaction allows that different ASs involved in the same IMS session (within an operator network or across networks) exchange information about executed services to avoid conflicting interactions between these services. Dynamic Service Interaction information is included in a SIP header field Service-Interact-Info defined in subclause 7.2.14.
If an AS which supports dynamic service interaction:
  • provides one or more services:
    1. the AS inserts in a SIP message the Service-Interact-Info header field with the identities of the services which have been performed; and
    2. if the AS identified services which should be further avoided the AS adds the identities of those services in the Service-Interact-Info header field; and
  • receives a SIP message containing the Service-Interact-Info header field, the AS takes the received Service-Interact-Info header field information into account as described in subclause 7.2.14.3.
Up

4.19  Restricted Local Operator Services |R16|

The UE and the network can support Restricted Local Operator Services (RLOS).
RLOS services are operator defined services that are offered to UEs when using an EPS IP-CAN as specified in Annex L in the following scenarios:
  • UE is successfully registered using IMS AKA or GPRS-IMS bundled authentication; or
  • UE has attempted to register and the registration is rejected from the network with a 403 (Forbidden) response.
RLOS services are offered only for the UE-originating case.
RLOS services can be offered to an operator's own subscribers and roaming subscribers.
Up

Up   Top   ToC