[Asterisk-Dev] Extension of transfer functionality in app_dial.c

[John Todd]

I humbly suggest this idea to someone who has more experience and 
time than I do.

The Dial program is woefully inadequate for certain tasks, as many of 
you with service-based installations I'm sure are aware.  What is 
lacking is the ability to _do_ things with channels that are 
currently active.  I will dispense with a full description of how 
app_dial needs an overhaul; that is too long an issue for me to 
adequately document at this time of the morning.  In the interim, 
some type of slightly better key event capture would be very welcome 
as an expansion of app_dial.c.

My proposal would be to modify Dial and extend the number of 
modifiers to allow for more flexible with interruptions.  Currently, 
only the # feature will break out of a call (options T and t, 
depending on what leg you want to listen to) at which point the word 
"transfer" is played back.  The call leg is then forwarded to the 
extension given in the current context.  This is fairly limited, to 
say the least.

I'd like to suggest a slightly different set of options, expanding 
this functionality somewhat:

  1) Mode 1: pressing any key, and not just #, could be used as a 
possible match for an interruption and transfer (I and i, for 
"i"ntercept, as dial modifiers and Rasta reference, mon?) and pass 
context control to a context given as an optional variable in 
parentheses.  All keystrokes would be captured and not relayed to the 
remote leg.

Example:

    [foo]
    exten => 1234,1,Dial(SIP/999,50,I(call-features))
    [call-features]
    exten => _98X,1,Playback(laugh-while-you-can)
    exten => _98X,2,AGI(make-outgoing-call,${PARKEDCALL},somewhere-else)
    exten => _98X,3,Hangup

Pressing 9 would result in no noticeable change in the call, but the 
keypress would NOT be passed through to the remote leg.  In other 
words, that keypress would be trapped by Asterisk.  If, within 2 
seconds, the "8" key were pressed, still nothing would happen, since 
there would be no matching extension in the call-features context. 
However, if an additional digit were entered (let's say a "5") then 
the remote leg would be parked, and the context/ext/priority would 
jump to call-features/985/1.  The transferring leg would hear a 
soundfile, while a hypothetical AGI script might then be called to 
re-route the other leg back into the system using a spooled call with 
the parked extension as the originating number.  The transferring leg 
would then be hung up, in our example.



  2) Mode 2; pressing # twice within 2 seconds and then any key within 
2 seconds would activate the context jump, for those instances where 
one would want to allow most DTMF to "bleed through" to the other 
side.  Proposed modifiers: B and b (for "b"leed through)

Example:

    [foo]
    exten => 1234,1,Dial(SIP/999,50,B(call-features))
    [call-features]
    exten => 3,1,Monitor(gsm,important-call)
    exten => 3,2,ParkedCall(${PARKEDCALL})

  User would hit (quickly) ##3 and be transferred to call-features/3/1 
(context/ext/pri)  The first "#" key would be transmitted to the 
remote leg.  Audio would not be interrupted or disturbed in the call 
until the "3" digit was pressed.  As soon as the "3" was entered, the 
original call would "terminate", the distant leg would be parked, a 
fresh Monitor application would be started, and the exact same two 
participants would then be reconnected with ParkedCall.
   If the user entered ##4, then in this specific example, only the 
first # would be transmitted, and audio would continue on the channel 
with no interruption or noticeable change between the two parties. 
If 2 seconds were allowed to pass after the last key, the system 
would "reset" and two #'s would be again be required to wake up local 
key parsing.


  3) During use of I,i,B,b there would be a variable set of 
"${PARKEDCALL}" which would reflect the number on which the other leg 
of the call was parked.  Standard call parking behavior would be 
honored, with one notable exception:  When a call was parked via 
I,i,B,b there would be no readback of the call park number - the call 
would simply land in the parking lot without any feedback.



Whichever side did NOT press the keystroke sequence would be the ones 
that got thrown into the parking lot.  Perhaps it may be wise to also 
include a parking context, so that for those incredibly short 
transfer issues (like my call recording example, above) there is a 
custom "silence" MOH descriptor.  In other words, I don't think 
people want to hear .5 seconds of MOH during the time when the other 
applications are running.  (er... did multiple parking contexts get 
implemented yet? I don't think I'm imagining that I've seen that 
patch somewhere... <sigh>)


The combination of these new features would allow for easy 
interruption and re-connection of channels based on a little bit more 
useful a set of actions than what we have now.  I suspect that the 
programming behind this is not major, but as always, I could be 
horribly wrong.  This would open up some extraordinarily useful 
features for Asterisk, and anyone who has some time on their hands 
would be doing the community a big service by putting some codework 
into these methods.  I'll even buy you a box of brownies if you put 
it together more or less like I describe above.  :-)

Possible features I came up with in about 10 seconds:
   - instant, one-key "hold"
   - instant, one-key "mute"
   - instant, one-key call recording turn on/turn off
   - instant, one-key "transfer to fax machine"
   - help menus during "normal" transfers without intermediate extension


MAJOR PROBLEM:
   The biggest problem I see with this method is that there is no 
chan_park.c.  In other words, to look at my second example above, it 
seems to me that once we reconnect with a call that was parked... 
we're screwed.  Since we're not using "Dial" to reconnect to that 
parked call, there is no way to apply the TtIiBb modifiers to the 
call - we're at a dead end.  In fact, there are no modifiers at all 
on ParkedCall at all - it's just "magic".  I'd love to be able to say:

   exten => 3,2,Dial(PARK/${PARKEDCALL},,B(call-features))

I suppose I could use chan_local for this and create a context which 
include'ed only [parkedcalls]; I haven't thought about it enough and 
I don't know how key events are passed through that channel type.

JT