Back in 2020, before I came to know about the JF firmware, the first thing I did was to sniff the network packets sent from the JioCall app to the router while registering and calling through the app for the first time. But when I turned on the sniffing app, JioCall was not detecting the router because the sniffing app was using VPN method and thus the local network was not accessible through it.
So I turned on my laptop, installed JioCall on an Android Emulator, turned on Wireshark, and then opened JioCall. Everything was working perfectly. But the requests which the app made to the router was encrypted by self-signed certificate, so I couldn't actually sniff the packets. But I got something useful : **The ports which the SIP Server listens on, which are 8080, 8443 and 7443**.
Next thing I did was to decompile the JioCall apk via [jadx](https://github.com/skylot/jadx) and I found a lot of interesting things. Looking into the code of JioCall app (which was obfuscated of course), I found that it was using [Retrofit](https://square.github.io/retrofit/) for the network requests which means that there must be an interface somewhere which contains all the HTTP links with their request methods and if POST request, then their POST data structures. So, I went through the code and found some interesting links. One of them was : `/request_account`. I opened up my browser and opened `http://192.168.29.1:8080/request_account` and voila, this is what I got as response (actually this is the current response, previously the response was a bit different but the contents were almost the same) :-
Indeed, the `msisdn` key contained my JF landline number. I also tried the other URL paths but none of them worked, perhaps those need an API key to work. Atleast I know that I am heading to the right path.
After an year, in October 2021, I found [this repository](https://github.com/fawazahmed0/Jio-fiber-Modem) where I found JF Firmware. I downloaded the firmware quickly and started to explore its contents. I read the lua codes and came to know how the WEB-UI works and stuff. I discovered the way to [get dbglogs from JF](https://github.com/itsyourap/JF-Home-Gateway/blob/master/Instructions/Get-dbglogs-JF-ONT-Home-Gateway.md) and within November, I discovered the way to decrypt the router settings backup file using the Router keys.
Then I started looking for the VoIP server code (which is called the Juice Server) in the firmware which led me to `/pfrm2.0/etc/voipInit` which further led me to `pfrm2.0/bin/hgw-voice-app` which was, of course, a binary, that cannot be decompiled easily. So, I started dumping the strings present in the binary and I found a reference to `libims.so` library which was present in `/pfrm2.0/lib/`. Dumping the strings in the `libims.so` gave me exactly what I needed.
1. First, after opening JJoin for the first time, it will search for the host `jiofiber.local.html` with a DNS Query. If found, JJoin will assume that you are on a JF network. *(This is why using custom DNS providers stops JJoin from working, to tackle this, you can define `jiofiber.local.html` with your router's static IP in your `hosts` file)*
The `mac_address` parameter contains a random mac address (it is not a real mac address of any device in your network, it is a random mac generated like as a session key which persists with the current JJoin installation. It might be the real mac address in case of Jio STB).
The `nwk_intf` parameter represents the Network Interface used for the request, it can either be `wifi` (almost everytime) or `eth` (in case of requests from Jio STB).
The `op_type` parameter perhaps represents "option type". It can be `add` or `remove` (maybe more which idk).
The `mac_address` and `op_type` are essential parameters in this request.
So, whenever this request is sent to the Juice Server, the Server first checks the `op_type` parameter. If it is `add` then the server has to add the device (from where the request was initiated) to SIP whitelist (devices in this list are the only devices which are permitted to send or receive SIP requests/responses). The server differentiates between clients (I mean different JJoin apps on different devices) using the `mac_address` parameter which is unique for each JJoin app installation. The Juice server checks if the `mac_address` is already present in the whitelisted devices list. If it is present it replies with a XML data which contains all the SIP configs which is explained later. For now let us assume that our device was not previously whitelisted. An OTP is sent to your JF linked mobile number. The Juice server then responds with a **`200 OK`** status code but without any response data. But the server provides with some important response headers which are
The Cookie called `WITRCSeConfigCookie` will be needed when we want to verify the OTP with the Juice Server next while the `x-amn` header signifies the JF linked mobile number to which the OTP was sent.
3. JJoin tells you that an OTP was sent to your registered mobile number `+91********XX` which is derived from the `x-amn` header from the previous step. You type the OTP and submit it. Now the request is sent to the Juice Server looks like this (assume the OTP is 696969):
4. As soon as the OTP is verified, the Juice Server whitelists the `mac_address` associated with the request with the cookie and replies with an XML body. This XML is the SIP configuration required to make calls using JJoin. Now, as the `mac_address` is verified, you can use it to get the XML configuration anytime using step 2. The response in step 2 will now be the XML data without any further authentication.
3. Under `characteristic` of type `application.other`:
`uuid_value` represents the value of `mac_address` parameter, if your `mac_address` parameter was `aa:bb:cc:dd:ee:ff` then the last section of the uuid will be `AABBCCDDEEFF`. The first sections are same for every device under every router as far as I know.
This is the general format of every request sent to the SIP server. This request is sent via the proxy, i.e., Juice Server (look for the parameters in the XML file mentioned previously).
Things that makes Jio's SIP protocol different from others are:
1.**The Contact Header** - The contact header must have the `+sip.instance` parameter with proper value format otherwise you will get *401 Unauthorized* response from the server. The proper format of this parameter is `+sip.instance="<00000000-0000-1000-8000-AABBCCDDEEFF>"` where you have to put the value of uuid got from the XML previously.
Let me be clear, other SIP Server/Clients have their `+sip.instance` parameter format as `+sip.instance="<urn:uuid:ABCABCAB-AABB-CCDD-EEFF-AABBCCAABBCCC>"` - Note the string `urn:uuid:` is present which Jio's Juice Server does not support. (This is why using a third party SIP client like MicroSIP to call through JF isn't gonna work).
2.**The P-Access-Network-Info Header** - Use it on every request.
So, the first time you send the REGISTER request to the SIP server via the Juice Server as proxy, you will get a *401 Unauthorized* response because you haven't provided your credentials yet. The server response is important. Let me show you how it looks like :
The headers `WWW-Authenticate` contains the Digest nonce which will be used to verify your identity using your credentials. Refer to [Wikipedia](https://en.wikipedia.org/wiki/Digest_access_authentication) for more information about digest authentication.
According to [Wikipedia](https://en.wikipedia.org/wiki/Digest_access_authentication), we need to prepare a response based on the nonce and our credentials.
The format is:
```none
HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)
```
where
`username` refers to your SIP username found in the XML, here, `91XXXXXXXXXX@wb.wln.ims.jio.com`
`realm` refers to your SIP realm, here, `wb.wln.ims.jio.com`
`password` refers to your SIP password, here `<randompassword>`
`method` refers to the request method, here, `REGISTER`
`digestURI` refers to (idk what) but it is `"sip:" + realm`, here, `sip:wb.wln.ims.jio.com`
`MD5(x)` refers to the MD5 hash of `x`.
After preparing our response, we need to send another REGISTER request with a fulfilled `Authorization` header like this:
The Juice server responds with *100 Trying* which means the call is being connected.
When the recipient picks up the call, we get a *183 Session Progress* from the Juice server along with some SDP data. It does place a call to the number but of course with no audio.
Also you need to send ACK and PRACK requests frequently to keep the call alive. You can read any SIP documentations available on the internet for more info.
Right now, I am stuck at using the RTP. In the INVITE request you can see the request data which is SDP. The `m` parameter gives us the media info which is `RTP/AVP` on port `52000`. Yes you can use any program to create RTP server on that port but the the actual RTP server will be created on the JF side for further communication.The only problem is the audio codec. The audio codec used is `AMR/AMR-WB` which from Android. I don't have the time to look at the whole source code of the audio codec in android repository. You can help me out with this.
I have tried connecting to the RTP server in the Juice Server and I got the audio data but it was AMR-WB encoded. I tried to use some third party programs to get audible audio from the data and one seems to work : [Check this Python Program](https://github.com/Spinlogic/AMR-WB_extractor). This gives me what I need but right now idk how to play the audio in realtime and how to reverse this process so that I can send audio data for the call.
If you do find a way to play the AMR/AMR-WB encoded audio in realtime and record AMR/AMR-WB audio in realtime using the OpenCore AMR library (originally built for Android) in Desktop and use the RTP server to establish communication between the caller and the callee, feel free to open a discussion in this repository.
