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?
 
@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
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

Ah I see. So the low TTL could be part of the VoWiFI spec? Also, I wasn't aware of this other domain being used for VoWiFi, and that could explain the intermittent issues I've been seeing. Thanks for that. 🙇‍♂️

I went through my DNS query logs and sure enough, I see repeated queries being made to epdg.epc.mnc862.mcc405.pub.3gppnetwork.org as well. This is in addition to vowifi.jio.com

And as expected Google DNS returns different results for that too.

Code:
root@bumblebee:~# dig epdg.epc.mnc862.mcc405.pub.3gppnetwork.org @8.8.8.8 +short
49.44.59.36
49.44.59.38
root@bumblebee:~# dig epdg.epc.mnc862.mcc405.pub.3gppnetwork.org @8.8.8.8 +short
49.45.63.1
49.45.63.2
root@bumblebee:~# dig epdg.epc.mnc862.mcc405.pub.3gppnetwork.org @8.8.8.8 +short
49.45.63.1
49.45.63.2
root@bumblebee:~# dig epdg.epc.mnc862.mcc405.pub.3gppnetwork.org @8.8.8.8 +short
49.45.63.1
49.45.63.2
root@bumblebee:~# dig epdg.epc.mnc862.mcc405.pub.3gppnetwork.org @8.8.8.8 +short
49.44.59.38
49.44.59.36
root@bumblebee:~#

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 ?

This is exactly what I tried, I created a record vowifi.jio.varkey.io (this points to the two correct IP addresses) and added an override for vowifi.jio.com to this name. (This was only because I use NextDNS (for now) and they don't allow multiple override records for the same name)

However doing this didn't give stability, but based on the new info from you about the 3gppnetwork.org domain, I will now conditionally forward 3gppnetwork.org to my ISP resolver or CloudFlare and see if I get stable VoWiFi.

Great info @swapneelp! 🙇‍♂️
 
Upvote 0
Mods, can you see why I don't see the Reply option for the latest post in the thread ?

Ah I see. So the low TTL could be part of the VoWiFI spec? Also, I wasn't aware of this other domain being used for VoWiFi, and that could explain the intermittent issues I've been seeing. Thanks for that. 🙇‍♂️

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”'.

This is exactly what I tried, I created a record vowifi.jio.varkey.io (this points to the two correct IP addresses) and added an override for vowifi.jio.com to this name. (This was only because I use NextDNS (for now) and they don't allow multiple override records for the same name)
A suggestion and a comment for you,
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.

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

Screenshot 2020-05-30 at 9.41.24 PM.webp


Can you turn that off & give it a whirl ? 😀

Great info @swapneelp! 🙇‍♂️
The path to going down the rabbit hole has many benefits, making friends along the way is certainly one of it 🙂
 
Upvote 0
reply on last post in thread is hidden because people use it on every single post which means every post is quoted in the next post and it goes on and on and on and on and on and on. it adds garbage to the thread view because every post is repeated twice. and user would have to check if the quoted post is something from previous pages or just the previous post. it's just annoying. i see this behaviour on other forums all the time and i just hate it.
 
Last edited:
Upvote 0
I get the logic. Thanks ! Especially, if people are quoting the entire response and merely adding their response to the bottom. It doesn’t add any value. But having said that, responding inline to a point by point comment/response brings clarity for a reader. For a starter, see the above conversation between @varkey and myself.

While, you might also be forced by the options the forum software provides and neither am I asking you to enable it, the least I could do is make you see the other side/point of view.
 


Upvote 0
sadly, xenforo also disables select text to quote if the quote button is disabled. otherwise that feature would have worked in your case. small inconvenience to keep the conversation on the entire board cleaner. if a similar situation does arise in future, just post a dummy post and report it for deletion. i would rather have that then have quotes in all posts on the forum tbh.
 
Upvote 0
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
I used bind BIND9.16.10.x64 for windows 10 and it worked . I am getting sames ips from Uk address and same in india .. I was trying to make vowifi working. I connected to my remote home wifi but it doesnt work somehow.Any idea how to trace it on the phone regarding which server jio is trying to access?
 
Upvote 0
@Gary hill yes, indeed you need an active plan. VoWiFi is just to route your calls via broadband backhaul instead of Jio Mobile network in case of low/inconsistent signal. Hence, you need an active plan on your Jio sim to make and receive calls.
 
Upvote 0

Top