VoIP call forwarding Technology: Protocols and Providers

VoIP call forwarding technology governs how voice calls transmitted over internet protocol networks are directed from origination point to destination. This page covers the core protocols that enable VoIP routing, the provider landscape, the operational scenarios where VoIP routing decisions diverge from traditional PSTN routing, and the technical boundaries that determine which protocol or architecture applies. Understanding these distinctions matters for any organization evaluating cloud-based call forwarding platforms or replacing legacy telephony infrastructure.

Definition and scope

Voice over Internet Protocol (VoIP) call forwarding is the process of converting analog voice signals into digital data packets, transmitting those packets across IP networks, and reassembling them at the destination endpoint. The International Telecommunication Union (ITU) defines the baseline signaling standards for packet-switched voice under its H-series and G-series recommendations, while the Internet Engineering Task Force (IETF) governs the dominant application-layer protocols through published RFCs.

The scope of VoIP routing spans four distinct infrastructure layers:

1. Signaling layer — establishes, manages, and terminates call sessions (SIP, H.323, MGCP)
2. Media transport layer — carries actual voice data between endpoints (RTP, SRTP)
3. Codec layer — compresses and decompresses audio (G.711, G.729, Opus)
4. Transport layer — moves packets across the network (UDP, TCP, TLS)

Each layer operates under separate standards bodies and introduces distinct routing decision points. Organizations evaluating SIP trunking and call forwarding must account for compatibility across all four layers, not just the signaling protocol in use.

How it works

A VoIP call forwarding sequence proceeds through six discrete phases:

1. Session initiation — The originating device sends a SIP INVITE message (defined in IETF RFC 3261) to a SIP proxy or registrar, identifying the destination URI.
2. Number resolution — The proxy queries a Location Server or ENUM (E.164 Number Mapping) database, translating a telephone number into a routable SIP URI per IETF RFC 6116.
3. Route selection — The proxy applies routing logic — least-cost routing, load balancing, geographic proximity, or failover rules — to select the next-hop carrier or endpoint cluster.
4. Session negotiation — SIP 183 Session Progress and 200 OK messages carry SDP (Session Description Protocol) payloads that negotiate codec, port, and media encryption parameters.
5. Media path establishment — RTP streams (or SRTP for encrypted media, per IETF RFC 3711) open between endpoints; the signaling path and media path are typically separate.
6. Call teardown — A SIP BYE message terminates the session; CDR (Call Detail Record) data is written for billing and analytics.

The dominant protocol in enterprise and carrier VoIP deployments is SIP (Session Initiation Protocol), which displaced H.323 — originally standardized by the ITU under Recommendation H.323 — as the prevailing session-layer standard by the mid-2000s. H.323 remains active in legacy video conferencing infrastructure. MGCP (Media Gateway Control Protocol), defined in IETF RFC 3435, persists in carrier-grade media gateway environments where centralized call control is required.

Common scenarios

Enterprise SIP trunk replacement of PRI lines — An organization replaces T1/PRI circuits with SIP trunks connecting its IP-PBX to a VoIP carrier. Routing logic moves from the PSTN carrier to the enterprise SIP proxy or session border controller (SBC). The SBC enforces topology hiding, codec normalization, and security policy at the IP perimeter. This scenario is described in operational terms within IETF RFC 5853, which addresses SBC requirements.

Hosted PBX and UCaaS routing — Cloud-hosted PBX services route inbound DIDs (Direct Inward Dial numbers) to registered SIP endpoints over the public internet or private MPLS links. Routing tables are managed through carrier portals rather than on-premise hardware. This model applies to organizations covered by the call forwarding for small business use case, where capital expenditure constraints favor hosted architectures.

Contact center media routing — High-volume contact centers combine VoIP infrastructure with automatic call distributor (ACD) systems to route calls based on IVR input, caller history, and agent skill sets. SIP REFER or SIP re-INVITE messages transfer calls between queues or agent endpoints without requiring the call to traverse the PSTN. Skills-based routing logic executes at the application layer, not the SIP signaling layer.

Emergency services (E911) routing — VoIP providers serving US subscribers are subject to FCC rules under 47 CFR Part 9, which mandate that nomadic VoIP services deliver 911 calls with accurate caller location to a Public Safety Answering Point (PSAP). The routing mechanism differs from standard SIP routing: calls must reach a geographically appropriate PSAP, requiring integration with the NENA i3 architecture (defined by the National Emergency Number Association) and Emergency Services IP Networks (ESInet).

Decision boundaries

SIP vs. H.323 — SIP is peer-to-peer and text-based, making it extensible and widely supported by open-source stacks (Asterisk, FreeSWITCH). H.323 is binary-encoded and centrally gated, making it more deterministic but less flexible. Organizations standardizing on modern UCaaS or CPaaS platforms will encounter SIP exclusively; H.323 appears only in legacy or video-conferencing contexts.

UDP vs. TLS transport — Standard SIP over UDP (port 5060) offers lower latency but no encryption or guaranteed delivery. SIP over TLS (port 5061) with SRTP for media satisfies the security requirements outlined in NIST SP 800-52 Rev. 2 for encrypted communications. Federal and healthcare deployments subject to FISMA or HIPAA enforcement pressure default to TLS/SRTP. Security considerations for VoIP infrastructure intersect directly with call forwarding security and fraud prevention controls, including STIR/SHAKEN call authentication mandated by the FCC for US carriers under the TRACED Act.

On-premise SBC vs. cloud SBC — Session border controllers deployed on-premise provide deterministic latency and local survivability during WAN failures. Cloud SBCs reduce hardware overhead and simplify multi-site interconnection. The architectural tradeoff is analyzed in detail on the on-premise vs. cloud call forwarding comparison resource. Organizations with latency-sensitive applications — financial trading desks, emergency dispatch — typically retain on-premise SBCs even in hybrid deployments.

References

• IETF RFC 3261 — SIP: Session Initiation Protocol
• IETF RFC 6116 — The E.164 to Uniform Resource Identifiers (URI) DDDS Application (ENUM)
• IETF RFC 3711 — The Secure Real-time Transport Protocol (SRTP)
• IETF RFC 3435 — Media Gateway Control Protocol (MGCP) Version 1.0
• NIST SP 800-52 Rev. 2 — Guidelines for the Selection, Configuration, and Use of TLS Implementations
• FCC 47 CFR Part 9 — 911 Requirements for VoIP Providers
• ITU-T H.323 — Packet-based Multimedia Communications Systems
• National Emergency Number Association (NENA) — i3 Solution Architecture