In this section:
Default values are enclosed in square brackets [ ].
The parameter generateRtcpForT140IfNotReceivedFromOtherLeg
is added to packetServiceProfile rtcpOptions rtcp
. When the parameter is set to enable
, the SBC generates RTCP for T140 media streams if RTCP is not received from peer.
For more information, refer to the following pages:
To configure the parameter generateRtcpForT140IfNotReceivedFromOtherLeg
, use the following syntax:
set profiles media packetServiceProfile <packetServiceProfile_name: INGRESS> rtcpOptions rtcp <disable | enable> generateRtcpForT140IfNotReceivedFromOtherLeg <disable | enable>
The SBC is enhanced to support a Public Key-based peer authentication method for IPSec on SBC. In past releases, the SBC used a Preshared key-based authentication method for Peer authentication during IKE negotiation for establishing IKE and IPSec Security associations. To meet Common Criteria certification requirements, the SBC is now capable of using x.509 digital certificates for Peer authentication. Note: Not currently supported on SBC Cloud and D-SBC platforms.
For more information, refer to IPsec Peer - CLI.
% set addressContext default ipsec peer <peerName> authType <psk | rsaSig> % set addressContext default ipsec peer <peerName> localCertificate <sbcCertName> % set addressContext default ipsec peer <peerName> remoteCertificate <peerCertName> % set addressContext default ipsec peer <peerName> remoteCaCertificate <caCertName1>
Parameter | Default | Description | M/O |
---|---|---|---|
authType | psk | The authentication method – preshared key (psk) or rsa signature (rsaSig). | M |
localCertificate | n/a | The name of local (SBC) Certificate. | M |
remoteCertificate | n/a | The name of remote (IPSec Peer) Certificate. | M |
remoteCaCertificate | n/a | The name of remote CA Certificate referred by the IPSec peer entry. | O |
The SBC is enhanced with the parameter maxNumTransfers
under the object global signaling
.
For more information, refer to Signaling - Global - CLI and Show Table Global.
To configure maxNumTransfers
, use the following syntax:
% set global signaling maxNumTransfers <10-100>
To configure maxNumTransfers
, use the following example:
% set global signaling maxNumTransfers 30
To display the maxNumTransfers
, use the following example:
In the "configure" mode:
% show global signaling maxNumTransfers maxNumTransfers 30
In the "display" mode (when you exit the "configure" mode):
> show table global signaling maxNumTransfers 30; messageManipulation { inputAdapterProfile DD1; outputAdapterProfile DD1; } sipPeerOverloadControl { samplingPeriod 2; discardPeriod 2; stepDownGain 100; rejectThreshold 1; } sipSigControls { registrarSupportContactParam enabled; maxPduSizeValue pdusize15kb; }
The SBC is enhanced to support a new parameter "Generate Recording CDR" to the OAM > Accounting > Admin. When the "Generate Recording CDR" parameter is enabled, the SBC generates a Recording-CDR. The selected CDR is placed in the .ACT files along with the other call and Event CDRs. All the file size and CDR count rules of the existing CDRs apply to the Recording CDRs.
For more information, refer to Packet Service Profile - CLI.
% set oam accounting admin generateSipRecordingCdr <disabled | enabled>
Parameter Name | Default Value | Optional or Required? | Parameter Description |
---|---|---|---|
| disabled | Optional | Enables or disables generation of CDRs for recording SIP calls. |
The ATIS specification defines an optional capability to signal verification failures in backward provisional responses. If a terminating carrier B fails verification for an originating carrier A subscribers, but continues to deliver the call to the carrier B called party, carrier A will have no way to know. The terminating carrier can use failed verification to indicate robocalling status to the called party. In this case, carrier A has no way to know that their subscribers' calls are being flagged as robocalls to the terminating party.
The capability described in the ATIS specification solves this issue if carrier A has tools in place to find these indications in the SIP messaging.
Trunk-group-level SIP cause value reporting should include counts for each unique case value transmitted. These statistics already exist for the Reason header transmitted at the end of the call; however, this would additionally count the cause values send in the 18x/200 for STIR/SHAKEN.
New STI Profile flag overWriteReasonCodeIn4xxto6xx
added regarding 4xx-6xx handling.
For more information, refer to STI Profile - CLI.
% set profiles services stiProfile <profile_name> overWriteReasonCodeIn4xxto6xx <disabled | enabled>
Parameter | Length/Range | Default | Description | M/O |
---|---|---|---|---|
overWriteReasonCodeIn4xxto6xx | 1 | disabled | This parameter controls whether to Insert Reason Code from PSX or not in case of 4XX/5XX/6XX responses
| O |
A parameter, t140RtcpMonitorInterval
, is added under mediaRTCPControl to define the RTCP monitoring interval. This enables the SBC to wait for an RTCP packet from peer before starting RTCP towards T.140 endpoint with the following PSP flag enabled.
A flag, generateRTCPForT140IfNotReceivedFromOtherLeg,
is added under RTCP Options in the Packet Service Profile so that the SBC is able to configure specific trunk groups to generate RTCP on T.140 to T.140 passthrough media streams. The SBC will start generating RTCP for T.140 stream if RTCP is NOT received from the endpoint.
For more information, refer to Packet Service Profile - CLI and Media System - CLI.
% set system media mediaRtcpControl t140RtcpMonitorInterval 6 % set profiles media packetServiceProfile DEFAULT rtcpOptions generateRtcpForT140IfNotReceivedFromOtherLeg enable
The synchronization source (SSRC) identifier uniquely identifies media streams within an RTP session and is included in SDP signaling when establishing or modifying media sessions. The WebRTC specification requires that the SSRC value in an RTP stream match the SSRC sent in the SDP. However some endpoints, such as PSTN gateways, are not capable of generating SSRC values so they are not present in the SDP. Other endpoints change the SSRC during call hold/resume scenarios. The SBC provides two flag parameters to the Packet Service profile to determine whether the SBC generates and updates the SSRC and related attributes.
For more information, refer to Packet Service Profile - CLI.
The SBC adds the following two flags to the Packet Service profile.
% set profiles media packetServiceProfile <profile name> flags generateAndSignalSSRCAndCname <disabled | enabled> allowMidCallSSRCModification <disabled | enabled>
The SBC only allows mid-call modifications to the SSRC if it is generating the SSRC. Therefore, the first parameter, generateAndSignalSSRCAndCname
, must be enabled for the second parameter, allowMidCallSSRCModification,
to become available.
Parameter | Description |
---|---|
| Enable this flag to generate an SSRC value and associated attributes and include them in SDP signaling and RTP/RTCP streams. Options are:
Note: This flag takes precedence over the Packet Service Profile |
| Enable this flag so that in call hold/resume scenarios the SBC modifies the SSRC and associated attributes after the call resumes. The SBC sends both the previous and updated SSRC in SDP signaling and includes the new SSRC iin RTP/RTCP streams. Options are:
Note: You must enable the Note: If you enable the IP Signaling profile common IP attributes flag |
The rcodeErrorMonitorTimer
parameter is added to the DNSGroup
configuration to support monitoring timer interval which the SBC Core uses to monitor RCODE errors.
For more information, refer to DNS Group - CLI
% set addressContext <address_context_name> dnsGroup <dnsgroup> rcodeErrorMonitorTimer <rcode_error_monitor_timer>
The SBC is enhanced to allow writing accounting files containing CDRs into a compressed format. The compressed files are retained for a user-specified time period; thereafter, they are automatically deleted after a specified number of days. The compressed files are stored in the evlog
directory or another directory that you specify.
For more information, refer to Event Log - CLI
% set oam eventLog typeAdmin acct compressionSupport <both | none | only> compressionDaysToKeep <1 .. 7> compressionCleanupDirectory
Parameter | Length/Range | Default | Description | M/O |
---|---|---|---|---|
compressionSupport | N/A | Type of compression.
| ||
compressionDaysToKeep | 1-7 | 5 | The number of days to keep compressed files before deleting. | |
compressionCleanupDirectory | N/A | N/A | Alternate directory name (containing no slashes) under the log file directory from which compressed files are removed after compressionDaysToKeep days elapse. |
The following is the full syntax to create a SIP ARS profile, including the new recoveryAlgForTimeouts
and recoveryAlgForNoRetryAfter
options and their parameters for selecting the ARS recovery algorithm for each blacklist algorithm.
For more information, refer to SIP ARS Profile - CLI.
Ensure the ARS profile is configured with the recovery algorithms specified in the recovery flags.
set profiles services sipArsProfile <Profile Name> recoveryAlgForTimeouts < probe | timer | none >
set profiles services sipArsProfile <Profile Name> recoveryAlgForNoRetryAfter < probe | timer | none >
% set profiles services sipArsProfile <profile name> blkListAlgRetryAfterType sip-503 blkListAlgTimeoutsDuration <1-3600> blkListAlgTimeoutsNumTimeouts <1-3600> blkListAlgTimeoutsType sip-invite blkListAlgorithms <retryafter | timeouts | noRetryAfer> blkListAlgNoRetryAfterNum503 <1-3600> blkListAlgNoRetryAfterDuration <1-3600> failureResponseCodes <400-699 | all |all4xx | all5xx | all6xx> midDialogArsScreenLevel <always | never | onlyIfNotBlackListDueto503> recoveryAlgProbeDuration <1-3600> recoveryAlgProbeInterval <1-600> recoveryAlgProbeMethod sip-options recoveryAlgProbeNumResponses <1-32> recoveryAlgTimerDuration <1-3600> recoveryAlgorithm <probe|timer> recoveryAlgForTimeouts <probe|timer|none> recoveryAlgForNoRetryAfter <probe|timer|none>
Two new parameters are added to SIP trunk group signaling and are shown in the context of the complete command syntax.
performPrecondtionRenegotiation:
to re-initiate precondition procedure when the SBC changes the ingress side SDP due to 18x/200 OK or UPDATE received from the egress side.preferUPDATEOverReINVITE:
to use UPDATE instead of Re-INVITE on the ingress to communicate SDP, when the call goes to the confirmed state.For more information, refer to:
% set addressContext default zone <zone_name> sipTrunkGroup <siptrunkgroup_name> signaling preferUPDATEOverReINVITE <enabled | disabled>
% set addressContext default zone <zone_name> sipTrunkGroup <siptrunkgroup_ingress_name> signaling performPrecondtionRenegotiation <enabled | disabled>
Packets that cause a direct SBC fault can lead to a catastrophic failure of an SBC service, which is known as a packet-stimulated fault avalanche. These packets appear for various reasons, such as: the SBC adds a new Session Initiation Protocol (SIP) endpoint, upgrades or replaces a peering endpoint or gateway (GW), changes a configuration on a peer, or introduces a new call scenario. The SBC does not currently check for double faults, which is when the SBC has a failover and then another failover. Double faults cause call loss.
For more information, refer to CLI Configure Mode.
Use the following command to set and configure the faultAvalancheControl
parameter.
% set system faultAvalancheControl callIdThreshold <0-999> calledPartyThreshold <0-999> callingNCalledPartyThreshold <0-999> callingPartyThreshold <0-999> sourceIpThreshold <0-999> faultRecAgeingTimeOut <15-60>
Use the following command to enable or disable the faultAvalancheControl
parameter.
% set system faultAvalancheControl facState <disabled | enabled>
In specific call scenarios, the SBC treats the Offer-Answer (OA) as a MODIFY Offer-Answer cycle, but the peer treats it as an INITIAL Offer-Answer cycle. According to RFC 3261, the response from the peer is expected within 300 seconds. The SBC, however, assumes a 20-second response, and therefore any delay in the response from the peer which exceeds of 20 seconds causes call failure.
Currently, the internal Offer-Answer (OA) timer value is fixed and cannot be configured. To overcome this limitation, the SBC is enhanced with a new parameter offerAnswerTimer
to configure this OA timer.
For more information, refer to Signaling - Global - CLI
% set global signaling sipSigControls offerAnswerTimer Possible completions: <Enter offer answer timer value in range of (10..300) in seconds.> (20):
The SBC provides the following new SIP trunk group parameter to specify whether to use the Contact header information instead of the source IP address when routing a call to an access user over TLS transport.
For more information, refer to SIP Trunk Group - Signaling - CLI
% set addressContext <address context> zone <zone> sipTrunkGroup <trunk group name> signaling honorContactInRegisterForTLSCalls <disabled | enabled> |
Parameter | Description |
---|---|
| Use this flag to specify where the SBC directs access calls from the internal network to users in the access network when the call is over TLS transport. The options are:
|
When the SBC fails a DNS query, it generates a 503 or 500 error response. These error codes are now mapped to a configurable response code. A new enum - DnsRcodeError - has been added to internalCause
in sonusSipInternalCauseMapProfile
.yang to provide mapping entry in existing InternalSipCauseMapProfile
profile.
For more information, refer to Show Table Global. and Internal SIP Cause Map Profile - CLI.
% set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap <CPC cause value> DnsRcodeError
Parameter | Length/Range | Default | Description | M/O |
---|---|---|---|---|
dnsRcodeError | 300-606 | N/A | Allows 500 and 503 error code mapping to a configurable response code. | Mandatory |
The SBC adds support for using SIP Message Manipulation (SMM) to enable secondary selection of an ingress trunk group. This processing requires two new SMM operations and SIP Param Based Action profiles.
For more information, refer to SIP Adaptor Profile - CLI.
The following new operations are supported in SMM sipAdaptorProfiles
.
% set profiles signaling sipAdaptorProfile <profileName> rule <rule index> action <action index> operation storeSipParam storeProfileName
The SIP Param Based Action profile is supported.
% set profiles signaling sipParamBasedActionProfile <profileName> action <none | selectTG> entry <0 to 2056> trunkGroupName <trunk group name> matchType full param <parameter value> none range rangeEnd <end of parameter range> rangeStart <start of parameter range> regexp paramRegexp <regular expression>
The following table describes the new SMM operations.
Parameter | Description |
---|---|
| SMM operation that extracts a specified value (header, parameter, token) from the incoming SIP message to compare to mapping defined in a |
| SMM operation that stores the name of a sipParamBasedActionProfile to use in selecting a new ingress trunk group. |
The following table describes the parameters in the sipParamBasedActionProfile
.
Parameter | Length/Range | Description |
---|---|---|
| up to 23 characters | Name for the |
| n/a | Action to be performed by the
|
| 0 to 2056 | Index value for the entry. A sipParamBasedActionProfile can contain a maximum of 2056 entries. |
| up to 23 characters | The name of the trunk group to set as the new ingress trunk group if the corresponding entry matches the value extracted with the SMM storeSipParam operation. |
| n/a | Type of matching to use when comparing the value extracted with the SMM
|
| up to 128 characters | Parameter value to compare against when matchType is full . More than one param value can be defined for an entry when matchType is full . |
| up to 128 characters | Ending value for a range to compare against when matchType is range . |
| up to 128 characters | Starting value for a range to compare against when matchType is range . |
| up to 128 characters | Regular expression to compare against when the matchType is regexp . |
The SBC adds support for applying SIP message manipulation (SMM) profiles (SIP adaptor profiles) at both the global and address context levels and options that control how to execute profiles when they are specified at more than one level.
For more information, refer to Signaling - Global - CLI.
The following new options specify the names of SIP adaptor profiles to apply at the global level.
% set global signaling messageManipulation inputAdapterProfile <profile name> outputAdapterProfile <profile name>
The following new options specify the names of SIP adaptor profiles to apply to sessions within a specified address context..
% set addressContext <address context> signaling messageManipulation inputAdapterProfile <profile name> outputAdapterProfile <profile name>
The following new options specify whether or not to use fixed order execution when multiple SMM profiles apply to a session. When fixed order execution is enabled, you can also specify which of the four profile types to enable and therefore include in SMM processing.
% set addressContext <address context> zone <zone> sipTrunkGroup <trunk group name> signaling messageManipulation smmProfileExecution none fixedOrder addressContext acState <disable | enable> global globalState <disable | enable> iptg iptgState <disable | enable> zone zoneState <disable | enable>
Parameter | Length/Range | Description |
---|---|---|
| 0-23 characters |
|
| 0-23 characters | <profile name> – Enter the name of a SIP adaptor profile to use globally on outbound messages. |
Parameter | Length/Range | Description |
---|---|---|
| 0-23 characters |
|
| 0-23 characters | <profile name> – Enter the name of a SIP adaptor profile to use for the address context on outbound messages. |
Parameter | Description |
---|---|
| Specifies whether or not to use fixed order processing when more than one SIP adaptor profile applies to messages in sessions associated with the specified SIP trunk group. The options are:
|
| Specifies whether the SBC executes the rules in the SIP adaptor profiles assigned at the address context level on messages in sessions associated with the specified SIP trunk group. The options are:
This option is only available after you set |
| Specifies whether the SBC executes the rules in the SIP adaptor profiles assigned at the global level on messages in sessions associated with the specified SIP trunk group. The options are:
This option is only available after you set |
| Specifies whether the SBC executes the rules in the SIP adaptor profiles assigned at the SIP trunk group level on messages in sessions associated with the specified SIP trunk group. The options are:
This option is only available after you set |
| Specifies whether the SBC executes the rules in the SIP adaptor profiles assigned at the zone level on messages in sessions associated with the specified SIP trunk group. The options are:
This option is only available after you set |
A new Services profile, sipAdaptiveTransparencyProfile
, is added to configure SIP header transparency for P-ASSERTED-IDENTITY.
For more information, refer to SIP Adaptive Transparency Profile - CLI.
Under sipAdaptiveTransparencyProfile
, the following parameters are added:
sipMethod
sipResponse
state
triggerHeader
action
trigger
% set profiles services sipAdaptiveTransparencyProfile <profile_name> sipMethod <UPDATE | INVITE> sipResponse <180 | 183 | 200> state <disabled | enabled> triggerHeader <P-ASSERTED-ID> action new-value trigger value-change
The CLI changes are as follows:
profiles signaling
:calledPrefixMatchProfile
carrierCodeToIoiMappingProfile
ioiToCarrierCodeMappingProfile
sipJJ9030InterworkingProfile
profiles signaling NNIProfile
:contractorNumInterworking
addressContext zone sipTrunkGroup signaling
:calledPrefixMatchProfile
sipJJ9030InterworkingProfile
For more information, refer to the following pages:
To configure the signaling profile calledPrefixMatchProfile
, use the following syntax:
% set profiles signaling calledPrefixMatchProfile <called_prefix_match_profile_name: 1-23 characters> prefixMatch <stringPattern: 1-12 digits, 'X' or 'x' characters> <startPosition: 0-11> <digitLength: 1-30>
To configure the signaling profile carrierCodeToIoiMappingProfile
, use the following syntax:
% set profiles signaling carrierCodeToIoiMappingProfile <carrier_code: 4 digits [0-9]> accessParam <class | type> accessValue <access_value_string: 1-64 characters> ioi <inter_operator_identifier_string: 1-128 characters>
To configure the signaling profile ioiToCarrierCodeMappingProfile
, use the following syntax:
% set profiles signaling ioiToCarrierCodeMappingProfile <inter_operator_identifier_string: 1-128 characters> carrierCode <carrier_code: 4 digits [0-9]>
To configure the signaling profile sipJJ9030InterworkingProfile
, use the following syntax:
% set profiles signaling sipJJ9030InterworkingProfile <sip_JJ9030_Interworking_Profile_name: 1-23 characters> addUserEqualPhoneforDivHiInterworking <disabled | enabled> bciCalledPartyCategory <noIndication | ordinary | payphone | spare> bciChargeIndicator <charge | noCharge | noIndication | spare> bciTerminatingIsdnAccess <isdn | nonIsdn> chargeAreaInformation <charge_area: 5 digits [0-9]> origIoi <originating_inter_operator_identifier_string: 1-128 characters> originatingCarrierCode <originating_carrier_code: 4 digits [0-9]> setHiPresentationRestricted <disabled | enabled> sipFlavor JJ9030 SIP-T SIP-ttc-charging-params termIoi <terminating_inter_operator_identifier_string: 1-128 characters>
To configure the parameter contractorNumInterworking
under the profile NNIProfile
, use the following syntax:
% set profiles signaling NNIProfile <nni_profile_name> contractorNumInterworking <disabled | enabled>
To attach the signaling profiles calledPrefixMatchProfile
and sipJJ9030InterworkingProfile
with sipTrunkGroup
, use the following syntax:
% set addressContext <address_context_name> zone <zone_name> sipTrunkGroup <SIP_TG_name> signaling calledPrefixMatchProfile <called_prefix_match_profile_name> sipJJ9030InterworkingProfile <sip_JJ9030_interworking_profile_name>
Create the profiles calledPrefixMatchProfile
and sipJJ9030InterworkingProfile
before attaching them with sipTrunkGroup
.
The parameter descriptions for profiles signaling
calledPrefixMatchProfile
are as follows:
The parameter descriptions for profiles signaling carrierCodeToIoiMappingProfile
are as follows:
The parameter descriptions for profiles signaling
are as follows:ioiToCarrierCodeMappingProfile
The parameter descriptions for profiles signaling
are as follows:sipJJ9030InterworkingProfile
The descriptions for new parameters under profiles signaling NNIProfile
are as follows:
The descriptions for new parameters under addressContext zone sipTrunkGroup signaling
are as follows: