Maximum retries asterisk problem

Hi Everyone, i have in my netowrk two GOAUTODIAL servers and i added the third on another server using Hyper-V server 2008 R2 but the problem is when i activate this last server goautodial also and passed some calls then i get the error “chan sip.2058 maximum retires” causing the problem on other servers because i have one sip account from my provider please what’s can be the problem exactly

With the additional fact that it says on critical response, it means that Asterisk never received an ACK to its final response, and gave up on repeating the final response.

A common cause of this is using NAT but failing to tell Asterisk what its public address is.

Thanks for your Response.
please is that can be the problem from the provider or just a problem in my configuration ?

Most of the time it is issue on the client side, what it is your NAT configuration ?

Thanks,
you mean the configuration of nat in my carrier setup or in the phone account in the sip.conf file ?

nat= yes in the carrier

nat= is not the NAT configuration. It controls some tweaks mainly used for when the destination is inside NAT and Asterisk is outside.

If that is the only “NAT configuration” you have, that is your problem.

The “yes” option is also deprecated, in favour of specifying the tweaks you actually need.

The missing configuration is in the general section. There is a large part of the sample file devoted to it.

This is my carrier :
[frYou]
disallow=all
allow=ulaw
allow=alaw
allow=g729
type=friend
username=**********
secret=*********
fromuser=**********
host =********
dtmfmode=rfc2833
canreinvite=no
qualify=yes
nat=no
insecure=invite,port

but i have already 2 other server using the same carrier and there’s no problem with it, when i copied thhis same carrier on a third new server i get this error.

Please prvovide seipd set debug on output for the complete INVITE transaction.

You haven’t provided the contents of the general section.

Also this looks like a cookbook configuration, as canreinvvite has been renamed, insecure=port is unlikely to be a necessary insecurity, and type=friend is rarely good practice, but we continually see these in people’s configurations where they have not thought about what everything means.