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
