TIPS Ancient install upgrade attempt

[Bham Tony]

Hello from 2015!
I've had my IncrediblePBX running since before 2015 then and decided to upgrade to 2027 with a new pi and the SSD thing. I figured there wasn't a way to get my config from the old system other than to take notes and put them in the new system settings. After all was said and done it doesn't work and I've had to revert back to the old system. The new system will make an outbound call which instantly terminates leaving a "Missed call" on the target phone. The old system makes the call just fine. I am imagining there is some "new" feature or a setting deep in the bit bowels of the new system but I just can't find it. I wanted to blame the firewall because it's new also but the old system works. I would prefer to have all the shiny new things and rest easier not worrying that the ticking time bomb of my old microsd card is going to phhft. I have backups but I don't think I've ever had to test them and I'm not sure they'd be complete and I would end up where I am now, trying to install the new thing. Anyone else upgrade from an old system or can provide insight on what's going on or where to look? TIA for any help

 

[wardmundy]

Who is the service provider? Is the trunk registered successfully with 2027??

 

[Bham Tony]

The service provider is didforsale. They go by my IP so I don't register. Something goes through on the call because my cell phone pops up and says "Missed Call from Home Phone". Incredible PBX 12.0.74 on the other hand the call rings I can pick it up and have 2-way audio

 

[Bham Tony]

On the CDR for the 2027 call at didforsale it says:
Direction : outbound
Terminate Cause : INCOMPATIBLE_DESTINA

 

[Bham Tony]

Maybe I figured this out. After some packet capture by the firewall and using wireshark to look at voip calls, rtp etc it seemed like the calls were partially getting there then for some weird reason the RTP traffic is going to IP blocks owned by intelliquent, not allowed by my firewall so I added them to my alias list for NAT & outbound rules. I had given up and was going to just continue using the old version until it died but I'm rebuilding the 2027 D box and I converted my firewall aliases and rules to these iptables lines for
/usr/local/sbin/iptables-custom
# // New entries for DIDForSale.iptables
/usr/sbin/iptables -A INPUT -s 209.216.2.211 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.15.70 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.2.212 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.15.71 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.2.202 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.2.203 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.2.204 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.2.205 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.15.72 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.15.73 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 209.216.15.74 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.209.76.101 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.209.76.102 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.209.76.103 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.209.76.104 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.209.76.102 -j ACCEPT
# // End entries for DIDForSale.iptables
# // New entries for WhoThe-F-isThis.iptables
/usr/sbin/iptables -A INPUT -s 64.2.142.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.241.96.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.241.97.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.241.99.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 66.241.111.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 207.166.136.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 207.166.137.0/24 -j ACCEPT
/usr/sbin/iptables -A INPUT -s 216.221.144.0/20 -j ACCEPT
# // End entries for WhoThe-F-isThis.iptables

 

[Bham Tony]

I was wrong still no joy with 2027.

 

[kenn10]

Do you have both old and new running at the same time? If so, the vendor might have difficulty deciding where to send the incoming call unless you change the DID routing on their end.

Secondly, are you using a SIP trunk or a PJSIP trunk on the new system? PJSIP is pretty much required if your provider can push calls to you from a variety of different IP addresses. Otherwise you have to have one SIP trunk for each possible incoming IP address from the provider.

Chan_sip is deprecated and will no longer be in Asterisk much longer. Support for chan_sip has stopped. The setup guide on the DIDforSale site for FreePBX is ancient and probably hasn't been updated in recent years.

 

[kenn10]

Using this guide from the DIDForSale site: https://docs.didforsale.com/sip-trunking/sip-trunking/ip-configuration
you would take each IP address shown as Incoming and put that in the match field of a PJSIP trunk. You only need one PJSIP trunk for all those IP addresses.

Also, in your Settings > Asterisk SIP Settings on the PBX, make sure of what the incoming port is for either PJSIP or chan_SIP and be sure you have DIDforSale pointing the inbound number at the correct port on your PBX. A lot has changed since 2015 and you really need to read up on the forum to understand changes.

 

[Bham Tony]

Thank you. I have had a working system for many years, ( I used piaf when it was new) I am not attempting to expand my system with multiple pbxs running on my end. I wish to bring up a 2027 system and retire the one from the 2010s this will be the 3rd time I've done this (brought a new system online and retired the old one), this is just the first time it didn't work. I have 1 external address, outgoing calls get routed out to DIDForSale and for incoming calls NAT and port forwarding takes care of the fact that calls come from any one of many IPs. For my own convenience I shutdown the new or old system that's not in use because it's easier to assign the active system the same internal IP rather than change the route, port forward, phones and fxs port on the grandstream. I have messed around with pjsip but I know that is not the issue today and I only require one trunk with SIP as well. I can packet sniff and see the traffic is making it to the intended server, the 2010s server works when it's online and the 2027 box does not. They are configured as identically as I can. The 2027 box has more options available and things like tlsenable don't have to be in the "Other sip settings" boxes. I noticed there is an image now and have downloaded it, though it goes against my instincts I will burn it and try it out. I do pay attention to the world around me and believe it or not I come to the forums when there's something I need help with, it just so happens I have found the answers to most of my questions before having to post them ;-)

 

[dicko]

Sounds like you might find sngrep useful

 

[Bham Tony]

Cool, thanks. It's always nice to have a cli option. If you haven't already checkout the Telephony tab on wireshark, it takes up more resources but you can easily track though an entire call all the way down to playing the rtp stream

 

[dicko]

Currently you need the 10000ft view, tshark/wshark is better for microscopic analysis.

man sngrep

look for the -O (output) option

 

[Bham Tony]

Very nice! I like it.

 

[atsak]

Many carriers don't proxy the RTP stream, though I don't know about didforsale. This means you'll have to allow UDP 10000 - 20000 through your firewall and through iptables, usually, because the IP address the actual audio stream comes from will be different than the IP address the SIP communication is on.

 

[Bham Tony]

Many carriers don't proxy the RTP stream, though I don't know about didforsale. This means you'll have to allow UDP 10000 - 20000 through your firewall and through iptables, usually, because the IP address the actual audio stream comes from will be different than the IP address the SIP communication is on.

I had noticed that. It seemed that the RTP stream was primarily coming from Intelliquent cidr blocks so I had whitelisted them. I think right now my firewall is good to go since the old box works. It's possible I missed something in iptables, I had posted those changes earlier. Following Dicko's tip I noticed I was getting a 403 unauthorized error, since I was taking stabs in the dark I decided to ditch that build and use the raspi image.

 

[dicko]

Beating a horse that refuses to die, but if your rtp range is 10000-20000 then you need to forward 10001-20001 from your firewall, first R the FM , then check with Ms. Pasternak .

 

[Bham Tony]

OK thank you everyone, whatever it was blowing away the build and using the raspi image, configuring it exactly as I did before worked. BTW my rtp range is 10000:40000 for DIDForSale. The "Free" manual is in tatters ;-)

 

[dicko]

And you are forwarding what ports to your Raspberry ?