From H.248 to Analog PSTN Lines - Bridging Operators' Landline Networks for Independent Operation
Background
This is my first blog post of 2023. I feel embarrassed that I haven’t produced many meaningful or valuable articles in the past two years. However, the posts I recorded in my blog were born from urgent problems or ideas that I resolved.
In fact, I solved this problem back in mid-last year, but I never found the time to document my exploration process—so here it is now.
At the beginning of last year, I had just completed my article “Replacing My HN8145V Optical Modem with Huawei MA5671A.” At that time, I had just switched to a modular optical access device, eliminating the cumbersome optical modem, but this came with a concern—my home landline might not function properly.
Yes, it’s 2022, and my family still has a landline, a relic from the last century. It has existed since the house was built and served as the only means to contact my parents every morning and evening before I had a mobile phone.
Now, while I rarely use it to make calls, the landline is crucial for receiving emergency calls—if someone at home encounters a crisis late at night, calling our phones set to Do Not Disturb/Silent mode would be futile. This is one reason we keep the landline. Another reason is that our broadband has a long history, with the dial-up account linked to this landline number.
Media Gateway Control Protocol H.248 (MeGaCo)
After switching to a modular optical access device, what should I do about the landline? The carrier’s optical modem must support this protocol, so it works without issues.
Another troublesome thing—IPTV—is much easier to set up. Many experts online have shared how to configure IPTV after bridging VLANs. However, my home VoIP landline uses a strange protocol implementation: H.248. Unlike the more common SIP protocol, there is no open-source software support available for H.248, while SIP can easily connect using various software. Thus, no one has explored this issue. For example, Shanghai Telecom’s commercial landline uses the public SIP protocol, while Shanghai Unicom’s uses H.248, as do Shandong Unicom and Jiangxi Telecom. There’s no widespread use of MGCP (RFC3435) in China, likely due to a lack of concentrated procurement of softswitch devices supporting this protocol stack.
MeGaCo => Media Gateway Controller => H.248 = RFC3015 or RFC3525. According to Wikipedia, MeGaCo defines a signaling exchange mechanism that allows media gateway controllers to control gateways for voice and fax transmission between PSTN and IP networks or IP-to-IP networks. The protocol was defined as RFC 3525 through cooperation between IETF and ITU, with the name given by IETF. The ITU refers to it as H.248. Although it’s unnecessary to mention ITU’s Jaguar standard, it is indeed used in some domestic VoIP devices.
H.248’s Historical Evolution
So, is there a way to persuade the carrier to make modifications? Given how mature SIP is, there must be a way to migrate.
Unfortunately, there isn’t. It’s well-known that SIP users connect to SBC, while H.248 users connect to AGCF. The telecom in my area uses H.248 protocol.
The Access Gateway Control Function (AGCF) allows legacy non-SIP networks to communicate with an IMS network via a Media Gateway or Softswitch. The AGCF acts as a SIP agent within an IMS network when working with a Media Gateway, a Call Session Controller, and Application Server, converting H.248 signals from an Access-MGW into appropriate SIP messages. This allows the network architecture to be IMS-compliant.
H.248, a protocol that gives headaches even to Latte enthusiasts
Since I can’t get the carrier to modify the configuration, I had to tackle it myself.
Finding a Device
My goal was clear: since I couldn’t find software implementations, I would look for hardware solutions. The device I needed is called IAD (Integrated Access Device). Initially, I browsed around on second-hand platforms and bought a rather old device that turned out to be unusable.
Little Yellow Fish.jpg
In mid-February of last year, just as I left home for school, I happened to notice a device from Ruijie: the Xingrui SVG6004. Without much thought, I purchased it.
Still Little Yellow Fish
This device surprisingly allowed me to modify the protocol type! I felt I had found the solution.
Backend settings interface of Xingrui SVG6000 series devices
At first, I struggled to understand the configurations, as they were quite obscure.
MG device configuration
Eventually, I figured out what these settings meant:
Preferred MGC Address/Backup MGC Address: The address of the MGC media gateway server—simply put, the voice server that MG connects to.
Preferred MGC Port/Backup MGC Port: The port of the MGC media gateway server. Port 2944 is text-based, while 2945 is binary (ASN.1).
MG Protocol ID/MG Domain Name: Identifies the MG device, similar to a hostname but not exactly; here, I entered the domain name assigned by the carrier.
MG Protocol Port/MG Port Number: Device port, similar to above; again, 2944 is text-based, and 2945 is binary (ASN.1).
RTP Endpoint ID/RTP Identifier: The RTP TID prefix combined with a numeric suffix forms the RTP endpoint ID, which is the inner endpoint ID of the H.248 message Add. Generally, it is RTP/XXXXX, and I used the carrier’s configuration of A100. The carrier’s optical modem divides prefix and suffix, with the RTP endpoint ID prefix being A100. The suffix must be completed; I used 6 zeros, while the carrier’s modem specifies an RTP endpoint identifier initial value of 0 and the number of digits to add as 6. Thus, it combines to A100/000000.
MG device subordinate terminal configuration
The terminal ID, the identifier for this FXO, is added to the outer layer of the H.248 message Add. For example, AG58900 is a terminal ID. Here, I also used the carrier configuration: A0.
MG device network configuration
Finally, I set the device to DHCP and connected the bridged VLAN network to the device, and it was ready for use.
Lift the handset, dial 10000, and you’ll hear the familiar voice!
