sr-users November 2011

sr-users@lists.kamailio.org

78 participants
114 discussions

Re: [SR-Users] Fwd: Kamailio as SBC / LB Media-Servers farm

by Klaus Darilion

On 04.11.2011 10:57, Sammy Govind wrote: > SORRY for PM but this is not getting through to the users List due to size. I have cc-ed the list. > > ---------- Forwarded message ---------- > From: *Sammy Govind* <govoiper(a)gmail.com <mailto:govoiper@gmail.com>> > Date: Fri, Nov 4, 2011 at 1:55 PM > Subject: Re: [SR-Users] Kamailio as SBC / LB Media-Servers farm > To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org > <mailto:sr-users@lists.sip-router.org>> > > > Klaus: mhomed did work indeed - no need to force_send_socket() now :) Thanks > > I'm progressing abit. > > RTP-Proxy was run in bridged mode like this. > > *rtpproxy -l 109.XX.XXX.212/192.168.2.29 <http://192.168.2.29> -s > udp:localhost:22222 -F -d DBUG* See description of i,e flag: http://kamailio.org/docs/modules/3.2.x/modules/rtpproxy.html#id2535618 Thus in your setup 109.... is the "internal" interface and 192.... is the "external" interface. That's mixed. Thus I advice you to switch the order of IP addresses so that internal is 192... and external is 109... This is essential to use the i,e flags correctly. > I'm getting RTPstats published on Kamailio/RTPproxy syslog. > > I am using Echo() application in asterisk. So I've observed that my > audio went to asterisk and asterisk did indeed send audio back to the > RTPproxy assigned ports BUT the RTPproxy isn't forwarding the Audio back > to the client or may-be the audio is lost somewhere in between > RTPproxy<--->Client. /[See Wirshark Flow-Diagram taken > on-Kamailio/RTPproxy Server]/ In your trace you see, that RTP does not use the internal IP address, but only the external IP address. Thus I suspect that the RTP packets from Asterisk to the public rtpproxy interface do not even arrive at rtpproxy. > > The # DTMF signal sent from Client phone reached asterisk safely and > terminated the Echo() application. > > I did the ip_forwarding thingie too.-- somebody mentioned to do this if > using RTPproxy in bridged mode. This is bullshit. People seem to not understand IP at all. rtpproxy is forwarding in user mode - it receives on a UDP socket and sends on a UDP socket. Thus, kernel based forwarding is not involved when using rtpproxy. You can disable IP forwarding again. > #echo "1" >> /proc/sys/net/ipv4/ip_forward > #sysctl -p > > > Here are the corresponding Logs from Kamailio and rtpproxy. The thing is quite easy. Swap the IP addresses when starting rtpproxy and then configure Kamailio to call rtpproxy with the proper i,e flags (as described in my previous email). For example: if (has_body("application/sdp")) { if ($si == "192.168.2.75") { # message from internal to external rtpproxy_manage("ie"); } else { # message from external to internal rtpproxy_manage("ei"); } } Put above code block in the main route block and also in a reply route which will be activated (or in the default reply route). Put some xlog statements around the rtpproxy calls to verify the proper command is called. regards Klaus

12 years, 6 months

Kamailio 3.2 Acc Runtime error

by Nathaniel L Keeling

I am getting this error when I start kamailio 3.2 on Solaris 10. Any direction on solving this would be greatly appreciated. ERROR: load_module: could not open module </opt/kamailio-3.2/lib64/kamailio/modules_k/acc.so>: ld.so.1: kamailio: fatal: relocation error: file /opt/kamailio-3.2/lib64/kamailio/modules_k/acc.so: symbol timersub: referenced symbol not found Thanks Nathaniel

12 years, 6 months

Directory missing compiling dbtext module

by Pedro Antonio Vico Solano

12 years, 6 months

CANCEL is not forwarded, if callee does not respond

by Mino Haluz

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

12 years, 6 months

Kamailio as SBC / LB Media-Servers farm

by Sammy Govind

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

12 years, 6 months

Kamailio as SBC / LB Media-Servers farm

by Sammy Govind

12 years, 6 months

Issue with version table

by Lucas Alvarez

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

12 years, 6 months

Dispatcher Confusion (v3.2.0)

by Asgaroth

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

12 years, 6 months

Kamailio dinner next week in Cape Town, South Africa

by Daniel-Constantin Mierla

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

12 years, 6 months

TOS=0 in kamailio.cfg

by DELEY Marion

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

12 years, 6 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 November 2011