[Serusers] relaying policy question

[Klaus Darilion]

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