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.

1. The OCSBC constructs the icid-value in the following format:

   icid-value=<unique string>

   The unique string is a value created by the OCSBC 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 OCSBC.
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 OCSBC 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 OCSBC 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.

   

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;

The P-Charging-Function-Address header is composed of two configurable parameters: ccf, ecf. You can configure the Oracle Communications Session Border Controller (OCSBC) 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC receives it.

In addition, the OCSBC 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:

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 OCSBC 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 OCSBC and accounting information. Such requests do not have a To tag, and responses do not appear in established dialogs. The OCSBC 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 OCSBC uses the latest cached copy of a PCFA header to insert into requests and responses. The OCSBC 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 OCSBC 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 OCSBC 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: ccf=192.168.0.20 ; ecf=192.168.0.21;

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.

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.

The P-Early-Media SIP header is defined in RFC 5009, Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media. RFC 5009 defines the use of the P-Early-Media header within SIP messages in certain SIP networks to authorize the cut-through of backward (server-to-client) and/or forward (client-to-server) early media when permitted by the early media policies of the networks involved. The P-Early-Media header field is intended for use in a SIP network, such as a 3GPP IMS that has the following characteristics: its early media policy prohibits the exchange of early media between end users; it is interconnected with other SIP networks that have unknown, untrusted, or different policies regarding early media; and it has the capability to gate (enable/disable) the flow of early media to/from user equipment.

A SIP network containing both PSTN gateways and SIP end devices, for example, can maintain such an early media policy by gating "off" any early media with a SIP end device acting as UAS, gating "on" early media with a SIP end device acting as UAC, and gating "on" early media at each PSTN gateway. This is what we have been doing for years with the SIP early media suppression feature, which allows determining who can send early media and in what direction.

Unfortunately, in SIP interconnection scenarios there is no means of assuring that the interconnected network is implementing a compatible early media policy, thus allowing the exchange of user data within early media under some circumstances. For example, if a network "A" allows all early media with user equipment as UAC and an interconnected network "B" allows all early media with user equipment as UAS, any session established between user equipment as UAC in "A" and user equipment as UAS in "B" will allow bidirectional user data exchange as early media.

The P-Early-Media header is used for the purpose of requesting and authorizing requests for backward and/or forward early media. It’s sent from UAS to UAC to indicate authorization for early media.

The syntax of the P-Early-Media header field is as follows.

P-Early-Media = "P-Early-Media" HCOLON[ em-param *(COMMA em-param) ] 
       em-param  = "sendrecv" / "sendonly" / "recvonly" / "inactive" / "gated" /  
      "supported" / token

The P-Early-Media header is used for requesting and authorizing requests for backward and/or forward early media. The P-Early-Media header field in an INVITE request contains the "supported" parameter. If P-CSCF is part of the trusted domain, then it must decide whether to insert or delete the P-Early-Media header field before forwarding the INVITE. The P-CSCF upon receiving the P-Early-Media header field in a message towards the UAC needs to verify that the early media request comes from an authorized source. If a P-Early-Media header field arrives from either an untrusted source, a source not allowed to send backward early media, or a source not allowed to receive forward early media, then it may remove the P-Early-Media header field or alter the direction parameter(s) of the P-Early-Media header field before forwarding the message, based on local policy.

The P-Early-Media header field with the "supported" parameter in an INVITE request indicates that the P-CSCF on the path recognizes the header field. The P-Early-Media header field includes one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following the convention used for SDP stream directionality. Each parameter applies, in order, to the media lines in the corresponding SDP messages establishing session media. The parameter value "sendrecv" indicates a request for authorization of early media associated with the corresponding media line, both from the UAS towards the UAC and from the UAC towards the UAS. The value "sendonly" indicates request for authorization of early media from the sender to the receiver and not in the other direction. The value "recvonly" indicates a request for authorization of early media from the receiver, and not in the other direction. The value "inactive" indicates either a request that no early media associated with the corresponding media line be authorized, or a request for revocation of authorization of previously authorized early media. Each parameter applies, in order, to the media lines in the corresponding SDP lines. Unrecognized parameters are discarded and non-direction parameters are ignored. If there are more direction parameters than media lines, the excess are silently discarded. If there are fewer direction parameters than media lines, the value of the last direction parameter applies to all remaining media lines. The P-Early-Media header field in any message within a dialog towards the sender of the INVITE request can also include the non-direction parameter "gated" to indicate that a network entity on the path towards the UAS is already gating the early media, according to the direction parameter(s).

As defined in 3GPP TS 24.229, IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 both the P-CSCF and IBCF may add, remove, or modify, the P-Early-Media header field within forwarded SIP requests and responses according to procedures in RFC 5009.

The P-CSCF can use the P-Early-Media header field for the gate control procedures, as described in 3GPP TS 29.214. Prior to Version S-CZ7.2.0, this capability was based on policy configuration, not examination of the P-Early-Media header.

In the current implementation, if the configuration option “early-media-allow” is set to none, the Oracle Communications Session Border Controller will send the Flow-Status AVP in any AAR request set to disable until the final response.

Acceptance of and authorization for early media is accomplished with two new ACLI parameters -- p-early-media-header and p-early-media-direction, which are added to SIP interface configuration in Version S-CZ7.2.0 and later releases.

The p-early-media-header parameter will enable the feature when the value is set to either “add” or “modify”. The p-early-media-header and p-early-media-direction should be configured on egress interface of the incoming message. The values for parameter p-early-media-direction are “sendrecv, sendonly, recvonly, inactive”. It is a list and each configured value corresponds to the m-line in the SDP. If the number of configured values is more than the number of m-lines in the SDP, the excess configured values are ignored. If the number of configured value is less than the number of m-lines in the SDP, the last configured value is used for all the m-lines.

The following illustrations show the ingress and egress sip-interface configuration.

Figure 18-15 180 RINGING Specifying p-early-media Support

P-Early-Media headers in Re-Invites are ignored. If the SDP contains Content-Disposition: early-session the P-Early-Media header is ignored.

Endpoint is considered trusted or untrusted based on the configuration on the ingress sip-interface of the P-CSCF. Sip-interface has the configuration parameter “trust-mode”. If the “trust-mode” is set to “none” then nobody is trusted in sip-interface. By default the value is “all”. Possible values are <all, agents-only, realm-prefix, registered, none>.

For multiple dialogs due to forking, P-CSCF will identify the media associated with a dialog, and then setup early media flow for the selected media. The configuration elements restricted-latching in realm-config, and latching in media-router should be enabled.

The following 3 tables detail early media implementation details.

This table illustrates the P-CSCF case when messages are received from trusted endpoints and forwarded to trusted endpoints.

This table illustrates the P-CSCF case when messages are received from untrusted endpoints and forwarded to trusted endpoints.

This table illustrates the P-CSCF case when messages are received from trusted endpoints and forwarded to untrusted endpoints.

1. Access the sip-interface configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# sip-interface
   ORACLE(sip-interface)# 
   

2. Select the sip-interface object to edit.

   ORACLE(sip-interface)# select
   <RealmID>:
   1: realm01 172.172.30.31:5060
   
   selection: 1
   ORACLE(sip-interface)#

3. Use the p-early-media-header parameter to enable P-Early-Media SIP header support. This parameter is disabled by default.
   • disabled—(the default value) disables support
   • add—enables support and allows the Oracle Communications Session Border Controller to add the P-Early-Media header to SIP messages.
   • modify—enables support and allows the Oracle Communications Session Border Controller to modify or strip the P-Early-Media header in SIP messages.

   ACMEPACKET(sip-interface)# p-early-media-header add
   ACMEPACKET(sip-interface)#

4. Use the p-early-media-direction parameter to specify the supported directionalities.
   • sendrecv—send and accept early media
   • sendonly—send early media
   • recvonly—receive early media
   • inactive—reject/cancel early media

   ACMEPACKET(sip-interface)# p-early-media-direction sendrecv,sendrecv
   ACMEPACKET(sip-interface)#

5. Type done to save your configuration.

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

   ACMEPACKET(sip-config)# options +add-second-pai
   ACMEPACKET(sip-config)#

4. Save and activate your configuration.