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