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,
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(a)pernau.at <mailto:
klaus.mailinglists(a)**pernau.at <klaus.mailinglists(a)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,
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(a)pernau.at
<mailto:klaus.mailinglists@**pernau.at <klaus.mailinglists(a)pernau.at>>
<mailto:klaus.mailinglists@**pernau.at<klaus.mailinglists@pernau.at>
<mailto:klaus.mailinglists@**pernau.at <klaus.mailinglists(a)pernau.at>
>
This sounds like a NAT problem, where the callee does not
receive the
ACK request (INVITE-200OK-ACK).
regards
klaus
Am 21.07.2011 10:32, schrieb Coca:
> 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<http://www.kamailio.org/dokuwiki/doku.php/instal…
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
<http://127.0.0.1:22222>
<http://127.0.0.1:22222>
<http://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 <http://127.0.0.1:22222> <
http://127.0.0.1:22222>
<http://127.0.0.1:22222>
<http://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
>
______________________________**_________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
<mailto:sr-dev@lists.sip-**router.org
<sr-dev(a)lists.sip-router.org>>
<mailto:sr-dev@lists.sip-**router.org <sr-dev(a)lists.sip-router.org>
<mailto:sr-dev@lists.sip-**router.org <sr-dev(a)lists.sip-router.org>>>
dev
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev>
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
<mailto:sr-dev@lists.sip-**router.org
<sr-dev(a)lists.sip-router.org>>
<mailto:sr-dev@lists.sip-**router.org <sr-dev(a)lists.sip-router.org>
<mailto:sr-dev@lists.sip-**router.org <sr-dev(a)lists.sip-router.org>>>
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
--
--------------------------
Room to Fly, Endless Sky!
--Yi Chen
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
<mailto:sr-dev@lists.sip-**router.org<sr-dev@lists.sip-router.org>
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
<mailto:sr-dev@lists.sip-**router.org<sr-dev@lists.sip-router.org>
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
--
--------------------------
Room to Fly, Endless Sky!
--Yi Chen
------------------------------**------------------------------**
------------
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
______________________________**_________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org