asterisk users - Feb 2014 - Rejecting a call as if the extension does not exist.

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.

-- 
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts,
build a wall, set a bone, comfort the dying, take orders, give orders,
cooperate, act alone, solve equations, analyze a new problem, pitch manure,
program a computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects.
---Heinlein
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140206/6faafb62/attachment.html>

You could have the call immediately return to the transferer

-----Original Message-----
From: John Kiniston <johnkiniston at gmail.com>
Sender: asterisk-users-bounces at lists.digium.comDate: Thu, 6 Feb 2014 17:14:02
To: Asterisk Users Mailing List - Non-Commercial Discussion<asterisk-users at
lists.digium.com>
Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion
 <asterisk-users at lists.digium.com>
Subject: [asterisk-users] Rejecting a call as if the extension does not
	exist.

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
               http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

On Friday 07 February 2014, John Kiniston wrote:
> 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.
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.


-- 
AJS

Answers come *after* questions.