Message type 0x8003 received from partner is the "res_call_info" remote message. It is apparently received by your modified ims_uac at step 48 (ims_uac:48) where, if I counted correctly, it's expecting the 200 response to its BYE. So what seems to be happening is that, for some reason, the 200 response is lost between UAS and UAC and the UAC does not retransmit its BYE (or this one is lost too, or the new 200 response is lost again...) during the 4 seconds that the UAS waits before sending its call info report to the partner UAC scenario instance. Hence this final 'res_call_info' UAS message (not a SIP message, an inter SIPp client message) reaches the UAC when it is still expecting the 200 response.
Your log actually shows other errors which may or may not be the consequence of the above one. Also, as often with IMS Bench SIPp, when scenario attempts regularly fail during a run, you end up running out of users since the users selected for the failed scenario attempts are not put back into the appropriate pool (for this to work even under error conditions, you'd need to cover all errors cases and this would be hardly achievable using the simple SIPp XML scenario approach - what is the right pool when a registration fails?). Since your load is still fairly low, I suggest you trace the messages using wireshark, look for the reported failed scenario attempts (based on their CallId) and try to understand what went wrong for them. Regards, -David ________________________________ From: Dushyant Dhalia [mailto:[email protected]] Sent: jeudi 23 juillet 2009 9:05 To: [email protected] Subject: [Sipp-users] Problem running load at IMS_Bench I am running load using IMS_Bench, 25cps for 20 hours with 2500 registered subs, call holding time 10 seconds. The load runs fine for a few hours but after that it stops. Some of the error messages that are logged in /usr/local/sipp/*_errors.log are - 2009-07-22 18:26:46.068: C:'[email protected]<mailto:[email protected]>' ERROR RECVRMT m=0x8003 at ims_uac:48-> aborting call!. 2009-07-22 18:30:40.266: C:'[email protected]<mailto:[email protected]>', T/O ims_uac:50 without ontimeout. 2009-07-22 18:32:57.453: No call found for partner_call_number [39103]. 2009-07-22 18:33:35.909: C:'[email protected]<mailto:[email protected]>' ERROR RECVRMT m=0x8003 at ims_uac:48-> aborting call!. 2009-07-22 18:36:53.442: Call '[email protected]<mailto:[email protected]>' - Continuing on an unexpected BYE. 2009-07-22 18:57:37.031: RmtRtdParmInfo(rtd=1) start_time not set!. 2009-07-22 18:57:37.031: RtdEvalAction: one or more specified remote RTD_INFO parameters not found!. 2009-07-22 21:05:57.948: No call found for partner_call_number [497417]. These messages were received intermittently and after about 16 hours the user_pool exhausted and following message was printed - 2009-07-23 09:59:00.357: User pool id[2] is empty -> Quitting!. 2009-07-23 09:59:00.357: Quitting!. 2009-07-23 09:59:00.357: Call '[email protected]<mailto:[email protected]>' - pick_user() returned NULL. 2009-07-23 09:59:00.357: Call '[email protected]<mailto:[email protected]>' - Action 'move_user' without a user assigned!. My question is why should such messages be received for some calls while other calls are working fine? Is there any timer/configurable parameter which need to be tuned? Manager.log, manager.xml, *_errors.log are attached. Dushyant P S Dhalia --------------------------------------------------------------------- Intel Corporation NV/SA Rond point Schuman 6, B-1040 Brussels RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
------------------------------------------------------------------------------
_______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
