Hi! A few months ago I needed some help for the following issue: .) a call comes in .) Person A takes the call and does an attended transfer to Person B .) Person A hangs up the phone without waiting for Person B taking the call .) the caller get lost at this point !! At this point the attended transfer should go into a blind transfer. The phone of Person B should still be ringing and the caller shouldnt get lost. I think this is the most usual behaviour of a call transfer also on the cheapest systems on the market. Why doesnt this work well with asterisk? Will there be a solution for that in the near future? I am thankful for any kind of help! thx, Tom
> A few months ago I needed some help for the following issue: > > .) a call comes in > .) Person A takes the call and does an attended transfer to Person B > .) Person A hangs up the phone without waiting for Person B taking the > call > .) the caller get lost at this point !! > > At this point the attended transfer should go into a blind transfer.The> phone of Person B should still be ringing and the caller shouldnt get > lost. > > I think this is the most usual behaviour of a call transfer also onthe> cheapest systems on the market.Could you remind us of what kinds of phones you are using, and whether you're using SIP, Zap or something else? Thanks! -MC
> Jerry Jones wrote: > > > Yes it should all behave the way we are used to. However SIP IS > > different. The exact behavior will be dependant upon the individual > > hard phone. > > > Isn't that true only if it has a preprogrammed transfer key? > an Asterisk feature code should work as discussed. > There SHOULD be a way to make SIP phones work the same. > ( easy to say, perhaps not so easy to do )Agreed! In regular PBX telephony there is no technological difference between a blind transfer and an attended/supervised transfer. As far as the generic PBX or key system is concerned, a transfer is a transfer. The only thing the differentiates the blind from the attended is the BEHAVIOR of the person initiating the transfer. HOWEVER, with the various types of SIP phones, firmware revs, etc., there are some issues. When the OP gives us the details on his exact config hopefully we'll be able to point him in the right direction. -MC
There is some kind of issue with SIP transfer interaction between some SIP phones and asterisk, I have personal experience with Polycom phones not being able to do a blind xfer using the feature key. We have to use the asterisk # blind xfrer functionality for blind transfers The phones will drop the call if you initiate a transfer with the feature key but do not wait for the remote line to answer before releasing the call. In other words, if you hit transfer on the phone, wait for the remote phone to ring, and hang up, you will drop the call. If you wait for the remote phone to answer (live or voicemail) the transfer will complete. It IS confusing to users to have 2 transfers, # for blind and the feature key for attended. Damon> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users- > bounces@lists.digium.com] On Behalf Of Jerry Jones > Sent: Friday, April 14, 2006 1:28 PM > To: jnovack@stromberg-carlson.org; Asterisk Users Mailing List - Non- > Commercial Discussion > Subject: Re: [Asterisk-Users] attended transfer issue > > Keep in mind that with a SIP phone you are not communicating directly > with asterisk but with the phone which acts on your behalf with > asterisk. On traditional systems if you performed a hook flash to > transfer, you were definately signalling directly to the PBX. Now > when you push a button, hard or soft, on a SIP phone you are telling > the phone to perform as series of actions to accomplish a goal. It is > very much up to the phone software on exactly how the set behaves. > As stated previously, yes there should be a standard, but afaik there > are no standards bodies specifying the ui for voip devices. > > > On Apr 14, 2006, at 2:16 PM, John Novack wrote: > > > > > > > Jerry Jones wrote: > > > >> Yes it should all behave the way we are used to. However SIP IS > >> different. The exact behavior will be dependant upon the > >> individual hard phone. > >> > > Isn't that true only if it has a preprogrammed transfer key? > > an Asterisk feature code should work as discussed. > > There SHOULD be a way to make SIP phones work the same. > > ( easy to say, perhaps not so easy to do ) > > > > John Novack > > > >> This of course is if using SIP which we do not know yet... > >> > >> On Apr 14, 2006, at 1:43 PM, John Novack wrote: > >> > >>> > >>> > >>> Michael Collins wrote: > >>> > >>>>> A few months ago I needed some help for the following issue: > >>>>> > >>>>> .) a call comes in > >>>>> .) Person A takes the call and does an attended transfer to > >>>>> Person B > >>>>> .) Person A hangs up the phone without waiting for Person B > >>>>> taking the call > >>>>> .) the caller get lost at this point !! > >>>>> > >>>>> At this point the attended transfer should go into a blind > >>>>> transfer. > >>>>> > >>>> The phone of Person B should still be ringing and the caller > >>>> shouldnt get lost. > >>>> > >>>> I think this is the most usual behaviour of a call transfer > >>>> also on the cheapest systems on the market. > >>>> > >>>> > >>>> > >>>> Could you remind us of what kinds of phones you are using, and > >>>> whether you're using SIP, Zap or something else? > >>>> > >>>> Thanks! > >>>> > >>>> -MC > >>>> > >>> I think the point of this post and other related ones is the > >>> fact that there are attended and blind transfers, initiated by > >>> different actions, where phone systems for at least the last 20 > >>> years have one action, or transfer. > >>> The person initiating the transfer starts the procedure, and if > >>> the destination extension answers, either through the facilities > >>> of handsfree intercom or picking up the phone, the initiator and > >>> the receiver can confer BEFORE the transfer is complete. > >>> If, on the other hand the initiator either chooses to hang up > >>> after starting the transfer, the transfer is then complete, and > >>> the destination extension rings until answered or overflows into > >>> voice mail. > >>> In NO case should the call get lost. Attended and blind transfer > >>> SHOULD start with the same action and be considered as ONEfunction> >>> Irrelevant what phones are being used. > >>> > >>> JMO > >>> > >>> John Novack > >>> > >>> _______________________________________________ > >>> --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 > >> > >> > >> _______________________________________________ > >> --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 > >> > >> > > _______________________________________________ > > --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 > > _______________________________________________ > --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
Damon Estep wrote:>There is some kind of issue with SIP transfer interaction between some SIP phones and asterisk, I have personal experience with Polycom phones not being able to do a blind xfer using the feature key. > > >Is that a Polycom or Asterisk defect?>We have to use the asterisk # blind xfrer functionality for blind >transfers > >>The phones will drop the call if you initiate a transfer with the >feature key but do not wait for the remote line to answer before >releasing the call. In other words, if you hit transfer on the phone, >wait for the remote phone to ring, and hang up, you will drop the call. > > >Not so good. Asterisk or Polycom doing that? John Novack>If you wait for the remote phone to answer (live or voicemail) the >transfer will complete. > >It IS confusing to users to have 2 transfers, # for blind and the >feature key for attended. > >Damon > > > > >
Not sure, but the fact that the # xfer in asterisk releases the call without the ability to do an attended transfer is an asterisk issue, maybe not a "defect", but a design issue inconsistent with typical PBX behavior. To be "typical" it would act like this; Press pound to get secondary dial tone Dial the number for the transfer Either hang up or stay on the line after progress (ring) If you stay on the line the transfer completes when you hang up If you hang up during the ring the call is blind transferred If you press the same feature access key (#) again you get the call back and terminate the transfer. Make sense? Is this feature already there? If it is it would be easy to code the feature key on the phone to use the sip feature server function, if it is not there then it is hard to have a phone ask asterisk to do something it does not know how to do. I agree that this feature could be built into the phone firmware, but it would be different for every phone. Putting it in asterisk provides a bit of consistency on a feature every business uses every day. Damon> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users- > bounces@lists.digium.com] On Behalf Of John Novack > Sent: Friday, April 14, 2006 2:22 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [Asterisk-Users] attended transfer issue > > > > Damon Estep wrote: > > >There is some kind of issue with SIP transfer interaction betweensome> SIP phones and asterisk, I have personal experience with Polycomphones> not being able to do a blind xfer using the feature key. > > > > > > > Is that a Polycom or Asterisk defect? > > >We have to use the asterisk # blind xfrer functionality for blind > >transfers > > > > > > >The phones will drop the call if you initiate a transfer with the > >feature key but do not wait for the remote line to answer before > >releasing the call. In other words, if you hit transfer on the phone, > >wait for the remote phone to ring, and hang up, you will drop thecall.> > > > > > > Not so good. > Asterisk or Polycom doing that? > > John Novack > > >If you wait for the remote phone to answer (live or voicemail) the > >transfer will complete. > > > >It IS confusing to users to have 2 transfers, # for blind and the > >feature key for attended. > > > >Damon > > > > > > > > > > > _______________________________________________ > --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
Hi! I decided to open an issue about this case in the mantis database! I am not very familiar with the bug/issue tracking procedure at the asterisk project, but I think i can make it. Is there something that would speak against it? cheers, tom Thomas Artner wrote:> Hi! > > > A few months ago I needed some help for the following issue: > > .) a call comes in > .) Person A takes the call and does an attended transfer to Person B > .) Person A hangs up the phone without waiting for Person B taking the call > .) the caller get lost at this point !! > > At this point the attended transfer should go into a blind transfer. The > phone of Person B should still be ringing and the caller shouldnt get lost. > > I think this is the most usual behaviour of a call transfer also on the > cheapest systems on the market. > > Why doesnt this work well with asterisk? Will there be a solution for > that in the near future? > > I am thankful for any kind of help! > > > thx, > Tom > > _______________________________________________ > --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 >
Thank you for doing that. With a little luck someone will be able to fix it, assuming they understand it NEEDS to be fixed. Damon Estep stated proper transfer operation well yesterday Sustitution of another key for pound in features.conf might also be desirable To be "typical" it would act like this; Press pound to get secondary dial tone Dial the number for the transfer Either hang up or stay on the line after progress (ring) If you stay on the line the transfer completes when you hang up If you hang up during the ring the call is blind transferred If you press the same feature access key (#) again you get the call back and terminate the transfer. John Novack Thomas Artner wrote:>Hi! > >I decided to open an issue about this case in the mantis database! >I am not very familiar with the bug/issue tracking procedure at the >asterisk project, but I think i can make it. > >Is there something that would speak against it? > >cheers, >tom > > > > >Thomas Artner wrote: > > >>Hi! >> >> >>A few months ago I needed some help for the following issue: >> >>.) a call comes in >>.) Person A takes the call and does an attended transfer to Person B >>.) Person A hangs up the phone without waiting for Person B taking the call >>.) the caller get lost at this point !! >> >>At this point the attended transfer should go into a blind transfer. The >>phone of Person B should still be ringing and the caller shouldnt get lost. >> >>I think this is the most usual behaviour of a call transfer also on the >>cheapest systems on the market. >> >>Why doesnt this work well with asterisk? Will there be a solution for >>that in the near future? >> >>I am thankful for any kind of help! >> >> >>thx, >>Tom >> >>_______________________________________________ >>--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 >> >> >> > >_______________________________________________ >--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 > > > >
That "fix" would be great!!! To press # and be able to get the call back and terminate the transfer... I had to implement an horrible workaround to emulate this functionality!!!! Dov -----Mensagem original----- De: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] Em nome de John Novack Enviada em: s?bado, 15 de abril de 2006 13:19 Para: Asterisk Users Mailing List - Non-Commercial Discussion Assunto: Re: [Asterisk-Users] attended transfer issue Thank you for doing that. With a little luck someone will be able to fix it, assuming they understand it NEEDS to be fixed. Damon Estep stated proper transfer operation well yesterday Sustitution of another key for pound in features.conf might also be desirable To be "typical" it would act like this; Press pound to get secondary dial tone Dial the number for the transfer Either hang up or stay on the line after progress (ring) If you stay on the line the transfer completes when you hang up If you hang up during the ring the call is blind transferred If you press the same feature access key (#) again you get the call back and terminate the transfer. John Novack Thomas Artner wrote:>Hi! > >I decided to open an issue about this case in the mantis database! >I am not very familiar with the bug/issue tracking procedure at the >asterisk project, but I think i can make it. > >Is there something that would speak against it? > >cheers, >tom > > > > >Thomas Artner wrote: > > >>Hi! >> >> >>A few months ago I needed some help for the following issue: >> >>.) a call comes in >>.) Person A takes the call and does an attended transfer to Person B >>.) Person A hangs up the phone without waiting for Person B taking the >>call >>.) the caller get lost at this point !! >> >>At this point the attended transfer should go into a blind transfer. >>The phone of Person B should still be ringing and the caller shouldnt getlost.>> >>I think this is the most usual behaviour of a call transfer also on >>the cheapest systems on the market. >> >>Why doesnt this work well with asterisk? Will there be a solution for >>that in the near future? >> >>I am thankful for any kind of help! >> >> >>thx, >>Tom >> >>_______________________________________________ >>--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 >> >> >> > >_______________________________________________ >--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 > > > >_______________________________________________ --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
John Novack wrote:> > > Damon Estep wrote: > >> There is some kind of issue with SIP transfer interaction between some >> SIP phones and asterisk, I have personal experience with Polycom >> phones not being able to do a blind xfer using the feature key.Our receptionist does both blind and attended transfers with Polycoms all the time. In later versions of the Polycom SIP firmware: Attended transfer: while on a call press the Transfer key, dial the destination, talk, then press the transfer key again. For Blind: while on call, press transfer key, then the Blind key, dial, hangup.
Eric "ManxPower" Wieling wrote:> John Novack wrote: > >> >> >> Damon Estep wrote: >> >>> There is some kind of issue with SIP transfer interaction between >>> some SIP phones and asterisk, I have personal experience with >>> Polycom phones not being able to do a blind xfer using the feature key. >> > > Our receptionist does both blind and attended transfers with Polycoms > all the time. In later versions of the Polycom SIP firmware: Attended > transfer: while on a call press the Transfer key, dial the > destination, talk, then press the transfer key again. For Blind: > while on call, press transfer key, then the Blind key, dial, hangup.All well and good, but that is awkward. The point is/was that doing a transfer, talk or not, transferee answer or not, the transferer should be able to hang up and the call NOT get lost, the transfer complete and ring then overflow to voice mail. Easier on ALL users and the way hybrid systems have worked for many a year John Novack
dovb wrote:> That "fix" would be great!!! > > To press # and be able to get the call back and terminate the transfer... > I had to implement an horrible workaround to emulate this functionality!!!!Well, as it stands now, to hangup while you are doing a transfer, you using the hangup feature code (in features.conf). That will put you back to the original person. Kevin
John Novack wrote:> > > Eric "ManxPower" Wieling wrote: > >> John Novack wrote: >> >>> >>> >>> Damon Estep wrote: >>> >>>> There is some kind of issue with SIP transfer interaction between >>>> some SIP phones and asterisk, I have personal experience with >>>> Polycom phones not being able to do a blind xfer using the feature key. >>> >> >> Our receptionist does both blind and attended transfers with Polycoms >> all the time. In later versions of the Polycom SIP firmware: Attended >> transfer: while on a call press the Transfer key, dial the >> destination, talk, then press the transfer key again. For Blind: >> while on call, press transfer key, then the Blind key, dial, hangup. > > All well and good, but that is awkward. > The point is/was that doing a transfer, talk or not, transferee answer > or not, the transferer should be able to hang up and the call NOT get > lost, the transfer complete and ring then overflow to voice mail. > Easier on ALL users and the way hybrid systems have worked for many a yearThis is just the way Polycom does transfers. Older versions of the Polycom firmware worked as you describe. I think it was in 1.6.x where they changed things to separate blind and attended transfers. It really has nothing to do with Asterisk at all.
________________________________ From: asterisk-users-bounces@lists.digium.com on behalf of Eric "ManxPower" Wieling Sent: Wed 4/19/2006 8:47 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] attended transfer issue John Novack wrote:> > > Eric "ManxPower" Wieling wrote: > >> John Novack wrote: >> >>> >>> >>> Damon Estep wrote: >>> >>>> There is some kind of issue with SIP transfer interaction between >>>> some SIP phones and asterisk, I have personal experience with >>>> Polycom phones not being able to do a blind xfer using the feature key. >>> >> >> Our receptionist does both blind and attended transfers with Polycoms >> all the time. In later versions of the Polycom SIP firmware: Attended >> transfer: while on a call press the Transfer key, dial the >> destination, talk, then press the transfer key again. For Blind: >> while on call, press transfer key, then the Blind key, dial, hangup. > > All well and good, but that is awkward. > The point is/was that doing a transfer, talk or not, transferee answer > or not, the transferer should be able to hang up and the call NOT get > lost, the transfer complete and ring then overflow to voice mail. > Easier on ALL users and the way hybrid systems have worked for many a yearThis is just the way Polycom does transfers. Older versions of the Polycom firmware worked as you describe. I think it was in 1.6.x where they changed things to separate blind and attended transfers. It really has nothing to do with Asterisk at all. Understand, but the point was that every SIP device has its own method, and it would be nice if asterisk had a blind/attend transfer feature as described so we are not dependent on the SIP UA vendors to try and normalize the world. If asterisk had the featuer we would not care that every SIP phone does it differently ,there would be one sure method that users could learn that wouild be consistent from device to device. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5057 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060419/5b2bd176/attachment.bin
> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users- > bounces@lists.digium.com] On Behalf Of Andrew Kohlsmith > Sent: Wednesday, April 19, 2006 11:53 AM > To: asterisk-users@lists.digium.com > Subject: Re: [Asterisk-Users] attended transfer issue > > On Wednesday 19 April 2006 13:32, Damon Estep wrote: > > Understand, but the point was that every SIP device has its ownmethod,> and > > it would be nice if asterisk had a blind/attend transfer feature as > > described so we are not dependent on the SIP UA vendors to try and > > normalize the world. If asterisk had the featuer we would not carethat> > every SIP phone does it differently ,there would be one sure methodthat> > users could learn that wouild be consistent from device to device. > > We do have that, it's called the "t" and "T" options for app_dial(),and> using > "#" :-) >Is the current release different than what I am running, # transfer on my systems are all blind, no attended option.
Damon Estep wrote:> Is the current release different than what I am running, # transfer on > my systems are all blind, no attended option.1.0.x only supported blind DTMF transfer hack. 1.2.x supports both blind and supervised DTMF transfer hacks. See features.conf in 1.2.x
Hi, Following last thread on unifying blind and attended transfers (http://thread.gmane.org/gmane.comp.telephony.pbx.asterisk.user/146002/focus=146683) I think it would be great if a user could either : 1. transform a transfer into into a blind-and-forget transfer one pressing # key 2. transform that transfer into a blind-and-return pressing another key As its name suggests, a blind-and-return transfer is a transfer which return back to initial callee in case transfer callee doesn't answer (useful for receptionnist who can't attend nor loose calls to special extensions). What do you think of that ? Maybe we could enchance http://bugs.digium.com/view.php?id=6973 description though a bounty on voip-info.org could be the best place to act on. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060517/a3056c08/attachment.htm
when I use ${EXTEN:2} in my dial plan it returns no value.
Is there something that I may have overlooked?
Rgds
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Looks like you are using it on a 2 digit extension. On 5/24/06, Akpome Akpoguma <akpome_a@hotmail.com> wrote:> > when I use ${EXTEN:2} in my dial plan it returns no value. > Is there something that I may have overlooked? > > Rgds > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > > _______________________________________________ > --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 >
Send your dial plan where you are having the problem. I agree with Eric, you
must have something misspelled.
bp
-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Eric
"ManxPower" Wieling
Sent: Wednesday, May 24, 2006 10:57 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] ${EXTEN}
Then you have a typo.
Akpome Akpoguma wrote:>
> I used it on a 4 digit extension
>
>> From: "C F" <shmaltz@gmail.com>
>> Reply-To: Asterisk Users Mailing List - Non-Commercial
>> Discussion<asterisk-users@lists.digium.com>
>> To: "Asterisk Users Mailing List - Non-Commercial
>> Discussion"<asterisk-users@lists.digium.com>
>> Subject: Re: [Asterisk-Users] ${EXTEN}
>> Date: Wed, 24 May 2006 09:25:50 -0400
>>
>> Looks like you are using it on a 2 digit extension.
>>
>> On 5/24/06, Akpome Akpoguma <akpome_a@hotmail.com> wrote:
>>>
>>> when I use ${EXTEN:2} in my dial plan it returns no value.
>>> Is there something that I may have overlooked?
--
Now accepting new clients in Birmingham, Atlanta, Huntsville,
Chattanooga, and Montgomery.
_______________________________________________
--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
__________ NOD32 1.1443 (20060314) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
I believe you want the ESP mailing list. Of the two message I have read that you have posted today, both require mind reading abiltities to answer your questions. Please include a little more information. On 5/24/06, Akpome Akpoguma <akpome_a@hotmail.com> wrote:> > > When I use the # key to interrupt an application it does not work. > Pls is there any idea on what could be wrong? > > Rgds, > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > > _______________________________________________ > --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/20060524/b35f92ea/attachment.htm
this problem has been resolved. Its actually a dtmf problem.>From: "Akpome Akpoguma" <akpome_a@hotmail.com> >Reply-To: Asterisk Users Mailing List - Non-Commercial >Discussion<asterisk-users@lists.digium.com> >To: asterisk-users@lists.digium.com >Subject: [Asterisk-Users] # key >Date: Wed, 24 May 2006 13:15:23 +0000 > > >When I use the # key to interrupt an application it does not work. >Pls is there any idea on what could be wrong? > >Rgds, > >_________________________________________________________________ >FREE pop-up blocking with the new MSN Toolbar - get it now! >http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > >_______________________________________________ >--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_________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Thomas Artner wrote:> A few months ago I needed some help for the following issue: > > .) a call comes in > .) Person A takes the call and does an attended transfer to Person B > .) Person A hangs up the phone without waiting for Person B taking the call > .) the caller get lost at this point !!I've just come across this issue too. As the call gets hung up if the transfer is attempted before answer I tried changing this: exten => _90ZXXXXXXXXX,1,Dial(zap/g1/${EXTEN},,TW) to this: exten => _90ZXXXXXXXXX,1,Answer exten => _90ZXXXXXXXXX,n,Dial(zap/g1/${EXTEN},,TW) So the call is 'answered' in one sense before it starts ringing. I've only tested it on a zap channel so far but it seems to fix it. Unless this is how Answer() is supposed to be used, I'm not sure then it's a bit of a dirty hack and I don't know what else it might break. I'm not back in the office until next week so can't test my brainwave out fully. Mike