Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Add_workflow_for_techpubs
AUTH2
AUTH1
REV5
REV6
REV3
REV1

Noprint
Panel
borderColorgreen
bgColortransparent
borderWidth2

Back to Table of Contents

Back to SIP Services

...


...

Panel

In this section:

Table of Contents

...

Info

...

icon

...

 

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

Spacevars
0product
defaults. When defining a new instance of one of these objects, simply use the profile to quickly customize the values. A brief summary of SIP profiles is provided below.

SIP ARS Profile

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

Spacevars
0product
uses the Address Reachability Service (ARS) to determine if a server is reachable, providing the ability to "blacklist" a server IP address if it is found to be unreachable, as well as the ability to remove the server from the blacklisted state. ARS profiles can be created to configure blacklisting and recovery algorithm variants.

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

See the following pages for configuration details:

SIP Call Admission Control Profile

The

Spacevars
0product
provides call and registration admission control for SIP calls and SIP registrations at the zone level, SIP trunk group level, and SIP endpoint level. For more information see Call Admission Controls topic.

See the following pages for configuration details:

SIP/CPC Cause Code Mapping Profiles

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

Spacevars
0product
to map cause codes between SIP and Q.850 cause codes. Previously, these mappings were hard coded in the
Spacevars
0product
. The custom mappings can be selected on a per route basis on egress trunks and ingress trunks on the
Spacevars
0product
.

Excerpt
Info
titleInfo

Spacevars
0series4
supports up to 64 SIP-to-CPC and 64 CPC-to-SIP cause code mapping profiles.

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

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

Spacevars
0product
uses the Cause Code profile specified by PSX. If PSX fails to provide the Cause Code profile,
Spacevars
0product
uses the local Cause Code Mapping profile configured on the SIP Trunk Group.

Spacevars
0product
applies the Cause Code Mapping profile in the following order:

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

    Spacevars
    0product
    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,

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

  3. Spacevars
    0product
    applies a default profile name if none of the above two cases match.

See the following pages for configuration details:

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 see Call Admission Controls topic.
  • 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.

See the following pages for configuration details:

SIP JIP Profile

 

Note
iconfalse
titleNote
JIP is only supported when using an external PSX in the network.

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

The inclusion of the JIP parameter in SIP INVITE message allows the 

Spacevars
0product
to support interworking of Jurisdiction information (JIP) for SIP-SIP and SIP-SIP-I, and vice versa, including GW-GW by sending and receiving JIP in the PAI/FROM/PDCS header. The SBC can interwork JIP across gateway to GSX as well.

JIP information can be carried in the P-Asserted-ID/FROM and P-DCS-Billing-Info headers of SIP INVITE message and in the PDCS header in a 3xx response. The

Spacevars
0product
records JIP-related details in the Call Detail Record.

Multiple controls can be enabled at a time to select the header or parameter from which JIP value will be extracted. When multiple controls are configured, JIP information is extracted in the following order:

  • RN PARAMETER IN PAI
  • JIP PARAMETER IN PAI
  • RN PARAMETER IN FROM
  • JIP PARAMETER IN PDCS

See the following pages for configuration details:

SIP OCSP Profile

The Online Certificate Status Protocol (OCSP) enables

Spacevars
0product
applications to determine the revocation status of a given certificate. OCSP is used to satisfy some of the operational requirements of providing timely revocation information.

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

Spacevars
0product
supports adding OCSP configuration to an existing/new TLS profile, and performing automatic OCSP checking in OpenSSL library without making substantial changes to OCSP clients (SIPFE, etc.). The OCSP clients may be involved when OCSP checking returns errors. The user may create up to four OCSP profiles per system as described in "Key Concepts" section below.

The

Spacevars
0product
can act in TLS server role as well as TLS client role.

  • As a TLS server with Client Authentication enabled, the
    Spacevars
    0product
    checks OCSP status when the TLS client sends its certificate chain to the
    Spacevars
    0product
    . Upon receiving Certificate Verify from client, the
    Spacevars
    0product
    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
    0product
    . The
    Spacevars
    0product
    then performs OCSP status checking for each certificate in the chain.
Note
iconfalse
titleNote

The

Spacevars
0product
integrates OCSP status-checking as a part of certificate validation in OpenSSL library.

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 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.
Note
iconfalse
titleNote
The configured default responder may point to the certificate authority (CA) that issued the certificate in question, a Trusted Responder whose public key is trusted by the
Spacevars
0product
, or a CA Authorized Responder (or Delegated Trust Responder in UCR term) that is designated by one or more CAs.

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

Spacevars
0product
is upgraded from a release which already supports OCSP, all the parameter values of existing OCSP profiles are retained after the upgrade completes.

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.

Code Block
% 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
Note
iconfalse
titleNote

Existing DNS CLIs add dynamic ACLs for the configured DNS servers.

See the following pages for command details:

SIP Security Profile

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

Spacevars
0product
acting as P-CSCF.

See the following pages for command details:

Transparency Profile

...

Spacevars
0product

...

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

The  supports flexible header transparency feature which allows a user to define a set of SIP header names using a configuration interface to the Transparency Profile (TP), and then assign that profile to a Trunk Group (TG). For example, if a header name is in the TP corresponding to the egress leg (respective to the message), it is passed through unmodified with its full content, including all parameters. This applies to all initial INVITE, REGISTER and mid-INVITE initiated dialog requests and responses (excluding mid-dialog SUBSCRIBE requests and responses sent in the context of an existing dialog). Corresponding relay flags for other mid-dialog requests (e.g. INFO, MESSAGE, NOTIFY) must be enabled for this functionality to work.

Note
iconfalse
titleNote
Headers are also configurable in compact form, and may be transparently passed by configuring a Transparency Profile. It is advisable to configure both compact and long formats to ensure both types of received headers in the PDU are transparently passed.

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.

This dynamic transparency capability applies to SIP-SIP, SIP-GW and GW-SIP scenarios. GW-GW is supported only between the same GW versions.

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

Spacevars
0product
supports configuring up to 256 Transparency Profiles. By default, no headers are present in the Transparency Profile.

Note
iconfalse
titleNote
Do not enable "unknownHeader" flag if using this feature.

See the following pages for command details:

Pagebreak