Since upgrading my test system to Asterisk 16.17.0, I’ve had an issue twice now where chan_pjsip seems to stop processing some calls. The first time this happened, a particular endpoint couldn’t make outgoing calls, and I noticed a bunch of identical dead air call attempts were stacked up in “pjsip show channels” so I just restarted Asterisk and things started working again. Now, after several days of things working fine, this same endpoint can’t receive incoming calls.
With this endpoint that currently can’t receive calls, there are two scenarios happening. In the first scenario, when someone calls one of my DIDs, I see an INVITE come in through the Asterisk console and there is no acknowledgement sent back from chan_pjsip at all. The provider sends a few more invites before giving up (the CSeq remains the same on all invites).
The other scenario is that the provider sends me an INVITE and chan_pjsip sends back Trying, but doesn’t do anything else. Dial never gets executed (which is the first thing the dialplan should do for a call coming into this extension). Eventually my provider sends me a few CANCELs and PJSIP never sends an OK.
I’ve placed a few test calls over approximately a ten minute span, and these two scenarios continue to happen. I haven’t restarted Asterisk or PJSIP because this problem isn’t hurting anyone at the moment, but I will have to restart by the end of the day.
Does anyone know why this might be happening and what I might be able to do? I set this system up for testing and I definitely can’t switch my production system to 16 unless I can figure out how to resolve this.
I didn’t start asterisk with the g option, so based on that article I gather there nothing I can do to get debug information unless I kill asterisk and restart it with g. However, I haven’t had my breakfast or coffee yet so I’ll look this over again later.
root@cloud:~# ps -C asterisk u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 12611 0.7 6.5 1645220 66516 ? Ssl Apr07 42:04 /usr/sbin/asterisk
I have got the same issues since I moved from Asterisk 13.36 to Asterisk 16.8, one month ago. I thought that it was only limited to my system, due to an error regarding chan_pjsip configuration, but you described exactly the same problems.
After investigating with my SIP Provider (OVH France), we listed :
incoming REGISTER without answer
first INVITE, followed by trying and then nothing else, and then awaiting 5 sec to send the 200 ACK to the cancel request coming from my provider due to a lack of response
It not applies on all calls but on some of them, when not registered.
I will also generate the core dump to investigate the deadlock “assumption”
I also upgraded from 13 (I don’t remember which minor version) to 16. Could this have something to do with an upgrade path vs a fresh install? I wouldn’t think so, but I remain open minded.
If you reload chan_pjsip or restart Asterisk, does the problem occur? Your problem description lets me remember an issue with another European provider, but I’d need more details.
If the problem never occurs after a restart, then I have more questions. You’d need to check the registration status and the status of the aors (or simply pjsip show contacts).
FYI : i did not upgrade the system, it is a fresh install of the 16.8, but I reused the config files of my previous running instance (13.36 with chan_pjsip), that’s why I am looking for some issues regarding the parameters of the chan_pjsip.
Can you switch back to the old system and check whether the problem does not occur?
The reason why I am asking is that sometimes providers change things themselves. Not related to this problem, I recently read about an announcement that one of the larger providers changed some things how their DNS servers work. I don’t really know whether they changed things, but there was an announcement that simple name lookup won’t work after April, 1.
You could also check the states of the OVH connections in the router. I guess they allow tcp as well, so one could check that for signalling as well. In case of tcp, you should see 1 or more established connections permanently.
On my system, the issue doesn’t occur immediately after a restart. In both cases the issue occurred about three days after starting Asterisk.
I recompiled with DONT_OPTIMIZE last night so that hopefully I can provide a better core dump, assuming the issue comes up again. It’s been about 15 hours and no issue yet, but I think both of the previous times this issue occurred, the system was up for three days.
I switched back to the old system, and i have got the same issue of “missed calls”.
Upgrading from 13.36 to 16.8 could not be the problem… but a change in the provider’s infrastructure could be: I asked OVH to investigate on their side…
They might not know themselves, , or at least the people that usually talk to customers. Please publish your registration configuration. I have something specific on my mind, but I’d like to first check that before I open my mouth.
You could check whether they rotate IP addresses for siptrunk.ovh.net. Asterisk always resolves names and by that the IP addresses might get out of sync. For example, it could be that your trunk is still registered to an old address, while the new call uses a different IP. Then it would depend on what the OVH servers are doing and whether you still have a valid registration.
I did not find what I was looking for.
For long-term observations I would attach a HEP server to Asterisk. HOMER is pretty easy to set up as it comes as a container and the configuration is trivial. Of course, you can also dump everything into a flat file, but searching for problems in thousands of lines is no fun.
And this is one of the commonest mistakes in cha_sip configurations, typically those copied and pasted from ITSP recommendations. It is normally fairly harmless, though.
, or at least the people that usually talk to customers. Please publish your registration configuration. I have something specific on my mind, but I’d like to first check that before I open my mouth.