Registration failure

Hi there,

I have two extensions 1001 and 1002. I have set them both up on my 2 SPA942 phones and they can register correctly.

Every so often though when I go to use the handset I see that one (or both) of the extension lights on my phone has gone out. When I look into this I see that registration has failed for one of the extensions. (When it goes to register again it seems to fix it up - but I am at times without any available extensions, so this issue does become very important).

When I then look into the pbxes system logs I find these errors constantly appearing...

Sep 21 07:33:16 VERBOSE[8624] chan_sip.c: SIP REGISTER attempt failed for (null) : Bad digest user
Sep 21 07:33:16 NOTICE[8624] chan_sip.c: Registration from '' failed - Username/auth name mismatch

Not sure how to fix these though, as the username and auth details do indeed work (as evidenced by the registration working at times).

Does anyone have any ideas on what to look at next? Thanks.

regards,

Matthew Venamore

RE: SPA942 - Registration failure

Hi,
Not sure how you are set up but It normally helps if you reduce the registration interval in the SPA setup, I have it set to 60 secs.
Also port forwarding the sip ports is worthwhile.
These tips from the forum certainly fixed similar problems for me.
Regards

RE: SPA942 - Registration failure

Setting the re-registration interval to such a low value (1 minute) on UAs, creates an unnecessary burden of traffic to the servers, just to compensate for not setting up properly port forwarding on routers.

If doing so, is the only way to keep your extensions registered to PBXes, then something is seriously flawed with the NAT Traversal techniques of your SIP UAs. Seek help, since a 30 minute (1800 sec) re-registration interval should be sufficient for the vast majority of routers.

Matthew, the issue you brought up has to do a lot with the router you use, so please mention its' brand & model, as well as inquire with the vendor whether it uses a SIP ALG, which would conflict with the STUN setting in your phone.

• Does your SPA-942 use different SIP ports on each line?
• Is your SPA-942 the only UA on your account, or are there any other UAs like soft=phones, ATAs, etc. for which the message might be intended?

RE: SPA942 - Registration failure

Hi Diafora,
My comment about registration interval for the SPA942 was taken from the PBXes documentation section (top of the page) for dynamic or problematic IPs., I believed it might help in diagnosing the issue.
Regards

RE: SPA942 - Registration failure

Hi,

Thanks for the response.

My router is a Linksys AG310. And it indeed does use SIP ALG.

Also - Yes, my SPA942 (both of them) use different ports for each line. Line 1 is 5060 and Line 2 is 5061.

I have 2 SPA942's setup. I have set up the first two lines on each of these to be for my extensiosn 1001 and 1002 as I mentioned. Is that likely to cause the issue?

Also with regards to STUN, I originally had the STUN server value set on my SPA942's because I was registering direct to my SIP provider. I took that out when registering the SPA942 to pbxes.com though. Was that the right thing to do?

I also haven't set up port forwarding on my router as telagente00 kindly mentioned. Should this be part of the solution?

Sorry for so many questions. Thanks for your help.

RE: SPA942 - Registration failure

if I understand correctly you have 2 of the 942 phones, Each 'line' should be unique so If the first 942 uses sip ports 5060 and 5061, then the second 942 should use 5062 and 5063 and so on.
Each SPA942 'line' should register with its own PBXes extension.
Regards

RE: SPA942 - Registration failure

Hi telagente00,

Thanks for that. I actually thought I already had my phones set up like that, but when I checked I did have a double up on the port numbers between the phones.

I'll change that now and see if that helps the situation. Thanks again.

RE: SPA942 - Registration failure

A couple of general points, with specific suggestion that apply in your situation are listed below:

• If your router's SIP ALG is activated, the STUN (as well as TURN, ICE, or any other NAT Traversal technique) setting on your SIP User Agents should be turned off. If both of them are active even on a single SIP UA in your LAN, all sorts of nasty things can happen in your network, including spontaneous reboots of your router. This applies to any ITSP you might use, not PBXes in particular.

• Concurrent registrations to the PBXes' SIP Proxies are not allowed from any SIP UA, under any circumstances. Each SIP UA (every SPA-942 has 4 UAs in total) should correspond to a single extension number. So in your case, the SPA-942 phones should register to 4 different extensions on your PBXes account.

First LED on 1st SPA942 - Line 1 -> Extension 1001
Second LED on 1st SPA942 - Line 2 -> Extension 1002

First LED on 2nd SPA942 - Line 1 -> Extension 1003
Second LED on 2nd SPA942 - Line 2 -> Extension 1004

• Which brings to the last major rule: Each SIP UA, should be individually addressed by a PBXes SIP Proxy. This is quite challenging to achieve on a LAN with multiple SIP UAs, which share a single Public IP over a WAN connection.

This is precisely the reason, there should be no duplicate SIP port numbers, on any SIP UA (IP-phones, ATAs, soft-phones) sharing a single Public IP. Each SIP UA is identified by IP_Address:Port_Number to the SIP Proxy. So in your case (unless you have assigned a Public IP on each SPA) the SIP port numbers should be set up like the example below:

First LED on 1st SPA942 - Line 1 -> SIP Port: 5061
Second LED on 1st SPA942 - Line 2 -> SIP Port: 5062
Third LED on 1st SPA942 - Line 3 -> SIP Port: 5063
Fourth LED on 1st SPA942 - Line 4 -> SIP Port: 5064

First LED on 2nd SPA942 - Line 1 -> SIP Port: 5065
Second LED on 2nd SPA942 - Line 2 -> SIP Port: 5066
Third LED on 2nd SPA942 - Line 3 -> SIP Port: 5067
Fourth LED on 2nd SPA942 - Line 4 -> SIP Port: 5068

A couple of notes regarding the above setup:

1# I skipped port 5060 intentionally, since this is the default SIP port on SIP UAs, which may conflict in the future, with another SIP UA you might setup on your LAN temporarily (soft-phone, mobile phone SIP client, etc.)
2# I also elected to setup the SIP port on every line initially, to avoid conflicts later on, when you enable the rest of the lines with another extension.

Setup your SPAs following the above guidelines, and let us know if your issues get resolved.

RE: SPA942 - Registration failure

Hi Diafora,

That was excellent information. And really quite obvious when I think about it, so thank you for setting me straight.

I have just set that up, and it has been stable for the last 5 minutes. So thanks in advance, and I will advise if things go haywire again.

Many thanks.

PS I will update an appropriate place in the wiki with some of this information if it is not already there. Thanks.

RE: SPA942 - Registration failure

OK. Can do.

Hi again,

It turns out that those last changes did help, but only a little. The problem still occurs but just not so frequently now. (i.e. was every few minutes, but now seems to be after ten minutes or so, on average). And I have double checked everything several times to ensure I haven't missed anything.

Any ideas as to the next step that I should investigate?

I have set up the port forwarding on my router so that the port ranges are sent through to the correct SPA942, as suggested by teleagnet0. This didn't seem to help either.

Thanks for any help anyone can give.

RE: SPA942 - Registration failure

Let's review the situation, to ensure how the SIP phones and router are currently setup:

• The SIP ALG on the router is turned off.
• The SIP ports on the SPAs are unique for each line.
• You have a total of 4 extensions on your PBXes account, for these SPAs.
• Both SPAs are using a STUN server for NAT traversal.
• Each SPA's SIP ports are separately setup in the port forwarding on the router.

RE: SPA942 - Registration failure

Zitat:

Originally posted by Diafora Let's review... • The SIP ALG on the router is turned off. • Both SPAs are using a STUN server for NAT traversal.

OK. I actually had this the other way around.
I had SIP ALG turned on (there did not seem any option to turn this off on my router); and
I had the STUN server turned off for both SPA's.

So considering that you suggest turning the SIP ALG off, I have set up another router which doesn't use it, with all the settings the same. ie port forwarding, no stun, separate ports for each UA, only one extensions being registered.

Still getting the same issue though. I am beginning to suspect my ISP. Is that likely? Thanks for all your help on this one.

RE: SPA942 - Registration failure

Well, you tried with the ALG on and STUN off, and your SPAs are loosing their registration. Try the other way around, and see if it makes a difference.

If your router has a SIP ALG, there should be some way to disable it. If might not be on its' web interface but via its' CLI. Do some research and see if you can disable it. If not, try another router and see if your SPAs hold their registration.

Lastly, if your SPAs can receive and dial calls successfully, even for two minutes after they reboot, it's unlikely your ISP is blocking or meddling with VoIP traffic. It's possible though.

Try another router first, and you will see. If you are going to buy one, I advise you to ask for opinions from other PBXes users, which routers work for them.

RE: SPA942 - Registration failure

OK,

I went away and did my homework, but I haven't succeeded unfortunately.

I have now tried it with...

1.
- Original Router (Linksys AG310)
- SIP ALG off (found out where to do this)
- STUN used on both SPA units

2.
- Original Router (Linksys AG310)
- SIP ALG on
- STUN off on both units

3.
- Original Router (Linksys AG310)
- SIP ALG on
- STUN used on just one unit

4.
- New router (D-Link DSL-2740B)
- SIP ALG not implemented
- STUN set on both SPA units

5.
- New router (D-Link DSL-2740B)
- SIP ALG not implemented
- STUN off on both units

6.
- New router (D-Link DSL-2740B)
- SIP ALG not implemented
- STUN set on only one SPA unit

In all cases they lose their registration from anywhere between, 5 and 15 minutes.

To keep it simpler, I am now only trying to register one extension per unit (1001 and 1002).
I have also got the port forwarding set up for each still and the port numbers are different for each extension.

One thing I have noticed is that the registration does come back at times, even (occasionally) before the 1800 second re-register time. Not sure if that helps give anything away for you.

So, after all that I am still a bit lost as to where the problem might lie. Any suggestions again greatfully received.

RE: SPA942 - Registration failure

Well, you have certainly done your homework, even if your issue has not been resolved yet. It is starting to sound as a broadband connectivity issue, so if you wish, provide us with the following info.

• What kind of DSL connection do you have, from which ISP, and which version of firmware is running on these two routers?
• It would be interesting to see a traceroute (tracert in Windows) as well as a ping with at least 10 hops towards the PBXes server you are trying to connect your extensions to.

Since the SPAs support PPPoE you might consider bridging an ADSL modem or router, to have the SPA connect directly to the ISP, bypassing any NAT on the router, as well as your LAN cabling. If that SPA keeps loosing its' registration instead of holding it solidly, then your ISP is most likely the culprit.

They either have a network issue starting at their DSLAM, or they might be using DPI to prevent VoIP from working properly by impeding its' performance. Does your ISP offer their own VoIP service?

RE: SPA942 - Registration failure

OK. Hi again Diafora.

Here is what I have found from the latest round of tests...

- With my router in bridged mode, and connecting the SPA direct to my ISP, the registration still gets lost after a little while.

- The other interesting thing that I tested, was registering the SPA's direct to my SIP Trunk provider (back in non-bridged mode on the router). Interestingly the registration didn't drop out doing it this way. So to me, that seems like it probably isn't an ISP issue.

- Other info that you suggested I provide...

tracert
---------
Tracing route to pbxes.org [188.40.65.148]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.1.1
2 52 ms 54 ms 52 ms lns01.ispone.net.au [124.254.72.18]
3 60 ms 55 ms 57 ms lns.gw.ispone.net.au [124.254.72.129]
4 52 ms 52 ms 53 ms GigabitEthernet3-10.exc1.Melbourne.telstra.net [139.130.248.161]
5 63 ms 52 ms 52 ms TenGigabitEthernet0-12-0-2.exi-core1.Melbourne.telstra.net [203.50.80.1]
6 67 ms 66 ms 69 ms Bundle-POS1.chw-core2.Sydney.telstra.net [203.50.6.13]
7 75 ms 68 ms 72 ms Bundle-Ether1.oxf-gw2.Sydney.telstra.net [203.50.6.90]
8 73 ms 67 ms 68 ms TenGigabitEthernetx-0.syd-core04.Sydney.reach.com [203.50.13.18]
9 126 ms 69 ms 75 ms i-3-1-0.sydp-core02.bi.reach.com [202.84.144.249]
10 217 ms 216 ms 216 ms i-2-0-0.wil-core02.bx.reach.com [202.84.140.246]
11 217 ms 218 ms 216 ms i-1-1.tlot03.bi.reach.com [202.84.251.234]
12 218 ms 215 ms 243 ms xe-11-2-0.edge1.losangeles6.level3.net [4.68.62.9]
13 236 ms 226 ms 233 ms ae-83-80.ebr3.LosAngeles1.Level3.net [4.69.144.180]
14 296 ms 298 ms 297 ms ae-4.ebr4.Washington1.Level3.net [4.69.132.82]
15 299 ms 289 ms 287 ms ae-94-94.csw4.Washington1.Level3.net [4.69.134.190]
16 314 ms 297 ms 297 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157]
17 376 ms 378 ms 378 ms ae-41-41.ebr2.Frankfurt1.Level3.net [4.69.137.49]
18 380 ms 385 ms * ae-92-92.csw4.Frankfurt1.Level3.net [4.69.140.30]
19 380 ms 378 ms 401 ms ae-4-99.edge6.Frankfurt1.Level3.net [4.68.23.206]
20 382 ms * 379 ms LAMBDANET.edge6.Frankfurt1.Level3.net [195.16.161.6]
21 381 ms 382 ms 380 ms FRA-3-eth100.de.lambdanet.net [217.71.96.70]
22 386 ms 385 ms 385 ms NUE-2-eth100.de.lambdanet.net [217.71.96.74]
23 386 ms 387 ms 387 ms lambdanet-gw.hetzner.de [213.239.242.214]
24 476 ms 385 ms 388 ms hos-bb2.juniper2.rz10.hetzner.de [213.239.240.147]
25 393 ms 386 ms 387 ms hos-tr3.ex3k4.rz10.hetzner.de [213.239.227.197]
26 385 ms 394 ms 387 ms www1.pbxes.com [188.40.65.148]

Trace complete.

Internet connection
--------------------------
ADSL G.DMT
Provider is ispOne (Optus wholesaler)

Firmware versions
-------------------------
Linksys AG310 - v1.04
Dlink DSL-2740B - v4.12(Aus)

====

So looking at all that information, it looks like (to me anyway) that the ISP may be OK because the direct SIP trunk registration works fine.
But perhaps the number of hops and high latency in some of those is what is at the heart of the problem I am having?

Thoughts? (Thanks in advance... again).

RE: SPA942 - Registration failure

Looking through the traceroute you sent, I can definitely tell you, there are servers closer to you. (www2 in San Diego and www6 in Tokyo).

There is no reason your PBXes account should remain in one of the European servers. Do a couple of traceroutes towards these two servers, and decide on to which to move your account to. I bet your ITSP's server is way closer to you than www1 is.

Looking through the traceroutes Tokyo seems to be closer to your location than San Diego is. Both of them are way more closer than Nuremberg is.

Traceroute to 124.254.72.18 (124.254.72.18) from www6 (Tokyo), 30 hops max, 40 byte packets
1 v187.aggr3.tok3.clara.ad.jp (124.108.37.2) 0.488 ms 0.443 ms 0.808 ms
2 v131.core1.tok3.clara.ad.jp (202.45.160.129) 0.182 ms 0.135 ms 0.128 ms
3 e2-1.core2.tok3.clara.ad.jp (202.45.160.90) 0.238 ms 0.199 ms 0.189 ms
4 202.131.192.81 (202.131.192.81) 0.364 ms 0.284 ms 0.284 ms
5 202.131.192.26 (202.131.192.26) 4.713 ms 0.322 ms 0.313 ms
6 202.131.192.5 (202.131.192.5) 0.395 ms 0.403 ms 0.392 ms
7 118.159.225.5 (118.159.225.5) 1.763 ms 13.164 ms 0.776 ms
8 otejbb204.kddnet.ad.jp (59.128.7.130) 12.992 ms
9 otejbb204.kddnet.ad.jp (59.128.7.194) 1.291 ms
10 otejbb203.kddnet.ad.jp (59.128.7.129) 1.332 ms
11 otecbb104.kddnet.ad.jp (59.128.4.166) 1.241 ms
12 otecbb103.kddnet.ad.jp (59.128.4.66) 175.315 ms
13 otecbb104.kddnet.ad.jp (59.128.4.174) 1.424 ms
14 tr-ote119.kddnet.ad.jp (124.211.33.73) 1.473 ms 1.460 ms 1.547 ms
15 118.155.194.74 (118.155.194.74) 1.190 ms 1.150 ms 1.068 ms
16 i-10-0-4.siko-core01.bi.reach.com (202.84.148.141) 1.190 ms 1.195 ms 1.095 ms
17 i-5-1.sydp-core02.bx.reach.com (202.84.143.149) 113.439 ms 113.478 ms 113.341 ms
18 TenGigE0-2-0-5.pad-gw2.Sydney.telstra.net (203.50.13.69) 113.978 ms 113.835 ms 113.976 ms
19 Bundle-Ether3.ken-core4.Sydney.telstra.net (203.50.6.30) 114.105 ms 114.493 ms 114.320 ms
20 Bundle-Ether4.chw-core2.Sydney.telstra.net (203.50.6.42) 114.554 ms 114.209 ms 114.009 ms
21 Bundle-POS1.exi-core1.Melbourne.telstra.net (203.50.6.14) 128.393 ms 128.210 ms 128.317 ms
22 TenGigabitEthernet7-1.exc1.Melbourne.telstra.net (203.50.80.12) 132.151 ms 132.129 ms 132.139 ms
23 ispone5.lnk.telstra.net (139.130.248.162) 128.612 ms 128.611 ms 128.723 ms
24 ge0-1.lns01.ispone.net.au (124.254.72.130) 129.819 ms 129.704 ms *

Traceroute to 124.254.72.18 (124.254.72.18) from www2 (San Diego), 30 hops max, 40 byte packets
1 71.6.135.1 (71.6.135.1) 0.696 ms 0.541 ms 0.396 ms
2 216.98.153.77 (216.98.153.77) 0.275 ms 0.499 ms 0.352 ms
3 216.98.153.90 (216.98.153.90) 0.624 ms 0.499 ms 0.327 ms
4 gi0-6.na21.b006463-1.san01.atlas.cogentco.com (66.28.28.125) 0.784 ms 0.879 ms 1.316 ms
5 gi1-41.3812.ccr01.san01.atlas.cogentco.com (38.20.33.129) 7.342 ms 7.240 ms 7.182 ms
6 te9-1.ccr02.lax01.atlas.cogentco.com (154.54.27.121) 3.458 ms 3.856 ms 3.715 ms
7 te7-3.ccr02.sjc01.atlas.cogentco.com (154.54.2.150) 15.803 ms 16.086 ms 15.962 ms
8 te4-2.ccr02.sjc03.atlas.cogentco.com (154.54.6.110) 16.585 ms 16.689 ms 16.566 ms
9 te2-1.mpd01.sjc03.atlas.cogentco.com (154.54.7.21) 16.849 ms
10 te3-1.mpd01.sjc03.atlas.cogentco.com (66.28.4.53) 17.134 ms
11 te2-1.mpd01.sjc03.atlas.cogentco.com (154.54.7.21) 16.477 ms
12 reach.sjc03.atlas.cogentco.com (154.54.10.190) 13.988 ms 14.054 ms
13 i-8-10-peer.eqnx02.pr.reach.com (134.159.62.145) 14.403 ms
14 g3_7-pax06.net.reach.com (202.84.251.86) 14.490 ms 14.369 ms 14.280 ms
15 i-4-1-0.sydp-core01.bx.reach.com (202.84.140.145) 196.349 ms 196.292 ms 196.411 ms
16 TenGigabitEthernet0-2-0-5.pad-gw1.Sydney.telstra.net (203.50.13.25) 196.823 ms 197.009 ms 196.882 ms
17 Bundle-Ether3.chw-core2.Sydney.telstra.net (203.50.6.26) 196.314 ms 196.320 ms 196.197 ms
18 Bundle-POS1.exi-core1.Melbourne.telstra.net (203.50.6.14) 211.518 ms 211.377 ms 211.440 ms
19 TenGigabitEthernet7-1.exc1.Melbourne.telstra.net (203.50.80.12) 210.210 ms 210.326 ms 210.197 ms
20 ispone5.lnk.telstra.net (139.130.248.162) 210.191 ms 210.049 ms 210.597 ms
21 ge0-1.lns01.ispone.net.au (124.254.72.130) 216.861 ms * *