Hello!
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
Thanks in advance!
That seems to be a problem with the load balancer, not with Asterisk.
why )
This is the message that LB sends to Asterisk as the first INVITE:
INVITE sip:101@vvvv.com:5061;transport=TLS SIP/2.0
Record-Route: sip:10.0.0.2:5060;lr;did=cab.8cec67d2;r2=on
Record-Route: sip:195.16.47.47:5061;transport=tls;lr;did=cab.8cec67d2;r2=on
Via: SIP/2.0/UDP 195.16.47.47:5060;branch=z9hG4bK0eb7.101e6e71.0;i=53625634
Via: SIP/2.0/TLS 192.168.1.71:56703;received=8.33.46.89;branch=z9hG4bK-d8754z-d5bcc969cd49431a-1—d8754z-;rport=53817
Max-Forwards: 69
Contact: sip:9f3ee6b6-30ee-4070-97bf-9bac3fcf8587109@8.33.46.89:53817;transport=TLS
To: sip:101@vvvv.com:5061;transport=TLS
From: sip:9f3ee6b6-30ee-4070-97bf-9bac3fcf8587109@vvvv.com:5061;transport=TLS;tag=a9f0c876
Call-ID: OGRlODZkMDJhMTMzZTI5N2I0MjYwNWIwODM2MjUyOGU.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.21937 r21903
Authorization: Digest username=“9f3ee6b6-30ee-4070-97bf-9bac3fcf8587109”,realm=“2sipagent”,nonce=“1662634024/be0596b72e829cc6f83f70efd1831d7c”,uri=“sip:101@vvvv.com:5061;transport=TLS”,response=“2b90e5460808bbe22f541396afe0a599”,cnonce=“5f0480405041fea99702bc5883f0aaa4”,nc=00000001,qop=auth,algorithm=MD5,opaque=“63737d1b6d
3a25”
Allow-Events: presence, kpml
Content-Length: 358v=0
o=Z 0 0 IN IP4 10.0.0.5
s=Z
c=IN IP4 10.0.0.5
t=0 0
m=audio 17414 RTP/AVP 18 3 110 8 0 98 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:110 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=rtcp:17415
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
UAC (INVITE w/o auth) → OpenSIPS (LB: Ast_1) → Ast_1 (401 Unauth)
UAC (INVITE with auth) → OpenSIPS (LB: Ast_2) → Ast_2 (401 Unauth)
… etc, until LB selects the same Asterisk for two INVITE`s (w/o auth and with auth).
My question is: why does the Ast_2 send 401 if the second INVITE has Digest?
P. S. Asterisk-18.13.0, PJSIP
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.
Even if there is the nonce in Digest?
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.
This is the answer from the OpenSIPS developer:
Hi Vadim,
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.
Regards,
Bogdan-Andrei Iancu
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.
I agree. But now I’m in this situation …
I’ve never heard of Asterisk supporting clustering to the level that Bogdan-Andrei is referring. Could you point me to the official documentation for this.
Why not use IP auth?
Because It is a SIP-proxy for more users …
Howdy,
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.
edit: 4am typo on mobile.
If you really want to use one of the non-hashing algorithms, then you could store the chosen destination in some sort of memory table, not sure what that’s called in OpenSIPs.
If CallID is in table then restore target Asterisk box from table.
Else ds_select_dst.
Then make sure to expire the table entries after some time, or depending on the load you’ll get a giant table which will slow things down.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.