[SR-Users] possible bug with dialog module
Daniel-Constantin Mierla
miconda at gmail.com
Fri Apr 23 09:38:26 CEST 2010
Hello,
thanks, so the Contact header is missing, that makes the 200ok invalid
for invitate - afaik contact is mandatory. Anyhow, crash should not
happen, but I wonder what happens with such call, practically the caller
does not know where to send the BYE. Or maybe 18x reply has contact hdr
and 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:
> 0901b21e13a60e0247988caf7d72f865 at 10.17.0.200
> <mailto:0901b21e13a60e0247988caf7d72f865 at 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"...
>
> (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:3701 at 10.17.0.200
> <mailto:ip%3A3701 at 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:97
> iLBC/8000\r\na=fmtp:97 mode=30\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101
> telephone-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:101
> 0-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:8
> PCMA/8000\r\na=rtpmap:4 G723/8000\r\na=rtpmap:18
> G729/8000\r\na=rtpmap:2 G726-32/8000\r\na=rtpmap:97
> iLBC/8000\r\na=fmtp:97 mode=20\r\na=rtpmap:102
> G729E/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:97
> mode=20\r\na=rtpmap:102 G729E/8000\r\na=rtpmap:100
> AAL2-G726-16/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101
> 0-16,32-36,54\r\n"
>
> (gdb) print buf+1300
> $12 = 0x86a3d4 "6/8000\r\na=rtpmap:101
> telephone-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
> <miconda at gmail.com <mailto:miconda at 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
>> "0901b21e13a60e0247988caf7d72f865 at 10.17.0.200sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
>> 0\r\n\r\n"
>> <mailto:0901b21e13a60e0247988caf7d72f865 at 10.17.0.200sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
>> len = 44}, from_uri = {
>> s = 0x2ab61c910264
>> "sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
>> 0\r\n\r\n"
>> <mailto:sip:029147089 at 10.17.0.200sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
>> len = 25}, to_uri = {
>> s = 0x2ab61c91027d
>> "sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
>> 0\r\n\r\n"
>> <mailto:sip:4153 at hiddendomain.edusip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
>> len = 19},
>> req_uri = {s = 0x2ab61c910290
>> "sip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:
>> 0\r\n\r\n"
>> <mailto:sip:4153 at 10.17.40.77:5060;user=phone;transport=udpent-Length:0%5Cr%5Cn%5Cr%5Cn>,
>> len = 50}, tag = {{
>> s = 0x2ab61c91c488 "as50d7852dsip:029147089 at 10.17.0.200
>> <mailto:as50d7852dsip%3A029147089 at 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:029147089 at 10.17.0.200
>> <mailto:sip%3A029147089 at 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:029147089 at 10.17.0.200
>> <mailto:sip%3A029147089 at 10.17.0.200>>;tag=as50d7852d\r\nTo:
>> <sip:4153 at hiddendomain.edu
>> <mailto:sip%3A4153 at hiddendomain.edu>>;tag=4735210"...
>>
>>
>>
>> (gdb) print buf+200
>> $4 = 0x869f88 "\nFrom: \"029147089\" <sip:029147089 at 10.17.0.200
>> <mailto:sip%3A029147089 at 10.17.0.200>>;tag=as50d7852d\r\nTo:
>> <sip:4153 at hiddendomain.edu
>> <mailto:sip%3A4153 at hiddendomain.edu>>;tag=473521065\r\nCall-ID:
>> 0901b21e13a60e0247988caf7d72f865 at 10.17.0.200
>> <mailto:0901b21e13a60e0247988caf7d72f865 at 10.17.0.200>\r\nCSeq:
>> 102 INVITE\r\nServer: Cisco ATA 186 "...
>>
>>
>>
>> (gdb) print buf+300
>> $5 = 0x869fec "65\r\nCall-ID:
>> 0901b21e13a60e0247988caf7d72f865 at 10.17.0.200
>> <mailto:0901b21e13a60e0247988caf7d72f865 at 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
>> <miconda at gmail.com <mailto:miconda at 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
>>> <miconda at gmail.com <mailto:miconda at 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
>>>> <ibc at aliax.net <mailto:ibc at aliax.net>> wrote:
>>>>
>>>> 2010/4/21 Kelvin Chua <kelchy at gmail.com
>>>> <mailto:kelchy at 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
>>>> <ibc at aliax.net <mailto:ibc at aliax.net>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> <mailto:sr-users at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100423/8f201321/attachment.htm>
More information about the sr-users
mailing list