[Freeswitch-users] Email notification when user unregistered?

[Steven Ayre]

Sofia's gateways achieve this by doing a SIP OPTIONS ping. Gateway is
marked as down if several timeout or return errors in a row (1 on its own
isn't enough as it's a single UDP packet - you don't want to mark it as
down if a single packet is lost).

That's only for outbound registrations though, AFAIK FS cannot do the same
for inbound registrations. Though it could, in theory.

The time to detect they're offline will still not be immediate though - you
need to periodically do the OPTIONS ping and have several fail before
marking it as unregistered - so it'd still be say half a minute before FS
saw it had gone.

-Steve




On 12 December 2012 20:43, Sean Devoy <sdevoy at bizfocused.com> wrote:

> I have looked into this a few times, sip messaging does not lend itself
> well to detecting a missing client – until you actually try to reach it!  I
> have pondered some kind of a SIP message to use like an IP “ping”, but I
> have nothing yet.  Maybe someone who actually knows “sip messaging” could
> suggest an innocuous sip message to send as a means of testing availability.
> ****
>
> ** **
>
> In the meantime, my best suggestion is a DIALPLAN that has some redundancy
> for failed bridge connections. That is if the initial bridge fails
> (continue on fail), send yourself an email indicating that EXT is DOWN and
> redirect the call with another bridge statement. It is Reactive rather than
> Proactive, but it is very simple to setup and extremely reliable.  You can
> even include playing a message like “There is a problem reaching that
> extension, please hold while we redirect your call.”****
>
> ** **
>
> Hope that helps.****
>
> ** **
>
> Sean****
>
> ** **
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Avi Marcus
> *Sent:* Wednesday, December 12, 2012 3:13 PM
> *To:* FreeSWITCH Users Help
> *Subject:* Re: [Freeswitch-users] Email notification when user
> unregistered?****
>
> ** **
>
> That expiry event is something to watch.****
>
> ** **
>
> Also, you might want to monitor your CDRs if a call to a registered device
> doesn't respond:****
>
> if variables->progress_mediamsec + variables->progressmsec = 0, then that
> means the remote destination never sent a progress media. Although, that
> seems to also occur if it replies with a "user_busy" so I haven't fully
> nailed this one down yet. Let me know if you figure that one out.****
>
>
> ****
>
> -Avi****
>
> ** **
>
> On Wed, Dec 12, 2012 at 9:55 PM, Steven Ayre <steveayre at gmail.com> wrote:*
> ***
>
> Reading the source, FS will only periodically scan the database for
> expired registrations and fire the sofia::expire event then. The period
> between polling the database will cause a delay between the registration
> expiring and the event being raised.****
>
> ** **
>
> The default is to check every 30s, but can be adjusted with the sofia
> profile param registration-thread-frequency. Remember lower values may
> raise the event sooner, but will increase load because you're checking the
> DB more often. Since the expiry is already going to be a certain amount
> after the device disappears a few seconds probably won't make much
> difference - 10s vs 30s may sometimes save up to 20s but if the expiry
> period was 30 minutes that's not going to be enough to care about since it
> may already have been offline for almost half an hour at that point.****
>
> ** **
>
> The registration expiry time comes from the client, but you can override
> it from FS:****
>
> http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#sip-force-expires
> ****
>
> ** **
>
> -Steve****
>
> ** **
>
> ** **
>
> On 12 December 2012 19:47, Steven Ayre <steveayre at gmail.com> wrote:****
>
> You'll need to manage your expectations here.****
>
> ** **
>
> SIP registrations start when the client sends a REGISTER, with an expiry
> time. They then periodically send additional REGISTERs to remain
> registered. They can be spread quite a long way apart - several minutes.**
> **
>
> ** **
>
> A client explicitly unregisters by sending a REGISTER with a 0 expiry
> time, ie the registration expires immediately.****
>
> ** **
>
> If the client has gone offline because of reboot, network problem etc it
> won't send that final REGISTER. You won't see the client unregister until
> the end of the expiry time when the client hasn't renewed its registration.
> ****
>
> ** **
>
> Since that's several minutes later, there's no way to see that they have
> unregistered *immediately*. You may be able to reduce the expiry time to
> detect they're offline quicker, but that will increase bandwidth and load.
> ****
>
> ** **
>
> ** **
>
> ** **
>
> As for actually how to detect the unregistration... I suspect the 2 events
> you want to listen for are sofia::unregister and sofia::expire. The names
> suggest the 1st will be for an explicit unregister and the 2nd for when the
> client fails to reregister within the expiry time. That means the 2nd'll be
> the one you'd see if the client goes unexpectedly offline.****
>
> ** **
>
> ** **
>
> -Steve****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On 12 December 2012 17:52, 王理 <itispip-qq at hotmail.com> wrote:****
>
> Hi Freeswtich Master,****
>
> ** **
>
> I'm in a situation where I need to proactively moniter whether some
> device/extension is on in my local network; If for some reason the devices
> are offline, I need to be noticed immediately so that I can restart the
> device;****
>
> ** **
>
> Previously I  use xlite client to suscribe to the presence notification of
> the devices, but recently added some devices which not supporting presence
> notification, so I want FreeSwitch to send an email notification when some
> user/extention are getting unregistered;****
>
> ** **
>
> How can I capture a Feeswtich user unregister event & launch a LUA script
> then?****
>
> ** **
>
> Happy days!****
>
> ** **
>
> /Brgds, Alex****
>
> ** **
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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****
>
> ** **
>
> ** **
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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****
>
> ** **
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121212/5d0873b3/attachment.html