draft-ietf-avtcore-multi-party-rtt-mix-05.txt   draft-ietf-avtcore-multi-party-rtt-mix-06.txt 
AVTCore G. Hellstrom AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: RFC 4102, RFC 4103 (if approved) 4 June 2020 Updates: RFC 4102, RFC 4103 (if approved) 11 June 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 6 December 2020 Expires: 13 December 2020
RTP-mixer formatting of multi-party Real-time text RTP-mixer formatting of multi-party Real-time text
draft-ietf-avtcore-multi-party-rtt-mix-05 draft-ietf-avtcore-multi-party-rtt-mix-06
Abstract Abstract
Real-time text mixers for multi-party sessions need to identify the 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 source of each transmitted group of text so that the text can be
presented by endpoints in suitable grouping with other text from the presented by endpoints in suitable grouping with other text from the
same source. same source.
Regional regulatory requirements specify provision of real-time text Regional regulatory requirements specify provision of real-time text
in multi-party calls. RFC 4103 mixer implementations can use in multi-party calls. RFC 4103 mixer implementations can use
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 December 2020. This Internet-Draft will expire on 13 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Selected solution and considered alternative . . . . . . 5 1.1. Selected solution and considered alternative . . . . . . 5
1.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Intended application . . . . . . . . . . . . . . . . . . 5 1.3. Intended application . . . . . . . . . . . . . . . . . . 6
2. Use of fields in the RTP packets . . . . . . . . . . . . . . 6 2. Use of fields in the RTP packets . . . . . . . . . . . . . . 6
3. Actions at transmission by a mixer . . . . . . . . . . . . . 9 3. Actions at transmission by a mixer . . . . . . . . . . . . . 9
3.1. Initial BOM transmission . . . . . . . . . . . . . . . . 9 3.1. Initial BOM transmission . . . . . . . . . . . . . . . . 9
3.2. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Transmission interval . . . . . . . . . . . . . . . . . . 9 3.3. Transmission interval . . . . . . . . . . . . . . . . . . 10
3.4. Do not send received text to the originating source . . . 9 3.4. Do not send received text to the originating source . . . 10
3.5. Clean incoming text . . . . . . . . . . . . . . . . . . . 10 3.5. Clean incoming text . . . . . . . . . . . . . . . . . . . 10
3.6. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Text placement in packets . . . . . . . . . . . . . . . . 10 3.7. Text placement in packets . . . . . . . . . . . . . . . . 10
3.8. Maximum number of sources per packet . . . . . . . . . . 10 3.8. Maximum number of sources per packet . . . . . . . . . . 11
3.9. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 11 3.9. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 11
3.10. Creation of the redundancy . . . . . . . . . . . . . . . 11 3.10. Creation of the redundancy . . . . . . . . . . . . . . . 11
3.11. Timer offset fields . . . . . . . . . . . . . . . . . . . 11 3.11. Timer offset fields . . . . . . . . . . . . . . . . . . . 12
3.12. Other RTP header fields . . . . . . . . . . . . . . . . . 11 3.12. Other RTP header fields . . . . . . . . . . . . . . . . . 12
3.13. Pause in transmission . . . . . . . . . . . . . . . . . . 12 3.13. Pause in transmission . . . . . . . . . . . . . . . . . . 12
4. Actions at reception . . . . . . . . . . . . . . . . . . . . 12 4. Actions at reception . . . . . . . . . . . . . . . . . . . . 12
4.1. Multi-party vs two-party use . . . . . . . . . . . . . . 12 4.1. Multi-party vs two-party use . . . . . . . . . . . . . . 12
4.2. Level of redundancy . . . . . . . . . . . . . . . . . . . 12 4.2. Level of redundancy . . . . . . . . . . . . . . . . . . . 13
4.3. Extracting text and handling recovery and loss . . . . . 12 4.3. Extracting text and handling recovery and loss . . . . . 13
4.4. Delete BOM . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Delete BOM . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 13 4.5. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 14
5. RTCP considerations . . . . . . . . . . . . . . . . . . . . . 13 5. RTCP considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Chained operation . . . . . . . . . . . . . . . . . . . . . . 14 6. Chained operation . . . . . . . . . . . . . . . . . . . . . . 14
7. Usage without redundancy . . . . . . . . . . . . . . . . . . 14 7. Usage without redundancy . . . . . . . . . . . . . . . . . . 14
8. Use with SIP centralized conferencing framework . . . . . . . 14 8. Use with SIP centralized conferencing framework . . . . . . . 15
9. Conference control . . . . . . . . . . . . . . . . . . . . . 14 9. Conference control . . . . . . . . . . . . . . . . . . . . . 15
10. Media Subtype Registration . . . . . . . . . . . . . . . . . 14 10. Media Subtype Registration . . . . . . . . . . . . . . . . . 15
11. SDP considerations . . . . . . . . . . . . . . . . . . . . . 16 11. SDP considerations . . . . . . . . . . . . . . . . . . . . . 17
11.1. Security for session control and media . . . . . . . . . 16 11.1. Mapping of media parameters to sdp . . . . . . . . . . . 18
11.2. SDP offer/answer examples . . . . . . . . . . . . . . . 16 11.2. Security for session control and media . . . . . . . . . 18
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.3. SDP offer/answer examples . . . . . . . . . . . . . . . 18
13. Performance considerations . . . . . . . . . . . . . . . . . 21 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Presentation level considerations . . . . . . . . . . . . . . 22 13. Performance considerations . . . . . . . . . . . . . . . . . 23
14.1. Presentation by multi-party aware endpoints . . . . . . 23 14. Presentation level considerations . . . . . . . . . . . . . . 23
14.2. Multi-party mixing for multi-party unaware endpoints . . 25 14.1. Presentation by multi-party aware endpoints . . . . . . 24
15. Gateway Considerations . . . . . . . . . . . . . . . . . . . 30 14.2. Multi-party mixing for multi-party unaware endpoints . . 26
15.1. Gateway considerations with Textphones (e.g. TTYs). . . 31 15. Gateway Considerations . . . . . . . . . . . . . . . . . . . 32
15.2. Gateway considerations with WebRTC. . . . . . . . . . . 31 15.1. Gateway considerations with Textphones (e.g. TTYs). . . 32
16. Updates to RFC 4102 and RFC 4103 . . . . . . . . . . . . . . 32 15.2. Gateway considerations with WebRTC. . . . . . . . . . . 33
17. Congestion considerations . . . . . . . . . . . . . . . . . . 32 16. Updates to RFC 4102 and RFC 4103 . . . . . . . . . . . . . . 33
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 17. Congestion considerations . . . . . . . . . . . . . . . . . . 33
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
20. Security Considerations . . . . . . . . . . . . . . . . . . . 32 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
21. Change history . . . . . . . . . . . . . . . . . . . . . . . 33 20. Security Considerations . . . . . . . . . . . . . . . . . . . 34
21. Change history . . . . . . . . . . . . . . . . . . . . . . . 34
21.1. Changes included in 21.1. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 33 draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 34
21.2. Changes included in 21.2. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 33 draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 34
21.3. Changes included in 21.3. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 33 draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 35
21.4. Changes included in 21.4. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 34 draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 35
21.5. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 34 21.5. Changes included in
21.6. Changes from draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 36
draft-hellstrom-avtcore-multi-party-rtt-source-03 to 21.6. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 36
draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 34
21.7. Changes from 21.7. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-02 to draft-hellstrom-avtcore-multi-party-rtt-source-03 to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 36
21.8. Changes from 21.8. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 37
21.9. Changes from 21.9. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-00 to draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . 37
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 21.10. Changes from
22.1. Normative References . . . . . . . . . . . . . . . . . . 36 draft-hellstrom-avtcore-multi-party-rtt-source-00 to
22.2. Informative References . . . . . . . . . . . . . . . . . 38 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
22.1. Normative References . . . . . . . . . . . . . . . . . . 38
22.2. Informative References . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
RFC 4103[RFC4103] specifies use of RFC 3550 RTP [RFC3550] for RFC 4103[RFC4103] specifies use of RFC 3550 RTP [RFC3550] for
transmission of real-time text (RTT) and the "text/t140" format. It transmission of real-time text (RTT) and the "text/t140" format. It
also specifies a redundancy format "text/red" for increased also specifies a redundancy format "text/red" for increased
robustness. RFC 4102 [RFC4102] registers the "text/red" format. robustness. RFC 4102 [RFC4102] registers the "text/red" format.
Regional regulatory requirements specify provision of real-time text Regional regulatory requirements specify provision of real-time text
in multi-party calls. in multi-party calls.
skipping to change at page 14, line 50 skipping to change at page 15, line 32
unmuting by the direction attributes in SDP [RFC4566]. unmuting by the direction attributes in SDP [RFC4566].
Note that floor control functions may be of value for RTT users as Note that floor control functions may be of value for RTT users as
well as for users of other media in a conference. well as for users of other media in a conference.
10. Media Subtype Registration 10. Media Subtype Registration
This registration is done using the template defined in [RFC6838] and This registration is done using the template defined in [RFC6838] and
following [RFC4855]. following [RFC4855].
Type name: text Type name:
text
Subtype name: rex Subtype name:
Required parameters: rate: The RTP timestamp (clock) rate. The rex
only valid value is 1000.
pt: A slash-separated list with the payload Required parameters:
type number(pt) for the primary text, the first redundant text, rate:
the second redundant text etc, that the receiver is capable to The RTP timestamp (clock) rate. The only valid value is 1000.
receive.
Optional parameter: cps: This parameter is used to signal the pt:
capabilities of a receiver implementation. It indicates the a comma-separated list of RTP payload types. Because comma is
maximum number of characters that may be received per second a special character, the list must be a quoted-string (enclosed
measured over a period of 10 seconds. The default value is 150. in double quotes). Each list element is a mapping of the
dynamic payload type number to an embedded Content-type
specification for the payload format corresponding to the
payload type. The format of the mapping is:
Encoding considerations: binary; see Section 4.8 of [RFC6838]. payload-type-number "=" content-type
If the content-type string includes a comma, then the content-
type string MUST be a quoted-string. If the content- type
string does not include a comma, it MAY still be quoted. Since
it is part of the list which must itself be a quoted- string,
that means the quotation marks MUST be quoted with backslash
quoting as specified in RFC 2045. If the content- type string
itself contains a quoted-string, then the requirement for
backslash quoting is recursively applied. To specify the text/
rex payload format in SDP, the pt parameter is mapped to an
a=fmtp attribute by eliminating the parameter name (pt) and
changing the commas to slashes. For example:
Security considerations: See Section 20 of RFC xxxx. [RFC Editor: pt = " = \"text/t140;cps=200,text/t140,text/t140\" "
Upon publication as an RFC, please replace "XXXX" with the number
assigned to this document and remove this note.]
Interoperability considerations: None. Implies the following sdp
Published specification: RFC XXXX. [RFC Editor: Upon publication as m=text 49170 RTP/AVP 98 100
an RFC, please replace "XXXX" with the number assigned to this a=rtpmap:98 rex/1000
a=fmtp:98 100/100/100
a=rtpmap:100 t140/1000
a=fmtp:100 cps=200
Encoding considerations:
binary; see Section 4.8 of [RFC6838].
Security considerations:
See Section 20 of RFC xxxx. [RFC Editor: Upon publication as an
RFC, please replace "XXXX" with the number assigned to this
document and remove this note.] document and remove this note.]
Applications which use this media type: For example: Text Interoperability considerations:
conferencing tools, multimedia conferencing tools.Real-time None.
conversational tools.
Fragment identifier considerations: N/A. Published specification:
RFC XXXX. [RFC Editor: Upon publication as an RFC, please replace
"XXXX" with the number assigned to this document and remove this
note.]
Additional information: None. Applications which use this media type:
For example: Text conferencing tools, multimedia conferencing
tools.Real-time conversational tools.
Person & email address to contact for further information: Gunnar Fragment identifier considerations:
Hellstrom <gunnar.hellstrom@ghaccess.se> N/A.
Intended usage: COMMON Additional information:
None.
Restrictions on usage: This media type depends on RTP framing, and Person & email address to contact for further information:
hence is only defined for transfer via RTP [RFC3550]. Gunnar Hellstrom <gunnar.hellstrom@ghaccess.se>
Author: Gunnar Hellstrom <gunnar.hellstrom@ghaccess.se> Intended usage:
COMMON
Change controller: IETF AVTCore Working Group delegated from the Restrictions on usage:
IESG. This media type depends on RTP framing, and hence is only defined
for transfer via RTP [RFC3550].
Author:
Gunnar Hellstrom <gunnar.hellstrom@ghaccess.se>
Change controller:
IETF AVTCore Working Group delegated from the IESG.
11. SDP considerations 11. SDP considerations
There are receiving RTT implementations which implement RFC 4103 There are receiving RTT implementations which implement RFC 4103
[RFC4103] but not the source separation by the CSRC. Sending mixed [RFC4103] but not the source separation by the CSRC. Sending mixed
text according to the usual CSRC convention from RFC 2198 [RFC2198] text according to the usual CSRC convention from RFC 2198 [RFC2198]
to a device implementing only RFC 4103 [RFC4103] would risk to lead to a device implementing only RFC 4103 [RFC4103] would risk to lead
to unreadable presented text. Therefore, in order to negotiate RTT to unreadable presented text. Therefore, in order to negotiate RTT
mixing capability according to this document, all devices supporting mixing capability according to this document, all devices supporting
this document for multi-party aware participants SHALL include an SDP this document for multi-party aware participants SHALL include an SDP
media format "text/rex" in the SDP [RFC4566], indicating this media format "text/rex" in the SDP [RFC4566], indicating this
capability in offers and answers. Multi-party streams using the capability in offers and answers. Multi-party streams using the
coding of this document intended for multi-party aware endpoints MUST coding of this document intended for multi-party aware endpoints MUST
NOT be sent to devices which have not indicated the "text/rex" NOT be sent to devices which have not indicated the "text/rex"
format. format.
Implementations not understanding this format MUST ignore it Implementations not understanding the "text/rex" format MUST ignore
according to common SDP rules. it according to common SDP rules.
The SDP media format defined here, is named "rex", for extended The SDP media format defined here, is named "rex", for extended
"red". It is intended to be used in "text" media descriptions with "red". It is intended to be used in "text" media descriptions with
"text/rex" and "text/t140" formats. Both formats MUST be declared "text/rex" and "text/t140" formats. Both formats MUST be declared
for the "text/rex" format to be used. It indicates capability to use for the "text/rex" format to be used. It indicates capability to use
source indications in the CSRC list and the packet format according source indications in the CSRC list and the packet format according
to this document. It also indicates ability to receive 150 real-time to this document. It also indicates ability to receive 150 real-time
text characters per second by default. text characters per second by default.
11.1. Security for session control and media 11.1. Mapping of media parameters to sdp
The information carried in the media type registration has a specific
mapping to fields in the Session Description Protocol (SDP) , which
is commonly used to describe RTP sessions. When SDP RFC 4566
[RFC4566]is used to specify sessions employing the "text/rex" format,
the mapping is as follows:
* The media type ("text") goes in SDP "m=" as the media name.
* The media subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name. The RTP clock rate in "a=rtpmap" MUST be 1000
for "text/rex".
* When the payload type is used with redundancy, the level of
redundancy is shown by the number of elements in the slash-
separated payload type list in the "fmtp" parameter of the "text/
rex" media format.
11.2. Security for session control and media
Security SHOULD be applied on both session control and media. In Security SHOULD be applied on both session control and media. In
applications where legacy endpoints without security may exist, a applications where legacy endpoints without security may exist, a
negotiation between security and no security SHOULD be applied. If negotiation between security and no security SHOULD be applied. If
no other security solution is mandated by the application, then RFC no other security solution is mandated by the application, then RFC
8643 OSRTP[RFC8643] SHOULD be applied to negotiate SRTP media 8643 OSRTP[RFC8643] SHOULD be applied to negotiate SRTP media
security with DTLS. Most SDP examples below are for simplicity security with DTLS. Most SDP examples below are for simplicity
expressed without the security additions. The principles (but not expressed without the security additions. The principles (but not
all details) for applying DTLS-SRTP security is shown in a couple of all details) for applying DTLS-SRTP security is shown in a couple of
the following examples. the following examples.
11.2. SDP offer/answer examples 11.3. SDP offer/answer examples
This sections shows some examples of SDP for session negotiation of This sections shows some examples of SDP for session negotiation of
the real-time text media in SIP sessions. Audio is usually provided the real-time text media in SIP sessions. Audio is usually provided
in the same session, and sometimes also video. The examples only in the same session, and sometimes also video. The examples only
show the part of importance for the real-time text media. show the part of importance for the real-time text media.
Offer example for just multi-party capability: Offer example for just multi-party capability:
m=text 11000 RTP/AVP 101 98 m=text 11000 RTP/AVP 101 98
a=rtpmap:98 t140/1000 a=rtpmap:98 t140/1000
skipping to change at page 21, line 33 skipping to change at page 23, line 17
13. Performance considerations 13. Performance considerations
This document allows new text from up to 16 sources per packet. A This document allows new text from up to 16 sources per packet. A
mixer implementing the specification will normally cause a latency of mixer implementing the specification will normally cause a latency of
0 to 150 milliseconds in text from up to 16 simultaneous sources. 0 to 150 milliseconds in text from up to 16 simultaneous sources.
This performance meets well the realistic requirements for conference This performance meets well the realistic requirements for conference
and conversational applications for which up to 5 simultaneous and conversational applications for which up to 5 simultaneous
sources should not be delayed more than 500 milliseconds by a mixer. sources should not be delayed more than 500 milliseconds by a mixer.
In order to achieve good performance, a receiver for multi-party In order to achieve good performance, a receiver for multi-party
calls SHOULD declare a sufficient CPS value in SDP for the number of calls SHOULD declare a sufficient CPS value for the "text/t140"
allowable characters per second. format in SDP for the number of allowable characters per second.
As comparison, if the "text/red" format would be used for multi-party As comparison, if the "text/red" format would be used for multi-party
communication with its default timing and redundancy, 5 communication with its default timing and redundancy, 5
simultaneously sending parties would cause jerky presentation of the simultaneously sending parties would cause jerky presentation of the
text from them in text spurts with 5 seconds intervals. With a text from them in text spurts with 5 seconds intervals. With a
reduction of the transmission interval to 150 ms, the time between reduction of the transmission interval to 150 ms, the time between
text spurts for 5 simultaneous sending parties would be 2.5 seconds. text spurts for 5 simultaneous sending parties would be 2.5 seconds.
Five simultaneous sending parties may occasionally occur in a Five simultaneous sending parties may occasionally occur in a
conference with one or two main sending parties and three parties conference with one or two main sending parties and three parties
giving very brief comments. giving very brief comments.
The default maximum rate of reception of real-time text is in RFC The default maximum rate of reception of "text/t140" real-time text
4103 [RFC4103] specified to be 30 characters per second. The value is in RFC 4103 [RFC4103] specified to be 30 characters per second.
MAY be modified in the CPS parameter of the FMTP attribute in the The value MAY be modified in the CPS parameter of the FMTP attribute
media section for RFC 4103. A mixer combining real-time text from a in the media section for the "text/t140" media. A mixer combining
number of sources may have a higher combined flow of text coming from real-time text from a number of sources may have a higher combined
the sources. Endpoints SHOULD therefore specify a suitable higher flow of text coming from the sources. Endpoints SHOULD therefore
value for the CPS parameter, corresponding to its real reception specify a suitable higher value for the CPS parameter, corresponding
capability. A value for CPS of 150 is the default for the "text/rex" to its real reception capability. A value for CPS of 150 is the
format. See RFC 4103 [RFC4103] for the format and use of the CPS default for the "text/t140" stream in the "text/rex" format. See RFC
parameter. The same rules apply for the "text/rex" format except for 4103 [RFC4103] for the format and use of the CPS parameter. The same
the default value. rules apply for the "text/rex" format except for the default value.
14. Presentation level considerations 14. Presentation level considerations
ITU-T T.140 [T140] provides the presentation level requirements for ITU-T T.140 [T140] provides the presentation level requirements for
the RFC 4103 [RFC4103] transport. T.140 [T140] has functions for the RFC 4103 [RFC4103] transport. T.140 [T140] has functions for
erasure and other formatting functions and has the following general erasure and other formatting functions and has the following general
statement for the presentation: statement for the presentation:
"The display of text from the members of the conversation should be "The display of text from the members of the conversation should be
arranged so that the text from each participant is clearly readable, arranged so that the text from each participant is clearly readable,
skipping to change at page 33, line 7 skipping to change at page 34, line 35
The requirement to transfer information about the user in RTCP The requirement to transfer information about the user in RTCP
reports in SDES, CNAME and NAME fields, and in conference reports in SDES, CNAME and NAME fields, and in conference
notifications, for creation of labels may have privacy concerns as notifications, for creation of labels may have privacy concerns as
already stated in RFC 3550 [RFC3550], and may be restricted of already stated in RFC 3550 [RFC3550], and may be restricted of
privacy reasons. The receiving user will then get a more symbolic privacy reasons. The receiving user will then get a more symbolic
label for the source. label for the source.
21. Change history 21. Change history
21.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05 21.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06
Improved definitions list format.
The format of the media subtype parameters is made to match the
requirements.
The mapping of media subtype parameters to sdp is included.
The CPS parameter belongs to the t140 subtype and does not need to be
registered here.
21.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05
nomenclature and editorial improvements nomenclature and editorial improvements
"this document" used consistently to refer to this document. "this document" used consistently to refer to this document.
21.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04 21.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04
'Redundancy header' renamed to 'data header'. 'Redundancy header' renamed to 'data header'.
More clarifications added. More clarifications added.
Language and figure number corrections. Language and figure number corrections.
21.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03 21.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03
Mention possible need to mute and raise hands as for other media. Mention possible need to mute and raise hands as for other media.
---done ---- ---done ----
Make sure that use in two-party calls is also possible and explained. Make sure that use in two-party calls is also possible and explained.
- may need more wording - - may need more wording -
Clarify the RTT is often used together with other media. --done-- Clarify the RTT is often used together with other media. --done--
Tell that text mixing is N-1. A users own text is not received in Tell that text mixing is N-1. A users own text is not received in
skipping to change at page 34, line 4 skipping to change at page 35, line 45
-done- -done-
In 1.3 say that the format is used both ways. -done- In 1.3 say that the format is used both ways. -done-
In 13.1 change presentation area to presentation field so that reader In 13.1 change presentation area to presentation field so that reader
does not think it shall be totally separated. -done- does not think it shall be totally separated. -done-
In Performance and intro, tell the performance in number of In Performance and intro, tell the performance in number of
simultaneous sending users and introduced delay 16, 150 vs simultaneous sending users and introduced delay 16, 150 vs
requirements 5 vs 500. -done -- requirements 5 vs 500. -done --
Clarify redundancy level per connection. -done- Clarify redundancy level per connection. -done-
Timestamp also for the last data header. To make it possible for all Timestamp also for the last data header. To make it possible for all
text to have time offset as for transmission from the source. Make text to have time offset as for transmission from the source. Make
that header equal to the others. -done- that header equal to the others. -done-
Mixer always use the CSRC list, even for its own BOM. -done- Mixer always use the CSRC list, even for its own BOM. -done-
Combine all talk about transmission interval (300 ms vs when text has Combine all talk about transmission interval (300 ms vs when text has
arrived) in section 3 in one paragraph or close to each other. -done- arrived) in section 3 in one paragraph or close to each other. -done-
Documents the goal of good performance with low delay for 5 Documents the goal of good performance with low delay for 5
simultaneous typers in the introduction. -done- simultaneous typers in the introduction. -done-
Describe better that only primary text shall be sent on to receivers. Describe better that only primary text shall be sent on to receivers.
Redundancy and loss must be resolved by the mixer. -done- Redundancy and loss must be resolved by the mixer. -done-
21.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02 21.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02
SDP and better description and visibility of security by OSRTP RFC SDP and better description and visibility of security by OSRTP RFC
8634 needed. 8634 needed.
The description of gatewaying to WebRTC extended. The description of gatewaying to WebRTC extended.
The description of the data header in the packet is improved. The description of the data header in the packet is improved.
21.5. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 21.6. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01
2,5,6 More efficient format "text/rex" introduced and attribute 2,5,6 More efficient format "text/rex" introduced and attribute
a=rtt-mix deleted. a=rtt-mix deleted.
3. Brief about use of OSRTP for security included- More needed. 3. Brief about use of OSRTP for security included- More needed.
4. Brief motivation for the solution and why not rtp-translator is 4. Brief motivation for the solution and why not rtp-translator is
used added to intro. used added to intro.
7. More limitations for the multi-party unaware mixing method 7. More limitations for the multi-party unaware mixing method
inserted. inserted.
8. Updates to RFC 4102 and 4103 more clearly expressed. 8. Updates to RFC 4102 and 4103 more clearly expressed.
9. Gateway to WebRTC started. More needed. 9. Gateway to WebRTC started. More needed.
21.6. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 to 21.7. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 to
draft-ietf-avtcore-multi-party-rtt-mix-00 draft-ietf-avtcore-multi-party-rtt-mix-00
Changed file name to draft-ietf-avtcore-multi-party-rtt-mix-00 Changed file name to draft-ietf-avtcore-multi-party-rtt-mix-00
Replaced CDATA in IANA registration table with better coding. Replaced CDATA in IANA registration table with better coding.
Converted to xml2rfc version 3. Converted to xml2rfc version 3.
21.7. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 to 21.8. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-03 -03
Changed company and e-mail of the author. Changed company and e-mail of the author.
Changed title to "RTP-mixer formatting of multi-party Real-time text" Changed title to "RTP-mixer formatting of multi-party Real-time text"
to better match contents. to better match contents.
Check and modification where needed of use of RFC 2119 words SHALL Check and modification where needed of use of RFC 2119 words SHALL
etc. etc.
More about the CC value in sections on transmitters and receivers so More about the CC value in sections on transmitters and receivers so
that 1-to-1 sessions do not use the mixer format. that 1-to-1 sessions do not use the mixer format.
Enhanced section on presentation for multi-party-unaware endpoints Enhanced section on presentation for multi-party-unaware endpoints
A paragraph recommending CPS=150 inserted in the performance section. A paragraph recommending CPS=150 inserted in the performance section.
21.8. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 to 21.9. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-02 -02
In Abstract and 1. Introduction: Introduced wording about regulatory In Abstract and 1. Introduction: Introduced wording about regulatory
requirements. requirements.
In section 5: The transmission interval is decreased to 100 ms when In section 5: The transmission interval is decreased to 100 ms when
there is text from more than one source to transmit. there is text from more than one source to transmit.
In section 11 about SDP negotiation, a SHOULD-requirement is In section 11 about SDP negotiation, a SHOULD-requirement is
introduced that the mixer should make a mix for multi-party unaware introduced that the mixer should make a mix for multi-party unaware
skipping to change at page 36, line 21 skipping to change at page 38, line 14
In chapter 9. "Use with SIP centralized conferencing framework" the In chapter 9. "Use with SIP centralized conferencing framework" the
following note is inserted: Note: The CSRC-list in an RTP packet only following note is inserted: Note: The CSRC-list in an RTP packet only
includes participants who's text is included in one or more text includes participants who's text is included in one or more text
blocks. It is not the same as the list of participants in a blocks. It is not the same as the list of participants in a
conference. With audio and video media, the CSRC-list would often conference. With audio and video media, the CSRC-list would often
contain all participants who are not muted whereas text participants contain all participants who are not muted whereas text participants
that don't type are completely silent and so don't show up in RTP that don't type are completely silent and so don't show up in RTP
packet CSRC-lists. packet CSRC-lists.
21.9. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00 to 21.10. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00
-01 to -01
Editorial cleanup. Editorial cleanup.
Changed capability indication from fmtp-parameter to SDP attribute Changed capability indication from fmtp-parameter to SDP attribute
"rtt-mix". "rtt-mix".
Swapped order of redundancy elements in the example to match reality. Swapped order of redundancy elements in the example to match reality.
Increased the SDP negotiation section Increased the SDP negotiation section
 End of changes. 51 change blocks. 
113 lines changed or deleted 182 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/