Odd little project I'm trying with SmokePing - but can't find a way to get asterisk to 'ping' a registered set (send an OPTIONS)

Asterisk Asterisk Support
1

I’ve been hacking around with this thing I want to do with Smokeping, and I’m almost too ashamed to ask for help, because it’s pretty weird, what I’m trying to do.

Put simply, we use SmokePing a lot for graphing network trends for the simple reason that it’s something even a very non-technical customer can understand. Tell people they have network problems and their eyes glaze over (or they get mad at you). Copy paste their graph from SmokePing, and they usually stop arguing (or at least that’s what we’ve found).

Problem is, SmokePing uses ICMP, and it’s pinging their WAN gateway/firewall/NAT, not the sets themselves.

So, what I’d like to do is send an OPTIONS message instead of a Ping. The only way Asterisk seems to be able to do that is with Qualify, but in that case, I’m not really getting what I want out of it, and also I risk taking the set out of service.

I just keep thinking there’s got to be some simple thing that’s staring me straight in the face: I want to send an OPTIONS message through pjsip to a registered endpoint, and track the reply (latency, jitter, loss, etc).

I’ve swallowed my pride, and am posting here.

Any and all ideas are welcome, other than writing something in Python. And yes, I know I can install a proxy, or some other non-asterisk tech, but that’s way out of the scope of what I want to do, which should be simple (hacking SmokePing to do this will be kludgy enough, so I want the Asterisk end of things to be as simple as it can be).

Oh, and the reason I want to pipe this through Asterisk is that I don’t want to have to muck about with ports, keys, auth, and what-all-else; the connection is already there.

You know what would be awesome? Having an option for qualify that tells it to just qualify the set and report the results, but don’t take it out of service if it fails. Just log the outcome and take no action.

Anyhow, this is a low-urgency science project for me, but I could see myself paying a bounty for someone to cook something up that would be useful to anyone who might want to be able to ask Asterisk to probe an endpoint and spit out the results, especially if it’s a simple new feature.

Am I missing something obvious here?

2

What you’re up to could be seen as a pimped DoS attack. I also question the purpose of the project. You can’t measure more than latency and that’s already built into Asterisk, albeit in a rudimentary way. Apart from that, SIP OPTIONS requests cannot be compared with ping requests. Some service providers require the requests to be authorized i.e. you would need a working SIP account.

3

For connectivity testing, you don’t need an 200 OK. 401 Unauthorised, or even 403 Forbidden, still indicate good connectivity. 404 Not found is commonly accepted for this.

Of course, if they run anything similar to fail2ban, multiple 401s could result in connectivity being removed.

4

hmm not a bad idear
one way to do it would be, having you SipSmoke connect to asterisk via AMI and listen for events
and then make a patch to asterisk that will add an option to send AMI events each time is do a Qualify
for chan_sip you could see the latency in sip show peers, but I belive that has not been implimentet for chen_pjsip
but I belive Asterisk keep track of it it is just not avalibe in CLI or AMI

6

What you’re up to could be seen as a pimped DoS attack. I also question the purpose of the project. You can’t measure more than latency and that’s already built into Asterisk, albeit in a rudimentary way. Apart from that, SIP OPTIONS requests cannot be compared with ping requests. Some service providers require the requests to be authorized i.e. you would need a working SIP account.

The goal isn’t to hammer the endpoint; it’s not really much different from what qualify does. How is data passing between two nodes a DoS attack? As for authentication, the set is registered to Asterisk, so both ends have the authentication needed to pass authenticated messages. I’m not following your logic here.

7

I think the contact and RTCP values give this kind of information. Nothing else is needed.

8

A well configured PBX does not get a lot of traffic from the outside that exceeds the bandwidth that is required. Within a LAN there is no need to hammer an endpoint.

In real life the OPTIONS information is almost useless. Today the phones might behave quite well, but in case a user complains that a call was bad three days ago, you can’t say anything. The usual approach is to hook up a Homer server to the PBX, which gives all the necessary information. Sometimes the problem is not the own PBX or the own phones.

9

Why not use Homer and its API (if you have a larger system)? If you query the contact information you do get the RTT values of the last CONTACTS request and there are ways to do that with AMI.

10

one way to do it would be, having you SipSmoke connect to asterisk via AMI and listen for events
and then make a patch to asterisk that will add an option to send AMI events each time is do a Qualify
for chan_sip you could see the latency in sip show peers, but I belive that has not been implimentet for chen_pjsip
but I belive Asterisk keep track of it it is just not avalibe in CLI or AMI

As far as I can tell, if qualify is turned on, there is always a risk the set will be taken out of service, even if it’s only experiencing minor packet loss. So, the desire is to sample the connection at defined intervals, and graph that, without it affecting the availability of the endpoint, and without having to install a bloated third party server (which is too much like the tail wagging the dog for my liking, although Homer does look like an amazing product).

11

hmm yes but you can always set qualify=2000+
also if Asterisk do not recive an answer it will resend the qualify to try reestablich connection
so it a peer go offline there is realy no point in try calling it
I would reater trace a problem to find out that the endpoing is logged as lagged in the log several times than trying to figure out way a call faild after with no reason in the log

12

hmm yes but you can always set qualify=2000+

If the reply is not forthcoming (due to packet loss), I don’t see how increasing the timer will help.

also if Asterisk do not recive an answer it will resend the qualify to try reestablich connection
so it a peer go offline there is realy no point in try calling it

This isn’t about whether to call the endpoint or not; it’s about graphing connectivity trends on lossy connections. Measuring replies and latency allows smokeping to provide a simple and easy-to-understand graph showing loss, latency and jitter. If for example a client is on a DOCSIS connection, network conditions on oversubscribed spans will frequently suffer when load is high (in residential areas this might be evenings, and in business areas M-F 9-5). A graph plotted over time shows this very clearly.

I would reater trace a problem to find out that the endpoing is logged as lagged in the log several times than trying to figure out way a call faild after with no reason in the log

I don’t really feel like chasing down calls one by one. A scheduled probe, that runs every 5 or 10 minutes (not much different from a keepalive), will over the course of a week or so provide a very clear picture of whether there is packet loss, latency, and jitter. We already do this to great effect with ICMP, but many firewalls ignore it, and none will pass it without specific configuration. The advantage of using qualify is that the connection through the firewall is already established, so we’re just piggy-backing on an existing, secure connection.

13

yes I thing we agree on the basice we just have diffren enviroment that require differnt tweeking to get the best result
I always loved testing SIP/GSM at Burning Man

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.