|Home||Reviews||Tools||Forums||FAQs||Find Service||ISP News||Maps||About|
how-to block ads
In the morning of February 6, 2007 an error occurred during a scheduled firmware update to the D-Link DVG-1120M ATAs. Primus has provided the following explanation:
In response to this outage, Primus has provided step by step instructions for recovering D-Links affected by the firmware upgrade error. The link to these instructions has been removed for security reasons (now that the severity of the outage has passed), but can still be found on the Primus website via the MyTBB Portal forums by logging in and then browsing to https://mytbb.primus.ca/forum/viewtopic.php?forum=6&showtopic=21155.
As per our email, there has been an error (a human one). Could happen with anyone (not excuse, just a fact of life). We do a lot of testing of any new firmware and software updates, have a clean update process, but nothing in the world is 100% perfect, and today is a good example.
Further clarification and instructions are available on the Primus MyTBB Portal forums.
Customers affected by this outage may also visit the Primus offices in Toronto and in Montreal. This option was offered until Friday, February 9th. After this date it would be recommended to call first before making the trip to one of those offices. See the threads in the Announcements forum on the MyTBB Portal for address information.
Several users around the country have also offered their time and assistance for those affected users who live in Calgary, Ottawa, and Winnipeg. Contact information for these users can be found in the Feedback forum on the MyTBB Portal.
Primus has announced that affected customers will be rebated one month's service over the next 3 months (a $10 credit on each of the March, April, and May bills). This rebate will be applied only to those users who experienced an outage, and not to every TBB subscriber with a D-Link gateway.
For those TBB subscribers whose only phone line is their TBB line or an expensive cell phone plan, remember that you can use Skype to call the Primus support 1-800 number, even if you don't have any SkypeOut credits.
got feedback?DNS (Domain Name Servers). DNS translates the "text name" of a host/server (which humans use) we are trying to reach, to the IP address of that host (example: from www.google.com to 184.108.40.206).
In your network there are DNS server entries (primary and backups), and domain name suffixes; defined usually at a Gateway device to keep things simple.
Some ISPs (i.e. Shaw, Rogers) make the presumption that most users connect directly to their modem (without a router). They set their modem's DHCP server to supply a default domain name suffix and provide the user with a shortform prefix for their mail servers such as "shawmail" or "rogersmail" to use in the email client popmail settings (Outlook, ThunderBird...).
When you are connected directly to their Modem, it is set to translate the prefix to the appropriate mail server's IP address. However, when your LAN (computer) is connected through a router (or the DVG ATA), although the router (or DVG) gets the domain name suffix from the modem, it may not pass this onto the LAN (your computer); hence, it cannot resolve this prefix correctly.
You should be able to resolve this with either of the following:
• Use the full mailserver name (if you want your LAN to have its own domain name - the three cases below do not allow this)
•Get the fully resolvable text name of the mail server from your ISP (i.e. "shawmail" becomes "shawmail.gv.shawcable.net", etc).
• Use this name within the popmail settings of your email client.
•Set the DVG's (or router's) domain name suffix
•Login to the DVG ATA
•Expand (Left Click) DHCP Configuration
•Left Click on Dynamic IP Assignment
•Modify the Domain Name to the value you're supposed to have
•Left Click on Save and follow the instructions
•Set your computer's DNS settings (example for Windows XP)
•Go into Network Connections
•Right click on Network Adapter and left click properties
•Find Internet Protocol (TCP/IP) and select it (left click)
•Left click on properties
•Left Click on the Advanced button
•Left Click on the DNS tab
•Modify the "DNS Suffix for this connection" text to the value you're supposed to have
•Left Click on OK
•Set your computer's Search Domain settings (example for Mac OS X)
•Go into System Preferences-->Network
•Select the Network Port Configuration that you use for internet access
•Click Configure (at the bottom of the window)
•Click the TCP/IP tab
•Place your cursor in the 'Search Domains' field
•Enter the DNS suffix for your ISP (e.g. gv.shawcable.net)
•Click on 'Apply Now'
Whether you have NO DIAL TONE or the DVG Alarm Status LED is Flashing Red, verify the following:
(New or Old TBB USER, your cables may have come loose, or the DVG may have lost some settings.)
•Verify your cables and jacks.
•Follow all steps in Setting up your DVG when you receive it !
- especially Power Up Sequencing.
- and that your DVG has a valid Call Agent (CA) IP address (starting with 216.b.c.d followed by ":2427"). Example: 216.b.c.d:2427
•On the DVG main screen, go to the "Factory Reset" link. Click on Reset NMM Configuration. Attention: Do NOT click "Reset to Factory Defaults".
This will do a reset and you will be able to login to the DVG after about a minute.Verify if you now have a green light, DIAL TONE, and can make calls. Otherwise continue with the next step.
•Verify that you can Ping the DVG.
This LAN delay should generally be less than 2ms.
•Ping each device (routers, etc) in the path from the DVG to the Modem. Ensure that each of these also have short ping delays, generally less than 2-4ms each.
•Use Ping and Traceroute to determine the path and associated delays to your Primus TBB Server. This delay should be about 60ms, but can be larger depending on the network (hop) distance between the endpoints.
If you still have a Flashing Red Light, please contact Primus TBB Technical Support to perform a Hard Reset under their supervision.
If PRIMUS has correctly provisioned your TBB account on the TBB server, with the above procedures, your status light should now turn green, and you should have DialTone.
Otherwise, you need to followup with Primus TBB Technical Support to verify and/or modify your account's settings (including MAC address), or in some cases, replacing your DVG ATA.
Verify that the Telephone cables and jacks on the ATA and telephone(s) look OK (wires or pins on jacks are not bent). Ensure the modular clip on any of the RJ11 plugs is not broken, as this will allow the telephone cable to unplug itself from the jack; or it may be loose and cause intermittent problems with your telephone call (static, ringbacks on calls "on-hold", no ringing...).
•When you encounter problems connecting (ping etc), swap cables to help isolate problems.
•Try a different cable if it "feels" tight when plugging the cable into the jack.
•Replace cables as necessary.
To rectify this Contact Primus TBB Technical Support.
•(2) Select Advanced from the menu on left.
•(3) Select telephony configuration
•(4) If TEL Dial Signal is AUTO go to step (9).
•(5) If TEL Dial Signal is MANUAL, set it to AUTO.
•(6) Press SAVE at bottom right of window (NOT in the left side menu).
•(7) On the next screen select "save and reset now". Wait a few seconds, then press shift-refresh in your web client. The DVG leds should now be green.
•(8) Login back at step (1) and follow these steps again.
•(9) Now set TEL Dial Signal to MANUAL.
•(10) Press SAVE at bottom right of window (NOT in the left side menu).
•(11) On the next screen select "save and reset now". Wait a few seconds, then press shift-refresh in your web client. The DVG leds should now be green.
You should now be able to make calls.
If you have any problems, please contact Primus TBB Technical Support.
This worked for me. Thanks for your hard work!
•A new TBB number assigned by Primus can take a week or more to be activated/provisioned completely.
•A request to port your POTS/PSTN number (from Bell, Telus, ...) can take from two (2) weeks to four (4) weeks or more to complete.
For more details refer to Length of time from signup to service activation.
Had the same problem.. turned out that via random pocket dialing call forwarding had been activated (you can check your call log to see if a *72, and any random sequence of numbers, entry exists - viola there it was on my phone). Try pressing *73 then send. This will cancel call forwarding - it worked for me. Thanks VZW for figuring out my problem!
•How many phones can be plugged into the DVG?
•DVG Hardware Version
Generally, the TBB VoIP service should not affect the ringing of your phones or operation of your answering machine. If these work on a POTS line, they should work on Primus TBB.
got feedback?Unlisted Number or Permanent Outgoing CallerID Block from Primus. Some of the Masked Numbers are: 905-361-8349, 416-398-1111, 604-550-7000, 604-629-2009
If the person you call then dials the number that is displayed on their Phone, it will either connect them with Primus Customer Service, result in a dial tone, or result in dead air; but it WILL NOT ring your TBB line.
Please contact Primus TBB Technical Support if either:
• You have the Unlisted Number feature but do not want a Masked Number and would like to have this component removed from the feature.
• You have a Masked Number, but have not requested an Unlisted Number (and are not paying for one).
Primus cannot remove the "masked number" and still retain the "unlisted"feature or permanent caller ID outgoing block.
You need to ensure that the hook switch is depressed for at least one second when you hangup or between subsequent phone calls - use the "Rls" or "End" buttons instead of the hook switch. Note that sometimes you may inadvertently (or through bad habit) rattle the hook switch when hanging up - either by banging or dropping the phone handset into the cradle.
In all cases, whenever the phone system does not "detect" that the hook switch has been depressed for one second, it believes that you are pressing the "flash" or "link" button. The phone system thinks that you want to make a second call - and places the first call "on-hold". Whether you actually hung up or dialed another number and then hung up, the first call is still "on-hold"! When you finally hang up, the system waits for a few seconds and then calls you back to remind you about this!
These are perfectly normal responses and not errors! So be careful how you hangup your phones!
Following are some other reasons that cause a ringback:
•A cheap phone - Some phones do not always provide the correct electrical signal when you hang up. A simple solution is to try using a different phone. Note that it is always best to try using one phone connected to the ATA at a time. Phones that are still plugged into the ATA (via house wiring or splitters) may still have an affect even when you are not using them in this test.
•Wire or jacks - Verify that the phone cords, wires, and jacks on the wall or ATA are not loose or frayed.
In some instances, if you had called someone with a voicemail system, you will hear their voicemail prompts, or you might have hung up just after their voicemail prompt ended. In either case, you may be saying "hello...hello..." which gets recorded on the voicemail system! When the other person listens to their voicemail, they usually cannot understand or find it quite funny that someone has left a "hello" message!
•If you are using a cordless phone which can be affected by other devices, test your TBB line with a corded phone to reproduce your problem and rule out your cordless phone.
•Are you using a wireless connection for your DVG?
•Do your calls drop either randomly or at fixed times?
•If it is none of the above, then this is the classical situation of the "Internet" affecting your VoIP service. You may also have had no problems for months, and all of a sudden, you start having issues. This can be occasional or very frequent.
These problems come and go based on Internet traffic usage and the (core) root servers (nodes), where the congestion lies, are very hard to pinpoint from a VoIP user's perspective, and from a service provider's too!
Until all components of the Internet can provide 99.9999% PSTN like Quality Of Service (QoS), these intermittent issues will occur, regardless of your VoIP provider and ISP provider.
•Frequent problems means that somewhere upstream, whether it's your LAN, your ISP, the interworking to Primus, or Primus' network itself, there is a problem with the way packets are being sent/received - for VoIP anyway - the root cause being HIGH JITTER (>50ms). Although your surfing and file transfers may slow somewhat, error correction in these protocols fix JITTER problems. HIGH JITTER affects things like VoIP and gaming.
HIGH JITTER may be due to a bad LAN configuration, load balancing in your ISP network, or congestion or loading within the ISP's or Primus' network.
See other Issues with SHAW CABLE.
If - from the TBB line - you can hear the other caller OK, but they hear your choppy voice, this usually means that your local ISP link is saturated/full. Do you notice that your calls fail at peak times [between 3pm and 6pm (after school - before supper), 7pm-10pm etc]?
This could be due to general Internet congestion at that particular time. However, apart from TBB system issues, degradation can occur at any time - but CABLE ISP networks are more susceptible to this problem given the local shared cable segment - which has a limited upload capability. This can happen regardless of any Higher Bandwidth "Speed" (i.e. Extreme) or QoS Priority (i.e. SHAW) feature on your Broadband connection. Either:
When you have degraded voice on your line, you should immediately Determine the JITTER on your ISP connection.
This should help to isolate the problem to some extent as to whether it is related to your ISP's network or Primus' Network. If the problem is both networks then further testing with Ping and Traceroute may help isolate the problem further.
So, assuming your TBB service quality is great with a corded phone, then generally, 2.4G cordless phones, wherever they are placed, should not affect or be affected electronically by the DVG unless there is a serious defect in either.
However, 2.4G cordless phones are affected by:
•Other 2.4G cordless phones
•WiFi (802.11b and 802.11g) routers
If you or your close neighbours have any of these devices, then you might experience choppy voice conditions at times due to interference from these devices.
Refer to the User-Contributed List of Compatible Cordless Phones that have been used successfully with TBB.
Note that 5.8G cordless phones are more reliable since there are fewer such devices in the 5.8G spectrum that will interfere with them. WiFi 802.11a works in the 5Ghz band but is not very commonly used.
got feedback?TBB has a three hour limit for all calls.
You may sometimes encounter a situation where you are able to place a call and start a conversation, only to have your call drop/disconnect suddenly. This can occur after one second, 40 seconds, or fifteen minutes or more into a call.
Please first ensure that you do not have a CABLE or DSL modem resync issue due to low signal (SNR), or noise - an unstable ISP connection.
•With DSL, a symptom is that your IP address might change often. See your modem stats, or call your ISP, to see if you keep losing either the DSL or PPPoE connection when your phone call dies. If so, this is not a TBB problem. DSL resync problems can sometimes be alleviated by having the Speed profile reduced on your line. Your modem may be too far from the DSLAM (Telco CO) to have a good signal at a high speed - it might be OK at 1,5Meg but terrible at 3.0Meg.
•With Cable, you also need to verify that the connection is not being temporarily dropped. If so, a possible solution may involve adding a signal amplifier to your line. You will need to call your ISP to determine how to verify this.
In either case, you might sometimes be able to "flash" the call to get it back - but not always.
If you determine that your ISP connection is stable, refer to:
•Call drops/disconnects after 5 minutes - Bell Sympatico SS5200 modem/router?
•Issues when the ATA is behind (certain) routers
•Issues with SHAW CABLE
•Experiencing Call Drops
•Terrible voice quality on your calls - you typically hear the other person, but they hear your choppy voice
These problems can occur at any time. You may make a perfect call, and the next one degrades to the point where you have to hang up!
The reason for the problems are due to SHAW's network topology, and nothing to do with Primus TBB. In other words, SHAW has a network with LOAD-BALANCING or TRAFFIC-SHAPING that causes severe JITTER at times. This HIGH JITTER is not usually a problem for most internet protocols like file transfers. However, it is often FATAL for VoIP!
When you have choppy voice on your line, you should immediately Determine the JITTER on your ISP connection.
Generally, if you have High Jitter (>50ms), calling TBB Tech Support is NOT going to resolve any problems and they will not be able to do much for you, apart from perhaps letting you vent.
You may first want to try some possible solutions:
•Ensure you have a free modem upgrade to the Motorola Surfboard.
•Call SHAW and see if there are too many subscribers sharing your local neighborhood segment. Complain forcefully and politely.
•Ask SHAW if you can try their EXTREME service free for 14 days to see it this improves things.
User "Kris Kroeker" reported that a free SHAW upgrade of his Motorola Cybersurfer modem to a Motorola Surfboard modem (DOCSIS) resolved the problem considerably - without using the QoS Enhancement or Extreme. In this case, the modem was creating JITTER conditions that affected his TBB service.
Some TBB users have indicated that an upgrade to SHAW EXTREME resolved the problems. Other have also tried the SHAW QoS Enhancement (for 3rd party VoIP like Primus & Vonage customers) at $10/mth, with mixed results. Others have even suggested that SHAW QoS and SHAW EXTREME are the same thing, although this is not true. This was miscommunicated by SHAW CSRs early on before the QOS feature was actually introduced. There does seem to be evidence, however, that the Shaw Extreme service actually includes the QoS Enhancement by default, so users who are paying for both Shaw Extreme AND the QoS Enhancement may be paying double.
User "Kenmo" calls the SHAW QoS feature the SHAW VoIP TAX! It can also be interpreted as a mechanism to get users to switch to SHAW's own higher priced, fixed, VoIP service.
BBR user cgycable has submitted the following information in response to Kenmo's comments:
There are multiple press releases that should be reviewed by any person wishing to learn more about the debate regarding the QoS enhancement and the mis-label of the service.
I have seen these problems from some of my company's VoIP customers in Winnipeg and Vancouver. Before calling Shaw, we recommend that they track their Internet/VoIP quality for a few days using www.voipspear.com and then send the information into Shaw. It makes it harder for the Shaw techs to ignore the problem when you can present them raw data showing that the connection is poor.
Assuming you have a stable ISP connection, there are some issues, sometimes related to UDP timeouts, when the ATA is placed behind some routers, rather than being connected to the modem directly:
•call drops/disconnects - random and periodic
•intermittent ringing for incoming calls (do not always ring)
•voice/audio cuts out for a few seconds
Some of the following routers exhibit these problems when used in this configuration:
•Linksys (Befsr41 & other models, except the WRT54G(s))
•SpeedStream 5200, 6300, 6520 (These are DSL modem/router combo units)
To resolve these issues, the following workarounds are available depending on your LAN requirements and equipment availability:
•If you have multiple IP addresses, configure the ATA in Bridge Mode and connect the Wan port to the modem. You can then connect the router to the ATA's Ethernet port and put your computer in the router's DMZ. This will provide a separate routable WAN IPs to the ATA and your router. However, if you are running high bandwidth applications/servers within your LAN, then it is recommended to use a QoS based router as described in point 5 below.
•If you must keep the ATA behind the router, configure the ATA in the router's DMZ. You should specify a FIXED WAN IP address for the ATA and configure your router's DMZ with this address.
•With some devices such as the SpeedStream 5200/6300/6520, you can also connect the ATA in PPPoE mode rather than DHCP. These modem/router combo units will Bridge a PPPoE connection, thus bypassing the built-in router capability and providing a WAN IP to the ATA.
•Purchase/Use a router which does not reproduce these problems. You can also use a multi-port QOS capable router such as the Linksys WRT54G(S), appropriately configured.
putting my ATA in DMZ helped the connection issues I was having.
If you have the Bell Sympatico SpeedStream 5200 modem/router, you may be experiencing calls dropping/disconnecting consistently after 5 minutes.
The workaround to this issue is to configure the DVG WAN IP settings as a PPPoE connection with your Bell b1xxxxxx ID and password info. In other words, do not configure the DVG ATA WAN IP for DHCP or a Static IP address. This will use the SS5200 modem function and completely bypass the router function.
•Ensure that the DVG's WAN port is connected to the SS5200 when you configure, save, and restart the DVG with the PPPoE settings, otherwise the DVG will restore the WAN settings to DHCP.
•You do NOT have to do anything on the SS5200 as the default Bell firmware will automatically BRIDGE the DVG PPPoE connection.
Much more configuration information is available in the Bell Sympatico FAQ.
Most Telecom systems have time limit safeguards to ensure that calls are not left "hanging" over long periods of time. Calls are left hanging when a phone is accidentally left off-hook, or a software or system error leaves the call in an indeterminate state. The time limit safeguard is intended to resolve these erroneous situations.
However, sometimes, a live call may also be interrupted. This is minimized by setting a time limit that is generally much above the average time of the majority of phone calls - three (3) hours in the case of TBB.
•Call forward first to a number, and then insert additional numbers to access a telephone extension or a cell phone roaming access number.
•Use SpeedDial to dial a number and automatically enter a PIN; perhaps even dialing a second number after this.
Unfortunately, these and other similar scenarios, are not technically feasible within the current Telephony Network.
A typical phone call (direct dial or through SpeedDial) is made through Telephone System switches (aka Bell Central Office or CO). The COs are initially involved in what is called Call-Setup to connect your phone to the phone number you have dialed. Once the call is setup and connected, the CO simply passes the voice signals between these two phones. It then waits for a flash signal, or a phone-on-hook signal before it does anything further.
Once the phone call is setup, any further "PIN numbers" or "extensions" need to be generated by a phone either manually or automatically. It is recommended to program your telephone (or cell-phone) to insert pauses, PINs, or additional numbers where needed. You need to refer to your phone's manual for the detailed programming procedures. If your phone does not have support for long numbers and "pauses", you can program the main number in a SpeedDial number, and the PIN and/or extensions in your phone's memory locations.
Call Setup Simplified Technical details:
This is what is called "Call Setup". Note that the PSTN consists of many COs and from different companies too. So when a call gets forwarded, this is part of CallSetup and it has to go through the PSTN through many COs perhaps(!).
For the problem at hand, the PSTN only handles 10 digits (incl Area Code). So adding more CALLED digits as in PIN numbers or extensions for roaming numbers or office extensions, cannot be handled by the current PSTN very easily. The system would also have to take into account time for pauses so that the PIN or extension number can be entered correctly.
This would mean the whole network would have to be changed in North America, as well as first getting all the Telcos and equipment manufacturers such as Nortel to agree to add the digits, how many digits, and how to modify the protocols to do this (not just the CCS7 protocol). This is not very likely.
•You are dialing a number from your TBB line and you get a network busy tone or another error. Similarly, you or someone else can dial the same number from another phone line (different provider - i.e. Bell) and the call goes through successfully!
The issues in both these scenarios are related to the Public Switched Telephone Network (PSTN) and applies to all Providers (POTS, Cell, VoIP, etc), and NOT ONLY to Primus.
•You can always attempt to dial the number as a long distance number (prefix with a "1"); which may incur long distance charges.
When you do encounter DIALING errors, first notify the service provider from which you are making your call, and tell them exactly what you are dialing. They need to get their technical dept to verify the routing - the CSR should not give you a "It's the other company's problem"... It might be, but your provider needs to verify their routing first!
The PSTN works with country codes, area codes, and exchanges. The USA and Canada have country code 1, and join together to assign area codes and exchanges through the Numbering Plan Administrator organization (see »www.nanpa.com/ and »www.cnac.ca/ ).
In simple terms, when a new exchange is created, the new exchange's info must be provided in databases (DB) to exchanges (CO) - all over North America. When a call is made, the originating CO looks up the DB to route the call over appropriate Trunks to the correct destination CO.
Compounding this is that since particular numbers can now be ported, it is not ony the Exchange that needs to be in a DB somewhere, but also the last 4 digits of the number!
When either new exchanges are created, or a number is ported, the process of updating the databases is cumbersome and is prone to (human) error; there are thousands of numbers added every day. Furthermore, not all databases get updated in sync. So sometimes you can call a new number from a Bell line, but it won't work from a Roger's cell phone!
In summary, for new numbers (or ports), don't expect to have all calls to or from different providers working asap - give it a few days. If the issue persists, call the (originating) provider to determine what the routing problem is (before calling the destination provider).
LAN/PC -> TBB DVG (DLINK ATA) -> Internet (Cable/DSL Modem)
You may be having an issue with TBB, whereby when if the P2P client is running for too long, it will eventually crash the DVG.
The reason for the crash is that the P2P was exceeding the maximum number of concurrent connections that the TBB DVG ATA could support. This caused the DVG to eventually choke and crash. This isn't so much a defect with the TBB DVG ATA as every router has a limit as to how many connections it can support concurrently. The DVG ATA could have a more powerful processor that could support more connections, but some people would continue to experience this issue. Plus, a more powerful router means more $$$.
The solution is to limit the number of maximum connections that your P2P client could use at a given time. The most recommended setting is approximately 66% of your router's specified number of concurrent connections. However, if you don't know how many concurrent connections the DVG can support (unknown at this time), 150 is safe. This may under some situations slow down your downloads... but that's the price you pay.
The TBB DVG ATA seems to be particularly sensitive to this type of workload. Not surprising considering that this one unit performs a considerable number of functions. Likely all being driven by one (maybe two) internal processors.
got feedback?Echo is caused by impedance mismatch, exacerbated by network latency and the use of cheap phones. [NOTE: The DVG-1120M tech specs (no longer on DLINK website) stated that echo cancellation was built into the device.]
You can expect echo on some VoIP calls (more prevalent when long distance/overseas). This can be due to some portion of the network reflecting the signal, or due to other issues - bad echo canceler in the PSTN network, etc. You can always hang up and dial again.
However, if echo is there often, then you may want to consider the following:
•You should also ensure that your telephone cables and plugs are secure. A loose connection can cause some echo.
•Calls to cell phones (cell networks) seem to have a longer latency (time delay), thus more echo, than calls to a wireline PSTN number. In addition, some cell phone speaker phones will also create echo; so ask your caller to not use the speakerphone if possible.
•You can occasionally hear two conversations if you are talking to someone who has two active phone lines on a conventional "twisted pair" analog phone system. For example, if you are talking to someone on one phone line and the second phone line is also in use, you will hear faint snippets of the second conversation. Basically, TBB faithfully reproduces all signals on the line - so if there is a slight secondary signal due to electrical induction (or poor insulators) you will hear the secondary conversation.
To help in isolating the problem, try using a different corded phone plugged directly into the DVG ATA (with no other phones).
In any case, if you hear echo very often, suggest you call TBB Tech Support, as I believe they can do a tweak to your settings somewhere to perhaps correct echo - it varies for each user depending on their network latency.
The chirps and squelches have been replaced by normal beeps in most cases since the firmware upgrade in April 2005. If you still have chirps (all the time), post the details in the BUG REPORTING Forum.
When it can occur
The chirps and squelches are generally an artifact of Visual Call Waiting and the Message Waiting Indicator (MWI) signal on TBB; heard when you are on the TBB phone and a second call is ringing through, or a new VoiceMail has been left.
The chirps are akin to Visual Call Waiting on standard POTS lines, where you hear the "clicks" (Number & Name being transmitted to your phone) and "beep" letting you know a call is waiting.
The squelch seems related to the MWI information being downloaded to the DVG ATA while you are on the TBB line. The squelch is an annoying sound for a lot of users and has been reported in the Forums.
got feedback?Caller ID (CLI) displays only when your phone is plugged into certain telephone jacks in your home, you may have an issue with the wiring of the non-functioning jacks.
TBB user Martin has explained that CLI is transmitted via the ring (red) wire and that a polarity reversal can affect the transmission of CLI on jacks where the red wire has been swapped with the green wire.
In order to ensure that CLI is transmitted and displayed at all jacks, make certain that the red and green wires are correctly located for each jack.
•(1) That your system is not OOS and using the Backup Call Forward setting.
•(2) That no Call Treatments are set to route some or all calls to VoiceMail.
•(3) That your (Cable or DSL) modem is setup to keep the connection alive forever.
-- This is a configuration on your modem (and/or router), so please verify with your ISP as to what setting is required to set the connection always ALIVE! (keepalive forever, set timeout=0 for infinity, ...)
NOTE: "ALWAYS ON" is a marketing term meaning that you "can" have a broadband connection all the time - it does not mean that it really is !!
In reality, when the "keepalive" is not set, after some time of inactivity (the timeout) on your network, the ISP actually drops the connection to your network.
-- As long as you use the ISP network (web browsing, email, etc), the connection will stay up and incoming calls will ring your TBB line.
-- Once you stop using the network, after a certain timeout (usually about 15 minutes), the ISP connection drops. At this point, TBB servers cannot communicate with the ATA and believes it to be OOS, so will send new incoming calls to VoiceMail.
-- When you again start to do something from your network (computer or Voip), it takes but a second or two to re-establish the network connection and all is well -- you may notice this "delay" when you use the network for the first time in between the dead periods.
TBB servers should always be able to communicate with your ATA and route calls appropriately - unless you have specific settings in Concierge, Remote Phone, or Backup Call Forward as noted above.
TalkBroadband user MTS_EMPLOYEE has provided the following explanation.
The trouble is with your cell phone company.
Your VoiceMail Message Waiting Indicator (VMWI) is flashing and will not turn off even after you have listened to or deleted all VoiceMail through your TBB phone.
You can still listen to your VM from the TBB line itself.
SOME WORKAROUNDs - which MAY NOT WORK for everyone!
However, to stop the continuous flashing VMWI, you need to leave at least one NEW (unheard) VM before doing one of the following, while ensuring that the TBB line is ON HOOK - NOT OFF HOOK:
1) LISTEN to your NEW VM through the Portal. If you listen through Email forwarding - this will NOT cancel the flashing VMWI.
2) Access your TBB VoiceMail from another phone (cell) or through RemotePhone. LISTEN to your NEW VM from there.
The flashing VMWI should be OFF and back to normal operation! You need to repeat the above steps for any NEW VM.
•You need to have at least one NEW VM that you have not listened to for the above to work. So if there are no NEW VM, phone your TBB line and create one. Then LISTEN to it from the Remote Phone/ cell phone, or delete it from the Portal, and the light should go off.
•Note that listening to or deleting OLD VM (whether in CURRENT or SAVED folders) will do nothing!
Temporarily Restoring the VMWI to normal operation
You can also try power cycling all individual phones to reset them including their VMWI indicators.
To do so you can simply try disconnecting and re-connecting the telephone wire from the ATA jack "1" - your phone or house wiring.
However, you will have to repeat this every subsequent time the VMWI flashes for new messages....
Please note that this page may not reflect the actual status of the Primus network. It has only come to our attention fairly recently, and we've not had the opportunity to evaluate the accuracy or frequency of updates to this page.
Additionally, this page does not appear to give information specific to expected resolution time, status updates, etc..