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/ ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
