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
…
[View More]differentiate between RPC functions meant to be executed by the master
vs sent to all the slaves?
Thanks
Anthony
[View Less]
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 …
[View More]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
[View Less]
#### 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 …
[View More]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
[View Less]
- 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 -…
[View More]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
[View Less]
### 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 …
[View More]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
[View Less]
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 …
[View More]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…
[View Less]
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.…
[View More]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
[View Less]