<div dir="ltr"><div>Yes, you're right about contact matching and ATAs, this is a part of our case too.</div>I actually use Path module to forward REGISTERs to backend servers. But there is a problem that not all backends support Path, like Asterisk 11.<br><div><br></div><div>If I get the point right, I should forward them as is and when I receive request from backend set $ru to contact and $du to Contact's received parameter?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-19 22:02 GMT+04:00 Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/19/2015 12:56 PM, Dmitry Sytchev wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there a way to make save() use original request fields like<br>
T_req($ct), or some way to call save() with full set of custom params?<br>
</blockquote>
<br></span>
Yes; in fact, there are many standards-based reasons why it's desirable to store the original Contact binding provided by the registrant. Many devices (e.g. ATAs, various gateways, for instance) will not accept an INVITE with an incoming Request URI that does not correspond to the exact Contact URI that it sent in the REGISTER request.<br>
<br>
This is why Kamailio's usrloc record provides a 'received' field in addition to a 'contact' field. Take a look at this:<br>
<br>
<a href="http://kamailio.org/docs/modules/4.2.x/modules/registrar.html#registrar.p.received_param" target="_blank">http://kamailio.org/docs/<u></u>modules/4.2.x/modules/<u></u>registrar.html#registrar.p.<u></u>received_param</a><br>
<br>
In essence, what you want is for the external IP:port to be stored in the 'received' value while the original Contact is stored in the 'contact' value. The 'received' value will be used as the destination set ($du) for inbound routing, while the Request URI will remain consistent with the Contact URI.<br>
<br>
The issue of having two proxies is a separate and more complex one. Ultimately, to make it work, you're going to need to use Path, which is like Record-Route, but for REGISTERs:<br>
<br>
<a href="http://kamailio.org/docs/modules/4.2.x/modules/registrar.html#registrar.p.path_mode" target="_blank">http://kamailio.org/docs/<u></u>modules/4.2.x/modules/<u></u>registrar.html#registrar.p.<u></u>path_mode</a><br>
<br>
But, the first step to solving your problem is to realise that you should not actually be rewriting the Contact header as your NAT traversal strategy. You should add the received IP:port as parameters in one way or another to be passed onto the receiving registrar, as for example using Contact URI header parameters per the received_param doc I linked to above.<br>
<br>
-- Alex<br>
<br>
-- <br>
Alex Balashov - Principal<br>
Evariste Systems LLC<br>
235 E Ponce de Leon Ave<br>
Suite 106<br>
Decatur, GA 30030<br>
United States<br>
<br>
Tel: +1-678-954-0670<br>
Web: <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.alexbalashov.com/" target="_blank">http://www.alexbalashov.com/</a><br>
<br>
______________________________<u></u>_________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>users</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best regards,<br><br>Dmitry Sytchev,<br>IT Engineer</div>
</div>