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
>
