[SR-Users] SUBSCRIBE/NOTIFY record route

[Klaus Darilion]

On 20.08.2012 23:26, Spencer Thomason wrote:
> Hello all,
>
> I'm using Kamailio (on a public IP) as a border proxy that handles NAT
> traversal (detection and keep alives) for several Freeswitch servers
> which have public IPs as well.  I'm having a problem record-routing
> SUBSCRIBEs and NOTIFYs for nated UACs.  If the UAC is behind NAT, I am
> adding a Record-Route to the initial SUBSCRIBE and NOTIFY request.  This
> works great until the UAC (in this case a Cisco SPA509G) refreshes the
> subcription and sends the SUBSCRIBE directly to the Freeswitch server.

If the phone receives the Record-Route headers then this is a bug in the 
Cisco phone.

>   Since the request doesn't pass through the proxy, Freeswitch then
> sends NOTIFYs directly to the UAC which only recieves the first NOTIFY
> as the NAT pinhole is still open from the SUBSCRIBE.  The UAC did

I think this is a bug in Freeswitch. IIRC the route set can not be 
changed during a dialog.

> receive a NOTIFY validating the subscription, and continues to refresh
> the subscription directly to the freeswitch server.  The completely
> breaks presence.
>
> What is the correct way to ensure all SUBSCRIBE/NOTIFYs pass through the
> proxy?  I have found that I can force this behavior by modifying the
> Contact header in the 202 Accepted to point back to the proxy but I'm
> not sure if this is what I "should" be doing.

That's what I did once because of this Cisco bug. I do not see another 
possibility. If the phone ignores the route-set but sends to the Contact 
URI, then you have to change the Contact URI to point to Kamailio, and 
on incoming reSUBSCRIBEs change the RURI to the original Contact URI 
(Freeswitch).

To rewrite the contact you have 2 possibilities:

a) if you have a fixed mapping from user to freeswitch-server, then 
apply this mapping also for the reSUBSCRIBE to get the IP address of the 
freeswitch node

b) if there is no fixed mapping, encode the original Contact URI into 
the new one. When receiving the reSUBSCRIBE, decode the RURI to get the 
original Contact URI back. If freeswitch does not care about the RURI in 
the reSUBSCRIBE then this can be done quite easy (by using the nathelper 
functions), e.g.:


reply-route of SUBSCRIBE:

   ...
   remove_hf("Contact");
   # '1' means UDP transport
   append_hf("Contact: <sip:ip.addr.of.proxy:port;alias=$si~$sp~1>\r\n");
   ...

WITHIN_DIALOG route:
   ...
   if (has_totag()) {
     if (is_method("SUBSCRIBE")) {
       handle_ruri_alias();
     }
   }
   ...

regards
Klaus