Subject: [Sipping] Rationalisation of hostport/usernames in draft-ietf-sipping-tortu re-tests-01

From: Steve Langstaff <[email-masked]>
Date: Tue, 11 Nov 2003 12:26:15 -0000

Hi All.

I am looking at automatic testing of a SIP implementation, and although
draft-ietf-sipping-torture-tests-01 says...

   "This document does not, however, attempt to be comprehensive. It should
be
   considered a seed to stimulate thinking and planning, not simply a
   set of tests to be passed."

...I was wondering if there were any reasons not to rationalise the test
messages in a number of ways:

1) There appear to be a large number of different host names present in the
test messages where surely only a few are needed, e.g.
	c.example.com
	example.com
	example.org
	example53.example.net
	fold-and-staple.example.com
	funky.example.com
	host-of-the-hour.example.com
	host.example.com
	host.example.net
	host1.examle.com
	host1.example.com
	host1.example.net
	host129.example.com
	host15.example.net
	host25.example.net
	host39923.example.net
	host4.example.com
	host5.example.com
	host5.example.net
	host59.example.net
	host9.example.com
	hungry.example.net
	iftgw.example.com
	saturn.example.com
	somehost.example.com
	t1.example.com

2) Shouldn't the call-ids be unique between messages, except where we are
specifically testing call-id issues? This would help us associate response
messages with the appropriate test message.

3) Could the URI always be [email-masked]' except where we are
specifically testing URI issues? This would simplify the configuration of
the device under test.

4) Ditto the To: ([email-masked]') and From: ([email-masked]')
headers?

5) The SDP o= and c= parameters mention about 7 different IP addresses.
Could this be rationalised down to one?

Thanks for any feedback,

-- 
Steve Langstaff. 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP