[asterisk-dev] DTMF-initiated transfers

[Örn Arnarson]

I think this is an excellent suggestion; I have often thought it more
convenient to be able to mark certain users as DTMF transfer-type users. I
also think it is, as you say, necessary to keep the tT functionality there
still, for in some cases you might be doing something special.

Regards,
Örn

On Wed, Nov 25, 2009 at 7:54 PM, Benny Amorsen
<benny+usenet at amorsen.dk<benny%2Busenet at amorsen.dk>
> wrote:

> One of the really ancient features of Asterisk is that you can do
> transfers with DTMF -- as long as t or T is set in Dial() or Queue() as
> appropriate. Quite nice, as far as it goes. However, this model doesn't
> really fit usage at IP Vision, and the impedance mismatch is getting worse.
>
> Our customers have 3 different kinds of needs:
>
> 1) SIP phones, where DTMF-initiated transfers should not be allowed
> (those phones have perfectly good buttons, no need to fake it)
>
> 2) Mobile phones and some DECT phones where DTMF-initiated transfers are
> necessary, because they can't do something smarter.
>
> 3) Outgoing lines where t or T must never be set.
>
> Right now we're detecting whether the caller is type 1, 2 or 3 and
> setting T as appropriate, and then doing the same for the callee. This
> is quite a bit of code (involving fun with Local channels), and it still
> breaks in this case:
>
> If a Pickup is done using the *8 feature, the phone who did the pickup
> will be able to transfer the call using DTMF if the ringing phone
> happened to be a mobile phone (which is wrong if the phone doing the
> Pickup is a SIP phone), and the opposite problem happens if a mobile
> phone does a Pickup from a ringing SIP phone.
>
> This would be a lot easier if the tT options were replaced with an
> option linked to the SIP peer/user: allowdtmftransfer=yes/no. Better
> names for the option are more than welcome, of course. We could set
> allowdtmftransfer=no for peers connecting to the outside and as long as
> we made sure to never use tT option (could be checked statically), we'd
> know that no error in the dial plan could result in outside users being
> able to transfer calls.
>
> For backwards compatibility and for those with more complicated needs,
> the tT options could be kept around.
>
>
> /Benny
>
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20091125/9b66e234/attachment.htm