28 Mar
2005
28 Mar
'05
6:48 a.m.
Hi All.
I'm doing some validation checks against my SIP proxy (ser-0.9.1)
using SFTF http://www.sipfoundry.org/sftf/
I'm seeing that some tests are making further through my ser.cfg than I'd like.
For example, SFTF test case214 sends an INVITE message to SER with an
invalid Content-Type header.
SER replies with a 404 User Not Found, which is technically correct,
since the the destination doesn't exist, but SFTF complains that SER
should have returned a 415 Unsupported Media Type error instead.
So my question is this; even though ser rejected the SIP message,
shouldn't it have performed some checks on the message to validate
things like Content-Type, R-URI, etc to make sure the message is not
corrupt or invalid?
If not, does it make sense to do so before letting a SIP message get
too far in to my ser.cfg?
I did find this article in the archives which seems to indicate that
ser should [happliy] ignore things it doesn't understand - but is this
safe?
http://lists.iptel.org/pipermail/serusers/2004-November/013171.html
Regards,
Paul
28 Mar
28 Mar
2:17 p.m.
Hi Paul,
inline.
On Monday 28 March 2005 06:48, Java Rockx wrote:
Hi All.
I'm doing some validation checks against my SIP proxy (ser-0.9.1)
using SFTF http://www.sipfoundry.org/sftf/
I'm seeing that some tests are making further through my ser.cfg than I'd
like.
For example, SFTF test case214 sends an INVITE message to SER with an
invalid Content-Type header.
SER replies with a 404 User Not Found, which is technically correct,
since the the destination doesn't exist, but SFTF complains that SER
should have returned a 415 Unsupported Media Type error instead.
First of all the test are written for UAs and not for proxies. That is the
reason why you get wrong error message about the result.
But everybody is welcome to write proxy tests with/for SFTF.
BTW: SFTF does NOT (yet) implement the SIP Torture Tests (from the Sipping
draft) like you write/assume in the subject. Only a very few SFTF test
messages are inspired by the torture draft.
In this particular case even a proxy should not take care about the
Content-Type, because the participating UAs may successfully use any
Content-Type they may understand, but with is not "supported" by the proxy.
SIP cares only about signlaing not about the media which is negotiated for
this session. (The only exception is if you use a rtpproxy.)
So my question is this; even though ser rejected the
SIP message,
shouldn't it have performed some checks on the message to validate
things like Content-Type, R-URI, etc to make sure the message is not
corrupt or invalid?
If not, does it make sense to do so before letting a SIP message get
too far in to my ser.cfg?
I allways thought about implementing a module which would do some sanity
checks to every incoming request. But these sanity checks would cost a lot of
performance, because you would have to parse a lot more of every request then
what is required to route this request.
On the other side at last the accepting UA should do this sanity check in any
case. So there is no real advantage of doing these checks earlier in the SIP
path. (Although there is currently no easy way to do all the checks which are
required by a SIP proxy according to RFC3261, e.g. Content-Length.)
I did find this article in the archives which seems to
indicate that
ser should [happliy] ignore things it doesn't understand - but is this
safe?
http://lists.iptel.org/pipermail/serusers/2004-November/013171.html
What we discussed in this thread is an absolute basic design principle of SIP:
ignoring of unknown message details.
If a proxy would reject every message with an unknown detail, then every SIP
element on a path from one UA to the other one would had to support this new
message extension. But with this basic SIP design principle every SIP element
can implement future standards without requiring that the hole SIP network
supports this new standard.
Greetings
Nils
2:36 p.m.
Thank you Nils. That totally makes sense.
Regards,
Paul
On Mon, 28 Mar 2005 14:17:44 +0200, Nils Ohlmeier <lists(a)ohlmeier.org> wrote:
Hi Paul,
inline.
On Monday 28 March 2005 06:48, Java Rockx wrote:
Hi All.
I'm doing some validation checks against my SIP proxy (ser-0.9.1)
using SFTF http://www.sipfoundry.org/sftf/
I'm seeing that some tests are making further through my ser.cfg than I'd
like.
For example, SFTF test case214 sends an INVITE message to SER with an
invalid Content-Type header.
SER replies with a 404 User Not Found, which is technically correct,
since the the destination doesn't exist, but SFTF complains that SER
should have returned a 415 Unsupported Media Type error instead.
First of all the test are written for UAs and not for proxies. That is the
reason why you get wrong error message about the result.
But everybody is welcome to write proxy tests with/for SFTF.
BTW: SFTF does NOT (yet) implement the SIP Torture Tests (from the Sipping
draft) like you write/assume in the subject. Only a very few SFTF test
messages are inspired by the torture draft.
In this particular case even a proxy should not take care about the
Content-Type, because the participating UAs may successfully use any
Content-Type they may understand, but with is not "supported" by the proxy.
SIP cares only about signlaing not about the media which is negotiated for
this session. (The only exception is if you use a rtpproxy.)
So my question is this; even though ser rejected
the SIP message,
shouldn't it have performed some checks on the message to validate
things like Content-Type, R-URI, etc to make sure the message is not
corrupt or invalid?
If not, does it make sense to do so before letting a SIP message get
too far in to my ser.cfg?
I allways thought about implementing a module which would do some sanity
checks to every incoming request. But these sanity checks would cost a lot of
performance, because you would have to parse a lot more of every request then
what is required to route this request.
On the other side at last the accepting UA should do this sanity check in any
case. So there is no real advantage of doing these checks earlier in the SIP
path. (Although there is currently no easy way to do all the checks which are
required by a SIP proxy according to RFC3261, e.g. Content-Length.)
I did find this article in the archives which
seems to indicate that
ser should [happliy] ignore things it doesn't understand - but is this
safe?
http://lists.iptel.org/pipermail/serusers/2004-November/013171.html
What we discussed in this thread is an absolute basic design principle of SIP:
ignoring of unknown message details.
If a proxy would reject every message with an unknown detail, then every SIP
element on a path from one UA to the other one would had to support this new
message extension. But with this basic SIP design principle every SIP element
can implement future standards without requiring that the hole SIP network
supports this new standard.
Greetings
Nils
9:42 p.m.
At 06:48 AM 3/28/2005, Java Rockx wrote:
Hi All.
I'm doing some validation checks against my SIP proxy (ser-0.9.1)
using SFTF http://www.sipfoundry.org/sftf/
I'm seeing that some tests are making further through my ser.cfg than I'd like.
For example, SFTF test case214 sends an INVITE message to SER with an
invalid Content-Type header.
SER replies with a 404 User Not Found, which is technically correct,
since the the destination doesn't exist, but SFTF complains that SER
should have returned a 415 Unsupported Media Type error instead.
That's correct. SFTF aims at testing end-devices. proxy servers are not
supposed to process body, 404 is correct answer in this context.
So my question is this; even though ser rejected the
SIP message,
shouldn't it have performed some checks on the message to validate
things like Content-Type, R-URI, etc to make sure the message is not
corrupt or invalid?
no. Extensibility is a feature, not a bug.
If not, does it make sense to do so before letting a
SIP message get
too far in to my ser.cfg?
I did find this article in the archives which seems to indicate that
ser should [happliy] ignore things it doesn't understand - but is this
safe?
A good proxy server should intervene with signaling as litte as it
can.
-jiri
9:50 p.m.
Thanks. That make sense.
Regards,
Paul
On Mon, 28 Mar 2005 21:42:29 +0200, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 06:48 AM 3/28/2005, Java Rockx wrote:
Hi All.
I'm doing some validation checks against my SIP proxy (ser-0.9.1)
using SFTF http://www.sipfoundry.org/sftf/
I'm seeing that some tests are making further through my ser.cfg than I'd like.
For example, SFTF test case214 sends an INVITE message to SER with an
invalid Content-Type header.
SER replies with a 404 User Not Found, which is technically correct,
since the the destination doesn't exist, but SFTF complains that SER
should have returned a 415 Unsupported Media Type error instead.
That's correct. SFTF aims at testing end-devices. proxy servers are not
supposed to process body, 404 is correct answer in this context.
So my question is this; even though ser rejected
the SIP message,
shouldn't it have performed some checks on the message to validate
things like Content-Type, R-URI, etc to make sure the message is not
corrupt or invalid?
no. Extensibility is a feature, not a bug.
If not, does it make sense to do so before letting
a SIP message get
too far in to my ser.cfg?
I did find this article in the archives which seems to indicate that
ser should [happliy] ignore things it doesn't understand - but is this
safe?
A good proxy server should intervene with signaling as litte as it
can.
-jiri
7186
days inactive
7186
days old
4 comments
3 participants
participants (3)
-
Java Rockx -
Jiri Kuthan -
Nils Ohlmeier