SIP is one of a few protocols where two completely standard-compliant implementations are commonly unable to interop.
They are totally detached from actually implementing elegant or high performance software. Actual engineers achieve this despite of SIP's terrible decisions. Granted, many of those are inherited from HTTP. Tell me how many HTTP stacks handle comments and line folding properly...
It opens up security holes, too. One proxy interprets \r\r\n as 1 line break, another as 2 line breaks and start of body. Oops, now you can end up sending fun headers to your target because they try to be flexible in accepting input.
IIRC there is essentially no way to implement SIP standardly because of so many broken implementations. You have to make some decisions on certain parsing that will break one but any other way will break another.
Text-based protocols invite abuse by designers and implementors alike. IETF compounds these by living in a fantasy world.
FWIW, I consider the canonical implementation of SIP at this point to be asterisk.
I work on a SIP derived protocol, P25 CSSI - it has all the issues of SIP, and more!
Actually we've seen people manage to fuck that up royally, too. Examples: Routers confusing MAC addresses starting with "6" with IPv6 packets. Various TLS implementations in proxies falling completely apart when they see an unknown version. Various TLS proxies falling apart when seeing an unknown extension. Far too many instances of "assert version==1" to list.
...