[asterisk-dev] Attn Olle: closed bug #9239 - "xfersound"

[Steve Davies]

On Jan 31, 2008 10:39 AM, Johansson Olle E <oej at edvina.net> 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.

Just my 2c.
Steve