[Spce-user] monitoring registered clients

[Skyler]

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/mailman/private/spce-user_lists.sipwise.com/attachments/20121025/b75c4930/attachment.html>