2 Feb
2010
2 Feb
'10
1:19 p.m.
Hello Aymeric,
I was forwarding some registrations to your domain and didn't get the
deadlock. I did get tcp_send failed many times and then used second dns
record. I have two udp workers.
How fast did you get to lock?
I am using latest 1.5.3 here, what is your output of kamailio -V?
Thanks,
Daniel
On 1/28/10 9:17 PM, Aymeric Moizard wrote:
On Thu, 28 Jan 2010, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla
eLearning class for Kamailio 3.0.0
Starting Feb 8, 2010
* http://www.asipto.com/
On 1/28/10 8:40 PM, Aymeric Moizard wrote:
Sorry, I though I did mentioned it in my initial mail (sent on
kamailio mailing list) however, it waz not the case.
I would have asked on ser-users if it was 3.0 ;)
On Thu, 28 Jan 2010, Andrei Pelinescu-Onciul wrote:
I thought it is 3.0.0, as all your other emails were
related to this
version. On Jan 28, 2010 at 14:56, Daniel-Constantin
Mierla
<miconda(a)gmail.com> wrote:
> I am cc-ing sr-dev, since tcp code is from ser and Andrei may have
> more
> insights...
Is this kamailio 1.5 or kamailio 3.0 (looks like <3.0 to me)?
This is branches/1.5
With svn version 5949. On another hand, if you run 1.x is better to use
the last one, 1.5.3.
I'm pretty sure it's 1.5.3: changelog starts with:
===================== 2009-10-XX Kamailio v1.5.3 released
=====================
Regards,
Aymeric
Please include the version when you report a
problem, otherwise we
can hunt in difference places.
Cheers,
Daniel
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Here is the debug backtrace: with kamailio-dbg_1.5.0_i386.deb
installed:
(gdb) bt
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb7d694ac in sched_yield () from /lib/tls/i686/cmov/libc.so.6
#2 0x080a93fd in tcp_send (send_sock=0x8159d60, type=3,
buf=0xb3992908 "SUBSCRIBE sip:aymeric2@mobipouce.com
SIP/2.0\r\nRecord-Route:
<sip:91.121.81.212:5061;transport=tls;r2=on;lr=on>\r\nRecord-Route:
<sip:91.121.81.212;r2=on;lr=on>\r\nVia: SIP/2.0/TLS
91.121.81.212:5061;branc"..., len=645, to=0xb392f494, id=0) at
fastlock.h:182
#3 0xb79ef679 in send_pr_buffer (rb=0xb392f480, buf=0xb3992908,
len=645) at ../../forward.h:127
#4 0xb79f29ac in t_forward_nonack (t=0xb392f368, p_msg=0x81d02d8,
proxy=0x0) at t_fwd.c:691
#5 0xb79ee784 in t_relay_to (p_msg=0x81d02d8, proxy=0x0,
flags=<value optimized out>) at t_funcs.c:264
#6 0xb79fda11 in w_t_relay (p_msg=0x81d02d8, proxy=0x0, flags=0x0)
at tm.c:1002
#7 0x080551ef in do_action (a=0x8172100, msg=0x81d02d8) at
action.c:874
#8 0x080577df in run_action_list (a=0x8172100, msg=0x81d02d8) at
action.c:145
#9 0x0808f11b in eval_expr (e=0x8172168, msg=0x81d02d8, val=0x0) at
route.c:1171
#10 0x0808ebb0 in eval_expr (e=0x8172190, msg=0x81d02d8, val=0x0) at
route.c:1488
#11 0x0808eb3f in eval_expr (e=0x81721b8, msg=0x81d02d8, val=0x0) at
route.c:1493
#12 0x08055005 in do_action (a=0x81722d0, msg=0x81d02d8) at
action.c:729
#13 0x080577df in run_action_list (a=0x8171928, msg=0x81d02d8) at
action.c:145
#14 0x08055e49 in do_action (a=0x816ba50, msg=0x81d02d8) at
action.c:120
#15 0x080577df in run_action_list (a=0x816ba50, msg=0x81d02d8) at
action.c:145
#16 0x08056d0f in do_action (a=0x816bab8, msg=0x81d02d8) at
action.c:746
#17 0x080577df in run_action_list (a=0x81618c0, msg=0x81d02d8) at
action.c:145
#18 0x08057b93 in run_top_route (a=0x81618c0, msg=0x81d02d8) at
action.c:120
#19 0x08083a0d in receive_msg (
buf=0x81341c0 "SUBSCRIBE sip:aymeric2@mobipouce.com
SIP/2.0\r\nVia: SIP/2.0/UDP
192.168.2.3:6010;rport;branch=z9hG4bK972183375\r\nFrom: \"aymeric\"
<sip:antisip@sip.antisip.com>;tag=286101806\r\nTo:
<sip:aymeric2@mobipouce."..., len=692, rcv_info=0xbfc9ad54) at
receive.c:175
#20 0x080b3943 in udp_rcv_loop () at udp_server.c:460
#21 0x0806b294 in main (argc=-1211358212, argv=0xb7f61590) at
main.c:774
One thing that didn't came up before is that it seems the message
is containing TLS, not TCP. I don't have time to analyse it now
deeper, but I may try to change the SRV to see how it differ.
Tks,
Aymeric
--
Daniel-Constantin Mierla
* http://www.asipto.com/