SPA3102 Registration State: Failed after External IP Changed

Answered Question
Mar 3rd, 2010
User Badges:

I found VoIP A/C will failed registration with my VSP whenever my Firewall external IP changed. Reboot the SPA3102 cannot help, I have to remove the VSP domain from the "Proxy and Registration -> Proxy"  field "Submit All Changes" and re-input the field then "Submit All Changes" in order to get the "Registered" success status.


When external Firewall IP changed SPA will log the following:


RSE_DEBUG: getting alternate from domain:iptel.org
[1]->213.192.59.75:5060(489)


RSE:GetServerAddrErr(iptel.org,0)=-101

[1]Reg Addr Change(0) 0:5060->d5c03b4b:5060
[1]->213.192.59.75:5060(380)


RSE_DEBUG: getting alternate from domain:iptel.org
AUD:Stop PSTN Tone
[1]RegFail. Retry in 30
[1]Reg Addr Change(0) 0:5060->d5c03b4b:5060
[1]->213.192.59.75:5060(383)


this will go on and on for a whole day without any success. My SPA3102's WAN port only connect to internal LAN with a fixed IP address. After removed & update the proxy domain field then  "Submit All Changes":


system request reboot
fu:0:3ba2, 01c4 01c9 01ca 01cb 0001
fu:0:3bd5, 0038 0049 043c 0445 0001
fu:0:3c2b, 03e4 05b0 0001
System started: [email protected], reboot reason:W4
    subnet mask:    255.255.255.0
    gateway ip:    192.168.0.1
    dns servers(2):    202.11.124.21 202.11.124.22 
IDBG: st-0
YM:ERR:AuthServerNotConfig
[1]Reg Addr Change(0) 0:0->d5c03b4b:5060
[1]->213.192.59.75:5060(489)


[1]<<213.192.59.75:5060(678)
SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.168.0.100:5061;branch=z9hG4bK-3f79f3dd;rport=1809;received=203.69.17.10


[1]->213.192.59.75:5060(667)
REGISTER sip:iptel.org SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5061;branch=z9hG4bK-a4da471e


fhs:05:0:0005:upg:app:1:5.1.10(GW)
fhs:06:0:0006:upg:app:2:5.1.10(GW)
fu:0:3c52, 0003 0001
[1]<<213.192.59.75:5060(704)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.100:5061;branch=z9hG4bK-a4da471e;rport=1809;received=203.69.17.10


[1]RegOK. NextReg in 495 (1)
AUD:Stop PSTN Tone
[1]Reg Addr Change(0) 0:0->d5c03b4b:5060
[1]->213.192.59.75:5060(379)


As you can see 203.69.17.10 is the new changed external IP and start to show up after the field updates and finally get RegOK.

Correct Answer by Alberto Montilla about 7 years 3 months ago

Dear Sir;


It is the service provider the one who has to deal with the NAT issue, either providing a STUN server or SBC functionality. This has been the case for the last 10 years, it is a global implementation standard.


Having said that and looking at your config. I suggest you set NAT mapping to NO (as you dont have STUN enabled and you IP address is dynamic), probably this would do the trick as your VSP may be already doing some sort of SBC function.


Regards
Alberto

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
samsonluk Wed, 03/03/2010 - 16:40
User Badges:

Looks like I am not alone, this is an unresolved issue as you can see the details from this long forum discussion:


http://forums.whirlpool.net.au/forum-replies-archive.cfm/1293673.html


For my case, I already enabled port forwarding 5060 & 5061 in my Firewall to the SPA IP in order to facilitate Direct IP Dial, I also have NAT Keep alive and NAT Mapping enabled and I don't use STUN servers.


A reboot or power reset on the Firewall side won't have this problem, it was only the Firewall external IP changes will trigger this VoIP A/C registration failure.


A URL reboot or power on/off the SPA won't get problem fixed.  My observation is that trigger an update (by remove "submit" then re-enter "submit" the same info) to the SPA "Proxy and Registration -> Proxy" field seems generated a "special" kind of SPA restart / reboot (as seen from the syslog message) and this one will able to update the external changed IP to the VSP registration server, someone also mentioned in the above forum discussion that the input of DSN field in the SPA will also trigger the same effect. I believe the restart of SPA in these fields update is somehow different than a URL reboot or power on/off.


Can other users in this forum give it a try and see if you also having the same problem with your SPA?  Many thanks!

Alberto Montilla Tue, 03/09/2010 - 07:05
User Badges:
  • Cisco Employee,

Dear Sir;


Can you please send us your configuration? (.mht page) please delete any sensitive data such as password and user accounts.


Just to understand...you have a dynamic IP address. This may have to do with the fact that your VSP does not support STUN or have an SBC (to track public IP address changes). This is something the SPA cannot control over time. It has some intelligence to learn the external IP address from the incoming SIP packets, but that's all, if this changes, there is no way for the SIP entities (unless STUN, SBC or static IP address is available) to understand the change.


I would like to have a look at the config to see if alternatively this is a config issue.


Regards

Alberto

samsonluk Tue, 03/09/2010 - 08:24
User Badges:

Thanks Alberto.


Yes, I use dynamic IP here and I can't use STUN - it just doesn't work for my VSP so I have disabled it.


I would like to ask who should responsible to detect the IP change? SPA3102 or the VSP registration server?  I would expect the registration server should able to detect the IP change of re-REGISTER request from the same UA and update the "SIP VIA: received=" to the new changed IP accordingly, if this is the case SPA3102 should able to learn the change from it.


I don't know how to remove the sensitive data so I just capture the screens with related information, let me know if there are any important missing.

Attachment: 
Correct Answer
Alberto Montilla Thu, 03/11/2010 - 05:53
User Badges:
  • Cisco Employee,

Dear Sir;


It is the service provider the one who has to deal with the NAT issue, either providing a STUN server or SBC functionality. This has been the case for the last 10 years, it is a global implementation standard.


Having said that and looking at your config. I suggest you set NAT mapping to NO (as you dont have STUN enabled and you IP address is dynamic), probably this would do the trick as your VSP may be already doing some sort of SBC function.


Regards
Alberto

samsonluk Thu, 03/11/2010 - 07:43
User Badges:

Dear Alberto,


Thank you so much!  It works!!!


Can you explain to me a bit more on why NAT Keep Alive will affect the IP change detection and why NAT Mapping can be allowed?

samsonluk Thu, 03/11/2010 - 08:19
User Badges:

I am sorry to tell you that disble NAT Keep Alive create a fatal issue  -  call cannot reach SPA at approximate 200 secs. after the REGISTER process, no call receive at all by looking a the syslog, however, call can be reached again if dial in right after the next REGISTER.  Seems no setting can fit all...

Alberto Montilla Thu, 03/11/2010 - 08:27
User Badges:
  • Cisco Employee,

Don’t disable NAT Keepalive, just NAT Mapping... NAT keepalive should be there to keep the ports open...

samsonluk Thu, 03/11/2010 - 09:16
User Badges:

Back to squre one, REGISTER failed after enable NAT Keep Alive and disable NAT Mapping.  Attached log recorded the whole process started with successful registration then change external IP in the middle and follow with registration failed, cannot see "SIP VIA received=" after external IP changed.

Attachment: 
Alberto Montilla Wed, 03/17/2010 - 16:01
User Badges:
  • Cisco Employee,

Dear Sir;


You will face this situation unless STUN is enabled. I suggest you check for a public STUN server and use it. Otherwise you will have this issue always as the server, does not know where to send the SIP reply message to the Register.


Regards
Alberto

Actions

This Discussion