[Kamailio-Users] Doubt about nat=yes

[mayamatakeshi]

On Sun, Jan 25, 2009 at 3:06 AM, Iñaki Baz Castillo <ibc at aliax.net> wrote:

> 2009/1/24 mayamatakeshi <mayamatakeshi at gmail.com>:
> > Hello,
> > I'm trying to understand this sample cfg:
> > http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
> >
> > This cfg is used as foundation for some of our cfg files here but nobody
> is
> > sure about exactly how some things work. So I'm trying to clear things
> up.
> > In particular, I am clueless about why there is code removing "nat=yes"
> from
> > the URI and adding it to the Contact header (actually I don't know what
> is
> > its meaning. I suppose this is a way of a client advertising that it is
> > behind NAT, but I couldn't find which RFC defines this):
> >
> > subst_uri('/(sip:.*);nat=yes/\1/')
> >
> > search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
> >
> > Is this something that always must be done when dealing with nat or it
> was a
> > particular situation that the writer of the cfg had to workaround?
> > I'm rewriting our cfg file (to be used with m4) and I'm trying to remove
> > unnecessary things.
>
> The Contact header of the caller (in the initial INVITE) and the
> Contact header of the callee (in the 200 OK) remain  during a dialog.
> This is, if the caller Contact contains
> "sip:alice at domain;param=qwerty" then when the callee creates an
> in-dialog request in that dialog (BYE, re-INVITE, INFO...) the RURI
> will be "sip:alice at domain;param=qwerty".
>
> In this way, the trick is done by the proxy who adds that parameter
> "nat=yes" to the Contact of both (caller and callee) when the call is
> detected to be behind NAT. In this way, for in-dialog requests the
> proxy just must examine the RURI to know if the related dialog has NAT
> or not, and just in that case reuse RtpProxy and so.
>
> Another way is the proxy adding "nat=yes" parameter to the
> Record-Route header in the initial INVITE, since RR header will become
> a Route header in every in-dialog message for that dialog.


Iñaki, thanks, I got it now.

>
> > Another thing in the cfg: in case a reinvite is issued, should not
> > unforce_rtp_proxy be called before force_rtp_proxy is called again? Could
> > this lead to having rtpproxy leaking resources?
>
> No, you should call RtpProxy with "l" parameter so it just will take
> an action is there is *already* a RTP session for that dialog.


OK. According to docs, "I" is on by default.
Regards,
mayama
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20090126/49655f3a/attachment.htm>