- sr-users - kamailio.org

Re: [SR-Users] drouting
by Keith 24 Apr '15

24 Apr '15

Hi, I am using drouting but having issues when trying to route numbers in E164 in the prefix. Any ideas how to allow for a + in the prefix field in the DB? Thanks Keith

2 1

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

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

MOH SIP SERVERS
by Kevin LeClair 19 Apr '15

19 Apr '15

Greetings, I'm new to the VoIP / SIP world but have successfully provisioned my new Yealink T48G and have begun to setup some of the many features. Of course one of the coolest features I found was the Music On Hold (MOH) with a SIP server. I configured the T48G to your sip:music@iptel.org which worked awesomely! My question is: Can I setup a SIP server with you to upload a default mp3 for using with my own MOH complete with SIP server URI? OR are there other services that do this? I have some of my own servers but I'm guessing that many servers do not allow the SIP MOH functionality? Thanks so much for your time. MaineWWW - A Maine Website Design Company Otter Creek, Maine 207-669-4269 <http://www.mainewww.com/> mainewww.com "One Site for All Devices" <http://www.mainewww.com/> maine_www_logo_small2

2 1

uri=myself question
by Andres 18 Apr '15

18 Apr '15

Hi, I have a question about about 'myself' usage. for example: if(uri==myself) { log("the request is for local processing\n"); }; I have always expected the above to hold true for any 'alias' definition in the config file. But I never really though about the domain module since I use the test "is_uri_host_local()" for that. So my question is, if we have an entry in the domain module will it resolve to true for the "(uri==myself)" test even if it's not an alias? Thanks, -- Technical Support http://www.cellroute.net

2 2

Kamailio relays ACK of 200 OK to itself
by Dmitry Sytchev 17 Apr '15

17 Apr '15

Hi all! I can't make my Kamailio to correctly relay stateful ACKs for 200 OK. It takes URI from Route: header and trying relay it to itself instead of sending it to host sent 200 OK. I don't understand why it can't match transaction and relay to correct host. Seems BYEs aren't relayed correctly either... 192.168.4.218 -> NAT 1.2.2.94 -> Kamailo (1.2.3.46, 1.2.2.219) -> 172.19.126.105 192.168.4.218 sends INVITE to 1.2.3.45 which relays it to 172.19.126.105. After 172.19.126.105 answers with 200 OK, it never gets ACK for it back. Instead, ACK relayed by proxy to 1.2.3.46 (one of proxy addresses). Example of original ACK: ACK sip:89211234567@172.19.126.105:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.4.218:5062;branch=z9hG4bK1161188624. Route: <sip:1.2.3.46;lr=on;ftag=259196205;nat=yes>. From: "0099977" <sip:0099977@1.2.3.46>;tag=259196205. To: <sip:89211234567@1.2.3.46>;tag=as6bfd1fa1. Call-ID: 910089142(a)192.168.4.218. CSeq: 2 ACK. Contact: <sip:0099977@192.168.4.218:5062>. Max-Forwards: 70. User-Agent: Yealink SIP-T46G 28.71.14.4. Content-Length: 0. It sees that host is not local: check_self: host != me I think the problem is somewhere in my NAT handling script code, but seems I'm stuck and can't get what am I doing wrong, so I'll greatly appreciate any help. Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <2> <ACK> Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: INFO: <script>: Nat detected Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [sipops.c:161]: w_is_first_hop(): no 2nd via found - first hop Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: INFO: <script>: Set contact alias Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [dset.c:774]: uri_add_rcv_alias(): encoded <sip:0099977@192.168.4.218:5062> => [sip:0099977@192.168.4.218:5062;alias =1.2.2.94~58542~1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [checks.c:106]: has_totag(): totag found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: INFO: <script>: Request in dialog Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: rr [loose.c:90]: is_preloaded(): is_preloaded: No Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==9 && [172.19.126.105] == [127.0.0. 1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==12 && [172.19.126.105] == [1.2. 2.219] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==11 && [172.19.126.105] == [1.2. 3.46] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==9 && [172.19.126.105] == [127.0.0. 1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==12 && [172.19.126.105] == [1.2. 2.219] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 14==11 && [172.19.126.105] == [1.2. 3.46] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [forward.c:448]: check_self(): check_self: host != me Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: rr [loose.c:674]: after_strict(): Next hop: 'sip:1.2.3.46;lr=on;ftag=259196205;nat=yes' is loose router Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: rr [loose.c:724]: after_strict(): The last route URI: 'sip:1.2.3.46;lr=on;ftag=259196205;nat=yes' Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: outbound [ob_mod.c:496]: use_outbound(): Analysing ACK for outbound markers Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 11==9 && [1.2.3.46] == [127.0.0.1] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 11==12 && [1.2.3.46] == [1.2.2.2 19] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 11==11 && [1.2.3.46] == [1.2.3.4 6] Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: outbound [ob_mod.c:466]: use_outbound_non_reg(): outbound not used Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [checks.c:106]: has_totag(): totag found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: siputils [checks.c:106]: has_totag(): totag found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: NOTICE: <script>: REL: ACK sip:1.2.3.46;lr=on;ftag=259196205;nat=yes -> sip:1.2.3.46;lr=on;ftag=259196205;nat=yes Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=59 , global msg id=58 , T on entrance=0xffffffff Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=37956, isACK=1 Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: tm [t_funcs.c:312]: t_relay_to(): SER: forwarding ACK statelessly Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: 2132d578ec20fa9b478ada51e9f2965f Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [forward.c:211]: get_out_socket(): DEBUG: get_out_socket: socket determined: 0xf6e777ec Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [msg_translator.c:206]: check_via_address(): check_via_address(1.2.2.94, 192.168.4.218, 0) Apr 16 19:21:33 kam-sbc-1-01 /usr/sbin/kamailio[9178]: DEBUG: <core> [forward.c:592]: forward_request(): Sending:#012ACK sip:1.2.3.46;lr=on;ftag=259196205;nat=yes SIP/2.0#015#012Record-Route: <sip:1.2.3.46;lr=on;ftag=259196205>#015#012Via: SIP/2.0/UDP 1.2.3.46;branch=z9hG4bK4449.2132d578ec20fa9b478ada51e9f2965f.0#015#012Via: SIP/2.0/UDP 192.168.4.218:5062;rport=58542;received=1.2.2.94;branch=z9hG4bK1161188624#015#012From: "0099977" <sip:0099977@1.2.3.46>;tag=259196205#015#012To: <sip:89215572714@1.2.3.46>;tag=as6bfd1fa1#015#012Call-ID: 910089142(a)192.168.4.218#015#012CSeq: 2 ACK#015#012Contact: <sip:0099977@192.168.4.218:5062;alias=1.2.2.94~58542~1>#015#012Max-Forwards: 69#015#012User-Agent: Yealink SIP-T46G 28.71.14.4#015#012Content-Length: 0#015#012#015#012. -- Best regards, Dmitry Sytchev, IT Engineer

2 4

Loadbalancing proxy using DNS SRV instead of dispatcher
by Daniel Tryba 17 Apr '15

17 Apr '15

The idea is to use SRV records instead of a dispatcher by setting $rd to a DNS SRV enabled host (with all hosts having the same prio and weight). Problem is that when authentication is required the flow is as follows (with 2 hosts): 1: UAC INVITE/REGISTER -> LB -> SIP0 SIP0 401 with nonce1 challenge -> LB -> UAC UAC ACK -> LB -> SIP0 2: UAC INVITE/REGISTER with nonce1 response -> LB -> SIP1 SIP1 401 with nonce2 challenge -> LB -> UAC UACK ACK -> LB -> SIP1 3: UAC INVITE/REGISTER with nonce2 response -> LB -> SIP0 SIP0 401 with nonce1 challenge -> LB -> UAC UACK ACK -> LB -> SIP0 4: UAC either gives up or goes to 2 Using the dispatcher module this can be solved by using a hash over either from/to/request URI. I can't find any hints for forcing the dialog to 1 backend. BTW the idea is to keep the loadbalancing proxy as simple/stupid as possible (no db), the backends have a shared db.

4 7

memcached module trimming the leading 8 char with innodb module
by Ethan Brooks 16 Apr '15

16 Apr '15

This is very simple Kamailio config and when i access Memcached directly everything seem to be fine but, when accessed via Kamailio he leading 8 char is omitted. I have included everything needed to test. kamailio mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" debug=0 fork=yes loadmodule "tm.so" loadmodule "sl.so" loadmodule "pv.so" loadmodule "xhttp.so" loadmodule "memcached.so" modparam("memcached", "servers", "localhost:11211") port=80 tcp_accept_no_cl=yes event_route[xhttp:request] { $var(number) = $hu; $var(number) = $(var(number){s.substr,2,0}); xhttp_reply("200", "OK", "text/html", "value: $mct(@@lnp.$var(number))"); } mysql: source /usr/share/mysql/innodb_memcached_config.sql install plugin daemon_memcached soname "libmemcached.so"; CREATE SCHEMA lnp; CREATE TABLE `lnp`.`lnp` ( `number` bigint(20) NOT NULL, `ported` bigint(20) DEFAULT NULL, PRIMARY KEY (`number`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; insert into lnp.lnp (number,ported) values (8055551212,8053214321); insert into innodb_memcache.containers (name,db_schema,db_table,key_columns,value_columns,flags,cas_column, expire_time_column,unique_idx_name_on_key) values ('lnp','lnp','lnp','number','ported', 0,0,0,'PRIMARY'); url: http://localhost/?8055551212 reponse: value: 21 memcached # nc localhost 11211 get @@lnp.8055551212 VALUE @@lnp.8055551212 0 10 8053214321 END

2 1

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