[Sipp-devel] Bug (& patch proposal): Auto-answer and out-of-call scenarios interact in unexpected ways

[Rob D. <rk...@rk...>]

Hi all,

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 
https://sourceforge.net/mailarchive/message.php?msg_id=29119564, where 
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 
recognise them.

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.

Best,
Rob

--
Rob Day
https://github.com/rkd91
https://sourceforge.net/users/arcady-91
http://rkd.me.uk/