[Freeswitch-users] Having a problem with attended transfer when FS is the transfer target
Anthony Minessale
anthony.minessale at gmail.com
Wed Apr 28 11:59:57 PDT 2010
I am not sure what you are talking about but the small patch I did was only
to the code that receives an INVITE+replaces and nothing else.
Also, I thought you said you took your custom application out of the mix and
was just doing a basic test with only sipX and FreeSWITCH.
you may want to re-think your approach.....
On Wed, Apr 28, 2010 at 11:30 AM, Mardy Marshall <mardy at voysys.com> wrote:
> I tried a new build created from git-head and the situation seems to have
> gotten worse. In my actual application, which is using the mod_event_socket
> API to communicate with FreeSwitch, I no longer receive any events
> indicating that a transfer of the call has occurred. Also both call legs
> remain active as FreeSWITCH never terminates the original call leg created
> for the transfer consultation.
>
> Prior to these latest changes, this is what I would observe:
>
> The station initiating the transfer would dial the destination extension,
> for example, extension 300, which is then redirected to FreeSWITCH.
> FreeSWITCH is configured with the following dialplan entry:
>
> <extension name="park">
> <condition field="destination_number" expression="^300$">
> <action application="socket" data="192.168.0.16:8086 async full"/>
> </condition>
> </extension>
>
> This initial "consultation" call will then launch my application which will
> communicate with FreeSWITCH via an outbound event socket connection.
> Later,when the station being transferred sends the INVITE w/Replaces to
> FreeSWITCH, FS would then create a new UUID and bridge that to the original
> UUID associated with the initiating call leg. In response to this, FS sends
> the application a uuid_bridge event which contains the other UUID. From the
> application side, I am able to respond to this uuid_bridge event and
> redirect the application to the new call leg. The problem is that the
> original call leg does not get terminated by FS and I haven't been able to
> terminate it via the API without ending up shutting down the whole session.
> To make matters worse, because FS did not terminate the original call leg,
> the station that initiated the transfer thinks that the transfer failed and
> sends a BYE to FS which then kills the session and drops the call. Yuck...
>
> -Mardy
>
>
>
> On Apr 27, 2010, at 3:43 PM, Anthony Minessale wrote:
>
> The problem here is that you were testing it against a 1 legged call (echo
> application is not bridged to anything)
>
> This code is usually only encountered when replacing a leg of a call.
>
> try git rev [8660b6f] or better
>
> I added a patch so the new channel executes the same app that the old was
> originally executing and hangs up on the original.
>
> Note, if you want the transferred call to pick up on the other call to the
> application in-progress you would have to loop the original call.
>
>
>
>
> On Tue, Apr 27, 2010 at 11:03 AM, Mardy Marshall <mardy at voysys.com> wrote:
>
>> The REFER exchange occurs on the other side of the proxy between the two
>> Polycom phones. Since
>> FreeSWITCH is the destination of the transfer, it will only see the INVITE
>> w/Replaces. I've sent you the
>> PCAP file which captures the complete SIP exchange. That should help to
>> clarify.
>>
>> -Mardy
>>
>> On Apr 27, 2010, at 11:47 AM, Anthony Minessale wrote:
>>
>> There is no sign of a REFER packet or anything indicating an attended
>> transfer in this trace.
>> Did you send the wrong one possibly?
>>
>>
>> On Mon, Apr 26, 2010 at 2:50 PM, Mardy Marshall <mardy at voysys.com> wrote:
>>
>>> Here is the setup that was used to reproduce the consultative transfer
>>> problem.
>>>
>>> There are two boxes, the first is running a proxy based PBX (sipXecs) and
>>> the
>>> second is running FreeSWITCH 1.0.6. The PBX has two Polycom phones,
>>> extension
>>> 200 and 202, registered with it. The PBX has configured a mapping rule
>>> which
>>> will transform requests to extension 9996 to sip:9996 at 192.168.0.16:5060which
>>> is the address of the second box running FreeSWITCH. FreeSWITCH has been
>>> configured to allow connections from the PBX box via an ACL configuration
>>> and
>>> the public dialplan includes an "echo" extension:
>>>
>>> <extension name="echo">
>>> <condition field="destination_number" expression="^9996$">
>>> <action application="answer"/>
>>> <action application="echo"/>
>>> </condition>
>>> </extension>
>>>
>>> Any of the phones registered with the PBX can dial extension 9996 and be
>>> connected to the FreeSWITCH echo application. But when one phone
>>> attempts
>>> to transfer another phone to extension 9996 via a consultative transfer,
>>> FreeSWITCH does not properly complete the transfer. You can see in the
>>> log
>>> at 18:55:58.4295322851 the INVITE w/Replaces is being sent to FreeSWITCH.
>>> FreeSWITCH accepts the INVITE but never sends a BYE to the phone which
>>> initiated the transfer. Without that terminating BYE, the transfer
>>> controller thinks that the transfer failed.
>>>
>>> The corresponding FreeSWITCH log file -
>>> http://pastebin.freeswitch.org/12806
>>>
>>> If it will help, I can also forward a corresponding PCAP file.
>>>
>>> Thanks
>>>
>>> -Mardy
>>>
>>> On Apr 21, 2010, at 11:23 AM, Anthony Minessale wrote:
>>>
>>> I'm trying to understand this:
>>>
>>> If FS is acting as a phone in your scenario why are you sending a refer
>>> to it and not the server?
>>> In most situations there is a b2bua server who routes the calls and takes
>>> all the REFER.
>>> Is this one of those PROXY only sip servers?
>>>
>>> I think you would need to produce a full debug log of this, and if you
>>> are using some kind of proxy based setup we would need some way to easily
>>> reproduce it or visit your lab because we do not typically use anything of
>>> the sort.
>>>
>>> Execute these commands and reproduce it and capture the whole log and put
>>> it on
>>> http://pastebin.freeswitch.org
>>>
>>> sofia profile internal siptrace on
>>> console loglevel debug
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 21, 2010 at 9:13 AM, Anthony Minessale <
>>> anthony.minessale at gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100428/c4869b7a/attachment-0001.html
More information about the FreeSWITCH-users
mailing list