Telecom Networking — Practice Q&A
Q: Why does VoIP media traffic typically use UDP instead of TCP, given TCP's reliability guarantees?
A: TCP's reliability comes from retransmitting lost packets and guaranteeing in-order delivery, both of which add latency — acceptable for most data transfer, but harmful for live voice, where a retransmitted-and-delayed audio sample often sounds worse than simply dropping that small sample and continuing. UDP's connectionless, no-retransmission model tolerates occasional packet loss with minimal latency impact, which better matches real-time voice's actual quality requirements — a small amount of loss is preferable to added delay.
Q: What's the actual difference between what SIP does and what RTP does in a VoIP call?
A: SIP handles signaling — session setup (INVITE), parameter negotiation (codec selection), and teardown (BYE) — while RTP carries the actual voice/video media once SIP has established the session. They're deliberately separate protocols because signaling and media have different requirements: signaling needs reliable delivery of a relatively small amount of control data, while media needs low-latency, loss-tolerant delivery of a continuous stream — combining both into one protocol would force an unnecessary compromise on one or the other.
Q: Explain how a VoLTE call actually uses IMS, tracing the signaling path.
A: A VoLTE call's SIP INVITE first reaches the P-CSCF, the subscriber's initial point of contact into the IMS network, which forwards it to the S-CSCF — the component that actually handles session control and routing for that subscriber, querying the HSS (the IMS-era equivalent of GSM's HLR) for subscriber profile and authentication data. Once signaling establishes the session, voice media flows as RTP over the LTE data bearer with a dedicated QoS class ensuring voice-appropriate latency and jitter characteristics — IMS/SIP handles the "how do we set this call up" problem, and the underlying LTE data connection carries the actual voice traffic once it's set up.
Q: Why does a carrier need MPLS traffic engineering instead of just relying on standard IP routing?
A: Standard IP routing picks the "best" path per its routing protocol's own criteria, with no mechanism for an operator to explicitly guarantee bandwidth, avoid specific congested links, or prioritize latency-sensitive traffic classes like VoLTE voice over more tolerant bulk data traffic. MPLS's label-based forwarding gives operators explicit control over traffic paths and enables genuine traffic engineering — differentiated handling for different traffic classes sharing the same physical infrastructure — which plain best-path IP routing doesn't provide on its own.
Q: Is SD-WAN a replacement for MPLS? Why or why not?
A: Not accurately, no — SD-WAN is more accurately an orchestration layer that can incorporate MPLS as one of several transport options (alongside broadband internet and cellular links), rather than a competing transport technology that eliminates the need for MPLS. Many real SD-WAN deployments still use MPLS links for their most latency/reliability-sensitive traffic, while using SD-WAN's software-based control to add cheaper transport options into the mix for less-critical traffic and for automatic failover — the value is in flexibility and centralized control across diverse transport, not in replacing MPLS specifically.
Q: What problem do Session Border Controllers solve in a real carrier SIP/IMS deployment?
A: SBCs address two practical deployment challenges the core SIP/IMS protocol model doesn't handle on its own: NAT traversal (many devices and networks sit behind address translation that can break SIP's assumption that signaling addresses map directly to reachable endpoints) and security/interoperability (encrypting signaling and media, enforcing security policy, and managing differences between SIP implementations across networks/operators). SBCs sit at network edges specifically to manage these practical issues, functioning as a necessary operational layer that the theoretical SIP/IMS signaling model alone doesn't describe.