draft-ietf-avtcore-multi-party-rtt-mix-17.txt   draft-ietf-avtcore-multi-party-rtt-mix-18.txt 
AVTCore G. Hellstrom AVTCore G. Hellstrom
Internet-Draft Gunnar Hellstrom Accessible Communication Internet-Draft Gunnar Hellstrom Accessible Communication
Updates: 4103 (if approved) 7 May 2021 Updates: 4103 (if approved) 17 May 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 8 November 2021 Expires: 18 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-17 draft-ietf-avtcore-multi-party-rtt-mix-18
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 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 8 November 2021. This Internet-Draft will expire on 18 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 31 skipping to change at page 3, line 31
6.1. Gateway considerations with Textphones . . . . . . . . . 35 6.1. Gateway considerations with Textphones . . . . . . . . . 35
6.2. Gateway considerations with WebRTC . . . . . . . . . . . 35 6.2. Gateway considerations with WebRTC . . . . . . . . . . . 35
7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 36 7. Updates to RFC 4103 . . . . . . . . . . . . . . . . . . . . . 36
8. Congestion considerations . . . . . . . . . . . . . . . . . . 36 8. Congestion considerations . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10.1. Registration of the "rtt-mixer" SDP media attribute . . 37 10.1. Registration of the "rtt-mixer" SDP media attribute . . 37
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12. Change history . . . . . . . . . . . . . . . . . . . . . . . 38 12. Change history . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Changes included in 12.1. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-17 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-18 . . . . . . . 38
12.2. Changes included in 12.2. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-16 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-17 . . . . . . . 38
12.3. Changes included in 12.3. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 38 draft-ietf-avtcore-multi-party-rtt-mix-16 . . . . . . . 38
12.4. Changes included in 12.4. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-15 . . . . . . . 39
12.5. Changes included in 12.5. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-14 . . . . . . . 39
12.6. Changes included in 12.6. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 39 draft-ietf-avtcore-multi-party-rtt-mix-13 . . . . . . . 39
12.7. Changes included in 12.7. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-12 . . . . . . . 40
12.8. Changes included in 12.8. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-11 . . . . . . . 40
12.9. Changes included in 12.9. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-10 . . . . . . . 40
12.10. Changes included in 12.10. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 40 draft-ietf-avtcore-multi-party-rtt-mix-09 . . . . . . . 40
12.11. Changes included in 12.11. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-08 . . . . . . . 41
12.12. Changes included in 12.12. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-07 . . . . . . . 41
12.13. Changes included in 12.13. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-06 . . . . . . . 41
12.14. Changes included in 12.14. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-05 . . . . . . . 41
12.15. Changes included in 12.15. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 41 draft-ietf-avtcore-multi-party-rtt-mix-04 . . . . . . . 41
12.16. Changes included in 12.16. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-03 . . . . . . . 42
12.17. Changes included in
draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-02 . . . . . . . 43
12.17. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 43 12.18. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 . . 43
12.18. Changes from 12.19. 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 . . . . . . . 43 draft-ietf-avtcore-multi-party-rtt-mix-00 . . . . . . . 43
12.19. Changes from 12.20. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-02 to draft-hellstrom-avtcore-multi-party-rtt-source-02 to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 43 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.20. Changes from 12.21. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-01 to draft-hellstrom-avtcore-multi-party-rtt-source-01 to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 44 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.21. Changes from 12.22. Changes from
draft-hellstrom-avtcore-multi-party-rtt-source-00 to draft-hellstrom-avtcore-multi-party-rtt-source-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 45 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 46 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
"RTP Payload for Text Conversation" [RFC4103] specifies use of RTP "RTP Payload for Text Conversation" [RFC4103] specifies use of RTP
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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 multiparty mixing. RFC 4103 increasing. Emergency call use requires multiparty mixing. RFC 4103
"RTP Payload for Text Conversation" mixer implementations can use "RTP Payload for Text Conversation" mixer implementations can use
traditional RTP functions for source identification, but the 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
to transmit is limited when using the default transmission to transmit is limited when using the default transmission
characteristics with redundancy. characteristics with redundancy.
The redundancy scheme of [RFC4103] enables efficient transmission of The redundancy scheme of [RFC4103] enables efficient transmission of
earlier transmitted redundant text in packets together with new text. earlier transmitted redundant text in packets together with new text.
However the redundancy header format has no source indicators for the However, the redundancy header format has no source indicators for
redundant transmissions. The redundant parts in a packet must the redundant transmissions. The redundant parts in a packet must
therefore be from the same source as the new text. The recommended therefore be from the same source as the new text. The recommended
transmission is one new and two redundant generations of text transmission is one new and two redundant generations of text
(T140blocks) in each packet and the recommended transmission interval (T140blocks) in each packet and the recommended transmission interval
for two-party use is 300 ms. for two-party use is 300 ms.
Real-time text mixers for multiparty sessions need to include the Real-time text mixers for multiparty sessions need to include the
source with each transmitted group of text from a conference source with each transmitted group of text from a conference
participant so that the text can be transmitted interleaved with text participant so that the text can be transmitted interleaved with text
groups from different sources at the rate they are created. This groups from different sources at the rate they are created. This
enables the text groups to be presented by endpoints in suitable enables the text groups to be presented by endpoints in suitable
grouping with other text from the same source. grouping with other text from the same source.
The presentation can then be arranged so that text from different The presentation can then be arranged so that text from different
sources can be presented in real-time and easily read. At the same sources can be presented in real-time and easily read. At the same
time it is possible for a reading user to perceive approximately when time it is possible for a reading user to perceive approximately when
the text was created in real time by the different parties. The the text was created in real time by the different parties. The
transmission and mixing is intended to be done in a general way so transmission and mixing is intended to be done in a general way, so
that presentation can be arranged in a layout decided by the that presentation can be arranged in a layout decided by the
endpoint. endpoint.
There are existing implementations of RFC 4103 in endpoints without There are existing implementations of RFC 4103 in endpoints without
the updates from this document. These will not be able to receive the updates from this document. These will not be able to receive
and present real-time text mixed for multiparty-aware endpoints. and present real-time text mixed for multiparty-aware endpoints.
A negotiation mechanism is therefore needed for verification if the A negotiation mechanism is therefore needed for verification if the
parties are able to handle a common method for multiparty parties are able to handle a common method for multiparty
transmission and agreeing on using that method. transmission and agreeing on using that method.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
One RTP stream per source would be sent in the same RTP session One RTP stream per source would be sent in the same RTP session
with the "text/red" format. From some points of view, use of with the "text/red" format. From some points of view, use of
multiple RTP streams, one for each source, sent in the same RTP multiple RTP streams, one for each source, sent in the same RTP
session would be efficient, and would use exactly the same packet session would be efficient, and would use exactly the same packet
format as [RFC4103] and the same payload type. A couple of format as [RFC4103] and the same payload type. A couple of
relevant scenarios using multiple RTP-streams are specified in relevant scenarios using multiple RTP-streams are specified in
"RTP Topologies" [RFC7667]. One possibility of special interest "RTP Topologies" [RFC7667]. One possibility of special interest
is the Selective Forwarding Middlebox (SFM) topology specified in is the Selective Forwarding Middlebox (SFM) topology specified in
RFC 7667 section 3.7 that could enable end-to-end encryption. In RFC 7667 section 3.7 that could enable end-to-end encryption. In
contrast to audio and video, real-time text is only transmitted contrast to audio and video, real-time text is only transmitted
when the users actually transmit information. Thus an SFM when the users actually transmit information. Thus, an SFM
solution would not need to exclude any party from transmission solution would not need to exclude any party from transmission
under normal conditions. In order to allow the mixer to convey under normal conditions. In order to allow the mixer to convey
the packets with the payload preserved and encrypted, an SFM the packets with the payload preserved and encrypted, an SFM
solution would need to act on some specific characteristics of the solution would need to act on some specific characteristics of the
"text/red" format. The redundancy headers are part of the "text/red" format. The redundancy headers are part of the
payload, so the receiver would need to just assume that the payload, so the receiver would need to just assume that the
payload type number in the redundancy header is for "text/t140". payload type number in the redundancy header is for "text/t140".
The characters per second parameter (CPS) would need to act per The characters per second parameter (CPS) would need to act per
stream. The relation between the SSRC and the source would need stream. The relation between the SSRC and the source would need
to be conveyed in some specified way, e.g., in the CSRC. Recovery to be conveyed in some specified way, e.g., in the CSRC. Recovery
and loss detection would preferably be based on sequence number and loss detection would preferably be based on sequence number
gap detection. Thus sequence number gaps in the incoming stream gap detection. Thus, sequence number gaps in the incoming stream
to the mixer would need to be reflected in the stream to the to the mixer would need to be reflected in the stream to the
participant, with no new gaps created by the mixer. However, the participant, with no new gaps created by the mixer. However, the
RTP implementation in both mixers and endpoints need to support RTP implementation in both mixers and endpoints need to support
multiple streams in the same RTP session in order to use this multiple streams in the same RTP session in order to use this
mechanism. For best deployment opportunity, it should be possible mechanism. For best deployment opportunity, it should be possible
to upgrade existing endpoint solutions to be multiparty-aware with to upgrade existing endpoint solutions to be multiparty-aware with
a reasonable effort. There is currently a lack of support for a reasonable effort. There is currently a lack of support for
multi-stream RTP in certain implementations. This fact led to multi-stream RTP in certain implementations. This fact led to
this solution being only briefly mentioned in this document as an this solution being only briefly mentioned in this document as an
option for further study. option for further study.
skipping to change at page 8, line 32 skipping to change at page 8, line 32
Multiple sources per packet Multiple sources per packet
A new "text" media subtype would be specified with up to 15 A new "text" media subtype would be specified with up to 15
sources in each packet. The mechanism would make use of the RTP sources in each packet. The mechanism would make use of the RTP
mixer model specified in RTP [RFC3550]. Text from up to 15 mixer model specified in RTP [RFC3550]. Text from up to 15
sources can be included in each packet. Packets are normally sent sources can be included in each packet. Packets are normally sent
with 300 ms intervals. The mean delay will be 150 ms. The with 300 ms intervals. The mean delay will be 150 ms. The
sources are indicated in strict order in the CSRC list of the RTP sources are indicated in strict order in the CSRC list of the RTP
packets. A new redundancy packet format is specified. This packets. A new redundancy packet format is specified. This
method would result in good performance, but would require method would result in good performance, but would require
standardisation and implementation of new releases in the target standardization and implementation of new releases in the target
technologies that would take more time than desirable to complete. technologies that would take more time than desirable to complete.
It was therefore not selected to be included in this document. It was therefore not selected to be included in this document.
Mixing for multiparty-unaware endpoints Mixing for multiparty-unaware endpoints
Presentation of text from multiple parties is prepared by the Presentation of text from multiple parties is prepared by the
mixer in one single stream. It is desirable to have a method that mixer in one single stream. It is desirable to have a method that
does not require any modifications in existing user devices does not require any modifications in existing user devices
implementing RFC 4103 for RTT without explicit support of implementing RFC 4103 for RTT without explicit support of
multiparty sessions. This is possible by having the mixer insert multiparty sessions. This is possible by having the mixer insert
a new line and a text formatted source label before each switch of a new line and a text formatted source label before each switch of
skipping to change at page 9, line 37 skipping to change at page 9, line 37
sessions. The focus of this document is RTP transport. sessions. The focus of this document is RTP transport.
Therefore, even if the WebRTC transport provides good multiparty Therefore, even if the WebRTC transport provides good multiparty
performance, it is just mentioned in this document in relation to performance, it is just mentioned in this document in relation to
providing gateways with multiparty capabilities between RTP and providing gateways with multiparty capabilities between RTP and
WebRTC technologies. WebRTC technologies.
1.3. Intended application 1.3. Intended application
The method for multiparty real-time text specified in this document The method for multiparty real-time text specified in this document
is primarily intended for use in transmission between mixers and is primarily intended for use in transmission between mixers and
endpoints in centralised mixing configurations. It is also endpoints in centralized mixing configurations. It is also
applicable between mixers. An often mentioned application is for applicable between mixers. An often mentioned application is for
emergency service calls with real-time text and voice, where a call emergency service calls with real-time text and voice, where a call
taker wants to make an attended handover of a call to another agent, taker wants to make an attended handover of a call to another agent,
and stay to observe the session. Multimedia conference sessions with and stay to observe the session. Multimedia conference sessions with
support for participants to contribute in text is another support for participants to contribute in text is another
application. Conferences with central support for speech-to-text application. Conferences with central support for speech-to-text
conversion is yet another mentioned application. conversion is yet another mentioned application.
In all these applications, normally only one participant at a time In all these applications, normally only one participant at a time
will send long text utterances. In some cases, one other participant will send long text utterances. In some cases, one other participant
skipping to change at page 18, line 20 skipping to change at page 18, line 20
until either new T140blocks arrive, or a keep-alive method calls for until either new T140blocks arrive, or a keep-alive method calls for
transmission of keep-alive packets. transmission of keep-alive packets.
3.16. RTCP considerations 3.16. RTCP considerations
A mixer SHALL send RTCP reports with SDES, CNAME, and NAME A mixer SHALL send RTCP reports with SDES, CNAME, and NAME
information about the sources in the multiparty call. This makes it information about the sources in the multiparty call. This makes it
possible for participants to compose a suitable label for text from possible for participants to compose a suitable label for text from
each source. each source.
Integrity SHALL be considered when composing these fields. They Confidentiality SHALL be considered when composing these fields.
contain name and address information that may be sensitive to They contain name and address information that may be sensitive to
transmit in its entirety e.g., to unauthenticated participants. transmit in its entirety e.g., to unauthenticated participants.
Similar considerations SHALL be taken as for other media. Similar considerations SHALL be taken as for other media.
3.17. Reception of multiparty contents 3.17. Reception of multiparty contents
The "text/red" receiver included in an endpoint with presentation The "text/red" receiver included in an endpoint with presentation
functions will receive RTP packets in the single stream from the functions will receive RTP packets in the single stream from the
mixer, and SHALL distribute the T140blocks for presentation in mixer, and SHALL distribute the T140blocks for presentation in
presentation areas for each source. Other receiver roles, such as presentation areas for each source. Other receiver roles, such as
gateways or chained mixers are also feasible, and requires gateways or chained mixers are also feasible, and requires
skipping to change at page 24, line 16 skipping to change at page 24, line 16
X Seq no 104, Timer=20830| X Seq no 104, Timer=20830|
X CC=1 | X CC=1 |
X CSRC list B | X CSRC list B |
X R2: Empty, Offset=600 | X R2: Empty, Offset=600 |
X R1: B1, Offset=300 | X R1: B1, Offset=300 |
X P: B2 | X P: B2 |
X------------------------| X------------------------|
Packet 104 contains text from B, including new B2 and Packet 104 contains text from B, including new B2 and
redundant B1. It is assumed dropped due to network redundant B1. It is assumed dropped due to network
problems. problems.
The mixer has A3 redundancy to send but no new text The mixer has A3 redundancy to send, but no new text
appears from A and therefore the redundancy is sent appears from A and therefore the redundancy is sent
330 ms after the previous packet with text from A. 330 ms after the previous packet with text from A.
|------------------------| |------------------------|
| Seq no 105, Timer=21060| | Seq no 105, Timer=21060|
| CC=1 | | CC=1 |
| CSRC list A | | CSRC list A |
| R2: A3, Offset=660 | | R2: A3, Offset=660 |
| R1: Empty, Offset=330 | | R1: Empty, Offset=330 |
| P: Empty | | P: Empty |
skipping to change at page 25, line 20 skipping to change at page 25, line 20
later than the latest received packet with source B. Therefore B2 is later than the latest received packet with source B. Therefore B2 is
retrieved and assigned to the input buffer for source B. No primary retrieved and assigned to the input buffer for source B. No primary
is available in packet 106. is available in packet 106.
After this sequence, A3 and B1 and B2 have been received. In this After this sequence, A3 and B1 and B2 have been received. In this
case no text was lost. case no text was lost.
3.22. Maximum character rate "CPS" 3.22. Maximum character rate "CPS"
The default maximum rate of reception of "text/t140" real-time text The default maximum rate of reception of "text/t140" real-time text
is in [RFC4103] specified to be 30 characters per second. The value is in [RFC4103] specified to be 30 characters per second. The actual
MAY be modified in the "CPS" parameter of the FMTP attribute in the rate is calculated without regard to any redundant text transmission
media section for the "text/t140" media. A mixer combining real-time and is in the multiparty case evaluated for all sources contributing
text from a number of sources may occasionally have a higher combined to transmission to a receiver. The value MAY be modified in the
flow of text coming from the sources. Endpoints SHOULD therefore "CPS" parameter of the FMTP attribute in the media section for the
specify a suitable higher value for the "CPS" parameter, "text/t140" media. A mixer combining real-time text from a number of
corresponding to its real reception capability. A value for "CPS" of sources may occasionally have a higher combined flow of text coming
90 SHALL be the default for the "text/t140" stream in the "text/red" from the sources. Endpoints SHOULD therefore specify a suitable
format when multiparty real-time text is negotiated. See [RFC4103] higher value for the "CPS" parameter, corresponding to its real
for the format and use of the "CPS" parameter. The same rules apply reception capability. A value for "CPS" of 90 SHALL be the default
for the multiparty case except for the default value. for the "text/t140" stream in the "text/red" format when multiparty
real-time text is negotiated. See [RFC4103] for the format and use
of the "CPS" parameter. The same rules apply for the multiparty case
except for the default value.
4. Presentation level considerations 4. Presentation level considerations
"Protocol for multimedia application text conversation" [T140] "Protocol for multimedia application text conversation" [T140]
provides the presentation level requirements for the [RFC4103] provides the presentation level requirements for the [RFC4103]
transport. Functions for erasure and other formatting functions are transport. Functions for erasure and other formatting functions are
specified in [T140] which has the following general statement for the specified in [T140] which has the following general statement for the
presentation: presentation:
"The display of text from the members of the conversation should be "The display of text from the members of the conversation should be
skipping to change at page 28, line 24 skipping to change at page 28, line 38
an endpoint with no multiparty awareness, when that is desired in the an endpoint with no multiparty awareness, when that is desired in the
actual implementation. The following specifies a procedure which MAY actual implementation. The following specifies a procedure which MAY
be applied in that situation. be applied in that situation.
This presentation format has functional limitations and SHOULD be This presentation format has functional limitations and SHOULD be
used only to enable participation in multiparty calls by legacy used only to enable participation in multiparty calls by legacy
deployed endpoints implementing only RFC 4103 without any multiparty deployed endpoints implementing only RFC 4103 without any multiparty
extensions specified in this document. extensions specified in this document.
The principles and procedures below do not specify any new protocol The principles and procedures below do not specify any new protocol
elements. They are instead composed from the information in [T140] elements. They are instead composed of information from [T140] and
and an ambition to provide a best-effort presentation on an endpoint an ambition to provide a best-effort presentation on an endpoint
which has functions only for two-party calls. which has functions originally intended only for two-party calls.
The mixer mixing for multiparty-unaware endpoints SHALL compose a The mixer mixing for multiparty-unaware endpoints SHALL compose a
simulated, limited multiparty RTT view suitable for presentation in simulated, limited multiparty RTT view suitable for presentation in
one presentation area. The mixer SHALL group text in suitable groups one presentation area. The mixer SHALL group text in suitable groups
and prepare for presentation of them by inserting a new line between and prepare for presentation of them by inserting a new line between
them if the transmitted text did not already end with a new line. A them if the transmitted text did not already end with a new line. A
presentable label SHALL be composed and sent for the source initially presentable label SHALL be composed and sent for the source initially
in the session and after each source switch. With this procedure the in the session and after each source switch. With this procedure the
time for switching from transmission of text from one source to time for switching from transmission of text from one source to
transmission of text from another source depends on the actions of transmission of text from another source depends on the actions of
skipping to change at page 29, line 21 skipping to change at page 29, line 32
receiving user for presentation in one single presentation area. receiving user for presentation in one single presentation area.
Text received from a participant SHOULD NOT be included in Text received from a participant SHOULD NOT be included in
transmission to that participant because it is usually presented transmission to that participant because it is usually presented
locally at transmission time. When there is text available for locally at transmission time. When there is text available for
transmission from the mixer to a receiving party from more than one transmission from the mixer to a receiving party from more than one
participant, the mixer SHALL switch between transmission of text from participant, the mixer SHALL switch between transmission of text from
the different sources at suitable points in the transmitted stream. the different sources at suitable points in the transmitted stream.
When switching source, the mixer SHALL insert a line separator if the When switching source, the mixer SHALL insert a line separator if the
already transmitted text did not end with a new line (line separator already transmitted text did not end with a new line (line separator
or CRLF). A label SHALL be composed from information in the CNAME or CRLF). A label SHALL be composed of information in the CNAME and
and NAME fields in RTCP reports from the participant to have its text NAME fields in RTCP reports from the participant to have its text
transmitted, or from other session information for that user. The transmitted, or from other session information for that user. The
label SHALL be delimited by suitable characters (e.g., '[ ]') and label SHALL be delimited by suitable characters (e.g., '[ ]') and
transmitted. The CSRC SHALL indicate the selected source. Then text transmitted. The CSRC SHALL indicate the selected source. Then text
from that selected participant SHALL be transmitted until a new from that selected participant SHALL be transmitted until a new
suitable point for switching source is reached. suitable point for switching source is reached.
Information available to the mixer for composing the label may Information available to the mixer for composing the label may
contain sensitive personal information that SHOULD not be revealed in contain sensitive personal information that SHOULD not be revealed in
sessions not securely authenticated and protected. Integrity sessions not securely authenticated and protected. Integrity
considerations regarding how much personal information is included in considerations regarding how much personal information is included in
skipping to change at page 32, line 7 skipping to change at page 31, line 51
recipient, that control code SHALL also be stored as the status recipient, that control code SHALL also be stored as the status
for the source in the storage for SGR status. If a reset graphic for the source in the storage for SGR status. If a reset graphic
rendition (SGR 0) originating from a source is sent, then the SGR rendition (SGR 0) originating from a source is sent, then the SGR
status storage for that source SHALL be cleared. The display status storage for that source SHALL be cleared. The display
count SHALL NOT be increased. count SHALL NOT be increased.
BS (U+0008) Back Space, intended to erase the last entered character BS (U+0008) Back Space, intended to erase the last entered character
by a source. Erasure by backspace cannot always be performed as by a source. Erasure by backspace cannot always be performed as
the erasing party intended. If an erasing action erases all text the erasing party intended. If an erasing action erases all text
up to the end of the leading label after a source switch, then the up to the end of the leading label after a source switch, then the
mixer MUST NOT transmit more backspaces. Instead it is mixer MUST NOT transmit more backspaces. Instead, it is
RECOMMENDED that a letter "X" is inserted in the text stream for RECOMMENDED that a letter "X" is inserted in the text stream for
each backspace as an indication of the intent to erase more. A each backspace as an indication of the intent to erase more. A
new line is usually coded by a Line Separator, but the character new line is usually coded by a Line Separator, but the character
combination "CRLF" MAY be used instead. Erasure of a new line is combination "CRLF" MAY be used instead. Erasure of a new line is
in both cases done by just one erasing action (Backspace). If the in both cases done by just one erasing action (Backspace). If the
display count has a positive value it SHALL be decreased by one display count has a positive value it SHALL be decreased by one
when the BS is sent. If the display count is at zero, it SHALL when the BS is sent. If the display count is at zero, it SHALL
NOT be altered. NOT be altered.
4.2.5. Packet transmission 4.2.5. Packet transmission
skipping to change at page 32, line 40 skipping to change at page 32, line 35
text mixed for multiparty-unaware endpoints, there will be two levels text mixed for multiparty-unaware endpoints, there will be two levels
of source indicators for the received text; one generated by the of source indicators for the received text; one generated by the
mixer and inserted in a label after each source switch, and another mixer and inserted in a label after each source switch, and another
generated by the receiving endpoint and inserted after each switch generated by the receiving endpoint and inserted after each switch
between local and remote source in the presentation area. This will between local and remote source in the presentation area. This will
waste display space and look inconsistent to the reader. waste display space and look inconsistent to the reader.
New text can be presented only from one source at a time. Switch of New text can be presented only from one source at a time. Switch of
source to be presented takes place at suitable places in the text, source to be presented takes place at suitable places in the text,
such as end of phrase, end of sentence, line separator and such as end of phrase, end of sentence, line separator and
inactivity. Therefore the time to switch to present waiting text inactivity. Therefore, the time to switch to present waiting text
from other sources may become long and will vary and depend on the from other sources may become long and will vary and depend on the
actions of the currently presented source. actions of the currently presented source.
Erasure can only be done up to the latest source switch. If a user Erasure can only be done up to the latest source switch. If a user
tries to erase more text, the erasing actions will be presented as tries to erase more text, the erasing actions will be presented as
letter X after the label. letter X after the label.
Text loss because of network errors may hit the label between entries Text loss because of network errors may hit the label between entries
from different parties, causing risk for misunderstanding from which from different parties, causing risk for misunderstanding from which
source a piece of text is. source a piece of text is.
These facts make it strongly RECOMMENDED to implement multiparty These facts make it strongly RECOMMENDED implementing multiparty
awareness in RTT endpoints. The use of the mixing method for awareness in RTT endpoints. The use of the mixing method for
multiparty-unaware endpoints should be left for use with endpoints multiparty-unaware endpoints should be left for use with endpoints
which are impossible to upgrade to become multiparty-aware. which are impossible to upgrade to become multiparty-aware.
4.2.7. Example views of presentation on multiparty-unaware endpoints 4.2.7. Example views of presentation on multiparty-unaware endpoints
The following pictures are examples of the view on a participant's The following pictures are examples of the view on a participant's
display for the multiparty-unaware case. display for the multiparty-unaware case.
_________________________________________________ _________________________________________________
skipping to change at page 36, line 10 skipping to change at page 36, line 10
The T.140 data channel used both ways is for text from the WebRTC The T.140 data channel used both ways is for text from the WebRTC
user and from the bridge or gateway itself to the WebRTC user. The user and from the bridge or gateway itself to the WebRTC user. The
label parameter of this T.140 data channel is used as the NAME field label parameter of this T.140 data channel is used as the NAME field
in RTCP to participants on the RTP side. The other T.140 data in RTCP to participants on the RTP side. The other T.140 data
channels are only for text from other participants to the WebRTC channels are only for text from other participants to the WebRTC
user. user.
When a new participant has entered the session with RTP transport of When a new participant has entered the session with RTP transport of
RTT, a new T.140 channel SHOULD be established to WebRTC users with RTT, a new T.140 channel SHOULD be established to WebRTC users with
the label parameter composed from the NAME field in RTCP on the RTP the label parameter composed of information from the NAME field in
side. RTCP on the RTP side.
When a new participant has entered the multiparty session with RTT When a new participant has entered the multiparty session with RTT
transport in a WebRTC T.140 data channel, the new participant SHOULD transport in a WebRTC T.140 data channel, the new participant SHOULD
be announced by a notification to RTP users. The label parameter be announced by a notification to RTP users. The label parameter
from the WebRTC side SHOULD be used as the NAME RTCP field on the RTP from the WebRTC side SHOULD be used as the NAME RTCP field on the RTP
side, or other available session information. side, or other available session information.
When a participant on the RTP side is disconnected from the When a participant on the RTP side is disconnected from the
multiparty session, the corresponding T.140 data channel(s) SHOULD be multiparty session, the corresponding T.140 data channel(s) SHOULD be
closed. closed.
skipping to change at page 36, line 43 skipping to change at page 36, line 43
This document updates [RFC4103] by introducing an SDP media attribute This document updates [RFC4103] by introducing an SDP media attribute
"rtt-mixer" for negotiation of multiparty-mixing capability with the "rtt-mixer" for negotiation of multiparty-mixing capability with the
[RFC4103] format, and by specifying the rules for packets when [RFC4103] format, and by specifying the rules for packets when
multiparty capability is negotiated and in use. multiparty capability is negotiated and in use.
8. Congestion considerations 8. Congestion considerations
The congestion considerations and recommended actions from [RFC4103] The congestion considerations and recommended actions from [RFC4103]
are also valid in multiparty situations. are also valid in multiparty situations.
The first action in case of congestion SHALL be to temporarily The time values SHALL then be applied per source of text sent to a
increase the transmission interval up to two seconds. receiver.
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 for a long period, a delay may conference send text simultaneously for a long period, a delay may
build up for presentation of text at the receivers if the limitation build up for presentation of text at the receivers if the limitation
in characters per second ("CPS") to be transmitted to the in characters per second ("CPS") to be transmitted to the
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
skipping to change at page 38, line 9 skipping to change at page 38, line 9
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 11. 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 achieve security in Therefore, the mixer needs to be trusted to achieve security in
confidentiality and integrity. This situation is similar to the confidentiality and integrity. 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, for creation of labels may have privacy concerns as notifications, for creation of labels may have privacy concerns as
already stated in RFC 3550 [RFC3550], and may be restricted for already stated in RFC 3550 [RFC3550], and may be restricted for
privacy reasons. The receiving user will then get a more symbolic privacy reasons. The receiving user will then get a more symbolic
label for the source. label for the source.
skipping to change at page 38, line 34 skipping to change at page 38, line 34
authentication, and to provide higher-layer conference functions authentication, and to provide higher-layer conference functions
e.g., for blocking, muting, and expelling participants. e.g., for blocking, muting, and expelling participants.
Further security considerations specific for this application are Further security considerations specific for this application are
specified in Section 3.19. specified in 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-17 12.1. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-18
Edits of nits as proposed in a review by Lars Eggert.
Edits as response to review by Martin Duke.
12.2. 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.2. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-16 12.3. 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.3. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-15 12.4. 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.4. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-14 12.5. 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.5. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-13 12.6. 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.6. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-12 12.7. 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.7. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-11 12.8. 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.8. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-10 12.9. 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.9. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-09 12.10. 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.10. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-08 12.11. 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.11. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-07 12.12. 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.12. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-06 12.13. 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.13. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-05 12.14. 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.14. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-04 12.15. 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.15. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-03 12.16. 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
the mix. -done- the mix. -done-
In 3. correct the interval to: A "text/rex" transmitter SHOULD send In 3. correct the interval to: A "text/rex" transmitter SHOULD send
packets distributed in time as long as there is something (new or packets distributed in time as long as there is something (new or
skipping to change at page 42, line 42 skipping to change at page 43, 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.16. Changes included in draft-ietf-avtcore-multi-party-rtt-mix-02 12.17. 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.17. Changes to draft-ietf-avtcore-multi-party-rtt-mix-01 12.18. 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.18. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-03 12.19. 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.19. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-02 12.20. 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.20. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-01 12.21. 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
endpoints if the negotiation is not successful. And a reference to a endpoints if the negotiation is not successful. And a reference to a
later chapter about it. later chapter about it.
The presentation considerations chapter 14 is extended with more The presentation considerations chapter 14 is extended with more
information about presentation on multiparty-aware endpoints, and a information about presentation on multiparty-aware endpoints, and a
new section on the multiparty-unaware mixing with low functionality new section on the multiparty-unaware mixing with low functionality
but SHOULD a be implemented in mixers. Presentation examples are but SHOULD be implemented in mixers. Presentation examples are
added. added.
A short chapter 15 on gateway considerations is introduced. A short chapter 15 on gateway considerations is introduced.
Clarification about the text/t140 format included in chapter 10. Clarification about the text/t140 format included in chapter 10.
This sentence added to the chapter 10 about use without redundancy. This sentence added to the chapter 10 about use without redundancy.
"The text/red format SHOULD be used unless some other protection "The text/red format SHOULD be used unless some other protection
against packet loss is utilized, for example a reliable network or against packet loss is utilized, for example a reliable network or
transport." transport."
Note about deviation from RFC 2198 added in chapter 4. Note about deviation from RFC 2198 added in chapter 4.
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 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.21. Changes from draft-hellstrom-avtcore-multi-party-rtt-source-00 12.22. 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. 67 change blocks. 
83 lines changed or deleted 94 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/