[Serusers] SIP Torture Tests Using Sip Foundry SFTF

[Nils Ohlmeier]

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