[Serusers] relaying policy question

[Jiri Kuthan]

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 at mydomain                     |                     x at anydomain
>   |                           | <--INVITE a at mydomain ---  |
>   | <---INVITE--------------- |                           |
>   |                           |                           |
>   | <-----------------200 OK + ACK ------------------->   |
>   |                           |                           |
>   |                           |<--reINVITE a at 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 at iptel.org and I have a permant contact which points to a at 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 at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/