Re: [SR-Users] database reconnection db_unixodbc
An update regarding this item: I have tested release 5.1.x and 5.2.x and neither release resolves the issue. However I did notice in the master branch that there is new code that is related to this issue. https://github.com/kamailio/kamailio/issues/1681 In issue 1681 there is code that allows Kamailio to start even if a database connection can not be established. Queries attempting to run against the offline database fail gracefully. And once the database is back online, a connection is established and queries against it are successful. However, if at some later point I shut down the database, we're back to the original issue that i reported. Kamailio crashes with the same output as listed before except the first query that is attempted against the offline db causes the crash in this master branch unlike previously (branch 5.0.x, 5.1.x, 5.2.x) the first attempt fails, tries again and fails, and the second attempt causes the crash. Regardless, the output is more or less the same and Kamailio is down. I suspect this might be the same behavior even if one is not using an odbc driver; but maybe not. Anyways, i will open an issue on github for this and hopefully the code change to resolve this is relatively straightforward. Henning, thanks again for your feedback on this. Karthik On Mon, Jan 21, 2019 at 9:09 AM Karthik Srinivasan wrote: > Henning, > > Thank you for the response. > > I will open an issue and test out the latest releases. > > Thanks again for the feedback. > > Karthik > > On Sun, Jan 20, 2019 at 9:31 AM Henning Westerholt > wrote: > >> Am Freitag, 18. Januar 2019, 18:28:09 CET schrieb Karthik Srinivasan: >> > I am testing how kamailio reacts to various database conditions. One >> such >> > condition is if the database engine is simply shut down (that is, >> database >> > server process no longer running, tcp listening socket closed, etc...) >> > >> > I am utilizing the db_unixodbc module to connect to an Informix database >> > engine. >> > >> > I am currently running on Kamailio version 5.0. >> > >> > I have a test query that executes against the database engine every 10 >> > seconds. >> > >> > Here is what i have noticed if i shut down the database engine at some >> > point after i run Kamailio. >> > >> > the first test query that attempts to run against the db engine fails; >> it >> > tries to reconnect and fails. >> > >> > The second test query (10 seconds after the 1st) results in a SIG_CHILD >> and >> > shuts down the entire Kamailio process. >> > >> > Has anyone experienced this? Is there a solution to this? Ideally the >> > second query should also fail and return gracefully; and ideally queries >> > continue to fail until the database engine is back up. >> >> Hello Karthik, >> >> Kamailio should not crash because of this error. The db_unixodbc module >> is not >> that widely used (compared to db_mysql), but nevertheless it shouldn't >> crash. >> >> Can you create an issue in our tracker on github for this: >> https://github.com/kamailio/kamailio/issues >> >> It would be great if you can also try with the latest stable version of >> 5.1.x >> or 5.2.x, there have been some changes in the db_unixodbc module since >> the >> release of 5.0. >> >> Best regards, >> >> Henning >> >> > See logs below: >> > >> > Jan 17 20:07:25 [29297]: INFO: (s) SQL query: FIRST TEST QUERY >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [dbase.c:135]: >> > db_unixodbc_submit_query(): rv=-1. Query= FIRST TEST QUERY >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [connection.c:220]: >> > db_unixodbc_extract_error(): >> > unixodbc:SQLExecDirect=08S01:1:-11020:[Informix][Informix ODBC >> > Driver]Communication link failure. >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [dbase.c:59]: reconnect(): >> > Attempting DB reconnect >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [dbase.c:74]: reconnect(): >> > failed to connect >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [connection.c:220]: >> > db_unixodbc_extract_error(): >> > unixodbc:SQLDriverConnect=08002:1:0:[unixODBC][Driver Manager]Connection >> > name in use >> > Jan 17 20:07:25 [29297]: ERROR: db_unixodbc [connection.c:220]: >> > db_unixodbc_extract_error(): >> > unixodbc:SQLDriverConnect=HY010:2:-11067:[Informix][Informix ODBC >> > Driver]Function sequence error. >> > Jan 17 20:07:25 [29297]: ERROR: [db_query.c:181]: >> db_do_raw_query(): >> > error while submitting query >> > Jan 17 20:07:25 [29297]: ERROR: sqlops [sql_api.c:265]: sql_do_query(): >> > cannot do the query FIRST TEST QUERY >> > Jan 17 20:07:25 [29297]: INFO: (s) [123] SQL ret: fail (-1) >> > Jan 17 20:07:25 [29297]: INFO: (s) [123] SQL res: no rows >> > Jan 17 20:07:35 [29297]: INFO: (s) [123] SQL query: 10 seconds later the >> > SECOND TEST QUERY (it's the same query as the first one) >> > Jan 17 20:07:35 [29301]: CRITICAL: [core/pass_fd.c:277]: >> > receive_fd(): EOF on 28 >> > Jan 17 20:07:35 [29283]: ALERT: [main.c:744]: handle_sigs(): >> child >> >
[SR-Users] Problem at Rx Interface - kamailio P-CSCF 5.1.6
Hi all,
We are using kamailio 5.1.6, configured as P-CSCF, facing following problem.
Please indicate, if you need further information - e.g. I could provide a
tshark trace.
If during call setup (by simulated UAs) at the terminating P-CSCF the simulated
PCRF rejects the Diameter AAR message, then the kamailio P-CSCF runs into a
questionable behaviour.
By calling the Rx_AAR() function in configuration, the processing of the 200 OK
is suspended (by the ims_qos module) and then resumed with the receipt of the
AAA message.
Now the ims_dialog module is called with the dlg_terminate("all", "reason")
function, but the 200 OK has not yet been sent. The ims_dialog sends CANCEL
downstream and 488 upstream. However, the 200 OK is sent additionally. We would
rather have expected the ims_dialog module should send BYE in both directions.
When we respond the CANCEL with 481 Call/Transaction does not exist (which we
MUST according to RFC 3261), then we would expect the ims_dialog module at
least now to react with BYE in both directions.
Could you help? What's our misunderstanding? How could we proceed to get this
issue fixed?
Kind regards
Christoph
P.S.: This is a retransmission, because the original message did not pass
moderator approval due to the attached tshark trace
The information contained in this e-mail message is privileged and confidential
and is for the exclusive use of the addressee. The person who receives this
message and who is not the addressee, one of his employees or an agent entitled
to hand it over to the addressee, is informed that he may not use, disclose or
reproduce the contents thereof, and is kindly asked to notify the sender and
delete the e-mail immediately.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] MWI notification through pua.publish
Hello!
Sorry for my confusion. Now I get it. There are two different IDs. One for
pua.publish and second that I was missing for jsonrpcs.
Thanks everyone for help!
ср, 23 січ. 2019 о 10:05 Daniel-Constantin Mierla пише:
> Hello,
>
> the rpc interface is not matching parameters by name, but by possition.
> You can add them with name, but must be at the right/expected possition.
>
> In your last example, body field is out of parameters structure. And as it
> was pointed out before, you need an id in the root jsonrpc structure.
>
> See some examples at:
>
> -
> https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#idm1028042236
>
> Cheers,
> Daniel
> On 22.01.19 17:58, Володимир Іванець wrote:
>
> Hello Serge,
>
> Thank you for clarifying this for me. But there is different issue when I
> change format. It appears that Kamailio indeed expects *body* under
> parameters
> https://www.kamailio.org/docs/modules/5.2.x/modules/pua_rpc.html#pua_rpc.r.pua.publish
> .
>
> I run:
>
> *# curl -H "Content-Type: application/json" -X POST -d '{"jsonrpc": "2.0",
> "method": "pua.publish", "params": {"presentity_uri":
> "sip:j...@test.tutpro.com ", "expires": "600",
> "event package": "message-summary", "content type":
> "application/simple-message-summary", "id": "4ce8c647a7b947c@172.16.30.151
> <4ce8c647a7b947c@172.16.30.151>", "ETag": ".", "outbound proxy":
> "sip:127.0.0.1:5060;transport=udp", "extra_headers": "P-Flags: 0"}, "body":
> 1}' http://172.16.30.151:5060/JSON_RPC *
>
> Result:
>
> *{*
> *"jsonrpc": "2.0",*
> *"error":{*
> *"code": 400,*
> *"message": "Body is missing"*
> *}*
> *}*
>
>
> Debug:
>
> *Jan 22 18:41:36 test kamailio: 14(27146) DEBUG:
Re: [SR-Users] Maximum Number of Probed Gateways
Greetings, Thank you for your answer. I have my destinations set as a sip uri with ip "sip:xxx.xxx.xxx.xxx:". Is there a way to increase that limit? Best regards, Duarte Rocha Na(o) quarta, 23/01/2019, 08:09, Daniel-Constantin Mierla escreveu: > Hello, > > for keepalive, there should be no limitation, as far as I can remember. > > Upon a quick search, I see that 16 is used as a limit to resolve domains. > Are you having the destination addresses with IP or with hostname? > > Cheers, > Daniel > On 21.01.19 12:35, Duarte Rocha wrote: > > Greetings, > > Is there a limitation to the number of Gateways probed by Dispatcher? > > I have several gateways configured to be probed, but the OPTIONS is only > sent to the first 16? Is there a configuration regarding this? > > Thanks in advance, > > Duarte Rocha > > ___ > Kamailio (SER) - Users Mailing > Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com > Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in > Washington, DC, USA -- www.asipto.com > > ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Maximum Number of Probed Gateways
Hello, for keepalive, there should be no limitation, as far as I can remember. Upon a quick search, I see that 16 is used as a limit to resolve domains. Are you having the destination addresses with IP or with hostname? Cheers, Daniel On 21.01.19 12:35, Duarte Rocha wrote: > Greetings, > > Is there a limitation to the number of Gateways probed by Dispatcher? > > I have several gateways configured to be probed, but the OPTIONS is > only sent to the first 16? Is there a configuration regarding this? > > Thanks in advance, > > Duarte Rocha > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] MWI notification through pua.publish
Hello,
the rpc interface is not matching parameters by name, but by possition.
You can add them with name, but must be at the right/expected possition.
In your last example, body field is out of parameters structure. And as
it was pointed out before, you need an id in the root jsonrpc structure.
See some examples at:
-
https://www.kamailio.org/docs/modules/stable/modules/jsonrpcs.html#idm1028042236
Cheers,
Daniel
On 22.01.19 17:58, Володимир Іванець wrote:
> Hello Serge,
>
> Thank you for clarifying this for me. But there is different issue
> when I change format. It appears that Kamailio indeed expects
> *body* under
> parameters
> https://www.kamailio.org/docs/modules/5.2.x/modules/pua_rpc.html#pua_rpc.r.pua.publish.
>
> I run:
>
> /# curl -H "Content-Type: application/json" -X POST -d
> '{"jsonrpc": "2.0", "method": "pua.publish", "params":
> {"presentity_uri": "sip:j...@test.tutpro.com
> ", "expires": "600", "event
> package": "message-summary", "content type":
> "application/simple-message-summary", "id":
> "4ce8c647a7b947c@172.16.30.151
> ", "ETag": ".", "outbound
> proxy": "sip:127.0.0.1:5060;transport=udp", "extra_headers":
> "P-Flags: 0"}, "body": 1}' http://172.16.30.151:5060/JSON_RPC/
>
> Result:
>
> /{/
> / "jsonrpc": "2.0",/
> / "error": {/
> / "code": 400,/
> / "message": "Body is missing"/
> / }/
> /}/
>
>
> Debug:
>
> /Jan 22 18:41:36 test kamailio: 14(27146) DEBUG:
