Hello Klaus,

On Tuesday 16 March 2004 10:44, Klaus Darilion wrote:

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?

i think there are three different scenarios possible: - the request uri contains your proxy address (either because the request is directly targeted to your proxy, or because the request was strict routed to your proxy) - a Route is present and contains your proxy address as next hop - you can reject the request because non of the both above is true

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.

I think checking the authentication of ACKs and CANCELs does not make much sence, because, at least for for CANCELs, your are not allowed to challenge them (I'm not sure about ACKs). And as ACKs and CANCELs have to look as original INVITE you should be able to apply the same rules for them as above.

Maybe i oversaw something.

Greetings Nils