On Oct 25, 2004 at 15:39, Martin Koenig martin.koenig@toplink-plannet.de wrote:
Hello,
-----Original Message----- From: Andrei Pelinescu-Onciul [mailto:pelinescu-onciul@fokus.fraunhofer.de] Sent: Thursday, October 21, 2004 4:24 PM To: Martin Koenig Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Loose Route
On Oct 21, 2004 at 11:33, Martin Koenig martin.koenig@toplink-plannet.de wrote:
Hello,
If a ser 0.8.14 named "server" receives the following message:
ACK sip:final@destination:5060 SIP/2.0. Route:
sip:route@server:5060;ftag=0006283e0a6800774f26ee45-1c475c78;lr=on.
And loose_route() is called on that server, shouldn't it
return true? Or is
loose_route() only true if there is another Route Header
field left after
removing self?
Yes, it would have been true if there was another route header. In fact loose_route returns true only if the message was "routed" according to the route headers. If there was no change in the message destination (either request uri or the destination uri), it returns false.
To my understanding, loose_route should return true if
there was a Route
header field removed by the function, so that we know we
have reached the
end of a server chain and can t_relay the request without
further local
processing.
If you are at the end of a server chain it will return false, because the message will go to the request uri and not to an uri extracted from a route header.
Okay, I understand. Is there another way to distinguish between a message whose sip-uri should be processed and one that should just be forwarded because it has reached the end of a loose routing signalling chain?
Check if loose_route return false and if there was a Route header present (search() or is_present_hf()). I don't see though why you want to make this distinction between messages at the end of the routing chain and messages without Route. From my point of view they are equivalent (in both cases they must be processed according to the request uri).
The problem is that the R-URI is defined by the end devices contact field and might contain anything, and just using uri==myself to determine whether the request should be forwarded or not opens holes in the design, because the server would basically be an open relay.
I don't understand this either. To deny relaying look at From:. If it has a local domain in it and if you can trust what's in From (e.g. challenge it & check_from()) relay it, if not drop it. You should do this only for the initial message in the dialog (has_to_tag() is false).
Andrei