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 Context, Packet Service Profile, IP Signaling Profile, Trunk Groups, Signaling Ports, Routes and Interfaces.
Basic Configuration Objects
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 when overlapping local IP addresses (e.g., 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.
The below rule blocks all traffic that is not explicitly allowed:
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.
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).
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:
- 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
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.
The following example sets an Address Context "default" to Zone "peer" with an ID of "2".
SIP Signaling Port
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, 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.
- SIP Signaling Port 1: 100.110.120.130 port 5060
- SIP Signaling Port 2: 100.110.120.130 port 5070
- SIP Signaling Port 3: 100.110.120.130 port 5080
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.
- SIP signaling port 1 - IPv4 address
- SIP signaling port 2 - IPv4 address
- SIP signaling port 1 - IPv6 address
- SIP signaling port 2 - IPv6 address
- SIP signaling port 1 - IPv4 / IPv6 addresses
- SIP signaling port 2 - IPv4 / IPv6 addresses
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.
This example sets address context "default" to zone "core" with an ID of 3 and SIP signaling port to 2 for IP interface group "IPIG1" at IP address.
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.
Note Trunk group names must be unique across all address contexts, zones, and trunk group types. Note IP peer names must be unique across all address contexts, and zones.
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.
This example creates a core SIP trunk group:
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.
Note 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. Note An SBC-POL-RTU license is needed to enable more than four codecs.
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:
- Packet Size
- Transcoding options
- Fax support
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.
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
This example creates G711u_20ms_2833_T38 a G.711u entry for internal side that uses 20 ms and 2833 only.
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.
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.
This example binds IP Peer "core_peer" to zone "core" and assigns IP address 126.96.36.199 to it with port 5060.
Global Call Routing
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.
This example sets routing label "TO_PEER" to send calls to trunk group "PEER".
A Route is used to determine how call routing on SBC is accomplished. There are various ways to implement routing, such as:
- Dialed number
- Calling number
- Trunk group
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.