Hi Ovidiu,

I have just tried this nat_traversal module, and it looks like I cannot run it from the registrars, as it appears that the "nat_keepalive()" parameter will only send the keepalive to the source address the message was sent from, which, if I run it from my registrar, will be the address of the proxy server.

I also tried running this from the proxy server. It seems to work from there, however, the issue have have now, is that even if I unregister a device, the nat_keepalive() application is still sending notify messages. I dont see an exported function anywhere for that module to stop it from sending keepalives when a device unregisters. Is that the expected behaviour?

On 13/05/2011, Ovidiu Sas osas@voipembedded.com wrote:

Try the nat_traversal module: http://www.kamailio.org/docs/modules/3.1.x/modules_k/nat_traversal.html It should handle this kind of scenarios.

Regards, Ovidiu Sas

On Fri, May 13, 2011 at 6:49 AM, Asgaroth 00asgaroth00@gmail.com wrote:

...

Hi All,

I have a scenario where our registrar's are sitting behind our sip proxy. The sip proxy is the only system that has access to the outside world. Our registrar's are all on internal private addresses.

I am trying to configure our registrar's to perform nat pinging. However, because the registrar's are on an internal address there is no way for the nat ping to get out. I enabled the path option so that the registrar stores the path that the registration comes in on. However it doesnt seem like the nathelper module uses the path parameter to send the outgoing nat ping. I tried the nat ping using sip method INFO, but the same applies, it does not appear to be able to send out via the outbound proxy.

I tried to enable the natping option on the sip proxy, but it appears that only registrations with a socket address of the local host will get pinged, or else it is ignored.

Is there an option that I am missing for the nat helper module that will enable me to set an outbound proxy for the nat ping messages?

Any insight would be appreciated.

Thanks

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Am 13.05.2011 18:10, schrieb Asgaroth:

Hi Klaus,

On 13/05/2011, Klaus Darilion klaus.mailinglists@pernau.at wrote:

...

Sending OPTIONS/INFO keep-alives should be possible from the registrar. Sending just CRLF for keep-alive can only be done by the outboundproxy.

How would I achieve this from the registrar? This would be ideal for me, if I could have the registrar that serviced the register request to also maintain the nat keepalive messages? I'm not sure how the nathelper module derives the route to send the OPTIONS/INFO message to the outbound registrar. I would have thought that it would use the path information stored in the usrloc table but it does not appear to do that.

Actually I have not tried it. Thus, if it does not work, you should open a bug report.

...

You could save() the REGISTER before forwarding to the REGISTRAR (or in a reply route if response=200 OK) and set the natping flag before.

If I save the register at the proxy, then that would defeat the purpose of the registrar server. I am trying to offload registration processing onto seperare registrar servers.

If you do not use DB-storage on the outboundproxy I think the CRLF pinging should be quite lightweight.

If I set the natping flag in the reply route, do I still need to save the registration informaiton on the proxy? Or do you mean that I can forward the register requests over to the registrar servers, then look for a 200 OK to the REGISTER and only set the natping flag then? If

Doing it in the response may cause problems if the response contains multiple contact headers. Also you have to call fix_nated_register() in request route to store the socket from where the REGISTER was received.

this is true, I would then also need to look for the REGISTER with expires=0 for an unregistration so that I can disable the natping flag then as well.

True. Or just ping de-registered contact until the contact is expired.

regards klaus