[Serusers] SIP Torture Tests Using Sip Foundry SFTF

[Java Rockx]

Thank you Nils. That totally makes sense.

Regards,
Paul


On Mon, 28 Mar 2005 14:17:44 +0200, Nils Ohlmeier <lists at 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
>