Hi devs,
The logs of our Kamailio servers are rich for such lines:
```
Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104)
Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading
```
The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers.
What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/385
Hi,
having some rare issues writing acc-data to a remote MySQL server. The connection is made using the MySQL SSL options. Most, 99,9%, of the writes work well.
The error is:
```
Nov 20 13:48:55 /usr/sbin/kamailio[28976]: WARNING: db_mysql [km_dbase.c:84]: db_mysql_submit_query(): driver error on ping: SSL connection error: socket layer receive error
Nov 20 13:48:55 /usr/sbin/kamailio[28976]: ERROR: db_mysql [km_dbase.c:121]: db_mysql_submit_query(): driver error on query: SSL connection error: socket layer receive error
Nov 20 13:48:55 /usr/sbin/kamailio[28976]: ERROR: <core> [db_query.c:235]: db_do_insert_cmd(): error while submitting query
```
Apart from the connection details (using [mysql-ssl-conf] for the SSL config block) I have this config:
```
modparam("db_mysql", "ping_interval", 30);
modparam("db_mysql", "timeout_interval", 8);
```
The documentation suggests that "ping_interval" is the "Time interval in seconds to send ping messages to MySQL server in order to keep the connection open." However, looking at the code this seems a bit misleading because it looks like the ping is only done on an actual query (db_mysql_submit_query), i.e. not with a regular interval/on a timer as suggested by the documentation?
Also the "auto_reconnect" parameter is stated as default 1 (on), but in the code this is just used as a "retry" of the query itself and MYSQL_OPT_RECONNECT is never set on the connection (https://dev.mysql.com/doc/refman/5.5/en/auto-reconnect.html)? Maybe this is not necessary and it's enough to just re-try the query?
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/406
This patch helps us to handle inadequatness of Linphone mobile apps (both iOS and Android flavours are affected) without reinventing a lot of logics to handle each transport (we use TCP, TLS, WS, WSS).
E.g. if we have two TLS-based Linphone clients, even with enable_double_rr for gentle cross-forwarding we would get single RR header without transport= attribute, resulting in Linphone sending ACK and BYE via UDP.
This new option, being enabled, results in two RR headers being always inserted, with transport attribute being always added. I believe this cannot harm the installation with enable_double_rr, just makes instructions more explicit.
The Linphone's behaviour looks like a set of different bugs, but it would get us much more efforts to fix.
I don't know if any other useragent needs such workaround. So I would perfectly understand if this commit wouldn't be accepted upstream.
Also this commit currently lacks README doc rebuild, because I don't know how to do that. Only XML doc is updated.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/257
-- Commit Summary --
* rr: add enable_double_rr_always option
-- File Changes --
M modules/rr/doc/rr_admin.xml (24)
M modules/rr/record.c (14)
M modules/rr/rr_mod.c (2)
M modules/rr/rr_mod.h (1)
M tcp_read.c (5)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/257.patchhttps://github.com/kamailio/kamailio/pull/257.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/257
I'm on Kamailio version: kamailio 4.3.3 (x86_64/linux) 22e455
When booting up Kamailio I get a Nov 21 20:36:52 sipr kamailio[24460]: 0(24476) DEBUG: <core> [main.c:747]: handle_sigs(): terminating due to SIGCHLD
Kamailio log:
http://pastebin.com/7bHHyHqD
Redis log:
http://pastebin.com/jWyYnbRB
Any ideas is greatly appreciated thanks! :).
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/407
Here are some proposed modifications to handle the P-Charging-Vector header as defined in rfc3455 section 4.6 to
- parse charging vector from SIP message
- generate new unique charging vector
- remove a charging vector header
a new pseudo variable
pseudo variables are exported and enable Read onlly access to charging vector fields
$pcv = whole field
$pcv.value = icid-value field (see RFC3455 section 5.6)
$pcv.genaddr = icid-generated-at field (see RFC3455 section 5.6)
a new function acc_charging_vector()
- g = generate a new charging vector or forward the orginal one
- f = generate a new charging vector regardless of the orginal charging vector
- r = remote the P-Charging vector header from the packet
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/215
-- Commit Summary --
* P-Charging-Vector implementation
* Merge remote branch 'upstream/master'
* P-Charging-Vector
-- File Changes --
M modules/acc/acc_mod.c (18)
A modules/acc/chargingvector.c (435)
A modules/acc/chargingvector.h (18)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/215.patchhttps://github.com/kamailio/kamailio/pull/215.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/215
Repeated use of http_request cause a crash related to the storage of the result in a PV.
Will upload backtraces and other info to this issue. If anyone else have seen this please add info to this bug report.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/400