Summary

  • RFC 5194 defines real-time text as conversational character flow. Whole-line buffering can deliver every word and still fail the medium because it removes the timing and partial-expression cues on which a live exchange depends.
  • Operators should keep session negotiation, character transmission, RTP arrival, loss recovery, rendering, participant attribution and gateway conversion as separate receipts. A connected badge or complete transcript cannot borrow authority from all of them.

A successful call with a missing conversation

The implementation team could defend every green indicator. SIP had produced a dialog. Offer/answer had selected a text format. RTP packets appeared after the user pressed Return. The stored transcript matched what the caller had typed. Nothing in that account was false.

It was also not an account of real-time text.

RFC 5194 uses a more demanding object. Real-time text is sent character by character as it is entered for conversational use. Its transport requirement says characters must leave as soon as possible and states directly that buffering whole lines does not meet the character-delay requirements. Small groups may be legitimate. A gateway may need a declared buffer to bridge unlike systems. But the ordinary text path cannot wait for a sentence boundary and then claim that eventual completeness proves real time.

The distinction matters because a conversation carries information before a sentence is finished. A receiver sees hesitation, a correction, an unfinished warning or the start of a name. The other party can answer while the thought is forming. Delayed messaging retains lexical content and removes interaction.

Delay belongs to each character

An average call latency does not describe this property. A line containing fifty characters can be delivered in one fast packet after eight seconds of editing. Network transit may be excellent while the first character suffers eight seconds of application delay.

RFC 5194 calls one second of end-to-end delay good, notes that users appreciate shorter delays down to 300 milliseconds, and says as much as two seconds may remain acceptable. Those observations should not be promoted into a universal contractual SLA. They show why the measurement unit cannot be only a packet, line or call.

The useful record begins with an input event. It binds that event to the local transmission time, RTP stream and sequence context, arrival, decoding and presentation. The resulting evidence can distinguish keyboard-to-sender buffering from network delay and renderer delay. Without that decomposition, every team can prove that its own component was fast while the conversation remains slow.

Rate needs the same discipline. RFC 5194 requires support for people generating real-time text and names 30 characters per second; RFC 4103 also exposes a cps parameter. A negotiated rate is an envelope, not a receipt that characters were actually emitted and displayed within it.

Negotiated is not flowing

SIP, SDP and offer/answer solve essential coordination problems. The endpoints need to agree that a text stream exists, which address and port carry it, and which payload formats apply. A successful exchange proves that an offer and answer converged on a description.

It does not prove that the sender produced RTP, that the path delivered it, that the receiver decoded it or that a user saw it. A session can have healthy audio, healthy video and no usable text. Treating a single call state as authority over all three media converts the most visible success into a false certificate for the least observed channel.

Each medium therefore needs its own readiness and continuity state. For text, that state should expose negotiation, first transmitted character, first received character, sustained sequence continuity, unresolved loss and renderer progress. The call-level view may summarize those states, but it must remain decomposable.

Redundancy is repair material, not a completeness certificate

RFC 4103 carries T.140 text over RTP and defines both primary and redundant payload use. RFC 2198 supplies the generic redundant-payload mechanism. Repeating recent text in later packets can recover characters lost with an earlier packet, which is especially valuable because a single missing text packet can remove a word fragment rather than merely degrade a sample.

The presence of text/red is nevertheless a capability claim. A receiver still needs to know which sequence gap occurred, what redundant generation repaired it, and whether anything remained unrecovered. RFC 5194 expects a text-loss indication when incoming loss remains. Silently deleting the gap may yield a smooth transcript whose semantic confidence is lower than its appearance.

The right success record is not redundancy enabled. It separates original arrival, repaired units and unresolved loss. Presentation should preserve the unresolved-loss indication instead of allowing a transcript exporter to normalize it away.

Presentation is part of the protocol outcome

T.140 semantics include more than printable letters. International characters, line breaks, erasure and alerting affect what a participant experiences. A storage pipeline that strips an erasure can retain text the sender visibly removed. A legacy conversion that substitutes characters can damage a name while preserving the rest of the sentence. A renderer that waits for punctuation can receive every packet on time and still destroy conversational timing.

This creates three distinct records: received character events, presented events and the later archival transcript. The transcript is useful, but it is a projection. It must not become the only retained evidence when the question is whether the live service was usable.

A gateway changes the claim

RFC 5194 spends unusual care on interworking because a gateway is not a transparent cable. A legacy PSTN textphone may operate at a lower rate, use half-duplex behavior and support a restricted character repertoire. An instant-messaging service may expect completed messages rather than a continuing character stream. The framework's IM example describes concatenating incoming characters and emitting them at a boundary.

That conversion may be necessary. It also creates a new responsibility. The gateway should identify its input and output protocols, buffering rule, rate limit, duplex change, character mapping and loss transformation. Then the service can say truthfully that one segment was real-time text while another used an interworking presentation.

Without that boundary, a platform can attribute gateway delay to the network, call message bubbles real-time characters, or publish a clean Unicode transcript after the legacy side received substitutions. Interoperability is not sameness. It is a controlled translation whose losses remain visible.

Multiple media require multiple witnesses

Real-time text is often valuable precisely because it can coexist with speech and video. That makes the temptation to use one call-health state stronger. Audio RTP is easy to monitor, video has conspicuous quality signals, and the text stream may be quiet while a participant listens.

Silence therefore needs context. It may mean the user is not typing, the sender is buffering, the stream is blocked, or the renderer has stalled. A text-channel heartbeat cannot invent user activity, but the system can retain negotiation state, RTP reception, last character event, renderer acknowledgement and loss state separately. When voice is flowing and text is not, the summary must show a partial service rather than borrowing the audio channel's authority.

Emergency routing is not media readiness

RFC 5194 requires the ability to place an emergency call using real-time text and contemplates relay services. The document does not settle every contemporary jurisdictional obligation, and this Article makes no compliance judgment. It does expose a consequential operational boundary.

Correct routing is only one event. Relay selection, text-media negotiation, first-character readiness and sustained two-way presentation are later events. If a dashboard closes the incident when the emergency destination answers, it can erase the interval during which a caller could not communicate.

The minimum evidence for such a path should therefore name the emergency route and relay status without merging them with the text channel. That is not additional ceremony. It is the difference between reaching an institution and reaching a person through a usable medium.

The minimum receipt

A practical receipt can stay narrow. It records the session and dialog; local and remote media descriptions; text stream and participant identity; input, transmit, arrival and render times; original, recovered and unrecovered loss; text-loss presentation; modality-specific readiness; and any gateway's conversion policy.

This is an operational inference, not wire syntax mandated by RFC 5194. Its purpose is to keep each assertion within the surface that produced it. SIP describes the session. RTP witnesses transport. The decoder witnesses character recovery. The renderer witnesses presentation. The gateway witnesses conversion. The transcript witnesses a later projection.

Heng Lu's reality-layer discipline applies cleanly here. Connected is a useful symbol until it is allowed to overrule the character path. The minimum initial specification protects portable conversational semantics; local products remain free to design richer interfaces. Running code settles whether characters moved and appeared. The status badge reports that reality—it does not create it.

Sources

  1. RFC 5194 HTML
  2. RFC 5194 text
  3. RFC 5194 information page
  4. IETF Datatracker: RFC 5194
  5. RFC 5194 history
  6. RFC 5194 references
  7. RFC 5194 errata
  8. RFC 4103
  9. RFC 4103 information page
  10. RFC 9071
  11. RFC 9071 information page
  12. RFC 4351
  13. RFC 3550
  14. RFC 2198
  15. RFC 3261
  16. RFC 3264
  17. RFC 8866
  18. Heng Lu — reality layers and symbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy