Re: [OpenSIPS-Users] db_mysql prep stmt took too long
Hi Owais,
It myght be something specific to your mysql setup - at least there is
nothing you can do from the OpenSIPS side. Still keep it mind that your
get the warning when preparing the statement - this is a bit of a
special DB action (it is not an actual query).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.08.2016 16:46, Owais Ahmad wrote:
Hi all,
I am Currently using opensips 2.2.0 and have the following query
threshold set:
loadmodule "db_mysql.so"
modparam("db_mysql", "exec_query_threshold", 5)
I am getting a lot of errors like the following even with a handful of
incoming SIP messages.
WARNING:db_mysql:log_expiry: threshold exceeded : mysql prep stmt took too
long - 61625 us.Source
The database exists on the same host as opensips itself. The DB engine
is InnoDB and its optimized because all external queries to the same
table / database return instantly.
Has anyone else experienced the same?
Any ideas to have this fixed?
Regards,
Owais
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] reject 3xx code
Hello, Bogdan
I understand, thank you very much.
mailto:denis7...@mail.ru
Hi Denis,
3xx is a final response and it cannot be simply drop (as will let the
transaction state machine in an ambiguous state). Not to mention that you will
de-syncronize the callee side (which rejected the call) and the caller side
(still waiting for a final answer).
What you can do is to replace the 3xx with another final negative reply. Use a
failure_route to do that:
failure_route[block_redirect]
{
if (t_check_status("3[0-9][0-9]))
t_reply("404","Not Found");
}
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.08.2016 11:58, Denis wrote:
reject 3xx code Hello
I am using Opensips 2.1.2.
I want to block sending 3xx codes to caller.
In reply route i wrote such code
if (status=~"30[1,2]") {
drop();
}
but i see that 302, for example, still process successfully.
Thank you for any help.
--
mailto:denis7...@mail.ru
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dialog information
In that case, you SHOULD consider opening a feature request on the
tracker ;) It will get your script more efficient.
Thanks and regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 19.08.2016 18:53, Adrian Fretwell wrote:
Bogdan,
Thankyou for the confirmation, yes I have made it work double storing,
I was just trying to make my script as efficient as possible.
Kind regards,
Adrian Fretwell
On 19/08/16 16:40, Bogdan-Andrei Iancu wrote:
Hi Adrian,
Unfortunately there is no way to directly access the dialog info
remotely (from the context of another dialog). Maybe this will be a
great addition if you consider opening a ticket on the GITHUB tracker.
Now, have you managed to make it work using the double storing in
conjunction with get_dialog_info() ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.08.2016 12:03, Adrian Fretwell wrote:
Ok, To put it another way; It seems like an overhead for me to store
say a to_tag so I can retrieve it later when the to_tag is already
stored in the dialog, I just can't work out how to get at it...
if ( t_check_status("200") ) {
store_dlg_value("my_callee_tag","$tt");
}
...
get_dialog_info("my_callee_tag","$var(my_callee_tag)","my_caller_cid","$var(my_srch_call_id)");
Perhaps there is a way I don't need to store something that is
already there?
Kind regards,
Adrian Fretwell
On 17/08/16 19:25, Adrian Fretwell wrote:
Hello all, A simple question that I can't seem to work out for myself:
When I execute the MI command :dlg_list_ctx: I can see lots of
useful information about the dialog like caller_contact:: and
callee_tag:: etc.
Is there a way of retrieving these values from within the script
especially from another dialog? I have tried get_dialog_info but
this will only retrieve values that I have set in the script
through store_dlg_value. Or am I just missing a naming convention
for the other dialog values and attributes?
Kind regards,
Adrian Fretwell
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] reject 3xx code
Hi Denis,
3xx is a final response and it cannot be simply drop (as will let the
transaction state machine in an ambiguous state). Not to mention that
you will de-syncronize the callee side (which rejected the call) and the
caller side (still waiting for a final answer).
What you can do is to replace the 3xx with another final negative reply.
Use a failure_route to do that:
failure_route[block_redirect]
{
if (t_check_status("3[0-9][0-9]))
t_reply("404","Not Found");
}
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.08.2016 11:58, Denis wrote:
reject 3xx code Hello
I am using Opensips 2.1.2.
I want to block sending 3xx codes to caller.
In reply route i wrote such code
if (status=~"30[1,2]") {
drop();
}
but i see that 302, for example, still process successfully.
Thank you for any help.
/--
/mailto:denis7...@mail.ru
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dialog information
Bogdan,
Thankyou for the confirmation, yes I have made it work double storing, I
was just trying to make my script as efficient as possible.
Kind regards,
Adrian Fretwell
On 19/08/16 16:40, Bogdan-Andrei Iancu wrote:
Hi Adrian,
Unfortunately there is no way to directly access the dialog info
remotely (from the context of another dialog). Maybe this will be a
great addition if you consider opening a ticket on the GITHUB tracker.
Now, have you managed to make it work using the double storing in
conjunction with get_dialog_info() ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.08.2016 12:03, Adrian Fretwell wrote:
Ok, To put it another way; It seems like an overhead for me to store
say a to_tag so I can retrieve it later when the to_tag is already
stored in the dialog, I just can't work out how to get at it...
if ( t_check_status("200") ) {
store_dlg_value("my_callee_tag","$tt");
}
...
get_dialog_info("my_callee_tag","$var(my_callee_tag)","my_caller_cid","$var(my_srch_call_id)");
Perhaps there is a way I don't need to store something that is
already there?
Kind regards,
Adrian Fretwell
On 17/08/16 19:25, Adrian Fretwell wrote:
Hello all, A simple question that I can't seem to work out for myself:
When I execute the MI command :dlg_list_ctx: I can see lots of
useful information about the dialog like caller_contact:: and
callee_tag:: etc.
Is there a way of retrieving these values from within the script
especially from another dialog? I have tried get_dialog_info but
this will only retrieve values that I have set in the script through
store_dlg_value. Or am I just missing a naming convention for the
other dialog values and attributes?
Kind regards,
Adrian Fretwell
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Dialog information
Hi Adrian,
Unfortunately there is no way to directly access the dialog info
remotely (from the context of another dialog). Maybe this will be a
great addition if you consider opening a ticket on the GITHUB tracker.
Now, have you managed to make it work using the double storing in
conjunction with get_dialog_info() ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.08.2016 12:03, Adrian Fretwell wrote:
Ok, To put it another way; It seems like an overhead for me to store
say a to_tag so I can retrieve it later when the to_tag is already
stored in the dialog, I just can't work out how to get at it...
if ( t_check_status("200") ) {
store_dlg_value("my_callee_tag","$tt");
}
...
get_dialog_info("my_callee_tag","$var(my_callee_tag)","my_caller_cid","$var(my_srch_call_id)");
Perhaps there is a way I don't need to store something that is already
there?
Kind regards,
Adrian Fretwell
On 17/08/16 19:25, Adrian Fretwell wrote:
Hello all, A simple question that I can't seem to work out for myself:
When I execute the MI command :dlg_list_ctx: I can see lots of useful
information about the dialog like caller_contact:: and callee_tag:: etc.
Is there a way of retrieving these values from within the script
especially from another dialog? I have tried get_dialog_info but
this will only retrieve values that I have set in the script through
store_dlg_value. Or am I just missing a naming convention for the
other dialog values and attributes?
Kind regards,
Adrian Fretwell
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Configure freeswitch and opensips for using tls and udp protocols simultaneously.
Hi Stas. A missing ACK may indicate a problem with the contact in the 200 OK reply (contact pointing back to callee). Do you have a SIP capture on the OpenSIPS side ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 18.08.2016 16:40, Стас Тельнов wrote: I have freeswitch and opensips working with the mobile client in the conference mode. When using UDP connection everything works perfectly, but when using tls connection the call is interrupted in 30 seconds. Whether to use TLS or UDP connection - it is assigned on the mobile client before initialization of connection with opensips server. Originally I assumed that these problems were caused by the NAT settings, but in that case the problem would be watched irrespective of the connection used - UDP or TLS. Generally such scheme works as it should: + udp udp + udp + + + -> + + -> + + -> + + + phone + + SIP + +free + + SIP+ + + <- + + <- + switch + <- + provider + + udp udp+ udp + And in such scheme a call breaks in 30 seconds: + tls + udp + udp + + + -> + + -> + + -> + + + phone + + SIP + +free + + SIP+ + + <- + + <- + switch + <- + provider + + tls + udp+ udp + SIP and freeswitch are in one local area network (Amazon EC2). SIP provider doesn't support tls in principle, they have 5061 closed. And the BYE packet sends freeswitch, as I understand, from packet headers as I didn't receive the response to ACK in time. There is the packet: BYE sip:8@85.236.*.*:55194;ob;transport=tls SIP/2.0 Via: SIP/2.0/TLS sip0.*.*:5061;branch=z9hG4bKc7a2.7909e7e1.0;received=52.58.*.* Via: SIP/2.0/UDP 172.31.*.*;received=52.58.*.*;rport=5060;branch=z9hG4bKBK82Zg50c2U0p Max-Forwards: 69 Contact: To: "8" ;tag=59221e6a From: ;tag=j4aX21rv83etN Call-ID: O7E3ktwLPiQWDN2Rism-7g.. CSeq: 95383912 BYE Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces User-Agent: FreeSWITCH-mod_sofia/1.6.6~64bit Reason: SIP;cause=408;text="ACK Timeout" Content-Length: 0 Having looked on logs, I can tell that the INVITE packet from the mobile client reach freeswitch and provider, but in reverse Trying/Ringing packet doesn't reach. I can't understand at what stage there is a problem. Freeswitch can't respond and transmit the response through opensips, or there is a problem in something else? Who faced similar problem, prompt what settings should be analyzed in order that the above-stated scheme with tls connection start functionning? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Opensips 2.1.2 dr_rules is empty
Hello! Recently i begun to get such problem. Opensips rejects all calls with 404 code. I can solve the problem by making dr_reload. I tried to analyze a log and what i could found you can see in attachment. As i could understand last problem began after dr_reload. Thank you for any help. mailto:denis7...@mail.ruAug 19 17:00:34 opensips-main /usr/local/opensips2.1/sbin/opensips[17749]: INFO:drouting:dr_reload_cmd: dr_reload MI command received! Aug 19 17:00:34 opensips-main /usr/local/opensips2.1/sbin/opensips[17749]: WARNING:drouting:parse_destination_list: destination ID <12367> was not found Aug 19 17:00:34 opensips-main /usr/local/opensips2.1/sbin/opensips[17749]: WARNING:drouting:parse_destination_list: destination ID <15352> was not found Aug 19 17:00:36 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33390710 ms (now 33390810 ms), it may ove rlap.. Aug 19 17:00:36 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33390810 ms (now 33390910 ms), it may ove rlap.. Aug 19 17:00:36 /usr/local/opensips2.1/sbin/opensips[17751]: last message repeated 2 times Aug 19 17:00:36 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33390910 ms (now 33391010 ms), it may ove rlap.. Aug 19 17:00:36 /usr/local/opensips2.1/sbin/opensips[17751]: last message repeated 3 times Aug 19 17:00:36 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33391010 ms (now 33391110 ms), it may ove rlap.. Aug 19 17:00:37 /usr/local/opensips2.1/sbin/opensips[17751]: last message repeated 3 times Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33391110 ms (now 33391210 ms), it may ove rlap.. Aug 19 17:00:37 /usr/local/opensips2.1/sbin/opensips[17751]: last message repeated 3 times Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17755]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17755]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0x7f8f2bb14e78) 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17755]: INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17755]: INFO:db_mysql:db_mysql_do_prepared_query: reconnected to mysql server -> re-init the statement Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33391210 ms (now 33391310 ms), it may ove rlap.. Aug 19 17:00:37 /usr/local/opensips2.1/sbin/opensips[17751]: last message repeated 3 times Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17749]: WARNING:drouting:dr_load_routing_info: table "ast_dr_rules" is empty Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17752]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17752]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0x7f8f2bb15370) 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17752]: INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17752]: INFO:db_mysql:db_mysql_do_prepared_query: reconnected to mysql server -> re-init the statement Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17757]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17757]: INFO:db_mysql:reset_all_statements: reseting all statements on connection: (0x7f8f2bb14e78) 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17757]: INFO:db_mysql:connect_with_retry: re-connected successful for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17757]: INFO:db_mysql:db_mysql_do_prepared_query: reconnected to mysql server -> re-init the statement Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17751]: WARNING:core:utimer_ticker: utimer task already scheduled for 33391310 ms (now 33391410 ms), it may overlap.. Aug 19 17:00:37 /usr/local/opensips2.1/sbin/opensips[17751]: last message repeated 3 times Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17759]: INFO:db_mysql:switch_state_to_disconnected: disconnect event for 0x7f8f2bb14508 Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/ope
