Hi folks, I am still looking for a solution to set up a call between two SIPp instances (first as a caller and second as a callee). Let me know please if anyone has successfully done this. Thanks.
Kind Regards, Junaid On Tue, Dec 11, 2018 at 3:37 PM Junaid Ali <junaidaliya...@gmail.com> wrote: > Hi Mark, > > The link you shared suggests having two different scenario files for > registration and call setup. So, I created these files on the callee machine > register.xml: http://ix.io/1vOj > call-set-up.xml: http://ix.io/1vOk > > While initiating the registration scenario with a small pause or without > any pause at the end of register.xml, SIPp command on caller machine fails > with 430 Flow error. I think that error is due to the termination of the > SIPp process which is responsible for registration on the callee machine > before the INVITE signal from the caller. > > If I add a large pause to keep the registration process alive for a bit > longer on the callee node, I face this error again: > <http://goog_643911926>http://ix.io/1vNj . One thing I have observed is > that INVITE signal is captured by the registration SIPp process instead of > the call setup SIPp process on the callee machine. Check the image here > please: https://i.imgur.com/jlFv7mD.jpg , where the upper window is for > registration and in the lower window I'm running the call set up scenario. > > I'm not passing the '-aa' parameter to the SIPp tool which is suggested > in the link because then we face the issue you mentioned in your reply#2. > > Kind Regards, > Junaid > > > On Tue, Dec 11, 2018 at 1:29 PM Junaid Ali <junaidaliya...@gmail.com> > wrote: > >> Hi Mark, >> >> I read this issue earlier and separated the registration and call set up >> in two different scenario files on the callee machine, but I was getting >> the same error. Let me separate the registration and call set up on caller >> machine as well please and see if there is any effect. Thanks a lot for >> looking into this issue. >> >> Kind Regards, >> Junaid >> >> On Tue, Dec 11, 2018 at 1:24 PM Mark Perryman < >> mark.perry...@metaswitch.com> wrote: >> >>> Junaid, >>> >>> >>> >>> You are encountering this problem. >>> https://github.com/SIPp/sipp/issues/199 >>> >>> >>> >>> There seem to be suggestions of what to try. >>> >>> >>> >>> Mark Perryman. >>> >>> >>> >>> *From:* Clearwater <clearwater-boun...@lists.projectclearwater.org> *On >>> Behalf Of *Junaid Ali >>> *Sent:* 11 December 2018 12:18 >>> *To:* clearwater@lists.projectclearwater.org >>> *Subject:* Re: [Project Clearwater] Initiating calls between two SIPp >>> instances >>> >>> >>> >>> Hi Mark, >>> >>> Just found the cause of that 200 OK response. Actually, I was using >>> "-aa" as an argument to SIPp tool on the callee machine. The man page of >>> SIPp for '-aa' argument says: "Enable automatic 200 OK answer for INFO, >>> UPDATE and NOTIFY messages." >>> >>> >>> >>> I have removed the '-aa' parameter, but now I'm getting this error on >>> the callee machine: http://ix.io/1vNj. I googled a little bit about >>> this error and it seems to me that this might be due to different call-ids >>> on caller and callee responses. SIPp output for callee: >>> http://ix.io/1vNl >>> >>> >>> >>> On caller node, I'm getting 408 Timeout error for INVITE sig: >>> http://ix.io/1vNn >>> >>> >>> >>> Sprout logs: http://ix.io/1vNg >>> >>> Bono logs: http://ix.io/1vNh >>> >>> >>> >>> Kind Regards, >>> Junaid >>> >>> >>> >>> On Tue, Dec 11, 2018 at 11:25 AM Junaid Ali <junaidaliya...@gmail.com> >>> wrote: >>> >>> Let me check and get back to you in a few minutes please. >>> >>> >>> >>> On Tue, Dec 11, 2018 at 11:23 AM Mark Perryman < >>> mark.perry...@metaswitch.com> wrote: >>> >>> So bono’s log >>> >>> 11-12-2018 10:27:40.054 UTC Verbose common_sip_processing.cpp:136: TX 2739 >>> bytes Request msg INVITE/cseq=4 (tdta0x7fc5f0052330) to TCP >>> 192.168.120.12:60900: >>> >>> suggests that the INVITE is sent to the callee. >>> >>> >>> >>> Something is then responding 200 OK >>> >>> 11-12-2018 10:27:40.055 UTC Verbose common_sip_processing.cpp:120: RX 689 >>> bytes Response msg 200/INVITE/cseq=4 (rdata0x7fc5f80046f0) from TCP >>> 192.168.120.12:60900: >>> >>> >>> >>> Is something else running on the callee machine that might be responding >>> instead of the SIPp script. >>> >>> >>> >>> Mark. >>> >>> >>> >>> *From:* Clearwater <clearwater-boun...@lists.projectclearwater.org> *On >>> Behalf Of *Junaid Ali >>> *Sent:* 11 December 2018 10:50 >>> *To:* clearwater@lists.projectclearwater.org >>> *Subject:* Re: [Project Clearwater] Initiating calls between two SIPp >>> instances >>> >>> >>> >>> Hi Mark, >>> >>> >>> >>> Apologies for the late reply. I have tried the above scenario files as >>> well but couldn't make the call work. >>> >>> I'm registering a number on the caller and callee machines for >>> initiating the calls using this csv file: http://ix.io/1vMI >>> >>> >>> >>> Here is the scenario file on caller machine: http://ix.io/1vME >>> >>> which first registers a number (2010000000) and then send an invite to >>> callee machine. >>> >>> >>> >>> On callee machine, I'm registering a number (2010000002) and waiting for >>> the call to establish using this scenario file: http://ix.io/1vMF >>> >>> >>> >>> The SIPp output on the callee machine looks like this: http://ix.io/1vMK >>> which >>> shows that it gets timeout waiting for INVITE from the caller. >>> >>> The output of /var/log/clearwater-sipp/sip-stress_6766_errors.log on >>> callee is: http://ix.io/1vMO >>> >>> which suggests that INVITE is received on the callee machine but it >>> doesn't get reflected in the SIPp output. >>> >>> >>> >>> The SIPp output the caller machine is: http://ix.io/1vML >>> >>> >>> >>> Bono output at log_level=5: http://ix.io/1vMN >>> >>> Sprout output at log_level=5: http://ix.io/1vMM >>> >>> >>> >>> I'm not sure if I'm missing anything in my scenario file since I don't >>> observe any error messages in bono and sprout logs. Your help is much >>> appreciated. >>> >>> >>> >>> Kind Regards, >>> Junaid >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Dec 7, 2018 at 4:10 PM Mark Perryman < >>> mark.perry...@metaswitch.com> wrote: >>> >>> The basic client and server scripts that ship with SIPp itself should be >>> suitable. >>> >>> >>> >>> http://sipp.sourceforge.net/ >>> >>> http://sipp.sourceforge.net/doc/reference.html#UAC >>> >>> http://sipp.sourceforge.net/doc/reference.html#UAS >>> >>> >>> >>> Hope that helps, let me know if that doesn’t work. >>> >>> >>> >>> Mark Perryman. >>> >>> >>> >>> *From:* Clearwater <clearwater-boun...@lists.projectclearwater.org> *On >>> Behalf Of *Junaid Ali >>> *Sent:* 04 December 2018 14:10 >>> *To:* clearwater@lists.projectclearwater.org >>> *Subject:* [Project Clearwater] Initiating calls between two SIPp >>> instances >>> >>> >>> >>> Hi guys, >>> >>> I am trying to create a call between two SIPp instances (caller and >>> callee) using Clearwater IMS. Can anyone share the scenario files for >>> caller and callee please if anyone has tried the same scenario? >>> >>> >>> >>> I have looked at the default scenario file which is present in the >>> sip-stress package but that emulates the same node as both caller and >>> callee. >>> >>> >>> >>> Any help would be really appreciated. Thanks. >>> >>> >>> >>> Kind Regards, >>> Junaid >>> >>> >>> >>> _______________________________________________ >>> Clearwater mailing list >>> Clearwater@lists.projectclearwater.org >>> >>> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org >>> >>> _______________________________________________ >>> Clearwater mailing list >>> Clearwater@lists.projectclearwater.org >>> >>> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org >>> >>> _______________________________________________ >>> Clearwater mailing list >>> Clearwater@lists.projectclearwater.org >>> >>> http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org >>> >>
_______________________________________________ Clearwater mailing list Clearwater@lists.projectclearwater.org http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
