What steps will reproduce the problem?
1. You need to be on a network with multiple, alternating NAT public IPs
2. Register to your SIP provider
3. Wait a while until your public IP changes (not that the internal, Wi-Fi IP
of the phone does *not* change)
4. Try to get an incoming call; SIP provider will try to reach the old IP which
you previously registered with.
What is the expected output? What do you see instead?
I would expect the client to make use of STUN to detect public IP changes and
re-register when that happens. RFC5626 proposes a method to use STUN over the
same flow as the SIP registration, although it appears most servers don't
support that method. (I use VoIP.ms and I don't see a Path header in the
registration response, which probably means this isn't supported).
I would guess similar results could be achieved by using a third-party STUN
server and just send regular queries (every few seconds?) to detect public IP
changes, after which we can replace our registration with a new one.
Original issue reported on code.google.com by plalondeovernet on 31 Jan 2015 at 6:38
Original issue reported on code.google.com by
plalondeovernet
on 31 Jan 2015 at 6:38