RTP-mixer formatting of multi-party Real-time text
draft-ietf-avtcore-multi-party-rtt-mix-12
AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: 4103 (if approved) 15 December 2020
Intended status: Standards Track
Expires: 18 June 2021
RTP-mixer formatting of multi-party Real-time text
draft-ietf-avtcore-multi-party-rtt-mix-12
Abstract
Real-time text mixers for multi-party sessions need to identify the
source of each transmitted group of text so that the text can be
presented by endpoints in suitable grouping with other text from the
same source, while new text from other sources is also presented in
readable grouping as received interleaved in real-time.
Use of RTT is increasing, and specifically, use in emergency calls is
increasing. Emergency call use requires multi-party mixing. RFC
4103 "RTP Payload for Text Conversation" mixer implementations can
use traditional RTP functions for source identification, but the
performance of the mixer when giving turns for the different sources
to transmit is limited when using the default transmission
characteristics with redundancy.
Enhancements for RFC 4103 real-time text mixing are provided in this
document, suitable for a centralized conference model that enables
source identification and rapidly interleaved transmission of text
from different sources. The intended use is for real-time text
mixers and participant endpoints capable of providing an efficient
presentation or other treatment of a multi-party real-time text
session. The specified mechanism builds on the standard use of the
CSRC list in the RTP packet for source identification. The method
makes use of the same "text/t140" and "text/red" formats as for two-
party sessions.
Solutions using multiple RTP streams in the same RTP session are
briefly mentioned, as they could have some benefits over the RTP-
mixer model. The possibility to implement the solution in a wide
range of existing RTP implementations made the RTP-mixer model be
selected to be fully specified in this document.
A capability exchange is specified so that it can be verified that a
mixer and a participant can handle the multi-party coded real-time
text stream using the RTP-mixer method. The capability is indicated
by use of an SDP media attribute "rtt-mixer".
Hellstrom Expires 18 June 2021 [Page 1]
Internet-Draft RTP-mixer format for multi-party RTT December 2020
The document updates RFC 4103 "RTP Payload for Text Conversation".
A specification of how a mixer can format text for the case when the
endpoint is not multi-party aware is also provided.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 June 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Selected solution and considered alternatives . . . . . . 6
1.3. Intended application . . . . . . . . . . . . . . . . . . 9
2. Overview of the two specified solutions and selection of
method . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. The RTP-mixer based solution for multi-party aware
endpoints . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Mixing for multi-party unaware endpoints . . . . . . . . 10
2.3. Offer/answer considerations . . . . . . . . . . . . . . . 11
Hellstrom Expires 18 June 2021 [Page 2]
Show full document text