Daniel,
As always experience counts the most (I did not consider the multiple
contacts scenario).
Here is what I cooked now after your advice (for the sake of proper
archiving). In the end I will process the rcv contact parameter (which
will become ruri param) in the proxy sitting in front of registrar and
set the $du out of it.
"""
if (!lookup("location")) {
$var(rc) = $rc;
t_newtran();
switch ($var(rc)) {
case -1:
case -3:
send_reply("404", "Not Found");
exit;
case -2:
send_reply("405", "Method Not Allowed");
exit;
}
}
# Populate received contact parameter if found in db
$var(received) = $(du{uri.param,received});
if !strempty( $var(received) ) {
$ru = $ru + ";rcv="+ $var(received);
}
$var(i)=0;
while($var(i)<$branch(count)) {
$var(received) = $(branch(dst_uri)[$var(i)]{uri.param,received});
if !strempty( $var(received) ) {
$(branch(uri)[$var(i)]) = $(branch(uri)[$var(i)]) + ";rcv="+
$var(received);
}
$var(i) = $var(i) + 1;
}
sl_send_reply("302", "Locator Redirect");
exit;
"""
Thanks again!
DanB
On 08/17/2012 11:42 AM, Daniel-Constantin Mierla wrote:
Hello,
On 8/17/12 11:13 AM, DanB wrote:
If it helps someone else, got in the mean time
another way of
accessing it, via transformations on top of $du:
$(du{uri.param,received}).
$du is the address of next hop and it is set due to the Path headers in
this case. In the case there is no intermediary proxy, it will be the
address of the NAT router.
In case you have many contacts for same users, then you have to look
also at the other branches, which are accessible via $branch(...).
The question which still stands: is there more "automated" way to
properly handle 302 redirect when the contact is behind NAT?
This might not work
for multiple contacts. I even wonder if there is a
RFC saying what to do in the case there are many contacts with different
Path headers. Path headers have to be turned into Route headers after
lookup(), but for redirects?!? Shall Path should be added in reply? Any
IETF guru around that can shed some light?
Cheers,
Daniel