Re: [SR-Users] possible bug with dialog module

Daniel-Constantin Mierla Fri, 23 Apr 2010 00:38:58 -0700

Hello,

thanks, so the Contact header is missing, that makes the 200ok invalidfor invitate - afaik contact is mandatory. Anyhow, crash should nothappen, but I wonder what happens with such call, practically the callerdoes not know where to send the BYE. Or maybe 18x reply has contact hdrand that is used ...


Cheers,
Daniel

On 4/22/10 12:00 PM, Kelvin Chua wrote:


(gdb) print buf+300

$2 = 0x869fec "65\r\nCall-ID:0901b21e13a60e0247988caf7d72f...@10.17.0.200<mailto:0901b21e13a60e0247988caf7d72f...@10.17.0.200>\r\nCSeq: 102INVITE\r\nServer: Cisco ATA 186 v3.2.0 atasip (041111A)\r\nAllow:ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, U"...


(gdb) print buf+400

$1 = 0x86a050 "v3.2.0 atasip (041111A)\r\nAllow: ACK, BYE, CANCEL,INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE\r\nSupported:replaces\r\nContent-Length: 0\r\n\r\n"


(gdb) print buf+500
$4 = 0x86a0b4 "PDATE\r\nSupported: replaces\r\nContent-Length: 0\r\n\r\n"

(gdb) print buf+600

$5 = 0x86a118 "ip:3...@10.17.0.200<mailto:ip%3a3...@10.17.0.200>>\r\nContent-Length: 0\r\n\r\n"


(gdb) print buf+700

$6 = 0x86a17c "A/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:97iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101telephone-event/8000\r\na=fmtp:101 0-16\r\na=silenceSupp:off - - --\r\na=ptime:20\r\na=sendrecv\r\n"


(gdb) print buf+800

$7 = 0x86a1e0 "p:101 telephone-event/8000\r\na=fmtp:1010-16\r\na=silenceSupp:off - - - -\r\na=ptime:20\r\na=sendrecv\r\n"


(gdb) print buf+900

$8 = 0x86a244 "8000\r\na=fmtp:101 0-16,32-36,54\r\na=silenceSupp:off -- - -\r\n"


(gdb) print buf+1000
$9 = 0x86a2a8 "0\r\na=fmtp:101 0-15\r\n"

(gdb) print buf+1100

$10 = 0x86a30c "000\r\na=ptime:20\r\na=rtpmap:8PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102G729E/8000\r\na=rtpmap:100 AAL2-G726-1"...


(gdb) print buf+1200

$11 = 0x86a370 "32/8000\r\na=rtpmap:97 iLBC/8000\r\na=fmtp:97mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:1010-16,32-36,54\r\n"


(gdb) print buf+1300

$12 = 0x86a3d4 "6/8000\r\na=rtpmap:101telephone-event/8000\r\na=fmtp:101 0-16,32-36,54\r\n"


(gdb) print buf+1400
$13 = 0x86a438 ""

(gdb) print buf+1500
$14 = 0x86a49c "5395257\"\r\nContent-Length: 0\r\n\r\n"


Kelvin Chua

On Thu, Apr 22, 2010 at 4:49 PM, Daniel-Constantin Mierla<mico...@gmail.com <mailto:mico...@gmail.com>> wrote:


    Hi,

    if you still have the core file, can you print more of buffer
    until it gets to end of headers? I am curios to see what is wrong
    with the contact.

    Just increase by 100:

    (gdb) print buf+300
    (gdb) print buf+400
    ...

    Thanks,
    Daniel


    On 4/21/10 3:15 PM, Kelvin Chua wrote:

    (gdb) bt
    #0  0x00002ab61b62779a in update_dialog_dbinfo
    (cell=0x2ab61c9100f8) at dlg_db_handler.c:501
    #1  0x00002ab61b628ea8 in dlg_onreply (t=0x7d5228, type=<value
    optimized out>, param=<value optimized out>) at dlg_handlers.c:361
    #2  0x00002ab617965505 in run_trans_callbacks_internal
    (cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
        params=0x7fffec157970) at t_hooks.c:261
    #3  0x00002ab61796575e in run_trans_callbacks (type=1,
    trans=0x88c580, req=0x0, rpl=0x0, code=477060464) at t_hooks.c:288
    #4  0x00002ab61798ebd1 in relay_reply (t=0x2ab61c9387c0,
    p_msg=<value optimized out>, branch=0, msg_status=200,
        cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at t_reply.c:1705
    #5  0x00002ab617990884 in reply_received (p_msg=0x8f48a8) at
    t_reply.c:2126
    #6  0x000000000044760e in forward_reply (msg=0x8f48a8) at
    forward.c:689
    #7  0x000000000047fd22 in receive_msg (
        buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
    10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
    10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
    <sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r"..., len=<value
    optimized out>,
        rcv_info=0x7fffec158020) at receive.c:257
    #8  0x0000000000505e2b in udp_rcv_loop () at udp_server.c:520
    #9  0x0000000000455adf in main_loop () at main.c:1447
    #10 0x0000000000456be2 in main (argc=<value optimized out>,
    argv=0x7fffec1582e8) at main.c:2251



    (gdb) print cell
    $1 = (struct dlg_cell *) 0x2ab61c9100f8



    (gdb) print *cell
    $2 = {ref = 2, next = 0x0, prev = 0x0, h_id = 996587990, h_entry
    = 1420, state = 3, lifetime = 3600, start_ts = 1271816397,
      dflags = 1, sflags = 0, toroute = 0, from_rr_nb = 0, tl = {next
    = 0x0, prev = 0x0, timeout = 0}, callid = {
        s = 0x2ab61c910238
    
"0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
    0\r\n\r\n"
    
<mailto:0901b21e13a60e0247988caf7d72f...@10.17.0.200sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
    len = 44}, from_uri = {
        s = 0x2ab61c910264
    
"sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
    0\r\n\r\n"
    
<mailto:sip:029147...@10.17.0.200sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
    len = 25}, to_uri = {
        s = 0x2ab61c91027d
    
"sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
    0\r\n\r\n"
    
<mailto:sip:4...@hiddendomain.edusip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
    len = 19},
      req_uri = {s = 0x2ab61c910290
    "sip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:
    0\r\n\r\n"
    
<mailto:sip:4...@10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
    len = 50}, tag = {{
          s = 0x2ab61c91c488 "as50d7852dsip:029147...@10.17.0.200
    <mailto:as50d7852dsip%3a029147...@10.17.0.200>\034�*", len = 10},
    {s = 0x0, len = 0}}, cseq = {{
          s = 0x2ab61c857950 "10213331\b", len = 3}, {s = 0x0, len =
    0}}, route_set = {{s = 0x0, len = 0}, {s = 0x0, len = 0}},
      contact = {{s = 0x2ab61c91c492 "sip:029147...@10.17.0.200
    <mailto:sip%3a029147...@10.17.0.200>\034�*", len = 25}, {s = 0x0,
    len = 0}}, bind_addr = {0x88c580, 0x0},
      cbs = {first = 0x0, types = 0}, profile_links = 0x0}



    (gdb) frame 7
    #7  0x000000000047fd22 in receive_msg (
        buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
    10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia: SIP/2.0/UDP
    10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
    <sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r"..., len=<value
    optimized out>,
        rcv_info=0x7fffec158020) at receive.c:257
    257 forward_reply(msg);



    (gdb) print buf+100
    $3 = 0x869f24
    ".200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
    <sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r\nFrom: \"029147089\"
    <sip:029147...@10.17.0.200
    <mailto:sip%3a029147...@10.17.0.200>>;tag=as50d7852d\r\nTo:
    <sip:4...@hiddendomain.edu
    <mailto:sip%3a4...@hiddendomain.edu>>;tag=4735210"...



    (gdb) print buf+200
    $4 = 0x869f88 "\nFrom: \"029147089\" <sip:029147...@10.17.0.200
    <mailto:sip%3a029147...@10.17.0.200>>;tag=as50d7852d\r\nTo:
    <sip:4...@hiddendomain.edu
    <mailto:sip%3a4...@hiddendomain.edu>>;tag=473521065\r\nCall-ID:
    0901b21e13a60e0247988caf7d72f...@10.17.0.200
    <mailto:0901b21e13a60e0247988caf7d72f...@10.17.0.200>\r\nCSeq:
    102 INVITE\r\nServer: Cisco ATA 186  "...



    (gdb) print buf+300
    $5 = 0x869fec "65\r\nCall-ID:
    0901b21e13a60e0247988caf7d72f...@10.17.0.200
    <mailto:0901b21e13a60e0247988caf7d72f...@10.17.0.200>\r\nCSeq:
    102 INVITE\r\nServer: Cisco ATA 186  v3.2.0 atasip
    (041111A)\r\nAllow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS,
    REFER, REGISTER, PRACK, U"...

    Kelvin Chua


    On Wed, Apr 21, 2010 at 7:22 PM, Daniel-Constantin Mierla
    <mico...@gmail.com <mailto:mico...@gmail.com>> wrote:

        Hello,


        On 4/21/10 12:23 PM, Kelvin Chua wrote:

        hi daniel,

        i'm not using git version. so maybe i'm missing some
        patches. can you confirm if what i am
        experiencing is the same problem and the fix is indeed
        available from the git version? thanks


        I recommend using at least 3.0.1, as a matter of fact 3.0.2
        should be released soon.

        Can you please print the content of cell adn more of the
        reply in gdb, here are the commands:


        gdb /path/to/kamailio core_file

        print cell

        print *cell

        frame 7

        print buf+100

        print buf+200

        print buf+300

        Thanks,
        Daniel


        here is the backtrace:

        #0  0x00002ab61b62779a in update_dialog_dbinfo
        (cell=0x2ab61c9100f8) at dlg_db_handler.c:501
        #1  0x00002ab61b628ea8 in dlg_onreply (t=0x7d5228,
        type=<value optimized out>, param=<value optimized out>) at
        dlg_handlers.c:361
        #2  0x00002ab617965505 in run_trans_callbacks_internal
        (cb_lst=0x2ab61c938830, type=128, trans=0x2ab61c9387c0,
            params=0x7fffec157970) at t_hooks.c:261
        #3  0x00002ab61796575e in run_trans_callbacks (type=1,
        trans=0x88c580, req=0x0, rpl=0x0, code=477060464) at
        t_hooks.c:288
        #4  0x00002ab61798ebd1 in relay_reply (t=0x2ab61c9387c0,
        p_msg=<value optimized out>, branch=0, msg_status=200,
            cancel_bitmap=0x7fffec157dd4, do_put_on_wait=1) at
        t_reply.c:1705
        #5  0x00002ab617990884 in reply_received (p_msg=0x8f48a8) at
        t_reply.c:2126
        #6  0x000000000044760e in forward_reply (msg=0x8f48a8) at
        forward.c:689
        #7  0x000000000047fd22 in receive_msg (
            buf=0x869ec0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
        10.17.0.202;branch=z9hG4bK75b5.e2a38a16.0\r\nVia:
        SIP/2.0/UDP
        10.17.0.200:5060;branch=z9hG4bK730bcb55;rport=5060\r\nRecord-Route:
        <sip:10.17.0.202;lr=on;did=c85.6d9b66b3>\r"..., len=<value
        optimized out>,
            rcv_info=0x7fffec158020) at receive.c:257
        #8  0x0000000000505e2b in udp_rcv_loop () at udp_server.c:520
        #9  0x0000000000455adf in main_loop () at main.c:1447
        #10 0x0000000000456be2 in main (argc=<value optimized out>,
        argv=0x7fffec1582e8) at main.c:2251


        Kelvin Chua


        On Wed, Apr 21, 2010 at 6:04 PM, Daniel-Constantin Mierla
        <mico...@gmail.com <mailto:mico...@gmail.com>> wrote:

            Hello,

            are you using the latest git version of branch
            kamailio_3.0? It was a fix to dialog after the 3.0.0
            release, adding some sanity checks for broken messages:
            
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=787fabb1e0085355aa1eeb77d5f17e7940f4ed3c

            On the other hand, I see you got a core dump file:
            Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]:
            ALERT: <core> [main.c:722]: child process 28511 exited
            by a signal 11
            Apr 21 10:19:57 kamvm-1 /usr/local/sbin/kamailio[28507]:
            ALERT: <core> [main.c:725]: core was generated

            Locate the core file and sent the backtrace. The core is
            either in root '/' folder or in working directory (if
            you provided by -w parameter).

            Use the gdb:

            gdb /path/to/kamailio core_file

            then do bt and send here.

            Thanks,
            Daniel

            On 4/21/10 11:38 AM, Kelvin Chua wrote:

            ok, i'll enable debug for now.
            but if it's indeed a buggy UA, the dialog module should
            not have crashed
            but instead dropped the dialog/session and moved on,
            something i think
            we need to address to be more resilient.

            i hope i catch the culprit when this happens again.

            Kelvin Chua


            On Wed, Apr 21, 2010 at 5:33 PM, Iñaki Baz Castillo
            <i...@aliax.net <mailto:i...@aliax.net>> wrote:

                2010/4/21 Kelvin Chua <kel...@gmail.com
                <mailto:kel...@gmail.com>>:
                > i wonder if anybody from list is also
                experiencing this?

                Perhaps in your case you have a buggy UA setting an
                invalid Contact
                header and it causes Kamailio to crash, maybe the
                reason others have
                not detected same issue.

                Could you get some SIP traces until the problem
                occurs again?
                or perhaps could you enable the debug?

                --
                Iñaki Baz Castillo
                <i...@aliax.net <mailto:i...@aliax.net>>



            _______________________________________________
            SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
list
            sr-users@lists.sip-router.org
            <mailto:sr-users@lists.sip-router.org>
            http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--Daniel-Constantin Mierla * http://www.asipto.com/ *

            http://twitter.com/miconda *
            http://www.linkedin.com/in/danielconstantinmierla

--Daniel-Constantin Mierla * http://www.asipto.com/ *

        http://twitter.com/miconda *
        http://www.linkedin.com/in/danielconstantinmierla

--Daniel-Constantin Mierla * http://www.asipto.com/ *

    http://twitter.com/miconda *
    http://www.linkedin.com/in/danielconstantinmierla



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


--
Daniel-Constantin Mierla
* http://www.asipto.com/
* http://twitter.com/miconda
* http://www.linkedin.com/in/danielconstantinmierla

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] possible bug with dialog module

Reply via email to