md07si wrote:I must say the two times I've contacted support, nothing came of it and the issue still exists to this day
1) auto reload doesn't function properly...i have to manually reload everytime
I can't help you with billing issues, obviously, since I don't work for them.
Submit a ticket at
https://support.fongo.com/hc/en-us/requests/new
Select VoIP Unlock Key and then World Credits Inquiry. Possibly, "Billing and Payment" is a better choice than "World Credits Inquiry." I'm not sure (try both?).
2) i can't call a certain country anymore..getting "rejected by the service provider reason 484"
You have an Obihai ATA.
I suggest registering and posting your question over here just to help rule out a dialplan issue:
https://www.obitalk.com/forum/index.php?board=3.0
When you post about this problem, provide the following information.
Dial ***1, and enter the IP address you're told into your web browser.
Navigate to Physical Interfaces-->Phone Port-->
a. Post
both your Phone Port's Digitmap and Outboundcallroute
b. Navigate to Service Providers-->ITSP Profile (FPL)-->General and post your digitmap for FPL.
All three of those are very important and affect your dialplan.
From
http://forums.redflagdeals.com/freephon ... #p26842900
The default digitmaps are a mess.
For
Service Providers–>ITSP Profile FPL–>General
I want to help explain a few things first.
<1> means add or prepend 1 to the beginning of the phone number
<:1> also means add 1
<1:> means remove 1 from the beginning (and replace with what follows after the colon)
[2-9] means match any single digit from 2 to 9
XX. means match any phone number you dial (also XX. is an indefinite variable, and without XX.S3, for example, your ATA will wait 10 seconds for you to finish entering in a phone number before dialing out. S3 reduces the wait (represents 3 seconds)
011XX. means any number starting with 011 (for international dialing), and again XX is an indefinite variable. Without the .S3, your ATA will wait 10 seconds
Mipd is for IP dialing
[^*#]@@. is for sip uri
Neither is needed with Freephoneline. I would remove them.
XX. is usually not needed (and actually, inadvisable).
[6-7]x*xxxxxxxxxxx. is complete nonsense and should never be used since it can't logically apply to anything.
011xxxxxxxxxxxx. is wrong if the international phone number is less than 11 digits.
That should should really be 011XX.
011XX.S3 is probably better to help avoid a 10s wait for the ATA to think you're doing punching in a phone number.
So, this is what I would suggest using with FPL:
(1xxxxxxxxxx|011xx.S3|[2-9]xxxxxxxxx|*98|911)
But that digitmap won’t work with 211, 311, 511, 611, etc.
Here’s an alternative example:
(1xxxxxxxxxx|011XX.S3|[2-9]xxxxxxxxx|<211:4163974636>|<311:4163922489>|<511:4162354686>|<611:4164772010>|<811:8667970000>|*98|911)
The digitmap is appropriate for Toronto. For 211, 311, 511, 611, 811 you will need to look up the corresponding phone numbers for your area and replace the phone number after the colon.
SIP error 484 means that the address is incomplete. The full phone number is not being sent properly. Typically this is due to the user not entering in full phone number. Another common cause is an issue with the user's dial plan. You should should view your FPL call logs to ensure the full proper phone number is being sent: log in at
https://www.freephoneline.ca/doGetCallLogs
If you did use 011XX.S3 and did punch in the proper phone number and still had problems, then there's a chance there's a problem with whatever carrier FPL is using to Tanzania.
I would suggest opening a ticket with Freephoneline and providing them with the full phone number you're trying to reach:
https://support.fongo.com/anonymous_requests/new
If no responds to your support ticket, provide the ticket number in a private message to the user, Fongo Support, after logging into the forums:
http://forum.fongo.com/ucp.php?i=pm&mode=compose&u=7852[
Also, Fongo monitors this thread, so you may want to ask if there's a carrier issue with a certain phone number:
http://forum.fongo.com/viewtopic.php?f=10&t=5418
You might want to ask there if there's a known carrier issue.
If it is a carrier issue, the problem is definitely not on your end.