Summary: | ASTERISK-24664: PJSIP Error processing packet on SIP requests with non-ascii characters in INVITE or REGISTER | ||
Reporter: | Y Ateya (yateya) | Labels: | |
Date Opened: | 2015-01-06 07:50:47.000-0600 | Date Closed: | 2015-02-15 12:04:59.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | pjproject/pjsip |
Versions: | 13.1.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Ubuntu 12.04 x86_64; pjproject build from source https://github.com/asterisk/pjproject using `./configure --prefix=/usr --enable-shared --disable-sound --disable-resample --disable-video --disable-opencore-amr` | Attachments: | ( 0) pjproject_strange_callerid.txt |
Description: | While investigating messages.log for my asterisk server; I found multiple occurrences of this pjsip exception (see attached log).
It happens when the sip caller id is non-ascii, like this (first one appears in the log) - اسماعيل - ٩٩٥٠ - ΟΠΡΣΤΥΦ This call is rejected from asterisk; and asterisk continues as normal. [Edit by Rusty - The call is *ignored* by Asterisk, with no response to the client. Asterisk produces an error type log message as below] {noformat} [Jan 7 15:24:40] ERROR[17677]: pjsip:0 <?>: sip_transport. Error processing 538 bytes packet from UDP 10.24.18.124:62265 : PJSIP syntax error exception when parsing '' header on line 4 col 29: {noformat} | ||
Comments: | By: Y Ateya (yateya) 2015-01-06 07:51:41.426-0600 Exception message from messages.log By: Rusty Newton (rnewton) 2015-01-06 14:25:13.834-0600 Can you reproduce the issue by simply sending calls to Asterisk with arabic callerid? Press Send Back or Enter Feedback to return the issue to us. By: Y Ateya (yateya) 2015-01-06 15:42:37.815-0600 Yes, any sip client capable of sending UTF8 will do this. You can try it using sipp; and it is not just arabic (I changed the title). Any UNICODE will do the same exception: sipp -sn uac_pcap -s ΟΠΡΣΤΥΦ 127.0.0.1 [Jan 6 23:35:40] ERROR[7928] pjsip: sip_transport. Error processing 589 bytes packet from UDP 127.0.0.1:5061 : PJSIP syntax error exception when parsing '' header on line 1 col 12: INVITE sip:ΟΠΡΣΤΥΦ@127.0.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-25427-7-0 From: sipp <sip:sipp@127.0.1.1:5061>;tag=25427SIPpTag097 To: ΟΠΡΣΤΥΦ <sip:ΟΠΡΣΤΥΦ@127.0.0.1:5060> Call-ID: 7-25427@127.0.1.1 CSeq: 1 INVITE Contact: sip:sipp@127.0.1.1:5061 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 By: Matt Jordan (mjordan) 2015-01-07 10:35:47.114-0600 Is it crashing, or simply not accepting the SIP request? I would not expect it to crash, but I would expect it to potentially have issues with UTF-8 characters. There are plenty of parts of Asterisk that don't support UTF-8. By: Y Ateya (yateya) 2015-01-07 11:32:15.664-0600 Asterisk itself don't crash; But it ignores the request and don't acknowledge this request; So the caller don't know that we ignored his request. By: Rusty Newton (rnewton) 2015-01-07 15:27:55.030-0600 It appears res_pjsip will allow you to configure an endpoint ID as such: {noformat} Endpoint: 6001 Unavailable 0 of inf InAuth: 6001/6001 Aor: 6001 1 Endpoint: ΟΠΡΣΤΥΦ Unavailable 0 of inf InAuth: ΟΠΡΣΤΥΦ/ΟΠΡΣΤΥΦ Aor: ΟΠΡΣΤΥΦ 1 {noformat} However I get the same results with registration. Asterisk ignores the request and produces the error: {noformat} [Jan 7 15:24:41] ERROR[17677]: pjsip:0 <?>: sip_transport. Error processing 538 bytes packet from UDP 10.24.18.124:62265 : PJSIP syntax error exception when parsing '' header on line 4 col 29: REGISTER sip:10.24.18.124 SIP/2.0 Call-ID: c8c0d7f26897cbd75f87fec71f48ae6e@0:0:0:0:0:0:0:0 CSeq: 1 REGISTER From: "ΟΠΡΣΤΥΦ" <sip:ΟΠΡΣΤΥΦ@10.24.18.124>;tag=aadbc398 To: "ΟΠΡΣΤΥΦ" <sip:ΟΠΡΣΤΥΦ@10.24.18.124> Via: SIP/2.0/UDP 10.24.18.124:62265;branch=z9hG4bK-343638-a14e551696b5af6e3fb65aa6f8da38ce Max-Forwards: 70 User-Agent: Jitsi2.5.5065Linux Expires: 600 Contact: "ΟΠΡΣΤΥΦ" <sip:ΟΠΡΣΤΥΦ@10.24.18.124:62265;transport=udp;registering_acc=10_24_18_124>;expires=600 Content-Length: 0 {noformat} Asterisk does not respond to the request. If we are can't handle these characters on requests, we shouldn't allow a user to configure objects using them. If we can't handle the requests, I wonder if a 488 Not Acceptable would be appropriate? By: Y Ateya (yateya) 2015-01-07 16:00:45.044-0600 I think handling UTF8 correctly is much better and should be the optimum solution. But if this is complex and need long time; We can reject it with 488 Not Acceptable for now. By: Joshua C. Colp (jcolp) 2015-02-14 13:36:10.240-0600 As it is this would require changes in pjproject to accomplish. The parser itself is considering it invalid, so it never reaches Asterisk itself thus it's not possible to send a response (even a 488). By: Joshua C. Colp (jcolp) 2015-02-15 12:04:59.947-0600 After looking at this I believe that the best course of action would be to bring it up on the PJSIP mailing list at http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org since this would end up being an invasive PJSIP change and is not a problem in Asterisk itself. Any fix for this would involve communicating with them anyway. |