I’m using the OpenSIPS Load_Balancer module for the incoming calls to an Asterisk cluster. When an INVITE is sent to one of the Asterisks, we receive the “401 Unauthorized” message from that server. But when UAC sends the INVITE with the authorization, the LB-module sends it to another Asterisk and this Asterisk requires authorization again, although the INVITE already has a Digest
It is up to the load balancer to ensure that all requests for a particular incoming call go to the same worker, typically by making the worker be a function of something in the request. I don’t believe there is anything in the SIP RFC that would result in anything being added to the 401 response that would indicate which worker was handling the request.
Although not entirely clear on a quick reading, I believe the resubmitted request should be the same, including caller ID, except for Authorization header, and CSeq, as the original one, and that is what should allow the balancer to select the correct worker.
That can’t be the first requests, as the first request wouldn’t include an authorization header
I understand the message flows. Only the load balancer can ensure that a resubmission of a request goes to the same place as the original submission.
Because each Asterisk generates its own nonces, so the nonce that Ast 2 receives is not the nonce that it has recently sent; it is the one that Ast 1 sent. Ast 2 will treat it the same as a stale nonce, and will send its current nonce, in the 401.
If you have a cluster of ASterisk servers, each box from the cluster should be able to handle the auth response, even if the challenge was done by a different one. Otherwise it is not a cluster, but a bunch of servers.
That is essential. The nonce in the digest allows the UAS to distinguish between a stale nonce and a bad password, and the whole purpose of the nonce is to guard against replay attacks.
You don’t want Asterisk clustering, there are things for it, but why distribute insanity?
For this scenario you probably want Opensips dispatcher module, set the right algorithm and it’ll work.
The key part is ds_select_dst. You’re looking more at the hash over algorithms most likely as those ID’s are going to be consistent between invites.