Every call has a CIC code (carrier identification code). If callerID was similar to ssl certs, the world would be a better place
185 karma · joined February 23, 2012
In order to combat this, all tier-1 carriers now have ASR (answer ratio) and ACD (average call duration) minimums. In addition, if you have more than ~10% of your calls less than 6 seconds, you get an ADDITIONAL 1-2 cent per call surcharge. That's a lot of money given that my average cost of long distance is .17 cents ($0.0017) per minute.
It's the second tier carriers that is "blending" this traffic with good traffic in order to get the minimums then charge the telemarketers much higher costs per minute.
I think Twilio is going to try to get there - and they have made some progress that's made it difficult to mimic on the backend.
I would hope that their cost structure is flexible enough to allow them to be competitive in the high volume space. That may not be nearly as much margin, but at one point in time, only 2 years ago, 2 customers made up 35% of their revenue (from what I had heard).
Take any developer that knows nothing about telecom and start dialing in seconds. That's extremely addicting - but it is quickly replaced as those bills rack up with pretty small volume pricing discounts.
Switching from twilio to us? Easy. Change the URL.
Switching from AWS - with the insane amount of APIs and toolkits that entrench you into it's structure to someone like rackspace or google? Much more difficult.
I operate a telecom company that mimics the twilio API and we are nabbing their bigger customers left and right. Being fully transparent - our average cost per minute of long-distance is $0.00014 (with 6 second increments) and twilio charges $0.0015/minute (with _60_ second increments).
Wholesale long-distance prices are falling MUCH faster than application providers charging per-call or per-minute. IMHO, That arbitrage will be squeezed eventually as telecom becomes more commoditized.
etcd had a HUGE issue with the implementation of the raft consensus algorithm they were using. This was in version 0.x
The tough part was that, even though etcd 2.0 was released in January [1], it was not put into CoreOS alpha until April [2]
After moving to 2.x - all my problems went away. It had a small learning curve of setting up lots of nodes in the cluster vs proxies [3]. 2.x had a lot of functionality added, but the main one for us was it's reliability. Being able to query status of members, add/remove members from the cluster and monitoring.
Before etcd 2.x, the whole etcd infrastructure would die (and consequently, fleet) if just ONE node restarted. Needless to say, it's come a long way.
We've been running etcd 2.x since January in a container [4], then just doing export FLEETCTL_ENDPOINT=http://127.0.0.1:2379
[1] - https://coreos.com/blog/etcd-2.0-release-first-major-stable-...
[2] - https://coreos.com/blog/coreos-alpha-with-etcd-2/
First persistent storage tackled, then networking and now resource-aware orchestration.
Maybe I should start my own service to harness all this infrastructure with something like swift!
Playing with Swift now - but it has really opened my eyes to how much more difficult 2-3 petabytes of storage is (disk failures, number of disks in your infrastructure, the time to redeploy a datacenter on a 1gpbs connection). All the little problems become much bigger!
People don't understand that flat-rate in this day in age means "I will send you all of my calls that are above the flat-rate, to your flat-rate" - aka LCR'ing the flat-rate. The whole industry has changed so much in the last 4 years. I am excited to see if the $0.0007 flat intercarrier FTC ruling will ever go through.
You are right - if the stats are good, the carrier doesn't care. The stats are the ONLY thing the carrier can control, and should control, imo.
You are exactly right. All the traditional means (like blocking a callerID) is far past it's useful time. The dialer companies are getting smarter as well. It's BIG business for them, so it's worth the money to figure out solutions.
Also, it's very difficult to error on the side of caution - you do not want to block a normal phone call, or your upstream will stop sending you calls and you lose money.
Typically, a dialer customer will hangup once an answering machine is detected (usually around 2 seconds into the call) - causing lots of short duration calls. What the dialer customer's are doing now, is simply holding the call open for longer, to raise their overall ACD. It's a tough game. The moment telecom carriers start caring about what the call is (call types, information in the call, etc) - they become liable.
I don't think it's as simple as people think - for example, simply make sure the person owns the CallerID. At what point in the call stream would that be validated? You have to think that, when a call is made through a typical VoIP provider, it is most likely passed through 10 carriers (through arbitrage long-distance, then IXCs, then tandem/CLLI/POI CLLI).
I believe a good step would be to simply let the FTC trace using the CIC code that all carriers send over the PSTN/traditional telecom network. That way, the FTC could track a particular call or number through all the carriers until it reaches the originating information. The FTC has the capability to do that now, and based on the number of subpoena requests I've received (about 10/day), they actively do it.
The problem is that the companies doing the "illegal" robocalling (business to consumer/DNC or TSR violations) are overseas. There is no way, IMHO, that it can be stopped as long as long-distance providers exist.
All were from trolls/non-practicing entities except for one (which we settled). As soon as we went public, we became a target.
It would come in the form of:
"Hello, we are XYZ company are you are infringing on 1,324 of our patents related to computing and to communicating over USB - we would be happy to not move forward with our lawsuit for the sum of $500,000"
We called it the reverse nigerian prince.
It protected us from the vast majority of trolls - and it really came down to the "thump" test. The thump test is when company A asserts patents against company B. Company A comes storming in the court room (or via plain ole email) and drops it's stack of patents on top of the table. We now have to invalidate each and every claim which puts the vast majority of the burden on us. We would then turn around and drop our borrowed patent portfolio on the desk and it would thump pretty loud as well. That stopped 95% of the major patent lawsuits from moving forward, as stupid as it was. We took an aggressive stance to counter-sue for patent infringement and ALSO to invalidate via prior-art. Instead of sharks smelling blood in the water, we stopped getting the lawsuits because we aggressive sought to not only stop a lawsuit, but to invalidate the patent from ever being asserted again due to prior art which could be applied in any future patent lawsuit case (and in some instances, would invalidate the patent or have it "re-examined")
Unfortunately, I feel there is still a very vulnerable phase of small business between profitable and not profitable enough to employ these strategies. As the MJs of the world (~$200M market cap) start to adapt - the trolls simply get change their nigerian email to $100,000 instead of $500,000 and start working their way down to smaller companies.
http://www.intellectualventures.com/news/press-releases/magi...
Even though the PR seems to say that MJ is joining the force - you can clearly see that none of the original Vocaltec/Magicjack VoIP patents have been asserted against anyone else/used as defense in any patent lawsuit. By playing ball, we were able to use their patent portfolio to defend against the MANY patent lawsuits brought against MJ. It did help in a few cases when we were sued over a number of different VoIP and USB-related patents. From what I remember, though, it was expensive to be in their alliance and you had to contribute your own patents as well. The idea itself is interesting. I think a non-profit could better fill the need for everyone sharing a big patent blanket.
For just momo or momentum traders that deal in extremely liquid trading instruments, microseconds can even make a difference. Our current feed from a US equity exchange is about 220 microseconds or .22 miliseconds - and we are on the "slow" side of things. The guys that actually read, process, send transactions usually go as far as using FPGAs even (some of the bigger firms)
That said - there are still lots of places in the market where opportunities exist!