sr-users October 2015

sr-users@lists.kamailio.org

77 participants
126 discussions

evapi tcp parsing??
by Jayesh Nambiar 13 Oct '15

13 Oct '15

Hello, I'm exploring the evapi module for my kamailio to interface with an external node.js app for third party stuff like AAA, billing engine tasks, notifications and so on. I followed and took some ideas from the rtjson and evapi tutorial found here( http://kb.asipto.com/kamailio:k43-async-sip-routing-nodejs) to build the node.js app consuming events. When I stress tested the scenario using SIPp and tried sending a lot of events at 300-350cps from Kamailio, I noticed that at times the client is receiving 2-3 events in a single message together although I do event_sync_relay once per SIP message received and have netstrings enabled. I believe this is a typical behavior of TCP and needs to be handled by the client using some kind of Netstring handler. Please correct me if I'm wrong. And hence I'd like to know what particularly needs to be taken care of while writing a client that is listening for events on raw tcp socket and how does kamailio handle this situation while receiving messages over TCP socket?? Does kamailio recognize the end of netstring properly on evapi:message-received and give exactly one message to take care of on every "message-received" event or should that be handled in the script somewhere !! I also referred cgrates client over evapi example which is written in GO, but I couldnt find them handling TCP streams clearly either. I'd really appreciate some expert suggestion here to make an informed decision on using the evapi module for a large scale solution. Thanks, - Jayesh

3 26

How to get runtime configuration?
by Magnus Nordström 13 Oct '15

13 Oct '15

Hi, Is there any command to get the runtime configuration from kamailio? I tried "kamctl monitor" but there was not a lot of information. For example I need information about what tcp_conn_wq_max is set to. Best regards, Magnus Nordström

3 2

Re: [SR-Users] Lost 180 Ringing Response
by John Billings 13 Oct '15

13 Oct '15

> Hello, > > look at: > > http://kamailio.org/docs/modules/stable/modules/tm.html#tm.p.cancel_b_method > > Maybe one or another value for that parameter is suiting better your use > case. Thank you for the suggestion. This looked promising, but the cancel_b_method parameter is already at the default value of one. I also tried changing the value to two and got a similar result. This may sound crazy, but it almost seems like the problem happens only when kamailio is processing unrelated INVITES at the same time.

2 1

Re: [SR-Users] MySQL Connect Errors
by John Billings 13 Oct '15

13 Oct '15

2 1

Persistence of enable/disable for uacreg
by DanB 13 Oct '15

13 Oct '15

Hey Guys, I was wondering how does enable/disable flag for uac registration gets persistence, since I could not spot it in the mysql tables. Is that just temporary in-memory and on next restart/refresh does not longer take effect? Thanks, DanB

2 2

rfc: event route when kamailio starts
by Daniel-Constantin Mierla 12 Oct '15

12 Oct '15

Hello, based on a recent discussion with Alex Balashov (at Kazoocon this week), I pushed a patch that enables the execution of event_route[core:worker-one-init] when kamailio is started. It would be more like an alternative for event_route[htable:mod-init], for the cases when htable is not used, but also should ensure that all the modules are initialized. Moreover, because most of the modules close connection in mod init, I though of doing it when child one (udp receiver) initialization for all modules is finished, which means that all is ready for runtime, still this is before receiving any packet. On the other hand, forking is done by main process, so other children can start listening for sip. More or less what I want to ask here is whether the forking of the other children should wait until the event_route[core:worker-one-init] is finished (e.g., what is done in this event route is important before any sip packet is routed) or just leave it like it is. Worth to say that some modules do special processing in child init of worker one, like usrloc module loads the records from database to memory, which means that overall start of kamailio could be slower. Also, if there are time consuming actions in the event_route[core:worker-one-init], getting to the stage of routing sip packets will take longer. What would you find important, fork the other processes so routing sip will happen as soon as possible, or block until execution ofevent_route[core:worker-one-init] is finished. I guess that making it cusomizable in some way would be a solution, but knowing what use cases would be important may help in reducing the complexity to get it enabled. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com

3 2

Dialog keep alive options are with error parsing headers
by José Seabra 12 Oct '15

12 Oct '15

Hello there, I'm using dialog module to send keep alive options to callee and caller in order to detect if dialog still up, but when kamailio generates the OPTION and parse it, gives the following errors: [root@c4-compute02-srv1 kamailio]# 37(1587) DEBUG: dialog [dlg_hash.c:614]: dlg_lookup(): ref dlg 0x7f89134c1d40 with 1 -> 3 37(1587) DEBUG: dialog [dlg_hash.c:616]: dlg_lookup(): dialog id=2210 found on entry 2350 37(1587) DEBUG: dialog [dlg_req_within.c:427]: dlg_send_ka(): sending OPTIONS to caller 37(1587) DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=< sip:unknown@62.28.197.25:5060> 37(1587) DEBUG: <core> [dns_cache.c:3293]: dns_srv_sip_resolve(): (62.28.197.25, 0, 0), ip, ret=0 37(1587) DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 14692 37(1587) DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request: 37(1587) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS> 37(1587) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: < sip:unknown@62.28.197.25:5060> 37(1587) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0> 37(1587) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK4693.2af96e95000000000000000000000000.0>; state=16 37(1587) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 37(1587) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 37(1587) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 37(1587) DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=90d40279ee5745d8851aa989e6fadfc2 37(1587) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 37(1587) DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [64]; uri=[sip:unknown@62.28.197.6] 37(1587) DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:unknown@62.28.197.6>] 37(1587) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <0> <OPTIONS> 37(1587) DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 *37(1587) ERROR: <core> [parser/msg_parser.c:96]: get_hdr_field(): ERROR: get_hdr_field: bad header* 37(1587) DEBUG: <core> [parser/msg_parser.c:280]: get_hdr_field(): get_hdr_field: error exit *37(1587) INFO: <core> [parser/msg_parser.c:338]: parse_headers(): ERROR: bad header field [VC* *]* 37(1587) DEBUG: topoh [topoh_mod.c:232]: th_prepare_msg(): parsing headers failed37(1587) DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request: 37(1587) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS> 37(1587) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: < sip:unknown@62.28.197.25:5060> 37(1587) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0> 37(1587) DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK4693.2af96e95000000000000000000000000.0>; state=16 37(1587) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 37(1587) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 37(1587) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 37(1587) DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=90d40279ee5745d8851aa989e6fadfc2 37(1587) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 37(1587) DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [64]; uri=[sip:unknown@62.28.197.6] 37(1587) DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:unknown@62.28.197.6>] 37(1587) DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <0> <OPTIONS> 37(1587) DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=e34d43e164ad4b7392dc9c6e1058a983 37(1587) DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29 37(1587) DEBUG: dialog [dlg_cseq.c:215]: dlg_cseq_msg_sent(): traking cseq updates 37(1587) DEBUG: dialog [dlg_hash.c:671]: internal_get_dlg(): ref dlg 0x7f89134c1d40 with 1 -> 4 37(1587) DEBUG: dialog [dlg_hash.c:674]: internal_get_dlg(): dialog callid='13208317017c42128fbf00e1685ee1b3' found on entry 2350, dir=2 37(1587) DEBUG: dialog [dlg_cseq.c:233]: dlg_cseq_msg_sent(): request not going downstream (2) 37(1587) DEBUG: dialog [dlg_hash.c:846]: dlg_unref(): unref dlg 0x7f89134c1d40 with 1 -> 3 37(1587) DEBUG: dialog [dlg_req_within.c:452]: dlg_send_ka(): keep-alive sent to caller 37(1587) DEBUG: dialog [dlg_req_within.c:427]: dlg_send_ka(): sending OPTIONS to callee I'm using the following dialog configuration: modparam("dialog","db_url", DBURL) modparam("dialog","db_mode", 0) modparam("dialog","enable_stats", 1) modparam("dialog","dlg_flag", DLG_FLAG) modparam("dialog","profiles_with_value","concurrentcalls") modparam("dialog", "detect_spirals", 1) modparam("dialog","dlg_match_mode", 2) modparam("dialog", "initial_cbs_inscript", 0) modparam("dialog", "default_timeout", 3600) modparam("dialog", "send_bye", 1) modparam("dialog", "timeout_avp", "$avp(s:timeout_dlg)") modparam("dialog", "track_cseq_updates", 1) modparam("dialog", "ka_timer", 10) modparam("dialog", "ka_interval", 30) I'm also using topoh module. Anyone can help me to identify if I'm doing the proper configuration? Thank you for your support Best Regards José Seabra

3 9

Startup Route in Kamailio
by Sunil More 12 Oct '15

12 Oct '15

Hi All, I am new to Kamailio world. I am trying to initialize some details at Kamailio startup, this requires some database queries from a few tables. I have read about the htable event, however sql queries are not working in this route. I have come upon following errors. Please suggest a solution for this. Route used: event_route[htable:mod-init] { xlog("L_INFO", "********Initailising the startup route ******\n"); sql_xquery("cb","SELECT id, media_server_port, name FROM domains","ra"); } error : Oct 8 13:28:32 P172 /usr/local/kamailio/sbin/kamailio[28735]: INFO: <script>: ********Initailising the startup route ****** Oct 8 13:28:32 P172 kamailio: ERROR: <core> [daemonize.c:303]: daemonize(): Main process exited before writing to pipe Thanking You, Sunil More Ph : 9503338275

2 1

Familiar topic about Kamailio with Asterisk behind NAT
by Dirk Teurlings - SIGNET B.V. 09 Oct '15

09 Oct '15

Hi, I found some existing topics on this but failed to get a solutions out of them. We're running into some issues with client devices connecting to our private addresses. The way it is setup now: CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) with RTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8) Our Kamaialio and Asterisk are in a private address range, but Kamailio also has a public interface. Most of the clients (about 95%) work well with this setup, but a couple don't. We have one case now where the CLIENT tries to connect to the private address of ASTERISK. And of course, that doesn't work. I'm kind of stuck as to where I need to fix this. I tried using the externaddr option in Asterisk to solve it on that end. But that didn't help anything. The NAT options in Kamailio are not really suited for this, as they tend to fix client NAT problems. Any pointer or help would be greatly appriciated. Cheers, Dirk

8 16

[pua] Question to DB Mode 0
by Maciej Marczyński 09 Oct '15

09 Oct '15

Hi Guys, I have a question regarding pua module parameter 'db mode'. I run Kamailio (4.3.2) with sqlite and I tried to set the parameter to 0 but even then I received: > ERROR: db_sqlite [dbase.c:489]: db_sqlite_commit(): sqlite commit failed: NOT NULL constraint failed: pua.call_id > ERROR: db_sqlite [dbase.c:138]: db_sqlite_cleanup_query(): finalize failed: NOT NULL constraint failed: pua.call_id > ERROR: pua [pua.c:1179]: db_update(): while inserting in db table pua > > As far as I checked the documentation, it says that '0' means: > high speed memory based storage Does it still writes to DB anyway (on timer or whatever?) or just keep it in memory? Is there any way to disable writing to DB? The second thing is the reason of the ERRORs above. Why does pua think that my call_id is null? If you need any more information please let me know. Best regards and have a good weekend, Maciej

3 7

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

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