Jio WiFi calling on Airtel Broadband

Messages
126
Location
Bangkok, Thailand
ISP
TrueOnline, TrueMoveH, Jio
I used to have Spectra and Jio WiFi calling on the iPhone used to be seamless. Switched to VoWifi as soon as it connected to the Wireless network. With Airtel, this is spotty. Sometimes it connects, sometimes it doesn't. Rebooting the phone or the router doesn't seem to help.

However, if I switch to Cloudfare DNS from Airtel's DNS on my router, VoWifi is perfect again. Has anyone else observed this? Is Airtel deliberately blocking Jio VoWifi?
 
I did some digging, so it appears the DNS name vowifi.jio.com resolves differently based on the source IP address of the resolver (or maybe they do make use of the EDNS-Client-Subnet mechanism also, I did not test that).

Screenshot 2020-05-21 at 11.05.44 AM.webp


So from India it resolves to 49.44.59.38 & 49.44.59.36, but from anywhere else it resolves to 49.45.63.2 & 49.45.63.1. The above image is from OpenDNS cache check (OpenDNS: Cloud-Delivered Security Enforcement and Intelligence) where you can check how the name resolves from various geographies.

So my guess is, they have this mechanism probably to support VoWiFi during international roaming. When outside India, you get redirected to a different endpoint, and the VoWiFi is enabled only when the required plan or addon is active.

The setup is a bit weird, if I ask ns1.jio.com which is one of the nameservers for jio.com, it says go ask ns1/2.vowifi.jio.com. But they are missing the DNS records for ns1.vowifi.jio.com and ns2.vowifi.jio.com, but they do send the glue records, so it does work.

Code:
(⎈ |docker-desktop:default)➜  ~ dig vowifi.jio.com @ns1.jio.com.

; <<>> DiG 9.10.6 <<>> vowifi.jio.com @ns1.jio.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3137
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;vowifi.jio.com.            IN    A

;; AUTHORITY SECTION:
vowifi.jio.com.        3600    IN    NS    ns1.vowifi.jio.com.
vowifi.jio.com.        3600    IN    NS    ns2.vowifi.jio.com.

;; ADDITIONAL SECTION:
ns1.vowifi.jio.com.    3600    IN    A    49.44.59.6
ns2.vowifi.jio.com.    3600    IN    A    49.44.59.7

;; Query time: 60 msec
;; SERVER: 2405:200:1602:720::4#53(2405:200:1602:720::4)
;; WHEN: Thu May 21 11:15:07 IST 2020
;; MSG SIZE  rcvd: 111

But the issue I am facing at times is that vowifi.jio.com resolves to the international IP addresses and VoWiFi doesn't work. I do use a caching resolver, so I am trying to pinpoint the actual problem. However, I can definitely say that this isn't set up properly from Jio's perspective.
 


Upvote 1
@swapneelp I've been observing something similar over the last few days since my post. VoWiFi works intermittently for me.

For example, this is from Google DNS, the same query run with maybe a second or two in between. It is also interesting that the TTL is super low, like 5 seconds, which would in a way explain the varying results. Depending on the Google recursive resolver node which actually makes the query to the Jio nameservers, it might be returning different results that gets cached.

Code:
root@bumblebee:~# dig vowifi.jio.com @8.8.8.8 +short
49.45.63.1
49.45.63.2
root@bumblebee:~# dig vowifi.jio.com @8.8.8.8 +short
49.44.59.36
49.44.59.38
root@bumblebee:~# dig vowifi.jio.com @8.8.8.8 +short
49.45.63.2
49.45.63.1
root@bumblebee:~# dig vowifi.jio.com @8.8.8.8 +short
49.44.59.38
49.44.59.36
root@bumblebee:~# dig vowifi.jio.com @8.8.8.8 +short
49.44.59.36
49.44.59.38
root@bumblebee:~# dig vowifi.jio.com @8.8.8.8 +short
49.45.63.1
49.45.63.2
root@bumblebee:~#

1.1.1.1 seem to consistently return the same result. Same behavior with my ISP resolvers.

Code:
root@bumblebee:~# dig vowifi.jio.com @1.1.1.1 +short
49.44.59.38
49.44.59.36
root@bumblebee:~#
root@bumblebee:~# dig vowifi.jio.com @61.1.1.1 +short
49.44.59.38
49.44.59.36
root@bumblebee:~#

Clearly Jio has messed it up for reasons unknown to me. At this point, I really don't know what they are trying to achieve.
 
Upvote 1
Ok. I am not sure why I don't see an option for 'Reply' so that I can quote your comment. So, instead, I am going to copy-paste and respond below it. Pardon the hack !

@swapneelp I've been observing something similar over the last few days since my post. VoWiFi works intermittently for me.

For example, this is from Google DNS, the same query run with maybe a second or two in between. It is also interesting that the TTL is super low, like 5 seconds, which would in a way explain the varying results. Depending on the Google recursive resolver node which actually makes the query to the Jio nameservers, it might be returning different results that gets cached.

The low TTL part is expected. I have seen similar low TTLs for destination domains of other carriers for VoWiFi. For example in the case of Airtel, in my case (depending on the region) the domain being queried is epdg.epc.mnc045.mcc404.pub.3gppnetwork.org

; <<>> DiG 9.10.6 <<>> epdg.epc.mnc045.mcc404.pub.3gppnetwork.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30595
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;epdg.epc.mnc045.mcc404.pub.3gppnetwork.org. IN A

;; ANSWER SECTION:
epdg.epc.mnc045.mcc404.pub.3gppnetwork.org. 4 IN A 106.200.64.1

;; Query time: 53 msec
;; SERVER: 192.168.0.250#53(192.168.0.250)
;; WHEN: Sat May 30 21:02:00 IST 2020
;; MSG SIZE rcvd: 87

Btw, for Jio, they also have the standardised domain epdg.epc.mnc861.mcc405.pub.3gppnetwork.org (Again, this is depending on region ). Ideally, the domain is standardised & is made up of Mobile Network Code(MNC) and Mobile Country Code(MCC). As expected, in my case the domain name resolves to 49.44.59.36 and 49.44.59.38.

; <<>> DiG 9.10.6 <<>> epdg.epc.mnc861.mcc405.pub.3gppnetwork.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54903
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;epdg.epc.mnc861.mcc405.pub.3gppnetwork.org. IN A

;; ANSWER SECTION:
epdg.epc.mnc861.mcc405.pub.3gppnetwork.org. 5 IN A 49.44.59.36
epdg.epc.mnc861.mcc405.pub.3gppnetwork.org. 5 IN A 49.44.59.38

;; Query time: 56 msec
;; SERVER: 192.168.0.250#53(192.168.0.250)
;; WHEN: Sat May 30 21:03:59 IST 2020
;; MSG SIZE rcvd: 103

Quick question for you, if you add static DNS A records in your resolver for vowifi.jio.com to 49.44.59.36 and 49.44.59.38, does VoWiFi work in a stable fashion ?

I am going to run a few more tests in this line of thinking and see how it goes.
 
Upvote 1
Yes. If you would be interested, here is a document with the details of how DNS infrastructure should be implemented. Check the section '6.5 Delegation of sub-domains of “pub.3gppnetwork.org”'.

Thanks for the doc. So it looks like each operator based on the different MCC/MNC codes they are assigned, would get the different 3rd or higher level subdomains of 3gppnetwork.org delegated to the operator's nameservers.

It is interesting how Jio has set it up though. They have got the 3rd level subdomain delegated to their main nameservers, then the VoWiFi zone ie the epdg.epc.mncxxx.mccxxx.pub.3gppnetwork.org is again delegated to another set of nameservers.

Code:
mnc862.mcc405.pub.3gppnetwork.org. 259200 IN NS    ns2.jio.com.
mnc862.mcc405.pub.3gppnetwork.org. 259200 IN NS    ns3.jio.com.
mnc862.mcc405.pub.3gppnetwork.org. 259200 IN NS    ns1.jio.com.
mnc862.mcc405.pub.3gppnetwork.org. 259200 IN NS    ns4.jio.com.

Code:
;; AUTHORITY SECTION:
epdg.epc.mnc862.mcc405.pub.3gppnetwork.org. 3600 IN NS ns1.epdg.epc.mnc862.mcc405.pub.3gppnetwork.org.
epdg.epc.mnc862.mcc405.pub.3gppnetwork.org. 3600 IN NS ns2.epdg.epc.mnc862.mcc405.pub.3gppnetwork.org.

;; ADDITIONAL SECTION:
ns1.epdg.epc.mnc862.mcc405.pub.3gppnetwork.org.    3600 IN    A 49.44.59.6
ns2.epdg.epc.mnc862.mcc405.pub.3gppnetwork.org.    3600 IN    A 49.44.59.7

They have not set up the DNS records for the nameservers themselves for whatever reason. It works due to the glue records sent by the parent zone. 🤷‍♂️ This is the exact same behavior of the vowifi.jio.com zone as well. Weird.

So if you try to resolve ns1.epdg.epc.mnc862.mcc405.pub.3gppnetwork.org you get a SERVFAIL 😛 🤷‍♂️

2. Upon logging into NextDNS, I am able to see an option 'Anonymized EDNS Client Subnet' which is turned on by default.

So I tried this and didn't make any difference. I wonder if the Jio nameservers for this zone even make use of EDNS Client Subnet data? Is there a way to send EDNS Client Subnet data using dig? 🤔 Just for testing.

Also, on NextDNS I usually get connected to their node in Mumbai which is hosted in Google Cloud Platform. The IP address of their recursive resolver in Mumbai appears to be 34.93.164.22 (Tried a DNS leak test and this was the IP address whenever I am connected to the Mumbai node). I then launched a VM in Mumbai GCP and sure enough, I always get the bad records which don't work ie 49.45.63.2 and 49.45.63.1.

Code:
varkey@varkey-test:~$ dig epdg.epc.mnc862.mcc405.pub.3gppnetwork.org @49.44.59.6 +short
49.45.63.1
49.45.63.2
varkey@varkey-test:~$ dig vowifi.jio.com @49.44.59.6 +short
49.45.63.1
49.45.63.2
varkey@varkey-test:~$
`
Queried the nameservers directly and I get the bad records consistently. This probably explains why VoWiFi doesn't work when using NextDNS resolvers.

1. I will test this myself with NextDNS w.r.t rewrite but I have a hunch, there a problem there. The TTL would vary. Instead, I would suggest you to rewrite natively in your DNS resolver. For that though, you will have to temporarily switch to running the resolver not as a forwarder but instead as a recursive resolver speaking to root. Many ways to do this, but this would be the ideal test configuration which will eliminate all complexities.

Right now I am using the nextdns client as my resolver - nextdns/nextdns. It supports configuring conditional forwarders, so I have set it to the below resolvers. Both these resolvers consistently gave me the right results.

Code:
forwarder 3gppnetwork.org.=61.1.1.1,1.1.1.1
forwarder jio.com.=61.1.1.1,1.1.1.1

So previously (when I made the initial post about this IP address drama Jio is playing 😛) I was using unbound as the recursive resolver and even then VoWiFi was unstable. At the time I wasn't aware of the 3gppnetwork.org DNS names that would get used so I didn't check how those resolve, but vowifi.jio.com was returning the bad records intermittently (basically it works for few hours and then stops working). I suspect it's when my IP address changes, I'm on BSNL and I get allocated a 59.92.x.x IP address or something in the 117.x.x.x range. It is possible like you noticed when queried from some networks even in India, Jio nameservers return the bad IP addresses.

The path to going down the rabbit hole has many benefits, making friends along the way is certainly one of it 🙂

It sure is! 🙂 🎉

Anyway, I totally missed mentioning the main thing that VoWiFi is now stable 🚀 ie after conditionally forwarding jio.com and 3gppnetwork.org to a set of resolvers that consistently return the right records.

It definitely appears like Jio has this misconfigured, I'm not even sure they have noticed? They might have whitelisted certain IP address ranges which would get the good or the India records and everything else gets the international records which wouldn't work (at least for now)
 
Upvote 1
Working here … airtel fiber …

@Chip yes local issue
 
Upvote 1
Jio VoWiFi has Issues with dns servers outside India which should not be the case with airtel dns so hard to say.
 
Upvote 0
Weird. I can definitely reproduce this problem on multiple Apple devices
1. Jio SIM, Airtel Xstream with Airtel (Default) DNS - Flight mode ON, OFF <--Takes 1-2 minutes for VoWIFI to turn ON
2. Airtel SIM, Airtel Xstream with Airtel (Default) DNS - Flight mode ON, OFF <--Immediately switches to VoWIFI
3. Jio SIM, Airtel Xstream with Cloudfare DNS - Flight mode ON, OFF <--Immediately switches to VoWIFI

Not too bothered by it, will stick to Cloudfare DNS
 
Upvote 0
Yeah as @Sushubh mentioned, Jio VoWiFi appears to be extremely picky with respect to the DNS resolvers used. My initial observation was that they are looking for resolvers in India. However, over the last 1-2 days, I was evaluating using unbound as a local recursive resolver and noticed the same issue. In this case, the IP address seen by Jio's nameservers would be my BSNL IP address which is definitely in India, but it still failed.

Then I switched back to the previous config of using Google DNS as the DNS forwarder and VoWiFi started working again.

🤷‍♂️
 
Upvote 0
I had similar issue. Was unable to use jiotv app, jio cinema and jio wifi calling on my iPhone. I tried resetting router as well but lost Voip setting. Nothing worked for me. Then i changed dns to clouldflare. I think issue is with DNS. If you change to adguard dns, jio services gets blocked.
 
Upvote 0
So in my case, all my devices are pointed to a local caching resolver, and I could if required bind that record to a specific IP address. But what if they change it? I was looking for a proper solution where the name reliably resolves to the right IP addresses. 😅😅

Yep, you could add an override in NextDNS too which is a cool feature. I had to stop using NextDNS as it didn't play well with Stubby (which I am using as a stub resolver for DoT). Maybe things have improved now, I really did like NextDNS for the reporting data they provided 😅😅
 
Upvote 0

Top