SIPp
Enable a mixture of server-mode and client-mode operation simultaneously
Source: https://sourceforge.net/p/sipp/mailman/message/28557628/
I'm posting the following modifications in case others have been battling the same sipp limitations as I have.
Background
I've had weeks of battle with SIPP server-mode scripts in an environment where maintaining registration with an SBC is required. Server mode means that you cannot start a script with a 'send' to carry out the registration, so a separate script had to be executed first to do this. Then all sorts of scripting acrobatics were required to maintain a registration (which had a 60 second expiry) and respond to options pings (as used by dynamic HNT to calculate the NAT timeout) during execution.
Additionally running SIP over TCP proved completely impossible for server-mode (terminating party) scenarios - as discussed in a previous mail, our SBC drops the registration as soon as it received a FIN on the TCP session used to register the endpoint, meaning that it was impossible to run a separate client-mode script to register, then a server-mode script to terminate calls without losing our registration when the first script exits.
The obvious solution was to enable SIPP to run in a mixture of client and server mode concurrently.
Solution
The following diff log shows to updates required to do the above. The modifications add two new command line parameters:
-sfrx -snrx
Including either of these at the command line puts SIPP into a mixed mode where it loads two scenarios, the first (specified in -sn or -sf) in client mode, and the second (specified in -snrx or -sfrx) in server mode.
The client mode scenario runs as normal, starting as many calls as specified in the command line parameters -m and -l.
Any unsolicited messages are handled in server mode by the second scenario - spawning a new 'call' to handle each new incoming call-id received as done in normal server mode. The -m and -l call limits are ignored by the second server-mode scenario.
The result is that a client mode scenario file can be specified in -sf to handle registration or make outgoing calls, and a server mode scenario file can simultaneously be specified in -sfrx to terminate multiple incoming calls and handle incoming options pings.
This differs from the OOC scenario allowed previously where all incoming unsolicited messages were handled by the same 'call' irrespective of their call-id, making this option unusable for handling multiple simultaneous incoming calls.
Fixes #745.
I think there may be an issue with the argument parsing? When I invoke this PR with the arguments -sf register.xml -rxsf receiver.xml -trace_err, it produces an error file named (null)_2582295_errors.log, which suggests to me that the scenario name is not being set. Additionally, it logs an unused variable warning from receiver.xml, which has does correctly include a Reference element that should suppress the warning from the dummy value. I have seen this behavior previously when sipp was not operating in the correct mode.
@pwinckles Can you please attach the scripts you test with, if possible also with their other parties?
Rebased and replaced NULL with nullptr. I cannot reproduce your issue. Waiting for inputs.
@orgads I figured out why (null) is appearing in the error log file name. It's because the scenario is parsed when it's constructed, but scenario_file isn't set till after all of the arguments have been parsed. So, if there is an error while parsing the scenario, it ends up in a file with that wonky name.
That aside, there was indeed a legitimate error in the scenario. I fixed it, but haven't finished testing the feature yet.
@orgads Line 2195 in sipp.cpp needs to be changed to:
if (creationMode == MODE_CLIENT || creationMode == MODE_MIXED) {
No registrations go out when I add the -rxsf scenario. Call/message count sits at 0. Assuming there is some problem in my scenario file, no error file was generated by the second scenario even though -trace_err was set. Nor is there any output on screen that could be helpful
The stat file is also strangely named as mentioned above by pwinckles: '(null)_3025435_logs.log'
I ran the UAS second scenario under -sf and SIPp starts in UAS mode fine
@orgads Line 2195 in sipp.cpp needs to be changed to:
if (creationMode == MODE_CLIENT || creationMode == MODE_MIXED) {
Done, thanks.
@dmbhatti I'm really sorry, but I'm short in time to work on this currently. If you're willing to push this forward, do feel free to push a PR.
@orgads thankyou for pushing the latest. My registrations started working after pull. I would love to contribute once I have a decent understanding of the SIPp code base