We are having an issue where SIP peer (over WAN) is showing unreachable[Ref attached image 1.png]. We can telnet into 5060 port of the remote peer and also Option packet flow is Ok.
Just wondering on what basis asterisk marks peer as Unreachable when port 5060 is reachable and Options are replied by the remote peer as expected. [Ref attached image 2.png].
This appears to be happening since our Cisco router change, but with Options and Ping to port working ok, it would be interesting to know what asterisk expects to mark peer reachable in order to troubleshoot the issue.
This appears to be chan_sip, which is in the process of being removed from Asterisk (no longer in the development version).
Asterisk looks for any well formed response to OPTIONS, within the qualify time limit. Whilst there is nothing that contradicts that condition, there is not enough information to confirm it either.
Although it is unlikely that any bug in chan_sip will be fixed, please provide “sip set debug on” output, as text, not images, from /var/log/asterisk/full, after enabling that in logger.conf.
Asterisk is both a SIP server and client, and in the current context is a client, as it is sending the requests. If you mean the hardware on which the Asterisk daemon is running, even packets captured on that machine may not actually reach Asterisk, if the firewall blocks them.
That's odd... Got a response on a call we don't know about. Callid 3d71658a0598d8a8226a6f9b0ca552e7@192.168.99.5:5060
Quite true. Something has mangled the Call ID, which should be handled as an opaque string. The part that looks like an IP address, is really just one way of ensuring its global uniqueness
You do not modify opaque data. 202.xx.xx.22 in the outgoing Call-ID are just characters to be returned unchanged, although they may have been derived from an IP address, nothing should attempt to interpret them as one.
I seem to remember that chan_pjsip doesn’t even have an @ or an IP address in its Call-IDs.
Unless you have a Sangoma support contract (in which case you should not be asking here), you should not be using certified versions.
In any case, I’m not sure that chan_sip is supported in Asterisk 16 certified, and you may have had to have modified it from the certified form to use it. I’d also be surprised if Sangoma provided contract support for versions no longer receiving normal bug fixes.
For community support, you should be using at least 18.17.0 (and chan_pjsip).
Finally SIP peer is reachable after removed "externip=public IP " statement from sip.conf.
It seems new series routers behave differently with SIP NAT then earlier ones.
Whenever someone mentions “router”, “SIP” and “NAT” in a sentence (especially
in relation to “problems”) I immediately say that they should check whether
the router has a “SIP ALG” or “SIP gateway” function, and if so, turn it off.
A very few have such a function and do not allow it to be turned off, but I
have never yet come across a situation where turning it on makes life easier
for the person trying to use VoIP.
Would you say there has been a sort of race between NAT routers trying to be helpful with tunnelling SIP, and SIP endpoints trying to be smart to get through troublesome NAT routers, and the race has been won by the endpoints, so the routers should just give up?
