mixed mode #745
Comments
orgads
pushed a commit
to orgads/sipp
that referenced
this issue
Sep 7, 2024
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
pushed a commit
to orgads/sipp
that referenced
this issue
Sep 7, 2024
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
pushed a commit
to orgads/sipp
that referenced
this issue
Sep 7, 2024
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
pushed a commit
to orgads/sipp
that referenced
this issue
Sep 7, 2024
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
pushed a commit
to orgads/sipp
that referenced
this issue
Sep 7, 2024
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.
|
Pushed as #746. Please give it a try. |
|
Thank you so much! I will test it tomorrow. |
orgads
pushed a commit
to orgads/sipp
that referenced
this issue
Sep 15, 2024
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I need to run a scenario that maintains a registration while also listening for incoming calls. We had been using a very old version with a patch applied that allowed two scenarios to be specified and it would run in "mixed mode". In order to upgrade to the latest, unpatched version, I attempted to convert the distinct register and receive scenarios that we had been using into a single scenario, using some branching trickery. However, I'm unable to get it working, and I assume it's because the scenario is running in client mode (because the first command is a register), which doesn't allow for using server
recv requestcommands.Is there anyway to get this to work without a sipp code change? If not, is there any interest in officially adding that functionality from old patch I linked to above?
The text was updated successfully, but these errors were encountered: