Hello,
is there an rsync endpoint available or is there a possiblity of setting
this up? Creating a mirror via HTTP is a rather quick and dirty solution
and while the deb-repo can be mirrored using debmirror, the rpm repo is
hard to sync to a non-CentOS-based machine due to missing dependencies
such as yum and reposync in latest Debian-based systems.
Would be great to get some input in regards to this topic.
Cheers
On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote:
> Sure. Attached. Problem appears to be that the topos query can't find
> callid-totag (from the response).
>
> I'll try the same scenario with the mysql backend to see if it behaves
> different.
Config works fine with mysql as topos backend. So the bug is restricted
to topos-redis.
Hi,
Intermittently we are observing the following error when checking if given
header is present in SIP INVITE:
SystemError: returned a result with an error set
The complete stack trace is (some names redacted):
11(28) ERROR: {1 195 INVITE nMHZDN.10nOIDt4ldOwz5cqz0XnMepA9} app_python3
[python_support.c:156]: python_handle_exception(): apy_exec:
modify_headers((null)): Unhandled exception in the Python code:
TypeError: an integer is required (got type NoneType)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/etc/kamailio/kamailio.py", line 25, in modify_headers
self.modify_header("SomeHeader")
File "/etc/kamailio/kamailio.py", line 29, in modify_header
present = KSR.hdr.is_present(header_name)
SystemError: returned a result with an error set
Kamailio version (kamailio -v output):
version: kamailio 5.4.6 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, 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, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, 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 8.3.0
Operation system: Linux kamailio-5c7484c74d-vhhr8 5.4.0-1056-azure
#58~18.04.1-Ubuntu SMP Wed Jul 28 23:14:18 UTC 2021 x86_64 GNU/Linux
Are you able to help me find the root cause of this issue?
Pozdrawiam / Best regards,
Wojtek
--
*For more information on how and why we collect your personal
information, please visit our Privacy Policy
<https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackI…>.*
Hi,
We're currently testing Kamailio 5.5.3 on Debian 11 compiled with RADCLI
and we're experiencing an issue with radius authentication:
Feb 23 08:54:22 redacted /sbin/kamailio[817172]: WARNING: <script>: RADIUS
auth failed for redacted (IP:redacted:5060)
Feb 23 08:54:22 redacted /sbin/kamailio[817173]: radcli: rc_avpair_new:
rc_avpair_new: no attribute 1/1 in dictionary
Feb 23 08:54:22 redacted2 /sbin/kamailio[817173]: ERROR: auth_radius
[sterman.c:204]: add_cisco_vsa(): unable to add Cisco-AVPair attribute
I don't believe this is directly a Kamailio issue but enabling debug
logging hasn't revealed any clues ( The log lines remain the same without
additional info ) This was working previously on 5.5.X on Debian 9
Has anyone experienced this before or have any suggestions on where to
start looking?
Thanks
Hello,
I have a problem with Kamailio 5.4.6 and auth_ephemeral. I have the
following in the Kamailio configuration
loadmodule "auth_ephemeral"
modparam( "auth_ephemeral", "sha_algorithm", 3 )
modparam( "auth_ephemeral", "username_format", 0 )
modparam( "auth_ephemeral", "secret", 1234 )
as per
https://kamailio.org/docs/modules/4.1.x/modules/auth_ephemeral.html#auth_ep…
and registrations fail. In the logs we see:
Jan 2 18:21:10 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER
rhaqgafd7boteg24jp5db0} sanity [sanity.c:777]: check_parse_uris():
looking up From header
Jan 2 18:21:10 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER
rhaqgafd7boteg24jp5db0} sanity [sanity.c:817]: check_parse_uris():
parsing From URI
Jan 2 18:21:10 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER
rhaqgafd7boteg24jp5db0} <core> [core/parser/parse_uri.c:1296]:
parse_uri(): bad port in uri (error at char 5 in state 2) parsed:
<sip:3518929:16411>(17) /<sip:3518929:1641150726@192.168.2.99> (35)
Jan 2 18:21:10 enswitch43 /sbin/kamailio[37501]: WARNING: {1 545
REGISTER rhaqgafd7boteg24jp5db0} sanity [sanity.c:820]:
check_parse_uris(): failed to parse From uri
Apparently Kamailio is confused by the timestamp following the username
separated by the : character. The REGISTER message is below:
REGISTER sip:192.168.2.99 SIP/2.0
Via: SIP/2.0/WSS 192.0.2.202;branch=z9hG4bK5452321
Max-Forwards: 70
To: "3518929" <sip:3518929:1641148397@192.168.2.99>
From: "3518929" <sip:3518929:1641148397@192.168.2.99>;tag=ht76o8b2b6
Call-ID: phkj9mi2n3s3ju7uu3qq2f
CSeq: 274 REGISTER
Contact:
<sip:edh7mmti@192.0.2.202;transport=wss>;reg-id=1;+sip.instance="<urn:uuid:ca5e9372-dfa1-459a-b6ba-4398d23bd896>";expires=300
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: path, gruu, outbound
User-Agent: Raspberry Phone (SipJS - 0.11.6)
Content-Length: 0
and Kamailio parses it as sip:<username>:<port> instead of
sip:<username>:<timestamp>.
Is this a bug that should be reported or is there any setting that I am
missing?
Hi List
We t_on_failure re-route calls to another destination in case one fails
for example announcement servers...
Before sending to the announcement server I do add some extra header to
define which announcement in which language should be played:
append_hf("IMP-annc: $avp(announcecode)\r\n");
append_hf("IMP-mandate: $avp(mandate)\r\n");
append_hf("IMP-language: $avp(callerlang)\r\n");
Also $rU is being set prior to sending the call to the announcement
server.
Now one of our announcement servers became unavailable and t_on_failure
was triggered.
The 2nd announcement servers was receiving the calls without any of the
additional header and with the 'inbound' $ru without the altered $rU
https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_on_failu…
I'm a bit confused by that, as this states the URI is reset to the
value it had on 'relaying'. Is this on 'inbound replaying' or on
'outbound relaying' when route(RELAY) was called to send the call TO
the first annoucement server?
Is there a bit more specific information on that behaviour?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Greetings,
I'm new to Kamailio and working to add Kamailio to an existing Asterisk
solution. I'm attracted to the idea of routing via KEMI jsdt since our
Asterisk ARI is using nodejs. Playing with KEMI jsdt I was trying to use
require() to break up the monolithic routing script. It seems that Kamailio
uses Ducktape 2 without module-node or module-ducktape, requiring all
routing in a single file? I'd appreciate any suggested practices for
managing Kamailio configurations.
Cheers,
Ian
Hi everyone,
in my environment (kamailio - http API for retrieve destinations -
rtpengine) it is used a lot parallel forking, the flow is as follows:
A -> INVITE -> Kamailio -> http API/rtjson / t_relay -> Kamailio -> client
B / C / D (only one accepting the call)
Kamailio loops to itself to have a parallel forking, it involves rtpengine
correctly.
Both audio and video work during call.
The issue comes with one of destinations sending 183 with SDP, the caller
will send then a video preview as early media before call is established.
I noticed that only the first one "asking" for early media is receiving
this video preview (sometimes none of clients requesting it), all others
are ignored by caller.
This is a case of 1-to-many, I searched a lot about this but it seems at
least not working or not supported, could you confirm that there is no
configuration trick possible to make work this early media to many
destinations?
Another issue in above call flow, is that if client B is receiving
correctly this early media video and client C answers the call (200OK)
client C does not see any video, audio working and video is completely
missing from rtp, only a reinvite makes possible to see video. Is this a
client side only issue (so only solution is the reinvite) or there is
something missing on my kamailio configuration?
Thanks
Filippo
Hello,
I use DNS failover feature for routing some calls, and I wonder about its limitations.
I noticed that INVITE and ReINVITE requests are correctly routed based on SRV priority/weight in case of failure, but ACK requests do not use them.
Let’s say I have Kamailio A relaying requests to a pool of Kamailios B1 and B2 in TLS.
DNS records are the below ones.
kamailiob.net. 60 NAPTR 20 100 S SIPS+D2T _sips._tcp.kamailiob.net.
_sips._tcp.kamailiob.net. 60 SRV 1 10 5061 kamailiob-1.net.
_sips._tcp.kamailiob.net. 60 SRV 2 10 5061 kamailiob-2.net.
If B1 is down, I expect requests being relayed to B2 (because of priority 2 in the SRV record).
* For initial INVITEs: R-URI is sip:kamailiob.net
* If B1 is down, the request is retried to B2 => OK
* For in-dialog requests: Route header in incoming request is sip:kamailiob.net so it is set as next destination with loose_route function
* If B1 is down, the request is retried to B2 for ReINVITE => OK
* But once the ACK comes in, with the same Route header (sip:kamailiob.net), Kamailio tries to send it to B1 only (no retries to B2, and even no retransmissions to B1 either).
* When B1 is back UP again a few seconds later, Kamailio does not try to relay the ACK again. The ACK request is attempted to be retransmitted only once to B1. It fails and no more retries after that.
Is it the expected behavior? Or is it something misconfigured on Kamailio A? Or is it a TLS connection issue?
Here is the DNS configuration on Kamailio A (TM module is enabled):
dns_try_naptr=yes
use_dns_failover=yes
use_dns_cache=yes
dns_srv_lb=yes
enable_tls=yes
tcp_max_connections=4096
tls_max_connections=4096
tcp_reuse_port=yes
tcp_connect_timeout=10
tcp_send_timeout=10
tcp_connection_lifetime=3600
I had a look into the DNS tutorial (https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt) without finding any hint about this.
If anyone has already played with SIP DNS failover in Kamailio, your help would be appreciated, thanks!
Julien
Hi all,
I'm switching my kamailio to use Let's Encrypt certificates.
Do I need to force a restart of kamailio when the certificate
is renewed or will this be automatic?
The doc indicates that reload is possible (but not advised)
but it looks to be for a "configuration change" (tls.cfg file change)
and not for certificate change.
Maybe certificates are automatically reloaded?
Regards
Aymeric
--
Antisip - http://www.antisip.com