Dialing Plan

1. Brekeke Product Name and version:

2. Java version:

3. OS type and the version:

4. UA (phone), gateway or other hardware/software involved:

5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :

6. Your problem:
We currently have an advance edition Brekeke in production. We have added a second server with also a Brekeke SIP server as we would like to use this new SIP Server to receive our Customers wholesale traffic and then send it to our current SIP server in production.

I have put together the below dialing plan for the new SIP server, can you please verify that it will work?

MATCHING
$request=^INVITE
$addr=^8\.20\.232\.[1-10]$ (this is the Customer IP address)

DEPLOY
$auth=false
To=sip:64.192.197.76 (this is the Brekeke in production address)
$continue=false

Please confirm if dialplan will work and if we will need to do any other adjustment to the SIP Servers.

Thanks once again.

At new sip server the dial plan is like
MATCHING
$request=^INVITE
$addr=^8\.20\.232\.[1-10]$ (this is the Customer IP address)

DEPLOY
$auth=false
$target=64.192.197.76 (this is the Brekeke in production address)


At production server, create dial plan to accept/route the call from new sip sever

We have decided to add a 4 digit prefix to each call based on the route code (area code). The below rule is for code 52432 and we would like to add prefix 0200 before sending call to production brekeke. Please review below rule and please make appropriate changes.


MATCHING
$request=^INVITE
$addr=^8\.20\.232\.[1-10]$
$request=sip(52432.+)@

DEPLOY
$auth=false
To=sip:0200@64.192.197.76

Thanking you in advance.

MATCHING
$request=^INVITE
$addr=^8\.20\.232\.[1-10]$
To=sip:(52432.+)@

DEPLOY
$auth=false
To=sip:0200%1@64.192.197.76

if there are many different prefix need to add for different area codes,
you can use alias function for advanced sip server
http://wiki.brekeke.com/wiki/How-to-use-Alias-function

Thank you.

What does the%1represent?

To=sip:0300%1@64.192.197.76

%1 refers to 52432.+ in matching patterns
http://wiki.brekeke.com/wiki/buffer-in-the-dial-plan
and there are dial plan explanation at admin guide and dial plan tutorial at
http://www.brekeke.com/download/download_sip_doc_en.php

Calls are completing.

Howerver, we need for the Customer prefix to be also sent to the Production Brekeke. With the below rules will the Customer prefix be passed on to the Production Brekeke?

MATCHING
$request=^INVITE
$addr=^123\.456\.789\.[1-10]$ (Customer IP adress)

DEPLOY
$request=sip:1234(52235.+)@ $auth=false (Production Brekeke Address)
To=sip:1800%1@987.654.321.00

MATCHING
$request=^INVITE
$addr=^123\.456\.789\.[1-10]$
To=sip:1234(52235.+)@

DEPLOY
$auth=false
To=sip:1800%1@<Production_IP>

with above dial plan, if get an incoming call from source ip 123.456.789.1 with dialing number like 1234522351111, the number will be changed to 1800522351111

is it what you need?

Thank you for the correction in the dialing plan.

Is there a way for both Customer prefix (1234) as well as Route prefix (1800) to be passed to the Production BREKEKE? Production BREKEKE account plug-in needs Customer prefix for billing.

change matching patterns like
MATCHING
$request=^INVITE
$addr=^123\.456\.789\.[1-10]$
To=sip:(123452235.+)@

at To=, move left bracket to include 1234

Then if call to 1234522351111 then production brekeke get it like 18001234500351111

Thanks for your reply, but it did no work, after further investigation it looks what we need is to have different prefixes in the REQUEST and TO fields of the same SIP messages, I did a trace on the call of our softswitch (the one we want to replace with BREKEKE) and this is what it shows on these fields, We need this feature for billing purposes.

Request-Line:
INVITE sip:0700523191234567@198.192.197.76 SIP/2.0
Message Header:
To: <sip:2315523191234567@198.192.197.77>

Note the switch is replacing the incoming prefix 2315 from the originating IP 198.192.197.77 and sending the call to IP 198.192.197.76 with prefix 0700

at the dial plan used for the call, change/add the following part to change the request header, and the old %n in deploy patterns also needs to change

MATCHING
$request=(INVITE )sip:0700(523191234567)(@.+)
To=sip:(2315523191234567)@

DEPLOY
$auth=false
$request=%1sip:18002315%2%3
To=sip:1800%4@<Production_IP>

change 0700 in request line to18002315 and add 1800 to dialing number 2315523191234567

Thanks again for your quick reply, but it is not working yet, not matter what I set $REQUEST, it always shows the same as the TO set in the DEPLOY pattern, after trying your suggestion I tried this and did not work either.

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

***DEPLOY***
$auth=false
$request=sip:2315@198.192.197.76:5106
To=sip:0700@198.192.197.76:5106

Remember we are trying to change prefix 2315 with 0700 (keeping 2315 in the TO field) the user dialed number is for example: 523191001234.

Appreciate any help you can give.

how about this one

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

DEPLOY
$auth=false
$request=%1%2
To=sip:0700%3@<Production_IP>

click apply rules button after changing dial plan

with above dial plan, if there is a call to number 2315523191001234,
brekeke will send inivte to production server with
request header as "INVITE sip:2315523191001234@<same as original request header>"
and To header is changed to sip:0700523191001234@production_IP

With that rule call completes, however TO and REQUEST headers are still the same. I am starting to thing the "$request=%1%2" command in the deploy side has no effect. I also noted in dial plan "View Rules" tab, that "$request" dos not show blue as the other variables. Could this has to do with the SIP SERVER version we have ? We still have the evaluation version on this server.

is correct dial plan used for the call?
you can check rule field in call details from "active session" tab.
and you need to click "Apply rules" button after changing dial plan.

Yes, I applied dialing plan rules and verified in the "Active Sessions Detail" it is hitting the rule in question.
Thanks

noiptel,
which version of SIP server are you using?
can you paste all of your DialPlan rules here??

After upgrading to the last version 2.4.7.0 and using the proposed dialing plan we now have different TO and REQUEST headers, however it is reverse at what we want to accomplish, we would like the TO field to maintain the original caller header (original prefix and IP) while the REQUEST have the called header information (production IP and prefix) I tried just reversing the fields, but the call is not routed to the proper IP. Is there any way to do that? Perhaps routing the call using $target instead of TO. Here is the current dialing plan:

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

DEPLOY
$auth=false
$request=%1%2
To=sip:0700%3@<Production_IP>
$continue=false

Appreciate your responses

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

DEPLOY
$auth=false
$request=INVITE sip:0700%1@<Production_IP> SIP/2.0
$target = %2

the call is sent to the ip address in the To header from caller

Thanks Hope, but I think the IP address in the TO header from the caller is my own IP, we want to route the call to a second BREKEKE ( <Production_ip> on this example) keeping the TO header as sent by the caller. Keep in mind my second BREKEKE is matching by $REQUEST so the TO header will not affect the call.

we want to route the call to a second BREKEKE ( <Production_ip> on this example)

then change $target = <production_IP>

Thank you Hope, it is now working as intented.

A few additional questions regarding the dialing:

1. We want to create a rule that will only allow sessions from IP segment 123.12.12.1 - 123.12.12.30. We tried using $addr=^123\.12\.12\.[1-30]$ but sessions from other IP's were not being rejected.

2. How to set up session timeout. We want to be able to set session time out value for each session attempt.

3. How to limit the maximum session duration? We would like to limit all session to not more than 240 minutes.

4. If a session those not complete for any reason we would like to reject session with SIP codec 503.

Thanking you in advance.

1. reject call from other ips
create another dialplan and put it under the dialplan accept call from wanted IPs
dialplan
matching
$request=^INVITE

deploy
$action = 603

2. How to set up session timeout.
the following parameter will set invite timeout as 10 seconds
&net.sip.timeout.inviting = 10000

3. How to limit the maximum session duration?
at configuration / sip/ talking timeout

4.reject session with SIP codec 503.
maybe you can use http://wiki.brekeke.com/wiki/How-to-mak ... -Dial-Plan

Thanks Hope, could you please post the rule to reject calls from undesired IP's ? For instance reject IP's NOT 123.456.78.xx and NOT 89.10.112.xx.

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

deploy
$action = 603

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

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


send 503 from the other BREKEKE SIP server.

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

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

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"

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

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.

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

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.

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 ?

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

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"

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?

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

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.

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

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

Paste the DialPlan rule here..

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

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

Tried, but got the same results and times.

Who is the caller?
Are you using Brekeke PBX?


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

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.

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

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

Yes, this resolved the issue. We have not seen calls in ACCEPTED state any more.

Thanks to all for your help.

Im glad to know you solved the issue.

I suppose you were using old version of Failover plug-in... it might be the cause of the issue..

I am still having a minor issue to properly get CDRs from this server, for some reason the server does not show the complete dilaed number in the "to:" field in either in the log or the active sessions page, it only shows this: "sip:<This Server_IP>:5060", this does not happen all the time, but on the 80% of the calls.

Interesting is that the proxy server (downstream) properly shows the dialed number for all calls.

The current dialing plan is:
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:<ProxyServer_IP> sip:<ProxyServer_IP> sip:<This Server_IP>
&failover.pattern.response=404|603|503
&failover.timer.provisional=60
$continue=false

How could we correct this problem ?

It seems you don't have any "To" definition in the Deploy Pattern.
You need it if you want to have To-URI in the CDR.

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

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

I recommend you get some advices from Brekeke or its integrator ..