Protocols

The protocols provide the registration of IP-device (gateway, terminal or IP-phone) on the server or gatekeeper of ISP, call and/or call forwarding, voice or video call establishment, the transfer of the name and/or telephone number. Currently, widespread following VoIP-protocols:

• SIP - session-protocol of communication, providing voice, video, messages, instant messaging and an arbitrary load, signaling usually uses port 5060 UDP. Supports control of presence.
• H.323 - the protocol is more tied to traditional telephony systems, than the SIP, signaling port 1720 TCP, and TCP 1719 for registration of terminals on the gatekeeper.
• IAX2 - through the 4569 UDP-port signaling and media traffic.
• MGCP (Media Gateway Control Protocol) - control protocol of media gateways.
• Megaco/H.248 - control protocol of media gateways, the development of MGCP.
• SIGTRAN - tunneling protocol PSTN-SS7 signaling over IP to the softswitch (SoftSwitch).
• SCTP (Stream Control Transmission Protocol) - Protocol for the organization of guaranteed delivery of packets in IP-based networks.
• SCCP (Skinny Call Control Protocol) - the private protocol terminal management (IP-phones and media gateways) in the products at Cisco.
• Unistim - private transmission protocol signal traffic in the products, Nortel.

In table 1 summarized comparison of protocols H.323 and SIP

Table 1

	H.323	SIP
Complexity	H.323 is limited to multimedia conferencing, so the complexity of the system is constrained accordingly. No communication system is simple, but H.323 attempts to clearly define the basic set of functionality that all devices must support.	SIP was initially focused on voice communication and then expanded to include video, application sharing, instant messaging, presence, etc. With each capability, complexity increases and, unfortunately, there are no strict guidelines as to what functionality any given device must support. This leads to more complex systems with more interoperability problems.
Reliability	H.323 has defined a number of features to handle failure of intermediate network entities, including "alternate gatekeeper", "alternate endpoints", and a means of recovering from connection failures.	SIP has not defined procedures for handling device failure. If a proxy fails, the user agent detects this through timer expiration. It is the responsibility of the user-agent to send a re-INVITE to another proxy, leading to long delays in call establishment.
Addressing	Flexible addressing mechanisms, including URIs, e-mail addresses, and E.164 numbers. H.323 supports these aliases: E.164 dialed digits generic H.323 ID URL transport address email address party number mobile UIM ISUP number H.323 also supports overlap sending with no additional overhead, except conveyance of the newly received digits in a single message.	SIP only understands URI-style addresses. This works fine for SIP-SIP devices, but causes some confusion when trying to translated various dialed digits. The unofficial convention is that a "+" sign is inserted in the SIP URI (e.g., "sip:+18005551212@example.com") in order to indicate that the number is in E.164 format, versus a user ID that might be numeric. SIP has support for overlapped signaling defined in RFC 3578, though additional digit received requires transmission of three messages on the wire (a new INVITE, a 484 response to indicate that the address is incomplete, and an ACK).
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. Various pieces of billing information may be present in the ARQ and DRQ messages at the start and end of the call.	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. Otherwise, there is no mechanism in SIP to perform any accounting/billing function.
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. There is no standard means of recovering from packet loss in a video stream (to parallel H.323's "video fast update" command).
Codecs	H.323 supports any codec, standardized or proprietary. No registration authority is required to use any codec in H.323.	SIP supports any IANA-registered codec (as a legacy feature) or other codec whose name is mutually agreed upon.
Minimum Ports for VoIP Call	3 (Call signaling, RTP, and RTCP.)	3 (SIP, RTP, and RTCP.)
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.