Hi all,
I am trying to route requests from Kamailio to a private SRV record in AWS Route 53. If I setup the record as an A record and put the 3 destination sip server IPs in the record, Kamailio routes perfectly round-robinning between the 3 servers. However, If I switch my dispatcher.list over to the SRV record, the calls do not route and I get a 404 No Destination in my pcap. When I perform a `dig _sip._udp.pool.sip.servers` from the Kamailio server, it properly returns the hostnames of the 3 sip servers that the SRV record points to.
I'm not sure if something in the Kamailio routing has to be changed to accommodate SRV record routing rather than A record? I have scoured the internet and can't really find much of anything. Would greatly appreciate any guidance.
Thanks,
Jesse
Hello,
How can we avoid these errors ?
Feb 5 11:21:39 proxy1 /usr/sbin/kamailio[29563]: ERROR: tm [t_reply.c:1301]: t_should_relay_response(): status rewrite by UAS: stored: 408, received: 200
Thanks
Hello Kamailions,
Ive beent trying to configure a tls connection between kamailio servers,
but looks like Im missing some knowledge.
The situation:
phone1 <> internet <> kamailio1 <internet> kamailio2<> internet <> phone2
The phones are yealink phones, they are connected using TLS v1.2, phone
1 registers at kamailio1 and phone2 registers at kamailio2.
Both kamailio servers have an letsencrypt certificate.
When the connection between the two kamailio servers is set as sip, a
call from a phone1 to phone2 the singnaling is forwarded and rtp flows.
When I set the connection between the two kamailio servers to tls,
things go wrong.. or better said I go wrong.
The kamailio log on the receiving kamailio(kamailio2) shows that things
go wrong and where, but I just cant figure out how to solve it.
The log shows that the tls connection will be handled by the TLS Default
configuration, the CA certificate is missing, well unknown.
15(7209) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new:
new tcp connection: 116.203.53.212
15(7209) DEBUG: <core> [core/tcp_main.c:999]: tcpconn_new(): on port
44153, type 3
15(7209) DEBUG: <core> [core/tcp_main.c:1309]: tcpconn_add(): hashes:
1805:3331:3809, 3
15(7209) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG:
io_watch_add(0xa77de0, 32, 2, 0x7ff9596d4b10), fd_no=23
15(7209) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG:
io_watch_del (0xa77de0, 32, -1, 0x0) fd_no=24 called
15(7209) DEBUG: <core> [core/tcp_main.c:4196]: handle_tcpconn_ev():
sending to child, events 1
15(7209) DEBUG: <core> [core/tcp_main.c:3878]: send2child(): selected
tcp worker 1 8(7202) for activity on [tls:kamailio2:5061], 0x7ff9596d4b10
8(7202) DEBUG: <core> [core/tcp_read.c:1759]: handle_io(): received
n=8 con=0x7ff9596d4b10, fd=9
8(7202) DEBUG: tls [tls_server.c:199]: tls_complete_init(): completing
tls connection initialization
8(7202) DEBUG: tls [tls_server.c:228]: tls_complete_init(): Using
initial TLS domain TLSs<default> (dom 0x7ff959498600 ctx 0x7ff9594b6430
sn [])
8(7202) DEBUG: tls [tls_domain.c:724]: sr_ssl_ctx_info_callback(): SSL
handshake started
8(7202) DEBUG: <core> [core/tcp_main.c:2460]: tcpconn_do_send():
sending...
8(7202) DEBUG: <core> [core/tcp_main.c:2494]: tcpconn_do_send(): after
real write: c= 0x7ff9596d4b10 n=2637 fd=9
8(7202) DEBUG: <core> [core/tcp_main.c:2495]: tcpconn_do_send(): buf=
8(7202) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG:
io_watch_add(0xac78a0, 9, 2, 0x7ff9596d4b10), fd_no=1
8(7202) ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS
accept:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
8(7202) ERROR: <core> [core/tcp_read.c:1505]: tcp_read_req(): ERROR:
tcp_read_req: error reading - c: 0x7ff9596d4b10 r: 0x7ff9596d4b90 (-1)
8(7202) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG:
io_watch_del (0xac78a0, 9, -1, 0x10) fd_no=2 called
8(7202) DEBUG: <core> [core/tcp_read.c:1683]: release_tcpconn():
releasing con 0x7ff9596d4b10, state -2, fd=9, id=3 (kamailio1]:44153 ->
[kamailio1]:5061)
8(7202) DEBUG: <core> [core/tcp_read.c:1684]: release_tcpconn():
extra_data 0x7ff9596d2ab0
15(7209) DEBUG: <core> [core/tcp_main.c:3308]: handle_tcp_child():
reader response= 7ff9596d4b10, -2 from 1
15(7209) DEBUG: tls [tls_server.c:667]: tls_h_close(): Closing SSL
connection 0x7ff9596d2ab0
I assume I have configured tls.cfg partially correct, as the phones
register and can make tls calls.
What I find strange is this line: 8(7202) DEBUG: <core>
[core/tcp_read.c:1683]: release_tcpconn(): releasing con 0x7ff9596d4b10,
state -2, fd=9, id=3 (kamailio1]:44153 -> [kamailio1]:5061)
Would the "[kamailio1]:5061" be the client configuration?
So, what do I need to configure within the tls.cfg file so when a tls
connection is initiated from the other server it will work.
I have tried adding the other server as server within the tls.cfg, which
does not work as kamailio is not listening on the ip address configured.
When I add the server as a client in the tls.cfg as follows, the
connection is handled by the default TLS configuration.
[server:default]
method = TLSv1.2
verify_certificate = no
require_certificate = no
private_key = /etc/letsencrypt/live/kamailio.kazlow.nl/privkey.pem
certificate = /etc/letsencrypt/live/kamailio.kazlow.nl/fullchain.pem
#ca_list = /etc/kamailio/tls/cacert.pem
#crl = /etc/kamailio/tls/crl.pem
[client:kamailio1:5061]
method = TLSv1.2
verify_certificate = no
require_certificate = yes
certificate = /etc/kamailio/tls/fullchain.pem
ca_list = /etc/kamailio/tls/cacert.pem
# This is the default client domain, settings
# in this domain will be used for all outgoing
# TLS connections that do not match any other
# client domain in this configuration file.
# We require that servers present valid certificate.
#
[client:default]
method = TLSv1.2
verify_certificate = no
require_certificate = no
ca_list = /etc/kamailio/tls/cacert.pem
I have tried forcing the socket on the sending kamailio, but that does
not work.
Any feedback on what I am doing wrong or where I can find information to
extend my knowledge would be appreciated.
Rgds,
Gertjan Wolzak
Assuming there are several proxies that have to be hopped sequentially to deliver the request and the order is determined dynamically (!), how can one achieve that behaviour in Kamailio?
My understanding was that Route header is used for that - it allows to keep R-URI intact but still route the egress message elsewhere. Documentation of the loose_route() from RR module seems to confirm that. But the catch is that loose_route() will not pick up any Route header that I might add in the config via append_hf() due to the delayed lump processing (as explained in https://sourceforge.net/p/openser/bugs/277/#5f42).
Thanks in advance for any help or ideas.
Regards,
Ivan
# How to TRACE and visualize TLS and non-TLS SIP traffic in real time
(thanks to Homer's Lorenzo Mangani for pointing me toward Frida)
apt-get install python-pip
pip install frida
pip install hexdump
wget https://raw.githubusercontent.com/google/ssl_logger/master/ssl_logger.py
#first ssh terminal
# create fifo pipe, then will send the content from fifo pipe to an
sngrep without gui, which will be reading pcap from stdin, and sending
eep packets to the other sngrep (third terminal)
mkfifo /tmp/pipe
cat /tmp/pipe | sngrep -N -q -H udp:127.0.0.1:5077 -I -
#second ssh terminal
# writes as pcap to fifo pipe what freeswitch writes and reads from ssl lib
python ssl_logger_giova.py -pcap /tmp/pipe freeswitch
#third ssh terminal
# sngrep that receives packets from both the Ethernet device, and the
eep packets sent by the other sngrep (eg, the tls packets ssl_logger
grabs from freeswitch's ssl lib)
sngrep -L udp:127.0.0.1:5077
(you may want to edit ssl_logger.py and change 228 to be 101 -
LINKTYPE_IPV4 to be LINKTYPE_RAW )
--
Sincerely,
Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
Hello,
Fosdem 2019 is approaching, so I am writing to see if any of you plans
to go to the event. If there is interest, we can try to organize again a
dinner on Saturday evening, a tradition for our project at the past 10
editions or even more.
Henning Westerholt will give a presentation about Kamailio in the RTC
Devroom, I will be around as well. I know few more developers that plan
to go to the event, so let's see who else from the community wants to
join us. As usual, at Fosdem will be developers from other VoIP
projects, like Asterisk, Janus, CGRates, Homer, Jitsi, ...
At the past editions we typically had two "kamailio" events:
1) an "ad-hoc" developers meeting in the cantina (or other available
room around) to discuss about short term plans for Kamailio -- time and
place being decided as we meet there between us (expected in the
afternoon of Saturday or during Sunday).
2) a dinner at a place nearby, with other VoIP folks joining us
Reply if you plan to go to Fosdem and say if you want to join for a
dinner. Just be aware that you have to pay for your food and drinks at
the dinner, unless we are going to be surprised again by a generous
sponsor that covers partially or completely to dinner.
If you need more details about Fosdem, the website is:
- https://fosdem.org
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
Hi Daniel,
Within a network above tech stack is working fine for VOIP calls.
But when i am trying from outside there is no sign of RTP.
Cmd for rtp -
/sbin/rtpengine -p /var/run/rtpengine.pid
--interface=192.168.1.249\!106.51.78.78 --listen-ng 127.0.0.1:60000 -m
50000 -M 55000 --log-level 6 --log-facility local1
106.51.78.78 - public ip
192.168.1.249 - priv ip (kamailio + RTPEngine)
Kamailio config when call is b/w WebRTC --> WebRTC
rtpengine_manage("trust-address replace-origin replace-session-connection
direction=internal direction=external");
Here is SDP, captured on the client sitting outside.
v=0
o=root 1133801452 1133801452 IN IP4 106.51.78.78
s=Asterisk PBX 16.0.0
c=IN IP4 106.51.78.78
t=0 0
m=audio 50196 UDP/TLS/RTP/SAVPF 0 8 111 9 126
a=maxptime:60
a=ice-ufrag:5e13a1292fc0b7163d49328b7516f763
a=ice-pwd:4fa5e003195492fa165020c81eff9346
a=candidate:Hc0a801ac 1 UDP 2130706431 192.168.1.172 46810 typ host
a=candidate:Hc0a801ac 2 UDP 2130706430 192.168.1.172 46811 typ host
a=connection:new
a=setup:active
a=fingerprint:SHA-256
AA:5A:51:BD:4C:53:65:E4:2B:EC:EB:BF:A9:07:DD:60:E3:46:D8:26:6D:04:C8:21:8B:B9:81:37:3A:EB:55:C0
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 opus/48000/2
a=rtpmap:9 G722/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=sendrecv
a=rtcp:50196
a=rtcp-mux
a=ptime:20
a=candidate:T7Tqd3oKM4NvATH3 1 UDP 2097152255 106.51.78.78 50196 typ host
Looking forward for help from you guys.
Thanks & Regards,
Arish Haque
