We have an issue where occasionally, and it can go months in between the events, PJSIP will go unresponsive showing no registered contacts. When this happens, Asterisk can’t be restarted. To kill the process, we have to restart the server.
This time, we were able to at least find this as the last entry in the PJSIP log, happened at the exact same time and no entries afterwards. This is a heavily used server, so here’s where PJSIP just stopped (apparently?).
Could this be the culprit? If so, is there a way to prevent it? Note this isn’t any of our known IP addresses, somewhere in Korea.
pjproject: sip_transport.c Error processing 94 bytes packet from UDP 222.102.5.185:6486 : PJSIP syntax error exception when parsing 'Request Line' header on line 1 col 3:
i.]dkkl."H #^B,,9$KV^WRo
g^La^\.^EYKn{(Sf^S?^T6^G4Y
a^EC^EQ^Y^\#^H&^K^U^G'C^L
-- end of packet.
That looks like a problem in the upstream code, so first question is which version of pjproject were you using?
Also the gibberish suggest it received something that wasn’t SIP, or that there was a memory corruption. In the first case, it might be a buffer overrun attack on a specific implementation, not necessarily Asterisk.
Generally, for deadlocks, you need to obtain a backtrace, from a version built without optimisation, and with full debug symbols available.
I see Asterisk 20.4 has 2.13.1, I’m going to look and see what was fixed with the PJSIP 2.13.1.
Also, lots of similar log entries HOWEVER, none of them have this many returns in the malformed packet, this seems to be the only one.
Not conclusive of course.
I know how to get a backtrace in our dev environment, I’m not sure production could handle it gracefully without causing resource issues. If it happened all the time, easy enough, but I’d have to leave it running for weeks to months.