sr-users October 2013

sr-users@lists.kamailio.org

78 participants
153 discussions

reload to memory is much slower and has problms after upgrade to 3.3.2 and using mem_join=1
by Uri Shacked 05 Dec '13

05 Dec '13

Hi, I am using MTREE and DIALPLAN modules to load lots of info to kamailio. (6 million rows). When kamailio was running with 3.2.1 (no mem_join=1 option), the used size was increasing but the process of loading the data was fast eanough. I upgraded to 3.3.2 and set mem_join=1. Now the loading process take about 10 time longer and sometimes stops kamailio from responding to traffic. Any ideas? Thanks, Uri

3 19

Loosing rtp only in carrierroute failureroute
by Oliver Roth 26 Nov '13

26 Nov '13

Hi all We do have a strange problem with loosing rtp in case of carrierroute - failureroute. If we send traffic directly to the failure gateway, we do have rtp without any problem Situation: Ua --> Freeswitch --> kamailio 3.3 --> gw 1 Error 404 --> failureroute --> media gateway voiceprompt for error 404 ==> this does not work Ua --> Freeswitch --> kamailio 3.3 rewrite to dest for voiceprompt 404 -->media gateway voiceprompt for error 404 ==> this works!! Any idea? For me it seems being a problem with branching or so. Regards, Oli Configs below: Main routing block request_route { --- do all the checks route(CARRIERROUTE); route(RELAY); } route[RELAY] { xlog(, "L_INFO", "RELAY: Outbound sent via $avp(s:trunk_out)"); # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|SUBSCRIBE")) { t_on_branch("MANAGE_BRANCH"); t_on_reply("MANAGE_REPLY"); xlog(,"L_INFO", "RELAX - Manage branch ...\n"); } if (is_method("INVITE")) { t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # carrierroute route[CARRIERROUTE] { xlog(,"L_INFO","Carrierroute module start \n"); $avp(s:tree) = "default"; # lookup from user and from domain cr_user_carrier("$fU", "$avp(s:trunk_in)", "$avp(s:cr_pref_carr)"); if($avp(s:cr_pref_carr) == 0){ # lookup from domain cr_user_carrier("", "$avp(s:trunk_in)", "$avp(s:cr_pref_carr)"); } if(!cr_route("$avp(s:cr_pref_carr)", "$avp(s:tree)", "$rU", "$rU", "call_id", "$avp(s:todirection)" )){ xlog("cr_route 403 no route found $avp(s:cr_pref_carr)"); sl_send_reply("403", "Not allowed"); exit; } $avp(s:trunk_out) = $avp(s:todirection); route(ALTERHEADER); } failure_route[MANAGE_FAILURE] { if (t_grep_status("486")){ xlog("L_INFO", "Status 486 - busy"); t_reply("486", "Busy"); } #revert_uri(); route(NATMANAGE); if (t_is_canceled()) { exit; } xlog("L_INFO", "failure_route $rd $T_reply_code $avp(s:trunk_in), $avp(s:tree), $rU, $rd, $T_reply_code, $avp(s:tree) \n"); if(!cr_next_domain("$avp(s:cr_pref_carr)", "$avp(s:tree)", "$rU", "$avp(s:trunk_in)", "$T_reply_code", "$avp(s:tree)" )){ xlog("cr_next_domain failed"); exit; } if(!cr_route("$avp(s:cr_pref_carr)", "$avp(s:tree)", "$rU", "$rU", "call_id", "$avp(s:todirection)" )){ xlog("cr_route failed"); exit; } $avp(s:trunk_out) = $avp(s:todirection); if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting setflag(FLT_ACCMISSED); # oro 28.10.13 } route(ALTERHEADER); t_on_failure("MANAGE_FAILURE"); if (!t_relay()) { xlog("failureroute t_relay failed"); exit; } }

1 1

Problem with 4.0 nightlies and IMS - sem_post undefined
by Barry Flanagan 21 Nov '13

21 Nov '13

Hi I am trying to run the Ubuntu nightlies from http://deb.kamailio.org/kamailiodev-nightly and loading the p-cscf config files. Things were working fine while I was on the 20130110 nightlies, but when I upgraded to 20130122 I get the following errors. Any have an idea why sem_post is undefined and how to fix this? 0(1980) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib64/kamailio/modules/ims_registrar_pcscf.so>: /usr/lib64/kamailio/modules/ims_registrar_pcscf.so: undefined symbol: sem_post 0(1980) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib64/kamailio/modules/cdp.so>: /usr/lib64/kamailio/modules/cdp.so: undefined symbol: sem_post 0(1980) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib64/kamailio/modules/ims_qos.so>: /usr/lib64/kamailio/modules/ims_qos.so: undefined symbol: sem_post Thanks -Barry Flanagan

4 10

EOF Error in pass_fd
by Ricardo Martinez 20 Nov '13

20 Nov '13

Hello List. The last weekend our kamailio process crashed with this error : Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10661]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 29 Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10542]: ALERT: <core> [main.c:751]: child process 10601 exited by a signal 11 Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10542]: ALERT: <core> [main.c:754]: core was generated Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10542]: INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD Can someone tell me what seems to be the problem here? We’re using : version: kamailio 3.2.2 (x86_64/linux) 98ba92-dirty flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 98ba92 -dirty compiled on 12:45:36 Feb 2 2012 with gcc 4.4.6 And this is the bt full from gdb Core was generated by `/usr/local/sbin/kamailio -m 1024'. Program terminated with signal 11, Segmentation fault. #0 mi_profile_list (cmd_tree=<value optimized out>, param=<value optimized out>) at dlg_profile.c:789 789 if ( mi_print_dlg( rpl, ph->dlg, 0)!=0 ) Missing separate debuginfos, use: debuginfo-install filesystem-2.4.30-2.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 libcom_err-1.41.12-7.el6.x86_64 libselinux-2.0.94-5.el6.x86_64 mysql-libs-5.1.52-1.el6_0.1.x86_64 nss-softokn-freebl-3.12.7-1.1.el6.x86_64 openssl-1.0.0-20.el6_2.1.x86_64 pcre-7.8-3.1.el6.x86_64 zlib-1.2.3-26.el6.x86_64 (gdb) bt full #0 mi_profile_list (cmd_tree=<value optimized out>, param=<value optimized out>) at dlg_profile.c:789 node = <value optimized out> rpl_tree = 0x20a6790 rpl = 0x20a67b0 profile = 0x7fe99a2dda00 ph = 0x0 profile_name = <value optimized out> value = <value optimized out> i = <value optimized out> #1 0x00007fe9dce287b1 in run_mi_cmd (fifo_stream=<value optimized out>) at ../../lib/kmi/mi.h:77 No locals. #2 mi_fifo_server (fifo_stream=<value optimized out>) at fifo_fnc.c:509 mi_cmd = 0x208f8f0 mi_rpl = <value optimized out> hdl = 0x0 line_len = 41 file_sep = 0x2039017 "" command = 0x7fe9dfdbdef9 "profile_list_dlgs" file = 0x7fe9dfd98d78 "/tmp/openser_receiver_27809" f = 0x2039018 reply_stream = 0x20b0980 #3 0x00007fe9dce2a640 in fifo_process (rank=<value optimized out>) at mi_fifo.c:247 fifo_stream = 0x209a0b0 #4 0x00007fe9dce2a9de in mi_child_init (rank=0) at mi_fifo.c:211 pid = <value optimized out> #5 0x00000000004dba41 in init_mod_child (m=0x7fe9dfc6ba10, rank=0) at sr_module.c:886 No locals. #6 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6bd08, rank=0) at sr_module.c:883 No locals. #7 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6c248, rank=0) at sr_module.c:883 No locals. #8 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6c748, rank=0) at sr_module.c:883 No locals. #9 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6d288, rank=0) at sr_module.c:883 No locals. #10 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6d928, rank=0) at sr_module.c:883 No locals. #11 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6dee0, rank=0) at sr_module.c:883 No locals. #12 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6e1f0, rank=0) at sr_module.c:883 No locals. #13 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6e5d0, rank=0) at sr_module.c:883 No locals. #14 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6e830, rank=0) at sr_module.c:883 No locals. #15 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6ebd0, rank=0) at sr_module.c:883 No locals. #16 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6f220, rank=0) at sr_module.c:883 No locals. #17 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6f648, rank=0) at sr_module.c:883 No locals. #18 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6fa60, rank=0) at sr_module.c:883 No locals. #19 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6fe40, rank=0) at sr_module.c:883 No locals. #20 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc702c0, rank=0) at sr_module.c:883 No locals. #21 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc70ae8, rank=0) at sr_module.c:883 No locals. ---Type <return> to continue, or q <return> to quit--- #22 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc70e18, rank=0) at sr_module.c:883 No locals. #23 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc71100, rank=0) at sr_module.c:883 No locals. #24 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc716c0, rank=0) at sr_module.c:883 No locals. #25 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc71df0, rank=0) at sr_module.c:883 No locals. #26 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc723c0, rank=0) at sr_module.c:883 No locals. #27 0x000000000046077d in main_loop () at main.c:1661 i = <value optimized out> pid = <value optimized out> si = 0x0 si_desc = "udp receiver child=15 sock=64.76.154.35:5060", '\000' <repeats 20 times>, "\003", '\000' <repeats 15 times>, "\030\325\a\232\351\177\000\000\001\000\000\000\002", '\000' <repeats 11 times>, "\001\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000)\000\000\000\000\000\000" #28 0x0000000000461f13 in main (argc=<value optimized out>, argv=0x7fff2f2b2848) at main.c:2475 cfg_stream = <value optimized out> c = <value optimized out> r = <value optimized out> tmp = 0x7fff2f2b3f76 "" tmp_len = 0 options = 0x5a3178 ":f:cm:M:dVhEb:l:L:n:vrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1850310455 rfd = <value optimized out> debug_save = <value optimized out> debug_flag = <value optimized out> dont_fork_cnt = <value optimized out> n_lst = <value optimized out> p = <value optimized out> (gdb) Regards, Ricardo.-

4 7

TLS questions
by Fabian Borot 20 Nov '13

20 Nov '13

Hi, please help me out with these questions: Is it possible to configure kamailio to use different certificates, one per peer? Do we just add them to the same "calist.pem" file? Is is possible to configure kamailio to accept a certificate from another device? I mean instead of Kamailio creating the certificate/key and give it to customer/provider. If that is the case, do we also add it to the "calist.pem" file as well? If all the above is true, what happens when the certificates have different expiration dates? thank you very much

3 7

kamailio tls.reload core dump
by Ding Ma 18 Nov '13

18 Nov '13

Hi, all This is related to the previous tls.reload not safe email chain. Now we have a detailed gdb output that shows the stack trace of the core dump. Please take a look. This looks like a bug. Please let me know if you have any insights on how to fix this. Thanks, Ding

2 6

Kamailio VUC Session on Nov 15
by Daniel-Constantin Mierla 14 Nov '13

14 Nov '13

Hello, we are preparing for a new VUC session to give an update about Kamailio project - a perfect timing as we are just about to release a new major version. We will like to get many developers involved to be able to highlight properly what is new, especially those that did new development for v4.1 - new modules or enhancement to existing modules. However, any developer and community member is welcome to join, we will appreciate it very much, in support of the project. Those that have a google hangout account can participate with video, otherwise there are options to join via sip or pstn audio calls - you can see more details at: - http://vuc.me The number of participants with video is limited, therefore if you plan to do it, let me know to be able to coordinate and send you the invite link when the session starts. No matter you participate with audio/video, you can join the IRC channel #vuc on freenode.net for text chatting during the event. I made quickly a news about the event: - http://www.kamailio.org/w/2013/10/kamailio-update-on-vuc-nov-15-2013/ I will add names of other participants as I get confirmations. Do suggest topics to highlight/discuss there as well. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Nov 25-28 - more details about Kamailio trainings at http://www.asipto.com -

3 3

Variables in event_route[sl:local-response]
by Sergey Okhapkin 14 Nov '13

14 Nov '13

Which variables I can use in event_route[sl:local-response] route to xlog proto:ip:port to which the response will be sent? event_route[sl:local-response] { xlog("L_INFO","Local response to *$??*\n$mb\n"); }

3 2

BUG? - Dialog module timeout BYE is not ok.
by Uri Shacked 11 Nov '13

11 Nov '13

Hi, Following this issue, and the issue "BYE dialog timeout bad syntax" from Julia. I have 2 kamailio servers. srv1 creates a dlg_timeout BYE and sends it to srv2 that forwards the BYE to the next sip server (some other server...). I can definitely see that the BYE that is being forward is malformed. The TO header info is not complete (the port section for example). When a "normal" bye is received from srv1 (not dlg_timeout) all works fine. One thing that i do in this scenario, on srv2 i use uac_replace() on the TO header. So, it is OK that the final destination is different (i do translations). I attached the BYE from both servers. Any ideas? Thanks, Uri You probably meant the To and From headers, I'm guessing. Yeah, as long as there is no display name component, URIs in headers like that don't have to go in <>s. The way Kamailio sends it is grammatically valid, per RFC 3261. The user agents are at fault for not understanding it correctly. Alex Balashov <abalashov at evaristesys.com<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> wrote: >*"BYE headers"? Which headers? *>* *>*Uri Shacked <ushacked at gmail.com <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> wrote: *>* *>>*Hi, *>>* *>>*I think there is a bug with the BYE that is sent to the caller and *>>*callee *>>*when dialog timeout happends. *>>* *>> *The BYE headers are sent with no "<" or ">". *>>*So, some sip singaling points decline the BYE. *>>* *>>*BR, *>>*Uri *>>* *>>* *>>*------------------------------------------------------------------------ *>>* *>>*_______________________________________________ *>>*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> *>>*http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users *>* *>*-- *>*Sent from my mobile, and thus lacking in the refinement one might *>*expect from a fully-fledged keyboard. *>* *>*Alex Balashov - Principal *>*Evariste Systems LLC *>*235 E Ponce de Leon Ave *>*Suite 106 *>*Decatur, GA 30030 *>*United States *>*Tel: +1-678-954-0670 *>*Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ *>* *>*_______________________________________________ *>*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> *>*http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users * -- Sent from my Nexus 10, with all the figments of autocorrect that might imply. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.sip-router.org/pipermail/sr-users/attachments/20130422/0c75272…>

4 11

Segmentaion fault in Kamailio 4.0.3
by Morten Isaksen 05 Nov '13

05 Nov '13

Hi, Our Kamailio has stopped with a segmentation fault 4 times the last week. There has been no changes to the configuration file the last 15 days, so I suspect a SIP phone is sending a SIP packet that Kamailio does not like. We have a core dump file but I cannot read anything usefull from the backtrace. Can you see what is wrong from the backtrace? Regards Morten The output from gdb (bt full): Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -m 256 -M 8 -u kamai'. Program terminated with signal 11, Segmentation fault. #0 0x00007f0e10de17b2 in cancel_branch (t=0x7f0dfbf38e10, branch=0, reason=<value optimized out>, flags=4) at t_cancel.c:284 284 if (cfg_get(tm, tm_cfg, reparse_invite) || Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 hiredis-0.10.1-3.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libxml2-2.7.6-12.el6_4.1.x86_64 mysql-libs-5.1.67-1.el6_3.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6_4.2.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt full #0 0x00007f0e10de17b2 in cancel_branch (t=0x7f0dfbf38e10, branch=0, reason=<value optimized out>, flags=4) at t_cancel.c:284 cancel = <value optimized out> len = <value optimized out> crb = 0x7f0dfbf39008 irb = 0x7f0dfbf38f80 ret = 1 tmp_cd = {cancel_bitmap = 0, reason = {cause = 0, u = {text = {s = 0x0, len = 0}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 0}}}} pcbuf = <value optimized out> __FUNCTION__ = "cancel_branch" #1 0x00007f0e10e298ab in reply_received (p_msg=0x7f0e124ce760) at t_reply.c:2194 msg_status = <value optimized out> last_uac_status = 408 ack = 0x7f0dfbf38e10 "Ð \267\373\r\177" ack_len = <value optimized out> branch = 0 reply_status = <value optimized out> onreply_route = <value optimized out> cancel_data = {cancel_bitmap = 0, reason = {cause = 408, u = {text = {s = 0x0, len = 307468800}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 307468800}}}} uac = <value optimized out> t = 0x7f0dfbf38e10 lack_dst = {send_sock = 0x0, to = {s = {sa_family = 6704, sa_data = "\\#\377\177\000\000\000\000\000\000\000\000\000"}, sin = {sin_family = 6704, sin_port = 9052, sin_addr = {s_addr = 32767}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 6704, sin6_port = 9052, sin6_flowinfo = 32767, sin6_addr = {__in6_u = { __u6_addr8 = "\000\000\000\000\000\000\000\000p{1\022\016\177\000", __u6_addr16 = {0, 0, 0, 0, 31600, 4657, 32526, 0}, __u6_addr32 = {0, 0, 305232752, 32526}}}, sin6_scope_id = 307029856}}, id = 32526, proto = 28 '\034', send_flags = {f = 0 '\000', blst_imask = 0 '\000'}} backup_user_from = <value optimized out> backup_user_to = <value optimized out> backup_domain_from = <value optimized out> backup_domain_to = <value optimized out> backup_uri_from = <value optimized out> backup_uri_to = <value optimized out> backup_xavps = <value optimized out> replies_locked = 0 branch_ret = <value optimized out> prev_branch = <value optimized out> blst_503_timeout = <value optimized out> hf = <value optimized out> onsend_params = {req = 0x8d8a39, rpl = 0x541db4, param = 0x7f0e1253e528, code = 307029856, flags = 32526, branch = 0, t_rbuf = 0x7fff235c1a30, dst = 0x7f0e12317b70, send_buf = { s = 0x375311000000000 <Address 0x375311000000000 out of bounds>, len = 0}} ctx = {rec_lev = 307491008, run_flags = 32526, last_retcode = 5674412, jmp_env = {{__jmpbuf = {140733786626256, 63331951475841423, 139698413054576, 139698413299552, 9276465, 139698039855608, -63254168797292145, 63332490682325391}, __mask_was_saved = 0, __saved_mask = {__val = {139698413734928, 0, 139698411522821, 1, 140733786626608, 6185835, 5972697, 8586176, 9275699, 69026945952, 3, 9276465, 9275673, 139698413738496, 9275961, 139698413760704}}}}} __FUNCTION__ = "reply_received" #2 0x0000000000456444 in do_forward_reply (msg=0x7f0e124ce760, mode=<value optimized out>) at forward.c:799 new_buf = 0x0 dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, id = 0, proto = 0 '\000', send_flags = {f = 0 '\000', blst_imask = 0 '\000'}} new_len = <value optimized out> r = <value optimized out> s = <value optimized out> len = <value optimized out> __FUNCTION__ = "do_forward_reply" #3 0x000000000049e15e in receive_msg (buf=<value optimized out>, len=313, rcv_info=0x7fff235c1cd0) at receive.c:270 msg = 0x7f0e124ce760 ctx = {rec_lev = 11, run_flags = 0, last_retcode = 206110737, jmp_env = {{__jmpbuf = {139698036884436, 11, 219309716216, 139698419720192, 140733786627520, 4294967295, 140733786627647, 1}, __mask_was_saved = 8576456, __saved_mask = {__val = {0, 28, 16, 0, 219305533392, 1, 0, 139698411461552, 219309716216, 139698036884436, 139698413732672, 139698419717800, 139698413732680, 140733786627416, 219305559701, 140733786627288}}}}} ret = <value optimized out> inb = { s = 0x8d8900 "SIP/2.0 100 Trying\r\nVia: SIP/2.0/UDP 178.21.249.20;branch=z9hG4bK8149.c6575a95.0\r\nTo: sip:201@78799865.pbx.one-connect.dk;tag=07c44e68\r\nFrom: sip:201@78799865.pbx.one-connect.dk;tag=a6a1c5f60faecf035a"..., len = 313} __FUNCTION__ = "receive_msg" #4 0x0000000000530e46 in udp_rcv_loop () at udp_server.c:557 ---Type <return> to continue, or q <return> to quit--- len = 313 buf = "SIP/2.0 100 Trying\r\nVia: SIP/2.0/UDP 178.21.249.20;branch=z9hG4bK8149.c6575a95.0\r\nTo: sip:201@78799865.pbx.one-connect.dk;tag=07c44e68\r\nFrom: sip:201@78799865.pbx.one-connect.dk;tag=a6a1c5f60faecf035a"... from = 0x7f0e12538340 fromlen = 16 ri = {src_ip = {af = 2, len = 4, u = {addrl = {2993962576, 0}, addr32 = {2993962576, 0, 0, 0}, addr16 = {15952, 45684, 0, 0, 0, 0, 0, 0}, addr = "P>t\262", '\000' <repeats 11 times>}}, dst_ip = { af = 2, len = 4, u = {addrl = {351868338, 0}, addr32 = {351868338, 0, 0, 0}, addr16 = {5554, 5369, 0, 0, 0, 0, 0, 0}, addr = "\262\025\371\024", '\000' <repeats 11 times>}}, src_port = 35754, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\213\252P>t\262\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 43659, sin_addr = {s_addr = 2993962576}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 43659, sin6_flowinfo = 2993962576, sin6_addr = {__in6_u = { __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x7f0e124cfbd0, proto = 1 '\001'} __FUNCTION__ = "udp_rcv_loop" #5 0x000000000046716a in main_loop () at main.c:1638 i = <value optimized out> pid = <value optimized out> si = <value optimized out> si_desc = "udp receiver child=2 sock=178.21.249.20:5060 \000\000\000\000\200\303P\022\016\177\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000@\350\216\000\000\000\000\000\001\000\000\000\000\000\000\000\200\350\216\000\000\000\000\000\000\000\200\020", '\000' <repeats 12 times>, "\005\000\000\000\000\000\000" nrprocs = <value optimized out> __FUNCTION__ = "main_loop" #6 0x000000000046a002 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:2566 cfg_stream = <value optimized out> c = <value optimized out> r = <value optimized out> tmp = 0x7fff235c377f "" tmp_len = 0 options = 0x5c08c8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1722854551 rfd = <value optimized out> debug_save = <value optimized out> debug_flag = <value optimized out> dont_fork_cnt = <value optimized out> n_lst = <value optimized out> p = <value optimized out> __FUNCTION__ = "main" (gdb) -- Morten Isaksen

2 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2013