RTP-Mixer Formatting of Multiparty Real-Time Text
updates
- rfc-4103 — RTP Payload for Text Conversation
Extracted elements (30)
The 330 ms maximum transmission interval was chosen (rather than 300 ms) because many text sources transmit at 300 ms during continuous typing; reception of new text from a source triggers combined transmission of new text plus unsent redundancy, so the 330 ms interval only applies when the user stops typing.
The 'multiple sources per packet' alternative (up to 15 sources per packet via CSRC ordering) was evaluated but rejected because it would require a new media subtype and new redundancy format, adding standardization and implementation time beyond what the deployment timeline allowed.
The RTP-mixer-based method (single stream with CSRC source identification) was chosen over multiple-RTP-streams-per-source because many existing RTP implementations lack support for multiple streams in the same session, making broad deployment of the multi-stream approach impractical.
A mixer SHOULD by default format transmissions as single-stream text suitable for multiparty-unaware RFC 4103 endpoints (inserting line separators and readable source labels) when the 'rtt-mixer' negotiation fails, to maintain backward compatibility with deployed endpoints.
For WebRTC gateway interoperability, one T.140 data channel per RTP source is established from gateway to each WebRTC participant; the data channel label parameter maps to the NAME RTCP field on the RTP side, and channels SHOULD be opened/closed as participants join or leave.
Gateways to PSTN textphones (TTYs) SHOULD NOT indicate multiparty awareness for those endpoints, or alternatively should incorporate the multiparty-unaware mixing function themselves, since textphones are limited devices with no multiparty awareness.
A mixer SHALL send RTCP reports with SDES, CNAME, and NAME information about sources in the multiparty call so participants can compose suitable labels; privacy considerations SHALL be taken when composing these fields.
A multiparty-aware receiving endpoint MUST separate text from different sources and present them in separate presentation fields. When multiple sources are active, the presentation SHALL provide a view where text is added in multiple presentation fields.
A party that has negotiated 'rtt-mixer' and acts as an RTP mixer MUST populate the CSRC list and format packets per Section 3; a party that has not successfully negotiated 'rtt-mixer' MUST NOT transmit interleaved packets from different sources in the same RTP stream.
A party willing to use the RTP-mixer-based method SHALL include the 'rtt-mixer' SDP attribute in the 'text' media section of the initial offer, and after sending that offer MUST be prepared to receive both multiparty-formatted and two-party formatted real-time text.
A 'text/red' or 'text/t140' transmitter in a mixer SHALL send packets as long as there is something to transmit, with a maximum transmission interval of 330 ms per source. It is RECOMMENDED to send the next packet as soon as new text is available, provided the mean character rate over the last 10 one-second intervals does not exceed the receiver's 'cps' value.
An answering party that receives an offer with 'rtt-mixer' and is willing to use the method SHALL echo the attribute in the answer; if the offer did not contain 'rtt-mixer', the answer MUST NOT contain it. An answer MUST NOT accept more than one multiparty method in the same RTP session.
As soon as a participant is known and available for text reception, a Unicode BOM character SHALL be sent by the other entity. If the transmitter is a mixer, the source of the BOM SHALL be indicated as the mixer itself, and the BOM SHALL be transmitted with the same redundancy procedures as any other text.
Division of text for partial transmission MUST be made at T140block borders when the 'cps' limit is reached. When the rate falls below 'cps' again, transmission intervals SHALL be reset to 330 ms and new text SHALL again be sent as soon as available.
If the CC field value of a received packet is 1, the receiver MUST act on the source indicated in the single CSRC list member according to its role; if CC is 0, the source is the SSRC.
It is RECOMMENDED that an RTP mixer discard text causing delays exceeding 15 seconds and insert a general indication of possible text loss; if the main text contributor is identifiable, the mixer MAY avoid deleting text from that participant.
Security mechanisms for confidentiality, integrity, and peer authentication SHOULD be applied using SIP over TLS for session control and DTLS-SRTP for media. If no other solution is mandated, OSRTP is a suitable method for negotiating SRTP with DTLS.
Text from different sources MUST NOT be transmitted in the same RTP packet; new text and redundant copies from one source SHALL be in the same packet if available at the same time.
The CC field SHALL be 1 when a mixer conveys text from other sources; the single CSRC list member SHALL contain the SSRC of the originating source of the T140blocks in that packet. CC SHALL be 0 for self-sourced transmissions.
The number of redundant generations SHALL be deduced from SDP negotiation and set to the minimum declared by both parties. It is RECOMMENDED to declare and transmit one original and two redundant generations of T140blocks for good loss protection and low overhead.
The RECOMMENDED 'cps' value is 90 characters per second, sufficient for large unmanaged conferences and speech-to-text use cases. The default of 30 cps from RFC 4103 is evaluated across all sources contributing to a receiver in the multiparty case.
When extracting T140blocks, possible RTP timestamp wraparound and SSRC changes in the session MUST be considered. Source SHALL be extracted from the CSRC list if available, otherwise from the SSRC.
RTCP SDES CNAME and NAME fields, as well as conference notifications, may reveal sensitive personal information. Real-time text services are frequently used by deaf and hard-of-hearing individuals who may not wish to disclose this characteristic; conference systems incorporating the mixer MAY need to be designed with confidentiality of such characteristics in mind.
Empty T140blocks are used when no unsent T140blocks exist for a source but redundant retransmissions are still pending; they occupy zero length in the packet but their SSRC is still placed in the CSRC list. The first packet of a session, after a source switch, or after a pause SHALL use the available T140blocks as primary with empty T140blocks for redundancy slots.
The CSRC list is used by the mixer to carry exactly one member — the SSRC of the originating source of T140blocks in the packet. The CC field is 1 for mixer-sourced multiparty packets and 0 for self-sourced transmissions by either endpoints or mixers.
The 'rtt-mixer' SDP media attribute (syntax: 'a=rtt-mixer') is used at the media level in the 'text' media section to negotiate and confirm mutual support for the RTP-mixer-based multiparty real-time text method. It takes no value.
IANA has registered the new SDP media attribute 'rtt-mixer' at the media usage level with no attribute value, used to indicate mixer and endpoint support of multiparty mixing for real-time text over a common RTP stream with source identified in a single CSRC-list member.
Malicious participants may send a continuous flow of text to disrupt the session or spoof text appearing to originate from other participants. Handling of text from different sources by receivers MUST be well separated so that malformed or malicious control codes from one source only affect that source's text stream.
The RTP-mixer model requires the mixer to decrypt, repack, and re-encrypt secured text from all conference participants, so the mixer must be fully trusted for confidentiality and integrity of real-time text data — analogous to the trust model for centralized audio/video mixers.
Each multiparty-aware RTP packet carries CC=1, a single-element CSRC list containing the originating source SSRC, and a 'text/red' payload with one primary T140block and typically two redundant T140block generations. Timestamp offset fields in the redundancy header use the same clock tick units as the RTP timestamp.