In this section:
This section describes the high-level SBC Core application architecture and the primary configuration objects.
This diagram depicts the high-level SBC Core application architecture and describes the configuration objects used when creating a basic call flow, such as Address Contexts, Packet Service Profiles, IP Signaling Profiles, Trunk Groups, Signaling Ports, Routes and Interfaces.
This topic describes the basic SBC Core configuration objects including CLI command syntax and examples.
An address context includes all objects associated with a particular IP address space. This includes IP packet interface groups, zones, as well as the contents of each of these objects. In a "flat" IP address space such as the public IP address space, only the single "default" address context is necessary. Additional address contexts are only needed to accommodate overlapping local IP addresses (e.g., the same IP addresses used in multiple networks connected to the same SBC).
A default address context implicitly includes the management interface group and its contained management interfaces. These interfaces are considered "trusted" network interfaces.
Command Syntax
% set addressContext <addressContext name> diamNode dnsGroup intercept ipAccessControlList ipInterfaceGroup ipsec linkDetectionGroup natDirectMediaGroup rtpServerTable staticRoute zone
Example
The below rule blocks all traffic that is not explicitly allowed:
% set addressContext default ipAccessControlList rule DENYALL_UNTRUST precedence 65015 ipInterfaceGroup EXTERNAL.IPIG action discard
An IP Interface represents an IP address assigned to a physical port in the system. An IP Interface is associated with an IP Interface Group, and may contain a VLAN tag. VLAN tags are required if more than one IP Interface is associated with a single physical port on the SBC.
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.
Do not configure more than 2,048 VLAN tags on the SBC 5100 due to memory constraints.
An IP Interface Group is a named object and contains one or more IP interfaces (IP addresses). An IP Interface Group is Address Context specific, and is permanently bound to a particular Address Context.The service section of an IP trunk group, and a Signaling Port will reference an IP Interface Group typically for purpose of restricting some sort of activity to that IP Interface Group (signaling and media respectively).
A Physical Port (four ports for SBC 52x0, SBC 5400 and SBC 7000; two ports for SBC 51x0) is independent of Address Context. If using VLAN tags, a port may carry multiple IP Interfaces in the same or different Interface Groups or Address Contexts. MAC addresses are assigned on a per-Port basis.
The first IP Interface assigned to a port determines if VLAN tagging is used or not. If a VLAN tag is used on the first IP Interface associated with a port, all IP Interfaces for that port must have VLAN tags.
A Zone groups a set of objects (for signaling and call routing information) for a particular Address Context (customer environment). A zone is permanently bound to a particular Address Context, and is normally allocated per customer, per carrier, per organization or per service level associated with one of the above groups. When configuring a zone, include zone name and ID as indicated below.
Zone objects include:
Up to 2,048 zones (SBC 5000 series and SBC SWe) and 4,000 zones (SBC 7000) are configurable. A zone may reference other objects within the address context such as interface groups, DNS server groups, etc. While these objects may only be used by one customer, the SBC allows them to be shared among customers so they are configured outside the zone.
The zone may also reference global objects such as call routing labels and call routes. Again, even though some global objects may only apply to one customer, the SBC allows global objects to be shared among customers so they are configured outside the zone.
For comprehensive provisioning limits, see SBC Provisioning Limits.
Example
The following example sets an Address Context "default" to Zone "peer" with an ID of "2".
% set addressContext <addressContext_name> zone <zone_name> cac dnsGroup gwSigPort gwTrunkGroup h323SigPort h323TrunkGroup id ipPeer messageManipulation remoteDeviceType sipSigPort sipTrunkGroup
% set addressContext default zone peer id 2
A SIP Signaling Port is a logical address permanently bound to a specific zone and is used to send and receive SIP call signaling packets. A SIP Signaling Port is capable of multiple transports such as UDP, SCTP, TCP and TLS/TCP.
SBC Core supports up to 16 SIP Signaling Ports per zone. These SIP Signaling Ports can use the same IP address, but each must have its own unique UDP/TCP port. In the example below, three SIP Signaling Ports are created using the same IP address but each with a unique UPD port.
A SIP Signaling Port can contain an IPv4 address, an IPv6 address or both. However, all SIP Signaling Ports within a particular zone must use the same address types as shown in below examples.
Example 1:
Example 2:
Example 3:
A SIP Signaling Port must reference one IP Interface Group signifying that signaling associated with that port is restricted to IP Interfaces in that group. Only reference IP Interface Groups within the same Address Context.
Command Syntax
% set addressContext <addressContext_name> zone <zone_name> sipSigPort <sipSigPort index> dscpValue ipAddressV4 ipAddressV6 ipInterfaceGroupName mode portNumber recorder sctpProfileName state tcpConnectTimeout tlsProfileName transportProtocolsAllowed
Example
This example sets the address context "default" to include a zone "core" with an ID of 3, a SIP signaling port set to 2, and an IP interface group "IPIG1."
% set addressContext default zone core id 3 sipSigPort 2 ipInterfaceGroupName IPIG1 ipAddressV4 100.110.11.10 state enabled
The SBC autonomously manages calls to and from its signaling peers through Trunk Groups. Trunk groups enable the SBC to provide call management functions (services processing, routing, call admission and accounting, reporting, etc.) for packet-to-packet communications.
Trunk groups are also used for call management between SBC within a carrier's network (known as SIP Trunk Groups in the core) as well as between SBCs in a carrier's core VoIP network and outside VoIP devices (SIP Trunk Groups at the network edge). These other VoIP devices are either under the carrier's administrative control or reside within the network of a packet peering partner.
The SBC signaling and routing is based on SIP and H.323 trunk groups. For SIP trunk groups, the following applies:
Trunk group names must be unique across all address contexts, zones, and trunk group types. IP peer names must be unique across all address contexts, and zones.
Command Syntax
% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <TG_NAME> action cac callReservation callRouting congestionHandling downstreamForkingSupport dryUpTimeout ingressIpPrefix media mode packetOutage parentSharedCacLimitsPoolName policy qoe services recordingDNpreference signaling state ucidSupport
Example
This example creates a core SIP trunk group:
% set addressContext default zone core sipTrunkGroup CORE media mediaIpInterfaceGroupName IPIG1
A Packet Service Profile (PSP) contains a list of up to four codec entries using ERE, and defines various parameters associated with voice packet traffic between SBC and any IP-based remote device.
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.
The SBC makes appropriate negotiations and transcoding decisions based on PSP information. PSPs for voice packet traffic between a SBC and a remote device are provided to the SBC by the Embedded Routing Engine (ERE) or external PSX as part of the Policy Response.
IP trunk groups are each assigned a PSP used for all calls (in or out) on that trunk group. The default PSP is G711 only (no transcoding).
Packet Service Profiles control the following trunk group media settings:
Command Syntax
% set profiles media packetServiceProfile <packetServiceProfile name> aal1PayloadSize codec dataCalls flags honorRemotePrecedence mediaPacketCos packetToPacketControl peerAbsenceAction preferredRtpPayloadTypeForDtmfRelay rtcpOptions secureRtpRtcp sendRoutePSPPrecedence silenceFactor silenceInsertionDescriptor t38 typeOfService videoCalls voiceInitialPlayoutBufferDelay
Example
This example sets a media profile with a Packet Service Profile named "PSP" that uses a Silence Factor of "40", Type of Service "0", Voice Initial Playout Buffer Delay of "10", Aal1 Payload Size of "47", Preferred RTP Payload Type for DTMF Relay of 128, Media Packet COS of 0 and Honor Remote Precedence disabled.
% set profiles media packetServiceProfile PSP silenceFactor 40 typeOfService 0 voiceInitialPlayoutBufferDelay 10 aal1PayloadSize 47 preferredRtpPayloadTypeForDtmfRelay 128 mediaPacketCos 0 honorRemotePrecedence disable
A Codec Entry object describes a specific codec that can be offered as part of the Packet Service Profile. Several default Codec entries are pre-configured on the system, and are a good starting point when creating your own. It is recommended to name your Codec Entries in a descriptive manner for easy selection during PSP creation or modification.
Codec Entry key fields:
Command Syntax
% set profiles media codecEntry <codecEntry_name> codec codingRate dtmf fax law modem packetSize preferredRtpPayloadType sendSid
Example
This example creates G711u_20ms_2833_T38 a G.711u 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
IP Signaling Profiles control how various SIP egress and ingress parameters are set and processed by specifying the parameters associated with H.323, SIP, and SIP-I communication sent as part of the outgoing signaling messages after applying standard protocol rules.
You may associate IP signaling profiles with IP trunk groups and virtual trunk groups. A unique profile must be used for each type of destination. A default IP Signaling Profile, "DEFAULT_SIP", is available for use. If changes are required, rather than modifying the default profile, create a new IP Signaling Profile.
Command Syntax
% set profiles signaling ipSignalingProfile <unique_identifier> commonIpAttributes egressIpAttributes ingressIpAttributes ipProtocolType
Example
% set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes callTransferFlags forceReRouteViaPsxQuery enable
IP Peer is the IP address of the far-end device, and is permanently bound to a particular Zone. The primary purpose of this object is to facilitate outbound call routing. An IP Peer is referenced in the routing label, and is used for outgoing calls for a particular trunk group. For inbound calls, the set of IP Peers associated with the give Zone is searched using the peer IP address as the key.
For access configurations, one IP Peer is assigned to the feature server, not for each individual phone. If you define an IP Signaling Profile in the IP Peer (policy subsection), it overrides the profile defined in the trunk group.
Command Syntax
% set addressContext <addressContext> zone <zone> ipPeer <ipPeer_name> defaultForIp ipAddress ipPort pathCheck policy sip surrogateRegistration
Example
This example binds IP Peer "core_peer" to zone "core" and assigns IP address 111.100.11.1 to it with port 5060.
% set addressContext default zone core ipPeer core_peer ipAddress 111.100.11.1 ipPort 5060
A Routing Label consists of a set of routes and gateway/trunk group pairs. The Routing Label sends traffic between two trunk groups. One Routing Label is created for each trunk group, and is used to send calls to that trunk group.
Command Syntax
% set global callRouting routingLabel <routingLabel_name> action overflowNOA overflowNPI overflowNumber routePrioritizationType routingLabelRoute script
Example
This example sets routing label "TO_PEER" to send calls to trunk group "PEER".
% set global callRouting routingLabel TO_PEER routingLabelRoute 1 trunkGroup PEER ipPeer PEER inService inService
A Route is used to determine how call routing on SBC is accomplished. There are various ways to implement routing, such as:
Command Syntax
% set global callRouting route <routingType>
Example
In this example, a trunk group route is set to send calls arriving on trunk group "PEER" to Routing Label "TO_CORE" which routes call to "CORE" trunk group.
% set global callRouting route trunkGroup PEER DALNBS01 standard Sonus_NULL 1 nationalType nationalType ALL none Sonus_NULL routingLabel TO_CORE