PJSIP crashes when parsing a faulty SIP-header. The Contact section of the error message below is clearly wrong as the @ should be removed if the user@ section is empty. However, it seems like pjsip crashes with Asterisk unable to recover, resulting in it not receiving calls anymore.
Error message:
sip_transport.c Error processing 743 bytes packet from TCP IP-adress-2:62086 : PJSIP syntax error exception when parsing 'Contact' header on line 8 col 15:
INVITE sip:caller-phone-number@IP-adress-1;transport=TCP SIP/2.0
From: <sip:IP-adress-2>;tag=b2d03e8-c1fee25a-13c4-65014-d9f2d-391e3187-d9f2d
To: <sip:caller-phone-number@IP-adress-1>
Call-ID: b4c3470-c1fee25a-13c4-65014-d9f2d-b47f051-d9f2d
CSeq: 1 INVITE
Via: SIP/2.0/TCP IP-adress-2:5060;branch=z9hG4bK-d9f2d-3535c8f1-5c229f04-b25ca28
Max-Forwards: 67
Contact: <sip:@IP-adress-2;transport=TCP>
Allow: INVITE, CANCEL, ACK, BYE, OPTIONS, INFO
Content-Type: application/sdp
Content-Length: 236
v=0
o=Dialogic_SIP_CCLIB 189543536 189543537 IN IP4 IP-adress-2
s=Dialogic_SIP_CCLIB
i=session information
c=IN IP4 IP-adress-1
Expected behaviour:
PJSIP reporting an error and rejecting the call?
Define “crashes”. That message alone would not cause Asterisk itself to crash, if the PJSIP stack encounters a parsing error it just ignores the message. How have you confirmed that it is unable to receive calls anymore?
I’m running Asterisk 15.7.4 inside an alpine linux (alpine:3.9.3) container in kubernetes (in host network mode) and after PJSIP throws this error the Asterisk becomes unresponsive. The pod seems fine in kubernetes though.
A tcpdump of the traffic gives the following for any call after the point where the Asterisk becomes unresponsive. Even for calls with correct SIP-headers.
If it has crashed, you are going to need to provide evidence from the machine running it, and, in particular, the back trace from the core dump, for which you will need to ensure that compiler optimisation was disabled when building it., for it to be of any real use for debugging.
On the Command Line Interface (CLI) of your Asterisk, what is the last message you see?
In a case like yours (without user), I get PJSIP syntax error exception when parsing 'Contact' header.
However, this is with the latest Asterisk. You are using a version from Sep. 2019. Although you are using the latest Asterisk 15, that branch is end of life already. Therefore, I recommend to go back to Asterisk 13 LTS or use a newer branch like Asterisk 16 LTS.
@traud I also get the same message PJSIP syntax error exception when parsing 'Contact' header on line 8 col 15: (first row, to the right, in the error output above). Thank you for the info that it has reached EOL. I installed it as a package in alpine linux and version 15 was the latest at the time. I see that it has been updated with version 16 now and I will test with that instead.
I’ve encountered another issue which might be related. While troubleshooting I accessed the asterisk CLI in order to start additional debugging and noticed that Asterisk will crash/exit if pjsip set logger on while receiving a new call.
The last output I get is:
{"hostname":"","timestamp":"Aug 31 11:57:18","identifiers":{"lwp":95,"callid":""},"logmsg":{"location":{"filename":"res_pjsip_logger.c","function":"logging_on_tx_msg","line":113},"level":"VERBOSE","message":"<--- Transmitting SIP response (693 bytes) to UDP:127.0.0.1:5064 --->\nSIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 127.0.0.1:5064;rport=5064;received=127.0.0.1\r\nCall-ID: 1-6@127.0.0.1\r\nFrom: \"sipp\" <sip:sipp@127.0.0.15064>;tag=1\r\nTo: \"echo-bot\" <sip:echo-bot-se@127.0.0.1>;tag=fgU.TcASWmudoAtStMKhbBtCRQ
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups
I don’t know if that constitutes a crash and if I can expect a core dump as a result. I’m running Asterisk as root now in order to avoid issues with permissions while troubleshooting.
EDIT:
Asterisk is started with the following flags: /usr/sbin/asterisk -T -W -p -n -f -g &
And will be shut down on SIGTERM with /usr/sbin/asterisk -rx "core stop gracefully".
core files should be produced in the current directory. They should never be produced in a system binary directory. I am not familiar with kernel_core_pattern. It was never necessary to touch it, even if it existed, when I was debugging Asterisk, which was a few years ago, now.
It looks as though someone has specially configured your system in the past and has forgotten to restore the default value of /proc/sys/kernel/core_pattern , which seems to be the, backwards compatible, “core”.
Just to clarify, I’m running Asterisk inside a alpine linux docker container and all OS files should have their default values. Asterisk is started with a docker-entrypoint.sh shell script under ‘/’ which basically only runs /usr/sbin/asterisk -T -W -p -n -f -g &
I just looked up Alpine Linux and it appears to be targetted at embedded systems. That’s going to make it difficult to support here, as it is likely to be missing lots of tools that that people will normally assume to exist. In particular, I assume, given the size minimisation aims, it is built without debugging symbols, and with optimisation enabled, and one would not normally run development tools on the system itself. That may make it almost impossible to debug, and you should probably be passing this problem to the person that created the package.
I also looked up apport, and it surprises me that it should be used in something intended for such minimal systems, especially as the documentation I found seems to suggest it needs a GUI.
Just to update, I built Asterisk 16 in a CentOS7 docker image instead and did not have any problem with any of the above. I will notify the maintainer of the Asterisk package in alpine-linux.
