Issue with Asterisk connectivity


#1

Hello,

I got a issue with connectivity from my ata box to the asterisk server that i don’t have on my second location.

First (with issue) location:
ATA <> Router <> INET <> FIREWALL (UDP 5060) (public ip) <> Redhat (using CentOS RPM / yum)(private ip)

Second (working) location:
ATA <> Router <> INET <> FIREWALL (UDP 5060) (public ip) <> Ubuntu (public ip)

Log from the first location:

[Nov 25 13:56:51] -- Registered SIP '12345555-0231-1234-8230-00402432423-00000000' at 86.x.x.x:62379 [Nov 25 13:57:31] == Using SIP RTP CoS mark 5 [Nov 25 13:57:31] -- Executing [400@Test:1] Ringing("SIP/12345555-0231-1234-8230-00402432423-00000000", "") in new stack [Nov 25 13:57:31] -- Executing [400@Test:2] Wait("SIP/12345555-0231-1234-8230-00402432423-00000000", "5") in new stack [Nov 25 13:57:35] -- Executing [400@Test:3] AlarmReceiver("SIP/12345555-0231-1234-8230-00402432423-00000000", "") in new stack [Nov 25 13:57:46] -- Registered SIP '12345555-0231-1234-8230-00402432423' at 86.x.x.x:62384 [Nov 25 13:58:07] WARNING[2692]: chan_sip.c:3383 retrans_pkt: Retransmission timeout reached on transmission OIeHaGDR7XKdvKSawPXqk3GNmDlFjNv1 for seqno 13967 (Critical Response) -- See doc/sip-retransmit.txt. Packet timed out after 32000ms with no response [Nov 25 13:58:07] WARNING[2692]: chan_sip.c:3412 retrans_pkt: Hanging up call OIeHaGDR7XKdvKSawPXqk3GNmDlFjNv1 - no reply to our critical pac ket (see doc/sip-retransmit.txt). [Nov 25 13:58:12] == Using SIP RTP CoS mark 5 [Nov 25 13:58:12] -- Executing [400@Test:1] Ringing("SIP/12345555-0231-1234-8230-00402432423-00000001", "") in new stack [Nov 25 13:58:12] -- Executing [400@Test:2] Wait("SIP/12345555-0231-1234-8230-00402432423-00000001", "5") in new stack [Nov 25 13:58:17] -- Executing [400@Test:3] AlarmReceiver("SIP/12345555-0231-1234-8230-00402432423-00000001", "") in new stack [Nov 25 13:58:41] -- Registered SIP '12345555-0231-1234-8230-00402432423' at 86.x.x.x:62409 [Nov 25 13:58:49] WARNING[2692]: chan_sip.c:3383 retrans_pkt: Retransmission timeout reached on transmission BPLfsVlTJASK07.2FPfuAfufDYGRuwzW for seqno 14233 (Critical Response) -- See doc/sip-retransmit.txt. Packet timed out after 32000ms with no response [Nov 25 13:58:49] WARNING[2692]: chan_sip.c:3412 retrans_pkt: Hanging up call BPLfsVlTJASK07.2FPfuAfufDYGRuwzW - no reply to our critical pac ket (see doc/sip-retransmit.txt). [Nov 25 13:58:54] == Using SIP RTP CoS mark 5 [Nov 25 13:58:54] -- Executing [400@Test:1] Ringing("SIP/12345555-0231-1234-8230-00402432423-00000002", "") in new stack [Nov 25 13:58:54] -- Executing [400@Test:2] Wait("SIP/12345555-0231-1234-8230-00402432423-00000002", "5") in new stack [Nov 25 13:58:59] -- Executing [400@Test:3] AlarmReceiver("SIP/12345555-0231-1234-8230-00402432423-00000002", "") in new stack

What i expected was something like:


#2

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.

My sip.conf:

[code];
— Removed allot of ; stuff because of char limit on posts ----

[general]
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 = 12.34.56.78 ; use this address.
; externip = 12.34.56.78: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
; off.

;
; 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
dtmfmode=rfc2833
context=from-office
type=friend

natted-phone ; another template inheriting basic-options
nat=yes
directmedia=no
host=dynamic

public-phone ; another template inheriting basic-options
nat=no
directmedia=yes

my-codecs ; a template for my preferred codecs
disallow=all
allow=ilbc
allow=g729
allow=gsm
allow=g723
allow=ulaw

ulaw-phone ; and another one for ulaw-only
disallow=all
allow=ulaw

; Template for all Test ATA’s
test
type=friend
host=dynamic
context=test
nat=yes
disallow=all
allow=ulaw
dtmfmode=rfc2833

;Test
12345555-0231-1234-8230-00402432423-00000000
secret=test[/code]

Error again:

-- 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[10108]: 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[10108]: chan_sip.c:3412 retrans_pkt: Hanging up call 9faO9cFeZmFgCIL8DrBp4HQmxRSR-IlG - no reply to our critical packet (see doc/sip-retransmit.txt).


#3

I found the problem yet not the solution.

RTP packets are not being received on the client / server. The issue seems to be that the server sends a SIP/SDP packet with the Asterisk local ip address (10.x) instead of the public from the firewall. So RTP then tries to send packets from the remote network (192.x) over the internet to (10.x) which for obvious reasons would never work.

Anyway to fix this issue?

I tried looking into sip/asterisk/nat but it’s still a bit vague on how to solve it.


#4

Did you check this topic?:

viewtopic.php?f=1&t=75217