Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] uac re-registration #761

Open
jojomay24 opened this issue Sep 30, 2024 · 4 comments
Open

[question] uac re-registration #761

jojomay24 opened this issue Sep 30, 2024 · 4 comments

Comments

@jojomay24
Copy link

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

@orgads
Copy link
Contributor

orgads commented Sep 30, 2024

Hi,

There is an open PR that should support your use-case. See #746

If you're able to build sipp yourself and test this change, this will be appreciated :)

@jojomay24
Copy link
Author

Thank's for the info, I'll let you know

@FabioCalcinelli
Copy link

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!

@jojomay24
Copy link
Author

jojomay24 commented Oct 8, 2024

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants