sr-users

sr-users@lists.kamailio.org

21 participants
37573 discussions

Kamailio, spiral with TM
by David 09 Jul '10

09 Jul '10

Hey, I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A. This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission. The difference between the first time through and the second time is the port 5061 instead of 5060. How can I tell tm that these are not the same transactions ? Would it be easier to have a seperate instance of Kamailio for 5061 ? Thanks, David

4 7

How to force snd_port?
by Victor Pascual Avila 09 Jul '10

09 Jul '10

Hi Folks, How could I force my sip-router to send from a given port number? Many thanks in advance, -- Victor Pascual Ávila

4 8

Kamailio and NAPTR lookup with TLS
by Matteo Campana 09 Jul '10

09 Jul '10

Hi all, I'm using kamailio 1.5 with TLS module. I need to make ENUM query and get NAPTR record. >From NAPTR lookup, I'd like to relay my SIP Invite with tls protocol. How can I tell Kamailio to use TLS protocol ( instead of udp) after NAPTR lookup ? I've try to set : dns_tls_pref=1 dns_udp_pref=2 dns_tcp_pref=3 in the general section of kamailio.cfg, but I get a parse error. Regards, Daniel

4 4

Fwd: Re: Fwd: Re: Kamailio and NAPTR lookup with TLS
by Matteo Campana 09 Jul '10

09 Jul '10

Hi klaus, Suppose I can't access to NAPTR settings. I need to manage SIP URI, so , If I right understand, the only way to use TLS protocol in kamailio 1.5 is to append ";transport=tls" in R-URI before relay. In other words I need to rewrite R-URI: $ru = $ru + ";transport=tls" ; # and the t_relay t_relay() ; something like that? Regards, Daniel Il 08/07/2010 18.45, Matteo Campana ha scritto: > > > -------- Messaggio originale -------- > Oggetto: Re: [SR-Users] Kamailio and NAPTR lookup with TLS > Data: Thu, 08 Jul 2010 18:44:27 +0200 > Mittente: Klaus Darilion <klaus.mailinglists(a)pernau.at> > A: Daniel-Constantin Mierla <miconda(a)gmail.com> > CC: matteo.campana(a)klarya.it, sr-users(a)lists.sip-router.org > > > > Am 08.07.2010 18:10, schrieb Daniel-Constantin Mierla: > > Hello, > > > > On 7/8/10 5:59 PM, Matteo Campana wrote: > >> > >> Hi all, > >> I'm using kamailio 1.5 with TLS module. > >> I need to make ENUM query and get NAPTR record. > >> > From NAPTR lookup, I'd like to relay my SIP Invite with tls protocol. > >> > >> How can I tell Kamailio to use TLS protocol ( instead of udp) after > >> NAPTR lookup ? > >> > >> I've try to set : > >> > >> dns_tls_pref=1 > >> dns_udp_pref=2 > >> dns_tcp_pref=3 > >> > >> in the general section of kamailio.cfg, but I get a parse error. > >> > > these parameters were introduced in kamailio with version 3.0. > > > > If you need TLS then it is recommended to use 3.0 anyhow, it is a far > > better implementation. That will make the life easier to migrate to > > upcoming 3.1 that will bring asynchronous TLS. > > > > No matter what you have in R-URI, you can force TLS via setting outbound > > proxy address to be a TLS uri: > > > > $du = "sip:__ip_or_host__;transport=tls"; > > t_relay(); > > IIRC we do have NAPTR support in Kamailio 1.5 - don't we? > > Then I think it should work when putting a domain into $du and makeing > sure that there is no transport parameter, no port, and NAPTR TLS record > has highest priority. > > regards > klaus > > > > > The IP or host you can take from R-URI without any problem via PV $rd. > > Other option is to use function from tm - t_relay_to_tls(): > > > > http://kamailio.org/docs/modules/stable/modules/tm.html#t_relay_to_udp > > > > Cheers, > > Daniel > > > >

2 1

Differentiation between ACK INVITE and ACK CANCEL
by inge 08 Jul '10

08 Jul '10

Hello all, I need to work on particular ACK within the configuration of SER 0.9.9. Firstly, I was thinking to make a difference using the CSeq field, but it seems that the CSeq on ACK contains the ACK himself. Probably because ACK is a request and not a response. Would it be possible to proceed in another way? Regards, Adrien .L

4 9

Kamailio integration - Registration issue
by Lucas Alvarez 08 Jul '10

08 Jul '10

Hi, I new with kamailio, I've been able to integrate kamailio 3.02 with asterisk 1.6. The only issue I'm having is if I have to restart asterisk( for some config update) I loose all the sip registration in asterisk, is there any way of fixing this?

9 13

Issue building sip-router (kamailio flavour)
by Santiago Gimeno 08 Jul '10

08 Jul '10

Hi, When I build sip-router (from master) with kamailio flavour using: make config mode=debug FLAVOUR=kamailio; make all; make install I'm getting this error when trying to start kamailio: ERROR: <core> [sr_module.c:396]: ERROR: load_module: could not open module </usr/local/lib/kamailio/modules_k/tmx.so>: /usr/local/lib/kamailio/modules_k/tmx.so: undefined symbol: _tm_table On the other hand, if I use: make FLAVOUR=kamailio cfg; make all; make install kamailio starts correctly. I've tried also: make mode=debug FLAVOUR=kamailio cfg with no luck either. What's the problem? How should I compile kamailio with debugging so it starts correctly? Thank you in advance. Regards, Santi

3 5

Re: [SR-Users] no Contact in REFER generated with dlg_bridge
by Anton Roman 08 Jul '10

08 Jul '10

Hi, regarding the missing Contact header in the REFER message, it can be solved by including some lines in /modules_k/dialog/dlg_ transfer.c. In this file, the Contact of the initial INVITE generated with dlg_bridge command can be easily changed as well. The problem now is only in the processing of the ACK generated by the TM module. When this ACK leaves the Kamailio server the branch value of the topmost Via header is '0'. Below you can find the debug output where the ACK is generated and routed by Kamailio. Any idea about where the error can be? thanks in advance, regards Anton 11(5056) DEBUG: tm [t_msgbuilder.c:791]: building ACK for out-of-dialog INVITE (using RS in RR set). 11(5056) DEBUG: tm [t_msgbuilder.c:967]: ACK RURI: `sip:235@10.1.3.15:5061', NH: `sip:10.1.2.122;lr=on'. 11(5056) DEBUG: tm [t_reply.c:1059]: ->>>>>>>>> T_code=180, new_code=200 11(5056) DEBUG: tm [t_reply.c:1794]: DEBUG: local_reply: branch=0, save=0, winner=0 11(5056) DEBUG: tm [t_reply.c:356]: DEBUG: update_totag_set: new totag 11(5056) DEBUG: tm [t_reply.c:1831]: DEBUG: local transaction completed 11(5056) DEBUG: tm [t_hooks.c:288]: DBG: trans=0x7f9767eb1268, callback type 256, id 0 entered 11(5056) DEBUG: dialog [dlg_transfer.c:207]: completed with status 200 11(5056) DEBUG: <core> [parser/parse_to.c:179]: DEBUG: add_param: tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd 9(5052) DEBUG: <core> [parser/msg_parser.c:612]: SIP Request: 9(5052) DEBUG: <core> [parser/msg_parser.c:614]: method: <ACK> 9(5052) DEBUG: <core> [parser/msg_parser.c:616]: uri: < sip:235@10.1.3.15:5061> 9(5052) DEBUG: <core> [parser/msg_parser.c:618]: version: <SIP/2.0> 9(5052) DEBUG: <core> [parser/parse_via.c:1283]: Found param type 232, <branch> = <z9hG4bKf7bc.00856364.0>; state=16 9(5052) DEBUG: <core> [parser/parse_via.c:2296]: end of header reached, state=5 9(5052) DEBUG: <core> [parser/msg_parser.c:500]: parse_headers: Via found, flags=2 9(5052) DEBUG: <core> [parser/msg_parser.c:502]: parse_headers: this is the first via 9(5052) DEBUG: <core> [receive.c:137]: After parse_msg... 9(5052) DEBUG: <core> [receive.c:177]: preparing to run routing scripts... 9(5052) DEBUG: sl [sl_funcs.c:335]: to late to be a local ACK! 9(5052) DEBUG: <core> [parser/parse_to.c:179]: DEBUG: add_param: tag=94cf927f9c6eed24i1 9(5052) DEBUG: <core> [parser/parse_to.c:808]: end of header reached, state=29 9(5052) DEBUG: <core> [parser/msg_parser.c:174]: DEBUG: get_hdr_field: <To> [43]; uri=[sip:235@10.1.2.122 <sip%3A235(a)10.1.2.122>] 9(5052) DEBUG: <core> [parser/msg_parser.c:176]: DEBUG: to body [ sip:235@10.1.2.122 <sip%3A235(a)10.1.2.122>] 9(5052) DEBUG: <core> [parser/msg_parser.c:154]: get_hdr_field: cseq <CSeq>: <10> <ACK> 9(5052) DEBUG: <core> [parser/msg_parser.c:188]: DEBUG: get_hdr_body : content_length=0 9(5052) DEBUG: <core> [parser/msg_parser.c:90]: found end of header 9(5052) DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! 9(5052) DEBUG: <core> [parser/parse_to.c:179]: DEBUG: add_param: tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd 9(5052) DEBUG: <core> [parser/parse_to.c:808]: end of header reached, state=29 9(5052) DEBUG: sanity [mod_sanity.c:220]: all sanity checks passed 9(5052) ERROR: <script>: kamailio!!!: ACK 9(5052) DEBUG: siputils [checks.c:68]: totag found 9(5052) DEBUG: rr [loose.c:85]: is_preloaded: No 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 9==9 && [10.1.3.15] == [127.0.0.1] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5061 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 9==9 && [10.1.3.15] == [127.0.0.2] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5061 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 9==10 && [10.1.3.15] == [10.1.2.122] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5061 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 9==9 && [10.1.3.15] == [127.0.0.1] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5061 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 9==9 && [10.1.3.15] == [127.0.0.2] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5061 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 9==10 && [10.1.3.15] == [10.1.2.122] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5061 9(5052) DEBUG: <core> [forward.c:356]: check_self: host != me 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 10==9 && [10.1.2.122] == [127.0.0.1] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5060 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 10==9 && [10.1.2.122] == [127.0.0.2] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5060 9(5052) DEBUG: <core> [socket_info.c:485]: grep_sock_info - checking if host==us: 10==10 && [10.1.2.122] == [10.1.2.122] 9(5052) DEBUG: <core> [socket_info.c:488]: grep_sock_info - checking if port 5060 matches port 5060 9(5052) DEBUG: rr [loose.c:781]: Topmost route URI: 'sip:10.1.2.122;lr=on' is me 9(5052) DEBUG: <core> [parser/msg_parser.c:90]: found end of header 9(5052) DEBUG: rr [loose.c:257]: No next Route HF found 9(5052) DEBUG: rr [loose.c:800]: No next URI found 9(5052) DEBUG: rr [rr_cb.c:97]: callback id 0 entered with <lr=on> 9(5052) DEBUG: dialog [dlg_handlers.c:797]: Route param 'did' not found 9(5052) DEBUG: tm [t_lookup.c:1387]: DEBUG: t_newtran: msg id=10 , global msg id=9 , T on entrance=0xffffffffffffffff 9(5052) DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=52095, isACK=1 9(5052) DEBUG: tm [t_lookup.c:720]: DEBUG: t_lookup_request: e2e proxy ACK found 9(5052) DEBUG: tm [t_reply.c:276]: DEBUG: totag for e2e ACK found: 0 9(5052) DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly 9(5052) DEBUG: <core> [msg_translator.c:200]: check_via_address(10.1.2.122, 10.1.2.122, 0) 9(5052) DEBUG: <core> [forward.c:509]: Sending: ACK sip:235@10.1.3.15:5061 SIP/2.0 Max-Forwards: 10 Via: SIP/2.0/UDP 10.1.2.122;branch=0 Via: SIP/2.0/UDP 10.1.2.122;branch=z9hG4bKf7bc.00856364.0 From: sip:click2dial@172.22.5.17 <sip%3Aclick2dial(a)172.22.5.17> ;tag=533cb9e91f4b999cf76861cbb9ed54ed-3bcd Call-ID: 2bef8d5474ff8cd4 To: sip:235@10.1.2.122 <sip%3A235(a)10.1.2.122>;tag=94cf927f9c6eed24i1 CSeq: 10 ACK User-Agent: kamailio (3.0.1 (x86_64/linux)) Content-Length: 0

2 2

LCR, problem with routing (prefix, from_uri, grp_id)
by Maciej Bylica 07 Jul '10

07 Jul '10

Hi ALL, I have a problem to configure LCR module to work properly (kamailio rel. 1.5) The task in my case is to handle: 1) All calls coming with CLD number prefix 482223344 from my MGW (77.77.77.77) towards kamilio and direct them to sip world (88.88.88.88) 2) Calls with CLD starting with 48 coming from SIP world towards kamailio and direct them to my MGWs. Additionaly i need to route it on the basis of CLI number. So MGWs <---> Kamailio <---> SIPProxies (88.88.88.88) In db: +----+-----------+----------------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +----+-----------+----------------+--------+----------+ | 1 | 48 | 48 | 1 | 1 | | 2 | 48 | 49 | 2 | 1 | | 3 | 482223344 | 77.77.77.77 | 3 | 1 | +----+-----------+----------------+--------+----------+ gw, +----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+ | id | gw_name | grp_id | ip_addr | hostname | port | uri_scheme | transport | strip | tag | weight | ping | flags | +----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+ | 1 | CLI48 | 1 | 77.77.77.70 | NULL | 5060 | NULL | NULL | NULL | NULL | 150 | 0 | 0 | | 2 | CLI48backup | 1 | 77.77.77.71 | NULL | 5060 | NULL | NULL | NULL | NULL | 150 | 0 | 0 | | 3 | CLI49 | 2 | 77.77.77.75 | NULL | 5060 | NULL | NULL | NULL | NULL | 15 | 0 | 0 | | 4 | CLI49backup | 2 | 77.77.77.76 | NULL | 5060 | NULL | NULL | NULL | NULL | 15 | 0 | 0 | | 5 | SIPWORLD | 3 | 88.88.88.88 | NULL | 5060 | NULL | NULL | NULL | NULL | 250 | 0 | 0 | +----+--------------+--------+----------------+----------+------+------------+-----------+-------+------+--------+------+-------+ Unfortunately: - call is originated on 77.77.77.77 with CLD 48222334455 number and kamailio forward this call to grp_id=3 SIPWORLD which is okay. The problem is that if the call fail, kamailio will try to use 77.77.77.70 and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to provide a kind of huntstop in grp_id=3. I've been trying with +----+-----------+----------------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +----+-----------+----------------+--------+----------+ | 1 | 48 | 88.88.88.88 | 1 | 1 | | 2 | 48 | 88.88.88.88 | 2 | 1 | | 3 | 482223344 | 77.77.77.77 | 3 | 1 | +----+-----------+----------------+--------+----------+ but in this case i am unable to provide kamailio with CLI number routing. Here is a part of my config file... if (!load_gws()) { sl_send_reply("503", "Unable to load gateways"); exit; } if (!next_gw()) { sl_send_reply("503", "Unable to find a gateway"); exit; } route(1); exit; and failover for route(1)... failure_route[11] { # In case of failure, send it to an alternative route: if (t_check_status("408|404|5[0-9][0-9]")) { if (!next_gw()) { t_reply("503", "Service not available, no more gateways"); exit; } else { t_on_failure("11"); t_relay(); } exit; } } Anybody could help my to get out of that? Thx, Maciej.

3 19

CANCEL before INVITE
by David 07 Jul '10

07 Jul '10

Hey, I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery demanding, the phone goes into a standby mode. When it's in the standby mode, it takes a few seconds to come back on. So I send an INVITE to the phone, statefully using TM, I send out a CANCEL before the phone returns the "180 ringing" message. Somehow the device is answering the CANCEL before the INVITE, so the result is that it responds to the CANCEL with "481 Call Leg/Transaction Does Not Exist.", after that it responds to the INVITE with a "180 Ringing", the phone than rings indefinitely because the CANCEL is not sent out again as the transaction is completed from the 481 SIP message. I had a look at the CANCEL, there is no Route: header or tag on the To, so it looks like it is part of a new dialog ( I believe that's what rfc3261 says. As far as I can tell, my Kamailio is working properly. It is retransmitting the messages at the proper intervals, and it is passing along the messages as it receives them. The trouble is that the device answers the initial CANCEL before it answers any of the retransmitted INVITEs. Is there something that I can do in Kamailio to resolve this issue ? Is there an option that I can set that will cause Kamailio to relay the CANCEL only to devices that have already returned a 100 Trying or 180 Trying ? What information do you need to know about my config? What parts of the SIP trace do you need ? Thanks, David

6 19

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