Rejecting A Call As If The Extension Does Not Exist.

Home » Asterisk Users » Rejecting A Call As If The Extension Does Not Exist.
Asterisk Users 3 Comments

I’m trying to address a problem with users transferring to invalid destinations.

In my sip peer I’m setting both __FORWARD_CONTEXT and __TRANSFER_CONTEXT to a context with a extension defined below to set some CDR variables before the call is transferred.

[customer-forward]
exten => _X.,1,Progress()
exten => _X.,n,Gosub(do-billing,s,1${EXTEN}))
exten => _X,n,Goto(customer-internal,${EXTEN},1)

Now if my user Dials an invalid extension, Say ‘9595’ from their sip phone they get back an ‘Address Incomplete’ message from their phone because it’s not a valid extension defined in my dialplan.

If my user Transfers a call to ‘9595’ the call gets transferred and then hung up on as there’s no ‘9595’ destination.

I’d like to reject the calls in my customer-foward context that do not exist in my customer-internal context.

I’ve tried doing something like:

exten => _X.,1,Progress()
same => n,ExecIf($[${DIALPLAN_EXISTS(customer-internal,${EXTEN},1)} 0]?Hangup(28))

But that’s still accepting the call as the _X makes it a Valid extension.

I’m looking for suggestions or ideas on a better way to do this.

3 thoughts on - Rejecting A Call As If The Extension Does Not Exist.

  • You are suffering from classic Namespace Pollution.

    You need to put the extensions for which you are testing into their own separate context, e.g. “customer-realexts”; and include -that- context into your customer-internal context. That way, your DIALPLAN_EXISTS() function call won’t see the _X. (which necessarily must be in customer-internal) to match against.

  • My customer-internal context doesn’t have a _X. in it actually, only the customer-fwd context does.

    customer-internal contains a bunch of includes for internal extensions and for routes for long-distance,local, toll calls etc.

    It’s only the forward that has and needs the wildcard match as I need the billing code in that context to be executed before the call goes into the customer-internal context.

    I suppose I could replace the _X. with a bunch of NXXX rules in customer-forward but it seems needlessly complex to do so there as customer-internal already controls what can be dialed/forwarded/transferred to by the customer.