Toggle sidebar Toggle sidebar

sipgate.co.uk registration timeout (constant)

Status
Not open for further replies.

AlecM

Customer
Joined
Aug 24, 2007
Messages
64
Reaction score
4
Hi.
3CX Version: 3.1.2434.0 (Free).
Installed on a test PC: XP Pro SP2, 2 x P3-650's, 512Mb RAM.

I have a Sipgate.co.uk VoIP account.
On the 3CX box I have registered this VoIP line using the Sipgate pre-configured template, added my sipgate credentials, and added the outgoing dialing rule #, with mask r.

I have only seen the line "register" once - and only for a few seconds. The rest of the time it is "unregistered".

Example of what the 3CX server log indicates (I've edited out my actual number):

16:43:39.011 ClientRegs::onRequestRetry [CM113008] Registration attempt for Ln:10000@SipGate 0845 xxx xxxx is scheduled in 120 sec.
16:43:38.700 ClientRegs::onFailure [CM113010] Next registration will be attempted in 10 minutes
16:43:38.700 ClientRegs::onFailure [CM113006] Registration of sip:xxxxxxx@sipgate.co.uk has failed; reason=Request Timeout

We have a SonicWALL 2040 Pro firewall, which has been configured to allow SIP (a prebuilt rule), plus I have added the 3CX ports of 9000-9499 to this rule.

I have added the SIP DNS entries for the 3CX server to my Active Directory.

Can anyone guide me as to what might be causing the failure of the registration? (I have posted on the Sipgate help about this as well).

Thanks for any help!
Al
 
Hi Kev,

Umm - possibly? The rules are not displayed with such clear descriptions. But I do know it does have port scanning prevention.

The logs do seem to distinguish this type of packet drop though, clearly stating dropped because of port scan.

That's not what seem to be happening here though.

I was interested to see your STUN rules though, as I don't think this is something my current rules cover - yet there does seem to be a STUN issue according to the 3CX log.

I will try adding that to my VOIP services rule (a convenient group of rules) and see if that makes a difference.

Thanks again for the continued input - it's appreciated!

Al
 
Hi again Kev,

Well, I've tried adding those additional rules for the STUN ports, but they didn't stop the packets being dropped.

So I have taken a rather radical step of adding UDP ports 1 - 50000 to my VOIP access rule. This certainly seems to have stopped the external incoming UDP packets from Sipgate being dropped, but I am still getting line busy when trying to call in.

The log does still show a registration problem as well.
From the firewall log:
Warning VOIP SIP Register expiration exceeds configured Signaling inactivity time out 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 [email protected] using expiration of 3600 secs.

From the 3CX log:
13:13:52.939 CallMgr::failResolveExtIp [CM200001] Failed to resolve external IP!
13:13:52.939 StunClient::process [CM215001] STUN failed to resolve external IP using server 64.69.76.23
13:13:49.879 StunClient::process [CM215001] STUN failed to resolve external IP using server 64.69.76.23
13:13:46.818 StunClient::process [CM115001] Send initial STUN request to 64.69.76.23

So STUN still seems a problem for my 3CX system.

Do you know what the system is actually trying to do with the "resolve external IP" ?

Al
 
Hi Al

STUN is used to find out what the public IP address of the router is and to find out which port is open to allow traffic back through to the network behind a NAT firewall

You can read about STUN here http://en.wikipedia.org/wiki/STUN

In Manage Gateways and Providers my STUN settings for my Sipgate line are as follows :

Registrar/Proxy Hostname or IP - sipgate.co.uk
Registrar/Proxy Port - 5060

Outbound Proxy Hostname or IP - blank
Outbound Proxy Port (default is 5060) - blank

STUN server Hostname or IP - stun.sipgate.net
STUN server Port (default is 3478) - 10000

Kev
 
Yeah - that's what I've got for Sipgate as well.

I'm sure the issue is with my firewall not letting the 3CX STUN server not recognise my 3CX install (or something like that!), as it's the 3CX STUN IP address that keeps showing up in my 3CX status log with the "failed to resolve" error.
 
Hi Al

If you use 217.10.79.2 which is the IP address of stun.sipgate.net does the problem still occur ?

In the General Settings under STUN Server Options I have the following :

Default STUN server address/port - stun.sipgate.net:10000
Default second STUN server address/port - stun.3cx.com:3478
Timeout time for STUN response (ms) - 5000
Recheck external IP every (sec) - 600

Kev
 
Hi Kev,

Well, that seems to have stopped the "unable to resolve stun" type messages, though I am still getting a busy tome when trying to dial in.

Strange that I can dial out on it OK though.

Am hoping the SonicWALL forum may be of help on this... though they are nowhere near as responsive as this one!

Al
 
Hi Al

Glad you can now resolve the STUN server, however that means you may have a DNS error if the server can't resolve the name of the STUN server !!

When you dial in, where is the call being routed to, is it the softphone ?
Make sure the extension thats answering the incoming call is online and avaliable

Kev
 
Hi Kev,

The incoming call rule is set to call my extension (set up on a Grandstream BT200) for testing purposes - this will be changed to direct calls to the DR once the incoming SIP calls are working correctly. My extension is online and available as far as my 3CX is concerned - all internal extension fucntions operate as planned/expected.

I'm not sure our DNS settings are at fault. We have our own internal DNS server that relays any unrecognised requests from any LAN PC/server out to our provider's (PIPEX) DNS servers.

It's possible of course that the PIPEX DNS db isn't as fresh as it could be, but I doubt it would remain so for weeks on end.

Also, there must be some resolution going on, as the 3CX STUN IP reported in the log was set in General Settings using the DNS host name. Therefore the system was resolving from host to IP.

What I think the log message was intending to mean was that our external router's IP is not resolving (according to the external 3CX STUN server at stun.3cx.com), but the log message is a little ambiguous to be competely sure if this is what is meant.

Al
 
Hi Al

Thats strange that you get the bsuy tone still, are there any other errors in the logs now ?

If you set your extension to forward to voicemail and then try and dial in do you hear the voicemail prompt ?

If you send the incoming call to another extension do you still get the busy tone ?

Point taken about DNS, just seemed strange that adding the IP address and not the name of the STUN server got rid of the error, but thinking about it, if DNS wasn't working then you wouldn't get the line registered with Sipgate

Kev
 
Nearly there...

Hi Kev,

Well, another day and another step forward!

I seem to have cracked the problem of getting 3CX to fully and properly register the sipgate account now.

In the sipgate VOIP gateway settings on my 3CX box, the default value for the time between registration attempts was 3600 seconds. The firewall log was reporting back that this was too long, so I simply reduced it down to 1800 seconds. I now see successful registration traffic (although I do sometimes still get a 401 unauthorised for some reason).

Example extract from the firewall logs:
1 10/05/2007 18:26:32.128 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
2 10/05/2007 18:26:32.064 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
3 10/05/2007 18:24:43.256 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (200 OK) ([email protected])
4 10/05/2007 18:24:43.192 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
5 10/05/2007 18:23:48.656 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (200 OK) ([email protected])
6 10/05/2007 18:23:48.576 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
7 10/05/2007 18:22:54.032 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (200 OK) ([email protected])
8 10/05/2007 18:22:53.944 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
9 10/05/2007 18:21:04.896 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
10 10/05/2007 18:21:04.832 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
11 10/05/2007 18:19:16.016 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (200 OK) ([email protected])
12 10/05/2007 18:19:15.912 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
13 10/05/2007 18:17:26.816 Debug VOIP SIP Response 217.10.79.23, 5060, X1 10.0.0.22, 5060, X0 SIP REGISTER (200 OK) ([email protected])
14 10/05/2007 18:17:26.768 Debug VOIP SIP Request 10.0.0.22, 5060, X0 217.10.79.23, 5060, X1 SIP REGISTER ([email protected])
Click to expand...

I do still have a problem for trying to dial in to my Sipgate PSTN number though, as this is still responding as "number busy" on my mobile.

I have been able to call out (which was true before as well). I though the dial in problem was purely my firewall, now it seems it wasn't (at least not entirely) - unless something else is still not quite right.

I have emailed their tech support about this this evening, so will wait and see what they say. Perhaps an issue with their system.

I also tried a second SIP account with Voipuser.org and tried calling between that and sipgate, but this wasn't successful either, responding as "21:call rejected" in the 3CX softphone. It also reported this when trying to call my moble, but I think this is because of a delay before getting access to the PSTN minutes pool.

So, not a smooth introduction to voip overall! Though I'm sure it will be worth it in the end!

Al
 
Hi Al

Glad you are making steps forward and have got the registration sorted, am not sure why changing that value has made a difference, my install is using the default 3600 value without a problem.

Can you post a snippet of the log for the server and the softphone so I can see what is happening when you dial in an get the busy tone ?

Kev
 
Hi Kev,

Baby steps it seems...

I got a support reply from Sipgate saying they had tested my account with their "terminal" (I guess they meant a Sip phone in software or similar) and it was successful, indicating it was a 3CX or firewall problem.
Helpful.

I had picked up somewhere on the Sipgate support pages that an RDP rule (UDP port 5004) was also required through my firewall for sipgate, so have added that.

This, plus anything that sipgate might have triggered by their use of my account resulted in my getting a "line not recognised" tone instead of a busy signal.

Of course, I thought this was a step backwards, but decided to try the 3CX phone again, just to see what happened.

After the softphone registered with Sipgate, I then called the number, and Lo! - I get the call ariving at my desk handset, as the incoming call was routed through 3CX.

Bizarre. So I quit the softphone and tried again - but got the not recognised signal again. Login with the software and my desktop phone will ring.

My Sipgate profile settings at this point showed both the "SIPPER" (3CX soft phone) and my 3CX were connected.

I then happened to do a relogin on my PC (unrelated to this exercise), then tried calling in again without starting the softphone - and this time it worked correctly straight away.

So I really don't get entirely what's happened. Obviously some sort of connection issue has been resolved, perhaps something to do with security of the account. I do think my firewall config was interfering as well, though I had added the RDP rule on Friday without any change in call ability.

My Sipgate profile settings at this point showed only the 3CX server, as expected.

So my firewall rules for VOIP ended up being:
("description", type, port range)

"SIP" UDP 5060 5061
"3CX Required UDP" UDP 9000 9499
"SIP - SIPGATE STUN" UDP 10000 10000
"SIP - Standard VOIP" STUN UDP 3478 3478
"SIP - SIPGATE RTP" UDP 5004 5004

After that, I used the 3CX softphone in addition to my 3CX server to register the "line". I could then quit the softphone (not active in anyway). After a few minutes (perhaps to stabilise with Sipgate?), the 3CX server handled everything properly.

Thanks for your input and help on this topic Kev - it has been very much appreciated in restricting how much hair I pull out!

And hopefully this topic thread will help someone else!

Kind regards,

Al
 
Hi Al

I am glad that you have it working, although its a bit of a workaround having to register the softphone first, I wonder if its a NAT problem and registering the softphone first opens the correct port on the firewall ?
Have you compared the open ports before and after the softphone is registered ?

I don't have port 5004 open on my firewall and my system works fine.

Kev
 
Hi Kev,

The SonicWALL doesn't support dynamic "learning" like a PC-based software firewall such as Symantec might do for example. It's a separate hardware firewall for which I have to manually configure all the rules (though there is a wizard that assists with some of this process).

So, the open ports "before and after" should remain the same at all times (they are the ones listed in my previous post). Of course, I may be wrong on this - as I mentioned way back, I'm an "educated super-user" rather than an expert on the firewall's behaviour.

I am experimenting with removing UDP 5004 to see what happens now that calls are working - see if it stops them again in other words - as this may be an unnecessary opening. One quick check seems to make no difference, but the registration timer lapse may need to occur when registration may fail again, so will leave it a few minutes and try again.

Will post result...

Alec
 
Well....

I have removed the RTP rule, but the registration with Sipgate seemed to get dropped, as I again got the "not recognised" tones.

I'm now testing whether this is actually due to the need for the softphone to maintain the registration properly, or if it is the protocol rule.

This takes a while, as there seems to be a reasonable "lag" between the softphone activating the registration and it getting dropped again after quitting the softphone, so it may be a while before I can post back my findings.

I guess I could just install the softphone on my 3CX server and leave it running, but I don't believe I should rely on "cludge" fixes for a business system.

Al
 
Hi Al

I have just been looking through the Sipgate help pages, it seems that port 5004 is used as listening RTP port, and it seems that it can vary between different makes of router/firewall as to whether you need to force it open in your configuration, yours seems to be one of those cases where you need to open it.

http://www.sipgate.co.uk/faq/index.php?do=displayArticle&article=323&qw=5004

http://www.sipgate.co.uk/faq/index.php?do=displayArticle&article=602&qw=5004

Totally agree with you you shouldn't "cludge" fixes for business systems.

Kev
 
Hi Kev,

Yeah, that second link is the one I came across and prompted me to try that extra rule.

What I have found so far is that after a complete registration (running both the software phone and 3CX server registrations), I can then remove the 5004 RTP port and still call in.

However, I'm not yet sure if removing this rule caused the later dropping of the registration or whether it's after a time-out occurs from after closing the Softphone.

I guess what I need to do is leave the RTP 5004 port open, make sure the softphone has made a registration, quit the softphone completely and then leave the system for a couple of hours / overnight and then see if I still can make an inward call.

If it does keep the full connection, I can then remove the rule, leave it a couple of hours and try again. If it fails, I'll then know I need to retain the rule after registration.

If neither of these work, I'll then try the install and run the softphone on the 3CX server (which stays running 24x7) and repeat the two tests.

A bit time consuming, but at least it should be thorough.

Al
 
Hi Al

Let me know how you get on

Kev
 
Morning Kev!

Well, success basically.

By leaving the RTP 5004 port rule active on the firewall and "completely" registering the line via 3CX softphone, then quitting the phone (my workstation is shut down overnight anyway), the line stayed registered overnight, so I was still able to make inwards calls this morning.

So it seems that this rule is required for my model of firewall.

Now onto further testing...

Kind regards,

Al
 
Afternoon Al !

Glad you have established that the 5004 rule is required, now to work out why the 3CX server won't register until you have got the softphone registered

Let me know how you get on

Kev
 
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
112,294
Messages
591,754
Members
165,428
Latest member
shaneOPTO
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom