In this section:
IMPORTANT
The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when 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.
Note
The SBC 52x0 and SBC 7000 systems support creating IP Interface Groups containing sets of IP interfaces that are not "processor friendly" (i.e. carried on physical Ethernet ports served by separate processors). However, restrictions exist regarding the usage of such Interface Groups.
(This ability does not apply to the SBC 51x0 and SBC 5400 systems which have only two physical media ports. IP interfaces from the two physical ports may be configured within the same IP Interface Groups without restriction.)
For complete details, refer to Configuring IP Interface Groups and Interfaces.
The configuration discussed in this section has been tested in the Sonus Networks lab. The goal is to show a simple working configuration that can be used as a basis for
Unable to show "metadata-from": No such page "_space_variables"
user customization.High Level Simple Configuration
Trunk group routing will be used to send all traffic that arrives on "Outside" trunk to "Inside" trunk, and vice versa. This allows for no additional configuration changes on the
Unable to show "metadata-from": No such page "_space_variables"
as the operator adds more numbers to be routed.This configuration will support G.729A on the "Outside" with G.711 on the "Inside" so transcoding will occur.
A single Address Context will be configured, so no overlapping IP address will be used.
Both "Outside" and "Inside" specific configuration data must be made. Below is a summary of the key configuration items.
Key Configuration Items
Configuration Item | "Outside": PEER | "Inside": CORE |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configuration Details
Please use default values except as noted. For this example the Address Context "default" is used, since there is no over-lapped IP addressing.
The term "operator" is used to mean the Carrier, Service Provider, or Enterprise that owns the
Unable to show "metadata-from": No such page "_space_variables"
.To get into configuration mode from the CLI:
admin@DFWNBS01a> configure Entering configuration mode private
Zones
Create four new zones, each one representing an external customer or operator equipment.
- Two are used for the Trunking configuration
- Two are used for the Access configuration.
As additional customer (non-operator) far ends are added, they can be put into a new zone. For additional operator equipment, you may use a new zone or re-use the existing one.
Zone Usage
Zone | Configuration Usage | Purpose |
|---|---|---|
peer | Trunking | Traffic to/from far end carrier |
core | Trunking | Traffic to/from operator trunking equipment |
phones | Access | Traffic to/from phones |
accesscore | Access | Traffic to/from operator feature server |
Example of Using Zone Types in CLI
% set addressContext default zone peer id 2 % set addressContext default zone core id 3 % set addressContext default zone phones id 4 % set addressContext default zone accesscore id 5
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Base Provisioning > Zone.
SIP Signaling Ports
The SIP Signaling Ports live on (the IP addresses are owned by) the
Unable to show "metadata-from": No such page "_space_variables"
. These are the IP addresses that external (non-SBC equipment) send SIP traffic to and receive SIP traffic from. For this example four new SIP Ports are created (two for Trunking and two for Access). The term "operator" is used to mean the Carrier, Service Provider, or Enterprise that owns the Unable to show "metadata-from": No such page "_space_variables"
.SIP Port Usage
SIP Port #/ Zone | Configuration Usage | Purpose |
|---|---|---|
1 / peer | Trunking | Traffic to/from far end carrier |
2 / core | Trunking | Traffic to/from operator trunking equipment |
3 / phones | Access | Traffic to/from phones |
4 / accesscore | Access | Traffic to/from operator feature server |
In the configuration examples, each SIP Signaling port is in a unique Zone. The non-
Unable to show "metadata-from": No such page "_space_variables"
equipment (phones, operator feature server, other Carriers, operator trunking server) sends/receives SIP messages to/from the IP addresses and port configured. The default protocol allowed is UDP and port is 5060.Caution
When a SIP Port is created (IP address is assigned), the system also creates an ACL that allows connection attempts to all ports on the IP address. This means that someone could attempt to SSH to the IP address of the SIP Port. To prevent unwanted access attempts, you should manually create ACLs that specify what is allowed and what is not. See the ACL section of this document for details.
% set addressContext default zone peer id 2 sipSigPort 1 ipInterfaceGroupName EXTERNAL_IPIG ipAddressV4 10.35.66.189 state enabled % set addressContext default zone core id 3 sipSigPort 2 ipInterfaceGroupName INTERNAL_IPIG ipAddressV4 192.168.75.10 state enabled % set addressContext default zone phones id 4 sipSigPort 3 ipAddressV4 10.35.66.143 portNumber 5060 transportProtocolsAllowed sip-udp ipInterfaceGroupName EXTERNAL.IPIG % set addressContext default zone accesscore id 5 sipSigPort 4 ipAddressV4 10.35.66.179 portNumber 5060 transportProtocolsAllowed sip-udp ipInterfaceGroupName EXTERNAL.IPIG
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Base Provisioning > Signaling Ports > Sip Sig Port.
Packet Service Profile (PSP)
Packet Service Profiles control the media settings such as Codec, Packet Size, Transcoding options, and fax support on a trunk group. For example you can specify that only G.729A codec is allowed to the PHONES trunk group, while G.729A and G.711 are allowed to the ACCESSCORE trunk group. Each PSP can contain up to four Codec entries when using ERE. These Codec entries describe a codec, its packet size, and its law (A or U). Several default Codec entries are pre- configured on the system, and you can use these as an example to create your own.
The PSX supports configuring up to 12 codecs in the Packet Service Profile and Preferred Packet Service Profile. The SBC supports receiving all 12 codecs from the PSX in the PSP and Preferred PSP. This applies to interworking with an external PSX (Advanced ERE deployment scenario). See Routing and Policy Management for deployment scenario details. Additionally, the SBC supports up to 12 codecs over Gateway links to SBCs and/or GSXs. An SBC-POL-RTU license is needed to enable more than four codecs.
Note
Note
If you do not wish to use the default Codec Entries you will need to create custom Codec Entries before you can create Packet Service Profiles, since the PSP reference the Codec Entries. For example, you may want to have a PSP that specifies 20ms packet size, RFC2833 transport, allows for G.729A codec, and allows transcoding of G.711 to G.729A.
In our example two, Packet Service Profiles are created. You should create new PSPs based on the default one, instead of modifying the default one. And they should be named in such a way so that you can identify what their function is.
On the SBC main screen, go to Configuration > System Provisioning > Category: Trunk Provisioning > Packet Service Profile.
Codec Entry
The Codec Entry describes one specific codec that can be offered as part of the Packet Service Profile. Several default Codec Entries are included with the
Unable to show "metadata-from": No such page "_space_variables"
. It is recommended to name the Codec Entry in a descriptive manner, so it is easy to select during the Packet Service Profile creation or modification.Some of the key fields of the Codec Entry include:
- Codec – the actual codec to be used
- Packet Size – the size of each RTP voice packet, in milliseconds.
- Law – Alaw, Ulaw, derived from other leg
- DTMF Relay method – should RFC2833 be used, in-band or out of band
Example 1:
Create G711u_20ms_2833_T38 entry for internal side that uses 20 ms and 2833 only.
% set profiles media codecEntry G711u_20ms_2833_T38 codec g711 packetSize 20 law ULaw % set profiles media codecEntry G711u_20ms_2833_T38 dtmf relay rfc2833 removeDigits enable % set profiles media codecEntry G711u_20ms_2833_T38 fax toneTreatment faxRelayOrFallbackToG711 % set profiles media codecEntry G711u_20ms_2833_T38 modem toneTreatment fallbackToG711 % set profiles media codecEntry G711a_20ms_2833_T38 codec g711 packetSize 20 law ALaw % set profiles media codecEntry G711a_20ms_2833_T38 dtmf relay rfc2833 removeDigits enable % set profiles media codecEntry G711a_20ms_2833_T38 fax toneTreatment faxRelayOrFallbackToG711 % set profiles media codecEntry G711a_20ms 2833_T38 modem toneTreatment fallbackToG711
Example 2:
Create G711u_40ms_2833_T38, G711a_40ms_2833_T38, and G729ab_40ms_2833_T38 entries for pubic facing side, G.711u, G.711a and G.729A, all using RFC2833 and 40ms packet size.
G.711U 40ms_2833_T38:
% set profiles media codecEntry G711u_40ms_2833_T38 codec g711 packetSize 40 law ULaw % set profiles media codecEntry G711u_40ms_2833_T38 dtmf relay rfc2833 removeDigits enable % set profiles media codecEntry G711u_40ms_2833_T38 fax toneTreatment faxRelayOrFallbacktoG711 % set profiles media codecEntry G711u_40ms_2833_T38 modem toneTreatment fallbackToG711 % set profiles media codecEntry G711a_40ms_2833_T38 codec g711 packetSize 40 law ALaw
G.711a 40ms_2833_T38:
% set profiles media codecEntry G711a_40ms_2833_T38 dtmf relay rfc2833 removeDigits enable % set profiles media codecEntry G711a_40ms_2833_T38 fax toneTreatment faxRelayOrFallbackToG711 % set profiles media codecEntry G711a_40ms 2833_T38 modem toneTreatment fallbackToG711
G.729ab 40ms_2833_T38:
% set profiles media codecEntry G729ab_40ms_2833_T38 codec g729ab packetSize 40 % set profiles media codecEntry G729ab_40ms_2833_T38 dtmf relay rfc2833 removeDigits enable % set profiles media codecEntry G729ab_40ms_2833_T38 fax toneTreatment faxRelayOrFallbacktoG711 % set profiles media codecEntry G729ab_40ms_2833_T38 modem toneTreatment fallbackToG711
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Call Routing > Codec Entry.
IP Signaling Profile
IP Signaling Profiles control how various SIP egress and ingress parameters are set and processed. A unique profile should be used for each type of destination. Each trunk group has an assigned IP Signaling Profile. You can see this from the EMA GUI via Configuration > System Provisioning > Category: Trunk Provisioning > Ip Signaling Profile.
A trunk group has both an IP Signaling Profile and an Egress IP Signaling profile. The Egress IP Signaling profile is used for the outgoing signaling (sent from the trunk group).
The IP Signaling profile configured on the IP Peer will overwrite the IP Signaling profile configured on the trunk group.
The IP Signaling Profile "DEFAULT_SIP" is available to use. If you do not wish to use the default one as is, it is recommended to create a new one and leave the DEFAULT_SIP unchanged. You should use the default values for the IP Signaling profile, except for Access configurations, do the following:
- Turn on all Common IP Attributes: Relay flags (to allow all messages to pass through SBC).
- Turn on all Common IP Attributes: Transparency for headers.
- Turn on Egress IP Attribute: Transparency
Trunk Groups
An important concept on the SBC is that all signaling and routing is based upon Trunk Groups. Even in Access configurations, a set of endpoints is represented by a trunk group. It is convention that the trunk group names are CAPATALIZED.
For the example configuration, four trunk groups are created. Two are created for the "SIP Trunking" configuration and two for the "Access" configuration.
Trunk Group Usage
Trunk Group Name | Configuration Usage | Purpose |
|---|---|---|
CORE | Trunking | Trunk to operator network equipment (carrier that owns the SBC) |
PEER | Trunking | Trunk to far end (another carrier or PBX for example) |
PHONES | Access | Trunk to the set of phones |
ACCESSCORE | Access | Trunk to the operator (owner the SBC) feature server (Sonus ASX, PBX, etc.) |
% set addressContext default zone core sipTrunkGroup CORE ingressIpPrefix 192.168.75.5 32 % set addressContext default zone core sipTrunkGroup CORE media mediaIpInterfaceGroupName IPIG1 % set profiles signaling ipSignalingProfile CORE_IPSP egressIpAttributes numberGlobalizationProfile NO_GLOBAL_IP % set profiles signaling ipSignalingProfile CORE_IPSP commonIpAttributes relayFlags thirdPartyBodies enable % set profiles signaling ipSignalingProfile CORE_IPSP commonIpAttributes transparencyFlags unknownBody enable unknownHeader enable % set addressContext default zone core sipTrunkGroup CORE policy signaling ipSignalingProfile CORE_IPSP % set profiles media packetServiceProfile CORE_PSP codec codecEntry1 G711-EITHER_OOB-2833 codecEntry2 G729AEITHER_OOB-2833 codecEntry3 G729AB-EITHER_OOB-2833 % set profiles media packetServiceProfile CORE_PSP packetToPacketControl codecsAllowedForTranscoding thisLeg g711a,g711u,g729,t38 % set profiles media packetServiceProfile CORE_PSP packetToPacketControl codecsAllowedForTranscoding otherLeg g711a,g711u,g729,t38 % set addressContext default zone core sipTrunkGroup CORE policy media packetServiceProfile CORE_PSP % set addressContext default zone core sipTrunkGroup CORE state enabled mode inService
On the SBC main screen, go to Configuration > System Provisioning > Category: Trunk Provisioning > Trunk Group > SIP Trunk Group.
IP Peer
The IP Peer is the IP address of the far end device. The IP Peer is referenced in the Routing Label, and is used for outgoing calls for a particular Trunk Group.
If you define an IP Signaling Profile in the IP Peer (policy sub section), it will overwrite the one defined the in trunk group.
For Access configurations, it is not necessary to have a IP Signaling Peer to the individual phones. You do need one to the feature server.
% set addressContext default zone core ipPeer core_peer ipAddress 192.168.75.5 ipPort 5060 % set addressContext default zone peer ipPeer peer_peer ipAddress 10.35.66.187 ipPort 5060 % set addressContext default zone accesscore ipPeer accesscore_peer ipAddress 10.35.66.140 ipPort 5620
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Trunk Provisioning > IP Peer
Routing Label
The Routing Label is used by the Route object to send traffic from one trunk group to the other, and vice versa. Trunk Group routing is used for this purpose.
One Routing Label is created for each Trunk Group. This Routing Label is used to send calls to that Trunk group. In the below example, the Routing Label "TO_CORE" sends calls to "CORE" trunk group. There is also a Routing Label "TO_PEER" that sends calls to "PEER" trunk group.
% set global callRouting routingLabel TO_PEER routingLabelRoute 1 trunkGroup PEER ipPeer PEER inService inService % set global callRouting routingLabel TO_CORE routingLabelRoute 2 trunkGroup CORE ipPeer CORE inService inService % set global callRouting routingLabel TO_PHONES routingLabelRoute 3 trunkGroup PHONES inService inService % set global callRouting routingLabel TO_ACCESSCORE routingLabelRoute 4 trunkGroup ACCESSCORE ipPeer ACCESSCORE inService inService
To view the Routing workspace, select Configuration > System Provisioning > Category: Call Routing > Routing
When Trunk Group is selected as the option for Route Type, all Trunk Group related fields display.
When IP Peer is selected as the option for Route Type, the Trunk Group related fields are hidden and the field, "Zone for TG and IP Peer" is changed to "Zone for IP Peer". This selection allows you to create Routing Label Routes with just an IP Peer as an option.
For more information about configuring a Routing Label from the EMA, refer to Call Routing: System Provisioning - Routing.
Route
The Route is used to determine how call routing is done. There are different ways to implement routing (dialed number, carrier, calling number, trunk group, etc.) Trunk Group routing is used for this example configuration. It is the simplest and most straight forward way for a "pure" SBC function to be implemented. It allows the operator to add users / routable numbers without having to configure those numbers into the SBC.
For our Trunk Group routing, calls that arrive on trunk group "CORE" are sent to Routing Label "TO_PEER", which routes the call to trunk group "PEER". And in the other direction, calls that arrive on trunk group "PEER" are sent to Routing Label "TO_CORE", which routes the call to the "CORE" trunk group.
In the examples below "DALNBS01" is the name of the SBC being used in this document.
% set global callRouting route trunkGroup PEER DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL routingLabel TO_CORE % set global callRouting route trunkGroup CORE DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL routingLabel TO_PEER % set global callRouting route trunkGroup PHONES DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL routingLabel TO_ACCESSCORE % set global callRouting route trunkGroup ACCESSCORE DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL routingLabel TO_PHONES % commit
To view the Routing workspace, select Configuration > System Provisioning > Category: Call Routing > Routing
For more information on Routing Label, refer to Call Routing: System Provisioning - Routing.
Link Detection
Link Detection is only useful for HA systems (2 units).
Link detection is used to determine if the active unit needs to be failed over to the other unit. If a certain number of links (configurable) within a "link detection group" fail then a failover will occur. A link is considered failed if it loses connectivity to the router (for example if the cable is pulled or if the router port is turned down). In addition if a non-zero ping target IP address is configured, a link can be marked out of service if pings to this predefined IP address fail.
It is recommended to use 0.0.0.0 as the ping target for enterprise and simple deployments. This disables the "ping" test functionality (other link detection functionality is not affected). If you do wish to activate the system failovers using a ping target, please contact Sonus.
If you do activate the ping test functionality (configure a non-zero ping target) you need to be careful to ensure that the ping target IP will ALWAYS respond to "ping", otherwise the
Unable to show "metadata-from": No such page "_space_variables"
detects a link failure, and could cause a failover to the other unit.Configuration Questionnaire
There is an extensive amount of information you need to have up front, before starting the configuration of your
Unable to show "metadata-from": No such page "_space_variables"
. You will need to have completed the physical connectivity (Hardware Installation) and IP plan (what IP address will be assigned to each physical port) for your Unable to show "metadata-from": No such page "_space_variables"
. The IP Plan is generally completed using an Excel spreadsheet. This spreadsheet shows the IP address that will be allocated for each of the various interfaces in your network.Even for a simple network, it is important to create this document for future reference. See Creating an IP Plan for details. If needed, please contact Sonus for an example spreadsheet.
Information Needed for Software Application Installation
Once you have installed the
Unable to show "metadata-from": No such page "_space_variables"
hardware, the application software must be installed. As part of this installation, you will be prompted for some configuration information. This step is done from the EMA. The steps for installing the application are described in SBC Core Installation and Upgrade Guide. As a quick summary, the information configured during this step includes (for each unit of a High Availability (HA) pair:
- System Name
- Host name
- Management IP address for management port 0
- Management IP address for management port 1
- NTP server IP address
Call Processing Configuration for Simple Routing
Call Processing Configuration for Simple Routing
Field | Description | Example | Your Data |
|---|---|---|---|
Zones | SIP Port and Trunk Group reside in Zone. Each Zone represents an external customer (endpoints). | peer core phones |
|
SIP Port on Private | IP address used to send and receive SIP messages to equipment on the Private side of the network | 192.168.75.10 | Included in IP Plan |
SIP Port on Public side | IP address used to send and receive SIP messages to equipment on the Public side of the network | 10.35.66.189 | Included in IP Plan |
Trunk Group to Server |
| CORETG |
|
Trunk Groups to Server |
| PEERTG |
|
Codec Entries | One entry for each codec that could be used. Used in the PSP (below) | G711-20-RFC2833 |
|
Packet Service | Used by the Trunk Group to determine the Codecs, Packet Size, Transcoding | G711-EITHER_OOB- 2833 |
|
CDR Server (SFTP server) | IP address and log in information for a downstream SFTP server that will receive CDR sent by the SBC 5000 series |
|
|
Routing Label | One for each trunk group | TO_PEER TO_CORE |
|
Route | Using Trunk group routing. Trunk Group CORETG routes to Routing Label TO_PEER, and PEERTG routes to TO_CORE | 2 Routes added, one for each trunk |
CLI Script Creates Trunk Group and Routes
Key fields that will change for each trunk group added:
- NEW_TRUNK - trunk group name.
- 216.37.55.90 - ip address of far end.
- CAC call limit currently 50
- rlToNEW_TRUNK - routing label to NEW_TRUNK
- peerNEW_TRUNK - ip peer NEW_TRUNK
- Numbers that route to the pbx - 7652320276 (the below script assumes that the following are already defined):
- PBX_SIP- ipsignaling profile
- pspMediaRelay - packet service profile
- "#" = comment lines
# Start of Scrip to add a new trunk group and routing information # CREATE trunk group configure set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" media mediaIpInterfaceGroupName "customerPublic" set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" ingressIpPrefix "216.37.55.90" "32" set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" policy media packetServiceProfile "pspMediaRelay" set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" policy signaling ipSignalingProfile "PBX_SIP" set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" signaling methods message "reject" publish "reject" subscribe "reject" notify "reject" info "reject" register "reject" update "reject" set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" cac callLimit "50" set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" mode inService set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" state enabled commit # Far end IP set addressContext "default" zone "zonePublicTrunking" ipPeer "peerNEW_TRUNK" ipAddress "216.37.55.90" ipPort "5060" ## need to add PSP and sig profile set addressContext default zone zonePublicTrunking ipPeer peerNEW_TRUNK policy ipSignalingProfile PBX_SIP set addressContext default zone zonePublicTrunking ipPeer peerNEW_TRUNK policy packetServiceProfile pspMediaRelay commit # Numbers and routing label - do a commit after each 5 number ranges added commit set global callRouting routingLabel "rlToNEW_TRUNK" routingLabelRoute "1" trunkGroup "NEW_TRUNK" ipPeer "peerNEW_TRUNK" commit set global callRouting route "none" "Sonus_NULL" "Sonus_NULL" "standard" "7652320276" "1" "all" "all" "ALL" "none" "Sonus_NULL" routingLabel "rlToNEW_TRUNK" set global callRouting route "none" "Sonus_NULL" "Sonus_NULL" "standard" "7652320277" "1" "all" "all" "ALL" "none" "Sonus_NULL" routingLabel "rlToNEW_TRUNK" set global callRouting routingLabel "rlToNEW_TRUNK" commit exit # End of Script
Overview
Content Tools