sr-users September 2013

sr-users@lists.kamailio.org

89 participants
127 discussions

by Fabian Borot

Hi I am using Kamailio 4.0.1 in front of an asterisk servers farm to handle TLS with our clients and providers. The idea is to have kamailio "talking" SIP/UDP/5060 and TLS/TCP/5061 with the customers and providers and regular SIP/UDP/5060 with our internal asterisk servers. So far at least for the customers it looks like it can work. But I have a problem, when the call is established and the called person hangs up, the BYE from the called person to the calling person is ignored. Only when the calling person hangs up first the call is terminated properly. This is what I have been able to see: 1- Customer starts the TLS handshake/connection. 2- Kamailio authenticate it, then routes the call to the asterisk server using regular SIP/UDP/5060 but I see that it is inserting 2 Record Routes in the INVITE: Record-Route: <sip:192.168.1.58;r2=on;lr=on> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> 3- The Contact on that INVITE to the asterisk also comes like this: Contact: <sip:94167032@172.31.196.21:53325;transport=tls> 4- The ACK sent to the asterisk once it accepts the call (200 OK) also has those 2 Record-Routes: Record-Route: <sip:192.168.1.58;r2=on;lr=on> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> 5- The call is established, once the called person decides to hang up the BYE looks like this: BYE sip:94167032@172.31.196.21:53325;transport=tls SIP/2.0 Via: SIP/2.0/UDP 192.168.1.59:5060;branch=z9hG4bK40fa1c23;rport Route: <sip:192.168.1.58;r2=on;lr=on>,<sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> Max-Forwards: 70 From: <sip:3030500@1.2.3.4>;tag=as37953869 To: "kamailio" <sip:kamailio@1.2.3.4>;tag=788cd7c892df40f3b1967112395e2ca4 Call-ID: f9fe65daf1074219be26cb0c224339f1 CSeq: 102 BYE User-Agent: Asterisk PBX 11.3.0 X-Asterisk-HangupCause: Normal Clearing X-Asterisk-HangupCauseCode: 16 Content-Length: 0 My kamailio TLS config is shown below: enable_tls=yes loadmodule "tls.so" # ----- tls params ----- modparam("tls", "config", "/usr/local/kamailio-4.1//etc/kamailio/tls.cfg") modparam("tls", "private_key", "./privkey.pem") modparam("tls", "certificate", "./kamailio1_cert.pem") modparam("tls", "ca_list", "./calist.pem") modparam("tls", "verify_certificate", 1) modparam("tls", "require_certificate", 1) The TLS client that I am using is called Blink.At this point I don't know whether kamailio is sending the BYE using TLS to the customer and waiting for the 200 OK from the customer or whether kamailio does not like something in the BYE and that is why is ignoring it. I see some encrypted packets from kamailio to the client but I don't know what is inside. Any help would be very appreciated. thank you fabian

10 years, 6 months

Double attempt to record-route

by Juha Heinanen

I tried to call record_route_preset() in branch route in order to add contact specific RR headers when request is forked to more than one contact. What happened was that I got error message: Sep 26 17:03:47 wheezy2 /usr/sbin/sip-proxy[2436]: ERROR: rr [rr_mod.c:256]: Duble attempt to record-route Is it really so that record routing is not a branch specific thing? Is there a way to solve this problem? -- Juha

10 years, 6 months

Call Control for Credit and Rate

by Raj Roy Ghandhi

Hi, I want to implement the call control by 1. Validating the CLI and get the credit from DB 2. Check the Rate for the dialed number 3. set the call timeout for the call duration. ( credit/rate) 4. pass the call to remote PSTN GW Please guide me on this. Regards, Roy.

10 years, 9 months

Error with ACK from SIPML5

by Jayesh Nambiar

Hello All, I have a setup which is SIPML5 -> Kamailio(Websocket) -> Freeswitch. All I am trying to do is initiate a call from SIPML5 and Play a Music file from freeswitch. This works, but the call hangs up after 30 seconds due to ACK timeout from from the SIPML5. What I can see is the SIPML5 from Chrome does send an ACK on websocket, but I see the following error in kamailio syslog: *via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found* *ERROR: <core> [msg_translator.c:1725]: build_req_buf_from_sip_req(): could not create Via header* *ERROR: <core> [forward.c:607]: forward_request(): ERROR: forward_request: building failed* *ERROR: sl [sl_funcs.c:371]: sl_reply_error(): ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)* Can someone help me understand what I am missing here and why kamailio is not able to create a VIA header to forward this request towards freeswitch. I have built a simple config file by following https://gist.github.com/jesusprubio/4066845 as reference. Any help in understanding this is really appreciated. Thanks, --- Jayesh

10 years, 9 months

Asterisk re-INVITE race condition, error 500.

by David K

Hello all, So I have three machines, we don't care about audio for this problem, so everything I mention here is SIP related. Freeswitch <--> Kamailio 3.3.2 <--> Asterisk 1. Asterisk sends an INVITE to Freeswitch through the Kamailio proxy. 2. Kamailio replies 100 Trying and forwards to Freeswitch 3. Freeswitch replies 100 Trying 4. Freeswitch replies 180 Ringing to Kamailio 5. Kamailio routes the answer to Asterisk 6. Freeswitch replies 200 OK to Kamailio 7. Kamailio replies 200 OK to Asterisk 8. Asterisk replies ACK to Kamailio 9. Asterisk sends a re-INVITE to Freeswitch through Kamailio 10. Kamailio routes the re-INVITE to freeswitch 11. Kamailio routes the ACK to freeswitch. 12. Freeswitch replies 500 Server error because it got a re-INVITE before the ACK. So, my problem is that Kamailio seems to process my re-INVITE more quickly than the ACK. So Freeswitch replies an error because it got the re-INVITE before the ACK. So my "solution" is to add a usleep(20); for re-INVITEs on Kamailio, but I think this is a lousy solution. Has anyone here had to deal with problems where Kamailio routes a re-INVITE faster than an ACK causing endpoints to return error messages? Has anyone had to deal with a similar issue? Thanks, David

10 years, 9 months

Implementing the Presence module(Kamailio) to work with websockets (sipML5)

by אורן אברהם

Dear List, I have some strange error when using sipML5 client (over websockets) with Kamailio 4.0 server when sending a SUBSCRIBE request. here is my log print: Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: WARNING: <core> [msg_translator.c:2499]: TCP/TLS connection (id: 0) for WebSocket could not be found (tcp:10.0.0.4:8080) Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: tm [t_msgbuilder.c:1367]: assemble_via: via building failed Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: tm [t_msgbuilder.c:1540]: build_uac_req(): Error while assembling Via Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: tm [uac.c:338]: t_uac: Error while building message Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [notify.c:1591]: in function tmb.t_request_within Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [notify.c:1678]: sending Notify not successful Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [subscribe.c:678]: Could not send notify Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [subscribe.c:713]: occured Apr 18 02:55:21 oren-ubuntu /usr/sbin/kamailio[26476]: ERROR: presence [subscribe.c:994]: in update_subscription Could anyone help here ? I think it is only some configuration problem, but i'm not sure how to solve it.

10 years, 10 months

Kamailio stability/timing problem w.r.t. registrations?

by Sotas Development

Hi, We run Kamailio 3.2.3 (FLAVOUR=ser) on an embedded ARM platform in near- default configuration. In a duration test, we observe that at a certain moment Kamailio seems to start ignoring all (re-)register messages, and eventually expires the existing registrations. We have not been able to reproduce the issue using debug-level logging (-dddd). Info-level logging (-ddd) does reproduce the error, but does not produce any error messages. Configuration: ser-basic.cfg, with the following changes: port=5060 alias=testnet Command line: ser -m 4 -f /etc/ser/ser-basic.cfg -n3 -l udp:eth0 Load: Bursts of 8 (Re-)REGISTER messages that are repeated every 85 seconds. The specified expiration time is 120 seconds. Bursts of 9 (Re-)INVITE messages that are repeated every 45 seconds. Note: With this load it takes roughly 1 hour for the error to occur. Using a more standard 3600 second expiration time Kamailio still stalls, it just takes longer. Does anyone have any idea how to tackle this issue? Kind regards, Michiel Veldkamp

10 years, 11 months

Kamailio- Redirect message 300 with LCR reroute

by Fatima Chahrour~Vanrise Support

Dear List, I'd like to get help regarding my case. I have the following script where many thanks to Daniel has helped me in if (is_method("INVITE")) { if (!load_gws(1, $rU, $fu)) { sl_send_reply("502", "Unable To lOad GatEwAyS"); exit;} if(!next_gw()){ sl_send_reply("503", "Unable To fInD a gateWaY"); exit;} while(next_gw()){ km_append_branch(); } sl_send_reply("302","Moved Temporary"); exit; } The problem am facing is that the call is rerouting from the first gateway to the next gateway successfully when I have two gateways. BUT when I have three gateways, and the first two gateways are off, the call is not rerouted to the third gateway. It keeps hitting the seconds gateway and gives request time out at the end Why is that? Thanks in advance, F Chahrour

10 years, 11 months

kamailioi is not relaying BYE message to UAC

by Arif Hossain

Hi, We have the following network architecture : UAC1------------------------->kamailio-------------------->VoipSwitch----->PSTN---------->Phone1 (Sip Client) Now UAC1 calls Phone1 and everything is ok. If UAC1 hangs up session is terminated cleanly. But if Phone1 hangs up the BYE message which comes to kamailio and goes back to VoipSwitch instead of relayed to UAC1 . So The session becomes a zombie one, And UAC1 unfortunately gets billed for a session which should be terminated. Following is the Call flow as seen from VoipSwitch : | <kamilio IP> | | | | <VoipSwitch IP> | |134.856 | INVITE SDP | |(7890) ------------------> (5060) | |134.858 | 407 Proxy Authentication Required | |(7890) <------------------ (5060) | |134.902 | ACK | | |(7890) ------------------> (5060) | |135.408 | INVITE SDP | |(7890) ------------------> (5060) | |135.414 | 100 Trying| | |(7890) <------------------ (5060) | |140.121 | 183 Session Progress SDP | |(7890) <------------------ (5060) | |140.184 | RTP (g729) | | |(61868) <------------------ (5136) | |141.295 | RTP (g729) | | |(61868) ------------------> (5136) | |153.701 | 200 OK SDP | |(7890) <------------------ (5060) | |153.713 | RTP (g729) | | |(61868) ------------------> (5136) | |154.126 | ACK | | |(7890) ------------------> (5060) | |159.988 | BYE | | |(7890) <------------------ (5060) | |160.031 | BYE | | |(7890) ------------------> (5060) | |160.478 | BYE | | |(7890) ------------------> (5060) | |161.412 | BYE | | |(7890) ------------------> (5060) | |181.952 | BYE | | |(7890) ------------------> (5060) | |185.687 | BYE | | |(7890) ------------------> (5060) | |188.018 | 408 Request Timeout | |(7890) ------------------> (5060) | Sip Traces : kamailio------>VoipSwitch I'm posting only the offending BYE msg instead of full trace , because of the mail will become difficult to read . If more traces needed, i can post it. The following BYE message is sent by VoipSwitch: BYE sip:ipphone@205.164.40.74 SIP/2.0 Route: <sip:108.166.195.189:7890;lr=on;nat=yes> CSeq: 2 BYE Via: SIP/2.0/UDP 205.164.40.74:5060 From: sip:008801673345531@205.164.40.74;tag=100528120745985872655137 Call-ID: IqBknV19AuxW0jk.8BjuE4hyx93Ws9qS To: "123456" <sip:ipphone@205.164.40.74>;tag=Zopl5lj5YiqyaSR5Le3QnfoR-G0NZAGG Content-Length: 0 Kamailio instead of relaying the message, sends a BYE message towards VoipSwitch: BYE sip:ipphone@205.164.40.74 SIP/2.0 Max-Forwards: 10 CSeq: 2 BYE Via: SIP/2.0/UDP 108.166.195.189:7890;branch=z9hG4bK4b2b.5d893e95.0 Via: SIP/2.0/UDP 205.164.40.74:5060;rport=5060 From: sip:008801673345531@205.164.40.74;tag=100528120745985872655137 Call-ID: IqBknV19AuxW0jk.8BjuE4hyx93Ws9qS To: "123456" <sip:ipphone@205.164.40.74>;tag=Zopl5lj5YiqyaSR5Le3QnfoR-G0NZAGG Content-Length: 0 When the first BYE message comes from VoipSwitch , kamailio does the following : May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:751]: _sdp = 0x831bf10 May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:753]: sdp = 0x83043dc May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:755]: session = 0x8304504 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:632]: method: <BYE> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:ipphone@205.164.40.74> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <BYE> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bk19052612230719933454843>; state=16 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:145]: After parse_msg... May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:186]: preparing to run routing scripts... May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=arILprdVR1srJ76HHlt4BEc3XsyaWcZm May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [76]; uri=[sip:ipphone@205.164.40.74] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body ["ipphone" <sip:ipphone@205.164.40.74>] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=1905251223419334290936029 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: siputils [checks.c:76]: totag found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:85]: is_preloaded: No May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==15 && [205.164.40.74] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 7890 matches port 5060 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==15 && [205.164.40.74] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [forward.c:448]: check_self: host != me May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 15==15 && [108.166.195.189] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 7890 matches port 7890 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:792]: Topmost route URI: 'sip:108.166.195.189:7890;lr=on;nat=yes' is me May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:257]: No next Route HF found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:811]: No next URI found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:983]: params are <;lr=on;nat=yes> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: siputils [checks.c:76]: totag found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=2501 , global msg id=2500 , T on entrance=0xffffffff May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=29177, isACK=0 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_hooks.c:374]: DBG: trans=0xb61626a4, callback type 1, id 0 entered May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [msg_translator.c:204]: check_via_address(205.164.40.74, 205.164.40.74, 0) May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_funcs.c:388]: SER: new transaction fwd'ed May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) May 20 02:26:04 VOS20-108 last message repeated 5 times May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up May 20 02:26:22 VOS20-108 /usr/local/sbin/kamailio[16445]: DEBUG: <core> [udp_server.c:486]: udp_rcv_loop: probing packet received from 180.234.62.230 38722 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_reply.c:1134]: ->>>>>>>>> T_code=0, new_code=408 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_reply.c:1636]: DEBUG: relay_reply: branch=0, save=0, relay=0 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: <core> [msg_translator.c:204]: check_via_address(205.164.40.74, 205.164.40.74, 0) May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: <core> [mem/shm_mem.c:105]: WARNING:vqm_resize: resize(0) called May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb61626a4, callback type 128, id 0 entered May 20 02:26:54 VOS20-108 /usr/local/sbin/kamailio[16451]: WARNING: <core> [timer.c:450]: WARNING: our timer runs faster then real-time (300000 ms / 4800 ticks our time .-> 299923 ms / 4798 ticks real time) OT: How do you guys maintain 80 column mails? i do not use a mail client, use gmail mailbox. -- -aft

10 years, 11 months

reload to memory is much slower and has problms after upgrade to 3.3.2 and using mem_join=1

by Uri Shacked

Hi, I am using MTREE and DIALPLAN modules to load lots of info to kamailio. (6 million rows). When kamailio was running with 3.2.1 (no mem_join=1 option), the used size was increasing but the process of loading the data was fast eanough. I upgraded to 3.3.2 and set mem_join=1. Now the loading process take about 10 time longer and sometimes stops kamailio from responding to traffic. Any ideas? Thanks, Uri

10 years, 11 months

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 2013