[asterisk-users] Transfer only, no outbound calling

Todd Routhier fonemasta at gmail.com
Wed Apr 17 22:59:43 CDT 2013


Nathan,

 Yes, SIP.. :-)

I ended up deciding to just not allow attended transfer at all since it
seemed so hard to deal with. If someone really wants attended transfer they
can put the call on hold, dial using the other line then transfer the call
on the other line if they want the call on the other end. Same thing, just
one more step.

I am just going to set a var in sip.conf so when people try to dial out
direct, it will catch it in the dial plan and kill the call. With blind
transfer I can set a var on the way in and it's held onto nicely and I can
allow the transfer based on that.

Again, thanks for your detailed response.



On Tue, Apr 16, 2013 at 9:59 PM, Nathan Anderson <nathana at fsr.com> wrote:

> 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
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130417/33f3c6f4/attachment.htm>


More information about the asterisk-users mailing list