13 Jul
2007
13 Jul
'07
9:19 a.m.
On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:
No. That is not true. Because you could receive a non-2xx ACK with a TEL RURI
and preloaded route. What now?
Sure, they are. But I currently do not really see any option for this problem.
Except we would consider removing strict route support. Then would not have
to look at the RURI at all any more. But I'm not in favor of that.
Nils
Nils Ohlmeier wrote:
loose_route should return false for this, because the message can not be
handled/routed by simply forwarding the request. This was the thing which
Dragos complained about earlier on the mailing lists already.
I chose this return code, because otherwise people would rely on the
loose_route return value true, and forward the message without further
inspection assuming it is in-dialog. And uuuppss you have an open proxy
without knowing ;-)
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.
Indeed. But doesn't that point towards the old behaviour? Only return
true if forwarding can be done based on a Route, otherwise the script
needs to decide what to do based on the Request-URI? Apparently, having
a Route header pointing to the proxy doesn't mean a thing.
BTW: What does loose_route() do if the topmost route doesn't point to
this proxy? But with this
theory we are back to the original topic: is a TEL URI a
local URI or not.
I though that was solved. Only SIP and SIPS URI are allowed in Contact.
Your 2xx ACK will never have a TEL URI (unless the UA is broken in which
case someone should have sent a 400 back). Is just came
to my mind that a possible solution could be to add some
kind of secret information to our Record-Route headers.
/me not like. Sounds like magic plus vendor specific extensions are
frowned upon in SIP.