H.323 versus SIP: A Comparison

                                                             Provided with permission from Packetizer.

            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?

 SIP Callflow Examples

	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.

SIP Registration Example

	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.

Usage of HTTP Authentication in SIP

	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.

Response Codes in SIP

The response codes are consistent with, and extend, HTTP/1.1 response
   codes.  Not all HTTP/1.1 response codes are appropriate, and only
   those that are appropriate are given here.  Other HTTP/1.1 response
   codes SHOULD NOT be used.  Also, SIP defines a new class, 6xx.