cwernstedt Posted November 16, 2009 Report Share Posted November 16, 2009 We've had a problem with 3.4.0.3201 (running under Mac OS X Leopard) such that a phone may suddenly not be able to register. In the log the following lines are repeated as the phone tries to register. [8] 2009/11/16 14:56:35: Timeout on UDP transport layer (1512382) [5] 2009/11/16 14:56:35: Final transport error on 1512382: REGISTER The pbx's operation in other aspects seem to be OK. Re-starting the machine on which pbxnsip is running resolves the problem. This has happened about two times over a period of three months, so it's not frequent, but causes a good deal of disruption. Quote Link to comment Share on other sites More sharing options...
pbx support Posted November 16, 2009 Report Share Posted November 16, 2009 We've had a problem with 3.4.0.3201 (running under Mac OS X Leopard) such that a phone may suddenly not be able to register. In the log the following lines are repeated as the phone tries to register. [8] 2009/11/16 14:56:35: Timeout on UDP transport layer (1512382) [5] 2009/11/16 14:56:35: Final transport error on 1512382: REGISTER The pbx's operation in other aspects seem to be OK. Re-starting the machine on which pbxnsip is running resolves the problem. This has happened about two times over a period of three months, so it's not frequent, but causes a good deal of disruption. This maybe something to do with the DNS. When the problem happens, can you ping the phone from the PBX? Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 16, 2009 Author Report Share Posted November 16, 2009 This maybe something to do with the DNS. When the problem happens, can you ping the phone from the PBX? A DNS lookup should not be necessary in order to reach the phone. (Or does the pbx generally try to do a DNS lookup when a phone registers?) The phone is on the same network, and it is possible to ping the phone from the PBX. /C Quote Link to comment Share on other sites More sharing options...
pbx support Posted November 19, 2009 Report Share Posted November 19, 2009 A DNS lookup should not be necessary in order to reach the phone. (Or does the pbx generally try to do a DNS lookup when a phone registers?) The phone is on the same network, and it is possible to ping the phone from the PBX. /C Did you try restarting the phone and/or PBX? Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 19, 2009 Author Report Share Posted November 19, 2009 Did you try restarting the phone and/or PBX? Restarting the phone doesn't help, but restarting the PBX (the entire server machine) helps - see my initial message about the subject. I don't know how to only restart the PBX service on a Mac without restarting the machine. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted November 23, 2009 Report Share Posted November 23, 2009 Restarting the phone doesn't help, but restarting the PBX (the entire server machine) helps - see my initial message about the subject. I don't know how to only restart the PBX service on a Mac without restarting the machine. I would use netstat to see what is going on. AFAIK netstat is also available on Mac. There you should see if the PBX still has the UDP socket 5060 open and if there are any unprocessed messages in that socket. Does the Mac have a "personal firewall"? This is usually the source for major problems like there in Windows... Quote Link to comment Share on other sites More sharing options...
pbx support Posted November 23, 2009 Report Share Posted November 23, 2009 I would use netstat to see what is going on. AFAIK netstat is also available on Mac. There you should see if the PBX still has the UDP socket 5060 open and if there are any unprocessed messages in that socket. Does the Mac have a "personal firewall"? This is usually the source for major problems like there in Windows... http://kiwi.pbxnsip.com/index.php/Installi...nd_Starting_PBX Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted November 23, 2009 Author Report Share Posted November 23, 2009 Thanks. I'll check for these things if it happens again. /CW Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted January 13, 2010 Author Report Share Posted January 13, 2010 I just had this problem on a second Mac system, but did not have a chance to capture any info before someone restarted the pbx. It seems to happen extremely rarely (months in between), but it never happened on my Windows based systems. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 14, 2010 Report Share Posted January 14, 2010 I just had this problem on a second Mac system, but did not have a chance to capture any info before someone restarted the pbx. It seems to happen extremely rarely (months in between), but it never happened on my Windows based systems. Well... Maybe the service provider has a small "window"... It is not so unusualy that SIP trunks go down for some time. Logging shows the inconvenient truth! I doubt that it depends on Mac or Windows. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted January 15, 2010 Author Report Share Posted January 15, 2010 Well... Maybe the service provider has a small "window"... It is not so unusualy that SIP trunks go down for some time. Logging shows the inconvenient truth! I doubt that it depends on Mac or Windows. Phones can no longer register to the pbx itself, so it's not a provider issue. Restarting the pbx helps immediately. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 16, 2010 Report Share Posted January 16, 2010 Phones can no longer register to the pbx itself, so it's not a provider issue. Restarting the pbx helps immediately. Okay, seems like we cannot blame the ITSP this time. We are currently investigating if there is a difference between the Windows and Linux abstraction for locking. Seems that Windows works better, and we need to have the same behavior in Linux as well. Let us know if you want to be the ginuea pig and try it out on the MAC. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted January 20, 2010 Author Report Share Posted January 20, 2010 Okay, seems like we cannot blame the ITSP this time. We are currently investigating if there is a difference between the Windows and Linux abstraction for locking. Seems that Windows works better, and we need to have the same behavior in Linux as well. Let us know if you want to be the ginuea pig and try it out on the MAC. I wouldn't mind trying out something that might fix this. Quote Link to comment Share on other sites More sharing options...
pbx support Posted June 2, 2010 Report Share Posted June 2, 2010 I wouldn't mind trying out something that might fix this. We have a new binary for the Mac OS - http://www.pbxnsip.com/download/pbxctrl-darwin9.0-4.0.1.3499 Note that this is just a binary. If you have the previous version installed, then – Copy this binary to wherever it was previously installed perform a “chmod a+x pbxctrl-darwin9.0-4.0.1.3499”. Then restart the PBX service Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.