[Spce-user] monitoring registered clients

Matthew Ogden matthew at tenacit.net
Mon Aug 27 17:49:11 EDT 2012


Hi Guys,



I’m not an Kamalio expert, so I don’t really know what scales well etc.



So I must be honest the thread goes a little past what I currently know how
to use in something to implement.



I’m also not sure what I can and can’t do in terms of making calls to
something outside (if this is scalable or not) – I’m assuming making tons
of webservice calls is not very efficient J, which can track those
timestamps, and each time something missed, mark it, or report it to the
other system thats receiving these calls, where I can then report on
devices that have say missed 10 pings this last x minutes, or missed 20
consecutive pings at any point in y minutes and so forth.

But obviously you don’t want it to only scale to 20 clients and then fall
over.



We are small now, so I imagine this is quite possible. Other alternatives
would be SNMP traps or SNMP queries etc. My client devices are configured
themselves to use the options command anyhow every 10 seconds, if there is
anyway to get a log of the last x minutes chatter summary times, or max
interval in in the last x minutes where there was no chatter to a queriable
dataset, this would be good. I don’t want to go down a bad road, I also
don’t want to it to be “NASA ready”, it must just be workable for up to a
few hundred clients (although I’m nowhere near that in size now).



Regards





*From:* spce-user-bounces at lists.sipwise.com [mailto:
spce-user-bounces at lists.sipwise.com] *On Behalf Of *Skyler
*Sent:* 26 August 2012 08:50 AM
*To:* Jon Bonilla
*Cc:* spce-user at lists.sipwise.com
*Subject:* Re: [Spce-user] monitoring registered clients



Hi,



>From the server point of view, I've just seen this thread in the sip-router
mailing list. This might be useful as start for monitoring alive clients.

http://lists.sip-router.org/pipermail/sr-users/2012-August/074337.html

Once the "dead" clients are removed from registration, one could just check
registered vs provisioned subscribers.

We have freezed 2.6 and we're working hard on releasing it before the end of
this month. Once it's released we'll discuss the 2.7-2.8 roadmap and update
it.
Not sure if this kind of feature (over the time flapping subscriber
detection)
is something we can include in early or later releases. But it's something
we
could discuss in the mailing list and check what should be the best
approach.


cheers

Jon


 I saw that thread as well, its a great addition to Kamailio. Generally
speaking though, I personally prefer that the client-side be in charge by
sending NOTIFY to spce rather than the other way around. Monitoring from
SPCE is not a bad idea if all of your endpoints are an Asterisk or similar
PBX. Though a subscriber could be a soft-phone/mobile or ATA which may or
may not always be registered, so monitoring all subscribers would not
always 'fit'.



 A few months back I had ventured into end-device monitoring for ATA's and
while it was just an OPTIONS ping and email, it became a PIA receiving
100's of emails when ppl simply moved the device to another room or took it
with them on a plane for example. Also I really wanted to have more info on
the device since I was already communicating with it regularly; such as
calculating the MOS score. That turned out to be near impossible so I just
dropped the whole idea and moved on with placing the responsibility onto
the PBX rather than SPCE.



 What about creating a 'Monitor Subscriber' as an option for each
subscriber with an email address field to notify? I could see this working
as then you could enter the subscriber's email and they are notified that
"Hey, Your device is not working. Check that it is plugged to the
Internet." or something like that. Put the responsibility onto the person
that can 'touch' the device.



Skyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20120827/eb9a0244/attachment-0001.html>


More information about the Spce-user mailing list