sr-users April 2015

sr-users@lists.kamailio.org

89 participants
144 discussions

About IMS_Chargin and CDP_AVP improvement
by Yasin CANER 24 Apr '15

24 Apr '15

1 0

Multi party body with content type as application/resource-lists+xml couldnt able to decode
by Surendra Pullaiah 24 Apr '15

24 Apr '15

HI Daniel, Can you please share , why kamailio couldn't able to extract the body, when INVITE comes with multi party body (sdp + resource-lists). Is there any other way to extract the same. Please share your views. Regards Surendra

1 0

Header Concatenation - is this a Bad Idea?
by Nathan Angelacos 23 Apr '15

23 Apr '15

Some udp INVITEs hit our network very close to the 1500 byte limit, and we add 2 Record-Routes before we pass the INVITE to the end user. The packet gets truncated in the SDP; "usually" it still works. In our use case, I can't use gzip or TCP. We are already using textops to convert to short-form headers where possible; we're also stripping unnecessary headers. So the next thing is to use RFC 3261 7.3 and 25.1 to concatenate the multiple Record-Routes into one longer line (same for Via, Contact, etc.): Record-Route: <sip:111.111.111.111;lr=on> Record-Route: <sip:99.99.99.99;lr=on> Record-Route: <sip:88.88.88.88:5060;lr> Record-Route: <sip:77.77.77.77;lr> becomes: Record-Route: <sip:111.111.111.111;lr=on>, <sip:99.99.99.99;lr=on>, <sip:88.88.88.88:5060;lr> <sip:77.77.77.77;lr> That saves about 30 bytes - one can save more if putting all the values on 1 line without the cr\lf between. Doesn't look like there's any kamailio function in textops/x that makes this kind of thing easy; so before I start hacking away at the code... Our downstream uses freeswitch, and is willing to verify it works for him - but from a larger interop view, is this a Bad Idea(tm)? Anyone have any experience with brand-name carrier SBC/Proxies that would choke on a header like that? Thanks!

3 3

topoh ACK Call-ID mismatch
by Daniel Tryba 23 Apr '15

23 Apr '15

Trying to call a T.38 enabled endpoint B from an endpoint A that doesn't. This results in a "488 Not Acceptable" from A. The kamailio (4.0.3) in between with topoh enabled (with mask_callid set to 1. Kamailio ACKs the 488 to A, but the ACK has the wrong (masked) Call-ID, resulting in the ACK to A being ignored, A keeps sending 488 at intervals before just dropping the call. My understanding is the Call-ID in the ACK has to be the same as the Call-ID from the 488. But instead of sending the unmasked Call-ID used in all other messages between A and Kamailio, the ACK contains the masked Call-ID used in all messagea between A and Kamailio. I can't find a bug report relating to this. Is this a known feature or maybe fixed in newer versions? A->Kamailio SIP/2.0 488 Not acceptable here. Via: SIP/2.0/UDP 109.235.32.40;branch=z9hG4bKf91a.c6c88747.0;received=109.235.32.40. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSEAktxGZKWgeKCgeS- RrKEAy057Nl9DEpWpefZD6AhGtwWDJjEqeuEAZgZs5iZA7*. From: <sip:+31880100799@sip.pocos.nl:5060>;tag=as3869fe2a. To: "+31880100705" <sip:+31880100705@sip.pocos.nl>;tag=as1b0b8097. Call-ID: 0b5946b977210450571f767a19cd6fa0(a)99sip.pocos.nl. CSeq: 102 INVITE. Kamailio<-A ACK sip:+31880100705@109.235.32.48 SIP/2.0. Via: SIP/2.0/UDP 109.235.32.40;branch=z9hG4bKf91a.c6c88747.0. Max-Forwards: 16. From: <sip:+31880100799@sip.pocos.nl:5060>;tag=as3869fe2a. To: "+31880100705" <sip:+31880100705@sip.pocos.nl>;tag=as1b0b8097. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. CSeq: 102 ACK. -- Telefoon: 088 0100 700 Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024

3 11

Kamailio World for students
by Daniel-Constantin Mierla 23 Apr '15

23 Apr '15

Hello, given the roots and the tight relation of Kamailio project with the academic environment, we are offering three seats at Kamailio World Conference, May 27029, 2015, in Berlin, to students enrolled in universities or research institutes (both bachelor and PhD programs qualify). Last year we tried it locally with the universities in Berlin and this year we want to extend it, as there might be young people interested to travel a bit and attend the event. If you are a student and want to participate, email me directly (miconda(a)gmail.com) or to registration(a)kamailio.org . Participation to all the content of the event (workshops, conference and social event) is free, but you will have to take care of expenses for traveling and accommodation. Write a short description about your interest in real time communications and what is the university or the research institute you are affiliate to. Also, if you are not a student, but you are in touch with some or have access to students forums/mailing lists, it will be very appreciated if you forward these details. More information about Kamailio World is available on the web site: - http://www.kamailioworld.com 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 0

Re: [SR-Users] SIP messages over UDP with sizes over MTU
by Yufei Tao 23 Apr '15

23 Apr '15

Hi Sharath Thanks for the tip! In fact just last night I've found what got things stuck was nothing to do with Kamailio - it was one of our own little module (plugged into Kamailio) that's got locked up. The first thing I suspected was like what you mentioned that Kamailio got stuck due to fragmentation. I wonder if you've seen this happening with Kamailio? At least in this problem of ours it wasn't Kamailio. Thank you and Daniel for the help on this! Yufei On 22 April 2015 at 22:19, Sharath Kumar <Sharath.Kumar(a)mezocliq.com> wrote: > It is definitely possible due to fragmentation the sip receiver was > stuck in some weird state. If I were you I would do TCP for SIP. It is also > recommended in 3261 to use TCP when sip is that big. > ------------------------------ > *From:* sr-users <sr-users-bounces(a)lists.sip-router.org> on behalf of > Yufei Tao <yufei.tao(a)gmail.com> > *Sent:* Friday, April 3, 2015 7:04 AM > *To:* sr-users(a)lists.sip-router.org > > *Subject:* Re: [SR-Users] SIP messages over UDP with sizes over MTU > > Hi Daniel > > We don't have pike module enabled. > > When the problem occurred on an VIP, we observed these: > * Kamailio stopped responding to any messages that were sent to the VIP, > not just OPTIONS > * The OPTIONS messages are not big. But the other SIP messages, e.g. some > of the INVITE/OK that came from some SBCs can be big > * netstat showed the Recv-Q on that VIP had a lot of bytes accumulated, > while Kamailio was not seeing/reading them > * Kamailio responded fine on its real IP, when I sent OPTIONS pings to it > using sipsak > * After restarting Kamailio it started working. But after 1 week or so > the same problem happened again > > Since this only happened after running for 1 week or so, we didn't have > any traces to show what exactly happened at the particular time when it > happened. It is possible some SIP messages may have come in fragmented and > some are just too big, depending on the route they came from etc. So I was > wonder if it was possible that the UDP receive buffer was filled somehow > with messed-up messages. Is there anyway to check this? Any suggestions > where I should start looking please? Or is it generally a bad idea to use > UDP when there are messages that may be too big, either fragmented or not? > > Since the it is running in the production environment, I'd like to get > some confidence that a Kamailio upgrade will fix the problem first before I > change anything there. > > Cheers, > Yufei > > > > Date: Wed, 01 Apr 2015 16:27:44 +0200 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.sip-router.org > > > Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU > Message-ID: <551C0060.3010002(a)gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hello, > > first, not related to the topic you reported, I would recommend at least > upgrading to latest 4.0.x, there were many fixes from v4.0.0 and there > are no changes to be done to config or database -- simply deploy latest > 4.0.x and restart. > > Back to this topic. Is all the other traffic handled apart of big OPTIONS? > > Do you have pike module enabled? If yes, can you double check and be > sure that the SBC is not blacklisted (traffic from it should not be > handled via pike_check_req()). > > Cheers, > Daniel > > On 01/04/15 15:42, Yufei Tao wrote: > > Hi > > > > We've got Kamailio (v4.0.0) connected to some SBC, which sends SIP > > traffic and periodic OPTIONS pings to Kamailio's VIP. Kamailio > > responds to the OPTIONS pings with OK, i.e. in the main route block: > > if (is_method("OPTIONS")) > > { > > sl_send_reply("200","OK"); > > exit; > > } > > > > All works fine for a week or so, then Kamailio stopped responding to > > the OPTIONS pings on the VIP it listens to. But it still respond to > > OPTIONS pings that are sent to its real IP. The real IP is not used > > for receiving/sending any traffic while only the VIP is. So it seems > > that Kamailio is still working, but maybe having problems with the > > receiving buffer for the VIP? > > > > We do see that some SIP messages sent to Kamailio's VIP are too big > > (sometimes over 1500 bytes). My question is, in this case, what would > > be expected to happen? Is it possible somehow the receiving buffer for > > the VIP got messed up by the big UDP messages? Any one seen similar > > problems? What is the suggested solution? > > > > We're considering moving to TCP. But since this is production > > environment, I want to get some confidence that the problem we saw was > > likely to have been caused by the UDP message being too large. > > > > Cheers, > > Yufei >

1 0

Kamailio v4.3 - development frozen
by Daniel-Constantin Mierla 23 Apr '15

23 Apr '15

Hello, development (master) branch of Kamailio enters now in pre-release phase for version 4.3.0. Therefore, no new feature should be pushed to master until we create a dedicated branch for 4.3 (expected to be in about 4 weeks or so). If in doubt to push or not a commit to master, push it first on a personal branch (or attach to an email) and discuss it on sr-dev. The new modules can be a bit more dynamic if there is need to get them to the right shape (e.g., like decision to rename functions, parameters or adjust database structure). We hope to get many people involved in testing, to rich a stable state before releasing 4.3.0. If you want to get involved and need assistance, don't hesitate to write to mailing lists. Help with updating the wiki page for migration from 4.2 to 4.3 as well as what is new in 4.3 is very appreciated. I will post updates about the very soon. Many thanks to everyone involved in development of 4.3 and the early testers that played with master branch so far. 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 0

Unauthorized register with persistence PostgreSQL
by Gabrielle Eymard 23 Apr '15

23 Apr '15

Hello everyone, I’m currently running Kamailio 4.2.4 with PostrgreSQL 9.3 database, each one on CentOS 6.6 I have installed and configured Kamailio with PostgreSQL without any problem. But now, I don’t want my phones register be recorded on Kamailio (on cache) but immediately on the external database. For that, I follow your advices and configure the kamailio.cfg this way : I added these lines : #!ifdef WITH_PGSQL #!define DBURL "postgres://user:passwd@database.domain:5432/kamailio" #!endif … #!ifdef WITH_PGSQL loadmodule "db_postgres.so" #!endif … And I have all these modules laoded : loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "outbound.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "stun.so" I also set 3 to the usrloc param so my registration are directly on my database : # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) modparam("usrloc", "db_mode", 3) modparam("usrloc", "use_domain", MULTIDOMAIN) #!endif Then, when I restart my Kamailio server, I saw on my postgres database that the connection with this user and passwd is ok but my sip phones didn’t registered. Thanks to Wireshark, I saw that the first REGISTER is send by my sip-phone to Kamailio. The first UNAUTHORIZED response came, as expected, with the WWW-Authenticate information. My phone sent a new REGISTER with the good realm and nonce-value (so I can see with wireshark) but Kamailio still refuse it by another UNAUTHORIZED message (same as the first one). Can you please explain to me where am I wrong ? If it helps, this is what I got on the kamailio logs : Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20466]: NOTICE: <core> [main.c:739]: handle_sigs(): Thank you for flying kamailio!!! Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20475]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20474]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20473]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20472]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20471]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20470]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20469]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20468]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[20467]: INFO: <core> [main.c:850]: sig_usr(): signal 15 received Apr 21 14:27:39 fiducial-vm-centos66-sipr1 kamailio: INFO: <core> [tcp_main.c:4746]: init_tcp(): using epoll_lt as the io watch method (auto detected) Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: usrloc [hslot.c:53]: ul_init_locks(): locks array size 1024 Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: auth [auth_mod.c:350]: mod_init(): auth: qop set, but nonce-count (nc_enabled) support disabled Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 124928 Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22331]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 249856 Apr 21 14:27:39 fiducial-vm-centos66-sipr1 /usr/sbin/kamailio[22339]: INFO: ctl [io_listener.c:225]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Hope someone could help me, Thank you in advance anyway Gab

2 3

Kamailio: MI Command: 'trusted_dump' and 'trusted_reload'
by José Luis Millán 22 Apr '15

22 Apr '15

Hi, I'm using 'allow_trusted()' from Permissions module without a problem in a Kamailio 4.0 routing logic. It does just work, but the MI command 'trusted_dump' tells me that the module is not in use: ''' server:/home/jmillan# kamctl fifo trusted_dump 500 Trusted-module not in use ''' Doing a 'trusted_reload' does neither make any query to database to retrieve the data. Other MI commands of same module do work correctly. ie: 'address_reload' or 'address_dump' Note: I have tested in a Kamailio 1.5 and the result is the same. Regards. -- José Luis Millán

4 3

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

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

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 April 2015