Hi Juha,
My configuration is trying to achieve exactly what you suggest.
The Kamailio presence and RLS modules send NOTIFYs using the route-set established by the SUBSCRIBE. This means that if I call add_contact_alias() and just pass the SUBSCRIBE to the module the NOTIFY will use that contact address as a request URI but the NOTIFY will not go back through the Kamailio route processing. Because it doesn't go back through the route processing handle_ruri_alias() is never called for it. The end result is that Kamailio attempts to route the NOTIFY to my private IP and fails.
My forwarding (looping) the SUBSCRIBE back to myself once forces NOTIFY requests from the presence and RLS modules to go through the Kamailio routing logic. This means that handle_ruri_alias() gets called and the request URIs of the NOTIFY (correctly) contain my private IP but the requests are (correctly) routed to my NAT devices public IP.
As I said, this works for the presence.winfo NOTIFY from presence and the first presence NOTIFY sent directly from RLS. The problem is that there seems to be a problem with the parsing of this forwarded SUBSCRIBE because rls_handle_subscribe() doesn't work. The RLS module never sends any SUBSCRIBEs for the contacts in my resource list.
Regards,
Peter
peter,
i don't have experience with k rls module, but in my environment if initial subscribe comes from behind nat, i just call add_contact_alias and add a nat param to r-r header for in-dialog requests. notifys from rls server then contain ;alias param in request uri and the nat param in route header. based on these sip proxy is able to get thee get notifys to the uas behind nat.
-- juha
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