SIP vs H323
From TD-er's Wiki
Jump to navigationJump to search(Source)
H.323 is the more mature of the two, but problems may arise due to lack of flexibility. SIP is currently less defined, but has greater scalability which could ease internet application integration. Which protocol will win out in the end? It is still too early to tell, but our unbiassed analysis will help you decide which protocol best suites your application.
| 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 | SI |
| 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 Yesgnaling | Yes, location requests (LRQ) and auto gatekeeper discovery (GRQ). | Yes, e.g., through group INVITEs. |
| Third-party Call Contro | 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. |
Links
- Comparison of H323 and SIP
- Overview SIP vs H323
- Discussion about Sip and H323 - Note: not entirely objective, because this vendor also sells H323 devices.
