SS7-to-SIP gateways - are you for or against encapsulation?

So, what are we talking about here, encapsulation in the context of SS7-to-SIP gateways? Let’s have an analogy; it’s always good to have an analogy and it’s certainly better than an apology.

Find this image at Listal

Let’s imagine you are the Martian delegate at a plenary conference between the third and fourth planets, and your speech is delivered in Martian. An interpreter – an electronic device – is used to simultaneously translate your Martian to Mandarin (the language spoken in the other planet’s future). And, except for leaving out the ‘uhmns’ and ‘aahs’ in your delivery, the converter delivers your Red Planet speech in perfectly understandable Mandarin.

You grok what that ‘gateway’ is doing – it gives your audience the essential data, leaving out only the protocol-level messages; those ‘uhmns’ and ‘aahs’ that mean, “Hang on, I’ve got more to say.” That’s a very useful gateway if the receiving endpoint wants to hear only Mandarin.
Here’s a further analogy. If the gateway were to capture the speaker’s voice as a .ufs (Universal file system) attachment and route that through to its destination, what would happen? The receiver would have to perform its own translation, before delivering your Martian speech in Mandarin. Surely, that’s a less useful gateway.



Yes, the latter gateway performs the essential function of encoding and routing from A to B, however, it means the far end device has to have its own Mandarin translator. More to the point, the receiving endpoint vendor has to know Mandarin, to be able to implement the translation in its product. If translating isn’t your core business, you probably don’t want to do that.

Here’s the real life comparison. In SS7-to-SIP gateways, the ‘translation’ is between protocols (there is a transcoding between say, G.711 µ-law and G.711 RTP, but we shall ignore the speech data in this analogy). The gateway ‘speaks’ SS7 and is able to extract the protocol messages needed to ‘talk’ SIP to the receiving endpoint. More importantly, it is able to pull out and pass on – translate – the information needed by the far end device.

Armed with, for example, a Charge Number or an Emergency Services Routing Key (ESRK), the receiver can do its job. That task could be the routing of a call to a Public Safety Answering Point (PSAP) via an NG9-1-1 SIP-based network. If the receiving device needs more information from within the SS7 signalling messages and parameters, interface specifications exist to ensure both devices (the gateway and the receiver) can interoperate. In this scenario, we have a really useful, real life gateway.

In an alternative, real life setting, if the gateway merely encapsulates the SS7 signalling messages, in their entirety, within a SIP INVITE and under an SDP raw data header, you end up with something akin to the above .ufs attachment example. That means the receiver has to extract and interpret – translate – the SS7 messages and message parameters.

For the vendor of the receiving endpoint equipment, that translation task might not be a problem. However, if specialist SS7 knowledge isn’t within its core competencies, it might just be an issue. Not insurmountable; nevertheless, developing (or procuring) an SS7 protocol stack is something a vendor would rather avoid. An SS7-to-SIP ‘encapsulating’ gateway, if that’s the only option it offers, is less attractive to manufacturers of SIP devices.

As a final contrast, consider a situation where the provider of the SIP appliance, for reasons determined by its application, needs access to SS7 message data that isn’t defined by a specification. Where there is no established method for ‘translating’ a given SS7 message to an ‘equivalent’ SIP header, the obvious solution might be to employ encapsulation. The down side with that is the same as before – significant extra cost for the developer of the SIP device (SS7 stacks don’t come cheap).

If the vendor has a good relationship with the manufacturer of the gateway, often a more straightforward solution to this final scenario is for the two parties to implement a system of mutually recognisable (by the software application) SIP headers. If the gateway product company makes a reasonable charge for its changes, the SIP equipment company still gets a far more cost-effective outcome.

What would you rather do; implement Aculab_Call_Information: Call-ID=xxxx;Trunk=yy;Channel=zzz as a SIP INVITE header in your application or develop your own SS7 stack interpreter?

For more information, check out Aculab’s really, really useful, real life gateway – GroomerII.