Comments?
Feature request: Add the ability for the "T" and "t"
suffixes in a
Dial command to call an extension directly (if specified) instead of
going only to the hardcoded "transfer" command.
Feature request: Flash events, when presented inside of an existing
call, will call a pre-specified extension just like the "T" and
"t"
request above, but perhaps with a different letter ("f")
Transfer extension flexibility:
I'd like to jump to an extension (or context?) when a transfer
trigger is pressed/used. Notably, flash-hooks and DTMF tones. If,
as an example, my user hits flash from within a call, I'd like to
have a voice announcement say "Press 1 to transfer this call to
sales, press 2 to play a howling monkey, etc."
I've read the manuals about using "#" as a transfer button;
that's
half of the battle - instead of jumping to a hardcoded "Transfer?"
voice prompt, can the "T" suffix in a Dial instead call an extension
directly, without the user entering it? This would do what I want,
which is provide a little more flexibility in how one moves calls
around.
The trick is, I suppose, twisting some (a lot?) of logic around
such that one party would be controlling the destination for the
other party (to which they were just connected a second ago.) In
order to do this, one would have to create some sort of automatic
park/unpark method and an application that would handle that.
Why do I request this? Because nobody, ever EVER has phone lists
beside them. They complain bitterly that the phone system isn't
user-friendly. They can't even remember that "0" gets them the
operator. The more I can do to spoon-feed things to them with
pre-recorded instructions, the better off I am.
A theoretical snippet from extensions.conf:
exten => 3444,1,Dial(${MYDESK},10,T[3000])
exten => 3000,s,Background(bigfatIVRfilewithtwoverbalizedoptions)
;
exten => 1,1,ReconnectPark
exten => 1,2,Dial(${SOMEWHERE1},10)
;
exten => 2,1,ReconnectPark
exten => 2,2,Dial(${SOMEOTHERPLACE},10)
;
First-Person example:
1) Someone ends up at extension 3444, and MYDESK phone rings. I talk
with them. I hit the "#" key.
2) The other party is parked in a (random?) unoccupied park area.
3) I am transferred to extension 3000 (should this be a context, or
just an extension?)
4) I go through a menu selection based on what is in my pre-built recording
5) At some point, I decide where I want to send the caller, based on
what I hear in the menu
6) I press the digit(s) for the appropriate
7) A new application, called "ReconnectPark" is called. This pulls
the parked call out of the holding tank and then the next priority is
run with that call as the "caller", and away they go.
8) I don't quite know what to do with my end of the conversation; it
seems a bit rude just to hang up. Perhaps another optional extension
for post-transfer, like this?
exten => 3444,1,Dial($MYDESK},10,T[3000:3999])
;
exten => 3000,s,Background(bigfatIVRfilewithtwoverbalizedoptions)
;
exten => 1,1,ReconnectPark
exten => 1,2,Dial(${SOMEWHERE1},10)
;
exten => 2,1,ReconnectPark
exten => 2,2,Dial(${SOMEOTHERPLACE},10)
;
exten => 3999,1,Playback(call-successfully-transferred)
exten => 3999,2,Hangup
;
Next feature.... flash usage:
From what I understand, SIP can relay flash events, so this is
within the bounds of reason. This is not a high-priority issue for
me, but it would be handy for managing transfers and whatnot. Using
the "#" key is fraught with danger, especially when it is used in IVR
menus on systems outside of the local PBX; I prefer "flash" since
it's local-only, though having both "flash" and "#"
would be great.
If this transfer logic is already implemented, could someone please
kindly point me to a resource or mailing list discussion about it?
I am re-inventing the wheel here, and I really hate doing these
exercises since everyone else has already thought it out.
PS: Man, the mailing list is a real bear to search through. There is
no keyword search that I've been able to find, and Google's search
features suck on mailing lists. The time delay on material appearing
in the manuals, plus lack of mailing list search-ability makes RTFM
very difficult.
JT
[re-hash of a previous message sent a few months ago. This is
especially interesting since the new "record" feature has been added.
A possible use for this method would be to start the Monitor
application on a channel after the caller enters a certain sequence
of touch tones. The more I look at the meta-code below, I think I
can use variables to get the call in and out of "park" without
creating new , but I still need to get something that allows the
caller/call-ee to get OUT of the call by pressing a touch tone and
then call some special extension instead of just the generic
"transfer?" prompt]
Comments?
Feature request: Add the ability for the "T" and "t"
suffixes in a
Dial command to call an extension directly (if specified) instead of
going only to the hardcoded "transfer" command.
Feature request: Flash events, when presented inside of an existing
call, will call a pre-specified extension just like the "T" and
"t"
request above, but perhaps with a different letter ("f")
Transfer extension flexibility:
I'd like to jump to an extension (or context?) when a transfer
trigger is pressed/used. Notably, flash-hooks and DTMF tones. If,
as an example, my user hits flash from within a call, I'd like to
have a voice announcement say "Press 1 to transfer this call to
sales, press 2 to play a howling monkey, etc."
I've read the manuals about using "#" as a transfer button;
that's
half of the battle - instead of jumping to a hardcoded "Transfer?"
voice prompt, can the "T" suffix in a Dial instead call an extension
directly, without the user entering it? This would do what I want,
which is provide a little more flexibility in how one moves calls
around.
The trick is, I suppose, twisting some (a lot?) of logic around
such that one party would be controlling the destination for the
other party (to which they were just connected a second ago.) In
order to do this, one would have to create some sort of automatic
park/unpark method and an application that would handle that.
Why do I request this? Because nobody, ever EVER has phone lists
beside them. They complain bitterly that the phone system isn't
user-friendly. They can't even remember that "0" gets them the
operator. The more I can do to spoon-feed things to them with
pre-recorded instructions, the better off I am.
A theoretical snippet from extensions.conf:
exten => 3444,1,Dial(${MYDESK},10,T[3000])
exten => 3000,s,Background(bigfatIVRfilewithtwoverbalizedoptions)
;
exten => 1,1,ReconnectPark
exten => 1,2,Dial(${SOMEWHERE1},10)
;
exten => 2,1,ReconnectPark
exten => 2,2,Dial(${SOMEOTHERPLACE},10)
;
First-Person example:
1) Someone ends up at extension 3444, and MYDESK phone rings. I talk
with them. I hit the "#" key.
2) The other party is parked in a (random?) unoccupied park area.
3) I am transferred to extension 3000 (should this be a context, or
just an extension?)
4) I go through a menu selection based on what is in my pre-built recording
5) At some point, I decide where I want to send the caller, based on
what I hear in the menu
6) I press the digit(s) for the appropriate
7) A new application, called "ReconnectPark" is called. This pulls
the parked call out of the holding tank and then the next priority is
run with that call as the "caller", and away they go.
8) I don't quite know what to do with my end of the conversation; it
seems a bit rude just to hang up. Perhaps another optional extension
for post-transfer, like this?
exten => 3444,1,Dial($MYDESK},10,T[3000:3999])
;
exten => 3000,s,Background(bigfatIVRfilewithtwoverbalizedoptions)
;
exten => 1,1,ReconnectPark
exten => 1,2,Dial(${SOMEWHERE1},10)
;
exten => 2,1,ReconnectPark
exten => 2,2,Dial(${SOMEOTHERPLACE},10)
;
exten => 3999,1,Playback(call-successfully-transferred)
exten => 3999,2,Hangup
;
Next feature.... flash usage:
From what I understand, SIP can relay flash events, so this is
within the bounds of reason. This is not a high-priority issue for
me, but it would be handy for managing transfers and whatnot. Using
the "#" key is fraught with danger, especially when it is used in IVR
menus on systems outside of the local PBX; I prefer "flash" since
it's local-only, though having both "flash" and "#"
would be great.
If this transfer logic is already implemented, could someone please
kindly point me to a resource or mailing list discussion about it?
I am re-inventing the wheel here, and I really hate doing these
exercises since everyone else has already thought it out.
PS: Man, the mailing list is a real bear to search through. There is
no keyword search that I've been able to find, and Google's search
features suck on mailing lists. The time delay on material appearing
in the manuals, plus lack of mailing list search-ability makes RTFM
very difficult.
JT
The ability to transfer calls to/from anywhere to anywhere is still an area that concerns me the most.. Specifically, Zap to SIP SIP to Zap SIP to SIP ZAP to ZAP (on standard phones without flash) Of course these issues may only be in my head becasue I haven't been using * all that long.. The "t" dial option is great but the "T" option is really needed to complete the facility of using the # to transfer calls.. I have read that for the SIP extensions I should just use a SIP tranfer but I haven't worked out how to SIP transfer a call to a Zap channel.. Again maybe just becasue I am new to *.. At this point I am not too concerned that the "transfer" is hard coded because I think that basic functionality for any-which-way transfer is more important than customising the transfer logic on a per system basis at this point.. Anyway thats my thoughts.. ----- Original Message ----- From: John Todd <jtodd@loligo.com> Date: Mon, 7 Apr 2003 19:47:00 -0700 To: asterisk-users@lists.digium.com Subject: [Asterisk-Users] Comments on "transfer" feature request> [re-hash of a previous message sent a few months ago. This is > especially interesting since the new "record" feature has been added. > A possible use for this method would be to start the Monitor > application on a channel after the caller enters a certain sequence > of touch tones. The more I look at the meta-code below, I think I > can use variables to get the call in and out of "park" without > creating new , but I still need to get something that allows the > caller/call-ee to get OUT of the call by pressing a touch tone and > then call some special extension instead of just the generic > "transfer?" prompt] > > Comments? > > Feature request: Add the ability for the "T" and "t" suffixes in a > Dial command to call an extension directly (if specified) instead of > going only to the hardcoded "transfer" command. > > Feature request: Flash events, when presented inside of an existing > call, will call a pre-specified extension just like the "T" and "t" > request above, but perhaps with a different letter ("f") > > > Transfer extension flexibility: > > I'd like to jump to an extension (or context?) when a transfer > trigger is pressed/used. Notably, flash-hooks and DTMF tones. If, > as an example, my user hits flash from within a call, I'd like to > have a voice announcement say "Press 1 to transfer this call to > sales, press 2 to play a howling monkey, etc." > > I've read the manuals about using "#" as a transfer button; that's > half of the battle - instead of jumping to a hardcoded "Transfer?" > voice prompt, can the "T" suffix in a Dial instead call an extension > directly, without the user entering it? This would do what I want, > which is provide a little more flexibility in how one moves calls > around. > > The trick is, I suppose, twisting some (a lot?) of logic around > such that one party would be controlling the destination for the > other party (to which they were just connected a second ago.) In > order to do this, one would have to create some sort of automatic > park/unpark method and an application that would handle that. > > Why do I request this? Because nobody, ever EVER has phone lists > beside them. They complain bitterly that the phone system isn't > user-friendly. They can't even remember that "0" gets them the > operator. The more I can do to spoon-feed things to them with > pre-recorded instructions, the better off I am. > > > A theoretical snippet from extensions.conf: > > exten => 3444,1,Dial(${MYDESK},10,T[3000]) > > > exten => 3000,s,Background(bigfatIVRfilewithtwoverbalizedoptions) > ; > exten => 1,1,ReconnectPark > exten => 1,2,Dial(${SOMEWHERE1},10) > ; > exten => 2,1,ReconnectPark > exten => 2,2,Dial(${SOMEOTHERPLACE},10) > ; > > First-Person example: > 1) Someone ends up at extension 3444, and MYDESK phone rings. I talk > with them. I hit the "#" key. > 2) The other party is parked in a (random?) unoccupied park area. > 3) I am transferred to extension 3000 (should this be a context, or > just an extension?) > 4) I go through a menu selection based on what is in my pre-built recording > 5) At some point, I decide where I want to send the caller, based on > what I hear in the menu > 6) I press the digit(s) for the appropriate > 7) A new application, called "ReconnectPark" is called. This pulls > the parked call out of the holding tank and then the next priority is > run with that call as the "caller", and away they go. > 8) I don't quite know what to do with my end of the conversation; it > seems a bit rude just to hang up. Perhaps another optional extension > for post-transfer, like this? > > exten => 3444,1,Dial($MYDESK},10,T[3000:3999]) > ; > exten => 3000,s,Background(bigfatIVRfilewithtwoverbalizedoptions) > ; > exten => 1,1,ReconnectPark > exten => 1,2,Dial(${SOMEWHERE1},10) > ; > exten => 2,1,ReconnectPark > exten => 2,2,Dial(${SOMEOTHERPLACE},10) > ; > exten => 3999,1,Playback(call-successfully-transferred) > exten => 3999,2,Hangup > ; > > > Next feature.... flash usage: > > From what I understand, SIP can relay flash events, so this is > within the bounds of reason. This is not a high-priority issue for > me, but it would be handy for managing transfers and whatnot. Using > the "#" key is fraught with danger, especially when it is used in IVR > menus on systems outside of the local PBX; I prefer "flash" since > it's local-only, though having both "flash" and "#" would be great. > > > > If this transfer logic is already implemented, could someone please > kindly point me to a resource or mailing list discussion about it? > I am re-inventing the wheel here, and I really hate doing these > exercises since everyone else has already thought it out. > > PS: Man, the mailing list is a real bear to search through. There is > no keyword search that I've been able to find, and Google's search > features suck on mailing lists. The time delay on material appearing > in the manuals, plus lack of mailing list search-ability makes RTFM > very difficult. > > JT > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users-- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze