[Serusers] relaying policy question

[Nils Ohlmeier]

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 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?

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