I'm having the dickens of a time getting this to work. I currently have 2 issues:
1 - remote phones can't get audio (clearly a NAT issue)
2 - flowroute calls are getting rejected when the IP which initially registers is different from the IP flowroute sends calls in from.
More below:
Background - I'm using 13-13 on an Intel platform. I took my analog phones off the Digium board and they now sit on an ATA device and register fine as SIP. I have disabled PJSip on the system. I have every NAT setting I can find turned on. There have been no changes to the network since I've tried to set up the new system. I'm using 13-13 because Ward has said 16-15 doesn't correctly handle faxes.
FIOS router forwards to Netgear. Netgear forwards to 192.168.40.29 (PBX). I'm forwarding 5060-5069 (TCP & UDP), 10000-20000 (TCP & UDP), my portknock ports, my openvpn port 1194 and my IAX port. I've checked and rechecked that all ports are forwarded all the way through. My internal network is 192.168.40.29 from the Netgear forward. The FIOS box identifies as 192.168.1.1.
Problem 1: (perhaps related to point 2 also).
A hard phone in CA is having this problem, and I recreated it with an extension on my cellphone and disabled wifi. I opened the PBX to the phone via my DDNS address - iptables confirms the PBX will take ALL packets/ports from this IP.
When I call my home line (extension on the PBX) from the cellphone extension I get no audio:
Clearly Not Good
On the SIP Settings page, I have:
External Address - my network's public IP. I'm using Ward's routine to keep it updated from the Pi install directions.
Local Networks - 192.168.40.0 / 255.255.255.255 and 10.0.0.0 / 255.255.255.255 (VPN network)
RTP Ports are 10K-20K (per above)
RTP Checksums is yes
Strict RTP is yes
ulaw, alaw, gsm, g726, g722 are allowed codecs
Chan Sip Settings Page, I have
Nat = Yes
Static IP and the IP box has my public IP
Reinvite is No
On the Asterisk Settings page, I have
Sip NAT = yes
On the Extension, I have
NAT mode = Yes, (force_rport,comedia)
I can think of nothing else to change.
2. Flowroute. I have my Trunk set to use us-east-nj.sip.flowroute.com (forgive any misspellings). I have the full range of NJ sip IP's allowed in my iptables. Flowroute will connect using (say) X.X.X.194 and this shows up in my sip show peers list. The problem is that the IP will 'migrate' over time and flowroute will send calls using (say) X.X.X.193. This IP is seen as foreign and is rejected - and the call won't get in. My Trunk settings match what everyone else is using. Prior to this upgrade I have been using the fixed POP in the LA and LV predefined Trunks - unfortunately, at least one of those is dead.
Ward posted a 'fix' for pjsip using a list of all the IP's but never answered if this can be used to 'alias' the IPs for chan_sip. I added all of the IPs for flowroute’s NJ pop per the bulkvs posting, but it doesn’t seem to work – still getting the rejection.
and, to top it off, I even get the retransmission error (since I called from an external to the network SIP phone).
What can I do to stop the rejection and allow external callers to actually get a ring on my phone?
Sorry for the long post. I've been trying for 3+ weeks to get either 13-13 or 16-15 working correctly.
Andrew
1 - remote phones can't get audio (clearly a NAT issue)
2 - flowroute calls are getting rejected when the IP which initially registers is different from the IP flowroute sends calls in from.
More below:
Background - I'm using 13-13 on an Intel platform. I took my analog phones off the Digium board and they now sit on an ATA device and register fine as SIP. I have disabled PJSip on the system. I have every NAT setting I can find turned on. There have been no changes to the network since I've tried to set up the new system. I'm using 13-13 because Ward has said 16-15 doesn't correctly handle faxes.
FIOS router forwards to Netgear. Netgear forwards to 192.168.40.29 (PBX). I'm forwarding 5060-5069 (TCP & UDP), 10000-20000 (TCP & UDP), my portknock ports, my openvpn port 1194 and my IAX port. I've checked and rechecked that all ports are forwarded all the way through. My internal network is 192.168.40.29 from the Netgear forward. The FIOS box identifies as 192.168.1.1.
Problem 1: (perhaps related to point 2 also).
A hard phone in CA is having this problem, and I recreated it with an extension on my cellphone and disabled wifi. I opened the PBX to the phone via my DDNS address - iptables confirms the PBX will take ALL packets/ports from this IP.
When I call my home line (extension on the PBX) from the cellphone extension I get no audio:
Code:
- Connected line update to SIP/flowrouteNJSIP_ASB-0000005c prevented.
-- SIP/1100-0000005d answered SIP/flowrouteNJSIP_ASB-0000005c
-- Channel SIP/1100-0000005d joined 'simple_bridge' basic-bridge <696ca793-89c8-4f6c-8ac2-3cd53b8919cf>
-- Channel SIP/flowrouteNJSIP_ASB-0000005c joined 'simple_bridge' basic-bridge <696ca793-89c8-4f6c-8ac2-3cd53b8919cf>
> 0x7f6c7c0184f0 -- Strict RTP qualifying stream type: audio
> 0x7f6c7c0184f0 -- Strict RTP switching source address to 192.168.1.1:16476
-- SIP/flowrouteNJSIP_ASB-0000005b answered SIP/3000-0000005a
-- Channel SIP/flowrouteNJSIP_ASB-0000005b joined 'simple_bridge' basic-bridge <cfc3ca54-89da-4222-bbf9-d77d503d75f0>
-- Channel SIP/3000-0000005a joined 'simple_bridge' basic-bridge <cfc3ca54-89da-4222-bbf9-d77d503d75f0>
> 0x7f6c6002fbf0 -- Strict RTP learning complete - Locking on source address 174.200.19.235:38474
> 0x7f6c7801b090 -- Strict RTP learning complete - Locking on source address 23.29.23.42:22040
> 0x7f6c7c0184f0 -- Strict RTP learning complete - Locking on source address 192.168.1.1:16476
[2019-10-12 10:11:33] WARNING[2509]: chan_sip.c:4069 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 6987 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[2019-10-12 10:11:33] WARNING[2509]: chan_sip.c:4093 retrans_pkt: Hanging up call [email protected] - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
Clearly Not Good
On the SIP Settings page, I have:
External Address - my network's public IP. I'm using Ward's routine to keep it updated from the Pi install directions.
Local Networks - 192.168.40.0 / 255.255.255.255 and 10.0.0.0 / 255.255.255.255 (VPN network)
RTP Ports are 10K-20K (per above)
RTP Checksums is yes
Strict RTP is yes
ulaw, alaw, gsm, g726, g722 are allowed codecs
Chan Sip Settings Page, I have
Nat = Yes
Static IP and the IP box has my public IP
Reinvite is No
On the Asterisk Settings page, I have
Sip NAT = yes
On the Extension, I have
NAT mode = Yes, (force_rport,comedia)
I can think of nothing else to change.
2. Flowroute. I have my Trunk set to use us-east-nj.sip.flowroute.com (forgive any misspellings). I have the full range of NJ sip IP's allowed in my iptables. Flowroute will connect using (say) X.X.X.194 and this shows up in my sip show peers list. The problem is that the IP will 'migrate' over time and flowroute will send calls using (say) X.X.X.193. This IP is seen as foreign and is rejected - and the call won't get in. My Trunk settings match what everyone else is using. Prior to this upgrade I have been using the fixed POP in the LA and LV predefined Trunks - unfortunately, at least one of those is dead.
Ward posted a 'fix' for pjsip using a list of all the IP's but never answered if this can be used to 'alias' the IPs for chan_sip. I added all of the IPs for flowroute’s NJ pop per the bulkvs posting, but it doesn’t seem to work – still getting the rejection.
Code:
-- Executing [s@from-sip-external:6] Log("SIP/fl.gg-00000002", "WARNING,"Rejecting unknown SIP connection from 147.75.65.195"") in new stack
[2019-10-12 10:44:26] WARNING[3823][C-00000001]: Ext. s:6 @ from-sip-external: "Rejecting unknown SIP connection from 147.75.65.195"
and, to top it off, I even get the retransmission error (since I called from an external to the network SIP phone).
What can I do to stop the rejection and allow external callers to actually get a ring on my phone?
Sorry for the long post. I've been trying for 3+ weeks to get either 13-13 or 16-15 working correctly.
Andrew