Does anyone know why the new GVSIP-NAF trucks are showing as offline? Incoming and outgoing still work.
Have noticed and was wondering the same.
Naf decided that he did not want to support qualify which would show you if the trunks are online or not. I dont know if he ever actually worked on supporting it or not with his methods.
Ok. I remember following those threads. Things moved quite fast. Perhaps it was a decision at the time to “get things working”?
As stands it’s an annoyance but not a major one. Better to have the trunks working than the graph but if can be made to play nice that would be great too.
As you were part of that discussion, do you think it can be relatively easily made working? I assume the request should be directed at NAF - any thoughts on best way to reach out?
You can try adding qualify_frequency=60 back to your settings
The reason was (probably still is) that GV did not reply to the OPTIONS packets that Asterisk uses for qualify. I would recommend you disable qualify and monitor the registration to verify that the trunk is online. That makes the most sense in this case because it’s a SIP Outbound (RFC 5626) connection.
@billsimon - Sorry - don’t quite follow. Where/how do I monitor the registrations?
@tm1000 if its true that GV doesn’t respond to those packets is there another way or can fpbx be tuned to support?
Except that the RFC covers, in numerous spots, the Keep-Alive process (both CRLF and STUN) for Outbound connections. These are meant to help keep NAT/Firewall rules open in the client side’s network when connecting to the server side. So basically the fact that GV is not responding to them or any form of client generated Keep-Alive means they are not following RFC 5626.
It’s not about keep-alive, it’s about how Asterisk uses the options method for qualify. GV’s crlf keep-alive works fine.
What do you mean by “How Asterisk uses the OPTIONS method for qualify”? Do you mean they use it differently than other B2BUA’s? SIP Clients? SIP Servers? OPTIONS is the standard method of Keep-Alive for SIP. Devices can either send Keep-Alives via OPTIONS or NOTIFY requests and the SIP server should be able to support one or both of those to handle those requests.
When you set qualify on a peer, Asterisk sends OPTIONS packets to the peer at a regular interval and reports the round trip time. Strictly speaking, this is not a keep-alive, though as you note, it is commonly used as one. (It is not “the standard method” according to any RFC. If I am wrong about that, please point out the RFC.)
RFC 5626 does not mention the use of the OPTIONS method for anything, let alone keep-alive. Keep-alive is done with CRLF pings and replies. Google Voice does not need to support the OPTIONS method for any reason.
Keepalive is configured in chan_sip with “keepalive” (https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L301) and in pjsip with keep_alive_interval (https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L1042)
That speaks of keepalive mechanisms, but what about using qualify to tell me whether the trunk is online? I personally do not trust qualify/OPTIONS packets to tell me whether my trunk is available.
- What if the provider doesn’t support OPTIONS? (GV)
- What if the provider responds to my OPTIONS packets but I am out of money and it rejects my INVITEs? Or I have no account with them? I can send OPTIONS packets to lots of SIP servers and get a positive reply but it doesn’t mean anything much.
- What if my registration failed? OPTIONS/qualify still tells me the trunk is up. But I won’t receive calls if I need to register.
Hope that helps clarify.
Thank you @billsimon. In depth and I understand now.
So what is a preferred method in your view? Is it monitoring registrations (as your earlier reply to me)?
And if so - how would I do that in FPBX? Is it something I can do in the dashboard or is this something you’re saying has to be outside of FPBX (like maybe a cron’d script parsing fpbx logs?)
As much as fix this particular issue, also trying to learn and follow along. Thanks so much.
Then that means GV is only using TCP because CRLF is only valid for connection based transactions. You cannot use CRLF over UDP. If you can use UDP over GV then they must support STUN keep-alives as well. Didn’t I see something in the GV setup to use a STUN server?
Part of using OPTIONS or NOTIFY for a “keep-alive” is to send out a request from the endpoint and keeping the NAT open in the router. OPTIONS automatically should be replied to with a 200 OK so that sends back a reply. NOTIFY can be used when OPTIONS is not supported. The NOTIFY is sent with an Event header that contains simply “keep-alive”.
The OPTIONS/NOTIFY process allows not having to rely on a STUN server or TCP.
Correct, GV SIP is TLS only.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.