[Freeswitch-users] Having a problem with attended transfer when FS is the transfer target

Wed Apr 21 07:13:02 PDT 2010

instead of emailing again when impatient for an answer (something we frown
upon here in this busy list)
produce a reproducible step by step process to duplicate your issue.  We are
trying to help people but we don't have the time to do the leg work for
everyone who asks a question when we get hundreds of emails a day.

On Wed, Apr 21, 2010 at 9:01 AM, Mardy Marshall <mardy at voysys.com> wrote:

> Just following up...  Does anyone have any suggestions on how to proceed
> with this?  I've run out of ideas.
>
> Thanks,
>
> -Mardy
>
> On Apr 19, 2010, at 8:21 PM, Mardy Marshall wrote:
>
> The phones that I am using are not registered with FS.  They are registered
> with another proxy based PBX.  I am simply using FS as B2BUA which is also
> registered with the PBX.  And yes, I can successfully transfer a call to
> another phone with this setup.
>
> To simplify things I tried the same scenario using FSComm in place of my
> own FS application and tried to transfer a call to FSComm with the same
> results.  And just in case there might be a problem specific to FSComm, I
> set up a clean install of FS 1.0.6 and tried transferring a call to the FS
> echo application with the same results.  By the way, I have no problems with
> blind transfers, only attended transfers.
>
> -Mardy
>
> On Apr 19, 2010, at 7:53 PM, Anthony Minessale wrote:
>
> did you try just setting up 2 phones on plain fresh FS install, and calling
> them normally and transferring them around?
> That description is still pretty vague? What is an Event Socket
> application, which has nothing to do with sip and sip transfers, that's a FS
> protocol.
>
>
> On Mon, Apr 19, 2010 at 6:33 PM, Mardy Marshall <mardy at voysys.com> wrote:
>
>> I have two phones (Polycom) and an event_socket application, all of which
>> are using a SIP proxy for call routing.  The first phone calls the second
>> phone.  The second phone then attempts to transfer the call to the
>> FS/event_socket application by first placing the call on hold and then
>> calling the FS application, followed by a consultative transfer.  The REFER
>> dialog occurs between the two phones and an INVITE w/Replaces is sent to FS.
>>  The transferred call leg appears to be answered by FS and the application
>> receives a uuid_bridge event with the UUID of the new call leg.  The problem
>> that I see is that the original call leg, created when the user called the
>> FS application to announce the transfer, does not get canceled by FS and
>> subsequently does not send the BYE back to the Polycom.  Is there something
>> that I need to do at the event_socket application to complete the transfer?
>>  I've tried killing the UUID associated with the first call leg as well as
>> issuing an "answer" command to the transferred call leg UUID, but no luck.
>>
>> -Mardy
>>
>>
>> On Apr 19, 2010, at 6:19 PM, Anthony Minessale wrote:
>>
>> but what is the client sending the REFER?
>>
>> FS gets refer+replaces all the time, if it's the one where the dest is on
>> another box (aka the nightmare xfer that you should see references to in the
>> debug log if so) then it will not complete until that far end call is
>> answered.
>>
>> FS handles this scenerio for us hundreds of times a day using a wide range
>> of sip devices so perhaps
>> your UA has an interop problem.
>>
>>
>> On Mon, Apr 19, 2010 at 4:47 PM, Mardy Marshall <mardy at voysys.com> wrote:
>>
>>>
>>> On Apr 19, 2010, at 5:12 PM, João Mesquita wrote:
>>>
>>> uuid_simplify will issue the refer...
>>>
>>>
>>> I looked at uuid_simplify and if I understand it correctly it is for use
>>> when one wants to act as the transfer controller.  In my case, FS is the
>>> transfer destination.  Another phone has already generated the refer and FS
>>> has been sent an invite with replaces.
>>>
>>>
>>> May I ask what application you are developing?
>>>
>>>
>>> An ACD.
>>>
>>>
>>> Regards,
>>> João Mesquita
>>> FSComm developer
>>>
>>>
>>> On Mon, Apr 19, 2010 at 11:27 AM, Mardy Marshall <mardy at voysys.com>wrote:
>>>
>>>> I'm having a problem with attended transfers where the destination of
>>>> the transfer is a FreeSWITCH based application such as FSComm.  (It should
>>>> be noted that in my setup the phone performing the transfer and the caller
>>>> which is being transferred are parties of another SIP server.)  What I see,
>>>> from a SIP signaling standpoint, is that after FreeSWITCH receives and
>>>> acknowledges the INVITE w/Replaces it does not terminate the initial call
>>>> leg by sending a BYE to the transfer controller.  From the FreeSWITCH
>>>> application side, FS still thinks that both the initial call leg and
>>>> transferred call leg are active.  I experimented with trying to explicitly
>>>> terminate the initial call leg by using uuid_kill, but this caused FS to
>>>> kill all legs of the call.  Is there a specific action that the application
>>>> must take in order for the transfer to complete?
>>>>
>>>> -Mardy
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 <MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
>> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 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
>>
>>
>>
>> _______________________________________________
>> 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 <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 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
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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 <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100421/263f29a9/attachment.html 