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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers