Panel | ||||
---|---|---|---|---|
In this section:
|
Noprint | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Info | ||
---|---|---|
| ||
Default values are enclosed in square brackets [ ]. |
Pagebreak |
---|
NASS-IMS-Bundled-Authentication (NBA) is used to provide access to the IMS (IP Multimedia Subsystem) network for legacy equipment that cannot support IMS access security (IMS AKA). The authentication algorithm is enhanced to include and select NBA authentication.
The main objective of the NBA is to gain access to the IMS network, based on successful access level authentication. This is achieved by associating an IMS identity with a fixed specific location from where it is authorized to access from. The SBC Core infers an authentication scheme applicable to the user based on response from S-CSCF for initial REGISTER request. If S-CSCF selects NBA, it either sends 200 OK or 403 response. The SBC infers an NBA authentication scheme on receipt of 200 OK and follows procedures associated with NBA. So, P-CSCF switches to either NBA or SIP Digest w/o TLS based on S-CSCF's response. When NBA is in use, receiving a 401 (Unauthorized) response to the REGISTER request is not expected.
When P-CSCF receives a REGISTER from the UE, and once NBA is selected as the authentication scheme, P-CSCF contacts CLF over the e2 interface. P-CSCF performs a"Location Information Query" towards CLF using the E2 interface User-Data-Request and User-Data-Answer message exchange to learn the location information. CLF sends the response to P-CSCF including location information of UE using the given IP address / User-Name. Upon getting a response from CLF, P-CSCF inserts PANI header, appends NASS location information to SIP REGISTER message, and forwards REGISTER message towards IMS core, in order to authenticate UE.
The following parameters configure this feature:
<nassImsAuth>
allows configuration related to NASSxDSL>
, <ethernet>
and <fiber>
provision IP connectivity access associated with TISPAN NASS<accessClass>
parameter, when configured to <tispan-NASS>
, allows the SBC to identify if the request arrived on TISPAN NASSe2
enhances <appId>
to provision the diameter e2 interface<clfRealm>
allows configuration so the UDR message sent has a destination realm AVP with a CLF realm value<ueDefaultLocation>
specifies the default UE location nameThe <nassImsAuth>
parameter is a new container, allowing configuration related to NASS. Under <nassImsAuth>
are:
<accessType>
<ethernet>
<xDsl>
<fiber>
<clfRealm>
<ueDefaultLocation>
The existing <accessClass>
is enhanced with a new value, tispan-NASS
The existing <appId>
is enhanced with a new value, e2
Pagebreak |
---|
Code Block |
---|
% set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling accessClass
ac-3GPP
none
tispan-NASS
% set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling nassImsAuth
accessType
clfRealm
ueDefaultLocation
% set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling nassImsAuth accessType
ethernet <ieee-802-3 | ieee-802-3a | ieee-802-3ab | ieee-802-3ae | ieee-802-3ak | ieee-802-3an | ieee-802-3aq | ieee-802-3e | ieee-802-3i | ieee-802-3j | ieee-802-3u | ieee-802-3y | ieee-802-3z>
fiber <g-pon | ieee-802-3ah | xgpon1>
none
xdsl <adsl | adsl2 | adsl2Plus | g-hdsl | hdsl | hdsl2 | idsl | radsl | sdsl | vdsl>
% set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling nassImsAuth clfRealm <1-128 chars>
% set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> signaling nassImsAuth ueDefaultLocation <1-64 chars>
% set addressContext <addressContext name> diamNode <diameterNode name> realmRoute <realmRoute name> appId <e2 | rf | rx> |
The SBC SWe supports two levels of link detection for both standby and active Ethernet ports to monitor the health of the ports and to ensure the health of a standby port before initiating a switchover to it. By default, physical link detection is enabled on all ports configured in Link Monitor. This default mechanism checks for the presence of the cable and that the adjacent device is powered on. If hardware failures are detected they are reported to the SBC processes that monitor ports and a switchover can be triggered if the standby port is available.
A second level of link detection can be enabled that checks connectivity between a port and and a configured destination. The specific mechanism used to check the port depends on the whether the port is in an active or standby state. These probing mechanisms for link detection are available regardless of the number of ports attached to the SWe instance.
The current description for the probeOnStandby
flag (under linkMonitor
) is expanded to account for port redundancy as shown below. This description covers both SWe and non-SWe use of the option.
Parameter | Length/Range | Default | Description |
---|---|---|---|
probeOnStandby | N/A | enabled | For the specified Link Monitor, use this flag to enable/disable probing the standby port to monitor the health of that port.
Note: This flag is only visible on SBC 7000 and SBC SWe Cloud systems. |
Crankback functionality is triggered based on the presence, absence, or value of a SIP information element, for example, a proprietary header, parameter, or response code. This is provided by enhancing SMM capabilities.
To invoke crankback functionality, SMM is enhanced to include a predefined SMM variable for crank-back invocation. The SMM variable is assigned to one of the predefined action values. To invoke crank-back functionality, the SMM rule is added so that "nextRouteActionOnCrankBack" is set to a predefined action value. Whenever the SMM rules are met, the SBC takes crankback action based on the action value. The user can assign value to this using SMM rules.
The parameter nextRouteActionOnCrankBack
is a predefined SMM operation parameter that configures crankback invocation for this feature.
Under this parameter are two options, <actionType>
and <generateAttemptRec>.
Under <actionType>, the options <
none>,
<SkipRemainingRoutes
>, <DisconnectCall>
, and <
AttemptNextRoute>
determine how crankback is performed.
Under <generateAttemptRec>
, the options <true>
and <false>
determine if the attempt record will be generated for crankback attempts.
The nextRouteActionOnCrankBack
SMM operation parameter is added. Under it are:
<actionType>
<skipRemainingRoutes>
<disconnectCall>
<attemptNextRoute>
<generateAttemptRec>
<true>
<false>
Code Block |
---|
% set profiles signaling sipAdaptorProfile <profile name> rule <index> action <index> operation nextRouteActionOnCrankBack
% set profiles signaling sipAdaptorProfile <profile name> rule <index> action <index> message
% set profiles signaling sipAdaptorProfile <profile name> rule <index> action <index> message nextRouteActionOnCrankBack actionType < None | AttemptNextRoute | SkipRemainingRoutes | DisconnectCall>
% set profiles signaling sipAdaptorProfile <profile name> rule <index> action <index> message nextRouteActionOnCrankBack generateAttemptRec <true | false> |
The S8 Home Routing (S8HR) uses the LTE S8 interface for transporting VoLTE traffic between the visited and home network as data traffic. The S8HR does not require IMS in the visited LTE network. In S8HR roaming architecture model of VoLTE, the Packet Data Network Gateway (PGW), Policy Charging and Rules Function (PCRF), and Proxy Call Session Control Function (P-CSCF) are in the Home Public Land Mobile Network (HPLMN) when the UE is roaming in a Visited Public Land Mobile Network (VPLMN). The S8HR roaming architecture provides all the IMS services to the UEs roaming in the VPLMN. In this scenario, the UE does not require any IMS network to network interface (NNI) between the VPLMN and HPLMN. A roaming user receives all the services of the home network in the S8HR model. In S8HR roaming model, the IMS/SIP/RTP traffic is tunneled back to the HPLMN like data traffic.
The visited S8HR user is authenticated using the GPRS-IMS-Bundled Authentication (GIBA) procedure and handles the emergency call. The flags s8hrSupport
and gibaSupportForS8hrInboundUser
are added to the SIP Trunk Group to support the emergency call handling for S8HR model.
To support the emergency call in S8HR model, execute the following command:
Code Block |
---|
% set addressContext <addressContext> zone <zone> sipTrunkGroup <sipTrunkGroup> signaling s8hrSupport <disabled | enabled> |
To configure the VPLMN and HPLMN profiles, execute the following command:
Code Block |
---|
% set profiles services
hplmnProfile <profileName> hplmnId <plmn id>
vplmnProfile <profileName> vplmnId <plmn id> emergencyPrefix <prefix id> |
To enable authenticated identity management, stiProfile
is added and is associated to a SIP Trunk Group. If the state of the stiProfile
attached to the ingress trunkgroup is enabled, the SBC sends STI related information to the PSX, which is provisioned to either sign, verify or tag the call. The SBC then receives information from the PSX about the service provided that is signing, verification or tagging
The provisioning on the PSX dictates whether STI related headers are signaled on the egress.
The stiProfile
has to be enabled on the egress sip trunkgroup for STI headers to be signaled on the egress.
For transparently passing Date Header, existing Header Transparency feature is used.
A new action "retryWithoutIdentity
" is added to the retryProfile
. When this action is configured for a SIP response code, on receipt of the response code the same route is tried without Identity Headers.
For the next route to be tried, the user provisions the reasonCode in the crankback profile. If the reasonCode is not provisioned in the crankback profile, the call fails.
A new stiProfile
is added under Services:
Code Block |
---|
set profiles services stiProfile <profileName>
Possible Completions
state - enabled or disabled. |
A new parameter retrywithoutIdentity
is added to action type:
Code Block |
---|
set profiles services retryProfile <retryprofile_name> triggerActionRule <Rule_Number> sipResponseCode <SipresponseCode> actionType retryWithoutIdentity |
STI Profile Parameters:
Parameter | Length/Range | Default | Description | M/O |
---|---|---|---|---|
state | enabled, disabled | disabled | Indicates whether STI procedures should be applied. | M |
stiProfile | NA | NA | Indicates the new services profile for STI feature. | M |
Retry Profile Parameters
Parameter | Length/range | Default | Description | M/O |
---|---|---|---|---|
retryWithoutIdentity | NA | NA | Indicates the new action type for trying the same route without identity | NA |
Rule parameter upper range limit changed to 256:
Parameter | Length/Range | Description |
---|---|---|
| 1-23 | The name of the SIP Adaptor profile. Up to 512 profiles are configurable. |
advancedSMM | N/A | Enable flag to apply advanced SMM logic, such as dialog stateful variables, to INVITE, REGISTER, SUBSCRIBE messaging. For an example SMM rule, see How to Treat Hostpart Based on the Received Format.
NOTE: Dialog Stateful variables are not applied for the NOTIFY messages received prior to receiving 200 OK response to the Egress SUBSCRIBE. |
profileType | N/A | When creating a SIP Adaptor Profile, use this parameter to specify whether a SIP Adaptor Profile is to be used for flexible policy or message manipulation.
|
| 1-256 | Use this object to define the SIP Message Manipulation (SMM) rule within the SIP Adaptor Profile. Specify the SSM rule index number, and then configure the parameters as listed in the Rule Parameters section below. |
| N/A | The administrative state of this SIP PDU Manipulation entry.
|
The existing CLI command to configure the system-wide media port range is modified to incorporate an optional configuration that divides the media port range into a high-priority port range and a low-priority port range. Under congestion conditions, all the packets received on ports outside high priority media range will be dropped automatically by NP layer. The new CLI allows you to configure the high priority media port range.
The High Priority port range is a contiguous range of ports that can lie either at the top or at the bottom of the media port range.
Ribbon recommends that signalling ports inside the media port range reside within the high priority port range, if configured.
For the sigport feature, the high-priority media port range will have impact only the ISBC because the pool for udp port is common for media and signalling.
Fot the DSBC, this configuration should appear on MSBC.
If signaling port lies outside the media port range then no CONTROL-XRES will be allocated for the configured port.
Example
Code Block |
---|
% set system media mediaPortRange baseUdpPort <base> maxUdpPort <max>
highPriorityPortRangeLocation <top/bottom>
highPriorityPortRangeSize <value (<25)> |
Parameter | Length/Range | Default | Description | M/O |
---|---|---|---|---|
highPriorityPortRangeLocation | top/bottom | N/A | Contiguous range of ports that can lie either at the top or at the bottom of the media port range.
| |
highPriorityPortRangeSize | value (<25) | N/A | The size of the high priority media port range; cannot exceed 25 percent of the overall configured media port range. |
The SBC now allows users to create multiple ENUM services for same service type (sipAor, CNAM, or LNP), and to create different triggers based on TLD (Top level Domain).
For example:
Service1 -> SIPAoR type -> Trigger1 as TG1 -> ENUM TLD example1.net
Service2 -> SIPAOR type -> Trigger2 as TG2 -> ENUM TLD example2.net
The mandatory priority parameter must be assigned when creating Enum Service. A lower value represents a higher priority.
Code Block |
---|
> set global servers enumService <EnumService Name> priority <value> |
To display configured ENUM servers:
Code Block |
---|
% show global servers enumService <service name> |
When enabled, the SBC skips all the next services and goes directly to routing.
Code Block |
---|
set global servers enumService <EnumService Name> flags skipFurtherNumberTranslationServices <disable/enable> |
Parameter | Length/Range | Default | Description | M/O |
---|---|---|---|---|
priority | 0-255 | N/A | Specifies the priority (order) of ENUM service execution. | M |
skipFurtherNumberTranslationServices <disable | enable> | N/A | disable | Skips all further services if enabled. | O |
An entity, dbSyncCheckProfile
, is added. A parameter, syncCheckInterval
is added to dbSyncCheckProfile
to configure the time interval for verifying the database integrity. It will raise an existing TRAP "sonusDatabaseConfigPolicyDataOutOfSyncNotification" when a DB Out of Sync condition arises.
Execute the following command to show the dbSyncCheckProfile and syncCheckInterval parameter:
Code Block |
---|
% show profiles dbSyncCheckProfile <DEFAULT>
syncCheckInterval 5; |
Execute the following command to configure dbSyncCheckProfile:
Code Block |
---|
% set profiles dbSyncCheckProfile <DEFAULT>
syncCheckInterval
<unsignedInt, 0 | 5 .. 30> |
Caption | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
To display the dbSyncCheckProfile
entity details, a new show command has been added.
Code Block |
---|
% show table profiles dbSyncCheckProfile |
Caption | ||||
---|---|---|---|---|
| ||||
|
The EVS codec and its options to the choice of codecs to configure in a codecEntry are added
. EVS has also been added as a possible parameter value for toneCodecEntry
and for codecRoutingPriority
.
The following new set of options are available in codecEntry configuration to configure a codec entry utilizing the EVS codec. The new parameters added for EVS are maxBitRate
and minBitRate
. The rest of the parameters listed are existing parameters used to define other types of codecs and descriptions of the parameters are already documented in the context of coedEntry configuration.
Code Block |
---|
% set profiles media codecEntry <name> codec evs
dtmf
relay <relay_type>
removeDigits <disable | enable>
maxBitRate <5.9 | 7.2 | 8 | 9.6 | 13.2 | 16.4 | 24.4 | 32 | 48 | 64 | 96 | 128>
minBitRate <5.9 | 7.2 | 8 | 9.6 | 13.2 | 16.4 | 24.4 | 32 | 48 | 64 | 96 | 128>
packetSize <20 | 40 | 60 | 80 | 100>
preferredRtpPayloadType <0-127> |
Caption | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
The EVS codec is added to the list of codecs that can be assigned as an Ingress or Egress Codec Group as part of configuring HD Codec Routing Priority (codecRoutingPriority
), as follows:
Code Block |
---|
% set profiles media codecRoutingPriority <ingress codec group: AMRWB | EVS | G722 | G7221 | G7291 | MSRT | OPUS | SILK>
entry <egress codec group: AMRWB | EVS | G722 | G7221 | G7291 | MSRT | OPUS | SILK> <priority number> |
The EVS codec is added to the list of codecs that can be configured as part of a Tone Codec Entry (toneCodecEntry codec
), as part of configuring Playing Tones as Announcements. Tone codec entries including the EVS codec do not require configuring the law
or codingRate
parameters. The following command parameters configure a tone codec entry for EVS specifically.
Code Block |
---|
% set profiles media toneCodecEntry <toneCodecEntry name>
codec evs
codingRate <EVS-0-7.2kbps | EVS-1-8.0kbps | EVS-2-9.6kbps | EVS-3-13.2kbps | EVS-4-13.2kbps | EVS-5-16.4kbps | EVS-6-24.4kbps | EVS-7-32kbps | EVS-8-48kbps |
EVS-9-64kbps | EVS-10-96kbps | EVS-11-128kbps> |
The SBC currently provides pass-through support for the SILK codec in narrowband (NB), mediumband (MB), wideband (WB), and super-wideband (SWB) formats. It will now also support transcoding for the NB and WB SILK codec variants. SILK transcoding support applies to the SBC 5110, 5210, 5400 and 7000 platforms only.
Two new parameters are added to codecEntry
configuration when the codec type is one of the SILK variants: maxAverageBitRate
and useSilkDTX
. These are added to the existing syntax below:
Code Block |
---|
% set profiles media codecEntry <name> codec <silk8|silk12|silk16|silk24>
dtmf
relay <relay_type>
removeDigits <disable | enable>
fax
failureHandling <continue | disconnect>
toneTreatment <treatment_type>
maxAverageBitRate <silk8:6000-20000|silk12:7000-25000|silk16:8000-36000|silk24:12000-40000>
modem
failureHandling <continue | disconnect>
toneTreatment <treatment_type>
packetSize <packetSize>
preferredRtpPayloadType <0-128>
silenceSuppression <disable | enable>
useSilkDTX <0 | 1> |
Caption | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
The SILK codec is added to the values that can be assigned to the PSP parameter Codecs Allowed For Transcoding (codecsAllowedForTranscoding
) under Packet To Packet Control, as follows:
Code Block |
---|
% set profiles media packetServiceProfile <unique_profile_name> packetToPacketControl
codecsAllowedForTranscoding
otherLeg <amr | efr | evrc | g711a | g711u | g722 | g726 | g729 | g7221 | g7222 | g7231 | ilbc | opus | silk | t38>
thisLeg <amr | efr | evrc | g711a | g711u | g722 | g726 | g729 | g7221 | g7222 | g7231 | ilbc | opus | silk | t38> |
Networks with a Caller ID Name (CNAM) gateway use an out of dialog Subscribe/Notify and there aren't any "sessions" as part of the transaction. The SBC now reports peak transactions for all Out of Dialog (OOD) in order to facilitate reporting of OOD SIP transactions.
A configurable is added to configure and modify the licensed OOD rate limit at a global level:
Two new statistics have been added to show table global
command:
To configure licensed Out-Of-Dialog rate limit:
Code Block |
---|
% set global sipOod licensedMaxRateLimit |
Caption | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
To display the Out-Of-Dialog Current Statistics:
Code Block |
---|
% show status global oodMessageCurrentStatistics |
Caption | ||||
---|---|---|---|---|
| ||||
|
To display the Out-Of-Dialog Interval Statistics:
Code Block |
---|
% show status global oodMessageIntervalStatistics |
Caption | ||||
---|---|---|---|---|
| ||||
|
The RTP Control Protocol (RTCP) in conjunction with RTP, provides the report of PDUs exchanged between the source and the destination. It provides feedback on the quality of the data distribution. The RTCP monitors the transmission statistics and Quality of Service (QoS) status of the media streams and aids synchronization of multiple streams.
When the SBC generates an RTCP packet toward the outgoing direction, it relays the received RTCP packets from one leg to another leg. The SBC supports RTCP monitoring and generates RTCP for pass through calls regardless of the leg where the RTCP is received. The SBC generates RTCP on one leg, even if other leg sends RTCP, without any dependency on the RTCP-related configuration on the other leg.
Code Block |
---|
% set profiles media packetServiceProfile <unique_profile_name>
rtcpOptions <disable | enable> |
Caption | ||||
---|---|---|---|---|
| ||||
|
SBC SWe cloud deployments support a domain-based licensing model referred to as network-wide domain licensing (NWDL). In contrast to node-locked licensing, a domain license is tied to an administrative domain rather than the hardware ID for a specific host server or the UUID for a specific node instance. A domain license is bound to the domain through public/private key-pairing and it defines the features and capacity allowed for all nodes within the domain. NWDL provides flexibility in cloud environments where the number and placement of nodes sometimes varies.
To set license mode.
Code Block |
---|
% set system licenseMode mode <domain | legacy | network> |
To set license restrictions while in domain license mode.
Code Block |
---|
% set system licenseRequired <licensed feature key> maxCount <2-1000000, or "unlimited"> |
To display information about the domain license bundles loaded into the system.
Code Block |
---|
> show status system licenseDomainBundleInfo or
> show table system licenseDomainBundleInfo |
Caption | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
|
The SBC is enhanced to disable/set Out of Service the server at the IP peer level. In order to do so, your network must know the server IP address of the peer.
The SBC uses a Domain Name Server (DNS) server to resolve the Fully Qualified Domain Name (FQDN), and obtains multiple IP peer addresses. After a carrier notifies your network that a particular server has an issue and is out of service, your network server's peer mode is set to Out Of Service
This feature provides the flexibility to block peers individually within a trunk group. The can be set to out of service, rejecting both incoming and outgoing calls.
This command controls the feature flag. When enabled, then only other commands are visible.
Code Block |
---|
% set addressContext <adddress context name> zone <zone name> advancePeerControl <disabled | enabled> |
This commands allows the user to accept or reject call through that IP peer.
Code Block |
---|
% set addressContext <adddress context name> zone <zone name> ipPeer <ip peer name> mode <inService | outOfService> |
This command allows the user to terminate calls immediately or after some specified time.
Code Block |
---|
% set addressContext <adddress context name> zone <zone name> ipPeer <ip peer name> action <dryUp | force> |
This command allows the user to select range timeout values to terminate the call.
Code Block |
---|
% set addressContext <adddress context name> zone <zone name> ipPeer <ip peer name> dryUpTimeout <1-1440 mins> |
This command allows user to block incoming /outgoing calls based on the selected direction.
Code Block |
---|
% set addressContext <adddress context name> zone <zone name> ipPeer <ippeer name> blockDirection <bothways | incoming | none | outgoing> |
Caption | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||
|
When a subscriber registers from multiple devices with the same username, there is an inherent issue on the private side of the SBC. In Access mode, the SBC traditionally does not manipulate the username for the AOR, but does manipulate the host portion. The host portion is changed to the private side IP of the SBC when sending to the Registrar. If a subscriber registers from multiple devices it causes the same AOR to be created from the SBC to the registrar.
To make this unique, the SBC inserts a parameter called reg-info and inserts a unique value in this parameter. Some registrars do not cache the parameters inserted by the SBC which causes this use case to fail.
To remediate this type of failure, the SBC privately assigns a unique new value to the username. The SBC maintains a mapping from this unique username value on the private side, and the original username on the public side.
Code Block |
---|
% set addressContext <name> zone <name> sipTrunkGroup <name> signaling embeddedRegInfoinUserPart <disabled | enabled> |
Caption | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
In its default behavior, the SBC adds an enumdi (ENUM dip indicator) parameter to the outgoing Request URI when the PSX performs an ENUM query. Some peering carriers do not support this parameter and want the option to not have the SBC insert the parameter the egress Request URI. A global flag, egressRemoveEnudmi, controls whether the parameter is present. By default the flag is disabled to maintain the SBC default behavior. When the egressRemoveEnudmi flag is enabled the SBC does not add an enumdi parameter even if the PSX performs an ENUM query.
The CLI change consists of adding a new option within the existing, global sipSigControls
options.
Code Block |
---|
% set global signaling sipSigControls egressRemoveEnudmi <disabled | enabled> |
Caption | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
The system metaVariableDynamic
table is added to allow adding the meta variable information on an already instantiated SBC instance with the following parameters:
Code Block |
---|
set system metaVariableDynamic ceName < name of the SBC instance> name <name of the metavariable> value <metavariable> |
Caption | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
|
To configure the flag gibaSupportForS8hrInboundUser
, execute the following command:
Code Block |
---|
% set addressContext <addressContext> zone <zone> sipTrunkGroup <sipTrunkGroup> signaling gibaSupportForS8hrInboundUser <disabled | enabled> |
To attach the
to the SIP Trunk Group, execute the following command:hplmnProfile
Code Block |
---|
% set addressContext <addressContext> zone <zone> sipTrunkGroup <sipTrunkGroup> services hplmnProfile <hplmnProfile> |
To attach the vplmnProfile
to the SIP Trunk Group, execute the following command:
Code Block |
---|
% set addressContext <addressContext> zone <zone> sipTrunkGroup <sipTrunkGroup> services vplmnProfile <vplmnProfile> |
The following parameters are added to the sipActiveRegisterNameStatus
:
ueRoamingType
mobileCountryCode
mobileNetworkCode
The following attributes are added to the sipCurrentStatistics
and sipIntervalStatistics
parameters:
totNumOfS8hrOutbndReg
numOfS8hrOutbndRegSuc
numOfS8hrOutbndRegFail
totNumOfS8hrOutbndNormalCall
numOfS8hrOutbndNormalCallSuc
numOfS8hrOutbndNormalCallFail
numOfS8hrOutbndEmgCallRej
numOfS8hrInboundRegSuc
numOfS8hrInboundRegFail
numOfS8hrInboundEmgCallSuc
numOfS8hrInboundEmgCallFail
Previously, the SBC invoked Media Resource Function (MRF) only for audio streams to achieve transcoding. Non-audio streams were relayed end-to-end even when the audio was sent to MRF.
Teletype (TTY) is the legacy service offered through encoding text characters as tones that are embedded in a carrier (PCMU, PCMA, or EVRC) media stream. The T.140 streams carry text as a separate payload.
With this feature, the SBC invokes MRF for T.140 and TTY interworking to achieve transcoding (see the following call flow). When T.140 and TTY interwork, text characters exchange between the T.140 stream and the tones carried inband with the audio.
This feature modifies the callDetailStatus
parameter by enhancing the mediaTypeStream<X>
statistic to transcode
for text streams when the SBC invokes MRF for T.140 and TTY interworking.
The SBC SWe and SBC SWe Cloud are enhanced to provide the configuration provisioning support using CLI and EMA. The provisioning limits can be configured based on the available RAM capacity. To achieve this functionality, the table sweConfigProfileSelection
is configured under system.
The SBC supports following two configuration profiles to configure the provisioning limits:
small
: applicable to the VM RAM >=10 GiBlarge
: applicable to the VM RAM >=18 GiB
Code Block |
---|
% set system sweConfigProfileSelection name <small | large> |
The media codecEntry
configuration for G.711 adds the honorToneDetection
flag in the fax
and modem
parameters.
Code Block |
---|
% set profiles media codecEntry <codecEntryName> codec g711 fax honorToneDetection <disable | enable>
% set profiles media codecEntry <codecEntryName> codec g711 modem honorToneDetection <disable | enable> |
A new Flag rfc7332ValidateMaxForwards is added in SipTrunkGroup signaling configuration in INGRESS side.
The default value for rfc7332ValidateMaxForwards is disable
. If rfc7332ValidateMaxForwards is enabled, the SBC will use the Max-Forwards header value received from the end-user, and decrements this header value by 1 before forwarding it to the other end-user. If the value received from the end-user is 0 or 1, the SBC will discard that request with an error response of "483 - Too Many Hops."
Code Block |
---|
% set addressContext <addressContext -name> zone <zone -name> sipTrunkGroup < TG- name> signaling rfc7332ValidateMaxForwards <disable | enable> |
The sipTrunkGroup media
configuration adds appSpecificBandwidth
.
Code Block |
---|
% set addressContext <addressContext name> zone <zone name> sipTrunkGroup <sipTrunkGroup name> media appSpecificBandwidth <disabled | enabled> |
The hpcCallProfile
configuration adds the dscpValue
parameter.
Code Block |
---|
% set profiles services hpcCallProfile <hpcCallProfile name> dscpValue <X>
|
The SBC supports Rsyslog as a method of sending event messages to a syslog server. It now has enhanced Rsyslog service with a number of new features:
Allow new configuration to specify which /var/log/ files to transfer over syslog
Allow a mechanism to capture Linux session console logs and transfer via syslog
Code Block |
---|
> show table oam eventLog platformRsyslog
% set oam eventLog platformRsyslog servers server<no> remoteHost<host_ip> protocolType<protocol> port <port>
> show configuration oam eventLog platformRsyslog
% set oam eventLog platformRsyslog syslogState <disabled | enabled>
|
New hyperthreading support affects various table options, parameters, and profiles in:
sweTrafficProfiles
sweActiveProfile
show table system
JITC requires the audit (.AUD) and security (.SEC) logs to be cryptographically protected. Since both logs are required to be hashed, this functionality is extended to support the hashing of all Event Logs on the SBC.
Code Block |
---|
> show table system security hashEventLogs
> show configuration system security hashEventLogs
% request system security eventLogValidation generateDefaultKeys
% request system security eventLogValidation showPublicKey <default/user>
% request system security eventLogValidation setUserPrivateKey <uniqueUserPrivateKeyName> <userPrivateKey>
% request system security eventLogValidation deleteUserPrivateKey |
The SBC can be configured to provide counts of the number of times different SIP responses codes are either sent or received during a statistics interval. Statistics of this type can provide insight into call-related or registration-related failures within the network. You can enable collection of current and interval SIP response code statistics on specific SIP trunk groups or IP peers. By default collecting SIP response code statistics is disabled on SIP trunk groups and IP peers.
When enabled, the statistics are stored in the following four tables. Refer to Interval Statistics - CLI for information on the parameters that control collection of interval statistics.
In addition to identifying the specific trunk group or IP peer to which they apply, entries in the table include:
Two new flags are added, one within IP peer and one within trunk group configuration, to enable collecting SIP response code statistics on specific objects of that type.
Code Block |
---|
% set addressContext <acName> zone <zoneName> ipPeer <ipPeerName> sipResponseCodeStats <enabled|disabled>
% set addressContext <acName> zone <zoneName> id <zoneId> sipTrunkGroup <tgName> sipResponseCodeStats <enabled|disabled> |
The SBC supports SIPREC when the SIPREC specifications were in early drafts (draft-ietf-siprec-xx-06). With the implementation of this feature, the SIPREC standard has evolved to RFCs (RFC 7245, RFC 7865, RFC 7866, and RFC 8068), and provides capability for supporting "dynamically programmable" selection of metadata content.
The profile sipRecMetaDataProfile is introduced to the services to provide the capability to configure the headers that are mapped from the target call leg to the XML and the corresponding metadata XML element name.
In case of a basic call, all information is copied from the initial-INVITE message on the leg where the tap is, to the metadata XML. However, "To" header and "to-tag" is copied additionally from the local information (as to-tag does not present in the INVITE).
In case of SIPREC trigger during REFER based transfer, irrespective of where the SIPREC tap is, all information is copied from the initial-INVITE of the new call leg towards the transfer target (C party).
In case of CLI triggered recording, the existing implementation of sending predefined information in metadata XML remains same (gcid, call-id, from, to). The new configuration of header-metadata mapping is not considered in this scenario.
The profile sipRecMetadataProfile
is added to the SRS Trunk Group to configure the metadata format.
The following parameters are added to the profile sipRecMetadataProfile
:
version
sipHeader
sipToXmlTagName
state
Code Block |
---|
% set profiles services sipRecMetadataProfile <sipRecMetadataProfile> |
The SBC, which continuously captures encrypted signaling packets of SIP over TLS at layer 2, has been enhanced to to capture decrypted signaling packets as well.
The SIP PDUs (Protocol Data Units) are captured at the application layer and continuously streamed to the monitoring server. Configurable Headers are included in SIP PDUs to enable the monitoring server to decode SIP signaling properly. Headers have source and destination IP address/Port information along with additional information which is configurable – this information is needed by the monitoring server in order to correlate the stream received.
The packet is captured at ingress leg without SMM applied and with SMM applied on egress leg, which is essentially what is being sent on the wire. To lessen performance impact, all socket-management activities to the monitoring server use a separate SIPSM (SIP Signaling Monitor ) process receives all signaling packets from the SIP Signaling Gateway (SIPSG) and streams to the configurable external monitoring server either over UDP or TCP.
A profile attached to the signaling port is a trigger for this feature. All feature-related configuration can be set in this profile.
The CLI adds a Monitoring Profile to configure monitoring server, filters, header names and select from the fixed set of information.
Code Block |
---|
% set profiles services monitoringProfile <monitoring profile name> |
The SBC is enhanced to support sending encrypted media streams (Secure Real-Time Transport Protocol (SRTP)) towards the SIPREC recorders.
The following parameters are added to the SRS Group Data to support whether the Secure Real-Time Transport Protocol (SRTP) is enabled for the call or not. The cryptoSuiteProfile is an existing parameter. The parameter cryptoSuiteProfile is configured under profile and security and can be attached to the SRS Group Data.
srtp
cryptoSuiteProfile
Code Block |
---|
% set global servers srsGroupProfile <srsGroupProfile> srsGroupData <priority index>
srtp <disable | enable>
cryptoSuiteProfile <cryptoSuiteProfile> |
The Ribbon SBC is enhanced to secure management of user accounts and passwords on its OpenStack versions. Default passwords have been eliminated in favor of injected credentials. SSH keys for users linuxadmin and admin are now pushed using the User Data section of the HEAT template.
Because the sftpadmin account is deleted, the associated CLI is also removed.
This feature implementation globalizes the Request-URI. Currently, when the To-Header Transparency flag is set, it is also sending the Request-URI transparently even when the globalization flag is enabled. When set, the To-Header Transparency should not send the called number in the Request-URI locally. Request-URI globalization should be independent of the To-Header Transparency.
For this feature, Request-URI is globalized when globalization for the called number is enabled and if the To-Header Transparency flag is enabled, Request-URI called number will not be transmitted transparently to the egress leg. To-Header transparency flag will not affect Request-URI globalization.
Enables flag to transparently copy the Request URI from the incoming message to the outgoing message for INVITE, REGISTER, SUBSCRIBE/NOTIFY. Provision this flag on the egress leg (with respect to the message direction).
Code Block |
---|
% set profiles signaling ipSignalingProfile <profile_name> commonIpAttributes transparencyFlags requestURI |
The enumDomainName forwardersData
configuration adds the eDNSType
flag and eDNSBufferSize
parameter. The servers lwresdProfile
configuration adds the eDnsGlobalBufferSize
and eDnsMonitorInterval
parameters.
Note: The M-SBC does not support this feature.
The SBC uses the signaling interface to send ENUM queries, in addition to sending ENUM queries from the management interface. ENUM queries are properly marked, and packets from the signaling interface receive higher priority, when ENUM queries are sent through the signaling interface.
The signalingIp parameter is added to the type field of the servers lwresdProfile configuration. Set the servers lwresdProfile type to signalingIp to send the ENUM queries through the signaling interface using the sipSigPort IP address. The signaling interface uses port 988 to send and receive the queries.
When lwresdProfile type is configured as signalingIp, configure the addressContext, zone, sipSigPort, and ipInterfaceGroupName parameters with the correct combinations as configured during sipSigPort.
addressContext
updates the staticRoute
for the ENUM server, and this configuration includes the <pkt0 ip>
parameter.servers lwresdProfile type
configuration adds the signalingIp
parameter. The signalingIp
includes the addressContext
, zone
, sipSigPort
, and ipInterfaceGroupName
parameters.lwresdProfile
can attach the enumArsProfileId
. Configure this profile ID for black listing and white listing in the enumArsProfile
, which is added to the global servers
configuration.
A new parameter, sipRegCountDomainStats, is added and can be used with both show status and show table commands. An address context must be specified and specifying a domain is optional. If a specific domain is not specified the command returns per-domain statistics for up to 256 domains. The command returns no data if there are no domain names found.
show status addressContext <AC_Name> sipRegCountDomainStats <DomainName>
show table addressContext <AC_Name> sipRegCountDomainStats <DomainName>
The following existing CLI command is extended to also reset the cumulative domain-based statistics (countAttempt, countCumCompletion, emergAcceptTotal) for all domains:
request addressContext <AC_Name> sipRegCountReset
Code Block |
---|
> show status addressContext <AC_Name> sipRegCountDomainStats <DomainName>
countAttempts
countCumCompletions
countPending
countStable
countTotal
emergAcceptTotal
emergActiveTotal
> show table addressContext <AC_Name> sipRegCountDomainStats <DomainName>
countAttempts
countCumCompletions
countPending
countStable
countTotal
emergAcceptTotal
emergActiveTotal |
With the implementation of this feature, the SBC is enhanced to support:
Remove any non-essential headers that are added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To, and In-Reply-To.
To configure this feature, the privacyProfile
is added to the services.
The following flags are added to the privacyProfile
:
applyPrivacyId
applyPrivacyUser
passThruPrivacyInfo
supportPrivacyId
supportPrivacyUser
Caption | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Pagebreak |
---|