Hi,
The error message was printed fine on the console (copasted below,
slight differences in the message). I'm using the latest SVN trunk
btw. Have you tried to run pjsua app (or your own app?) under VS
debugger to check what was going on?
09:31:47.505 sip_transport. Error processing 548 bytes packet from UDP 192.168
.1.30:6000 : PJSIP syntax error exception when parsing 'Request Line' header on
line 1 col 30:
MESSAGE sip:242 at 192.168.1.230@192.168.1.127 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.230:5060;branch=z9hG4bK1152b306;rport
To: "242 at 192.168.1.230"<sip:242 at 192.168.1.230@192.168.1.127>
From: "CareIP" <sip:243@192.168.1.230>;tag=7a82b0c8
Call-ID: 857d4f37 at 192.168.1.244
CSeq: 102 MESSAGE
User-Agent: PBX
Max-Forwards: 70
Content-Type: text/plain
Content-Length: 179
<alarmreq><ref>780028900006</ref><aty>AL</aty><tty>C9300</tty><tid>911</tid><tar
></tar><eco>010</eco><ete></ete><snu></snu><ste></ste><dnu></dnu><dte></dte><inf
></inf></alarmreq>
-- end of packet.
BR,
nanang
On Wed, Dec 1, 2010 at 8:20 PM, Stefan Hobbel
<stefanhobbel at abstraxxion.com> wrote:
> Hey,
>
> thanks for investigating this problem Nanang.
> Can you also confirm that creating the error message after the parsing does
> not make windows crash?
>
> I have the feeling windows does succeed in parsing the message (although it
> will find it invalid), but crashes on instantiating the error message, or
> putting it out on the console.
>
> Thanks!
>
> Op 1-12-2010 10:32, Nanang Izzuddin schreef:
>>
>> Hi,
>>
>> Just did a quick check on the standard, such SIP URI is not valid,
>> cmiiw, and must be escaped, e.g:
>> sip:242%40192.168.1.230 at 192.168.1.127.
>>
>> Moreover, also just tried to feed exact SIP message using sipp on win
>> vista machine and neither crash nor assertion occurred on pjsua app.
>>
>> BR,
>> nanang
>>
>>
>> On Fri, Nov 26, 2010 at 7:03 PM, Stefan Hobbel
>> <stefanhobbel at abstraxxion.com> ?wrote:
>>>
>>> Hello all,
>>>
>>> currently I am testing a CareTech device, which is a SIP unit, which
>>> works
>>> as a medical alarm intercom unit.
>>> This device can send a MESSAGE when the alarm button on it is pressed.
>>>
>>> It does this, by sending an XML message as contents of that SIP MESSAGE.
>>> However, it seems this CareTech unit has a bug in the MESSAGE header. It
>>> adds the domain twice, so the SIP uri becomes
>>> sip:xxx at xxx.xxx.xxx.xxx@xxxxxxxxxxxxxxx.
>>> Obviously pjsua has problems parsing this message, which is valid and I
>>> understand.
>>>
>>> Though, on my linux test PC, the error and the message show up in my
>>> debug
>>> log window, saying it has an error parsing the message and shows the
>>> according message.
>>> That is how I know what the actual error is.
>>>
>>> On my windows machine however, the app crashes right away, without
>>> showing
>>> the error, so my guess is, it crashes on creating and putting out the
>>> error
>>> log message, that shows on linux.
>>> Is it possible this is the problem? I get hints from the debugger it has
>>> something to do with string length, so maybe the buffer length is not ok.
>>> Is
>>> it possible linux and windows take this up differently and makes the
>>> windows
>>> app crash and the linux one not?
>>> If it is so, I consider this a bug in pjsip, because it should be able to
>>> handle the error properly. Or am I doing something wrong, or is there a
>>> workaround?
>>>
>>>
>>> I found in sip_transport.c the following code part i suspect to be the
>>> problem. Underneath i copied in the pjsua log part from the linux
>>> machine.
>>>
>>> Can someone have a look at it?
>>>
>>> /* Check for parsing syntax error */
>>> ? ?if (msg==NULL || !pj_list_empty(&rdata->msg_info.parse_err)) {
>>> ? ? ? ?pjsip_parser_err_report *err;
>>> ? ? ? ?char buf[128];
>>> ? ? ? ?pj_str_t tmp;
>>>
>>> ? ? ? ?/* Gather syntax error information */
>>> ? ? ? ?tmp.ptr = buf; tmp.slen = 0;
>>> ? ? ? ?err = rdata->msg_info.parse_err.next;
>>> ? ? ? ?while (err !=&rdata->msg_info.parse_err) {
>>> ? ? ? ?int len;
>>> ? ? ? ?len = pj_ansi_snprintf(tmp.ptr+tmp.slen, sizeof(buf)-tmp.slen,
>>> ? ? ? ? ? ? ? ? ? ? ? ": %s exception when parsing '%.*s' "
>>> ? ? ? ? ? ? ? ? ? ? ? "header on line %d col %d",
>>> ? ? ? ? ? ? ? ? ? ? ? pj_exception_id_name(err->except_code),
>>> ? ? ? ? ? ? ? ? ? ? ? (int)err->hname.slen, err->hname.ptr,
>>> ? ? ? ? ? ? ? ? ? ? ? err->line, err->col);
>>> ? ? ? ?if (len> ?0&& ?len< ?(int) (sizeof(buf)-tmp.slen)) {
>>> ? ? ? ? ? ?tmp.slen += len;
>>> ? ? ? ?}
>>> ? ? ? ?err = err->next;
>>> ? ? ? ?}
>>>
>>> ? ? ? ?/* Only print error message if there's error.
>>> ? ? ? ? * Sometimes we receive blank packets (packets with only CRLF)
>>> ? ? ? ? * which were sent to keep NAT bindings.
>>> ? ? ? ? */
>>> ? ? ? ?if (tmp.slen) {
>>> ? ? ? ?PJ_LOG(1, (THIS_FILE,
>>> ? ? ? ? ? ? ?"Error processing %d bytes packet from %s %s:%d %.*s:\n"
>>> ? ? ? ? ? ? ?"%.*s\n"
>>> ? ? ? ? ? ? ?"-- end of packet.",
>>> ? ? ? ? ? ? ?msg_fragment_size,
>>> ? ? ? ? ? ? ?rdata->tp_info.transport->type_name,
>>> ? ? ? ? ? ? ?rdata->pkt_info.src_name,
>>> ? ? ? ? ? ? ?rdata->pkt_info.src_port,
>>> ? ? ? ? ? ? ?(int)tmp.slen, tmp.ptr,
>>> ? ? ? ? ? ? ?(int)msg_fragment_size,
>>> ? ? ? ? ? ? ?rdata->msg_info.msg_buf));
>>> ? ? ? ?}
>>>
>>> ? ? ? ?goto finish_process_fragment;
>>> ? ?}
>>>
>>>
>>>
>>>
>>> ---->> ?PJSUA log:
>>> ?12:31:46.789 sip_transport. ?Error processing 549 bytes packet from UDP
>>> 192.168.1.230:5060 : PJSIP syntax error exception when parsing '' header
>>> on
>>> line 1 col 30:
>>> MESSAGE sip:242 at 192.168.1.230@192.168.1.127 SIP/2.0
>>> Via: SIP/2.0/UDP 192.168.1.230:5060;branch=z9hG4bK1152b306;rport
>>> To: "242 at 192.168.1.230"<sip:242 at 192.168.1.230@192.168.1.127>
>>> From: "CareIP"<sip:243@192.168.1.230>;tag=7a82b0c8
>>> Call-ID: 857d4f37 at 192.168.1.244
>>> CSeq: 102 MESSAGE
>>> User-Agent: PBX
>>> Max-Forwards: 70
>>> Content-Type: text/plain
>>> Content-Length: 179
>>>
>>>
>>> <alarmreq><ref>780028900006</ref><aty>AL</aty><tty>C9300</tty><tid>911</tid><tar></tar><eco>010</eco><ete></ete><snu></snu><ste></ste><dnu></dnu><dte></dte><inf></inf></alarmreq>
>>>
>>> -- end of packet.
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
