<br><div class="gmail_quote">On Sun, Jan 25, 2009 at 3:06 AM, Iņaki Baz Castillo <span dir="ltr"><<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/1/24 mayamatakeshi <<a href="mailto:mayamatakeshi@gmail.com">mayamatakeshi@gmail.com</a>>:<br>
<div class="Ih2E3d">> Hello,<br>
> I'm trying to understand this sample cfg:<br>
> <a href="http://voip-info.org/wiki/view/OpenSER+And+RTPProxy" target="_blank">http://voip-info.org/wiki/view/OpenSER+And+RTPProxy</a><br>
><br>
> This cfg is used as foundation for some of our cfg files here but nobody is<br>
> sure about exactly how some things work. So I'm trying to clear things up.<br>
> In particular, I am clueless about why there is code removing "nat=yes" from<br>
> the URI and adding it to the Contact header (actually I don't know what is<br>
> its meaning. I suppose this is a way of a client advertising that it is<br>
> behind NAT, but I couldn't find which RFC defines this):<br>
><br>
> subst_uri('/(sip:.*);nat=yes/\1/')<br>
><br>
> search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');<br>
><br>
> Is this something that always must be done when dealing with nat or it was a<br>
> particular situation that the writer of the cfg had to workaround?<br>
> I'm rewriting our cfg file (to be used with m4) and I'm trying to remove<br>
> unnecessary things.<br>
<br>
</div>The Contact header of the caller (in the initial INVITE) and the<br>
Contact header of the callee (in the 200 OK) remain during a dialog.<br>
This is, if the caller Contact contains<br>
"sip:alice@domain;param=qwerty" then when the callee creates an<br>
in-dialog request in that dialog (BYE, re-INVITE, INFO...) the RURI<br>
will be "sip:alice@domain;param=qwerty".<br>
<br>
In this way, the trick is done by the proxy who adds that parameter<br>
"nat=yes" to the Contact of both (caller and callee) when the call is<br>
detected to be behind NAT. In this way, for in-dialog requests the<br>
proxy just must examine the RURI to know if the related dialog has NAT<br>
or not, and just in that case reuse RtpProxy and so.<br>
<br>
Another way is the proxy adding "nat=yes" parameter to the<br>
Record-Route header in the initial INVITE, since RR header will become<br>
a Route header in every in-dialog message for that dialog.</blockquote><div><br>
Iņaki, thanks, I got it now. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> Another thing in the cfg: in case a reinvite is issued, should not<br>
> unforce_rtp_proxy be called before force_rtp_proxy is called again? Could<br>
> this lead to having rtpproxy leaking resources?<br>
<br>
</div>No, you should call RtpProxy with "l" parameter so it just will take<br>
an action is there is *already* a RTP session for that dialog.</blockquote><div> </div><div>OK. According to docs, "I" is on by default.<br>Regards,<br>mayama<br><br></div></div>