28 Mar
2005
28 Mar
'05
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