Plivo Launches Bring Your Own Carrier | Hacker News Reader

Plivo Launches Bring Your Own Carrier

plivo.com

48 pointsdhfromkorea19 comments

Perhaps I just haven't spent enough time dealing with telephony, but I still haven't got a clue what BYOC is. Can someone give me a TL;DR?

Hi @j_baker tl;dr -> Cloud telephony platform consists of 3 main components - 1. Technology, 2. Infra/Ops 3. Carriers. Until now we and other providers have offered APIs which bundled all three together. This is good for folks who are just getting started, as customers want to get the best pricing and direct access to carrier when they start to grow. Just like how one can get own merchant accounts with Payment gateways.

Today's announcement means we basically allow you to use all 3 components from us, or just use us for Technology and Infra and bring your own carriers. Rest of the details in the post. let me know if you have any other questions :D

That seems like a far more useful introduction than the one in the article. I mean, I'm sure the plivo vision for telephony is interesting, but I'd rather learn more about what the changes mean to me.

Thank you @j_baker. I will bear your feedback in mind and try my best to make you not need me for some core questions like this next time. :D

Clicking through to their "API" page, their any-carrier functionality seems quite primitive. Basically, you tell them which IP addresses to expect SIP connections from. That's it.

That's what we expose to our customers. There is a whole lot more on the backend. :D

Do tell! Did this capability require infrastructure changes for you? Does it require anything from the carrier? If so, is the requirement one they all meet already, or something only a major customer could bully them into? Will IP-spoofing just be a DOS or something more sinister?

With SIP you have two popular models. HTTP Digest, which requires an extra round-trip to get a nonce to auth, and going off IP. "Carriers" and most high volume folks just auth off IP. If you were using SIP TCP only, this wouldn't be so terrible. HTTP Digest is generally only used for phones and the like.

Except, most folks use UDP, and IP auth is simply broken on many SIP platforms. If you can spoof an IP packet (who can't?) and you know someone's IP that's allowed to send traffic, _most likely_ you can auth as them and complete the call and no one will notice. More paranoid implementations will give each customer their own IP and setup firewall rules, which mitigates the issue.

Either way, using UDP and going off IP is still terrible. Because now, a spoofed IP packet comes in, and based on that packet alone, you're going to start up all the call processing and make a call. The SIP transaction might timeout and end the call in 5-60 seconds, but it's very open to [D]DoS'ing. Oh, and even some major platforms consider 100 calls/sec to be "high volume", so even an unsophisticated attacker could probably bring a lot of systems to their knees via IP spoofing.

The real mitigation is that there's so much low hanging fruit, that hackers are just going after the quick buck by hitting PBXes or phones and calling rebate numbers or 30+ cent destinations.

Telephony has traditionally been a trusted system, and a lot of that's carried over to VoIP.

Yes, it requires very different kind of architecture to be able to interop openly. However, we did design for it from day 1. It does not need anything from carriers and most of the VoIP carriers already support it. We will be pushing out more blogs/docs for specific carriers in coming weeks.

This is the third response in a row in which you're speaking like a marketer. Please understand that on HN this sort of communication is less trusted than no communication at all. Actually, a more believable (if still unsatisfying) answer would have been the last sentence by itself. Your first two sentences are fine, but they don't suffice in and of themselves: you should provide some supporting details. What aspects of your architecture support interop? Don't say "innate, interop-supporting qualities". Say "we're N+1 for more capacity and reliability" or "we have a 'carrier' column in some of our SQL tables" or whatever the actual truth is.

Your third sentence contradicts itself, so it makes you seem either uninformed or deceptive.

If these difficulties should be blamed on non-native English use, please say so.

@jessaustin, Let me try to explain a few more details here:

Inbound Phone Number existing Carrier

Lets assume, you have existing numbers you own with your existing carrier. Carriers usually allow forwarding to certain IP destination or hostnames like sbc.plivo.com, so what you will need to do on your carrier side is to just configure this one time for the numbers with them.

On the Plivo side, for us to be able to enable the carrier to pass through our firewall, you would whitelist the Carrier IPs using our APIs/UI and then add (not buy) the numbers in the system you own with the carrier. That we it allows us to be able to match the incoming calls from a certain carrier on a certain number to a customer app. (there are tons of edge cases here I am not covering, but we have taken care of that in the implementation)

Outbound Calls via your Carrier to phones

This is a bit more tricky and complex as users may want to use Carrier 1 for Country A, Carrier 2 for Country B etc.. so we allow customers to be able to configure this logic using our APIs and assign them with dedicated IPs which allows the carrier to distinguish where the call is coming from for them to bill/ account it.

It may sound simple here, but trust me, when you open up that kind of logic to every customer, it becomes a tough problem quickly and thats where architecture matters. I am not sure, I want to talk about how we architected the system, so will leave it for later discussion.

Regarding DoS or DDoS, IP spoofing is not so trivial, as first one needs to figure out carrier ip, then customers phone number and then all they can do is just trigger the app which can perform some business logic. So again not sure if there is any security risk with this.

Thanks! The outbound piece wasn't clear to me before. If the architecture is the secret sauce, that's OK.

I'm pretty OK with the sort of spoofing you describe, since ISTM it will impact Plivo rather than the Plivo customer.

I just read it and I did not understand anything either.

Hi, I just added some comments above. Let me know if you have other questions. :D

I read that pilivo was allowing me to 'bring my own carrier' 3 times, but I have no idea wtf that means.

Does it have anything to do with paint samples?

Bad marketing page.

DH tried answering this above, pasting it here..

Cloud telephony platform consists of 3 main components - 1. Technology, 2. Infra/Ops 3. Carriers. Until now we and other providers have offered APIs which bundled all three together. This is good for folks who are just getting started, as customers want to get the best pricing and direct access to carrier when they start to grow. Just like how one can get own merchant accounts with Payment gateways. Today's announcement means we basically allow you to use all 3 components from us, or just use us for Technology and Infra and bring your own carriers. Rest of the details in the post. let me know if you have any other questions :D

Here's a related Forbes article: http://www.forbes.com/sites/tomiogeron/2013/08/14/plivo-targ...

Is this just SIP trunking?

@thesis, thats a great question.

Answer: No its not just SIP trunking. We have always supported native SIP trunking (in, out & device registrations) from day 1 we publicly launched in July 2012.

With BYOC launch, we now allow/make it simpler for any developer, business to be able to use existing VoIP carriers and plug in our APIs to build powerful apps. Its completely plug and play. e.g. we offer a dedicated IP to authenticate with, for folks who want to plug in outbound carriers to terminate calls.

Reply on news.ycombinator.com