[Spce-user] monitoring registered clients

Matthew Ogden matthew at tenacit.net
Mon Oct 29 03:26:15 EDT 2012


I have both Linux and Windows servers available.



(I’m and MS type background developer, so generally that’s easier for me to
implent in windows), but the tools aren’t always the most diverse.



For “dead” type clients, I guess we can’t cater for them “perfectly”,
except we could catch an “unavailable” as them being down, and registration
renewal as them being up (it would be larger time frames), but isn’t it
only ATAs that are generally guilty of this?



Kind Regards









*From:* Skyler [mailto:skchopperguy at gmail.com]
*Sent:* 25 October 2012 10:39 PM
*To:* Matthew Ogden
*Cc:* spce-user at lists.sipwise.com
*Subject:* Re: monitoring registered clients



SPCE does handle NAT, but it does not keep a 'NAT-hole' open on the
client-side firewall by default. This is where the NOTIFY comes in from an
end-point device/software and (with my patch) SCPE will reply "200" if
authorized, in order to keep the hole open, for inbound calls to the device.

 Monitoring any UA which is behind a router is by design, near impossible.
No ping to the inside from the outside. So for these server/devices, they
need to be programmed locally to ping SPCE and then SPCE must know what to
do with that.

 Another hurdle is devices/software. Not all will accept OPTIONS pings so
some devices will never reply if you send out anything.



 Basically, if you want to monitor as many UA types as possible you'll need
to have a Client > Server monitoring strategy. Let the devices tell you
when they are online or not.



 I'm thinking you are on the right track with using Presence with PUBLISH
and SUBSCRIBE. So when a UA sends a OPTIONS or a NOTIFY, spce can be coded
to then submit a PUBLISH on behalf of the UA. Then for actual monitoring,
you can SUBSCRIBE from another server. Do you already have a separate
monitoring server which is running Linux?



--Skyler



On Thu, Oct 25, 2012 at 5:58 AM, Matthew Ogden <matthew at tenacit.net> wrote:

Thanks Skyler.



Ok, your ramblings are useful, mine, are just ramblings.



I would like to primarily monitor UACs, but monitoring UASs is probably
just as important (although its far more obvious when they aren’t working).



Basically I want monitor that the SIP subscription is still there, (that
for some reason they aren’t subscribed, and won’t be able to receive an
inbound call). I don’t have any mobile clients yet, so am not worried about
that yet.



The how I extract this is also important to me, I think it should be
interoperable for other platforms, (and my thoughts jump to SNMP or
something like that) to expose it to a host of platforms, exposing things
like:

“Registered”: yes/no

“Pingable x seconds ago” : 1 to 99999999

Last inbound x seconds ago : 1 to 99999999

Last outbound x seconds ago : 1 to 9999999



I guess the reason I jump to SNMP is we currently we monitor hundreds of
IPs using SNMP, and its across so many different devices, and most SNMP
programs support the ability to monitor so many different things (Temp, UPS
online, data rates, open ports, .... and hopefully “registered”, x seconds
ago etc. But, I would happily agree to the most accessible method is for
everyone.



Other alternatives are just something else that is doing the work. For
example a trusted client, whom is doing this query, and then exposing it to
some program that a company uses. So its asking the SPCE, “are they still
there”, but SPCE will say they are even if last OPTIONS failed, so long as
the client is still subscribed (is my current understanding) – and you
might get false rings, if you are trying to do this with an INVITE?



My first object is just querying that a client is up on very short
intervals and feeding it back to our monitoring application, which I use
with SNMP, or http gets, the problem is, OPTIONS is on shorter notice, and
much realistic, and tells you a client is flapping up and down. Or SPCE
pushing to a webservice that a client hasn’t reported in. Where from I can
do anything I want with the info.



I would have thought that NAT wouldn’t have made a difference, because SPCE
deals with it already, but obviously at this level of configs, you need to
deal withit yourself.



I have a mix of NAT clients and non-NAT clients.



I don’t have any NATd peers, but I do have peers some peers that are IP,
and some that require SIP Auth.



Kind Regards



*From:* Skyler [mailto:skchopperguy at gmail.com]
*Sent:* 25 October 2012 02:05 PM
*To:* Matthew Ogden
*Cc:* spce-user at lists.sipwise.com
*Subject:* Re: monitoring registered clients



Hi,



 So after re-reading, let me ramble a bit so we're on the same page. Think
of OPTIONS as pinging. When you want to see if a web-server is online, you
ping it and it replies. The standard reply from a PROXY is "200", "Alive"
or sometimes an options_reply() is used which just adds a bit more info to
the reply. Really up to the admin as a Proxy allows that control.



 On a PBX, Asterisk for example handles OPTIONS a bit differently. If we
send Asterisk an OPTIONS ping, it is hard-coded to lookup the RURI locally
and reply accordingly. So let's say that the RURI is
sip:916254578777 at mydomain.com, Asterisk will receive this and lookup in its
local subscriber base and if found, replies with "200", "OK" or if not
found then "404", "Subscriber Not Found". This is probably what you are
expecting (different replies) but spce is not doing this.



 Here's why. Spce is a proxy, so it only does what the admin codes in the
config. By default, that is "200", "Alive". So what you are seeking must be
coded into your config by you.



 Now back into monitoring ;)



  There are a few ways to monitor UAC/UAS from a Proxy but before diving in
and trying to "Jam" some kind of code in the config, you need to define
your goal. The same way you would complete a layout/design of a web page
before jumping in and coding it.



 First, are you monitoring other servers (UAS)? Are these Peers? Are they
Registered as subscriber ... both? Are any behind Firewall(s) (NAT)?

 Second, are you monitoring end-user devices (UAC)? Are these behind
Firewall(s) (NAT)?

 Third, what do you want to have happen if any of the above are found to be
unreacheable?



 From here, we can start deciding on which module(s) to use and how the
code will begin to shape.



--Skyler







On Thu, Aug 30, 2012 at 11:52 AM, Matthew Ogden <matthew at tenacit.net> wrote:

Hi Skyler,



Not sure if you’ve seen my other email regarding OPTIONS from one
subscriber to another not working.



What do you think is better if I want the data into another system?
Creating a monitoring subscriber sending options to all other subscribers
(I don’t seem to get the reply I want, it always says ALIVE... like the
proxy or LB is saying its fine).



If I do it from inside SPCE, where would I “jam” the code in, I’ve looked
at all the tt2 files, and cant actually find where I would put it into.



I was also thinking (as per another post which now one has replied to), I
could create a subscriber who SUBSCRIBE (like you would for presence) to
all the customers I need to, and fetch this info, then I could log it on
another system, and if its down for what ever predefined intervals I setup,
take some action.



Kind regards





*Matthew Ogden*

Management

TenacIT







*Strategic IT Consulting *•* Advanced Networking *• *Virtualisation*

*Custom Development *•* Hosting *•* Syspro Support  *• *MS Licensing*

Tel: 041 10 10 100 | Cell: 084 205 4445 | Email: matthew at tenacit.net

Skype Name: matthew.ogden | Web: http://www.tenacit.net









*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/20121029/0dcb71a6/attachment-0001.html>


More information about the Spce-user mailing list