hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888 "sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r \nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l \337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977 "sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001 \330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888 "sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r \nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977"sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888"sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
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
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264 \016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r \nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977 "sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r \nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344 \003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888 "sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
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 www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com _______________________________________________ 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
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers, Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977"sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888"sip:8888888888@7.7.7.7;user=phone sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060 sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
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 www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com http://www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com http://www.kamailioworld.com _______________________________________________ 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
hello Daniel
it happened only once as far as i know, i tried to duplicate by myself but i couldnt create the sipp scenario i will try to duplicate it setting the octal parameters in hex escaped by % in the SIP uris to see if i can, but i didnt have time yet
in the meantime here you have the information
(gdb) frame 6 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 2679 he=dns_get_he(name, dns_flags); (gdb) p *name $1 = {s = 0x0, len = 0} (gdb) p *port $2 = 5080
thanks a lot and regards david
El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió:
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers, Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264 \016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977 "sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB \r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888 "sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
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 www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com _______________________________________________ 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 www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
Hello,
I pushed a safety checks to avoid crash in this situation. I will have to investigate deeper why it got to this state, but for now the fix should avoid this crash in a similar situation. You have to use the latest branch 4.4 or backport the patch e20b38e0084c1f89c43a921a8a2affbea060aaa5 to your version.
Cheers, Daniel
On 28/03/2017 12:15, David Escartín Almudévar wrote:
hello Daniel
it happened only once as far as i know, i tried to duplicate by myself but i couldnt create the sipp scenario i will try to duplicate it setting the octal parameters in hex escaped by % in the SIP uris to see if i can, but i didnt have time yet
in the meantime here you have the information
(gdb) frame 6 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 2679 he=dns_get_he(name, dns_flags); (gdb) p *name $1 = {s = 0x0, len = 0} (gdb) p *port $2 = 5080
thanks a lot and regards david
El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió:
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers, Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977"sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016\213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
hello all
we have experienced a crash and tracing the logs and the core, seems it was because a sip response from an endpoint. a UDP receiver (26248) crashed and the last message we see on it is a 487 quite bad formed
Mar 24 01:58:02 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header Mar 24 01:58:17 mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11
the backtrace of the core (gdb) backtrace #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at hashes.h:210 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, type=1) at dns_cache.c:2102 #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at dns_cache.c:2432 #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, flags=1) at dns_cache.c:2505 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 #7 0x000000000046aa37 in dns_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 #8 0x000000000049519e in update_sock_struct_from_via (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at forward.c:704 #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, mode=0) at forward.c:766 #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at forward.c:849 #11 0x00000000005197ef in receive_msg ( buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: "8888888888"sip:8888888888@7.7.7.7;user=phone sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060 sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 #13 0x00000000004b107a in main_loop () at main.c:1600 #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) at main.c:2616
i have tried to duplicate the issue, but i dont know how to translate l\337K\016 to a xml notation i guess this is some weird that cannot be processed for kamailio
could you please take a look and let me know if you know how to duplicate and fix this crash?
thanks a lot and regards david
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 www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com http://www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com http://www.kamailioworld.com _______________________________________________ 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 www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com http://www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com http://www.kamailioworld.com
hello Daniel
thanks a lot. we actually will start testing 5.0 to migrate to it, but in the meantime it's great if we can patch it on the 4.4
best regards david
El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla escribió:
Hello,
I pushed a safety checks to avoid crash in this situation. I will have to investigate deeper why it got to this state, but for now the fix should avoid this crash in a similar situation. You have to use the latest branch 4.4 or backport the patch e20b38e0084c1f89c43a921a8a2affbea060aaa5 to your version.
Cheers, Daniel
On 28/03/2017 12:15, David Escartín Almudévar wrote:
hello Daniel
it happened only once as far as i know, i tried to duplicate by myself but i couldnt create the sipp scenario i will try to duplicate it setting the octal parameters in hex escaped by % in the SIP uris to see if i can, but i didnt have time yet
in the meantime here you have the information
(gdb) frame 6 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 2679 he=dns_get_he(name, dns_flags); (gdb) p *name $1 = {s = 0x0, len = 0} (gdb) p *port $2 = 5080
thanks a lot and regards david
El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió:
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers, Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264 \016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264 \016 \r\nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
hello all, Daniel
checking the core with the gdb, we have checked the variables at the frames of the backtrace, to try to get the full sip message seems it seemed truncated. checking the buf variable of the frame 11 which theorically contains the sip msg to parse we have the string
SIP/2.0 487 Request Terminated\r\nFrom: "881237046977 "sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n
this is i guess how gdb parses the message, so i guess i cannot introduce this like that in a xml sipp formal, since CRLF is represented as \r\n, so others parts like l\337K\016 \213\347: \344\003 i have no idea what they are, because they also seem to be out of the ASCII table ¿? anycase, seems the message is very bad formed, and the kamailio tries to resolve the host of the Via and it gets nothing, so the function get_hash1_case_raw is fed by a nul value and seems that the reason it crashes
hope you can retrieve information from that message to find out what kind of message it exactly is and see if it's possible to avoid kamailio's crash in this scenario
best regards david
El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar escribió:
> hello all > > we have experienced a crash and tracing the logs and the > core, seems it was because a sip response from an > endpoint. > a UDP receiver (26248) crashed and the last message we see > on it is a 487 quite bad formed > > Mar 24 01:58:02 > mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header > Mar 24 01:58:17 > mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11 > > > the backtrace of the core > (gdb) backtrace > #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, > len=0) at hashes.h:210 > #1 0x000000000045b472 in _dns_hash_find > (name=0x7f6906943188, type=1, h=0x7fff120793cc, > err=0x7fff120793ac) at dns_cache.c:535 > #2 0x0000000000461285 in dns_hash_get > (name=0x7f6906943188, type=1, h=0x7fff120793cc, > err=0x7fff120793ac) at dns_cache.c:762 > #3 0x0000000000467194 in dns_get_entry > (name=0x7f6906943188, type=1) at dns_cache.c:2102 > #4 0x0000000000468a05 in dns_a_get_he > (name=0x7f6906943188) at dns_cache.c:2432 > #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, > flags=1) at dns_cache.c:2505 > #6 0x00000000004696c4 in dns_srv_sip_resolvehost > (name=0x7f6906943188, port=0x7fff120795e2, > proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 > #7 0x000000000046aa37 in dns_sip_resolvehost > (name=0x7f6906943188, port=0x7fff120795e2, > proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2849 > #8 0x000000000049519e in update_sock_struct_from_via > (to=0x7fff12079708, msg=0x7f69069a1dd8, > via=0x7f69068f82a8) at forward.c:704 > #9 0x0000000000495ee5 in do_forward_reply > (msg=0x7f69069a1dd8, mode=0) at forward.c:766 > #10 0x00000000004970af in forward_reply > (msg=0x7f69069a1dd8) at forward.c:849 > #11 0x00000000005197ef in receive_msg ( > buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: > "8888888888 > "sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r > \nTo: > sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 > #12 0x0000000000627b43 in udp_rcv_loop () at > udp_server.c:495 > #13 0x00000000004b107a in main_loop () at main.c:1600 > #14 0x00000000004b842f in main (argc=13, > argv=0x7fff12079fb8) at main.c:2616 > > > i have tried to duplicate the issue, but i dont know how > to translate l\337K\016 to a xml notation > i guess this is some weird that cannot be processed for > kamailio > > could you please take a look and let me know if you know > how to duplicate and fix this crash? > > thanks a lot and regards > david
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 www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com _______________________________________________ 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 www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
Hello,
it is already backported to branch 4.4 -- I said that you can use latest 4.4 branch from git -- backporting was only if you want to still use 4.4.1 snapshot + this patch.
Therefore next release in 4.4 series will have it as well.
Cheers, Daniel
On 28/03/2017 13:42, David Escartín Almudévar wrote:
hello Daniel
thanks a lot. we actually will start testing 5.0 to migrate to it, but in the meantime it's great if we can patch it on the 4.4
best regards david
El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla escribió:
Hello,
I pushed a safety checks to avoid crash in this situation. I will have to investigate deeper why it got to this state, but for now the fix should avoid this crash in a similar situation. You have to use the latest branch 4.4 or backport the patch e20b38e0084c1f89c43a921a8a2affbea060aaa5 to your version.
Cheers, Daniel
On 28/03/2017 12:15, David Escartín Almudévar wrote:
hello Daniel
it happened only once as far as i know, i tried to duplicate by myself but i couldnt create the sipp scenario i will try to duplicate it setting the octal parameters in hex escaped by % in the SIP uris to see if i can, but i didnt have time yet
in the meantime here you have the information
(gdb) frame 6 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 2679 he=dns_get_he(name, dns_flags); (gdb) p *name $1 = {s = 0x0, len = 0} (gdb) p *port $2 = 5080
thanks a lot and regards david
El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió:
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers, Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
Hello,
the backtrace is no longer matching the 4.4 branch code, as you run an older release in that series.
Can you get with gdb from the core the output of the following commands:
frame 1
info locals
list
and send them here on the mailing list.
Cheers, Daniel
On 24/03/2017 14:50, David Escartín Almudévar wrote:
> hello all, Daniel > > checking the core with the gdb, we have checked the variables at > the frames of the backtrace, to try to get the full sip message > seems it seemed truncated. > checking the buf variable of the frame 11 which theorically > contains the sip msg to parse we have the string > > > SIP/2.0 487 Request Terminated\r\nFrom: > "881237046977"sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: > sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: > \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP > L\263\264\016\020?\337\v\234\262\264\016 > ;branch=\327\f\340\r\nVia: SIP/2.0/UDP > \020?\337\v\234\262\264\016 > :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 > \r\nContent-Length: 0\r\n\r\n > > this is i guess how gdb parses the message, so i guess i cannot > introduce this like that in a xml sipp formal, since CRLF is > represented as \r\n, so others parts like l\337K\016\213\347: > \344\003 i have no idea what they are, because they also seem to > be out of the ASCII table ¿? > anycase, seems the message is very bad formed, and the kamailio > tries to resolve the host of the Via and it gets nothing, so the > function get_hash1_case_raw is fed by a nul value and seems that > the reason it crashes > > hope you can retrieve information from that message to find out > what kind of message it exactly is and see if it's possible to > avoid kamailio's crash in this scenario > > > best regards > david > > > > El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar > escribió: >> hello all >> >> we have experienced a crash and tracing the logs and the core, >> seems it was because a sip response from an endpoint. >> a UDP receiver (26248) crashed and the last message we see on >> it is a 487 quite bad formed >> >> Mar 24 01:58:02 mia-proxy-inout-1-stby >> /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm >> [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a >> via, cseq or call-id header >> Mar 24 01:58:17 mia-proxy-inout-1-stby >> /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> >> [main.c:739]: handle_sigs(): child process 26248 exited by a >> signal 11 >> >> >> the backtrace of the core >> (gdb) backtrace >> #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at >> hashes.h:210 >> #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, >> type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 >> #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, >> type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 >> #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, >> type=1) at dns_cache.c:2102 >> #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at >> dns_cache.c:2432 >> #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, >> flags=1) at dns_cache.c:2505 >> #6 0x00000000004696c4 in dns_srv_sip_resolvehost >> (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 >> "\001\330\023") at dns_cache.c:2679 >> #7 0x000000000046aa37 in dns_sip_resolvehost >> (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 >> "\001\330\023") at dns_cache.c:2849 >> #8 0x000000000049519e in update_sock_struct_from_via >> (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at >> forward.c:704 >> #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, >> mode=0) at forward.c:766 >> #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at >> forward.c:849 >> #11 0x00000000005197ef in receive_msg ( >> buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: >> "8888888888"sip:8888888888@7.7.7.7;user=phone >> sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: >> sip:555555555@8.8.8.8:5060 >> sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., >> len=367, rcv_info=0x7fff12079a10) at receive.c:299 >> #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 >> #13 0x00000000004b107a in main_loop () at main.c:1600 >> #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) >> at main.c:2616 >> >> >> i have tried to duplicate the issue, but i dont know how to >> translate l\337K\016 to a xml notation >> i guess this is some weird that cannot be processed for kamailio >> >> could you please take a look and let me know if you know how to >> duplicate and fix this crash? >> >> thanks a lot and regards >> david > > > > _______________________________________________ > 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 www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com http://www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com http://www.kamailioworld.com _______________________________________________ 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 www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com http://www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com http://www.kamailioworld.com
-- Daniel-Constantin Mierla www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com http://www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com http://www.kamailioworld.com
hello Daniel
yes yes i understood.
thanks a lot david
El mar, 28-03-2017 a las 13:44 +0200, Daniel-Constantin Mierla escribió:
Hello,
it is already backported to branch 4.4 -- I said that you can use latest 4.4 branch from git -- backporting was only if you want to still use 4.4.1 snapshot + this patch.
Therefore next release in 4.4 series will have it as well.
Cheers, Daniel
On 28/03/2017 13:42, David Escartín Almudévar wrote:
hello Daniel
thanks a lot. we actually will start testing 5.0 to migrate to it, but in the meantime it's great if we can patch it on the 4.4
best regards david
El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla escribió:
Hello,
I pushed a safety checks to avoid crash in this situation. I will have to investigate deeper why it got to this state, but for now the fix should avoid this crash in a similar situation. You have to use the latest branch 4.4 or backport the patch e20b38e0084c1f89c43a921a8a2affbea060aaa5 to your version.
Cheers, Daniel
On 28/03/2017 12:15, David Escartín Almudévar wrote:
hello Daniel
it happened only once as far as i know, i tried to duplicate by myself but i couldnt create the sipp scenario i will try to duplicate it setting the octal parameters in hex escaped by % in the SIP uris to see if i can, but i didnt have time yet
in the meantime here you have the information
(gdb) frame 6 #6 0x00000000004696c4 in dns_srv_sip_resolvehost (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679 2679 he=dns_get_he(name, dns_flags); (gdb) p *name $1 = {s = 0x0, len = 0} (gdb) p *port $2 = 5080
thanks a lot and regards david
El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió:
Hello,
did it happen only once, or it can be reproduced?
Can you also get from gdb:
frame 6
p *name
p *port
Cheers, Daniel
On 27/03/2017 16:43, David Escartín Almudévar wrote:
hello Daniel
here you have
(gdb) frame 1 #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 535 *h=dns_hash_no(name->s, name->len, type); (gdb) info locals e = 0x7f69069015b8 tmp = 0x7f69069247e0 ret = 0x0 now = 689922868 cname_chain = 0 cname = {s = 0xab0e93 "Via: SIP/2.0/UDP \020?\337\v\234\262 \264\016 :5080;received=;rport=5080;branch=\020?\337\v\234 \262\264\016 \r\nContent-Length: 0\r\n\r\n", len = 11210375} __FUNCTION__ = "_dns_hash_find" (gdb) list 530 cname_chain=0; 531 ret=0; 532 now=get_ticks_raw(); 533 *err=0; 534 again: 535 *h=dns_hash_no(name->s, name->len, type); 536 #ifdef DNS_CACHE_DEBUG 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, name->len, type, *h); 538 #endif 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){
thanks a lot and regards david
El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla escribió:
> Hello, > > the backtrace is no longer matching the 4.4 branch code, > as you run an older release in that series. > > Can you get with gdb from the core the output of the > following commands: > > frame 1 > > info locals > > list > > > and send them here on the mailing list. > > Cheers, > Daniel > > On 24/03/2017 14:50, David Escartín Almudévar wrote: > > > > hello all, Daniel > > > > checking the core with the gdb, we have checked the > > variables at the frames of the backtrace, to try to get > > the full sip message seems it seemed truncated. > > checking the buf variable of the frame 11 which > > theorically contains the sip msg to parse we have the > > string > > > > > > SIP/2.0 487 Request Terminated\r\nFrom: "881237046977 > > "sip:881237046977@79.170.68.185;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:5926053324@79.170.68.186:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347: \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP L\263\264\016\020?\337\v\234\262\264\016 ;branch=\327\f\340\r\nVia: SIP/2.0/UDP \020?\337\v\234\262\264\016 :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016 \r\nContent-Length: 0\r\n\r\n > > > > this is i guess how gdb parses the message, so i guess i > > cannot introduce this like that in a xml sipp formal, > > since CRLF is represented as \r\n, so others parts like > > l\337K\016\213\347: \344\003 i have no idea what they > > are, because they also seem to be out of the ASCII table > > ¿? > > anycase, seems the message is very bad formed, and the > > kamailio tries to resolve the host of the Via and it > > gets nothing, so the function get_hash1_case_raw is fed > > by a nul value and seems that the reason it crashes > > > > hope you can retrieve information from that message to > > find out what kind of message it exactly is and see if > > it's possible to avoid kamailio's crash in this scenario > > > > > > best regards > > david > > > > > > > > El vie, 24-03-2017 a las 12:10 +0100, David Escartín > > Almudévar escribió: > > > > > hello all > > > > > > we have experienced a crash and tracing the logs and > > > the core, seems it was because a sip response from an > > > endpoint. > > > a UDP receiver (26248) crashed and the last message we > > > see on it is a 487 quite bad formed > > > > > > Mar 24 01:58:02 > > > mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm [t_lookup.c:1055]: t_check_msg(): ERROR: reply doesn't have a via, cseq or call-id header > > > Mar 24 01:58:17 > > > mia-proxy-inout-1-stby /usr/local/kamailio/sbin/kamailio[26230]: ALERT: <core> [main.c:739]: handle_sigs(): child process 26248 exited by a signal 11 > > > > > > > > > the backtrace of the core > > > (gdb) backtrace > > > #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, > > > len=0) at hashes.h:210 > > > #1 0x000000000045b472 in _dns_hash_find > > > (name=0x7f6906943188, type=1, h=0x7fff120793cc, > > > err=0x7fff120793ac) at dns_cache.c:535 > > > #2 0x0000000000461285 in dns_hash_get > > > (name=0x7f6906943188, type=1, h=0x7fff120793cc, > > > err=0x7fff120793ac) at dns_cache.c:762 > > > #3 0x0000000000467194 in dns_get_entry > > > (name=0x7f6906943188, type=1) at dns_cache.c:2102 > > > #4 0x0000000000468a05 in dns_a_get_he > > > (name=0x7f6906943188) at dns_cache.c:2432 > > > #5 0x0000000000468bb9 in dns_get_he > > > (name=0x7f6906943188, flags=1) at dns_cache.c:2505 > > > #6 0x00000000004696c4 in dns_srv_sip_resolvehost > > > (name=0x7f6906943188, port=0x7fff120795e2, > > > proto=0x7fff120795e1 "\001\330\023") at > > > dns_cache.c:2679 > > > #7 0x000000000046aa37 in dns_sip_resolvehost > > > (name=0x7f6906943188, port=0x7fff120795e2, > > > proto=0x7fff120795e1 "\001\330\023") at > > > dns_cache.c:2849 > > > #8 0x000000000049519e in update_sock_struct_from_via > > > (to=0x7fff12079708, msg=0x7f69069a1dd8, > > > via=0x7f69068f82a8) at forward.c:704 > > > #9 0x0000000000495ee5 in do_forward_reply > > > (msg=0x7f69069a1dd8, mode=0) at forward.c:766 > > > #10 0x00000000004970af in forward_reply > > > (msg=0x7f69069a1dd8) at forward.c:849 > > > #11 0x00000000005197ef in receive_msg ( > > > buf=0xab0d80 "SIP/2.0 487 Request Terminated\r > > > \nFrom: "8888888888 > > > "sip:8888888888@7.7.7.7;user=phone;tag=B7jgc8jQ4m5pB\r\nTo: sip:555555555@8.8.8.8:5060;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., len=367, rcv_info=0x7fff12079a10) at receive.c:299 > > > #12 0x0000000000627b43 in udp_rcv_loop () at > > > udp_server.c:495 > > > #13 0x00000000004b107a in main_loop () at main.c:1600 > > > #14 0x00000000004b842f in main (argc=13, > > > argv=0x7fff12079fb8) at main.c:2616 > > > > > > > > > i have tried to duplicate the issue, but i dont know > > > how to translate l\337K\016 to a xml notation > > > i guess this is some weird that cannot be processed > > > for kamailio > > > > > > could you please take a look and let me know if you > > > know how to duplicate and fix this crash? > > > > > > thanks a lot and regards > > > david > > > > > > > > > > > > _______________________________________________ > > 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 > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com > Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com > _______________________________________________ > 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 www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
-- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
-
Daniel-Constantin Mierla -
David Escartín Almudévar