Page History

A profile allows you to create a specific set of characteristics different from the standard

SIP ARS Profile

To achieve efficient device failover to the backup/secondary Application Server, the

These ARS profiles can be assigned to the services section of a SIP trunk group to enforce the blacklisting and recovery of any SIP peer(s) associated with the trunk group. If no recovery algorithm is specified when configuring a SIP ARS profile, the recovery algorithm default values are used as indicated below:

• recoveryAlgProbeDuration: 1 second
• recoveryAlgProbeInterval: 1 second
• recoveryAlgProbeMethod: sip-options
• recoveryAlgProbeNumResponses: 1
• recoveryAlgTimerDuration: 1 second
• recoveryAlgorithm: probe

Refer to the following pages for configuration details:

• EMA: Service Profiles - SIP ARS Profile
• CLI: SIP ARS Profile - CLI

SIP Call Admission Control Profile

The

Refer to the following pages for configuration details:

• EMA: Profiles - SIP CAC Profile
• CLI: SIP CAC Profile - CLI

SIP/CPC Cause Code Mapping Profiles

The Cause Map Profile, SIP-to-CPC and CPC-to-SIP mappings provide customized tables on the

The following IPSP configurations are added to PSX under SIP Cause Mapping section to specify the Cause Code Mapping profile name.

• Internal to SIP Cause Mapping Profile Name
• SIP to Internal Cause Mapping Profile Name

The PSX returns the Cause Code profile name in the POL responses. The 

The 

1. If a policy response contains a profile name and a locally configured profile uses the same name, the 

   Spacevars
   0 product

   applies the same name.

2. If a policy response does not contain a profile name or if the profile name does not match with any local profile, the 

   Spacevars
   0 product

   applies the SIP Trunk Group created local profile name (if created).

3. The 

   Spacevars
   0 product

   applies a default profile name if none of the above two cases match.

The

The PSX sends the SIP_USED_IN_CORE flag with the policy response to the egress

When the call flow uses a single

The following figure illustrates the I-

Refer to the following pages for configuration details:

• EMA: Signaling Profiles - SIP Cause Code Mapping
• CLI: SIP/CPC Cause Code Mapping Profiles

SIP Emergency Call Profile

This object creates and configures an Emergency Call Profile for SIP calls used to host emergency call criteria. The emergency call classification methods are:

• Emergency Call Marking: The cpc-priority in P-Asserted Identities is present in the INVITE message, and the CPC parameter of the SIP EMERGENCY PROFILE is set to “priority”.
• Prefix Matching (up to three prefixes): At least one of the three emergency prefixes is configured in SIP EMERGENCY PROFILE and the R-URI header in the INVITE message matches one of the three emergency prefixes. The emergency prefix is an alphanumeric string that consists of numeric digits (phone number). For more information refer to Call Admission Controls.
• URN Prefix: Emergency prefix URN, for example “services:sos”.
• X-EMG Header: Use this flag to determine whether SIP X-EMG header should be accepted as an emergency call indicator.

Refer to the following pages for configuration details:

• EMA: Service Profiles - Emergency Call Profile
• CLI: Emergency Call Profile - CLI

SIP JIP Profile

The Jurisdiction Information Parameter (JIP) is a 6-digit field (NPA-NXX format) in an ISUP IAM message used to indicate the geographic location of the originating caller or switch. This information may be used in billing. 

The SBC supports sending JIP information in SIP-SIP, SIP-SIP-I and SIP-I to SIP scenarios. This capability is enabled/disabled through the SIP Jurisdiction Support option (sipJurisdictionSupport flag) set in the SIP trunk group, and specific processing details are controlled through the SIP JIP profile assigned to the trunk group.

When SIP Jurisdiction support is enabled, options in the SIP JIP profile assigned to the ingress SIP trunk group specify where to extract the SIP JIP value from in an incoming SIP INVITE message. The SBC can take the JIP value from the following parameters:

• rn parameter in the PAI header
• jip parameter in the PAI header
• rn parameter in the From header
• jip parameter in the P-DCS-Billing-Info header

Note that if a SIP JIP profile enables more than one possible source parameter, the SBC prioritizes them in the order shown above.

The SBC sends the JIP value it extracts to the external PSX. Based on its configuration, the PSX determines what JIP value should be sent out and returns this value to the SBC.

In the outgoing message, the SBC sends the JIP it received from the PSX in the parameter specified in the SIP JIP profile assigned to the egress SIP trunk group. The parameter options are the same as the source choices:

• rn parameter in the PAI header
• jip parameter in the PAI header
• rn parameter in the From header
• jip parameter in the P-DCS-Billing-Info header

For cases when the JIP value is sent in a P-DCS-Billing-Info header, the SIP trunk group also includes a parameter (feidForPDCS) in which you can specify a Financial-Entity-ID (FEID) to be sent out in the egress PDCS-Billing-Info header. An FEID consists of hexadecimal string of up to 16 characters followed by a domain name. 

The SBC records JIP-related details in the Call Detail Record.

Refer to the following pages for configuration details:

• EMA: Service Profiles - SIP JIP Profile
  
• CLI: SIP JIP Profile - CLI
  

SIP OCSP Profile

The Online Certificate Status Protocol (OCSP) enables

When a peer sends certificates, an OCSP client (e.g. SIPFE) issues a status request to an OCSP responder and suspends acceptance of the certificates in question until the responder provides a response. The OCSP client needs the address/URL of the OCSP responder, the certificate to be checked, and the certificate issuer’s certificate. The OCSP URL can be FQDN or IPv4 address plus port number.

The

The

• As a TLS server with Client Authentication enabled, the

  Spacevars
  0 product

  checks OCSP status when the TLS client sends its certificate chain to the

  Spacevars
  0 product

  . Upon receiving Certificate Verify from client, the

  Spacevars
  0 product

  performs OCSP status checking for each certificate in the chain after validating signature, expiration time, etc. for each certificate in the chain.
• When acting as a TLS client, SBC checks OCSP status when the peer TLS server sends its certificate chain to the

  Spacevars
  0 product

  . The

  Spacevars
  0 product

  then performs OCSP status checking for each certificate in the chain.

Key Concepts

The user may create up to four OCSP profiles per system, each specifying the OCSP capabilities and protocol parameters applying to one or more TLS connections that use the profile (a SIP/TLS connection may reference an OCSP profile in its assigned TLS profile). The OCSP profile is referenced by the existing TLS profile.

• OCSP capability
  • enabled
  • disabled (default)
• Default responder URI (default: blank):
  
  • IPv4 address and port number, or
  • FQDN
• AIA override:
  • enabled - Forces the use of configured Default responder for OCSP validation regardless of whether or not the certificate being validated references a responder by AIA.
  • disabled (default) - The responder referenced via AIA by the certificate being validated is used, or the Default responder as configured is used only if the AIA is not available.
• OCSP Stapling
  
  • disabled (default)
  • enabled
• OCSP response waiting time - If the corresponding OCSP response does not return before the time expires after sending an OCSP request, the response is considered unavailable.
  
  • Range: 1-16 seconds. Default: 2.
• OCSP Response Caching Timer
  • Range: 1-30 days. Default: 1.

When configuring an OCSP profile, be aware that you may delete a given OCSP profile when it is not referenced by any TLS connections.

When OCSP is enabled for a TLS connection, every individual certificate in the chain presented by the peer device during the establishment of the connection is validated against an OCSP responder for its revocation status.

When the

OCSP Stapling

The

If the ingress peer sends a ClientHello with the "status_request: OCSP" status request extension to the

• enable the ocspStapling flag in the ingress OCSP profile, the

  Spacevars
  0 product

  sends an OCSP request to the OCSP responder and receives the OCSP response. The

  Spacevars
  0 product

  stores the OCSP response in the OCSP cache before it sends the OCSP response as a certificate status message to the ingress peer.

  Info
  title Note
  The Spacevars 0 product does not send a certificate status message to the client when the Spacevars 0 product receives a failure response from the OCSP responder. The client must use another mechanism to verify the validity of the server certificate.

  
  

• disable the ocspStapling flag in the ingress OCSP profile, the

  Spacevars
  0 product

  does not send a certificate status message to the ingress peer. The

  Spacevars
  0 product

  ignores the OCSP status extension.

When the

If the ingress peer sends a ClientHello with the "status_request: OCSP" status request extension, and both mutual authentication and the ocspStapling flag are enabled in the ingress OCSP profile, the

When the

When the

• good, the

  Spacevars
  0 product

  establishes a TLS connection with the egress peer.
• revoked, the

  Spacevars
  0 product

  does not establish a TLS connection with the egress peer.
• unknown, the

  Spacevars
  0 product

  establishes a TLS connection with the egress peer and logs a major log that indicates the status is unknown in the debug file.
  

The following figure illustrates the OCSP stapling call flow.

Linux DNS Client Support

Linux DNS client functionality is required for OpenSSL OCSP API to translate a FQDN to an IPv4 address. To populate the file with DNS server addresses, use following CLI commands.

% set addressContext default dnsGroup d1 type mgmt server dns1 ipAddress 10.11.12.13 state enabled
% set addressContext default dnsGroup d1 type mgmt server dns2 ipAddress 10.11.12.15 state enabled

Refer to the following pages for command details:

• EMA: Security Configuration - Ocsp Profile
• CLI: OCSP Profile - CLI

SIP Security Profile

The SIP Security Profile feature defines the type and behavior of security mechanism to apply to the

Refer to the following pages for command details:

• EMA:  Service Profiles - Sip Security Profile
• CLI: SIP Security Profile - CLI

Transparency Profile

The

If a header is not in the transparency configurable, existing “Unknown Header Transparency” and explicit header transparency flag semantics shall apply.

This feature allows you to add previously “unknown” headers to the TP making them “semi-known” to the system, as well as add “known” headers thus eliminating the need for IP Signaling Profile (IPSP) transparency control flags for those headers. An "unknown" header is defined as a header that, if present in an incoming SIP message, is parsed as a generic “unknown” header, but is treated as a “known” header with respect to transparency by allowing individual transparency control towards it.

If you configure a Contact header in the Transparency Profile, it is treated as full contact header transparency.

Support for known headers (with or without IPSP transparency flags) is available for INVITE, REGISTER and OOD messages. Support for selective unknown header transparency is available for INVITE, REGISTER messages.

The following message body headers cannot be used when configuring a Transparency Profile:

• Content-Encoding
• Mime-Version
• Content-Disposition

The

Refer to the following pages for command details:

• EMA: Service Profiles - Transparency Profile
• CLI: Transparency Profile - CLI

SIP Adaptor Profile - Rich Call Data

Rich Call Data (RCD) is intended as a tool to help persuade called parties to answer their phone. It shows the name of the caller, along with other optional elements such as a company logo or photograph. This information is included in SIP signaling. A drawback to this method is that the information can be spoofed.

To overcome this, a new specification is introduced in which the RCD is cryptographically signed by the originating network and delivered to the terminating network. The terminating network verifies and validates the signature. If the signature passes verification and validation, the terminating network passes the RCD to the called party, and the called party can trust the information rendered on the device and answer the call accordingly.

The main goal of this feature is to enhance the SBC perform signing and verification of the RCD, so that the SBC sends verified call and caller information in the egress INVITE and the device of the called party can render this information before the call is answered. When STIR/SHAKEN functionality is enabled at the SBC, it will send certain signaling parameters received in the INVITE – such as the calling number, called number, display name, RPH, and the identity header – to to the PSX over the D+ interface using specific AVPs. In order to support RCD, the SBC will also need to send 'Call-Info' header parameters like the 'jcard' and 'call-reason' to the PSX when present. The PSX gives verified RCD data in the D+ response, and the SBC includes verified RCD data in the egress INVITE. 

Refer to the following page for command details:

• CLI: SIP Adaptor Profile - CLI