draft-ietf-avtcore-multi-party-rtt-mix-19.txt   draft-ietf-avtcore-multi-party-rtt-mix-20.txt 
AVTCore G. Hellstrom AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: 4103 (if approved) 25 May 2021 Updates: 4103 (if approved) 26 May 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 26 November 2021 Expires: 27 November 2021
RTP-mixer formatting of multiparty Real-time text RTP-mixer formatting of multiparty Real-time text
draft-ietf-avtcore-multi-party-rtt-mix-19 draft-ietf-avtcore-multi-party-rtt-mix-20
Abstract Abstract
This document provides enhancements for RFC 4103 real-time text This document provides enhancements for RFC 4103 real-time text
mixing suitable for a centralized conference model that enables mixing suitable for a centralized conference model that enables
source identification and rapidly interleaved transmission of text source identification and rapidly interleaved transmission of text
from different sources. The intended use is for real-time text from different sources. The intended use is for real-time text
mixers and participant endpoints capable of providing an efficient mixers and participant endpoints capable of providing an efficient
presentation or other treatment of a multiparty real-time text presentation or other treatment of a multiparty real-time text
session. The specified mechanism builds on the standard use of the session. The specified mechanism builds on the standard use of the
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 26 November 2021. This Internet-Draft will expire on 27 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 3, line 29 skipping to change at page 3, line 29
4.1. Presentation by multiparty-aware endpoints . . . . . . . 27 4.1. Presentation by multiparty-aware endpoints . . . . . . . 27
4.2. Multiparty mixing for multiparty-unaware endpoints . . . 29 4.2. Multiparty mixing for multiparty-unaware endpoints . . . 29
5. Relation to Conference Control . . . . . . . . . . . . . . . 35 5. Relation to Conference Control . . . . . . . . . . . . . . . 35
5.1. Use with SIP centralized conferencing framework . . . . . 36 5.1. Use with SIP centralized conferencing framework . . . . . 36
5.2. Conference control . . . . . . . . . . . . . . . . . . . 36 5.2. Conference control . . . . . . . . . . . . . . . . . . . 36
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 36 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Gateway considerations with Textphones . . . . . . . . . 36 6.1. Gateway considerations with Textphones . . . . . . . . . 36
6.2. Gateway considerations with WebRTC . . . . . . . . . . . 36 6.2. Gateway considerations with WebRTC . . . . . . . . . . . 36
7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 37 7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 37
8. Congestion considerations . . . . . . . . . . . . . . . . . . 38 8. Congestion considerations . . . . . . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9.1. Registration of the "rtt-mixer" SDP media attribute . . . 38
10.1. Registration of the "rtt-mixer" SDP media attribute . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 40
12. Change history . . . . . . . . . . . . . . . . . . . . . . . 40 11.1. Changes included in
12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-20 . . . . . . . 40
11.2. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-19 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-19 . . . . . . . 40
12.2. Changes included in 11.3. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-18 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-18 . . . . . . . 40
12.3. Changes included in 11.4. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-17 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-17 . . . . . . . 40
12.4. Changes included in 11.5. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-16 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-16 . . . . . . . 40
12.5. Changes included in 11.6. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 41
12.6. Changes included in 11.7. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 41
12.7. Changes included in 11.8. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 41
12.8. Changes included in 11.9. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 42
12.9. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 42
12.10. Changes included in 11.10. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 42
11.11. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 42 draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 42
12.11. Changes included in 11.12. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 42 draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 42
12.12. Changes included in 11.13. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 43
12.13. Changes included in 11.14. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 43
12.14. Changes included in 11.15. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 43
12.15. Changes included in 11.16. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 43
12.16. Changes included in 11.17. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 43
12.17. Changes included in 11.18. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 44 draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 44
12.18. Changes included in 11.19. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 45 draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 45
12.19. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 45 11.20. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 45
12.20. Changes from 11.21. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-03 to draft-hellstrom-avtcore-multi-party-rtt-source-03 to
draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 45 draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 45
12.21. Changes from 11.22. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-02 to draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 45 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.22. Changes from 11.23. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 46 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . 46
12.23. Changes from 11.24. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-00 to draft-hellstrom-avtcore-multi-party-rtt-source-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 47 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
13.1. Normative References . . . . . . . . . . . . . . . . . . 47 12.1. Normative References . . . . . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . 48 12.2. Informative References . . . . . . . . . . . . . . . . . 48
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
"RTP Payload for Text Conversation" [RFC4103] specifies use of the "RTP Payload for Text Conversation" [RFC4103] specifies use of the
Real-Time Transport Protocol (RTP) [RFC3550] for transmission of Real-Time Transport Protocol (RTP) [RFC3550] for transmission of
real-time text (RTT) and the "text/t140" format. It also specifies a real-time text (RTT) and the "text/t140" format. It also specifies a
redundancy format "text/red" for increased robustness. The "text/ redundancy format "text/red" for increased robustness. The "text/
red" format is registered in [RFC4102]. red" format is registered in [RFC4102].
skipping to change at page 20, line 26 skipping to change at page 20, line 26
uncertain if there was loss. uncertain if there was loss.
3.16.3. Extracting text and handling recovery 3.16.3. 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 multiparty-aware endpoints, its T140blocks SHALL be extracted in for multiparty-aware endpoints, its T140blocks SHALL be extracted in
the following way. The description is adapted to the default the following way.
redundancy case using the original and two redundant generations.
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 oldest available
redundancy, continuing with the first generation redundancy and redundant generation, continuing with the younger redundant
finally the primary. generations in age order and finally the primary.
Note: The normal case is that in the first packet, only the primary Note: The normal case is that in the first packet, only the primary
data has contents. The redundant data has contents in the first data has contents. The redundant data has contents in the 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
second generation redundant data is available, its timestamp SHALL be redundant data is available, the process SHALL start with the oldest
created by subtracting its timestamp offset from the RTP timestamp. generation. The timestamp of that redundant data SHALL be created by
If the resulting timestamp is later than the latest retrieved data subtracting its timestamp offset from the RTP timestamp. If the
from the same source, then the redundant data SHALL be retrieved and resulting timestamp is later than the latest retrieved data from the
appended to the receive buffer. The process SHALL be continued in same source, then the redundant data SHALL be retrieved and appended
the same way for the first generation redundant data. After that, to the receive buffer. The process SHALL be continued in the same
the timestamp of the packet SHALL be compared with the timestamp of way for all younger generations of redundant data. After that, the
the latest retrieved data from the same source and if it is later, timestamp of the packet SHALL be compared with the timestamp of the
then the primary data SHALL be retrieved from the packet and appended latest retrieved data from the same source and if it is later, then
to the receive buffer for the source. the primary data SHALL be retrieved from the packet and appended to
the receive buffer for the source.
3.16.4. Delete 'BOM' 3.16.4. Delete 'BOM'
Unicode character 'BOM' is used as a start indication and sometimes Unicode character 'BOM' is used as a start indication and sometimes
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.17. Performance considerations 3.17. Performance considerations
This solution has good performance with low text delays, as long as This solution has good performance with low text delays, as long as
skipping to change at page 22, line 9 skipping to change at page 22, line 10
media level. In applications where legacy endpoints without security media level. In applications where legacy endpoints without security
are allowed, a negotiation SHOULD be performed to decide if are allowed, a negotiation SHOULD be performed to decide if
encryption on the media level will be applied. If no other security encryption on the media level will be applied. If no other security
solution is mandated for the application, then OSRTP [RFC8643] is a solution is mandated for the application, then OSRTP [RFC8643] is a
suitable method to be applied to negotiate SRTP media security with suitable method to be applied to negotiate SRTP media security with
DTLS. Most SDP examples below are for simplicity expressed without DTLS. Most SDP examples below are for simplicity expressed without
the security additions. The principles (but not all details) for the security additions. The principles (but not all details) for
applying DTLS-SRTP [RFC5764] security are shown in a couple of the applying DTLS-SRTP [RFC5764] security are shown in a couple of the
following examples. following examples.
Further general security considerations are covered in Section 11. Further general security considerations are covered in Section 10.
End-to-end encryption would require further work and could be based End-to-end encryption would require further work and could be based
on WebRTC as specified in Section 1.2 or on double encryption as on WebRTC as specified in Section 1.2 or on double encryption as
specified in [RFC8723]. specified in [RFC8723].
3.19. SDP offer/answer examples 3.19. SDP offer/answer examples
This section shows some examples of SDP for session negotiation of This section 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
skipping to change at page 38, line 27 skipping to change at page 38, line 27
participants is exceeded. More delay than 7 seconds can cause participants is exceeded. More delay than 7 seconds can cause
confusion in the session. It is therefore RECOMMENDED that an RTP- confusion in the session. It is therefore RECOMMENDED that an RTP-
mixer-based mixer discards such text causing excessive delays and mixer-based mixer discards such text causing excessive delays and
inserts a general indication of possible text loss [T140ad1] in the inserts a general indication of possible text loss [T140ad1] in the
session. If the main text contributor is indicated in any way, the session. If the main text contributor is indicated in any way, the
mixer MAY avoid deleting text from that participant. It should mixer MAY avoid deleting text from that participant. It should
however be noted that human creation of text normally contains however be noted that human creation of text normally contains
pauses, when the transmission can catch up, so that the transmission pauses, when the transmission can catch up, so that the transmission
overload situations are expected to be very rare. overload situations are expected to be very rare.
9. Acknowledgements 9. IANA Considerations
James Hamlin for format and performance aspects.
10. IANA Considerations
10.1. Registration of the "rtt-mixer" SDP media attribute 9.1. Registration of the "rtt-mixer" SDP media attribute
[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the
RFC number of this document.] RFC number of this document.]
IANA is asked to register the new SDP attribute "rtt-mixer". IANA is asked to register the new SDP attribute "rtt-mixer".
Contact name: IESG Contact name: IESG
Contact email: iesg@ietf.org Contact email: iesg@ietf.org
skipping to change at page 39, line 17 skipping to change at page 39, line 13
member. member.
Charset Dependent: no Charset Dependent: no
O/A procedure: See RFCXXXX Section 2.3 O/A procedure: See RFCXXXX Section 2.3
Mux Category: normal Mux Category: normal
Reference: RFCXXXX Reference: RFCXXXX
11. Security Considerations 10. Security Considerations
The RTP-mixer model requires the mixer to be allowed to decrypt, The RTP-mixer model requires the mixer to be allowed to decrypt,
pack, and encrypt secured text from the conference participants. pack, and encrypt secured text from the conference participants.
Therefore, the mixer needs to be trusted to maintain confidentiality Therefore, the mixer needs to be trusted to maintain confidentiality
and integrity of the RTT data. This situation is similar to the and integrity of the RTT data. This situation is similar to the
situation for handling audio and video media in centralized mixers. situation for handling audio and video media in centralized mixers.
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, may have privacy concerns as already stated in RFC notifications, may have privacy concerns as already stated in RFC
skipping to change at page 40, line 16 skipping to change at page 40, line 11
both with and without security procedures, opens for possible attacks both with and without security procedures, opens for possible attacks
by both unauthenticated call participants and even eavesdropping and by both unauthenticated call participants and even eavesdropping and
manipulating of content non-participants. manipulating of content non-participants.
As already stated in Section 3.18, security in media SHOULD be As already stated in Section 3.18, security in media SHOULD be
applied by using DTLS-SRTP [RFC5764] on the media level. applied by using DTLS-SRTP [RFC5764] on the media level.
Further security considerations specific for this application are Further security considerations specific for this application are
specified in Section 3.18. specified in Section 3.18.
12. Change history 11. Change history
[RFC Editor: Please remove this section prior to publication.] [RFC Editor: Please remove this section prior to publication.]
12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-19 11.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-20
Inclusion of edits as respone to a comment by Benjamin Kaduk in
section 3.16.3 to make the recovery procedure generic.
Added persons to the acknowledgements and moved acknowledgements to
last in the document.
11.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-19
Edits because of comments in a review by Francesca Palombini. Edits because of comments in a review by Francesca Palombini.
Edits because of comments from Benjamin Kaduk. Edits because of comments from Benjamin Kaduk.
Proposed to not change anything because of Robert Wilton's comments. Proposed to not change anything because of Robert Wilton's comments.
Two added sentences in the security section to meet comments by Roman Two added sentences in the security section to meet comments by Roman
Danyliw. Danyliw.
12.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-18 11.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-18
Edits of nits as proposed in a review by Lars Eggert. Edits of nits as proposed in a review by Lars Eggert.
Edits as response to review by Martin Duke. Edits as response to review by Martin Duke.
12.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-17 11.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-17
Actions on Gen-ART review comments. Actions on Gen-ART review comments.
Actions on SecDir review comments. Actions on SecDir review comments.
12.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-16 11.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-16
Improvements in the offer/answer considerations section by adding Improvements in the offer/answer considerations section by adding
subsections for each phase in the negotiation as requested by IANA subsections for each phase in the negotiation as requested by IANA
expert review. expert review.
12.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-15 11.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-15
Actions on review comments from Jurgen Schonwalder: Actions on review comments from Jurgen Schonwalder:
A bit more about congestion situations and that they are expected to A bit more about congestion situations and that they are expected to
be very rare. be very rare.
Explanation of differences in security between the conference-aware Explanation of differences in security between the conference-aware
and the conference-unaware case added in security section. and the conference-unaware case added in security section.
Presentation examples with suource labels made less confusing, and Presentation examples with suource labels made less confusing, and
explained. explained.
Reference to T.140 inserted at first mentioning of T.140. Reference to T.140 inserted at first mentioning of T.140.
Reference to RFC 8825 inserted to explain WebRTC Reference to RFC 8825 inserted to explain WebRTC
Nit in wording in terminology section adjusted. Nit in wording in terminology section adjusted.
12.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-14 11.7. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-14
Changes from comments by Murray Kucherawy during AD review. Changes from comments by Murray Kucherawy during AD review.
Many SHOULD in section 4.2 on multiparty-unaware mixing changed to Many SHOULD in section 4.2 on multiparty-unaware mixing changed to
SHALL, and the whole section instead specified to be optional SHALL, and the whole section instead specified to be optional
depending on the application. depending on the application.
Some SHOULD in section 3 either explained or changed to SHALL. Some SHOULD in section 3 either explained or changed to SHALL.
In order to have explainable conditions behind SHOULDs, the In order to have explainable conditions behind SHOULDs, the
transmission interval in 3.4 is changed to as soon as text is transmission interval in 3.4 is changed to as soon as text is
available as a main principle. The call participants send with 300 available as a main principle. The call participants send with 300
ms interval so that will create realistic load conditions anyway. ms interval so that will create realistic load conditions anyway.
12.7. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-13 11.8. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-13
Changed year to 2021. Changed year to 2021.
Changed reference to draft on RTT in WebRTC to recently published RFC Changed reference to draft on RTT in WebRTC to recently published RFC
8865. 8865.
Changed label brackets in example from "[]" to "()" to avoid nits Changed label brackets in example from "[]" to "()" to avoid nits
comment. comment.
Changed reference "RFC 4566" to recently published "RFC 8866" Changed reference "RFC 4566" to recently published "RFC 8866"
12.8. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-12 11.9. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-12
Changes according to responses on comments from Brian Rosen in Changes according to responses on comments from Brian Rosen in
Avtcore list on 2020-12-05 and -06. Avtcore list on 2020-12-05 and -06.
Changes according to responses to comments by Bernard Aboba in Changes according to responses to comments by Bernard Aboba in
avtcore list 2020-12-06. avtcore list 2020-12-06.
Introduction of an optiona RTP multi-stream mixing method for further Introduction of an optiona RTP multi-stream mixing method for further
study as proposed by Bernard Aboba. study as proposed by Bernard Aboba.
Changes clarifying how to open and close T.140 data channels included Changes clarifying how to open and close T.140 data channels included
in 6.2 after comments by Lorenzo Miniero. in 6.2 after comments by Lorenzo Miniero.
Changes to satisfy nits check. Some "not" changed to "NOT" in Changes to satisfy nits check. Some "not" changed to "NOT" in
normative wording combinations. Some lower case normative words normative wording combinations. Some lower case normative words
changed to upper case. A normative reference deleted from the changed to upper case. A normative reference deleted from the
abstract. Two informative documents moved from normative references abstract. Two informative documents moved from normative references
to informative references. to informative references.
12.9. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-11 11.10. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-11
Timestamps and timestamp offsets added to the packet examples in Timestamps and timestamp offsets added to the packet examples in
section 3.23, and the description corrected. section 3.23, and the description corrected.
A number of minor corrections added in sections 3.10 - 3.23. A number of minor corrections added in sections 3.10 - 3.23.
12.10. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-10 11.11. 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.11. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-09 11.12. 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.12. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-08 11.13. 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.13. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-07 11.14. 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.14. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06 11.15. 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 The "cps" parameter belongs to the t140 subtype and does not need to
be registered here. be registered here.
12.15. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05 11.16. 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.16. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04 11.17. 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.17. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03 11.18. 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 44, line 48 skipping to change at page 45, line 4
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.18. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02 11.19. 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.19. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 11.20. 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 multiparty-unaware mixing method 7. More limitations for the multiparty-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.20. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 11.21. 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.21. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 11.22. 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 multiparty-unaware endpoints Enhanced section on presentation for multiparty-unaware endpoints
A paragraph recommending cps=150 inserted in the performance section. A paragraph recommending cps=150 inserted in the performance section.
12.22. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 11.23. 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 multiparty-unaware introduced that the mixer should make a mix for multiparty-unaware
skipping to change at page 47, line 5 skipping to change at page 47, 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 whose text is included in one or more text includes participants whose 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.23. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00 11.24. 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
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
skipping to change at page 48, line 39 skipping to change at page 48, line 45
[T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), Protocol for [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), Protocol for
multimedia application text conversation", February 1998, multimedia application text conversation", February 1998,
<https://www.itu.int/rec/T-REC-T.140-199802-I/en>. <https://www.itu.int/rec/T-REC-T.140-199802-I/en>.
[T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 - (02/2000), [T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 - (02/2000),
Protocol for multimedia application text conversation", Protocol for multimedia application text conversation",
February 2000, February 2000,
<https://www.itu.int/rec/T-REC-T.140-200002-I!Add1/en>. <https://www.itu.int/rec/T-REC-T.140-200002-I!Add1/en>.
13.2. Informative References 12.2. Informative References
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
DOI 10.17487/RFC4353, February 2006, DOI 10.17487/RFC4353, February 2006,
<https://www.rfc-editor.org/info/rfc4353>. <https://www.rfc-editor.org/info/rfc4353>.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Session Initiation Protocol (SIP) Event Package for Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, DOI 10.17487/RFC4575, August Conference State", RFC 4575, DOI 10.17487/RFC4575, August
2006, <https://www.rfc-editor.org/info/rfc4575>. 2006, <https://www.rfc-editor.org/info/rfc4575>.
skipping to change at page 49, line 36 skipping to change at page 49, line 41
"Double Encryption Procedures for the Secure Real-Time "Double Encryption Procedures for the Secure Real-Time
Transport Protocol (SRTP)", RFC 8723, Transport Protocol (SRTP)", RFC 8723,
DOI 10.17487/RFC8723, April 2020, DOI 10.17487/RFC8723, April 2020,
<https://www.rfc-editor.org/info/rfc8723>. <https://www.rfc-editor.org/info/rfc8723>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021, DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/info/rfc8825>.
Author's Address Acknowledgements
The author want to thank the following persons for support, reviews
and valuable comments: Bernard Aboba, Amanda Baber, Roman Danyliw,
Spencer Dawkins, Martin Duke, Lars Eggert, James Hamlin, Benjamin
Kaduk, Murray Kucherawy, Paul Kyziwat, Jonathan Lennox, Lorenzo
Miniero, Dan Mongrain, Francesca Palombini, Colin Perkins, Brian
Rosen, Juergen Schoenwaelder, Rich Salz, Robert Wilton, Dale Worley,
Peter Yee and Yong Xin.
Author's Address
Gunnar Hellstrom Gunnar Hellstrom
Gunnar Hellstrom Accessible Communication Gunnar Hellstrom Accessible Communication
SE-13670 Vendelso SE-13670 Vendelso
Sweden Sweden
Email: gunnar.hellstrom@ghaccess.se Email: gunnar.hellstrom@ghaccess.se
 End of changes. 63 change blocks. 
91 lines changed or deleted 106 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/