We Recently updated to V17 and it was working great. Our SIP provider did some scheduled maintenance and all the sudden outbound calling stopped working. They claim it was just a router patch and they have hundreds of other SIP endpoints on that router and no one else is complaining of anything.
We dug into the traffic and can see that when we place a call we receive the 401 Unauthorized response to it, to which Asterisk responds with the username and password as defined in the trunk settings. Password is what I assume MD5 encrypted.
The provider then responds again with another 401, claiming something is wrong with the password.
When they disable authentication on their end it now all the sudden works.
I am 99% sure that this is a provider issue but we tried to simplify the password and everything and they just wont take it.
My question is, is there anyway to decrypt that password with a private key from the server to verify in plain text that we are sending the correct password back on the 401 challenge?
They wouldn’t reply with 401, if the password was wrong. It is generally when the supporting information is wrong, that that happens.
The password (more correctly secret) is combined with other information and hashed. They will check the other information,and if some is missing, or stale, will rechallenge with 401. If the hash is wrong, for the supporting information provided, and the shared secret, they should respond with 403.
Without the actual challenge and response, we can’t really go further than that.
My suspicion is the source port rewrite: Via: SIP/2.0/UDP 216.107.220.XXX:5060;received=216.107.220.XXX;rport=1784;branch=z9hG4bKPjddbccae0-2df4-4132-a1a5-646be290a277 Contact: sip:[email protected]:5060;line=cbwchet
So Asterisk sent the REGISTER from port 5060 but your router/firewall rewrote the source port to 1784, which doesn’t match the port 5060 in the Contact header. Some providers will reject such requests.
Try disabling source port rewrite, use port forwarding or otherwise force the firewall to leave the source port alone.
Interesting! I didn’t catch that. The firewall rule isn’t touching the service side of it. Or at least its not configured to be touching it. Supposed to just be SNAT it and leave the port alone.
I will have to clarify with support and report back.
The calls are staying up as of right now. It’s a production system and I know the calls are lasting long than that.
I will have to work with the provider and do more troubleshooting on it. right now with Auth turned off we aren’t getting the challenge so I can’t update you with those logs.
I don’t know where that contact sip:[email protected] is coming from. I did go into the trunk advance settings and change contact rewrite to the username that they are expecting but I did not get a follow up capture from them.
The return port is blank on what they see though so I assume that means to send it back on the same port it arrived on.
That’s what Asterisk sends by default (on a REGISTER request). If you have only one DID with the provider, set Contact User for the trunk to that number (or your username if different), which will replace the s. On an incoming INVITE, the URI will have that value in the user part, unless the provider substitutes the called number.
The provider should not care about the user part of the contact; they should simply return the whole value, as the request URI, when sending incoming calls to you. Unfortunately, some providers try and extract account information from it, so there is a Contact User setting that allows you to control it.
As already described, the default is to use the user part of the request URI as the “DID”. Sometimes the real “DID” will be in the To header, and there is an alternative initial context, from-pstn-toheader, to handle that case. However you haven’t got that far, if the REGISTER is being rejected.