[Freeswitch-users] hold_music var gets unset/lost by cancelled/failed att_xfer

[Anthony Minessale]

try latest GIT

On Tue, Feb 8, 2011 at 1:28 AM, Dmitry Sytchev <kbdfck at gmail.com> wrote:
> I have same issue with MOH and att_xfer on failed transfers, music on
> hold played only once
> At the same time, transfer_ringback always plays correctly to transferer
>
> 2011/2/8 Anthony Minessale <anthony.minessale at gmail.com>:
>> you really should report this to jira not to the mailing list.
>> http://jira.freeswitch.org
>>
>>
>>
>> On Mon, Feb 7, 2011 at 4:23 PM, Fraser Redmond <fraserredmond at gmail.com> wrote:
>>> I'm trying to do a second att_xfer on a call so that if the first attended
>>> transfer fails (c-leg is busy, or presses do-not-answer, or is an extn that
>>> doesn't exist) then the call could be transferred to someone else.
>>>
>>> On the first att_xfer the person on hold hears the hold_music correctly.
>>> Once that transfer is cancelled or fails:
>>> -- On any subsequent att_xfer's the person on hold just hears silence.
>>> -- If they are put on hold they just hear silence.
>>>
>>> I tried setting hold_music again for each channel after the first att_xfer,
>>> but that didn't work, so it's probably not actually a problem with
>>> hold_music per se, but some other variable/setting that decides whether to
>>> use hold_music.
>>>
>>> I also tried doing a uuid_dump before and after each attempt, but didn't
>>> notice anything too different - unless it's a matter of unsetting one of the
>>> couple of changed/new vars like:
>>> variable_originate_disposition
>>> variable_current_application
>>> variable_playback_seconds
>>>
>>> I get the feeling other variables are probably also lost by the first failed
>>> transfer as the second att_xfer has some odd things happen if the third
>>> party does answer. Haven't been able to narrow it down as closely as the
>>> hold_music, but two things I've seen happen are:
>>> -- The party that initiated the transfer gets hung up automatically (after
>>> 30 sec)
>>> -- When the party that initiated the transfer hangs up it should connect the
>>> other two parties, but instead it hung up all three
>>>
>>> Cheers,
>>> Fraser
>>>
>>>
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>
>
>
> --
> Best regards,
>
> Dmitry Sytchev,
> IT Engineer
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900