You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(31) |
Jun
(41) |
Jul
(59) |
Aug
(39) |
Sep
(41) |
Oct
(36) |
Nov
(38) |
Dec
(65) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(39) |
Feb
(78) |
Mar
(68) |
Apr
(69) |
May
(83) |
Jun
(113) |
Jul
(113) |
Aug
(122) |
Sep
(77) |
Oct
(91) |
Nov
(61) |
Dec
(58) |
2006 |
Jan
(94) |
Feb
(139) |
Mar
(230) |
Apr
(126) |
May
(126) |
Jun
(124) |
Jul
(127) |
Aug
(140) |
Sep
(150) |
Oct
(183) |
Nov
(174) |
Dec
(127) |
2007 |
Jan
(132) |
Feb
(99) |
Mar
(150) |
Apr
(98) |
May
(154) |
Jun
(156) |
Jul
(96) |
Aug
(126) |
Sep
(109) |
Oct
(123) |
Nov
(130) |
Dec
(52) |
2008 |
Jan
(109) |
Feb
(93) |
Mar
(83) |
Apr
(70) |
May
(113) |
Jun
(78) |
Jul
(155) |
Aug
(115) |
Sep
(106) |
Oct
(172) |
Nov
(119) |
Dec
(116) |
2009 |
Jan
(104) |
Feb
(102) |
Mar
(116) |
Apr
(127) |
May
(78) |
Jun
(74) |
Jul
(99) |
Aug
(97) |
Sep
(66) |
Oct
(57) |
Nov
(73) |
Dec
(38) |
2010 |
Jan
(63) |
Feb
(31) |
Mar
(40) |
Apr
(52) |
May
(34) |
Jun
(40) |
Jul
(120) |
Aug
(30) |
Sep
(28) |
Oct
(57) |
Nov
(22) |
Dec
(36) |
2011 |
Jan
(32) |
Feb
(67) |
Mar
(115) |
Apr
(67) |
May
(81) |
Jun
(29) |
Jul
(78) |
Aug
(42) |
Sep
(29) |
Oct
(48) |
Nov
(35) |
Dec
(41) |
2012 |
Jan
(28) |
Feb
(18) |
Mar
(28) |
Apr
(16) |
May
(54) |
Jun
(14) |
Jul
(8) |
Aug
(12) |
Sep
(15) |
Oct
(8) |
Nov
(1) |
Dec
(19) |
2013 |
Jan
(24) |
Feb
(36) |
Mar
(39) |
Apr
(28) |
May
(21) |
Jun
(27) |
Jul
(15) |
Aug
(1) |
Sep
(21) |
Oct
(51) |
Nov
(37) |
Dec
(16) |
2014 |
Jan
(45) |
Feb
(50) |
Mar
(44) |
Apr
(62) |
May
(25) |
Jun
(29) |
Jul
(95) |
Aug
(12) |
Sep
(43) |
Oct
(41) |
Nov
(28) |
Dec
(26) |
2015 |
Jan
(1) |
Feb
(22) |
Mar
(26) |
Apr
(14) |
May
(17) |
Jun
(12) |
Jul
(5) |
Aug
(6) |
Sep
(16) |
Oct
(13) |
Nov
(14) |
Dec
(25) |
2016 |
Jan
(25) |
Feb
(9) |
Mar
(36) |
Apr
(9) |
May
(1) |
Jun
(12) |
Jul
(17) |
Aug
(29) |
Sep
(7) |
Oct
(25) |
Nov
(23) |
Dec
(8) |
2017 |
Jan
(12) |
Feb
(13) |
Mar
(11) |
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(11) |
Sep
(2) |
Oct
(10) |
Nov
(46) |
Dec
(3) |
2018 |
Jan
(5) |
Feb
(2) |
Mar
(21) |
Apr
(7) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(4) |
Oct
(10) |
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(8) |
May
(4) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(5) |
2020 |
Jan
(2) |
Feb
(1) |
Mar
(12) |
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(3) |
Oct
(14) |
Nov
(3) |
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
(3) |
Mar
(2) |
Apr
(3) |
May
(4) |
Jun
|
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(2) |
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Shailendra P. <bei...@gm...> - 2022-04-20 12:32:48
|
Hello, I'm trying to send multiple calls to my Asterisk Instance(Asterisk 19.2.1). I have created the UAC XML from the requests logged by Asterisk when communicating with a softphone. However when I trigger this, I see Asterisk responding to all of these requests with 401 status. What should I change here to successfully trigger calls to Asterisk? I have not masked any IP or numbers here since these computers are only accessible from my local network. SIPp command, ``` sipp -sf Basic/uac.xml asterisk-dev ``` uac.xml ```xml <?xml version="1.0" encoding="UTF-8" ?> <scenario name="Basic UAC scenario"> <send> <![CDATA[ INVITE sip:100@asterisk-dev SIP/2.0 Via: SIP/2.0/UDP 100.103.250.60:50906 ;rport;branch=z9hG4bKPjb0kGNfULZnPtVspABKIkmekflf3zPKk1 Max-Forwards: 70 From: "shai" <sip:6001@asterisk-dev >;tag=6ukVZBwnfdB7Ae95nE.EtAF6MaA9I43m To: sip:100@asterisk-dev Contact: <sip:6001@100.103.250.60:50906;ob> Call-ID: i1XKt0o6WzopIEc4oTwEnz3zxjemmI8s CSeq: 6001 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, norefersub User-Agent: Telephone 1.5.2 Authorization: Digest username="6001", realm="asterisk", nonce="1650456215/33cf144cc5c0370a2d355d070f987efd", uri="sip:100@asterisk-dev", response="bf3337f5c8edd5c6506e42225ed4bc35", algorithm=md5, cnonce="LvE3CsEAXJMJlFszvDDEVaLHwfKhseD4", opaque="4a7e2ea9085ffb42", qop=auth, nc=00000001 Content-Type: application/sdp Content-Length: 483 v=0 o=- 3859445015 3859445015 IN IP4 100.103.250.60 s=pjmedia b=AS:117 t=0 0 a=X-nat:0 m=audio 4006 RTP/AVP 96 9 8 0 101 102 c=IN IP4 100.103.250.60 b=TIAS:96000 a=rtcp:4007 IN IP4 100.103.250.60 a=sendrecv a=rtpmap:96 opus/48000/2 a=fmtp:96 useinbandfec=1 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/48000 a=fmtp:101 0-16 a=rtpmap:102 telephone-event/8000 a=fmtp:102 0-16 a=ssrc:1512283992 cname:785442ca63ed197d ]]> </send> <recv response="100" optional="true"> </recv> <recv response="180" optional="true"> </recv> <recv response="200"> </recv> <send> <![CDATA[ ACK sip:100.69.169.87:5060 SIP/2.0 Via: SIP/2.0/UDP 100.103.250.60:50906 ;rport;branch=z9hG4bKPjB20rSWAebAkr8Vr9lHsKTkGr84MrCahP Max-Forwards: 70 From: "shai" <sip:6001@asterisk-dev >;tag=6EVN12veK30DOeBFZ9mB7a9o9HCaI1X6 To: sip:100@asterisk-dev;tag=33b584f6-5849-4020-bf16-6ea0296e38ae Call-ID: 8LT92XH8Qf8ZZSebCulkuOwdngQTpbF- CSeq: 14242 ACK Content-Length: 0 ]]> </send> <pause milliseconds="5000"/> <send retrans="500"> <![CDATA[ BYE sip:100.69.169.87:5060 SIP/2.0 Via: SIP/2.0/UDP 100.103.250.60:50906 ;rport;branch=z9hG4bKPjtpJP7zMUrJixyy-QHRk79pmcKQlFTVzL Max-Forwards: 70 From: "shai" <sip:6001@asterisk-dev >;tag=6EVN12veK30DOeBFZ9mB7a9o9HCaI1X6 To: sip:100@asterisk-dev;tag=33b584f6-5849-4020-bf16-6ea0296e38ae Call-ID: 8LT92XH8Qf8ZZSebCulkuOwdngQTpbF- CSeq: 14243 BYE User-Agent: Telephone 1.5.2 Content-Length: 0 ]]> </send> <recv response="200"> </recv> </scenario> ``` Asterisk response, ``` <--- Transmitting SIP response (568 bytes) to UDP:100.103.250.60:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 100.103.250.60:50906 ;rport=5060;received=100.103.250.60;branch=z9hG4bKPjb0kGNfULZnPtVspABKIkmekflf3zPKk1 Call-ID: i1XKt0o6WzopIEc4oTwEnz3zxjemmI8s From: "shai" <sip:6001@asterisk-dev>;tag=6ukVZBwnfdB7Ae95nE.EtAF6MaA9I43m To: <sip:100@asterisk-dev>;tag=z9hG4bKPjb0kGNfULZnPtVspABKIkmekflf3zPKk1 CSeq: 6001 INVITE WWW-Authenticate: Digest realm="asterisk",nonce="1650456365/6f4af806234d2a4690cdc945b0903a31",opaque="2683948a0d25bcd3",stale=true,algorithm=md5,qop="auth" Server: Asterisk PBX 19.2.1 Content-Length: 0 ``` Thanks |
From: Jeannot L. <Jea...@mi...> - 2022-04-15 05:05:33
|
Hello: As I'm using SIPP 3.6 I'm seeing this error frequently on the UAC side of scenarios -- maybe about 50% of the time when using TCP (-t t1): " The following events occurred: 2022-04-14 22:31:12.442122 1649989872.442122: Unable to connect a TCP socket. Use 'sipp -h' for details, errno = 99 (Cannot assign requested address) " "Cannot assign requested address" -- what does this means exactly? Any pointers on how I could find out? Thanks! -- Jeannot Langlois Software Developer SIP Inspector RFC Lawyer Refactoring Expert MiVoice Border Gateway Development Mitel Networks 4000 Innovation Drive Kanata (Ontario) K2K 3K1 http://www.mitel.com "Never give in, never give in, never, never, never, never. In nothing, great or small, large or petty. Never give in except to convictions of honor and good sense." - Winston Churchill "Can I get an update on issue X? Did you fix issue X in stream Y?" [https://mitel.atlassian.net/issues/?filter=17325] "When is MBG version X planned for GA? Will it include fix Y?" [https://mitel.atlassian.net/wiki/spaces/MBG/pages/5588287492/Project+Dashboard] ________________________________ NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message. |
From: sajjad p. <spu...@ya...> - 2022-03-26 14:21:42
|
I have read these emails and I would like to have "SIPp_IPSEC_patched_with_KeyExpansion.tar". Does anybody have this file? If you could send me this file, I would be very grateful. -------------------------------------------------- kind regards; Sajad Pourmohseni |
From: Kanishk J. <kan...@ec...> - 2022-03-15 07:33:06
|
Hello Experts, PFA to see the screenshots of the errors I am trying to set a custom IP address in the from header using the parameter -i in the sipp script The command that i used is this "sipp 10.1.3.12:5060 -sf /sipp-msrp-originate.xml -cid_str 1337327b-e10a-4df3-98c8-ec8c49529ff4 -m 1 -t t1 -i 10.1.2.228" Here 10.1.3.12 is my remote IP address(which is also my local IP) and in *-i* i am trying to put some random IP address so that it can be used in the from header but i am getting this error " Unable to bind main socket, errno = 99 (Cannot assign requested address)" NOTE - u can check the error1 screenshot in the attachments for more details Then i added the flag -bind_local to bind the port with the local address . For the i tried two commands 1) "sipp 10.1.3.12:5060 -sf /sipp-msrp-originate.xml -cid_str 1337327b-e10a-4df3-98c8-ec8c49529ff4 -m 1 -t t1 -i 10.1.2.228 -bind_local" 2) "sipp 10.1.3.12:5060 -sf /sipp-msrp-originate.xml -cid_str 1337327b-e10a-4df3-98c8-ec8c49529ff4 -m 1 -t t1 -i 10.1.2.228 -bind_local 10.1.3.12" But even after using this i got the same error as before NOTE- For more details u can check the error2 and error3 screenshot in attachments Please tell me how can i provide custom ip address in the from header and also the usage of *-ci *tag in sipp tool Warm Regards, Kanishk Jain -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems. |
From: Rob S. <rsi...@gm...> - 2022-02-25 16:02:20
|
Hi, I am setting up a very basic SIP lab. I have Asterisk running and I am learning how to work with it. I have successfully been able to have 1 SIP phone (Android Zoiper client) call another Zoiper client on the same LAN. One of the Zoiper client's IP Address is 192.168.0.187 and its 4 digit extension is 7002. I'm trying to get SIPp to make a test call to this SIP extension. The IP address of the Linux server running SIPp is 192.168.0.180. When I run this SIPp command sipp -sn uac -m 1 192.168.0.187 -s 7002 and setup a wireshark capture, I get this result: Any suggestions how I can get this to work? I can't figure out why I get a PING failure when the SIP client (.187) tried to respond to the server running SIPp (.180). All I am trying to do at this point is to get SIPp to call a SIP client whose IP address is 192.168.0.187. -- Thanks, Rob S |
From: Olivier T. <oli...@gm...> - 2022-02-16 16:28:11
|
Hello guys, Do you know if it is possible to provide a SIPp scenario with a unix variable? In fact, I would like to do something like that: <exec rtp_stream="$HOME/audio/f1_alaw_enc.wav,-1"/> with $HOME = /home/<username> Thanks a lot for your help ! Best regards, Olivier T. |
From: Anton V. <ant...@no...> - 2022-02-13 17:05:54
|
Hello SIPP users, For testing proposes I have to develop a SIPP scenario to simulate SIPREC recording, but I haven't found a way to send two RTP steams using SIPP. It seems like the tool allows to fork just one RTP steam. Am I wrong? Is there a way to send two RTP streams? Thanks, Anton Voylenko |
From: Rouben B. <rou...@or...> - 2022-01-11 03:47:19
|
Hi all, Please instruct how to force SIPp to use TLS 1.2 and Diffie Helman with key size 2048 instead of TLS 1.0 And key size 1024. Thank you. Rouben |
From: Walter D. <wal...@wj...> - 2021-10-26 08:59:28
|
Good day dear SIPp users, I've drafted two new release candidates: - 3.6.2~rc1 - 3.7.0~rc1 They can be found here: - https://github.com/SIPp/sipp/releases - https://github.com/SIPp/sipp/releases/download/v3.6.2_rc1/sipp-3.6.2.rc1.tar.gz - https://github.com/SIPp/sipp/releases/download/v3.7.0_rc1/sipp-3.7.0.rc1.tar.gz The 3.6.2 version contains bug fixes and some code/documentation cleanups. The 3.7.0 version additionally contains some new features: - B2BUA Media Gateway RTP/SRTP bit pattern testing. - URL encode/decode <action> for scenarios. - Variables in the rtpstream/pcap filenames. - WolfSSL/WolfCrypt library support. Please try them any report any issues on GitHub. Happy SIPping! Walter Doekes OSSO B.V. |
From: Jaime J. M. <ma...@ho...> - 2021-08-05 00:51:19
|
Hello, I am using sipp to test a remote system that does not support PRACK but the sipp connection to the network enforces PRACK which causes inconsistent message sequences for the 200 OK PRACK and 200 OK INVITE. My script is the UA client for this call. I have created a pseudo loop to process the out of order 200 OK PRACK messages but it fails to process the messages in the right sequence or the retransmitted 200 OK INVITE that is received after the 200 OK PRACK(s). Here is a portion of the script in question: <label id=“WAIT4PRK200” /> <recv response=“200” > <action> <ereg regex=“([0-9]+) (.*)” search_in=“hdr” header=“CSeq: “ assign_to=“dummy, seqNum, seqMethod” /> <strcmp assign_to=“match” variable=“seqNum” value=“3” /> <test assign_to=“seqPass” variable=“match” “compare=“less_than” value=“3” /> </action> </recv> <nop next=“WAIT4PRK200” test=“seqPass” /> <nop next=“WAIT4ANS” /> ... <label id=“WAIT4ANS” /> <recv response=“200” /> ... The code above works for handling the 200 OK PRACK, in sequence or out of sequence; but it fails when processing the 200 OK INVITE as it declares it an Unexpected message. Why is that? Thanks, Maizo |
From: Nagy A. <ak...@fr...> - 2021-07-22 09:06:10
|
Hello Pavel, thank you very much for reply and suggestion. Indeed that was to problem! Port 3000 UDP packets were recognized as DIS protocol instead of SIP. There is an option to disable DIS (or reconfigure DIS default protocol), which solved the issue. After disabling the DIS in Wireshark, Wireshark shows all the UDP packets from SIPp properly as SIP messages. Have a nice day and regards,Akos "Šindelka Pavel" <sin...@tt...> írta: > That sounds more like a Wireshark configuration issue, where heuristics or static port assignment chooses to dissect the packet contents as DIS rather than SIP. Do you use standard SIP ports (5060) in your test setup? What have the "misinterpreted" packets have in common that differs from what the "properly interpreted" packets have in common? Try to disable DIS in supported protocols of Wireshark and see whether it helps. P. Dne 21.07.2021 v 14:20 Nagy Akos napsal(a): >Hello dear SIPp experts, I didn't found any related thread in the archive, so I'm asking: we got a proper working SIPp generator on CentOS - connected to a SBC (Session Border Controller). With different scenarios working okay. SIPp logs (-trace_msg) are all fine. But if I capture with tcpdump -i any -s 0 -w /tmp/capture.cap: the capture is strange sometimes. Some messages appear as proper SIP messages, but some appear as "DIS (Distributed Interactive Simulator) protocol" messages - as the Wireshark shows it. Any suggestion? (We don't use TLS, obviously.) (Due to company secrecy, I'm not allowed to attach capture.) (I know, we can work with the SIPp log files, -trace_msg. But since we highly used to work with captures, it's easier and more comfortable for us to work with captures.) ;Thanks in advance and regards,Akos Nagy _______________________________________________ Sipp-users mailing list Sip...@li... https://lists.sourceforge.net/lists/listinfo/sipp-users That sounds more like a Wireshark configuration issue, where heuristics or static port assignment chooses to dissect the packet contents as DIS rather than SIP. Do you use standard SIP ports (5060) in your test setup? What have the "misinterpreted" packets have in common that differs from what the "properly interpreted" packets have in common? Try to disable DIS in supported protocols of Wireshark and see whether it helps. P. Dne 21.07.2021 v 14:20 Nagy Akos napsal(a): Hello dear SIPp experts, I didn't found any related thread in the archive, so I'm asking: we got a proper working SIPp generator on CentOS - connected to a SBC (Session Border Controller). With different scenarios working okay. SIPp logs (-trace_msg) are all fine. But if I capture with tcpdump -i any -s 0 -w /tmp/capture.cap: the capture is strange sometimes. Some messages appear as proper SIP messages, but some appear as "DIS (Distributed Interactive Simulator) protocol" messages - as the Wireshark shows it. Any suggestion? (We don't use TLS, obviously.) (Due to company secrecy, I'm not allowed to attach capture.) (I know, we can work with the SIPp log files, -trace_msg. But since we highly used to work with captures, it's easier and more comfortable for us to work with captures.) ;Thanks in advance and regards, Akos Nagy _______________________________________________ Sipp-users mailing list Sip...@li... https://lists.sourceforge.net/lists/listinfo/sipp-users That sounds more like a Wireshark configuration issue, where heuristics or static port assignment chooses to dissect the packet contents as DIS rather than SIP. Do you use standard SIP ports (5060) in your test setup? What have the "misinterpreted" packets have in common that differs from what the "properly interpreted" packets have in common? Try to disable DIS in supported protocols of Wireshark and see whether it helps. P. Dne 21.07.2021 v 14:20 Nagy Akos napsal(a): Hello dear SIPp experts, I didn't found any related thread in the archive, so I'm asking: we got a proper working SIPp generator on CentOS - connected to a SBC (Session Border Controller). With different scenarios working okay. SIPp logs (-trace_msg) are all fine. But if I capture with tcpdump -i any -s 0 -w /tmp/capture.cap: the capture is strange sometimes. Some messages appear as proper SIP messages, but some appear as "DIS (Distributed Interactive Simulator) protocol" messages - as the Wireshark shows it. Any suggestion? (We don't use TLS, obviously.) (Due to company secrecy, I'm not allowed to attach capture.) (I know, we can work with the SIPp log files, -trace_msg. But since we highly used to work with captures, it's easier and more comfortable for us to work with captures.) ;Thanks in advance and regards, Akos Nagy _______________________________________________ Sipp-users mailing list Sip...@li... https://lists.sourceforge.net/lists/listinfo/sipp-users _______________________________________________ Sipp-users mailing list Sip...@li... https://lists.sourceforge.net/lists/listinfo/sipp-users |
From: Šindelka P. <sin...@tt...> - 2021-07-21 17:45:53
|
That sounds more like a Wireshark configuration issue, where heuristics or static port assignment chooses to dissect the packet contents as DIS rather than SIP. Do you use standard SIP ports (5060) in your test setup? What have the "misinterpreted" packets have in common that differs from what the "properly interpreted" packets have in common? Try to disable DIS in supported protocols of Wireshark and see whether it helps. P. Dne 21.07.2021 v 14:20 Nagy Akos napsal(a): > Hello dear SIPp experts, > I didn't found any related thread in the archive, so I'm asking: we > got a proper working SIPp generator on CentOS - connected to a SBC > (Session Border Controller). With different scenarios working okay. > SIPp logs (-trace_msg) are all fine. But if I capture with tcpdump -i > any -s 0 -w /tmp/capture.cap: the capture is strange sometimes. Some > messages appear as proper SIP messages, but some appear as "DIS > (Distributed Interactive Simulator) protocol" messages - as the > Wireshark shows it. Any suggestion? > (We don't use TLS, obviously.) > (Due to company secrecy, I'm not allowed to attach capture.) > (I know, we can work with the SIPp log files, -trace_msg. But since > we highly used to work with captures, it's easier and more comfortable > for us to work with captures.) > ;Thanks in advance and regards, > Akos Nagy > > > _______________________________________________ > Sipp-users mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/sipp-users |
From: Nagy A. <ak...@fr...> - 2021-07-21 12:38:35
|
Hello dear SIPp experts, I didn't found any related thread in the archive, so I'm asking: we got a proper working SIPp generator on CentOS - connected to a SBC (Session Border Controller). With different scenarios working okay. SIPp logs (-trace_msg) are all fine. But if I capture with tcpdump -i any -s 0 -w /tmp/capture.cap: the capture is strange sometimes. Some messages appear as proper SIP messages, but some appear as "DIS (Distributed Interactive Simulator) protocol" messages - as the Wireshark shows it. Any suggestion? (We don't use TLS, obviously.) (Due to company secrecy, I'm not allowed to attach capture.) (I know, we can work with the SIPp log files, -trace_msg. But since we highly used to work with captures, it's easier and more comfortable for us to work with captures.) Thanks in advance and regards,Akos Nagy |
From: Jaime J. M. <ma...@ho...> - 2021-07-21 00:07:50
|
I am doing SIP-I (encapsulated Isup) and I read a few threads with a similar question to mine. The only solution I saw was to use to [file] constructs back to back with the later containing the binary field. I would like to include the isup iam in the csv file if possible. Is there a better solution? Sent from my iPhone |
From: Vinayak M. <vin...@ec...> - 2021-06-01 08:56:30
|
Hello all, I am using sipp latest version 3.6.1 for stress testing . but i am getting a dead call in this stress testing. I checked the signalling there i found in the BYE method Route header is missing in the dead call.In succesful call i got Route header in BYE method. Can anyone guide me about this issue? -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems. |
From: Mitch V. <m.v...@gm...> - 2021-01-22 15:47:08
|
Hello all I inherited a system with sipp on it that appears to have been installed from the tar package. Where is the make uninstall directory located? I would like to remove sipp and run a clean install of the tar package. Thanks Mitch V. |
From: sshark w. <ssh...@gm...> - 2020-11-01 22:26:57
|
I changed to UDP and verified and still the same - SIPp crashes in the called party when it receives the recvCmd. I guess the scenario you described is not be possible based on what is stated in issue #493 On Mon, Nov 2, 2020 at 1:45 AM Šindelka Pavel <sin...@tt...> wrote: > The missing part of the puzzle was that you use TCP. So there are two > issues, one related to SIPp and another one related to real world > deployment: > > - with TCP, the difference between UAC mode and UAS mode begins as low > as in whether to bind to port 5060 for listening as UAS, or whether to bind > to an ephemeral port for sending as UAC. I am not sure how this is > internally handled in SIPp. > - in real SIP deployment, the devices are rarely on public IPs, so the > mode where each peer establishes its own TCP session (or even more sessions > in sequence) towards the other peer's port 5060 to send its requests and > receive responses to them is not practically usable on the call path > between CPE and the exchange (or SBC). So if a CPE needs to use TCP to talk > to the exchange (e.g. because TLS is used), the CPE needs to establish a > TCP session as a client, in order to deliver the REGISTER, but that session > then stays open "forever" (and prolonged by the the re-REGISTERs), and is > reused not only for requests sent by the CPE (like outgoing INVITEs), but > also for requests sent by the exchange (incoming INVITEs from the CPE > perspective). I'm afraid I cannot imagine how to imitate this behaviour > using SIPp without modifying the code, which is way above my capabilities. > > P. > > > Dne 01.11.2020 v 1:20 sshark wsk napsal(a): > > Here are the scenario files, input files & scripts. I will try and test > with an older version of SIPp. I have to build it for my environment > > Thanks > > On Sun, Nov 1, 2020 at 7:31 AM Šindelka Pavel <sin...@tt...> wrote: > >> Until the bug gets fixed, can you try an older version of SIPp? Or, can >> you send me your scenarios for checking on my 3.6.0? >> >> P. >> Dne 28.10.2020 v 10:23 sshark wsk napsal(a): >> >> I tried to use the scenario described in the link below, unfortunately my >> sipp crashes with segmentation fault. Have raised an issue in GitHub >> https://sourceforge.net/p/sipp/mailman/message/34707334/ >> >> Any other ways I can achieve what I initially posted... >> >> >> On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <ssh...@gm...> wrote: >> >>> I have the below. I guess for the called party, as I am finishing the >>> thread for registration adn then wait for INVITE in the same IP/port it >>> seems to work. Maybe it's not a good idea ? >>> Do you think the 3PCC scenario is the only way it will work for my >>> requirement ? >>> >>> *Server1 script* >>> bindIP=10.10.10.1 >>> port=5060 >>> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf >>> ./register_and_call.xml -inf ./A_user.csv -trace_msg >>> >>> *Server2 script* >>> bindIP=10.10.10.2 >>> port=5061 >>> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./reg.xml -inf >>> ./B_user_register.csv -trace_msg >>> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./receive.xml >>> -inf ./B_user_answer.csv -trace_msg >>> >>> I also saw some other posting where you can run UAC & UAS with one >>> instance of the sipp. Does that work ? >>> https://github.com/SIPp/sipp/issues/362 >>> >>> >>> >>> On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel <sin...@tt...> wrote: >>> >>>> > my plan for the called user is to keep different >>>> > scenarios for register and process invites. >>>> But that's only possible if the tested device is fine with the REGISTER >>>> coming from a different socket than the one which is indicated in the >>>> Contact uri, as is the case with vanilla SIP. In real life >>>> environments, >>>> which I suppose you are going to test, the SBC stores the actual socket >>>> from which the REGISTER has arrived, and sends the INVITE to that >>>> stored >>>> socket regardless what was written in the Contact uri in the REGISTER. >>>> >>>> As you want the calls to overlap, the scenario expecting the INVITEs >>>> (and later on receiving or sending the BYEs) must be running >>>> continuously, so you cannot simultaneously send the REGISTERs from the >>>> same socket. >>>> >>>> > I am struggling with the setup to continue to run called user to >>>> > continuously process invites. Should I be just using labels to >>>> > continue the loop in the "process invites" scenario ? >>>> This sounds to me as if you haven't understood the relationship between >>>> threads and Call-IDs. At the beginning, the scenario receives an >>>> initial >>>> INVITE with some Call-ID yet unknown to it, so it spawns a new thread >>>> for that call, answers the INVITE with a 200, then receives or sends a >>>> BYE and responds it/gets it responded with a 200, and all that time the >>>> Call-ID stays attached to the thread. If there are no other messages to >>>> send or receive left in the scenario, the thread will end after some >>>> guard timer expires (which is there to handle eventual retransmissions >>>> of the BYE or the 200 to it if they arrive) and SIPp stops recognizing >>>> that Call-ID, but if you jump to the beginning of the scenario, the >>>> thread will expect another INVITE with the same Call-ID - which will >>>> never arrive (or at least should never arrive). >>>> >>>> So you don't need to do anything special in order that a scenario was >>>> ready for a new call. It just sits there listening at its socket, and >>>> if >>>> an INVITE with a yet unknown Call-ID arrives, it handles it in a >>>> freshly >>>> spawn dedicated thread. If several INVITEs come "at once" with an >>>> individual Call-ID each, several threads get spawned "at once". >>>> >>>> P. >>>> >>>> Dne 04.10.2020 v 14:27 sshark wsk napsal(a): >>>> > Hi Pavel, >>>> > >>>> > Thanks, yes I did go through that post and various other posts >>>> > describing the challenges of running UAC & UAS for called party.. >>>> > As I mentioned, my plan for the called user is to keep different >>>> > scenarios for register and process invites. >>>> > >>>> > I am struggling with the setup to continue to run called user to >>>> > continuously process invites. Should I be just using labels to >>>> > continue the loop in the "process invites" scenario ? >>>> > >>>> > //sshark >>>> > >>>> > On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel <sin...@tt...> >>>> wrote: >>>> >> Hi sshark, >>>> >> >>>> >> could you please read >>>> https://sourceforge.net/p/sipp/mailman/message/34707334/ first if you >>>> haven't yet? >>>> >> >>>> >> I think I've put pretty much everything in there on how to create >>>> "amphibious" scenarios behaving as both UAC and UAS, which is what you need >>>> in order to create a scenario which will register and keep updating the >>>> registration (as a UAC) and answer incoming calls (as a UAS) while it stays >>>> bound to the same local UDP socket. The need to stay bound to the same >>>> socket explains why I deem all the timing to be done using SIPp itself to >>>> be a better way than using bash scripts to spawn execution of the >>>> scenarios. It's true, however, that on the calling side you could spawn a >>>> registration, outgoing call, and unregistration as three separate scenarios >>>> binding to the same local port by shell script, but then you'd have to use >>>> one socket per user. >>>> >> >>>> >> I didn't detail there the reasons why a Call-ID of a REGISTER must >>>> be different from the one of the INVITE, but normal SIP stacks should >>>> ignore or reject an INVITE with the same Call-ID like one in a previously >>>> received REGISTER, at least if it came soon enough after that REGISTER. >>>> >> >>>> >> So as you don't insist on the unregistrations at the called side >>>> (from the point of view of traffic volume, registration updates will >>>> generate 1/2 of the traffic volume as compared to un-registrations and >>>> re-registrations with the same periodicity), the A and B scenarios (or >>>> rather scenario pairs) can be completely independent. Plus in the wild, an >>>> active un-registration is a rare beast. >>>> >> >>>> >> There's just one point to the periodicity of the registration >>>> updates, some registrars/SBCs have not only maximum registration time but >>>> also a minimum one, and if you attempt to register for a shorter time, they >>>> respond with "423 interval too brief", so even if you'll be actually >>>> updating the registration every minute, you have to indicate an Expires >>>> value which will satisfy the SBC and/or registrar. >>>> >> >>>> >> So in my approach, the B scenario would optionally accept and >>>> respond INVITEs (and possibly OPTIONS depending on the behaiour of the >>>> system being tested) by a corresponding branch, and mandatorily accept >>>> commands from the timer instance and spawn another branch which would >>>> periodically register. Eventually, that branch could accept a termination >>>> command from the timer instance if you want the scenario group to terminate >>>> autonomously after a predefined number of cycles or amount of time (I've >>>> never tried the -m command line option with a UAS scenario, maybe it works >>>> too). >>>> >> >>>> >> The A scenario would accept trigger commands from its own timer >>>> scenario, where a single call in the timer scenario would use two distinct >>>> Call-IDs in the commands it would send to the executive scenario a few >>>> seconds apart: the first one would be made up and would trigger the >>>> registration, the second one would be the native one of the timer scenario >>>> and would trigger the outgoing call. The random duration of the outgoing >>>> call would be determined by the executive scenario, which would send a >>>> command to the timer one as a notification that the call has ended; in >>>> response to that, the timer would send back a command with the made-up call >>>> ID to trigger the unregistration. This way of synchronizing two threads >>>> within the same scenario is the simplest one I could find throughout the >>>> years. >>>> >> >>>> >> The overlapping would be provided by the -l 2 command line option as >>>> I've suggested earlier (third call cannot start until the first one ends). >>>> >> >>>> >> P. >>>> >> >>>> >> Dne 03.10.2020 v 6:11 sshark wsk napsal(a): >>>> >> >>>> >> Thanks for the email, The main goal for me is to keep some constant >>>> >> traffic on the SIP servers. I thought of having >>>> >> registration/deregistration flows as they do invoke different >>>> >> functions/procedures within the SIP server. If it introduces too much >>>> >> complexity, then I am happy with doing re-registration rather than >>>> >> de-register/register again... >>>> >> >>>> >> How can I approach in doing this, can sipp orchestrate this or better >>>> >> use shell script to do a loop and use sipp ? >>>> >> >>>> >> Thanks for your help.. >>>> >> >>>> >> On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel <sin...@tt...> >>>> wrote: >>>> >> >>>> >> Okay, the diagram shows clearly that the calls can and should >>>> overlap. >>>> >> >>>> >> Is it an absolute must that the called side was de-registering and >>>> >> re-registering again for every call, or may it register in the >>>> beginning >>>> >> and keep renewing the registration periodically, and just accept >>>> >> incoming calls? If the unregistration of the called side is not >>>> >> mandatory, this will remove the need for synchronization between the >>>> A >>>> >> side script and the B side script. >>>> >> >>>> >> P. >>>> >> >>>> >> Dne 30.09.2020 v 14:35 sshark wsk napsal(a): >>>> >> >>>> >> I have below setup available with me >>>> >> Shell Script1: Handles A party >>>> >> Scenario 1 - A user to register and send INVITE and handle subsequent >>>> >> messages (180, 200OK, ACK) and then deregister user >>>> >> >>>> >> Shell Script2: Handles B party >>>> >> Scenario 2 - B user to register >>>> >> Scenario 3 - B user to accept INVITE and handle appropriate messages >>>> >> (180, 200OK, ACK) >>>> >> Scenario 4 - B user to de-register >>>> >> >>>> >> Have drafted a sequence diagram on what I had in mind. I hope it >>>> >> explains what I have in mind.. >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel <sin...@tt...> >>>> wrote: >>>> >> >>>> >> Do you want a single scenario to act as both A and B subscribers or >>>> you plan to use two scenarios? The thing is that if you want each user to >>>> unregister after the call, you need to have some synchronization between >>>> the A and B side even if each runs as a separate scenario on a different >>>> machine, otherwise you'll find A knocking on a closed door at B sooner or >>>> later. >>>> >> >>>> >> You also state contradictory requirements - if you want at least one >>>> call "on air" at any given instant of time, the calls must be overlapping, >>>> whereas unregistering An,Bn after a call and then registering An+1,Bn+1 >>>> creates a gap between the calls. So choose which one of these two >>>> requirements is more important. >>>> >> >>>> >> My approach would be to use a timer scenario, sending sync messages >>>> to both the A and B scenarios, with Call-IDs in the sync messages generated >>>> from [call_number] so that the sync message triggering the REGISTER at A >>>> and the one triggering the INVITE at A would be sent by the same call at >>>> the timer scenario but seen as two independent calls at the A scenario. To >>>> choose the right row in the csv file, I'd compute the row ID in the timing >>>> scenario and deliver it from there as a value of some P-user-index header - >>>> this way, all the calculations (call number modulo 5) would be done in the >>>> timer scenario and the A and B scenarios would just use the value extracted >>>> from that header in the synchronization messages. So you would not need to >>>> start sipp in loops, you'd just specify the total number of calls and >>>> number of calls per unit of time, and the modulo 5 would do the rest of the >>>> job. >>>> >> >>>> >> I remember I was not able to make the 3PCC extended work some years >>>> ago, so you may have tough time making three scenarios (timer, A, B) work, >>>> but maybe it's not an issue any more, or it even never was and it was just >>>> some mistake I could not find in my setup. >>>> >> >>>> >> -l 2 option on the command line should make sure that not more than >>>> two trigger calls will be active simultaneously, so the third call should >>>> not start before the first one finishes. >>>> >> >>>> >> Pavel >>>> >> >>>> >> Dne 29.09.2020 v 14:07 sshark wsk napsal(a): >>>> >> >>>> >> Continuation to below thread, I have some additional questions >>>> >> https://sourceforge.net/p/sipp/mailman/message/35176307/ >>>> >> >>>> >> I would like to know if anyone has some sample scenario files for >>>> >> 1. Have bunch of users for A (5) & B (5) >>>> >> 2. Register B1 party and listen for INVITEs >>>> >> 3. Register A1 party and setup call towards A party >>>> >> 4. Keep the call predefined period/can be random (~10s) >>>> >> 5. Terminate the call >>>> >> 6. De-register A1 & B1 >>>> >> 7. Continue to the next set of users - A2/B2, A3/B3, A4/B4, A5/B5 >>>> >> 8. Once list is exhausted, start from A1/B1 >>>> >> >>>> >> I am able to create the scenario file (Register/call/answer), however >>>> >> would like to get some hints on how to do the below >>>> >> - How SIPp can be scheduled to run through a loop >>>> >> - Our goal is to have at least 1 call through the network at a given >>>> >> point of time to simulate background testing >>>> >> >>>> >> Thank You in advance for any inputs/feedback >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Sipp-users mailing list >>>> >> Sip...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >>>> >> >>>> >> _______________________________________________ >>>> >> Sipp-users mailing list >>>> >> Sip...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >>>> >>>> |
From: Šindelka P. <sin...@tt...> - 2020-11-01 15:17:48
|
The missing part of the puzzle was that you use TCP. So there are two issues, one related to SIPp and another one related to real world deployment: * with TCP, the difference between UAC mode and UAS mode begins as low as in whether to bind to port 5060 for listening as UAS, or whether to bind to an ephemeral port for sending as UAC. I am not sure how this is internally handled in SIPp. * in real SIP deployment, the devices are rarely on public IPs, so the mode where each peer establishes its own TCP session (or even more sessions in sequence) towards the other peer's port 5060 to send its requests and receive responses to them is not practically usable on the call path between CPE and the exchange (or SBC). So if a CPE needs to use TCP to talk to the exchange (e.g. because TLS is used), the CPE needs to establish a TCP session as a client, in order to deliver the REGISTER, but that session then stays open "forever" (and prolonged by the the re-REGISTERs), and is reused not only for requests sent by the CPE (like outgoing INVITEs), but also for requests sent by the exchange (incoming INVITEs from the CPE perspective). I'm afraid I cannot imagine how to imitate this behaviour using SIPp without modifying the code, which is way above my capabilities. P. Dne 01.11.2020 v 1:20 sshark wsk napsal(a): > Here are the scenario files, input files & scripts. I will try and > test with an older version of SIPp. I have to build it for my environment > > Thanks > > On Sun, Nov 1, 2020 at 7:31 AM Šindelka Pavel <sin...@tt... > <mailto:sin...@tt...>> wrote: > > Until the bug gets fixed, can you try an older version of SIPp? > Or, can you send me your scenarios for checking on my 3.6.0? > > P. > > Dne 28.10.2020 v 10:23 sshark wsk napsal(a): >> I tried to use the scenario described in the link below, >> unfortunately my sipp crashes with segmentation fault. Have >> raised an issue in GitHub >> https://sourceforge.net/p/sipp/mailman/message/34707334/ >> >> Any other ways I can achieve what I initially posted... >> >> >> On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <ssh...@gm... >> <mailto:ssh...@gm...>> wrote: >> >> I have the below. I guess for the called party, as I am >> finishing the thread for registration adn then wait for >> INVITE in the same IP/port it seems to work. Maybe it's not a >> good idea ? >> Do you think the 3PCC scenario is the only way it will work >> for my requirement ? >> >> _Server1 script_ >> bindIP=10.10.10.1 >> port=5060 >> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf >> ./register_and_call.xml -inf ./A_user.csv -trace_msg >> >> _Server2 script_ >> bindIP=10.10.10.2 >> port=5061 >> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf >> ./reg.xml -inf ./B_user_register.csv -trace_msg >> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf >> ./receive.xml -inf ./B_user_answer.csv -trace_msg >> >> I also saw some other posting where you can run UAC & UAS >> with one instance of the sipp. Does that work ? >> https://github.com/SIPp/sipp/issues/362 >> >> >> >> On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel >> <sin...@tt... <mailto:sin...@tt...>> wrote: >> >> > my plan for the called user is to keep different >> > scenarios for register and process invites. >> But that's only possible if the tested device is fine >> with the REGISTER >> coming from a different socket than the one which is >> indicated in the >> Contact uri, as is the case with vanilla SIP. In real >> life environments, >> which I suppose you are going to test, the SBC stores the >> actual socket >> from which the REGISTER has arrived, and sends the INVITE >> to that stored >> socket regardless what was written in the Contact uri in >> the REGISTER. >> >> As you want the calls to overlap, the scenario expecting >> the INVITEs >> (and later on receiving or sending the BYEs) must be running >> continuously, so you cannot simultaneously send the >> REGISTERs from the >> same socket. >> >> > I am struggling with the setup to continue to run >> called user to >> > continuously process invites. Should I be just using >> labels to >> > continue the loop in the "process invites" scenario ? >> This sounds to me as if you haven't understood the >> relationship between >> threads and Call-IDs. At the beginning, the scenario >> receives an initial >> INVITE with some Call-ID yet unknown to it, so it spawns >> a new thread >> for that call, answers the INVITE with a 200, then >> receives or sends a >> BYE and responds it/gets it responded with a 200, and all >> that time the >> Call-ID stays attached to the thread. If there are no >> other messages to >> send or receive left in the scenario, the thread will end >> after some >> guard timer expires (which is there to handle eventual >> retransmissions >> of the BYE or the 200 to it if they arrive) and SIPp >> stops recognizing >> that Call-ID, but if you jump to the beginning of the >> scenario, the >> thread will expect another INVITE with the same Call-ID - >> which will >> never arrive (or at least should never arrive). >> >> So you don't need to do anything special in order that a >> scenario was >> ready for a new call. It just sits there listening at its >> socket, and if >> an INVITE with a yet unknown Call-ID arrives, it handles >> it in a freshly >> spawn dedicated thread. If several INVITEs come "at once" >> with an >> individual Call-ID each, several threads get spawned "at >> once". >> >> P. >> >> Dne 04.10.2020 v 14:27 sshark wsk napsal(a): >> > Hi Pavel, >> > >> > Thanks, yes I did go through that post and various >> other posts >> > describing the challenges of running UAC & UAS for >> called party.. >> > As I mentioned, my plan for the called user is to keep >> different >> > scenarios for register and process invites. >> > >> > I am struggling with the setup to continue to run >> called user to >> > continuously process invites. Should I be just using >> labels to >> > continue the loop in the "process invites" scenario ? >> > >> > //sshark >> > >> > On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel >> <sin...@tt... <mailto:sin...@tt...>> wrote: >> >> Hi sshark, >> >> >> >> could you please read >> https://sourceforge.net/p/sipp/mailman/message/34707334/ >> first if you haven't yet? >> >> >> >> I think I've put pretty much everything in there on >> how to create "amphibious" scenarios behaving as both UAC >> and UAS, which is what you need in order to create a >> scenario which will register and keep updating the >> registration (as a UAC) and answer incoming calls (as a >> UAS) while it stays bound to the same local UDP socket. >> The need to stay bound to the same socket explains why I >> deem all the timing to be done using SIPp itself to be a >> better way than using bash scripts to spawn execution of >> the scenarios. It's true, however, that on the calling >> side you could spawn a registration, outgoing call, and >> unregistration as three separate scenarios binding to the >> same local port by shell script, but then you'd have to >> use one socket per user. >> >> >> >> I didn't detail there the reasons why a Call-ID of a >> REGISTER must be different from the one of the INVITE, >> but normal SIP stacks should ignore or reject an INVITE >> with the same Call-ID like one in a previously received >> REGISTER, at least if it came soon enough after that >> REGISTER. >> >> >> >> So as you don't insist on the unregistrations at the >> called side (from the point of view of traffic volume, >> registration updates will generate 1/2 of the traffic >> volume as compared to un-registrations and >> re-registrations with the same periodicity), the A and B >> scenarios (or rather scenario pairs) can be completely >> independent. Plus in the wild, an active un-registration >> is a rare beast. >> >> >> >> There's just one point to the periodicity of the >> registration updates, some registrars/SBCs have not only >> maximum registration time but also a minimum one, and if >> you attempt to register for a shorter time, they respond >> with "423 interval too brief", so even if you'll be >> actually updating the registration every minute, you have >> to indicate an Expires value which will satisfy the SBC >> and/or registrar. >> >> >> >> So in my approach, the B scenario would optionally >> accept and respond INVITEs (and possibly OPTIONS >> depending on the behaiour of the system being tested) by >> a corresponding branch, and mandatorily accept commands >> from the timer instance and spawn another branch which >> would periodically register. Eventually, that branch >> could accept a termination command from the timer >> instance if you want the scenario group to terminate >> autonomously after a predefined number of cycles or >> amount of time (I've never tried the -m command line >> option with a UAS scenario, maybe it works too). >> >> >> >> The A scenario would accept trigger commands from its >> own timer scenario, where a single call in the timer >> scenario would use two distinct Call-IDs in the commands >> it would send to the executive scenario a few seconds >> apart: the first one would be made up and would trigger >> the registration, the second one would be the native one >> of the timer scenario and would trigger the outgoing >> call. The random duration of the outgoing call would be >> determined by the executive scenario, which would send a >> command to the timer one as a notification that the call >> has ended; in response to that, the timer would send back >> a command with the made-up call ID to trigger the >> unregistration. This way of synchronizing two threads >> within the same scenario is the simplest one I could find >> throughout the years. >> >> >> >> The overlapping would be provided by the -l 2 command >> line option as I've suggested earlier (third call cannot >> start until the first one ends). >> >> >> >> P. >> >> >> >> Dne 03.10.2020 v 6:11 sshark wsk napsal(a): >> >> >> >> Thanks for the email, The main goal for me is to keep >> some constant >> >> traffic on the SIP servers. I thought of having >> >> registration/deregistration flows as they do invoke >> different >> >> functions/procedures within the SIP server. If it >> introduces too much >> >> complexity, then I am happy with doing re-registration >> rather than >> >> de-register/register again... >> >> >> >> How can I approach in doing this, can sipp orchestrate >> this or better >> >> use shell script to do a loop and use sipp ? >> >> >> >> Thanks for your help.. >> >> >> >> On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel >> <sin...@tt... <mailto:sin...@tt...>> wrote: >> >> >> >> Okay, the diagram shows clearly that the calls can and >> should overlap. >> >> >> >> Is it an absolute must that the called side was >> de-registering and >> >> re-registering again for every call, or may it >> register in the beginning >> >> and keep renewing the registration periodically, and >> just accept >> >> incoming calls? If the unregistration of the called >> side is not >> >> mandatory, this will remove the need for >> synchronization between the A >> >> side script and the B side script. >> >> >> >> P. >> >> >> >> Dne 30.09.2020 v 14:35 sshark wsk napsal(a): >> >> >> >> I have below setup available with me >> >> Shell Script1: Handles A party >> >> Scenario 1 - A user to register and send INVITE and >> handle subsequent >> >> messages (180, 200OK, ACK) and then deregister user >> >> >> >> Shell Script2: Handles B party >> >> Scenario 2 - B user to register >> >> Scenario 3 - B user to accept INVITE and handle >> appropriate messages >> >> (180, 200OK, ACK) >> >> Scenario 4 - B user to de-register >> >> >> >> Have drafted a sequence diagram on what I had in mind. >> I hope it >> >> explains what I have in mind.. >> >> >> >> >> >> >> >> On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel >> <sin...@tt... <mailto:sin...@tt...>> wrote: >> >> >> >> Do you want a single scenario to act as both A and B >> subscribers or you plan to use two scenarios? The thing >> is that if you want each user to unregister after the >> call, you need to have some synchronization between the A >> and B side even if each runs as a separate scenario on a >> different machine, otherwise you'll find A knocking on a >> closed door at B sooner or later. >> >> >> >> You also state contradictory requirements - if you >> want at least one call "on air" at any given instant of >> time, the calls must be overlapping, whereas >> unregistering An,Bn after a call and then registering >> An+1,Bn+1 creates a gap between the calls. So choose >> which one of these two requirements is more important. >> >> >> >> My approach would be to use a timer scenario, sending >> sync messages to both the A and B scenarios, with >> Call-IDs in the sync messages generated from >> [call_number] so that the sync message triggering the >> REGISTER at A and the one triggering the INVITE at A >> would be sent by the same call at the timer scenario but >> seen as two independent calls at the A scenario. To >> choose the right row in the csv file, I'd compute the row >> ID in the timing scenario and deliver it from there as a >> value of some P-user-index header - this way, all the >> calculations (call number modulo 5) would be done in the >> timer scenario and the A and B scenarios would just use >> the value extracted from that header in the >> synchronization messages. So you would not need to start >> sipp in loops, you'd just specify the total number of >> calls and number of calls per unit of time, and the >> modulo 5 would do the rest of the job. >> >> >> >> I remember I was not able to make the 3PCC extended >> work some years ago, so you may have tough time making >> three scenarios (timer, A, B) work, but maybe it's not an >> issue any more, or it even never was and it was just some >> mistake I could not find in my setup. >> >> >> >> -l 2 option on the command line should make sure that >> not more than two trigger calls will be active >> simultaneously, so the third call should not start before >> the first one finishes. >> >> >> >> Pavel >> >> >> >> Dne 29.09.2020 v 14:07 sshark wsk napsal(a): >> >> >> >> Continuation to below thread, I have some additional >> questions >> >> https://sourceforge.net/p/sipp/mailman/message/35176307/ >> >> >> >> I would like to know if anyone has some sample >> scenario files for >> >> 1. Have bunch of users for A (5) & B (5) >> >> 2. Register B1 party and listen for INVITEs >> >> 3. Register A1 party and setup call towards A party >> >> 4. Keep the call predefined period/can be random (~10s) >> >> 5. Terminate the call >> >> 6. De-register A1 & B1 >> >> 7. Continue to the next set of users - A2/B2, A3/B3, >> A4/B4, A5/B5 >> >> 8. Once list is exhausted, start from A1/B1 >> >> >> >> I am able to create the scenario file >> (Register/call/answer), however >> >> would like to get some hints on how to do the below >> >> - How SIPp can be scheduled to run through a loop >> >> - Our goal is to have at least 1 call through the >> network at a given >> >> point of time to simulate background testing >> >> >> >> Thank You in advance for any inputs/feedback >> >> >> >> >> >> _______________________________________________ >> >> Sipp-users mailing list >> >> Sip...@li... >> <mailto:Sip...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> >> >> >> _______________________________________________ >> >> Sipp-users mailing list >> >> Sip...@li... >> <mailto:Sip...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> |
From: sshark w. <ssh...@gm...> - 2020-11-01 11:16:46
|
Not sure if you had a look at the SIPp issue. The specific scenario may not work (Optional recvs & recvCmd https://github.com/SIPp/sipp/issues/493 On Sun, Nov 1, 2020 at 11:20 AM sshark wsk <ssh...@gm...> wrote: > Here are the scenario files, input files & scripts. I will try and test > with an older version of SIPp. I have to build it for my environment > > Thanks > > On Sun, Nov 1, 2020 at 7:31 AM Šindelka Pavel <sin...@tt...> wrote: > >> Until the bug gets fixed, can you try an older version of SIPp? Or, can >> you send me your scenarios for checking on my 3.6.0? >> >> P. >> Dne 28.10.2020 v 10:23 sshark wsk napsal(a): >> >> I tried to use the scenario described in the link below, unfortunately my >> sipp crashes with segmentation fault. Have raised an issue in GitHub >> https://sourceforge.net/p/sipp/mailman/message/34707334/ >> >> Any other ways I can achieve what I initially posted... >> >> >> On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <ssh...@gm...> wrote: >> >>> I have the below. I guess for the called party, as I am finishing the >>> thread for registration adn then wait for INVITE in the same IP/port it >>> seems to work. Maybe it's not a good idea ? >>> Do you think the 3PCC scenario is the only way it will work for my >>> requirement ? >>> >>> *Server1 script* >>> bindIP=10.10.10.1 >>> port=5060 >>> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf >>> ./register_and_call.xml -inf ./A_user.csv -trace_msg >>> >>> *Server2 script* >>> bindIP=10.10.10.2 >>> port=5061 >>> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./reg.xml -inf >>> ./B_user_register.csv -trace_msg >>> ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./receive.xml >>> -inf ./B_user_answer.csv -trace_msg >>> >>> I also saw some other posting where you can run UAC & UAS with one >>> instance of the sipp. Does that work ? >>> https://github.com/SIPp/sipp/issues/362 >>> >>> >>> >>> On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel <sin...@tt...> wrote: >>> >>>> > my plan for the called user is to keep different >>>> > scenarios for register and process invites. >>>> But that's only possible if the tested device is fine with the REGISTER >>>> coming from a different socket than the one which is indicated in the >>>> Contact uri, as is the case with vanilla SIP. In real life >>>> environments, >>>> which I suppose you are going to test, the SBC stores the actual socket >>>> from which the REGISTER has arrived, and sends the INVITE to that >>>> stored >>>> socket regardless what was written in the Contact uri in the REGISTER. >>>> >>>> As you want the calls to overlap, the scenario expecting the INVITEs >>>> (and later on receiving or sending the BYEs) must be running >>>> continuously, so you cannot simultaneously send the REGISTERs from the >>>> same socket. >>>> >>>> > I am struggling with the setup to continue to run called user to >>>> > continuously process invites. Should I be just using labels to >>>> > continue the loop in the "process invites" scenario ? >>>> This sounds to me as if you haven't understood the relationship between >>>> threads and Call-IDs. At the beginning, the scenario receives an >>>> initial >>>> INVITE with some Call-ID yet unknown to it, so it spawns a new thread >>>> for that call, answers the INVITE with a 200, then receives or sends a >>>> BYE and responds it/gets it responded with a 200, and all that time the >>>> Call-ID stays attached to the thread. If there are no other messages to >>>> send or receive left in the scenario, the thread will end after some >>>> guard timer expires (which is there to handle eventual retransmissions >>>> of the BYE or the 200 to it if they arrive) and SIPp stops recognizing >>>> that Call-ID, but if you jump to the beginning of the scenario, the >>>> thread will expect another INVITE with the same Call-ID - which will >>>> never arrive (or at least should never arrive). >>>> >>>> So you don't need to do anything special in order that a scenario was >>>> ready for a new call. It just sits there listening at its socket, and >>>> if >>>> an INVITE with a yet unknown Call-ID arrives, it handles it in a >>>> freshly >>>> spawn dedicated thread. If several INVITEs come "at once" with an >>>> individual Call-ID each, several threads get spawned "at once". >>>> >>>> P. >>>> >>>> Dne 04.10.2020 v 14:27 sshark wsk napsal(a): >>>> > Hi Pavel, >>>> > >>>> > Thanks, yes I did go through that post and various other posts >>>> > describing the challenges of running UAC & UAS for called party.. >>>> > As I mentioned, my plan for the called user is to keep different >>>> > scenarios for register and process invites. >>>> > >>>> > I am struggling with the setup to continue to run called user to >>>> > continuously process invites. Should I be just using labels to >>>> > continue the loop in the "process invites" scenario ? >>>> > >>>> > //sshark >>>> > >>>> > On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel <sin...@tt...> >>>> wrote: >>>> >> Hi sshark, >>>> >> >>>> >> could you please read >>>> https://sourceforge.net/p/sipp/mailman/message/34707334/ first if you >>>> haven't yet? >>>> >> >>>> >> I think I've put pretty much everything in there on how to create >>>> "amphibious" scenarios behaving as both UAC and UAS, which is what you need >>>> in order to create a scenario which will register and keep updating the >>>> registration (as a UAC) and answer incoming calls (as a UAS) while it stays >>>> bound to the same local UDP socket. The need to stay bound to the same >>>> socket explains why I deem all the timing to be done using SIPp itself to >>>> be a better way than using bash scripts to spawn execution of the >>>> scenarios. It's true, however, that on the calling side you could spawn a >>>> registration, outgoing call, and unregistration as three separate scenarios >>>> binding to the same local port by shell script, but then you'd have to use >>>> one socket per user. >>>> >> >>>> >> I didn't detail there the reasons why a Call-ID of a REGISTER must >>>> be different from the one of the INVITE, but normal SIP stacks should >>>> ignore or reject an INVITE with the same Call-ID like one in a previously >>>> received REGISTER, at least if it came soon enough after that REGISTER. >>>> >> >>>> >> So as you don't insist on the unregistrations at the called side >>>> (from the point of view of traffic volume, registration updates will >>>> generate 1/2 of the traffic volume as compared to un-registrations and >>>> re-registrations with the same periodicity), the A and B scenarios (or >>>> rather scenario pairs) can be completely independent. Plus in the wild, an >>>> active un-registration is a rare beast. >>>> >> >>>> >> There's just one point to the periodicity of the registration >>>> updates, some registrars/SBCs have not only maximum registration time but >>>> also a minimum one, and if you attempt to register for a shorter time, they >>>> respond with "423 interval too brief", so even if you'll be actually >>>> updating the registration every minute, you have to indicate an Expires >>>> value which will satisfy the SBC and/or registrar. >>>> >> >>>> >> So in my approach, the B scenario would optionally accept and >>>> respond INVITEs (and possibly OPTIONS depending on the behaiour of the >>>> system being tested) by a corresponding branch, and mandatorily accept >>>> commands from the timer instance and spawn another branch which would >>>> periodically register. Eventually, that branch could accept a termination >>>> command from the timer instance if you want the scenario group to terminate >>>> autonomously after a predefined number of cycles or amount of time (I've >>>> never tried the -m command line option with a UAS scenario, maybe it works >>>> too). >>>> >> >>>> >> The A scenario would accept trigger commands from its own timer >>>> scenario, where a single call in the timer scenario would use two distinct >>>> Call-IDs in the commands it would send to the executive scenario a few >>>> seconds apart: the first one would be made up and would trigger the >>>> registration, the second one would be the native one of the timer scenario >>>> and would trigger the outgoing call. The random duration of the outgoing >>>> call would be determined by the executive scenario, which would send a >>>> command to the timer one as a notification that the call has ended; in >>>> response to that, the timer would send back a command with the made-up call >>>> ID to trigger the unregistration. This way of synchronizing two threads >>>> within the same scenario is the simplest one I could find throughout the >>>> years. >>>> >> >>>> >> The overlapping would be provided by the -l 2 command line option as >>>> I've suggested earlier (third call cannot start until the first one ends). >>>> >> >>>> >> P. >>>> >> >>>> >> Dne 03.10.2020 v 6:11 sshark wsk napsal(a): >>>> >> >>>> >> Thanks for the email, The main goal for me is to keep some constant >>>> >> traffic on the SIP servers. I thought of having >>>> >> registration/deregistration flows as they do invoke different >>>> >> functions/procedures within the SIP server. If it introduces too much >>>> >> complexity, then I am happy with doing re-registration rather than >>>> >> de-register/register again... >>>> >> >>>> >> How can I approach in doing this, can sipp orchestrate this or better >>>> >> use shell script to do a loop and use sipp ? >>>> >> >>>> >> Thanks for your help.. >>>> >> >>>> >> On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel <sin...@tt...> >>>> wrote: >>>> >> >>>> >> Okay, the diagram shows clearly that the calls can and should >>>> overlap. >>>> >> >>>> >> Is it an absolute must that the called side was de-registering and >>>> >> re-registering again for every call, or may it register in the >>>> beginning >>>> >> and keep renewing the registration periodically, and just accept >>>> >> incoming calls? If the unregistration of the called side is not >>>> >> mandatory, this will remove the need for synchronization between the >>>> A >>>> >> side script and the B side script. >>>> >> >>>> >> P. >>>> >> >>>> >> Dne 30.09.2020 v 14:35 sshark wsk napsal(a): >>>> >> >>>> >> I have below setup available with me >>>> >> Shell Script1: Handles A party >>>> >> Scenario 1 - A user to register and send INVITE and handle subsequent >>>> >> messages (180, 200OK, ACK) and then deregister user >>>> >> >>>> >> Shell Script2: Handles B party >>>> >> Scenario 2 - B user to register >>>> >> Scenario 3 - B user to accept INVITE and handle appropriate messages >>>> >> (180, 200OK, ACK) >>>> >> Scenario 4 - B user to de-register >>>> >> >>>> >> Have drafted a sequence diagram on what I had in mind. I hope it >>>> >> explains what I have in mind.. >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel <sin...@tt...> >>>> wrote: >>>> >> >>>> >> Do you want a single scenario to act as both A and B subscribers or >>>> you plan to use two scenarios? The thing is that if you want each user to >>>> unregister after the call, you need to have some synchronization between >>>> the A and B side even if each runs as a separate scenario on a different >>>> machine, otherwise you'll find A knocking on a closed door at B sooner or >>>> later. >>>> >> >>>> >> You also state contradictory requirements - if you want at least one >>>> call "on air" at any given instant of time, the calls must be overlapping, >>>> whereas unregistering An,Bn after a call and then registering An+1,Bn+1 >>>> creates a gap between the calls. So choose which one of these two >>>> requirements is more important. >>>> >> >>>> >> My approach would be to use a timer scenario, sending sync messages >>>> to both the A and B scenarios, with Call-IDs in the sync messages generated >>>> from [call_number] so that the sync message triggering the REGISTER at A >>>> and the one triggering the INVITE at A would be sent by the same call at >>>> the timer scenario but seen as two independent calls at the A scenario. To >>>> choose the right row in the csv file, I'd compute the row ID in the timing >>>> scenario and deliver it from there as a value of some P-user-index header - >>>> this way, all the calculations (call number modulo 5) would be done in the >>>> timer scenario and the A and B scenarios would just use the value extracted >>>> from that header in the synchronization messages. So you would not need to >>>> start sipp in loops, you'd just specify the total number of calls and >>>> number of calls per unit of time, and the modulo 5 would do the rest of the >>>> job. >>>> >> >>>> >> I remember I was not able to make the 3PCC extended work some years >>>> ago, so you may have tough time making three scenarios (timer, A, B) work, >>>> but maybe it's not an issue any more, or it even never was and it was just >>>> some mistake I could not find in my setup. >>>> >> >>>> >> -l 2 option on the command line should make sure that not more than >>>> two trigger calls will be active simultaneously, so the third call should >>>> not start before the first one finishes. >>>> >> >>>> >> Pavel >>>> >> >>>> >> Dne 29.09.2020 v 14:07 sshark wsk napsal(a): >>>> >> >>>> >> Continuation to below thread, I have some additional questions >>>> >> https://sourceforge.net/p/sipp/mailman/message/35176307/ >>>> >> >>>> >> I would like to know if anyone has some sample scenario files for >>>> >> 1. Have bunch of users for A (5) & B (5) >>>> >> 2. Register B1 party and listen for INVITEs >>>> >> 3. Register A1 party and setup call towards A party >>>> >> 4. Keep the call predefined period/can be random (~10s) >>>> >> 5. Terminate the call >>>> >> 6. De-register A1 & B1 >>>> >> 7. Continue to the next set of users - A2/B2, A3/B3, A4/B4, A5/B5 >>>> >> 8. Once list is exhausted, start from A1/B1 >>>> >> >>>> >> I am able to create the scenario file (Register/call/answer), however >>>> >> would like to get some hints on how to do the below >>>> >> - How SIPp can be scheduled to run through a loop >>>> >> - Our goal is to have at least 1 call through the network at a given >>>> >> point of time to simulate background testing >>>> >> >>>> >> Thank You in advance for any inputs/feedback >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Sipp-users mailing list >>>> >> Sip...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >>>> >> >>>> >> _______________________________________________ >>>> >> Sipp-users mailing list >>>> >> Sip...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >>>> >>>> |
From: Šindelka P. <sin...@tt...> - 2020-10-31 21:04:31
|
Until the bug gets fixed, can you try an older version of SIPp? Or, can you send me your scenarios for checking on my 3.6.0? P. Dne 28.10.2020 v 10:23 sshark wsk napsal(a): > I tried to use the scenario described in the link below, > unfortunately my sipp crashes with segmentation fault. Have raised an > issue in GitHub > https://sourceforge.net/p/sipp/mailman/message/34707334/ > > Any other ways I can achieve what I initially posted... > > > On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <ssh...@gm... > <mailto:ssh...@gm...>> wrote: > > I have the below. I guess for the called party, as I am finishing > the thread for registration adn then wait for INVITE in the same > IP/port it seems to work. Maybe it's not a good idea ? > Do you think the 3PCC scenario is the only way it will work for my > requirement ? > > _Server1 script_ > bindIP=10.10.10.1 > port=5060 > ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf > ./register_and_call.xml -inf ./A_user.csv -trace_msg > > _Server2 script_ > bindIP=10.10.10.2 > port=5061 > ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./reg.xml > -inf ./B_user_register.csv -trace_msg > ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf > ./receive.xml -inf ./B_user_answer.csv -trace_msg > > I also saw some other posting where you can run UAC & UAS with one > instance of the sipp. Does that work ? > https://github.com/SIPp/sipp/issues/362 > > > > On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel <sin...@tt... > <mailto:sin...@tt...>> wrote: > > > my plan for the called user is to keep different > > scenarios for register and process invites. > But that's only possible if the tested device is fine with the > REGISTER > coming from a different socket than the one which is indicated > in the > Contact uri, as is the case with vanilla SIP. In real life > environments, > which I suppose you are going to test, the SBC stores the > actual socket > from which the REGISTER has arrived, and sends the INVITE to > that stored > socket regardless what was written in the Contact uri in the > REGISTER. > > As you want the calls to overlap, the scenario expecting the > INVITEs > (and later on receiving or sending the BYEs) must be running > continuously, so you cannot simultaneously send the REGISTERs > from the > same socket. > > > I am struggling with the setup to continue to run called user to > > continuously process invites. Should I be just using labels to > > continue the loop in the "process invites" scenario ? > This sounds to me as if you haven't understood the > relationship between > threads and Call-IDs. At the beginning, the scenario receives > an initial > INVITE with some Call-ID yet unknown to it, so it spawns a new > thread > for that call, answers the INVITE with a 200, then receives or > sends a > BYE and responds it/gets it responded with a 200, and all that > time the > Call-ID stays attached to the thread. If there are no other > messages to > send or receive left in the scenario, the thread will end > after some > guard timer expires (which is there to handle eventual > retransmissions > of the BYE or the 200 to it if they arrive) and SIPp stops > recognizing > that Call-ID, but if you jump to the beginning of the > scenario, the > thread will expect another INVITE with the same Call-ID - > which will > never arrive (or at least should never arrive). > > So you don't need to do anything special in order that a > scenario was > ready for a new call. It just sits there listening at its > socket, and if > an INVITE with a yet unknown Call-ID arrives, it handles it in > a freshly > spawn dedicated thread. If several INVITEs come "at once" with an > individual Call-ID each, several threads get spawned "at once". > > P. > > Dne 04.10.2020 v 14:27 sshark wsk napsal(a): > > Hi Pavel, > > > > Thanks, yes I did go through that post and various other posts > > describing the challenges of running UAC & UAS for called > party.. > > As I mentioned, my plan for the called user is to keep different > > scenarios for register and process invites. > > > > I am struggling with the setup to continue to run called user to > > continuously process invites. Should I be just using labels to > > continue the loop in the "process invites" scenario ? > > > > //sshark > > > > On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel > <sin...@tt... <mailto:sin...@tt...>> wrote: > >> Hi sshark, > >> > >> could you please read > https://sourceforge.net/p/sipp/mailman/message/34707334/ first > if you haven't yet? > >> > >> I think I've put pretty much everything in there on how to > create "amphibious" scenarios behaving as both UAC and UAS, > which is what you need in order to create a scenario which > will register and keep updating the registration (as a UAC) > and answer incoming calls (as a UAS) while it stays bound to > the same local UDP socket. The need to stay bound to the same > socket explains why I deem all the timing to be done using > SIPp itself to be a better way than using bash scripts to > spawn execution of the scenarios. It's true, however, that on > the calling side you could spawn a registration, outgoing > call, and unregistration as three separate scenarios binding > to the same local port by shell script, but then you'd have to > use one socket per user. > >> > >> I didn't detail there the reasons why a Call-ID of a > REGISTER must be different from the one of the INVITE, but > normal SIP stacks should ignore or reject an INVITE with the > same Call-ID like one in a previously received REGISTER, at > least if it came soon enough after that REGISTER. > >> > >> So as you don't insist on the unregistrations at the called > side (from the point of view of traffic volume, registration > updates will generate 1/2 of the traffic volume as compared to > un-registrations and re-registrations with the same > periodicity), the A and B scenarios (or rather scenario pairs) > can be completely independent. Plus in the wild, an active > un-registration is a rare beast. > >> > >> There's just one point to the periodicity of the > registration updates, some registrars/SBCs have not only > maximum registration time but also a minimum one, and if you > attempt to register for a shorter time, they respond with "423 > interval too brief", so even if you'll be actually updating > the registration every minute, you have to indicate an Expires > value which will satisfy the SBC and/or registrar. > >> > >> So in my approach, the B scenario would optionally accept > and respond INVITEs (and possibly OPTIONS depending on the > behaiour of the system being tested) by a corresponding > branch, and mandatorily accept commands from the timer > instance and spawn another branch which would periodically > register. Eventually, that branch could accept a termination > command from the timer instance if you want the scenario group > to terminate autonomously after a predefined number of cycles > or amount of time (I've never tried the -m command line option > with a UAS scenario, maybe it works too). > >> > >> The A scenario would accept trigger commands from its own > timer scenario, where a single call in the timer scenario > would use two distinct Call-IDs in the commands it would send > to the executive scenario a few seconds apart: the first one > would be made up and would trigger the registration, the > second one would be the native one of the timer scenario and > would trigger the outgoing call. The random duration of the > outgoing call would be determined by the executive scenario, > which would send a command to the timer one as a notification > that the call has ended; in response to that, the timer would > send back a command with the made-up call ID to trigger the > unregistration. This way of synchronizing two threads within > the same scenario is the simplest one I could find throughout > the years. > >> > >> The overlapping would be provided by the -l 2 command line > option as I've suggested earlier (third call cannot start > until the first one ends). > >> > >> P. > >> > >> Dne 03.10.2020 v 6:11 sshark wsk napsal(a): > >> > >> Thanks for the email, The main goal for me is to keep some > constant > >> traffic on the SIP servers. I thought of having > >> registration/deregistration flows as they do invoke different > >> functions/procedures within the SIP server. If it > introduces too much > >> complexity, then I am happy with doing re-registration > rather than > >> de-register/register again... > >> > >> How can I approach in doing this, can sipp orchestrate this > or better > >> use shell script to do a loop and use sipp ? > >> > >> Thanks for your help.. > >> > >> On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel > <sin...@tt... <mailto:sin...@tt...>> wrote: > >> > >> Okay, the diagram shows clearly that the calls can and > should overlap. > >> > >> Is it an absolute must that the called side was > de-registering and > >> re-registering again for every call, or may it register in > the beginning > >> and keep renewing the registration periodically, and just > accept > >> incoming calls? If the unregistration of the called side is not > >> mandatory, this will remove the need for synchronization > between the A > >> side script and the B side script. > >> > >> P. > >> > >> Dne 30.09.2020 v 14:35 sshark wsk napsal(a): > >> > >> I have below setup available with me > >> Shell Script1: Handles A party > >> Scenario 1 - A user to register and send INVITE and handle > subsequent > >> messages (180, 200OK, ACK) and then deregister user > >> > >> Shell Script2: Handles B party > >> Scenario 2 - B user to register > >> Scenario 3 - B user to accept INVITE and handle appropriate > messages > >> (180, 200OK, ACK) > >> Scenario 4 - B user to de-register > >> > >> Have drafted a sequence diagram on what I had in mind. I > hope it > >> explains what I have in mind.. > >> > >> > >> > >> On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel > <sin...@tt... <mailto:sin...@tt...>> wrote: > >> > >> Do you want a single scenario to act as both A and B > subscribers or you plan to use two scenarios? The thing is > that if you want each user to unregister after the call, you > need to have some synchronization between the A and B side > even if each runs as a separate scenario on a different > machine, otherwise you'll find A knocking on a closed door at > B sooner or later. > >> > >> You also state contradictory requirements - if you want at > least one call "on air" at any given instant of time, the > calls must be overlapping, whereas unregistering An,Bn after a > call and then registering An+1,Bn+1 creates a gap between the > calls. So choose which one of these two requirements is more > important. > >> > >> My approach would be to use a timer scenario, sending sync > messages to both the A and B scenarios, with Call-IDs in the > sync messages generated from [call_number] so that the sync > message triggering the REGISTER at A and the one triggering > the INVITE at A would be sent by the same call at the timer > scenario but seen as two independent calls at the A scenario. > To choose the right row in the csv file, I'd compute the row > ID in the timing scenario and deliver it from there as a value > of some P-user-index header - this way, all the calculations > (call number modulo 5) would be done in the timer scenario and > the A and B scenarios would just use the value extracted from > that header in the synchronization messages. So you would not > need to start sipp in loops, you'd just specify the total > number of calls and number of calls per unit of time, and the > modulo 5 would do the rest of the job. > >> > >> I remember I was not able to make the 3PCC extended work > some years ago, so you may have tough time making three > scenarios (timer, A, B) work, but maybe it's not an issue any > more, or it even never was and it was just some mistake I > could not find in my setup. > >> > >> -l 2 option on the command line should make sure that not > more than two trigger calls will be active simultaneously, so > the third call should not start before the first one finishes. > >> > >> Pavel > >> > >> Dne 29.09.2020 v 14:07 sshark wsk napsal(a): > >> > >> Continuation to below thread, I have some additional questions > >> https://sourceforge.net/p/sipp/mailman/message/35176307/ > >> > >> I would like to know if anyone has some sample scenario > files for > >> 1. Have bunch of users for A (5) & B (5) > >> 2. Register B1 party and listen for INVITEs > >> 3. Register A1 party and setup call towards A party > >> 4. Keep the call predefined period/can be random (~10s) > >> 5. Terminate the call > >> 6. De-register A1 & B1 > >> 7. Continue to the next set of users - A2/B2, A3/B3, A4/B4, > A5/B5 > >> 8. Once list is exhausted, start from A1/B1 > >> > >> I am able to create the scenario file > (Register/call/answer), however > >> would like to get some hints on how to do the below > >> - How SIPp can be scheduled to run through a loop > >> - Our goal is to have at least 1 call through the network > at a given > >> point of time to simulate background testing > >> > >> Thank You in advance for any inputs/feedback > >> > >> > >> _______________________________________________ > >> Sipp-users mailing list > >> Sip...@li... > <mailto:Sip...@li...> > >> https://lists.sourceforge.net/lists/listinfo/sipp-users > >> > >> _______________________________________________ > >> Sipp-users mailing list > >> Sip...@li... > <mailto:Sip...@li...> > >> https://lists.sourceforge.net/lists/listinfo/sipp-users > |
From: sshark w. <ssh...@gm...> - 2020-10-28 09:24:10
|
I tried to use the scenario described in the link below, unfortunately my sipp crashes with segmentation fault. Have raised an issue in GitHub https://sourceforge.net/p/sipp/mailman/message/34707334/ Any other ways I can achieve what I initially posted... On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <ssh...@gm...> wrote: > I have the below. I guess for the called party, as I am finishing the > thread for registration adn then wait for INVITE in the same IP/port it > seems to work. Maybe it's not a good idea ? > Do you think the 3PCC scenario is the only way it will work for my > requirement ? > > *Server1 script* > bindIP=10.10.10.1 > port=5060 > ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf > ./register_and_call.xml -inf ./A_user.csv -trace_msg > > *Server2 script* > bindIP=10.10.10.2 > port=5061 > ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./reg.xml -inf > ./B_user_register.csv -trace_msg > ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./receive.xml > -inf ./B_user_answer.csv -trace_msg > > I also saw some other posting where you can run UAC & UAS with one > instance of the sipp. Does that work ? > https://github.com/SIPp/sipp/issues/362 > > > > On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel <sin...@tt...> wrote: > >> > my plan for the called user is to keep different >> > scenarios for register and process invites. >> But that's only possible if the tested device is fine with the REGISTER >> coming from a different socket than the one which is indicated in the >> Contact uri, as is the case with vanilla SIP. In real life environments, >> which I suppose you are going to test, the SBC stores the actual socket >> from which the REGISTER has arrived, and sends the INVITE to that stored >> socket regardless what was written in the Contact uri in the REGISTER. >> >> As you want the calls to overlap, the scenario expecting the INVITEs >> (and later on receiving or sending the BYEs) must be running >> continuously, so you cannot simultaneously send the REGISTERs from the >> same socket. >> >> > I am struggling with the setup to continue to run called user to >> > continuously process invites. Should I be just using labels to >> > continue the loop in the "process invites" scenario ? >> This sounds to me as if you haven't understood the relationship between >> threads and Call-IDs. At the beginning, the scenario receives an initial >> INVITE with some Call-ID yet unknown to it, so it spawns a new thread >> for that call, answers the INVITE with a 200, then receives or sends a >> BYE and responds it/gets it responded with a 200, and all that time the >> Call-ID stays attached to the thread. If there are no other messages to >> send or receive left in the scenario, the thread will end after some >> guard timer expires (which is there to handle eventual retransmissions >> of the BYE or the 200 to it if they arrive) and SIPp stops recognizing >> that Call-ID, but if you jump to the beginning of the scenario, the >> thread will expect another INVITE with the same Call-ID - which will >> never arrive (or at least should never arrive). >> >> So you don't need to do anything special in order that a scenario was >> ready for a new call. It just sits there listening at its socket, and if >> an INVITE with a yet unknown Call-ID arrives, it handles it in a freshly >> spawn dedicated thread. If several INVITEs come "at once" with an >> individual Call-ID each, several threads get spawned "at once". >> >> P. >> >> Dne 04.10.2020 v 14:27 sshark wsk napsal(a): >> > Hi Pavel, >> > >> > Thanks, yes I did go through that post and various other posts >> > describing the challenges of running UAC & UAS for called party.. >> > As I mentioned, my plan for the called user is to keep different >> > scenarios for register and process invites. >> > >> > I am struggling with the setup to continue to run called user to >> > continuously process invites. Should I be just using labels to >> > continue the loop in the "process invites" scenario ? >> > >> > //sshark >> > >> > On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel <sin...@tt...> wrote: >> >> Hi sshark, >> >> >> >> could you please read >> https://sourceforge.net/p/sipp/mailman/message/34707334/ first if you >> haven't yet? >> >> >> >> I think I've put pretty much everything in there on how to create >> "amphibious" scenarios behaving as both UAC and UAS, which is what you need >> in order to create a scenario which will register and keep updating the >> registration (as a UAC) and answer incoming calls (as a UAS) while it stays >> bound to the same local UDP socket. The need to stay bound to the same >> socket explains why I deem all the timing to be done using SIPp itself to >> be a better way than using bash scripts to spawn execution of the >> scenarios. It's true, however, that on the calling side you could spawn a >> registration, outgoing call, and unregistration as three separate scenarios >> binding to the same local port by shell script, but then you'd have to use >> one socket per user. >> >> >> >> I didn't detail there the reasons why a Call-ID of a REGISTER must be >> different from the one of the INVITE, but normal SIP stacks should ignore >> or reject an INVITE with the same Call-ID like one in a previously received >> REGISTER, at least if it came soon enough after that REGISTER. >> >> >> >> So as you don't insist on the unregistrations at the called side (from >> the point of view of traffic volume, registration updates will generate 1/2 >> of the traffic volume as compared to un-registrations and re-registrations >> with the same periodicity), the A and B scenarios (or rather scenario >> pairs) can be completely independent. Plus in the wild, an active >> un-registration is a rare beast. >> >> >> >> There's just one point to the periodicity of the registration updates, >> some registrars/SBCs have not only maximum registration time but also a >> minimum one, and if you attempt to register for a shorter time, they >> respond with "423 interval too brief", so even if you'll be actually >> updating the registration every minute, you have to indicate an Expires >> value which will satisfy the SBC and/or registrar. >> >> >> >> So in my approach, the B scenario would optionally accept and respond >> INVITEs (and possibly OPTIONS depending on the behaiour of the system being >> tested) by a corresponding branch, and mandatorily accept commands from the >> timer instance and spawn another branch which would periodically register. >> Eventually, that branch could accept a termination command from the timer >> instance if you want the scenario group to terminate autonomously after a >> predefined number of cycles or amount of time (I've never tried the -m >> command line option with a UAS scenario, maybe it works too). >> >> >> >> The A scenario would accept trigger commands from its own timer >> scenario, where a single call in the timer scenario would use two distinct >> Call-IDs in the commands it would send to the executive scenario a few >> seconds apart: the first one would be made up and would trigger the >> registration, the second one would be the native one of the timer scenario >> and would trigger the outgoing call. The random duration of the outgoing >> call would be determined by the executive scenario, which would send a >> command to the timer one as a notification that the call has ended; in >> response to that, the timer would send back a command with the made-up call >> ID to trigger the unregistration. This way of synchronizing two threads >> within the same scenario is the simplest one I could find throughout the >> years. >> >> >> >> The overlapping would be provided by the -l 2 command line option as >> I've suggested earlier (third call cannot start until the first one ends). >> >> >> >> P. >> >> >> >> Dne 03.10.2020 v 6:11 sshark wsk napsal(a): >> >> >> >> Thanks for the email, The main goal for me is to keep some constant >> >> traffic on the SIP servers. I thought of having >> >> registration/deregistration flows as they do invoke different >> >> functions/procedures within the SIP server. If it introduces too much >> >> complexity, then I am happy with doing re-registration rather than >> >> de-register/register again... >> >> >> >> How can I approach in doing this, can sipp orchestrate this or better >> >> use shell script to do a loop and use sipp ? >> >> >> >> Thanks for your help.. >> >> >> >> On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel <sin...@tt...> wrote: >> >> >> >> Okay, the diagram shows clearly that the calls can and should overlap. >> >> >> >> Is it an absolute must that the called side was de-registering and >> >> re-registering again for every call, or may it register in the >> beginning >> >> and keep renewing the registration periodically, and just accept >> >> incoming calls? If the unregistration of the called side is not >> >> mandatory, this will remove the need for synchronization between the A >> >> side script and the B side script. >> >> >> >> P. >> >> >> >> Dne 30.09.2020 v 14:35 sshark wsk napsal(a): >> >> >> >> I have below setup available with me >> >> Shell Script1: Handles A party >> >> Scenario 1 - A user to register and send INVITE and handle subsequent >> >> messages (180, 200OK, ACK) and then deregister user >> >> >> >> Shell Script2: Handles B party >> >> Scenario 2 - B user to register >> >> Scenario 3 - B user to accept INVITE and handle appropriate messages >> >> (180, 200OK, ACK) >> >> Scenario 4 - B user to de-register >> >> >> >> Have drafted a sequence diagram on what I had in mind. I hope it >> >> explains what I have in mind.. >> >> >> >> >> >> >> >> On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel <sin...@tt...> >> wrote: >> >> >> >> Do you want a single scenario to act as both A and B subscribers or >> you plan to use two scenarios? The thing is that if you want each user to >> unregister after the call, you need to have some synchronization between >> the A and B side even if each runs as a separate scenario on a different >> machine, otherwise you'll find A knocking on a closed door at B sooner or >> later. >> >> >> >> You also state contradictory requirements - if you want at least one >> call "on air" at any given instant of time, the calls must be overlapping, >> whereas unregistering An,Bn after a call and then registering An+1,Bn+1 >> creates a gap between the calls. So choose which one of these two >> requirements is more important. >> >> >> >> My approach would be to use a timer scenario, sending sync messages to >> both the A and B scenarios, with Call-IDs in the sync messages generated >> from [call_number] so that the sync message triggering the REGISTER at A >> and the one triggering the INVITE at A would be sent by the same call at >> the timer scenario but seen as two independent calls at the A scenario. To >> choose the right row in the csv file, I'd compute the row ID in the timing >> scenario and deliver it from there as a value of some P-user-index header - >> this way, all the calculations (call number modulo 5) would be done in the >> timer scenario and the A and B scenarios would just use the value extracted >> from that header in the synchronization messages. So you would not need to >> start sipp in loops, you'd just specify the total number of calls and >> number of calls per unit of time, and the modulo 5 would do the rest of the >> job. >> >> >> >> I remember I was not able to make the 3PCC extended work some years >> ago, so you may have tough time making three scenarios (timer, A, B) work, >> but maybe it's not an issue any more, or it even never was and it was just >> some mistake I could not find in my setup. >> >> >> >> -l 2 option on the command line should make sure that not more than >> two trigger calls will be active simultaneously, so the third call should >> not start before the first one finishes. >> >> >> >> Pavel >> >> >> >> Dne 29.09.2020 v 14:07 sshark wsk napsal(a): >> >> >> >> Continuation to below thread, I have some additional questions >> >> https://sourceforge.net/p/sipp/mailman/message/35176307/ >> >> >> >> I would like to know if anyone has some sample scenario files for >> >> 1. Have bunch of users for A (5) & B (5) >> >> 2. Register B1 party and listen for INVITEs >> >> 3. Register A1 party and setup call towards A party >> >> 4. Keep the call predefined period/can be random (~10s) >> >> 5. Terminate the call >> >> 6. De-register A1 & B1 >> >> 7. Continue to the next set of users - A2/B2, A3/B3, A4/B4, A5/B5 >> >> 8. Once list is exhausted, start from A1/B1 >> >> >> >> I am able to create the scenario file (Register/call/answer), however >> >> would like to get some hints on how to do the below >> >> - How SIPp can be scheduled to run through a loop >> >> - Our goal is to have at least 1 call through the network at a given >> >> point of time to simulate background testing >> >> >> >> Thank You in advance for any inputs/feedback >> >> >> >> >> >> _______________________________________________ >> >> Sipp-users mailing list >> >> Sip...@li... >> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> >> >> >> _______________________________________________ >> >> Sipp-users mailing list >> >> Sip...@li... >> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> >> |
From: Šindelka P. <sin...@tt...> - 2020-10-27 22:27:20
|
Exactement. P. Dne 27.10.2020 v 21:21 Olivier Thomas napsal(a): > Hi Pawel ! > > You means something like that : > > <nop> > <action> > <!-- $enabled=true if [field0]=1 --> > <test assign_to="enabled" variable="[field0]" compare="equal" > value="1" /> > </action> > </nop> > > *<!-- Send INVITE with SDP with Header P-My-Header-->* > <send retrans="500" start_rtd="PDD" *condexec="enabled"*> > <![CDATA[ > > INVITE sip:[service]@[remote_ip] SIP/2.0 > Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] > From: > <sip:[field0]@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number] > To: <sip:[service]@[remote_ip]> > Call-ID: [call_id] > P-Asserted-Identity: <tel:2245061> > Supported: 100rel > User-Agent: SIPp-UAC > Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, PUBLISH > CSeq: 1 INVITE > Contact: <sip:[field0]@[local_ip]:[local_port]> > Max-Forwards: 70 > > *P-My-Header: myValue* > > Content-Type: application/sdp > Content-Length: [len] > > v=0 > o=uac [call_number] 2353687637 IN IP[local_ip_type] [local_ip] > s=- > c=IN IP[media_ip_type] [media_ip] > t=0 0 > m=audio [media_port] RTP/AVP 8 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ptime:20 > > ]]> > </send> > > *<!-- Send INVITE with SDP without Header P-My-Header -->* > <send retrans="500" start_rtd="PDD"*condexec="enabled" > condexec_inverse="true"*> > <![CDATA[ > > INVITE sip:[service]@[remote_ip] SIP/2.0 > Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] > From: > <sip:[field0]@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number] > To: <sip:[service]@[remote_ip]> > Call-ID: [call_id] > P-Asserted-Identity: <tel:2245061> > Supported: 100rel > User-Agent: SIPp-UAC > Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, PUBLISH > CSeq: 1 INVITE > Contact: <sip:[field0]@[local_ip]:[local_port]> > Max-Forwards: 70 > Content-Type: application/sdp > Content-Length: [len] > > v=0 > o=uac [call_number] 2353687637 IN IP[local_ip_type] [local_ip] > s=- > c=IN IP[media_ip_type] [media_ip] > t=0 0 > m=audio [media_port] RTP/AVP 8 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ptime:20 > > ]]> > </send> > > *Olivier Thomas* > > 18 rue Guyon de Guercheville > Hérouville Saint-Clair > Tél : 06 16 44 92 57 > oli...@gm... <mailto:oli...@gm...> > > > > Le mar. 27 oct. 2020 à 20:16, Šindelka Pavel <sin...@tt... > <mailto:sin...@tt...>> a écrit : > > Maybe there are other possibilities, but I would use two INVITE > templates, with and without the P-My-Header, and send one ot the > other depending on the variable setting. > > P. > > Dne 27.10.2020 v 20:01 Olivier Thomas napsal(a): >> Hello guys, >> >> Does someone know if there is a way to make a private header >> optional in a SIPp scenario ? >> >> I would like to add a private header "P-My-Header" in the INVITE >> requests only if a variable is set. >> >> For instance, I would like to add this header only if the >> [field0] from my input CSV file is equal to 0. >> If [field0] is equal to any other value, the header "P-My-Header" >> will not be added in INVITE requests. >> >> Or maybe do you know a better way to do the same thing... ? >> >> Thanks a lot for your help! >> Regards, >> >> *Olivier Thomas* >> >> oli...@gm... <mailto:oli...@gm...> >> >> >> >> _______________________________________________ >> Sipp-users mailing list >> Sip...@li... <mailto:Sip...@li...> >> https://lists.sourceforge.net/lists/listinfo/sipp-users > _______________________________________________ > Sipp-users mailing list > Sip...@li... > <mailto:Sip...@li...> > https://lists.sourceforge.net/lists/listinfo/sipp-users > |
From: Olivier T. <oli...@gm...> - 2020-10-27 20:58:52
|
Ok, thanks! Le mar. 27 oct. 2020 à 21:52, Šindelka Pavel <sin...@tt...> a écrit : > Exactement. > > P. > Dne 27.10.2020 v 21:21 Olivier Thomas napsal(a): > > Hi Pawel ! > > You means something like that : > > <nop> > <action> > <!-- $enabled=true if [field0]=1 --> > <test assign_to="enabled" variable="[field0]" compare="equal" > value="1" /> > </action> > </nop> > > *<!-- Send INVITE with SDP with Header P-My-Header-->* > <send retrans="500" start_rtd="PDD" *condexec="enabled"*> > <![CDATA[ > > INVITE sip:[service]@[remote_ip] SIP/2.0 > Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] > From: <sip:[field0]@[local_ip]:[local_port]> > ;tag=[pid]SIPpTag00[call_number] > To: <sip:[service]@[remote_ip]> > Call-ID: [call_id] > P-Asserted-Identity: <tel:2245061> <2245061> > Supported: 100rel > User-Agent: SIPp-UAC > Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, PUBLISH > CSeq: 1 INVITE > Contact: <sip:[field0]@[local_ip]:[local_port]> > Max-Forwards: 70 > > * P-My-Header: myValue* > > Content-Type: application/sdp > Content-Length: [len] > > v=0 > o=uac [call_number] 2353687637 IN IP[local_ip_type] [local_ip] > s=- > c=IN IP[media_ip_type] [media_ip] > t=0 0 > m=audio [media_port] RTP/AVP 8 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ptime:20 > > ]]> > </send> > > *<!-- Send INVITE with SDP without Header P-My-Header -->* > <send retrans="500" start_rtd="PDD"* condexec="enabled" > condexec_inverse="true"*> > <![CDATA[ > > INVITE sip:[service]@[remote_ip] SIP/2.0 > Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] > From: <sip:[field0]@[local_ip]:[local_port]> > ;tag=[pid]SIPpTag00[call_number] > To: <sip:[service]@[remote_ip]> > Call-ID: [call_id] > P-Asserted-Identity: <tel:2245061> <2245061> > Supported: 100rel > User-Agent: SIPp-UAC > Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, PUBLISH > CSeq: 1 INVITE > Contact: <sip:[field0]@[local_ip]:[local_port]> > Max-Forwards: 70 > Content-Type: application/sdp > Content-Length: [len] > > v=0 > o=uac [call_number] 2353687637 IN IP[local_ip_type] [local_ip] > s=- > c=IN IP[media_ip_type] [media_ip] > t=0 0 > m=audio [media_port] RTP/AVP 8 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ptime:20 > > ]]> > </send> > > *Olivier Thomas* > 18 rue Guyon de Guercheville > Hérouville Saint-Clair > Tél : 06 16 44 92 57 > oli...@gm... > > > Le mar. 27 oct. 2020 à 20:16, Šindelka Pavel <sin...@tt...> a écrit : > >> Maybe there are other possibilities, but I would use two INVITE >> templates, with and without the P-My-Header, and send one ot the other >> depending on the variable setting. >> >> P. >> Dne 27.10.2020 v 20:01 Olivier Thomas napsal(a): >> >> Hello guys, >> >> Does someone know if there is a way to make a private header optional in >> a SIPp scenario ? >> >> I would like to add a private header "P-My-Header" in the INVITE requests >> only if a variable is set. >> >> For instance, I would like to add this header only if the [field0] from >> my input CSV file is equal to 0. >> If [field0] is equal to any other value, the header "P-My-Header" will >> not be added in INVITE requests. >> >> Or maybe do you know a better way to do the same thing... ? >> >> Thanks a lot for your help! >> Regards, >> >> *Olivier Thomas* >> oli...@gm... >> >> >> _______________________________________________ >> Sipp-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sipp-users >> >> _______________________________________________ >> Sipp-users mailing list >> Sip...@li... >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> > |
From: Olivier T. <oli...@gm...> - 2020-10-27 20:22:05
|
Hi Pawel ! You means something like that : <nop> <action> <!-- $enabled=true if [field0]=1 --> <test assign_to="enabled" variable="[field0]" compare="equal" value="1" /> </action> </nop> *<!-- Send INVITE with SDP with Header P-My-Header-->* <send retrans="500" start_rtd="PDD" *condexec="enabled"*> <![CDATA[ INVITE sip:[service]@[remote_ip] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: <sip:[field0]@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number] To: <sip:[service]@[remote_ip]> Call-ID: [call_id] P-Asserted-Identity: <tel:2245061> Supported: 100rel User-Agent: SIPp-UAC Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH CSeq: 1 INVITE Contact: <sip:[field0]@[local_ip]:[local_port]> Max-Forwards: 70 * P-My-Header: myValue* Content-Type: application/sdp Content-Length: [len] v=0 o=uac [call_number] 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 ]]> </send> *<!-- Send INVITE with SDP without Header P-My-Header -->* <send retrans="500" start_rtd="PDD"* condexec="enabled" condexec_inverse="true"*> <![CDATA[ INVITE sip:[service]@[remote_ip] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: <sip:[field0]@[local_ip]:[local_port]>;tag=[pid]SIPpTag00[call_number] To: <sip:[service]@[remote_ip]> Call-ID: [call_id] P-Asserted-Identity: <tel:2245061> Supported: 100rel User-Agent: SIPp-UAC Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH CSeq: 1 INVITE Contact: <sip:[field0]@[local_ip]:[local_port]> Max-Forwards: 70 Content-Type: application/sdp Content-Length: [len] v=0 o=uac [call_number] 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 ]]> </send> *Olivier Thomas* 18 rue Guyon de Guercheville Hérouville Saint-Clair Tél : 06 16 44 92 57 oli...@gm... Le mar. 27 oct. 2020 à 20:16, Šindelka Pavel <sin...@tt...> a écrit : > Maybe there are other possibilities, but I would use two INVITE templates, > with and without the P-My-Header, and send one ot the other depending on > the variable setting. > > P. > Dne 27.10.2020 v 20:01 Olivier Thomas napsal(a): > > Hello guys, > > Does someone know if there is a way to make a private header optional in a > SIPp scenario ? > > I would like to add a private header "P-My-Header" in the INVITE requests > only if a variable is set. > > For instance, I would like to add this header only if the [field0] from my > input CSV file is equal to 0. > If [field0] is equal to any other value, the header "P-My-Header" will not > be added in INVITE requests. > > Or maybe do you know a better way to do the same thing... ? > > Thanks a lot for your help! > Regards, > > *Olivier Thomas* > oli...@gm... > > > _______________________________________________ > Sipp-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sipp-users > > _______________________________________________ > Sipp-users mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/sipp-users > |
From: Šindelka P. <sin...@tt...> - 2020-10-27 19:15:32
|
Maybe there are other possibilities, but I would use two INVITE templates, with and without the P-My-Header, and send one ot the other depending on the variable setting. P. Dne 27.10.2020 v 20:01 Olivier Thomas napsal(a): > Hello guys, > > Does someone know if there is a way to make a private header optional > in a SIPp scenario ? > > I would like to add a private header "P-My-Header" in the INVITE > requests only if a variable is set. > > For instance, I would like to add this header only if the [field0] > from my input CSV file is equal to 0. > If [field0] is equal to any other value, the header "P-My-Header" will > not be added in INVITE requests. > > Or maybe do you know a better way to do the same thing... ? > > Thanks a lot for your help! > Regards, > > *Olivier Thomas* > > oli...@gm... <mailto:oli...@gm...> > > > > _______________________________________________ > Sipp-users mailing list > Sip...@li... > https://lists.sourceforge.net/lists/listinfo/sipp-users |