Android phones nowadays come equipped with powerful processors like Quadcore and Octacore, making them capable SIP clients for VoIP. By connecting to an Asterisk server through 3G or WiFi, these phones can act as VoIP gateways for outgoing calls, with the option of using a DID for inbound calls at a minimal cost.

Imagine installing AsteriskAsterisk or FreeSWITCH directly on an Android device, turning it into a portable call center or PBX. Other phones can then join as SIP clients, eliminating the need for a middle application gateway. The Android device itself becomes the VoIP gateway, leveraging its processing power.

However, porting Asterisk to an Android device will only allow it to serve as VoIP and/or SMS gateway. What if we want to use an android device as a GSM gateway? For example, using your cellular network to send automated calls and messages to your phone contacts. The current Android phone is unable to do that. They are unable to provide call and media control that is required to make them work as a gateway.

Hurdle 1:

First thing, if we look at a high-level of abstraction, in the Android software, it doesn't provide any high-level APIs to call and media control. One example of media control is playing recording files on a voice call. This is mentioned in the Android official documentation. As quoted in the documentation that "You can playback the audio data only to the standard output device. Currently, that is the mobile device speaker or a Bluetooth headset. You cannot play sound files in the conversation audio during a call".

Even if we are able to remove this hurdle, we may still not be able to use Android as GSM Gateway. Because there is a second hurdle.

Hurdle 2:

The second hurdle is in the design of the Android RIL Radio Interface Layer. RIL is an abstraction layer between Android telephony services android.telephony package and radio hardware. It is clearly visible from the diagram below that RIL passes on complete control of the call to Radio Daemon (rild) of the Linux library which then further passes the control to the vendor RIL. So we are unable to control our call at the android application. We need access to Radio Daemon and vendor RIL source code to manipulate our call.

Hurdle 3:

The vendor RIL, a crucial component, is not open source. Each vendor has its proprietary RIL library that communicates with Radio Daemon, making it difficult to control incoming calls and interact with radio hardware.

Even with the potential removal of Hurdles 1 and 2 through open-source community efforts, Hurdle 3 remains a significant roadblock. Custom ROMs, dependent on proprietary RIL firmware, cannot circumvent this issue. The lack of vendor RIL source code availability from hardware vendors makes using Android as a GSM Gateway in its current form impossible.

Conclusion:

It's not possible to use Android as a GSM Gateway in its current form. Even after flashing custom ROM because they also depend on proprietary RIL firmware. Hurdles 1 and 2 can be removed because the source code is available for the open-source community to make it possible. However, hurdle 3 is dependent on the hardware vendors. Hardware vendors do not usually make their device drivers' code available.

While some projects aim to replace proprietary firmware, such as Replicant, their device support is currently limited. Unless hardware vendors make their device drivers' code available, the prospect of using Android as a GSM Gateway remains constrained.

ICT Innovations, an open-source telephony integration consultant. Contact us for those interested in deploying and developing open-source telephony projects to contact them for assistance.