Hi,
Some percentage of requests processed with async_route("REQ_PROCESS", "5") seem to end up with a resumed transaction, though most do. Not sure what the exact percentage is. The ones that don't
Is this due to excessive requests? Is there a limit on internal IPC queue depth? Is it conceptually similar to a generic shared blocking queue internally, along the lines of 'mqueue'? Is there any reasonable way to troubleshoot this?
Thanks!
-- Alex
--
Alex Balashov
Principal Consultant
…
[View More]Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
[View Less]
Hi,
Can DISPATCHER be used in conjunction with ENUM?
E.g., to avoid sending requests to SIP destinations that are returned by ENUM, but, which DISPATCHER knows are down?
Thanks,
Jawaid
I have a multi-homed kam with a uas behind one private interface and a
public interface for the uac+sip provider.
When the uac initiates a call, kam sends the invite to the private uas
which sets up a b-leg call back to kam with a Contact header that has the
uas' private ip address. I want to change that private ip address to be
Kamailio's advertised/public ip address before it gets forwarded to the sip
provider.
I am rewriting Contact in a route from request_route like this:
> if ($rP != …
[View More]$null) {
> $var(ct) = ";transport=" + $rP;
> }else{
> $var(ct) = "";
> }
> $var(cr) = "<sip:" + $fU + "@" + $RAi + ":" + $RAp + $var(ct) + ">";
>
> remove_hf("Contact");
> append_hf("Contact: $var(cr)\r\n");
This seems to work fine for the INVITE going to the provider.
There's also the 200 OK that the uas sends for the uac (a-leg) with a
private ip address in Contact -- I want to rewrite that before sending it
to the UAC, too.
Using the same method as above (but inside onreply_route), what happens is
the UAC receives the modified OK and sends back an ACK with the modified
Contact (kam's public ip addr) in the ACK r-uri, and kam gets in a loop of
sending an ACK from its private ip address to its public ip address and
replying to itself.
call flows: https://imgur.com/a/Yj2DJpn
Is there a right way to do this?
[View Less]
Hello,
https://www.kamailio.org/docs/modules/devel/modules/htable#htable.p.htable says for
modparam('htable', 'htable', '…autoexpire … updateexpire…')
autoexpire -time in seconds to delete an item from a hash table if no update was done to it. If is missing or set to 0, the items won't expire.
updateexpire - if set to 1 (default), the time until expiration of an item is reset when that item is updated. Certain uses of htable may dictate that
updates should not reset the expiration timeout, …
[View More]however, in which case this attribute can be set to 0.
My reading is that, when a value is updated and autoexpire is positive, autoexpire will reset the timer, but updateexpire may or may not reset the
same timer.
That is:
modparam('htable', 'htable', 'a=>autoexpire=5;updatedelete=1')
modparam('htable', 'htable', 'b=>autoexpire=5;updatedelete=0')
If b was not updated for 5s, will it be removed, as the documentation for autoxpire suggests, irrespective of updatedelete?
Greetings
Dilyan
[View Less]
Hello,
when I use
dns_try_naptr=on
corelog=-1
debug=-1
enable_tls=yes
use_dns_cache=off
dns_cache_init=off
modparam("topoh", "mask_key", "TEAI32l)- eauiDEUIA!?()")
and run Kamailio under valgrind, Kamailio logs:
20(21) ERROR: kemix [kemix_mod.c:229]: ki_kx_get_ruri_attr(): failed to parse the R-URI
20(21) ERROR: rr [loose.c:1011]: loose_route_mode(): failed to parse Request URI
The workflow is: I start Kamailio. A UDP-client registers. Then a websocket client calls the UDP-client. …
[View More]Finally the websocket client hangs up.
Valgrind does not report anything suspicious.
When I use instead
modparam("topoh", "mask_key", "TEAI32l")
for the same workflow, with the same configuration, valgrind logs:
==14== Invalid read of size 4
==14== at 0x4867E5: atomic_cmpxchg_int (atomic_x86.h:224)
==14== by 0x486830: futex_get (futexlock.h:99)
==14== by 0x490CE4: dns_hash_get (dns_cache.c:673)
==14== by 0x4972A6: dns_get_entry (dns_cache.c:2001)
==14== by 0x499288: dns_srv_get_he (dns_cache.c:2455)
==14== by 0x597AAD: no_naptr_srv_sip_resolvehost (resolve.c:1599)
==14== by 0x598332: naptr_sip_resolvehost (resolve.c:1675)
==14== by 0x5983C5: _sip_resolvehost (resolve.c:1707)
==14== by 0x49943B: dns_srv_sip_resolvehost (dns_cache.c:2516)
==14== by 0x49B3DD: dns_sip_resolvehost (dns_cache.c:2738)
==14== by 0x59846A: sip_hostport2su (resolve.c:1727)
==14== by 0x4CB951: forward_request (forward.c:515)
==14== by 0x99993CD: t_relay_to (t_funcs.c:300)
==14== by 0x99EBA32: _w_t_relay_to (tm.c:1764)
==14== by 0x99F4DEB: ki_t_relay (tm.c:2917)
==14== by 0xA80A94B: sr_kemi_lua_exec_func_ex (app_lua_api.c:1022)
==14== by 0xA81237D: sr_kemi_lua_exec_func (app_lua_api.c:1706)
==14== by 0xA81B93F: sr_kemi_lua_exec_func_209 (app_lua_kemi_export.c:1717)
==14== by 0xA8383C0: luaD_precall (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA84C4CA: luaV_execute (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA838C90: luaD_callnoyield (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA837029: luaD_rawrunprotected (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA8391DF: luaD_pcall (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA8333DE: lua_pcallk (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA806F0C: app_lua_run_ex (app_lua_api.c:773)
==14== by 0xA825F06: sr_kemi_config_engine_lua (app_lua_mod.c:119)
==14== by 0x5048BE: sr_kemi_route (kemi.c:3784)
==14== by 0x588909: receive_msg (receive.c:502)
==14== by 0xA609ADF: ws_frame_receive (ws_frame.c:644)
==14== by 0x4BCAAB: sr_event_exec (events.c:299)
==14== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14==
==14==
==14== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==14== Access not within mapped region at address 0x0
==14== at 0x4867E5: atomic_cmpxchg_int (atomic_x86.h:224)
==14== by 0x486830: futex_get (futexlock.h:99)
==14== by 0x490CE4: dns_hash_get (dns_cache.c:673)
==14== by 0x4972A6: dns_get_entry (dns_cache.c:2001)
==14== by 0x499288: dns_srv_get_he (dns_cache.c:2455)
==14== by 0x597AAD: no_naptr_srv_sip_resolvehost (resolve.c:1599)
==14== by 0x598332: naptr_sip_resolvehost (resolve.c:1675)
==14== by 0x5983C5: _sip_resolvehost (resolve.c:1707)
==14== by 0x49943B: dns_srv_sip_resolvehost (dns_cache.c:2516)
==14== by 0x49B3DD: dns_sip_resolvehost (dns_cache.c:2738)
==14== by 0x59846A: sip_hostport2su (resolve.c:1727)
==14== by 0x4CB951: forward_request (forward.c:515)
==14== by 0x99993CD: t_relay_to (t_funcs.c:300)
==14== by 0x99EBA32: _w_t_relay_to (tm.c:1764)
==14== by 0x99F4DEB: ki_t_relay (tm.c:2917)
==14== by 0xA80A94B: sr_kemi_lua_exec_func_ex (app_lua_api.c:1022)
==14== by 0xA81237D: sr_kemi_lua_exec_func (app_lua_api.c:1706)
==14== by 0xA81B93F: sr_kemi_lua_exec_func_209 (app_lua_kemi_export.c:1717)
==14== by 0xA8383C0: luaD_precall (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA84C4CA: luaV_execute (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA838C90: luaD_callnoyield (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA837029: luaD_rawrunprotected (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA8391DF: luaD_pcall (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA8333DE: lua_pcallk (in /lib64/kamailio/modules/app_lua.so)
==14== by 0xA806F0C: app_lua_run_ex (app_lua_api.c:773)
==14== by 0xA825F06: sr_kemi_config_engine_lua (app_lua_mod.c:119)
==14== by 0x5048BE: sr_kemi_route (kemi.c:3784)
==14== by 0x588909: receive_msg (receive.c:502)
==14== by 0xA609ADF: ws_frame_receive (ws_frame.c:644)
==14== by 0x4BCAAB: sr_event_exec (events.c:299)
The stacktrace with the values of the variables is available at https://github.com/kamailio/kamailio/issues/3350 . Or at least these things seem very
similar to me.
Any idea?
I can share the OCI-image and the full configuration.
Greetings
Дилян
[View Less]
Hello,
The latest debian packages are built without autocomplete for kamcmd.
Do we have the libreadline-dev package installed on the build machine?
I know that we have kamctl rpc and kamcli, but if we are still
shipping kamcmd, it should have the autocomplete feature enabled.
Regards,
Ovidiu Sas
--
VoIP Embedded, Inc.
http://www.voipembedded.com
I try to workout if - currently it would work, or - where and how to debug more:
I face - 2 interfacec - public internet (so, TLS + sRTP) is desired
and private - old infrastructure - i mus only use plain RTP
172.23.9.70 - private ip - from this endpoint of kamailio and rtpengine should send only basic RTP
172.23.210.75:5060 private - target for kamailio
1.2.3.24 obfuscated public IP (TLS + sRTP required)
kamailio 5.4.4 (x86_64/linux)
rtpengine -v Version: 11.1.1.4-1~bpo11+1
all i do …
[View More]is:
if (proto==TLS) {
rtpengine_manage("RTP/AVP ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=external direction=internal record-call=on");
} else if ($ru =~ "transport=tls") {
rtpengine_manage("DTLS=on SRTP AVPF ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=internal direction=external record-call=on media-address=1.2.3.24");
}
# 1.2.3.24 obfuscated public IP
172.23.210.75:5060 is in dispatch.cfg, as '11'
route[SBC_CORE] {
append_hf("X-My-SRTP: removed31337\r\n");
### i see this text in invtes from kamailio 172.23.9.70 towards 172.23.210.75:5060
### i see only RTP, so as expected
if (!ds_select_dst("11", "0")) {
xwarn("I:$var(i) DROP(DOWN!) FWD:$rm [$fU->$tU] [SBCVIP] to $du\n");
sl_send_reply("503", "Destination down");
exit;
}
what i did:
certificate is a paid one (the public party needs it)
TLS works
i deleted - entries in (not kamailo) cryptosuite that caused this:
13:08:05 localhost rtpengine[15140]: ERR: [51ad8758-b64d-4d2f-9fd0-41d03a38f74d]: [core] Failed to parse a=crypto attribute, ignoring: unknown crypto suite
Tried to search for any "ready" examples for this - only found old threads and - that this should be possible, but - no example for woking config.
what i see:
Jan 19 19:00:57 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000038 sec
Jan 19 19:00:58 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000036 sec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Closing call due to timeout
Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Redis delete_async=0
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Final packet stats:
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag 'JVR5LTs', created 60:00 ago for branch ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/SAVP) using unknown codec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30136 <> 52.129.106.28:17030, SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30137 <> 52.129.106.28:17031 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag '', created 60:00 ago for branch ''
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to 'JVR5LTs'
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for 'JVR5LTs'
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e
Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Moved metadata file "/var/spool/rtpengine/tmp/rtpengine-meta-c17bab16-5eea-492e-b1c4-ac9387f3e265-7003946f152c6c8d.tmp" to "/var/spool/rtpengine/metadata"
Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000828 sec
Jan 19 19:01:00 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000053 sec
route(SBC_CORE);
maybe any hint or - someone has working exmaple of kamailio config + rtpengine settings ?
i use only userspace daemon rtp forwarding (this is a test, dont need any performance here)
Thanks,
[View Less]
Hi all,
We're hitting an issue while integrating secure websockets in our existing SIP infrastructure using Kamailio.
When the registration comes in, it causes an entry in our AOR table, with ";transport=ws" appended.
When we want to send a message to this client (using t_relay), kamailio seems to take 'ws' as being *unsecure* websockets. In turn, this makes Kamailio try to send out the message using a TCP listener - while it should have picked the TLS listener.
There are some remarks in the …
[View More]sources about ws vs. wss, so i'm struggling to figure out where things go wrong. I've also created github issue #3340 with more details.
Any help would be appreciated. If this turns out to be a Kamailio bug, i'm happy to provide a patch.
[View Less]