Call Release [511] on DP752 on any attempt to make a call

#1

Since the last firmware update, I haven’t been able to make outgoing calls on a DP752. Incoming calls are fine, and calls via a soft-phone to the VoIP provider are fine, it’s only the DP752 that can’t make a call, and it’s only happened since the last firmware update (although this may be a coincidence, I rarely make calls and it could have been a change at the VoIP provider). The provider has been trying to resolve this without much success.

What’s happening is that the soft-phone is going through the expected INVITE -> 401 -> ACK -> INVITE -> Trying sequence of placing a call, the DP752 instead has INVITE -> 401 -> ACK -> INVITE repeated three times after which the call fails. The only significant difference I can see between what the soft-phone and the DP752 are sending is an a=crypto in the SDP offer, but I can’t see that that would make any difference.

Does anyone have any ideas what the problem could be? There’s been a few other posts on the 511 problem but nothing in the replies seems to apply in this case.

#2

401 Unauthorized

The request requires user authentication. This response is issued by UASs and registrars

#3

Yes, but that’s part of the normal challenge/response flow, the difference is that the soft-phone gets past it but the DP752 doesn’t.

#4

I don’t see the pcap, so I can currently only tell you that the credentials are incorrect, check the credentials on the DP752 and trunk etc …

#5

They’re exactly the same credentials the soft-phone is successfully using, and exactly the same credentials that have been working unchanged for the last year or so on the DP752, up until a few months ago.

I can send the pcaps if it’s possible to do that as a PM, just don’t want to post them publicly.

#6

please send, remember that you are on a forum, Grandstream assistance can be found at the link below,
I wait for the PCAP and take a look when possible, but again, 401 is a credential error, I invite you to delete the credentials on the extensions concerned and on the trunk, and put them back from scratch.
99.99% you should solve.

#7

Is there any way to send a PM here? I’d prefer to send the unedited traces in case there’s something useful in there, since I’d have to remove quite a bit of stuff to hide PII.

In summary though, the 401 is an expected part of the challenge/response process. It’s not a credential error, it’s part of the challenge/response process, the UAC contacts the UAS which responds with a 401 challenge and the UAC responds with the response which now contains the appropriate Authorization: line based on the UAS’s challenge.

The soft-phone works with the given credentials. The DP752 can receive incoming calls with the given credentials. Up until a few months ago it could also make outgoing calls with the given credentials. My guess is that the DP752 is computing the response incorrectly, or at least different to what the UAS expects, since it’s at that point that the two flows diverge.

#8

As a followup, I’ve just calculated the HTTP auth responses in the pcaps in a Python script for both the DP752 and soft-phone, and both are correct. So both are definitely sending the correct responses to the 401 challenge, however the soft-phone continues while the DP752 re-sends the INVITE three times and then reports the [511].

#9

DP752 what FW does it have?
tried to make a factory format of DP752?
Tried putting a TRUNK directly on the D752?

#10

you see:
register
401
register
401

If yes try making invite smaller by removing some codecs and extra info (headers).

#11

Latest firmware, and tried removing codecs (since that was mentioned in another thread related to the [511] issue), but it didn’t fix things.

#12

SEE IF IT CAN HELP YOU

https://forums.grandstream.com/t/error-code-511/47428/6

#13

You said INVITE repeated three times, that’s failover being triggered, looks like INVITE send to the server which is the first record in the DNS, it got no response for 3 times, then it send INVITE to the server IP address which is the second record server, and received 511 server error. please check the SIP server in your DNS record, if that IP address is reachable for your device?

#14

Ah, good point, I was assuming the lack of response was RADIUS-like behaviour where failed auth gets a stony silence but it could be because the INVITE or response isn’t getting through. I’ll try running the DP752 straight into the ONT to rule out any local issues first.

Incidentally, for anyone else who wants to manually calculate the SIP auth response to make sure it’s all good:

HA1 = MD5(username ":" realm ":" password)
HA2 = MD5(method ":" URI)
response = MD5(HA1 ":" nonce ":" HA2)

The following Python script will do it, just replace all the lowercase words in quotes with the values from the “Authorization:” line in the SIP header:

import hashlib
ha1=hashlib.md5("username:realm:password").hexdigest()
ha2=hashlib.md5("INVITE:uri").hexdigest()
response=hashlib.md5(ha1+":nonce:"+ha2).hexdigest()
response

The printed hash should match the one given in the “Authorization:” line as “response=xxx”.

#15

OK, it’s now fixed, the ISP switched me to a static IP which, after further complications unrelated to VoIP, fixed it. Thanks to everyone for their help, in particular for pointing to a DNS/routing issue which it turned out to be.

#16

At choice “PROFILES”–>“Profile x” --> “Audio Settings” I change the first line “Send DTMF” untic
“via RTP (RFC2833)” and put a tic to “via SIP INFO”.