<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
Hello,<BR>
<BR>
I am using Kamailio and nathelper to connect UAs behind a NAT. However, I want to use presence and RLS in this system as well. The problem I have is that the presence and RLS modules are not nathelper aware and the NOTIFY requests that they generate are targeted at the private network IP address and port of the UA.<BR>
<BR>
Has anyone any experience of this? Can anyone help?<BR>
<BR>
I had a cunning plan where, in route[NAT], I detected SUBSCRIBE requests that originate from behind a NAT (and do not have myself as the last hop). When I see a request like this I use add_contact_alias(), record_route() and forward it to myself. I then added a handle_ruri_alias() to the WITH_NAT section of route[RELAY]. The theory being that an in-dialog NOTIFY from presence or RLS will use the route-set established by the SUBSCRIBE transaction.<BR>
<BR>
This almost works. The presence.winfo NOTIFY from the presence module and the initial presence NOTIFY from the RLS module make it back to the client successfully. However, when this forwarding of the SUBSCRIBE is in place the RLS subscriptions don't happen. I know it is the forward of the SUBSCRIBE that is the trigger behind this problem because simply commenting that out (and allowing the first SUBSCRIBE to get to RLS) makes the RLS subscriptions happen (but in this case the NOTIFYs get back to the client and are 404'd because the request URI is not correct).<BR>
<BR>
The only difference between the first SUBSCRIBE and the forwarded SUBSCRIBE is an additional "Via:" header and a "Record-Route:" header.<BR>
<BR>
I ran Kamailio with the -E -ddd options and observed that:
<UL>
<LI>modules_k/rls/subscribe.c:rls_get_service_list() is outputting the line "searching document for user sip:@"
<LI>This function is called by modules_k/rls/subscribe.c:rls_handle_subscribe() and the output suggests that GET_FROM_PURI(msg)->user and GET_FROM_PURI(msg)->host are empty strings
<LI>However, parse_from_header(msg) is called near the top of rls_handle_subscribe() and clearly succeeds to find the "From:" header in the message
<LI>As I mentioned above the forwarded SUBSCRIBE is almost identical to the first SUBSCRIBE, and so it does contain a valid "From:" header
</UL>
<BR>
All I can think of is that Kamailio is becoming confused by the two near-identical SUBSCRIBE requests and that the "cleaning up" of the first (statelessly forwarded) SUBSCRIBE is also "cleaning up" the forwarded SUBSCRIBE that I am currently working with?<BR>
<BR>
My route[NAT]:<BR>
<BLOCKQUOTE>
route[NAT] {<BR>
xlog("L_INFO", "$rm: route[NAT]\n");<BR>
#!ifdef WITH_NAT<BR>
force_rport();<BR>
if (nat_uac_test("19") && $si!="MY_REAL_IP" && $si!="127.0.0.1") {<BR>
xlog("L_INFO", " Request from NAT'd UAC\n");<BR>
if (is_method("REGISTER")) {<BR>
fix_nated_register();<BR>
} else if (is_method("SUBSCRIBE")) {<BR>
add_contact_alias();<BR>
route(RECORD_ROUTE);<BR>
forward(127.0.0.1, MY_REAL_PORT);<BR>
exit;<BR>
} else {<BR>
fix_nated_contact();<BR>
}<BR>
setflag(FLT_NATS);<BR>
}<BR>
#!endif<BR>
return;<BR>
}<BR>
</BLOCKQUOTE>
<BR>
My route[RECORD_ROUTE]:<BR>
<BLOCKQUOTE>
route[RECORD_ROUTE]<BR>
{<BR>
# remove preloaded route headers<BR>
remove_hf("Route");<BR>
if (is_method("INVITE|SUBSCRIBE"))<BR>
record_route();<BR>
<BR>
return;<BR>
}<BR>
<BR>
</BLOCKQUOTE>
The start of my route[RELAY]:<BR>
<BLOCKQUOTE>
route[RELAY] {<BR>
xlog("L_INFO", "$rm: route[RELAY]\n");<BR>
#!ifdef WITH_NAT<BR>
if (check_route_param("nat=yes")) {<BR>
setbflag(FLB_NATB);<BR>
}<BR>
if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) {<BR>
route(RTPPROXY);<BR>
}<BR>
<BR>
handle_ruri_alias();<BR>
#!endif<BR>
</BLOCKQUOTE>
<BR>
Regards,<BR>
<BR>
Peter<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>