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

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:[e-mail]

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 (OCSBC) 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 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 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 (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 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 OCSBC uses pass mode.
     • For those that do not have the associated header, the OCSBC 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 OCSBC uses pass mode.
     • For those that do not have the associated header, the OCSBC 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

Version S-CZ7.2.0 provides support for the SIP P-Early-Media that can be used in SIP INVITES, PRACKS, and UPDATES to request and authorize the use of early media. It offers an alternative to policy-based early media support.

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.

P-Early-Media SIP Header

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.

P-Early-Media-Header Usage

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.

Functional Design

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.

P-Early-Media Trusted to Trusted

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

Message Parameters configured on egress interface	Request (Invite, UPDATE, PRACK) w/o header	Request (Invite, UPDATE, PRACK) with header with one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or"inactive"	Response (18x, 200OK(UPDATE/PRACK)) w/o header	Response (18x, 200OK(UPDATE/PRACK) with header with one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or"inactive"
p-early-media-header-"add" p-early-media-direction -"sendonly"	Add header with "supported" value. Setup flows based on SDP value	Add "supported" value if not present. Setup the flows based on the value in the SDP value.	Setup flows based on local config PEM value. Add the PEM header based on local config value. Status Flow AVP in AAR message updated.	Setup the flows based on the value in the incoming PEM header.
p-early-media-header-"modify" p-early-media-direction -"sendonly"	Add header with "supported" value. Setup flows based on SDP value	Add "supported" value if not present. Setup the flows based on the SDP value	Setup flows based on local config PEM value. Add the PEM header based on local config value. Status Flow AVP in AAR message updated.	Setup flows based on local config PEM value. Modify the PEM header based on local config value. Status Flow AVP in AAR message updated.
p-early-media-header-"add" No p-early-media-direction	Add header with "supported" value. Setup flows based on SDP value	Add "supported" value if not present. Setup the flows based on the SDP.	Setup flows based on local config PEM value. Add the PEM header based on default value. Status Flow AVP in AAR message updated.	Setup flows based on local config PEM value. Modify the PEM header based on default value. Status Flow AVP in AAR message updated.
p-early-media-header-"modify" No p-early-media-direction	Add header with "supported" value. Setup flows based on SDP value.	Add header with "supported" value if not present. Setup the flows based on the SDP.	config PEM value. Add the PEM header based on default value. Status Flow AVP in AAR message updated.	Setup flows based on local config PEM value. Modify the PEM header based on default value. Status Flow AVP in AAR message updated.

P-Early-Media Untrusted to Trusted

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

Message Parameters configured on egress interface	Request (Invite, UPDATE, PRACK) w/o header	Request (Invite, UPDATE, PRACK) with header with one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or"inactive"	Response (18x, 200OK(UPDATE/PRACK)) w/o header	Response (18x, 200OK(UPDATE/PRACK) with header with one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or"inactive"
p-early-media-header-"add" p-early-media-direction -"sendonly"	Add header with "supported" value. Setup flows based on SDP value	Discard the header. Add the header with supported value. Setup flows based on SDP value.	Setup flows based on local config PEM value. Add the PEM header based on local config value. Status Flow AVP in AAR message updated.	Discard the header. Setup flows based on local config PEM value. Add the PEM header based on local config value. Status Flow AVP in AAR message updated.
p-early-media-header-"modify" p-early-media-direction -"sendonly"	Add header with "supported" value. Setup flows based on SDP value	Discard the header. Add the header with supported value. Setup flows based on SDP value.	Setup flows based on local config PEM value. Add the PEM header based on local config value. Status Flow AVP in AAR message updated.	based on local config PEM value. Add the PEM header based on local config value. Status Flow AVP in AAR message updated.
p-early-media-header-"add" No p-early-media-direction	Add header with "supported" value. Setup flows based on SDP value.	Discard the header. Setup flows based on SDP value.	Setup flows based on local config PEM value. Add the PEM header based on default value. Status Flow AVP in AAR message updated.	Discard the header. Setup flows based on local config PEM value. Add the PEM header based on default value. Status Flow AVP in AAR message updated.
p-early-media-header-"modify" No p-early-media-direction	Add header with "supported" value. Setup flows based on SDP value	Discard the header. Setup flows based on SDP value.	Setup flows based on local config PEM value. Add the PEM header based on default value. Status Flow AVP in AAR message updated.	Discard the header. Setup flows based on local config PEM value. Add the PEM header based on default value. Status Flow AVP in AAR message updated.

P-Early-Media Trusted to Untrusted

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

Message Parameters configured on egress interface	Request (Invite, UPDATE, PRACK) w/o header	Request (Invite, UPDATE, PRACK) with header with one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or"inactive"	Response (18x, 200OK(UPDATE/PRACK)) w/o header.	Response (18x, 200OK(UPDATE/PRACK) with header with one or more direction parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or"inactive"
p-early-media-header-"add" p-early-media-direction -"sendonly"	Setup flows based on SDP value.	Discard the header. Setup flows based on SDP value.	Setup flows based on SDP value.	Discard the header. Setup flows based on local config PEM value. Status Flow AVP in AAR message updated.
p-early-media-header-"modify" p-early-media-direction -"sendonly"	Setup flows based on SDP value.	Discard the header. Setup flows based on SDP value.	Setup flows based on SDP value.	Discard the header. Setup flows based on local config PEM value. Status Flow AVP in AAR message updated.
p-early-media-header-"add" No p-early-media-direction	Setup flows based on SDP value.	Discard the header. Setup flows based on SDP value.	Setup flows based on SDP value.	Discard the header. Setup flows based on default PEM value. Status Flow AVP in AAR message updated.
p-early-media-header-"modify" No p-early-media-direction	Setup flows based on SDP value.	Discard the header. Setup flows based on SDP value.	Setup flows based on SDP value.	Discard the header. Setup flows based on default PEM value. Status Flow AVP in AAR message updated.

P-Early-Media ACLI Configuration

Use the following procedure to configure P-Early-Media SIP header support.

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.

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

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

4. Save and activate your configuration.