I found it.Liptonbrisk wrote:. I'm trying to find the star code for your ATA.
According to https://www.voipmechanic.com/linksys-si ... -codes.htm, you might have accidentally dialed *67.
*68 deactivates it.
I found it.Liptonbrisk wrote:. I'm trying to find the star code for your ATA.
Yepsic698 wrote:
sic698 wrote:So I have renabled block cid service and dialed *67 and a phone number and I get fast busy if i deactivate it through *68 than dial a phone number the call goes through no fast busy.
strange
Freephoneline changed it's policy years ago. They stopped allowing *67 to work at the provider level (see #1) to prevent abuse. I think it's allowed for Fongo users though.sic698 wrote:I see so there is no solution for *67 ? I cant use this function ? anymore ? I can't block my number when I call out ?
sic698 wrote:
this is my current dial plan I will have to re-read you're last pot a few times in order to process and understand what this server migration means for me and my ATA Linksys spa 1001.
sic698 wrote:once again thanks so much for you're help Im sorry if I appeared rude on the trouble shooting process
Yeah, that [6-7]x*xxxxxxxxxxx has never made any sense to me.sic698 wrote:
Thats the official dialplan listed on freephonelines website when I log onto my account.
The colons and the phone numbers following them aren't necessary for you anymore: https://www.fongo.com/government-service-numbers/.Cyber wrote:I use that dial plan on my SPA112 :
<311:5148720311>S0|<411:18005551212>S0|<511:18883550511>S0|<811:18003613977>S0
15 minute before disconnect makes no sense at all. There's no reasonable explanation for it.Before having the fast busy tone, I had a 15 minutes call disconnection issue by using that feature.
Thanks for the information. I updated my SPA112 dial plan to :Liptonbrisk wrote:The colons and the phone numbers following them aren't necessary for you anymore: https://www.fongo.com/government-service-numbers/
I think a SIP re-invite is occurring at the 15 minute mark and not being acknowledged, but maybe something else is happening.albeause wrote:I have the same issue
voip4.freephoneline.ca:6060 should be bypassing SIP ALG if it's on (hidden setting) in your router. Some routers have SIP ALG stuck on with no way to disable it. That's what voip4.freephoneline.ca:6060 is for.even with using voip4.freephoneline.ca:6060, as i didn't find the option SIP-ALG on my router
Really, that seems almost random.So calling FPL to FPL ,, works after 15mins.
Calling from cellphone (videotron) to FPL,, works after 15mins.
Calling from FPL to cellphone (videotron), call drops after 15mins.
The thing is that 3 people in this thread appear to have resolved their issue. I haven't been able to reproduce it. I'm going to test on voip4.freephoneline.ca:6060 for you shortly.I hope that issue will be resolved soon as i cannot use my FPL to call on my conference calls meetings as it's disconnect.
http://forum.fongo.com/viewtopic.php?f= ... =25#p77289JOHN-SBK wrote:A quick update to say I just completed a 1h36min call without any problem. Great!
http://forum.fongo.com/viewtopic.php?f= ... =25#p77295mkaye wrote:a friend sent his incoming/outgoing config
i changed a few parameters and now it is FIXED!
And then there'sJos wrote:@mkaye it works now to pass the 15 minutes, the error I made is when I used the copy and paste command I did not include the last command
canreinvite=no
Thank you very much.
albeause wrote:Hi !
On my side i think i found the issue. The problem seems to occurs when *67 is activated,, meaning when calling from FPL and not showing the CallerID on the other end.
When *67 is activated from FPL to call my cellphone, the call is dropped in 15 mins.
When *68 is activated (showing CallerID), and calling my cellphone, it goes beyong the 15 mins.
Those test i did, i was on proxy voip.freephoneline.ca
@Liptonbrisk,, if you have a chance to test it, i'm curious to see your result.
Thanks !
15 minute drop issues are almost always due to an ACK not being received after an Invite is requested. SIP ALG problems for FPL users used to cause calls to drop after 32 seconds in the past. As for why this is now happening due to using *67, after server migration, I have no clue. If a call is supposed to be dropped due to using *67, it should be dropped immediately instead.albeause wrote: Maybe FPL team will have to pull CDR on the switch to find out where is the disconnect. I will file a ticket and see.