Gateway routing

Whether gateways have SIP trunks, PRIs or analog lines and devices, they all need to make routing decisions. In very simple architectures, a gateway only connects two systems – usually the PSTN and SfB – so there are no decisions to be made. Calls coming in one interface are sent out the other.

When you have multiple interfaces and systems to route between, you have a number of options for routing choices. In most cases, you can combine these choices.

Static Routing

Static routing is the least technical option is the most administratively demanding. You build a list of numbers, and assign them a destination. Static routing could include listing every single number, or it could be patterns like 425555xxxx or 74xx.

Analog devices that are connected to a larger gateway, possibly the same gateway used for your telco connection, are easy to route to. When a call reaches the gateway, it checks what numbers belong to devices connected directly to it, and delivers the call their rather than routing it to another destination. These gateways tend to not have very many analog ports, and you might also not be able to connect all of your analog devices to one gateway because of cable runs and gateway locations.

Gateway/SBC Registration

Analog only gateways such as the MediaPack from AudioCodes and Tenor from Sonus can integrate into their respective larger gateways. This integration allows you to treat the ports on the MediaPack or Sonus as if they were on the larger gateway. This gives you the simple routing of “connected” devices, yet allows you to have a number of different gateways in different locations. In this configuration, the analog gateway registers each analog device as a SIP endpoint in the larger gateway or SBC.

Active Directory Lookups

Both Sonus and AudioCodes offer the ability to use Active Directory to determine where a call should be routed. In the simplest SfB configuration, the gateway queries AD to see if the destination phone number is assigned to the msRTCSIP-Line attribute of any user. This attribute is the SfB LineURI, so a match indicates that the number belongs to a user in SfB, and that the gateway should route to the call to SfB. Calls that don’t match can be directed to another location, perhaps a legacy PBX. It’s possible to use more than the msRTCSIP-Line attribute, and build some very complex and dynamic route configurations. Be sure to account for other attributes for different devices like dial in conferencing, auto attendants, and other endpoints that don’t use the msRTCSIP-Line attribute of a user object.

Brute Force Method

If you don’t want to deal with Active Directory lookups, or are in a scenario where that method might not be suitable, you can take advantage of failover behavior. If you configure a gateway to deliver all calls to one destination – say a legacy PBX – and the number isn’t a valid endpoint on that device, the call should be rejected. The gateway can then delivery that call to the next destination in the route table, and so on, until the call is delivered or the destinations in that table are exhausted and the call fails.

And that covers gateway routing. Up next, SfB routing options.