asterisk users - Apr 2013 - Transfer only, no outbound calling

OK, it's been a while since I drank from the pool of wisdom hear on the
list.

After cracking my head against the wall for a few days trying to figure
this out, I have decided to swallow my pride and take the drink.

So, on to my question:

I have some agents/operators setup in sip.conf which point to a context
where I have just about disabled outbound calls (only specific numbers can
be dialed).

The purpose of this is to allow the inbound calls to come in, then if the
operator has a need, they transfer the call to a pre-defined extension
which lives in the limited context defined in sip.conf.

This has worked for some time to restrict outbound calling and where calls
can be transferred to.

Now I would like to open up the numbers the inbound calls can be
transferred to. So, easy enough I thought and I went on my merry way adding
the regular patterns to the context such as NXXNXXXXXX and so on.

Hooray, now the operators can transfer anywhere.

New Problem, now operators can pick up the previous inbound only line and
dial out to anything that matches the patterns I have defined in the
context for their extension in sip.conf.

What I really need to make work here is Attended-Transfer since that is
what is desired by those using the system.

It seems that any variables I try to set on the way in don't carry through
too well during an attended transfer.

Basically, I need the ability to know for sure at the point the call ends
up in the outbound context (defined in sip.conf) if the call is actually a
transfer from an inbound call or if it's a direct dial outbound call with
no incoming call attached. If I can figure out how to know this for sure, I
can just do a GoToIf type of thing in the outbound context that just kills
the call if there is no proof that it's a transfer.

I hope this makes sense, please let me know if more info is needed.

Running Asterisk 1.8.8.0.

A huge thanks in advance to the list for any help with this, it's driving
me batty.

Regards,
 Todd R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130416/7112cfe1/attachment.htm>

On Tuesday, April 16, 2013 6:25 PM, Todd Routhier wrote:
> New Problem, now operators can pick up the previous inbound only line and
> dial out to anything that matches the patterns I have defined in the
> context for their extension in sip.conf.  
> 
> What I really need to make work here is Attended-Transfer since that is
> what is desired by those using the system. 
I'll assume we are talking about SIP extensions here.

What is doing the actual transfer?  Is it Asterisk (res_features /
features.conf), or the phones themselves?

If it is the phones themselves, you're probably out of luck because in an
attended transfer scenario, the transferor has to send a regular ol' INVITE
to the transfer target before sending a REFER to the transferee, and so
there's really no way that Asterisk can know whether that INVITE to the
transfer target is someone in the middle of attempting an attended transfer, or
someone trying to place a regular outbound call.  Your only hope would be to
sniff the SIP traffic between your handsets and Asterisk, and see if there is a
SIP header difference that is detectable between what your phones generate for
an attended transfer vs. an outbound call.  If there is, you can use the
${SIP_HEADER()} function in your dialplan to check for the presence of that
difference in order to determine whether a call is an attended transfer or not.

If you have the option of using Asterisk's built-in attended transfer
feature (features.conf + passing option 't' to the Dial() command that
calls a given extension for an inbound call) instead of a button on your phones,
you can override which context a transfer target's number is executed in by
overriding the global variable TRANSFER_CONTEXT.  So you can create a new stub
context that sets your variable to let you know that this is a transfer and then
jumps to the SIP client's normal context, and set
TRANSFER_CONTEXT=your_new_context under the [globals] section of
extensions.conf.  Check for the presence of your variable in the SIP
client's context, and act accordingly.

Note that in either scenario, as long as you allow attended transfers, the
system can be gamed by people.  For example, assuming that extensions can call
other extensions, someone who wants to make an unsanctioned outbound call simply
walks over to a vacant phone in another cubicle, calls their own
phone/extension, rushes back to answer it, and then initiates an attended
transfer that they never end up completing (they just talk to the person they
initiated the transfer to the whole time).

Hope this helps,

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com