Jump to content

Dial Plan Woes


Sota Solutions

Recommended Posts

Since upgrading to PBXnSIP v2, we are having problems with dial plans that have worked perfectly and predicatably in PBXnSIP 1.5x

 

For example given the following dialplan which has historically been used for matching UK BT numbers such as 154 and sending them out via PSTN.

 

100 VEGA 1([0-9]{2}) sip:1\1@\r

 

we then have oddities such as 11 digit numbers matching this dial plan entry:

 

[5] 2008/01/07 10:50:31: Dialplan: Match 01632465160@pbx.domain.co.uk to <sip:160@10.1.0.101> on trunk Vega

 

As you can see somehow we end up with the last 3 digits of the number being dialled????

 

Yes this can be got around with a simpler 1xx dial plan, but this is for example purposes, we have similar problems with more complex patterns.

 

Has something changed with pattern matching?

 

Thanks in advance

Tim

Link to comment
Share on other sites

I have now run the same test with 2.1.5 and get the following information in the logs.

 

Dialplan: Evaluating !1([0-9]{2})@.*!sip:1\1@\r!i against 01632465160@pbx.domain.co.uk

Dialplan FFDP: Match 01632465160@pbx.domain.co.uk to <sip:160@10.1.0.101> on trunk Vega

 

The dial plan in PBXnSIP is as follows:

 

Pattern: 1([0-9]{2})@.*

Replacement: sip:1\1@\r

 

Thanks

Link to comment
Share on other sites

ERE are not so simple... That is why we recommend to use the other "simple" forms - if possible. :D

 

To what extend can someone study http://www.opengroup.org/onlinepubs/009695...xbd_chap09.html and use what they learn here? I guess I mean does PBXnSIP truncate the support to a predined subset needed for dial plans, or is the sky is the limit on the use of BRE.

Link to comment
Share on other sites

To what extend can someone study http://www.opengroup.org/onlinepubs/009695...xbd_chap09.html and use what they learn here? I guess I mean does PBXnSIP truncate the support to a predined subset needed for dial plans, or is the sky is the limit on the use of BRE.

 

The whole ERE thing starts at http://www.ietf.org/rfc/rfc2915.txt, which is the base for ENUM. That ERE subset should be pretty complete. But I agree, we need to provide more examples for ERE.

 

There are all kinds of extensions to ERE. Those are not supported...

Link to comment
Share on other sites

Conversely - Can the PBXnSIP Dial Plans be manipulated to strip digits?

 

For Example - Someone wants to dial more than 11 digits in North America - Say a 1-800 number that is spelled out.

 

1-800-PBX-NSIP-FORUM

 

Is there a way to take the pattern of more than 11 digits and replacing them with the 1st 11 digits dialed? Effectively ignoring -FORUM from my example.

 

Thanks

Link to comment
Share on other sites

Conversely - Can the PBXnSIP Dial Plans be manipulated to strip digits?

 

For Example - Someone wants to dial more than 11 digits in North America - Say a 1-800 number that is spelled out.

 

1-800-PBX-NSIP-FORUM

 

Is there a way to take the pattern of more than 11 digits and replacing them with the 1st 11 digits dialed? Effectively ignoring -FORUM from my example.

 

Well, in that case you would match the first 11 digits:

 

Pattern: ([0-9]{11})[0-9]*@.*

Replacement: (left empty)

Or if you want to match the front part as well:

 

Pattern: (1800[0-9]{7})[0-9]*@.*

Replacement: (left empty)

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.

×
×
  • Create New...