Jump to content

408 Request Timeout (Registration failed, retry after 60 seconds)


Leonardo srl

Recommended Posts

we have been testing SnomOne for 2 weeks now, and we were almost thinking about buying the blue one for a company we work for;

but in the last days there were some unexpected things which raised up a few doubts;

hoping they will disappear soon, as the product is very fine from the administration point of view;

the biggest problem we have came out today;

for 2 weeks the registration of a sip-trunk worked perfectly; today it is always giving "408 request timeout";

the situation is the following:

> the server is Windows 2008 English 64bit

> the snomone software is the actual one at 64bit

> we did not change anything on the configuration of SnomOne, but unexpectedly it started giving problems today

> if we configure the same sip-account on a snom phone 821 it works great (so it is not a sip-provider problem)

> if we configure the same sip-account on a softphone on the same server it works great (so it is not a firewall, port or any other problem

regarding the server itself)

> another sip-trunk on the snom-one is still working fine (it's another provider) and says 200 OK registered

 

activating the log on the most detailled way, it says just the following

of course:

- [server-ip] contains the real ip of the server

- [trunk-account] contains the real account user of the sip-provider

 

[9] 2012/04/12 21:31:26: SIP Tr udp:83.211.227.21:5060:

REGISTER sip:voip.eutelia.it SIP/2.0

Via: SIP/2.0/UDP [server-ip]:5060;branch=z9hG4bK-e59675b24c1a72b65270c196bc7a5362;rport

From: "[trunk-account]" <sip:[trunk-account]@voip.eutelia.it>;tag=17644

To: "[trunk-account]" <sip:[trunk-account]@voip.eutelia.it>

Call-ID: fq87utbb@pbx

CSeq: 27476 REGISTER

Max-Forwards: 70

Contact: <sip:[trunk-account]@[server-ip]:5060;transport=udp;line=9bf31c7f>;+sip.instance="<urn:uuid:cb028e47-5cf1-4e18-a931-4420d3e4e724>"

User-Agent: snom-PBX/4.2.0.3958

Supported: outbound

Expires: 3600

Content-Length: 0

 

[5] 2012/04/12 21:31:26: Registration on trunk 15 (test) failed. Retry in 60 seconds

 

anyone has any idea what we could check? service was already restarted ... trunk was deleted and reinserted ... nothing helps

thanks!

Giovanni

Link to comment
Share on other sites

Well, what could be is that the service is really not available. This could be because the Internet connection is (temporarily) unavailable, or the service provider does not answer the request. That can be because the IP address where you are sending from suddenly became blacklisted or even worse the service provider has technical problems (can also happen). If you see "Tr" in the log that means the PBX is repeating the request and did not get anything back. Also if you are operating your PBX behind a NAT, maybe the public IP address of the router has changed in case that you have setup the PBX to replace the IP address with the public IP address. If your phones are still registered, you can exclude problems with the server itself.

 

Other problems we have seen especially in Italy are problems with the DNS. Sometimes the service itself available, but cannot be found on DNS any more. In that case you can just "hard code" the IP address instead of the DNS in the outbound proxy of the trunk. It does not win the beauty contest, but solves a real problem with some DNS servers.

Link to comment
Share on other sites

Well, what could be is that the service is really not available. This could be because the Internet connection is (temporarily) unavailable, or the service provider does not answer the request. That can be because the IP address where you are sending from suddenly became blacklisted or even worse the service provider has technical problems (can also happen). If you see "Tr" in the log that means the PBX is repeating the request and did not get anything back. Also if you are operating your PBX behind a NAT, maybe the public IP address of the router has changed in case that you have setup the PBX to replace the IP address with the public IP address. If your phones are still registered, you can exclude problems with the server itself.

 

Other problems we have seen especially in Italy are problems with the DNS. Sometimes the service itself available, but cannot be found on DNS any more. In that case you can just "hard code" the IP address instead of the DNS in the outbound proxy of the trunk. It does not win the beauty contest, but solves a real problem with some DNS servers.

 

thank you very much for your quick reply!!

- no the service is really available: registering from a (Snom) phone works, and registering from a softphone on the same server where

SnomOne resides works

- the address is not blacklisted as the softphone (i.e. same IP) works

- no technical problems at the provider: calling with the phone using the same provider works;

but registering on the SnomOne every trunk of this provider (Eutelia) doesn't work anymore (we had configured 5, which worked well before today)

- no NAT, it's a public IP

... so the only solution was the DNS-test, which unfortunately didn't work, this is the log

(I replaced the fields "Domain" and "Proxy Address" in the trunk with the IP corresponding to voip.eutelia.it)

 

[9] 2012/04/12 22:36:32: SIP Tr udp:83.211.227.21:5060:

REGISTER sip:83.211.227.21 SIP/2.0

Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK-f7fb3403eaa40a3a87a5a964f3ee9840;rport

From: "0472679055" <sip:0472xxxxxx@83.211.227.21>;tag=27076

To: "0472679055" <sip:0472xxxxxx@83.211.227.21>

Call-ID: 27c5ywkj@pbx

CSeq: 17336 REGISTER

Max-Forwards: 70

Contact: <sip:0472xxxxxx@xxx.xxx.xxx.xxx:5060;transport=udp;line=c74d97b0>;+sip.instance="<urn:uuid:a216d81f-4a4d-4cf5-ad74-2aff07491039>"

User-Agent: snom-PBX/2011-4.3.0.5021

Supported: outbound

Expires: 3600

Content-Length: 0

 

[9] 2012/04/12 22:36:36: Last message repeated 2 times

[5] 2012/04/12 22:36:36: Registration on trunk 16 (test) failed. Retry in 60 seconds

 

any other ideas?

Link to comment
Share on other sites

(I replaced the fields "Domain" and "Proxy Address" in the trunk with the IP corresponding to voip.eutelia.it)

 

Don't replace the domain name; that might confuse the service provider. Only the Proxy Address, which tells the PBX where to send the request.

 

One more thing to check would be the Windows firewall, although it would be very surprising if the firewall suddenly blocks traffic after two weeks of good operation.

Link to comment
Share on other sites

Don't replace the domain name; that might confuse the service provider. Only the Proxy Address, which tells the PBX where to send the request.

 

One more thing to check would be the Windows firewall, although it would be very surprising if the firewall suddenly blocks traffic after two weeks of good operation.

 

ok, that was worth a new test ... but it still doesn't work;

no problems on the firewall: another trunk (from another provider) works great on SnomOne and the same trunk (Eutelia), configured on the softphone installed on the same server (=same firewall) works great; the only case which doesn't work is Eutelia's trunk configured on the SnomOne ...

I think I will do a last test now ... remove completely SnomOne and install it again from scratch ... it's very strange and silly, but I cannot think of another kind of solution;

if it works, then the problem is a bug on SnomOne, but then I would be very frightened starting the pbx in a "real world" ... where our customer (as the most of voip customers in Italy) has official numbers registered with Eutelia ...

if you - or anyone in this forum - doesn't have new ideas to check something out, I don't see other solutions;

thank you for your real help, I appreciated it very much!

Link to comment
Share on other sites

2 things -

  1. Did you really see the packet is leaving the system where the PBX running? This can be done using a wireshark (or some other network tracers)
  2. Did you verify that the provider has not filtering packets based on user agent string?

 

> I didn't do the wireshark test, but the log say it does, and the other trunk configured works, therefore outbound communication from pbx to the net is working

> unfortunately I have no possibility to do this; Eutelia is a big player in the voip-market in Italy, and big companies have always silly call centers;

if I made such a question, the gently woman on the other side (trying hard to speak something similar to Italian, as call center is outsorced to Romania),

they probably will say the don't filter anything and I should try to restart the server or verify the firewall or something generic they've been trained to answer ...

but if it was true, then it should be something new, as it was greatly working before ...

I will try now to install the PBX on a local pc and do the test ... if it works ... then it wouldn't be the user agent string

 

anyway ... thank you!

Link to comment
Share on other sites

tested on another pbx local installation and Eutelia works perfectly;

so tried to do the whole installation again on the server!

 

so the "solution" was the following

> deinstall the actual software (very strange: deinstallation doesn't remove the directory!)

> delete the whole directory

> install the official software version (it is a version of 2010!)

> upgrade the version with the most actual exe

> setup the software again

> change the pbx.xml (it is the usual problem, that the integrated webserver get installed on port 80, not really a good idea)

and start the service manually

> reconfigured everything from scratch, and it worked!

 

will continue the test for the following weeks, hoping it won't happen anymore!

... but now I'm a little scared ... will the software work when it will be installed on a customer's production server?

or will it be instable like it was this week?

Link to comment
Share on other sites

Stability is most important for a PBX, the system should run 24/7 thats the key feature of a telephone system. In the IT world, there are unfortunately a lot of components in the picture that ca make this a problem. I doubt that it is the PBX iteself which has a problem, th "Tx" log entry is pretty low level and from then on there is not much happening between the PBX logging in and putting the packet on the cable.

 

Before it hits the service provider (who BTW also operates an IT system!), the packet has to pass the operating system, and here the biggest enemy is the personal firewall (if present) and hte local interface. The personal firewall is usually only a problem during installation, once it whitelisted the PBX process I dont see a reason why it should filter packets after two weeks. On the interface side, I can think about link loss (no Ethernet connection) and problems with the IP configuration like DHCP server down or an IP address conflict, However in that case the PBX should not be available to anyone on that interface. If there are multiple interface, for example on efor the LAN and another one for the WAN, then it could explain why the LAN registration worked while the WAN did not work. We have seen cases where cables were broken (very difficult to find out). Maybe there is a log entry in the OS that tells about link loss events, this would be an easy way to find out if that was the problem.

 

Then once that the packet physically has left the PBX host, the next problem zone is the firewall. This is a long chapter. We have seen firewalls with 32 UDP NAT entries, and when they were full they simply dropped the traffic. This was also very difficult to trouble shoot. Another "favourite" is when the firewall is "SIP aware", which usually means no good. All the firewall does in such cases it mangle packets or accidentially drop them at all. My standard recommendation for SIP aware firewalls is to turn the madness off, use TLS to hire the traffic from the firewall or purchase another one without the feature.

 

 

 

Link to comment
Share on other sites

Stability is most important for a PBX, the system should run 24/7 thats the key feature of a telephone system. In the IT world, there are unfortunately a lot of components in the picture that ca make this a problem. I doubt that it is the PBX iteself which has a problem, th "Tx" log entry is pretty low level and from then on there is not much happening between the PBX logging in and putting the packet on the cable.

 

Before it hits the service provider (who BTW also operates an IT system!), the packet has to pass the operating system, and here the biggest enemy is the personal firewall (if present) and hte local interface. The personal firewall is usually only a problem during installation, once it whitelisted the PBX process I dont see a reason why it should filter packets after two weeks. On the interface side, I can think about link loss (no Ethernet connection) and problems with the IP configuration like DHCP server down or an IP address conflict, However in that case the PBX should not be available to anyone on that interface. If there are multiple interface, for example on efor the LAN and another one for the WAN, then it could explain why the LAN registration worked while the WAN did not work. We have seen cases where cables were broken (very difficult to find out). Maybe there is a log entry in the OS that tells about link loss events, this would be an easy way to find out if that was the problem.

 

Then once that the packet physically has left the PBX host, the next problem zone is the firewall. This is a long chapter. We have seen firewalls with 32 UDP NAT entries, and when they were full they simply dropped the traffic. This was also very difficult to trouble shoot. Another "favourite" is when the firewall is "SIP aware", which usually means no good. All the firewall does in such cases it mangle packets or accidentially drop them at all. My standard recommendation for SIP aware firewalls is to turn the madness off, use TLS to hire the traffic from the firewall or purchase another one without the feature.

 

thank you for your answer, but you probably didn't read the whole content; the short version of the story: SnomOne worked well with 2 trunks for 2 weeks; nothing was done afterwards; then one of the two stopped working, the other still worked ok (so, no firewall problem: same service, same sip, same rtp); softphone installed on the same machine worked well with the problematic trunk (so, no problem at the voip provider); snomone installed on another machine worked well with the same problematic trunk (still no problem with voip provider); so apparently there was no problem at all, but the problem was still there; it was resolved (we hope it!) by removing (and manually deleting the directory as the removal process of snomOne doesn't do the right job!) and reinstalling the software; on this server nothing else is being done as it is a complete new server and the first software installed was SnomOne

Link to comment
Share on other sites

It would be good to really find the reason, so that we can put that on our checklist. Reinstallation is not really a solution to me that we can recomment... We also had other topics with voip.eutelia.it (for example, http://forum.snomone.com/index.php?/topic/2741-error-400-bad-request/) and it would be good to know if there is anything that we can do to make this install smooth. If it magically suddenly works we all love to hear it, but it would be better to know why it works again.

BTW if you change files on the file system, the PBX does not care about that. The PBX reads most of those files only during the startup phase.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...