Stop sending SIP OPTIONS packets

I´m working with Asterisk 16.3.0 throug FreePBX . I have 3 SIP trunks with a gateway (8 FXO). One trunk is on 5060 port, another in 5062 and the other one in 5064 (all at the same ip of the gateway). I have qualify=yes in all of them. SIP options packets are sent every 60 seconds. At certain time, after receiving the response to the SIP OPTIONS package, Asterisk stops sending the packages to one of the ports and never tries to send it again. The trunks on the other ports remain sending and receiving the packets. After a while another one of the ports is dropped. That’s why, at this point, there are two ports to which Asterisk does not send the packets, but another one does. If I restart the SIP module doesn’t change anything. When I restart the gateway, Asterisk sends the OPTIONS packets back to the three ports. Any ideas? Thank you

Which SIP stack are you using? In case you are using chan_pjsip you could keep the console open and watch for related messages like “Endpoint godot is now Unreachable” and then check whether the rest is still working, like aor(s). This would also tell you where to start to look in pcap traces.

I’ve seen a similar behavior before, but you’d need to describe your system with more details. In case you tend to lose the contacts and increasingly more aors are generated (if permitted), you’d likely have some other kind of network problem, but that’s currently impossible to diagnose.

Hi, these are the last two messages before port 5062 become unrecheable. The other two ports are still working (on the same ip)
‘4f757dd35edd9ac4286a9e500d21a348@’ Method: OPTIONS

[2019-08-23 17:01:51] VERBOSE[4367] chan_sip.c: Reliably Transmitting (no NAT) to
OPTIONS sip:Line@;transport=udp SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK37500bdd
Max-Forwards: 70
From: “Unknown” sip:Unknown@;tag=as3f496896
To: sip:Line@;transport=udp
Contact: sip:Unknown@
Call-ID: 19f1f5b50c50fe6e2e758bb21ca40c52@
User-Agent: FreePBX
Date: Fri, 23 Aug 2019 20:01:51 GMT
Supported: replaces, timer
Content-Length: 0

[2019-08-23 17:01:51] VERBOSE[4367] chan_sip.c:
<— SIP read from UDP: —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK37500bdd
From: “Unknown” sip:Unknown@;tag=as3f496896
To: sip:Line@;transport=udp;tag=76a55ab1e7e0a614
Call-ID: 19f1f5b50c50fe6e2e758bb21ca40c52@
User-Agent: Grandstream GXW4108 (HW 2.3, Ch:9)
Contact: sip:Line@;transport=udp
Supported: replaces, timer, 100rel, path
Content-Length: 0

The Grandstream GXW4108 is responding correctly to the OPTION request package, so I dont see nothing wrong here

Yes, that´s right, but those are the last messages. Then, suddenly, there an¿re no more SIP OPTIONS messages at port 5062. There are still messages for port 5060 and 5064. Some time later, the messages to the other ports are also ended.

If remote device is not responding to the OPTION request packages sent by Asterisk. Asterisk considers the device off-line for future calls, but it will retry again. verify if that happen on the console

No, there are not any more OPTION request messages from Asterisk. Why would Asterisk stop sending OPTION requests? And why one port yes and another no?

Maybe I’ve missed here something, but why would Asterisk send OPTION requests to a simple endpoint? I’d expect it the other way around. Endpoints with outbound registrations, for example, are something else.

To detect whether it is still present, so that callers don’t have to wait for an INVITE to time out. It is quite normal, and even default, to enable qualify in such cases.

1 Like

At this time, port 5060 is monitored and port 5062 is not. Doing a “sip show peer …” the differences are:
Expire : 1616 / Addr->IP :
Expire : -1 / Addr->IP : (null)
Now, there are no more SIP OPTIONS messages to port 5062.
When I restart the gateway, the SIP OTIONS will return at both ports.

This is an Issue you need to address directly on the Gateway, suggest you verify SIP setting, firmware upgrade or something else

That sounds like a registration has expired, and Asterisk isn’t sending the OPTIONS because it doesn’t know where to send them.

Adding to the David Teory , this confirm such teory IP address is NULL, so Asterisk doesnt know were to send the OPTION request package, look Gateway is not renewing the registration, and it only do it it is rebooted

Ok, yes, may be it´s something with registry. It´s strange as gateway is new, and it has the last firmware. Yesterday i have changed gw configuration and now it has fix IP (i removed DHCP) and now it’s been 24 hours without failure

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