Re: [OpenSIPS-Users] uac_replace_from not restoring displayname
Hi Bogdan, Hmm, that would be just as confusing i think, i might be able to pull it off by storing the original displayname in an AVP ? Regards, Erik Op 8-7-2010 9:55, Bogdan-Andrei Iancu schreef: Hi Erik, by design, the display name is not restored at all as it is not relevant from SIP point of view in the sequential requests. To avoid confusions, a simple hack I do in script, is, for sequential requests, to completely remove the display name part (also with uac_replace_from). Regards, Bogdan E. Versaevel wrote: Hi all, Is there a reason why uac_replace_from() is not restoring the displayname back to the sipclient? i'm doing a uac_replace_from() to mange the displayname/uri so my asterisk machine wil use the correct sip peer, however packages back to the sipclient only have their URI restored and keep the displayname set with the uac_replace_from() Is this expected behaviour? It's confusing for both me and the end users because you suddenly recieve packages with another displayname. Kind regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel -- Core Network Engineer Infopact Network Solutions Hoogvlietsekerkweg 170 3194 AM Rotterdam Hoogvliet Telefoon+31 (0)88 - 4636777 Fax +31 (0)88 - 4636799 Mobile +31 (0)6 - 6070 e.versae...@infopact.nl www.infopact.nl ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] uac_replace_from not restoring displayname
Hi bogdan, a config snippet would be appreciated, i am using the dialog module at the moment to limit concurrent calls Regards, Erik Op 8-7-2010 11:19, Bogdan-Andrei Iancu schreef: AVPs are not dialog persistent, but you can use dialog module with dialog persistent vars to store the displayname from the original INVITE and apply it in all sequential requests. If you are not familiar with how to use the dialog support, just let me know. Regards, Bogdan Erik Versaevel - InfoPact Netwerkdiensten wrote: Hi Bogdan, Hmm, that would be just as confusing i think, i might be able to pull it off by storing the original displayname in an AVP ? Regards, Erik Op 8-7-2010 9:55, Bogdan-Andrei Iancu schreef: Hi Erik, by design, the display name is not restored at all as it is not relevant from SIP point of view in the sequential requests. To avoid confusions, a simple hack I do in script, is, for sequential requests, to completely remove the display name part (also with uac_replace_from). Regards, Bogdan E. Versaevel wrote: Hi all, Is there a reason why uac_replace_from() is not restoring the displayname back to the sipclient? i'm doing a uac_replace_from() to mange the displayname/uri so my asterisk machine wil use the correct sip peer, however packages back to the sipclient only have their URI restored and keep the displayname set with the uac_replace_from() Is this expected behaviour? It's confusing for both me and the end users because you suddenly recieve packages with another displayname. Kind regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel Erik Versaevel -- Core Network Engineer Infopact Network Solutions Hoogvlietsekerkweg 170 3194 AM Rotterdam Hoogvliet Telefoon+31 (0)88 - 4636777 Fax +31 (0)88 - 4636799 Mobile +31 (0)6 - 6070 e.versae...@infopact.nl www.infopact.nl ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips crashes with db_virtual
I'm guessing this has somthing to do with db_virtual crashing: May 12 08:01:06 INFO:db_mysql:re_init_statement: query is insert into dialog (hash_entry,hash_id,callid,from_uri,from_tag,to_uri,to_tag,caller_sock,callee_sock,start_time,state,timeout,caller_cseq,callee_cseq,caller_route_set,callee_route_set,caller_contact,callee_contact ) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?), ptr=(nil) Op 10-5-2010 10:45, Erik Versaevel - InfoPact Netwerkdiensten schreef: Hi Bogdan, I'm currently not using db_virtual as i don't want the server to crash :) I do have the core file from the 2nd crash, but if i understand you we can't use that because of the destroy_modules() ? If opensips crashes on me again (without using db_virtual) i'll recomple it without the destroy_modules. Kind regards, Erik Versaevel Op 7-5-2010 18:10, Bogdan-Andrei Iancu schreef: Hi Erik, To avoid the core file to be overwritten, try to go in main.c file, function void cleanup(int show_status) (around line 329) and comment the destroy_modules(); line (336) . If you have the real backtrace, please post it here. Regards, bogdan Erik Versaevel wrote: Hi all, I've had some sort of migration yesterday but i ran into a couple of problems, first of which, opensips crashed at random, i've made the following backtraces (core file of the 1st has been overwritten by the 2nd so i won't be able to do anything with the 1st). Switching back to the regular mysql module instead of db_virtual seemed to solve the issue. I've had about 1800 accounts registrered on the server and calling around when it went down. (gdb) bt #0 0xb77b4430 in __kernel_vsyscall () #1 0xb7661651 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7664a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb769849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb76a2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #5 0xb76a5395 in ?? () from /lib/tls/i686/cmov/libc.so.6 #6 0xb76a6f9c in malloc () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7696bf6 in open_memstream () from /lib/tls/i686/cmov/libc.so.6 #8 0xb77006f5 in __vsyslog_chk () from /lib/tls/i686/cmov/libc.so.6 #9 0xb7700c46 in __syslog_chk () from /lib/tls/i686/cmov/libc.so.6 #10 0xb760d93d in syslog (_h=0x81be420, _s=0x8189660) at /usr/include/bits/syslog.h:32 #11 db_mysql_submit_query (_h=0x81be420, _s=0x8189660) at dbase.c:136 #12 0x0811acfd in db_do_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21, val2str=0xb76108b5 db_mysql_val2str, submit_query=0xb760d60c db_mysql_submit_query) at db/db_query.c:177 #13 0xb760d4c5 in db_mysql_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:868 #14 0xb762b894 in db_virtual_insert (_h=0x81be3e0, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:482 #15 0xb7255036 in dialog_update_db (ticks=0, param=0x0) at dlg_db_handler.c:960 #16 0xb724c809 in mod_destroy () at dialog.c:694 #17 0x080bdce0 in destroy_modules () at sr_module.c:370 #18 0x0806ad7a in cleanup (show_status=1) at main.c:336 #19 0x0806b8c7 in handle_sigs () at main.c:533 #20 0x0806efb3 in main_loop (argc=5, argv=0xbf85ff24) at main.c:913 #21 main (argc=5, argv=0xbf85ff24) at main.c:1388 Core was generated by `/usr/local/opensips/sbin/opensips -m 2048 -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 587 d_entry = (d_table-entries[dlg-h_entry]); (gdb) bt #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 #1 0xb725e724 in tmcb_unreference_dialog (t=0x373bed94, type=8192, param=0xb73642d4) at dlg_handlers.c:518 #2 0xb733dd32 in run_trans_callbacks (type=8192, trans=0x373bed94, req=0x0, rpl=0x0, code=0) at t_hooks.c:208 #3 0xb732c91b in free_cell (dead_cell=0x373bed94) at h_table.c:124 #4 0xb732c9c2 in free_hash_table () at h_table.c:342 #5 0xb7339797 in tm_shutdown () at t_funcs.c:99 #6 0x080bdce0 in destroy_modules () at sr_module.c:370 #7 0x0806ad7a in cleanup (show_status=1) at main.c:336 #8 0x0806b8c7 in handle_sigs () at main.c:533 #9 0x0806efb3 in main_loop (argc=5, argv=0xbfc71174) at main.c:913 #10 main (argc=5, argv=0xbfc71174) at main.c:1388 (gdb) Kind Regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel Erik Versaevel ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips crashes with db_virtual
Hi Bogdan, I'm currently not using db_virtual as i don't want the server to crash :) I do have the core file from the 2nd crash, but if i understand you we can't use that because of the destroy_modules() ? If opensips crashes on me again (without using db_virtual) i'll recomple it without the destroy_modules. Kind regards, Erik Versaevel Op 7-5-2010 18:10, Bogdan-Andrei Iancu schreef: Hi Erik, To avoid the core file to be overwritten, try to go in main.c file, function void cleanup(int show_status) (around line 329) and comment the destroy_modules(); line (336) . If you have the real backtrace, please post it here. Regards, bogdan Erik Versaevel wrote: Hi all, I've had some sort of migration yesterday but i ran into a couple of problems, first of which, opensips crashed at random, i've made the following backtraces (core file of the 1st has been overwritten by the 2nd so i won't be able to do anything with the 1st). Switching back to the regular mysql module instead of db_virtual seemed to solve the issue. I've had about 1800 accounts registrered on the server and calling around when it went down. (gdb) bt #0 0xb77b4430 in __kernel_vsyscall () #1 0xb7661651 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7664a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb769849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb76a2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #5 0xb76a5395 in ?? () from /lib/tls/i686/cmov/libc.so.6 #6 0xb76a6f9c in malloc () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7696bf6 in open_memstream () from /lib/tls/i686/cmov/libc.so.6 #8 0xb77006f5 in __vsyslog_chk () from /lib/tls/i686/cmov/libc.so.6 #9 0xb7700c46 in __syslog_chk () from /lib/tls/i686/cmov/libc.so.6 #10 0xb760d93d in syslog (_h=0x81be420, _s=0x8189660) at /usr/include/bits/syslog.h:32 #11 db_mysql_submit_query (_h=0x81be420, _s=0x8189660) at dbase.c:136 #12 0x0811acfd in db_do_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21, val2str=0xb76108b5 db_mysql_val2str, submit_query=0xb760d60c db_mysql_submit_query) at db/db_query.c:177 #13 0xb760d4c5 in db_mysql_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:868 #14 0xb762b894 in db_virtual_insert (_h=0x81be3e0, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:482 #15 0xb7255036 in dialog_update_db (ticks=0, param=0x0) at dlg_db_handler.c:960 #16 0xb724c809 in mod_destroy () at dialog.c:694 #17 0x080bdce0 in destroy_modules () at sr_module.c:370 #18 0x0806ad7a in cleanup (show_status=1) at main.c:336 #19 0x0806b8c7 in handle_sigs () at main.c:533 #20 0x0806efb3 in main_loop (argc=5, argv=0xbf85ff24) at main.c:913 #21 main (argc=5, argv=0xbf85ff24) at main.c:1388 Core was generated by `/usr/local/opensips/sbin/opensips -m 2048 -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 587 d_entry = (d_table-entries[dlg-h_entry]); (gdb) bt #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 #1 0xb725e724 in tmcb_unreference_dialog (t=0x373bed94, type=8192, param=0xb73642d4) at dlg_handlers.c:518 #2 0xb733dd32 in run_trans_callbacks (type=8192, trans=0x373bed94, req=0x0, rpl=0x0, code=0) at t_hooks.c:208 #3 0xb732c91b in free_cell (dead_cell=0x373bed94) at h_table.c:124 #4 0xb732c9c2 in free_hash_table () at h_table.c:342 #5 0xb7339797 in tm_shutdown () at t_funcs.c:99 #6 0x080bdce0 in destroy_modules () at sr_module.c:370 #7 0x0806ad7a in cleanup (show_status=1) at main.c:336 #8 0x0806b8c7 in handle_sigs () at main.c:533 #9 0x0806efb3 in main_loop (argc=5, argv=0xbfc71174) at main.c:913 #10 main (argc=5, argv=0xbfc71174) at main.c:1388 (gdb) Kind Regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel -- Core Network Engineer Infopact Network Solutions Hoogvlietsekerkweg 170 3194 AM Rotterdam Hoogvliet Telefoon+31 (0)88 - 4636777 Fax +31 (0)88 - 4636799 Mobile +31 (0)6 - 6070 e.versae...@infopact.nl www.infopact.nl ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dialogs get stuck
Hi Bogdan,
As far as i have seen the stuck dialogs are in STATE 3 or state 4, i've traced
allmost all state 3
calls to an invalid reply ( send_reply(486, Busy Here : Channel limit
exceeded\n); instead of
send_reply(486, Busy Here : Channel limit exceeded);)
The \n leads to an invalid sip message and calls stuck in state 3.
The state 4 calls seem to be caused by opensips crashing and therefore not
getting the BYE for the calls,
after a crash i restart opensips and end up with the dialogs from the database
(which may nog be accurate anymore)
I'm going to migrate to my opensips environment tomorrow evening, i'll keep you
informed of the results.
Kind regards,
Erik Versaevel
Op 7-5-2010 17:53, Bogdan-Andrei Iancu schreef:
Hi Erik,
Dialog states are :
#define DLG_STATE_UNCONFIRMED 1
#define DLG_STATE_EARLY2
#define DLG_STATE_CONFIRMED_NA 3
#define DLG_STATE_CONFIRMED4
#define DLG_STATE_DELETED 5
Dialog may cumulate in state 3 or 4 (ongoing calls) because of a missing
(or poorly routed) BYE request. Maybe you should check if you have the
BYE for the dialogs that do not exist on CPE but do on opensips.
Again, missing BYE is a common case for having some left-over dialogs.
Regards,
Bogdan
Erik Versaevel wrote:
Hi all,
i'm attempting to build a loadbalancer from opensips to loadbalance requests
to an cluster of asterisk machines.
Users register to opensips and loadbalances the requests for those users to
the asterisk machines.
One of the checks opensips has to perform on a call is if there aren't more
concurrent calls from this user than
his bandwidth would allow. I'm using a slightly modified version of the
example on the website (mainly using other AVP's to
set the maximum allowed simultanious calls).
The problem i'm experiencing is that dialogs seem to get stuck in opensips,
the CPE on the customers side doesn't list a call, the asterisk
machine on the other end of the call doesn't list a call but opensips does,
this results in the CPE beeing unreachable because opensips
thinks it has reached the maximum allowed calls.
I i look at the dialog state i find the following:
opensipsctl fifo dlg_list | grep state | sort | uniq -c
1 state:: 1
4 state:: 2
14 state:: 3
78 state:: 4
5 state:: 5
Is there any documentation on those states?
My routing logic uses loose route afaik so all request within the dialog
should pass my opensips server:
if (has_totag()) {
if (loose_route()) {
if (is_method(INVITE)) {
record_route();
route(1);
} else {
if ( is_method(ACK) ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
exit;
}
}
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}
sl_send_reply(404,Not here - seq no loose
routing);
}
exit;
}
I could send you my complete config if that would help, but it's mostly the
default config with some tweaks (to loadbalance calls to an asterisk
cluster and then send the calls from asterisk to the end users with a
maximum number of concurrent calls
Kind regards,
Erik
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Erik Versaevel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Opensips crashes with db_virtual
Hi all, I've had some sort of migration yesterday but i ran into a couple of problems, first of which, opensips crashed at random, i've made the following backtraces (core file of the 1st has been overwritten by the 2nd so i won't be able to do anything with the 1st). Switching back to the regular mysql module instead of db_virtual seemed to solve the issue. I've had about 1800 accounts registrered on the server and calling around when it went down. (gdb) bt #0 0xb77b4430 in __kernel_vsyscall () #1 0xb7661651 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7664a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb769849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb76a2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #5 0xb76a5395 in ?? () from /lib/tls/i686/cmov/libc.so.6 #6 0xb76a6f9c in malloc () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7696bf6 in open_memstream () from /lib/tls/i686/cmov/libc.so.6 #8 0xb77006f5 in __vsyslog_chk () from /lib/tls/i686/cmov/libc.so.6 #9 0xb7700c46 in __syslog_chk () from /lib/tls/i686/cmov/libc.so.6 #10 0xb760d93d in syslog (_h=0x81be420, _s=0x8189660) at /usr/include/bits/syslog.h:32 #11 db_mysql_submit_query (_h=0x81be420, _s=0x8189660) at dbase.c:136 #12 0x0811acfd in db_do_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21, val2str=0xb76108b5 db_mysql_val2str, submit_query=0xb760d60c db_mysql_submit_query) at db/db_query.c:177 #13 0xb760d4c5 in db_mysql_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:868 #14 0xb762b894 in db_virtual_insert (_h=0x81be3e0, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:482 #15 0xb7255036 in dialog_update_db (ticks=0, param=0x0) at dlg_db_handler.c:960 #16 0xb724c809 in mod_destroy () at dialog.c:694 #17 0x080bdce0 in destroy_modules () at sr_module.c:370 #18 0x0806ad7a in cleanup (show_status=1) at main.c:336 #19 0x0806b8c7 in handle_sigs () at main.c:533 #20 0x0806efb3 in main_loop (argc=5, argv=0xbf85ff24) at main.c:913 #21 main (argc=5, argv=0xbf85ff24) at main.c:1388 Core was generated by `/usr/local/opensips/sbin/opensips -m 2048 -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 587 d_entry = (d_table-entries[dlg-h_entry]); (gdb) bt #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 #1 0xb725e724 in tmcb_unreference_dialog (t=0x373bed94, type=8192, param=0xb73642d4) at dlg_handlers.c:518 #2 0xb733dd32 in run_trans_callbacks (type=8192, trans=0x373bed94, req=0x0, rpl=0x0, code=0) at t_hooks.c:208 #3 0xb732c91b in free_cell (dead_cell=0x373bed94) at h_table.c:124 #4 0xb732c9c2 in free_hash_table () at h_table.c:342 #5 0xb7339797 in tm_shutdown () at t_funcs.c:99 #6 0x080bdce0 in destroy_modules () at sr_module.c:370 #7 0x0806ad7a in cleanup (show_status=1) at main.c:336 #8 0x0806b8c7 in handle_sigs () at main.c:533 #9 0x0806efb3 in main_loop (argc=5, argv=0xbfc71174) at main.c:913 #10 main (argc=5, argv=0xbfc71174) at main.c:1388 (gdb) Kind Regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Dialogs get stuck
Hi all,
i'm attempting to build a loadbalancer from opensips to loadbalance requests to
an cluster of asterisk machines.
Users register to opensips and loadbalances the requests for those users to the
asterisk machines.
One of the checks opensips has to perform on a call is if there aren't more
concurrent calls from this user than
his bandwidth would allow. I'm using a slightly modified version of the example
on the website (mainly using other AVP's to
set the maximum allowed simultanious calls).
The problem i'm experiencing is that dialogs seem to get stuck in opensips, the
CPE on the customers side doesn't list a call, the asterisk
machine on the other end of the call doesn't list a call but opensips does,
this results in the CPE beeing unreachable because opensips
thinks it has reached the maximum allowed calls.
I i look at the dialog state i find the following:
opensipsctl fifo dlg_list | grep state | sort | uniq -c
1 state:: 1
4 state:: 2
14 state:: 3
78 state:: 4
5 state:: 5
Is there any documentation on those states?
My routing logic uses loose route afaik so all request within the dialog should
pass my opensips server:
if (has_totag()) {
if (loose_route()) {
if (is_method(INVITE)) {
record_route();
route(1);
} else {
if ( is_method(ACK) ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
exit;
}
}
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}
sl_send_reply(404,Not here - seq no loose routing);
}
exit;
}
I could send you my complete config if that would help, but it's mostly the
default config with some tweaks (to loadbalance calls to an asterisk
cluster and then send the calls from asterisk to the end users with a maximum
number of concurrent calls
Kind regards,
Erik
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Strange errors forwarding requests
The destination (in this case) is the 1st server in the loadbalancer list (as
there are no other calls).
I've upgraded this machine to ubuntu 10 (from 8) and started getting Connection
Tracking drop messages in my
syslog. I've disabled connection tracking and the issue hasn't appeared since...
Op 5-5-2010 12:24, Bogdan-Andrei Iancu schreef:
Hi Erik,
have you tried to print the destination of the requests that fail?
regards,
Bogdan
Erik Versaevel wrote:
Hi All,
I attempted an migration last night (from our current environment to this
new setup) but i ran into this
problem as soon as i tried to make some test calls, funny thing is i can't
get it reproduced :/ Any clues
on how to debug this any further?
Kind regards,
Erik
Op 27-4-2010 15:17, Erik Versaevel schreef:
Hi all,
I'm building a setup in which opensips is acting as registar for my
endpoints and loadbalancing
calls made by those endpoint over an cluster of asterisk machines. (so that
if we need more asterisk
power, we just have to add another destination to the loadbalancer module)
Opensips is listening on multiple IP addresses and uses the loadbalancer
module to poll my asterisk
machines and select the destination.
My problem is that every now and then opensips fails to forward an invite
to my asterisk cluster and
generates
ERROR:core:udp_send: sendto(sock,0x77b81280,1353,0,0x77b81b04,16):
Operation not permitted(1)
there is some iptables filtering on this machine, however it is not showing
drops in the logfile (and it keeps
occuring even without any iptable rules).
I tried stracing opensips but all i get is:
opensipstrace.7423:sendto(6, INVITE
sip:e164_dst_phone...@opensips_ip_address SIP/2.0
Record-Route:
sip:OPENSIPS_IP_ADDRESS;lr=on;ftag=AI05ED431A05432EB8;nat=yes;did=fd6.e1f16fe3;vsf=AAMIBgl3AggLFgF5HAAFGhwBHzE3NC44MQ--
Via: SIP/2.0/UDP OPENSIPS_IP_ADDRESS;branch=z9hG4bK3177.1e0e38b7.0
Via: SIP/2.0/UDP
192.168.178.44:5060;received=CPE_IP_ADDRESS;rport=61008;branch=z9hG4bK2010Apr222938466E164_DST_PHONE_NR
To: sip:e164_dst_phone...@opensips_ip_address
From: \3961\ sip:3...@opensips_ip_address;tag=AI05ED431A05432EB8
Call-ID: aif001c45e85f79...@192.168.178.44
CSeq: 2 INVITE
Max-Forwards: 69
Contact: sip:e164phone...@cpe_ip_address:61008;line=AIF8F01E8DF866D7CB
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER
Allow-Events: dialog,message-summary
P-Preferred-Identity: sip:e164phone...@opensips_ip_address
Privacy: none
User-Agent: SomeStrangeDude
Content-Type: application/sdp
Content-Length: 324
I-FromDisp: null
I-FromUri: E164PHONE_NR
I-CustId: 3961
v=0
o=intelligate 1133701155 1133701155 IN IP4 192.168.178.44
s=call
c=IN IP4 CPE_IP_ADDRESS
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=direction:active
a=oldmediaip:192.168.178.44
, 1253, 0, {sa_family=AF_INET, sin_port=htons(5060),
sin_addr=inet_addr(ASTERISK_IP_ADDRESS)}, 16) = -1 EPERM (Operation not
permitted)
I also use the uac_replace_from() to mangle the from header so asterisk
uses the correct user/peer/client to connect the call (codec/dialplan etc).
I'm having trouble reproducing the error as it's not allways occuring, the
errors i straced where mainly the initial invite towards my asterisk
cluster and a few 200 OK's which didn't get processed correctly.
Any clues on how to debug this further?
Kind regards,
Erik Versaevel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Erik Versaevel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Strange errors forwarding requests
That might be :)
I'm now running into problems with the dialog module (which i use to limit
concurrent calls).
Calls seem to stick in the dialog module (thus denying additional calls) while
the endpoint isn't
listing the same amount of calls :/
Regards,
Erik
Op 6-5-2010 11:02, Bogdan-Andrei Iancu schreef:
So, after all, it was a network layer configuration issue... :)
Regards,
Bogdan
Erik Versaevel wrote:
The destination (in this case) is the 1st server in the loadbalancer
list (as there are no other calls).
I've upgraded this machine to ubuntu 10 (from 8) and started getting
Connection Tracking drop messages in my
syslog. I've disabled connection tracking and the issue hasn't
appeared since...
Op 5-5-2010 12:24, Bogdan-Andrei Iancu schreef:
Hi Erik,
have you tried to print the destination of the requests that fail?
regards,
Bogdan
Erik Versaevel wrote:
Hi All,
I attempted an migration last night (from our current environment to
this new setup) but i ran into this
problem as soon as i tried to make some test calls, funny thing is i
can't get it reproduced :/ Any clues
on how to debug this any further?
Kind regards,
Erik
Op 27-4-2010 15:17, Erik Versaevel schreef:
Hi all,
I'm building a setup in which opensips is acting as registar for my
endpoints and loadbalancing
calls made by those endpoint over an cluster of asterisk machines.
(so that if we need more asterisk
power, we just have to add another destination to the loadbalancer
module)
Opensips is listening on multiple IP addresses and uses the
loadbalancer module to poll my asterisk
machines and select the destination.
My problem is that every now and then opensips fails to forward an
invite to my asterisk cluster and
generates
ERROR:core:udp_send:
sendto(sock,0x77b81280,1353,0,0x77b81b04,16): Operation not
permitted(1)
there is some iptables filtering on this machine, however it is not
showing drops in the logfile (and it keeps
occuring even without any iptable rules).
I tried stracing opensips but all i get is:
opensipstrace.7423:sendto(6, INVITE
sip:e164_dst_phone...@opensips_ip_address SIP/2.0
Record-Route:
sip:OPENSIPS_IP_ADDRESS;lr=on;ftag=AI05ED431A05432EB8;nat=yes;did=fd6.e1f16fe3;vsf=AAMIBgl3AggLFgF5HAAFGhwBHzE3NC44MQ--
Via: SIP/2.0/UDP OPENSIPS_IP_ADDRESS;branch=z9hG4bK3177.1e0e38b7.0
Via: SIP/2.0/UDP
192.168.178.44:5060;received=CPE_IP_ADDRESS;rport=61008;branch=z9hG4bK2010Apr222938466E164_DST_PHONE_NR
To: sip:e164_dst_phone...@opensips_ip_address
From: \3961\
sip:3...@opensips_ip_address;tag=AI05ED431A05432EB8
Call-ID: aif001c45e85f79...@192.168.178.44
CSeq: 2 INVITE
Max-Forwards: 69
Contact:
sip:e164phone...@cpe_ip_address:61008;line=AIF8F01E8DF866D7CB
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER
Allow-Events: dialog,message-summary
P-Preferred-Identity: sip:e164phone...@opensips_ip_address
Privacy: none
User-Agent: SomeStrangeDude
Content-Type: application/sdp
Content-Length: 324
I-FromDisp: null
I-FromUri: E164PHONE_NR
I-CustId: 3961
v=0
o=intelligate 1133701155 1133701155 IN IP4 192.168.178.44
s=call
c=IN IP4 CPE_IP_ADDRESS
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=direction:active
a=oldmediaip:192.168.178.44
, 1253, 0, {sa_family=AF_INET, sin_port=htons(5060),
sin_addr=inet_addr(ASTERISK_IP_ADDRESS)}, 16) = -1 EPERM
(Operation not permitted)
I also use the uac_replace_from() to mangle the from header so
asterisk uses the correct user/peer/client to connect the call
(codec/dialplan etc).
I'm having trouble reproducing the error as it's not allways
occuring, the errors i straced where mainly the initial invite
towards my asterisk
cluster and a few 200 OK's which didn't get processed correctly.
Any clues on how to debug this further?
Kind regards,
Erik Versaevel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Erik Versaevel
Erik Versaevel
--
Core Network Engineer
Infopact Network Solutions
Hoogvlietsekerkweg 170
3194 AM Rotterdam Hoogvliet
Telefoon+31 (0)88 - 4636777
Fax +31 (0)88 - 4636799
Mobile +31 (0)6 - 6070
e.versae...@infopact.nl
www.infopact.nl
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Strange errors forwarding requests
Hi all,
I'm building a setup in which opensips is acting as registar for my endpoints
and loadbalancing
calls made by those endpoint over an cluster of asterisk machines. (so that if
we need more asterisk
power, we just have to add another destination to the loadbalancer module)
Opensips is listening on multiple IP addresses and uses the loadbalancer module
to poll my asterisk
machines and select the destination.
My problem is that every now and then opensips fails to forward an invite to my
asterisk cluster and
generates
ERROR:core:udp_send: sendto(sock,0x77b81280,1353,0,0x77b81b04,16):
Operation not permitted(1)
there is some iptables filtering on this machine, however it is not showing
drops in the logfile (and it keeps
occuring even without any iptable rules).
I tried stracing opensips but all i get is:
opensipstrace.7423:sendto(6, INVITE
sip:e164_dst_phone...@opensips_ip_address SIP/2.0
Record-Route:
sip:OPENSIPS_IP_ADDRESS;lr=on;ftag=AI05ED431A05432EB8;nat=yes;did=fd6.e1f16fe3;vsf=AAMIBgl3AggLFgF5HAAFGhwBHzE3NC44MQ--
Via: SIP/2.0/UDP OPENSIPS_IP_ADDRESS;branch=z9hG4bK3177.1e0e38b7.0
Via: SIP/2.0/UDP
192.168.178.44:5060;received=CPE_IP_ADDRESS;rport=61008;branch=z9hG4bK2010Apr222938466E164_DST_PHONE_NR
To: sip:e164_dst_phone...@opensips_ip_address
From: \3961\ sip:3...@opensips_ip_address;tag=AI05ED431A05432EB8
Call-ID: aif001c45e85f79...@192.168.178.44
CSeq: 2 INVITE
Max-Forwards: 69
Contact: sip:e164phone...@cpe_ip_address:61008;line=AIF8F01E8DF866D7CB
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER
Allow-Events: dialog,message-summary
P-Preferred-Identity: sip:e164phone...@opensips_ip_address
Privacy: none
User-Agent: SomeStrangeDude
Content-Type: application/sdp
Content-Length: 324
I-FromDisp: null
I-FromUri: E164PHONE_NR
I-CustId: 3961
v=0
o=intelligate 1133701155 1133701155 IN IP4 192.168.178.44
s=call
c=IN IP4 CPE_IP_ADDRESS
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=direction:active
a=oldmediaip:192.168.178.44
, 1253, 0, {sa_family=AF_INET, sin_port=htons(5060),
sin_addr=inet_addr(ASTERISK_IP_ADDRESS)}, 16) = -1 EPERM (Operation not
permitted)
I also use the uac_replace_from() to mangle the from header so asterisk uses
the correct user/peer/client to connect the call (codec/dialplan etc).
I'm having trouble reproducing the error as it's not allways occuring, the
errors i straced where mainly the initial invite towards my asterisk
cluster and a few 200 OK's which didn't get processed correctly.
Any clues on how to debug this further?
Kind regards,
Erik Versaevel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
