Enable a mixture of server-mode and client-mode operation simultaneously #746
Conversation
orgads
force-pushed
the
mixed-mode
branch
4 times, most recently
from
76eb2f1 to
c61d627
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| /* 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; | ||
| } | ||
| */ |
Check notice
Code scanning / CodeQL
Commented-out code Note
|
@pwinckles can you please give it a try? |
|
I think there may be an issue with the argument parsing? When I invoke this PR with the arguments |
|
@pwinckles Can you please attach the scripts you test with, if possible also with their other parties? |
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.
|
Rebased and replaced |
|
@orgads I figured out why That aside, there was indeed a legitimate error in the scenario. I fixed it, but haven't finished testing the feature yet. |
|
I see. Thanks for the information. |
|
@orgads Line 2195 in sipp.cpp needs to be changed to: |
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.