It’s been quite a while since I last built OBS from source and really dove into its internals. With the recent addition of WebRTC WHIP/WHEP protocols, I wanted to revisit the project and test out this exciting new capability. Having attended IETF meetings where these draft specifications were being developed, I was particularly excited to see them implemented in production software.

1. About WHIP and WHEP
2. So Why These Protocols Matter ?
3. Download mediamtx and Run the server (no configuration needed!)

About WHIP and WHEP

WHIP (WebRTC-HTTP Ingestion Protocol) and WHEP (WebRTC-HTTP Egress Protocol) are IETF draft standards

• WHIP (RFC 9725): https://datatracker.ietf.org/doc/rfc9725/ – Published Standard for WebRTC stream ingestion via HTTP
• WHEP (Internet-Draft): https://datatracker.ietf.org/doc/draft-ietf-wish-whep/ – Tries to standardize WebRTC stream distribution via HTTP.

So Why These Protocols Matter ?

From the IETF specifications, these protocols were designed to address fundamental challenges in WebRTC deployment:

WHIP (RFC 9725)’s objective is to Provide a simple HTTP-based protocol for WebRTC stream ingestion that eliminate the need for custom signaling protocols and WebSocket connections. This enable interoperability between encoders and media servers from different vendors and also support authentication and authorization through standard HTTP mechanisms (Bearer tokens). Similarly, it provides a standardized way to terminate sessions via HTTP DELETE

WHEP (Draft) Objective is to mirror WHIP’s simplicity for the playback/egress side. So it aims to enable one-to-many broadcasting scenarios with WebRTC while supporting adaptive bitrate through simulcast and scalable video coding. Note that unlike WHIP, WHEP ( at the time of writing this article) is only a draft document submitted, which describes simple HTTP-based protocol for WebRTC based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs).

1. Build OBS Studio from Source

Instead of using pre-built OBS binaries its kinda great to compile it from scratch. The build process is surprisingly smooth thanks to CMake, though the initial setup requires downloading dependencies.

Note: I’m using Visual Studio 2026 (18.4.0) on Windows, but OBS builds on Linux and macOS as well.

# Configure CMake (downloads dependencies automatically)
cmake -S . -B build_x64
# Build the project (parallel build speeds things up significantly)
cmake --build build_x64 --config Release --parallel

Result: OBS executable at build_x64/rundir/Release/bin/64bit/obs64.exe

build_x64/
├── frontend/
│   └── Release/
│       └── obs64.exe          ← Build output
└── rundir/
    └── Release/
        └── bin/
            └── 64bit/
                └── obs64.exe  ← Final runtime location 

The build includes the obs-webrtc plugin by default, which is what we’ll be testing. This plugin leverages libdatachannel for WebRTC implementation and supports the WHIP protocol natively.

2. Run OBS Studio

Start-Process "build_x64\rundir\Release\bin\64bit\obs64.exe" -WorkingDirectory "build_x64\rundir\Release\bin\64bit"

Verify: Check $env:APPDATA\obs-studio\logs for runtime logs

=== Latest Log: 2026-03-17 09-29-36.txt ===
15:23:03.742:   id: \\?\DISPLAY#AUS270B#5&6875e40&1&UID4353#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
15:23:03.742:   alt_id: \\.\DISPLAY1
15:23:03.742:   setting_id: \\?\DISPLAY#AUS270B#5&6875e40&1&UID4353#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
15:23:03.742:   force SDR: false
15:23:06.642: [duplicator-monitor-capture: 'Display Capture'] update settings:
15:23:06.642:   display:  (0x0)
15:23:06.642:   cursor: true
15:23:06.642:   method: WGC
15:23:06.642:   id:
15:23:06.642:   alt_id:
15:23:06.642:   setting_id: DUMMY
15:23:06.642:   force SDR: false
15:23:17.226: User added source 'Video Capture Device' (dshow_input) to scene 'Scene'
15:23:17.235: Video Capture Device: DecodeDeviceId failed
15:23:17.235: Video Capture Device: Video configuration failed
15:23:17.480: ---------------------------------
15:23:17.480: [DShow Device: 'Video Capture Device'] settings updated:
15:23:17.480:   video device: HD Webcam eMeet C960
15:23:17.480:   video path: \\?\usb#vid_328f&pid_003f&mi_00#9&124b7a38&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global
15:23:17.480:   resolution: 640x480
15:23:17.480:   flip: 0
15:23:17.480:   fps: 30.00 (interval: 333333)
15:23:17.480:   format: YUY2
15:23:17.480:   buffering: disabled
15:23:17.480:   hardware decode: disabled
15:24:04.545: Loading branches from file failed: Opening file failed.
15:37:57.050: Max audio buffering reached!
15:37:57.050: adding 917 milliseconds of audio buffering, total audio buffering is now 960 milliseconds (source: Desktop Audio)
15:37:57.050:
15:37:57.071: Source Desktop Audio audio is lagging (over by 834667.38 ms) at max audio buffering. Restarting source audio.

3. Setup WHIP Server (mediamtx)

OBS Studio’s obs-webrtc plugin implements WHIP, which requires a server to:

1. Receive WebRTC streams from OBS via HTTP POST with SDP offer/answer negotiation
2. Handle ICE/STUN/TURN for NAT traversal and peer connection setup (including trickle ICE support)
3. Redistribute streams to viewers via WHEP (WebRTC-HTTP Egress Protocol)  (TODO)
4. Manage session lifecycle – HTTP DELETE terminates sessions
5. Support authentication via HTTP Bearer tokens
6. Enable load balancing through HTTP 307 redirects

Unlike traditional RTMP servers, WHIP servers should enable <1s using WebRTC’s RTP transport. Having been part of the IETF discussions that shaped these protocols, it’s fascinating to see the design decisions translate into real-world performance benefits. So I expect to just HTTP POST my SDP offer to the WHIP endpoint, get back a 201 Created with SDP answer and resource Location, and be streaming. No complex WebSocket signaling, no custom protocols.

Download mediamtx and Run the server (no configuration needed!)

Invoke-WebRequest -Uri "https://github.com/bluenviron/mediamtx/releases/download/v1.8.4/mediamtx_v1.8.4_windows_amd64.zip" -OutFile "mediamtx.zip"
Expand-Archive -Path "mediamtx.zip" -DestinationPath "mediamtx"
cd mediamtx
.\mediamtx.exe

Default Ports:

• WHIP endpoint: http://localhost:8889/{stream}/whip
• WHEP endpoint: http://localhost:8889/{stream}/whep
• RTSP: rtsp://localhost:8554/{stream}
• HLS: http://localhost:8888/{stream}

Configuration: mediamtx works out-of-the-box. For advanced settings, edit mediamtx.yml

Logs snippet

2026/03/17 09:23:05 INF MediaMTX v1.8.4
2026/03/17 09:23:05 INF configuration loaded from C:\Users\altan\Downloads\OBS\obs-studio\mediamtx\mediamtx.yml
2026/03/17 09:23:05 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2026/03/17 09:23:05 INF [RTMP] listener opened on :1935
2026/03/17 09:23:05 INF [HLS] listener opened on :8888
2026/03/17 09:23:05 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2026/03/17 09:23:05 INF [SRT] listener opened on :8890 (UDP)
2026/03/17 09:23:40 INF [WebRTC] [session 4c95bc04] created by [::1]:64696
2026/03/17 09:23:40 INF [WebRTC] [session 4c95bc04] closed: no one is publishing to path 'mystream'
2026/03/17 09:29:56 INF [WebRTC] [session b15a4fef] created by [::1]:53070
2026/03/17 09:29:56 INF [WebRTC] [session b15a4fef] closed: no one is publishing to path 'mystream'
2026/03/17 09:29:57 INF [WebRTC] [session 4f42ee65] created by [::1]:53070
2026/03/17 09:29:57 INF [WebRTC] [session 4f42ee65] closed: no one is publishing to path 'mystream'
2026/03/17 16:15:33 INF [WebRTC] [session b1cfc835] created by [::1]:57732
2026/03/17 16:15:34 INF [WebRTC] [session b1cfc835] peer connection established, local candidate: host/udp/192.168.68.90/8189, remote candidate: prflx/udp/169.254.197.35/55983
2026/03/17 16:15:35 INF [WebRTC] [session b1cfc835] is publishing to path 'mystream', 2 tracks (Opus, H264)
2026/03/17 16:16:48 INF [WebRTC] [session 079d3b5c] created by [::1]:58062
2026/03/17 16:16:48 INF [WebRTC] [session 079d3b5c] peer connection established, local candidate: host/udp/169.254.197.35/8189, remote candidate: prflx/udp/169.254.197.35/64607
2026/03/17 16:16:48 INF [WebRTC] [session 079d3b5c] is reading from path 'mystream', 2 tracks (Opus, H264)

4. Create HTML Test Player

Create test-webrtc-playback.html with WebRTC player

quiche-webtransport-playground/test-webrtc-playback.html at main · altanai/quiche-webtransport-playground

5. Configure OBS for WHIP Streaming

Now comes the exciting part—configuring OBS to use WHIP instead of traditional RTMP.

1. Open OBS Studio
2. Add a source (Display Capture, Window Capture, your cat whatever..)
3. Settings → Stream
   • Service: WHIP 
   • Server: http://localhost:8889/mystream/whip
   • Bearer Token: (leave empty for local testing)
4. Click Apply → OK
5. Click Start Streaming

Behind the scenes, OBS performs an HTTP POST to the WHIP endpoint with an SDP offer containing:

• Codec information (H.264/HEVC/AV1 for video, Opus for audio)
• ICE candidates for network traversal
• Media stream IDs and track information

The server responds with an SDP answer, and the WebRTC peer connection is established. Simple.

6. Test Playback with WHEP

The viewer side uses WHEP (WebRTC-HTTP Egress Protocol), the companion spec to WHIP. Just as WHIP simplifies publishing, WHEP makes playback straightforward.

1. In the browser (test-webrtc-playback.html)
2. WHEP URL: http://localhost:8889/mystream/whep
3. Click Connect
4. Stream should appear with <1 second latency

The HTML player performs an HTTP POST to the WHEP endpoint with its SDP offer, receives the server’s answer, and establishes a WebRTC peer connection. No proprietary protocols,—just standardized WebRTC in the browser.

What you’ll experience:

Near-instantaneous stream start + Smooth playback at your source framerate

Smooth and crisp SDP exchange

Also Real-time stats showing bytes received, packet loss, jitter + True interactive latency for two-way communication use cases

AUDIO: 2.10 MB, 6651 packets, 0 lost, jitter: 10.00ms | VIDEO: 95.30 MB, 90393 packets, 0 lost, jitter: 23.00m

Or goto chrome://webrtc-internals for the detailed view

Statistics IT01V4267985642
timestamp	3/17/2026, 4:28:01 PM	
bytesReceived	505663558	
codecId	CIT01_109_level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f	
decoderImplementation	ExternalDecoder (D3D11VideoDecoder)	
estimatedPlayoutTimestamp	3982778881401	
firCount	0	
frameHeight	720	
frameWidth	1280	
framesAssembledFromMultiplePackets	20141	
framesDecoded	20142	
framesDropped	0	
framesPerSecond	30	
framesReceived	20146	
freezeCount	0	
headerBytesReceived	5478960	
jitter	0.023	
jitterBufferDelay	1935.284545	
jitterBufferEmittedCount	20142	
jitterBufferMinimumDelay	1447.6261889999998	
jitterBufferTargetDelay	1924.9337189999999	
keyFramesDecoded	81	
kind	video	
lastPacketReceivedTimestamp	1773790082077.461	
mid	0	
minPlayoutDelay	0.113	
nackCount	0	
packetsLost	0	
packetsReceived	456580	
packetsReceivedWithCe	0	
packetsReceivedWithEct1	0	
pauseCount	0	
pliCount	10	
powerEfficientDecoder	true	
remoteId	ROV4267985642	
ssrc	4267985642	
totalAssemblyTime	4.002161	
totalDecodeTime	7.443236	
totalFreezesDuration	0	
totalInterFrameDelay	671.397	
totalPausesDuration	0	
totalProcessingDelay	1943.1741359999999	
totalSquaredInterFrameDelay	23.392953000002198	
trackIdentifier	cd91177d-1b57-458a-9598-945f1b11ab23	
transportId	T01	
type	inbound-rtp	
[framesReceived-framesDecoded-framesDropped]	4	
[codec]	H264 (109, level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f)	
[lastPacketReceivedTimestamp]	3/17/2026, 4:28:02 PM	
[estimatedPlayoutTimestamp]	3/17/2026, 4:28:01 PM	
[bytesReceived_in_bits/s]	5796213	
[headerBytesReceived_in_bits/s]	63158	
[framesReceived/s]	28.995384523752566	
[framesDecoded/s]	29.995225369399208	
[keyFramesDecoded/s]	0	
[totalDecodeTime/framesDecoded_in_ms]	0.30120000000000147	
[totalInterFrameDelay/framesDecoded_in_ms]	33.10000000000173	
[interFrameDelayStDev_in_ms]	5.855766388792323	
[jitterBufferDelay/jitterBufferEmittedCount_in_ms]	109.5702666666663	
[jitterBufferTargetDelay/jitterBufferEmittedCount_in_ms]	102.99999999999727	
[jitterBufferMinimumDelay/jitterBufferEmittedCount_in_ms]	75.22246666666585	
[totalProcessingDelay/jitterBufferEmittedCount_in_ms]	109.89603333333282	
[totalAssemblyTime/framesAssembledFromMultiplePackets_in_ms]	

This is a massive improvement over traditional HLS (5-30s latency) or even Low-Latency HLS (2-4s). Btw seeing it work end-to-end is incredibly satisfying.

If you are still reading then here is the Architecture

Endpoints

• OBS WebSocket: ws://localhost:4455 (for API control)
• WHIP Ingest: http://localhost:8889/mystream/whip (publish)
• WHEP Playback: http://localhost:8889/mystream/whep (view)

Ports

 Get-NetTCPConnection -LocalPort 8889,4455

LocalAddress                        LocalPort RemoteAddress                       RemotePort State       AppliedSetting
------------                        --------- -------------                       ---------- -----       --------------
::1                                 8889      ::1                                 58062      Established Internet
::                                  8889      ::                                  0          Listen
::                                  4455      ::                                  0          Listen

I also made a stats heavy page for latency testing ( also found in the rep oquiche-webtransport-playground/test-webrtc-playback.html at main · altanai/quiche-webtransport-playground )

So if you are testing things in the wild remember these key Metrics to Watch:

Resources & Further Reading

• OBS Studio: https://obsproject.com – Amazing open-source streaming software
• WHIP Spec (IETF): https://datatracker.ietf.org/doc/draft-ietf-wish-whip/ – WebRTC-HTTP Ingestion Protocol
• WHEP Spec (IETF): https://datatracker.ietf.org/doc/draft-murillo-whep/ – WebRTC-HTTP Egress Protocol
• mediamtx: https://github.com/bluenviron/mediamtx – Excellent multi-protocol media server
• libdatachannel: https://github.com/paullouisageneau/libdatachannel – WebRTC library used by OBS

Why DRM Still Matters

Piracy tooling now targets low-latency and browser-delivered streams, not just VOD assets. Modern stacks blend real-time WebRTC, near-real-time LL-HLS/DASH on QUIC, and traditional HLS/DASH, so protection must span all three delivery modes. Regulatory and contractual controls such as windowing, geography, and device caps also demand auditable enforcement, not only encryption.

Encrypted Media Extensions (EME) is the browser API that lets a web page request protected playback, obtain licenses, and control keys; it is implemented in major browsers and delegates to a platform Content Decryption Module (CDM). CDMs—such as Widevine (Google), PlayReady (Microsoft), and FairPlay (Apple)—are the trusted components that receive licenses, decrypt media, and enforce policy like output protection, HDCP, secure decode, offline rules, renewal, and revocation. EME mediates access from JavaScript, the CDM enforces rights below the page (often in a sandbox or TEE), and the license server encodes the business rules, making EME+CDM the delivery and enforcement surface for browser-based DRM.

DRM in major Live Streaming Frameworks

Low-latency HLS and low-latency DASH over HTTP/2 or HTTP/3 still rely on EME with CENC and the same license services; the differentiators are shorter segment parts, tighter token expirations, and the need for license issuance fast enough to keep up with part delivery.

HESP (High Efficiency Streaming Protocol) trades startup and channel-change latency for chunked CMAF delivery, using standard CENC licenses, so part-level entitlement and rapid license response times are the main DRM levers.

Contribution protocols like SRT and RIST carry mezzanine feeds into the packager and do not provide DRM; security depends on transport encryption plus authentication before repackaging into HLS/DASH/CMAF.

Emerging browser-facing paths such as WHIP/WHEP (WebRTC ingest/egress) and WebTransport/WebCodecs inherit WebRTC’s DRM gap: you need application-layer entitlement, SFrame or equivalent end-to-end encryption, and watermarking to deter capture or restreams.

Considerations in Digital Rights for WebRTC Streams

WebRTC has no built-in Encrypted Media Extensions (EME) or Content Decryption Module (CDM) path; media is typically SRTP with DTLS keying, so DRM-like controls live at the application layer on top of encryption. Premium content is often handled through server-side rendering to an EME-capable player or via insertable streams with SFrame to keep media encrypted through SFUs while enforcing policy in the app.

Key challenges include per-participant entitlement, secure key distribution to endpoints, and preventing SFU-level leakage through recording or simulcast abuse. Mitigations hinge on short-lived keys, per-subscriber identities bound to signaling, watermarking (visible or forensic), device fingerprinting, and limiting resolution or track sets per entitlement.

Consideration for DRM in Media on QUIC / HTTP/3

QUIC removes head-of-line blocking for CMAF, LL-HLS, and DASH, while the DRM layer generally remains CENC (Widevine/PlayReady/FairPlay) delivered via EME in browsers or native SDKs. Effective setups rely on frequent key rotation on live edges, signed URLs or cookies tied to viewer identity, and license TTLs aligned to segment windows. Operators must watch for partial object caching issues with CDNs that do not fully support HTTP/3 and for player fallbacks to TCP/HTTP2 where latency-sensitive anti-piracy rules can weaken. QUIC datagrams for media (WebTransport/WebCodecs) are emerging, but there is no standardized DRM story yet, so most implementations still encapsulate EME-backed playback for protected content.

Packagers work best with CMAF and CENC, typically using cbcs for Apple ecosystems, with aligned initialization data across ABR ladders to simplify license acquisition. Players such as Shaka Player, dash.js, ExoPlayer, AVFoundation, and WebKit EME depend on license servers, and consistency in robustness levels (L1 vs L3) by device class is essential. License services are often centralized—either through multi-DRM vendors or native KMS-backed services—and must enforce concurrency, device registration, and geo/IP/ASN allow/deny logic. Observability should trace license requests, key rotation cadence, and playback errors and tie these signals to watermarking hits to respond quickly to restreams.

References

W3C Encrypted Media Extensions (EME) specification; IETF SFrame (draft-ietf-sframe-enc) for end-to-end encryption in WebRTC; IETF QUIC (RFC 9000) and HTTP/3 (RFC 9114) for transport of CMAF/LL-HLS/DASH; CTA-5001 Common Media Application Format (CMAF); Apple Low-Latency HLS (LL-HLS) specification; DASH-IF Interoperability Points (IOP) for live or low-latency streaming; HESP Alliance specification; SRT and RIST protocol specifications for contribution transport; WHIP/WHEP drafts for WebRTC ingest/egress.

Multicast media streaming has become essential for modern telecommunications, broadcasting, and content delivery networks. This guide explores the protocols and technologies that enable efficient, scalable distribution of media to multiple receivers simultaneously, from MPLS-based approaches to cutting-edge QUIC-based solutions.

MLDP (Multipoint Label Distribution Protocol)

MLDP is an MPLS-based multicast protocol designed for establishing multicast label switched paths (LSPs) in MPLS networks. It’s particularly suited for large-scale multicast delivery scenarios like IPTV, live video broadcasting, and enterprise multimedia applications.

How MLDP Works

• Uses label distribution to create multicast trees
• Optimizes bandwidth by leveraging MPLS forwarding
• Handles packet loss and congestion through sophisticated forwarding mechanisms
• Establishes efficient multicast paths across provider networks

Advantages

Excellent scalability for handling multicast traffic across large networks
Efficient bandwidth utilization through label switching
Built-in packet loss and congestion handling via MPLS forwarding
Proven in large carrier deployments

Disadvantages

Higher latency compared to UDP-based approaches, Less suitable for real-time, ultra-low-latency applications
Requires dedicated MPLS network infrastructure
Complex configuration and management overhead

Use Cases

• IPTV Networks: Primary protocol for carrier IPTV deployments
• Live Event Broadcasting: Sports and entertainment distribution
• Enterprise Multicast: Internal network content delivery

HLS (HTTP Live Streaming)

HLS is one of the most widely deployed HTTP-based streaming protocols, created by Apple and standardized through IETF (RFC 8216). It segments media content into fixed-duration chunks and delivers them over standard HTTP/HTTPS, making it highly compatible with existing CDN infrastructure and web technologies, but it faces competition from other streaming protocols due to certain limitations, including latenc , fragmented playback, bandwidth inefficiency and limited interactivity.

Architecture

• Media Segmentation: Content divided into 2-10 second segments
• Playlist Distribution: M3U8 playlist files guide client playback
• Progressive Download: Segments downloaded sequentially over HTTP
• CDN-Optimized: Works seamlessly with content delivery networks

Advantages

Exceptional CDN compatibility (optimal for OTT content distribution)
Works across firewalls (uses standard HTTP/HTTPS)
Cross-platform and device compatibility
Simple implementation and deployment
Proven at massive scale (Netflix, YouTube, etc.)

Disadvantages

Higher latency (due to buffering and HTTP overhead), Not suitable for live, interactive, or real-time applications
Bandwidth inefficiency from repetitive HTTP requests
Limited interactivity and control capabilities

Use Cases

• Video-on-Demand (VOD): Movies, TV shows, educational content
• Live Streaming: Sports, news broadcasts (with reduced interactivity)
• OTT Platforms: Netflix, YouTube, Disney+, etc.
• Podcast & Audio Streaming: Music and audio-based content

DASH (Dynamic Adaptive Streaming over HTTP)

DASH is an international standard (ISO/IEC 23009-1) that provides dynamic bitrate adaptation for HTTP-based streaming. Unlike HLS’s fixed approach, DASH enables clients to select the optimal quality based on network conditions, similar to HLS but with standardized mechanisms.

Architecture

• Media Presentation Description (MPD): XML file describing available bitrates and segments
• Multiple Bitrates: Content encoded at various quality levels (480p, 720p, 1080p, 4K)
• Dynamic Selection: Client chooses bitrate based on available bandwidth
• CDN Integration: Works with standard HTTP/HTTPS delivery networks

Advantages

Dynamic adaptive streaming reduces buffering and improves QoE
International standardization (ISO/IEC 23009-1)
Supports multiple codecs (H.264, H.265, VP9, AV1)
Efficient bandwidth utilization
CDN-friendly like HLS

Disadvantages

Similar latency limitations to HLS (10-30 seconds typical) but more complex implementation than HLS
Requires sophisticated client logic for bitrate selection
Not optimized for real-time communication

Use Cases

• Premium VOD Services: Netflix, Amazon Prime (primary choice)
• Live Streaming Events: Sports, concerts, conferences
• 4K Ultra HD Streaming: High-quality media delivery
• Mobile Streaming: Adaptive quality for variable networks

SRT (Secure Reliable Transport)

SRT is an open-source, real-time video streaming protocol developed by Haivision and Wowza, and now governed by the SRT Alliance. It combines reliability, security, and low latency into a single protocol, specifically designed for high-quality video streaming over unpredictable networks.

Key Technologies

• NAK-based Retransmission: Selective and immediate re-transmission for packet loss recovery
• Adaptive Bitrate: Adjusts to network conditions
• Advanced Encryption: TLS 1.2+ for secure transmission
• Video Processing: Optimized codec support and quality control

Advantages

Sub-second latency (500ms or less) comparable to WebRTC
Codec agnostic – works with any video codec
Strong security with built-in encryption
Excellent compatibility across platforms
Proven in enterprise and broadcasting environments
NAK-based recovery for efficient loss handling

Disadvantages

Requires dedicated SRT infrastructure
Less widespread adoption compared to HLS/DASH
Higher bandwidth overhead due to reliability mechanisms
Smaller ecosystem of tools and services

Technical Details

• Packet Structure: Each SRT packet begins with an SRT header containing metadata
• Control & Data Packets: Separate handling for media and control information
• Window-based ACK: Acknowledges reception of packet groups for efficiency

Use Cases

• Live Event Streaming: Sports, concerts, news broadcasts
• Enterprise Video: Corporate events, remote monitoring
• Contribution Networks: Equipment to broadcast center feeds
• Low-Latency Surveillance: Security camera monitoring
• Gaming & Interactive: Competitive gaming with minimal latency

 Each unit of SRT media or control data created by an application begins with the SRT packet header.

RIST ( Reliable Internet Stream Transport )

RIST is an open-source specification for transporting video over lossy, unpredictable internet networks with low latency and high quality. Managed by the VESA (Video Electronics Standards Association), it’s optimized for broadcasting and professional video delivery where reliability is critical.

Core Features

• RTP/UDP Foundation: Built on industry-standard protocols
• NACK-based Retransmission: Automatic Request (ARQ) for packet recovery
• Error Correction: Forward Error Correction (FEC) capabilities
• Profile Flexibility: Multiple profiles for different use cases

RIST Profiles

Associated Protocols

• RTP (Real-time Transport Protocol): Media transport
• RTCP (RTP Control Protocol): Feedback and statistics
• FEC (Forward Error Correction): Additional reliability layer

Advantages

Excellent for 2-6 second latency applications
Built-in error correction and recovery
NACK-based efficiency reduces bandwidth waste
Open-source specification promotes adoption
Suitable for mission-critical broadcasting
Multiple profiles for different scenarios

Disadvantages

Higher latency than SRT or WebRTC
Requires careful network tuning
Still building ecosystem and tooling, Less mainstream than HLS/DASH

Competitive Landscape

• Open-source Predecessors: SRT (more mature, lower latency)
• Proprietary Alternatives: Zixi (feature-rich), VideoFlow (specialized use cases)

Use Cases

• Professional Broadcasting: Live TV, sports events
• Content Distribution: Reliable ingest and contribution
• Failover Networks: Redundancy with automatic recovery
• International Feeds: Transatlantic/transpacific broadcasts

MoQ( Media Over QUIC)

MoQ is under design for low-latency media streaming applications, which can be live as well as on demand streaming , e.g., interactive content, live events, gaming. MoQ represents the next evolution in low-latency media streaming, currently under standardization by the IETF Media Over QUIC Working Group. It leverages QUIC (Quick UDP Internet Connections) as its transport layer, inheriting QUIC’s advantages: multiplexing, connection migration, and built-in security.

• (+) TLS 1.3 and AES encryption

Architecture Overview

Publisher → QUIC Servers → CDN Nodes → Transcoding → Subscribers
                        ↓
                   Caching & Relay

Key Advantages of QUIC Foundation

 TLS 1.3 Integration: Encryption by default (AES-GCM)
 Multiplexing: Multiple streams over single connection
 Connection Migration: Seamless network switching (WiFi5G)
 Reduced Latency: 0-RTT resumption, faster handshakes
 Congestion Control: Improved adaptation to network changes

Media Over QUIC Features

• Variable Resolution Support: Subscribers request different quality levels
• Content Transcoding: On-the-fly quality conversion at CDN nodes
• Selective Bitstream Decoding: Partial bitstream reception for lower resolutions
• Dynamic Adaptation: Real-time quality adjustment based on network conditions

WebRTC SFU + Scalable Video Encoding (SVC) for low latency decoding

WebRTC-based Selective Forwarding Unit (SFU) combined with Scalable Video Coding (SVC) represents a powerful architecture for real-time interactive media. Rather than mixing or transcoding media server-side, an SFU forwards selected streams while SVC enables efficient bitrate adaptation at the application layer, allowing subscribers to consume partial bitstreams matching their network conditions and device capabilities.

Scalable Video Coding (SVC)

SVC enables transmission and decoding of partial bitstreams, allowing delivery of video services with lower temporal or spatial resolutions or reduced quality while maintaining high reconstruction fidelity relative to the partial bitstream rate.

Scalability Dimensions

• Quality/Fidelity Scalability: Variable compression levels and details
• Temporal Scalability: Different frame rates (30fps, 15fps, 7.5fps, 3.75fps)
• Spatial Scalability: Different resolutions (1080p, 720p, 480p, 360p)

RTCRtpCodecCapability dictionary provides information about codec capabilities such as codec MIME media type/subtype,codec clock rate expressed in Hertz, maximum number of channels (mono=1, stereo=2). With the advent of SVC there has been a rising interest in motion-compensation and intra prediction, transform and entropy coding, deblocking, unit packetization. The base layer of an SVC bit-stream is generally coded in compliance with H.264/MPEG4-AVC.

Selective Forwarding Unit (SFU)

A Selective Forwarding Unit is a media server that:

• Receives media streams from multiple participants
• Does NOT mix or transcode (unlike MCU)
• Selectively forwards streams to receivers based on:
  • Bandwidth constraints
  • Device capabilities
  • Application logic
  • User selection

Publisher (H.264 SVC)
    ↓
SFU (receives multi-layer stream)
    ↓
  ├→ Client 1 (1080p/30fps) - receives all layers
  ├→ Client 2 (720p/15fps) - receives subset of layers  
  └→ Client 3 (480p/7.5fps) - receives base layer only

Use Cases

• Multi-Party Video Conferencing: Efficient bandwidth for 4+ participants
• Interactive Streaming: Live Q&A, webinars, online classes
• Gaming: Low-latency multiplayer gaming streams
• Remote Collaboration: Screen sharing + video with adaptive quality
• Live Broadcasting with Interactivity: Audience participation features

Implementation Considerations

Encoding Requirements

• Encoder must support SVC profile (H.264/AVC SVC, VP9, or AV1)
• Base layer MUST be independently decodable
• Enhancement layers defined at encoding time

Client-Side Complexity

• Clients must understand layer dependencies and perform Dynamic layer switching based on bandwidth
• Clients also need to implement complex jitter buffer management for multi-layer streams

Network Considerations

• Packet loss recovery becomes layer-aware
• Prioritize base layer transport and perform QoS marking for different layers

Fanout Multicast / Anycast

Fanout (multicast) and anycast are connection-less approaches to multi-recipient delivery, distinct from connection-oriented protocols that must establish individual peer connections.

Connection-oriented protocols find it difficult to scale out to large numbers as compared to connectionless protocols like IP/UDP. It is not advisable to implement hybrid, multipoint or cascading architectures for low latency networks as every proxy node will add its buffering delays.

Connection-Oriented Issues:

• Linear scaling: N connections for N receivers
• Per-peer buffering overhead
• Session management complexity
• Exponential state growth

Connectionless Advantages:

• IP-level distribution efficiency
• Single transmission, multiple receivers
• Minimal per-connection overhead
• Broadcast/multicast native to UDP/IP

As a rule of thumb In low-latency networks, avoid proxy cascades. Direct peer-to-peer or simple tree topologies minimize delay.

WHEP (WebRTC-HTTP Egress Protocol)

WHEP is a standardized protocol (IETF draft) for WebRTC-based media egress. It enables efficient delivery of media streams via WebRTC’s proven reliability mechanisms while maintaining compatibility with HTTP infrastructure.

WebRTC-based egress protocol with Very Low (<500ms) latency but high reliability over SRTP atop DTLS.

Technical Specifications

• Transport: SRTP (Secure Real-time Transport Protocol) over DTLS (Datagram TLS)
• Latency: Very low (<500ms typical)
• Reliability: High confidence delivery with automatic retransmission
• Encryption: DTLS secures the transport layer

Advantages

Sub-500ms latency with high reliability
SRTP encryption prevents eavesdropping
DTLS authentication and integrity
Leverages proven WebRTC infrastructure
HTTP compatibility for firewall traversal
Standardized protocol definition

Disadvantages

Requires DTLS/SRTP infrastructure
Less established than HLS/DASH
Client implementation complexity
Browser support still developing

Use Cases

• Interactive Broadcasting: Real-time viewer participation
• Live Event Streaming: Ultra-low latency consumption
• WebRTC Broadcasting: Native browser consumption
• Secure Streaming: Encrypted media delivery

Protocol Comparison Matrix

My Decision Framework for Choosing the Right Protocol

For Enterprise IPTV MLDP
For Video-on-Demand (VOD) & OTT Services chose DASH or HLS
For Live Broadcasting (≤6s Latency) m RIST or SRT
For Ultra-Low Latency Interactive (<1s) like cloud gaming MoQ, SRT, WebRTC SFU+SVC, or WHEP

For Multi-Party Video Conferencing WebRTC SFU + SVC

 Latency-Scalability Tradeoff

Low Latency  ←──────────────→  High Scalability
  (WHEP)                          (HLS/DASH)
  (SRT)                           (MLDP)
  (MoQ)                           

Scalable multicast media streaming requires a nuanced understanding of protocol tradeoffs. There is no one-size-fits-all solution. However as QUIC deployment accelerates and MoQ/WHEP mature, we’ll likely see a convergence toward QUIC-based solutions for new projects.

Standardization & Regulatory Status (2025)

References

RFC & International Standards

HTTP Streaming Protocols

• RFC 8216 – HTTP Live Streaming (HLS) – Apple HTTP Live Streaming Specification
• ISO/IEC 23009-1:2019 – DASH (Dynamic Adaptive Streaming over HTTP) – International standard for adaptive HTTP streaming
• IETF Draft – Low-Latency DASH (LL-DASH) – Extension for reduced latency HLS

Real-Time Transport Protocols

• RFC 3550 – RTP (Real-time Transport Protocol) – Foundation for media transport
• RFC 3551 – RTP Payload Format – Audio and video codec specifications
• RFC 3711 – SRTP (Secure Real-time Transport Protocol) – Encryption and authentication for RTP

Multicast & Network Protocols

• RFC 3031 – MPLS Architecture – Foundation for MLDP
• RFC 6388 – LDP Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MLDP)
• RFC 6389 – MPLS Upstream Label Assignment for LDP

Emerging Protocols (IETF WGs)

• IETF MoQ WG – Media Over QUIC – Draft-11 (January 2025)
• IETF WHEP – WebRTC HTTP Egress Protocol – Draft-12 (January 2025)
• RFC 9000 – QUIC: A UDP-Based Multiplexed and Secure Transport

Open-Source Specifications

SRT Alliance

• SRT (Secure Reliable Transport) Specification – Version 1.4.4 (2024)
• SRT Cookbook – Best Practices Guide – Implementation guidelines
• SRT GitHub Repository – Reference implementation

VESA RIST

• RIST (Reliable Internet Stream Transport) Official Specification – Version 2.2 (2024)
• RIST Simple, Main, Enhanced Profiles – Profile definitions
• RIST Alliance Documentation – Technical resources

Industry Standards & Working Groups

Broadcasting Standards

• EBU (European Broadcasting Union) – RIST Recommendations – European standard adoption
• SMPTE ST 2059-1 – Timecode and Control Specifications – Professional video standards
• ITU-R BT.2020 – Ultra High Definition Television (UHDTV) – 4K/8K specifications

WebRTC Standards

• W3C WebRTC Specification – Real-time communication API
• IETF RTCWEB WG – WebRTC Protocols – Transport and codec specifications

Encapsulation is the process of encasing the payload sent by an endpoint into another protocol’s payload, attaching its own header and trailer. This is applied to all data being processed by the network stack layers. For example, an HTTP ( L7 application layer protocol) is encapsulated under a TCP header (L4 layer protocol ) and further in an IP header ( L3 protocol) and so on until it is down to the physical layer.

This article doesn’t deal with encapsulation across the general network stack but rather focuses on encapsulating protocols that try to mask the identity of the original payload from network middleboxes to provide anonymity or virtualized networking.

Core parts of a secure communication framework relying on encapsulation are

• Encapsulation and decapsulation ( encap and decap) libraries on the receiver and sender as well as a means to exchange the metadata enabling encap-decap.
•  The payload, which is an original packet, optionally including upper-layer protocols, can be encrypted or plain.
•  Algorithms and tools to order packets arriving out of order and duplicated
•  Provide confidentiality as well as detection against malicious activities like MITM attacks or other kinds of passive attacks such as eavesdropping and replaying.

Sequnece Numbers are monotonically increasing numbers that show the ordering of the packets in a stream. They do not necessarily start from 0. Most sequence numbers have a wrapping feature, especially useful for long-lived connections. At the far end of the valid sequence number range, the sequence numbers can go down to the beginning after maxing out. First used in TCP, sequence numbers have become popular in the most reliable communication protocols. Primarily meant for reordering the incoming packets in traffic in the correct order, these numbers can be used for other purposes as well.

• Sequence numbers in the headers, such as ESP, help maintain the anti-replay window, which prevents attacks from replaying previously captured data. Any packet coming from a sequence outside the window is either a retransmission or a replay attack and, hence, can be more scrutinized.
• In some cases of ESP, even extended sequence numbers are used, which can be controlled by the cryptographic algorithm making it a security enhancement.

Security Association between the endpoints of an encapsulated path. Security Association is a critical aspect of securing a communication path with a crypto algorithm, integration, keys, etc, and is used especially in the case of IPsec.

Sharing Keys : Maual keying , static configuration based keying and most recommended, Key exchange protocols such as IKE ( Internet Key exchange) can be used to share secret keys.

Unique identification : The onus of unique identification of the multiple paths/streams and the order of packets in the individual paths/streams lies with the creator of the header that would be attached to the encapsulated payload. Such a unique identifier or set of attributes should be able to distinguish multiple coexisting tunnels. Some example of unique Id/ identifiers in multioplexed usecase in case of non tunneling usecases are

• HTTP/2 uses stream ID for multiplexed flows within a single connection
• SIP uses Session ID

Simmilarly example of unique Id/ identifier in case of tunneling are

• GRE uses the key field to make distuiction between individual flows
• MPLS uses labels to identify diferent strems associated with different classes.
• ESP uses SPI to attach the cryptographic SA keys to each packet for processing.
• L2TP ( Layer 2 Tunneling protocol) also uses tunnel ID to identify coexisting tunnels.
• SPI used in IPSec ESP protocol is a 32-bit identifier that bounds a security association to a packet. This is used to demultiplex inbound traffic at the receiver’s end.
• QUIC uses connection ID

Others can rely on sequence numbers as counters or even destination address mappings to identify the path/stream. However, these approaches have many limitations. Most protocols would try to attach a new custom field.

More description on some encapsulating protocols

Secure Shell (SSH )

While ssh is not generally thought of as a tnunneling protocol , it does create a communicaion link for remote access and file transfer to happen securly. Hence forming the crux of what is considered a VPN functionality.

Encapsulating protocols at Network Layer

IP in IP

As IPV4 in IPv4 , IPV4 in IPv6 , IPv6 in IPv4 , and IPv6 in IPv6, are most commonly used for network virtualization ( VPN) and other kinds of Network as service such as Secure Access Service Edge (SASE).

Multiprotocol Label Switching (MPLS)

MPLS can transport IP packets ( IPv4 and IPv6) over IPv4 backbone.Orignally design for forwarding and routing, instead of trraditional IP based routing MPLS uses packet labels to make next hop routing decisions. This enables creation of paths based on QoS. In contrast to ESP which is applied at layer 3, MPLs operated at layer 2.5( between layer 2 and 3).

ESP (Encapsulating Security Payload)

ESP, part of the IPSec suite, enables confidentiality, integrity, and authenticity for IP packets it encapsulates. ESP header contains

• SPI ( Security Parameter Index) to links SA ( security association) with an endpoint
•  Sequence number, which is a counter to prevent a replay attack
•  payload type can be encrypted or plain
• followed by the Next header, which specifies the type of original IP packet in the payload.

ESP can operate in transport mode (protecting the payload of an IP packet) or tunnel mode (protecting the entire IP packet).

Generic IP packet

	Transport Mode	Tunnel Mode
Authetication Header
ESP

Without considering encryption or authentication overhead, the basic ESP header is 8 bytes in size. The ESP H( header) is realitively smaller in transport mode than in tunnel mode.

IPV4
IPv6

	Transport Mode	Tunnel Model
IPv4
IPv6

Encapsulating protocols at Transport Layer

TLS and Datagram Transport Layer Security (DTLS)

While TLS is designed for TCP, DTLS securily encapsulates datagrams over UDP. In contrast to ESP which encapsulates traffic for VPN usecases , DTLS is mostly used to encapsulate real time data traffic suhc as in WebRTC, gaming.

Generic Routing Encapsulation (GRE)

Another layer 4 tunneling protocol is GRE. It is protocol agnostic to layer 3 payloads as in it can tunnel any layer 3 protocol from IPv6, IPv4 to other raw formats. The “Protocol Type” fiels in GRE header specifies the protocol type of the encapsulated packet. GRE has a minimal header structure with no out of box security such as encrytion.

QUIC

QUIC encapsulates higher-layer protocols, such as HTTP/3, within its own transport layer over UDP. Besides efficient multiplexing, encryption , QUIC also excels at migration and quick handshakes.

In contrarst to ESP , while ESP is part of IPSec suite of protocol aimed at lower underlay layer tunnleing, QUIC is aimed at application data encapsulation like web traffic and leverages UDP itself , appendning its own header with control information.

Note that MASQUE is another enacpsulation protocol build over QUIC. As these are still nascent and eveolving I will update this section as more specificatiosn are standardised.

TCP encapsulation

Many network middleboxes that filter traffic on public hotspots block all UDP traffic. As a result, UDP traffic, such as media streams for VoIP calls or even IKEv2 UDP packets, gets blocked. But middleboxes are likely to allow TCP connections through because they appear to be web traffic

• (+) provides NAT support
•  (+) Avoids UDP fragmentation
•  (-) overhead of TCP or TLS

While designing a TCP-based encapsulation, it is recommended that Initiators should only use TCP encapsulation when traffic over UDP is blocked. TCP can leverage the streams over a single TCP connection to send data across. This way, any firewall or NAT mappings allocated for the TCP connection apply to all of the traffic associated with the encapsulated packet. This prevents large number of roundtrips.

Subtle points of using encapsulation

In addition to encapsulation overhead and reachability, the following are concerns that occur in encapsulating the data and traversing through a complex network.

Path MTU and fragmentation

Path MTU discovery messages such as ICMP can be blanket blocked by firewalls, which prevents proper MTU from being set for the encapsulated and overall packet. Subsequently, the MTU of the endcap packet may exceed the path MTU, leading to fragmentation, leading to

• latency in transmission
• undecipherable or unroutable packets by middleboxes / VPN hubs
• Fragmented packets received may be unprocessable or not be able to be disassembled properly, which is countered by packet loss, leading to retransmission and further congestion.

Migration of inner payload from one to another protocol

For IPv4 encapsulating other IPs in a dual-stack implementation, sometimes the destination can decide to upgrade, such as from IPv4 to IPv6. The upgrade involves periods of simultaneously using IPv4 and IPv6 and then a gradual transition towards IPv6. The key differenece between the IPv4 and IPv6

• header size which is 20 bytes and 40 bytes for IPv4 and IPv6 repectively.
• only IPv4 supports fragmenetation
• IPv4 has nique adddress space thus NAT is not needed as much as with limited addressing of IPv4

With migration ineffect on a dual stack impact on as the overlay depends on the underlay protocols ability to carry its traffic. For example in IPv6 over IPv4, as IPV4 underlays are well adopted in network infrastructure, original payload packets with ipv6 header use the ipv4 as encapsulating packet IP to carry accross the tunnel. BGP and OSPF are common routing and forwrading protocols for a IPv4 underlay network.

Prioritization and congestion post encapsulation

Many network middleboxes ( routers, cloud firewalls, gateways, and so on ) implement traffic filtering, shaping, or queue management based on prioritization( AQM at ISPs). Due to the masked nature of encapsulated packets, there is a high chance of the middleboxes not being able to ascertain their identity and, thus, making it deprioritized.

Misordering

To still keep the endpoints connected, the packets thus need to be put in the correct order with manageable latency at the receiving endpoint. This is especially critical for encapsulating packets for low-latency applications. For example, for video codec, a keyframe encapsulated packets arriving late could affect all subsequent packets to wait in the receiver buffer. This cascaded into a downward spiral of sending selective acknowledgments, retransmission, and discarding arrived packets, which can further intensified the problem.

Loss of ECN signal

Some systems overcome this by copying the ECN header from the inner header of the original packet to the outside headers. However, this needs to be a mutable field as the packet traverses through the many nodes of a large network. This is not protected by the integrator algorithms, and thus, for the risk of being misused, once a feature, this is now dropped by the updated specifications of many encapsulating protocols, such as IPsec.

Classification and tagging

Classification and tagging of traffic within a stream of encapsulated packets is also a challenge. The payload of the encapsulated packets could contain mixed content that cannot be tagged to any specific class, which can be used to prioritize real-time or critical traffic. For example, DSCP tag propagation from inner to outer packets can help in this direction but runs the risk of traffic profiling by middleboxes.

State Synchronization in Multipath

Scaling to involve multiple streams in a session using encapsulation poses challenges. This problem is further amplified in the case of multi-sender and multi-receiver scenarios.

Applying policies

For a stateful, contextual, and intelligent decision-making process, a sender needs to leverage the multiple available paths. It needs to discover alternate reachable paths and collect and sync network metrics to use the resources matching the needs of time sensitivity, cost, etc.

Anti-replay window synchronization

Difficulty in synchronizing anti-replay windows when multiple paths are involved impacts load-sharing encapsulated traffic. Additional issues may involve multicore or distributed operations.
A short-term solution to Sync issues is to have a very large Anti-replay window. Patching this with a short-term change of making the anti-replay window too big increases the possibility of packets being too far in sequence, which further leads to unpredictability in ordering. In high throughput scenarios, it may even be difficult for the CPU to keep the state in cache for an immensely large window size, thus causing undue latency penalties.

Protocol Design for an encapsulating protocol

Traffic Fow confidentiality ( TFC)

Primarily, an encapsulating protocol needs to make the traffic from outside visibility, which can be done by rewriting the source destination information as well as encrypting and/or padding the payload so as to not make it intelligible to middleboxes. Also mentioned in RFC 4303 for ESP in Tunel mode.

Dummy Data : Other means to secure confidentiality could be to use dummy packets or even dummy streams.

Segmentation of information into header and trailer

• Avoid leaking information on the payoad
• enable reassembly in case of fragmentation

Dynamically adjustable anti-replay window sizes

A smaller window is faster to process and secure but inapplicable to multi legged session, while a large window has a performance impact and can jeopardize the security of replays. By implementing a dynamically sized sliding window, the protocol can keep up the instantaneous requirements of the Network, such as keeping the window large for higher packet loss but also compressing the window size when the traffic latency-sensitive and out-of-sequence is intended to be discarded.

• multiple replay windows for multiple paths
• Synchronize sequneces with minial communication between the threads

Security constraints

Enabling multiple child SAs to be linked to a session is one way to overcome both multipath and antireplay issues mentioned above. The multiple children SAs in a parent SA can be thought of as representing a child tunnel inside a parent tunnel as it enables uniquely identifying and maintaining each SA-associated path with SPI-based identification. This leads to no overhead in synchronizing sequence numbers for ordering in case of multipath or multicore. Such concepts have been proposed in a few IETF drafts using different terminologies, such as sub-tunnel, cluster-tunnel, etc

References :

• https://en.wikipedia.org/wiki/6in4
• https://datatracker.ietf.org/doc/html/rfc4303
• https://datatracker.ietf.org/doc/html/rfc6040

A multihoming protocol maintains a simultaneous connection to multiple networks. Such a protocol enhances reliability, load balancing, and fault tolerance and makes an excellent candidate for signaling planes, which are lightweight packets managing the connection for the data plane. Dataplane acts as the actual data transfer protocol, which can be for multimedia such as audio-video content, games, streaming, and so on. Multihoming can be implemented at several levels of the network stack.

Low Layer Multihoming

While lower layers of the network stack do not generally have the logic to maintain statefulness and decision-making, they can still leverage multiple paths efficiently to provide redundancy and increased BDP.

Link Aggregation Control Protocol (LACP), an IEEE standard and part of the IEEE 802.3ad specification, bundles individual physical links of Ethernet connections into one logical link to increase throughput using multiple NICs.

Layer 3 Network Layer multihoming

BGP can be considered an example of multihoming since it process multiple paths via logical addressing and sets up the routes.

IP multihoming : Virtual Router Redundancy Protocol (VRRP) and Hot Standby Router Protocol (HSRP) enable routers to share IP and MAC address.

Layer 4 Transport layer multihoming

Some protocols simultaneously use these multiple paths for a single communication session such as Multi-path TCP. This can be used to improve bandwidth utilization ( sometimes unfairly) and build resilience. While simultaneous usage of multiple links/ paths provides great resilience, they can lead to asymmetrical routing issues.

SCTP (Stream Control Transmission Protocol) is another example of a transport layer protocol that provides connection-oriented reliable communication while having multiple IP addresses and interfaces. With multiple paths dynamically added, the SCTP session can switch from one path to another in the event of a failover or can load balance between paths.

Higher Layer Multihoming techniques

AnyCast is a networking technique that lets multiple endpoints share the same IP and dynamically select the best destination path.

SIP Forking is an application layer technique to have multiple VoIP endpoints receive an incoming call either parallelly or sequentially. The first SIP phone to answer the calls establishes the connection.

Equal-cost multipath (ECMP) is a routing technique that allows routers to distribute traffic across multiple equal-cost paths. This is often associated with OSPF (Open Shortest Path First) like implementations.

Best Path Selection among multiple paths

Selection of the best path and routing decision in a multihomed scenario can be made by :

FIFO or Round Robin

The first path to respond can be selected first to establish a connection in FIFO, while Round Robin can select paths in order of packet arrival to prevent starvation of a path.

Weights ( predetermined or dynamically allocated)

BGP can help provide weight and preferences to paths while exchanging routing and reachability. For example, AS( Autonomous systems ) that connect to multiple ISPs use BGP to advertise their IP prefixes through each link.

Prioritization algorithms

In an anycast scenario, where the same address is assigned to multiple destinations, the traffic can be assigned to the geographically nearest, shortest RTT, or best-performing path. For example, to manage ingress traffic to a service across multiple data centers. A more sophisticated algorithm can also add compound metrics such as a derivative of loss, jitter, etc.

Cost and load balancing are often top considerations for path selection. The more complex decisions can be based on instantaneous Qos collected or even forecasted. Resource utilization or carbon footprint is also a candidate for path selection. A fairness-based approach can also be built in to avoid starvation.

Mobility management

Mobility management has been long used to provide network continuity. From telecom devices’ handover between base stations ( home network and visitor network ) to mobile IPv6 ( via home agent and Foreign agent), mobility is crucial to meet the needs of mobile devices for seamless connectivity.

In cases of session-based protocols, when the source IP changes after an established connection, the mobility of the protocol should kick in to discover and migrate to another reachable address for the endpoint. This is especially crucial in the case of wireless networks and mobile devices. Examples of such cases may be

• when NATing changes and a host receives a new IP address.
•  A device with multiple interfaces or uplinks decides to tear down one of the interfaces to uplink and migrate to another one.
•  A user on a call travels through multiple networks, so the call is handed over from mobile data to wifi, etc.
•  Switching between ipv4 and ipv6 address

A mobility management protocol should be able to seamlessly update the existing sessions endpoint IP address without re-establishing all of the security protocol or handshakes or using a minimal subset of it.

MultiPath protocol design

To design a multipath protocol with multihoming and seamless session migration, any available network metrics and topologies should be identified. These help build mechanisms for discovery and selection. Multipath management is stateful, and the states are utilized to identify degradation, plan migration, and recovery. Multihoming protocol design can be divided into the following parts

Service discovery

The network endpoint needs to detect the presence of multiple paths to a common destination, such as a server. This can be achieved by gaining the link state information at the router, preferred policies and static routes, feedback packets sharing path alternatives, Hello’s, ICMP, or other monitoring techniques. Address Resolution Protocol(ARP), IPv6 Neighbor Discovery, and Neighbor Unreachability Detection are also instances of path discovery.

A successful discovery is followed by routability checks, which involve checking if a BGP session is established. If it is not, then check the advertised IP prefix by each link. At this stage, reviewing the routing table at the hub( or router) to ensure the entries corresponding to each IP prefix point to a valid next-hop address is also an option. Tools like ping and traceroute can be used to confirm that the packets can reach the multihomed network through each link.
This prevalidation leads to quick convergence from old to new path in case the network conditions change, and this avoids blackholing traffic and downtime.

Unique Identifiers

DHCP, a client-server protocol, assigns addresses dynamically to devices as they get joined to a network. Even with rapid network changes, DHCP automates the address assignment from a pool and even relays across subnets. Since the IPV4 address is not necessarily unique across networks (32 bits), a different UUID ( 128 bits) is needed to be generated per endpoint. In the case of IPv6-enabled endpoints, the IPv6 address itself can serve as a unique identifier.

Path / Route and Network identifiers

To identify migration from one network to another, it is important to address each network uniquely. While the details of most ISP infrastructure itself cannot be determined by analyzing a packet that traversed it, other means of analysis can help narrow the choices, such as IP address ranges and DNS resolutions. TTL ( Time to Live) and RTT (Round Trip Time) can also help make inferences on physical distance. Fragmentation and filtering can help narrow its behavior and policies. For all different kinds of networks identified between a common source and destination, there should be a unique identifier to address the paths. Network identifiers can be in the form of

• Link-layer identifiers for an interface include IEEE 802 addresses on Ethernet links.
• subnet prefixes, CIDR
• Gateway identification
• home address/care of address in mobile ipv6
• Index serialization 
• UUID generated from its characteristics so on

Append the router’s address to an array of path identifiers. Such a prefix helps to identify the path. Example

• SIP via header Via: SIP/2.0/UDP client.atlanta.com:5060;branch=z9hG45684bf9
• SIP Route header : <sip:proxy1.atlanta.com;lr>, <sip:proxy2.atlanta.com;lr>

Some techniques also rely on cookies to identify the route

Header metadata

In addition to the network identifiers themselves, there are more metadata that need to be part of the payload or the encapsulating header to determine that the packet is traversing the appropriate source and destination. This can be in the form of the following:

• unique pair of ip and port + optional magic number for NAT
•  tuple of transport type, ip, and port
•  unique ID derived from timestamp, ip , port, etc

Pre – Registration

As a mobile node detects a new network it registers its current location with the network. This can be in form of authentication as a mobile node enters a network of sending its presence with pub/sub notification. Example :

• SIP registration
• acknowlege message for a new init
• hello handshake

Handover / Failover from one path to another without disruption

A shift from one network to another can be triggered by various factors such as signal strength, load balancing, or network congestion. The decision to move over to a new network may also be gauged by algorithmically analyzing signal quality, interference, performance metrics, or cost and usage.
L2 handover: Change in link layer connection such as disconnecting from a wireless access point and connecting to another. Another example of mobility management is the telecom network handover, which re-established link-layer connectivity instead of relying on upper layers to reconnect.
L3 handover: change of router to which the mobile node is connected to.
Assuming endpoint 1 of the session has M addresses and another endpoint, i.e., endpoint 2 has an N address, then the connection should be able to migrate between any one of the M*N address pairs.

Security association for paths

Although more related to IPsec tunnels, SAs( security associations) in this context refer to cryptographic certainty that the endpoints are authorized and authenticated. SA uses nonce to randomize the keygen tokens. Additionally, there is anti-replay and rekeys in place to detect if there is possible interference in the communication link. A successful security association should display that the binding is successful and the endpoints are now allowed to transfer data or establish a tunnel to transfer encapsulated encrypted dat

Token based validity : A token, often generated by nonce and session’s unique parameters, is often used to validate intermediate messages without having to cross-confirm every packet with the home network or profile database

ESP Header : In cases of encapsulated packets like Encapsulating Security Payload (ESP), a not null payload authentication header can provide information on the authenticity of the origin.

Pre – Registration / Validation : As a mobile node detects a new network, it registers its current location with the network. This can be in the form of authentication as a mobile node enters a network by sending its presence with pub/sub notification. Example: SIP registration, child SAs for various paths in IPSec

References :

• IKEv2 Mobility and Multihoming Protocol (MOBIKE) https://datatracker.ietf.org/doc/html/rfc4555
• IP mobility https://datatracker.ietf.org/doc/html/rfc3344
• Mobility Support in IPv6 https://datatracker.ietf.org/doc/html/rfc3775

Key components of Low latency streaming include systems that can support second or even subsecond latency. To achieve this a system should have

• Low latency encoders on edge devices, ideally <100ms processing + small Rx buffers
• Global distribution with many pop ( point of presence) at ideally ~50ms from user. Anycast routing works best for lowest latency
• Stateless protocols / soft state session tracking
• Fast codecs on fast transport as UDP

Designing a low-latency streaming protocol and platform involves overcoming significant technical challenges across multiple layers of network stack.

NTP Synchronization and measuring Latency

As latency is critical to maintaining a good Qos in glass to glass streaming and also to implement congestion control, it is critical to measure latency as precisely as possible.

A NTP Time server  measures the number of seconds that have elapsed since January 1, 1970. NTP time stamp can represent time values to an accuracy of ± 0.1 nanoseconds (ns). In RTP spec it is a 64-bit double word where top 32 bits represent seconds, and the bottom 32 bits represent fractions of a second. For measuring latency in RTP however NTP time server is not used, instead the audio capture clock forms the basis for NTP time calculation.

RTP/(RTP sample rate) = (NTP + offset) x scale

The latency is then calculated with accurate mappings between the NTP time and RTP media time stamps by sending RTCP packets for each media stream.

Latency can be induced at various points in the systems

1. Transmitter Latency in the capture, encoding and/or packetization
2.  Network latency including gateways, load balancing, buffering
3.  Media path having TURN servers for Network address traversal, delay due to low bandwidth, transcoding delays in media servers.
4.  Receiver delays in playback due to buffer delay, playout delay by decoder due to hardware constraints

The delay can be caused by one or many stages of the path in the media stream and would be a cumulative sum of all individual delays. For this reason, TCP is a bad candidate due to its latency incurred in packet reordering and fair congestion control mechanisms. While TCP continues to provide signaling transport, the media is streamed over RTP/UDP.

Latency reduction

Although modern media stacks such as WebRTC are designed to be adaptable for dynamic network condition, the issues of bandwidth unpredictability leads to packet loss and eventually low Qos. Effective techniques to reduce latency :

• Dynamic network analysis and bandwidth estimation for adaptive streaming ensure low latency stream reception at the remote end.
• Silence suppression: This is an effective way to save bandwidth
  • (+) typical bandwidth reduction after using silence suppression ~50%
• Noise filtering and Background blurring are also efficient ways to reduce the network traffic 
• Forward error correction or redundant encoding, techniques help to recover from packet loss faster than retransmission requests via NACK 
• Increased Compression can also optimize packetization and transmission of raw data that targets low latency
• Predictive decoding and end point controlled congestion

Ineffective techniques that do not improve QoS even if reduce latency 

• minimizing headers in every PDU: Some extra headers such as CSRC or timestamp can be removed to create RTPLite but significant disadvantages include having to functionalities using custom logic as
  • (-) removing timestamp would lead to issues in cross-media sync ( lip-sync) or jitter, packet loss sync
  • (-) Removing contributing source identifiers (SSRC ) could lead to issues in managing source identity in multicast or via media gateway.
• Too many TURN, STUN servers and candidates collection 
• lowering resolution or bitrate may achieve low latency but is far from the hi-definition experience that users expect.

Lip Sync ( Audio Video Synchronization)

Many real time communication and streaming platforms have separate audio and video processing pipelines. The output of these two can go out of sync due to differing latency or speed and may may appear out of sync at the playback on receivers end. As the skew increases the viewers perceive it as bad quality.

According to convention, at the input to the encoder, the audio should not lead the video by more than 15 ms and should not lag the video by more than 45 ms. Generally the lip sync tolerance is at +- 15 ms.

Synchronize clocks

The clock helps in various ways to make the streaming faster by calculating delays with precision

• NTP timestamps help the endpoints measure their delays.
• Sequence numbers detect losses as it increases by 1 for each packet transmitted. The timestamps increase by the time covered by a packet which is useful for correcting timing order, playout delay compensation etc.

To compute transmission time the sender and receiver clocks need to be synchronized with milliseconds of precision. But this is unlikely in a heterogeneous environment as hosts may have different clock speeds. Clock Synchronization can be achieved in various ways

1. NTP synchronization : For multimedia conferences the NTP timestamp from RTCP SR is used to give a common time reference that can associate these independant timesatmps witha wall clock shared time. Thei allows media synchronization between sender in a single session. Additionally RFC 3550 specifies one media-timestamp in the RTP data header and a mapping between such timestamp and a globally synchronized clock( NTP), carried as RTCP timestamp mappings.

2. MultiCast synchronization: receivers synchronize to sender’s RTP Header media timestamp

• (-) good approach for multicast sessions

3. Round Trip Time measurement as a workaround to calculate clock sync. A round trip propagation delay can help the host sync its clock with peers.

roundtrip_time = send timestamp - reflected timestamp
tramission_time = roundtrip_time / 2

• (-) this approach assumes equal time for sending and receiving packet which is not the case in cellular networks. thus not suited for networks which are time asymmetrical.
• (-) transmission time can also vary with jitter. ( some packets arrive in bursts and some be delayed)
• (-) subjected to packet loss

4. Adjust playout delay via Marker Bit : Marker bit indicates beginning of talk spurt. This lets the receiver adjust the playout delay to compensate fir the different click rates between sender and receiver and/or network delay jitter.

Receivers can perform delay adaption using marker bit as long as the reordering time of market bit packer with respect to other packets is less than the playout delay. Else the receiver waits for the next talkspurt.

Similar examples from WebRTC RTP dumps

Congestion Control in Real Time Systems

Congestion is when we have reached the peak limit the network can support and path can handle. There could be many reasons for congestion as limits by ISP, high usage at certain time, failure on some network resources causing other relay to be overloaded so on. Congestion can result in

• dropping excess packets => high packet loss
• increased buffering -> overloaded packets will queue and cause erratic delivery -> high jitter
• progressively increasing round trip time
• congestion control algorithms send explicit notification which trigger other nodes to activate congestion control.

A real time communication system maybe efficient performing encoding/decoding but will be eventually limited by the network. Sending congestion dynamically helps the platform to adapt and ensure a satisfactory quality without losing too many packet at network path. There has been extensive research on the subject of congestion control in both TCP and UDP transports. Simplistic methods use ACK’s for packet drop and OWD (one way delay) to derive that some congestion may be occurring and go into avoidance mode by reducing the bitrate and/or sending window.

UDP/RTP streams have the support of well designed RTCP feedback to proactively deduce congestion situation before it happens. Some WebRTC approaches work around the problem of congestion by providing simulcast , SVC(Temporal/frame rate, spatial/picture size , SNR/Quality/Fidelity ) , redundant encoding etc. Following attributes can help to infer congestion in a network

• increasing RTT ( Round Trip Time)
• increasing OWD( One Way Delay)
• occurance of Packet Loss
• Queing Delay Gradient = queue length in bits / Capacity of bottleneck link

Feedback loop

A feedback loop between video encoder and congestion controller can significantly help the host from experiencing bad QoS.

MTU determination

Maximum transmission Unit ( MTU) determine how large a packet can be to be send via a network. MTU differs on the path and path discovery is an effective way to determine the largest packet size that can be sent.

RTCP Feedback

To avoid having to expend on retransmission and faulty gaps in playback, the system needs to cumulatively detect congestion. The ways to detect congestion are looking at self’s sending buffer and observing receivers feedback. RTP supports mechanisms that allow a form of congestion control on longer time scales.

Resolving congestion via RTCP

Some popular approaches to overcome congestion are limiting speed and sending less

• Throttling video frame acquisition at the sender when the send buffer is full
• change the audio/video encoding rate
• Reduce video frame rate, or video image size at the transmitter
• modifying the source encoder

The aim of these algorithms is usually a trade-off between Throughout and Latency. Hence maximizing throughout and penalizing delays is a formula use often to come up with more modern congestion control algorithms.

• LEDBAT
• NADA ( Network Assisted Dynamic Adaption) which uses a loss vs delay algorithm using OWD,
• SCREAM ( Sefl Clocked Rate Adaptation for multimedia)
• GCC ( google congestion control) uses kalman filter on end to end OWD( one way delay) and compares against an adaptive threhsold to throttle the sending rate.

Transport Protocol Optimization

A low latency transport such as UDP is most appropriate for real time transmission of media packet, due to smaller packet and ack less operation. A TCP transport for such delay sensitive environments is not ideal. Some points that show TCP unsuited for RTP are :

• Missing packet discovery and retrasmission will take atleast one round trip time using ack which either results in audible gap in playout or the retransmitted packet being discarded by altogether by decoder buffer.
• TCP packets are heavier than UDP.
• TCP cannot support multicast
• TCP congestion control is inapplicable to real time media as it reduces the congestion window when packet loss is detected. This is unsuited to codecs which have a specific sampling like PCM is 64 kb/s + header overhead.

Fasten session establishment

Lower layer protocols are always required to have control over resources in switches, routers or other network relay points. However, RTP provides ways to ensure a fast real-time stream and its feedback including timestamps and control synchronization of different streams to the application layer.

1. Mux the stream: RTP and RTCP share the same socket and connection, instead of using two separate connections.

• (+) Since the same port is used fewer ICE candidates gathering is required in WebRTC.

2. Prioritize PoP ( points of presence) under quality control over open internet relays points.

3. Parallelize AAA ( authentication and authorization) with session establishing instead of serializing it.

Trade-Off of Latency vs Quality

To achieve reliable transmission the media needs to be compressed ( made smaller) which may lead to loss of certain picture quality.

Lossy vs Lossless compression

Loss Less Compression will incur higher latency as compared to lossy compression.

Intra frame vs Inter frame compression

Container Formats for Streaming

Some time ago Flash + RTMP was the popular choice for streaming. Streaming involves segmenting a audio or audio inot smaller chunks which can be easily transmitted over networks. Container formats contain an encoded video and audio track in a single file which is then streamed using the streaming protocol. It is encoded in different resolutions and bitrates. Once received it is again stored in a container format (MP4, FLV).

ABR formats are HTTP-based, media-streaming communications protocols. As the connection gets slower, the protocol adjusts the requested bitrate to the available bandwidth. Therefore, it can work on different network bandwidths, such as 3G or 4G.

TCP based streaming

• (-) slow start due to three way handshake , TCP Slow Start and congestion avoidance phase
• (+) SACK to overcoming resending the whole chain for a lost packet

UDP based streaming

One of the first television broadcasting techniques, such as in IPTV over fibre with repeaters , was multicast broadcasting with MPEG Transport Stream content over UDP.  This is suited for internal closed networks but not as much for external networks with issues such as interference, shaping, traffic congestion channels, hardware errors, damaged cables, and software-level problems. In this case, not only low latency is required, but also retransmission of lost packets.

• (-) needs FEC for overcoming lost packets which causes overheads

Real-Time Messaging Protocol (RTMP)

Developed by Macromedia and acquired by Adobe in 2005. Originally developed to support Flash streaming, RTMP enables segmented streaming. RTMP Codecs

• Audio Codecs: AAC, AAC-LC, HE-AAC+V1 and V2, OPUS, MP3, SPEEX, VORBIS
• Video Codecs: H.264, VP6, VP8

RTMP is widely used for ingest and usually has latency ~5s. RTMP works on TCP using default port 1935. RTMP uses UDP by replaced chunked stream. It has many variations such as

• (-) HTTP incompatible.
• (-) may get blocked by some firewalls
• (-) delay from 2-3 s , upto 30 s
• (+) multicast supported
• (+) Low buffering
• (-) non support for vp9/HEVC/AV1
• (-) Medium latency 2-5s

RTMP forms several virtual channels on which audio, video, metadata, etc. are transmitted.

RTSP (Real-Time Streaming Protocol)

RTSP is primarily used for streaming and controlling media such as audio and video on IP networks. It relies on external codecs and security. It is not typically used for low-latency streaming because of its design and the way it handles data transfer. RTSP uses TCP (Transmission Control Protocol) as its transport protocol. This protocol is designed to provide reliability and error correction, but it also introduces additional overhead and latency compared to UDP.
RTSP cannot adjust the video and audio bitrate, resolution, and frame rate in real-time to minimize the impact of network congestion.

• (-) legacy requires system software
• (+) often used by Surveillance system or IOT system with higher latency tolerance
• (-) mostly compatible with android mobile clients

LL ( Low Latency) – HTTP Live Streaming (HLS)

While traditional HLS has large chunk of segments 6-10 seconds, LLHLS has 3-5 seconds or less. Additionally LLHLS also has partial segments which allow HTTP player to play them before full segment is received. Additionally leveraging HTTP2 and HTTP3 makes LLHLS even faster and better in performance, allowing faster switching in quality.

HLS can adapt the bitrate of the video to the actual speed of the connection using container format such as mp4. Apple’s HLS protocol used the MPEG transport stream container format or .ts (MPEG-TS)

• Audio Codecs: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, FLAC, Apple Lossless
• Video Codecs: H.265, H.264

The sub 2 second latency using fragmented 200ms chunks .

• (+) relies on ABR to produce ultra high quality streams
• (+) widely compatible even HTML5 video players
• (+) secure with HTTPS and DRM ( Digital Rights Management)
• (-) higher latency ( sub 2 second) than WebRTC
• (-) propertiary : HLS capable encoders are not accessible or affordable

MPEG -DASH

MPEG DASH (MPEG DASH (Dynamic Adaptive Streaming over HTTP)) is primarily used for streaming on-demand video and audio content over HTTP. A HTTP based streaming protocol by MPEG, as an alternative to HLS. While MPEG is an open standard, HLS is widely used by apple devices.

MPEG-DASH and HLS are much similar as both protocols run over HTTP, use TCP as their transport protocol, breaking video into segments with an accompanying manifest index file, and offer adaptive bitrate streaming. MPEG-DASH uses .mp4 containers as HLS streams are delivered in .ts format.

MPEG DASH uses HTTP (Hypertext Transfer Protocol) as its transport protocol, which allows for better compatibility with firewalls and other network devices, but it also introduces additional overhead and latency, hence unsuitable for low latency streaming

• (+) supports adaptive streaming (ABR)
• (+) open source
• (-) incompatible to apple devices
• (-) not provided out of box with browsers, requires system software for playback
• (-) high latency ~10-30s

WebRTC (Web Based Real Time Communication)

Low latency is imperative for use cases that require mission-critical communication such as the emergency call for first responders, interactive collaboration and communication services, real-time remote object detection etc. Other use cases where low latency is essential are banking communication, financial trading communication, VR gaming etc. When low latency streaming is combined with high definition (HD) quality, the complication grows tenfold. Some instance where good video quality is as important as sensitivity to delay is telehealth for patient-doctor communication.  WebRTC is the most used p2p Web bsed streaming with sub second latency. Inbuild Latency control. However it is not suited to multicast streaming usecases.

Transport protocol

WebRTC uses UDP as its transport protocol, which allows for faster and more efficient data transfer compared to TCP (Transmission Control Protocol). UDP does not require the same level of error correction and retransmission as TCP, which results in lower latency.

P2P (Peer-to-Peer) Connections

WebRTC allows for P2P connections between clients, which reduces the number of hops that data must travel through and thus reduces latency. WebRTC also use Data channel API which can transmit data p2p swiftly such as state changes or messages.

Choice of Codecs

Most WebRTC providers use vp9 codec ( successor to vp8) for video compression which is great at providing high quality with reduced data.

Network Adaptation

WebRTC adapts to networks in realtime by adjusting bitrate, resolution, framework with changes in networks conditions. This auto adjusting quality also helps WebRTC mitigate the losses under congestion buildup.

• (+) open source and support for other open source standardized techs such as Vp8, Vp9 , Av1 video codecs , OPUS audio codec. Also supported H264 certain profiles and other telecom codecs
• (+) secure E2E SRTP
• (-) evolving still

CMAF (Common Media Application Format)

Format to enable HTTP based streaming. It is compatible with DASH and HLS players by using a new uniform transport container file. Apple and Microsoft proposed CMAF to the Moving Pictures Expert Group (MPEG) in 2016 . CMAF features

• (+) Simpler
• (+) chunked encoder and chunked transfer
• (-) 3-5 s of latency
• (+) increases CDN efficiency

CMAF Addressable Media Objects : CMAF header , CMAF segment , CMAF chunk , CMAF track file. Logical components of CMAF

• CMAF Track: contains encoded media samples, including audio, video, and subtitles. Media samples are stored in a CMAF specified container. Tracks are made up of a CMAF Header and one or more CMAF Fragments.
• CMAF Switching Set: contains alternative tracks that can be switched and spliced at CMAF Fragment boundaries to adaptively stream the same content at different bit rates and resolutions.
• Aligned CMAF Switching Set: two or more CMAF Switching Sets encoded from the same source with alternative encoding; for example, different codecs, and time aligned to each other.
• CMAF Selection Set: a group of switching sets of the same media type that may include alternative content (for example, different languages or camera angles) or alternative encoding (for example,different codecs).

CMAF Presentation: one or more presentation time synchronized selection sets.

Ref :

• BufferBloat: What’s Wrong with the Internet?A discussion with Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys
• RTSP
  • https://datatracker.ietf.org/doc/html/rfc7826
• SRT
  • SRT wikipedia https://en.wikipedia.org/wiki/Secure_Reliable_Transport
  • https://github.com/Haivision/srt/
• CMAF
  • http://www.reznik.org/papers/PeckR_BEITC2019.pdf

Fluctuating Networks

WebRTC has build in capabilities to detect network glitches and adapt itself to changing situations. Some of the methodologies used are listed below.

Dynamic Bandwidth estimation

Bandwidth are dependent on network strength and is affected by the other users on the network. Under hetrogenious network conditions Bandwidth estimation is a critical step to improve call quality and end user exeprince.

JitterBuffer

An unreliable network / fluctiating one will cause some packets to be delivered on time and some to be delayed more thn others, causing them to come in bursts. JitterBuffer is an effective methodology for Jitter management which ensures a steady delivery of apckets even when the peers transmit at flucting rates.

A jitter buffer is a buffer that consumes packets as soon as they arrive and keep them untill the frame can be fully reconstructed. At the point when all apckets have bee filled in buffer ( in any order ) it emiits it for decoding which the play can playback to user. Note that serveral RTP packet can have the same timestamp is they are part of the same video frame.

• (+) dynamically manages unordered packets and reconstrcts a frame after accumulating all packets
• (-) can introduce latency for packets that arrive early
• (-) Need active resisizing by means of feedback
  • for hi speed and goog network jitterbuffer can ve small sized
  • for congested and disruptive networks it is better to keep a longer buffer which can also add some latency
• (-) buffer has limited capacity so the packet can expire if not received within a duration “jitterBufferDealy”.

SDP renegotiation

-TBD

Demand for High Quality Video

Applications telehealth, advertising or broadcasting on WebRTC media streams

Tradeoff between Latency vs Quality

Reduced resolution, framerate, bit rate are effective for congestion control however not suited to the case of High defintaion video conferecing such as gaming , telehealth of broadcast of concert as it may hinder with user experience.

Layering for adaptive streaming

using the I-frame , P-frame and B frame efficiently in the codec combines with predictive machine learning models make packet loss unnoticible to the human eye. Marker ( M bit) in the RTP packet structure marks keyframes.

• (-) more complex compression algorithms

Better compression algorithms vs CPU compute

A better performing compression algorithm produces fewer bits to encode the same video quality as its predecessor.

• (-) Higher performing compression engines most always has higher energy consumption and carbon footprint
• (+) resilent to network fluctuations

Full INTRA-frame Request (FIR)

Requests a key frame to decode the frame. Can be used when a new peer joins the conference a key frane is required to start decoding its video strea,.

Picture Loss Indication (PLI)

Partial frames given to decoder are unprocessable, then PLI message is send to the sender. As the sender receives pli message it will produce new I-frames to help the reciver decore the frames.

a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100

Redundant Encoding (RED) in Media Packets

Recovers packet loss under lossy networks by adding extra bits of information in following packets.

• (+) good for unpredictable networks

LBRR ( low bit-rate redundancy) – tbd

Congestion

Congestion is created when a network path has reached its maximum limits which could be due to

• failures(switches, routers, cables, fibres ..)
• over subscription and operating at peak bandwidth.
• broadcast storms
• Inapt BGP routing and congestion detection
• BGP is responsisble for finiding the shortest routable path for a packet

The direct consequences of congestion for any network transport can be

• High Latency
• Connection Timeouts
• Low throughput
• Packet loss
• Queueing delay

With respect to WebRTC streams too, if a network has congestion, the buffer will overflow and packets will be droppped. Due to excessive dropping of packets both transmission time and jitter increases.To overcome this adaptive buffereing is used as jitter increases or decreases.

Feedback Loop

A congestion notifier and detection algorithm can analyze the RTCP metrics for possible congestion in the network route and suggest options to overcome it. Part of Adaptive Bitrate and Bandwidth Estimation process.

Overcome congestion with lower bitrate

Rate limiting the sending information is one way to overcome congestion, even though it could lead to bad call quality at the reciver’s end and non typical for realtime communciation systems

Reduce frame quality and resolution

Congestion control Algorithms : Google Congestion Control ( GCC)

Bandwidth estimation and congestion control are ofetn paird in as a operational unit. Primarily packet loss and inter packet arrival times drives the bandwidth estimation and enable GCC to flagcongestion.

• On the receiver side TMMBR/TMMBN (Temporary Maximum Media Stream Bit Rate Request/Notification) and REMB(Receiver Estimated Maximum Bitrate ) exchange the bandwodth estimates.
• On the sender side TWCC(Transport wide congestion control) can be used.

Other congestion control algorithms

• QUIC Loss Detection and Congestion Control RFC 9002
• Coupled Congestion Control for RTP Media rfc8699
• NADA: A Unified Congestion Control Scheme for Real-Time Media – Network Working group
• Self-Clocked Rate Adaptation for Multimedia RMCAT WG
• SCReAM – Mobile optimised congestion control algorithm by Ericson

Low Network Strength and High Packet Loss

Packet loss is the loss of packets in transmission which could be owing to

• network resources and path
• transmission medium congestion
• applications inability to absord delayed packets.
• Maximum Transmission Unit size : measure of how large a single apcket can be.

Recovering Lost packets

High definition video stream requires low/no packet loss and fast recovery if any. RTP intrinsically has no means for recovering packet loss. Instead, low bit rate redundancy can be added to packets themselves to make up for any loss. Retransmission of lost packets can be a feature developed over RTP using sequence numbers head in RTP.

Acknowledgement to identify packet loss

A receiver can notifiy the sender of the possible concerns around packet loss by means of sendings acks.

• Selective Acknowledgement (SACK) : notifies the sender of multiple packets and thereby indicating gaps
• Negative Acknowledgements (NACK ) : notifies the sender of packets lost
  • RTCP Packet Type 193 denotes NACK.

• (+) higher NACK count is suggestive of high packet loss
• (-) round trip time for NACK to send and waiting for packet to be retransmitted and receive in response can cause significant delay

Forward Error Correction (FEC)

The sender proactively send redundant data such that lost packets dont affact the stream on receiver’s end.

• (+) receiver doesnt have to request for exgtra data to be sent , the sender does it by itself at RTP level
• (+) less delay than NACK which incurs round trip time
• (-) involve extra bandwidth.

Long distance Calls and High Round Trip Time

Geographical distances can add significant delay in Transmission time.Transmission time is an important metric in the Call Quality analysis however calculating transmission time as sthe different of timestamp of sending and timestamp of receiving requires perfect sync of systems clock which is unreliable.

transmission_time = timestamp_send - timestamp_receive

For this reason RTT( Round Trip Time)is a better means to avoid clock synchoronization errors.

transmission_time = rtt /2 

Using Receiver reports and Sender Reports from RTCP to adjust to network conditions

Sender and receiver reports (SR and RR) provide a highlight of the connection and media quality streaming on this connection.

Low Latency Media Streaming

Latency is calculated from getting user media encoding transmission , network delays , buffering , decoding and playback. There are many factors involved in latency management such as queing delays , media path, CPU utilization etc.

Optimize Compute resource

• mobile agents have lesser computative power
• Camera with features such as auto focus or other adjustments will taker more time to cappture
• network should be of suited bandwidth and strength

Reduce information to be encoded and sent

• Subject focus and blurring backgroud
• Filtering noise at source
• Voice Activity Detection (VAD)
  • send extra data in FEC only is there is voice activity detected in packet
• Echo Cancellation

Measuring latency

Since we know that synchorinizaing clocks in distributed systems is a tough task and mostly avoided by wither using NTP or using other means of synchronization

NTP Synchronization of Audio Video Sync

During the buffereng of incoming [ackets ( which canrage from few ten of miliseconds to few hundred milisecond ) the streams are synchronized.

Time used by RTP for sync is NTP and RTP based ( which are not required to be in sync).

• NTP Timestamp : 64-bit unsigned value that indicates the time at which this RTCP SR packet was sent. Formatted as fractional seconds since Jan 1, 1900
• RTP Timestamp : RTP timestamp corresponds to the same instant as the NTP timestamp. Expressed in the units of the RTP media clock.
  • Majority of video formats use a 90kHz clock.
  • For receiver to sync audio and video streams these two streasm must be from same clock

Frame 300: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0 (outbound)
....
Packet type: Sender Report (200)
Length: 6 (28 bytes)
Sender SSRC: 0x39a659b4 (967203252)
Timestamp, MSW: 3855754463 (0xe5d224df)
Timestamp, LSW: 2364654374 (0x8cf1c326)
[MSW and LSW as NTP timestamp: Mar 8, 2022 18:54:23.550563999 UTC]
RTP timestamp: 1110449770

Demand for higher security on WebRTC’s CPaaS

Webrtc uses Stream Control Transmission Protocol (SCTP) over DTLS connection as an alternative to TCP and UDP.

Features :

• multihoming : one or both endpoints of a connection can consist of more than one IP address. This enables transparent failover between redundant network paths
• Multistreaming transmit several independent streams of chunks in parallel
• SCTP has similarities to TCP retransmission and partial reliability like UDP.
• Heartbest to keep connection alive with exponential backoff if packet hasnt arrived.
• Validation and acknowledgment mechanisms protect against flooding attack

SCTP frames data as datagrams and not as a byte stream

• (+) SCTP enables WebRTC to be multiplexing
• (+) It has flow control and congestion avoidance support
• (+)  

End to End Encryption

End to end encryption model of WebRTC is a good defence to MIM ( man in middle ) attacks howver it is not yet 100% foolproof. I discussed more security loopholes and concerns in WebRTC and Realtime communication platfroms in this article WebRTC App and webpage Security.

Minimize Public-private mapping pairs vai RTCP-mux

Traditionally 2 separte ports for RTP aand RTCP were used in SIP / RTP based realtime communications systems. Thus demultiplexisng of the traffic of these data streams is peformed at the transport later.

With rtcp-mux the NAT tarversal si simplified as onlya single port is used for media and control messages .

• (+) easier to manage security by gathering ICE candidates for a single port only instead of 2
• (+) increases the systesm capacity for media session using the same number of ports
• (+) further simplified using BUNDLE as all media session and their control messages flow on the same port .
• WebRTC has rtcp-mux capabilities thus simplifying the ICE candidate pairing

References :

• https://www.w3.org/TR/webrtc-stats/
• RTP: A Transport Protocol for Real-Time Applications RFC 3550

Echo is the sound of your own voice reverberating. If the amplitude of such a sound is high and intervals exceed 25 ms, it becomes disruptive to the conversation. Its types can be acoustic or hybrid. Echo cancellers need to eliminate the echo while still preserving call quality and not disrupting tones such as DTMF.

Acoustic Echo 

Usually the background or reflected noise which is an undesired voiceband energy transfers from the speaker to the microphone and into the communication network. Mostly found in a hands-free set or speakerphone. In a multiparty call scenario, it could also occur due to unmatched volume levels, challenging network conditions on one party, background noise, double talk or even proximity between user and microphone

Hybrid / Electronic Echo in PSTN phones

In a public telephone system, local loop wiring is done using two-wire connections carrying bidirectional voice signals. In PBX, a two-to-four wire conversion is done using a hybrid circuit which does not perform perfect impedance matches resulting in a Hybrid echo.

Echo Cancellation

An efficient echo canceller should cancel out the entire echo tail while not leading to any packet loss. It needs to be adaptive to changing IP network bandwidth and algorithm should function equally well in conference scenarios  where there may be more than one echo sources. Benchmarking tools like MOS (Mean Opinion scores ) are used to gauge the  results. Often voice quality enhancement technologies are also integrated into AEC modules, such as :

• automatic Gain control ( AGC) ,
• Noise Reduction
• Confort Noise Generator ( CNG)
• Non linear processor
• tone Disabler for SS& and DTMF tones

WebRTC Echo Cancellation

WebRTC now actively detects and removes echo especially the local system echo resonance.

Noise Suppression in WebRTC

Noise suppression automatically filters the audio to remove background noise.

Automatic Gain Control (AGC)

AGC works as a circuit. When the average audio level is low , circuit raises it and if the audio level is high the circuit brings it down.

• (+) AGC frees the user from manually tuning the audio level.
• (-) During a pause too , agc tries to bring audio level to standard setting making background noises louder.
• (-) subesquent audio processing make gain control progressively worse.

Audio Compressor : Due to the drawbacks with AGC , Audio Compressers carry the operation more sophistically by looking at amplitude of the sound.

(-) not ideal for music which had varrying sound amplitude.

Audio Peak Limiter : Limiters simply keep the audio from exceeding a set maximum level.

(+) well suited for avoiding loud noise such as door slam from entering the processing pipeline.

Audio Expanders :increase the dynamic (loudness) range of audio that has been overly processed.

(+) suited for over compressed audio transmissiono such as Satellite relays

Audio Filters :attenuate audio frequencies either above or below certain points within the audio range.

AGC in webRTC

navigator.mediaDevices.getSupportedConstraints();

aspectRatio: true
autoGainControl: true
brightness: true
channelCount: true
colorTemperature: true
contrast: true
deviceId: true
echoCancellation: true
exposureCompensation: true
exposureMode: true
exposureTime: true
facingMode: true
focusDistance: true
focusMode: true
frameRate: true
groupId: true
height: true
iso: true
latency: true
noiseSuppression: true
pan: true
pointsOfInterest: true
resizeMode: true
sampleRate: true
sampleSize: true
saturation: true
sharpness: true
tilt: true
torch: true
whiteBalanceMode: true
width: true
zoom: true

WebRTC Get User MEdia with various values of autoGainControl

References :

• https://webrtc.org/blog/2011/07/11/webrtc-improvement-optimized-aec-acoustic-echo-cancellation.html
• http://www.ti.com/lit/wp/spraal1/spraal1.pdf
• https://www.adaptivedigital.com/vqe-suite/echo-cancellation-explained/
• https://github.com/webrtc-uwp/webrtc/blob/master/modules/audio_processing/aec3/echo_canceller3.h
• Mozilla docs https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackSettings/noiseSuppression

1. Why SCTP Matters in Modern Telecom
2. Key Features of SCTP
   1. Message-Oriented Delivery
   2. Multi-Homing Support
   3. Multiple Independent Streams
   4. Robust Error Handling
   5. Path MTU Discovery
3. SCTP Connection Handshake
4. SCTP vs QUIC
5. SCTP in IPSec
6. Key Takeaways
7. References:

Why SCTP Matters in Modern Telecom

Unlike TCP, which treats data as a continuous stream, SCTP preserves message boundaries while maintaining the reliability guarantees that critical systems demand. For telecom infrastructure and video applications requiring multiple independent data streams, SCTP eliminates the head-of-line blocking issues that plague traditional TCP connections.

Key Features of SCTP

SCTP brings several powerful features to the table that set it apart from TCP and UDP:

Message-Oriented Delivery

Data is transmitted in chunks or messages rather than as a continuous stream of bytes like TCP. This preserves message boundaries and eliminates the need for application-level delimiters.

Multi-Homing Support

SCTP supports multiple IP addresses for each endpoint, enabling redundancy across multiple network paths. If one path fails, the connection seamlessly switches to an alternative path without dropping the association.

Multiple Independent Streams

A single SCTP association can carry multiple streams simultaneously, each with independent reliability guarantees. This eliminates head-of-line blocking—when one stream’s data is delayed, other streams continue unaffected. This is critical for applications like video conferencing where audio and video must progress independently.

Robust Error Handling

SCTP implements acknowledgments, retransmissions, and congestion control mechanisms similar to TCP, ensuring reliable delivery in lossy networks.

Path MTU Discovery

SCTP automatically determines the largest data chunk size that can traverse the network without fragmentation, optimizing throughput while preventing excessive packet fragmentation.

SCTP Connection Handshake

SCTP uses a four-way handshake to establish connections, providing additional security and validation compared to TCP’s three-way handshake. This handshake design provides protection against SYN flood attacks while ensuring both endpoints are synchronized and ready for data transfer.

Four-way handshake in SCTP

1. INIT        -> Client sends INIT with sequence number and supported parameters
2. INIT ACK    <- Server responds with INIT ACK and its own sequence number
3. COOKIE ECHO -> Client sends COOKIE ECHO to confirm receipt of INIT ACK
4. COOKIE ACK  <- Server responds with COOKIE ACK to finalize connection setup

SCTP vs QUIC

Is SCTP Still Relevant After QUIC?

The emergence of QUIC has raised questions about SCTP’s future. The answer is nuanced:

No, for general web-based applications: For modern web applications, QUIC is the preferred protocol due to its low-latency and built-in security features, as well as its integration with HTTP/3. QUIC can outperform SCTP in web traffic, video streaming, and real-time communications like WebRTC.

Yes, for specific use cases: While QUIC has gained attention for web traffic and real-time communication, SCTP is still relevant in niche use cases that demand multi-homing (e.g., cellular and telecommunication networks) or high-reliability signaling (e.g., SIP in VoIP). SCTP’s ability to handle multiple streams of data with strong error correction and congestion control makes it indispensable for telecommunication protocols. SCTP continues to be used in areas like VoIP (Voice over IP), 5G, and telecommunication systems today.

SCTP in IPSec

This combo is meant to leverage IPSec to secure SCTP communication ensuring that the transmission of SCTP packets is protected against threats such as eavesdropping, tampering, and spoofing. IPSec is a network layer protocol ( L3) while SCTP is transport layer ( L4). Therefore IPSec is often used to provide encryption, integrity, and authentication services by securing the payload and headers.

Key Takeaways

• SCTP is message-oriented: Data preserves boundaries, unlike TCP’s stream model
• Multi-homing for redundancy: Multiple paths ensure high availability
• Multiple streams eliminate head-of-line blocking: Critical for multimedia applications
• Still essential for telecom: VoIP, 5G, and carrier networks depend on SCTP
• QUIC for web, SCTP for telecom: Each excels in its domain
• IPSec integration: Adds enterprise-grade security to SCTP associations

References:

• RFC 4960: Stream Control Transmission Protocol (SCTP) – https://tools.ietf.org/html/rfc4960
• RFC 3554: On the Use of Stream Control Transmission Protocol (SCTP) with IPsec – https://tools.ietf.org/html/rfc3554
• IETF SIGTRAN Working Group: Signaling Transport standards – https://datatracker.ietf.org/wg/sigtran/
• Wikipedia – SCTP: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

VoIP manages Call setup and teardown using IP protocol. The APIs can be used to provide public or internal endpoinst to create mnage calls , conference addon services like recording , tgranscription or even do auth and heartbeat. This article lists some external programmable Call Control APIs, internal APIs for biling , health as well as Rate limitting.

Public API endpoints

Programmatic call control APIs

1. Making a Call

HTTP POST https://www.altteelcom.com/voice/call

Parameters

to: '+14155551212',
from: '+18668675310'

Calback params

statusCallback: 'https://www.myapp.com/events',
statusCallbackEvent: ['initiated', 'answered'],
statusCallbackMethod: 'POST'

Response

"from": "+9999999999"
"to": "+111111111",
"status": "ongoing"

Tmestamps
"date_created": "Mon, 5 Sep 2020 20:36:28 +0000"
"start_time": "Mon, 5 Sep 2020 20:36:29 +0000"
"date_updated": "Mon, 5 Sep 2020 20:36:44 +0000"
"direction": "outbound",
"duration": ""
"end_time": ""

Price
"price": "-0.03000"
"price_unit": "USD"

The response can additional have SID and app version and other URI for recording , transcription , apyment and other services for this call .

2. Ending an ongoing Call

HTTP UPDATE https://www.altteelcom.com/voice/call/callid001

params

status: 'end'

This updates the end time of the call and sets the evenst for CDR processing

Services API

• Call Reording
• Call transcription

Confernece APIs
HTTP POST https://www.altteelcom.com/voice/conferences

• creating a conf
• fetching conf based on date or room name
• updating a ongoing conf
• ending a conf
• set IVR announcement on ongoing conf

Auth API

CDR APIs

HTTP POST https://www.altteelcom.com/cdr

• get CDR ( filtered per cal or acc to specific date or account)
• bulk export of CDR

Internal API gateways

API Rate Limiter

Noisy neighbour is when one of the clients monoplizes the bandwidth using most of the i/o or cpu or other resources which can negatively affect the performance for other users . Throttling is a good way to solve this problem by limit.

A rate limiter should have low latency, accurate and scalable.

Token based Rate Limiting

 provides admission contro

Token bucket filter

define a users quota in terms average rate and burst capacity

Hierarchical Token Bucket ( HTB)

 uses the deficit round-robin algorithm for fair queuing

Fair Queing

give paying users a bandwidth fraction of 25%

priority queuing

decide 1 packet/ms for free or reduce rate user

distributes that sender’s bandwidth among the other senders

CBQ ( Class Based Queing)

Shaping is performed using link idle time calculations based on the timing of dequeue events and underlying link bandwidth. Input classes that tried to send too much were restricted, unless the node was permitted to “borrow” bandwidth from a sibling.

Modular QoS command-Line interface (MQC) Shaping

mplement traffic shaping for a specific type of traffic using a traffic policy

• When the rate of packets matching the specified traffic classifier exceeds the rate limit, the device buffers the excess packets.
• When there are sufficient tokens in the token bucket, the device forwards the buffered packets at an even rate.
• When the buffer queue is full, the device discards the buffered packets.

Throttling

• delay the packet until the bucket is ready / shaping
• drop the packet / Policing
• mark the packet as non-compliant

Failure management on Rate Limiter

• Node Crash : just less requests trolled
• Leaky bucket
• tokens can go into -ve

System Design for API gateway

Important points for design API gateway

• Serialize data in company binary format
• allocate buffer in memory and build frequency count hash table and flash once full or based on time to calculate counters
• aggregation on API gateway on the fly

Distributed messaging system( fast and slow paths) for API

A distributed messahing system such as Apache kafka or AWs kinesis, internally splits a msg accross serveral partitions where each parition can be placed on a single shard in a seprate machine on a clustered system.

Applications of this system design

• Find heavy hitters ( Top K problem )
• Popular products / trends
• Voltaile stocks
• DDoS Attack Prevention

References :

• [1] tc-cbq linux : https://man7.org/linux/man-pages/man8/tc-cbq-details.8.html
• [2] http://intronetworks.cs.luc.edu/current2/html/tokenbucket.html
• [3] Cisco https://community.cisco.com/t5/routing/qos-atm-voip-where-to-rate-limit-police/td-p/2161691

Load Balancers

Load Balancer(LB) is the initial point of interaction between the client application and the core system. It is pivotal in the distribution of the load across multiple servers and ensuring the client is connected to the nearest VoIP/SIP application server to minimize latency. However, the load balancers are also susceptible to security breaches and DOS attacks as they have a public-facing interface. This section lists the protocols, types and algorithms used popularly in Load balancers of VoIP systems.

Load Balancers(LB) ping each server for health status and greylists servers that are unhealthy( respond late) as they may be overloaded or experiencing congestion. The LB monitors it rechecks after a while and if a server is healthy ( ie if a server responds with responds with status update) it can resume sending traffic to it. LB should also be distributed to different data centres in primary-secondary setup for HA.

Networking protocol

Load balancing algorithms

• Weighted Scheduling Algorithm
• Round Robin Algorithm
• Least Connection First Scheduling
• Lest response time algorithms
• Hash based algorithm ( send req based on hashed value such as suing IP address of request URL)

Service Discovery

Client-side or even backend service discovery uses a broadcasting or heartbeat mechanism to keep track of active servers and deactivates unresponsive or failed servers. This process of maintaining active servers helps in faster connection time. Some approaches to Service Discovery

1. Mesh
   1. (-) exponentially incresing network traffic
2. Gossip
3. Distributed cache
4. Coordination service with Service
   • (-) requesres coordination service for leader selection
   • (-) needs consensus
   • (-) RAFT and pbFT for mnaging failures
5. Random leader selection
   • (+) quicker
   • (-) may not gurantee one leader
   • (-)split brain problem

Keepalive, unregistering unhealthy nodes

Systems such as Consul, Etcd, and Zookeeper can help services find each other by keeping track of registered names, addresses, and ports. Health checks help verify service integrity and are often done using an HTTP endpoint.

Replication

Usuallay there is a tradeoff between liveness and safety.

1. Single leader replication
   • (-) vulnerable to loss of data is leader goes down before replication completes
   • used to in sql
2. multileader replication and
3. leaderless replication
   • (-) increases latencies
   • (-) quorem based on majority , cannot function is majority node are not down
   • used in cassandra

Data Store Replication

For Relatonal Dataabase

For NoSQL databse replication and HA

Quick Response / Low latency

Message format

Gateways for faster routing and caching to services

gateways are single entry point to route user requests to backend services .

Separate hot storage from cold storage

hot storage is frquently accessed data which must be near to server

cold storage is less frequently accessed data such as archives

• object storage
• slow access

Scalability

To make a system :-

• scalable : use partitioing
• reliable : use replication and checkpointing to not loose data in failures
• fast : use in -memory usage

According to CAP theorem Consistency and Availiability are difficult to achieve together and there has to be a tradeof acc to requirnments.

Partitioining

Partition strategy can be based on various ways such as :-

• Name based partition
• geographic partition
• names’ hashed value based on identifier
  • (-) can lead to hot partitions ( high density in areas of freq accessible identioers )
  • (-) high density spots for example all messages with a null key to go to the same partition
  • (-) doesnt scale
• event time based hash
  • (+) data is spread evenly over time

To create a well distributed partition we could spread hot partition into 2 partitions or dedicate partitions for freq accessible items. An effective partitioning keys uses

• Cardinality : total num of unique keys for a usecase. High cardinality leads to better distribution.
  • high cardinatility keys : names , email address , url since they have high variatioln
  • low cardinatlity keys : boolean flags such as gender M/F
• Selectivity : number of message with each key. High selectivity leads to hotspots and hence low selectivity is better for even distribution.

Autoscalling

Scale Out not Up !

Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management used in DevOps. I have mentioned this in detail on the article on VoIP and DevOps below.

Multiple PoPs (point of presence)

for a VOIP system catering to many clients accross the globe or accessing multiple carriers meant for different counteries based on Prefix matching , there should be alocal PoP in most used regions . typically these regions include – US east – west coasts, UK – germany of London , Asia Pacific – Mumbai ,Hong Kong and Australia.

Minimal Latency and lowest amount of tarffic via public internet

Creating multiple POPs and enabling private traffic via VPN in between them ensures that we use the backbone of our cloud provider such as AWS or datacentre instead of traversing via public internet which is slower and more insecure. Hopping on a private interface between the cloud server and maintaining a private connection and keepalive between them helps optimize the traffic flow while keeping the RTT and latency low.

HA ( High-availability )

Some factors affecting Dependability are

• Eventual Consistency
• MultiRegion failover
• Disaster Recovery

A high-availability (HA) architecture implies Dependability.Usually via existence of redundant applications servers for backups: a primary and a standby. These applications are configured so that if primary fails, the other can take over its operations without significant loss of data or impact to business operations.

Downtime / SLA of 5 9’s in aggregate failures

4 9’s of availiability on each service components gives a downtime of 53 mins per service each year. However in aggregate failure this could amlount to (99.99)¹⁰ = 99.9 downtime which is 8-10 hours each year.

Thus, aggregate failure should be taken into consideration while designing reliable systems.

HA for Proxy / Load balancer (LB)

A LB is the first point of contact for outbound calls and usually does not save the dialogue information into memory or database but still contain the transaction information in memory. In case the LB crashes and has to restart, it should

• have a quick uptime
• be able to handle in dialogue requests
• handle new incoming dialogue requests in a stateless manner
• verify auth/authorization details from requests even after restart

HA for Call Control app server

App server is where all the business logic for call flow management resides and it maintains the dialog information in memory.

Issues with in-memory call states : If the VM or server hosting the call control app server is down or disconnected, then live calls are affected, this, in turn, causes revenue loss. Primarily since the state variable holding the call duration would be able to pass onto the CDR/ billing service upon the termination of the call. For long-distance, multi telco endpoint calls running hours this could be a significant loss.

• Standby app server configuration and shared memory : If the primary app server crashes the standby app server should be ready to take its place and reads the dialog states from the shared memory.
• Live load balanced secondary app server + external cache for state varaibles : External cache for state variables: a cluster of master-slave caches like Redis is a good way of maintaining the dialogue state and reading from it once the app server recovers from a failed state or when a secondary server figures it has a missing variable in local memory.

Media Server HA

Assuming the kamailio-RTPengine duo as App server and Media Server. These components can reside in same or different VMs. Incase of media server crash, during the process of restoring restarted RTpengine or assigning a secondary backup RTpengine , it should load the state of all live calls without dropping any and causing loss of revenue . This is achived by

• external cache such as Redis ,
• quick switchover from primary to secondary/fallback media server and
• floating IPs for media servers that ensures call continuity inspite of failure on active media server.

Architecturally it looks the same as fig above on HA for the SIP app server.

Security against malicious attacks

Attacks and security compromisation pose a very signficant threat to a VoIP platform.

MITM attacks

Man in midddle attacks can be counetred by

• End to end encryption of media using SRTP and signals using TLS
• Strong SIP auth mechanism using challenges and creds where password is composed of mixed alphanumeric charecters and atleast 12 digits long
• Authorization / whitelisting based on IP which adheres to CIDR notation

DDOS attacks

DDOS renders a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces.

dDOS – multiple network hosts to flood a target host with a large amount of network traffic. Can be created by sending falsified sip requests to other parties such that numerous transactions originating in the backwards direction comes to the target server created congestion.

Can be counetred by

• detect flooding and q in traffic and use Fail2ban to block
• challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required)

Read about SIP security practices in deatils https://telecom.altanai.com/2020/04/12/sip-security/

Other important factors leading to security

• Keystores and certificate expiry tracker
• priveligges and roles
• Test cases and code coverage
• Reviewers approval before code merge
• Window for QA setup and testing , to give go ahead before deployment

Identifying outages and Alerting

Raise Event notification alerts to designated developers for any anolous behavior. It could be call based or SMS basef alert based on the sevirity of the situtaion .

Sources for alert manager

• Build failed ( code crashes, Jenkins error)
• Deployment failed ( from Kubernetes , codechef, docker ..)
• configuration errors ( setting VPN etc )
• Server logs
• Server health
• homer alerts ( SIP calls responses 4xx,5xx,6xx)
• PCAP alerts ( Malformed SIP SDP ..)
• Internal Smoke test ( auto testing procedure done routinely to check live systems )
• Support tickets from customer complaints ( treat these as high priority since they are directly impacting customers)

Bottlenecks

The test bed and QA framework play a very crticial role in final product’s credibility and quality.

Performance Testing

• Stress Testing : take to breaking
• Load Testing : 2x to 3x testing
• Soak Testing : typical network load to long time ( identify leaks )

Robust QA framework( stress and monkey testing) to identify potential bottlenecks before going live

A QA framework basically validates the services and callflows on staging envrionment before pushing changes to production. Any architectural changes should especially be validated throughly on staginng QA framework befire making the cut. The qualities of an efficient QA platform are :

Genric nature – QA framework should be adatable to different envrionments such as dev , staging , prod

Containerized – it should be easy to spn the QA env to do large scale or small scale testing and hence it should be dockerized

CICD Integration and Automation – integrate the testcases tightly with gt post push and pull request creation . Minimal Latency and lowest amount of tarffic via public internet

Keep as less external dependecies as possible for exmaple a telecom carrier can be simulated by using an PBX like freeswitch or asterix

Asynchronous Run – Test cases should be able to run asynchronously. Such as seprate sipp xml script for reach usecase

Sample Testcases for VoIP

• Authentication before establish a session
• Balance and account check before establishing a session like whitelisting , blacklisting , restricted permission in a particular geography
• Transport security and adaptibility checks , TLS , UDP , TCP
• codec support validation
• DTMF and detection
• Cross checking CDR values with actual call initiator and terminator party
• cross checking call uuid and stats
• Validating for media and related timeouts

QA frameworks tools – Robot framework

traffic monitor – VOIP monitor

customer simulator – sipP scripts

network traffic analyser – wireshark

pcap collevcter – tcpdump , sngrep

Distributed Data Store

A Distributed Database Design could have many components. It could work on static datastore like

• SQL DB where schema is important
  • MySQL
  • postgress
  • Spanner – Globally-distributed database from Google
• NoSQL DB for to store records in json
  • Cassandra – Distributed column-oriented database
• Cache for low latency retrivals
  • Memcached – Distributed memory caching system
  • Redis – Distributed memory caching system with persistence and value types
• Data lakes for heavy sized data
  • AWS s3 object storage
  • blob storage
• File System
  • Google File System (GFS) – Distributed file system
  • Hadoop File System (HDFS) – Open source Distributed file system

or work on realtime data streams

• Batch processing ( Hadoop Mapreduce)
• Stream processing ( Kafka + spark)
  • Kafka – Pub/sub message queue
• Cloud native stream processing ( kinesis)

Each component has its own pros and cons. The choice depends on requirnments and scope for system behaviour like

• users/customer usuage and expectation ,
• Scale ( read and write )
• Performnace
• Cost

Some fundamental constrains while design distributed data structure :-

p99 latency : 99% of the requests should be faster than given latency. In other words only 1% of the requests are allowed to be slower.

Request latency:
    min: 0.1
    max: 7.2
    median: 0.2
    p95: 0.5
    p99: 1.3

Inidiviual Events vs Aggregate Data

Push vs Pull Architecture

Push : A processing server manages state of varaible in memory and pushes them to data store.

• (-) crashed processingserver means all data is lost

Pull : A temporary data strcyture such as a queue manages the stream of data and processing service pull from it to process before pusging to data stoore.

• (+) a crashed server has to effect on temporarily queue held data and new server can simply take on where previous processing server left.
• (+) can use checkpointing

Popular DB storage technologies

A NoSQL databse can be of type

• Quorem
• Document
• Key value
• Graph

Cassandra is wide column supports asyn master less replication

Hinge base also a quorem based db also has master based preplication

MongoDB documente orientd DB used leacder based replication

SQL scaling patterns include:

• Federation/ federated database system : transparently maps multiple autonomous database systems into a single virtual/federated database.
  • (-) slow since it access multiple data storages to get the value
• Sharding / horizontal partition
• Denormalization : Even though normalization is more memory efficient denormalization can enhance read performance by additing redundant pre computed data in db or grouping related data.
  • Normalizing data reduces data warehouse disk space by reducing data duplication and dimension cardinality. In its full definition, normalization is the process of discarding repeating groups, minimizing redundancy, eliminating composite keys for partial dependency and separating non-key attributes.

• SQL Tuning : “iterative process of improving SQL statement performance to meet specific, measurable, and achievable goals”

Influx DB : to store time series data

AWS Redshift

Apache Hadoop

Redis

Embeed Data : RocksDB

Message Queues(Buffering) vs Batch Processing

Distributed event management, monitoring and working on incoming realtime data instead of stored Database is the preferred way to churn realtime analysis and updates. The multiple ways to handle incoming data are

1. Batch processing – has lags to produce results, not time crtical
2. Data stream – realtime response
3. Message Queues – ensures timely sequence and order

Timeout

• Connection timeout : use latency percentiles to calculate this
• Request timeout

Retries

• exponential backoff : increase waiting time each try
• jitter : adds rabdomness to retry intervals to spread out the load.

Grouping events into object storage and Message Brokers

slower than stream processing but faster than batch processing.

Distributed Event management and Event Driven architecture using streams

In event driven archietcture a produce components performs and action which creates an event thata consumer/listener would subscribes to consume.

• (+) time sensitive
• (+)Asynch
• (+) Decoupled
• (+) Easy scaling and Elasticity
• (+) Heterogeneous
• (+) contginious

Expanding the stream pipeline

Event Streams decouple the source and sink applications. The event source and event sinks (such as webhooks) can asynchronously communicate with each other through events.

Options for stream processing architectures

• Apache Kafka
• Apache Spark
• Amazon kinesis
• Google Cloud Data Flow
• Spring Cloud Data Flow

Here is a post from earlier which discusses – Scalable and Flexible SIP platform building, Multi geography Scaled via Universal Router, Cluster SIP telephony Server for High Availability, Failure Recovery, Multi-tier cluster architecture, Role Abstraction / Micro-Service based architecture, Load Balancer / Message Dispatcher, Back end Dynamic Routing and REST API services, Containerization and Auto Deployment, Auto scaling Cloud Servers using containerized images.

VoIP/ OTT / Telecom Solution startup’s strategy for building a scalable flexible SIP platform

Lambda Architecture

Stream processing on top of map reduce and stream processing engine. In lambda architecture we can send events to batch system and stream processing system in parallel. The results are stiched together at query time.

Apache Kafka is used as source which is a framework implementation of a software bus using stream-processing. “.. high-throughput, low-latency platform for handling real-time data feeds”.

Apache Spark : Data partitioning and in memory aggregation.

Distributed cache for call control Servers

Choosing cache host

• Mod function
  • (-) behaves differently when a new client is added or one is removed , unsuitable for prod
• Consistent hashing ( chord)
  • maps each value to a point on circle

Cache Replacement

Least Recently Used Cache Replacement

Consistency and High Availiability in Cache setup

ReadReplicas live in differenet data centre for disaster recovery.

Strong consistency using Master Slave

Circuits – fail fast, wait for circuit to recover before using again

Design patterns for a circuit base setup to gracefully handle exceptions using fallback.

Circuit breaker : stops client from repeatedly trying to exceute by calculate the error threshold.

Isolated thread pool in circuits and ensure full recovery before calling the service again.

(+) Circuit breaker event causes the entire circuit to repair itself before attempting operations.

References :

• [1] http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html
• [2] http://engineering.hackerearth.com/2013/10/07/scaling-database-with-django-and-haproxy/
• [3] Mastering Chaos – A Netflix Guide to Microservices , QCon London
• [4] https://dzone.com/refcardz/event-stream-processing-essentials
• [5] p99 latency https://stackoverflow.com/questions/12808934/what-is-p99-latency
• [6] Oracle site on partitioing- https://docs.oracle.com/en-us/iaas/Content/Streaming/Concepts/partitioningastream.htm
• [7] Mastering Chaos – A Netflix Guide to Microservices https://www.youtube.com/watch?v=CZ3wIuvmHeM&ab_channel=InfoQ
• [8] Netflix cloud architecture https://netflixtechblog.com/tagged/cloud-architecture

Innovations in telecommunication today are largely driven by the advancements in Open source tech tools, standards and stacks. IP-based video and voice communication systems, Unified Communication systems such as Enterprise CPaaS platforms or even an external independent VoIP provider. The challenge for service providers today is that operating costs are growing faster than revenues. A large number of growing systems and vendors make operation a complex and expensive process.

Maintaining a network for communication service providers can be a complex and challenging task for several reasons:

1. Network maintenance and upgrades: Service providers must constantly maintain and upgrade their networks to ensure that they are able to provide reliable service to their customers. This can involve replacing outdated equipment, installing new technology, and troubleshooting issues that arise.
2. Managing traffic: Service providers must manage the traffic on their networks to ensure that it is distributed efficiently and that users are able to access the services they need. This can be a challenge, especially when the network is congested or there are unexpected spikes in traffic.
3. Ensuring security: Communication networks are vulnerable to a variety of security threats, including hacking, malware, and denial of service attacks. Service providers must take measures to protect their networks and their customers’ data from these threats.
4. Managing costs: Maintaining a communication network can be expensive, and service providers must find ways to manage costs while still providing high-quality service to their customers.
5. Meeting regulatory requirements: Service providers must comply with a variety of regulations, including those related to privacy, data protection, and network security. Failing to comply with these regulations can have serious consequences, including fines and reputational damage.

Network Virtualisation

Network virtualization is the process of creating a virtual version of a network, including the hardware, network topology, and protocols, using software. This allows multiple virtual networks to be created and run on the same physical infrastructure, which can be used to isolate different network environments, test new network configurations, or provide network resources as a service.

NV = NFV + SDN

• NFV is SW-defined network functions with separation of HW and SW. Once network elements are SW-based, network HW can be managed as a pool of resources
• SDN is Interconnecting Virtual Network Functions with separation of control and data plane. Orchestration together with SW domain

There are several ways to implement network virtualization, including using software-defined networking (SDN) technologies, which allow the network to be controlled and managed using software, and using virtualization technologies such as virtual LANs (VLANs) or virtual private networks (VPNs) to create isolated network segments within a larger network. In a virtualized network the setup network functionalities are SW-based over COTS HW. Multiple roles can be made over same HW.

Network Virtualisation is an opportunity to build mouldable networks and redefine the architecture to make the infrastructure uniform.Virtual network services lowered CAPEX. Lessening dependencies on proprietary hardware and dedicated appliances.

• (+) Improves management of risk in a changing and ambiguous environment
• (+) capacity alteration Network flexibility
• (+) scalability
• (+) Service provisioning speed
• (+) holistic management:
• (+) granular security

There are several approaches to network virtualization that service providers can use, including:

1. Network Function Virtualization (NFV): NFV involves virtualizing network functions, such as routers, firewalls, and load balancers, and running them on standard servers or other off-the-shelf hardware using virtualization platforms like VMware or OpenStack.
2. Software-Defined Networking (SDN): SDN involves separating the control plane (which determines how data is routed through the network) from the data plane (which carries the actual data). This allows the control plane to be more flexible and responsive to changes in the network.
3. Virtual Private Network (VPN): A VPN allows service providers to create virtual private networks (VPNs) over the public Internet, allowing them to securely connect users to the resources they need.

Service providers can use network virtualization to reduce costs, increase flexibility, and improve the scalability and reliability of their networks. Managed Service Providers (MSPs) can use a single viewpoint and toolset to manage virtual networking, computing and storage resources. However, implementing network virtualization can also be complex and require significant investments in hardware, software, and training.

Software Defined Network (SDN)

A software-defined network (SDN) is a networking architecture that uses software provisioning interfaces to control and manage the flow of traffic in a network. In an SDN, the control plane, which determines how data is routed through the network, is separated from the data plane, which carries the actual data traffic.

The main benefit of an SDN is that it allows the control of the network to be abstracted from the underlying hardware. This makes it possible to use software to dynamically configure the network, rather than relying on fixed configurations that are set using hardware switches and routers. SDN allows network administrators to easily and quickly change the way that data is routed through the network, which can be useful in a variety of scenarios. For example, an SDN can be used to optimize the flow of traffic in a data center, or to quickly reconfigure a network in response to changing traffic patterns or security threats such as DDoS.

SDN planes

1. Control plane: The control plane is the part of the SDN that determines how data is routed through the network. It consists of a central controller, which is a software application that runs on a server, and a series of software agents that run on the network devices (such as switches and routers). The controller communicates with the agents using a protocol such as OpenFlow, which allows it to control the flow of traffic in the network.
2. Data plane: The data plane is the part of the SDN that carries the actual data traffic. It consists of the network devices (such as switches and routers) that forward data packets through the network.
3. Management plane: The management plane is the part of the SDN that is responsible for configuring and managing the network. It consists of a set of tools and applications that allow network administrators to monitor and control the network.
4. Application plane: The application plane is the part of the SDN that consists of the applications that run on the network. These applications may include things like web servers, email servers, and database servers.

Software-defined network functions separates hardware and software. Once network elements are Software-based, network harware can be managed as a pool of resources. Separating route/switching intelligence from packet forwarding reduces hardware prices as routers and switches must compete on price-performance features.

SDN interconnects Virtual Network Function and orchestrated with SW domain. Enables separation of control and data plane.Setting up networks in an SDN can be as easy as creating VM instances, and the way SDNs can be set up is a far better complement to VMs than plain old physical networks. SDNs enable “network experimentation without impact”. Overcome SNMP limitations and experiment with new network configurations without being hamstrung by their consequences.

• Infrastructure Savings
• Reducing margin of Error : By eliminating manual intervention, SDNs enable resellers to reduce configuration and deployment errors that can impact the network.
• Operational Savings: SDNs lower operating expenses. Network services can be packaged for application owners, freeing up the networking team.
• Flexibility: SDNs create flexibility in how the network can be used and operated. Resellers can write their own network services using standard development tools.
• Better Management gives Better visibility into the network, computing, and storage

SDN protocols : OpenFlow, NETCONF. Its applications could be

• Bandwidth on Demand or test networks.
• Platform Virtualization for emulation/simulation of Network Nodes (BSS/MSS)
• SDN based Application Layer Traffic Optimization
• Intrusion Detection System that can interact with controller in terms of capturing packets, analyzing them for anomaly and sharing results real-time / near real-time with controller.
• Software-Defined Branch and SD-WAN
• IP Multi-Media Subsystem (IMS)
• Session Border Control (SBC)
• Video Servers
• Voice Servers
• Universal Customer Premises Equipment (uCPE)
• Content Delivery Networks (CDN)
• Network Monitoring
• Network Slicing
• Service Delivery
• Network security functions such as firewalls, IDS, IPS, vRR, NAT 

Network functions virtualization (NFV)

NFV provides the basic networking functions and SDN assumes higher-level management responsibility to orchestrate overall network operations.

blog.equinix.com/blog/2020/03/10/sdn-vs-nfv-understanding-their-differences-similarities-and-benefits/

Network Function Virtualization (NFV) is a technology that allows network functions, such as routers, firewalls, and load balancers, to be implemented in software rather than hardware. This allows these functions to be run on standard servers or other off-the-shelf hardware, rather than dedicated appliances.

In an NFV system, network functions are implemented as software called Virtual Network Functions (VNFs). These VNFs are run on virtualization platforms, such as VMware or OpenStack, which allow multiple VNFs to be run on the same physical hardware. To use NFV, a service provider will first define the network functions that it needs in its network, and then create VNFs for each of these functions. These VNFs can then be deployed on virtualization platforms and used to build the service provider’s network.

One of the main benefits of NFV is that it allows service providers to be more flexible and agile in building and managing their networks. Because VNFs can be easily added, removed, or scaled up or down as needed, service providers can quickly respond to changes in demand or new business opportunities. NFV decouples network functions from proprietary hardware appliances (routers, firewalls, VPN terminators, SD-WAN, etc.) and delivers equivalent network functionality without the need for specialized hardware. And this way it helps service providers reduce costs, as they can use standard hardware rather than specialized appliances ( vendor lockins) to implement their network functions.

IMS Virtual Network Functions (VNFs)

A traditional appliance based IMS setup is dedicated to every single service, limited hardware/people/process leveraging.Some drawbacks of this approach is

• Not suited for Heterogeneous Networks that are evolving – inflexible
• Higher footprint cost per customer/service – high OPEX
• New services would need a new dedicated network thus high maintenance cost for solios of operation

Virtualisation will help to redesign the network architecture. In an IMS (IP Multimedia Subsystem) system, VNFs might be used to implement a variety of functions, including:

1. Call Session Control Function (CSCF): The CSCF is responsible for managing call sessions and routing signaling messages between the IMS network and other networks.
2. Media Gateway Control Function (MGCF): The MGCF is responsible for translating between different media formats, such as voice and video, and for controlling media gateways that connect the IMS network to other networks.
3. Home Subscriber Server (HSS): The HSS is a database that stores information about IMS subscribers, including their profiles and service subscriptions.
4. Serving Gateway (S-GW): The S-GW is responsible for routing data packets between the IMS network and the user’s device.
5. Policy and Charging Rules Function (PCRF): The PCRF is responsible for enforcing policy decisions and charging rules for IMS services.
6. IP-SM-GW (SMS Gateway): The IP-SM-GW is responsible for routing SMS messages between the IMS network and other networks.
7. Presence Server: The presence server is responsible for managing presence information (such as availability status) for IMS subscribers.

Local Data Centre can rapidly build Network Intelligence rationalisation using Real Time Network Analytics on virtul STB, EPC, NAT, BRAS, PE, DHCP , PCRF etc. Core can be simplified and centralised with common and standard interfaces within core network and services to interact with OSS and BSS (standardized billing and fulfillment process).

OpenStack

OpenStack is an open-source virtualization platform. It enables service providers to deploy virtual network functions (VNFs) using commercial off-the-shelf (COTS) server hardware.  OpenStack is widely used in the telecommunications industry, as it allows service providers to build and manage large-scale cloud computing environments that can be used to deliver a wide range of services, including virtualized infrastructure, NFV, and containerized applications. Applying Openstack to virtualize networks :

1. Infrastructure as a Service (IaaS): OpenStack can be used to create and manage virtualized infrastructure, including compute, storage, and networking resources. This allows service providers to offer users the ability to spin up and manage virtual machines, storage volumes, and other resources on demand.
2. Network Function Virtualization (NFV): OpenStack can be used as a platform for virtualizing network functions, such as routers, firewalls, and load balancers, and running them on standard servers or other off-the-shelf hardware.
3. Container orchestration: OpenStack can be used to manage containerized applications, allowing service providers to deploy and scale applications more quickly and efficiently.

References:

• https://en.wikipedia.org/wiki/Software-defined_networking
• https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
• https://www.vmware.com/topics/glossary/content/virtual-networking.html#:~:text=Virtual%20Networking%20enables%20the%20communication,office%20and%20data%20center%20locations.

More to read :

• intended for passive duplicated for remote collection
• can be used for audit storage and analysis
• does not alter the orignal datagram or headers

HOMER is Packet and Event capture system popular fpr VOIP/RTC Monitoring based on HEP/EEP (Extensible Encapsulation protocol)

SIP Server Integration

Homer and homer encapsulation protocl (HEP) integration with sip server brings the capabilities to SIP/SDP payload retention with precise timestamping better monitor and detect anomilies in call tarffic and events correlation of session ,logs , reports also the power to bring charts and statictics for SIP and RTP/RTCP packets etc. We read about sipcapture and sip trace modules in project sipcapture_siptrace_hep.

Both Kamailio and Opensips HEP Integration are structurally simmilar. In kamailio SIPCAPTURE [2] module enables support for –

● Monitoring/mirroring port
● IPIP encapsulation (ETHHDR+IPHDR+IPHDR+UDPHDR)
● HEP encapsulation protocol mode (HEP v1, v2, v3)

Figure Opensips Capturing ( credits http://www.opensips.org)

Figure showing Opensips integartion with external capturing agent via proxy agent ( which can be HOMER)

To achieve that, load and configure the SipCapture module in the routing script.

Snippets fro Kamailio Homer docker installation as a collector

git clone https://github.com/sipcapture/homer-docker.git
cd homer-docker
docker-compose build
docker-compose up

Outsnippets from screen while the installation takes place

Creating network "homer-docker_default" with the default driver
Creating volume "homer-docker_homer-data-semaphore" with default driver
Creating volume "homer-docker_homer-data-mysql" with default driver
Creating volume "homer-docker_homer-data-dashboard" with default driver
Pulling mysql (mysql:5.6)...
5.6: Pulling from library/mysql
...
Creating mysql ... done
Creating homer-webapp   ... done
Creating homer-cron      ... done
Creating homer-kamailio  ... done
Creating bootstrap-mysql ... done
Attaching to mysql, homer-webapp, bootstrap-mysql, homer-cron, homer-kamailio
....
homer-webapp | Homer web app, waiting for MySQL
homer-cron   | Homer cron container, waiting for MySQL
homer-kamailio | Kamailio, waiting for MySQL
bootstrap-mysql | Mysql is now running.
bootstrap-mysql | Beginning initial data load....
bootstrap-mysql | Creating Databases...
bootstrap-mysql | Creating Tables...
.....
omer-kamailio | Kamailio container detected MySQL is running & bootstrapped
homer-kamailio |  0(22) INFO: <core> [core/sctp_core.c:75]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module
homer-kamailio |  0(22) WARNING: <core> [core/socket_info.c:1315]: fix_hostname(): could not rev. resolve 0.0.0.0
homer-kamailio | config file ok, exiting...
homer-kamailio | loading modules under config path: //usr/lib/x86_64-linux-gnu/kamailio/modules/
homer-kamailio | Listening on 
homer-kamailio |              udp: 0.0.0.0:9060
homer-kamailio | Aliases: 
homer-kamailio | 
homer-kamailio |  0(23) INFO: <core> [core/sctp_core.c:75]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module
homer-kamailio |  0(23) WARNING: <core> [core/socket_info.c:1315]: fix_hostname(): could not rev. resolve 0.0.0.0
homer-kamailio | loading modules under config path: //usr/lib/x86_64-linux-gnu/kamailio/modules/
homer-kamailio | Listening on 
homer-kamailio |              udp: 0.0.0.0:9060
homer-kamailio | Aliases: 
homer-kamailio | 
homer-kamailio |  0(23) INFO: sipcapture [sipcapture.c:480]: parse_table_names(): INFO: table name:sip_capture
...
homer-webapp | Homer web app container detected MySQL is running & bootstrapped
homer-webapp | Module php5 already enabled

Capture tools

Dialoge module

storing dialogs in mysql DB , requires initialising mysql

#!define WITH_MYSQL
...
#!ifdef WITH_MYSQL
loadmodule "db_mysql.so"
#!endif
...
#!ifdef WITH_MYSQL
# - database URL - used to connect to database server by modules such
#       as: auth_db, acc, usrloc, a.s.o.
#!ifndef DBURL
#!define DBURL "mysql://root:kamailio@localhost/kamailio"
#!endif
#!endif

loadmodule "dialog.so"
# ----- dialog params ------
modparam("dialog", "dlg_flag", 10)
modparam("dialog", "track_cseq_updates", 0)
modparam("dialog", "dlg_match_mode", 2)
modparam("dialog", "timeout_avp", "$avp(i:10)")
modparam("dialog", "enable_stats", 1)
modparam("dialog", "db_url", DBURL)
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_update_period", 120)
modparam("dialog", "table_name", "dialog")

seting db_mode – synchronisation of dialog information from memory to an underlying database has following options
0 – NO_DB – the memory content is not flushed into DB;
1 – REALTIME – any dialog information changes will be reflected into the database immediately.
2 – DELAYED – the dialog information changes will be flushed into DB periodically, based on a timer routine.
3 – SHUTDOWN – the dialog information will be flushed into DB only at shutdown – no runtime updates.

note :

• use the same hash_size while using diff kamailio to restore dialogs

database table for dialogue

1. install mysql
2. define root ( with db create permissions ) and user ( with database read wrote ) permission in kamctlrc

vi /usr/local/etc/kamailio/kamctlrc

• Dialogue table schema *

name type size default null key extra attributes description
id unsigned int 10 no primary autoincrement unique ID
hash_entry unsigned int 10 no Number of the hash entry in the dialog hash table
hash_id unsigned int 10 no The ID on the hash entry
callid string 255 no Call-ID of the dialog
from_uri string 128 no URI of the FROM header (as per INVITE)
from_tag string 64 no identify a dialog, which is the combination of the Call-ID along with two tags, one from participant in the dialog.
to_uri string 128 no URI of the TO header (as per INVITE)
to_tag string 64 no identify a dialog, which is the combination of the Call-ID along with two tags, one from participant in the dialog.
caller_cseq string 20 no Last Cseq number on the caller side.
callee_cseq string 20 no Last Cseq number on the caller side.
caller_route_set string 512 yes Route set on the caller side.
callee_route_set string 512 yes Route set on on the caller side.
caller_contact string 128 no Caller's contact uri.
callee_contact string 128 no Callee's contact uri.
caller_sock string 64 no Local socket used to communicate with caller
callee_sock string 64 no Local socket used to communicate with callee
state unsigned int 10 no The state of the dialog.
start_time unsigned int 10 no The timestamp (unix time) when the dialog was confirmed.
timeout unsigned int 10 0 no The timestamp (unix time) when the dialog will expire.
sflags unsigned int 10 0 no The flags to set for dialog and accesible from config file.
iflags unsigned int 10 0 no The internal flags for dialog.
toroute_name string 32 yes The name of route to be executed at dialog timeout.
req_uri string 128 no The URI of initial request in dialog
xdata string 512 yes Extra data associated to the dialog (e.g., serialized profiles).

Siptrace module

SIPtrace module offer a possibility to store incoming and outgoing SIP messages in a database and/or duplicate to the capturing server (using HEP, the Homer encapsulation protocol, or plain SIP mode).

loadmodule "siptrace.so"
modparam("siptrace", "duplicate_uri", "sip:127.0.0.1:9060")
modparam("siptrace", "hep_mode_on", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag", 22)
modparam("siptrace", "trace_on", 1)

integrating iut with request route to start duplicating the sip messages

sip_trace();
setflag(22);

• trace_mode * 1 – uses core events triggered when receiving or sending SIP traffic to mirror traffic to a SIP capture server using HEP 0 – no automatic mirroring of SIP traffic via HEP.

duplicate

address in form of a SIP URI where to send a duplicate of traced message. It uses UDP all the time.

modparam("siptrace", "duplicate_uri", "sip:127.0.0.1:9060")

to check the duplicate messages arriving

ngrep -W byline -d any port 9060 -q

RPC commands

Can ruen sip trace on or off

kamcmd> siptrace.status on   
Enabled

and to check

kamcmd> siptrace.status check
Enabled

Store sip_trace in database

modparam("siptrace", "trace_to_database", 1)
modparam("siptrace", "db_url", DBURL)
modparam("siptrace", "table", "sip_trace")

where the sip_trace tabel description is

+-------------+------------------+------+-----+---------------------+----------------+
| Field       | Type             | Null | Key | Default             | Extra          |
+-------------+------------------+------+-----+---------------------+----------------+
| id          | int(10) unsigned | NO   | PRI | NULL                | auto_increment |
| time_stamp  | datetime         | NO   | MUL | 2000-01-01 00:00:01 |                |
| time_us     | int(10) unsigned | NO   |     | 0                   |                |
| callid      | varchar(255)     | NO   | MUL |                     |                |
| traced_user | varchar(128)     | NO   | MUL |                     |                |
| msg         | mediumtext       | NO   |     | NULL                |                |
| method      | varchar(50)      | NO   |     |                     |                |
| status      | varchar(128)     | NO   |     |                     |                |
| fromip      | varchar(50)      | NO   | MUL |                     |                |
| toip        | varchar(50)      | NO   |     |                     |                |
| fromtag     | varchar(64)      | NO   |     |                     |                |
| totag       | varchar(64)      | NO   |     |                     |                |
| direction   | varchar(4)       | NO   |     |                     |                |
+-------------+------------------+------+-----+---------------------+----------------+

sample databse storage for sip traces

select * from sip_trace;

| id | time_stamp          | time_us | callid  | traced_user | msg         | method | status | fromip                   | toip                     | fromtag  | totag    | direction |
+----+---------------------+---------+---------------------------------------------+-------------+-----------------------------------
|  1 | 2019-07-18 09:00:18 |  417484 | MTlhY2VmNDdjN2QxZGM5ZDFhMWRhZThhZDU4YjE0MGM |             | INVITE sip:altanai@sip_addr;transport=udp SIP/2.0
Via: SIP/2.0/UDP local_addr:25584;branch=z9hG4bK-d8754z-1f5a337092a84122-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:derek@call_addr:7086;transport=udp>
To: <sip:altanai@sip_addr>
From: <sip:derek@sip_addr>;tag=de523549
Call-ID: MTlhY2VmNDdjN2QxZGM5ZDFhMWRhZThhZDU4YjE0MGM
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: Bria 3 release 3.5.5 stamp 71243
Content-Length: 214

v=0
o=- 1563440415743829 1 IN IP4 local_addr
s=Bria 3 release 3.5.5 stamp 71243
c=IN IP4 local_addr
t=0 0
m=audio 59814 RTP/AVP 9 8 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv                                                                                                                                                                                      | INVITE |        | udp:caller_addr:27982 | udp:sip_pvt_addr:5060   | de523549 |          | in        |

|  2 | 2019-07-18 09:00:18 |  421675 | MTlhY2VmNDdjN2QxZGM5ZDFhMWRhZThhZDU4YjE0MGM |             | SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP local_addr:25584;branch=z9hG4bK-d8754z-1f5a337092a84122-1---d8754z-;rport=27982;received=caller_addr
To: <sip:altanai@sip_addr>
From: <sip:derek@sip_addr>;tag=de523549
Call-ID: MTlhY2VmNDdjN2QxZGM5ZDFhMWRhZThhZDU4YjE0MGM
CSeq: 1 INVITE
Server: kamailio (5.2.3 (x86_64/linux))
Content-Length: 0                                                                                                                                                                                                                                                                                                                                                                                                                                                           | ACK    |        | udp:caller_addr:27982 | udp:local_addr:5060   | de523549 | b2d8ad3f | in       |
...
+----+---------------------+---------+---------------------------------------------+-------------+-----------------------------------

Heplify

Multi-Protocol Go HEP Capture Agent made   https://github.com/sipcapture/heplify

wget https://dl.google.com/go/go1.11.2.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.11.2.linux-amd64.tar.gz

move package to /usr/local/go

mv go 

Either add go bin to ~/.profile

export PATH=$PATH:/usr/local/go/bin

and apply

source ~/.profile

or set GO ROOT , and GOPATH

export GOROOT=/usr/local/go
export GOPATH=$HOME/heplify
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

installation of dependencies

go get

clone heplify repo and make

make 

CAPTAGENT

New OSS Capture-Agent framework with capture suitable for SIP, XMPP and more. With internal method filtering , encryption and authetication this does look very promising howevr since I have perosnally not tried it yet , I will leave this space TBD for future

• tbd
• http://github.com/sipcapture/captagent

sngrep

https://github.com/irontec/sngrep

Other include Sipgrep , HEPipe and nProbe

HEPop

Multi-Protocol HEP Server & Switch in NodeJS. stand-alone HEP Capture Server designed for HOMER7 capable of emitting indexed datasets and tagged timeseries to multiple backends

https://github.com/sipcapture/HEPop

node hepop.js -c /app/myconfig.js

PCAP monitoring -> Homer Server -> Notification and Fraud Prevention

A realtime monitoring and alerting setup fom homer can best safeguard on VoIP specific attacks and suspecious activity by early warning . Some list of attacks such as DDOS , SIP SQL injections , parser , remote manipulation hijacking as cell as resource enumeration are common ifor a cloud telephony provider.

Adiitionally homer provide session quality using varables that include [1]

SD = Session Defects
[SUM(500,503,504)]

ISA = Ineffective Session Attempts
[SUM(408,500,503)]

AHR = Average HOP Requests

ASR = Answer Seizure Ratio
[(‘200’ / (INVITES – AUTH – SUM(3XX))) * 100]

NER = Network Efficiency Ratio
[(‘200’ + (‘486′,’487′,’603’) / (INVITES -AUTH-(SUM(30x)) * 100]

HOMER Web Interface or Custom Dashboard

Some more visualization for inter team communication such as NOC team can include

Homer Integration with influx DB

time series Reltiem DB install

wget https://dl.influxdata.com/influxdb/releases/influxdb_1.7.7_amd64.deb
sudo dpkg -i influxdb_1.7.7_amd64.deb

start

 >influxd
 8888888           .d888 888                   8888888b.  888888b.
   888            d88P"  888                   888  "Y88b 888  "88b
   888            888    888                   888    888 888  .88P
   888   88888b.  888888 888 888  888 888  888 888    888 8888888K.
   888   888 "88b 888    888 888  888  Y8bd8P' 888    888 888  "Y88b
   888   888  888 888    888 888  888   X88K   888    888 888    888
   888   888  888 888    888 Y88b 888 .d8""8b. 888  .d88P 888   d88P
 8888888 888  888 888    888  "Y88888 888  888 8888888P"  8888888P"

2019-07-19T07:03:04.603494Z	info	InfluxDB starting	{"log_id": "0GjGVvbW000", "version": "1.7.7", "branch": "1.7", "commit": "f8fdf652f348fc9980997fe1c972e2b79ddd13b0"}
2019-07-19T07:03:04.603756Z	info	Go runtime	{"log_id": "0GjGVvbW000", "version": "go1.11", "maxprocs": 1}
2019-07-19T07:03:04.707567Z	info	Using data dir	{"log_id": "0GjGVvbW000", "service": "store", "path": "/var/lib/influxdb/data"}

For Kamailio integration follow github instructions on https://github.com/altanai/kamailioexamples

References :

[1] https://www.kamailio.org/events/2013-KamailioWorld/13-Alexandr.Dubovikov-Homer-SIP-Capture.pdf

[2] HEP/EEP – https://github.com/sipcapture/hep

[3] kamailio sipdump module – https://www.kamailio.org/docs/modules/devel/modules/sipdump.html

[4] https://github.com/sipcapture/HEPop

[5] HOMER Big Data – https://github.com/sipcapture/homer/wiki/Homer-Bigdata

Just like a regular IT datacentre , storage, computing power and network capacity define the usage of the server.Also unobstructed electricty of of paramount importance as any blackout could drop ongoing calls and lead to loss of revenue for the service provider not to forget the loss caused to parties engaged in call.

Increasing Power consumption by telecom Sector over the years

Typical VoIP Setup : Whether a cloud Infrstrcture provider of a hosted data centre , an aproximate number of 7 servers is required even for SME ( small to medium enterprises ) communication system and VoIP systems

• 2 signalling servers primary and standby for HA ,
• 2 media server for MCU of media bridges or IVR playback etc ,
• 1 for CDR , logs or call analytics , stats and other supplementary operation
• 1 for dev or engineering team .
• 1 edge server could be API server or a gateway or laodbalancer.

VoIP solutions are more energy expensive, unless aggressive power saving schemes are in place

Comparison of energy efficiency in PSTN and VoIP systems [14]

While PSTN and other hybrid scenarios relied on audio only communication the embedded systems involved took great pain to make then energy efficient which is not really the case with all digital and software based VoIP.

Power Consumption

Mobile phone :  Typical smartphone with 4,000mAh ( 4 Ah) battery that gets 1 full cycle of usage a day. Daily consumption =4Ah*3.7V=14.8 Wh

Laptop : With  14–15″ screen, a laptop can draw 60 watts power in active use depending on model. Runing 8 hours a day can be 60 * 8 = 480 Wh ( 0.480 kWh) energy consumed in a day.

Desktop PC : Runing at 50-60 Hz frequency , can upto draw 200 W power in active use. For 8 hours energy usage 200 * 8 = 1600 Wh ( 1.6 kWh ) energy a day.

Server : Even though servers are virtual to the request maker , they caters to the request on the other end of the internet.

Typically runing on 850 Wh ( 0.850 kwh ) of energy in an hour and since server are usually up 24*7 that totals to

0.850 * 24 = 20.4 kWh a day [2].

VoIP System ( 7 VM’s) : For a setup of 7 VM’s ( could on a the same PM), total energy consumed in a day

20.4 * 7 = 142.8 kWh.

Data centre: The data centre building consists of the infrastructure to support the servers, disks and networking equipment it contains. However, for simplicity, I will only use the consumption of servers and ignore the cooling units, networking, backup batteries charging, generators, lightning, fire suppression, maintenance etc.

High tier DC can have 100 Megawatts of capacity having each rack was using 25 kW of power in a 52U Rack. 100,000 kW / 25 kW = 4,000 racks * 52(U) = 208000 1U servers. This number scales down depending on how much energy each server uses and idle servers.

Total energy 100,000 kW * 24 hours = 2400000 kWh

Carbon Footprint

Carbon footprint in the context of this article refers to the amount of greenhouse gas ( consisting majorly of Co2) caused by electricity consumption. The unit is carbon emission equivalent of the total amount of electricity consumed kg CO2 per kWh.

In doing this calculation I have assumed 0.233 kg CO2 per kWh which could be less or more depending on the generation profile of the electricity provider as well as the heat produced by the machine.

Laptop: Aside from the production which could be 61.4 kg (135.5 lbs) of Co2, a 60W laptop will produce 0.112 kg co2 eq per day.

Desktop PC: Aside from production cost and heating, the GWG and co2 eq emission from running a desktop for a day ( 8 hours) produces 1.6* 0.233 = 0.3728 kg CO2 per kWh

Server : 20.4 * 0.233 = 4.7532 kg CO2 per kWh per day .

VoIP System ( 7 VM’s): Again ignoring the GWG emission of associated components, 142.8 * 0.233 = 33.2724 kg CO2 per kWh per day. It is to be noted that DC’s ( datacentres) use the term PUE ( Power Usage Effectiveness) to showcase their energy efficiency and energy efficiency certification uses the same in ratings.

Data centre: electrical carbon footprint( approximate calculation not counting the cooling, infra maintenance, lightning and possibly idle servers in datacentre) is 2400000 * 0.233 = 559200 kg CO2 per kWh per day

It is to be noted that a common figure should not be extrapolated like this to derive carbon emission. The emission depends on the fuel mix of the electricity generation as well as the life cycle assessment (LCA) of carbon equivalent emission. Countries with heavy reliance on renewables have lower co2 footprint per kWh ~ 0.013 kg co2 per kWh Sweden while others may have higher such as 0.819 kg CO2 per kWh Estonia [1].

Flatten the Curve from Tech and Internet usage

Rack servers tend to be the main perpetrators of wasting energy and represent the largest portion of the IT
energy load in a typical data center.

A decade ago, small enterprise IT facilities were quick to create data centres for hosting applications from hospitals, banks, insurance companies. While some of these is likely to have been upgrade to shared server instances runing on IaaS providers, most of them are still serving traffic or stays there for the lack of effort to upgrade.

With the advancement in p2p technlogies such as dApps , bitcoion network , p2p webrtc streaming , more edge computed ML continue to create disruptions in existing trend , most likely to result in in many fold increase in consumption.

According to the Cambridge Center for Alternative Finance (CCAF), Bitcoin currently consumes around 110 Terawatt Hours per year — 0.55% of global electricity production

Harward Business Review [12]

“the emissions generated by watching 30 minutes of Netflix (1.6 kg of CO₂) is the same as driving almost four miles.” 

EnergyInnovation [13]

Cloud Computing and Energy efficiency

Cloud computing ( SaaS, PaaS , IaaS and also CPaaS) minimize power consumption and consequently IT costs via virtualization, clustering and dynamic configuration.

With cloud infrastrcture vendors such as Amazon , Google , microsoft .. and their adoption of energy efficiency computing and credible transparency has alleviated some of the stress that could have been made if onsite self – hosted data centres were used as often in mainstream as a decade ago.

Even as cloud providers gives on -demand access to shared resources in large scale distributed computing , the ease of getting on board has inturn created a surge in cloud hosted online applications consequently high power consumption, more operation costs and higher CO₂ emissions.

Components of energy Consumption in Data Centre

As shown CPU, Memory, and Storage incur 45% of the costs and consume 26% of the total energy , however power distribution and colling cost 25% but consumer >50% of total energy.

Energy forcast for Data Centres

As reported by nature [3] the widely cited forcasts suggested thte total electrcity demand of ICT ( Informatioin and Communication technology ) will accelerate and while consumer devices such as smart TV , laptops and mobile are becoming energy effcient , the data centres and network devices will demand bigger portions. Reported in 2018 , 200 Twh( terawatt hours) of energy was being consumed by data centers . Although there are no figures for the telecom or specifically IP cloud telephony , the assumption that enormous multimedia data flows in every session is enouogh to assume the figure must be huge.

Energy eficiency in data centres have also been the subject of many papers and studies. Many of the tech advancements and measures have so far been able to keep the growth in energy requirnments by tech sector to a linear/ flat one.

Some noteworthy innovations made in Data centre for energy efficiency include –

1. Star efficiency requirnments

• Average server utilization
• Server power scaling at low utilization
• Average power draw of hard disk drives
• Average power draw of network ports
• Average infrastructure efficiency (i.e., PUE)

PUE = Total Facility power / IT equipment power

Standard 2.0, Good 1.4 , Better 1.1

Low PUE indicates greater efficicny since more power would then be used by It gear . Idealistically 1 should be the perfect score where all power was used only by the IT gears.

2. Optimizing the cooling system which takes a lot of focus is also not touched upon here but can be understood in great detail from very many sources including one here on how google uses AI for cooling its Datacentres [6]

3. Throttle-down drive ,a device that reduces energy consumption on idle processors, so that when a server is running at its typical 20% utilization it is not drawing full power

Energy efficiency is vital to not only productivity and performance but also to carbon neutral tech and economy. There is ample scope to designing energy efficient applications and platfroms. Some approaches are described below:

Energy Efficiency in VoIP Architecture and design

Low Energy consumption not only lowers operating cost but also helps the enviornment by reducing carbon emission.

1.Server Virtualization

By consolidating multiple independant servers to a single underlying physical server helps retain the logical sepration while also maintaining the energy costs and maximizinng utilization . VM’s( Virtual machines) are instances of virtaulized portions on the same server and can be independetly accesed using its own IP and network settings.

To reduce electricity usage in our labs and data centers, we use smart power distribution units to monitor
our lab equipment. We increase server utilization by using virtual machines. Our Cisco Customer
Experience labs use a check-in, check-out system of automation pods to allow lab employees to set up
configurations virtually and then release equipment when they are finished with it.

Cisco 2020 Environment Technical Review [20]

Models to place VMs on PM ( physical machine ) have been proposed by Dong et al[8] , Huang[9]  ,Tian et al [10]

2.Decommissioning old / outdated servers

While this is the most obvious way to increase efficiency , it is also the toughest since legacy applications or a small portion of it may be running on a server that service providers are not keen on updating or updates do not exist and it is past end of life yet somehow still in use. It is important to identify such components. Check if maybe an old glassfish or bea weblogic SIP servlet server needs updating and/or migration !

3.Plan HA ( high availability ) efficiently

Redundant servers take only if at all any , partial loads so they can be activated in full swing when failover happens in other server. With quick load up times and forward looking monitoring , the analyzers can monitor logs for upcoming failure or predictable downtime and infra script can bring up pre designed containers in seconds if not minutes. It isn’t wise to create more than 1 standby server which does no essential work but consumes as much power.

4.Consolidate individual applications on a Server

Map the maximum precitable load and deduce the percentage comsuption with teh same . In view of these figures it is best to consolidate applications servers to be run on a single server . A distributed microservice based architecture can also support consolidation by runing each major application in its own dockerized container. Consolidation ensures that

• All data can be stored and accessed centrally, which reduces the likelihood of data duplication.
• while a server is drawing full power , it is also showing relataible utilization.
• Single point to prevent intrusion , provide security and fix vulnerabilities against malware like ( ransomware , viruses , spyware , trojans)

5.Reduce redundancy

While it is a common practise to store multiple copies of data such as CDR ( call detail records ) and archiev historical logs for later auditing , it is not the most energy efficient way since it ends up wasting stoarge space. It is infact a better approach to skim only the crtical parts and diacard the rest and definetely implement background tasks to compress the older and less referenced logs.

6.Power management

Powering down idle server or putting unused server to sleep is an effective way to reduce operating power but is often ignored by the IT department in view of risking slower performance and failure in call continuity in case a server does go down. However power management leads to potential energy savings and should be weighted accordingly.

7.Common Storage such as Network Attached Storage

Power consumption is roughly linear to the number of storage modules used. Storage redundancy needs to be
right-sized to avoid rapid consumption of avaible storage space , CPU cycles to refer and index them, its associated power consumption [7].

The process of maximizing storage capacity utilization by drawing from a common pool of shared storage on need baisis also allows for flexixbility.

It is sensible to take the data offline thereby reducing clutter on production system and make the existing data quickly retrievable.

8.Sharing other IT resources

Central Processing Units (CPU), disk drives, and memory optimizes electrical usage. Short term load shifting combined with throttling resources up and down as demand dictates improves long term hardware energy efficiency. [7]

Hardware based approaches such as energy star rating, air conditoning , placement of server racks , air flow , cabling etc have not been touched upon in this article they can be read from energystar report here [5] .

9. DMZ / Perimeter network

The perimeter network (also known as DMZ, demilitarized zone, and screened subnet) is a zone where resources and services accessible from outside the organization are available. Often used as barrier between internal secure green zone within company and outside partners / suppliers such as external organization gateways.

• Load balancers
• API gateways
• SBC ( Session Border controllers)
• Media Gateways

Ways to cut down on CPU consumption in DMZ machines

1. Scrutinize incoming traffic only , trust outgoing traffic .

2. Use hardware / network firewalls to monitor and block instead of software defined ones . Hardware firewall can be a standalone physical device or form part of another device on your network. Physical devices like routers, for example, already have a built-in firewall. 

Other types of firewalls

• Application-layer firewalls can be a physical appliance, or software-based, like a plug-in or a filter. These types of firewalls target your applications. For example, they could affect how requests for HTTP connections are inspected across each of your applications.
• Packet filtering firewalls scrutinize each data packet as it travels through your network. Based on rules you configure, they decide whether to block the specific packet or not. For example firewalls can block SSH/RDP for remote management.
• Circuit-level firewalls check whether TCP and UDP connections across your network are valid before data is exchanged. For example, this type of firewall might first check whether the source and destination addresses, the user, the time, and date meet certain defined rules.
• Proxy server firewalls secure the traffic into and out of a network by monitor, filter, and cache data requests to and from the network.

Energy Efficiency in VoIP Applications and algorithms

In theory, energy efficient algorithms would take less processing power , run fewer CPU cycles and consume less memory. For the experiments with WebRTC and SIP VoIP systems CPU performance can be reliable factor to consider for carbon emissions . Here is list of approaches to include energy as of the parameters in programing for RTC applications.

1. Take advanatge of Multi Core applications

Multi-core processor chips allow simultaneous processing of multiple tasks, which leads to higher efficiency. Same power source and shared cooling leads to better efficiency . It is the same logic which applied to consolidating one power supply for a rach isntead of individual power supply to each servers on rack.

2. Reduce Buffering

Input/Output buffer pile up comuted packets or blocks which will come inot use in near future but may be discarded all together in event of skip or shutdown. For example in case of video on Demand ( VoD) , a buffered video of 1 hour is of not much use if viewer decides to cancel the video session after 10 minutes .

3. Optimize memeory access algorithms

4. Network energy Management to vary as per demand

The newer generations of network equipment pack more throughput per unit of power. There are active energy management measures that can also be applied to reduce energy usage as network demand varies. In a telecoomunication system , almost always a tradeof between power consumption and network performance is made.

1. Quick switching of speed of the network to match the amount of data that is currently transmitted. A demand following streaming session will maingtain the QoS , avoid imbalance while also reducing power consumption.

2. Avoid sudden burst and peaks and/or align them with energy availaibility .

Metrics

• computational performance (i.e., computations/second per server),
• electrical efficiency of computations (i.e., computations per kWh),
• storage capacity (i.e., TB per drive), and
• port speeds (i.e., Gb per port)

5. Task Scheduling algorithms

Some recent researched frameworks and models take Co2 emission into prespective , while allocating resources according to queuing model. The most efficient ones not only bring down the carbon footprint but also the high operating cost [11].

Scheduling and monitoring techniques have been applied to achieve a cost effective and power-aware cloud environment by reducing the resource exploitation

6. Centralised operation – RTP topology ( Mesh , MCU and SFU)

Instead of operating many servers at low CPU utilization, at edge of client’s end, combines the processing
power onto fewer servers that operate at higher utilization.

Modern machine learning programs are computationally intensive, and their integration in VoIP systems for tagging , sentiment analysis , voice quality analysis is increasingly adding additional strain already heavy processing of media server in transcoding and multiplexing .

As an example a SFU client sends one upstream but receives 4 downstreams which reduces the load on server but increases on clients .

7. Distributing workload based on server performance

Aggregating tasks and runing them as Serverless , asynchronous jobs instead of standalone processes is very efficient way to cut down idle runing wastage. Additioally catagorizing server workloads based on server performance can also reduce power consumption by using idle servers efficiently. Thermal aware workload distribution also helps reducing power consumption and consequently electricity consumption in cooling .

8 . Reduce reauthetication and challemge response mechanism when it can be avoided.

There exists multiple modes to authenticate and authorize users and application access to server content

Over the network

• password based auth ,
• third party based auth ( Oauth)
• 2 factors authetication( phone/sms based) ,
• multi factor auth ( sms / email / other media) ,
• token auth ( custom USB device/ smart card ) ,
• biometric auth (physical human charecteristics / scanners ) ,
• transactional auth ( location , hour of day , browser/ machine type)

Computer recognition authentication

• CAPTCHA
• Single sign-on

Authentication protocols

• Kerbos – Key Distribution Center (KDC) using a Ticker gransting Server ( TGS)
• TLS/SSL

A callflow involves AAA while creating the session and may require occsional re authetication to reafform the user is intended one. Doing re-authtication too often increases the power consumption and can be countered by caching and timeout mechanism.

Point of presence and handover using Carbon footprint in different demographics

1. Include Carbon emission from Datacentre in condieration before engaging the server in call path from load balancer gateway

2. Use point of presence ( PoP) for server according to their carbon emission factor in the demography .

Energy Efficiency in WebRTC browser applications and native applications

In a Video conferencing the over browser, WebRTC has emerged as te the default standard . The efficiency of sch webrtc browser based video conferencing web applications can be enhanced in the following ways :

1.Use VoIP Push Notifications to Avoid Persistent Connections

2. Voice Activity detection ( Mute the spectators ) and join with video true , audio false for attendeees

Energy efficiency in VoIP phones

If all eligible VoIP phones sold in the United States were ENERGY STAR certified, the energy cost savings would grow to more than $65 million each year and 1.2 billion pounds of annual greenhouse gas emissions would be prevented, equivalent to the emissions from more than 119,000 vehicles.

Energystart [15]

Low-energy-consuming embedded hardware on most phones keep the average consumption low . A analog phone can consume power between 0.07 W to 9.27 W while a VoIP phone can consume 0.1W to 3.5 W of standby power.

Off mode power is often less than standby power since phone is on low power model during idle hours such as night . According to energy star Sund transmission mechnism also plays a key role and hybrid phones consume more power.

Power allowance for each of the below features of the device:

• 1.0 watt for Gigabit Ethernet
• 0.2 watt for Energy Efficiency Ethernet 802.3az compliant Gigabit Ethernet

Additional proxy incentive(W) for the ability to maintain network presence while in a low power mode and intelligently wake when needed

• 0.3 watt for base capability
• 0.5 watt for remote wake

Government bodies and groups to track Energy efficiency of Telecom and IP telephony

• Alliance for Telecommunications Industry Solutions (ATIS)
• Telecommunications Energy Efficiency Ratio (TEER)
• measurement method covers all power conversion and power distribution from the front end of the
  system to the data wire plug, including application-specific integrated circuits (ASICs).
• European Telecommunications Standards Institute (ETSI)
• International Telecommunication Union (ITU)
• U.S. Department of Energy (DOE), Environmental Protection Agency (EPA)

External links

Amazon : https://sustainability.aboutamazon.com/environment/sustainable-operations/carbon-footprint

Cisco : https://www.cisco.com/c/dam/m/en_us/about/csr/esg-hub/_pdf/2020_Environment_Technical_Review.pdf

3CX : https://askozia.com/voip/how-can-i-save-energy-with-green-voip-and-my-ip-pbx/

The purpose of the article is to raise awareness about carbon footprint from application programs to archietcture designs techniques to data centres and commuulative performance. It gives a direction to stakeholders (customers , programmers , architects , mangers , … ) to choose less carbon emitting approach whenever possible since every bit counts to help the environment.

References

[1] rensmart.com https://www.rensmart.com/Calculators/KWH-to-CO2

[2] https://www.zdnet.com/article/toolkit-calculate-datacenter-server-power-usage/

[3] nature : https://www.nature.com/articles/d41586-018-06610-y

[4] Center of Expertise for Energy Efficiency in Data Centers at the US Department of Energy’s Lawrence Berkeley National Laboratory in Berkeley, California. https://datacenters.lbl.gov/

[5] energy Star – https://www.energystar.gov/sites/default/files/asset/document/DataCenter-Top12-Brochure-Final.pdf

[6] https://www.blog.google/inside-google/infrastructure/safety-first-ai-autonomous-data-center-cooling-and-industrial-control/

[7] https://www.energy.gov/sites/default/files/2013/10/f3/eedatacenterbestpractices.pdf

[8] Yin K, Wang S, Wang G, Cai Z, Chen Y. Optimizing deployment of VMs in cloud computing environment. In: Proceedings of the 3rd international conference on computer science and network technology. IEEE; 2013. p. 703–06.

[9] Huang W, Li X, Qian Z. An energy efficient virtual machine placement algorithm with balanced resource utilization. In: Proceedings of the seventh IEEE international conference on innovative mobile and internet services in ubiquitous computing; 2013. p. 313–19.

[10] W. Tian, C.S. Yeo, R. Xue, Y. Zhong Power-aware schedulingof real-time virtual machines in cloud data centers considering fixed processing intervalsProc IEEE, 1 (2012), pp. 269-273

[11] H. Chen, X. Zhu, H. Guo, J. Zhu, X. Qin, J. Wu Towards energy-efficient scheduling for real-time tasks under uncertain Cloud computing environmentJ Syst Softw, 99 (2015), pp. 20-35

[12] https://hbr.org/2021/05/how-much-energy-does-bitcoin-actually-consume

[13] https://energyinnovation.org/2020/03/17/how-much-energy-do-data-centers-really-use/

[14] F. Bota, F. Khuhawar, M. Mellia and M. Meo, “Comparison of energy efficiency in PSTN and VoIP systems,” 2012 Third International Conference on Future Systems: Where Energy, Computing and Communication Meet (e-Energy), 2012, pp. 1-4, doi: 10.1145/2208828.2208834. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.720.446&rep=rep1&type=pdf

[15] https://www.energystar.gov/products/office_equipment/voice_over_internet_protocol_voip_phone

[16] egrid summary table 2018 for carbon emission rate in Us states : https://www.epa.gov/sites/default/files/2020-01/documents/egrid2018_summary_tables.pdf

[17] UK greenhourse gas reporting – https://www.gov.uk/government/publications/greenhouse-gas-reporting-conversion-factors-2018

[19] http://assets.worldwildlife.org/publications/575/files/original/The_3_Percent_Solution_-_June_10.pdf?1371151781

[20] https://www.cisco.com/c/dam/m/en_us/about/csr/esg-hub/_pdf/2020_Environment_Technical_Review.pdf

[21] It’s Not Easy Being Green by Peter Xiang Gao, Andrew R. Curtis, Bernard Wong, S. Keshav
Cheriton School of Computer Sc https://dl.acm.org/doi/pdf/10.1145/2342356.2342398

With the dawn of IP telephony service and cloud communication platforms in recent years, the SIP has caught the attention of many application developers. while SIP is essentially a session management multimedia signalling protocol its generic stack can be used for various use cases from IoT camera streaming sessions to call centres even auto calling for purpose of sharing OTP(one-time password) etc. In this I will highlight the usecase of large calltraffic and the use of SIP trunks.

SIP based trunking can provide significant cost savings and business process improvements by supporting the native SIP protocol that controls the VoIP systems used in call centres and business communication platforms.

• (+) unified communication
• (+) lower telco network
• (+) streamline operations for multicountry/ geography

Traditional trunk call

In the past, telephone systems used trunk lines to connect different parts of the network. Trunk lines were long-distance communication lines that connected telephone exchanges in different locations. Trunk calls were calls made over these trunk lines. They were typically used for long-distance communication, as they allowed calls to be made between exchanges that were geographically far apart. Trunk calls were generally more expensive than local calls, as they involved the use of long-distance communication lines.

Traditional trunk calls operated like a circuit with local loops , trunk lines and switching offices. The telco acted as carriers that sell of lease communication lines to facilitate communication over long distances using local exchanges and interexchange carriers.

In the early days of telephone systems, trunk lines were typically made of copper wires or cables. Later, trunk lines were replaced with satellite links and fiber optic cables, which provided higher capacity and faster transmission speeds. Today, with the widespread adoption of VoIP (Voice over Internet Protocol) technology, many telephone systems no longer use trunk lines in the traditional sense. Instead, they use virtual connections, such as SIP trunks (Session Initiation Protocol trunks), which allow organizations to make and receive phone calls over the internet. SIP trunks are generally more flexible and cost-effective than traditional trunk lines, and do not require the installation of additional hardware.

Voice trunk Lines in SS7 based Next Generations IN networks used media gate ways and MGCP, H323 protocols

SIP trunk (older) systems

SIP is a protocol that is commonly used in VoIP (Voice over Internet Protocol) systems to set up, modify, and terminate sessions that involve the exchange of audio, video, and other media. SIP Trunks are virtual voice channels (or paths) which deliver media (voice, video, IM) over an IP network to a designated endpoint. SIP Trunks can be thought of as a virtual line or concurrent call path. SIP Trunks are delivered over an IP connection like Tier One Carrier or Voice Optimized Recommended or UDP. SIP Trunk may be over-subscribed ie can have more numbers than trunks for example G.711 – 17 calls over T1 or G.729a – 45 calls over T1. SIP Trunking can be provided as one-way or two-way lines. Direct Inward Dialing (DIDs) can be used for toll-free number service.

Centralized SIP Trunk Model

Centralized SIP Trunk Model is designed to aggregate all calls from all sites and funnels them into a single entry point. Each site has its own SIP trunk termination of the appropriate capacity for calls to and from that site.

Such SIP trunks models offer benefits in three significant areas:

1. Cost savings, arising from many factors including reduced telecommunications network charges and streamlined operations.
2. Unified communications, where voice, video, email, text and other messaging technologies are combined to provide greater flexibility for users by enabling new ways to transfer information and manage connectivity. Many SIP trunk providers offer advanced features such as call forwarding, call waiting, and voicemail, which can improve the overall communication experience for employees.
3. Business Continuity and Disaster Recovery, where the right physical configuration in conjunction with intelligence in the network can be leveraged to provide uninterrupted communications and alternative means to stay connected for employees in the event of system bottlenecks or failures.

SIP trunking is an IP-based alternative to ISDN trunking services

SIP Trunking is a low-cost IP-based alternative to ISDN offering for medium to large businesses needing upwards of several tens of channels in a trunk, often across multiple sites, with IP VPN access. 

• (+) Optimal utilization of bandwidth by delivering both data and voice in the same bandwidth

A telephony company such as a telecom service provider may expose SIP trunks as a means of connecting inbound or outbound calls through its telecom network. For the integrator ( or the service provider managing the other enedpoint of the call leg ) it can be no different that a traditional phone call.The SIP signalling however is useful for enabling better session understaning using standard SIP requests and responses as compared to SS7 or PRI lines.

Planning to set up SIP trunk

•Cost analysis
•Assess traffic volumes and patterns
•Assess network design implications
•Emergency call policy
•Define production user community phases
•Define user community to pilot
•Evaluate future new services
•Assess security precautions

The steps to set up a SIP trunk connection may vary depending on the specific provider and the equipment being used. However, here are some general steps that are often involved in the process:

1. Choose a SIP trunk provider: Research and compare different SIP trunk providers to find one that meets your organization’s needs and budget.
2. Sign up for a SIP trunk account: Follow the provider’s instructions to sign up for a SIP trunk account. This may involve completing an online form, providing contact information and payment details, and selecting the desired features and services.
3. Configure your VoIP phone system: Consult your VoIP phone system’s documentation to learn how to configure it to work with a SIP trunk. This may involve specifying the SIP trunk’s IP address and port number, as well as any authentication credentials that are required.
4. Test the connection: Once the SIP trunk is set up, it is a good idea to test the connection to ensure that it is working properly. Make a few test calls to verify that the connection is functioning as expected.
5. Use the SIP trunk: Once the SIP trunk is set up and tested, it can be used to make and receive calls using your VoIP phone system.

SIP Trunking platform has to integrate with multiple networks seamlessly. Components for setting up a SIP trunking system requires atleast these

• Compliance with standrad signalling protol, like SIP.
• SBC( Session Border Controller ) facing the private PBX
• Gateway for specific endpoints such as PSTN gateway , public internet gateway etc
• L3/L4 Layer switches
• Telco operator lines
• Codec support

Kamailio is an open-source SIP (Session Initiation Protocol) server that can be used to create a SIP trunk. Kamailio can be PBX used to connect different locations within an organization, enabling employees to communicate with each other using their VoIP phones. Kamailio can also be used to set up a SIP trunk in a number of ways. For example, it can be used to connect an organization’s VoIP phone system to the public telephone network, allowing employees to make and receive calls from outside the organization.

Kamailio is a highly flexible and customizable SIP server that can be configured to meet the specific needs of an organization. It offers a range of features and functionality, including call routing, load balancing, and security. Kamailio is a popular choice for organizations that want to set up a SIP trunk because it is open-source and can be customized to meet their specific needs.

Features of SIP trunking

SIP trunk with VoIP phone systems are often preferred over traditional phone systems because they are generally more flexible and cost-effective. They allow employees to make and receive calls from any device with an internet connection, including desk phones, smartphones, and laptops. They can be easily scaled up or down to meet changing communication needs and do not require the installation of additional physical hardware. Some factors to consider when evaluating SIP trunks include:

1. Cost: It is important to compare the costs of different SIP trunk providers and consider factors such as monthly fees, per-minute charges, and any additional fees for features or services.
2. Coverage: Make sure that the SIP trunk provider has coverage in the areas where your organization needs to make and receive calls.
3. Quality: The quality of a SIP trunk can vary greatly depending on the provider and the connection. Be sure to research the provider’s reputation for call quality and reliability.
4. Features: Different SIP trunk providers may offer different features, such as call forwarding, call waiting, and voicemail. Consider which features are important to your organization and make sure that the SIP trunk provider offers them.
5. Customer support: It is important to choose a SIP trunk provider that offers reliable customer support in case you experience any issues with your service.

Other features that are good to have is integration to existing backend for OSS/BSS stack. Some of the feature set for a carrier grade SIP trunking solution are listed here

• Inbound and outbound trunks
• Number Import/Export
• Security
  • Dynamic registeration of users
  • Authentication and Authorization
  • Security (SRTP)
• Cost Savings
  • Low cost for large traffic volumes instead of charges of call per second
  • CDR for tracing and monitoring call failures
• Clear media stream ( no robotic or choopy audio). Good MOS score
• realtime traffic monitoring to rule out bad players.
• Inbound and Outbound call – Call Establishment, Rejection, Termination
• DDI: Direct Dialling-In ranges can be provided on the SIP Trunk
• CLIP(Calling Line Identification Presentation )/CLIR Calling Line Identification Presentation Restriction) for Inbound and Outbound
• Call Management
  • AUTH Code Screening
  • Combined Screening
  • Data Call Screening
  • Local Screening
  • Anonymous Call Rejection: Anonymous Call Rejection
  • Incoming Call Barring: bar receiving of calls to certain extensions
  • Outgoing Call Barring: Restrict calls to certain numbers
  • Incoming Call Diversion – unconditional, busy, and unreachable
  • Call Admission Control: Call Admission Control (CAC) is a mechanism to restrict the number of simultaneous sessions (calls) 
  • Incoming Call Diversion (DestNo not reachable, CAC exceeded, unconditional)
• Geographic and Non-Geographic Number Support
• Multiple Codec Support
• Emergency Calling: Emergency Calls are routed on a priority basis irrespective of the customer’s available channel

Trunking inbound services voice can be used to support contact centres, conferencing, number translation services etc. Regulatory requirements for the operation of the customer in the PSTN of respective countries must be met with Country Specific Emergency Calling support Enhanced feature set for SIP trunking should include the features of the SIP Trunking with Multicountry support

• Enhanced CAC(Call Admission Control) – Directional & Network
• Global Dial Plan Support
• Proactive MCID (Malicious CallerId) Identification and tracing
• Call Distribution(CD)
• Intelligent Routing involving machine learning and constant feedback
  • Origin Based Routing
  • Menu Routing
  • Origin Dependent Routing (ODR)
  • PIN Routing
  • Dynamic Route Select
  • Time-Dependent Routing (TDR)
  • Uniform Load Distribution(ULD)
  • International Routing
  • Mobile Routing
  • Payphone Routing
• Product Association

Ultimately, the most useful SIP trunk for your organization will depend on your specific needs and budget. It is a good idea to research and compare different SIP trunk providers to find the one that best meets your organization’s needs.

Future of SIP trunks

SIP trunking systems are likely to continue to be an important part of the telecommunications landscape in the future. As more and more organizations adopt WebRTC or SRT based VoIP (Voice over Internet Protocol) technology for their phone systems, the demand for SIP trunks is likely to continue to grow. One trend that is expected to shape the future of SIP trunking is the increasing adoption of cloud-based communication systems. As more organizations move their communication systems to the cloud, they are likely to turn to SIP trunks as a way to connect their phone systems to the public telephone network and enable remote communication. Another trend that is expected to impact the future of SIP trunking is the increasing adoption of 5G technology. 5G networks offer faster speeds and lower latency, which may make it possible to use SIP trunks for real-time communication applications such as interactive and/or immersive video conferencing.