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

Fri Feb 11 16:22:33 MSK 2011

Maybe you are right, but then tell me the right way :) att_xfer uses
loopback by itself, and it doesn't work without tricks with not well
documented loopback_bowout/bowout_on_execute variables... This
behavior is not documented anywhere, but I can't propose wiki updates
until I get it working or just give up with att_xfer in FS at all :)

All I need is just working in-call att_xfer with Sofia channels :( SIP
transfers are cool, but  I need in-call DTMF triggered transfers :((

Is there a developer documentation about FS basic work principles?
I'll try to dive in the code :))

2011/2/11 Anthony Minessale <anthony.minessale at gmail.com>:
> I reverted the patch, I guess it doesn't work based on your feedback.
> We will leave well enough alone when you said in your last email
> everything was working.
>
> There is a time when maybe you are taking things too far trying to
> solve things a silly way and maybe you should consider nicer
> equipment.
>
>
> On Fri, Feb 11, 2011 at 4:43 AM, Dmitry Sytchev <kbdfck at gmail.com> wrote:
>> I see your patch in git log, is it enough to do 'make current', or I
>> should apply it in some special way? After make current issues are
>> still present...
>>
>> What should i set loopback_bowout/bowout_on_execute variables to? I
>> tried with false, this works as in previous versions, and loopback
>> stays in path during the call. While loopback channels are present in
>> path, there are issues with sound quality, there is robot voice effect
>> for short periods of time. You mentioned setting rtp timer to none,
>> where this should be done? In loopback channel execute_extension while
>> doing att_xfer?
>>
>> When bowout variables set to true  att_xfer doesn't work just as I
>> described in my previous posts, and there is also issue with MOH -
>> after transfer target answers to transferor, MOH is stoped for
>> transferee. Maybe this can help somehow.
>>
>>
>>
>>
>> 2011/2/10 Anthony Minessale <anthony.minessale at gmail.com>:
>>> I pushed a patch that will probably delay the bowout until after the
>>> att_xfer is over
>>> Give it a try.
>>>
>>> commit 3546654615f88058fb6769fe79e07162602fa4af
>>> Author: Anthony Minessale <anthm at freeswitch.org>
>>> Date:   Thu Feb 10 12:37:14 2011 -0600
>>>
>>>    don't bow out on att_xfer bridge
>>>
>>>
>>> On Thu, Feb 10, 2011 at 1:03 AM, Dmitry Sytchev <kbdfck at gmail.com> wrote:
>>>> Thanks! It works now! BTW, att_xfer with
>>>> loopback_bowout/bowout_on_execute set to false seems to be working
>>>> too. Is there a way to make loopback channel leave the path? Without
>>>> bowout turned off att_xfer doesn't work...
>>>>
>>>> 2011/2/8 Anthony Minessale <anthony.minessale at gmail.com>:
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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