-
Notifications
You must be signed in to change notification settings - Fork 384
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
Comments
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 :) |
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 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 ( |
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
The text was updated successfully, but these errors were encountered: