draft-ietf-avtcore-multi-party-rtt-mix-10.txt   draft-ietf-avtcore-multi-party-rtt-mix-11.txt 
AVTCore G. Hellstrom AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: RFC 4103 (if approved) 18 November 2020 Updates: RFC 4103 (if approved) 22 November 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 22 May 2021 Expires: 26 May 2021
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-10 draft-ietf-avtcore-multi-party-rtt-mix-11
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, while new text from other sources is also presented in same source, while new text from other sources is also presented in
readable grouping as received interleaved in real-time. readable grouping as received interleaved in real-time.
Regional regulatory requirements specify provision of real-time text Regional regulatory requirements specify provision of real-time text
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 22 May 2021. This Internet-Draft will expire on 26 May 2021.
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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Intended application . . . . . . . . . . . . . . . . . . 8 1.3. Intended application . . . . . . . . . . . . . . . . . . 8
2. Overview over the two specified solutions . . . . . . . . . . 8 2. Overview over the two specified solutions . . . . . . . . . . 9
2.1. Negotiated use of the RFC 4103 format for multi-party 2.1. Negotiated use of the RFC 4103 format for multi-party
transmission in a single RTP stream . . . . . . . . . . . 9 transmission in a single RTP stream . . . . . . . . . . . 9
2.2. Mixing for multi-party unaware endpoints . . . . . . . . 9 2.2. Mixing for multi-party unaware endpoints . . . . . . . . 9
3. Details for the multi-party aware mixing case . . . . . . . . 9 3. Details for the multi-party aware mixing case . . . . . . . . 9
3.1. Offer/answer considerations . . . . . . . . . . . . . . . 9 3.1. Offer/answer considerations . . . . . . . . . . . . . . . 10
3.2. Actions depending on capability negotiation result . . . 10 3.2. Actions depending on capability negotiation result . . . 10
3.3. Use of fields in the RTP packets . . . . . . . . . . . . 10 3.3. Use of fields in the RTP packets . . . . . . . . . . . . 10
3.4. Initial transmission of a BOM character . . . . . . . . . 11 3.4. Initial transmission of a BOM character . . . . . . . . . 11
3.5. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Transmission interval . . . . . . . . . . . . . . . . . . 11 3.6. Transmission interval . . . . . . . . . . . . . . . . . . 11
3.7. Only one source per packet . . . . . . . . . . . . . . . 11 3.7. Only one source per packet . . . . . . . . . . . . . . . 11
3.8. Do not send received text to the originating source . . . 11 3.8. Do not send received text to the originating source . . . 12
3.9. Clean incoming text . . . . . . . . . . . . . . . . . . . 11 3.9. Clean incoming text . . . . . . . . . . . . . . . . . . . 12
3.10. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 12 3.10. Redundant transmission principles . . . . . . . . . . . . 12
3.11. Source switching . . . . . . . . . . . . . . . . . . . . 12 3.11. Interleaving text from different sources . . . . . . . . 12
3.12. Text placement in packets . . . . . . . . . . . . . . . . 12 3.12. Text placement in packets . . . . . . . . . . . . . . . . 12
3.13. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 13 3.13. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 13
3.14. Creation of the redundancy . . . . . . . . . . . . . . . 13 3.14. Creation of the redundancy . . . . . . . . . . . . . . . 13
3.15. Timer offset fields . . . . . . . . . . . . . . . . . . . 13 3.15. Timer offset fields . . . . . . . . . . . . . . . . . . . 14
3.16. Other RTP header fields . . . . . . . . . . . . . . . . . 14 3.16. Other RTP header fields . . . . . . . . . . . . . . . . . 14
3.17. Pause in transmission . . . . . . . . . . . . . . . . . . 14 3.17. Pause in transmission . . . . . . . . . . . . . . . . . . 14
3.18. RTCP considerations . . . . . . . . . . . . . . . . . . . 14 3.18. RTCP considerations . . . . . . . . . . . . . . . . . . . 15
3.19. Reception of multi-party contents . . . . . . . . . . . . 15 3.19. Reception of multi-party contents . . . . . . . . . . . . 15
3.20. Performance considerations . . . . . . . . . . . . . . . 17 3.20. Performance considerations . . . . . . . . . . . . . . . 17
3.21. Security for session control and media . . . . . . . . . 17 3.21. Security for session control and media . . . . . . . . . 18
3.22. SDP offer/answer examples . . . . . . . . . . . . . . . . 18 3.22. SDP offer/answer examples . . . . . . . . . . . . . . . . 18
3.23. Packet sequence example from a source switch . . . . . . 19 3.23. Packet sequence example from interleaved transmission . . 19
3.24. Maximum character rate "CPS" . . . . . . . . . . . . . . 21 3.24. Maximum character rate "CPS" . . . . . . . . . . . . . . 22
4. Presentation level considerations . . . . . . . . . . . . . . 21 4. Presentation level considerations . . . . . . . . . . . . . . 22
4.1. Presentation by multi-party aware endpoints . . . . . . . 22 4.1. Presentation by multi-party aware endpoints . . . . . . . 23
4.2. Multi-party mixing for multi-party unaware endpoints . . 24 4.2. Multi-party mixing for multi-party unaware endpoints . . 25
5. Relation to Conference Control . . . . . . . . . . . . . . . 29 5. Relation to Conference Control . . . . . . . . . . . . . . . 30
5.1. Use with SIP centralized conferencing framework . . . . . 30 5.1. Use with SIP centralized conferencing framework . . . . . 31
5.2. Conference control . . . . . . . . . . . . . . . . . . . 30 5.2. Conference control . . . . . . . . . . . . . . . . . . . 31
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 30 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 31
6.1. Gateway considerations with Textphones (e.g. TTYs). . . 30 6.1. Gateway considerations with Textphones (e.g. TTYs). . . 31
6.2. Gateway considerations with WebRTC. . . . . . . . . . . . 31 6.2. Gateway considerations with WebRTC. . . . . . . . . . . . 32
7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 31 7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 32
8. Congestion considerations . . . . . . . . . . . . . . . . . . 31 8. Congestion considerations . . . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1. Registration of the "rtt-mixer" sdp media attribute . . 32 10.1. Registration of the "rtt-mixer" sdp media attribute . . 33
11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34
12. Change history . . . . . . . . . . . . . . . . . . . . . . . 33 12. Change history . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Changes included in 12.1. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 33 draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 34
12.2. Changes included in 12.2. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 33 draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 34
12.3. Changes included in 12.3. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 34 draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 34
12.4. Changes included in 12.4. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 34 draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 35
12.5. Changes included in 12.5. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 34 draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 35
12.6. Changes included in 12.6. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 34 draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 35
12.7. Changes included in 12.7. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 34 draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 35
12.8. Changes included in 12.8. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 35 draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 36
12.9. Changes included in 12.9. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 36 draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 36
12.10. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 36
12.11. Changes from 12.10. Changes included in
draft-hellstrom-avtcore-multi-party-rtt-source-03 to draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 37
draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 36 12.11. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 37
12.12. Changes from 12.12. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-02 to draft-hellstrom-avtcore-multi-party-rtt-source-03 to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 37
12.13. Changes from 12.13. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 37 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.14. Changes from 12.14. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.15. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-00 to draft-hellstrom-avtcore-multi-party-rtt-source-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. Normative References . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
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 9, line 10 skipping to change at page 9, line 22
2. Overview over the two specified solutions 2. Overview over the two specified solutions
This section contains a brief introduction of the two methods This section contains a brief introduction of the two methods
specified in this document. specified in this document.
2.1. Negotiated use of the RFC 4103 format for multi-party transmission 2.1. Negotiated use of the RFC 4103 format for multi-party transmission
in a single RTP stream in a single RTP stream
The main purpose of this document is to specify a method for true The main purpose of this document is to specify a method for true
multi-party real-time text mixing for multi-party aware endpoints. multi-party real-time text mixing for multi-party aware endpoints.
The method use of the current format for real-time text in [RFC4103]. The method makes use of the current format for real-time text in
It is an update of RFC 4103 by a clarification on one way to use it [RFC4103]. It is an update of RFC 4103 by a clarification on one way
in the multi-party situation. It is done by completing a negotiation to use it in the multi-party situation. It is done by completing a
for this kind of multi-party capability and by indicating source in negotiation for this kind of multi-party capability and by indicating
the CSRC element in the RTP packets. Specific considerations are source in the CSRC element in the RTP packets. Specific
made to be able to recover text after packet loss. considerations are made to be able to recover text after packet loss.
The detailed procedures for the multi-party aware case are specified The detailed procedures for the multi-party aware case are specified
in Section 3 in Section 3
Please use [RFC4103] as reference when reading the specification. Please use [RFC4103] as reference when reading the specification.
2.2. Mixing for multi-party unaware endpoints 2.2. Mixing for multi-party unaware endpoints
A method is also specified in this document for cases when the A method is also specified in this document for cases when the
endpoint participating in a multi-party call does not itself endpoint participating in a multi-party call does not itself
implement any solution for multi-party handling of real-time text. implement any solution for multi-party handling of real-time text.
The solution requires the mixer to insert text dividers and readable The solution requires the mixer to insert text dividers and readable
labels and only send text from one source at a time until a suitable labels and only send text from one source at a time until a suitable
point appears for source change. This solution is a fallback method point appears for source change. This solution is a fallback method
with functional limitations that acts on the presentation level. with functional limitations. It acts on the presentation level.
A party performing as a mixer, which has not negotiated the "rtt- A party performing as a mixer, which has not negotiated the "rtt-
mixer" sdp media attribute, but negotiated a "text/red" or "text/ mixer" sdp media attribute, but negotiated a "text/red" or "text/
t140" format in a session with a participant SHOULD, if nothing else t140" format in a session with a participant SHOULD, if nothing else
is specified for the application, format transmitted text to that is specified for the application, format transmitted text to that
participant to be suitable to present on a multi-party unaware participant to be suitable to present on a multi-party unaware
endpoint as further specified in Section 4.2. endpoint as further specified in Section 4.2.
3. Details for the multi-party aware mixing case 3. Details for the multi-party aware mixing case
3.1. Offer/answer considerations 3.1. Offer/answer considerations
RFC 4103[RFC4103] specifies use of RFC 3550 RTP[RFC3550], and a RFC 4103[RFC4103] specifies use of RFC 3550 RTP[RFC3550], and a
redundancy format "text/red" for increased robustness of real-time redundancy format "text/red" for increased robustness of real-time
text transmission. This document updates RFC 4103[RFC4103] by text transmission. This document updates RFC 4103[RFC4103] by
introducing a capability negotiation for handling multi-party real- introducing a capability negotiation for handling multi-party real-
time text, a way to indicate the source of transmitted text, and time text, a way to indicate the source of transmitted text, and
rules for efficient timing of the transmissions. rules for efficient timing of the transmissions interleaved from
different sources.
The capability negotiation is based on use of the sdp media attribute The capability negotiation is based on use of the sdp media attribute
"rtt-mixer". "rtt-mixer".
Both parties shall indicate their capability in a session setup or Both parties shall indicate their capability in a session setup or
modification, and evaluate the capability of the counterpart. modification, and evaluate the capability of the counterpart.
The syntax is as follows: The syntax is as follows:
"a=rtt-mixer" "a=rtt-mixer"
skipping to change at page 11, line 25 skipping to change at page 11, line 31
3.5. Keep-alive 3.5. Keep-alive
After that, the transmitter SHALL send keep-alive traffic to the After that, the transmitter SHALL send keep-alive traffic to the
receiver(s) at regular intervals when no other traffic has occurred receiver(s) at regular intervals when no other traffic has occurred
during that interval, if that is decided for the actual connection. during that interval, if that is decided for the actual connection.
Recommendations for keep-alive can be found in [RFC6263]. Recommendations for keep-alive can be found in [RFC6263].
3.6. Transmission interval 3.6. Transmission interval
A "text/red" transmitter in a mixer SHOULD send packets distributed A "text/red" or "text/t140" transmitter in a mixer SHOULD send
in time as long as there is something (new or redundant T140blocks) packets distributed in time as long as there is something (new or
to transmit. The maximum transmission interval SHOULD then be 330 redundant T140blocks) to transmit. The maximum transmission interval
ms. It is RECOMMENDED to send next packet to a receiver as soon as SHOULD then be 330 ms. It is RECOMMENDED to send next packet to a
new text to that receiver is available, as long as the time after the receiver as soon as new text to that receiver is available, as long
latest sent packet to the same receiver is more than or equal to 100 as the time after the latest sent packet to the same receiver is more
ms, and also the maximum character rate to the receiver is not than or equal to 100 ms, and also the maximum character rate ("CPS")
exceeded. The intention is to keep the latency low and network load to the receiver is not exceeded. The intention is to keep the
limited while keeping a good protection against text loss in bursty latency low and network load limited while keeping a good protection
packet loss conditions. against text loss in bursty packet loss conditions.
For a transmitter not acting in a mixer, the same transmission
interval principles apply, but the maximum transmission interval
SHOULD be 300 ms.
3.7. Only one source per packet 3.7. Only one source per packet
New and redundant text from one source SHALL be transmitted in the New and redundant text from one source SHALL be transmitted in the
same packet if available for transmission at the same time. Text same packet if available for transmission at the same time. Text
from different sources MUST NOT be transmitted in the same packet. from different sources MUST NOT be transmitted in the same packet.
3.8. Do not send received text to the originating source 3.8. Do not send received text to the originating source
Text received to a mixer from a participant SHOULD NOT be included in Text received to a mixer from a participant SHOULD NOT be included in
transmission from the mixer to that participant. transmission from the mixer to that participant.
3.9. Clean incoming text 3.9. Clean incoming text
A mixer SHALL handle reception, recovery of packet loss, deletion of A mixer SHALL handle reception, recovery from packet loss, deletion
superfluous redundancy, marking of possible text loss and deletion of of superfluous redundancy, marking of possible text loss and deletion
'BOM' characters from each participant before queueing received text of 'BOM' characters from each participant before queueing received
for transmission to receiving participants. text for transmission to receiving participants.
3.10. Redundancy 3.10. Redundant transmission principles
A transmitting party using redundancy SHALL send redundant A transmitting party using redundancy SHALL send redundant
repetitions of T140blocks already transmitted in earlier packets. repetitions of T140blocks already transmitted in earlier packets.
The number of redundant generations of T140blocks to include in The number of redundant generations of T140blocks to include in
transmitted packets SHALL be deduced from the SDP negotiation. It transmitted packets SHALL be deduced from the SDP negotiation. It
SHOULD be set to the minimum of the number declared by the two SHOULD be set to the minimum of the number declared by the two
parties negotiating a connection. It is RECOMMENDED to transmit one parties negotiating a connection. It is RECOMMENDED to declare and
original and two redundant generations of the T140blocks. transmit one original and two redundant generations of the
T140blocks.
3.11. Source switching 3.11. Interleaving text from different sources
When text from more than one source is available for transmission When text from more than one source is available for transmission
from a mixer, the mixer SHALL let the sources take turns in having from a mixer, the mixer SHALL let the sources take turns in having
their text transmitted. their text transmitted.
The source with the oldest received text in the mixer SHOULD be next The source with the oldest text received in the mixer or oldest
in turn to get all its available unsent text transmitted. redundant text SHOULD be next in turn to get all its available unsent
text transmitted. The age of redundant text SHOULD then be
considered to be 330 ms after its previous transmission.
3.12. Text placement in packets 3.12. Text placement in packets
The mixer SHOULD compose and transmit an RTP packet to a receiver The mixer SHOULD compose and transmit an RTP packet to a receiver
when one of the following conditions has occurred: when one of the following conditions has occurred:
* 100 ms has passed since the latest transmission to that receiver, * 100 ms has passed since the latest transmission to that receiver,
and there is unsent text available for transmission. and there is unsent text available for transmission.
* New text has arrived and more than 100 ms has passed since latest * New text has arrived and more than 100 ms has passed since latest
skipping to change at page 12, line 48 skipping to change at page 13, line 17
since the latest transmission to that receiver, and the redundant since the latest transmission to that receiver, and the redundant
text is still not sent. text is still not sent.
At time of transmission, the mixer SHALL populate the RTP packet with At time of transmission, the mixer SHALL populate the RTP packet with
all T140blocks queued for transmission originating from the source in all T140blocks queued for transmission originating from the source in
turn for transmission as long as this is not in conflict with the turn for transmission as long as this is not in conflict with the
allowed number of characters per second ("CPS") or the maximum packet allowed number of characters per second ("CPS") or the maximum packet
size. In this way, the latency of the latest received text is kept size. In this way, the latency of the latest received text is kept
low even in moments of simultaneous transmission from many sources. low even in moments of simultaneous transmission from many sources.
Redundant text SHALL also be included. See Section 3.14
The SSRC of the source shall be placed as the only member in the The SSRC of the source shall be placed as the only member in the
CSRC-list. CSRC-list.
Note: The CSRC-list in an RTP packet only includes the participant Note: The CSRC-list in an RTP packet only includes the participant
who's text is included in text blocks. It is not the same as the who's text is included in text blocks. It is not the same as the
total list of participants in a conference. With audio and video total list of participants in a conference. With audio and video
media, the CSRC-list would often contain all participants who are not media, the CSRC-list would often contain all participants who are not
muted whereas text participants that don't type are completely silent muted whereas text participants that don't type are completely silent
and thus are not represented in RTP packet CSRC-lists. and thus are not represented in RTP packet CSRC-lists.
skipping to change at page 13, line 44 skipping to change at page 14, line 13
text from that source. text from that source.
Usually this is the level of redundancy used. If a higher number of Usually this is the level of redundancy used. If a higher number of
redundancy is negotiated, then the procedure SHALL be maintained redundancy is negotiated, then the procedure SHALL be maintained
until all available redundant levels of T140blocks are placed in the until all available redundant levels of T140blocks are placed in the
packet. If a receiver has negotiated a lower number of "text/red" packet. If a receiver has negotiated a lower number of "text/red"
generations, then that level shall be the maximum used by the generations, then that level shall be the maximum used by the
transmitter. transmitter.
The T140blocks saved for transmission as redundant data are assigned The T140blocks saved for transmission as redundant data are assigned
a planned transmission time 330 ms after the current time. a planned transmission time 330 ms after the current time, but SHOULD
be transmitted earlier if new text for the same source gets in turn
for transmission before that time.
3.15. Timer offset fields 3.15. Timer offset fields
The timestamp offset values are inserted in the redundancy header, The timestamp offset values are inserted in the redundancy header,
with the time offset from the RTP timestamp in the packet when the with the time offset from the RTP timestamp in the packet when the
corresponding T140block was sent as primary. corresponding T140block was sent as primary.
The timestamp offsets are expressed in the same clock tick units as The timestamp offsets are expressed in the same clock tick units as
the RTP timestamp. the RTP timestamp.
skipping to change at page 15, line 32 skipping to change at page 15, line 42
3.19.2. Level of redundancy 3.19.2. Level of redundancy
The used level of redundancy generations SHALL be evaluated from the The used level of redundancy generations SHALL be evaluated from the
received packet contents. The number of generations (including the received packet contents. The number of generations (including the
primary) is equal to the number of members in the redundancy header. primary) is equal to the number of members in the redundancy header.
3.19.3. Empty T140blocks 3.19.3. Empty T140blocks
Empty T140blocks are included as fillers for unused primary or Empty T140blocks are included as fillers for unused primary or
redundancy levels in the packets. They just do not provide any redundancy levels in the packets. They just do not provide any
contents and do not contribute to the received streams. contents.
3.19.4. Detection and indication of possible text loss 3.19.4. Detection and indication of possible text loss
The RTP sequence numbers of the received packets SHALL be monitored The RTP sequence numbers of the received packets SHALL be monitored
for gaps and packets out of order. If a sequence number gap appears for gaps and packets out of order. If a sequence number gap appears
and still exists after some defined short time for jitter resolution, and still exists after some defined short time for jitter resolution,
the packets in the gap SHALL be regarded lost. the packets in the gap SHALL be regarded lost.
If it is known that only one source is active in the RTP session, If it is known that only one source is active in the RTP session,
then it is likely that a gap equal to or larger than the agreed then it is likely that a gap equal to or larger than the agreed
number of redundancy generations causes text loss. In that case a number of redundancy generations (including the primary) causes text
t140block SHALL be created with a marker for possible text loss loss. In that case a t140block SHALL be created with a marker for
[T140ad1] and assigned to the source and inserted in the reception possible text loss [T140ad1] and assigned to the source and inserted
buffer for that source. in the reception buffer for that source.
If it is known that more than one source is active in the RTP If it is known that more than one source is active in the RTP
session, then it is not possible in general to evaluate if text was session, then it is not possible in general to evaluate if text was
lost when packets were lost. With two active sources and the lost when packets were lost. With two active sources and the
recommended number of redundancy generations (3), it can take a gap recommended number of redundancy generations (3), it can take a gap
of five lost packets until any text may be lost, but text loss can of five consecutive lost packets until any text may be lost, but text
also appear if three non-consecutive packets are lost when they loss can also appear if three non-consecutive packets are lost when
contained consecutive data from the same source. A simple method to they contained consecutive data from the same source. A simple
decide when there is risk for resulting text loss is to evaluate if method to decide when there is risk for resulting text loss is to
three or more packets were lost within one second. Then a t140block evaluate if three or more packets were lost within one second. Then
SHALL be created with a marker for possible text loss [T140ad1] and a t140block SHALL be created with a marker for possible text loss
assigned to the SSRC of the transmitter as a general input from the [T140ad1] and assigned to the SSRC of the transmitter as a general
mixer. input from the mixer.
Implementations MAY apply more refined methods for more reliable Implementations MAY apply more refined methods for more reliable
detection of if text was lost or not. Any refined method SHOULD detection of if text was lost or not. Any refined method SHOULD
rather falsely mark possible loss when there was no loss instead of rather falsely mark possible loss when there was no loss instead of
not marking possible loss when there was loss. not marking possible loss when there was loss.
3.19.5. Extracting text and handling recovery 3.19.5. Extracting text and handling recovery
When applying the following procedures, the effects MUST be When applying the following procedures, the effects MUST be
considered of possible timestamp wrap around and the RTP session considered of possible timestamp wrap around and the RTP session
possibly changing SSRC. possibly changing SSRC.
When a packet is received in an RTP session using the packetization When a packet is received in an RTP session using the packetization
for multi-party aware endpoints, its T140blocks SHALL be extracted in for multi-party aware endpoints, its T140blocks SHALL be extracted in
the following way. The description is adapted to the default the following way. The description is adapted to the default
redundancy case using the original and two redundant generations. redundancy case using the original and two redundant generations.
When applying the following procedures, the effects MUST be
considered of possible timestamp wrap around and the RTP session
possibly changing SSRC.
The source SHALL be extracted from the CSRC-list if available, The source SHALL be extracted from the CSRC-list if available,
otherwise from the SSRC. otherwise from the SSRC.
If the received packet is the first packet received from the source, If the received packet is the first packet received from the source,
then all T140blocks in the packet SHALL be retrieved and assigned to then all T140blocks in the packet SHALL be retrieved and assigned to
a receive buffer for the source beginning with the second generation a receive buffer for the source beginning with the second generation
redundancy, continuing with the first generation redundancy and redundancy, continuing with the first generation redundancy and
finally the primary. finally the primary.
Note that the normal case is that in the first packet, only the Note: The normal case is that in the first packet, only the primary
primary data has contents. The redundant data has contents in the data has contents. The redundant data has contents in the first
first received packet from a source only after initial packet loss. received packet from a source only after initial packet loss.
If the packet is not the first packet from a source, then if the If the packet is not the first packet from a source, then if the
second generation redundant data is available, its timestamp SHALL be second generation redundant data is available, its timestamp SHALL be
created by subtracting its timestamp offset from the RTP timestamp. created by subtracting its timestamp offset from the RTP timestamp.
If the resulting timestamp is later than the latest retrieved data If the resulting timestamp is later than the latest retrieved data
from the same source, then the redundant data SHALL be retrieved and from the same source, then the redundant data SHALL be retrieved and
appended to the receive buffer. The process SHALL be continued in appended to the receive buffer. The process SHALL be continued in
the same way for the first generation redundant data. After that, the same way for the first generation redundant data. After that,
the primary data SHALL be retrieved from the packet and appended to the primary data SHALL be retrieved from the packet and appended to
the receive buffer for the source. the receive buffer for the source.
skipping to change at page 17, line 28 skipping to change at page 17, line 32
used as a filler or keep alive by transmission implementations. used as a filler or keep alive by transmission implementations.
These SHALL be deleted after extraction from received packets. These SHALL be deleted after extraction from received packets.
3.20. Performance considerations 3.20. Performance considerations
This solution has good performance for up to five participants This solution has good performance for up to five participants
simultaneously sending text. At higher numbers of participants simultaneously sending text. At higher numbers of participants
simultaneously sending text, a jerkiness is visible in the simultaneously sending text, a jerkiness is visible in the
presentation of text. With ten participants simultaneously presentation of text. With ten participants simultaneously
transmitting text, the jerkiness is about one second. Even so, the transmitting text, the jerkiness is about one second. Even so, the
transmission of text catches up, so there is no resulting total delay transmission of text catches up, so there is limited delay of new
introduced. The solution is therefore suitable for emergency service text. The solution is therefore suitable for emergency service use,
use, relay service use, and small or well-managed larger multimedia relay service use, and small or well-managed larger multimedia
conferences. Only in large unmanaged conferences with a high number conferences. Only in large unmanaged conferences with a high number
of participants there may on very rare occasions appear situations of participants there may on very rare occasions appear situations
when many participants happen to send text simultaneously, resulting when many participants happen to send text simultaneously, resulting
in unpleasantly long switching times. It should be noted that it is in unpleasantly jerky presentation of text from each sending
only the number of users sending text within the same moment that participant. It should be noted that it is only the number of users
causes jerkiness, not the total number of users with RTT capability. sending text within the same moment that causes jerkiness, not the
total number of users with RTT capability.
3.21. Security for session control and media 3.21. 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 SHOULD be performed to decide if security by encryption negotiation SHOULD be performed to decide if security by encryption
will be applied. If no other security solution is mandated for the will be applied. If no other security solution is mandated for the
application, then RFC 8643 OSRTP[RFC8643] SHOULD be applied to application, then RFC 8643 OSRTP [RFC8643] SHOULD be applied to
negotiate SRTP media security with DTLS. Most SDP examples below are negotiate SRTP media security with DTLS. Most SDP examples below are
for simplicity expressed without the security additions. The for simplicity expressed without the security additions. The
principles (but not all details) for applying DTLS-SRTP security is principles (but not all details) for applying DTLS-SRTP [RFC5764]
shown in a couple of the following examples. security is shown in a couple of the following examples.
3.22. SDP offer/answer examples 3.22. 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 "text/red" format and multi-party support: Offer example for "text/red" format and multi-party support:
skipping to change at page 19, line 13 skipping to change at page 19, line 23
With the "fingerprint" the device acknowledges use of SRTP/DTLS. With the "fingerprint" the device acknowledges use of SRTP/DTLS.
Answer example from a multi-party unaware device that also Answer example from a multi-party unaware device that also
does not support security: does not support security:
m=text 12000 RTP/AVP 100 98 m=text 12000 RTP/AVP 100 98
a=rtpmap:98 t140/1000 a=rtpmap:98 t140/1000
a=rtpmap:100 red/1000 a=rtpmap:100 red/1000
a=fmtp:100 98/98/98 a=fmtp:100 98/98/98
3.23. Packet sequence example from a source switch 3.23. Packet sequence example from interleaved transmission
This example shows a symbolic flow of packets from a mixer including This example shows a symbolic flow of packets from a mixer including
loss and recovery. The sequence includes a source switch. A and B loss and recovery. The sequence includes interleaved transmission of
are sources of RTT. P indicates primary data. R1 is first redundant text from two RTT sources A and B. P indicates primary data. R1 is
generation data and R2 is second redundant generation data. A1, B1, first redundant generation data and R2 is the second redundant
A2 etc are text chunks (T140blocks) received from the respective generation data. A1, B1, A2 etc are text chunks (T140blocks)
sources. X indicates dropped packet between the mixer and a received from the respective sources and sent on to the receiver by
the mixer. X indicates dropped packet between the mixer and a
receiver. The session is assumed to use original and two redundant receiver. The session is assumed to use original and two redundant
generations of RTT. generations of RTT.
|----------------| |-----------------------|
|Seq no 101 | |Seq no 101, Time=20400 |
|CC=1 | |CC=1 |
|CSRC list A | |CSRC list A |
|R2: A1 | |R2: A1, Offset=600 |
|R1: A2 | |R1: A2, Offset=300 |
|P: A3 | |P: A3 |
|----------------| |-----------------------|
Assuming that earlier packets ( with text A1 and A2) were received in Assuming that earlier packets ( with text A1 and A2) were received in
sequence, text A3 is received from packet 101 and assigned to sequence, text A3 is received from packet 101 and assigned to
reception area A. The mixer is now assumed to have received text reception area A. The mixer is now assumed to have received text
from source B and will send that text 100 ms after packet 101. from source B and will send that text 100 ms after packet 101.
Transmission of A2 and A3 as redundancy is planned for 200 ms after Transmission of A2 and A3 as redundancy is planned for 330 ms after
packet 101. packet 101 if no new text from A is ready to be sent before that.
|----------------| |-----------------------|
|Seq no 102 | |Seq no 102, Time=20500 |
|CC=1 | |CC=1 |
|CSRC list B | |CSRC list B |
|R2 Empty | |R2 Empty, Offset=600 |
|R1: Empty | |R1: Empty, Offset=300 |
|P: B1 | |P: B1 |
|----------------| |-----------------------|
Packet 102 is received.
B1 is retrieved from this packet. Redundant transmission of B1 is retrieved from this packet. Redundant transmission of
B1 is planned 200 ms after packet 102. B1 is planned 330 ms after packet 102.
X----------------| X------------------------|
X Seq no 103 | X Seq no 103, Timer=20730|
X CC=1 | X CC=1 |
X CSRC list A | X CSRC list A |
X R2: A2 | X R2: A2, Offset=630 |
X R1: A3 | X R1: A3, Offset=330 |
X P: Empty | X P: Empty |
X----------------| X------------------------|
Packet 103 is assumed to be dropped in network problems. It Packet 103 is assumed to be dropped in network problems. It
contains redundancy for A. Sending A3 as second level contains redundancy for A. Sending A3 as second level
redundancy is planned for 100 ms after packet 104. redundancy is planned for 330 ms after packet 104.
X----------------| X------------------------|
X Seq no 104 | X Seq no 104, Timer=20820|
X CC=1 | X CC=1 |
X CSRC list B | X CSRC list B |
X R2: Empty | X R2: Empty, Offset=600 |
X R1: B1 | X R1: B1, Offset=300 |
X P2: B2 | X P: B2 |
X----------------| X------------------------|
Packet 104 contains text from B, assumed dropped in network Packet 104 contains text from B, including new B2 and
problems. The mixer has A3 redundancy to send and plans it redundant B1. It is assumed dropped in network
after 100 ms. problems.
The mixer has A3 redundancy to send but no new text
appears from A and therefore the redundancy is sent
330 ms after the previous packet with text from A.
|------------------------|
| Seq no 105, Timer=21060|
| CC=1 |
| CSRC list A |
| R2: A3, Offset=660 |
| R1: Empty, Offset=330 |
| P: Empty |
|------------------------|
Packet 105 is received.
A gap for lost 103, and 104 is detected.
Assume that no other loss was detected the last second.
Then it can be concluded that nothing was totally lost.
R2 is checked. Its original time was 21040-660=20400.
A packet with text from A was received with that
timestamp, so nothing needs to be recovered.
X----------------|
X Seq no 105 |
X CC=1 |
X CSRC list A |
X R2: A3 |
X R1: Empty |
X P: Empty |
X----------------|
Packet 105 is assumed to be dropped in network problems
B1 and B2 still needs to be transmitted as redundancy. B1 and B2 still needs to be transmitted as redundancy.
This is planned 320 ms after packet 105. This is planned 330 ms after packet 105. But that
would be at 21150 which is only 90 ms after the
latest packet. It is instead transmitted at
time 21160.
|----------------| |-----------------------|
|Seq no 106 | |Seq no 106, Timer=21160|
|CC=1 | |CC=1 |
|CSRC list B | |CSRC list B |
| R2: B1 | | R2: B1, Offset=660 |
| R1: B2 | | R1: B2, Offset=340 |
| P: Empty | | P: Empty |
|----------------| |-----------------------|
Packet 106 is received 320 ms after packet 105. The latest received Packet 106 is received.
sequence number was 102. 103,104,105 were lost. Three packets were
thus lost during less than one second. The simple rule for detection
of text loss then results in that an indicator for possible loss
(U'FFFD) [T140ad1], should be inserted generally for the mixer.
The second level redundancy in packet 106 is B1 and has timestamp The second level redundancy in packet 106 is B1 and has timestamp
offset 620 ms. The timestamp of packet 106 minus 620 is the offset 660 ms. The timestamp of packet 106 minus 660 is 20500 which
timestamp of packet 101 which was received. So B1 does not need to is the timestamp of packet 101 THAT was received. So B1 does not
be retrieved. The first level redundancy in packet 106 is 420. The need to be retrieved. The first level redundancy in packet 106 has
timestamp of packet 106 minus 420 is later than the latest received offset 340. The timestamp of packet 106 minus 340 is 20820. That is
packet with source A. Therefore B2 is retrieved and assigned to the later than the latest received packet with source B. Therefore B2 is
input buffer for source B. No primary is available in packet 106 retrieved and assigned to the input buffer for source B. No primary
is available in packet 106
After this sequence, A3 and B1 and B2 have been received. In this After this sequence, A3 and B1 and B2 have been received. In this
case no text was lost. case no text was lost.
3.24. Maximum character rate "CPS" 3.24. Maximum character rate "CPS"
The default maximum rate of reception of "text/t140" real-time text The default maximum rate of reception of "text/t140" real-time text
is in RFC 4103 [RFC4103] specified to be 30 characters per second. is in RFC 4103 [RFC4103] specified to be 30 characters per second.
The value MAY be modified in the CPS parameter of the FMTP attribute The value MAY be modified in the CPS parameter of the FMTP attribute
in the media section for the "text/t140" media. A mixer combining in the media section for the "text/t140" media. A mixer combining
skipping to change at page 22, line 14 skipping to change at page 22, line 45
Strict application of T.140 [T140] is of essence for the Strict application of T.140 [T140] is of essence for the
interoperability of real-time text implementations and to fulfill the interoperability of real-time text implementations and to fulfill the
intention that the session participants have the same information of intention that the session participants have the same information of
the text contents of the conversation without necessarily having the the text contents of the conversation without necessarily having the
exact same layout of the conversation. exact same layout of the conversation.
T.140 [T140] specifies a set of presentation control codes to include T.140 [T140] specifies a set of presentation control codes to include
in the stream. Some of them are optional. Implementations MUST be in the stream. Some of them are optional. Implementations MUST be
able to ignore optional control codes that they do not support. able to ignore optional control codes that they do not support.
There is no strict "message" concept in real-time text. Line There is no strict "message" concept in real-time text. The Unicode
Separator SHALL be used as a separator allowing a part of received Line Separator character SHALL be used as a separator allowing a part
text to be grouped in presentation. The characters "CRLF" may be of received text to be grouped in presentation. The characters
used by other implementations as replacement for Line Separator. The "CRLF" may be used by other implementations as replacement for Line
"CRLF" combination SHALL be erased by just one erasing action, just Separator. The "CRLF" combination SHALL be erased by just one
as the Line Separator. Presentation functions are allowed to group erasing action, just as the Line Separator. Presentation functions
text for presentation in smaller groups than the line separators are allowed to group text for presentation in smaller groups than the
imply and present such groups with source indication together with line separators imply and present such groups with source indication
text groups from other sources (see the following presentation together with text groups from other sources (see the following
examples). Erasure has no specific limit by any delimiter in the presentation examples). Erasure has no specific limit by any
text stream. delimiter in the text stream.
4.1. Presentation by multi-party aware endpoints 4.1. Presentation by multi-party aware endpoints
A multi-party aware receiving party, presenting real-time text MUST A multi-party aware receiving party, presenting real-time text MUST
separate text from different sources and present them in separate separate text from different sources and present them in separate
presentation fields. The receiving party MAY separate presentation presentation fields. The receiving party MAY separate presentation
of parts of text from a source in readable groups based on other of parts of text from a source in readable groups based on other
criteria than line separator and merge these groups in the criteria than line separator and merge these groups in the
presentation area when it benefits the user to most easily find and presentation area when it benefits the user to most easily find and
read text from the different participants. The criteria MAY e.g. be read text from the different participants. The criteria MAY e.g. be
skipping to change at page 22, line 47 skipping to change at page 23, line 29
When text is received from multiple original sources, the When text is received from multiple original sources, the
presentation SHOULD provide a view where text is added in multiple presentation SHOULD provide a view where text is added in multiple
presentation fields. presentation fields.
If the presentation presents text from different sources in one If the presentation presents text from different sources in one
common area, the presenting endpoint SHOULD insert text from the common area, the presenting endpoint SHOULD insert text from the
local user ended at suitable points merged with received text to local user ended at suitable points merged with received text to
indicate the relative timing for when the text groups were completed. indicate the relative timing for when the text groups were completed.
In this presentation mode, the receiving endpoint SHALL present the In this presentation mode, the receiving endpoint SHALL present the
source of the different groups of text. source of the different groups of text. This presentation style is
called the "chat" style here.
A view of a three-party RTT call in chat style is shown in this A view of a three-party RTT call in chat style is shown in this
example . example .
_________________________________________________ _________________________________________________
| |^| | |^|
|[Alice] Hi, Alice here. |-| |[Alice] Hi, Alice here. |-|
| | | | | |
|[Bob] Bob as well. | | |[Bob] Bob as well. | |
| | | | | |
skipping to change at page 33, line 28 skipping to change at page 34, line 28
Participants with malicious intentions may appear and e.g. disturb Participants with malicious intentions may appear and e.g. disturb
the multi-party session by a continuous flow of text, or masquerading the multi-party session by a continuous flow of text, or masquerading
as text from other participants. Counteractions should be to require as text from other participants. Counteractions should be to require
secure signaling, media and authentication, and to provide higher secure signaling, media and authentication, and to provide higher
level conference functions e.g. for blocking and expelling level conference functions e.g. for blocking and expelling
participants. participants.
12. Change history 12. Change history
12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-10 12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-11
Timestamps and timestamp offsets added to the packet examples in
section 3.23, and the description corrected.
A number of minor corrections added in sections 3.10 - 3.23.
12.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-10
The packet composition was modified for interleaving packets from The packet composition was modified for interleaving packets from
different sources. different sources.
The packet reception was modified for the new interleaving method. The packet reception was modified for the new interleaving method.
The packet sequence examples was adjusted for the new interleaving The packet sequence examples was adjusted for the new interleaving
method. method.
Modifications according to responses to Brian Rosen of 2020-11-03 Modifications according to responses to Brian Rosen of 2020-11-03
12.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-09 12.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-09
Changed name on the SDP media attribute to "rtt-mixer" Changed name on the SDP media attribute to "rtt-mixer"
Restructure of section 2 for balance between aware and unaware cases. Restructure of section 2 for balance between aware and unaware cases.
Moved conference control to own section. Moved conference control to own section.
Improved clarification of recovery and loss in the packet sequence Improved clarification of recovery and loss in the packet sequence
example. example.
A number of editorial corrections and improvements. A number of editorial corrections and improvements.
12.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-08 12.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-08
Deleted the method requiring a new packet format "text/rex" because Deleted the method requiring a new packet format "text/rex" because
of the longer standardization and implementation period it needs. of the longer standardization and implementation period it needs.
Focus on use of RFC 4103 text/red format with shorter transmission Focus on use of RFC 4103 text/red format with shorter transmission
interval, and source indicated in CSRC. interval, and source indicated in CSRC.
12.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-07 12.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-07
Added a method based on the "text/red" format and single source per Added a method based on the "text/red" format and single source per
packet, negotiated by the "rtt-mixer" sdp attribute. packet, negotiated by the "rtt-mixer" sdp attribute.
Added reasoning and recommendation about indication of loss. Added reasoning and recommendation about indication of loss.
The highest number of sources in one packet is 15, not 16. Changed. The highest number of sources in one packet is 15, not 16. Changed.
Added in information on update to RFC 4103 that RFC 4103 explicitly Added in information on update to RFC 4103 that RFC 4103 explicitly
allows addition of FEC method. The redundancy is a kind of forward allows addition of FEC method. The redundancy is a kind of forward
error correction.. error correction..
12.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06 12.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06
Improved definitions list format. Improved definitions list format.
The format of the media subtype parameters is made to match the The format of the media subtype parameters is made to match the
requirements. requirements.
The mapping of media subtype parameters to sdp is included. The mapping of media subtype parameters to sdp is included.
The CPS parameter belongs to the t140 subtype and does not need to be The CPS parameter belongs to the t140 subtype and does not need to be
registered here. registered here.
12.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05 12.7. 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.
12.7. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04 12.8. 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.
12.8. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03 12.9. 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 35, line 45 skipping to change at page 37, line 4
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-
12.9. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02 12.10. 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.
12.10. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 12.11. 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.
12.11. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 12.12. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03
to draft-ietf-avtcore-multi-party-rtt-mix-00 to 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.
12.12. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 12.13. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02
to -03 to -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.
12.13. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 12.14. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01
to -02 to -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 38, line 5 skipping to change at page 39, 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.
12.14. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00 12.15. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00
to -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. 77 change blocks. 
213 lines changed or deleted 245 lines changed or added

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