3 ms·

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?

by j_baker 13y ago

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

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?

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

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