Jump to content

Registration fails and the log shows "Final transport error"


cwernstedt
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...
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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 months later...
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 –

  1. Copy this binary to wherever it was previously installed
  2. perform a “chmod a+x pbxctrl-darwin9.0-4.0.1.3499”.
  3. Then restart the PBX service

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.

 Share

×
×
  • Create New...