Re: [sr-dev] [kamailio/kamailio] Allow setting AMQP-Headers when publishing messages (Issue #2895)
Yes, but that module does not seem to provide that provide that functionality either. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2895#issuecomment-950362453___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Allow setting AMQP-Headers when publishing messages (Issue #2895)
### Description I am using kazoo-module for connecting Kamailio to RabbitMQ and publishing messages to several consumers. Now I´d like to extend my setup to a more sophisticated routing based on a consistent hash-exchange (https://github.com/rabbitmq/rabbitmq-consistent-hash-exchange), while retaining also existing topology based on routing keys. This can be achieved by using ["Routing on a Header" (hash-header)](https://github.com/rabbitmq/rabbitmq-consistent-hash-exchange#routing-on-a-header). However, [kazoo_publish](https://kamailio.org/docs/modules/5.0.x/modules/kazoo.html#idp30289164) does not allow setting such header. ### Expected behavior Please extend publish-functions of the kazoo-module with the possibility to (optionally) supply AMQP-headers. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2895___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] TOS field not overtaken by RTPengine (#2303)
Thank you very much for the clarification. Maybe it would be good to add it to the documentation. The original description of the issue is for sure invalid, and can be closed/rejected. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2303#issuecomment-621012058___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] TOS field not overtaken by RTPengine (#2303)
Thanks for that clarification - this is what I observed ;-)
>From this description in the module's documentation:
> TOS=... - change the IP TOS value for all outgoing RTP packets within the
> entire call in both directions. Only honoured in an “offer”, ignored for an
> “answer”. Valid values are 0 through 255, given in decimal. If this option is
> not specified, the TOS value will revert to the default TOS (normally 184). A
> value of -1 may be used to leave the currently used TOS unchanged.
Resp. also from the source-comment in daemon/calls.c:
```
/* Handle TOS= parameter. Negative value = no change, not present or too large =
* revert to default, otherwise set specified value. We only do it in an offer,
but
* then for both directions. */
```
I interpreted "no change" as "as received".
What is then actually the difference between negative value ("no change") and >
255 "revert to default"? Both result in the same default?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2303#issuecomment-620414684___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] TOS field not overtaken by RTPengine (#2303)
### Description
Altough setting TOS to -1, the TOS-header of the outgoing RTP stream is always
set to the default TOS (184, resp 0xb0).
### Troubleshooting
Reproduction
Use following flags in rtpengine_manage:
`rtpengine_manage("ICE=remove record-call=on call-id=$avp(correlationId)
TOS=-1");`
and set up a dialog, where the RTP-stream from the UA towards the rtpengine has
TOS-field (e.g.: 0x80).
Based on the documentation
> A value of -1 may be used to leave the currently used TOS unchanged.
the expected behavior was, that also the stream from rtpengine to the other UA
has the same TOS field. However, the stream from rtpengine has the default
value 0xb0
Debugging Data
Relevant call in kamailio.cfg:
```
rtpengine_manage("ICE=remove record-call=on call-id=$avp(correlationId)
TOS=-1");
```
Log Messages
```
2020-04-27T14:50:08.001+02:00 vm1 rtpengine[129780] debug: DEBUG: timer run
time = 0.60 sec
2020-04-27T14:50:08.001+02:00 vm1 rtpengine[130247] debug: DEBUG: timer run
time = 0.60 sec
2020-04-27T14:50:08.968+02:00 vm1 rtpengine[129780] info: INFO:
[75CzR7D4L7Cjjpdhq1dbyS]: Received command 'offer' from 192.168.211.21:47072
2020-04-27T14:50:08.968+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Dump for 'offer' from 192.168.211.21:47072: {
"supports": [ "load limit" ], "sdp": "v=0
o=UA1 0 1 IN IP4 127.0.0.1
s=testcall
t=0 0
m=audio 6001 RTP/AVP 8
c=IN IP4 127.0.0.1
a=rtpmap:8 PCMA/8000
a=sendrecv
a=ptime:20
a=maxptime:20
a=interval:20
", "ICE": "remove", "record-call": "on", "TOS": -1, "call-id":
"75CzR7D4L7Cjjpdhq1dbyS", "received-from": [ "IP4", "127.0.0.1" ], "from-tag":
"1", "command": "offer" }
2020-04-27T14:50:08.968+02:00 vm1 rtpengine[129780] notice: NOTICE:
[75CzR7D4L7Cjjpdhq1dbyS]: Creating new call
2020-04-27T14:50:08.969+02:00 vm1 rtpengine[129780] notice: NOTICE:
[75CzR7D4L7Cjjpdhq1dbyS]: Turning on call recording.
2020-04-27T14:50:08.969+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: kernel call idx is 0
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Default sink codec is PCMA/8000
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: 0 DTMF sink entries
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Creating codec handler for PCMA/8000
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Sink supports codec PCMA/8000
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Using passthrough handler for PCMA/8000
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: creating send_timer
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 0
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 1
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: set FILLED flag for stream 127.0.0.1:6001
2020-04-27T14:50:08.973+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: set FILLED flag for stream 127.0.0.1:6002
2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 2
2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: kernel stream idx is 3
2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] info: INFO:
[75CzR7D4L7Cjjpdhq1dbyS]: Replying to 'offer' from 192.168.211.21:47072
(elapsed time 0.002197 sec)
2020-04-27T14:50:08.974+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Response dump for 'offer' to 192.168.211.21:47072: {
"sdp": "v=0
o=UA1 0 1 IN IP4 127.0.0.1
s=testcall
t=0 0
m=audio 6004 RTP/AVP 8
c=IN IP4 192.168.211.21
a=maxptime:20
a=interval:20
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtcp:6005
a=ptime:20
", "result": "ok" }
2020-04-27T14:50:08.982+02:00 vm1 rtpengine[129780] info: INFO:
[75CzR7D4L7Cjjpdhq1dbyS]: Received command 'answer' from 192.168.211.21:60917
2020-04-27T14:50:08.982+02:00 vm1 rtpengine[129780] debug: DEBUG:
[75CzR7D4L7Cjjpdhq1dbyS]: Dump for 'answer' from 192.168.211.21:60917: {
"supports": [ "load limit" ], "sdp": "v=0
o=UA2 0 1 IN IP4 127.0.0.1
s=testcall
t=0 0
m=audio 6000 RTP/AVP 8
c=IN IP4 127.0.0.1
a=rtpmap:8 PCMA/8000
a=sendrecv
a=ptime:20
a=maxptime:20
a=interval:20
", "ICE": "remove", "record-call": "on", "TOS": -1, "call-id":
"75CzR7D4L7Cjjpdhq1dbyS", "received-from": [ "IP4", "127.0.0.1" ], "from-tag":
Re: [sr-dev] [kamailio/kamailio] kazoo: consuming of events fails if message has no body (#1837)
Thanks for your fast response! Do you maybe see any other solution/workaround that allows consuming messages from the event-exchange-plugin? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1837#issuecomment-460917311___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] kazoo: consuming of events fails if message has no body (#1837)
### Description
Consuming messages without message body fails due to a JSON parsing error:
```
ERROR: kazoo [kz_json.c:287]: kz_json_parse(): Error parsing json: unexpected
end of data
ERROR: kazoo [kz_json.c:288]: kz_json_parse():
ERROR: kazoo [kz_amqp.c:2960]: kz_amqp_send_worker_event(): error parsing json
body
```
This makes it unable to consume messages from RabbitMQ's event exchange plugin
( https://www.rabbitmq.com/event-exchange.html ), as the documentatin states:
**"The message body is always blank."**
### Possible Solutions
As a possible fix I tried following change in kz_amqp.c:
```
void kz_amqp_send_worker_event(kz_amqp_server_ptr server_ptr, amqp_envelope_t*
envelope, kz_amqp_bind_ptr bind)
{
char buffer[100];
kz_amqp_cmd_ptr cmd = NULL;
kz_amqp_consumer_delivery_ptr ptr = NULL;
json_obj_ptr json_obj = NULL;
json_object* JObj = NULL;
str* message_id = NULL;
int idx = envelope->channel-1;
int worker = 0;
int _kz_server_id = server_ptr->id;
int msg_size = envelope->message.body.len;
//begin of changes
int routingkey_size = envelope->routing_key.len;
if (msg_size == 0 && routingkey_size > 0 ) {
char *routingkey_data = pkg_malloc(routingkey_size + 1);
memset(routingkey_data, 0, routingkey_size + 1);
memcpy(routingkey_data, (char*)envelope->routing_key.bytes,
routingkey_size);
LM_DBG("Message size: %d\n", msg_size);
LM_DBG("Routing Key: %s\n", routingkey_data);
char *pos = strchr(routingkey_data,'.');
while (pos){
*pos = '_';
pos = strchr(pos,'.');
}
LM_DBG("New Routing Key: %s\n", routingkey_data);
sprintf(buffer, "kazoo:%s", routingkey_data);
if(kz_amqp_consumer_fire_event(buffer) != 0) {
LM_ERR("kazoo:%s not found", routingkey_data);
}
pkg_free(routingkey_data);
return;
}
char *json_data = pkg_malloc(msg_size + 1);
if(!json_data) {
LM_ERR("no more package memory available. needed %d\n", msg_size
+ 1);
return;
}
char *json_data = pkg_malloc(msg_size + 1);
//end of changes
if(!json_data) {
LM_ERR("no more package memory available. needed %d\n", msg_size
+ 1);
return;
}
```
The change is rather simple: If there is no message-body supplied, the
event-route _kazoo:_ is called (after replacing any '.' with '_'
in the routing_key).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1837___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] sqlops offline database start and live re-connect (#1681)
Just opened https://github.com/kamailio/kamailio/pull/1706 - as this is my first pull request at all, I hope I did everything correctly ... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1681#issuecomment-435702016___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Allow startup with offline database. See issue https://github.com/kam… (#1706)
…ailio/kamailio/issues/1681 Pre-Submission Checklist - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) Checklist: - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue # (replace with an open issue number) Description You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1706 -- Commit Summary -- * Allow startup with offline database. See issue https://github.com/kamailio/kamailio/issues/1681 -- File Changes -- M src/modules/sqlops/README (25) M src/modules/sqlops/sqlops.c (34) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1706.patch https://github.com/kamailio/kamailio/pull/1706.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/1706 ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] sqlops offline database start and live re-connect (#1681)
Thanks for your suggestions. I first tried the periodic timer, but I somehow did not get it working for the child-processes: altough I started a timer in each child, and the timer-method was even executed per child, it was always executed in the same process (verified with getpid()), so that the "postponed" initialization happen only in one process. Anyhow, I then focussed on another approach, where the initialization is triggered with each sql-query, instead of periodically (which is anyway the more efficient way). A first version worked quite well in my tests, and I am already trying to figure out how to open a PR ;-) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1681#issuecomment-435677963___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] sqlops blocks startup of kamailio if database unreachable (#1681)
### Description I´m using kamailio´s sqlops-module on a postgresql database. If the database server gets unreachable during operation, sqlops detects this and tries to reconnect: ``` 14:40:48.784 WARNING: db_postgres [km_dbase.c:259]: db_postgres_submit_query(): postgres query command failed, connection status 1, error [no connection to the server] 14:40:48.784 DEBUG: db_postgres [km_dbase.c:262]: db_postgres_submit_query(): resetting the connection to postgress server 14:40:48.784 ERROR: db_postgres [km_dbase.c:267]: db_postgres_submit_query(): 0x7f80a8093680 PQsendQuery Error: could not connect to server: Connection refused ``` and finally, when the DB comes up again, succeeds in executing queries: ``` 14:41:39.738 WARNING: db_postgres [km_dbase.c:259]: db_postgres_submit_query(): postgres query command failed, connection status 1, error [SSL connection has been closed unexpectedly] 14:41:39.739 DEBUG: db_postgres [km_dbase.c:262]: db_postgres_submit_query(): resetting the connection to postgress server 14:41:39.810 DEBUG: db_postgres [km_dbase.c:249]: db_postgres_submit_query(): sending query ok: 0x7f80a8093680 (1) ``` So, obviously the module can handle database outages well. But if the DB is already down when kamailio is started, the cyclic reconnect does not work. Instead, kamailio fails to start immediately: ``` 14:57:54.187 CRITICAL: [main.c:1614]: main_loop(): Cannot fork 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:112]: db_postgres_new_connection(): PQconnectdbParams(0x136bfb0) 14:57:54.188 DEBUG: [core/sr_module.c:938]: init_mod_child(): idx 12 rank -1: rtimer [timer] 14:57:54.188 DEBUG: [core/sr_module.c:938]: init_mod_child(): idx 12 rank -1: sqlops [timer] 14:57:54.188 DEBUG: [core/sr_module.c:708]: find_mod_export_record(): found export of in module db_postgres [/usr/lib64/kamailio/modules/db_postgres.so] 14:57:54.188 DEBUG: [db.c:209]: db_bind_mod(): using db bind api for db_postgres 14:57:54.188 DEBUG: [db.c:314]: db_do_init2(): connection 0x7f23c0154120 not found in pool 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:56]: db_postgres_new_connection(): db_id = 0x7f23c0154120 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:70]: db_postgres_new_connection(): 0x7f23c0154380=pkg_malloc(80) 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:84]: db_postgres_new_connection(): opening connection: postgres://:@xx 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:112]: db_postgres_new_connection(): PQconnectdbParams(0x13a41e0) 14:57:54.188 ERROR: db_postgres [km_pg_con.c:115]: db_postgres_new_connection(): could not connect to server: Connection refused Is the server running on host "" () and accepting TCP/IP connections on port 5432? 14:57:54.188 ERROR: db_postgres [km_pg_con.c:148]: db_postgres_new_connection(): cleaning up 0x7f23c0154380=pkg_free() 14:57:54.188 ERROR: [db.c:318]: db_do_init2(): could not add connection to the pool 14:57:54.188 ERROR: sqlops [sql_api.c:164]: sql_connect(): failed to connect to the database [cb] 14:57:54.188 ERROR: [core/sr_module.c:942]: init_mod_child(): error while initializing module sqlops (/usr/lib64/kamailio/modules/sqlops.so) (idx: 12 rank: -1 desc: [timer]) 14:57:54.189 ERROR: [core/pt.c:340]: fork_process(): init_child failed for process 12, pid 24036, "timer" 14:57:54.189 CRITICAL: [main.c:1691]: main_loop(): cannot fork timer process 14:57:54.189 ALERT: [main.c:743]: handle_sigs(): child process 24009 exited normally, status=255 14:57:54.190 ALERT: [main.c:743]: handle_sigs(): child process 24010 exited normally, status=255 14:57:54.190 ALERT: [main.c:743]: handle_sigs(): child process 24011 exited normally, status=255 14:57:54.191 ALERT: [main.c:743]: handle_sigs(): child process 24013 exited normally, status=255 14:57:54.191 ALERT: [main.c:743]: handle_sigs(): child process 24015 exited normally, status=255 14:57:54.191 ALERT: [main.c:743]: handle_sigs(): child process 24019 exited normally, status=255 14:57:54.191 ALERT: [main.c:743]: handle_sigs(): child process 24030 exited normally, status=255 14:57:54.192 INFO: [main.c:771]: handle_sigs(): terminating due to SIGCHLD 14:57:54.192 INFO: [main.c:826]: sig_usr(): signal 15 received 14:57:54.192 INFO: [main.c:826]: sig_usr(): signal 15 received ``` Reproduction - use kamailio-script with sqlops - stop kamailio - stop database - try to start kamailio Log Messages see above ### Additional Information * **Kamailio Version** - output of `kamailio -v` kamailio 5.1.2 (x86_64/linux) * **Operating System**: RHEL 7.4 on x86_64 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1681___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
