3 ms·

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

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.
- vladimirralev 12y ago
  These issues seem to be focused on the phone-side of things. Robust and high capacity servers and load balancers have other use-cases. Unless I misunderstand, all of these Date format, the header parsing, the commends in headers, querystring headers come straight from HTTP itself. Can't blame SIP for it. Unless you want to commit fully to TCP, then the fragmentation must be taken care of in the protocol, no way around it. Yes most networks are fine, but the protocol has to deal with the worst-case scenarios. UDP has a lot of advantages - two most used - the retransmissions are faster and it's stateless. It allows to have a fully stateless SIP server devices, reduced chance of DoS attacks or session/fd leaks. UDP allows you to play with the queue design on the server side since you can drop messages and wait for the faster retransmissions. UDP block parsers vs TCP stream parsers have advantages in certain cases to optimize for memory on high traffic devices. UDP allows for multicast and broadcast SIP functions. There are many other little things that make UDP easier and cheaper to deal with on the server side. The routing stuff, some of it comes from HTTP again, and then they added a bunch of extra stuff to accomodate some use-cases in federated environments and chain-systems. The source routing feature is not a problem like in IP because each server is allowed to challenge any request at any time. I've used source routing to establish sticky sessions in a cluster so I don't force replication everywhere for the same user and to create test calls that exercise specific paths in a multinode system.
  - MichaelGG 12y ago
    The scenarios I worked on were for load balancers, proxies, and analyzers. All very high performance (at peak, 5TB/day of SIP on a single quad core processor). SIP parsing is terrible for this and leads to ugly hacky code. Same as HTTP (look at nginx's parsing code - all sorts of crazy compares). This is also why the HTTP replacement protocols ditched this nonsense. Yes, a lot of stuff came from HTTP, which likewise has no excuse other than copying previous mistakes (the date example being a prime example). Except, SIP isn't HTTP compatible, and no implementation is going to be sharing code. It'd beyond bizarre wishful thinking that an implementation is going to share any nontrivial amount of code. One of the folks from the RFC explained they aimed to make it HTTP compatible to use HTTP proxies, than gave up part way through but didn't fix up the rest of it. At any rate, you can blame SIP for it - no need to copy previous mistakes. And HTTP deserves a ton of blame, and I'd be absolutely surprised to find out that most software follows the HTTP spec. Most likely, they follow something sort of looking like HTTP, and test on the Internet to see which subset is actually being followed. Just like no one puts comments into email URIs because it's stupid. Fragmentation does _not_ need to be taken care of in protocol. IP already does fragmentation and it works. As I noted: 1-2% of all our customers had MTUs of ~576 bytes, so their SIP UDP packets were already IP fragemented. No one experienced problems with this, and some broken IP fragmentation issue would also affect TCP. UDP has a limit, but they could specify a switch to TCP at 64K. Could you clarify what you mean? UDP actually makes DoS harder to deal with as there's no handshake for determining the other IP actually exists. Whereas with TCP syn cookies, that particular problem is totally solved. Also, any benefits of UDP in this case are totally negated because implementations "MUST" support both. Any client or server that only uses UDP is broken. So embedded devices and the other scenarios you mention have to handle both protocols, on a message-by-message basis. There's no case where this is beneficial. Oh, also, since most VoIP systems today rely on IP authentication, UDP combined with the SIP routing rules means almost all of them are trivially exploitable. Despite this being a rather obvious attack, I've yet to see any SIP stacks explicitly harden for this. Larger companies hope firewalling is good enough (hint: it's not really). Look up Cloudflare's handling of DNS-based DDoS's for another example of why it's a bad decision. AFAIK HTTP doesn't allow "triangle" paths, like SIP. That is, in SIP, A talks to proxy B, which talks to client C. Then client C sends directly back to A. Of course, in reality, everyone turns on record route to make it act sane, but it's one more thing that's in the protocol and is lying in wait to screw someone over or just make things more complicated than necessary. But in SIP, this is not only possible, it's celebrated and drawn into diagrams, showing off how fantastic an idea they think it is. These kind of things arise when people act clever when writing stuff out on paper. When you're just writing a spec, your imagination is the limit. Actual implementation considerations are a detail that doesn't bother you. Actually, SIP requires an AI to be properly implemented, as the RFCs suggest implementation "infer" the "intent" of messages, which sounds like a job for GAI. Likewise, comments in headers, headers in querystring, multi-protocol flip-flopping, inane rewrite-TCP-inside-UDP, etc. etc. are all just a few keystrokes away when you're making up a spec. After all, SIP even says maybe someone would use it to start a chess game, that's their actual example. Despite having "Call-ID" as a mandatory header, they want to make it clear they're not about just calls! Oh no, they've implemented a general purpose session protocol. Look up the RFC for SIP torture tests. They revel in the fact they've created a terrible grammar with special syntax for various headers (multiple headers are separate, unless they're Accept, in which case combine them into a single value). There's no need for that and it just shows what a terrible idea it is to have text protocols without strict grammars. For a humorous take on this: https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt In which he mocks the SIP design decisions, but in a very accurate way reflecting what real-world networks actually do. My favourite line: "But this is not the real world, this is the IETF".

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.

vladimirralev 12y ago
These issues seem to be focused on the phone-side of things. Robust and high capacity servers and load balancers have other use-cases. Unless I misunderstand, all of these Date format, the header parsing, the commends in headers, querystring headers come straight from HTTP itself. Can't blame SIP for it. Unless you want to commit fully to TCP, then the fragmentation must be taken care of in the protocol, no way around it. Yes most networks are fine, but the protocol has to deal with the worst-case scenarios. UDP has a lot of advantages - two most used - the retransmissions are faster and it's stateless. It allows to have a fully stateless SIP server devices, reduced chance of DoS attacks or session/fd leaks. UDP allows you to play with the queue design on the server side since you can drop messages and wait for the faster retransmissions. UDP block parsers vs TCP stream parsers have advantages in certain cases to optimize for memory on high traffic devices. UDP allows for multicast and broadcast SIP functions. There are many other little things that make UDP easier and cheaper to deal with on the server side. The routing stuff, some of it comes from HTTP again, and then they added a bunch of extra stuff to accomodate some use-cases in federated environments and chain-systems. The source routing feature is not a problem like in IP because each server is allowed to challenge any request at any time. I've used source routing to establish sticky sessions in a cluster so I don't force replication everywhere for the same user and to create test calls that exercise specific paths in a multinode system.
- MichaelGG 12y ago
  The scenarios I worked on were for load balancers, proxies, and analyzers. All very high performance (at peak, 5TB/day of SIP on a single quad core processor). SIP parsing is terrible for this and leads to ugly hacky code. Same as HTTP (look at nginx's parsing code - all sorts of crazy compares). This is also why the HTTP replacement protocols ditched this nonsense. Yes, a lot of stuff came from HTTP, which likewise has no excuse other than copying previous mistakes (the date example being a prime example). Except, SIP isn't HTTP compatible, and no implementation is going to be sharing code. It'd beyond bizarre wishful thinking that an implementation is going to share any nontrivial amount of code. One of the folks from the RFC explained they aimed to make it HTTP compatible to use HTTP proxies, than gave up part way through but didn't fix up the rest of it. At any rate, you can blame SIP for it - no need to copy previous mistakes. And HTTP deserves a ton of blame, and I'd be absolutely surprised to find out that most software follows the HTTP spec. Most likely, they follow something sort of looking like HTTP, and test on the Internet to see which subset is actually being followed. Just like no one puts comments into email URIs because it's stupid. Fragmentation does _not_ need to be taken care of in protocol. IP already does fragmentation and it works. As I noted: 1-2% of all our customers had MTUs of ~576 bytes, so their SIP UDP packets were already IP fragemented. No one experienced problems with this, and some broken IP fragmentation issue would also affect TCP. UDP has a limit, but they could specify a switch to TCP at 64K. Could you clarify what you mean? UDP actually makes DoS harder to deal with as there's no handshake for determining the other IP actually exists. Whereas with TCP syn cookies, that particular problem is totally solved. Also, any benefits of UDP in this case are totally negated because implementations "MUST" support both. Any client or server that only uses UDP is broken. So embedded devices and the other scenarios you mention have to handle both protocols, on a message-by-message basis. There's no case where this is beneficial. Oh, also, since most VoIP systems today rely on IP authentication, UDP combined with the SIP routing rules means almost all of them are trivially exploitable. Despite this being a rather obvious attack, I've yet to see any SIP stacks explicitly harden for this. Larger companies hope firewalling is good enough (hint: it's not really). Look up Cloudflare's handling of DNS-based DDoS's for another example of why it's a bad decision. AFAIK HTTP doesn't allow "triangle" paths, like SIP. That is, in SIP, A talks to proxy B, which talks to client C. Then client C sends directly back to A. Of course, in reality, everyone turns on record route to make it act sane, but it's one more thing that's in the protocol and is lying in wait to screw someone over or just make things more complicated than necessary. But in SIP, this is not only possible, it's celebrated and drawn into diagrams, showing off how fantastic an idea they think it is. These kind of things arise when people act clever when writing stuff out on paper. When you're just writing a spec, your imagination is the limit. Actual implementation considerations are a detail that doesn't bother you. Actually, SIP requires an AI to be properly implemented, as the RFCs suggest implementation "infer" the "intent" of messages, which sounds like a job for GAI. Likewise, comments in headers, headers in querystring, multi-protocol flip-flopping, inane rewrite-TCP-inside-UDP, etc. etc. are all just a few keystrokes away when you're making up a spec. After all, SIP even says maybe someone would use it to start a chess game, that's their actual example. Despite having "Call-ID" as a mandatory header, they want to make it clear they're not about just calls! Oh no, they've implemented a general purpose session protocol. Look up the RFC for SIP torture tests. They revel in the fact they've created a terrible grammar with special syntax for various headers (multiple headers are separate, unless they're Accept, in which case combine them into a single value). There's no need for that and it just shows what a terrible idea it is to have text protocols without strict grammars. For a humorous take on this: https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt In which he mocks the SIP design decisions, but in a very accurate way reflecting what real-world networks actually do. My favourite line: "But this is not the real world, this is the IETF".