Comparison of H.323 and SIP

A set of papers and personal notes goes into more detail; a different perspective is provided by packetizer.com. Unfortunately, almost all of the information about SIP is either wrong, FUD, misleading or spun in a particular way, so the comparison should be treated as H.323 advertising, not fact.

Taegon Park and Chu Hee Lee offer another comparison, which is less blatantly biased, but still has a number of factual errors, e.g., in terms of call setup and redundancy.

Some of the errors include:

• Summary: SIP does provide message waiting, through draft-mahy-sip-message-waiting
• Summary: SIP does provide name identification, in the display name of the To and From headers
• Summary: since SIP allows multiple calls per end system, call intrusion in the classical sense is not typically needed or relevant. Also, SIP allows adding call legs to an existing call, which approximates call intrusion in the VoIP context.
• Summary: Call offer (H.450.10): "Call Offer (SS-CO) is a supplementary service which, on request from the calling user (or on that user's behalf), enables a call to be offered to a busy called user and to wait for that called user to accept this call." This is an end system implementation issue and requires no protocol support in SIP.
• Summary: Admission and policy control: The SIP architecture assumes that packet-level admission control should be handled by a resource reservation protocol. Unlike a gatekeeper, it has knowledge across traffic types, not just H.323 or SIP calls. Obviously, any outbound proxy, for example, can reject or admit calls based on whatever criteria it likes, including some notion of maximum bandwidth usage.
• Summary: Implementation interoperability: This is not "unknown", as dozens of SIP implementations test interoperability at the SIPit events taking place every four months, in addition to other venues.
• Summary: Security: SIP does not use SSH or S-HTTP, although it could potentially use these protocols.

H.323 encompasses a range of protocols, including RTP for data transport, H.225.0 (with RAS and Q.931 signaling) for setup, H.245 for format negotiation, H.450 for supplementary services and H.332 for panel-style conferences.

SIP offers functionality similar to H.225.0/Q.931/RAS, H.245 and H.450. H.323 comes in several versions, so any comparison needs to be careful to identify the precise version of the protocol.

SIP Design Choices

SIP made a number of design choices that we enumerate below.

Transport-protocol neutrality

SIP can use TCP, SCTP or UDP. If desired, SIP can run directly on top of any protocol offering reliable or unreliable byte stream or datagram services, including ATM AAL5, IPX, X.25, without changes to the protocol. H.323 requires the use of a reliable transport protocol.

Fast call setup

Setting up a SIP call via UDP takes 1.5 round trip times and four packets, namely an INVITE from caller to callee, followed by a 200 OK in the opposite direction and a final ACK from the caller.

H.323 call setup delay varies greatly depending on the version and details.

Address-format neutrality

SIP destination and forwarding addresses can be any URL, including mailto, phone, H.323 and http URL, affording flexibility in combining SIP with other signaling protocols. Email-like names can be mapped by any device on the Internet.

H.323v1 allows to address either hosts directly (but without user name), or go through an alias. All aliases have to be resolved through a gatekeeper. An H.323 URL is under development.

Multicast-capable

Since it uses UDP rather than TCP, SIP requests can be sent via multicast. This simplifies user location, call-center application ("response by first available reservation agent"), and group invitations.

Multicast-friendly

A caller can invite a callee to a point-to-point call as well as a multicast conference, even one the caller does not belong to.

H.323 has a separate spec, H.332, for including multicast listeners. Roughly, endpoints declare that they are multicast capable to the MC. The MC then decides whether to use multicast, and informs the endpoints of the addresses to use. As to invitation, normally a member of the conference asks the MC to invite somebody else. However, the FACILITY message would allow an endpoint to transfer a call into a conference (perhaps from a side conversation).

Topological flexibility

SIP supports multicast, full-mesh and MCU-based conferences, without requiring a full control mesh. The Via header allows arbitrary routing of requests with loop detection.

H.323 does not have loop detection for gatekeeper-routed calls.

Call control functionality

SIP currently supports terminal mobility, call redirection, call transfer and similar telephony-services. Forwarding and lookups can be based on the media types for the call.

H.225.0 defines the FACILITY message for this functionality, providing an address to connect to. This allows forwarding and blind transfer. The H.450.x specification allows for consultation transfer, and basically seals up the holes where after consultation another endpoint could gain access to the transferred to party rather than the transferee. H.450 is also intended to be modeled on the QSIG PBX supplementary services to gain better integration in that area.

SIP has a single protocol for these services, while H.323 splits them across H.450, RAS, H.245 and Q.931.

Caller and callee preferences

SIP can encode caller and callee preferences, allowing the caller or callee to indicate, for example, that it may prefer to communicate via SIP as first choice, with second preference via H.323 and, if that should fail, via plain old telephone. The callee can indicate a preferred time to be called back.

Security

SIP supports caller and callee authentication via HTTP mechanisms (Digest authentication). Cryptographically secure authentication and encryption is supported hop-by-hop via TLS or IPsec. Keys for media encryption are conveyed using SDP. TLS supports symmetric and asymmetric authentication, i.e., either only the server authenticates itself or both client and server mutually authenticate themselves. SIP also defines end-to-end authentication and encryption using S/MIME. H.323v2 defines security mechanisms and negotation facilities via H.235.

Protocol encoding

SIP is a text-based protocol similar to HTTP and RTSP. In the opinion of the author, textual formats tend to be easier to debug and generate with high-level programming languages such as Tcl, Perl, Java, and Visual Basic. SIP is fully internationalized (see next item). SIP also allows to return far more extensive error and status reports, including web pages.

H.323 uses Q.931 and the ASN.1 PER encoding.

Extensibility

SIP has a formal mechanism for negotiating about the support of features, so that methods and parameters can be added that are either optional or must be supported by the other side. Currently, there is one extension defined for call control services, such as supervise call transfer.

Internationalization

SIP uses Unicode (ISO 10646-1), encoded as UTF-8, for all text strings, affording full character set neutrality for names, messages and parameters. SIP provides for the indication of languages and language preferences. This allows, for example, to connect automatically to an operator that speaks the callers language, or allows to tailor error responses to the requestor's language preferences.

H.323 uses Unicode (BMPString within ASN.1) for some textual information (h323-id), but generally has few textual parameters.

Connection state

A SIP call is independent of the existence of a transport-layer connection, but instead signals call termination explicitly.

H.323 calls are terminated either explicitly or when the H.245 connection is torn down. Thus, all intervening gatekeepers have to maintain state during a phone call.

Content description

H.323 always uses H.245 to negotiate media within a conference; SIP can use any session description format, including but not limited to SDP.

SIP can use any IANA-registered or privately-named codec by mutual agreement.

SIP currently does not have the full negotiation flexibility of H.245, due to the limitations of the expressiveness of SDP. However, H.245 is currently restricted to ITU-T codecs only. The IETF MMUSIC group is discussing a follow-on protocol for session descriptions, currently titled SDPng.

Only ITU codecs are supported within H.245.

Last updated by Henning Schulzrinne