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

[Johansson Olle E]

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.

/O