2011/7/23 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,

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 <mailto: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,
>
> 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
<mailto:klaus.mailinglists@pernau.at>
> <mailto:klaus.mailinglists@pernau.at
<mailto:klaus.mailinglists@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
> > 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>
> >
> > 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@lists.sip-router.org
<mailto:sr-dev@lists.sip-router.org>
<mailto:sr-dev@lists.sip-router.org
<mailto:sr-dev@lists.sip-router.org>>
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> _______________________________________________
> sr-dev mailing list
> sr-dev@lists.sip-router.org
<mailto:sr-dev@lists.sip-router.org>
<mailto:sr-dev@lists.sip-router.org
<mailto:sr-dev@lists.sip-router.org>>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
>
> --
> --------------------------
> Room to Fly, Endless Sky!
>
> --Yi Chen
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

--
--------------------------
Room to Fly, Endless Sky!

--Yi Chen

------------------------------------------------------------------------

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev