SIP a single RFC? Can you imagine the number of SIP related RFCs and associated drafts? SIP WAS simple, it is now a mess. Even if we restrict to RFC 3261, if you can asnwer the following questions you are already a MASTER in SIP:
- what is the difference between request URI and the "To" header? Are they redundant?
- what is the difference between the "Contact" header, the "P-Asserted-Identity" header and the "From" header?
- what is the loose routign mechanism and what is the relationship with the "Via" headers?
- what is the need for "from tags" and 'to tags".
If we go a bit further:
- Why is SIP/SIMPLE do we need to introduce an "etag" and why not resuing the callid ?
We are a company that is based on SIP and very in favor of this protocol mostly form market reasons but one should not be blind: this protocol has its problems like any other. At the beginning, it was sooo "simple" that it could not even support "announced transfer" or line supervision which is a must for corporate telephony then the real people jumped in and added what it takes to make it usable and added complexity.
Even the big telco that are hated so much in this forum jumped in and created the IMS standards based on SIP (under the ETSI Umbrella = European
If you imagine one second that you can only read ONE RFC to start working on the real SIP world, you are VERY WRONG (see RFC 3581, RFC2327, RFC 3264, RFC 3550 + all the RFC dedicated to packetization, SIP/SIMPLE, MESSAGING,
Now if you compare SIP with H.323, I agree that initially, one can see a lot of advantages.
- H323 has a stupid protocol layering
- slow dialog establishment, etc?
and although they have improved this, this is still not perfect but they have advandages as well:
- camera control and double video streams are a reality in H.323 world wher in SIP it is still on paper only and badly documented.
- screen and application sharing are a reality on H.323 world. They are non existant in SIP
- H.323 has defined a clean standard for NAT traversal where SIP has a set of "best practices" spread in various RFC (keepalive, rport, symetric RTP, etc.).
if you cannot read the ITU standards that is basically because:
- most of them need to be bought
- they have a strong culture of separating the function and the encoding, which renders them difficult to grasp for field hackers
- ITU protocols are often based on ASN.1 BER encoding and therefore are compact an binaries and cannot be test with a simple TELNET connection, which seems to trouble a lot of Internet gurus.