5 ms·

Plivo Launches Bring Your Own Carrier

48 points by dhfromkorea 13y ago

dhfromkorea 13y ago
Here's a related Forbes article: http://www.forbes.com/sites/tomiogeron/2013/08/14/plivo-targets-big-enterprises-with-bring-your-own-carrier-cloud-telephony/ http://www.forbes.com/sites/tomiogeron/2013/08/14/plivo-targ...
j_baker 13y ago
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?
- xutopia 13y ago
  I just read it and I did not understand anything either.
  - dhfromkorea 13y ago
    Hi, I just added some comments above. Let me know if you have other questions. :D
- jessaustin 13y ago
  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.
  - dhfromkorea 13y ago
    That's what we expose to our customers. There is a whole lot more on the backend. :D
    - jessaustin 13y ago
      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?
      - dhfromkorea 13y ago
        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.
        jessaustin 13y ago
        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.
        bevenky 13y ago
        @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.
- dhfromkorea 13y ago
  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
  - j_baker 13y ago
    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.
    - dhfromkorea 13y ago
      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
deleted 13y ago
[deleted]
fowkswe 13y ago
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.
- bevenky 13y ago
  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
thesis 13y ago
Is this just SIP trunking?
- bevenky 13y ago
  @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.

48 points by dhfromkorea 13y ago

Here's a related Forbes article: http://www.forbes.com/sites/tomiogeron/2013/08/14/plivo-targets-big-enterprises-with-bring-your-own-carrier-cloud-telephony/ http://www.forbes.com/sites/tomiogeron/2013/08/14/plivo-targ...

j_baker 13y ago

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?

xutopia 13y ago
I just read it and I did not understand anything either.
- dhfromkorea 13y ago
  Hi, I just added some comments above. Let me know if you have other questions. :D
jessaustin 13y ago
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.
- dhfromkorea 13y ago
  That's what we expose to our customers. There is a whole lot more on the backend. :D
  - jessaustin 13y ago
    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?
    - dhfromkorea 13y ago
      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.
      - jessaustin 13y ago
        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.
        bevenky 13y ago
        @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.
dhfromkorea 13y ago
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
- j_baker 13y ago
  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.
  - dhfromkorea 13y ago
    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

deleted 13y ago

[deleted]

fowkswe 13y ago

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.

bevenky 13y ago
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

thesis 13y ago

Is this just SIP trunking?

bevenky 13y ago
@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.