31 jan 2008 kl. 15.43 skrev Steve Davies: > On Jan 31, 2008 10:39 AM, Johansson Olle E <[EMAIL PROTECTED]> wrote: >> Late answer, found in my mail queue. Obviously did not get sent on >> the >> airport... >> >> /O >> >> 23 jan 2008 kl. 21.03 skrev Nic Bellamy: >> >>> Hi Olle, >>> you closed off the above bug yesterday, or thereabouts, with a >>> comment: >>> >>> "No answer from reporter, and it's doable in dialplan." >>> >>> The "No answer from reporter" part is easy enough to understand >>> (yes, it >>> had been a while), but you have commented a couple of times during >>> the >>> life of the bug that it's doable in the dialplan. >>> >>> I can't for the life of me think how to do it in the dialplan, so if >>> it >>> can be done, please please please enlighten me. >>> >>> The basic idea is to have a notification beep play when an attended >>> transfer is completed - ie.: >>> >>> 1. A rings B, B answers. A wants to talk to C >>> 2. B rings C, C answers. C says "go ahead" >>> 3. B completes attended transfer >>> 4. B->C bridge gets replaced with A->C bridge - but C would like a >>> "beep!" when this happens. Currently, unless there's a significant >>> change in background noise, it's very hard for C to tell when B->C >>> changes to A->C >> >> >> For blind transfers: >> >> Catch the new call in the TRANSFER_CONTEXT, play a beep and >> go ahead. >> >> Attended transfers are harder, you're right. There's obviously no >> dialplan execution at time of transfer. I am a bit afraid of >> duplicating >> too much code of the PBX transfer in res_features into chan_sip and >> building my own PBX in the SIP channel, so I am very hesitant for >> this type of patches... >> >> I guess I will have to revisit this bug. Thanks for the correction >> and the reminder. >> >> /O :-) >> > > I would personally love to see this implemented as a parameter to > Dial(), perhaps a B(macro) parameter which works a bit like M(macro), > except that is is executed whenever any sort of call bridge is > completed, rather than when the call is answered. The macro would be > called with a couple of system variables set to indicate channels > involved, and the type of transfer taking place. > > One complication - There might be 2 call legs with either the same or > different B() parameters specified... This would need resolving! > > This feature would allow more than just a Beep to be played, it would > allow call-recording settings to be re-evaluated for the newly bridged > call, MoH settings to be changed, CDR updates, and all sorts of other > useless behaviour that keeps end-user happy :) > > Of course, ideally M() and B() behaviour would also be available to > app_queue originated calls.
That's a cool idea which also takes it out of the SIP scope :-) We just need to make sure that chan_sip and other channels activate this in the same way as the new features non-module does. /O _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev