Hello,
We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached).
#0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
Any thoughts? Thanks!
There should be another core file for the process that caused the crash. This bt is of kamailio crashing on shutdown..... After the real crash
-- Sent using my phone and may be brief, to the point or contain typos -- On 31 Oct 2014 19:57, "Kristian Kielhofner" kris@kriskinc.com wrote:
Hello,
We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached).
#0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
Any thoughts? Thanks!
-- Kristian Kielhofner
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Indeed, thanks!
Fortunately (and as a testament to the stability of Kamailio), I don't have much experience debugging Kamailio crashes. The real bt:
#0 0x00002acddbc507f2 in update_dlg_timer (tl=0x58, timeout=10) at dlg_timer.c:203 #1 0x00002acddbc3dc6c in dlg_clean_run (ti=23926498) at dlg_hash.c:253 #2 0x00002acddbc28c41 in dlg_clean_timer_exec (ticks=23926498, param=0x0) at dialog.c:1246 #3 0x0000000000536c6f in fork_sync_timer (child_id=-1, desc=0x2acddbc5b789 "Dialog Clean Timer", make_sock=1, f=0x2acddbc28c2a <dlg_clean_timer_exec>, param=0x0, interval=90) at timer_proc.c:232 #4 0x00002acddbc25778 in child_init (rank=0) at dialog.c:733 #5 0x00000000004f80e5 in init_mod_child (m=0x2acdd7731f60, rank=0) at sr_module.c:924 #6 0x00000000004f7f8e in init_mod_child (m=0x2acdd7732c20, rank=0) at sr_module.c:921 #7 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733068, rank=0) at sr_module.c:921 #8 0x00000000004f7f8e in init_mod_child (m=0x2acdd77334b0, rank=0) at sr_module.c:921 #9 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733e00, rank=0) at sr_module.c:921 #10 0x00000000004f7f8e in init_mod_child (m=0x2acdd7739d40, rank=0) at sr_module.c:921 #11 0x00000000004f7f8e in init_mod_child (m=0x2acdd773a150, rank=0) at sr_module.c:921 #12 0x00000000004f7f8e in init_mod_child (m=0x2acdd773b9c0, rank=0) at sr_module.c:921 #13 0x00000000004f7f8e in init_mod_child (m=0x2acdd773be10, rank=0) at sr_module.c:921 #14 0x00000000004f7f8e in init_mod_child (m=0x2acdd773c588, rank=0) at sr_module.c:921 #15 0x00000000004f7f8e in init_mod_child (m=0x2acdd773cdd0, rank=0) at sr_module.c:921 #16 0x00000000004f7f8e in init_mod_child (m=0x2acdd773f610, rank=0) at sr_module.c:921 #17 0x00000000004f7f8e in init_mod_child (m=0x2acdd773fb70, rank=0) at sr_module.c:921 #18 0x00000000004f8269 in init_child (rank=0) at sr_module.c:948 #19 0x000000000046ddb7 in main_loop () at main.c:1696 #20 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
On Fri, Oct 31, 2014 at 2:23 PM, Jason Penton jason.penton@gmail.com wrote:
There should be another core file for the process that caused the crash. This bt is of kamailio crashing on shutdown..... After the real crash
-- Sent using my phone and may be brief, to the point or contain typos --
On 31 Oct 2014 19:57, "Kristian Kielhofner" kris@kriskinc.com wrote:
Hello,
We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached).
#0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
Any thoughts? Thanks!
-- Kristian Kielhofner
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
it looks like a bug fixed after release of 4.1.6 (the bug was also in older releases, but is happening in a rather corner case -- iirc, a call not getting the ACK for 2min or so). Can you install from git branch 4.1?
I was considering releasing 4.1.7 for a while now, most probably it will happen next week.
Cheers, Daniel
On 31/10/14 20:23, Kristian Kielhofner wrote:
Indeed, thanks!
Fortunately (and as a testament to the stability of Kamailio), I don't have much experience debugging Kamailio crashes. The real bt:
#0 0x00002acddbc507f2 in update_dlg_timer (tl=0x58, timeout=10) at dlg_timer.c:203 #1 0x00002acddbc3dc6c in dlg_clean_run (ti=23926498) at dlg_hash.c:253 #2 0x00002acddbc28c41 in dlg_clean_timer_exec (ticks=23926498, param=0x0) at dialog.c:1246 #3 0x0000000000536c6f in fork_sync_timer (child_id=-1, desc=0x2acddbc5b789 "Dialog Clean Timer", make_sock=1, f=0x2acddbc28c2a <dlg_clean_timer_exec>, param=0x0, interval=90) at timer_proc.c:232 #4 0x00002acddbc25778 in child_init (rank=0) at dialog.c:733 #5 0x00000000004f80e5 in init_mod_child (m=0x2acdd7731f60, rank=0) at sr_module.c:924 #6 0x00000000004f7f8e in init_mod_child (m=0x2acdd7732c20, rank=0) at sr_module.c:921 #7 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733068, rank=0) at sr_module.c:921 #8 0x00000000004f7f8e in init_mod_child (m=0x2acdd77334b0, rank=0) at sr_module.c:921 #9 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733e00, rank=0) at sr_module.c:921 #10 0x00000000004f7f8e in init_mod_child (m=0x2acdd7739d40, rank=0) at sr_module.c:921 #11 0x00000000004f7f8e in init_mod_child (m=0x2acdd773a150, rank=0) at sr_module.c:921 #12 0x00000000004f7f8e in init_mod_child (m=0x2acdd773b9c0, rank=0) at sr_module.c:921 #13 0x00000000004f7f8e in init_mod_child (m=0x2acdd773be10, rank=0) at sr_module.c:921 #14 0x00000000004f7f8e in init_mod_child (m=0x2acdd773c588, rank=0) at sr_module.c:921 #15 0x00000000004f7f8e in init_mod_child (m=0x2acdd773cdd0, rank=0) at sr_module.c:921 #16 0x00000000004f7f8e in init_mod_child (m=0x2acdd773f610, rank=0) at sr_module.c:921 #17 0x00000000004f7f8e in init_mod_child (m=0x2acdd773fb70, rank=0) at sr_module.c:921 #18 0x00000000004f8269 in init_child (rank=0) at sr_module.c:948 #19 0x000000000046ddb7 in main_loop () at main.c:1696 #20 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
On Fri, Oct 31, 2014 at 2:23 PM, Jason Penton jason.penton@gmail.com wrote:
There should be another core file for the process that caused the crash. This bt is of kamailio crashing on shutdown..... After the real crash
-- Sent using my phone and may be brief, to the point or contain typos --
On 31 Oct 2014 19:57, "Kristian Kielhofner" kris@kriskinc.com wrote:
Hello,
We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached).
#0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
Any thoughts? Thanks!
-- Kristian Kielhofner
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel,
Well as they say "that was easy".
We'll install from git 4.1 branch and respond with how it goes.
As always, thanks!
On Fri, Oct 31, 2014 at 5:53 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it looks like a bug fixed after release of 4.1.6 (the bug was also in older releases, but is happening in a rather corner case -- iirc, a call not getting the ACK for 2min or so). Can you install from git branch 4.1?
I was considering releasing 4.1.7 for a while now, most probably it will happen next week.
Cheers, Daniel
On 31/10/14 20:23, Kristian Kielhofner wrote:
Indeed, thanks!
Fortunately (and as a testament to the stability of Kamailio), I don't have much experience debugging Kamailio crashes. The real bt:
#0 0x00002acddbc507f2 in update_dlg_timer (tl=0x58, timeout=10) at dlg_timer.c:203 #1 0x00002acddbc3dc6c in dlg_clean_run (ti=23926498) at dlg_hash.c:253 #2 0x00002acddbc28c41 in dlg_clean_timer_exec (ticks=23926498, param=0x0) at dialog.c:1246 #3 0x0000000000536c6f in fork_sync_timer (child_id=-1, desc=0x2acddbc5b789 "Dialog Clean Timer", make_sock=1, f=0x2acddbc28c2a <dlg_clean_timer_exec>, param=0x0, interval=90) at timer_proc.c:232 #4 0x00002acddbc25778 in child_init (rank=0) at dialog.c:733 #5 0x00000000004f80e5 in init_mod_child (m=0x2acdd7731f60, rank=0) at sr_module.c:924 #6 0x00000000004f7f8e in init_mod_child (m=0x2acdd7732c20, rank=0) at sr_module.c:921 #7 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733068, rank=0) at sr_module.c:921 #8 0x00000000004f7f8e in init_mod_child (m=0x2acdd77334b0, rank=0) at sr_module.c:921 #9 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733e00, rank=0) at sr_module.c:921 #10 0x00000000004f7f8e in init_mod_child (m=0x2acdd7739d40, rank=0) at sr_module.c:921 #11 0x00000000004f7f8e in init_mod_child (m=0x2acdd773a150, rank=0) at sr_module.c:921 #12 0x00000000004f7f8e in init_mod_child (m=0x2acdd773b9c0, rank=0) at sr_module.c:921 #13 0x00000000004f7f8e in init_mod_child (m=0x2acdd773be10, rank=0) at sr_module.c:921 #14 0x00000000004f7f8e in init_mod_child (m=0x2acdd773c588, rank=0) at sr_module.c:921 #15 0x00000000004f7f8e in init_mod_child (m=0x2acdd773cdd0, rank=0) at sr_module.c:921 #16 0x00000000004f7f8e in init_mod_child (m=0x2acdd773f610, rank=0) at sr_module.c:921 #17 0x00000000004f7f8e in init_mod_child (m=0x2acdd773fb70, rank=0) at sr_module.c:921 #18 0x00000000004f8269 in init_child (rank=0) at sr_module.c:948 #19 0x000000000046ddb7 in main_loop () at main.c:1696 #20 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
On Fri, Oct 31, 2014 at 2:23 PM, Jason Penton jason.penton@gmail.com wrote:
There should be another core file for the process that caused the crash. This bt is of kamailio crashing on shutdown..... After the real crash
-- Sent using my phone and may be brief, to the point or contain typos --
On 31 Oct 2014 19:57, "Kristian Kielhofner" kris@kriskinc.com wrote:
Hello,
We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached).
#0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
Any thoughts? Thanks!
-- Kristian Kielhofner
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Issue resolved with latest git 4.1 - thanks again!
On Fri, Oct 31, 2014 at 6:19 PM, Kristian Kielhofner kris@kriskinc.com wrote:
Hi Daniel,
Well as they say "that was easy".
We'll install from git 4.1 branch and respond with how it goes.
As always, thanks!
On Fri, Oct 31, 2014 at 5:53 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it looks like a bug fixed after release of 4.1.6 (the bug was also in older releases, but is happening in a rather corner case -- iirc, a call not getting the ACK for 2min or so). Can you install from git branch 4.1?
I was considering releasing 4.1.7 for a while now, most probably it will happen next week.
Cheers, Daniel
On 31/10/14 20:23, Kristian Kielhofner wrote:
Indeed, thanks!
Fortunately (and as a testament to the stability of Kamailio), I don't have much experience debugging Kamailio crashes. The real bt:
#0 0x00002acddbc507f2 in update_dlg_timer (tl=0x58, timeout=10) at dlg_timer.c:203 #1 0x00002acddbc3dc6c in dlg_clean_run (ti=23926498) at dlg_hash.c:253 #2 0x00002acddbc28c41 in dlg_clean_timer_exec (ticks=23926498, param=0x0) at dialog.c:1246 #3 0x0000000000536c6f in fork_sync_timer (child_id=-1, desc=0x2acddbc5b789 "Dialog Clean Timer", make_sock=1, f=0x2acddbc28c2a <dlg_clean_timer_exec>, param=0x0, interval=90) at timer_proc.c:232 #4 0x00002acddbc25778 in child_init (rank=0) at dialog.c:733 #5 0x00000000004f80e5 in init_mod_child (m=0x2acdd7731f60, rank=0) at sr_module.c:924 #6 0x00000000004f7f8e in init_mod_child (m=0x2acdd7732c20, rank=0) at sr_module.c:921 #7 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733068, rank=0) at sr_module.c:921 #8 0x00000000004f7f8e in init_mod_child (m=0x2acdd77334b0, rank=0) at sr_module.c:921 #9 0x00000000004f7f8e in init_mod_child (m=0x2acdd7733e00, rank=0) at sr_module.c:921 #10 0x00000000004f7f8e in init_mod_child (m=0x2acdd7739d40, rank=0) at sr_module.c:921 #11 0x00000000004f7f8e in init_mod_child (m=0x2acdd773a150, rank=0) at sr_module.c:921 #12 0x00000000004f7f8e in init_mod_child (m=0x2acdd773b9c0, rank=0) at sr_module.c:921 #13 0x00000000004f7f8e in init_mod_child (m=0x2acdd773be10, rank=0) at sr_module.c:921 #14 0x00000000004f7f8e in init_mod_child (m=0x2acdd773c588, rank=0) at sr_module.c:921 #15 0x00000000004f7f8e in init_mod_child (m=0x2acdd773cdd0, rank=0) at sr_module.c:921 #16 0x00000000004f7f8e in init_mod_child (m=0x2acdd773f610, rank=0) at sr_module.c:921 #17 0x00000000004f7f8e in init_mod_child (m=0x2acdd773fb70, rank=0) at sr_module.c:921 #18 0x00000000004f8269 in init_child (rank=0) at sr_module.c:948 #19 0x000000000046ddb7 in main_loop () at main.c:1696 #20 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
On Fri, Oct 31, 2014 at 2:23 PM, Jason Penton jason.penton@gmail.com wrote:
There should be another core file for the process that caused the crash. This bt is of kamailio crashing on shutdown..... After the real crash
-- Sent using my phone and may be brief, to the point or contain typos --
On 31 Oct 2014 19:57, "Kristian Kielhofner" kris@kriskinc.com wrote:
Hello,
We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached).
#0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547
Any thoughts? Thanks!
-- Kristian Kielhofner
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Kristian Kielhofner
-
Daniel-Constantin Mierla -
Jason Penton -
Kristian Kielhofner