Basic VoIP Protocols
Signaling Protocols
SIP (Session Initiation Protocol)
This is the industry standard, for more information check:
Sip Session Initiation Protocol
MGCP (Media Gateway Control Protocol)
MGCP (Media Gateway Control Protocol) is a signaling and call-control protocol described in RFC 3435. It uses a centralized architecture with the following components:[1]
- Call Agent or Media Gateway Controller (MGC): The master gateway in the MGCP architecture is responsible for managing and controlling the media gateways. It handles call setup, modification, and termination processes. The MGC communicates with the media gateways using the MGCP protocol.
- Media Gateways (MGs) or Slave Gateways: These devices convert digital media streams between different networks, such as traditional circuit-switched telephony and packet-switched IP networks. They are managed by the MGC and execute commands received from it. Media gateways may include functions like transcoding, packetization, and echo cancellation.
- Signaling Gateways (SGs): These gateways are responsible for converting signaling messages between different networks, enabling seamless communication between traditional telephony systems (e.g., SS7) and IP-based networks (e.g., SIP or H.323). Signaling gateways are crucial for interoperability and ensuring that call control information is properly communicated between the different networks.
In summary, MGCP centralizes the call control logic in the call agent, which simplifies the management of media and signaling gateways, providing better scalability, reliability, and efficiency in telecommunication networks.
SCCP (Skinny Client Control Protocol)
Skinny Client Control Protocol (SCCP) is a proprietary signaling and call-control protocol used primarily between Cisco Unified Communications Manager (formerly Cisco CallManager) and Cisco voice/video endpoints.[2]
SCCP is a lightweight protocol that simplifies the communication between the call control server and the endpoint devices. It is referred to as “Skinny” because of its minimalistic design and reduced bandwidth requirements compared to other VoIP protocols like H.323 or SIP.
The main components of an SCCP-based system are:
- Call Control Server: This server, typically a Cisco Unified Communications Manager, manages the call setup, modification, and termination processes, as well as other telephony features such as call forwarding, call transfer, and call hold.
- SCCP Endpoints: These are devices such as IP phones, video conferencing units, or other Cisco voice and video endpoints that use SCCP to communicate with the call control server. They register with the server, send and receive signaling messages, and follow the instructions provided by the call control server for call handling.
- Gateways: These devices, such as voice gateways or media gateways, are responsible for converting media streams between different networks, like traditional circuit-switched telephony and packet-switched IP networks. They may also include additional functionality, such as transcoding or echo cancellation.
SCCP offers a simple and efficient communication method between Cisco call control servers and endpoint devices. However, it is worth noting that SCCP is a proprietary protocol, which can limit interoperability with non-Cisco systems. In such cases, other standard VoIP protocols like SIP may be more suitable.
H.323
H.323 is an ITU-T umbrella recommendation for packet-based multimedia communications, including voice, video, and data conferencing.[3]
Some key components of the H.323 suite include:
- Terminals: These are endpoint devices, such as IP phones, video conferencing systems, or software applications, that support H.323 and can participate in multimedia communication sessions.
- Gateways: These devices convert media streams between different networks, like traditional circuit-switched telephony and packet-switched IP networks, enabling interoperability between H.323 and other communication systems. They may also include additional functionality, such as transcoding or echo cancellation.
- Gatekeepers: These are optional components that provide call control and management services in an H.323 network. They perform functions such as address translation, bandwidth management, and admission control, helping to manage and optimize network resources.
- Multipoint Control Units (MCUs): These devices facilitate multipoint conferences by managing and mixing media streams from multiple endpoints. MCUs enable features such as video layout control, voice-activated switching, and continuous presence, making it possible to host large-scale conferences with multiple participants.
H.323 supports a range of audio and video codecs, as well as other supplementary services like call forwarding, call transfer, call hold, and call waiting. Despite its widespread adoption in the early days of VoIP, H.323 has been gradually replaced by more modern and flexible protocols like the Session Initiation Protocol (SIP), which offers better interoperability and easier implementation. However, H.323 remains in use in many legacy systems and continues to be supported by various equipment vendors.
IAX (Inter Asterisk eXchange)
IAX (Inter-Asterisk eXchange) is a signaling and media protocol primarily used between Asterisk PBX servers and VoIP endpoints. It was created through an open-source methodology for Asterisk as an “all-in-one” protocol that combines control and media rather than pairing separate signaling and media protocols. IAX version 2 is documented in RFC 5456.[4]
IAX is known for its simplicity, efficiency, and ease of implementation. Some key features of IAX include:
- Single UDP Port: IAX uses a single UDP port (4569) for both signaling and media traffic, which simplifies firewall and NAT traversal, making it easier to deploy in various network environments.
- Binary Protocol: Unlike text-based protocols like SIP, IAX is a binary protocol, which reduces its bandwidth consumption and makes it more efficient for transmitting signaling and media data.
- Trunking: IAX supports trunking, which allows multiple calls to be combined into a single network connection, reducing overhead and improving bandwidth utilization.
- Native Encryption: IAX has built-in support for encryption, using methods like RSA for key exchange and AES for media encryption, providing secure communication between endpoints.
- Peer-to-Peer Communication: IAX can be used for direct communication between endpoints without the need for a central server, enabling simpler and more efficient call routing.
Despite its benefits, IAX has some limitations, such as its primary focus on the Asterisk ecosystem and less widespread adoption compared to more established protocols like SIP. As a result, IAX might not be the best choice for interoperability with non-Asterisk systems or devices. However, for those working within the Asterisk environment, IAX offers a robust and efficient solution for VoIP communication.
Transmission & Transport Protocols
SDP (Session Description Protocol)
SDP (Session Description Protocol) is a text-based format used to describe multimedia sessions. It does not transport media or establish sessions by itself; signaling protocols such as SIP carry SDP descriptions to negotiate media streams and their attributes. RFC 8866 obsoletes the earlier RFC 4566 definition.[5]
Some key elements of SDP include:
- Session Information: SDP describes the details of a multimedia session, including session name, session description, start time, and end time.
- Media Streams: SDP defines the characteristics of media streams, such as the media type (audio, video, or text), transport protocol (e.g., RTP or SRTP), and the media format (e.g., codec information).
- Connection Information: SDP provides information about the network address (IP address) and port number where the media should be sent or received.
- Attributes: SDP supports the use of attributes to provide additional, optional information about a session or media stream. Attributes can be used for specifying various features like encryption keys, bandwidth requirements, or media control mechanisms.
SDP is typically used in the following process:
- An initiating party creates an SDP description of the proposed multimedia session, including the details of the media streams and their attributes.
- The SDP description is sent to the receiving party, usually embedded within a signaling protocol message like SIP or RTSP.
- The receiving party processes the SDP description, and based on its capabilities, it may accept, reject, or modify the proposed session.
- The final SDP description is sent back to the initiating party as part of the signaling protocol message, completing the negotiation process.
SDP’s simplicity and flexibility make it a widely adopted standard for describing multimedia sessions in various communication systems, playing a crucial role in establishing and managing real-time multimedia sessions over IP networks.
RTP / RTCP / SRTP / ZRTP
- RTP (Real-time Transport Protocol): RTP carries audio, video, and other real-time media over IP networks. RFC 3550 defines RTP sequence numbers, timestamps, payload identification, and synchronization mechanisms.[6]
- RTCP (Real-time Transport Control Protocol): RTCP is RTP’s companion control protocol. Participants periodically exchange reports containing information such as packet loss, jitter, timing, and source identity.[6]
- SRTP (Secure Real-time Transport Protocol): SRTP adds confidentiality, message authentication, and replay protection to RTP/RTCP. RFC 3711 defines its original AES and HMAC-SHA1 transforms; later profiles add other algorithms.[7]
- ZRTP (Zimmermann Real-time Transport Protocol): ZRTP negotiates keys in the RTP media path independently of the signaling protocol. RFC 6189 defines Diffie-Hellman modes, retained shared secrets, and a Short Authentication String (SAS) that participants can compare to detect a man-in-the-middle attack.[8]
These protocols play essential roles in delivering and securing real-time multimedia communication over IP networks. While RTP and RTCP handle the actual media transmission and quality monitoring, SRTP and ZRTP ensure that the transmitted media is protected against eavesdropping, tampering, and replay attacks.
References
- [1] RFC 3435 - Media Gateway Control Protocol (MGCP) Version 1.0
- [2] Cisco - Skinny Client Control Protocol
- [3] ITU-T H.323
- [4] RFC 5456 - IAX: Inter-Asterisk eXchange Version 2
- [5] RFC 8866 - SDP: Session Description Protocol
- [6] RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
- [7] RFC 3711 - The Secure Real-time Transport Protocol
- [8] RFC 6189 - ZRTP