Hi Robert,
if the scenario you've provided is a verbatim copy of the one you actually use, not an edited version for illustration purposes, the trouble is that you blindly fire a series of requests without waiting for any response from the server. Normally, the authentication challenge comes in a 401 or 407 response to the first INVITE, and the generation of the authentication response as requested by the [authentication] keyword depends on the information from the authentication challenge. So you must insert some optional and mandatory <recv> statements between the first INVITE and first ACK - namely, <recv response="100" optional="true"/> <recv response="401" optional="true" auth="true" next="auth_challenge_received"/> <recv response="407" auth="true"/> <label id="auth_challenge-received"/> This ensures that regardless whether the sipx device sends the 100 or not, and regardless whether it uses 401 or 407 to send the authentication challenge, you'll handle it properly. Also, remove the auth="true" AVPs from all the <send> blocks, they are useless there. On top of that, please <recv> optionally a 100, a 180, a 183 and then compulsorily a 200 between sending the second INVITE (with the authentication response) and sending the second ACK, otherwise you may run into some other issues. And the last point, if you specify user and password inside the scenario, SIPp does not use the -au and -ap specified on the command line. Pavel ------------------------------------------------------------------------------ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
