[asterisk-dev] DTMF-initiated transfers

Kai Hoerner kai at ciphron.de
Thu Nov 26 11:29:57 CST 2009


Hi,

Olle E. Johansson wrote:
>>>> Backwards compatibility could be a bit
>>>> fun though; the default when not set would have to be
>>>> allow_transfer=refer. 

>>> I do not understand this comment of yours.
>>> Wouldn't the default be allow_transfer=yes (tone&refer)?
>>>
>>> I must be misunderstanding the proposal. I assumed tone 
>>> transfers would be enabled only if the call had tT 
>>> options set and sip.conf had allow_transfer=tone. If 
>>> the default is allow_transfer=yes then tone transfers 
>>> would be controlled by the tT options as currently. 

>> My understanding is that the Dial() options "t" and "T" should simply 
>> override the "allow_transfer=no" (or "=refer") setting with 
>> "allow_transfer=tone" (or "=yes", respectively).
>>
>> This has two benefits over the other way round:
>>
>> 1. compatibility with old dialplans .. tT will work anywhere specified
>> 2. you can still override this setting for special purposes in dialplan.
>>   Example:  When you redirect a call to a mobile phone associated
>>             with an extension of your PBX, you may wish to enable
>>             transfers for that callee, but not for the whole PSTN
>>             trunk.
>>
>> IMHO a setting like "transfer=native,dtmf" makes more sense.
>> (I find "yes" actually meaning "native & dtmf" is very intransparent)

> Well, what do you do if you want to disable all peer configs in the dial() command?
> dial(sip/olle,15,-t) 

Good point.

Wouldn't an option "E" ("E"xample) be sufficient, meaning "ignore per
peer options, give Dial() full control"?
That would also provide some sort of "old behaviour" mode like other
options already do. (like "o" for asterisk 1.0 callerid behaviour)


If effort like this is welcome in asterisk and if someone really starts
implementing this, we should think about those dial options enabling
other "features" too. (example: "w","W" for recording)

Should one be able to force those per device too, then?
I think in terms of consistent behaviour this should be possible, too.




More information about the asterisk-dev mailing list