Greetings all, Not specifically an asterisk query, but a couple of transfer queries that I'm sure are obvious to folks who use these phones all the time: 1) how does one do a blind transfer? When a call is answered and one hits the transfer button, followed by an extension, one has to wait for the other party to answer, then hit transfer again, before the call is released. I'm sure there must be an option to answer a call, then fire it straight off to another extension without waiting for an answer? 2) if there are 2 incoming calls currently on the go (i.e. the first one has been put on hold for the operator to answer the second call), how does one determine which call will be transferred when the transfer button is pressed? Is there a way to select the source call for a transfer prior to hitting transfer? 3) when handling 2 calls, how does one swap between them? These phones are running sccp through chan_sccp if that makes any difference to operation. Thanks in advance folks. Regards, Chris -- C.M. Bagnall, Director, Minotaur I.T. Limited This email is made from 100% recycled electrons
Chan_sccp does not support blind transfer. I would suggest using chan_sip and the SIP images with these phones; it is much more stable, has more features and is being actively developed. Chan_sip supports blind transfer and 3-way calling, plus it handles multiple calls on hold a bit more gracefully than chan_sccp. Chan_sccp seems largely dead at this point; the maintainer has not released a patch in 2 months and most of the users who know the code well enough to possibly maintain it seem to have moved on to other projects. If you don't have access to the SIP firmware (which you can get for a $75 cisco smartNET contract,) understand that chan_sccp still has quite a few bugs that make it unsuitable for a production system in my eyes. There are still unresolved deadlocks and channel locking issues which can render your phone unusable until an asterisk restart, and you can't reload the configuration without unloading the driver and killing registration on all your phones (meaning you can't add a phone without downtime for the whole system.) But this is just my take on the situation. -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Chris Bagnall Sent: Tuesday, June 27, 2006 9:57 AM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: [Asterisk-Users] 7960 help: transferring calls Greetings all, Not specifically an asterisk query, but a couple of transfer queries that I'm sure are obvious to folks who use these phones all the time: 1) how does one do a blind transfer? When a call is answered and one hits the transfer button, followed by an extension, one has to wait for the other party to answer, then hit transfer again, before the call is released. I'm sure there must be an option to answer a call, then fire it straight off to another extension without waiting for an answer? 2) if there are 2 incoming calls currently on the go (i.e. the first one has been put on hold for the operator to answer the second call), how does one determine which call will be transferred when the transfer button is pressed? Is there a way to select the source call for a transfer prior to hitting transfer? 3) when handling 2 calls, how does one swap between them? These phones are running sccp through chan_sccp if that makes any difference to operation. Thanks in advance folks. Regards, Chris -- C.M. Bagnall, Director, Minotaur I.T. Limited This email is made from 100% recycled electrons _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Lacy Moore - Aspendora
2006-Jun-27 10:08 UTC
[Asterisk-Users] 7960 help: transferring calls
Blind transfer is not possible via softkeys on the 7960 using chan_sccp. However, check your features.conf. You should have a line in there regarding blind transfer. I believe the default is #, but it recommended changing that to ##. I did this, and on my 7960s, you hit ## then the extension you wish to transfer to. This does requires use of the t or T dial command options. You'll have to look this up, as I can't remember offhand which is needed, and it depends on whether the 7960 is the caller or callee. #2 and #3 I'll have to check on. If I remember correctly, it's pretty easy. On 6/27/06, Chris Bagnall <asterisk@minotaur.cc> wrote:> > Greetings all, > > Not specifically an asterisk query, but a couple of transfer queries that > I'm sure are obvious to folks who use these phones all the time: > > 1) how does one do a blind transfer? When a call is answered and one hits > the transfer button, followed by an extension, one has to wait for the > other > party to answer, then hit transfer again, before the call is released. I'm > sure there must be an option to answer a call, then fire it straight off > to > another extension without waiting for an answer? > > 2) if there are 2 incoming calls currently on the go (i.e. the first one > has > been put on hold for the operator to answer the second call), how does one > determine which call will be transferred when the transfer button is > pressed? Is there a way to select the source call for a transfer prior to > hitting transfer? > > 3) when handling 2 calls, how does one swap between them? > > These phones are running sccp through chan_sccp if that makes any > difference > to operation. > > Thanks in advance folks. > > Regards, > > Chris > -- > C.M. Bagnall, Director, Minotaur I.T. Limited > This email is made from 100% recycled electrons > > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-- Lacy Moore Aspendora, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060627/0a1cfcd0/attachment.htm