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
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
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
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
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
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
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
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/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
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
