SIPp failing due to unsolicited NOTIFY and OPTIONS messages after registration

[piyer8x8]

Description:

We are encountering failures in SIPp test scenarios due to unsolicited NOTIFY and OPTIONS messages being sent after successful registration.
Observed Behavior:
After SIP registration, server sends NOTIFY messages at exponential intervals (1s, 2s, 4s, 8s...).
The SBC sends OPTIONS messages every 15 seconds.
SIPp terminates the scenario with unexpected message errors, even when these messages are marked as optional.

NOTE: We are using this for Functional Testing so we are limiting the no of messages to 1

sipp <proxy_ip>:<proxy_port>
-sf <scenario_file_path>
-inf <data_file_path>
-i <local_ip>
-p
-au <sip_username>
-ap <sip_password>
-trace_err
-error_file <output_dir>/sipp_uas_trace_errors.log
-trace_msg
-message_file <output_dir>/sipp_uastrace_messages.log
-log_file <output_dir>/sipp_uas_log.txt
-trace_logs
-m 1

Can someone please help on this ?

[orgads]

You can try using -rxsf for the options, if your main script is a client script. See #746.

[piyer8x8]

The issue occurs on the UAS side, not the UAC. We create and use our own UAC and UAS XML scenarios.
SIPp is executed separately for registration and call flows.
For a two-party call:
Each party is assigned its TS IP and port.
Both parties complete registration first.
The call flows run in parallel, with the UAS starting before the UAC.
-m has been removed for UAS, and a completion marker has been added: the last UAS SIP message now triggers a action in the XML, indicating that the UAS has finished processing and can be safely terminated.
We also wanted to check if there is any other better way to handle this.

[orgads]

Can you configure the SBC to use ping for liveness check instead of OPTIONS?

[piyer8x8]

We cannot suppress the NOTIFY and OPTIONS messages at server level, so we need a reliable mechanism to handle them on the script side.
Currently, we handle this by removing -m for the UAS and adding a completion marker, the final UAS SIP message triggers an in the XML that logs completion, allowing us to safely terminate the UAS process.

We wanted to check if there is a better or recommended approach to manage UAS completion in this scenario.