In this article we’ll explore how to provide Emergency Standalone (ESA) function when you have a TelcoBridges media gateway operating with a Metaswitch CFS.
Late last year Metaswitch and TelcoBridges announced a partnership to provide greater interoperability between the Metaswitch ecosystem and Tmedia media gateways, with the intent that TelcoBridges media gateways could serve as a long-term option for a TDM media gateway for telcos using the Metaswitch solution.
We’ve been paying close attention to this situation. We think the partnership is great news for telcos, but we also think telcos may need help to integrate the two platforms into their network. So in January we announced our own partnership with TelcoBridges and we want to make sure we can provide technical assistance to anyone integrating the two platforms.
Emergency Standalone (ESA)
With a traditional Metaswitch media gateway, the hardware and software was identical to that of an integrated softswitch. This meant that if the media gateway was ever isolated from the core network, the UMG could be converted into an integrated softswitch, and provide emergency standalone (ESA) functionality to local users during the outage.
However, if you replace that Metaswitch media gateway with a TelcoBridges Tmedia then you obviously can’t convert that hardware into a Metaswitch CFS – so that method of ESA is no longer available.
What options do we have for ESA?
At a high-level, there are two different ways to approach ESA functionality in a hybrid network. I’ll summarize them first, and then we can explore what each of these options entails.
- Use ESA Proxy (from Metaswitch) and configure the Tmedia as an independent signaling gateway.
- Use ESA Proxy and an AGC/MGC component (from Metaswitch) and configure the Tmedia as an H.248 media gateway controlled by the AGC/MGC.
(Note that at the time of writing we have not implemented these architectures for a client – but we have discussed with both vendors to confirm our understanding of how this should work.)
What is ESA Proxy?
ESA Proxy is a Metaswitch product that acts as a SIP registrar for all local SIP devices (meaning that all SIP lines register to the ESA Proxy), but then forwards that registration over to the CFS – while keeping a cache of the registration information. In the event that the local site becomes isolated from the CFS, the SIP lines are still registered to ESA Proxy, which can then handle call processing locally.
ESA Proxy provides some simple call handling functionality, so if it becomes isolated it can:
- Route calls between subscribers using the existing registrations
- Route 911 calls to a specific line (e.g. the sheriff’s office) if the PSAP is not reachable
- Route all other calls over a designated SIP trunk.
What is an AGC/MGC?
The terms Access Gateway Controller and Media Gateway Controller come from IMS, but for our purposes this is basically a network element that can convert from SIP to MGCP / H.248. Metaswitch uses this product in a clustered CFS environment or when deploying IMS – and they’re also important for our scenario here.
Option 1: ESA Proxy with independent Tmedia signaling gateway
In this first scenario, you would configure the Tmedia independently from the Metaswitch CFS. It would have its own point code, its own A-links and ISUP trunks, and all the routing would be configured directly on the Tmedia itself (not through MetaView on the CFS).
As a consequence, from a trunking point-of-view, the Tmedia already has all it needs to operate if the local site is isolated from the core network (the dotted line below separates the CFS in the core network, from everything else in the remote location).
So if ESA kicks in, ESA Proxy can handle the subscribers, and then route any trunk calls to the Tmedia (over SIP) which can then route off-net (to the extent that PSTN trunking is still available).
Option 2: ESA Proxy, AGC/MGC and an H.248 Tmedia gateway
Of course, the downside in option 1 is that you would need to configure each Tmedia independently, rather than having all control function and routing (for subscribers and trunking) managed centrally on the CFS. A much more natural approach (for those used to a Metaswitch environment) would be to configure the TelcoBridges media gateway to be controlled using H.248. In this case all media (TDM and IP port) assignments could be managed centrally by the CFS, in exactly the same way that the CFS manages a Metaswitch UMG.
This model can still work for ESA, but you need to add an additional component – the AGC/MGC – to convert from SIP (the interface from the CFS / ESA Proxy) to H.248 when communicating with the media gateway.
This is the scenario envisioned by Metaswitch in their documentation here (login required).
Which is the best option for me?
Unfortunately there’s no perfect answer – it will depend on your situation. In particular it depends on what features you have purchased on both products, what connectivity you have at the local site you want to protect with ESA, and the scale / complexity of your network.
If you’re considering integrating a TelcoBridges media gateway into your Metaswitch-based voice network, please get in touch with us to discuss your situation. As a TelcoBridges Alliance Partner we can help you purchase the right product for your network, and if needed, we can offer technical consulting services to help with the design and implementation of your updated network.
