3 ms·

Wow. I suspected SIP was bad, but I never got around to looking at it in detail. ... Wait, NIST wrote the reference implementation? Also, your description sou

by pdkl95 12y ago

Wow. I suspected SIP was bad, but I never got around to looking at it in detail. ... Wait, NIST wrote the reference implementation? Also, your description sounds suspiciously like someone was going for maximum confusion and a "design" that practically guarantees bugs in every implementation. This stinks of BULLRUN-style sabotage.

viraptor 12y ago
Real life sip is the worst protocol I've seen. There are loads of additions to it that try to fix previous issues. Phone status publishing, nat detection/workarounds, companies coming up with their own extension, etc. etc. Basically forget about things interoperating without proxies that capture and contain/fix all the weirdness. Snom, grandstream and Linksys will not agree on all features natively no matter how you try. The process for re-invites with proxies in the middle, loose routing, nats, and codec renegotiation is a VoIP engineer's hell. But all those extensions/rules were created with good intentions.
- MichaelGG 12y ago
  And they have the nerve to call their IM extension "SIMPLE". It also shocks me how prevalent SIP is for arbitrary lookups in telcoland. More than one switch uses a SIP call to find number portability info. So they involve at least 3 SIP messages, each hundreds of bytes long, complete with a full SIP transaction state, burning up call resources on their switch, to essentially send and receive 10 bytes. The amount of stupidity in telecom is mind-boggling. I take solace in hearing that other industries are just as bad, but I don't see them so they just appear to be OK.
MichaelGG 12y ago
Eh, I'm not so sure. TLS is rarely supported, and not really ever used, so it's not like sabotage is needed to make it viewable. And a lot of this stuff is the result of carrying over design decisions, literally, from the 60s. Someone wrote an RFC codifying what they were doing by hand. And that nonsense gets passed forward for zero reason. Ever wonder why HTTP uses the idiotic "Thu, 28 Jan, 1998, GMT" format for datetime? Because that format makes sense if you're hand-reading email message headers. And HTTP just copied it forward, zero thinking involved. Probably the same reason you can have comments in headers. SIP gives an example: Retry-After: 300 (I'm in a meeting) To real-world engineers, we say, wow, that's idiotic. Comments will never be used, so they'll never be properly implemented and only serve to make things problematic. To an IETF RFC author, that kind of behaviour is "well RFC xxx does it that way", and ultimately comes to "well, like, if you were sending HTTP messages by fax, extra comments might help". If you stack up enough hacks like that, then it starts to become the clusterfuck it is. I don't think there's any maliciousness involved. Just lack of critical thinking, or lack of experience actually implementing software. Plus the fact that when writing a spec, you've got a blank paper and can just go all-out with crazy ideas you won't have to support.
- pas 12y ago
  Interestingly, I think any magic number that can somehow end up in the hand of developers (or maybe users whom developers then need to support) should always come with a human-readable explanation, or if it's impossible, then that means that should have been a stacktrace somewhere much deeper in the stack. (Because at first it's easy to just look up what those numbers mean, but when 5+ years down the timeline someone has to support something that only barfs up those numbers ... well, I'm sure a lot of sons and moms would be spared.)

by pdkl95 12y ago

viraptor 12y ago

Real life sip is the worst protocol I've seen. There are loads of additions to it that try to fix previous issues. Phone status publishing, nat detection/workarounds, companies coming up with their own extension, etc. etc. Basically forget about things interoperating without proxies that capture and contain/fix all the weirdness. Snom, grandstream and Linksys will not agree on all features natively no matter how you try. The process for re-invites with proxies in the middle, loose routing, nats, and codec renegotiation is a VoIP engineer's hell. But all those extensions/rules were created with good intentions.

MichaelGG 12y ago
And they have the nerve to call their IM extension "SIMPLE". It also shocks me how prevalent SIP is for arbitrary lookups in telcoland. More than one switch uses a SIP call to find number portability info. So they involve at least 3 SIP messages, each hundreds of bytes long, complete with a full SIP transaction state, burning up call resources on their switch, to essentially send and receive 10 bytes. The amount of stupidity in telecom is mind-boggling. I take solace in hearing that other industries are just as bad, but I don't see them so they just appear to be OK.

MichaelGG 12y ago

Eh, I'm not so sure. TLS is rarely supported, and not really ever used, so it's not like sabotage is needed to make it viewable. And a lot of this stuff is the result of carrying over design decisions, literally, from the 60s. Someone wrote an RFC codifying what they were doing by hand. And that nonsense gets passed forward for zero reason. Ever wonder why HTTP uses the idiotic "Thu, 28 Jan, 1998, GMT" format for datetime? Because that format makes sense if you're hand-reading email message headers. And HTTP just copied it forward, zero thinking involved. Probably the same reason you can have comments in headers. SIP gives an example: Retry-After: 300 (I'm in a meeting) To real-world engineers, we say, wow, that's idiotic. Comments will never be used, so they'll never be properly implemented and only serve to make things problematic. To an IETF RFC author, that kind of behaviour is "well RFC xxx does it that way", and ultimately comes to "well, like, if you were sending HTTP messages by fax, extra comments might help". If you stack up enough hacks like that, then it starts to become the clusterfuck it is. I don't think there's any maliciousness involved. Just lack of critical thinking, or lack of experience actually implementing software. Plus the fact that when writing a spec, you've got a blank paper and can just go all-out with crazy ideas you won't have to support.

pas 12y ago
Interestingly, I think any magic number that can somehow end up in the hand of developers (or maybe users whom developers then need to support) should always come with a human-readable explanation, or if it's impossible, then that means that should have been a stacktrace somewhere much deeper in the stack. (Because at first it's easy to just look up what those numbers mean, but when 5+ years down the timeline someone has to support something that only barfs up those numbers ... well, I'm sure a lot of sons and moms would be spared.)