<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>-Mardy</div><div><br><div><div><br><div><div>On Apr 19, 2010, at 6:19 PM, Anthony Minessale wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">but what is the client sending the REFER?<br><br>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.<br>
<br>FS handles this scenerio for us hundreds of times a day using a wide range of sip devices so perhaps<br>your UA has an interop problem.<br><br><br><div class="gmail_quote">On Mon, Apr 19, 2010 at 4:47 PM, Mardy Marshall <span dir="ltr"><<a href="mailto:mardy@voysys.com">mardy@voysys.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><br><div><div class="im"><div>On Apr 19, 2010, at 5:12 PM, Joćo Mesquita wrote:</div>
<br><blockquote type="cite">uuid_simplify will issue the refer...</blockquote><div><br></div></div>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.</div>
<div><div class="im"><br><blockquote type="cite"><div><br></div><div>May I ask what application you are developing?</div></blockquote><div><br></div></div><div>An ACD.</div><div><div></div><div class="h5"><br><blockquote type="cite">
<div><br></div><div>Regards,<br clear="all">Joćo Mesquita<br>FSComm developer<br>
<br><br><div class="gmail_quote">On Mon, Apr 19, 2010 at 11:27 AM, Mardy Marshall <span dir="ltr"><<a href="mailto:mardy@voysys.com" target="_blank">mardy@voysys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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?<br>
<br>
-Mardy<br>
<br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br></div>
_______________________________________________<br>FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br><a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div></div></div><br></div><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net/">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
_______________________________________________<br>FreeSWITCH-users mailing list<br><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>http://lists.freeswitch.org/mailman/listinfo/freeswitch-users<br>UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users<br>http://www.freeswitch.org<br></blockquote></div><br></div></div></div></body></html>