SIP stands for Session Initiation Protocol. It is an application-layer control protocol which has been developed and designed within the IETF. The protocol has been designed with easy implementation, good scalability, and flexibility in mind.
The specification is available in form of several RFCs, the most important one is RFC3261 which contains the core protocol specification. The protocol is used for creating, modifying, and terminating sessions with one or more participants. By sessions we understand a set of senders and receivers that communicate and the state kept in those senders and receivers during the communication. Examples of a session can include Internet telephone calls, distribution of multimedia, multimedia conferences, distributed computer games, etc.
SIP is not the only protocol that the communicating devices will need. It is not meant to be a general purpose protocol. Purpose of SIP is just to make the communication possible, the communication itself must be achieved by another means (and possibly another protocol). Two protocols that are most often used along with SIP are RTP and SDP. RTP protocol is used to carry the real-time multimedia data (including audio, video, and text), the protocol makes it possible to encode and split the data into packets and transport such packets over the Internet. Another important protocol is SDP, which is used to describe and encode capabilities of session participants. Such a description is then used to negotiate the characteristics of the session so that all the devices can participate (that includes, for example, negotiation of codecs used to encode media so all the participants will be able to decode it, negotiation of transport protocol used and so on).
This is, frankly, the best comparison of H.323 and SIP available anywhere. Virtually all of the others are misleading, out-of-date, and just plain wrong. To compound the problem--to further propagate the error, as it were--we have also seen several papers written by naive students and rank-and-file engineers that blindly parrot what they have read in these comparisons. Furthermore, many, many people have formed their opinions of H.323 and SIP based not on each protocol's merits but solely on the misinformation provided by these comparisons and through other information provided by largely the same sources.
To counter this misinformation, we decided to put together this thorough, up-to-date comparison. As with ours, please consider the financial interests of the source of any information on this subject, be it an author, speaker, institution, forum, company, web site, or conference. Are the people providing information on this issue involved in both of these--and other--protocols and have nothing besides perhaps an honest academic interest in one or the other protocol, or have they otherwise "hitched their wagon" to one?
The call flows shown in this document were developed in the design of a SIP IP communications network. They represent an example minimum set of functionality.
It is the hope of the authors that this document will be useful for SIP implementers, designers, and protocol researchers alike and will help further the goal of a standard implementation of RFC 3261 [1]. These flows represent carefully checked and working group reviewed scenarios of the most basic examples as a companion to the specifications.
Bob registers on start-up. The message flow is shown in Figure 9. Note that the authentication usually required for registration is not shown for simplicity.
SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document.
