Hi - following my last post, I did some research on the Fritz!Box modems and it seems to be a common configuration issue. The Fritz!Box has an integrated SIP Server and AVM has structured the firmware so that it is not possible to Disable SIP ALG. With a third party ATA (Analog Terminal Adapter) device, it is possible to connect the Fritz!Box directly to ISPs and VoIP providers who allow such connections or provide you with their SIP registration details for a VoIP service which currently precludes Optus and Telstra who restrict their modems to their own VoIP telephone services.
From my understanding, an alternative non Fritz!Box front end modem that allows 'Disable SIP ALG' should be able to use the Sagemcom 5366 as an ATA on an Optus telephone service. I would be helpful to readers for people to post their experiences with other modems or any new AVM developments to verify.
Hi - thanks for the question. I think that JC29 may have cross referenced me in error with you in regards to the #2 link and I assume the suggestion was attempted. I don't have an ATA or use a third party front end modem, so I haven't done any testing per se but find it an interesting learning topic. It's a new knowledge area for me.
The AVM article appeared to cover two options for using VoIP on the Fritz!Box which included native SIP Phones, SIP Soft Phones and ATA's that allow configuration to those device settings in association with required customised ISP settings. Given that the Optus modem has fixed VoIP settings and can be regarded as a pre-configured ATA, I don't know what else could get the Fritz!Box to co-operate with the Sagemcom 5366. You have covered all the usual bases and maybe the Fritz!Box 7490 just has restrictions - hopefully someone may post a workaround.
I have not done a lot of reading on this topic, but it seems to be a variable outcome even with other routers. I was impressed with the guidance you provided from your personal set up in a post using an ASUS router and the findings from one of the OPs in that same post who eventually achieved success after a new ASUS front end router replaced the original ASUS router - why I call it a variable experience.
On this last day of the year, I would like to take this opportunity to thank you for your contributions to the forum and your efforts to assist others. I generally learn something from your informative posts and enjoy the journey of discovering new information. All the best for 2021.
Sorry this post has been a bit inactive, I haven't had a chance to get back to my brother's but will be tonight, although based on @Mkrtich 's information, I may be out of luck with using the Fritzbox, the frustrating thing is it had been working, although in a different configuration (with a switch in the middle of the routers and NTD, so maybe a firmware update has locked down the fritzbox or Sagemcomm?
@JC29 the furthest I got was successfully making outbound calls and could talk fine. Inbound there was no ring tone either on the mobile phone making the call or on the landline. The RJ11 just plugged from landline into the phone port on the Sagemcomm, the part that allowed me to make outbound calls was logging into the Sagemcomm and on the main info page there should be a WAN IP address (same range as your internal IP Range) that's the IP address that the port forward rules should use in the Fritzbox, Under Friztbox -> Networking, you need to continue giving the Optus Router the same IP address based on the MAC Address.
@YetAnotherAcc I had tried talking my brother through following step #2 from the link you provided and it then broke the phone completely and we couldn't reverse it, was a bit trickier remote.
I'll be returning this afternoon to try and round out 2020 with a win! if not, there's always beer.
Thanks to you both for taking the time to respond to this and the various other posts I have seen you both responding on.
When it comes to VoIP, I'm constantly surprised with all the crazy configurations that work and the ones that should work but don't.
The reason I asked you the question is because you have a Fritzbox and I know you like these types of challenges/learning opportunities, and you might notice something that others may have missed.
Be aware the some changes can alter related settings without being obvious. I'm guessing that when disabling VoIP in the Fritzbox it may have messed with/cleared the 5060 forward so check that its still there.
Also when testing phone calls you should always test incoming calls first and only test outgoing calls once incoming calls work. This is because an outgoing call will open the necessary ports temporarily because it was client side initiated, and during that period incoming calls may work and end up giving a false sense of success.
@YetAnotherAcc Thanks, I thought it may have changed some settings so will take a look this afternoon!
Good to know Re: testing incoming first, wouldn't have thought about that!
Hi - Good project for next year 😀 ! Yes, I have also come to the conclusion that it is not straight forward and comes with variances. One of the observations I have made is that the carrier modem needs to be working on the broadband service with its telephone service registered and active before the the third party modem is placed in front of it - some history of successfully making and receiving calls built up in the modem; Calling Line ID display may also confirm full registration. So your suggestion about incoming calls test first may be part of that stage as well.
I use the Fritz!Box as a secondary network connected to a Telstra Arcadyan modem which has the telephone service active; separate subnets. I will look at doing some new configuration tests next week. Unaware of how Optus run their VoIP service, but there is a lot going on and hidden in the background mode in the Telstra modem which may require more than Port 5060/5061 to be open. Don't know. I have seen posts that refer to additional ports, but I don't know if they are relevant , appropriate or safe.
The Telstra modem 'calls home' via TR069 entries every 10 minutes to re-register the SIP details to its associated servers, one of which includes authentication, and I have the impression that one of these is primarily for incoming calls. People who have connected third party front end modems generally seem to be able to make outgoing calls from the secondary carrier modem, then can receive incoming test calls but sometime later lose incoming call ability - they either get no progress or the calls go to voice mail. I can't remember seeing similar Log entries to multiple SIP Network elements in the F@ST5366 - they may be hidden.
This is a sample of what happens every 10 minutes in the Telstra modem. It may be that one of the incoming re-registration connections coming from an associated server is, in the case of the Telstra network, being blocked by the Fritz!Boxafter the 10 minutes of the first outgoing call has expired. Perhaps the same applies to Optus and suggestion #2 may remove the blocking?
1.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.OutboundProxyPort success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.ProxyServer success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.UserAgentDomain success.
31.12.2020 08:59:32 TR069: Set Device.Services.X_TELSTRA_VOLTE.Enable success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.Enable success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.URI success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.Line.1.Enable success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServerPort success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.OutboundProxy success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthPassword success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.X_TELSTRA_FXSState success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServer success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.RegisterRetryInterval success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.Line.1.CallingFeatures.CallerIDName success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.X_TELSTRA_FXOState success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthUserName success.
31.12.2020 08:59:32 TR069: Set Device.Services.VoiceService.1.VoiceProfile.1.SIP.RegisterExpires success.
31.12.2020 08:59:34 TR069: Sending SetParameterValuesResponse
31.12.2020 08:59:34 TR069: Received GetParameterValues
31.12.2020 08:59:34 TR069: Sending GetParameterValuesResponse
31.12.2020 08:59:34 TR069: Session end.
31.12.2020 08:59:41 Start dnsmasq at br0
As you can see, there many entries involved for SIP. Will report back after experiments next week.
I use the Fritz!Box as a secondary network connected to a Telstra Arcadyan modem which has the telephone service active; separate subnets.
Separate subnets may be a problem, at least for testing you should keep everything on the same subnet to eliminate that as a potential cause of problems.
Telstra modem which may require more than Port 5060/5061 to be open. Don't know. I have seen posts that refer to additional ports, but I don't know if they are relevant , appropriate or safe.
I haven't looked into Telstra VoIP at all other then a quick search now that has an apparent solution for the needed ports.
Be wary of any solution that requires 100's or even 1,000's of ports in a range as that is just asking for trouble and really just a lazy scatter-gun approach.
For initial testing it might be simplest to just tell the Fritzbox to put the Telstra router into DMZ. That, combined with disabling of Telephony in the Fritzbox should work. If you can't get it to work at that level then it is unlikely to work at all. That will save you wasting time playing with specific ports/port combinations. Once that works, disable DMZ and investigate the ports.
@Shwongy you can actually put the Sagemcom into DMZ and leave it on, as the Sagemcom's firewall will still be protecting it.
This is a sample of what happens every 10 minutes in the Telstra modem.
While I totally expect initial setting to be set via TR069 as that is no doubt how Optus are doing it as well, but doing it every 10 minutes seems totally unnecessary. The most I would expect is maybe once per bootup/reboot.
It may be that one of the incoming re-registration connections coming from an associated server is, in the case of the Telstra network, being blocked by the Fritz!Boxafter the 10 minutes of the first outgoing call has expired.
The typical TR069 port is 7547, so if Telstra are using that, and it indeed needs updating every 10 minutes then you can try forwarding that as well.
Greetings and Happy New Year everyone - appreciate your advice @YetAnotherAcc and the information in your last post - I think you hit it on the head with Port 5060 in the #2 URL and glad that you encouraged me to experiment - as frustrating as it was looking at many web pages that referred to other people's negative experiences, I have learned a lot today - thank you
After carefully reading the preamble clauses of the #2 URL , which seems to relate to making outgoing calls using Internet Telephony, followed by 8 hours of testing, I think my investigative skills have been exhausted but a successful outcome has eventuated.
Initially, to set a benchmark, I had no Port Forwarding as one successful post I read made no mention of it being required. Incoming calls only worked for me after a successful outgoing call was made but only for a limited time - my suspicion is the 10 minute window came into play. After lunch, I activated Port Forwarding on Port 5060 in the Fritz!Box which appeared to be the missing key and it looks like all works fine now, so hoping the same will happen for others on the Optus network.
I gave up on Port Forwarding in the morning as I could not find the hidden screen but discovered it in the afternoon - it has two sections - one for the Fritz!Box (no protocol mapping) and further down you have to select a radio button to reveal the other page for the Ports which enables protocol mapping.
I didn't set up the Arcadyan Modem as an Access Point in the same network - its firmware has a current restriction that prevents it from being used in that mode - it has an embedded Wi-Fi Easy Mesh Master Controller and Agent which may be influencing matters in that regard - don't know. The Fritz!Box 7490 is at 07.12 firmware and under my previous arrangement, the WAN was auto set at 192.168.188.1, so I left it at that address. My Fritz!Box defaulted with IPV4 only, I thought that IPV6 may somehow assist, but avoided that page due to its complexity of choices.
Fritz!Box - 192.168.188.1 - using WAN (LAN1) connected to NBN HFC modem set at 50/20 speed WAN DHCP Auto IPoE.
Telephony/Telephone Numbers/No telephone numbers configured ; Line Settings - Disabled Land Line and Substitute Connection; Security - Disabled - Prevent use of internet telephony from the home network = #2 URL ( I think that may also be related to freeing up Port 5060 if you have no telephone numbers in the Fritz!Box - aligns with your suggestion)
Arcadyan - 192.168.0.1 WAN connected to Fritz!Box LAN2, DECT Base Station on Phone Port
8:32 AM - Mobile to Home - long silence and eventually diverted to Message Bank
8:33 AM - Home to Mobile - dial tone , successful call.
8:34 AM - Mobile to Home - successful call.
9:06 AM - Mobile to Home - long silence and eventually diverted to Message Bank
9.07 AM - Home to Mobile - dial tone , successful call.
9.08 AM - Mobile to Home - successful call.
I did the same tests again three times over the next three hours and came up with the same result. No problem making a call. Incoming only worked after an outgoing call was made which I assume kept the SIP registration open for the next 10 minutes. So re-registration request using TR069 appears be prevented by the Fritz!Box but allowed when the user initiates an outgoing call which keeps that registration open for 10 minutes.
Eureka moment ! I then set up Permit Access/Port Sharing rule for Port 5060 UDP and 5060 TCP (for insurance only) targeting the Arcadyan Static IP address 192.168.188.23 and its MAC and hit Refresh so that the greyed out buttons went green to signify activation. Thinking All Systems GO - maybe - made sure to allow for multiple 10 minute intervals.
2:40 PM Mobile to Home - successful call. Preceded by successful outgoing call.
3:00 PM Mobile to Home - successful call.
3:01 PM Home to Mobile - dial tone , successful call.
3:32 PM Mobile to Home - successful call !