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