[Spce-user] monitoring registered clients

[Skyler]

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/20121025/479bc89f/attachment-0001.html>