We get 10 to 20 junk phone calls per day, and most days have no legitimate calls. This is getting ridiculous; why should we pay big bucks to our landline provider (Frontier) just to get spam? The alternative is a non-carrier VoIP provider.
Abstract: We signed up with CallCentric and we got the OBi200 ATA (Analog Telephone Adapter) by Obihai. Setup is far from plug and play, but someone familiar with configuring services can get it right on the first try. VoIP service is working as it should. But we were unable to meet our goals for digital security and for communication during a disaster.
(There is a glossary of acronyms at the end of this document.)
The goals of this service change are:
We want to call and be called by our friends and service providers (e.g. doctors) relatively normally and hassle-free.
We want to drastically reduce the rate at which we receive calls from telemarketers, scammers, and similar lowlife.
We want to reduce our cost for voice chat service.
Constant handholding is to be avoided; the solution has to stay functional and/or self-heal despite normal upsets in the network.
We want a reasonable balance between availability, security and useability. In particular, we would like to be able to communicate despite a local or wide-area loss of electrical power. We are unlikely to get what we want here.
Given the security climate in today's world, we want to use best practices for digital security.
These goals can be turned around to these issues:
We have to accept calls from people (e.g. doctors' offices) whose phone number we didn't know before. Thus a draconian whitelist is not going to fly: all numbers missing from the whitelist are (not) rejected. This means that some unwanted callers, particularly humans, will be able to jump through the gateway hoop.
We want to reduce costs, but we also value reliability and service, so it is very unlikely that we will pick the lowest priced carrier.
One of the highly rated ATAs wants you to configure the box via their web portal. Companies go bankrupt, are eaten then discontinued, or otherwise disappear. It's essential that we should be able to configure and troubleshoot the box autonomously. Logging to our syslog server is a big plus.
We are not the specific targets of geopolitical enemies or criminal gangs; nonetheless we are more aware of security issues than most users and we would like to use secure protocols for VoIP. And we insist on secure procedures for administering our ATA.
The traditional landline is powered from the central office, with good backup, independent of house power and of internet screwups. But now with FIOS, we're doing VoIP from the ONT to the destination and that depends on house power (with about 2 hour battery backup for the ONT). With the new VoIP service we'll be relying on our home server. Its battery backup lasts about half an hour, but more of a problem, the ONT shuts off IP service when power is lost (to save battery).
Most VoIP providers will fail over to a PSTN number, including cellphones, if the IP connection to the customer is lost for any reason. Outgoing calls can also go by cellphone. Cell towers are supposed to have battery backup, but how long can the battery run the tower? And batteries degrade with time, particularly if outdoors; are these replaced on an adequate schedule?
Although it is very likely that the ATA will interoperate with all our home phone devices, this should be checked carefully. Specifically, we should set off our intrusion alarm and see if it successfully notifies the outside security provider.
A provider with geographic redundancy is preferred. For example, CallCentric is located in New York City, and during Hurricane Sandy both their primary power and their backup flooded out, so they were down until the waters abated.
There are a lot of VoIP companies in the United States (and worldwide).
Here is a list, far from inclusive, resulting from a search on Google for
VoIP companies in USA. Numerous
10 best lists appeared;
bestness is not necessarily rated according to our criteria.
For cost quotes I'm targeting a plan with an
incoming phone number and about 100 minutes per month of prepaid
outgoing credit to PSTN within the United States. Setup charges and the
cost of the ATA are excluded. Business-oriented services are excluded.
One of the earliest VoIP companies. $10/mo, I think you have to use their ATA, which may be included in the current promo. Hard to get info from the website.
$10/mo. ATA is
$6.21/mo ($149 for 2 year contract). Located in Irvine, CA.
$4/mo. Located in New York City. They don't sell the ATA; you buy your own, or use a pure software solution.
Our son has been with CallCentric for several years and finds their service to be excellent. The recommendation of a satisfied customer counts for a lot. I was also surprised to find that CallCentric has the lowest price of the providers checked, although I believe that several non-checked providers have slightly lower prices. What do they have available and how well does it meet our needs?
We need a plan for outgoing and for incoming calls. Technically the incoming part is optional but it's a little bizarre to have a phone that nobody can call.
Outgoing plans: Calls cost $0.0198/minute after your plan minutes are
used up. There is a $1.50 setup fee except not on the free plans.
Taxes are in addition to these prices. The fee for 911
service is $1.50/mo but you can opt out (not recommended).
All plans cover calling to
America meaning USA, Canada and Puerto Rico, but Mexico is an
international call priced separately; see below for the (low) price.
Incoming plans: Setup is 1 month's cost except where noted. Phone
numbers are available in a lot of places (I can't say for sure
place) in the USA and Canada.
We would get per call outgoing and incoming, which would cost:
telecommunication carriersand so avoid taxes except for billing addresses in their jurisdiction of physical presence: New York City for CallCentric.
To use the service you can use phone software on your non-mobile computer, or an app (theirs or a generic one) on mobile devices, or an ATA which you purchase (not from CallCentric). Android 5.1 "Lollipop" and above intrinsically supports SIP (I don't know how far back the support goes), so you don't need the app unless you need more than generic features. Asterisk PBX software (and 5 others) works with their service. All the software has to do is do the SIP protocol with their server; you can use any of these strategies at different times or simultaneously, from any IP addresses, or you can restrict to your fixed IP if you have one (typically for business).
Sample international rates (per minute, mid-2016):
|Country||To Landline||To Mobile|
|North Korea||Only $0.80/min|
|USA||$0.0198 (after your plan minutes are used up)|
There are about 35 features apparently included with all numbers. These are jimc's highlights. Some of them can be turned on and off on the fly with star codes.
Some bloggers are leery of a VoIP provider that doesn't do phone support. I have interacted with CallCentric customer support through their web form and ticket tracker on several issues, and I have been very impressed with how prompt, helpful and professional they have been. New VoIP users considering CallCentric, who are able to describe an issue comprehensibly in written form, need have no worries about getting customer support.
CallCentric's ATA compatibility list:
$50, SBSF Amazon. Includes T.38. Configure to use up to 4 VoIP providers at once. Available codecs: G.711 u or a, G.726 (32kbps), G.729, iLBC. Wi-Fi or Bluetooth (via USB, sold separately, $20). FXO = Can originate calls to PSTN carrier (via USB, sold separately, $40). Ports: power, RJ45, USB, RJ11. Configuration: Log in to their portal. (Jimc research: it is possible to turn on autonomous web configuration.)
Note: a wired network connection is always better than Wi-Fi or Bluetooth. Use the latter only if a wired connection is really impossible.
$70, SBSF Amazon. Includes T.38. Similar to OBi200 except 2 RJ11's (for 2 separate numbers, can chatter at once), and 2 RJ45's, 1 to wild side, 1 to LAN, QoS priority for voice chat. Dimensions: 4.1 x 4.5 x 1.2 inch. First on Amazon: 2012-02-25.
$47, SBSF Amazon. Similar to OBI200 except no USB, no
only 2 VoIP providers, no iLBC. On Amazon: 2011-03-24.
OBi website says these products are at end of life.
Same as OBi100 except can originate calls to PSTN carrier. (OBi200/202 uses a USB dongle for this.)
88% 4+5*, 12% 1,2,3*. Most people love it; featured review tells of $2000/year savings for a home business. Most people are using it with Google Voice which is Obihai's recommended use case. 2 bad reviews I saw: 1 died in a year (others update reviews after 2-3 years saying it's still great); 1 had trouble getting warranty support.
SPA112: $49 SBSF Amazon ($34 from affiliate). SPA122 about $7 more. First on Amazon: 2011-11-15. 2 RJ11 + 1 RJ45, serve 2 lines at once. Reviews: Apparently when first sold it had firmware bugs, fixed during 2012. Recent reviewers mostly think it's good, except T.38 may be flaky (but this was from 2012-12-23, obviously another firmware bug.)
$38 sold by affiiate, fulfilled by Amazon. 2 RJ11 1 RJ45. On Amazon 2016-02-26. Not a lot of details. No reviews yet.
HT702: $70 for a pair, SBSF outside vendor. $34 from affiliate, fulfilled by Amazon. 2 RJ11 + 1 RJ45. T.38. Supports TLS/SRTP/HTTPS. HT704 has 4 RJ11s. Includes vertical mount stand. Codecs: G.711 G.723 G.729A/B iLBC. On Amazon 2012-02-18. Can log to remote syslog. Hard for ordinary user to configure and troubleshoot. One person (after extensive troubleshooting) complains about losing registration (firmware bug?) One reviewer junked his HT702 and replaced with a OBi200 which was much better for him.
$198.61, forget it.
$139, forget it.
Not on Amazon.
Not on Amazon.
$82, SBSF outside vendor
Not on Amazon.
All the products sold by and shipped from Amazon were on the compatibility list. A fair number of products from Amazon affiliates (outside vendors) were not on the list, though. Generic products that can do SIP are likely to work, but no actual confirmation of success is posted.
Discussion of ATA: The Obi products are the most favorably reviewed; the Grandstream and Cisco (including Linksys) products have a lot of complaints. Obi's cost is competitive (some competitors are ridiculously expensive). Doubtful issues have been resolved to my satisfaction as follows:
If the Obi portal were to be discontinued, is there an autonomous way to configure the device? CallCentric support page on this topic: Yes. Dial arcane codes on the phone, to enable web configuration access. Discover the IP address of the OBi202. Web browser to http://$IP/ Give basic authentication: admin/admin. Disable Obihai provisioning (their VoIP service). Configure CallCentric provisioning. Jimc research: the web interface is (now?) enabled at the factory, no need for arcane codes.
Can the Obi products log to a remote syslog server? Obi forum thread on this topic (2011-04-19): Yes. Instructions here for newbies.
Conclusion: I think I'm going to get the OBi200.
Product pages and users manuals can be downloaded here.
Settings for a generic ATA or software:
We need to decide the network geometry that will make QoS most effective.
The standard configuration is to get a OBi202, connect its uplink to a DSL router (which provides RFC 1918 IP addresses like 192.168.1.1 by DHCP), and connect the home computer or other clients to the switch port. The OBi202 acts as a network switch and gives itself QoS priority, not letting lower priority activities on the local net interfere with VoIP traffic. This is not going to fly on my net.
Our Jacinth does the same things as the DSL router, but it hosts a virtual machine called Claude which is our wild-side webserer, so Jacinth itself has to do QoS for all clients including Claude. I plan to add a mini-hub for the local LAN. I'll connect the MOCA bridge (to the rest of the clients in the house) and a new OBi200 to it, with the uplink to Jacinth's LAN-side NIC.
I need to adjust Jacinth's traffic shaping rules to properly handle VoIP, which it doesn't recognize now. Traffic on my net is modest, and it will be feasible to set everything up first without dealing with traffic shaping. Then once everything is confirmed working, I can add the priority level for VoIP. On a heavily loaded enterprise net this strategy would not be prudent.
The Obihai OBi200 arrived. The box includes the OBi200 (RoHS compliant, about 69 x 69 x 25mm), a wall wart, a 1 meter Ethernet cable, and instructions. A phone number on the OBitalk network is preassigned, on the label on the bottom of the box. The MAC address and serial number are also shown. Apparently it is pre-configured for their network and you can use it to call and be called from within the network, without registering on their website.
Register the MAC address of the OBi200 with my firewall and assign a fixed IP address. Hostname: Toucan. It will discover its fixed address and the default route by DHCP from my DNSmasq service. Most people do not use MAC registration and use a random DHCP address.
I already have a Netgear 10/100 Fast Ethernet Switch. It draws 3W when booting, under 1W when idle. An alternative is the OBi202 ($70 on Amazon, $20 more) which has a three port switch built in with QoS preconfigured, in case your main router doesn't do QoS (Jacinth does).
Find a place for the switch and the OBi200 (Toucan) in Jacinth's cabinet. Present connection: local LAN MOCA bridge (100Mbit/sec) to Jacinth's internal NIC. Change to: MOCA bridge to switch, switch to Jacinth NIC and to OBi200. [Done and working.]
Steal a wired phone and connect it to the OBi200. Don't connect to the house phone line yet; only one ring generator should be online, and if you have both the OBi200 and the ONT connected at the same time, it's bad for both of them when one or the other rings the phones.
Make a test call to the Obitalk test number: **9 222 222 222. Yay, what I say is echoed back to me with a half second delay, demonstrating bidirectional connectivity. No adjustments were needed in my aggressive firewall rules.
According to the setup instructions, the web configuration interface of the OBi200 is enabled at the factory. Just browse to http://toucan.cft.ca.us/ (substitute your own hostname or its IP address). Basic authentication: admin/admin. Yes, it works. They tell you a dial code to make it recite the IP address over the phone (except I already know its fixed IP). It does not do IPv6.
Generic instructions for setting parameters:
Defaultcheckbox to the right of the value, and then fill in the desired new value.
Parameters set up on the web interface, before configuring for
CallCentric. When you change parameters
remember to hit
Submit on the web form.
The web interface is simple but competently done.
admin. It looks like the user name
admincannot be changed. The password display is limited to 8 bytes but with a longer password of 18 bytes the whole thing is required for authentication. This is Basic authentication over HTTP, hiss, boo! It is possible to use a nonstandard port but I don't think TLS is supported.
Signup for a free account. Fill out the new customer web form. The maximum length of the password is 15 bytes.
Sign Me Up.
(*xx.|**275*x.|11|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)Hit Submit when finished. Reboot required but probably can be deferred. See below about digit maps.
Original value was:
My Account(next to
Welcome James Carter). In the upper left corner will you find your full name, username, CallCentric number, and credit balance. Copy the CallCentric number.
Status: Registered (server=IP).
Your phone is registered(formerly not registered). Assuming all went well. I got it right the first time.
Receive a Free Test Call. It will connect you to the same service. OK, it worked. Continue to purchase a rate plan.
See this useful blog post about digit maps from Aveo Systems. Digit maps are defined in RFC 3435. It's basically a modified POSIX regexp with alternatives separated by '|' (pipe). When the dialled number matches one of the choices there's a short wait for more numbers to come in, then the number so far is dialled. 'x' matches any digit; '.' (dot) means the preceeding unit is repeated zero or more times; digits or ranges in  match any one of the enclosed digits.
You have to have a working SIP connection before you can pay to use it. In other words, you need to successfully finish the above configuration steps. From the Test Call page, follow the link to Purchase Rate Plan.
usually available in 1 business day. Since we're porting a 310 number, I suspect it will be easier if I get the assigned 310 number. (Wrong; I should have taken 424.) They're going to bill me for 1 month and 3 days so my billing cycle ends on Sept. 30. $2.14 service plus $3.95 setup.
To hell with patience! I'm going to go out and kill something!After checking with customer service (quick response!) I cancelled the DID in 310 and ordered a new one in 424. I was able to call the new number from my cellphone.
The PBX software on the VoIP provider's server lets you route your calls
in a wide variety of fantastic patterns, called
Log in to your CallCentric account and go to Call Treatments in the left
Add a New Call Treatment. These are the fields in the
call treatment record:
number is no longer in service. For telemarketers.
Our call treatments: They should be applied in this order; on the summary page there are arrows to re-order the rules. At the bottom of the form put a title or description to help you remember what the rule does. All our call treatments apply at all times. Since my Spit (Spam via Internet Telephony) reputation is good, I can't really test the telemarketer blocking until after we port our number.
Discussion of the default rule: I could make the default to be the telemarketer blocker. But we get robo-calls from doctors' offices and pharmacies which we want to actually receive. So I'm only doing the telemarketer block thing when the number's spam reputation is high.
What to do to telemarketers: Initially we used the telemarketer block feature, and it was quite effective; we had a dramatic reduction in the number of unwanted calls. However, to do the telemarketer block thing, CallCentric has to accept the call and talk to the telemarketer, for which they have to pay their upstream provider, and charge the customer, whereas SIT tone 1 or another standard error message is free. We found that we were paying as much for telemarketer blocking as for the fixed charge for the line. It was a lot less than for our PSTN landline, but even so we were annoyed, and so we adopted a less nice strategy for the telemarketers, SIT tone 1 (number not in service).
In e-mail I had a very bad experience when my outsourced provider added a
reputation-based filter and tossed (refused to accept) mail from any source
with a bad reputation. My work server got blacklisted because a lot of users
forward all mail, including spam, to Gmail. Of course the
solution is to run all outgoing mail through SpamAssassin, but management
didn't accept this solution. So I fired my e-mail provider. It's important
when using a reputation-based filter to accept the traffic but to tag it or
otherwise apply a non-fatal mitigation strategy.
Under Preferences - General - Send unanswered calls to message after: The default is 30 seconds. I left it that way, but the traditional value for PSTN is 60 seconds, to give the farmer's wife time to come in from the barn and answer the phone.
Voicemail is considered to be a separate product at no cost. Once you
order it you get a tab for it under Preferences. The defaults look fine,
except you need to set the PIN (4 digits). To do so, follow one of several
links to Preferences - Voicemail and Edit the Global Settings. To
listen to voicemail: from the CallCentric (home) phone(s) dial *123 or *86,
then follow voice prompts. From outside, dial your CallCentric extension (home
phone); wait 30 secs for the
leave a message prompt; as soon as it
starts playing dial * and your PIN ended by #. If you have separate mailboxes
for multiple extensions, dial the extension before the PIN (no separator).
Then follow the prompts -- 7 to delete the current or most recently played
To set up your phone book the easiest way is to export an existing phone book as a CSV file. Field order is speed dial code (4 digits, leave empty if not used), full name (in double quotes, last name last), phone number (with country code, digits only, no spaces), group name (quoted if it contains blanks; leave empty if not used). To make sure, add an item by hand, export it, and inspect the result. When you import, new entries will be added, duplicates will be ignored, but if the full name or the phone number matches an existing entry the imported record will replace the existing one. (So a person's phone number could be changed, or the person owning a phone number could be replaced.) I wrote a small script to extract the needed fields from a file of vCards (VCF) and write them out as comma separated values (CSV). Then the file needed hand editing to exclude irrelevant numbers. I then imported this file.
See CallCentric's FAQ about Local Number Portability. Jimc's excerpts and history of what happened:
billfrom the losing carrier, to prove that you have administrative control over the number being ported. For Frontier the relevant information is scattered over several documents. You need to show the owner's full name (this appears to mean the first and last name; middle name may be optional), the service address, the account number and/or the primary phone number on the account, and the number being ported if different. Obtain the documents. The standard method is to view your bill online, print relevant pages, and scan them. Wait to scan until you have your agency letter.
losingcarrier to do their part. CallCentric says the average time to port a number is 25 days. CallCentric will notify you when it's about to happen. It turns out that Frontier did the job in 6 days.
We started out with Verizon FIOS Digital Voice, and Verizon's 15/5 Mbit/sec Internet service, later upgraded to 25/25 Mbit/sec. Verizon FIOS was sold to Frontier Communications, which continued the services unchanged. But there is a botfly in the ointment: both of them are phone companies, and the entire account is keyed on the primary billing phone number. Which now belongs to CallCentric. Therefore you need to guide them through the transition process. Other people who let nature take its course found that the natural state of disloyal customers is to not have Internet service any more.
On the porting day I checked when it actually happened. CallCentric and I notified each other when the ported number seemed to be functional. Then I got on the (CallCentric) phone with Frontier customer service. I'm omitting a lot of details in this tale…
Fortunatelythe customer service rep can do the credit card transaction over the phone. Be sure to write down the confirmation number; you will need it when they lose your deposit.
-A TRUSTED -p udp -m udp -m multiport --dports \
kpasswd,openvpn,syslog -g TRUSTEDa
This is tested on CyanogenMod-12.1 based on Android-5.1.1
Hardware is a Samsung Galaxy S5 model SM-G900M (should be irrelevant).
CallCentric's support writeup about Android, which is actually for
Kitkat. To set it up:
cell standbybattery use category. So I am reverting to use my cell carrier. I could turn SIP back on to make an international call.
VoIP traffic needs to be sent out promptly and reliably, and in particular,
it needs priority over
hog flows like downloading a giant file.
This kind of traffic control is generically referred to as
Quality of Service. My traffic control script uses QoS code points
(action numbers) from RFC 1349 to decide priority. But RFC 1349 is now
deprecated and is superceded by RFC 2474. I need to revise and improve the
That turned out to be a lot harder than anticipated, but I finally figured out what was really going on, and now VoIP is getting its proper priority both outgoing and incoming. It turns out that RFC 2474 is totally useless, and I need to ignore the QoS code points and use other means to recognize the flows that need high or low priority. See my separate writeup on QoS (Quality of Service).
First we need to be clear about security in VoIP. There are two phases in VoIP: SIP signalling, in which you identify yourself to the server and tell who you want to call, followed by sending and receiving the voice payload, normally using RTP. Secure protocols exist by which you can keep both phases secure from prying ears in transit from your site to the VoIP provider.
However, in the United States telecommunication carriers including VoIP are subject to the Communications Assistance for Law Enforcement Act (CALEA) and the Foreign Intelligence Surveillance Act (FISA). CALEA requires that the carrier must design their system so law enforcement personnel could listen to and record the throughgoing traffic. Read the writeups and the law text to see when a warrant is required -- basically when one end of the conversation is a USA citizen or permanent resident -- and what the law enforcement personnel need to allege in order to get a warrant.
There is extensive discussion about whether these laws are appropriate and/or abused, all of which is off topic for this document. But also, USA government agents are not the only ones who might be interested in a high-value conversation: other governments are known to steal secrets, and industrial or business espionage is a well-known threat. If you have something to hide, you need to assume that provider personnel have gone over to the dark side (or to the side that you are not on) and are in collusion with the enemy.
In addition, once the traffic reaches your provider you do not have direct control over how it is protected (likely, not at all) on the often multiple hops to the recipient.
Thus it is pointless to use secure protocols to your carrier's server. If you are serious about security you need to run VoIP server software on your own server that is inside your own security perimeter, and to communicate only with partners who that server can reach directly. Or you should set up your and your parters' cellphones so they can accept SIP connections peer to peer (using security) rather than going through a central server. Then you only need to concern yourself with traitors within your own organization, and subpoenas directed to your own organization.
Nonetheless, as a wearer of the tinfoil hat, I want to finish the ultimately fruitless project of investigating what security the OBi200 is capable of doing, and how much CallCentric will support it. In the configuration pages of the OBi200 check out these items:
I raised the syslog level to 7 and turned on the above items one at a time in the order listed above. I could have diagnosed the problems better if I had used tcpdump or wireshark, but since failure is a foregone conclusion, because subsequent transport hops are likely unprotected, I'm not going to put a lot of work into these tests.
The biggest problem with VoIP is, if your digital network goes down you get silenced. Threats to the digital net, ordered in jimc's opinion of likeliness, are:
Suppose you had solar power and a big battery, so you could run your
house network through a long power failure or other loss of outside
connectivity. What kind of a
back door could you get? A wormhole
through Hausdorff space is attractive, but the technology is not mature and
there are no commercial products. The only credible alternative is satellite
communication. I didn't put a lot of time into this research, but this
article makes some good points:
How and When to Buy a Satellite Phone in Forbes (2013-03-18) by
Marc Weber Tobias. Jimc's highlights from the article:
Some research on prices:
unitsfor $99 USD, lasts 90 days, voice and data to PSTN cost 1.3 units (dollars, effectively) per minute. 0.5 unit per outgoing SMS, free incoming SMS. An expired SIM can be reloaded (you avoid shipping charges and delays). Costs are higher to other satellite phones.
Conclusion: This kind of backdoor may be attractive to some people, particularly if you have an ongoing business need or if you provide emergency services, but with those prices a casual user is advised to make do with 19th century communication (carrier pigeons) when electrical power fails.
Wikipedia article about Telephone Number Mapping (ENUM). ITU-T E.164 is a scheme by which ranges of phone numbers are allocated to countries (using country codes) and within that to carriers, under national jurisdiction. Per RFC 2916 (2000) there is a domain $number.e164.arpa (where $number is the phone number, little endian, with dots between the digits). The RR(s) with this key are a NAPTR record (per RFC 3403 (2002)) which indicate a URI that should be connected to, which could point to your VoIP provider or some alternate.
Unfortunately ENUM is not supported by many countries, specifically country code 1 (North America). Here are a few countries having e164.arpa. delegated domains: 44 (UK), 43 (AT), 49 (DE), 46 (SE), 358 (FI), 86 (China, PRC), 886 (China, Taiwan). Countries checked but not having domains: 1 (North America), 7 (RU), 45 (DK). There is an alternative registry called e164.org and North American users can register there, but only a minority of users do so.
I do not have an operational need for anything other than the default SIP URI, so I'm not going to register with e164.org.
Yet to do:
All items are finished.
Get the OBi200 to log to our syslog server. [Done]
For survivalist kitsch, what would it take for us to be able to communicate despite a wide area long duration power failure, like after an earthquake? See section above.
Wait for the incoming number to be assigned. I killed it and re-ordered in 424, successfully.
Set up call treatments (e.g. block telemarketers) on CallCentric. [Done]
See how much secure protocols CallCentric can handle [none]. Write this up.
Test the Android support for SIP via CallCentric. [Works]
Test our intrusion alarm and make sure it works with the OBi200. [Works]
Port our existing number from Frontier to CallCentric. [Done]
Add VoIP to the router's traffic shaping rules. This is a lot more complicated than it seems. See my separate writeup on QoS (Quality of Service). [Done]
Here are some suggestions I have for CallCentric:
For LNP (porting), the user needs to scan documents and upload/attach them to his trouble ticket. The instructions should state what format CallCentric prefers. I'm going to put all of them into one PDF file. This worked; Customer Service were able to use them to port the number.
When a new account is created, CallCentric sends a domain validation message to the specified e-mail address. The customer is supposed to follow the link, and a cookie in the query-string is recognized by CallCentric as proof that the customer has administrative control of that e-mail address. But there are two links, one with the cookie in all upper case, which is rejected, and one with mixed case, which is the one that the customer needs to use. The upper case link should be removed. I was viewing the message as text/plain with webmail (Roundcube); it recognizes a text string resembling a URL and wraps it in an 'A' element.
CallCentric does not set QoS on its outgoing packets. Or at least when they arrive at my end the code point is 0. RFC 2474 allows routers to mangle the DiffServ code points. When diagnosing a problem, CallCentric customer service captured my packets at their end: My OBi200 sent them with appropriate QoS code points, and they arrived with all zeroes. I don't have a similar smoking gun for the reverse direction, so I'll say this minimally judgmentally: if CallCentric isn't setting QoS, they ought to, as a good example to the community.
CallCentric does not support secure VoIP protocols: SRTP, and SIP over TLS. I agree that for a carrier to support secure protocols is a joke and to some extent is dishonest; however, CallCentric should discuss this issue in their FAQ so newbies understand the reasons for non-support.
Internet Protocol. This is the basic format of a packet on the Internet; within the payload area of the IP packet a variety of more specific protocols have been defined. IP is governed by RFC 791 (1981) and RFC 2460 (1998) (both as amended).
Voice over Internet Protocol. The voice chat payload is sent to (or partway to) the partner using the packet switched internet protocol.
The kind of telephone invented by Alexander Graham Bell. Wires run across the land (ocean cables have different technical issues) from the central office to your analog phone.
Public Switched Telephone Network. While it is relatively simple to connect phones whose landlines run to the same central office, citywide and nationwide service requires a network of trunk lines between central offices, using VoIP or older technology, and called the PSTN.
Analog Telephone Adapter. Connects the digital world, i.e. your VoIP provider, to traditional (analog) phones. All the phones in the house (within practical limits) can share one ATA.
Fiber Optic Information Service. Packet switched internet traffic is carried to and from the customer. Television signals can be distributed in parallel using different technology.
Optical Network Terminal. It receives the FIOS signal and sends the payloads out to the customer's home devices. Specifically, it can act as an ATA from the carrier's own VoIP service.
A list of partners, in this case phone numbers, which are either allowed or blocked from communicating.
Private Branch Exchange. The caller dials your company's central number, then can dial an extension number to reach numerous phones in the business. Modern software like Asterisk has features like voicemail and is useful for both large and small phone nets like a family or a home business. See also DID.
Direct Inward Dialing. A range of phone numbers is registered to be routed to the VoIP provider, PBX, or shared FAX interface. The term DID is also used to refer to a single one of those phone numbers that you rent from your provider.
Session Initiation Protocol, for setting up multimedia communication, not just voice chat but video calls, a shared whiteboard, and other features.
Realtime Transport Protocol, optimized for sending a media stream almost isochronously, i.e. the recipient gets the data at the same time it happens and is recorded by the sender, as near as possible.
Secure Realtime Transport Protocol. See also ZRTP.
Quality of Service. In IP this is handled by the Differentiated Services (DiffServ) field of the IP header; see RFC 2474.
An ITU (International Telecommunications Union) standard for transmitting FAX over IP.
Connectors for an analog phone line (RJ11) or Ethernet (RJ45). The RJ11 has space for 6 wires of which usually only 2 are connected; the RJ45 is similar but has space for 8 wires.
Sold by and ships from …