Dialing Plan

hope · Post by **hope** » Mon Oct 04, 2010 12:51 pm

matching
$request=^INVITE
$addr = !(123\.456\.78.*|89\.10\.112.*)

deploy
$action = 603

noiptel · Post by **noiptel** » Mon Oct 11, 2010 8:51 am

Thanks Hope, it worked perfectly, (I only have to remove the "*" from the address line) .

One more question: How can we manipulate the SIP code we sent back to callers on failed calls ? For Instance after all failover options fail in our dialing plan we currently send SIP/404, Which is what we receive from the other BREKEKE SIP server. We would like to send 503 instead.

MATCHING
$request=^INVITE
$geturi(To)=sip:2315(52319.+)@(.+)

DEPLOY
$auth=false
$request=INVITE sip:0700%1@<Production_IP> SIP/2.0
$target = <Production_IP>
$session=plugin.failover sip:<Production_IP> sip:<Production_IP>
$continue=false

Harold · Post by **Harold** » Mon Oct 11, 2010 12:44 pm

>> we currently send SIP/404, Which is what we receive from the other BREKEKE SIP server.

send 503 from the other BREKEKE SIP server.

noiptel · Post by **noiptel** » Mon Oct 11, 2010 5:01 pm

How do you set production Brekeke SIP Server to send SIP/503 to new Brekeke SIP server?

Harold · Post by **Harold** » Tue Oct 12, 2010 10:43 am

Add new DialPlan rule with appropriate Matching Patterns and the following Deploy Pattern in your production SIP Server.
$response = 503

noiptel · Post by **noiptel** » Mon Oct 25, 2010 8:07 am

It must be set on this server, because It is complicated for us to do it on the production BREKEKE with the load balance and RADIUS accounting running on it.

Is there a way with the plan above to set one rule after with $response=503 ? I guess we will have to remove the "continue=false"

lakeview · Post by **lakeview** » Mon Oct 25, 2010 9:13 am

The "$continue=false" doesn't work because the response code (503) has been decided...

Why do you need to place rules after that??
You can define rules before that..

noiptel · Post by **noiptel** » Mon Oct 25, 2010 12:21 pm

Because we try every call at least 6 times (using failover) before we reject the call back to our customers. The problem is our customers require we reject failed calls with 503 not 404 as both of our BREKEKE do.

hope · Post by **hope** » Mon Oct 25, 2010 1:07 pm

at the failover dial plan deploy pattern add one more sip id as
$session=failover sip:1@<production_IP> sip:2@<production_IP> sip:3@<current_server_IP>

then add another dial plan on current server and put on top of all other dial plans
matching
$request=^INVITE
To = sip:3@

deploy:
$response = 503

noiptel · Post by **noiptel** » Tue Oct 26, 2010 11:09 am

That was clever and it works fine. I used the rule below to reject the call.

MATCHING
$request=^INVITE
$addr=<current_server_IP>

DEPLOY
$action=503
$continue=false

Thanks for your help.

noiptel · Post by **noiptel** » Tue Nov 02, 2010 10:56 am

After putting live calls on the new BSS, I am having an issue in which many calls are showing as ACCEPTED in the Active status page of the production BSS, Unfortunately this issue does not happen all the time and many calls are released normally.

One thing I noticed, and I think is related to this problem, is that the failover seems to try the next call attempt too fast. I noticed when I place a test call first saw normal flow (->INVITE, <-(100) TRYING,<-(183) SESSION PROGRESS) then after 20 seconds of ring no answer it sends (-> CANCEL) Then it tries the same call again and repeats the process until the last failover option is exhausted.

I verified the ringing timeout and is set to 240000 ms, also tried to set "&failover.timer.provisional=60" in the deploy pattern with same results

Why is the failover advancing to the next hop after 20 seconds even when call is ringing ?
Is it possible to increase this timeout ?

hope · Post by **hope** » Tue Nov 02, 2010 1:38 pm

active session show "accepted" when brekeke receive 200 ok for the invite but didnot receive ACK, so it is not showing talking
capture packets at caller and brekeke to check if there is 200 ok received by caller and send ACK to brekeke. and if caller contact in the invite is correct and reachable.

for the ringer time in failover
did you click "apply rule" button after adding &failover.timer.provisional=60 in dial plan?
http://wiki.brekeke.com/wiki/How-to-mak ... -Dial-Plan

noiptel · Post by **noiptel** » Wed Nov 03, 2010 2:02 pm

In normal conditions yes, I verified the new BSS (caller) sends ACK after the 200 OK from the Production BSS (where the accepted issue is showing)
What I think is happening is sometimes the 200 OK arrives after the CANCEL message, hence not ACK is sent by the new BSS.

I really have to solve the 20 seconds failover ringer timer, this should solve the above issue

I did apply rules after adding "&failover.timer.provisional=60"

hope · Post by **hope** » Wed Nov 03, 2010 2:54 pm

is the dial plan with failover provision setting used for the call?
is there response sent back from callee at the time failover happen?
if there is error response, the failover will happen without ringing destination 60 seconds.
what dial plans are there on you server?

taitan · Post by **taitan** » Wed Nov 03, 2010 3:09 pm

Are you using Advanced Edition of Brekeke SIP Server?
If not, the Failover setting doesn't effect.

noiptel · Post by **noiptel** » Wed Nov 03, 2010 3:49 pm

Thanks for your responses.

We currently have Version 2.4.7.0 Advanced

I am hitting this rule, verified in the Active Sessions Page, I just deleted other dialing related rules to be sure, and got the same results after testing.

No other response is sent or received after the 183 (Session Progress with SDP) for about 20 seconds (ringback) after that time BSS sends CANCEL, ACK and a new INVITE with the next hop of the failover list.

taitan · Post by **taitan** » Thu Nov 04, 2010 10:36 am

noiptel,

Are you sure that the BSS generated CANCEL by itself after 20sec?
I mean.. does the caller not send this CANCEL originally?

If you capture packet in middle of the caller and the BSS, you can check whether the caller sends the CANCEL...

taitan · Post by **taitan** » Thu Nov 04, 2010 10:40 am

where did you set "&failover.timer.provisional=60"??

Paste the DialPlan rule here..

noiptel · Post by **noiptel** » Thu Nov 04, 2010 12:35 pm

I am running Wireshark in the same server we are trying to implement, so I can catch messages to/from caller and to/from production BSS.

One thing I noted is there is not exactly 20 seconds after the 183 Progress, it varies down to 15 seconds, what it looks like is there are always 30 seconds between the 100 Trying received from the Production Brekeke and the CANCEL sent from this BSS.

Here is the rule:

MATCHING
$request=^INVITE
$geturi(To)=sip:2315(52319.+)@(.+)

DEPLOY
$auth=false
$request=INVITE sip:0700%1@<Production_IP> SIP/2.0
$target = <Production_IP>
$session=plugin.failover sip:<Production_IP> sip:<Production_IP> sip:<This Server_IP>
&failover.timer.provisional=60
$continue=false

taitan · Post by **taitan** » Fri Nov 05, 2010 10:32 am

Try this:

MATCHING
$request = ^INVITE
To = sip:2315(52319.+)@

DEPLOY
$auth = false
To = sip:0700%1@<Production_IP>
$session = plugin.failover sip:<Production_IP> sip:<Production_IP> sip:<This Server_IP>
&failover.timer.provisional = 60
&failover.timer.inviting = 60
$continue = false

noiptel · Post by **noiptel** » Mon Nov 08, 2010 3:51 pm

Tried, but got the same results and times.

taitan · Post by **taitan** » Mon Nov 08, 2010 5:40 pm

Who is the caller?
Are you using Brekeke PBX?

Also try the following.
Set "failover.timer.provisional = 60" at [Configuration] > [Advanced] page.

noiptel · Post by **noiptel** » Tue Nov 09, 2010 4:12 pm

Test calls are originated from a softswitch within the same network, but just tin case, I just tried the call from a SIP phone registered in this BREKEKE SIP server and got the same results.

Added both variables as instructed in the advanced configs, saved and restarted SIP server and got the same results.

BSS sends a CANCEL and tries the next hop in the failover list, unless the callee answers before 20 seconds and a 200 OK is received.

noiptel · Post by **noiptel** » Wed Nov 10, 2010 10:55 am

I have removed the word "plugin" from the session line in the rule and it stopped doing the CANCEL thing, but failover was not advancing to next hop when SIP response 404 was received, so I added one extra line for those cases and seems to be working so far. Here is the final rule:

MATCHING
$request=^INVITE
$geturi(To)=sip:2315(52319.+)@(.+)

DEPLOY
$auth=false
$request=INVITE sip:0700%1@<Production_IP> SIP/2.0
$target = <Production_IP>
$session=failover sip:<Production_IP> sip:<Production_IP> sip:<This Server_IP>
&failover.pattern.response=404|603|503
$continue=false

taitan · Post by **taitan** » Thu Nov 11, 2010 11:34 am

It seems you solved the issue.. Right?

The latest version of Failover plug-in doesn't need the prefix "plugin".
From your post, I suppose you are using the latest one.

http://wiki.brekeke.com/wiki/How-to-mak ... -Dial-Plan