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
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.
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@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@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@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
_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@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@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900
_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@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@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@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_wireAIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/
PAYPAL:anthony.minessale@gmail.com
IRC:
irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@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@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900
_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org