What we do is we authenticate all requests with our domain in From which which are not in-dialog. We relax on in-dialog requests (identified by presence of to-tag). We relax on CANCELs and ACKs too -- due to nature of digest authetnication, it makes no sense to challenge them.
-jiri
At 10:44 AM 3/16/2004, Klaus Darilion wrote:
Hi!
I want to prevent my SIP proxy from relaying of SIP messages. Therefore, I will check every request if the request-URI or the from-URI includes my domain and if not, i will refuse the request. This works fine for the first request, but will cause problems with in-dialog requests like in the following scenario.
local UA SIP proxy extern UA a@mydomain | x@anydomain | | <--INVITE a@mydomain --- | | <---INVITE--------------- | | | | | | <-----------------200 OK + ACK -------------------> | | | | | |<--reINVITE a@a-ipaddress--|
---403 relaying forbidden-->The re-INVITE will be rejected as mydomain is not in the req-URI. I could solve this by checking the To: header in the re-INVITE. But this only works if the extern UA calls my SIP proxy directly. If there is another SIP proxy in the way, e.g. the extern UA calls klaus@iptel.org and I have a permant contact which points to a@mydomain, this won't work.
In my opinion, the reINVITE should not traverse the complete routing logic of my SIP proxy but should be processed by the loose_route block - yes, again the same problem :-( . This is the case with requests from Windows Messenger, but not with requests from xlite.
Of course, the same problem occurs with any in-dialog request that isn't processed by the loose_route block (e.g. BYE, INFO...).
A solution would be to check incoming requests if they have an Route: header and allow "relaying" for those requests - but I don't like this solution. Do you have any solutions to this problem?
BTW: How do you handle authentication of BYE, ACK and CANCEL requests. Do you authenticate them? I would propose: BYE: authenticate & challenge ACK: authenticate only; What should I do if the authentication fails, e.g. broken UA? CANCEL: authenticate, send 403 if no credentials are present.
Sorry for asking that much :-) Klaus
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/