draft-ietf-avtcore-multi-party-rtt-mix-15.txt   draft-ietf-avtcore-multi-party-rtt-mix-16.txt 
AVTCore G. Hellstrom AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: 4103 (if approved) 28 April 2021 Updates: 4103 (if approved) 1 May 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 30 October 2021 Expires: 2 November 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-15 draft-ietf-avtcore-multi-party-rtt-mix-16
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 30 October 2021. This Internet-Draft will expire on 2 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 2, line 38 skipping to change at page 2, line 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Selected solution and considered alternatives . . . . . . 6 1.2. Selected solution and considered alternatives . . . . . . 6
1.3. Intended application . . . . . . . . . . . . . . . . . . 9 1.3. Intended application . . . . . . . . . . . . . . . . . . 9
2. Overview of the two specified solutions and selection of 2. Overview of the two specified solutions and selection of
method . . . . . . . . . . . . . . . . . . . . . . . . . 10 method . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. The RTP-mixer based solution for multi-party aware 2.1. The RTP-mixer based solution for multi-party aware
endpoints . . . . . . . . . . . . . . . . . . . . . . . . 10 endpoints . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Mixing for multi-party unaware endpoints . . . . . . . . 10 2.2. Mixing for multi-party unaware endpoints . . . . . . . . 10
2.3. Offer/answer considerations . . . . . . . . . . . . . . . 11 2.3. Offer/answer considerations . . . . . . . . . . . . . . . 11
2.4. Actions depending on capability negotiation result . . . 11 2.4. Actions depending on capability negotiation result . . . 12
3. Details for the RTP-mixer based multi-party aware mixing 3. Details for the RTP-mixer based mixing method for multi-party
method . . . . . . . . . . . . . . . . . . . . . . . . . 12 aware endpoints . . . . . . . . . . . . . . . . . . . . . 13
3.1. Use of fields in the RTP packets . . . . . . . . . . . . 12 3.1. Use of fields in the RTP packets . . . . . . . . . . . . 13
3.2. Initial transmission of a BOM character . . . . . . . . . 12 3.2. Initial transmission of a BOM character . . . . . . . . . 13
3.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Keep-alive . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Transmission interval . . . . . . . . . . . . . . . . . . 13 3.4. Transmission interval . . . . . . . . . . . . . . . . . . 14
3.5. Only one source per packet . . . . . . . . . . . . . . . 13 3.5. Only one source per packet . . . . . . . . . . . . . . . 14
3.6. Do not send received text to the originating source . . . 13 3.6. Do not send received text to the originating source . . . 14
3.7. Clean incoming text . . . . . . . . . . . . . . . . . . . 13 3.7. Clean incoming text . . . . . . . . . . . . . . . . . . . 15
3.8. Redundant transmission principles . . . . . . . . . . . . 13 3.8. Redundant transmission principles . . . . . . . . . . . . 15
3.9. Interleaving text from different sources . . . . . . . . 14 3.9. Interleaving text from different sources . . . . . . . . 15
3.10. Text placement in packets . . . . . . . . . . . . . . . . 14 3.10. Text placement in packets . . . . . . . . . . . . . . . . 15
3.11. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 15 3.11. Empty T140blocks . . . . . . . . . . . . . . . . . . . . 16
3.12. Creation of the redundancy . . . . . . . . . . . . . . . 15 3.12. Creation of the redundancy . . . . . . . . . . . . . . . 16
3.13. Timer offset fields . . . . . . . . . . . . . . . . . . . 15 3.13. Timer offset fields . . . . . . . . . . . . . . . . . . . 17
3.14. Other RTP header fields . . . . . . . . . . . . . . . . . 16 3.14. Other RTP header fields . . . . . . . . . . . . . . . . . 17
3.15. Pause in transmission . . . . . . . . . . . . . . . . . . 16 3.15. Pause in transmission . . . . . . . . . . . . . . . . . . 17
3.16. RTCP considerations . . . . . . . . . . . . . . . . . . . 16 3.16. RTCP considerations . . . . . . . . . . . . . . . . . . . 17
3.17. Reception of multi-party contents . . . . . . . . . . . . 16 3.17. Reception of multi-party contents . . . . . . . . . . . . 18
3.18. Performance considerations . . . . . . . . . . . . . . . 18 3.18. Performance considerations . . . . . . . . . . . . . . . 20
3.19. Security for session control and media . . . . . . . . . 19 3.19. Security for session control and media . . . . . . . . . 20
3.20. SDP offer/answer examples . . . . . . . . . . . . . . . . 19 3.20. SDP offer/answer examples . . . . . . . . . . . . . . . . 21
3.21. Packet sequence example from interleaved transmission . . 21 3.21. Packet sequence example from interleaved transmission . . 22
3.22. Maximum character rate "CPS" . . . . . . . . . . . . . . 24 3.22. Maximum character rate "CPS" . . . . . . . . . . . . . . 25
4. Presentation level considerations . . . . . . . . . . . . . . 24 4. Presentation level considerations . . . . . . . . . . . . . . 25
4.1. Presentation by multi-party aware endpoints . . . . . . . 25 4.1. Presentation by multi-party aware endpoints . . . . . . . 26
4.2. Multi-party mixing for multi-party unaware endpoints . . 27 4.2. Multi-party mixing for multi-party unaware endpoints . . 28
5. Relation to Conference Control . . . . . . . . . . . . . . . 33 5. Relation to Conference Control . . . . . . . . . . . . . . . 34
5.1. Use with SIP centralized conferencing framework . . . . . 33 5.1. Use with SIP centralized conferencing framework . . . . . 34
5.2. Conference control . . . . . . . . . . . . . . . . . . . 33 5.2. Conference control . . . . . . . . . . . . . . . . . . . 34
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 33 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Gateway considerations with Textphones (e.g. TTYs). . . 33 6.1. Gateway considerations with Textphones (e.g. TTYs). . . 34
6.2. Gateway considerations with WebRTC. . . . . . . . . . . . 34 6.2. Gateway considerations with WebRTC. . . . . . . . . . . . 35
7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 35 7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 36
8. Congestion considerations . . . . . . . . . . . . . . . . . . 35 8. Congestion considerations . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10.1. Registration of the "rtt-mixer" SDP media attribute . . 35 10.1. Registration of the "rtt-mixer" SDP media attribute . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12. Change history . . . . . . . . . . . . . . . . . . . . . . . 37 12. Change history . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Changes included in 12.1. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-16 . . . . . . . 38
12.2. Changes included in 12.2. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 38
12.3. Changes included in 12.3. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 37 draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 38
12.4. Changes included in 12.4. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 39
12.5. Changes included in 12.5. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 39
12.6. Changes included in 12.6. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 39
12.7. Changes included in 12.7. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 39
12.8. Changes included in 12.8. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 40
12.9. Changes included in 12.9. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 40
12.10. Changes included in 12.10. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 40
12.11. Changes included in 12.11. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 40
12.12. Changes included in 12.12. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 41
12.13. Changes included in 12.13. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 41
12.14. Changes included in 12.14. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 41
12.15. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 41 12.15. Changes included in
12.16. Changes from draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 42
draft-hellstrom-avtcore-multi-party-rtt-source-03 to 12.16. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 42
draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 41
12.17. Changes from 12.17. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-02 to draft-hellstrom-avtcore-multi-party-rtt-source-03 to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 42
12.18. Changes from 12.18. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.19. Changes from 12.19. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.20. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-00 to draft-hellstrom-avtcore-multi-party-rtt-source-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 43 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 44
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46
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
skipping to change at page 11, line 18 skipping to change at page 11, line 18
[RFC3550], and a redundancy format "text/red" for increased [RFC3550], and a redundancy format "text/red" for increased
robustness of real-time text transmission. This document updates robustness of real-time text transmission. This document updates
[RFC4103] by introducing a capability negotiation for handling multi- [RFC4103] by introducing a capability negotiation for handling multi-
party real-time text, a way to indicate the source of transmitted party real-time text, a way to indicate the source of transmitted
text, and rules for efficient timing of the transmissions interleaved text, and rules for efficient timing of the transmissions interleaved
from different sources. from different sources.
The capability negotiation for the "RTP-mixer based multi-party The capability negotiation for the "RTP-mixer based multi-party
method" is based on use of the SDP media attribute "rtt-mixer". method" is based on use of the SDP media attribute "rtt-mixer".
Both parties SHALL indicate their capability in a session setup or
modification, and evaluate the capability of the counterpart.
The syntax is as follows: The syntax is as follows:
"a=rtt-mixer" "a=rtt-mixer"
If any other method for RTP-based multi-party real-time text gets If any other method for RTP-based multi-party real-time text gets
specified, it is assumed that it will be recognized by some specific specified by additional work, it is assumed that it will be
SDP feature exchange. recognized by some specific SDP feature exchange.
It is possible to both indicate capability for the RTP-mixer based 2.3.1. Initial offer
method and another method. An answer MUST NOT accept more than one
method. A party intending to set up a session and being willing to use the
RTP-mixer based method of this specification for sending or receiving
or both sending and receiving real-time text SHALL include the "rtt-
mixer" SDP attribute in the corresponding "text" media section in the
initial offer.
The party MAY indicate capability for both the RTP-mixer based method
of this specification and other methods.
When the offeror has sent the offer including the "rtt-mixer"
attribute, it MUST be prepared to receive and handle real-time text
formatted according to both the method for multi-party aware parties
specified in Section 3 in this specification and two-party formatted
real-time text.
2.3.2. Answering the offer
A party receiving an offer containing the "rtt-mixer" SDP attribute
and being willing to use the RTP-mixer based method of this
specification for sending or receiving or both sending and receiving
SHALL include the "rtt-mixer" SDP attribute in the corresponding
"text" media section in the answer.
If the offer did not contain the "rtt-mixer" attribute, the answer
MUST NOT contain the "rtt-mixer" attribute.
An answer MUST NOT include acceptance of more than one method for
multi-party real-time text in the same RTP session.
When the answer including acceptance is transmitted, the answerer
MUST be prepared to act on received text in the negotiated session
according to the method for multi-party aware parties specified in
Section 3 of this specification. Reception of text for a two-party
session SHALL also be supported.
2.3.3. Offeror processing the answer
When the answer is processed by the offeror, it MUST act as specified
in Section 2.4
2.3.4. Modifying a session
A session MAY be modified at any time by any party offering a
modified SDP with or without the "rtt-mixer" SDP attribute expressing
a desired change in the support of multi-party real-time text.
If the modified offer adds indication of support for multi-party
real-time text by including the "rtt-mixer" SDP attribute, the
procedures specified in the previous subsections SHALL be applied.
If the modified offer deletes indication of support for multi-party
real-time text by excluding the "rtt-mixer" SDP attribute, the answer
MUST NOT contain the "rtt-mixer" attribute, and both parties SHALL
after processing the SDP exchange NOT send real-time text formatted
for multi-party aware parties according to this specification.
2.4. Actions depending on capability negotiation result 2.4. Actions depending on capability negotiation result
A transmitting party SHALL send text according to the RTP-mixer based A transmitting party SHALL send text according to the RTP-mixer based
multi-party method only when the negotiation for that method was multi-party method only when the negotiation for that method was
successful and when it conveys text for another source. In all other successful and when it conveys text for another source. In all other
cases, the packets SHALL be populated and interpreted as for a two- cases, the packets SHALL be populated and interpreted as for a two-
party session. party session.
A party which has negotiated the "rtt-mixer" SDP media attribute MUST A party which has negotiated the "rtt-mixer" SDP media attribute MUST
skipping to change at page 12, line 6 skipping to change at page 13, line 11
interpret the contents of the "CC" field, the CSRC-list and the interpret the contents of the "CC" field, the CSRC-list and the
packets according to Section 3 in received RTP packets in the packets according to Section 3 in received RTP packets in the
corresponding RTP stream. corresponding RTP stream.
A party which has not successfully completed the negotiation of the A party which has not successfully completed the negotiation of the
"rtt-mixer" SDP media attribute MUST NOT transmit packets interleaved "rtt-mixer" SDP media attribute MUST NOT transmit packets interleaved
from different sources in the same RTP stream as specified in from different sources in the same RTP stream as specified in
Section 3. If the party is a mixer and did declare the "rtt-mixer" Section 3. If the party is a mixer and did declare the "rtt-mixer"
SDP media attribute, it SHOULD perform the procedure for multi-party SDP media attribute, it SHOULD perform the procedure for multi-party
unaware endpoints. If the party is not a mixer, it SHOULD transmit unaware endpoints. If the party is not a mixer, it SHOULD transmit
according to [RFC4103]. as in a two-party session according to [RFC4103].
3. Details for the RTP-mixer based multi-party aware mixing method 3. Details for the RTP-mixer based mixing method for multi-party aware
endpoints
3.1. Use of fields in the RTP packets 3.1. Use of fields in the RTP packets
The CC field SHALL show the number of members in the CSRC list, which The CC field SHALL show the number of members in the CSRC list, which
SHALL be one (1) in transmissions from a mixer when conveying text SHALL be one (1) in transmissions from a mixer when conveying text
from other sources in a multi-party session, and otherwise 0. from other sources in a multi-party session, and otherwise 0.
When text is conveyed by a mixer during a multi-party session, a CSRC When text is conveyed by a mixer during a multi-party session, a CSRC
list SHALL be included in the packet. The single member in the CSRC- list SHALL be included in the packet. The single member in the CSRC-
list SHALL contain the SSRC of the source of the T140blocks in the list SHALL contain the SSRC of the source of the T140blocks in the
skipping to change at page 37, line 12 skipping to change at page 38, 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-15 12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-16
Improvements in the offer/answer considerations section by adding
subsections for each phase in the negotiation as requested by IANA
expert review.
12.2. 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.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-14 12.3. 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.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-13 12.4. 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.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-12 12.5. 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.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-11 12.6. 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.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-10 12.7. 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.7. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-09 12.8. 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.8. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-08 12.9. 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.9. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-07 12.10. 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.10. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06 12.11. 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.11. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05 12.12. 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.12. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04 12.13. 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.13. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03 12.14. 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 40, line 47 skipping to change at page 42, line 4
In 1.3 say that the format is used both ways. -done- In 1.3 say that the format is used both ways. -done-
In 13.1 change presentation area to presentation field so that reader In 13.1 change presentation area to presentation field so that reader
does not think it shall be totally separated. -done- does not think it shall be totally separated. -done-
In Performance and intro, tell the performance in number of In Performance and intro, tell the performance in number of
simultaneous sending users and introduced delay 16, 150 vs simultaneous sending users and introduced delay 16, 150 vs
requirements 5 vs 500. -done -- requirements 5 vs 500. -done --
Clarify redundancy level per connection. -done- Clarify redundancy level per connection. -done-
Timestamp also for the last data header. To make it possible for all Timestamp also for the last data header. To make it possible for all
text to have time offset as for transmission from the source. Make text to have time offset as for transmission from the source. Make
that header equal to the others. -done- that header equal to the others. -done-
Mixer always use the CSRC list, even for its own BOM. -done- Mixer always use the CSRC list, even for its own BOM. -done-
Combine all talk about transmission interval (300 ms vs when text has Combine all talk about transmission interval (300 ms vs when text has
arrived) in section 3 in one paragraph or close to each other. -done- arrived) in section 3 in one paragraph or close to each other. -done-
Documents the goal of good performance with low delay for 5 Documents the goal of good performance with low delay for 5
simultaneous typers in the introduction. -done- simultaneous typers in the introduction. -done-
Describe better that only primary text shall be sent on to receivers. Describe better that only primary text shall be sent on to receivers.
Redundancy and loss must be resolved by the mixer. -done- Redundancy and loss must be resolved by the mixer. -done-
12.14. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02 12.15. 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.15. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 12.16. 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.16. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 12.17. 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.17. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 12.18. 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.18. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 12.19. 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 43, line 14 skipping to change at page 44, line 15
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.19. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00 12.20. 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. 50 change blocks. 
102 lines changed or deleted 163 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/