Page 1 of 1

incoming calls fail after 30 minutes with Rogers XB7

PostPosted: 09/23/2022
by purbagp13
I have free phone line with obi 202 from last 4 years but since i changed my Rogers modem to XB7 i can't receive incoming calls. I tried re booting the device and modem and also tried all the url from free phone line. It works for may be 30 minutes then again stops working for incoming calls. Any help please what to do. I already factory reset the device and re enabled but still same issue with incoming calls. This is the software version OBIHAI/OBi202-

Re: incoming calls fail after 30 minutes with Rogers XB7

PostPosted: 09/23/2022
by Liptonbrisk
You posted in an unrelated thread, so I created your own. All servers are working for incoming calls at the moment, but while troubleshooting this issue, you should be using and switching X_UserAgentPort to a random number (of your choosing) between 30000 and 60000 in your ATA. Also, ensure that X_UsePublicAddressInVia is enabled in the ATA.

Please note that only one registration per FPL account is allowed at any time. When there are multiple devices/softphones using the same account, only the most recent registration is valid. The previous device will lose
registration (despite what the ATA's registration status indicates, since 3600 seconds is a long time to update registration status), and incoming calls will not work on it. Registration is required for incoming calls but not for outgoing calls.This is especially important to consider if someone else is using your SIP credentials (username and password) that are found after logging in at (or if you're trying to register your FPL account with a smartphone SIP app, with another device, or, in this case with an additional SP on your OBi202). Registration is required for incoming calls. This is also important to consider if you're using Freephoneline's desktop application (don't have it running while using your ATA with the same FPL account). Additionally, keep in mind that if someone else is also attempting to register the same SIP credentials on another device where you live, too many registration attempts can result in a temporary IP ban. If you ever see a SIP user agent that you don't recognize after logging in at the above link, someone else is using your credentials (possibly, you've been hacked in that scenario).

Dial ***1.
Enter the IP address you hear into a web browser.
Navigate to Status--System Status-->SP(FPL) Service Status-->Status
Check registration status in the ATA when the problem occurs.

Also, check the registration status in your ATA or IP Phone and also "SIP status" after logging in at
Please note that if "SIP User Agent" does not reflect a device you're using, someone else is using your Freephoneline VoIP unlock key.

I tried re booting the device and modem

Proper device reboot order is always Modem--->Router--->ATA. Make sure that the first device in the list is fully up and running before the next device is. That is, the ATA should always be rebooted last in the device chain, after the modem and the router (or Rogers gateway . . . the XB7 is a modem/router combo) are fully up and running first.

Technicolor CGM4331COM is the Rogers (Gen 2) XB7 gateway. If the only thing that's changed in your setup is the Technicolor CGM4331COM gateway, then it's logical to suspect a problem has arisen because of it.
Possible scenarios include poor modem signal levels or noise problems, a problem that's developed along the route data takes between you and FPL, SIP ALG not being disabled (use voip4.freephoneline:6060 and a high random X_UserAgenPort in your OBi202 to help circumvent SIP ALG) in the XB7, or a NAT/firewall/UDP timeout issue.

Follow these steps, step by step, down the list.

1) Contact Rogers and ask for a senior level tech (tier 2) to check for signal noise in your area and modem signal levels. Tier 2 has access to more diagnostic tools than the first rep you'll speak to.
Check to ensure the coaxial cable at the back to the XB7 isn't slightly loose as well.

Some modems are better able to handle noise and out of spec signal levels than others. You're using a different modem/router combo than before.

2) Dial ***1.
Enter the IP address you hear into a web browser.
Login to your ATA, and navigate to Status-->SP Services Stats-->RTP Statistics-->SP(FPL) Service Status-->PacketsLost

If you see a lot of lost packets there, that indicates you have a problem (likely with Rogers on the WAN side rather than on your LAN). Ideally, you should see "0" or close to it.

3) Read the choppy audio section from pages 42 and 43 from download/file.php?id=2195 (PDF File found at the bottom of the first post of viewtopic.php?f=15&t=18805#p73839).

4) Perform the WinMTR test (mentioned below) when the problem occurs. If you're having problems reaching servers (or experience severe ping spikes), you're going to have problems receiving calls.

The instructions below are for testing to FPL's proxy servers, but I would also test to and, which are the RTP IPs at the moment for FPL.
That's where the RTP audio packets (audio stream) come from.

"Test pings and jitter (you want little to no variation between pings) to the specific Freephoneline SIP servers you plan on using.

Use winmtr: Ping about 200 times to each server.

My pings to average 11 ms. average 12 ms average 27 ms

If you're using a Macintosh, maybe this helps: ... tr_on_mac/

When using WinMTR, look at the very last hop or line. Look at your average ping and then maximum ping. Although WINMTR doesn't provide a jitter value, you can get an idea of what yours is by subtracting maximum ping from your average. Jitter is the difference between each successive ping. The bigger the difference, the bigger the problem.

Same with ping, which represents lag or delay. The lower your ping and jitter, the better.

You do not want high pings and lots of jitter (you do not want a lot of variation between each ping). If you get horrible results (pings over 200ms), to any server, you probably don’t want to use that server. So you would want to give that server the lowest priority.

I get between 11 ( and and 24ms ( on average, depending on the server I'm testing to. Preferably, you want pings below 100ms.
Anything over 200ms is unacceptable.
What you don't want to see is 40, 45, 50, 35, 500, 40, 30, 45, 700. That's bad jitter.
You want relatively consistent pings without a lot of variation.

One reason why jitter can occur is due to other devices on your LAN (local area network) using bandwidth. That’s why properly enabling QoS in your router for your ATA is always a good idea. Refer to point C from viewtopic.php?f=8&t=20199#p78976.

Bad jitter can produce broken-up audio or choppiness during phone calls. Severe jitter (or large ping spikes) can cause calls to drop (and incoming calls won’t arrive while the ping spike is occurring). Ping affects delay.

I recommend testing pings/jitter between 8 p.m. and 11 p.m. to see if local congestion is a factor (this often is your ISP's fault). Sundays are the best days to test (because that's when most people in your area will be home). 8 p.m. - 11 p.m. is prime time. During prime time (between 8 p.m. and 11 p.m.) cable internet nodes may be oversubscribed in your area and face congestion issues (and congestion can also exist with DSL). So I suggest testing services between 8 p.m. and 11 p.m., particularly on Sundays, when everyone in your area will be home.

Ping is a measurement of data packet transmission, and ping does affect delay or lag. All gamers know, almost inherently, that lag affects them negatively. A PC gamer will pound his or her keyboard in hope that a character will respond on his or her monitor, quickly, but when there's a delay or lag, reality doesn't meet expectation. A gamer can see this problem visually. Over VoIP, anything over 200-210 ms, you will typically start to encounter crosstalk due to increased delay, even if the untrained ear doesn't notice. All VoIP services are subject to the same scientific principles including the fact that speed of transmission affects delay, and Freephoneline is not some magical service that is somehow exempt from issues arising from high pings and jitter. When pings and, especially, jitter are high, it's a pretty horrible experience, just as it would be with any other VoIP service. When pings and jitter are fine, Freephoneline is great.

Lastly, anyone using any communication service (or even when playing online games or using other online services) should understand that the longer the path to the server being used, the greater the potential exists for a problem to occur somewhere along that path. Freephoneline’s SIP servers are located in Ontario."

-- from download/file.php?id=2195 (pages 16 and 17)

5) Refer to "Are you getting one way audio issues with an OBi200/202 and Freephoneline? Are incoming calls not ringing?
Can you not hear one side of the conversation (you can hear the caller, but the caller can't hear you or vice
versa)?" on pages 40 to 43 in the PDF guide.

If you use the Obitalk web portal ( to configure your ATA, keep in mind
that you must continue using it to configure your ATA unless you disable Obitalk
Provisioning first. Otherwise whatever settings you change will eventually be overwritten
(they will be transferred from your account to your ATA) by what you
previously entered at anyway. If you wish to disable this behaviour, dial ***1.
Enter the IP address you hear into a web browser. Navigate to System
Management-->OBiTalk Provisioning-->select Disabled for the method. Save. Reboot ATA.
Afterwards, won't overwrite whatever changes you make via the device's
interface (via IP address). Pick one method ( or the other (IP address of device) for changing device
settings. But do not use both methods.

If you use, refer to pages 10 and 11 of the PDF guide first to learn how to enter the "Expert" menus.

a) while troubleshooting this issue, use "" for ProxyServer (without the quotation marks)
i) Navigate to Service Providers-->ITSP Profile (used for FPL)-->SIP-->ProxyServer
ii) ProxyServerPort needs to be 6060 while using for ProxyServer
(use 5060 when using and is used to circumvent potential SIP ALG issues.

There isn't an option to disable SIP ALG in a Technicolor CGM4331COM (XB7) with this Rogers firmware version:
eMTA & DOCSIS Software Version: Prod_21.1_d31 & Prod_21.1
Software Image Name: CGM4331COM_5.2p12s1_PROD_sey

According to a tier 2 rep at Rogers, SIP ALG is enabled by default in the XB7 with no way to disable it.
I'm not sure whether that representative is correct (the part about SIP ALG being enabled). However, the response from Rogers seems to coincide with what's happening in Xfinity/Comcast XB7's in the U.S.: ... 66f45f8df1.

b) In your Obihai ATA or at (whichever method you use), navigate to Voice Services-->SP(FPL) Service-->X_UserAgentPort
X_UserAgentPort should be a random port number between 30000 and 60000. Just pick a port number in that range.
If you already have a random number in that range, simply choose a new one.

By using a high random port you help to thwart SIP scanners and may also circumvent a faulty SIP ALG feature in
your (XB7) router.

c) Navigate to Service Providers-->ITSP Profile (FPL)-->SIP
i) ensure X_DiscoverPublicAddress is enabled (it is by default)

This helps to ensure the ATA has discovered your public WAN IP.

ii) enable X_UsePublicAddressInVia (it's not by default)
You will need to uncheck default, device default, and Obitalk settings boxes (if you're using Obitalk). Then check the box to enable the
feature. Submit changes.

This helps to ensure data from FPL is sent to your public WAN IP address instead of the ATA's LAN IP (or outer space. That is, FPL sending packets to, for example, which is a LAN IP, isn't going to accomplish much).

d) Navigate to Voice Services-->SP(FPL)
i) X_KeepAliveEnable should be Checked
ii) X_KeepAliveExpires should be 20 seconds
iii) X_KeepAliveMsgType should be "notify"

Submit changes.

This helps to keep NAT associations/connections working (alive).

e) Navigate to Service Providers–>ITSP Profile (FPL)–>SIP
i) RegistrationPeriod should be 3600 seconds

If it's not, you run the risk of being temporarily IP banned by FPL's server.

ii) RegisterRetryInterval should be at least 120 seconds

Submit changes.

Then reboot ATA, and test within incoming calls.

Re: incoming calls fail after 30 minutes with Rogers XB7

PostPosted: 09/23/2022
by Liptonbrisk
6) Refer to point D from viewtopic.php?f=8&t=20199#p78976. It's always better to have a good router for SIP instead of relying solely on the ISP's device.
The best way to rule out router problems in modem/router combos that ISPs issue is to enable bridge mode in them and use your own router instead.

Also visit viewtopic.php?f=8&t=20199#p78976 if you're interested in learning what features are desirable in routers for SIP services, such as FPL.

7) If all else fails, disconnect all devices from the XB7 except your OBi202, and enable bridge mode in the XB7: ... eway-modem.
Use bridge mode temporarily, only while testing. When bridge mode is enabled, the XB7 won't be protecting any devices connected to it.

Dial ***1.
Enter the IP address you hear into a web browser.
Login to your ATA, and navigate to Router Configuration-->Firewall and DMZ-->Firewall Settings
Enable the OBi202's firewall. It isn't very good, but it's better than nothing.

After testing, disable bridge mode in the XB7 and reconnect devices.

If incoming calls last more than 30 minutes, the problem involves the router portion of the XB7. In that case, since you've now ruled out all other possibilities, you could try port forwarding, as suggested on page 41 in step 11 from download/file.php?id=2195. Port forwarding is a security risk and should only be done when all else fails. If you require help with port forwarding (these are all UDP ports) in the XB7 to your OBi202, contact Rogers. If you find you also have to port forward X_UserAgentPort in addition to the RTP port range defined in your ATA, I would invest in my own router (which I already do) for use with SIP services.
I know that an XB7 in bridge mode used in conjunction with a router that supports Asuswrt-Merlin works well with Freephoneline, for example.

Re: incoming calls fail after 30 minutes with Rogers XB7

PostPosted: 09/24/2022
by Liptonbrisk
An OBi202 that I configured (exactly as outlined in the PDF guide located at the bottom of the first post from viewtopic.php?f=15&t=18805#p73839) is working fine for incoming calls when connected directly to a Rogers XB7 gateway after an hour has passed. I waited to check for registration renewal.

The OBi202 is currently using (the proxy server used doesn't matter), and X_UserAgentPort is set to a high, random UDP port number between 30000 and 60000.
X_UsePublicAddressInVia is enabled in the ATA.

XB7 (Technicolor CGM4331COM) has IPv4 and IPv6 firewalls set to "medium (typical)".
Bridge mode is disabled.
Everything else is at defaults in the XB7, except for Wi-Fi username/password.
There is no option to disable SIP ALG in this XB7's web interface on its current firmware version at the time of this post.

Incoming calls are working normally after 1 hour. I suspect in the event the public (WAN) IP address changes that problems will occur due to point D from viewtopic.php?f=8&t=20199#p78976. There's no way to change UDP Unreplied timeout in the XB7. But for now, I believe incoming calls will continue to work indefinitely until WAN IP changes. Public (WAN) IP doesn't change frequently with Rogers, so that problem should occur infrequently. I'll never find out because I don't use ISP's gateways or hubs as routers. I always enable bridge mode and use my own router instead, and the person who is helping me test does the same thing.

The bottom line is, a normally operating XB7, at defaults, won't stop incoming calls from working after 30 minutes when a properly configured OBi202 (using the PDF guide's settings) is being used. Using Obitalk’s default Freephoneline profile isn’t a good idea, as explained on pages 6 and 7 of the PDF guide.

Port forwarding in the XB7 isn’t required (and should be avoided). So, step 7 in the previous post can be ignored.

Re: incoming calls fail after 30 minutes with Rogers XB7

PostPosted: 09/24/2022
by Liptonbrisk
By the way, apparently Rogers has released XB8: ... isplay-bug.
A tier 2 rep mentioned that Rogers is moving towards locking out administration setting changes for users, so it's doubtful that SIP ALG can be disabled as well in the XB8, but we'll have to wait to confirm.
His reasoning is that if you can't disable SIP ALG in XB7, it's unlikely XB8 will offer the capacity to disable SIP ALG either.