FreePBX | Register | Issues | Wiki | Portal | Support

Trunk settings for Freephoneline.ca/Fongo.ca


#1

Hi everyone! Well, since this is my first-ever post here I thought I would make it a helpful one.

I have been browsing the forums here for years and a common thread that keeps popping up is “Trunk settings not working for inbound or outbound calls”

I thought I would post the settings I have finally found that work correctly with Freephoneline.ca/Fongo and will probably work with almost all other SIP providers. (Please note the ALMOST.)

I ran a fresh install of PIAF Green with Asterisk 11.10.0 and FreePBX 2.11.0.37 today and aside from creating 2 DAHDI FXS extensions with my digium TDM400P and 2 SIP trunks along with inbound and outbound routes, everything else is stock vanilla. On to the good stuff:

Under the Trunk settings, fill out as per usual but when you get to the “Outgoing” section, try this:

context=from-trunk
host=voip.freephoneline.ca
username=yourSIPusernamehere
secret=yourSIPpasswordhere
type=friend
insecure=port,invite
dtmfmode=auto
disallow=all
allow=ulaw&g729
fromdomain=freephoneline.ca

“Incoming” should be this:

secret=[insertSIPpasswordhere]
type=user
context=from-trunk
insecure=port,invite
fromdomain=freephoneline.ca

Registration string should be this:

SIPusernamehere:SIPpasswordhere@voip.freephoneline.ca/SIPusernamehere

Now a couple of notes:
Freephoneline, like most SIP/DID providers have a touchy registration timer. If it’s too short they will hit you with a “Too many requests” error and prevent your trunk from registering. You will have to lengthen it under “Asterisk SIP Settings” to RegisterTimeout=3600 and RegisterExpiry=3600

DEPRECATED as per post #8 (thx jfinstrom!!) Another note is that you must add under “Asterisk SIP Settings” at the bottom where it says “Other SIP settings” put in useragent and then after the equals (=) put Mozilla or WRTP54Gv3.0.6.1

I’m new here but I Hope this helps. Any criticism will be taken constructively unless you talk about my wife or my momma, thems’ is fighting words bub! :wink:

Cheers,

Repherb


(Tony Lewis) #2

Why would you have someone change their useragent to something the box is not and broadcast a lie.


#3

Well, Freephoneline/Fongo does NOT allow asterisk boxes to register on their service because they do not want businesses using residential services on their servers.

That about sums it up. Out of my hands, only trying to be helpful here. Apologies for offending anyone (if i have!)

Cheers!


(Tony Lewis) #4

Ok well posting here telling people how to get around what a ITSP does not want done is just wrong and if it violates their ToS why would you do it.


#5

To be quite honest this was intended to help those who use this at home to tinker with. I see your direction, point and case.

Unfortunately you went about it the wrong way. As did I, unwittingly as it seems. My post was intended to clear up some issues I and others had/may have. you see it a different way and you are entitled to that. This post was not intended to circumvent/breach Terms of Service/act shady or otherwise. I was experimenting with FreePBX and asterisk for quite some time and finally made headway and thought i would post my findings to assist others who may encounter my predicament.

Please accept this as my last post on this subject. I’m sorry you took this approach to a seemingly simple post and I will refrain from opening my perverbial mouth. I will only answer replies after this point.


(Lorne Gaetz) #6

This does not violate tos. FFL will happily sell you overpriced SIP credentials for a BYOD device, tho their core business is selling service over their own devices. There was an issue in the past with using useragent=asterisk, which caused problems but it is not clear whether that is still the case.

As I understand things, this usage is legit and it is just FFL’s flaky service that’s at fault.


#7

FWIW, AT&T will do exactly the same for their FLEX offering, you need to complete a 2000 page “Self Certification” course to use anything but Cisco and Nortel UA’s even if they are 10 years old (OK, I’m exaggerating, but FreePBX is NOT acceptable), pragmatically many people just change the UA to something in

http://www.voip-info.org/wiki/view/SIP+user+agent+identification


(TheJames) #8

I reached out to the folks at Fongo. They offer configuration as a service so I wanted to clarify this post didn’t violate their IP, TOS, AUP etc. We also want to ensure people are getting the right information as there is a lot of wrong info out there.

Here is the response:

Greetings from Canada!

I have reviewed the post in your Forums and the information presented is not accurate.

At Freephoneline (residential) services, we are not blocking user agent if it’s Freepbx.

However, back in February 2013 we updated our guidelines ( http://support.freephoneline.ca/entries/23120323-VoIP-Unlock-Key-Credentials ) and gave users a period to adhere to it until we start enforcing such rules.

Those rules are mostly regarding REGISTER requests as close to 40% our user base had it missconfigured and caused a negative impact on overall service health.

As May 2013, our servers will rate limit REGISTER requests to a maximum of 10 requests per 5 minutes. Each authentication round usually consumes 2 requests (digest auth), so it is a fair number given our guidelines. Also, it does not affect INVITES (which are also authenticated)…

This rate limit is applied per IP address as our service is tailored to residential Canadian users (ADSL/Cable). Services as sip.sorcery.com or PBXes.org have been white listed already and they are not affected.

That being said, a user having registration expiry set to 240 seconds might run into issues.

I am running PBX in a Flash at my home with 3 FPL trunks and have no issues.

These are the settings:

Registration Interval: 3600 seconds (1 hour)

Registration Expiry: 3600 seconds (1 hour)

Failed Registration Re-Try Interval:120 seconds

I am also attaching a screenshot from freepbx->Asterisk SIP settings for your reference.

You can inform this user that we are not blocking user agents and as long as their system is configured as per FPL guidelines, they should have no issues.


#9

Just as a point of reference, is this SIP config still working for you? I’ve got mine set to yours verbatim and it registers but won’t allow inbound calling. I’ve tried old configs that used to work and still no luck. Just wanted to make sure that someone still has this working before I continue to rack my brain.


#10

Yes, these settings are in use exactly as they appear on my production unit. Be sure to check your Asterisk SIP settings especially under NAT (yes/no/never/route) and IP Configuration (Public IP/Static IP/Dynamic IP). Also be sure to check under codecs that only g729 and ulaw have checkmarks beside them.


(Joe Lones) #11

Sorry to revive an older thread, but I seem to be having an issue where incoming calls cease to ring on FPL after about a day, a restart fixes the issue. I’m on asterisk 13.7.2

I’m using the settings are per the OP. NAT is set to YES and STATIC IP is selected and I have a dynamic dyndns that points to my public IP which I put in the “Override External IP” field.

I made the registrations times modifications as per this thread and in General SIP settings only ulaw and g729 are selected.

I am behind a pfsense firewall and the way I understand it you don’t need to port forward or anything. My FPL was working fine with a obihan device.

Any thoughts? Please help.


#12

To be honest, you certainly DO need to port forward with a firewall in place! Please setup the port forwards and try again. I am quite certain that’s your problem. also be sure to do a SIP debug to see what errors asterisk is encountering because that will lead you to figure things out much faster than guessing.


(Joe Lones) #13

Thanks for the reply, I do appreciate it.

There’s just much conflicting information on whether you need to port forward or not. I was under the impression that you need to port forward if you want external sip clients to connect to you. More so, withe the obi200 device I had before, no port forwarding was necessary with FPL and my incoming calls would always ring in. So I’m really confused.

Just to clarify, these ports you are referring to, with respect to FPL are: UDP 5060-5061, 13000-13001?

When you say a SIP debug, you mean: asterisk -rvvv on the command line and watch what happens? Can you elaborate?

I added the following in the PEER Details, not sure it will make a difference:

canreinvite=no
qualify=yes
nat=yes

To clarify, incoming is fine for about a day, then the following morning incoming calls don’t ring in. The minute a restart the service (or change a setting in freepbx), incoming calls start working again. Extremely difficult to troubleshoot as I have to wait the following morning to see if it’s working again.


#14

Maybe I can clarify a few things to ease your confusion. Please be understanding that I am not trying to belittle you in any way, it just seems that your grasp of firewalls etc. seems to be limited, from what you have written thusfar.

When you have an appliance behind a firewall, you need to setup rules for what traffic will be allowed into (and/or out of) your network. if you have all ports save for HTTP port 80 closed, nothing will penetrate to your internal network save for the DMZ (DeMilitarized Zone) or port 80.

Ward Mundy (et al) make it clear that setting your * box on the DMZ is a bad idea unless it is hardened. If the VoIp device is a simple ATA you can usually get away with putting it in the DMZ but when you start using customized devices like * boxes, you run the risk of allowing external forces open access to attack the box and therefor penetrate your communications system.

Port forwarding is REQUIRED with a * box because you need to tell the firewall where to direct the traffic to and how to safely route your data. the NAT=YES line is not enough to accomplish this. Many times it is, but not in this case.

Ports that need to be forwarded are typically UDP 5060-5061 for call session initiation, then handoff to port 16384-16484 typically. If your * setup is UDP 13000-13001, you need to expand the range because you have 2 channels, 1 up and 1 down, for voice traffic. I would suggest adding multiples of 2. I use 16384-16484 to allow 50 concurrent calls. It doesn’t hurt anything but gives the * box enough room to wiggle should something come up and it is getting constrained. Try UDP 13000-13010.

As for the SIP debug, this command must be initiated inside the asterisk client itself, so asterisk -vvvvvvr first then (i believe) it is SET SIP DEBUG ON to start tracing your requests to FPL.

The peer details are good, but be careful that it may re-register another instance to FPL and they won’t like that much.

I understand clearly what you are saying, so repeating it isn’t necessary. It’s fine for about a day and then fails. Restarting the box or service means you probably are getting a session inbound for the ring but it is getting lost during the * processing it. Keep an eye out when you call in to see if the call is even making to the * box in the first place. If it is, then we can go from there. If not, the pfSense needs to be adjusted for port forwarding.

Question: once you reboot or restart the service, can you make normal calls and hear audio on both directions? If no audio in one or both directions then it is your NAT setup and/or forwarding. I would also check the firewall settings in your router/modem. Many routers and modems (cable/DSL) have a setting in their firewall that says “SIP ALG”. turn this OFF as it has been shown to actually interfere with SIP traffic.


(Joe Lones) #15

Thanks again for elaborating it’s very much appreciated.

However, I’m still unconvinced whether port forwarding is required to get FPL working with an * box and I sincerely mean no disrespect with regards to your explanation. Also, I never mentioned my * box was in the DMZ, it’s on the private LAN. I also don’t have a router, pfSense is my router configured as a VM in my ESXi box and connected to switches - not sure if pfSense has a “SIP ALG” option though, will take a look. Rebooting generally fixes incoming, I can make normal calls and hear audio in both directions.

Please excuse my ignorance but isn’t port forwarding, and using your words, inviting external forces to attack the box and penetrate my communications system? Of course in a perfect world, I’d rather not port forward. And to be frank your explanation kind of contradicts the plethora of accounts I’m seeing of users getting * working without port forwarding - of course some may be using different VoIP providers.

My knowledge may in fact be limited as it pertains to firewalls and VoIP data in general, but as it stands now, I’ve got it running without port forwarding. And it appears as though I’m able to get incoming calls without the aforementioned issue. It’s been stable for more than a couple of days, which wasn’t the case when I first posted - we’ll see how this progresses over time…

Quite honestly, I’m not sure what setting did it. I applied the settings as per my previous post and altered the useragent just for good measure. More so, I did the following: registered a dynamic DNS setup, configured pfsense to keep my ddns updated on what my public IP address is and configured Asterisk so that it knows its outbound trunk connection is being natted, and that the public IP address can be found by looking up the dynamic domain. Perhaps the NAT=YES IS enough in this case.

I am however very grateful for your input and explanations and your time is extremely appreciated.