SBC Core Application Architecture

This section describes the high-level SBC Core application architecture and the primary configuration objects. 

High Level Architecture

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.

High-Level Architecture

Basic Configuration Objects

This topic describes the basic SBC Core configuration objects including CLI command syntax and examples.

Address Context

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

IP Interface

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.

IP Interface Group

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).

Physical Port

A Physical Port (four ports for SBC 5400 and SBC 7000) 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.

Zone

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:

• Call Admission Control
• DNS Group
• SIP Signaling Port/H.323 Signaling Port/ GW Signaling Port
• SIP/H.323/Gateway Trunk Group
• IP Peer (Signaling Endpoints)
• Message Manipulation
• Remote Device Type

For hardware appliances, up to 2,048 zones (SBC 5400) and 4,000 zones (SBC 7000) are configurable. The SBC SWe supports 129 zones ("small" profile) or 4,000 zones ("large" profile). 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.

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

SIP Signaling Port

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

Trunk Groups

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:

• There can be multiple SIP trunk groups per Zone.
• A single SIP trunk group can represent a group of peer devices (endpoints).
• An Ingress SIP trunk group is selected by matching the layer 3 address on a signaling peer to any entry in an Ingress IP Prefix table associated with the trunk group. This table is provisioned when building the trunk group.

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

Profiles

Packet Service Profile

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 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:

• Codec
• Packet Size
• Transcoding options
• Fax support

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

Codec Entry

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:

• Codec — the actual codec to be used
• Packet Size — the size of each RTP voice packet, in milliseconds
• Law — (G.711 only) A-law, u-law, derived from other leg
• DTMF Relay method — RFC2833, in-band or out of band

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 Profile

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

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

Global Call Routing

Routing Label

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

Route

A Route is used to determine how call routing on SBC is accomplished. There are various ways to implement routing, such as:

• Dialed number
• Carrier
• Calling number
• Trunk group

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