[Spce-user] monitoring registered clients

Thu Oct 25 08:58:14 EDT 2012

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/20121025/326d45a6/attachment-0001.html>