On 05/06/14 19:13, Mahudeswaran A wrote: > Hi Rob, > In sequel to the above mail, we did used the attached scenario file, > [cid:image001.png@01CF8117.CDE96650] > Would like to understand from the above snap shot > > If you look at step5, the BYE is received from UAS, why the ‘Retrans’ keeps > increasing; how is ‘Retrans’ plays a role in receive end!! > > Thanks & Regards > Mahu > From: Mahudeswaran A > Sent: 05 June 2014 12:21 > To: 'Rob Day' > Cc: sipp-users@lists.sourceforge.net > Subject: RE: [Sipp-users] sipp not generating calls after a point;!! > > Hi Rob, > Please find the attached scenario file; > We are trying for the below call scenario in the load setup > > 1.SIPp(uac) will initiate “1-call-per-second—call-duration-60-seconds” to our > sip server > 2.Our sip application will answer the call and sipp-uac will wait for 60 > seconds > 3.After 60secs sipp drop the call;
Hi Mahu, In answer to your question about 'Retrans' - when SIPp is receiving a message, the Retrans column indicates how many times the peer has retransmitted that message. In your screenshot, the incoming BYE has been resent 15,836 times by the other end, and correspondingly, SIPp has resent the 200 OK (step 8) 15,836 times. (Note that the screenshot attached to your last email doesn't match the scenario file you sent before - it expects to receive a BYE as well as send one). I've also taken a look at your original screenshot again (attached for reference), and it appears that some of your INVITEs have just vanished. Note that you have sent 14,970 INVITEs, and have received 11,305 200 OKs, received 2693 unexpected messages instead of the 100 Trying, and 872 unexpected messages instead of the 180 Ringing - a total of just 14,870 responses. This is why SIPp thinks 100 calls are still in progress and is failing to make any more calls. (You previously said that the BYE was not sent, but I think this is wrong - of the 11,305 calls that are correctly established, 1,401 fail due to an unexpected message during the pause, and the other 9,904 do have BYEs sent, so all 11,305 are accounted for). From your screenshot, I see that you're using UDP - but you've removed the retrans="500" attribute from the INVITE in your scenario file, which is needed to make the unreliable UDP transport work reliably. That is, I think what's happening here is that occasionally a UDP packet containing an INVITE is lost due to network unreliability, and because you have no retransmission timer, that call just hangs. Eventually, 100 calls get into this state, and SIPp can't make any more. If you add this attribute back in, or switch to using TCP, I expect you'll stop seeing this problem. Best, Rob
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
