Hi List,
I have a Kamailio3.1 server and RTPProxy running in WAN.
The calls between UA will automatically terminated in Callee UA side 36s after connected, while no one sends a BYE.
While Kamailio and UA are in LAN at all , everything is just working well.
Is it my rtpproxy doesn't working correctly or something else is wrong? What can I do to fix it.
Any hint??
BTW, Kamailio is installed following official guide http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git The kamailio.cfg wasn't changed at all except for below: ----------------------------------------------------------------------------------------- 1) adding the following lines: #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB #!define WITH_NAT
2)uncommenting the line below in route[REGISTRAR], setbflag(FLB_NATSIPPING);
3)change rtpproxy port corresponding modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:22222")
-----------------------------------------------------------------------------------------
and my rtpproxy1.2.1 was installed by apt-get install rtpproxy, with 1) /etc/default/rtpproxy changed into:
# Defaults for rtpproxy
# The control socket.
#CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock"
# To listen on an UDP socket, uncomment this line:
CONTROL_SOCK=udp:127.0.0.1:22222
LISTEN_ADDR=xx.xx.xx.xx
# Additional options that are passed to the daemon.
EXTRA_OPTS="-l ${LISTEN_ADDR}" 2) and started by rtpproxy -l xx.xx.xx.xx -s udp:localhost:22222 -u kamailio
Your help will be great appreciated.
Coca
Dear Klaus,
Since I have Usrloc record made for registration of myUA behind nat looks like: Contact: sip:1234@192.168.10.50:2305 ;transport=TCP;line=7e1d8b95f65b25a;expires=600;received="sip:27.96.63.122:49202 ;transport=TCP"
I thought my rtpproxy is running. However , the call can be established even without NAT enable, and it also ends unusually after 36s.
Attachment is the ngrep log in my Kamailio server side on 5060 port. ( I have replaced my server ip as xx.xx.xx.xx and the UA name as myUA)
Any hint will be great appreciated.
Coca
2011/7/21 Klaus Darilion klaus.mailinglists@pernau.at
IF you take a look at the trace you see, that the caller does not send ACK after receiving 200 OK. Either it does not send ACK or it sends it to wrong destination.
Trace at the caller's phone and watch log file of caller.
regards Klaus
Am 21.07.2011 12:33, schrieb Coca:
Dear Klaus,
Thank you for your email. I tried using my UA connecting to the servers provided by other free sip service provider like Opensips in WAN. And the same problem didn't happen. My UA did sent ACK after the 200 OK in the invite process.
It looks like the problem is my Kamailio server 's NAT setting.
I wonder how I can do to verify whether the NAT setting is correctly done. What kind of method did you use in this issue?
Your help will be great appreciated.
Coca
2011/7/21 Klaus Darilion klaus.mailinglists@pernau.at
If it is "your" client, then you should be able to debug your client to find out if ACK is sent, and if yes, where the ACK is sent to. I inspected the last trace and I didn't spotted an error.
regards klaus
Coca wrote:
Dear Klaus,
Sorry for the late response. I check the log of the caller and found out:
The message header of 200 OK (with session description) from the server to the caller , right before the RTP starts, has the value sip:10.150.175.210;lr=on;nat=yes of Record-Route . Then the caller sent ACK to ip 10.150.175.210. The ip 10.150.175.210 is the private ip of the amazon server I am using , which is unreachable for the caller.
Is it kinda installing Kamailio inside the NAT issue? What should I do?
Your help is great appreciated.
Thanks,
Coca
2011/7/23 Klaus Darilion klaus.mailinglists@pernau.at
Am 23.07.2011 17:54, schrieb Coca:
Is it kinda installing Kamailio inside the NAT issue?
Yes.
You have to set http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#advertised_add...
and add the public IP address to alias=....
Basically a SIP proxy behind NAT sucks and may you give some more headaches.
regards klaus
Dear Klaus,
Thanks to your advice. I've already had it resolved.
Coca
2011/7/25 Klaus Darilion klaus.mailinglists@pernau.at