Jump to content

Trunk Re-Registration Problems


JohnnyG

Recommended Posts

Basically you need to link /usr/local/snomONE/snomONE-ctrl to the new executable

 

First, download the fix. Then copy it in the snom ONE root directory:

cp pbxctrl-centos5-2011-4.2.1.4018 /usr/local/snomONE/

 

Stop snom ONE:

/etc/init.d/snomONE stop

 

Make the fix executable:

chmod +x /usr/local/snomONE/pbxctrl-centos5-2011-4.2.1.4018

 

Link snomONE-ctrl to the new executable:

ln -fs /usr/local/snomONE/pbxctrl-centos5-2011-4.2.1.4018 /usr/local/snomONE/snomONE-ctrl

 

Start snom ONE:

/etc/init.d/snomONE start

 

Thank you ;)

Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply

Top Posters In This Topic

Hi,

I have the same problem of all my trunk registrations (7 of them with 2 providers) stopping suddenly.

I tried the Debian link at http://pbxnsip.com/snomone/beta/debian/pbxctrl-debian4.0-2011-4.2.1.4025.

The sip connections seem to be all up, but this is difficult to verify as a significant number of website pages refuse to be returned.

So now I am back at

Version: 	                        4.2.0.3981 (Linux)
Created on: 	                        Jan 28 2011 17:22:18
License Status: 	                pbxnsip Europe - TopIT - Dencad - Office Pro 10 - Upgrade Protection Ends - 31th August 2011
License Duration: 	                Permanent
Additional license information: 	Extensions: 10/10 Accounts: 16/500 Upgrade: 08 31 2011
Working Directory: 	                /root/pbxnsip
MAC Addresses: 	                        00248CC1EEAF
Calls: 	                                0/0 (CDR: 276/282/270) 0/0 Calls
SIP packet statistics: 	                Tx: 618 Rx: 618
Emails: 	                        Successful sent: 9 Unsuccessful attempts: 0
Available file system space: 	        75%
Uptime: 	                        2011/6/29 13:55:54 (uptime: 0 days 00:12:00) (7211 8446912-0) WAV cache: 0
Number of HTTP sessions: 	        Sessions: PAC=0, HTTP=1; Threads: SIP=5, HTTP=1

Any suggestions?

Thanks.

Link to comment
Share on other sites

So that is a dead end for now. Bummer.

I tried another avenue where I have this Python script running in the background. It analyses the log file as it develops and detects when the SIP register messages do not appear any more. The idea is to have the script simulate a 'click' on the link that I normally click manually if I want to restart registrations again (http://<pbx ip address>/dom_trunks.htm?trunkreg=<trunk index>). Unfortunately I am unable to get past the authentication stuff. Would anyone know the right incantation that my script should send to the pbx in order to make it simulate my clicking on this link? The alternative would be to send a text message to my cell phone, but I'd hate to receive those in the middle of the night: most-times the registration process stops when I am fast asleep.

Thanks.

Link to comment
Share on other sites

So that is a dead end for now. Bummer.

 

Not sure why you say so. The issues is fixed in the latest version(.4025).

 

Let me clarify what I was trying to tell -

We have separate binaries for snomONE and pbxnsip. They use different licenses for each one.

So, if you are a pbxnsip Inc customer(i.e., if you own the pbxnsip license) and have not made the transition to snomONE yet, then please use http://www.pbxnsip.com/download-software/software.php to download the binary and try it.

Link to comment
Share on other sites

Well, at the time I wrote that, I had looked for pbxnsip binaries but they were not there yet. They are now. No dead end any more :) .

 

I installed 4025 and it works fine. Thanks. Now let's see how it behaves at the next incident.

 

BTW. I read that the fix is to declare a 408 error on the trunks when the registering stops. I then can receive an e-mail, go into the web interface and click "REGISTER". That's much better than how it was. However, I would prefer to be able to automatically recover from an incident . Right now I am thinking of doing so by automatically "clicking" on the REGISTER link of each trunk. So I am still interested in the incantation to do that with proper authentication : 'http://<pbx ip address>/dom_trunks.htm?trunkreg=<trunk index>' and then some extra stuff. Or something similar.

Link to comment
Share on other sites

The way it works now is, PBX does a DNS query on trunk's "Proxy Address" before sending the REGISTER message to the provider. This happens only first time. Then PBX keeps this address for the future REGISTER messages (i.e., it will not perform DNS query before every REGISTER request). If the provider does not respond on that address, then PBX puts that trunks as unregistered (408 Request Timeout) and keeps retrying every 60 seconds or so.

 

So you really don't need to do "http://<pbx ip address>/dom_trunks.htm?trunkreg=<trunk index>" using a program. You will have to intervene only if the provider changes the IP address for the DNS name.

 

Note that if you use IP address in the "Proxy Address" field, then there is no issue at all.

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...

The way it works now is, PBX does a DNS query on trunk's "Proxy Address" before sending the REGISTER message to the provider. This happens only first time. Then PBX keeps this address for the future REGISTER messages (i.e., it will not perform DNS query before every REGISTER request). If the provider does not respond on that address, then PBX puts that trunks as unregistered (408 Request Timeout) and keeps retrying every 60 seconds or so.

 

So you really don't need to do "http://<pbx ip address>/dom_trunks.htm?trunkreg=<trunk index>" using a program. You will have to intervene only if the provider changes the IP address for the DNS name.

 

Note that if you use IP address in the "Proxy Address" field, then there is no issue at all.

Apparently one of our providers (Callcentric) does change IP addresses, because every couple of months or so that trunk gets stuck in a "408 Timeout" that doesn't clear until I click the "Register" button again. The trunk with our other provider doesn't have this problem.

 

Is there any way to have the DNS lookup occur automatically after a 408 Timeout, but not for the regularly scheduled register events?

Link to comment
Share on other sites

  • 4 months later...

Hi,

I still have the re-registration problem in the 2011-4.3.0.5021 (Linux) version on CentOS.

 

Today I'll try changing the IP address in the "Proxy Address" field, but it's not true that from version .4025 the bug is fixed.

 

 

Does anyone have any other solution/fix?

 

I don't know about the Beta but I have customers on 5021 and if the internet goes out at one of my customers, then comes back some time later, the trunk stays 408 until someone manually clicks the register button. The worst part is I don't get an email in this instance because the PBX also thinks the email has been sent. I will disconnect my company PBX from the network tonight (It has the new Beta) for 15 minutes and see if it reconnects after I connect it back to the network.

Link to comment
Share on other sites

I did not read all the posts concerning this issue but I have a possible solution.

 

I had a similar type of trouble with another type of phone system.

 

Try changing the DNS Address in the computer running Snom Software from "Use the following DNS Addresses" in Windows (ex. 192.168.1.1) to a Public DNS Server address like 8.8.8.8 (Google DNS).

 

Or where ever the equivalent is in Linux.

 

Once I did that I no longer had any trouble with Callcentric.

Link to comment
Share on other sites

Very strange! If you set the log level to 8 (or 9) and turn on "Log trunk events:" on the PBX, you should see something like this (this was a simulated case by pulling the Ethernet cable from the system.

 

[8] 20120222133617: Trunk 8: Preparing for re-registration

[8] 20120222133617: Trunk mac-reg: Sending registration to 10.20.14.195

[8] 20120222133618: Trunk 8: setup callback to send re-registration after 180 seconds

----------- Trunk was registered at this moment ---------------------

 

------------ Cable is unplugged here -------------------------------

 

 

[8] 20120222133917: Trunk 8: Preparing for re-registration

[8] 20120222133917: Trunk mac-reg: Sending registration to 10.20.14.195

[5] 20120222133949: Registration on trunk 8 (mac-reg) failed. Retry in 60 seconds

[2] 20120222133949: Trunk status mac-reg (8) changed to "408 Request Timeout" (Registration failed, retry after 60 secon

ds)

------------------ failed registration ----------------------------

 

[8] 20120222134049: Trunk 8: Preparing for re-registration

[8] 20120222134049: Trunk 8: sending discover message for pbxmacmini.com

[8] 20120222134049: Trunk 8 (mac-reg) is associated with the following addresses: udp:10.20.14.195:5060

[8] 20120222134049: Trunk mac-reg: Sending registration to 10.20.14.195

[5] 20120222134121: Registration on trunk 8 (mac-reg) failed. Retry in 60 seconds

 

------------------ Failed again ------------------------------

 

[8] 20120222134221: Trunk 8: Preparing for re-registration

[8] 20120222134221: Trunk 8: sending discover message for pbxmacmini.com

[8] 20120222134221: Trunk 8 (mac-reg) is associated with the following addresses: udp:10.20.14.195:5060

[8] 20120222134221: Trunk mac-reg: Sending registration to 10.20.14.195

 

--------------------- Plug the cable back in ------------------

[8] 20120222134242: Trunk 8: setup callback to send re-registration after 179 seconds

[2] 20120222134242: Trunk status mac-reg (8) changed to "200 Ok" (Refresh interval 179 seconds)

 

----------------- got the response back and state is good again -----------

 

This test was done on 4.3.0.5021.

 

So could you please get us similar trunk log from this customer to see if there is something else going on?. PBX should not give up trying to register at every 60 seconds when the internet is down.

Link to comment
Share on other sites

Very strange! If you set the log level to 8 (or 9) and turn on "Log trunk events:" on the PBX, you should see something like this (this was a simulated case by pulling the Ethernet cable from the system.

 

[8] 20120222133617: Trunk 8: Preparing for re-registration

[8] 20120222133617: Trunk mac-reg: Sending registration to 10.20.14.195

[8] 20120222133618: Trunk 8: setup callback to send re-registration after 180 seconds

----------- Trunk was registered at this moment ---------------------

 

------------ Cable is unplugged here -------------------------------

 

 

[8] 20120222133917: Trunk 8: Preparing for re-registration

[8] 20120222133917: Trunk mac-reg: Sending registration to 10.20.14.195

[5] 20120222133949: Registration on trunk 8 (mac-reg) failed. Retry in 60 seconds

[2] 20120222133949: Trunk status mac-reg (8) changed to "408 Request Timeout" (Registration failed, retry after 60 secon

ds)

------------------ failed registration ----------------------------

 

[8] 20120222134049: Trunk 8: Preparing for re-registration

[8] 20120222134049: Trunk 8: sending discover message for pbxmacmini.com

[8] 20120222134049: Trunk 8 (mac-reg) is associated with the following addresses: udp:10.20.14.195:5060

[8] 20120222134049: Trunk mac-reg: Sending registration to 10.20.14.195

[5] 20120222134121: Registration on trunk 8 (mac-reg) failed. Retry in 60 seconds

 

------------------ Failed again ------------------------------

 

[8] 20120222134221: Trunk 8: Preparing for re-registration

[8] 20120222134221: Trunk 8: sending discover message for pbxmacmini.com

[8] 20120222134221: Trunk 8 (mac-reg) is associated with the following addresses: udp:10.20.14.195:5060

[8] 20120222134221: Trunk mac-reg: Sending registration to 10.20.14.195

 

--------------------- Plug the cable back in ------------------

[8] 20120222134242: Trunk 8: setup callback to send re-registration after 179 seconds

[2] 20120222134242: Trunk status mac-reg (8) changed to "200 Ok" (Refresh interval 179 seconds)

 

----------------- got the response back and state is good again -----------

 

This test was done on 4.3.0.5021.

 

So could you please get us similar trunk log from this customer to see if there is something else going on?. PBX should not give up trying to register at every 60 seconds when the internet is down.

 

If I get to it before they reset it next time I will try that. The DNS issue Bill H came up with may be the problem as this customer has had numerous times where the cable company's DNS servers could not resolve certain websites. I assume I can syslog the PBX logfile to one of my linux boxes at my office, is that correct?

Link to comment
Share on other sites

If I get to it before they reset it next time I will try that. The DNS issue Bill H came up with may be the problem as this customer has had numerous times where the cable company's DNS servers could not resolve certain websites. I assume I can syslog the PBX logfile to one of my linux boxes at my office, is that correct?

 

Well, the same PBX that has given me problems before, lost a part (Port 5060) of its internet connection yesterday. Happily, after 6 hours, when the internet connection was restored in full everything re-registered without any manual intervention. Version 5021.

Link to comment
Share on other sites

I have already tried to change the primary DNS server with an external one (OpenDNS 208.67.222.222), but i still had the problem. Tomorrow i'll try changing it into 8.8.8.8, but it's the same.

 

 

Now I think I have partially solved: i have changed in the trunk setup the DNS name of the Proxy (voip.eutelia.it) into the IP address (83.211.227.21); now if i do the previous test unplugging and then plugging the LAN cable after a few minutes, it works, re-registering correctly.

 

It's clear that if the voip provider changes the IP, I'll have a big problem...

 

Any other idea?

 

Thanks

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...