sr-users

sr-users@lists.kamailio.org

42 participants
37518 discussions

Start a nNew thread

Directory missing compiling dbtext module
by Pedro Antonio Vico Solano 05 Nov '11

05 Nov '11

3 2

CANCEL is not forwarded, if callee does not respond
by Mino Haluz 04 Nov '11

04 Nov '11

Hi, the scenario is like this: - user1 makes a call to user2 - proxy sends receives INVITE and sends it to user2 - user2 does not respond at all (firewall for example) - user1 after 5 seconds hangs up the call with CANCEL - proxy sends to user1 200 canceling CANCEL is not forwarded to user2. Ok this behaviour is maybe ok, but after 30 seconds Request timed out is sent to user1 (fr_inv_timer possibly hit). So if I am thinking well, first CANCEL did not match the transaction ? Why ? It this behaviour ok or do I have to search for something wrong in the config? Thanks, Mino

2 1

Kamailio as SBC / LB Media-Servers farm
by Sammy Govind 04 Nov '11

04 Nov '11

Hello List, I've successfully configured Kamailio with a farm of asterisk servers in L/B | F/O mode. The topology is something like below: User<-->Kamailio<-->Asterisk-Servers Both kamailio and Asterisk serevrs are on public IPs *The problem:* Kamailio and Asterisk Servers need to be on Public IPs in order to fully handle NAT/media related issues. Whereas what I require is to have two interfaces at kamailio server, one is Public other is Private and All the Asterisk Servers should be on LAN/Private IPs. I've tried making a scenario as per my requirement (attached image) but there are some serious NAT and media issues. Can anyone help me how to handle NAT'd Asterisk servers behind Kamailio? Thanks and Best Regards. Sammy

4 7

Kamailio as SBC / LB Media-Servers farm
by Sammy Govind 04 Nov '11

04 Nov '11

1 0

Issue with version table
by Lucas Alvarez 03 Nov '11

03 Nov '11

Hi, I've enabled xcap server in kamailio 3.1.3 and I'm stuck with this error: 0(5073) ERROR: <core> [db.c:408]: invalid version 0 for table subscriber found, expected 6 (check table structure and table "version") I've already checked the version table and the table_name = 'subscriber' has table_version = 6. Any help will be appreciated. Regards. Lucas

2 3

Dispatcher Confusion (v3.2.0)
by Asgaroth 03 Nov '11

03 Nov '11

Hi All, Just been doing some testing with Kamailio 3.2 and the dispatcher module, and have some strange behaviour, can we confirm if it is expected behaviour or a bug of some sort. It appears that I can only set the dspatcher state via fifo command once, and not reset it again, here is an example: version: kamailio 3.2.0 (i386/linux) 94d3b8 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 94d3b8 compiled on 12:34:43 Oct 20 2011 with gcc 4.1.2 Here we start with the dispatcher list as it was pulled from the database and currently loaded in memory. # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= Now I try to set one gateway inactive: # kamctl fifo ds_set_state i 1 sip:1.1.1.1:10001 # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= All normal so far, now if I try to set the same gateway active again, the state still stays inactive, i dont seem to be able to change the state back to active. The same thing happens if I attempt to set this state to disabled and then try to set it back to active afterwards. The state does not change from what the first attempt was. # kamctl fifo ds_set_state a 1 sip:1.1.1.1:10001 # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=IX priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= Now I can try to set the state to inactive probing, that works. # kamctl fifo ds_set_state ip 1 sip:1.1.1.1:10001 # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= Now if I try to disable the same destination: # kamctl fifo ds_set_state d 1 sip:1.1.1.1:10001 # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= State still stays in Inactive/Probing mode. Now if I try to set the same gateway to active/probing mode, I cant: # kamctl fifo ds_set_state ap 1 sip:1.1.1.1:10001 # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=IP priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= The only way for me to get the state back to active after the above is to do a reload on the dispatch table: # kamctl dispatcher reload # kamctl dispatcher dump SET_NO:: 2 SET:: 1 URI:: sip:1.1.1.1:10001 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10000 flags=AX priority=0 attrs= SET:: 2 URI:: sip:1.1.1.1:10003 flags=AX priority=0 attrs= URI:: sip:1.1.1.1:10002 flags=AX priority=0 attrs= Is the dispatcher expected to behave as above? I'm still trying to understand the different states assuming the following options are set in the configuration file: modparam("dispatcher", "ds_ping_interval", 10) modparam("dispatcher", "ds_probing_threshhold", 1) modparam("dispatcher", "ds_probing_mode", 0) AX = Active/No Probing (*) Gateway is used in ds_select_*, ds_next_* (*) No OPTIONS/INFO messages are sent to destination to check alive state This appears to be the normal operating state with no issues detected. AP = Active/Probing (*) Gateway is NOT used in ds_select_*, ds_next_* (*) OPTIONS/INFO messages ARE sent to destination to check alive state This appears to be the state taken when a gateway times out and ds_mark_dst("p") is set in failure route, the gateway is "pinged" while down and set into AX mode once a response is recieved. IX = Inactive/No Probing (*) Gateway is NOT used in ds_select_*, ds_next_* (*) No OPTIONS/INFO messages sent to destination This appears to be the state taken when a gateway times out and if ds_mark_dst("i") is set in failure route, this gateway is set inactive and no "pinging" is performed. IP = Inactive/Probing (*) Gateway is NOT used in ds_select_*, ds_next_* (*) OPTIONS/INFO messages ARE sent to destination I'm not sure when this state would be reached unless it is set by fifo command. The ds_mark_dst function only allows "a","i" or "p". So the probing method would only become active is ds_probing_mode = 1. In my case it is 0, so I'm not sure if I would ever reach this state unless I forced it. What would happen here is the gateway came back alive once in "IP" state, would it go back to "AX" state? DX = Disabled/No Probing (*) Gateway is administratively set to down This is where manual intervention has occured and the destination has been set to administrativly down, for example, work being carried out on the destination gateway. All these states make sense, for the most part, I'm a little unsure of how IP/IX is meant to work unless you manually set it to "inactive" in your failure route. The main concern though is the the fifo commands dont appear to be working as expected, I can only set the state for a destination manually once, and not again after that, unless I perform a dispatcher reload. Has anyone else experienced this behaviour? Any comments/suggestions explanations are most welcome. Thanks

3 32

Kamailio dinner next week in Cape Town, South Africa
by Daniel-Constantin Mierla 03 Nov '11

03 Nov '11

Hello, it happens to come across Cape Town for few days and I was wondering if there are folks using our project or doing VoIP in general that want to meet up for a dinner. The date for dinner is planned for next Tuesday, November 8, 2011. Place will be decided once I know if there are people coming and how many. Likewise with such events done in the past, it is going to be a dinner open for everyone that wants to join, each participant paying the drinks and food for himelf/herself. The goal is to meet and discuss latest trends in IP communication and what's up lately around our project. Here are some pictures from two past similar events: http://www.asipto.com/gallery/v/social_meeting_barcelona2008/ http://www.asipto.com/gallery/v/FOSDEM2009/ So, if there are people on these mailing lists in the area of Cape Town next Tuesday and want to meet, please reply to me till Friday evening -- I will follow up privately to each person that is going to join with details about location and start time. Looking forward to meet some of you very soon! Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

2 1

TOS=0 in kamailio.cfg
by DELEY Marion 03 Nov '11

03 Nov '11

Hi, I'm trying to set tos value to zero but kamailio doesn't accept it. In fact, it's DSCP field which interest me but i can't set zero. Can you explain me why is it forbidden and how can i do that ? Thanks a lot Marion

1 0

is there help on mi commands in sercmd?
by Juha Heinanen 03 Nov '11

03 Nov '11

sercmd has help that lists the commands, one of which is mi. is there a way to list all mi sub-commands? i have tried ip-proxy_ctl> help mi Execute MI command sip-proxy_ctl> mi help error: 500 - command not available -- juha

2 3

extra _ctl in ctl file
by Juha Heinanen 03 Nov '11

03 Nov '11

i just noticed that my sip-proxy_ctl (alias kamailio_ctl) command has stopped working. it now adds an extra _ctl to the socket file name: # sip-proxy_ctl ERROR: connect_unix_sock: connect(/tmp/sip-proxy_ctl_ctl): No such file or directory [2] any idea where that comes from or it is only me, who has this problem? i have not changed anything the command used to work fine earlier. -- juha

2 4

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