Thaddeus,<br><br>FYI, doing an API from the dialplan is a piece of cake:<br><a href="http://wiki.freeswitch.org/wiki/Mod_commands#From_the_Dialplan">http://wiki.freeswitch.org/wiki/Mod_commands#From_the_Dialplan</a><br><br>
In your case put this line in your dialplan before you do the sofia_contact check:<br><font size="1"><span style="font-family:courier new,monospace"><action application="set" data="api_result=${sofia profile internal check_sync}"/></span></font><br>
<br>That should solve the problem of people wandering off and their SIP clients not unregging. Give it a try and let us know how it works.<br><br>-MC<br><br><div class="gmail_quote">On Tue, May 8, 2012 at 8:11 AM, <a href="mailto:thaddeus@thogan.com">thaddeus@thogan.com</a> <span dir="ltr"><<a href="mailto:thaddeus@thogan.com" target="_blank">thaddeus@thogan.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Thanks for the information, I have explored the sofia_contact option and it is promising, but I am unsure of how to make it work in my dialplan.<br>
<br>
I think I need to elaborate on the indended behavior some more. A user will have three possible routes by which they can be reached. Two SIP accounts and a POTS number. Each user has three routes but only two devices, a desk phone and a cell phone. The cell phone is a target of the POTS number and is also one of the SIP clients. I am afraid I did not mention the desk phone initially, and I apologize for my question being incomplete.<br>
<br>
Given this setup I want to select one of these two dialplans:<br>
<br>
1. If SIP on cell phone is registered, ring <DESK SIP> && <CELL SIP>.<br>
<br>
2. If SIP on cell is not registered, ring <DESK SIP> && <CELL POTS><br>
<br>
sofia_contact looks promising, however it returns a string indicating that a user is registered long after they have become unavailable. Example: User walks out of building and cell phone loses the Wifi connection. The SIP client did not un-register, it just went away. I have found that "sofia check_sync" will check all registrations and correctly identify clients that have gone off the network as no longer being registered.<br>
<br>
However, I cannot figure out how to run sofia_check sync before testing the output of sofia_contact in my dialplan, any thoughts on how to do this? Or is there a better way to get my above listed call routing to occur based on the availability of a SIP client?<br>
<br>
Also, I did investigate using continue_on_fail to check for hangup causes that did involve the SIP client being unreachable, but I could not make the above logic occur using only that setting. That is, I always want to ring <DESK SIP>, but only one of <CELL POTS> or <CELL SIP>, and never both simultaneously or in sequence.<br>
<br>
Might I need to go into a Lua script for this kind of logic?<br>
<br>
Thanks again for your responses!<br>
<br>
-- Thaddeus<div class="im"><br>
<br>
<br>
On Friday, May 4, 2012 12:34 PM CDT, Michael Collins <<a href="mailto:msc@freeswitch.org" target="_blank">msc@freeswitch.org</a>> wrote:<br>
<br>
</div><blockquote cite="http://CAKzWOxVYv_e3oPmyR+zwjv54zMK3shfQ6q5utXC9XBrwprKD3w@mail.gmail.com" type="cite"><div class="im">
Hi Thaddeus,<br>
<br>
You definitely have several options here. While you could use the<br>
sofia_contact API, I'm wondering if perhaps you could let the dialplan and<br>
the bridge app do the work for you.<br>
<br>
You could bridge directly to the Android user and then if it fails it could<br>
then continue in the dialplan and ring the mobile number. This is covered<br>
briefly on the wiki<u></u>,<br></div>
however <u></u>it is covered very nicely in the new FreeSWITCH<br>
Cookbook<u></u> in chapter 1.<div class="im"><br>
<br>
Try out the basic failover (pipe-separated list of endpoints) and if that<br>
doesn't work let us know. Maybe you could hop on IRC and talk live with<br>
other community members. Of course, it can't hurt to raise your karma by<br>
getting the FreeSWITCH books. :) (See <a href="http://freeswitch.org" target="_blank">freeswitch.org</a>, upper left corner.)<br>
<br>
Thanks,<br>
Michael<br>
<br></div><div><div class="h5">
On Fri, May 4, 2012 at 10:10 AM, <a href="mailto:thaddeus@thogan.com" target="_blank">thaddeus@thogan.com</a> <u></u>wrote:<br>
<br>
> I was wondering if there is a way to tell if a SIP client is registered<br>
> with a dialplan condition? Or maybe a better way to accomplish the<br>
> following?:<br>
><br>
> The users' cell phones (Android) are running a SIP client and connect to<br>
> freeswitch via Wifi when in the office. I want calls destined for a given<br>
> user to ring only their extension if they are connected via SIP, and ring<br>
> only their mobile number when they are not connected.<br>
><br>
> Currently I just take every incoming call and bridge it back out to their<br>
> mobile number, but 95% of the time these users are on the Wifi network, and<br>
> I could just pass the call to their phones via SIP.<br>
><br>
> I have tested hunt groups but the callers hear ringing for far too long.<br>
> Ring groups don't work because it is confusing when the user simultaneously<br>
> receiving the same call via SIP and mobile on the same phone.<br>
><br>
> Thanks in advance for any insights and help!<br>
><br>
> -- Thaddeus<br>
> _________________________________________________________________________<br>
> Professional FreeSWITCH Consulting Services:<br>
> <a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
> <a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
><br>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
> <a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
><br>
> Official FreeSWITCH Sites<br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
> <a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
> <a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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>
><br>
><u></u><u></u></div></div></blockquote>
<br>
<br>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><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>