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

[Anthony Minessale]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100419/9b6f413d/attachment.html