[Serusers] [Serdev] loose_route behaviour, detecting single Route with myself

[Klaus Darilion]

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 at mydomain calls B at 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