5 ms·

It's a real shame that they couldn't make a SIP client and leverage VOIP. VOIP is used by a lot of businesses and I believe it would really improve Web adoption

by hendry 12y ago

It's a real shame that they couldn't make a SIP client and leverage VOIP. VOIP is used by a lot of businesses and I believe it would really improve Web adoption if the Web could support it.

MichaelGG 12y ago
WebRTC is sort of a hack up of SIP-similar technologies, and is definitely VoIP. SIP and SDP are also clusterfucks of protocols with some really, really, terrible design decisions. (Hey, let's specify UDP _AND_ TCP, and require clients to flip between transport on a per-message level! Why not? It's easy to spec idiotic stuff on paper...) Anyways, SIP does not NAT well as it assumes, like it's the 1980s, that you are on a public IP and can directly send to any port on anyone's public IP. Then it goes and embeds your IP all over the place, because they were too cool for simple symmetric pipes. To make it more fun, all sorts of firewall and router vendors try to "fix" SIP and generally just screw things up even more. As I understand, a lot of WebRTC effort went into dealing with NAT and some other niceties. (And apparently, arguing about codecs.) Otherwise, you're right, there's not a whole lot to be done. Despite the terribleness of SIP, it generally works, and VoIP engineers have figured out how to make it work pretty well. However, it's unlikely that re-using parts of SIP/SDP in WebRTC makes _any_ difference in adoption of things. Almost no one runs SIP openly, they lock it down like a traditional telephony system. Best is in fact to firewall it off, because you're rather naive if you trust all this C/C++ code parsing strings like mad. Plus, since SIP systems are often connected to other telephone networks with billing, even protocol-level hackery can lead to a lot of financial loss. So in short, it'd be super duper unlikely you'd ever be able to point your web browser at "sip:someone@somebusiness.com", even if it had SIP built-in.
- voltagex_ 12y ago
  One day I hope someone can call my email address. That's all I want - Google Talk/Hangouts almost had it, then they closed off the protocol.
  - MichaelGG 12y ago
    You can do that with SIP now. But with email, getting a bunch of spam can be handled in bulk, and letting a few slip by isn't disastrous. With phone calls, it could be much worse. As I understand, Google killed xmpp federation for precisely this reason.
    - stephenr 12y ago
      Google killed XMPP federation because supporting open standards that allow people to use non-google services easily are bad for business.
      - MichaelGG 12y ago
        You can say that, but Google has stated it's because federation was not used that much and that the spam aspect of it was the dominating usage. Which makes total sense and XMPP does not solve it, and in fact it's hard to see a solution for this problem that doesn't rely on a centralized solution. Feel free to propose one. Because if you can solve it for XMPP, you can probably solve it for SMTP and become a billionaire for fixing spam.
        stephenr 12y ago
        Google can say that, but I and many others simply don't believe them. Google is a business, and an advertising business at that. It's literally their job to try and make us believe what they say, regardless of the truth.
- vladimirralev 12y ago
  SIP and SDP are not clusterfucks. Pretty much everything is done for a reason. Often it has to do with scaling and load balancing. Flipping transports is just a side effect of a useful feature where you send INVITE through a proxy that doesn't record-route so it's bypassed on the next message meaning you will have to use the transport of the next node in the chain. You never change the transport between the original endpoints just randomly for no reason. You are simply connecting to another server which prefers the other transport (or is not under your control). TCP or UDP have significant differences and tradeoffs in load balancing and tunneling traffic, each has a place. If you are building huge telecom systems most of this makes total sense in one situation or another. No signalling protocol can be used "openly", there is simply too much potential for abuse. Integration and especially selective integration on the other hand is quite good with SIP.
  - MichaelGG 12y ago
    Well I'm, on my third pass around writing a SIP parser/stack, and I'd have to say, no, things are not done for a reason. The silly date format ("Thu, 25 November, 1921") is a relic from the 70s and only there because that's what someone happened to be doing on some private little mail system. And the IETF just blindly copies nonsense like that, even though there's zero benefit to an English-specific long-date format in a protocol. SIP headers, in the wild, cannot be unambiguously parsed. This is because the whole \r\n thing to end lines combined with the SIP RFC's instructions that implementations should "infer meaning" ends up with some implementations considering \n\n to be start of data, and some not. Good luck. Not to mention idiocy like "comments in headers", "line wrapping". Or my favourite "put headers in the querystring". Because nothing makes ensuring your implementation is correctly following messaging (on which tons of money may ride) than specifying not only two ways to define a common header, but adding two distinct locations to find the same data. Or the awesomeness of deciding "IP fragmentation is broken" (???) and deciding on an arbitrary MTU size at which point you've gotta flip to TCP. Literally, on a message-by-message basis, they see nothing wrong with requiring you to read from both a UDP and TCP socket to get the next message for a transaction. I'd go as far as saying they think they're being clever. The only point of using UDP (complete with their own retransmission system to deal with packetloss) is if you think _maybe_ you're gonna shave off 1xRTT by avoiding a TCP handshake. Except since most calls are going between well defined endpoints, that's not an issue. And secure calling requires TCP (TLS) anyways. The real result is that plenty of implementations end up doing UDP only, or only really supporting UDP. And why MS decided this was idiotic, and went TCP only because "most of our messages will exceed the MTU". Oh, and the kicker? IP fragmentation works fine. I analyzed a VoIP network (several terabytes of SIP signalling) and found about 1-2% of SIP messages were IP frag'd (MTU around 576) and never did IP frag mess anything up. All this crazy complexity because Rosenberg et al thought they were oh-so-clever about a non-existent problem. The routing stuff is moronic, like IP's source routing which the Internet decided was a terrible idea, but the IETF kept insisting on for IPv6 anyways. I could go on, but this is direct result of writing SIP software and implementing SIP networks for around a decade.

by hendry 12y ago

It's a real shame that they couldn't make a SIP client and leverage VOIP. VOIP is used by a lot of businesses and I believe it would really improve Web adoption if the Web could support it.

MichaelGG 12y ago

WebRTC is sort of a hack up of SIP-similar technologies, and is definitely VoIP. SIP and SDP are also clusterfucks of protocols with some really, really, terrible design decisions. (Hey, let's specify UDP _AND_ TCP, and require clients to flip between transport on a per-message level! Why not? It's easy to spec idiotic stuff on paper...) Anyways, SIP does not NAT well as it assumes, like it's the 1980s, that you are on a public IP and can directly send to any port on anyone's public IP. Then it goes and embeds your IP all over the place, because they were too cool for simple symmetric pipes. To make it more fun, all sorts of firewall and router vendors try to "fix" SIP and generally just screw things up even more. As I understand, a lot of WebRTC effort went into dealing with NAT and some other niceties. (And apparently, arguing about codecs.) Otherwise, you're right, there's not a whole lot to be done. Despite the terribleness of SIP, it generally works, and VoIP engineers have figured out how to make it work pretty well. However, it's unlikely that re-using parts of SIP/SDP in WebRTC makes _any_ difference in adoption of things. Almost no one runs SIP openly, they lock it down like a traditional telephony system. Best is in fact to firewall it off, because you're rather naive if you trust all this C/C++ code parsing strings like mad. Plus, since SIP systems are often connected to other telephone networks with billing, even protocol-level hackery can lead to a lot of financial loss. So in short, it'd be super duper unlikely you'd ever be able to point your web browser at "sip:someone@somebusiness.com", even if it had SIP built-in.

voltagex_ 12y ago
One day I hope someone can call my email address. That's all I want - Google Talk/Hangouts almost had it, then they closed off the protocol.
- MichaelGG 12y ago
  You can do that with SIP now. But with email, getting a bunch of spam can be handled in bulk, and letting a few slip by isn't disastrous. With phone calls, it could be much worse. As I understand, Google killed xmpp federation for precisely this reason.
  - stephenr 12y ago
    Google killed XMPP federation because supporting open standards that allow people to use non-google services easily are bad for business.
    - MichaelGG 12y ago
      You can say that, but Google has stated it's because federation was not used that much and that the spam aspect of it was the dominating usage. Which makes total sense and XMPP does not solve it, and in fact it's hard to see a solution for this problem that doesn't rely on a centralized solution. Feel free to propose one. Because if you can solve it for XMPP, you can probably solve it for SMTP and become a billionaire for fixing spam.
      - stephenr 12y ago
        Google can say that, but I and many others simply don't believe them. Google is a business, and an advertising business at that. It's literally their job to try and make us believe what they say, regardless of the truth.
vladimirralev 12y ago
SIP and SDP are not clusterfucks. Pretty much everything is done for a reason. Often it has to do with scaling and load balancing. Flipping transports is just a side effect of a useful feature where you send INVITE through a proxy that doesn't record-route so it's bypassed on the next message meaning you will have to use the transport of the next node in the chain. You never change the transport between the original endpoints just randomly for no reason. You are simply connecting to another server which prefers the other transport (or is not under your control). TCP or UDP have significant differences and tradeoffs in load balancing and tunneling traffic, each has a place. If you are building huge telecom systems most of this makes total sense in one situation or another. No signalling protocol can be used "openly", there is simply too much potential for abuse. Integration and especially selective integration on the other hand is quite good with SIP.
- MichaelGG 12y ago
  Well I'm, on my third pass around writing a SIP parser/stack, and I'd have to say, no, things are not done for a reason. The silly date format ("Thu, 25 November, 1921") is a relic from the 70s and only there because that's what someone happened to be doing on some private little mail system. And the IETF just blindly copies nonsense like that, even though there's zero benefit to an English-specific long-date format in a protocol. SIP headers, in the wild, cannot be unambiguously parsed. This is because the whole \r\n thing to end lines combined with the SIP RFC's instructions that implementations should "infer meaning" ends up with some implementations considering \n\n to be start of data, and some not. Good luck. Not to mention idiocy like "comments in headers", "line wrapping". Or my favourite "put headers in the querystring". Because nothing makes ensuring your implementation is correctly following messaging (on which tons of money may ride) than specifying not only two ways to define a common header, but adding two distinct locations to find the same data. Or the awesomeness of deciding "IP fragmentation is broken" (???) and deciding on an arbitrary MTU size at which point you've gotta flip to TCP. Literally, on a message-by-message basis, they see nothing wrong with requiring you to read from both a UDP and TCP socket to get the next message for a transaction. I'd go as far as saying they think they're being clever. The only point of using UDP (complete with their own retransmission system to deal with packetloss) is if you think _maybe_ you're gonna shave off 1xRTT by avoiding a TCP handshake. Except since most calls are going between well defined endpoints, that's not an issue. And secure calling requires TCP (TLS) anyways. The real result is that plenty of implementations end up doing UDP only, or only really supporting UDP. And why MS decided this was idiotic, and went TCP only because "most of our messages will exceed the MTU". Oh, and the kicker? IP fragmentation works fine. I analyzed a VoIP network (several terabytes of SIP signalling) and found about 1-2% of SIP messages were IP frag'd (MTU around 576) and never did IP frag mess anything up. All this crazy complexity because Rosenberg et al thought they were oh-so-clever about a non-existent problem. The routing stuff is moronic, like IP's source routing which the Internet decided was a terrible idea, but the IETF kept insisting on for IPv6 anyways. I could go on, but this is direct result of writing SIP software and implementing SIP networks for around a decade.