draft-ietf-avtcore-multi-party-rtt-mix-14.txt   draft-ietf-avtcore-multi-party-rtt-mix-15.txt 
AVTCore G. Hellstrom AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: 4103 (if approved) 11 April 2021 Updates: 4103 (if approved) 28 April 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 13 October 2021 Expires: 30 October 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-14 draft-ietf-avtcore-multi-party-rtt-mix-15
Abstract Abstract
Enhancements for RFC 4103 real-time text mixing are provided in this Enhancements for RFC 4103 real-time text mixing are provided in this
document, suitable for a centralized conference model that enables document, 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 multi-party real-time text presentation or other treatment of a multi-party 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 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 October 2021. This Internet-Draft will expire on 30 October 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 12 skipping to change at page 3, line 12
3.11. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 15 3.11. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 15
3.12. Creation of the redundancy . . . . . . . . . . . . . . . 15 3.12. Creation of the redundancy . . . . . . . . . . . . . . . 15
3.13. Timer offset fields . . . . . . . . . . . . . . . . . . . 15 3.13. Timer offset fields . . . . . . . . . . . . . . . . . . . 15
3.14. Other RTP header fields . . . . . . . . . . . . . . . . . 16 3.14. Other RTP header fields . . . . . . . . . . . . . . . . . 16
3.15. Pause in transmission . . . . . . . . . . . . . . . . . . 16 3.15. Pause in transmission . . . . . . . . . . . . . . . . . . 16
3.16. RTCP considerations . . . . . . . . . . . . . . . . . . . 16 3.16. RTCP considerations . . . . . . . . . . . . . . . . . . . 16
3.17. Reception of multi-party contents . . . . . . . . . . . . 16 3.17. Reception of multi-party contents . . . . . . . . . . . . 16
3.18. Performance considerations . . . . . . . . . . . . . . . 18 3.18. Performance considerations . . . . . . . . . . . . . . . 18
3.19. Security for session control and media . . . . . . . . . 19 3.19. Security for session control and media . . . . . . . . . 19
3.20. SDP offer/answer examples . . . . . . . . . . . . . . . . 19 3.20. SDP offer/answer examples . . . . . . . . . . . . . . . . 19
3.21. Packet sequence example from interleaved transmission . . 20 3.21. Packet sequence example from interleaved transmission . . 21
3.22. Maximum character rate "CPS" . . . . . . . . . . . . . . 23 3.22. Maximum character rate "CPS" . . . . . . . . . . . . . . 24
4. Presentation level considerations . . . . . . . . . . . . . . 23 4. Presentation level considerations . . . . . . . . . . . . . . 24
4.1. Presentation by multi-party aware endpoints . . . . . . . 24 4.1. Presentation by multi-party aware endpoints . . . . . . . 25
4.2. Multi-party mixing for multi-party unaware endpoints . . 26 4.2. Multi-party mixing for multi-party unaware endpoints . . 27
5. Relation to Conference Control . . . . . . . . . . . . . . . 31 5. Relation to Conference Control . . . . . . . . . . . . . . . 33
5.1. Use with SIP centralized conferencing framework . . . . . 32 5.1. Use with SIP centralized conferencing framework . . . . . 33
5.2. Conference control . . . . . . . . . . . . . . . . . . . 32 5.2. Conference control . . . . . . . . . . . . . . . . . . . 33
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 32 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 33
6.1. Gateway considerations with Textphones (e.g. TTYs). . . 32 6.1. Gateway considerations with Textphones (e.g. TTYs). . . 33
6.2. Gateway considerations with WebRTC. . . . . . . . . . . . 32 6.2. Gateway considerations with WebRTC. . . . . . . . . . . . 34
7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 33 7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 35
8. Congestion considerations . . . . . . . . . . . . . . . . . . 34 8. Congestion considerations . . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10.1. Registration of the "rtt-mixer" SDP media attribute . . 34 10.1. Registration of the "rtt-mixer" SDP media attribute . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. Change history . . . . . . . . . . . . . . . . . . . . . . . 35 12. Change history . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Changes included in 12.1. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 35 draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 37
12.2. Changes included in 12.2. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 36 draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 37
12.3. Changes included in 12.3. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 36 draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 37
12.4. Changes included in 12.4. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 36 draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 38
12.5. Changes included in 12.5. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 36 draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 38
12.6. Changes included in 12.6. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 38
12.7. Changes included in 12.7. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 38
12.8. Changes included in 12.8. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 39
12.9. Changes included in 12.9. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 39
12.10. Changes included in 12.10. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 39
12.11. Changes included in 12.11. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 39
12.12. Changes included in 12.12. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 40
12.13. Changes included in 12.13. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 40
12.14. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 39 12.14. Changes included in
12.15. Changes from draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 41
draft-hellstrom-avtcore-multi-party-rtt-source-03 to 12.15. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 41
draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 40
12.16. Changes from 12.16. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-02 to draft-hellstrom-avtcore-multi-party-rtt-source-03 to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 41
12.17. Changes from 12.17. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 40 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.18. Changes from 12.18. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.19. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-00 to draft-hellstrom-avtcore-multi-party-rtt-source-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 41 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
"RTP Payload for Text Conversation" [RFC4103] specifies use of RTP "RTP Payload for Text Conversation" [RFC4103] specifies use of RTP
[RFC3550] for transmission of real-time text (RTT) and the "text/ [RFC3550] for transmission of real-time text (RTT) and the "text/
t140" format. It also specifies a redundancy format "text/red" for t140" format. It also specifies a redundancy format "text/red" for
increased robustness. The "text/red" format is registered in increased robustness. The "text/red" format is registered in
[RFC4102]. [RFC4102].
Real-time text is usually provided together with audio and sometimes Real-time text is usually provided together with audio and sometimes
with video in conversational sessions. with video in conversational sessions.
A requirement related to multi-party sessions from the presentation A requirement related to multi-party sessions from the presentation
level standard T.140 for real-time text is: "The display of text from level standard T.140 [T140] for real-time text is: "The display of
the members of the conversation should be arranged so that the text text from the members of the conversation should be arranged so that
from each participant is clearly readable, and its source and the the text from each participant is clearly readable, and its source
relative timing of entered text is visualized in the display." and the relative timing of entered text is visualized in the
display."
Another requirement is that the mixing procedure must not introduce Another requirement is that the mixing procedure must not introduce
delays in the text streams that are experienced to be disturbing the delays in the text streams that are experienced to be disturbing the
real-time experience of the receiving users. real-time experience of the receiving users.
Use of RTT is increasing, and specifically, use in emergency calls is Use of RTT is increasing, and specifically, use in emergency calls is
increasing. Emergency call use requires multi-party mixing. RFC increasing. Emergency call use requires multi-party mixing. RFC
4103 "RTP Payload for Text Conversation" mixer implementations can 4103 "RTP Payload for Text Conversation" mixer implementations can
use traditional RTP functions for source identification, but the use traditional RTP functions for source identification, but the
performance of the mixer when giving turns for the different sources performance of the mixer when giving turns for the different sources
skipping to change at page 6, line 22 skipping to change at page 6, line 22
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown above. capitals, as shown above.
The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP- The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP-
mixer, RTP-translator as defined in [RFC3550] mixer, RTP-translator are defined in [RFC3550].
The term "T140block" is defined in [RFC4103] to contain one or more The term "T140block" is defined in [RFC4103] to contain one or more
T.140 code elements. T.140 code elements.
"TTY" stands for a text telephone type used in North America. "TTY" stands for a text telephone type used in North America.
"WebRTC" stands for web based communication specified by W3C and "WebRTC" stands for web based communication specified by W3C and
IETF. IETF. See [RFC8825].
"DTLS-SRTP" stands for security specified in [RFC5764]. "DTLS-SRTP" stands for security specified in [RFC5764].
"multi-party aware" stands for an endpoint receiving real-time text "multi-party aware" stands for an endpoint receiving real-time text
from multiple sources through a common conference mixer being able to from multiple sources through a common conference mixer being able to
present the text in real-time separated by source and presented so present the text in real-time separated by source and presented so
that a user can get an impression of the approximate relative timing that a user can get an impression of the approximate relative timing
of text from different parties. of text from different parties.
"multi-party unaware" stands for an endpoint not itself being able to "multi-party unaware" stands for an endpoint not itself being able to
skipping to change at page 19, line 23 skipping to change at page 19, line 23
default using DTLS-SRTP [RFC5764] on media level. In applications default using DTLS-SRTP [RFC5764] on media level. In applications
where legacy endpoints without security may exist, a negotiation where legacy endpoints without security may exist, a negotiation
SHOULD be performed to decide if security by encryption on media SHOULD be performed to decide if security by encryption on media
level will be applied. If no other security solution is mandated for level will be applied. If no other security solution is mandated for
the application, then OSRTP [RFC8643] is a suitable method be applied the application, then OSRTP [RFC8643] is a suitable method be applied
to negotiate SRTP media security with DTLS. Most SDP examples below to negotiate SRTP media security with DTLS. Most SDP examples below
are for simplicity expressed without the security additions. The are for simplicity expressed without the security additions. The
principles (but not all details) for applying DTLS-SRTP [RFC5764] principles (but not all details) for applying DTLS-SRTP [RFC5764]
security is shown in a couple of the following examples. security is shown in a couple of the following examples.
This document contains two mixing procedures which imply different
security levels. The mixing for conference-unaware endpoints has
lower security level than the mixing method for conference-aware
endpoints, because there may be an opportunity for a malicious mixer
or a middleman to masquerade the source labels accompanying the text
streams in text format. This is especially true if support of un-
encrypted SIP and media is supported because of lack of such support
in the target endpoints. However, the mixing for conference-aware
endpoints as specified here also requires that the mixer can be
trusted. End to end encryption would require further work and could
be based on WebRTC as specified in Section 1.2.
3.20. SDP offer/answer examples 3.20. 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
show the part of importance for the real-time text media. The show the part of importance for the real-time text media. The
examples relate to the single RTP stream mixing for multi-party aware examples relate to the single RTP stream mixing for multi-party aware
endpoints and for multi-party unaware endpoints. endpoints and for multi-party unaware endpoints.
Note: Multi-party RTT MAY also be provided through other methods, Note: Multi-party RTT MAY also be provided through other methods,
skipping to change at page 31, line 22 skipping to change at page 32, line 22
|plan for the seminar. | | |plan for the seminar. | |
| | | | | |
|[Bob]:Eve, will you do | | |[Bob]:Eve, will you do | |
|your presentation on | | |your presentation on | |
|Friday? | | |Friday? | |
|[Eve]:Yes, Friday at 10.| | |[Eve]:Yes, Friday at 10.| |
|[Bob]: Fine, wo |We need to meet befo | |[Bob]: Fine, wo |We need to meet befo |
|________________________|_________________________| |________________________|_________________________|
Figure 5: Alice who has a conference-unaware client is receiving the Figure 5: Alice who has a conference-unaware client is receiving the
multi-party real-time text in a single-stream. This figure shows how multi-party real-time text in a single-stream.
a coordinated column view MAY be presented on Alice's device.
This figure shows how a coordinated column view MAY be presented on
Alice's device in a view with two-columns. The mixer inserts labels
to show how the sources alternate in the column with received text.
The mixer alternates between the sources at suitable points in the
text exchange so that text entries from each party can be
conveniently read.
_________________________________________________ _________________________________________________
| |^| | |^|
|[Alice] Hi, Alice here. |-| |(Alice) Hi, Alice here. |-|
| | | | | |
|[mix](Bob) Bob as well. | | |(mix)[Bob)] Bob as well. | |
| | | | | |
|(Eve) Hi, this is Eve, calling from Paris | | |[Eve] Hi, this is Eve, calling from Paris | |
| I thought you should be here. | | | I thought you should be here. | |
| | | | | |
|[Alice] I am coming on Thursday, my | | |(Alice) I am coming on Thursday, my | |
| performance is not until Friday morning.| | | performance is not until Friday morning.| |
| | | | | |
|[mix](Bob) And I on Wednesday evening. | | |(mix)[Bob] And I on Wednesday evening. | |
| | | | | |
|(Eve) we can have dinner and then walk | | |[Eve] we can have dinner and then walk | |
| | | | | |
|(Eve) But I need to be back to | | |[Eve] But I need to be back to | |
| the hotel by 11 because I need | | | the hotel by 11 because I need | |
| |-| | |-|
|______________________________________________|v| |______________________________________________|v|
| of course, I underst | | of course, I underst |
|________________________________________________| |________________________________________________|
Figure 6: An example of a view of the multi-party unaware Figure 6: An example of a view of the multi-party unaware
presentation in chat style. Alice is the local user. presentation in chat style. Alice is the local user.
In this view, there is a tradition in receiving applications to
include a label showing the source of the text, here shown with
parenthesis "()". The mixer also inserts source labels for the
multi-party call participants, here shown with brackets "[]".
5. Relation to Conference Control 5. Relation to Conference Control
5.1. Use with SIP centralized conferencing framework 5.1. Use with SIP centralized conferencing framework
The SIP conferencing framework, mainly specified in [RFC4353], The SIP conferencing framework, mainly specified in [RFC4353],
[RFC4579] and [RFC4575] is suitable for coordinating sessions [RFC4579] and [RFC4575] is suitable for coordinating sessions
including multi-party RTT. The RTT stream between the mixer and a including multi-party RTT. The RTT stream between the mixer and a
participant is one and the same during the conference. Participants participant is one and the same during the conference. Participants
get announced by notifications when participants are joining or get announced by notifications when participants are joining or
leaving, and further user information may be provided. The SSRC of leaving, and further user information may be provided. The SSRC of
the text to expect from joined users MAY be included in a the text to expect from joined users MAY be included in a
notification. The notifications MAY be used both for security notification. The notifications MAY be used both for security
skipping to change at page 34, line 14 skipping to change at page 35, line 29
8. Congestion considerations 8. Congestion considerations
The congestion considerations and recommended actions from [RFC4103] The congestion considerations and recommended actions from [RFC4103]
are valid also in multi-party situations. are valid also in multi-party situations.
The first action in case of congestion SHALL be to temporarily The first action in case of congestion SHALL be to temporarily
increase the transmission interval up to two seconds. increase the transmission interval up to two seconds.
If the very unlikely situation appears that many participants in a If the very unlikely situation appears that many participants in a
conference send text simultaneously, a delay will build up for conference send text simultaneously for a long period, a delay may
presentation of text at the receivers because of the limitation in build up for presentation of text at the receivers if the limitation
characters per second("CPS") to be transmitted to the participants. in characters per second("CPS") to be transmitted to the participants
More delay than 7 seconds can cause confusion in the session. It is is exceeded. More delay than 7 seconds can cause confusion in the
therefore RECOMMENDED that RTP-mixer based mixer discards such text session. It is therefore RECOMMENDED that an RTP-mixer based mixer
in excess and inserts a general indication of possible text loss discards such text in excess and inserts a general indication of
[T140ad1] in the session. If the main text contributor is indicated possible text loss [T140ad1] in the session. If the main text
in any way, the mixer MAY avoid deleting text from that participant. contributor is indicated in any way, the mixer MAY avoid deleting
text from that participant. It should however be noted that human
creation of text normally contains pauses, when the transmission can
catch up, so that the transmission overload situations are expected
to be very rare.
9. Acknowledgements 9. Acknowledgements
James Hamlin for format and performance aspects. James Hamlin for format and performance aspects.
10. IANA Considerations 10. IANA Considerations
10.1. Registration of the "rtt-mixer" SDP media attribute 10.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
skipping to change at page 35, line 41 skipping to change at page 37, line 12
level conference functions e.g. for blocking and expelling level conference functions e.g. for blocking and expelling
participants. participants.
Further security considerations specific for this application are Further security considerations specific for this application are
specified in section Section 3.19. specified in section Section 3.19.
12. Change history 12. 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-14 12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-15
Actions on review comments from Jurgen Schonwalder:
A bit more about congestion situations and that they are expected to
be very rare.
Explanation of differences in security between the conference-aware
and the conference-unaware case added in security section.
Presentation examples with suource labels made less confusing, and
explained.
Reference to T.140 inserted at first mentioning of T.140.
Reference to RFC 8825 inserted to explain WebRTC
Nit in wording in terminology section adjusted.
12.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-14
Changes from comments by Murray Cucherawy during AD review. Changes from comments by Murray Cucherawy during AD review.
Many SHOULD in section 4.2 on multi-party unaware mixing changed to Many SHOULD in section 4.2 on multi-party 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.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-13 12.3. 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.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-12 12.4. 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.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-11 12.5. 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.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-10 12.6. 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.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-09 12.7. 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.7. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-08 12.8. 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.8. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-07 12.9. 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.9. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06 12.10. 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.10. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05 12.11. 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.11. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04 12.12. 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.12. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03 12.13. 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 39, line 15 skipping to change at page 41, 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.13. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02 12.14. 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.14. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 12.15. 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.15. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 12.16. 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.16. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 12.17. 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.17. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 12.18. 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 41, line 23 skipping to change at page 43, 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.18. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00 12.19. 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
skipping to change at page 42, line 35 skipping to change at page 44, line 26
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>. October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>.
[RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text [RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text
Conversation over WebRTC Data Channels", RFC 8865, Conversation over WebRTC Data Channels", RFC 8865,
DOI 10.17487/RFC8865, January 2021, DOI 10.17487/RFC8865, January 2021,
<https://www.rfc-editor.org/info/rfc8865>. <https://www.rfc-editor.org/info/rfc8865>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866, Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021, DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>. <https://www.rfc-editor.org/info/rfc8866>.
 End of changes. 58 change blocks. 
91 lines changed or deleted 144 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/