RE: [Sipping] Testing the water: A transaction torture-tests draft

This will be useful.  One more tool I found pretty useful is, SFTF from
SIPFoundary.  

http://www.sipfoundry.org/sip-forum-test-framework/sip-forum-test-framework-
sftf.html

I can create most of the out of sequence call flows, generating such test
cases and so on.

Thanks,
Neel

> -----Original Message-----
> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf
> Of Byron Campen
> Sent: Tuesday, May 15, 2007 9:44 AM
> To: Gonzalo Camarillo
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] Testing the water: A transaction torture-tests
> draft
> 
> 	This is mostly Dialog-related weirdness (although there are a few
> transaction-level cases here). Most of the examples are things that
> can arise accidentally between compliant endpoints. I was thinking a
> draft that would focus exclusively on transaction-level cases,
> including cases where there is a broken/malicious endpoint sending
> complete garbage. (For instance, ACK in a NIT, response to an ACK,
> sending provisionals after a final response, mixed final responses,
> an INVITE collides with a previous ACK/200's transaction id, etc)
> 
> Best regards,
> Byron Campen
> 
> > Hi Byron,
> >
> > are you thinking of something similar to the draft below?... or
> > something else?
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-sipping-race-
> > examples-01.txt
> >
> > Cheers,
> >
> > Gonzalo
> >
> >
> > Byron Campen wrote:
> >>     I was thinking a torture-tests draft in the same spirit as RFC
> >> 4475 and draft-ietf-sipping-ipv6-torture-tests; an enumeration of
> >> test-cases that could cause trouble for an unsuspecting
> >> implementation, with exposition on what makes the case
> >> interesting, and how implementations should react. Of course, the
> >> tests themselves would read differently, since the contents of the
> >> messages won't matter apart from stuff like the method and branch
> >> params.
> >> Best regards,
> >> Byron Campen
> >>>    From: Byron Campen <bcampen@estacado.net>
> >>>
> >>>    I have doing a lot of work lately on hardening a SIP stack, and I
> >>>    have repeatedly come across bugs triggered not by syntactic
> >>> garbage
> >>>    (malformed header-field-values and the like), but by semantic
> >>>    garbage, usually in the form of transaction collisions. I'm
> >>> trying
> >>>    to get a feel for working-group interest on the subject, so
> >>> let me
> >>>    know what you think.
> >>>
> >>> It's obviously very valuable work.  What are you proposing?
> >>>
> >>> Dale
> >>>
> >>>
> >>> _______________________________________________
> >>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>> This list is for NEW development of the application of SIP
> >>> Use sip-implementors@cs.columbia.edu for questions on current sip
> >>> Use sip@ietf.org for new developments of core SIP
> >> ---------------------------------------------------------------------
> >> ---
> >> _______________________________________________
> >> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sip@ietf.org for new developments of core SIP
> >

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP