4 ms·

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 carr

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

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