|
H.323 versus SIP: A Comparison |
|
|
|
|
Written by Packetizer
|
|
Friday, 28 December 2007 |
|
Page 4 of 4 | SIP supports any IANA-registered codec (as a legacy feature) or other codec whose name is mutually agreed upon. |
| Firewall/NAT support | Provided by H.323 "proxy" or by the endpoint, both in conjunction with a gatekeeper residing in the public network. Refer to H.460.17, H.460.18, and H.460.19. | SIP does not defined a NAT/FW traversal mechanism, as this is left to other standard. Some standards that have been defined or are being defined are STUN, TURN, ANAT, and ICE. (All of this has been work in progress for years, with most workable solutions done by agreed convention.) |
| Transport protocol | Reliable or unreliable, e.g., TCP or UDP. Most H.323 entities use a reliable transport for signaling. | Reliable or unreliable, e.g., TCP or UDP. Most SIP entities use an unreliable transport for signaling. |
| Loop Detection | Routing gatekeepers can detect loops by looking at the CallIdentifier and destinationAddress fields in call-processing messages. If the combination of these matches an existing call, it is a loop. Infinite loops may be prevented by utilizing the hopCount field in the SETUP message. | The Via header facilitates this. However, there has been talk about deprecating Via as a means of loop detection due to its complexity. Instead, the Max-Forwards header seems to be the preferred method of limiting hops and therefore loops. In November 2005, a presentation was given on issues with max-forwards. So, what is the right solution? |
| Multicast Signaling | Yes, location requests (LRQ) and auto gatekeeper discovery (GRQ). | Yes, e.g., through group INVITEs. |
| Third-party Call Control | Yes, through third-party pause and re-routing which is defined within H.323. More sophisticated control is defined by the related H.450.x series of standards. | Yes, through SIP as described in RFC 3725. |
| Minimum Ports for VoIP Call | 3 (Call signaling, RTP, and RTCP.) | 3 (SIP, RTP, and RTCP.) |
| Conferencing Entity | Yes, an MC is required for this, but it could be co-located in a participating endpoint, or all endpoints could contain an MC. A stand-alone conference bride may provide this functionality and H.323 has well-defined procedures for such entities. What distinguishes H.323 is not that it requires yet another onerous physical entity for conferencing (it does not) but that it just has a name for this functionality, an "MC," and that it provides a flexible means of implementing that functionality. | No; however, SIP user agents may perform conferencing themselves. A stand-alone conference bridge may also provide this functionality. |
| Original Title | "VISUAL TELEPHONE SYSTEMS AND EQUIPMENT FOR LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE" It is now, "Packet-based multimedia communications systems." Despite the word, "VISUAL," in the original title, H.323 has never described just a videoconferencing solution--support for video and data has always been optional. And the reference to LANs may be misleading because H.323 was intended from the start to support simple and "complex topologies" and not just single-segment networks, which "LOCAL AREA NETWORKS" may imply. | "Application-level protocol for inviting users to multimedia conferences [emphasis ours]" It is now, "SIP: Session Initiation Protocol." Note that the "multimedia conferences" referred to in the original title are loosely coupled multicast conferences, à la MBone. This is because SIP was intended to be just a point-to-point version of SAP and not the "carrier-class solution addressing a wide area" that many would have you believe. |
| Lineage | H.323 is based on H.324, not H.320. However, H.324 was designed to be a better H.320. - 1990 - H.320 approved.
- 1995 - H.324 approved.
- 1995 - H.323 working draft circulated.
- 1996 - H.323 approved.
- 2000 - H.323v4 approved.
- 2003 - H.323v5 approved.
- 2006 - H.323v6 approved.
As you can see, H.323 is no more a "legacy" protocol than SIP. Both are very modern protocols. | SIP is frequently allied with the Internet and the World Wide Web by way of HTTP. - 1990 - WWW and HTTP described and implemented.
- 1996 - SIP Internet Draft circulated.
- 1999 - SIP (RFC 2543) approved.
- 2002 - SIP (RFC 3261) approved.
While backward compatibility was not maintained between the 1999 and 2002 documents, the version number remained the same "version 2.0". |
| Open-source projects | Yes, e.g., H.323 Plus. | Yes, e.g., reSIProcate. |
| Media Topology | Unicast, multicast, star, and centralized. | Unicast, multicast, star, and centralized. |
| Authentication | Yes, via H.235. | Yes, via HTTP (Digest and Basic), SSL, PGP, S/MIME, or various other means. |
| Encryption | Yes, via H.235 (including use of SRTP, TLS, IPSec, etc.). | Yes, via SSL, PGP, S/MIME, or various other means. |
| DTMF Carriage | Three ways, with the alphanumeric choice of the H.245 UserInputIndication message being the baseline carriage common to all H.323 endpoints. | Three ways. There is no baseline carriage, which presents issues of interoperability. However, transport of DTMF via the INFO method and RFC 2833 are most common. |
| | | |
