Failed to authenticate on INVITE to '<sip:XXXXXXX@XXXXXX'

Outbound calls end in congestion/busy with that error.
I changed voip operator. With old one it works correctly
I have not changed the format of Register string

Where can I can look ? Thanks

This is not to do with the register string. It is the secrets in the actual device section that matter here.

A failed registration may cause this if the service only accepts calls from known IP addresses.

Note that the intended purpose of REGISTER is to tell the peer where to send incoming calls, not to authenticate the sender of outgoing calls.

And so ? The peer section has the same parameters of other trunks and in
Secret= I put correct password
What I have to check ?

You would need to see if there is a recommended configuration for the provider in question. If not then I’d suggest providing the configuration so others can make suggestions.

unfortunately not.
But here there is the log:
log.txt (25.8 KB)

configuration is:


Maybe they are using 403 for everything. You should actually get:

488 Not Acceptable Here

with that you have disabled all codecs.

yes but other trunks works. And this error appears not related to codecs right?

Remove disallow=all but the problem remains

You will need to ask your ITSP why they are rejecting you.

already asked. but they says that it is correctly registered and cannot me help further because they simply don’t know using asterisk

You are not asking them what is wrong in Asterisk, you are asking them what is wrong in your INVITE request.

I don’t think they are so skilled. I already tried to call them and ask…but they are aware of this.
The problem is that my asterisk requires a
Proxy Authentication because it receives an error 407.

I found on a website this meaning:
Failure to authenticate - 401 or 407?
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.

Moreover appears that a
Proxy-Authorization: Digest username=“0123456789”, realm=“”, algorithm=MD5, uri=""

Why in realm there is my other trunk ? eutelia? This one is

401 and 407 are not errors.

The realm will be what the other side sends. It sounds like you are sending your request to the wrong service provider.

where to check if the request is sent to wrong service provider? If you look to log that I posted, it appears that the server is correct

Your log (which was hidden - please try to include logs in-line, as it is easy to miss small links, and having to go to another site is a hurdle which will discourage people from looking at your problem) shows that you sent it to eutelia:

Reliably Transmitting (NAT) to

Non-authoritative answer:	name =

As you haven’t include the verbose dialplan logging, or the actual dialplan, it is not possible to say why you have sent it to the wrong place. You’ve even missed the section name from sip.conf

It would appear that vivavox is an alternate brand name for eutelia, or a brand engineered service, based on them, but when requesting authentication, their real name is used:

Non-authoritative answer:

It wouldn’t surprise me if they are only in the single line SIP market, rather than the PBX one. SIP phones generally don’t worry about having different passwords for different domains, as they assume they only have the one.

And so?
How to solve?
I switched my line to them

Provide proxy authentication data for the domain they actually use, or ask them if their system will allow you use their real name in URIs. This problem seems to be mainly of your ITSP’s making.

Where can I provide authentication data for the domain they uses? in which file? Moreover I doubt they are able to provide me with these data

sip.conf (see the sample file for details).

If they cannot provide basic data needed to configure PBX access, choose a better provider.