Hey everyone,
Whenever I read documentation for htable usage, and other examples of other scripts in Kamailio, htable keys are typically named:
something::something
Examples are: $au::auth_count, $ci::srcip, join::$rU
Why are there two colons (as opposed to a | )? Is this just a standard semantic thing in Kamailio? Is there something about that double character that’s unusual and easy to parse with SIP values? Or is it just what people do, and that’s a good choice to continue for all other Kamailio script writers to have understanding?
Any insight would be appreciated.
Thanks!
~Noah
Hello,
I am trying to make use of crypto module. The scenario is the following:
1. Encrypt plaintext passwords on kamailio side using crypto_aes_encrypt function of crypto module
2. Decrypt them outside of kamailio using 3rd party tools, such as PHP openssl_decrypt
Crypto module parametrs are the following:
modparam("crypto", "salt", "")
modparam("crypto", "key_derivation", 0)
If encryption and decription are handled by kamailio, the initial password matches the decrypted string (initial password -> encrypted string -> decrypted string)
For example:
sql_query("ds_dburl", "select secret from kamailio_sip_buddies where username='$au'", "secret");
$avp(secret_plain) = $dbr(secret=>[0,0]); //value: 'kamailio'
crypto_aes_encrypt("$avp(secret_plain)", "YUZySHVtdlVTYjI0TGJNd3JTeVV0MlRaRWFraFNBRlM=", "$var(encrypted)"); //value: 'qfOqTMoJMgGAherGCqLRRQc4zTlqsEj3MEtcORurFf0='
crypto_aes_decrypt("$avp(secret_plain)", "YUZySHVtdlVTYjI0TGJNd3JTeVV0MlRaRWFraFNBRlM=", "$var(decrypted)"); //value: 'kamailio'
But in case I try to decrypt the value of $var(encrypted) using PHP openssl_decrypt or online tool like https://www.devglan.com/online-tools/aes-encryption-decryption, I am getting the result 'kamailio' prepended by 16 random bytes, like:
6“¤›¿Ð+IÊ\ñžïZkamailio
or
6�����+I\��Zkamailio
I believe this 16 bytes are actually random initialization vector in some encoding.
Possibly kamailio is trimming them from result here:
https://github.com/kamailio/kamailio/blob/master/src/modules/crypto/crypto_…
Moreover, if secret was encrypted using crypto_aes_encrypt and random IV, you can use any IV while decrypting and get 16 different bytes+result
Please advice if someone have used crypto module in similar way and what are the possible ways to acheive results consistency
In latest stable K release, we noticed pkg memory leak (pgk memory usage
increases by each processed call). It turned out that the leak goes
away if acc module cdr_enable is not enabled.
Could be a bug in dialog or acc module. Any debug instructions if the
bug is not obvious?
-- Juha
Hello,
I am using Kemi with Python3. I am getting a TypeError exception when
using the following:
KSR.presence.handle_subscribe()
40(208) INFO: PY3 {SUBSCRIBE}: app_python3 [apy_kemi.c:1839]:
sr_apy_kemi_exec_func(): alert - action KSR.presence.handle_subscribe(...)
took too long [2004761 ms] (file:(null) func:(null) line:733)
40(208) ERROR: PY3 {SUBSCRIBE}: app_python3 [python_support.c:156]:
python_handle_exception(): apy_exec: ksr_request_route((null)): Unhandled
exception in the Python code:
TypeError: expected bytes, str found
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/etc/kamailio/kamailio.py", line 152, in ksr_request_route
if self.ksr_route_presence(msg) == -255:
File "/etc/kamailio/kamailio.py", line 733, in ksr_route_presence
KSR.presence.handle_subscribe()
SystemError: <built-in function handle_subscribe> returned a result with an
error set
Using the following appears to be a good workaround, as it does not exhibit
the issue at all:
KSR.presence.handle_subscribe_uri(KSR.pv.get("$fu"))
Cheers,
Michel Pelletier
Hello all,
I'm trying to figure out one problem on my Kamailio server.
When kamailio receive a reinvite from the infra, I get the error message "477 - Unforunately error on sending to next hop" and the call drop.
I don't understand why this message appears as the first invite is well answered and the call is going well.
Any ideas how to resolve this issue ?
Thanks in advance for your help.
Regards,
Nathan
Dear All,
For a normal call, Kamailio receives 200:OK sip response for the method
invite only once but for some calls, it receives 200:OK too many times
around 6 to 7. And I also do not receive BYE or any other packets for this
kind of call. How can I detect such calls in Kamailio and cancel them? I am
inserting data of the calls in the database when the call occurs and
deleting it when BYE is received but for these calls as I don't receive BYE
so I am unable to delete the record of such calls.
Is there a way to detect such calls? Like How can I count if the number of
200:OK responses is more than one or anything like that?
Regards
Vicky
Dear List,
We’re using Kamailio to load balance MRCP requests to multiple backend groups with a configuration as follows:
# kamailio.cfg
...
...
route[DISPATCH] {
if($ua=="mrcp_backend_1") {
if(!ds_select_dst("1", "4")) {
send_reply("404", "No destination");
exit;
}
}
if($ua=="mrcp_backend_2") {
if(!ds_select_dst("2", "4")) {
send_reply("404", "No destination");
exit;
}
}
xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
...
...
# dispatcher.list
1 sip:mrcp01.server.int:8060;transport=tcp
1 sip:mrcp02.server.int:8060;transport=tcp
2 sip:mrcp03.server.int:8060;transport=tcp
2 sip:mrcp04.server.int:8060;transport=tcp
With this configuration, Kamailio load balances the initial SIP INVITE among the MRCP servers. After the INVITE, the service communicates directly to the MRCP servers via SIP (for hanging up the call), MRCPv2 (for sending speech control messages), and RTP (for sending audio).
We would like to implement a configurable number of retries, so that if a particular backend times out, Kamailio would retry X times to other backend(s). In short, something equivalent to HAProxy’s retries, but for Kamailio. This probably implies having Kamailio always as part of our communication (not just load balancing the initial SIP INVITE).
I haven’t been able to find much information about this, could someone provide some pointers?
Thank you so much
With best wishes,
Unai Rodriguez
Hello All
I have below setup :
SBC -> kamailio -> Media server(remote) -> web-client
Call comes from sbc to kamilio and it relays to Remote server to end user,
In Ringing state if remote server goes down then in kamailio there is any
way to Recover that ringing call like we can generate new invite for other
Remote server which is active state, for relaying call i am using
dispatcher module..
I tried with tm.cancel RPC command but it works only if the remote server
is running , when I crash the remote server at that time tm.cancel is not
generating cancel to remote server.
Please suggest if there is any other way to generate INVITE.
Regards
Devang Dhandhalya
--
* <https://www.ecosmob.com/>
*
*Disclaimer*
In addition to generic
Disclaimer which you have agreed on our website, any views or opinions
presented in this email are solely those of the originator and do not
necessarily represent those of the Company or its sister concerns. Any
liability (in negligence, contract or otherwise) arising from any third
party taking any action, or refraining from taking any action on the basis
of any of the information contained in this email is hereby excluded.
*Confidentiality*
This communication (including any attachment/s) is
intended only for the use of the addressee(s) and contains information that
is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination,
distribution, or copying of this communication is prohibited. Please inform
originator if you have received it in error.
*Caution for viruses,
malware etc.*
This communication, including any attachments, may not be
free of viruses, trojans, similar or new contaminants/malware,
interceptions or interference, and may not be compatible with your systems.
You shall carry out virus/malware scanning on your own before opening any
attachment to this e-mail. The sender of this e-mail and Company including
its sister concerns shall not be liable for any damage that may incur to
you as a result of viruses, incompleteness of this message, a delay in
receipt of this message or any other computer problems.
