| |
H.323
|
SIP
|
Architecture
|
H.323
covers almost every service, such as capability exchange, conference
control, basic signaling, QoS, registration, service discovery,
and so on. |
SIP is modular because it covers basic call signaling, user location,
and registration. Other features are in other separate orthogonal
protocols. |
|
Components
|
Terminal/Gateway
|
UA
|
|
Gatekeeper
|
Servers
|
|
Protocols
|
RAS/Q.931
|
SIP
|
|
H.245
|
SDP
|
|
Call control Functionality
|
| Call
Transfer |
Yes |
Yes |
| Call
Forwarding |
Yes |
Yes |
| Call
Holding |
Yes |
Yes |
| Call
Parking/Pickup |
Yes |
Yes |
| Call
Waiting |
Yes |
Yes |
| Message
Waiting Indication |
Yes |
No |
| Name
Identification |
Yes |
No |
| Call
Completion on Busy Subscriber |
Yes |
Yes |
| Call
Offer |
Yes |
No |
| Call
Intrusion |
Yes |
No |
| |
H.323 splits them across H.450, RAS, H.245 and Q.931 |
|
|
Advanced
Features
|
| 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 separate Internet Drafts. |
| Conference |
Yes |
Yes |
| Click
for Dial |
Yes |
Yes |
|
Scalability
|
| Large
Number of Domains |
The
initial intent of H.323 was for the support of LANs, so it was not
inherently designed for wide area addressing. The concept of a zone
was added to accommodate wide area addressing. Procedures
are defined for “user location” across zones for email names. Annex
G defines communication between administrative domains, describing
methods to allow for address resolution, access authorization and
usage reporting between administrative domains. In multi-domain
searches, there is no easy way to perform loop detection. Performing
the loop detection can be done (using the PathValue field), but
introduces other issues related to scalability. |
SIP
inherently supports wide area addressing. When multiple servers
are involved in setting up a call, SIP uses a loop detection algorithm
similar to the one used in BGP, which can be done in a stateless
manner, thus avoiding scalability issues. The SIP Registrar and
redirect servers were designed to support user location. |
| Large
Number of Calls |
H.323 call control can be implemented in a stateless manner.
A gateway can use messages defined in H.225 to assist the gatekeeper
in performing load balancing across gateways. |
Call
control can be implemented in a call stateless manner. SIP supports
n to n scaling between UAs and servers. SIP takes less CPU cycles
to generate signaling messages; therefore a server could theoretically
handle more transactions. SIP has specified a method of load balancing
based upon the DNS SRV record translation mechanisms. |
| Connection
State |
Stateful or Stateless.
|
Stateful or Stateless.
A SIP call is independent of the existence of a transport-layer
connection, but instead signals call termination explicitly.
|
| Internationalization |
Yes, H.323 uses Unicode
(BMPString within ASN.1) for some textual information (h323-id),
but generally has few textual parameters.
|
Yes, 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.
|
|
Security
|
Defines
security mechanisms and negotiation facilities via H.235,
can also use SSL for transport-layer security. |
SIP
supports caller and callee authentication via HTTP mechanisms. Cryptographically
secure authentication and encryption is supported hop-by-hop via
SSL/TSL, but SIP could use any transport-layer or HTTP-like security
mechanism, such as SSH or S-HTTP. Keys for media encryption are
conveyed using SDP. SSL supports symmetric and asymmetric authentication.
SIP also defines end-to-end authentication and encryption using
either PGP or S/MIME. |
| Interoperability
among Versions |
The
fully backward compatibility in H.323 enables all implementations
based on different H.323 versions to be seamlessly integrated. |
In
SIP, a newer version may discard some old features that are not
expected to be implemented any more. This approach saves code size
and reduces protocol complexity, but loses some compatibility between
different versions. |
|
Implementation Interoperability
|
H.323 provides an implementers’ guide,
which clarifies the standard and helps towards interoperability
among different implementations.
|
SIP
thus far has not provided an implementation agreement. |
| Billing
|
Even
with H.323's direct call model, the ability to successfully bill
for the call is not lost because the endpoint reports to the gatekeeper
the beginning and end time of the call via the RAS protocol. |
If
the SIP proxy wants to collect billing information, it has no choice
but to stay in the call signaling path for the entire duration of
the call so that it can detect when the call completes. Even then,
the statistics are skewed because the call signaling may have been
delayed. |
|
Codecs
|
H.323
supports any codec, standardized or proprietary, not just ITU-T
codecs. There have been codepoints for MPEG and GSM, which are not
ITU-T codecs, in H.323 for a long time; many vendors support proprietary
codecs through ASN.1 NonStandardParameters, which is equivalent
to SIP's "privately-named codec by mutual agreement";
and any codec can be signaled via the GenericCapability feature
that was added in H.323v3. Payload types can be specified statically
or dynamically. |
SIP
supports any IANA-registered codec (as a legacy feature) or other
codec whose name is mutually agreed upon. Payload types can be specified
statically or dynamically. |
| Call
Forking |
H.323
gatekeeper can control the call signaling and may fork the call
to any number of devices simultaneously. |
SIP
proxies can control the call signaling and may fork the call to
any number of devices simultaneously. |
|
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. |
| Message
Encoding |
H.323
encodes messages in a compact binary format that is suitable for
narrowband and broadband connections.
| SIP
messages are encoded in ASCII text format, suitable for humans to
read. |
|
Addressing
|
Flexible
addressing mechanisms, including URLs and E.164 numbers.
| SIP
only understands URL-style addresses. |
| PSTN
Interworking |
H.323
borrows from traditional PSTN protocols, e.g., Q.931, and is therefore
well suited for PSTN integration. However, H.323 does not employ
the PSTN's circuit-switched technology--like SIP, H.323 is completely
packet-switched. How Media Gateway Controllers fit into the overall
H.323 architecture is well-defined within the standard. |
SIP
has no commonality with the PSTN and such signaling must be "shoe-horned"
into SIP. SIP has no architecture that describes the decomposition
of the gateway into the Media Gateway Controller and the Media Gateways. |
|
Loop Detection
|
Yes,
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. |
Yes,
the SIP message 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 prefered method of limiting hops and therefore loops. |
Minimum
Ports for VoIP Call
|
5
(Call signaling, 2 RTP, and 2 RTCP.) |
5
(Call signaling, 2 RTP, and 2 RTCP.) |
Video
and Data Conferencing
|
H.323
fully supports video and data conferencing. Procedures are in place
to provide control for the conference as well as lip synchronization
of audio and video streams. |
SIP
has limited support for video and no support for data conferencing
protocols like T.120. SIP has no protocol to control the conference
and there is no mechanism within SIP for lip synchronization. |
