I’ve been wondering if there is a way to monitor peers without actually enabling SIP Qualify,
Currently the Asterisk engine that i’m using, for some reason, suddenly disconnects Peers,
And today, I had an incidence where a Peer went unresponsive, since SIP Qualify was disabled, the peer wasn’t being monitored,
Any idea how can i send “manually” via external script
sip qualify peer $PeerName / pjsip qualify $EndpointName
And read the result?
Or if there is another way of generating SIP OPTIONS method, not via Asterisk
Any suggestions will be greatly appreciated
I don’t think that this is a good approach. If a peers/endpoints go away, you need to find out why. If it is really a missing reply to an OPTIONS request, then the first thing to check would be to verify that it is not a NAT related problem. In case everything happens inside a LAN segment, this is a relatively unlikely cause.
I’d assume that most people use options either to ensure that calls fail quickly if there is a loss of connectivity, or for the side effect that they may keep dynamic NAT and firewall rules open.
It seems to me that you want to know if the connectivity is lost when there is no real traffic, but you want real traffic to time out, rather than be immediately faulted when there is a loss of connectivity and real traffic.
OPTIONS is only used because it is end to end, but has minimal effect on the UAS. You could probably make calls to an invalid number and see how that fails, rather than using OPTIONS. (This may fill logs and might trigger intrusion detection.)
I think the OP wants to know that there is a problem, without real traffic and without the contact being disabled. show contacts will only show a problem when the contact has been disabled.
To some extent, this is a case of shooting the messenger.
Dear EkFudrek*, Thanks for your suggestion,
The thing is that, im trying to somehow, receive an e-mail from a script that can read asterisk prompts after i request a SIP Qualify manually,
I cannot enable sip qualify to my asterisk server, and i cannot update it yet.
So, in order to keep my peers monitored, i require to somehow generate a SIP OPTIONS and read if there is any reply,
If you know any tool/service, please let me know
Exactly David,
Since i don’t have my peers with QUALIFY enabled, calls will always timeout, at least, for the amount of seconds configured from Dial APP
I don’t know if there is another tool to generate SIP OPTIONS and then prompt out the result in order to process the information and send an e-mail of any threshold is being triggered
Just in case, i can’t enable QUALIFY because for some reason, suddenly all the Peers disconnect (Could be that some sip peers have the same IP and there are 30+ :/)
Any further suggestion will be greatly appreciated
Warm Regards
I actually prefer not to qualify, not even for NAT (I’d rather fiddle with the router’s internal NAT tables, which is rather easy with OPNsense or pfSense). If an endpoint becomes unreachable, Asterisk will complain anyway, but that was also not the real question.
My point was essentially, that one needs to look at the possible causes with other tools. Diego’s replies actually suggests that there is a network problem.
Assuming these are incoming SIP registrations to your PBX, you could try lowering the expiration timeouts in the PBX configuration files for pjsip and/or sip. That might be enough to work around whatever piece of the network is closing these connections early, especially if the PBX is the only thing that you can somewhat control.
Dear @penguinpbx
Thanks for your advices, I’ve tried modifying those parameters before, but, somehow the “network” issue happened again. Thats why i’m not willing to re-enable SIP Qualify, at least for chan sip in asterisk 16.
I think that there is no way to monitor a peer outside asterisk QUALIFY, so i will try to migrate to pjsip and then enable endpoint monitoring.
I’m not aware of any feature in chan_pjsip which would be different from chan_sip in this respect. If anything it is feature poor, in that it doesn’t use the measured round trip time to set the first attempt timeout.