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
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
Thank you Nils. That totally makes sense.
Regards, Paul
On Mon, 28 Mar 2005 14:17:44 +0200, Nils Ohlmeier lists@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
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
Thanks. That make sense.
Regards, Paul
On Mon, 28 Mar 2005 21:42:29 +0200, Jiri Kuthan jiri@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
-
Java Rockx -
Jiri Kuthan -
Nils Ohlmeier