16 Mar
2004
16 Mar
'04
11:44 a.m.
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
17 Mar
17 Mar
3:39 p.m.
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(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?
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
4:25 p.m.
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
--
Jiri Kuthan http://iptel.org/~jiri/
7558
days inactive
7559
days old
2 comments
3 participants
participants (3)
-
Jiri Kuthan -
Klaus Darilion -
Nils Ohlmeier