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

[Steve Davies]

On Jan 31, 2008 4:36 PM, Johansson Olle E <oej at edvina.net> wrote:
>
> 31 jan 2008 kl. 15.43 skrev 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.
>
> 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.
>

I hope it is not too cheeky to have raised a feature request in bug #
11900 for discussion of this possible new feature.
http://bugs.digium.com/view.php?id=11900

Steve