Small bump with some more info:
I get the feeling it’s NAT related because i tested it within an environment that uses public ip’s from their servers (1:1 forwarding on the firewall) and there it works. But in the new environment it goes from public (on firewall/nat outside) to private (10.x) on the internal side. So my old server had a real public up while my new have a private being mapped.
I think it might be related to eternalip and some other settings in the sip.conf.
— Removed allot of ; stuff because of char limit on posts ----
context=default ; Default context for incoming calls
;allowguest=no ; Allow or reject guest calls (default is yes)
;match_auth_username=yes ; if available, match user entry using the
; ‘username’ field from the authentication line
; instead of the From: field.
allowoverlap=no ; Disable overlap dialing support. (Default is yes)
;allowtransfer=no ; Disable all transfers (unless enabled in peers or users)
; Default is enabled. The Dial() options ‘t’ and ‘T’ are not
; related as to whether SIP transfers are allowed or not.
;realm=mydomain.tld ; Realm for digest authentication
; defaults to “asterisk”. If you set a system name in
; asterisk.conf, it defaults to that system name
; Realms MUST be globally unique according to RFC 3261
; Set this to your host name or domain name
udpbindaddr=0.0.0.0 ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
; Optionally add a port number, 192.168.1.1:5062 (default is port 5060)
tcpenable=no ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=0.0.0.0 ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
; Optionally add a port number, 192.168.1.1:5062 (default is port 5060)
srvlookup=yes ; Enable DNS SRV lookups on outbound calls
; Note: Asterisk only uses the first host
; in SRV records
; Disabling DNS SRV lookups disables the
; ability to place SIP calls based on domain
; names to some other SIP users on the Internet
; Specifying a port in a SIP peer definition or
; when dialing outbound calls will supress SRV
; lookups for that peer or call.
;----------------------------------------- NAT SUPPORT ------------------------
; WARNING: SIP operation behind a NAT is tricky and you really need
; to read and understand well the following section.
; When Asterisk is behind a NAT device, the “local” address (and port) that
; a socket is bound to has different values when seen from the inside or
; from the outside of the NATted network. Unfortunately this address must
; be communicated to the outside (e.g. in SIP and SDP messages), and in
; order to determine the correct value Asterisk needs to know:
; + whether it is talking to someone “inside” or “outside” of the NATted network.
; This is configured by assigning the “localnet” parameter with a list
; of network addresses that are considered “inside” of the NATted network.
; IF LOCALNET IS NOT SET, THE EXTERNAL ADDRESS WILL NOT BE SET CORRECTLY.
; Multiple entries are allowed, e.g. a reasonable set is the following:
; localnet=192.168.0.0/255.255.0.0 ; RFC 1918 addresses
; localnet=10.0.0.0/255.0.0.0 ; Also RFC1918
; localnet=172.16.0.0/12 ; Another RFC1918 with CIDR notation
; localnet=169.254.0.0/255.255.0.0 ; Zero conf local network
; + the “externally visible” address and port number to be used when talking
; to a host outside the NAT. This information is derived by one of the
; following (mutually exclusive) config file parameters:
; a. “externip = hostname[:port]” specifies a static address[:port] to
; be used in SIP and SDP messages.
; The hostname is looked up only once, when [re]loading sip.conf .
; If a port number is not present, use the “bindport” value (which is
; not guaranteed to work correctly, because a NAT box might remap the
; port number as well as the address).
; This approach can be useful if you have a NAT device where you can
; configure the mapping statically. Examples:
; externip = 22.214.171.124 ; use this address.
; externip = 126.96.36.199:9900 ; use this address and port.
; externip = mynat.my.org:12600 ; Public address of my nat box.
; b. “externhost = hostname[:port]” is similar to “externip” except
; that the hostname is looked up every “externrefresh” seconds
; (default 10s). This can be useful when your NAT device lets you choose
; the port mapping, but the IP address is dynamic.
; Beware, you might suffer from service disruption when the name server
; resolution fails. Examples:
; externhost=foo.dyndns.net ; refreshed periodically
; externrefresh=180 ; change the refresh interval
; c. “stunaddr = stun.server[:port]” queries the STUN server specified
; as an argument to obtain the external address/port.
; Queries are also sent periodically every “externrefresh” seconds
; (as a side effect, sending the query also acts as a keepalive for
; the state entry on the nat box):
; stunaddr = foo.stun.com:3478
; externrefresh = 15
; Note that at the moment all these mechanism work only for the SIP socket.
; The IP address discovered with externip/externhost/STUN is reused for
; media sessions as well, but the port numbers are not remapped so you
; may still experience problems.
; NOTE 1: in some cases, NAT boxes will use different port numbers in
; the internal<->external mapping. In these cases, the “externip” and
; “externhost” might not help you configure addresses properly, and you
; really need to use STUN.
; NOTE 2: when using “externip” or “externhost”, the address part is
; also used as the external address for media sessions.
; If you use “stunaddr”, STUN queries will be sent to the same server
; also from media sockets, and this should permit a correct mapping of
; the port numbers as well.
; In addition to the above, Asterisk has an additional “nat” parameter to
; address NAT-related issues in incoming SIP or media sessions.
; In particular, depending on the 'nat= ’ settings described below, Asterisk
; may override the address/port information specified in the SIP/SDP messages,
; and use the information (sender address) supplied by the network stack instead.
; However, this is only useful if the external traffic can reach us.
; The following settings are allowed (both globally and in individual sections):
; nat = no ; default. Use NAT mode only according to RFC3581 (;rport)
; nat = yes ; Always ignore info and assume NAT
; nat = never ; Never attempt NAT mode or RFC3581 support
; nat = route ; route = Assume NAT, don’t send rport
; ; (work around more UNIDEN bugs)
;----------------------------------- MEDIA HANDLING --------------------------------
; By default, Asterisk tries to re-invite media streams to an optimal path. If there’s
; no reason for Asterisk to stay in the media path, the media will be redirected.
; This does not really work well in the case where Asterisk is outside and the
; clients are on the inside of a NAT. In that case, you want to set directmedia=nonat.
;directmedia=yes ; Asterisk by default tries to redirect the
; RTP media stream to go directly from
; the caller to the callee. Some devices do not
; support this (especially if one of them is behind a NAT).
; The default setting is YES. If you have all clients
; behind a NAT, or for some other reason want Asterisk to
; stay in the audio path, you may want to turn this off.
; This setting also affect direct RTP
; at call setup (a new feature in 1.4 - setting up the
; call directly between the endpoints instead of sending
; a re-INVITE).
;directrtpsetup=yes ; Enable the new experimental direct RTP setup. This sets up
; the call directly with media peer-2-peer without re-invites.
; Will not work for video and cases where the callee sends
; RTP payloads and fmtp headers in the 200 OK that does not match the
; callers INVITE. This will also fail if directmedia is enabled when
; the device is actually behind NAT.
; Additionally this option does not disable all reINVITE operations.
; It only controls Asterisk generating reINVITEs for the specific
; purpose of setting up a direct media path. If a reINVITE is
; needed to switch a media stream to inactive (when placed on
; hold) or to T.38, it will still be done, regardless of this
; setting. Note that direct T.38 is not supported.
;directmedia=nonat ; An additional option is to allow media path redirection
; (reinvite) but only when the peer where the media is being
; sent is known to not be behind a NAT (as the RTP core can
; determine it based on the apparent IP address the media
; arrives from).
;directmedia=update ; Yet a third option… use UPDATE for media path redirection,
; instead of INVITE. This can be combined with ‘nonat’, as
; ‘directmedia=update,nonat’. It implies ‘yes’.
;ignoresdpversion=yes ; By default, Asterisk will honor the session version
; number in SDP packets and will only modify the SDP
; session if the version number changes. This option will
; force asterisk to ignore the SDP session version number
; and treat all SDP data as new data. This is required
; for devices that send us non standard SDP packets
; (observed with Microsoft OCS). By default this option is
; Because you might have a large number of similar sections, it is generally
; convenient to use templates for the common parameters, and add them
; the the various sections. Examples are below, and we can even leave
; the templates uncommented as they will not harm:
basic-options ; a template
natted-phone ; another template inheriting basic-options
public-phone ; another template inheriting basic-options
my-codecs ; a template for my preferred codecs
ulaw-phone ; and another one for ulaw-only
; Template for all Test ATA’s
-- Registered SIP '12345555-0231-1234-8230-00402432423-00000000' at 86.x.x.x:51822
== Using SIP RTP CoS mark 5
-- Executing [400@Test:1] Ringing("SIP/12345555-0231-1234-8230-00402432423-00000000", "") in new stack
-- Executing [400@Test:2] Wait("SIP/12345555-0231-1234-8230-00402432423-00000000", "5") in new stack
-- Executing [400@Test:3] AlarmReceiver("SIP/12345555-0231-1234-8230-00402432423-00000000", "") in new stack
[Nov 26 13:39:53] WARNING: chan_sip.c:3383 retrans_pkt: Retransmission timeout reached on transmission 9faO9cFeZmFgCIL8DrBp4HQmxRSR-IlG for seqno 31797 (Critical Response) -- See doc/sip-retransmit.txt.
Packet timed out after 32000ms with no response
[Nov 26 13:39:53] WARNING: chan_sip.c:3412 retrans_pkt: Hanging up call 9faO9cFeZmFgCIL8DrBp4HQmxRSR-IlG - no reply to our critical packet (see doc/sip-retransmit.txt).