Nils Ohlmeier wrote:
On Thursday 12 July 2007 20:31:10 Greger V. Teigre
wrote:
I vote for a new preloaded_route() in trunk. I
also suggest a new alias
for loose_route (or rename and create loose_route as backwards
compatible name): in_dialog() returning true if and only if the message
being processed is and in-dialog message.
The problem is that you simply can not provide the functions you want in a
stateless way.
An non-2xx ACK with a preloaded route looks exactly the same then a 2xx ACK. A
preloaded_route() function thus has no chance to distinguish them. And I will
not make the rr module depending on the tm module, just to query tm all the
time if it knows something about this transaction or not.
IMHO the only way to distinguish these two is the RURI. Because in a normal
loose route case the 2xx ACK should have non-local URI (the remote Contact)
as RURI. But the non-2xx ACK should have a local RURI.
But with this theory we are back to the original topic: is a TEL URI a local
URI or not.
Using RURI domain wont work, e.g. A@mydomain calls B(a)iptel.org. If I
want the call from A to go to my dispatcher first, then to my proxy
cluster (e.g. for authentication and SIP Identity signing) and then to
iptel the dispatcher also needs to distinguish the
non-2xx-ACK+preloadedroute.
And an in_dialog() function would not work as well.
Because the To-tag is not
enough to decide wether the request belongs to an established dialog or not.
And the presence of one Route header also means nothing.
Is just came to my mind that a possible solution could be to add some kind of
secret information to our Record-Route headers. Then the criteria for
distinguishing a preloaded from an in-dialog routed request would be the
presence of this "secret" information in the Route header. And if a UA omits
this "secret" add-on from the Route header it would be guilty on its own that
its requests might be mis-routed.
I had the same idea - probably there is no other workaround.
btw: I guess there are many ser users out there which use dispatcher in
stateless mode - how do they handle this yet?
regards
klaus