Enable a mixture of server-mode and client-mode operation simultaneously #746

orgads · 2024-09-07T20:30:13Z

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.

src/sipp.cpp

src/socket.cpp

+            /* Ignore quitting for now ... as this is triggered when all tx calls are active
+            if (quitting >= 1) {
+                CStat::globalStat(CStat::E_OUT_OF_CALL_MSGS);
+                TRACE_MSG("Discarded message for new calls while quitting\n");
+                return;
+            }
+            */


orgads · 2024-09-08T12:00:29Z

@pwinckles can you please give it a try?

pwinckles · 2024-09-09T14:39:27Z

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.

orgads · 2024-09-15T18:58:18Z

@pwinckles Can you please attach the scripts you test with, if possible also with their other parties?

orgads · 2024-09-15T19:51:21Z

Rebased and replaced NULL with nullptr. I cannot reproduce your issue. Waiting for inputs.

pwinckles · 2024-09-16T19:18:53Z

@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 · 2024-09-16T19:23:03Z

I see. Thanks for the information.

pwinckles · 2024-09-17T20:51:33Z

@orgads Line 2195 in sipp.cpp needs to be changed to:

if (creationMode == MODE_CLIENT || creationMode == MODE_MIXED) {

dmbhatti · 2025-01-27T14:59:50Z

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 · 2025-01-27T15:05:31Z

@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.

dmbhatti · 2025-01-27T18:12:53Z

@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

Copilot

Pull Request Overview

This PR implements support for running SIPp in a mixed mode where both client-mode and server-mode scenarios can execute simultaneously. This addresses the need to maintain SIP registrations while handling incoming calls, particularly important for SIP over TCP environments where separate client/server processes would lose registration upon connection termination.

Key changes include:

Addition of new command line options -rxsf and -rxsn for specifying receive scenarios
Implementation of MODE_MIXED creation mode alongside existing client/server modes
Refactoring of scenario and file path management to support multiple scenarios

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
`src/sipp.cpp`	Adds new command line options, mixed mode logic, and refactors scenario initialization
`src/socket.cpp`	Updates message processing to handle mixed mode with separate rx_scenario
`src/scenario.cpp`	Adds scenario file name management and mixed mode detection
`src/call.cpp`	Updates call constructors to accept scenario parameter
`src/screen.cpp`	Adds display logic for mixed mode scenarios
`src/actions.cpp`	Updates file path resolution to use scenario-specific paths
`src/fileutil.c`	Removes global scenario_path dependency in favor of parameter-based approach
`src/send_packets.c`	Updates function signature to accept basepath parameter
`include/*.hpp`	Header updates for new mixed mode constants and function signatures

src/sipp.cpp

src/screen.cpp

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 SIPp#745.

orgads force-pushed the mixed-mode branch 4 times, most recently from 76eb2f1 to c61d627 Compare September 7, 2024 20:34

github-advanced-security bot found potential problems Sep 7, 2024

View reviewed changes

orgads force-pushed the mixed-mode branch from c61d627 to c554a7b Compare September 7, 2024 20:59

orgads mentioned this pull request Sep 8, 2024

mixed mode #745

Closed

orgads force-pushed the mixed-mode branch from c554a7b to 368ba0a Compare September 15, 2024 19:45

orgads added the request-feedback label Sep 15, 2024

orgads requested review from lemenkov and wdoekes September 15, 2024 19:51

orgads mentioned this pull request Sep 30, 2024

[question] uac re-registration #761

Open

orgads removed the request-feedback label Nov 7, 2024

orgads force-pushed the mixed-mode branch from 368ba0a to fab4019 Compare January 27, 2025 15:04

orgads requested a review from Copilot August 7, 2025 20:11

Copilot AI reviewed Aug 7, 2025

View reviewed changes

src/sipp.cpp Outdated Show resolved Hide resolved

src/sipp.cpp Outdated Show resolved Hide resolved

src/screen.cpp Outdated Show resolved Hide resolved

orgads force-pushed the mixed-mode branch from fab4019 to 1e603e3 Compare August 8, 2025 04:23

orgads merged commit 663cc0a into SIPp:master Aug 8, 2025
7 checks passed

orgads deleted the mixed-mode branch August 8, 2025 04:23

orgads mentioned this pull request Nov 13, 2025

SIPp failing due to unsolicited NOTIFY and OPTIONS messages after registration #814

Open

Enable a mixture of server-mode and client-mode operation simultaneously #746

Enable a mixture of server-mode and client-mode operation simultaneously #746

Uh oh!

Conversation

orgads commented Sep 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

Solution

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Check notice

orgads commented Sep 8, 2024

Uh oh!

pwinckles commented Sep 9, 2024

Uh oh!

orgads commented Sep 15, 2024

Uh oh!

orgads commented Sep 15, 2024

Uh oh!

pwinckles commented Sep 16, 2024

Uh oh!

orgads commented Sep 16, 2024

Uh oh!

pwinckles commented Sep 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dmbhatti commented Jan 27, 2025

Uh oh!

orgads commented Jan 27, 2025

Uh oh!

dmbhatti commented Jan 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

orgads commented Sep 7, 2024 •

edited

Loading

pwinckles commented Sep 17, 2024 •

edited

Loading

dmbhatti commented Jan 27, 2025 •

edited

Loading