sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

rtpengine and security
by GG GG 22 Apr '15

22 Apr '15

By port closed, I mean that ports are normally closed, but when rtpengine send the first rtp packets to the client, it opens a pinhole in the firewall, and the matching incoming packets from the client will make the connection established,related in iptables. I think symmetric nat permits that. But now I'm thinking that it's impossible for rtpengine to know the client's destination port at the learning phase if the client's rtp packets can't reach rtpengine. Rtpengine can learn the IP Address from kamailio through the --sip-source CLI switch, but can't guess the port, right ? So, playing with established,related is not possible. > If the attacker is fast enough, yes. You can disable learning of > endpoint addresses using the asynchronous flag, but obviously this will > break NAT'd media. You can also use the strict-source flag to make > rtpengine drop packets received from a mismatched source address. So if I don't use strict-source flag, an attacker could merge any garbage of data in an existing RTP stream ? Thanks.

3 2

Roadmap for next major release v4.3.0
by Daniel-Constantin Mierla 22 Apr '15

22 Apr '15

Hello, it is time to nail down the roadmap to the next major release. We discussed during the last IRC devel meeting, proposing to get it out by beginning of June. Given we need to have at least one month of testing, I propose the next milestones: - freezing the development: Wednesday, April 22, 2015 - if testing goes smooth, then branching 4.3 after about one month: During the week starting May 18 - test more in beta phase, prepare packaging, etc. and release after 2-3 weeks: One of the days between June 4 and 11 Other suggestions or adjustments are welcome! Send them to mailing list to discuss further. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

1 3

Possible bug in TM module
by Mickael Marrache 22 Apr '15

22 Apr '15

Hi, I just got the following issue when stopping kamailio. kamailio[7279]: NOTICE: <core> [main.c:682]: handle_sigs(): Thank you for flying kamailio!!! kamailio[7279]: ERROR: ctl [ctl.c:369]: mod_destroy(): ERROR: ctl: could not delete unix socket /tmp/kamailio_ctl: Operation not permitted (1) kamailio[7279]: : <core> [mem/f_malloc.c:586]: fm_free(): BUG: fm_free: bad pointer 0x4f2dec6200000000 (out of memory block!), called from tm: h_table.c: free_cell(138) - aborting I always get the first ERROR when I stop kamailio, I need to look at the permissions. However, the next one is a bug. Thanks, Mickael

2 2

Iterative DNS resolution by enum module ?
by jyaim 22 Apr '15

22 Apr '15

Hello everyone, Do you know if the kamailio enum module is able to process 'recursives' dns requests in case of CNAME or NS response, until a NAPTR answer is returned ? Thanks in advance! Jy

2 1

Problems with git.kamailio.org server?
by kai.ohnacker＠cbc.de 22 Apr '15

22 Apr '15

Hello, is there actually a problem with the git.kamailio.org server? If I try the command git clone --depth 1 git://git.kamailio.org/kamailio kamailio or git clone --depth 1 git://git.sip-router.org/kamailio kamailio I got the message "fatal: read error: connection reset by peer". Perhaps it is a problem of my setup? Best regards, Kai Ohnacker

2 3

siptrace for keep alive OPTIONS
by Koray Vatansever 22 Apr '15

22 Apr '15

Hi, It seems that siptrace module doesn't trace requests which are sent out by dialog module (i.e. keep-alive OPTIONS and dialog timeout BYE). Is there any easy way to do that? any suggestion?

1 0

rtpengine and security
by GG GG 21 Apr '15

21 Apr '15

Hello, what do you think about opening all RTP ports for rtpengine on Internet, is it a bad practice ? I wonder if it's possible to use rtpengine with all ports closed. Maybe someone could explain how rtpengine learn the source address when the SDP contains a local address. If your rtpengine server is under attack, could rtpengine choose the wrong ip source for RTP ? Thanks.

2 1

UAC Module
by Ali Jibran 21 Apr '15

21 Apr '15

Hi all. I am using UAC module to establish two trunks to my provider. I can see that the trunks are registered successfully but the calls are coming only from the first one. The provider says server isn't responding on the second one. How is that possible when it says registered? Can somebody help me out here.

2 1

ACK and BYE routing - wrong interface problem and TCP/UDP conversion troubles
by Dmitry Sytchev 21 Apr '15

21 Apr '15

Hi all! I'm still working on incorrect routing of ACKs/BYEs with certain conditions and asking for guru help. My network looks like this: 192.168.4.218 -> TCP -> NAT (1.2.2.94) -> (1.2.0.160) Kamailio (1.2.0.160) -> UDP-> backend servers (1.2.2.44). IP address 1.2.0.16 is a 1.2.0.160/32 on loopback interface lo, and it is announced via BGP to neighbours. There is also 1.2.3.46/30, which is used to maintain BGP session. Backends are Asterisk 11 machines with "outboundproxy" sip peer setting set to Kamailio address. Kamailio forwards registrations to Asterisk servers with authentication and caches successful attempts to its internal DB. Natted clients are managed adding 'received' param to reg contact. When backend calls client, Kamailio takes correct URI from 'received' and forwards request. There is a possibility Kamailio will have several IP addresses for outbound clients. To specify source address of forwarded packets I set $fs. For initial requests and responses all works fine, but there are troubles when dealing with ACKs and BYEs. In case I don't specify interfaces with 'listen' , Kamailio listens on 1.2.0.160 and 1.2.3.46. I use $fs to set 1.2.0.160 as outgoing interface, and it works for requests. But when Kamailio forwards ACKs and BYEs, it uses 3.46 instead of 1.2.0.160, especially in case of TCP client and UDP backend. If I set mhomed = 0 and specify Kamailio to listen only to 1.2.0.160, everything works fine, except UDP <-> TCP signalling conversion. When natted TCP client receives call from backend, it answers with 200 OK and ACK from backend is never back to client. At the same time UDP<->UDP works fine. I've noted that TCP and UDP ACKs differ in Record-route headers, in case of TCP there are two records of Kamailio UDP/TCP. I have enable_double_rr = 1. UDP ACK: ACK sip:0097242@192.168.4.218:5063 SIP/2.0. Via: SIP/2.0/UDP 1.2.2.44:5060;branch=z9hG4bK31d1a26c;rport. Route: <sip:1.2.0.160;lr=on;ftag=as7af34000>. Max-Forwards: 70. From: <sip:8121230000@1.2.2.44>;tag=as7af34000. To: <sip:0097242@192.168.4.218:5063;received=sip:1.2.2.94:64825>;tag=3122411720. Contact: <sip:8121230000@1.2.2.44:5060>. Call-ID: 56c5362d2250df6777e6665523964729@1.2.2.44:5060. CSeq: 102 ACK. User-Agent: Zero vPBX. Content-Length: 0. This ack forwarded to destination correctly (to external IP 1.2.2.94:64825). Actually, I don't understand why, because $du is null and no functions logged that rURI was modified... TCP ACK: ACK sip:0097242@192.168.4.218:5062;transport=TCP SIP/2.0 Via: SIP/2.0/UDP 1.2.2.44:5060;branch=z9hG4bK08f7b9f2;rport Route: <sip:1.2.0.160;r2=on;lr=on;ftag=as5cc06d60>,<sip:1.2.0.160;transport=tcp;r2=on;lr=on;ftag=as5cc06d60> Max-Forwards: 70 From: <sip:8121230000@1.2.2.44>;tag=as5cc06d60 To: <sip:0097242@192.168.4.218:5062;transport=TCP;received=sip:1.2.2.94:57735;transport=TCP>;tag=4089422268 Contact: <sip:8121230000@1.2.2.44:5060> Call-ID: 3a72968b552bdb8875e3215431f1522d@1.2.2.44:5060 CSeq: 102 ACK User-Agent: Zero vPBX Content-Length: 0 This ack doesn't get forwarded anywhere, although Kamailio says: DEBUG: <core> [forward.c:592]: forward_request(): Sending:#012ACK sip:0097242@192.168.4.218:5062;transport=TCP SIP/2.0#015#012Via: SIP/2.0/TCP 1.2.0.160;branch=z9hG4bK42a6.5e57399c6a2c1dae96f28c7381b6c64e.0#015#012Via: SIP/2.0/UDP 1.2.2.44:5060;received=1.2.2.44;branch=z9hG4bK26130626;rport=5060#015#012Max-Forwards: 69#015#012From: <sip:8121230000@1.2.2.44>;tag=as74c521ed#015#012To: <sip:0097242@192.168.4.218:5062;transport=TCP;received=sip:1.2.2.94:65535;transport=TCP>;tag=547751151#015#012Contact: <sip:8121230000@1.2.2.44:5060>#015#012Call-ID: 10dfa7d00a9848c411a28bb54edf0f14@1.2.2.44:5060#015#012CSeq: 102 ACK#015#012User-Agent: Zero vPBX#015#012Content-Length: 0#015#012#015#012. So I'm trying to understand - how Kamailio get correct destination address to send to in case of UDP <-> UDP ack, and why the same doesn't work in case of TCP? If I turn on mhomed = 1, it breaks forwarding of UDP ACKs too... Maybe it is because of 1.2.0.160/32 IP address it is placed on lo iface, or there should be some entries in IP routing table on Kamailio host allowing selection of 1.2.0.160? Thanks in advance! -- Best regards, Dmitry Sytchev, IT Engineer

1 0

Re: [SR-Users] registrar: add optional check for local path during lookup()
by Charles Chance 21 Apr '15

21 Apr '15

Hi Volkan, It is in the master (development) branch, so will appear in the next major release (4.3). The code could not be backported to 4.2 because it was considered a new feature rather than a fix. Cheers, Charles P.S. please use mailing list in case the question is useful to others :-) On 21 April 2015 at 12:57, Volkan Hatem <volkan(a)hatem.net> wrote: > Hi Charles, > > I was hoping to see your change ( > http://git.kamailio.org/gitlist/index.php/kamailio/commits/635f23b12eff2431…) > in 4.2.4 > > I could not tell to which branch your code was submitted. Do you know when > it might find its way to an official release? > > Best, > -volkan > -- www.sipcentric.com Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.

1 0

Jump to page:

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