Good morning.
We have the following problem:
After an asterisk restart is made, incoming calls no longer enter. By making a call, in fact, to a geographic numbering, the line falls after 2 or 3 seconds of noises. There is no record of that call in asterisk logs. The only way to resolve it is to make a call outgoing from an extension. At that point the calls come in again.
We are certain it may depend on the switchboard, as another switchboard does not have the same problem.
Do you have any idea what it may be?
Thank you
What channel technology are you using?
For VoIP technologies, I would look at NAT and firewall devices. They may be deleting dynamic routes/persmissions
thank your for support.
It’s voip.
We tried to reset the firewall and all natting rules, but it did not resolve. Making other asterisk stop and start did not resolve.
As usual with the first outbound call from an extension, the problem resolved automatically for all numbering.
Some idea?
Thank you
Same idea as before. The firewall or NAT device is learning a path through itself for the outbound call that it can use for subsequent inbound ones. Resetting it is likely to make things worse by clearing those rules.
Asterisk uses the public ip directly.
What could be a solution? Are there any modifications to the sip.conf that we could configure?
Even using ‘public’ IP space directly on the server, it’s still possible that NAT is applied if there is a firewall in the way.
To get around this you could try setting it to qualify=yes along with qualifyfreq=30 in your sip.conf peer definition. This will keep the entry in the NAT table populated which will allow traffic back in the reverse direction.
Also might be worth checking that there isn’t an ALG/SIP “helper” on the firewall that may be interfering somehow.
We did other tests but we did not solve it.
However, when we restart asterisk and the problem occurs, we reported this error:
SIP / 2.0 401 Unauthorized
Via: SIP / 2.0 / UDP
As response from our asterisk server to the caller
How do we make a call outside and subsequent calls do not present the problem.
401 is a normal part of the protocol, not an error. The client should respond with authentication data based on the password it stores.
Good morning, maybe we found the problem.
The numbers were registered by a provider that we entered into the host parameter, which we then provided the privileges of type = friend and insecure = port, invite. However, it did not work and in logs we identified code 401.
By removing the host name and directing the public ip the problem disappears. Is there, however, a way to always and correctly resolve the name rather than injecting the public ip? Thank you
I’m not aware of a case where Asterisk incorrectly resolves a domain name, and I can’t work out from your description where you think that is happening.
insecure=port is unusual, except for TCP.
type=friend is bad practice. Use type=peer in most cases.
If Asterisk sending 401, it is because the call is coming from an unknown IP address, or because it is coming from a known IP address that has secret or md5secret set, but doesn’t have insecure=invite set, i.e. it configured to authenticate callers.
A 401 will only go on to a failure if the caller doesn’t actually authenticate. Most ITSP’s aren’t prepared to authenticate themselves,and need either remotesecret, instead of secret,or insecure=invite, as well as secret.
No way. It only works by putting the public ip in the host. If I put the full name (example: sip.testvoip.com) it will not work and the incoming call will be interrupted after a 401.
All this works only if I make an outgoing call. At that point, calls come in as shown.