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