This discussion is quite interesting ...
Nils Ohlmeier wrote:
No. The To-tag is not enough as criteria for
in-dialog. And unfortunately the
presence of Route isn't as well.
You can basically have these type of ACKs (ACKs illustrate the worst case):
- the UAC uses an outbound proxy without a Route
header
(A) > - the in-dialog ACK will have a To-tag and a Route header
(B) > - the out-of-dialog ACK will have a To-tag and no Route header
- the UAC uses a Route header for its outbound proxy
(C) > - then in-dialog ACK will have a To-tag and a Route header (same
as above)
(D) > - the out-of-dialog ACK will have a To-tag and a Route header
(and this is
the problematic case!)
ACK. Lets consider the different forwarding scenarios: tm + sl
tm:
(A) loose_route=true, --> just t_relay
(B) loose_route=false, --> just t_relay (will be absorbed by tm)
(C) loose_route=true, --> just t_relay
(D) loose_route=true, --> just t_relay (will be absorbed by tm)
sl:
(A) loose_route=true, --> just forward
(B) loose_route=false, --> lookup()*, forward
(C) loose_route=true, --> just forward
(D) loose_route=true, --> lookup()**, forward
* if lookup() was done for corresponding INVITE then lookup() then it
also has do be done here. Usually lookup() is done if RURI=myself.
** if lookup() was done for corresponding INVITE then lookup() then it
also has do be done here. This scenario is more complicated - if the
proxy is just used as relay (Route=myself, RURI!=myself) then lookup()
is not necessary. If this is the authoritative proxy (Route=myself,
RURI=myself), then lookup will be performed.
I think all scenarios can be handled with current functionality,
although I would prefer the behavior suggested by JF to have
loose_route=false if there is only one route header which points to the
proxy itself because regardless if the outbound proxy is addressed
directly or with a preloaded route set it has to be routed identically.
regards
klaus
sl dispatcher
The only thing which distinguishes the in-dialog ACKs
from the last
out-of-dialog ACK might be the length of the Route header. If the Route
header has the length one it might be an out-of-dialog ACK. But in the worst
case this is equal to an in-dialog ACK with only one Route header. In this
case the only difference will be the RURI.
process_routes(); # may have different return
values
# -1: no routes found
# -2: only a single route pointing to "myself"
# 1: loose routing done
# 2: strict routing done
... NAT traversal, security checks, ....
t_relay();
exit;
}
process_routes();
# here proceed according to policy, e.g.
# -1, -2: handle now incoming request
# 1, 2: reject out-of-dialog loose/strict-route request
...
Ok, what would be the difference then between this new process_routes()
function and adding more different return values to the existing
loose_route() function?
Nils