Henning Schulzrinne wrote:
>
> Based on a suggestion and experience at the last bake-off, it might make
> sense to get together a group of people for doing a bit more advance
> planning of the technical aspects of the next bake-off, in particular
> since the bake-off organizer is not a SIP implementor. What I'd like to
> do include:
>
> - identify test scenarios and participants ahead of time, rather than by
> PA system at the event...
>
> - classify participants into groups, as in Chicago
>
> - set up a torture test station for "weird" messages (*)
>
> - set up a basic message flow test, as in INVITE-200-ACK (*)
>
> (*) One could argue that folks should do these ahead of time, since they
> don't really need a bake-off and not passing these just wastes the time
> of other, better-prepared participants. Maybe there should be an
> informal commitment to at least pass these before signing up?
I think this is acceptable. I wouldn't want to discourage first
timers but these basic tests are not too difficult to run
beforehand. We could even make some basic software to spit out
test messages based on the existing text files freely available.
Of course you can always just cut and paste them into telnet if
you support TCP. There are also test UAs now freely available
(not that they can guarantee interoperability within anyone else,
or indeed the spec, of course).
> These are only random suggestions, so I'd welcome your input. However,
> at this time, I'd particularly like to assemble a group of people that
> can serve as the "technical program committee" for the event.
>
> Comments?
In keeping with the spirit of the bakeoffs it should not be done
for any perceived commercial advantage. Could this be arranged
under the auspices of individuals coming together under
sipbakeoff.org rather than employees of commercial entities? It
would be nice it this work could be grown into the basis of the
self-certification program you have referred to with test
messages, call flows etc being published within the IETF. I would
be happy to help, particularly on the side of trying to set up
more taxing scenarios for proxies.
Cheers,
Neil
--
Ubiquity Software Corporation, UK
http://www.ubiquity.net
