Protocol Stacks: SIP and H.323

Second to H.323, the next most commonly used protocol is the Session Initiation Protocol (SIP). Its architecture and main elements were discussed in the previous post. SIP essentially serves the same purpose as H.323.

Both protocols can be seen as different approaches to the same task. While H.323 relies on traditional phone signaling systems based on the Q.931 protocol, SIP uses a more modern, Internet-oriented approach based on HTTP.

SIP can set up, modify, and end multimedia sessions. It was developed by the IETF's Multiparty Multimedia Session Control (MMUSIC) working group, and its specification is outlined in the IETF's RFC 3261 document.

SIP supports several key functions for starting and ending multimedia sessions, such as locating the called user, checking their readiness and capabilities (like equipment and environment settings), sending the call, setting session parameters for both sides, and managing the session (including transfer, termination, parameter changes, and service offerings).

SIP supports inviting participants to ongoing sessions, like in multipoint conferences, adding or removing multimedia data to or from a session, and handling naming transparency and service redirection, including user personal mobility.

SIP is compatible with both IPv4 and IPv6 addressing protocols.

Note: Presence information includes the user's or device's state at a given moment. For example, a mobile user's actual location: "at the office," "on the road," "in the lab," etc.

To build a complete multimedia architecture, SIP is used alongside other IETF protocols: the Real-time Transport Protocol (RTP) and the Real-Time Control Protocol (RTCP).

The Session Description Protocol (SDP) is part of the SIP family as per IETF's RFC 2327. It describes session characteristics like time and required resources and allows real-time session parameter changes.

The Session Initiation Protocol for Telephones (SIP-T), as described in RFC 3372, outlines the interaction between SIP and the Public Switched Telephone Network (PSTN). It supports direct SIP and PSTN message conversion as well as encapsulation.

In direct conversion, a SIP call from a PSTN gateway is indistinguishable from a call sent by a SIP device, so both calls are processed the same. However, not every PSTN signaling message parameter has an equivalent in SIP, meaning some signaling information may be lost if the call is directed to a PSTN user.

Encapsulation drawbacks include applicability only to networks with a single signaling protocol, the need to encrypt PSTN messages when sent over the public Internet, or use in networks only with SIP-compatible devices.

The Signaling Transport Protocol Stack (SIGTRAN) supports the transport of SS7 signaling protocols over IP networks, representing an evolution of SS7 that accounts for the unique features of SS7 and packet protocols. SIGTRAN applications include remote dial-up access and IP telephony interactions with PSTN, among others.

SIGTRAN's core architecture includes the following elements:

• Media Gateway (MG) packs voice traffic into packets for delivery
• Signaling Gateway (SG) interfaces with the SS7 network and sends signaling messages to IP nodes
• Media Gateway Controller (MGC) manages calls between the signaling and media gateways and between PSTN and IP networks
• IP-enabled Service Control Point (SCP) located in the IP network but addressable from the SS7 network
• IP phone

The Stream Control Transmission Protocol (SCTP) is the key protocol in the SIGTRAN family. It's an enhanced version of TCP, providing reliable packet transport but surpassing TCP in message transport.

SCTP has built-in message segmentation at the transport level; it avoids TCP's "Head of Line Blocking" problem, where a lost segment delays the entire buffer content until retransmission. SCTP also supports multihoming, ensuring continued message reception if one load-balancing server fails without needing DNS services.

Telephony Routing over IP (TRIP) supports the exchange of call routing tables between different IP telephony networks or IP Telephony Administrative Domains (ITADs) as defined in RFC 2871. Each ITAD has at least one Location Server (LS) acting as a signaling server, which can be an H.323 domain controller, SIP server, or MGC. TRIP is crucial for integrating such LSs, handling the called-party data, and their signaling within an ITAD, similar to BGP's role in combining Internet autonomous systems.