sr-users February 2019

sr-users@lists.kamailio.org

78 participants
98 discussions

Kamailio with RTPengine, allow source port of RTP to change during a call

by Laurent Schweizer

Hello, I'm using the RTPengine with Kamailio and I have a question for a specific case. I have some customer that are changing the source port of the RTP stream during the call ( no re-invite) I think it's more a NAT issue that a user agent issue... I see in the doc that I can handle this case with the "media handover" but in that case the rtpengine will allow a change of the source port but also of the source IP. Any possibility to allow only a change of the source port so source IP must still be the same ? Thanks BR Laurent

5 years, 9 months

Kamailio failure routing to SRV Record

by Jesse Strahn

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

5 years, 9 months

Error UAS

by Nicolas Breuer

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

5 years, 9 months

TLS challenge

by Gertjan Wolzak

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

5 years, 9 months

How to chain proxies with Route header and loose_route()

by Ivan Ribakov

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

5 years, 9 months

TLS traffic visualization HOWTO

by Giovanni Maruzzelli

# 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

5 years, 9 months

Planning Fosdem 2019

by Daniel-Constantin Mierla

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.com www.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

5 years, 9 months

kamailio + asterisk + webrtc

by arish haque

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

5 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users February 2019