Hello ist,
I've noticed some of the latest releases do not have their repo mentioned
in the https://rpm.kamailio.org/centos/kamailio.repo
The repos are there, it is just the kamailio.repo file missing some of the
newer versions like 5.4.7, 4.5.8, 5.5.4, 5.6.0...
Cheers,
Patrick
Hello,
im using DNS Failover and everything works well except i would like to try other resolved ips when i receive a 408 from the previous ones
As far as i know only a received 503 will trigger next destinations and there is no config parameters in tm module to handle that behaviour.
so how can i implement it ?
set a failure route before relay and just call t_relay() after again ?
also is there a way in failure route to know how many destinations are left to exit failure route.
Thanks for help.
Hello,
I am writing some Kamailio scripts using app_python3.
I understand that the KSR module is automatically generated by Kamailio. So when I
import KSR from KSR
I don't get any syntax from my IDE since it doesn't know where KSR is.
My question: is there a way to generate a KSR.py file that can be used for autocompletion and syntax highlighting?
Thanks.
Olivier
Hello is there a way or pseudo var to get ip address & port that the request will be sent to and save it in to another variable.
i want a way to get it to store it.
im not able to save it with to_ip and to_port of the onsend_route.
TThanks.
Sorry if this is a super basic ask but I can't seem to work it out, I have got a work around but for my own sanity wanted to post the question on here.
In Kamailio Native 5.5.2
I want to be able to look into this field $(di{uri.user}) and "find" or see if it "contains" a value
i.e Diversion: "TEST" sip:112233445566@xxx.xxx.xxx.xxx;user=phone;
find 234
or
contains 234
I know how to do this in in KEMI Python but for the life of me cant get my head around it in Native.
2ndly is there an opposite to {s.numeric} Removes all non-numeric parts of string.
I want the ability to strip all numeric parts.
Keep us the good work.
Lewis
Hello all!
My test Kamailio setup (now updated to version 5.5.4) that was working with
MS Teams some time ago, now stopped :)
I was wondering if someone could tell me if the current behavior is correct
or if there is a problem?
Here is a screenshot of the packet capture:
[image: image.png]
I thought that after MS Teams side sent Change Cipher Spec request,
Kamailio should respond with ACK. But instead it just starts sending data
(I believe it sends OPTIONS request. sipdump module captured it). Is this
correct?
There seems to be no issues in the Kamailio debug log:
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/io_wait.h:782]: io_watch_chg(): DBG: io_watch_chg (0xae9560, 24, 0x1,
0xffffffff) fd_no=20 called
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xae9560, 25, -1,
0x0) fd_no=20 called
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/tcp_main.c:4471]: handle_tcpconn_ev(): sending to child, events 1
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/tcp_main.c:4144]: send2child(): selected tcp worker idx:1 proc:11
pid:28972 for activity on [tls:172.16.30.206:5062], 0x7fad6a70f6c8
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:1737]: handle_io(): received n=8 con=0x7fad6a70f6c8, fd=6
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for
SSL_CTX-0x7fad6a5e1eb8: (nil)
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_main.c:2720]: tcpconn_do_send(): sending...
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_main.c:2753]: tcpconn_do_send(): after real write: c=
0x7fad6a70f6c8 n=2279 fd=6
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_main.c:2754]: tcpconn_do_send(): buf=
May 20 15:29:05 server kamailio[28961]: 7
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/io_wait.h:375]: io_watch_add(): processing io_watch_add(0xb555c0, 6,
2, 0x7fad6a70f6c8) - fd_no=1
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for
SSL_CTX-0x7fad6a5e1eb8: (nil)
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_domain.c:790]: sr_ssl_ctx_info_callback(): SSL handshake done
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_domain.c:794]: sr_ssl_ctx_info_callback(): SSL disable renegotiation
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_server.c:542]: tls_connect(): TLS connect successful
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_server.c:549]: tls_connect(): tls_connect: new connection to
52.114.132.46:5061 using TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384 256
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_server.c:552]: tls_connect(): tls_connect: sending socket:
172.16.30.206:0
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_server.c:418]: tls_dump_cert_info(): tls_connect: server certificate
subject:/CN=sip.pstnhub.microsoft.com
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: tls
[tls_server.c:422]: tls_dump_cert_info(): tls_connect: server certificate
issuer:/C=US/O=Microsoft Corporation/CN=Microsoft RSA TLS CA 01
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_main.c:2720]: tcpconn_do_send(): sending...
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_main.c:2753]: tcpconn_do_send(): after real write: c=
0x7fad6a70f6c8 n=509 fd=6
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_main.c:2754]: tcpconn_do_send(): buf=
May 20 15:29:05 server kamailio[28961]: ▒4▒▒▒▒.▒2T$-▒▒ o▒w)▒(▒▒^▒D▒U{xn9▒'
▒&▒t▒▒)▒▒?▒d▒=g▒▒?▒▒▒4/▒▒▒▒-R+▒tR▒H,▒o▒D2r
▒5Q?m▒▒9▒▒#▒O▒▒▒\eϣ▒݄"▒z=▒U▒?
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xae9560, 24, -1,
0x0) fd_no=19 called
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/tcp_main.c:4471]: handle_tcpconn_ev(): sending to child, events 1
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/tcp_main.c:4144]: send2child(): selected tcp worker idx:2 proc:12
pid:28973 for activity on [tls:172.16.30.206:5062], 0x7fad6a6f25a0
May 20 15:29:05 server kamailio[28961]: 12(28973) DEBUG: <core>
[core/tcp_read.c:1737]: handle_io(): received n=8 con=0x7fad6a6f25a0, fd=6
May 20 15:29:05 server kamailio[28961]: 12(28973) DEBUG: tls
[tls_domain.c:1208]: tls_lookup_private_key(): Private key lookup for
SSL_CTX-0x7fad6a5e1eb8: (nil)
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:304]: tcp_read_data(): EOF on connection 0x7fad6a70f6c8
(state: 0, flags: 18) - FD 6, bytes 0, rd-flags 10000 ([52.114.132.46]:5061
-> [52.114.132.46]:0)11(28972) DEBUG: <coreTCP closed event creation
triggered (reason: 0)
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:192]: tcp_emit_closed_event(): no callback registering for
handling TCP closed event
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:1503]: tcp_read_req(): EOF
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0xb555c0, 6, -1,
0x10) fd_no=2 called
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:1878]: handle_io(): removing from list 0x7fad6a70f6c8 id 2
fd 6, state 2, flags 18, main fd 25, refcnt 2 ([52.114.132.46]:5061 ->
[52.114.132.46]:0)
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:1659]: release_tcpconn(): releasing con 0x7fad6a70f6c8,
state -1, fd=6, id=2 ([52.114.132.46]:5061 -> [52.114.132.46]:0)
May 20 15:29:05 server kamailio[28961]: 11(28972) DEBUG: <core>
[core/tcp_read.c:1660]: release_tcpconn(): extra_data 0x7fad6a70f008
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: <core>
[core/tcp_main.c:3574]: handle_tcp_child(): reader response= 7fad6a70f6c8,
-1 from 1
May 20 15:29:05 server kamailio[28961]: 14(28975) DEBUG: tls
[tls_server.c:729]: tls_h_tcpconn_close_f(): Closing SSL connection
0x7fad6a70f008
Thank you!
Hi, am looking for some specific Kamailio help i cant seem to find anywhere
(
#
running Kamailio on Debian/buster ...
##
after receipt of tcp FIN, port is closed.
when signaling is required again from Kamailio side.
Kam is attempting SYN on FINd (closed) port.
this is rejected RST.
How to change SYN to re-establish tcp on new ephemeral port?
##
another description, same problem:
FIN received from (external) cisco (call owner) due to port recycling, not
to keep port open after x minutes. everything is as expected re ACKs and
such.
When Kam wants to send REFER to cisco after the FIN, tcp attempts a SYN (as
we'd expect) but sends SYN on old closed port.
##
Where to change this Kam/OS/other is where i'm attempting to identify, then
figure how to change.
Thank you.
It seems that TOPOS is not working properly on RE-INVITE and stop masking IP and contact on some RE-INVITE.
When a RE-INVITE is send with Kamailio IP as Request-URI TOPOS is not operating.
Note : we are using the HTABLE trick to rewrite $ru and match the call but we would need to have TOPOS re-evaluating the dialog once done.
We use a standard configuration with 2 modifications.
1. in route[DISPATCH] to set the HTABLE
if(is_method("INVITE")) {
$sht(ct=>$ci::$ft) = $sel(contact.uri);
}
1. in route[WITHINDLG] to find the call if R-URI = myself
if(has_totag() && uri==myself) {
if($sht(ct=>$ci::$ft) != $null && $T_reply_code > 400) $shtex(ct=>$ci::$ft) = 10 ;
if($sht(ct=>$ci::$tt) != $null) {
$ru = $sht(ct=>$ci::$tt);
if (is_method("BYE")) $shtex(ct=>$ci::$tt) = 10 ;
route(RELAY);
}
}
As you can see in the PCAP the RE-INVITE goes directly to calling stating with the Contact not updated and the 200 OK is also sent to called party with wrong Contact info too.
[ https://github.com/kamailio/kamailio/files/8730489/topos-issue.zip ]
This behavior breaks the BYE procedure.
Any advice ?
Chris
Hi all,
I'm building an simple PBX with 1 Kamailio as load balancer for several
Asterisk servers.
My issue is if an extension is in-call on Asterisk#1 wants to consult
transfer to another number, it makes another call and Kamailio forward this
new call to another Asterisk and cause call tranfer will fail.
Does anyone here have tips or sugestions to resolve this?
Thanks in advance for your help.
Best regards