Summary

  • RFC 3351 asked SIP designers to treat text, voice, video, relays and user preferences as parts of a session that could change without restarting the call.
  • It was an Informational requirements memo, not a standardized extension or proof that devices and services delivered the scenarios it described.

The decisive sentence in RFC 3351 is almost architectural shorthand: any User Agent in a conversation, including a transcoding service, “MUST be able to add or remove a media stream” without tearing down and re-establishing the call. A voice call could gain text; a relay could join, translate between modalities and leave; the conversation would not need to begin again just because its participants needed another channel.

That is a more interesting history than a list of accessibility features. Published in August 2002, RFC 3351 placed communication preferences inside session design. It defined a user profile as abilities and preferences that SIP could communicate and use to determine how a session was handled. Text, audio and video might flow in either direction or in combination. A relay might translate voice to text or text to speech. A gateway might connect a modern User Agent to a legacy textphone. The session, not a fixed device category, became the place where those choices met.

But the status line must stay in view. RFC 3351 is Informational and explicitly says it does not specify an Internet standard. Its “MUST” and “SHOULD” language records the authors’ requested requirements; it does not turn the memo into a standardized SIP extension, certify an implementation or prove that an accessible call could be completed. The document’s scenarios are design cases, not a deployment survey.

The proposal also understood that flexibility could create a new form of exposure. A profile may help a call find the right media path, but it can reveal a person’s abilities or preferences. RFC 3351 therefore called for anonymity: the recipient need not be told that the caller is deaf merely because a relay participates. It urged providers to let people prevent such information from becoming public in a transaction, and asked third-party transcoders to state confidentiality policies. Access was not only a question of whether text could be added. It was also a question of what a service learned, stored and disclosed while doing so.

The cost and choice language is unusually concrete. The memo wanted a User Agent to identify a stream’s content, compare transcoding services by capability and policy, and discover alternatives. It suggested displaying per-minute prices and minimum charges before a relay session began. In the radio example, a text stream was unavailable, and a transcoding provider declined the audio because it could overload its resources. The call path had an operational limit, not a magical guarantee. Making a service selectable meant exposing its constraints and price, rather than treating the intermediary as invisible infrastructure.

The scenarios range beyond typed text. One keeps an existing voice connection while a relay converts speech to text and typed replies back to speech. Another chains speech-to-text, text-to-sign and sign-to-text services for conference participants with different preferences. A voice-activated menu gains a text route through a relay. These are ambitious sketches: they make the user’s chosen modality central, but every additional conversion introduces a provider, a policy, a possible fee and another place where information crosses a boundary.

RFC 3351’s later history is a sequence of specifications, not a record of universal success. RFC 4103 defined an RTP payload for T.140 real-time text and redundancy for recovering some lost characters. RFC 5194 later set out a SIP/IP framework with more detailed requirements for text, transcoding, presentation and interworking, citing RFC 3351’s relay guidance. RFC 4504 recommended that SIP telephony devices support RFC 3351 accessibility requirements. Much later, RFC 8865 specified T.140 over reliable, ordered WebRTC data channels, while RFC 9071 addressed source-aware multiparty RTP text and updated RFC 4103.

Each document makes part of the path more precise. None, by itself, establishes that every endpoint, provider, emergency service or user has that path available.

That distinction is the point. A session can be technically extensible while the service remains unavailable, unaffordable, incompatible or unwilling to accept the stream. A profile can help match a call and simultaneously disclose sensitive information. A relay can bridge media and still impose a price or confidentiality risk. RFC 3351’s lasting contribution is to put these decisions in the design conversation: changing the medium should not force a new call, and the user should retain meaningful control over how the change happens.

Sources: RFC 3351 · RFC 3351 record · RFC 3351 Datatracker record · RFC 2119 · RFC 8174 · SIP: Session Initiation Protocol, RFC 3261 · An Offer/Answer Model with SDP, RFC 3264 · RTP Payload for Text Conversation, RFC 4103 · Framework for Real-Time Text over SIP, RFC 5194 · SIP Telephony Device Requirements, RFC 4504 · T.140 Text over WebRTC Data Channels, RFC 8865 · RTP-Mixer Formatting of Multiparty Real-Time Text, RFC 9071 · Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption · Running-Code Primacy