6.2 Remote & Hybrid Realtime Streaming

6.2 Remote & Hybrid Realtime Streaming

Quick Summary: Remote and hybrid legal proceedings require secure, low-latency distribution of stenographic text across wide-area networks. Transitioning from legacy peer-to-peer port forwarding to cloud relay architectures operating over outbound TCP Port 443 ensures rock-solid connectivity. Integrating steno streams into video platforms (Zoom, Webex, Teams) alongside dedicated litigation viewers preserves confidentiality and delivers essential trial advocacy features across distributed legal teams.

The Paradigm Shift to Cloud Realtime Architecture

The modernization of legal practice has elevated remote and hybrid depositions, arbitrations, and appellate hearings from an occasional convenience to a daily standard. Today's court reporter frequently streams live steno text to participants distributed across different cities, time zones, and continents. The RPR job analysis lists clients' viewing platforms and hot spots, Wi-Fi, LANs, and WANs among its Domain 1 realtime topics.

The Failure of Legacy Peer-to-Peer WAN Streaming

In the early era of internet realtime, reporters relied on direct Peer-to-Peer (P2P) connections:

1. The reporter's CAT software listened for incoming connections on a specific port (e.g., port 1099 or 8080).
2. The reporter had to discover their public WAN IP address, log into the venue's router, and configure Port Forwarding rules to direct external traffic through the router's Network Address Translation (NAT) firewall to the CAT laptop's private IP.
3. Remote attorneys entered the reporter's public IP address directly into their viewer software.

This legacy model proved disastrous in practical legal settings: corporate hotel and courthouse firewalls strictly block inbound port forwarding; residential ISPs frequently alter dynamic IP addresses mid-proceeding; and exposing an open inbound listening port on a reporter's laptop poses severe cybersecurity vulnerabilities.

The Modern Cloud Relay Architecture

Cloud realtime services offered with CAT systems (for example, Stenograph's CaseViewNet and Advantage Software's Bridge) generally operate on a centralized publisher-subscriber relay model:

[CAT Laptop (Publisher)] 
       |
       | (Outbound TCP Connection - Port 443 / TLS 1.3 / WSS)
       v
+-----------------------------------------------------------+
|               Secure Cloud Relay Server Cluster            |
|  - Authenticates session tokens & case passcodes          |
|  - Buffers text packets & manages client subscriptions    |
|  - Broadcasts text downstream to authorized endpoints     |
+-----------------------------------------------------------+
       |                                                   |
       | (Outbound TLS Connection)                         | (Outbound REST API Push)
       v                                                   v
[Remote Litigator Viewer]                           [Video Conference Engine]
(CaseViewNet / Bridge Mobile)                       (Zoom Closed Caption API)
- Full Transcript Backlog                           - 2-Line Transient Subtitles
- Boolean Search & Annotations                      - Live Meeting Video Feed

1. Outbound-Only Communication: The reporter's CAT laptop initiates an outbound encrypted connection over standard TCP Port 443 (HTTPS / WebSocket Secure) to an enterprise cloud relay server. Because firewalls inherently allow outbound stateful traffic, zero router configuration or port forwarding is required.
2. Session Instantiation: The cloud server assigns a unique Session Identifier (or room code) and generates an encrypted connection token.
3. Client Subscription: Remote litigators open their viewer application or web browser and connect outbound to the cloud server, entering the session code and case password. The relay server routes the text packets downstream to authenticated subscribers in fractions of a second.

---

Security Architecture: Session Tokens, Passcodes & Encryption

Provision 4 of the NCRA Code of Professional Ethics requires members to preserve the confidentiality and ensure the security of information entrusted to them by the parties. In trade secret litigation, federal grand jury hearings, and in-camera bench conferences, unedited realtime text streams contain highly sensitive, sealed, and legally privileged information.

To safeguard the record across the public Internet, modern streaming platforms enforce multi-layered cryptographic safeguards:

• Transport Layer Security (TLS 1.2 / TLS 1.3): Text traveling over the internet is encrypted with modern cipher suites such as AES-GCM. Eavesdroppers intercepting raw Wi-Fi or broadband traffic observe only randomized ciphertext.
• Session codes and passwords: Access is controlled with a session identifier and password; send them only to authorized participants, through a separate channel when the matter is sensitive.
• Participant list: Many services show the reporter who is connected and let the reporter remove a connection, for example if an unauthorized person joins or a witness excluded under Federal Rule of Evidence 615 should not be following the testimony.

[!NOTE] Handling Sealed Testimony in Hybrid Proceedings: When a judge orders a proceeding sealed or holds an in-camera sidebar conference, the reporter should pause the realtime feed to anyone not authorized to see that portion (the control's name varies by CAT program). This halts outbound packet transmission to remote participants while allowing the reporter's local machine to continuously capture the official sealed record.

---

Transport Protocols: TCP/IP vs. UDP in Text Streaming

Data traversing the Internet is governed by transport layer protocols within the Internet Protocol suite. The difference between TCP and UDP explains why text and video behave differently on a poor connection:

[TCP: Transmission Control Protocol - Used for Realtime Steno]
Sender   --- [SYN Packet] ------------> Receiver
Sender   <-- [SYN-ACK Packet] --------- Receiver
Sender   --- [ACK + Data Packet 1] ---> Receiver
Sender   <-- [ACK 1 Confirmed] -------- Receiver
*Guarantees: Zero packet loss, strictly ordered byte stream, error retransmission.*

[UDP: User Datagram Protocol - Used for Video & Audio Streams]
Sender   === [Video Packet 1] =========> Receiver
Sender   === [Video Packet 2 (Lost)] ==> [DROPPED IN TRANSIT]
Sender   === [Video Packet 3] =========> Receiver
*Prioritizes: Minimal latency over reliability; lost packets are never resent.*

Why Realtime Steno Mandates TCP

While video conferencing platforms (Zoom, Teams, Webex) utilize User Datagram Protocol (UDP) for real-time video and voice transmission—accepting occasional dropped video frames to prevent buffering delays—realtime text services typically run over Transmission Control Protocol (TCP), for example through HTTPS and WebSocket connections:

1. Guaranteed Delivery (Zero Packet Loss): TCP employs a positive acknowledgment mechanism (ACK). If an internet routing hiccup drops a packet, the sender's TCP stack automatically retransmits the missing byte segment.
2. Strict In-Order Sequencing: Stenographic transcription is highly sequential. If steno packets arrived out of order, CAT translation engines would reverse word orders, generating chaotic gibberish.
3. Integrity Verification: TCP headers include 16-bit mathematical checksums that verify no electrical noise corrupted byte payloads during transit.

Stenographic streams rely primarily on TCP Port 443, which hosts both traditional HTTPS and modern WebSocket Secure (WSS) protocols. Because port 443 is usually open for encrypted web browsing, these connections pass through most firewalls.

---

Integrating Realtime Text with Remote Video Platforms

In remote proceedings, participants require simultaneous access to both video/audio feeds and the live steno transcript. Integration occurs through two distinct pathways:

1. Direct Video Platform Captioning (REST API Integration)

Major videoconferencing platforms support third-party Closed Caption (CC) ingestion:

• Zoom Closed Captioning API: When a meeting host assigns the court reporter as the closed captioner, the host can select "Use a 3rd party CC service." Zoom generates a unique REST API URL / Token (e.g., https://wmcc.zoom.us/closedcaption?id=...). The reporter copies this URL and pastes it into their CAT software's streaming setup window (many CAT and captioning programs support this; check yours). As the reporter writes, the CAT software packages completed text lines into HTTP POST requests, streaming them directly into Zoom's native subtitle display.
• Microsoft Teams & Cisco Webex: Teams lets a meeting organizer assign a CART captioner through a captioning link, and Webex supports assigning a closed captioner and third-party caption integrations. Setup steps change, so review the vendor's current instructions.

2. Dedicated Litigation Viewers vs. Native Video Captions

While native video closed captions provide convenient basic subtitles, experienced trial attorneys and judges almost universally demand dedicated litigation viewer applications running in a separate window or on a dual-monitor workstation:

| Operational Feature | Native Video Closed Captions (e.g., Zoom CC) | Dedicated Litigation Viewers (e.g., CaseViewNet, Bridge) | | :--- | :--- | :--- | :--- | | Display Format | 1 to 2 transient lines overlaid across video | Multi-line, scrollable transcript page (Lines 1-25) | | Transcript Backlog | None; subtitles disappear after 5 to 10 seconds | Complete full-day searchable transcript history | | Page & Line Coordinates| Completely absent | Fully visible; enables precise legal objections | | Search Capabilities | None | Real-time boolean, wildcard, and proximity search | | Private Annotations | None | Color-coded issue coding and private attorney notes | | Data Privacy | Subject to meeting recording and platform logs | Separate from the video platform; security depends on the service |

[!TIP] Dual-monitor tip: In remote proceedings, attorneys following realtime often use a dual-monitor workstation: Monitor 1 displays the video conferencing gallery (witness, judge, opposing counsel), while Monitor 2 runs the dedicated litigation support viewer. This layout mirrors an in-person courtroom, allowing counsel to maintain visual eye contact with the witness while continuously tracking verbatim text.

---

Managing Firewall Restrictions & Enterprise Proxy Servers

Streaming realtime text into federal courthouses, state judicial networks, corporate legal departments, and government agencies (e.g., the Department of Justice or SEC) frequently encounters aggressive enterprise cybersecurity defenses.

Common Enterprise Network Obstacles

1. Deep Packet Inspection (DPI): Next-generation firewalls inspect the internal contents of SSL/TLS packets. If the firewall detects a long-lived, persistent WebSocket connection over Port 443 that does not behave like standard web browsing, it terminates the socket connection.
2. Authenticated Proxy Servers: Many government and financial institutions route all outbound traffic through an enterprise proxy server (utilizing NTLM or Kerberos authentication). Unauthenticated background daemons in CAT software cannot pass through the proxy.
3. Restricted Domain Policies: Strict firewall whitelists block connections to any cloud IP address not explicitly pre-approved by the IT department.

Systematic Firewall Navigation Strategies

• Protocol Fallback (WSS to HTTPS Long-Polling): Leading CAT streaming platforms feature automated protocol negotiation. If persistent WebSocket Secure (WSS) frames are blocked by DPI, the software drops back to standard HTTPS polling (issuing rapid, short-lived HTTP POST/GET requests), which mimics standard web browser requests.
• Advance allow-listing: Before a hearing in a high-security venue, ask the realtime service for its current domains and ports and give them to court or client IT well in advance.
• Independent cellular connection (with permission): If the facility network blocks the service and the court or client allows it, move the realtime connection to a dedicated cellular hotspot on an independent carrier. Never work around a court's or client's security rules without authorization.

---

Latency Management & Audio-Text Synchronization

In a remote proceeding, the court reporter does not hear the witness's voice in person; the voice travels across the internet, is encoded by the videoconferencing platform, and is played through the reporter's headphones. The reporter then strokes the keys, the CAT software translates the chords, and the text travels to the cloud relay before appearing on counsel's screen.

[Spoken Word] -> [Mic & Encoder] -> [Internet Transit] -> [Reporter Hears Audio] (250-400 ms)
                                                                 |
                                                          [Steno Keystroke] (200-300 ms reaction)
                                                                 |
                                                          [CAT Translation Engine] (50-100 ms)
                                                                 |
                                                          [Cloud Relay & Delivery] (100-200 ms)
                                                                 v
                                                  [Remote Counsel Sees Text] (Illustrative total: ~1-2 sec)

The Latency Budget

Under good conditions, text typically reaches remote viewers within a second or two of the spoken word. Longer delays make realtime less useful, because attorneys following along fall behind the testimony.

CAT Translation Buffer Optimization

A critical CAT software setting influencing perceived latency is the Stroke Flush Threshold (or output buffer delay):

• Immediate Stroke Flushing: The CAT engine emits every translated word or stroke packet the instant it is translated. This provides near-zero latency, but can cause words to appear in rapid, single-syllable bursts.
• Buffered Flushing (Word/Phrase Boundary): The CAT engine waits for a complete phrase or sentence delimiter (period, question mark) before pushing the text block. While this produces cleaner chunks, it adds a noticeable delay.
• A practical balance: Use immediate or short-delay output for litigation realtime so text flows continuously across the viewer screen.