IMS Support for Private Header Extensions for 3GPP
As part of its RFC 3455 support, the Oracle Communications Session Border Controller supports the following headers in its IMS implementation:
- P-Associated-URI
- P-Asserted-Identity
- P-Called-Party-ID
- P-Charging-Function-Address
- P-Visited-Network-ID
- P-Early-Media —The PEM header, which has applications within IMS deployments is explained in the P-Early-Media SIP Header Support section.
The procedure to enable IMS support is explained in the previous section. IMS and all related functions must be enabled on both the access-side and core-side SIP interfaces.
P-Associated-URI Header
In the SIP registration process, the registrar often returns a set of associated URIs for a registering AoR. When the Oracle Communications Session Border Controller receives the list of associated URIs, it stores them in the registration entry for the registering endpoint. The service provider allocates one or more associated URIs per user for his or her own usage. After an endpoint successfully registers, the P-Associated-URI header returned in a 200 OK message informs the UE of all URIs associated with the AoR.
When the Oracle Communications Session Border Controller receives a request from a UE, the URI in the From header is matched against the registration cache for that endpoint. If the registering endpoint matches an associated-URI already in the registration table, the Service-Route associated with this endpoint is used to create the route for originating transactions associated with the endpoint to the S-CSCF.
The inclusion or exclusion of the P-Associated-URI header is not dependent on the trust level of an ingress or egress realm.
P-Asserted-Identity Header
The Oracle Communications Session Border Controller inserts a P-Asserted-Identity header into any initial request for a dialog or standalone transaction sourced by the UE.
The inclusion or exclusion of the P-Asserted-Identity header is dependent on the trust level of an egress realm.
P-Asserted-Identity Header Configuration
P-Asserted-Identity header handling is enabled with the sip-ims-feature as described in the previous section. A P-Asserted-Identity header can be manually configured for a session agent if the automatic logic, explained earlier in this section, fails.
To configure the P-Asserted-Identity header for a session agent:
P-Called-Party-ID Header
The Oracle Communications Session Border Controller transparently passes the P-Called-Party-ID header between the S-CSCF and a UA.
IMS Charging Headers
The Oracle Communications Session Border Controller supports IMS Charging Headers. These headers include P-Charging-Vector and the P-Charging-Function-Address. IMS charging header support is configured separately from other IMS functions in order to support a variety of customer needs. Charging header information is now recorded in the CDR records.
A charging vector is defined as a collection of charging information. The charging vector may be filled in during the establishment of a dialog or standalone transaction outside a dialog. The information inside the charging vector may be filled in by multiple network entities (including SIP proxies) and retrieved by multiple network entities. There are three types of correlation information to be transferred: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifiers (IOI).
Charging headers are inserted, deleted, or ignored for request messages. They are forwarded through the Oracle Communications Session Border Controller unmodified when embedded in response messages. If you wish to modify the charging headers in a response message, you must use the Oracle Communications Session Border Controller's header manipulation feature as a general solution.
P-Charging-Vector
You can configure the Oracle Communications Session Border Controller (SBC) to processes the P-Charging Vector header in four different ways.
- If a P-Charging-vector header is present in an incoming SIP request, the SBC can pass the header untouched, as part of the full SIP message that is forwarded out of an egress interface.
- If a P-Charging-vector header is present in an incoming SIP request, the SBC can delete the header and forward the full SIP message out of an egress interface.
- If an incoming SIP request does not contain a P-charging-vector header, the SBC can create and insert the header and forward the full SIP message out of an egress interface. Likewise, if an incoming SIP request contains an existing P-Charging-Vector header, the SBC can overwrite this header with the values generated internally.
- Determine whether to insert a P-Charging-Vector header based on whether the header is present when the SBC receives it.
The P-Charging-Vector header is composed of four parameters: icid-value, icid-gen-addr, orig-ioi, term-ioi. See RFC 3455, Section 4.6 for more information.
P-Charging-Vector Header Example
P-Charging-Vector: icid-value=1ate6g46n1823s8719ck3ps6gbt46m5d3bci3po5hhdg3n86g1csio47g9c43@192.168.0.2;
icid-generated-at=192.168.0.2;
orig-ioi=192.168.0.1;
term-ioi=192.168.0.2;
P-Charging-Function-Address
The P-Charging-Function-Address header is composed of two configurable parameters: ccf, ecf. You can configure the Oracle Communications Session Border Controller (SBC) to processes the P-Charging-Function-Address header in five different ways.
- If a P-Charging-Function-Address header is present in an incoming SIP request, the SBC can be set to pass the header, untouched, as the full SIP request is forwarded out of an egress interface.
- If a P-Charging-Function-Address header is present in an incoming SIP request, the SBC can be set to delete the header and forward the SIP request out of an egress interface.
- If an incoming SIP request does not contain a P-Charging-Function-Address header, the SBC can be set to create and insert the header and forward the SIP message out of an egress interface.
- If an incoming SIP request contains a P-Charging-Function-Address header, and the SBC is set to insert a configured P-Charging-Function-Address header, the new parameters will be appended before the existing parameters in the header. The SBC will then forward the SIP request out of an egress interface.
- Determine whether to insert a P-Charging-Function-Address header based on whether the header is present when the SBC receives it.
In addition, the SBC can also be configured to perform insertion and caching for the PCFA header in dialog-creating or stand-alone messages. The following diagram illustrates how this works:
![Depicts the OCSBC determining p-charging-function-address handling. Depicts the OCSBC determining p-charging-function-address handling.](img/sip-chg-pcfa-enhance.jpg)
For this scenario, there are two main functions, PCFA insertion and PCFA caching:
- PCFA insertion—Using the
insert-reg-cache and delete-and-respond configuration values, the
SBC adds the PCFA to
all SIP requests and to the response on the P-CSCF facing the SIP interface.
However, only dialog-creating and standalone requests, and responses to each of
those, update the
SBC and accounting
information. Such requests do not have a To tag, and responses do not appear in
established dialogs. The
SBC inserts the PCFA
into provisional (1XX) and success (2XX) responses, with the exception of the
100 Trying response.
You can use SIP header manipulation rules (HMR) to remove any unwanted headers.
- PCFA caching—When you use
either of the insert-reg-cache and delete-and-respond configuration values, the
SBC uses the latest
cached copy of a PCFA header to insert into requests and responses. The
SBC does not cache any
PCFA headers it receives on SIP interfaces using the none, insert, or
insert-reg-cache modes because this type of SIP interface faces the UE making
its replacement headers ones from the core.
Though there can be various sources for the latest cached copy, the PCFA header received as part of a dialog-creating or standalone request has highest precedence. This PCFA header is then stored as the latest cached value for that dialog. That is, for each specific dialog, the SBC the PCFA is cached separately so it can add the most specific PCFA to the message—and is added to any message for the dialog.
When there is no cache PCFA for a specific dialog, the SBC uses the registration cache entry as the latest cached copy. And when there is no entry in the registration, the PCFA uses the ccf-address and ecf-address values from the SIP interface.
The latest cached copy or the ccf-address is the value reported in the RADIUS VSA Acme-Session-Charging-Function-Address; this VSA is used for both of the new modes.Note:
Only the ccf-address is reported in RADIUS records; the ecf-address is not.
P-Charging-Function-Address Header Example
P-Charging-Function-Address: ccf=192.168.0.20 ; ecf=192.168.0.21;
RADIUS Accounting of Charging Headers
When the Oracle Communications Session Border Controller creates either the P-Charging-Vector header or the P-Charging-Function-Address header, it inserts an entry in the RADIUS record to record the charging header data.
For a P-Charging-Vector header, the icid-value is saved to the P-Charging-Vector attribute in the radius record. If the Oracle Communications Session Border Controller does not create a P-Charging-Vector header, but it receives a SIP message that already has the P-Charging-Vector header with an icid-value, the existing icid-value is written to the RADIUS record.
For a P-Charging-Function-Address header, the first CCF value is saved to the P-Charging-Function-Address attribute. When the Oracle Communications Session Border Controller creates the P-Charging-Function-Address, the CCF value it inserts into the header is saved to the radius record. If the Oracle Communications Session Border Controller does not create a P-Charging-Function-Address header, but it receives a SIP message that already has the P-Charging-Function-Address with a CCF value, the existing CCF value is written to the RADIUS record.
Name | Value | Value Type |
---|---|---|
Acme-Session-Charging-Vector | 54 | string |
Acme-Session-Charging-Function-Address | 55 | string |
P-Charging-Vector Processing for SIP Interfaces Configuration
P-Charging-Vector header handling is enabled in the SIP interface.
To configure P-Charging-Vector processing in a SIP interface:
Charging Correlation
IMS is based on a distributed architecture that can result in multiple network entities becoming involved in providing access and services. Operators require the ability to charge for the access and services as they provide. This necessitates coordination among the network entities (for example, SIP proxies), which includes correlating charging records generated from different entities that are supporting the same session.
Charging correlation is supported in Release SC-X7.1.2 and later.
During initial provisioning of session information, the Oracle Communications Session Border Controller, functioning as a P-CSCF, indicates its support for charging correlation by subscribing to access network charging information from the PCRF (Policy Charging Rule Function). In a typical exchange, the subscription is requested with an AA-Request (AA-R) command that contains the Specific-Action (Type 513) and AF-ChargingIdentifier (Type 505) AVPs. The Specific-Action AVP is set to 1, (CHARGING_CORRELATION_EXCHANGE), requesting that the PCRF provide new and updated charging information as such information becomes available.
The PCRF responds with an AA-Answer (AA-A) that usually contains one or more associated Access-Network-Charging-Identifier (Type 502) and an Access-Network-Charging-Address (Type 501) AVPs. The Access-Network-Charging-Address AVP contains the IP address of a network entity that is charging for session services. The Access-Network-Charging-Identifier associated with the entity identified by the Access-Network-Charging-Address AVP. This identifier is applied to all traffic/media flows within the current session.
The AA-A can contain an IP-CAN-Type (Type 1027) AVP that indicates the type of Connectivity Access Network and an associated RAT-Type AVP that provides more specific information as to the access technology. For IMS charging correlation, the IP-CAN-Type AVP can contain one or two values: 0 (3GPP), or 5 (3GPP-EPS).
In some cases, the PCRF may not have the requested charging information at the time of the initial AA-R. When information becomes available, the PCRF sends the data to the P-CSCF via a Re-Auth-Request (RAR) command, which is then acknowledged by the P-CSCF with a Re-Auth-Answer (RAA) command.
Upon receiving charging information from the PCRF, the P-CSCF saves the data in the context of the associated SIP session. Saved data is used to populate the P-Charging-Vector SIP header.
P-Early-Media SIP Header Support
The P-Early-Media (OEM) SIP Header provides a means of managing and authorizing the use of early media. This header applies to multiple contexts, including within IMS. Documentation on the PEM header is consolidated in the SIP chapter.
See Early Media Support for PEM documentation.
P-Visited-Network-ID Header
The Oracle Communications Session Border Controller's IMS support also includes the insertion of a P-Visited-Network-ID header into SIP messages when applicable. When a UE sends a dialog-initiating request (e.g., REGISTER or INVITE message) or a standalone request outside of a dialog (e.g., OPTIONS) to the P-CSCF, the Oracle Communications Session Border Controller inserts the P-Visited-Network-ID header into the SIP message as it enters into the destination network.
![The P-Visited-Network-ID Header diagram is described above. The P-Visited-Network-ID Header diagram is described above.](img/ims_pvni.gif)
The P-Visited-Network ID header will be stripped from SIP messages forwarded into untrusted networks as expected. The content of a P-Visited-Network-ID header is a text string that identifies the originating UE's home network. This string is user-configurable.
P-Visited-Network-ID Header Handling for SIP Interfaces Configuration
P-Visited-Network-ID header handling is enabled with the sip-ims-feature as described earlier. The actual P-Visited-Network-ID string must be configured on the access-side SIP interface. The Oracle Communications Session Border Controller must consider the egress device trusted or it does not add that the P-Visited-Network-ID header to the forwarded request.
To configure the P-Visited-Network-ID string in a SIP interface:
Second P-Asserted-Identity Header for Emergency Calls
The Oracle Communications Session Border Controller can add a second P-Asserted-Identity header when forwarding an emergency message into the network.
When the UE registers with an S-CSCF, the S-CSCF returns a set of associated URIs, the implicit registration set (IRS,) for the AoR in the 200 OK response. The Oracle Communications Session Border Controller caches the IRS. The user identities that comprise the cached IRS are used for validation later.
As the Oracle Communications Session Border Controller receive a UE’s INVITE, the value in the P-Preferred-Identity header is validated against the public user identities in the cached IRS. If the inbound P-Preferred-Identity matches any items in the IRS, the Oracle Communications Session Border Controller inserts that value into a P-Asserted-Identity header in the egress message. The P-Preferred- Identity header is stripped from the outbound message.
Inbound INVITE Contains: | Validate Against Implicit Registration Set | Outbound Invite Created With: (all P-Preferred-Identity headers are removed) |
---|---|---|
P-Preferred-Identity: value-1 | value-1 present | P-Asserted-Identity: value-1 |
The Oracle Communications Session Border Controller can create a second P-Asserted-Identity header by configuring the add-second-pai option in the SIP config. Once a combination of SIP URIs and/or TEL URIs in the inbound P-Preferred-Identity header are validated against the IRS, the Oracle Communications Session Border Controller forwards the emergency INVITEs with two P-Asserted-Identity headers to the E-CSCF. The behavior is based upon the URI type received in the P-Preferred-Identity header and whether those values validate against the IRS list.
Inbound INVITE Contains: | Validate Against Implicit Registration Set | Outbound Invite Created With: (all P-Preferred-Identity headers are removed) |
---|---|---|
P-Preferred-Identity: SIP-URI-1 | SIP-URI-1 present
TEL-URI-1 present (TEL-URI-n present) |
P-Asserted-Identity: SIP-URI-1
P-Asserted-Identity: TEL-URI-1 |
P-Preferred-Identity: TEL-URI-1 | TEL-URI-1 present
SIP-URI-1 present (SIP-URI-n present) |
P-Asserted-Identity: TEL-URI-1 P-Asserted-Identity: SIP-URI-1 |
NO P-Preferred-Identity: |
(SIP | TEL) URI -1 present (SIP | TEL) URI -n present |
P-Asserted-Identity: 1st public identity from IRS |
P-Preferred-Identity: SIP-URI-1 P-Preferred-Identity: TEL-URI-1 |
TEL-URI-1 present SIP-URI-1 present |
P-Asserted-ID: SIP-URI-1 P-Asserted-ID: TEL-URI-1 |
P-Preferred-Identity: SIP-URI-1 P-Preferred-Identity: SIP-URI-2 |
SIP-URI-1 present SIP-URI-2 present TEL-URI-n present |
P-Asserted-Identity: SIP-URI-1 P-Asserted-Identity: 1st TEL-URI from IRS |
P-Preferred-Identity: TEL-URI-1 P-Preferred-Identity: TEL-URI-2 |
TEL-URI-1 present TEL-URI-2 present SIP-URI-n present |
P-Asserted-Identity: TEL-URI-1 P-Asserted-Identity: 1st SIP-URI from IRS |
If the INVITE does not include a P-Preferred-Identity header and does not include a P-Asserted-Identity header, or the value in the original P-Preferred-Identity or P-Asserted- Identity header is not contained in the IRS, or the URI from the From: header is not the in the IRS, then default public user identity is inserted into a P-Asserted- Identity header in the egress message. (The default public user identity is the first on the list of URIs in the P-Associated-URI header.)
If the strict-3gpp-pai-compliance option is configured in the outbound SIP interface, the first P-Asserted-Identity header also includes the display name.
Two Incoming P-Asserted-Identity Headers
Inbound Invite Contains | Validate Against Implicit Registration Set: | Outbound Invite Created With: |
---|---|---|
P-Asserted-Identity: SIP-URI-1 P-Asserted-Identity: TEL-URI-1 |
SIP-URI-1 and TEL-URI-1 present |
P-Asserted-Identity: SIP-URI-1 or TEL-URI-1 P-Asserted-Identity: 1st public identity from IRS other than value in 1st P-Asserted-Identity |
P-Asserted-Identity: SIP-URI-1 P-Asserted-Identity: SIP-URI-2 |
SIP-URI-1 or SIP-URI-2 present TEL-URI-1 present |
P-Asserted-Identity: SIP-URI-1 P-Asserted-Identity: TEL-URI-1 |
P-Asserted-Identity: TEL-URI-1 P-Asserted-Identity: TEL-URI-2 |
TEL-URI-1 or TEL-URI-2 present SIP-URI-1 present |
P-Asserted-Identity: TEL-URI-1 or TEL-URI-2 P-Asserted-Identity: SIP-URI-1 |