Infobip’s in-house built platform processes over 200 million daily transactions for more than 200,000 business users worldwide – developers, internet companies, banks and others. A large number of these companies are using our platform to route voice calls.

Building the capacity to route calls by ourselves was quite a challenging thing to do. It required close collaboration of developer teams and a couple of weeks of research and development. What is interesting – it was not all about coding.

Our Voice team had to set-up the session border controller (SBC*) to resolve the incoming voice calls via an ENUM* based server developed by SMS monitoring team, which makes routing requests to IPCore to make it choose a gateway.

It actually involved very little coding, and it was more about coupling existing components into a puzzle which I will try to depict here.

After the session border controller has received an incoming call it needs to resolve the dialed number into an IP address to which the call will be routed. This was pre-configured by looking up a static configuration that maps every number prefix to a specific IP address.

Maintaining such a complex configuration was challenging, as it didn’t integrate well with the rest of Infobip ecosystem, where routes are normally managed through our internal account managing tool.

Conveniently, SBC can be configured to make ENUM requests which are basically DNS lookups that are resolving a dialed number to an IP address. We didn’t analyze the whole RFC3761, we just took wireshark dumps of UDP packets and reverse-engineered the protocol.

Among with the dialed numbers, SBC also sends the client’s IP address which the SBC ENUM proxy then uses to resolve it to our SmsChannelId by calling the SBC API service.

When we have a dialed number (destination address) and our client’s ID (SmsChannelId), we can ask IPCore to choose a gateway. We do this by simply submitting the message to the dialed number on behalf of the client, letting our IPCore team use standard routing rules for choosing a gateway.

Every gateway is configured to send an HTTP request back to the SBC ENUM proxy service. The HTTP request contains the gateway’s IP address, which is the actual result of the initial ENUM query, and it is returned to SBC.

Not only we exposed existing routing mechanism to SBC, with standard Infobip tooling to manage it, but we also got several other benefits:

TRACEABILITY – every routing request is visible in MessageLog part, along with other traffic, denoted by requestType 43. This allows us to analyze routing requests, for example in Routing Test Form. Also, requests from the gateway are visible in communication logs, which resulted in increased transparency. This, in turn, had direct impact on the ability of other technical teams to monitor the routing processes much better than before.

MNP SUPPORT – now we can handle ported numbers properly by performing number lookups, and make better gateways choices. This was a significant improvement in service quality experienced by our clients, as it allowed us to achieve even better rates in successfully connected calls. It also enabled considerable optimisation of costs for all the businesses that use our platform for routing their voice calls.

ADVANCED ROUTING CAPABILITY – the static SBC configuration was limited to route-by-prefix rules, whereas now we can implement and perform more complex routing rules. We can perform gateway balancing, offer customized routes for clients, as well as blacklisting and many other features that are key to a professional voice service needed by our clients.

By Milan Mimica, Software Engineer at Infobip