A profile allows you to create a specific set of characteristics different from the standard SBC 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.
To achieve efficient device failover to the backup/secondary Application Server, the SBC 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
Refer to the following pages for configuration details:
The SBC 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 refer to Call Admission Controls.
Refer to the following pages for configuration details:
The Cause Map Profile, SIP-to-CPC and CPC-to-SIP mappings provide customized tables on the SBC to map cause codes between SIP and Q.850 cause codes. Previously, these mappings were hard coded in the SBC. The custom mappings can be selected on a per route basis on egress trunks and ingress trunks on the SBC.
The SBC Core 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.
The PSX returns the Cause Code profile name in the POL responses. The SBC uses the Cause Code profile specified by PSX. If PSX fails to provide the Cause Code profile, the SBC uses the local Cause Code Mapping profile configured on the SIP Trunk Group.
The SBC applies the Cause Code Mapping profile in the following order:
If a policy response contains a profile name and a locally configured profile uses the same name, the SBC applies the same name.
If a policy response does not contain a profile name or if the profile name does not match with any local profile, the SBC applies the SIP Trunk Group created local profile name (if created).
The SBC applies a default profile name if none of the above two cases match.
The SBC supports SIP Cause Code Mapping for CPC to SIP for trunk groups regardless of the signaling zone.
The SBC does not support SIP Cause Code Mapping for CPC to SIP for trunk groups if the PSX enables the SIP_IN_CORE flag.
The PSX sends the SIP_USED_IN_CORE flag with the policy response to the egress SBC. If the egress SBC receives the SIP_USED_IN_CORE flag and the ingress zone of the egress SBC is in the default signaling zone, the egress SBC does not allow SIP Cause Code Mapping for CPC to SIP because the scenario is SIP In Core. If the PSX either is not present or does not enable the SIP_IN_CORE flag, then SIP Cause Code Mapping for CPC to SIP functions as if the SBC uses a non-default signaling zone. The following figure illustrates the SIP In Core call flow.
This SIP Cause Code Mapping for CPC to SIP function does not impact GW-GW call scenarios.
SIP in Core Call Flow
When the call flow uses a single SBC, the PSX always disables the SIP_IN_CORE flag and the SIP Cause Code Mapping for CPC to SIP occurs whether or not the SBC uses the default signaling zone.
The following figure illustrates the I-SBC call flow.
I-SBC Call Flow
Refer to the following pages for configuration details:
This object creates and configures an Emergency Call Profile for SIP calls used to host emergency call criteria. The emergency call classification methods are:
Refer to the following pages for configuration details:
JIP handling 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 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 headerjip
parameter in the PAI headerrn
parameter in the From headerjip
parameter in the P-DCS-Billing-Info headerNote 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 headerjip
parameter in the PAI headerrn
parameter in the From headerjip
parameter in the P-DCS-Billing-Info headerFor 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:
The Online Certificate Status Protocol (OCSP) enables SBC 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 SBC 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 SBC can act in TLS server role as well as TLS client role.
The SBC integrates OCSP status-checking as a part of certificate validation in OpenSSL library.
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.
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 SBC, 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 SBC is upgraded from a release which already supports OCSP, all the parameter values of existing OCSP profiles are retained after the upgrade completes.
SBC as a Server or Client
When this ICD refers to the SBC as a... | This term means the SBC... |
---|---|
Client | Initiates the TCP/TLS connection |
Server | Accepts the TCP/TLS connection |
OSCP stapling supports the following interworking scenarios:
The SBC that acts as a server checks if the OCSP response is available in the OCSP cache before the SBC queries the OCSP server. If the OCSP response is available in the OCSP cache, the SBC uses that OCSP response to send the response as a certificate status message. If the OCSP response is not available in the OCSP cache, the SBC queries the OCSP server to receive the OCSP response.
If the ingress peer sends a ClientHello with the "status_request: OCSP" status request extension to the SBC (as a server) and you
enable the ocspStapling
flag in the ingress OCSP profile, the SBC sends an OCSP request to the OCSP responder and receives the OCSP response. The SBC stores the OCSP response in the OCSP cache before it sends the OCSP response as a certificate status message to the ingress peer.
The SBC does not send a certificate status message to the client when the SBC receives a failure response from the OCSP responder. The client must use another mechanism to verify the validity of the server certificate.
ocspStapling
flag in the ingress OCSP profile, the SBC does not send a certificate status message to the ingress peer. The SBC ignores the OCSP status extension.The ocspStapling
flag automatically disables if the ocspProfile state
flag is disabled
.
The ClientHello is the first message the ingress peer sends to the SBC while the ingress peer initiates the Transport Layer Security (TLS) connection to the SBC.
When the SBC enables mutual authentication and receives a ClientHello with the "status_request: OCSP" status request extension, the SBC sends the client the OCSP response as a certificate status message.
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 SBC sends an OCSP request to the OCSP responder and receives the OCSP response. The SBC then sends the OCSP response as a certificate status message to the ingress peer.
When the SBC acts as a client and you enable the ocspStapling
flag in the egress OCSP profile, the SBC sends a ClientHello with the "status_request: OCSP" status request extension to the egress TLS peer. When the SBC acts as a client and you disable the ocspStapling
flag in the egress OCSP profile, the SBC does not send a ClientHello with the "status_request: OCSP" status request extension to the egress TLS peer.
When the SBC acts as a client, the SBC checks the certificate status message received from the server for the validity of the server certificate. If the server certificate status is
The following figure illustrates the OCSP stapling call flow.
OCSP Stapling Call Flow
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
Existing DNS CLIs add dynamic ACLs for the configured DNS servers.
Refer to the following pages for command details:
The SIP Security Profile feature defines the type and behavior of security mechanism to apply to the SBC acting as P-CSCF.
Refer to the following pages for command details:
Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
The SBC 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.
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:
The SBC supports configuring up to 256 Transparency Profiles. By default, no headers are present in the Transparency Profile.
Do not enable "unknownHeader" flag if using this feature.
Refer to the following pages for command details:
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 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: