10 Nov
2009
10 Nov
'09
11:15 p.m.
Juha Heinanen schrieb:
"final" versions of alias functions are now
ready for testing in in this
sr_3.0 based nathelper.c:
http://box.tutpro.com/tmp/nathelper.c
Great, thanks.
i changed the names to more descriptive ones:
add_contact_alias() and
handle_ruri_alias(). also helper function rr_count(pvar) is included
that assigns into the pvar the number of rr headers in incoming message
(request or reply).
I just wonder why "alias" is used, and not "received". Current similar
features (fix_nated_register, Path) use the term "received" to refer to
the socket from which the request was received, not alias. I know your
mean purpose was TCP, but IMO this is proper method to handle both,
NATed and TCP clients. Thus, I think by using add_contact_received and
handle_uri_received it would be easier for people to understand what the
function does.
But anyway, a name is just name :-)
thanks
klaus
usage example is below. i believe (until otherwise shown) that it
works correctly.
if you are interested, please try with different UAs and different
transports with or without nat.
-- juha
add_contact_alias()/handle_ruri_alias() usage example
-----------------------------------------------------
supports re-use of tcp sessions between proxy and UAs. supports routing
of requests to UAs behind NATs so that r-uri is always what UAs expect.
proxying of media is not shown, but can be easily added.
NON_REGISTER_INITIAL_REQUESTS
-----------------------------
- call alias_contact() for all non-register initial requests, which
don't come from another proxy (which takes care of its own UAs).
- if you know that non-register initial request is going to another
proxy, set TO_PROXY flag before relaying the request.
- in cases, where initial request may go to another proxy, but you are
not sure about it, store the number of record-route headers in
incoming request in an AVP that you can then later test in onreply
route and find out, if next hop was a proxy.
route [NON_REGISTER_INITIAL_REQUESTS] {
if (!is_present_hf("Record-Route")) {
route(ADD_CONTACT_ALIAS);
};
...
if (I_KNOW_FOR_SURE_THAT_NEXT_HOP_IS_ANOTHER_PROXY) {
setbflag("TO_PROXY");
};
if (NEXT_HOP_MAY_BE_ANOTHER_PROXY_BUT_I_DONT_KNOW_FOR_SURE) {
if (!rr_count($avp("rr_count"))) {
send_reply("400", "Bad request");
exit;
};
};
t_on_reply("REPLY");
if (!t_relay()) ...
route [ADD_CONTACT_ALIAS] {
if (!add_contact_alias()) {
xlog("L_ERR", "Error in aliasing contact <$ct>\n");
send_reply("400", "Bad request");
exit;
};
}
REGISTER_REQUESTS
-----------------
- call fix_nated_register() on register requests, if registering ua is
behind nat OR is using tcp.
route [REGISTER_REQUESTS] {
...
if (isflagset(FROM_NATED) || (proto == TCP)) {
fix_nated_register();
if (isflagset(FROM_NATED)) {
setbflag("TO_NATED");
};
};
save("location");
...
IN_DIALOG_REQUESTS
------------------
- call handle_ruri_alias() for all in-dialog requests before
t_relaying them, provided that loose_route() didn't set $du, which it
does if next hop is another proxy. in the latter case set TO_PROXY
fag.
route [IN_DIALOG_REQUESTS] {
loose_route();
...
if ($du == "") {
handle_ruri_alias();
switch ($rc) {
case -1:
xlog("L_ERR", "Failed to handle alias of R-URI
<$ru>\n");
send_reply("400", "Bad request");
exit;
case 1:
xlog("L_INFO", "Routing in-dialog $rm from <$fu> to
<$du>\n");
break;
case 2:
xlog("L_INFO", "Routing in-dialog $rm from <$fu> to
<$ru>\n");
break;
};
} else {
setbflag("TO_PROXY");
}
t_on_reply("REPLY");
if (!t_relay()) {
...
REPLIES
-------
- call add_contact_alias() on all replies except the ones that come from
another proxy.
onreply_route [REPLY] {
if (!isbflagset("TO_PROXY") {
if (is_avp_set("rr_count")) {
if (!rr_count("$(var(rr_count)"))) {
xlog("L_NOTICE", "Bad R-R header in reply\n");
send_reply("400", "Bad reply");
exit;
};
if ($var(rr_count) == $avp(rr_count) + 1) {
route(ADD_CONTACT_ALIAS);
};
} else {
route(ADD_CONTACT_ALIAS);
}
}
...
NOTE
----
- do NOT call fix_nated_contact() on anything, because
add_contact_alias() replaces it.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev