1. Configuration Guide
  2. IMS Support
  3. IMS Support for Private Header Extensions for 3GPP

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 Handling

  1. The Oracle Communications Session Border Controller inserts a P-Asserted-Identity header into all messages other than the REGISTER message.
  2. When the P-Preferred-Identity header is present in an INVITE sourced by the UE, and the SIP URI contained in this header is also present in the UE's associated URI list, then this SIP URI is inserted in the P-Asserted-Identity header as the SIP message enters the core network.
  3. When the P-Asserted-Identity header is present in an INVITE sourced by the UE, and the SIP URI contained in this header is also present in the UE's associated URI list, then the original P-Asserted-Identity header and SIP URI is passed unchanged into the core network.
  4. When the From header is present in an INVITE sourced by the UE, and the SIP URI contained in this header appears in the UE's Associated URI list, then this SIP URI is inserted into the P-Asserted-Identity header as the SIP message enters the core network.
  5. When the P-Asserted-Identity header is present in an INVITE sourced by the UE, and the SIP URI contained in this header is not present in the Associated URI list, the Oracle Communications Session Border Controller acts like no P-Asserted-Identity was received from the UE.
  6. When no P-Asserted-Identity can be derived from an INVITE sourced by the UE, the P-Asserted-Identity is based on the first URI in the Associated URI list.
  7. The P-Asserted-Identity header will be removed from SIP messages sent and received from a UE if either the ingress or egress side is untrusted and the UE’s Privacy header’s contents is id.
  8. If no P-Associated-URI exists for a registered endpoint, the Oracle Communications Session Border Controller will use the configured default P-Asserted-Identity found on the sourcing session agent. This feature works with both SIP and H.323 session agents.
  9. If the session agent that originates a message does not include a P-Asserted-Identity header or the request is not originated from the session agent, and the P-CSCF has not received P-Associated-URI list from the registrar for a particular user, no P-Asserted-Identity will be created.
  10. The P-Preferred-Identity header will never be passed to the S-CSCF.

    If the above steps fail to insert a P-Asserted-Identity header, you can manually configure a value to be inserted into a P-Asserted-Identity header. The sip-ims-feature parameter must still be enabled to use the P-Asserted-Identity header override.

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:

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
  2. Type session-router and press Enter to access the session-level configuration elements. 
    ORACLE(configure)# session-router
ORACLE(session-router)#
  3. Type sip-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters. 
    ORACLE(session-router)# session-agent
ORACLE(session-agent)#
  4. Type select and the number of the pre-configured session agent you want to configure. 
    ORACLE(session-agent)# select 1
  5. Type p-asserted-id <space> <URI to use when no P-Asserted-ID has been created> and press Enter. This completes the configuration. 
    ORACLE(session-agent)# p-asserted-id sip:name@acmepacket.com
  6. Save your work using the ACLI done command.

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.

  1. The SBC constructs the icid-value in the following format: 
    icid-value=<unique string>

    The unique string is a value created by the SBC and is based on the realm, local IP port, time, and a sequence number.

  2. The icid-gen-addr parameter's value is the IP address of the egress SIP interface. This value is generated by the SBC.
  3. The orig-ioi parameter's value is set manually using the operator-identifier field located in the SIP interface configuration element.
  4. The term-ioi parameter's value is set manually using the operator-identifier field located in the SIP interface configuration element.

    You configure charging vector handling on the SBC interface that receives the SIP request by turning on the switches that enable charging vector processing on the ingress interface for the call. Based on the direction of the call, the SBC will insert the operator-identifier configuration parameter into the orig-ioi and the term-ioi parameters. The orig-ioi parameter takes the value of the operator-identifier configuration parameter of the SIP interface that receives the SIP request. The term-ioi parameter takes the value of the operator-identifier configuration parameter of the SIP interface that sends the SIP request to its next hop.

    Depicts the detail of p-charging-vector insertion by the OCSBC.

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.

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:

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
ORACLE(configure)#
  2. Type session-router and press Enter. 
    ORACLE(configure)# session-router
ORACLE(session-router)#
  3. Type sip-interface and press Enter. 
    ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#

    If you are adding support to an existing SIP interface, then you will need to select the interface you want to edit using the ACLI select command. 

    ORACLE(sip-interface)# select
  4. charging-vector-mode—Sets the Oracle Communications Session Border Controller to create the P-Charging-Vector header. The default value is pass. The valid values are:

    • none—Pass the P-Charging-Vector header received in an incoming SIP message untouched as the message is forwarded out of the Oracle Communications Session Border Controller , but does not include icid-value in accounting records.

    • pass—Pass the P-Charging-Vector header received in an incoming SIP message untouched as the message is forwarded out of the Oracle Communications Session Border Controller , includes icid-value in accounting records.

    • delete—Delete the P-Charging-Vector header received in an incoming SIP message before it is forwarded out of the Oracle Communications Session Border Controller .

    • insert—Insert the P-Charging-Vector-Mode header in an incoming SIP message that does not contain the Charging-Vector header. If the incoming message contains the Charging-Vector header, the Oracle Communications Session Border Controller will overwrite the Charging-Vector-Mode header with its values. This option always uses the ccf-address and ecf-address static values.

    • delete-and-respond—To be configured on the SIP interface facing the P-CSCF, configures the Oracle Communications Session Border Controller to strip out the latest cached PCFA from the core side. The Oracle Communications Session Border Controller then remembers this PCFA and uses it in communications sent to the core.

    • conditional-insert—Configures the Oracle Communications Session Border Controller to perform the following functions, based on whether or not the header is present in the message when the Oracle Communications Session Border Controller receives it:
      • For incoming messages that have the associated header, the SBC uses pass mode.
      • For those that do not have the associated header, the SBC uses insert mode.

      An incoming message received on a realm that does not have a sip-interface associated with it refers to the egress sip-interface configuration to determine the behavior. Such messages include those with a PCV header. Under these conditions and with the egress sip-interface configured for conditional-insert, the system forwards the PCV header unmodified. The system would also save accounting/charging information normally.

  5. operator-identifier—Set the operator identifier value to be inserted into a P-Charging-Vector header. The direction of the call determines whether this value is inserted into the orig-ioi or the term-ioi parameter in the P-Charging-Vector header. This string MUST begin with an alphabetical character.
  6. charging-function-address-mode—Set the charging function address mode you want to use. The default value is pass. The valid values are:

    • none—Pass the P-Charging-Function-Address header received in an incoming SIP message untouched as the message is forwarded out of the Oracle Communications Session Border Controller , but does not include icid-value in accounting records.

    • pass—Pass the P-Charging-Function-Address header received in an incoming SIP message untouched as the message is forwarded out of the Oracle Communications Session Border Controller , includes icid-value in accounting records.

    • delete—Delete the P-Charging-Function-Address header received in an incoming SIP message before it is forwarded out of the Oracle Communications Session Border Controller .

    • insert—Insert the P-Charging-Function-Address header in an incoming SIP message that does not contain the P-Charging-Function-Address header. If the incoming message contains the P-Charging-Function-Address header, the Oracle Communications Session Border Controller will overwrite the P-Charging-Function-Address header with its values. This option always uses the ccf-address and ecf-address static values.

    • insert-reg-cache—To be configured on the SIP interface facing the UE, configures the Oracle Communications Session Border Controller to replace the PCFA with the most recently cached value rather than the ccf-address and ecf-address you set to be static in your configuration. The cached values come from one of the following that the Oracle Communications Session Border Controller has received most recently: request, response, registration, or local configuration.

    • delete-and-respond—To be configured on the SIP interface facing the P-CSCF, configures the Oracle Communications Session Border Controller to strip out the latest cached PCFA from the core side. The Oracle Communications Session Border Controller then remembers this PCFA and uses it in communications sent to the core.

    • conditional-insert—Configures the Oracle Communications Session Border Controller to perform the following functions, based on whether or not the header is present in the message when the Oracle Communications Session Border Controller receives it:
      • For incoming messages that have the associated header, the SBC uses pass mode.
      • For those that do not have the associated header, the SBC uses insert mode.

      Note:

      The default settings for this parameter and for charging-vector-mode are pass for new SIP interface configurations. If you are upgrading and there are pre-existing SIP interfaces in your configuration, the defaults become none.
  7. ccf-address—Set the CCF address value that will be inserted into the P-Charging-Function-Address header.
  8. ecf-address—Set the ECF address value that will be inserted into the P-Charging-Function-Address header.
  9. Save your work using the ACLI done command.

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.

Charging Correlation Configuration

To enable support for charging correlation:
  1. Navigate to ext-policy-server configuration mode. 
    ACMEPACKET(configure)# media-manager
ACMEPACKET(media-manager)# ext-policy-server
ACMEPACKET(ext-policy-server)#
  2. specific-action-subscription—Enables the system to subscribe to IMS action-specific notification services. By default, no subscriptions are enabled. Available subscriptions are:
    • charging-correlation-exchange
    • loss-of-bearer
    • recovery-of-bearer
    • release-of-bearer
    • out-of-credit
    • successful-resource-allocation
    • failed-resource-allocation 
    ACMEPACKET(ext-policy-server)# specific-action-subscription changing-correlation-exchange

    adds a single subscription 

    ACMEPACKET(ext-policy-server)# specific-action-subscription (changing-correlation-exchange loss-of-bearer recovery-of-bearer)

    adds multiple subscriptions

  3. Use done, exit, and verify-config to complete configuration.

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

  1. In Superuser mode, type configure terminal and press Enter. 
    ORACLE# configure terminal
  2. Type session-router and press Enter to access the session-level configuration elements. 
    ORACLE(configure)# session-router
ORACLE(session-router)#
  3. Type sip-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters. 
    ORACLE(session-router)# sip-interface
ORACLE(sip-interface)#
  4. Type select and the number of the pre-configured sip interface you want to configure. 
    ORACLE(sip-interface)# select 1
  5. Type network-id <space> <network ID string> and press Enter. This completes the configuration of the P-Visited-Network-ID string for a given SIP interface. 
    ORACLE(sip-interface)# network-id examplenetworkid
  6. Save your work using the ACLI done command.

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-for-emergency-calls 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

When the inbound INVITE contains 2 P-Asserted-Identity headers, the Oracle Communications Session Border Controller ensures that both outbound P-Asserted-Identity headers contain public user identities from the IRS according to the following:
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

  1. Navigate to the sip-config configuration element. 
    ACMEPACKET# configure terminal
ACMEPACKET(configure)# session-router
ACMEPACKET(session-router)# sip-config
ACMEPACKET(sip-config)#
  2. Type select to begin configuring this object. 
    ACMEPACKET(sip-config)# select
ACMEPACKET(sip-config)#
  3. options—Configure the add-second-pai-for-emergency-calls option: 
    ACMEPACKET(sip-config)# options +add-second-pai-for-emergency-calls
ACMEPACKET(sip-config)#
  4. Save and activate your configuration.