A quick thanks to Olivier and the other maintainers for agreeing to make
me a maintainer - I've found SIPp really useful over the past few
months, and hopefully it can be improved even more. To that end, I've
found an issue I'd like to discuss more widely.
I've been following up on the problem mentioned in
out-of-call scenarios don't work unless the auto-answer option is also set.
It seems that the bug here is a little more interesting: when the
auto-answer option is set, all out-of-call messages are handled by the
default out-of-call scenario file, which responds to everything with a
200 OK. That is - if you send in out-of-call OPTIONS messages (for
example) to a SIPp script which is set to auto-answer, they will get a
200 OK, even though the docs for auto-answer only refer to NOTIFY,
UPDATE and INFO.
The only cases where the actual auto-answer code gets invoked (which
deals exclusively with those three) is when they are received inside an
existing call (or at least I think so from code reading - I haven't
tested this) or if you set an out-of-call scenario file which doesn't
This means that there are at least three bugs here:
* The -aa option doesn't behave as documented - it responds with "200
OK" to all out-of-call messages;
* The -oocs[fn] options don't behave as documented - they have an
undocumented dependency on -aa;
* There's no obvious way to use out-of-call scenarios without also
automatically responding to NOTIFY/UPDATE/INFO, which seem like
logically separate functions.
I can think of a couple of ways to resolve this:
* We decide to live with the current situation, and update the docs to
reflect how these options actually work (as well as adding a check so
that SIPp prints a warning and exits if someone tries to use -oocs[fn]
without -aa). I don't much like this - but perhaps there are arguments
for it I haven't thought of.
* We do away with the auto-answer code, and just rely on out-of-call
scenarios. I thought of this first, but then realised that it couldn't
cover the case where we receive an UPDATE/NOTIFY/INFO within an existing
call, rather than as an out-of-call message. So that also seems wrong.
* We decouple auto-answer from out-of-call scenarios. This actually
looks a bit tricky - as the auto-answer function for out-of-call
scenario messages can only work when you run an out-of-call scenario, so
that call::checkAutomaticResponseMode gets called for that message. And
if you always run a dummy out-of-call scenario file, you'll lose your
ability to discriminate between the E_AUTO_ANSWERED and
E_OUT_OF_CALL_MSGS statistics. But if we only run this dummy scenario
when auto-answer is on and the message is a UPDATE/NOTIFY/INFO message,
that should work. The main issue that I can see here is that the logic
of what messages we auto-answer will be located in two places -
call::checkAutomaticResponseMode and this new bit of code. But that
feels tenable, so this is my preferred option.
I'd like comments for and against the above ideas, and/or better
solutions. If there's a consensus - or if people would like to see the
proposed change before commenting further - I'll probably sort out and
test a patch in the next week or so.