Open jojomay24 opened 2 months ago
Hi,
There is an open PR that should support your use-case. See https://github.com/SIPp/sipp/pull/746
If you're able to build sipp yourself and test this change, this will be appreciated :)
Thank's for the info, I'll let you know
Hi @orgads , I am also trying to use your SIPp version, but I am running into a problem.
Basically, I can run SIPp regularly, but the moment I add a secondary scenario file with the command line options -rxsf server_scenario_file.xml -rxinf server_injection_file.csv
, the primary scenario file is not executed anymore.
I see the "Scenario Screen", and the structure of the primary .xml file shown there is correct, but there are 0 calls being performed. Do you have any idea what the problem could be?
I can show you the .xml files if needed, but they are all very basic, and as I said, they work perfectly well until I try to combine them in mixed mode.
Thanks!
Hi @orgads , I can confirm what @FabioCalcinelli commented. As soon as I add the rxsf scenario, no calls are generated anymore (sipp -r 1 -rxsf uas2.xml -sn uac 127.0.0.1
). Any Ideas? Would be very appreciated since I am still very interested in this feature :)
Hi
I'd like to create many short sip calls (~1 minute) over a period of 24 hours against a sip server. The sip server requires registration, which needs to be renewed in certain time intervals. I was planning to have 1 scenario file doing only registrations ( REGISTER, PAUSE, RE-REGISTER loop) and 1 scenario file doing the actual calls (INVITE,...,BYE). However, this turned out not to be possible since the source port of the sipp registration process differs from the source port of the call process and my sip server requires them to be identical. Consequently the INVITES are rejected.
Then I tried to build my uac scenario in a way such that at the beginning, there is a check if enough time has passed so that a re-registration is necessary. And if yes, a registration flow is prepended before the actual INVITE. However, this also does not seem like a good idea because sip rfc 3261 states "All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar". Since sipp creates the call-id by itself, I don't see any way to reuse the call-id from the inital register. sipp wouldn't be able to relate the REGISTER response messages to the REGISTER event.
So my question is: Do I oversee something, or is it indeed not possible with sipp to create sip calls against a sip server requiring REGISTER and INVITE coming from the same source port?
Thank's