<div dir="ltr">Daniel, thank you.<div><br></div><div>You are right. NAT pinging from freeswitch side is more preferred in my use case. And it works pretty well. Thank you once more.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-03 16:59 GMT+02:00 Daniel Tryba <span dir="ltr"><<a href="mailto:d.tryba@pocos.nl" target="_blank">d.tryba@pocos.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 03, 2017 at 04:07:20PM +0200, Vladyslav Zakhozhai wrote:<br>
> Daniel, thank you for your answer.<br>
><br>
> You did not understand me completely. This is my fault.<br>
><br>
> Let me put it this way. I want kamailio to handle NAT (fixing nat only from<br>
> client's side) not being registrar itself. This also includes nat pinning.<br>
> usrloc module is a dependency for nat pinning in nathelper module.<br>
><br>
> Request: UAC behind NAT ===> kamailio == fixed contact ==> freeswitch<br>
> Respnse: freeswitch == 200 OK ==> kamailio (store contact in usrloc, start<br>
> pinning) == 200 OK ==> UAC behind NAT<br>
><br>
> Kamailio starts pinning UACs behind NAT only after successful<br>
> authentication and registration on freeswitch box.<br>
><br>
> No nat fixes between kamailio and freeswitch (only from UAC).<br>
<br>
<br>
</span>You keep telling kamailio isn't the registrar, but you are implementing<br>
a registrar :) (but instead of authenticating locally you leave that to<br>
an other backend)<br>
<br>
To my understanding (without testing), saving the REGISTERs to the<br>
kamailio locationdb isn't necessary. You need usrloc to mangle Contact<br>
headers, nothing more. So what is the purpose for storing the REGISTERs<br>
in kamailio? Unless you mean NAT pinging instead of NAT pinning (which I<br>
interpreted to somehow fixing a all traffic to the source of the<br>
REGISTERs (which is what normally is done)).<br>
<br>
Looks like you are trying to implement something like Path<br>
<a href="https://tools.ietf.org/html/rfc3327" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>rfc3327</a><br>
<br>
I'd take a look at Path support in Freeswitch and Kamailio. Use<br>
add_contact_alias to add the source ip/port to the Contact, then add a<br>
Path header to REGISTERs befoire sending it to Freeswitch. And let<br>
Freeswitch do the keepalive pinging based on it's own location database<br>
(you need to add some routing logic to forward (presumably) OPTIONS from<br>
Freeswitch to the alias portion of the RURI and back again).<br>
This way you are essentially creating a very lightweight stateless<br>
kamailio proxy.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">С уважением,<br>Владислав Захожай<br><br></div></div>
</div>