Jump to content

Long Distance Redundancy


djanjic
 Share

Recommended Posts

Hi, few days ago I posted this question on yahoo group. Christian rightly suggested that I should open a topic on this forum since this is of general interest to pbxnsip community. First let me state that we are still running version 1.5.1.6

 

So here it is my original question was:

 

We currently have two LD providers. For some reason when one goes out pbxnsip doesn't route long distance calls to another one. How can we achive the redundancy by sending the calls automaticaly to another provider if our primary provider is down?

 

The response we received was this:

 

Take a look at the outbound settings of the first trunk:

 

http://wiki. pbxnsip.com/ index.php/ Trunk_Settings# Outbound_ Settings

 

Unfortunatelly this doesn't work since in our case we had failover set on all errors and our calls were not sent to secondary provider... Does any one have a magic wand?

 

Dusan

Link to comment
Share on other sites

First let me state that we are still running version 1.5.1.6

 

I would definitevely upgrade to 1.5.2.7 (see http://www.pbxnsip.com/downloads.php). This is a relatively painless upgrade, because all you need is to replace the executable. You can still keep the old executable, and also move back without pain.

 

The whole redundancy thing depends on the error code that is returned. There is a setting for this in the trunk. Did you try that? What error code is being returned?

Link to comment
Share on other sites

  • 3 weeks later...

I am setting up redundancy, however, there are 2 things that are unclear to me (and not documented)

1) There is the following note in the wiki:

"On all error codes. In this case, all error codes will trigger the failover process. Note that also call redirect will be treated as a error code, as the redirection destination can easily be abused to route calls though expensive routes."

--> What does this mean "in practice"? Does this mean that it will be impossible to forward and/or transfer a call?

 

2) What is the undocumented "Request Timeout:". I'm guessing this is how long the server will try the trunk before unconditionally giving up.

 

Jan Forcier

Link to comment
Share on other sites

--> What does this mean "in practice"? Does this mean that it will be impossible to forward and/or transfer a call?

 

SIP has different error classes. If I read it right, the standard says that 4xx class codes should tell the PBX not to try again. For example, 486 means that the user is busy, and also trying another route will not change that fact.

 

In a perfect world, a gateway sends a 5xx class response to tell that the gateway is busy. The problem is that some implementations send 486 if the gateway is busy. In this case it does make sense to try another trunk. That is the reason why we added the setting for the error response class.

 

What is the undocumented "Request Timeout:". I'm guessing this is how long the server will try the trunk before unconditionally giving up.

 

According to SIP, the request timeout should be in the 30 s area. However, if the Internet is down you don't want to wait so long. That is why the request timeout can explicitly specified for a trunk.

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