#14 enhanced AUTH feature

[bbyrd74]

The current version of SIPp cannot auth multiple
registrations (one for each unique user) due to it
incrementing the nonce count, even though the dialog is
a new dialog.

I have the need to test capacity and performance of a
registrar that can handle 100000 configured and active
accounts. I have created 100000 accounts in the registrar.

I have also created a CSV file with each individual
username and auth password field.

I am using a simple .xml file that is used for each
auth attempt (register, 401, ack, register, 200)

This test works fine for "-m 1", but as soon as the
second account is tried to be authenticated, the
registrar under test sends back another 401 because
SIPP used nc=00000002

But since this was a completely new user/dialog/callID,
the nonce should have been nc=00000001

Will this be an option for the future?

[Olivier Jacques]

Logged In: YES
user_id=999021

As cnonce is random, I agree that nc should not be
incremented as there is very little chance that cnonce will
be the same twice (and will be an issue anyway).
So, I have removed the incrementation of nc - fixed in rev
55 (sipp.2006-10-16).

[bbyrd74]

Logged In: YES
user_id=1614898

Perhaps it would be best to put in logic to select whether
or not to increase the NC at the testers discretion.

Sometimes a test would require the NC to increment
(reregistrations). Sometimes a test would require it to not
be incremented (different users registering one after another)

So maybe we need the NC to only increment per transaction of
each unique users dialogs?

[Olivier Jacques]

Logged In: YES
user_id=999021

According to RFC 2617,
" nonce-count
This MUST be specified if a qop directive is sent (see
above), and MUST NOT be specified if the server did not send
a qop directive in the WWW-Authenticate header field. The
nc-value is the hexadecimal count of the number of requests
(including the current request) that the client has sent
with the nonce value in this request. For example, in the
first request sent in response to a given nonce value, the
client sends "nc=00000001". The purpose of this directive
is to allow the server to detect request replays by
maintaining its own copy of this count - if the same c-value
is seen twice, then the request is a replay. See the
description below of the construction of the request-digest
value."
My understanding is that the nc is per nonce. Today, nonce
is generated randomly (rand()) by SIPp and not kept in any
context.
Do you feel this should change? If yes, would you be willing
to provide a patch?