A funny thing happened after my T-Mobile iPhone recently upgraded to iOS 10.3.1 … my SIP client stopped working!
It seems that the OS update came along with new carrier settings that assigned my device an IPv6 address. In my case, the carrier setting version is now T Mobile 28.3.
After analyzing network captures from the switch side, we found that SIP UDP messages are no longer routed to the SkySwitch SIP proxy which has an IPv4 address. But noticing that API calls made over HTTP from the same app were reaching the IPv4 web service, we concluded that TCP packets were being translated and routed correctly. So we switched the SIP signaling to TCP and the IPv6 device was able to register with the IPv4 server. Unfortunately, this allowed only basic two-way communication between the SIP client and the proxy. SIP calling was still broken because the audio IP addresses and ports still referenced IPv6. Specifically, the CONTACT header and RTP IP addresses in the SDP contain the IPv6 address.
A little research uncovered that T-Mobile has been rolling IPv6 to Android devices for a few years now . According to this T-Mobile slide deck from 2014, they use an IPv6 transition mechanism called 464XLAT to allow communication between IPv6 devices and servers on the Internet that do not support IPv6. But making the conversion work seamlessly for applications that reference IP address information in the payload (such as SIP) requires a client side translator called CLAT (this document from Juniper explains it). To make a long story short, Android version 4.3 embedded a CLAT client into the operating system in 2013, but Apple never did. As a result, T-Mobile has continued to serve IPv4 addresses to iPhone users … until last week.
I suppose we may never know why Apple has not employed CLAT in the operating system (thereby forcing SIP application developers to embed this functionality in the app), or why T-Mobile decided to force IPv6 on iPhone owners despite this limitation. But the bottom line is that more than a few SIP applications have stopped working as a result (eg. here). I hope that this blog will save other SIP users some time in figuring out why.
In the meantime, we are working with our vendors to support IPv6 in this use case.