Hi list,
I am looking at the python script reload functionality exposed by the
rpc command "app_python.reload" and implemented by the function
app_python_rpc_reload.
The implementation increments a version number and calls
apy_reload_script(). But it looks like apy_reload_script() would be
run invoked in the process where the RPC server lives rather than the
children.
How is it sent to the workers for invocation?
I think I am misunderstanding how the RPC server works: how do you
differentiate between RPC functions meant to be executed by the master
vs sent to all the slaves?
Thanks
Anthony
It's great to see that rtpengine now supports transcoding. I always watched rtpproxy (for so many years) to see when it might happen.
I have some questions. I could not find on ffmpeg.org specific mention of:
-advanced audio jitter buffer capability
-advanced RTP related RFCs, eg. RFC 8108
-advanced codec capability, eg. G711 Appendix II (DTX and CNG)
In particular, it's not clear to me where jitter buffer and RTP RFCs are handled -- inside rtpgengine or ffmpeg. I don't see any mention of jitter
buffer on the rtpengine web and github pages. In general ffmpeg's focus is on content delivery and not bidirectional real-time communication. My
questions:
1) Is there an rtpengine-ffmpeg software architecture or data flow diagram available ?
2) Is it possible to connect libraries besides ffmpeg to the "other side" of rtpengine ? For example, using the rtpengine interface, send and
receive a UDP/RTP packet stream to/from a third-party library and let it handle jitter buffer, encoding/decoding, ptime mismatch (transrating), and
more ?
3) If architecturally that's a do-able thing, is there a spec on how rtpengine is currently interfacing to ffmpeg ? Which APIs are being used ? (I
assume the command line interface is not being used). Re. ffmpeg APIs I found this:
http://dranger.com/ffmpeg/
but maybe there is something more recent or rtpengine source code we can look at.
Thanks.
-Jeff
#### Pre-Submission Checklist
- [X] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] 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
- [X] 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
- [X] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
While testing Kamailio instance with multiple interfaces I noticed that dispatcher probing does not use the socket defined on dispatcher ```list_file```.
By setting flag ```SND_F_FORCE_SOCKET```, in tm module, dispatcher probing or tm t_uac_send() is sourced as per ```socket``` attribute.
Tested on FreeBSD 11.1 and Ubuntu 16.04.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1451
-- Commit Summary --
* tm: flag core to use forced socket when uac socket is set
-- File Changes --
M src/modules/tm/uac.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1451.patchhttps://github.com/kamailio/kamailio/pull/1451.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/1451
- A parameter "control_cmd_tos" has been created in order to set
the type of service for the control channel.
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [ ] 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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
A parameter "control_cmd_tos" has been created in order to set the type of service for the control channel.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1442
-- Commit Summary --
* rtpengine: setting tos value for the control commands
-- File Changes --
M src/modules/rtpengine/doc/rtpengine_admin.xml (21)
M src/modules/rtpengine/rtpengine.c (15)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1442.patchhttps://github.com/kamailio/kamailio/pull/1442.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/1442
### Description
Hello,
related to #265 ,
I can reproduce the issue, with kamailio 4.4.6+jessie from kamailio debian repository
- 0x04 flag is set on save()
- old contacts are deleted on the server receiving the REGISTER message
- old contacts are not deleted on servers being notified via DMQ
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
- Setup 2 servers with dmq & dmq_usrloc replication between each other, and with registration on 1st
- Use 0x04 flag on save() function
- Register your softphones a 1st time on 1 server: registration is replicated on 2d server, contact is on both servers
- Reregister (with different contact) on same server:
- previous contact is deleted on 1st server
- new contact is replicated to 2d server
- previous contact is *NOT* delete on 2d server
#### Log Messages
server1 (REGISTER message):
DEBUG: usrloc [ucontact.c:1692]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE
DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f0096e0b548, callback type 2/15, id 0 entered
DEBUG: dmq_usrloc [usrloc_sync.c:578]: dmq_ul_cb_contact(): Callback from usrloc with type=2
DEBUG: dmq_usrloc [usrloc_sync.c:548]: usrloc_dmq_send_contact(): sending serialized data {"action":1,"aor":"+33564093848","ruid":"uloc-5a86b8c5-31e0-2","c":"sip:+33564093848@xxx:41502;ob","received":"","path":"","callid":"ntoWjs3R3WpP9Z5rsi7Npmr2rRGKstls","user_agent":"CSipSimple_porridge-23/r2457","instance":"","expires":1518779539,"cseq":55952,"flags":0,"cflags":0,"q":-1,"last_modified":1518778639,"methods":8159,"reg_id":0}
DEBUG: dmq_usrloc [usrloc_sync.c:299]: usrloc_dmq_send(): sending dmq broadcast...
server2 (DMQ recipient):
DEBUG: dmq_usrloc [usrloc_sync.c:327]: usrloc_dmq_handle_msg(): dmq message received from sip:usrloc@172.16.67.15:5060
DEBUG: dmq_usrloc [usrloc_sync.c:429]: usrloc_dmq_handle_msg(): Received DMQ_UPDATE. Update contact info...
DEBUG: dmq_usrloc [usrloc_sync.c:64]: add_contact(): aor: +33564093848
DEBUG: dmq_usrloc [usrloc_sync.c:65]: add_contact(): ci->ruid: uloc-5a86b8c5-31e0-2
DEBUG: dmq_usrloc [usrloc_sync.c:66]: add_contact(): aorhash: -1799456359
DEBUG: dmq_usrloc [usrloc_sync.c:72]: add_contact(): Found contact
DEBUG: usrloc [ucontact.c:1692]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE
DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f3900243bd0, callback type 2/15, id 0 entered
DEBUG: dmq_usrloc [usrloc_sync.c:578]: dmq_ul_cb_contact(): Callback from usrloc with type=2
DEBUG: dmq_usrloc [usrloc_sync.c:600]: dmq_ul_cb_contact(): Contact received from DMQ... skip
DEBUG: usrloc [ucontact.c:1004]: db_update_ucontact_ruid(): ruid:uloc-5a86b8c5-31e0-2
DEBUG: usrloc [ucontact.c:1133]: db_update_ucontact_ruid(): contact:sip:+33564093848@xxx:41502;ob
DEBUG: dmq_usrloc [usrloc_sync.c:74]: add_contact(): Release record
DEBUG: dmq_usrloc [usrloc_sync.c:76]: add_contact(): Unlock udomain
the recipient receive an UPDATE message only.
according to usrloc_sync.c:usrloc_dmq_handle_msg(), UPDATE message add the new contact only (execute add_contact()), but the other one is not deleted
and there is no DMQ_RM message generated from the emitter
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
```
version: kamailio 4.4.6 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 4.9.2
```
* **Operating System**:
```
3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux
```
--
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/1445
Module: kamailio
Branch: master
Commit: fd9fe3a677cde97dbf00ef965c45e5b6a495edf7
URL: https://github.com/kamailio/kamailio/commit/fd9fe3a677cde97dbf00ef965c45e5b…
Author: Andreas Granig <agranig(a)sipwise.com>
Committer: Andreas Granig <agranig(a)sipwise.com>
Date: 2018-02-20T11:12:57+01:00
db_redis: re-do appended commands after reconnect
Since hiredis sends out the pipelined command only after
calling redisGetReply(), we need a mechamism to queue up all
appended commands, so we can re-queue them once the connection
is re-established.
This commit introduces a redis command queue used for pipelined
commands to re-do all appended commands in case of a connection drop
(which typically happens in db-mode write-through with very low
traffic, where redis would close the connection due to inactivity).
---
Modified: src/modules/db_redis/redis_connection.c
Modified: src/modules/db_redis/redis_connection.h
Modified: src/modules/db_redis/redis_dbase.c
Modified: src/modules/db_redis/redis_dbase.h
Modified: src/modules/db_redis/redis_table.h
---
Diff: https://github.com/kamailio/kamailio/commit/fd9fe3a677cde97dbf00ef965c45e5b…
Patch: https://github.com/kamailio/kamailio/commit/fd9fe3a677cde97dbf00ef965c45e5b…
I tried to configure dmq module according to README, but got this kind
of error:
Feb 20 07:32:55 rautu /usr/bin/pres-serv[17983]: ERROR: dmq [dmq.c:228]: mod_init(): server_uri is not a socket the proxy is listening on
In the config I have:
modparam("dmq", "server_address", "sip:192.26.133.10:5080")
and just above the error message there is this in syslog:
Feb 20 07:32:55 rautu pres-serv[17959]: Listening on
Feb 20 07:32:55 rautu pres-serv[17959]: tcp: 192.26.133.10 [192.26.133.10]:5080
i.e., server is listening on the same ip/port as in server_address.
I tried also by configuring
modparam("dmq", "server_address", "tcp:192.26.133.10:5080")
since "sip" is not a transport protocol of a socket, but that was
rejected with "server address invalid" error message.
It is confusing that error message refers to server_uri, when modparam
is called server_address.
I must be missing something. Any ideas what it is?
-- Juha