Call me Now

What is a Session Border Controller?

By Mark Snow

Coming from the Voice arena, we are all very familiar with a Voice Gateway and what it does. It typically either originates traffic from a POTS connection and sends it along its way via VoIP (or if you’re old school – possibly VoFR, VoATM, VoDSL, etc, etc), or it has an incoming call leg via VoIP and terminates that stream on any number of POTS’ connections (PRI, CAS, FXO, FXS). Whether it is an Originating Gateway (OGW) or a Terminating Gateway (TGW), we know that we have 2 call legs – and incoming call leg and an outgoing call leg per every Voice gateway (or router) in our administrative domain.

So what happens if we, as a corporation, wish to pass VoIP traffic off to a Service Provider? Or possibly if we are running a service provider and we wish pass VoIP traffic off to a corporate subscriber, a residential subscriber, or possibly even another service provider? Should we just simply extend to them a SIP or H323 Trunk? We certainly could, but where you can do something, doesn’t mean you should! Where do per-user Security, Billing, Codec Translation, Signaling Internetworking, CAC, and QoS come into the picture? These are certainly important topics and worth looking into.

Enter the concept of something known as a Session Border Controller (SBC). Cisco is actually a relatively new player to the SBC arena, and has a decent product. They refer to the SCB also interchangeably as an IP-to-IP Gateway or IPIPGW. This naming actually sheds some light on the operations of the box. Instead of a traditional OGW or TGW, an IPIPGW has it’s incoming call leg consisting of VoIP as well it’s outgoing call leg also being VoIP. So why would want to have an incoming VoIP leg and an outgoing VoIP leg? We already mentioned a few reasons such as Security, Billing, QoS and Codec, but lets dive deeper into how these actually would work.

An IPIPGW or SBC allows us to connect two very different networks. Lets say we are a service provider that runs mostly SIP trunks in our internal VoIP network, but we have a corporate client that has an older IP PBX only capable of handing us an H323 trunk – are we stuck? Well of course not. The IPIPGW will allow us to accept an incoming H323 VoIP call leg connection (in from our client), and spit out the other end (the end toward our SP core network) a SIP VoIP call leg. Furthermore, it will allow us a demarcation point (the incoming call leg VoIP Dial Peer) by which we can attach a TCL or VXML script that might induce billing or even allow Federal Law Enforcement Officials to start the Lawful Intercept feature. On the outgoing IP interface, we again have an perfect demarcation point to change any metrics related to QoS. Maybe we wish to re-mark the DSCP PHB and have our own Queuing strategy on the egress of the SBC. Maybe the corporate client sends us voice traffic using the G.711ulaw codec, but we as a provider wish to bump that down to a G.729r8 bit rate codec – again the IPIPGW provides the proper administrative device with which to do this. Security is inherit to the concept in that we are telling our corporate client to point their H323 Trunk to a specific IP address – being the IP address on the SBC router – and thereby not giving them any information relating to the internal IP addressing schemes in our core network. On top of that we could just as easily turn on Cisco’s IOS FW Feature Set on the same SBC router, to further protect our internal network from inadvertent worms or attacks that might originate from our client’s network. Obviously one would need to choose the proper sized router for the amount of features one wishes to turn on in conjunction with the amount of IP traffic allowed. CAC can be accomplished by a number of means – the simplest of which is simply putting a “max-conn 24” statement on the incoming VoIP Dial Peer – thereby emulating a T1 CAS worth of voice channels (24) but of course with much more feature rich components of the IP signaling protocol than a T1 CAS could support.

So why is this important to CCIE Voice candidates and where could this really come into play? Well since July of 2006, CCIE Voice has been testing using IOS version 12.4.3 mainline code. IPIPGW or SBC was introduced in IOS version 12.2(13)T3, meaning the concept is certainly fair game as a testable topic. But where might we see this? Well it certainly can be used as a stand alone gateway. It can be used in conjunction with H323 Gatekeepers as well as SIP Proxy Servers. But one very interesting place that this could show up would be in conjunction with Cisco Unity Express (CUE) and CME. CUE only speaks the SIP protocol if integrated with CME (it uses JTPAI for CCM integrations). It also only speaks the G711 codec. So if by chance you had the need to bring in a G729 H323 trunk from another GW (Say CCM or another CME box), and needed to terminate that on CME – well no problem. But the minute you need that incoming trunk to ring a phone, and then roll over to VM in a ring no answer situation – well now you are talking about a network that has an incoming call leg of VoIP – H323 – G729 and an outgoing call leg of VoIP – SIP – G711ulaw – and you are going to need to configure a IPIPGW to make that work.

Looking to the configuration of such - lets address the first basic need that we have – and that is to turn on support for this feature in IOS. We need to determine what signaling protocol will be coming in, and what protocol will be going out. So here we have the example configuration in global config mode:

voice service voip
allow-connections h323 to sip

Now we need to define our incoming dial-peer and we will assume that the Dial Plan on the GW sending calls to CME runs DN’s in the 3xx range. This dial-peer will be G729 and H323 which do not show up in the dial-peer config because of course they are the default.

dial-peer voice 10 voip
incoming called-number 3..
dtmf-relay h245-alphanumeric

Next we need to define an outgoing dial-peer that will point to the CUE module and will have DN’s in the 5xx range.dial-peer voice 20 voip
destination-pattern 5xx
session protocol sipv2
dtmf-relay sip-notify
session target ipv4:10.1.202.2
codec g711ulaw
no vad

Now we need to address the issue of transcoding the G729 into a G711 codec for the CUE engine to understand. We will need a DSP on the IPIPGW router that is not in use, and we will need it to register to a SCCP server. CME (or SRST) does quite nicely. We will configure the following:

voice-card 0
dsp services dspfarm
!
interface FastEthernet0/0
ip address 10.1.202.1 255.255.255.0
!
sccp local FastEthernet0/0
sccp ccm 10.1.202.1 identifier 1
sccp
!
sccp ccm group 1
associate ccm 1 priority 1
associate profile 1 register mtp00128031d058 <-- MAC Add of FastEth
0/0
!
dspfarm profile 1 transcode
codec g711ulaw
codec g729ar8
maximum sessions 2
associate application SCCP
!
telephony-service
max-ephones 20
max-dn 48
ip source-address 10.1.202.1 port 2000
sdspfarm units 1
sdspfarm transcode sessions 2
sdspfarm tag 1 mtp00128031d058

That pretty much does it for the IPIPGW configuration. The transcoder will automatically be induced when the need arises. There are other considerations to keep in mind for calls coming into CME rolling to CUE, especially when CCM is sending the call, but that is outside the scope of this article pertaining to SBC’s.

Please join us in a Boot Camp soon to discover all the "ins and outs" of this scenario as well as many fun others!