Inbound calls are working, but why?

[limewater]

I installed FusionPBX on Digital Ocean using Debian, as recommended. I setup two extensions, with two destinations, per the manual. I installed an origination gateway, and a termination gateway. Outbound calls work, but inbound do not.

I did some investigating on this forum and found another user with a similar problem. He mad a change and said his inbound worked after the change. I made the same change, and now my inbound works, but I don't understand why it now works, nor why if it is correct, why it wasn't setup this way to begin with when I created the destinations.

The automatically populated data in question was <TYPE "destination_number"> and <DATA ^(984241XXXX)$> for the first line of instructions in the dial plan, and it does not work. I changed the DATA to this: 100. The 100 is the phone's extension number, and now it works. I use a the appropriate extension number for each phone line and they both now work, but I don't understand why they work. Is there a bug in the system, and the dial plan is not being generated correctly, or what?

Thanks in advance for any insight.

 

[Adrian Fretwell]

Not exactly sure what you have done, a screenshot would help.

My guess is that it is now working because the inbound number you are calling has a "100" string in it somewhere.

The DATA part is looking for a regular expression so 100 will match any string of digits with a 100 in it. You should specify exactly the inbound number anchoring it to the beginning of the line with the ^ and to the end of the line with the $. The brackets just form a capturing group so you can use the captured digits in the variable $1 if required.

If you are wanting to route a DDI range to a range of extensions you can use the xxx wildcard syntax. for example if you had inbound numbers 01159876600 to 01159876699 you could specify your destination as 011598766(xx) and then route to extensions 200 to 299 with an action transfer statement like:
transfer:2$1 XML sip.a2es.uk

I hope that makes sense.

 

[limewater]

Adrian,

Thank you for being willing to help.

The inbound destination was generated automatically as: ^(xxxxxxxxxx)$ when I created the destination, and it did not work. It was only when I changed the destination to the extension number that it worked. By the way 100 is not in the number. This is a work around that another user discovered. I just copied his work around.

 

[Adrian Fretwell]

Share a link to the work around you found, I'm interested...

 

[limewater]

Happy to send you a copy of the dial plan in question. I hope it helps. I would really like to know why this is happening.

 

[Adrian Fretwell]

Your condition statement is testing for the existence of "100" occurring somewhere in the destination number. This is definitely wrong if the inbound route is taking calls from the public switched telephone network.

You say your destination number does not contain "100", if this is the case, then it does not make sense. Do you have any other inbound routes in place?