Subject: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-avtcore-multi-party-rtt-mix-18: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 19:53:19 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-avtcore-multi-party-rtt-mix-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm not sure I understand how the examples are consistent with the main
specification, so let's please discuss it to either un-confuse me or fix
the document.

Section 3.9 seems to say that the oldest (source or redundant) text at
the mixer takes priority when there is text from more than one source
waiting to be sent, but the examples in Section 3.21 seem to show (e.g.)
text received from A at time 20400 that is to be sent as redundancy,
being sent after text from B received at time 20500 (sent as primary).
Is the intent that if there is any primary text, the oldest primary text
is sent first, and only if there is no outstanding primary text do we
consider the redundant text?

In a related vein, Section 3.10 says that a packet is sent when (among
other things) "330 ms has passed since already transmitted text was
queued for transmission as redundant text".  But that doesn't say
anything about the timer being reset by subsequent transmission or
queuing of redundant text, so I'm not sure how in the Section 3.21
example, we say that transmitting B1 and B2 as redundancy was planned as
330 ms after packet 105 -- the original B2 was sent in packet 104, so
shouldn't the 330ms start from packet 104's transmission?  (The stated
time for this seems to match 330ms after 104, so maybe the "105" is just
a typo?)

I also left a note in the comment that there's a remark about "lower
security level" in Section 3.19 that's not really accurate; we should
resolve that in some manner before the document proceeds.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The abstract is perhaps pushing the boundary of length reasonable for an
abstract.

There were a couple interesting remarks in the shepherd writeup:

% The specification has not been implemented yet, so it is possible that
% issues could arise in implementation. This is more of a concern than
% for typical AVTCORE documents, since this specification is likely to
% become a regulatory requirement prior to advancing beyond Proposed
% Standard.

Are there still no implementations?  Are we happy with publishign the
specification at this time in the absence of implementations?

% During review, the question was raised as to whether the specification
% will require development of an RTT mixer, or whether it could be made
% compatible with existing conferencing servers implementing Selective
% Forwarding.

What was the outcome of the discussion?  Should that be reflected in the
document?

Abstract

   mixer model.  The possibility to implement the solution in a wide
   range of existing RTP implementations made the RTP-mixer model be
   selected to be fully specified in this document.

It's a little surprising to see this claim given the absence (per the
shepherd writeup) of any actual implementations.

Section 1.2

   Multiple sources per packet
      A new "text" media subtype would be specified with up to 15
      sources in each packet.  The mechanism would make use of the RTP
      mixer model specified in RTP [RFC3550].  Text from up to 15
      sources can be included in each packet.  [...]

(How was the "15" number determined?)

Section 2.3.2

   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.

This requirement doesn't quite seem to match up with what I expect -- an
answerer that's willing to use rtt-mixer and also willing to use
something else seems to still be bound by the "SHALL include" in the
first paragraph, which makes the willingness to use something else a bit
irrelevant and precludes choosing the other option.  Perhaps we want to
say only "chooses to use the RTP-mixer-based method of this
specification"?

Section 3.2

What purpose does the initial BOM serve?  I note that, e.g., RFC 5198
has an explicit BOM "MUST NOT appear at the beginning of these text
strings" and that RFC 4103 specifies UTF-8 encoding of the text.
I see in Section 3.17.4 (and 4.2.1) we mention that it might be used for
keepalive, but in rtt-mix don't we have lots of non-BOM keepalive
options?

Section 3.4

   If the "CPS" value is reached, longer transmission intervals SHALL be
   applied and only as much of the text queued for transmission SHALL be
   sent at the end of each transmission interval that can be allowed
   without exceeding the "CPS" value, until the transmission rate falls
   under the "CPS" value again.  [...]

This doesn't seem as precisely specified as it could be, given that the
CPS rate is supposed to be enforced over "any 10-second interval".  As
written, this seems to suggest that the entire 10-second history of
packet size/spacing needs to be retained, so that at each transmission
the earliest time for next transmission can be computed that retains the
CPS limit.  It's not clear that there's real need for such a complicated
solution vs something that more bluntly backs off the transmit rate and
uses bucketed averages for tracking the transmission rate.

(I have no idea why it's 330ms for a mixer and 300ms for a non-mixer,
but assume there is some reason for the difference.)

Section 3.6

   Text received by a mixer from a participant SHOULD NOT be included in
   transmission from the mixer to that participant, because the normal
   behavior of the endpoint is to present locally-produced text locally.

When would the SHOULD NOT be ignored?  (How might a mixer know that the
other endpoint is not using the "normal behavior" of presenting
locally-produced text locally?)

Section 3.7

   A mixer SHALL handle reception, recovery from packet loss, deletion
   of superfluous redundancy, marking of possible text loss and deletion
   of 'BOM' characters from each participant before queueing received
   text for transmission to receiving participants.

Are there specific references available for each of these operations?

Section 3.9

   The source with the oldest text received in the mixer or oldest
   redundant text SHALL be next in turn to get all its available unsent
   text transmitted.  Any redundant repetitions of earlier transmitted

Just to confirm: this is really *all* its available unsent text, not
just however much will fit in one packet/flight/etc.?  Can a participant
"hog the mic" by continuing to append to that list even as transmission
has commenced?

Section 3.13

It took me a bit of searching to realize that it is RFC 2198 that
specifies the additional header that includes the "timestamp offset"
field.  A specific reference here (or maybe from an earlier section?)
would have helped me out.

Section 3.14

   The SSRC of the mixer for the RTT session SHALL be inserted in the
   SSRC field of the RTP header.

As written, this could be taken to say that the non-mixer endpoint
should also use the SSRC of the mixer.

Section 3.16

   Confidentiality SHALL be considered when composing these fields.

I think "privacy considerations" would be more relevant than
"confidentiality".

   Similar considerations SHALL be taken as for other media.

This seems rather vague and it's not really clear how the implementor is
supposed to take action based on it.  (Note that media are typically
straight over (S)RTP, but these reports are (S)RTCP, which admittedly is
also over (S)RTP, but is still different.)

Section 3.17.2

   If it is known that only one source is active in the RTP session,
   then it is likely that a gap equal to or larger than the agreed
   number of redundancy generations (including the primary) causes text
   loss.  [...]

Some more care in description may be needed here, as the gap in RTP
sequence numbers is measured in the RTP sequence units (e.g., time), but
the redundancy generation number is just a dimensionless generation
count.  We need to assume the max inter-packet spacing in order to
convert that into a time value that is suitable for assuming loss.

   evaluate if three or more packets were lost within one second.  If
   this simple method is used, then a t140block SHOULD be created with a
   marker for possible text loss [T140ad1] and associated with the SSRC
   of the transmitter as a general input from the mixer.

Does "input from the mixer" mean that it uses the mixer's SSRC value?
Or is this injected by the mixer (in contrast to the previous paragraph,
where it was the receiver that injects the marker for possible text
loss)?

Section 3.17.3

   If the packet is not the first packet from a source, then if the
   second generation redundant data is available, its timestamp SHALL be
   created by subtracting its timestamp offset from the RTP timestamp.
   If the resulting timestamp is later than the latest retrieved data
   from the same source, then the redundant data SHALL be retrieved and
   appended to the receive buffer.  The process SHALL be continued in
   the same way for the first generation redundant data.  After that,
   the primary data SHALL be retrieved from the packet and appended to
   the receive buffer for the source.

I think I can come up with reordering scenarios that cause this
procedure to discard data that would otherwise have recovered from loss.

Also, this procedure as written says that the primary data shall always
be appended to the receive buffer (with no time check), which could
result in doubled content in the case of reordering.

Section 3.19

   Security SHOULD be applied when possible regarding the capabilities
   of the participating devices by use of SIP over TLS by default

"Security" is not some all-encompassing attribute that can be
generically applied; there are specific security properties that may or
may not be achieved by any given mechanism, and it's generally worth
being precise about what properties are (or are not) achieved.  So here
we might say "security mechanisms to provide confidentiality and
integrity protection and peer authentication SHOULD be applied".  We
cannot in general achieve source authenticity with just SRTP when a
mixer is involved, though RFC 8723 does specify a double-encryption
mechanism that applies in some cases when there is a central media
distributor.

                                                             In
   applications where legacy endpoints without security may exist, a
   negotiation SHOULD be performed to decide if encryption on the media
   level will be applied.  [...]

How would endpoints know if legacy endpoints might exist?

How would this negotiation be performed?

   security levels.  The mixing for conference-unaware endpoints has
   lower security level than the mixing method for conference-aware
   endpoints, because there may be an opportunity for a malicious mixer
   or a middleman to masquerade the source labels accompanying the text
   streams in text format.  This is especially true if support of un-
   encrypted SIP and media is supported because of lack of such support
   in the target endpoints.  However, the mixing for conference-aware
   endpoints as specified here also requires that the mixer can be
   trusted.  [...]

As the last sentence indicates, the provided reasoning in the first
sentence is not really accurate, since the mixer could just as easily
adjust the CSRC value in the header as change the label in the in-band
text stream.  This does not inherently invalidate the claim that there
are different security levels, though, as the correct behavior of the
mixer seems easier to independently validate in the conference-aware
endpoint case (with the well-formed RTP payloads providing information
that can be validated out-of-band with other participants).  But I don't
think this description should be left in the document as-is; it doesn't
seem accurate.

In the case of unencrypted media, it does seem technically true that it
is easier for a non-mixer middleman to masquerade the source labels,
since in that case it only adjusts the payload directly without needing
to keep state on the RTP sender information and produce well-formed RTP
headers after its adjustment.  But this is only a modest level of
additional difficulty and does not reflect any kind of effective
security control, so it may not be worth mentioning at all.

   End-to-end encryption would require further work and could be based
   on WebRTC as specified in Section 1.2.

Is RFC 8723 not applicable to these scenarios at all?  I do not think it
is WebRTC-specific.

Section 3.21

          Transmission of A2 and A3 as redundancy is planned for 330 ms
   after packet 101 if no new text from A is ready to be sent before
   that.

I thought new text from *anyone* would trigger sending A2 and A3 as
redundancy, per §3.9.

Is there any reason why the dummy offsets in 104 are 300/600 but the
dummy offsets in 103 are 330/660?

Section 4.2

               In order to expedite source switching, a user can, for
   example, end its turn with a new line.

How would a user know that there is a legacy endpoint in the coversation
so as to choose to end its turn in this way?

Section 4.2.2

   *  A long pause (e.g., > 10 seconds) in received text from the
      currently transmitted source

   *  If text from one participant has been transmitted with text from
      other sources waiting for transmission for a long time (e.g., > 1
      minute) and none of the other suitable points for switching has

I think I'm confused how we could hit the 1 minute timer before the 10
seconds timer has triggered.

Section 11

I think that the obvious attacks involving control characters are
addressed in one way or another, but it might be worth a reminder to
implementors that control characters should not be allowed to let one
user's content affect the display of other users' content, or the
presentation-format's label of the sender, etc.

It might be appropriate to have yet another reminder here that SRTP is
the recommended mode of operation.

   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], [...]

Could you point me to where this is stated in RFC 3550?  I looked in the
security considerations (section 14) and searched for all instances of
"CNAME", but didn't see discussion about SDES/CNAME/NAME being privacy
sensitive.

Section 13.1

RFC 8825 is not currently referenced in any context that specifically
requires it to be listed as a normative reference.  This may suggest
that it should be referenced in more places (e.g., in the discussion of
gateway considerations with WebRTC).

NITS

Section 1

   Use of RTT is increasing, and specifically, use in emergency calls is
   increasing.  Emergency call use requires multiparty mixing.  [...]

I expect the conclusion that emergency-call use requires mixing to be
non-intuitive to many readers, so additional explanation might be
helpful.

                                                                RFC 4103
   "RTP Payload for Text Conversation" mixer implementations can use
   traditional RTP functions for source identification, but the

The word "mixer" (or even "mix") does not appear in RFC 4103, so I'm not
sure how to interpret "RFC 4103 mixer implementations".  Perhaps it is
an RFC 3550 mixer acting on RFC 4103 payloads?

   The document updates [RFC4103] by introducing an attribute for
   indicating capability for the RTP-mixer-based multiparty mixing case
   and rules for source indications and interleaving of text from
   different sources.

I think "indicating capability for the RTP-mixer-based multiparty mixing
case" needs another verb.

Section 2.2

   A party acting as a mixer, which has not negotiated any method for
   true multiparty RTT handling, but negotiated a "text/red" or "text/
   t140" format in a session with a participant SHOULD in order to
   maintain interoperability, if nothing else is specified for the
   application, format transmitted text to that participant to be
   suitable to present on a multiparty-unaware endpoint as further
   specified in Section 4.2.

comma after "SHOULD".
The whole sentence is a bit long, though, and the parenthetical "if
nothing else is specified for the application" is somewhat in the way in
its current location.  Further reworking may be in order.

I'd also consider s/format transmitted text/transmit formatted text/ or
/format text transmitted/.

Section 2.3.4

   If the modified offer deletes indication of support for multiparty
   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 multiparty-aware parties according to this specification.

The BCP 14 keyword "SHALL NOT" is supposed to appear as the specific
phrase, so something like "SHALL NOT, after processing the SDP exchange,
send" seems more appropriate.

Section 3.4

   transmission MUST then be made at T140block borders.  See also
   Section 8

full stop at end of sentence.

Section 3.10

   The mixer SHALL compose and transmit an RTP packet to a receiver when
   one of the following conditions has occurred:

Maybe "one or more" (or "one or both")?

Section 3.16

   Confidentiality SHALL be considered when composing these fields.
   They contain name and address information that may be sensitive to
   transmit in its entirety e.g., to unauthenticated participants.

comma before "e.g." (as well as after)

Section 3.17

   presentation areas for each source.  Other receiver roles, such as
   gateways or chained mixers are also feasible, and requires
   consideration if the stream shall just be forwarded, or distributed

"such as gateways or chained mixers" seems like a parenthetical phrase
that should be offset by commas on both sides.

Also, "require consideration" seems to match up better with the plural
"roles".

Section 3.17.3

   When a packet is received in an RTP session using the packetization
   for multiparty-aware endpoints, its T140blocks SHALL be extracted in
   the following way.  The description is adapted to the default
   redundancy case using the original and two redundant generations.

Is this supposed to imply that the extension to the generic case with
other levels of redundancy is trivial for the reader to perform?

Section 3.18

   This solution has good performance with low text delays as long as
   the sum of characters per second during any 10-second interval sent
   from a number of simultaneously sending participants to a receiving
   participant does not reach the 'CPS' value.  [...]

"sum of characters per second during any 10-second interval" seems to
mean "compute CPS for each second, then add them up".  I don't think
that's the intended meaning.

                                   Only in large unmanaged conferences
   with a high number of participants there may on very rare occasions
   appear situations when many participants happen to send text
   simultaneously, resulting in unpleasantly jerky presentation of text
   from each sending participant.  [...]

This sentence seems a bit long and winding.

Section 3.20

      Offer example for "text/red" format including multiparty
      and security:
            a=fingerprint: (fingerprint1)

I think it would be preferred to make up some random fingerprints and
use them instead of the placeholder string (throughout).

Section 3.21

   offset 660 ms.  The timestamp of packet 106 minus 660 is 20500 which
   is the timestamp of packet 102 THAT was received.  So B1 does not

I don't see why "THAT" needs to be in all majuscule letters.

Section 3.22

   to transmission to a receiver.  The value MAY be modified in the
   "CPS" parameter of the FMTP attribute in the media section for the
   "text/t140" media.  [...]

RFC 4103 seems to show the lowercase "cps" parameter name (there are
subsequent occurrences that I do not quote).

Section 4.2

   one presentation area.  The mixer SHALL group text in suitable groups
   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

Is "new line" specified somewhere?  Up in toplevel §4 we cover the
unicode line separator and CRLF sequences but don't use the phrase "new
line".

Section 4.2.2

   Information available to the mixer for composing the label may
   contain sensitive personal information that SHOULD not be revealed in

"SHOULD NOT" in all caps

   sessions not securely authenticated and protected.  Integrity

"confidentiality protected"

   considerations regarding how much personal information is included in
   the label SHOULD therefore be taken when composing the label.

I don't think "integrity" is the right word here.

Section 11

   Therefore, the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  [...]

s/trusted to achieve security in confidentiality and integrity/trusted
to maintain confidentiality and integrity of the RTT data/

   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as

There's something awry with the commas around "for creation of labels".

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 19 May 2021 23:25:04 +0200

Benjamin,

Thanks for the thorough review.

I will respond in multiple pieces, starting with the first parts of the 
DISCUSS.

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

[GH] You are right. The text in 3.9 i not clear enough. If there is no 
new text from A, the redundancy of A shall not be sent until 330 ms 
after the primary text from A was sent.

Only if new text arrives from A before 330 ms after the previous text 
was sent, then both that new text and the redundancy shall be sent, when 
the new text is the oldest available.

So in the example, it is correct to send text from B first.

One way to say it is that redundant text shall not participate in the 
age assessment until it is 330 ms older than when it was last sent. But 
it shall be included if new text is available and decided to be sent.

When composing suitable text from this, we also need to consider that 
the "CPS" value may puts a limit to how much new text may be sent.

We also have the following words last in 3.12:

"   The T140blocks saved for transmission as redundant data are assigned
    a planned transmission time 330 ms after the current time, but SHOULD
    be transmitted earlier if new text for the same source gets in turn
    for transmission before that time."

So, 3.9 is about interleaving new text and not about making sure that 
redundancy is sent even when there is no new text.  The text in 3.9 may 
become correct by deleting the redundancy from the age assessment, and 
include "CPS" consideration, to result in:

"The source with the oldest text received in the mixer  SHALL be next in 
turn to get all its available unsent text transmitted, as long as it is 
allowed considering the "CPS" value of the receiver.  Any redundant 
repetitions of earlier transmitted  text not yet sent the intended 
number of times SHALL be included as redundant retransmission in the 
transmission."

> resolve that in some manner before the document proceeds.
[GH]

-Answers to be continued,

Gunnar
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 23 May 2021 22:21:36 +0200

Benjamin,

This is a more complete answer on your DISCUSS

I think the description of the procedure was too much spread out in 
section 3. So, I propose to delete section 3.9, and change 3.4 to become:

--------------------------------------------------------------------------------------------

3.4.  Transmission interval

    A "text/red" or "text/t140" transmitter in a mixer SHALL send packets
    distributed in time as long as there is something (new or redundant
    T140blocks) to transmit.  The maximum transmission interval between
    text from the same source SHALL then be 330 ms, when no other
    limitations cause a longer interval to be temporarily used.
    It is RECOMMENDED to send the next packet to a
    receiver as soon as new text to that receiver is available, as long
    as the maximum character rate ("CPS") to the receiver is not exceeded
    during any 10-second interval.  The intention is to keep the latency
    low and network load limited while keeping good protection against
    text loss in bursty packet loss conditions.
    The main purpose of the 330 ms interval is for timing of redundant
    transmission, when no new text from the same source is available.

    The reason for the value 330 ms is that many sources of text will
    transmit new text with 300 ms intervals during periods of
    continuous user typing, and then reception in the mixer of such new
    text will cause a combined transmission of the new text and the
    unsent redundancy from the previous transmission. Only when the user
    stops typing, the 330 ms interval will be applied to send the
    redundancy.

    If the "CPS" value is reached, a longer transmission interval SHALL be
    applied for text from all sources as specified in [RFC 4103] and only
    as much of the text queued for transmission SHALL be sent at the end
    of each transmission interval that can be allowed without exceeding
    the "CPS" value. Division of text for partial transmission MUST
    then be made at T140block borders.
    When the transmission rate falls under the "CPS" value again,
    the transmission intervals SHALL be returned to 330 ms and
    transmission of new text SHALL return to be made as soon as new
    text is available.

    NOTE: that extending the transmission intervals during high load
    periods does not change the number of characters to be conveyed.
    It just evens out the load in time and reduces the number of packets
    per second. With human created conversational text, the sending
    user will eventually take a pause letting transmission catch up.

    See also Section 8

    For a transmitter not acting as a mixer, the transmission interval
    principles from [RFC4103] apply, and the normal transmission 
interval SHALL
    be 300 ms.

Section 3.10 also needs a few changes, to read:

3.10.  Text placement in packets

    *  There is unsent text available for transmission to that receiver.

|   *  The current transmission interval ( normally 330 ms) has passed
|     since already transmitted text was queued for
|      transmission as redundant text.

    At the time of transmission, the mixer SHALL populate the RTP packet
    with all T140blocks queued for transmission originating from the
    source in turn for transmission as long as this is not in conflict
    with the allowed number of characters per second ("CPS") or the
    maximum packet size.  In this way, the latency of the latest received
    text is kept low even in moments of simultaneous transmission from
    many sources.

    Redundant text SHALL also be included, and the assessment of how much
    new text can be included within the maximum packet size MUST take
    into account that the redundancy has priority to be transmitted in
|   its entirety.  See Section 3.4

    The SSRC of the source SHALL be placed as the only member in the
    CSRC-list.

    Note: The CSRC-list in an RTP packet only includes the participant
    whose text is included in text blocks.  It is not the same as the
    total list of participants in a conference.  With audio and video
    media, the CSRC-list would often contain all participants who are not
    muted whereas text participants that don't type are completely silent
    and thus are not represented in RTP packet CSRC-lists.

.........................................................................................

The examples in section 3.21 needs some small adjustments:

in packet 104, the timer should be 20 800,

The text above and in packet 106 should be as you also discovered:

  B1 and B2 still need to be transmitted as redundancy.
|     This is planned 330 ms after packet 104. That
|    would be at 21130.

       |-----------------------|
|     |Seq no 106, Timer=21130|
       |CC=1                   |
       |CSRC list B            |
       | R2: B1, Offset=660    |
       | R1: B2, Offset=330    |
       | P:  Empty             |
       |-----------------------|

-----------------------------------------------------------------

Regards

Gunnar

.

Den 2021-05-19 kl. 23:25, skrev Gunnar Hellström:
> I will respond in multiple pieces, starting with the first parts of 
> the DISCUSS.
>
> was sent, then both that new text and the redundancy shall be sent, 
> when the new text is the oldest available.
>
> age assessment until it is 330 ms older than when it was last sent. 
> But it shall be included if new text is available and decided to be sent.
>
> redundancy is sent even when there is no new text.  The text in 3.9 
> may become correct by deleting the redundancy from the age assessment, 
> and include "CPS" consideration, to result in:
>
> "The source with the oldest text received in the mixer  SHALL be next 
> in turn to get all its available unsent text transmitted, as long as 
> it is allowed considering the "CPS" value of the receiver.  Any 
> redundant repetitions of earlier transmitted  text not yet sent the 
> intended number of times SHALL be included as redundant retransmission 
> in the transmission."
>
>
>
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 24 May 2021 16:33:23 +0200

Benjamin,

I hope I resolved the issues with 3.9 in the previous answer.

Therefore I continue here with 3.19 that you partly included in the DISCUSS.

You say:

"I also left a note in the comment that there's a remark about "lower
security level" in Section 3.19 that's not really accurate; we should
resolve that in some manner before the document proceeds."

Section 3.19

integrity protection and peer authentication SHOULD be applied".

[GH] Accepted and included.
  We
cannot in general achieve source authenticity with just SRTP when a
mixer is involved, though RFC 8723 does specify a double-encryption
mechanism that applies in some cases when there is a central media
distributor.

  In

[GH] It may be a decision by the service provider. It is of course not 
desirable to mix secure and unsecured endpoints, but that is what is 
specified in the next generation emergency service RFC:s RFC 6443 and 
RFC 6881. These RFCs have reasoning about that choise. I suggest to 
replace "may exist" with "are allowed".   

  How would this negotiation be performed?
[GH]The draft only supplies a suitable example in next sentence by 
recommending RFC 8643 OSRTP when nothing else is specified in the 
application. RFC 6443 and RFC 6881 also specifies mechanisms to be used 
for negotiating security. I suggest that that is sufficient.   

In the case of unencrypted media, it does seem technically true that it
is easier for a non-mixer middleman to masquerade the source labels,
since in that case it only adjusts the payload directly without needing
to keep state on the RTP sender information and produce well-formed RTP
headers after its adjustment.  But this is only a modest level of
additional difficulty and does not reflect any kind of effective
security control, so it may not be worth mentioning at all.
[GH]I suggest to delete the paragraph, except the last sentence 
referring to "Further security considerations..."

  End-to-end encryption would require further work and could be based
    on WebRTC as specified in Section 1.2.
Is RFC 8723 not applicable to these scenarios at all? I do not think it 
is WebRTC-specific. [GH] Yes, it looks good, but requires quite another 
approach to how to detect and indicate text loss, because RFC 2198 that 
is used, has a header in the RTP payload, containing Payload type and 
timestamp offsets. RFC 8723 has a special chapter on how to handle cases 
when RFC 2198 is used, and it requires the detection of loss and 
recovery to be handled between the source and the destination rather 
than by the mixer. I suggest to add reference to RFC 8723 in the 
sentence about further work to read: "End-to-end encryption would 
require further work and could be based on WebRTC as specified in 
section 1.2 or on double encryption as specified in [RFC8723]."

----

Continuation will follow with the COMMENT points.
Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 24 May 2021 23:14:59 +0200

Continuing the answers:

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

[GH] There is an implementation of section 4.2

4.2.  multiparty mixing for multiparty-unaware endpoints
It works well.

It is true that there are no known implementations of the method for 
multiparty-aware endpoints. However the basic methods: the RTP-mixer and 
the centralized SIP conference model, and the base RTP transport for 
real-time text (RFC 4103) are all commonly implemented.

> What was the outcome of the discussion?  Should that be reflected in the
[GH] The discussion is concluded in section 1.2, and a note in 3.20.
The first expected implementation environment is the traditional SIP 
centralized conference server and endpoints (for emergency services) , 
where traditional RTP-mixers are the dominating bases for 
implementations. It seems to me that we are closer to get 
implementations done by keeping to that well known technology than 
trying to apply selective forwarding for this case.

> shepherd writeup) of any actual implementations.

[GH] The RTP-mixer is a general technology, specified in RFC 3550. It is 
very commonly applied in conference bridges since long, but for the 
other media; video and audio. But more important here is that the 
RTP-mixer makes use of just one RTP media stream to each receiver. Many 
implementations of RTP seem to have the limitation that they cannot 
handle more than one media stream per RTP media session. Requiring a 
multi-stream solution would have led to excluding a lot of potential 
current endpoints with two-party RTT implementations from becoming 
upgraded to RTT multiparty-aware endpoints.

> (How was the "15" number determined?)
[GH] It is a limitation from the maximum size of the CSRC list in the 
RTP header defined in RFC 3550:
"

CSRC list: 0 to 15 items, 32 bits each The CSRC list identifies the 
contributing sources for the payload contained in this packet. The 
number of identifiers is given by the CC field. If there are more than 
15 contributing sources, only 15 can be identified." In our case it is 
essential to have the sources identified, and complicated to go over 
this limitation. I suggest to add to the text in 1.2 to read: "The 
sources are indicated in strict order in the CSRC list of the RTP 
packets. The CSRC list can have up to 15 members. Therefore, text from 
up to 15 sources can be included in each packet."

> say only "chooses to use the RTP-mixer-based method of this

[GH] It says "willing" because also two-party coded real-time text is 
still allowed. The multi-party coding is expected to be applied when 
more than two parties participate in the call.

So, the answerer is not willing to use another multiparty method.

In order to make that clear, I suggest to insert this sentence before 
the discussion of other multiparty methods in 2.3.2:

"  Even when the "rtt-mixer" attribute is successfully negotiated, the 
parties MAY send and receive two-party coded real-time text."

> keepalive, but in rtt-mix don't we have lots of non-BOM keepalive

[GH] The initial BOM is for initial opening of ports and firewall paths 
so that traffic rapidly can start to flow both ways. In real-time text 
already the first real media packet with text is important, while for 
most other media (= video and audio) usually many hundred RTP packet 
flow before any important information carrying packet is sent. BOM is 
also said in Unicode to be required in the beginning of UNICODE streams, 
and that is negated by RFC 5198. RFC 4103 is a update of RFC 2793, 
published in May 2000. At that time RFC 2279 was the UTF-8 RFC. RFC 2279 
did not mention any restrictions for use of BOM, so RFC 2793 specified 
the use from Unicode, For interoperability reasons we have not changed 
that in RFC 4103 and not in the current draft. So we can just realizr 
that we are not fully RFC 5198 compliant of historical and 
interoperational reasons.

BOM is not recommended as keep-alive even if some implementations may 
use it.

I suggest to add this sentence in 3.2: " This is useful in many 
configurations to open ports and firewalls and setting up the connection 
between the application and the network."

> uses bucketed averages for tracking the transmission rate.

[GH] I suggest to change the calculation of mean character rate in the 
first paragraph of 3.4 to: " as long as the mean character rate of new 
text to the receiver calculated over the last 10 one-second intervals 
does not exceed the "CPS" value of the receiver."

That calculation method of character rate will then be remembered when 
reading other references to "CPS"

> but assume there is some reason for the difference.)

[GH] I have now inserted an explanation in 3.4 as proposed in the 
DISCUSS resolution:

"    The reason for the value 330 ms is that many sources of text will
    redundancy."

> locally-produced text locally?)
[GH] It is SHOULD just to allow specific applications to deviate. I have 
no reason to think that it would be useful, but I do not want to make it 
forbidden. Then all mixers and endpoints in that application environment 
would do it the same way or have a setting or control mechanism to 
select which solution to use. I suggest no change.
> Are there specific references available for each of these operations?

[GH] Yes. I suggest to add last " as specified in [RFC4103] for 
single-party sources and section 3.17  for multiparty sources (chained 
mixers).

> "hog the mic" by continuing to append to that list even as transmission
[GH] Section 3.9 is in answers to the DISCUSS suggested to be replaced 
by wording in 3.4, where the problem indicated here is amended.
> would have helped me out.
[GH] I suggest to include after the bullet list in section 3.10 the 
following:
             "The principles from [RFC4103] apply for populating the 
header, the redundancy header and the data in the packet with specifics 
specified here and in the following sections."

I hope it is OK to take it in pieces, with next piece coming soon.

Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 25 May 2021 12:29:51 +0200

Benjamin,

Continuing the answers with the last part.,

> should also use the SSRC of the mixer.
[GH] I suggest to change to:
" The SSRC header field SHALL contain the SSRC of the RTP session where 
the packet will be transmitted."
> I think "privacy considerations" would be more relevant than
[GH] Accepted. Changed to "Privacy considerations SHALL be taken..."
> also over (S)RTP, but is still different.)
[GH] I propose to delete the sentence.

> convert that into a time value that is suitable for assuming loss.
[GH] The RTP sequence number steps by one for each new packet sent in 
the RTP session. It is the timestamp that is increased by the time.  
Real-time text is also unusual in that it can transmit with varying 
intervals and be silent when there is no new text to send. No change 
proposed.
> where it was the receiver that injects the marker for possible text
[GH] I suggest to change "transmitter" to "RTP session" to make it clear 
that it is the mixer.
> procedure to discard data that would otherwise have recovered from loss.
[GH] Would it be sufficient to insert the words "and reordering" in the 
first two sentences in the paragraph to read:
"The receiver SHALL monitor the RTP sequence numbers of the received 
packets for gaps and packets out of order.
If a sequence number gap appears and still exists after some defined 
short time for jitter and reordering resolution, the packets in the gap 
SHALL be regarded as lost."
> result in doubled content in the case of reordering.
[GH] I suggest to change the last sentence in the paragraph to " After 
that, the timestamp of the packet SHALL be compared with the timestamp 
of the latest retrieved data from the same source and if it is later, 
then the primary data SHALL be retrieved from the packet and appended to 
the receive buffer for the source."
> mechanism that applies in some cases when there is a central media
[GH] Answered in the DISCUSS part.
> How would endpoints know if legacy endpoints might exist?
[GH] Answered in the DISCUSS part.
> How would this negotiation be performed?
[GH] Answered in the DISCUSS part.
> security control, so it may not be worth mentioning at all.
[GH] Answered in the DISCUSS part.
> Is RFC 8723 not applicable to these scenarios at all?  I do not think it
[GH] Answered in the DISCUSS part.
> I thought new text from *anyone* would trigger sending A2 and A3 as
[GH] No, since A2 and A3 sent as redundancy only can be sent alone or 
together with new text from A, they should only be triggered to be sent 
when new text from A has arrived or the current transmission interval 
since last transmission from A has passed. I hope that is clear from 
"3.5 Only one source per packet."
> dummy offsets in 103 are 330/660?
[GH] There are dummy offsets in 102, 104 and 105. The ones which can be 
analyzed for the values are the ones in 104 and 105. They have the same 
values as they would have if there was redundancy on that level 
available for transmission at that time. Since the value is irrelevant, 
that is just one way to assign a "realistic" value.
> so as to choose to end its turn in this way?
[GH] It can be from experience or education. The first implementations 
are expected to be in emergency services, where the calling users in 
emergency may get multiparty-aware clients later than the emergency 
service call- takers. The call-takers can then be educated from the 
beginning to end their turns with a new line to expedite the switch so 
that new text from the caller is rapidly presented to another person in 
the service observing, or taking over the call. It is also quite normal 
in modern text communication, both real-time and messaging, to end turn 
with a new line.
> seconds timer has triggered.
[GH] If one user is generating text continously, e.g. making a live 
transcription of someone making a speech, then it may happen that the 
text neither has full stop anywhere, nor any pause longer than 10 
seconds appears within one minute or more. In that situation it is fair 
that waiting text is allowed to break in and be given turn.
> presentation-format's label of the sender, etc.

[GH] I suggest to insert in section 11:

"      Participants with malicious intentions may also try to disturb 
the presentation by sending incomplete or malformed control codes. 
Handling of text from the different sources by the receivers MUST 
therefore be well separated so that the effects of such actions only 
affect text from the source causing the action. "

> the recommended mode of operation.
[GH] I suggest to insert the following in section 11:
"As already stated in <xref target="security2" format="default"/>, 
security in media SHOULD be applied by using DTLS-SRTP <xref 
target="RFC5764" format="default"/> on the media level."
> "CNAME", but didn't see discussion about SDES/CNAME/NAME being privacy
[GH] In RFC 3550, sentences 2 and 3, it is said: "

For example, an impostor can fake source or destination
    network addresses, or change the header or payload.  Within RTCP, the
    CNAME and NAME information may be used to impersonate another
    participant. "

> gateway considerations with WebRTC).
[GH] I think it is sufficient to reference RFC 8865 in the WebRTC 
gateway section. Therefore my proposal is to move the reference to RFC 
8825 to informational.
> non-intuitive to many readers, so additional explanation might be
[GH] I propose extending the sentence to: " Emergency call use requires 
multiparty mixing because it is common that one agent needs to transfer 
the call to another specialized agent but is obliged to stay on the call 
at least to verify that the transfer was successful. "
> an RFC 3550 mixer acting on RFC 4103 payloads?
[GH] I do not think that other RTP payload type specifications specify 
how RTP mixing shall be applied either. It is just assumed that RFC 3550 
RTP mixing is used. Anyway, I suggest to change the sentence to: "Mixer 
implementations for RFC 4103 "RTP Payload for Text Conversation" can use 
traditional RFC 3550 RTP functions for mixing and source identification."
> case" needs another verb.
[GH] My non-English background makes me not realize the problem. Will it 
be better with "declaring support of" instead of "indicating capability 
for". If so, there may be a couple of other places where similar wording 
should be changed.
> its current location.  Further reworking may be in order.
[GH] I propose to change to:
"A mixer SHOULD by default format and transmit text to a call 
participant to be suitable to present on a multiparty-unaware endpoint 
which has not negotiated any method for true multiparty RTT handling, 
but negotiated a "text/red" or "text/t140" format in a session. This 
SHOULD be done if nothing else is specified for the application in order 
to maintain interoperability. Section 4.2 specifies how this mixing is 
done."
> /format text transmitted/.
[GH] Included above
> send" seems more appropriate.
[GH] I propose to change to:
"If the modified offer deletes indication of support for multiparty 
real-time text by excluding the "rtt-mixer" SDP attribute, the answer 
MUST NOT contain the "rtt-mixer" attribute. After processing this SDP 
exchange, the parties MUST NOT send real-time text formatted for 
multiparty-aware parties according to this specification."
> full stop at end of sentence.
[GH] Accepted.
> Maybe "one or more" (or "one or both")?
[GH] Accepted.
> comma before "e.g." (as well as after)
[GH] Accepted.
> that should be offset by commas on both sides.
[GH] Accepted.
> Also, "require consideration" seems to match up better with the plural
[GH] I suggest to start a new sentence "They require considerations..."
> other levels of redundancy is trivial for the reader to perform?
[GH] Yes. Should that be indicated?
> that's the intended meaning.
[GH] I suggest: "as long as the mean number of characters per second 
sent during any 10-second interval from a number of simultaneously 
sending participants to a receiving participant, does not reach the 
'CPS' value."
> This sentence seems a bit long and winding.
[GH] I suggest to divide to: "Only in large unmanaged conferences with a 
high number of participants there may on very rare occasions appear 
situations when many participants happen to send text simultaneously. In 
such circumstances, the result may be unpleasantly jerky presentation of 
text from each sending participant."
> use them instead of the placeholder string (throughout).
[GH] I had the opposite reaction in an earlier review, when I had random 
fingerprints. I suggest to keep as is.
> I don't see why "THAT" needs to be in all majuscule letters.
[GH] Right. Accepted.
> subsequent occurrences that I do not quote).
[GH] Thanks , all changed to lower case.
> unicode line separator and CRLF sequences but don't use the phrase "new
[GH] "new line (line separator or CRLF)" is used in a number of places. 
I suggest to modify this one to:
"the mixer SHALL insert a line separator if the already transmitted text 
did not end with a new line (line separator or CRLF)"
>     contain sensitive personal information that SHOULD not be revealed in
[GH]Accepted
> "confidentiality protected"
[GH] Accepted
> I don't think "integrity" is the right word here.
[GH] Change to "Privacy" is proposed.
> to maintain confidentiality and integrity of the RTT data/
[GH] Accepted
> There's something awry with the commas around "for creation of labels".
[GH] I suggest to split in two sentences: "**When used for creation of 
readable labels in the presentation, the receiving user will then get a 
more symbolic label for the source."

[GH]Again, thanks for a thorough review and many good proposals for changes.

Regards

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 25 May 2021 23:23:27 +0200

Anew version of the draft is published, intended to satisfy the DISCUSS 
and all comments.

A new version of I-D, draft-ietf-avtcore-multi-party-rtt-mix-19.txt
has been successfully submitted by Gunnar Hellstrom and posted to the
IETF repository.

Name:		draft-ietf-avtcore-multi-party-rtt-mix
Revision:	19
Title:		RTP-mixer formatting of multiparty Real-time text
Document date:	2021-05-25
Group:		avtcore
Pages:		49
URL:https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-19.txt
Status:https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
Html:https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-19.html
Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix
Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-19

Regards

Gunnar

Gunnar Hellström
GHAccess

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 25 May 2021 17:23:19 -0700

Hi Gunnar,

> Continuing the answers with the last part.,

Thank you for going through them all.  To be clear, I was not waiting for
you to finish before I started replying -- I just had a deadline earlier
today and did not have a chance to do much with my email sooner.  Having
the content chunked up into multiple pieces can make it easier to manage.

This is the only message I'm going to respond to, though, since I basically
have nothing further to say.  (I've already updated my ballot position to
remove the Discuss.)  I'm really impressed with how you took my comments
and turned them into improved text in the document, especially in the
places where I did not have a clear proposal.  I also appreciate your
explanations in the places where my questions did not make sense or are
already covered by some of the fundamental documents in this space; the
gaps in my knowledge are slowly getting filled in.

> Den 2021-05-19 kl. 04:53, skrev Benjamin Kaduk via Datatracker:
[...]
> [GH]Again, thanks for a thorough review and many good proposals for changes.

I must thank you again for your thorough responses; I feel like I am not
doing them justice by only sending this one short note, but do not want to
make you read through a repetitive set of "yes", "this sounds good", "thank
you", etc.

I read through the changes in the already-uploaded -19 (thank you again!),
and there were only two items that might be worth following up on (both in
section 3.16.3 of the -19):

You had proposed:

[GH] Would it be sufficient to insert the words "and reordering" in the
first two sentences in the paragraph to read: "The receiver SHALL monitor
the RTP sequence numbers of the received packets for gaps and packets
out of order.  If a sequence number gap appears and still exists after some
defined short time for jitter and reordering resolution, the packets in the
gap SHALL be regarded as lost."

I don't think this made it into the -19; my preference is to use your
proposed text that includes mention of reordering, but I do not insist on
it.

There was also a mention about the procedures for extracing T140blocks with
the redundancy procedure, where we currently say "T140blocks SHALL be
extracted in the following way.  The description is adapted to the default
redundancy case using the original and two redundant generations."  While I
am inclined to agree that the extension to the generic case with other
levels of redundancy is something that the reader can be expected to
perform, it feels a little incomplete to say that something "SHALL be
[done] in the following way" but give a not-complete/not-generic procedure.
Only for that reason do I prefer to have an explicit indication that the
procedure might need to be adjusted for a different level of redundancy; as
for the previous point, I do not insist on any change, though.

Thanks again,

Ben

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 26 May 2021 09:39:53 +0200

Hi Ben,

Thank you for the kind words.

The inserted words about packets out-of-order that you did not find in 
version -19 are there, but in the beginning of section 3.16.2, instead 
of in 3.16.3 where you expected to find them.

Please see furthe comments inline.

> proposed text that includes mention of reordering, but I do not insist on

[GH] They are there, in 3.16.2, where basic packet reception and gap 
analysis is specified.

it says:

"   The receiver SHALL monitor the RTP sequence numbers of the received
    packets for gaps and packets out of order.  If a sequence number gap
    appears and still exists after some defined short time for jitter and
    reordering resolution, the packets in the gap SHALL be regarded as
    lost. "

This is intended to require that packets are in order when they go to 
the loss analysis and data retrieval stages.

Very late packets out-of-order would be regarded lost. When you said 
that you could imagine cases of duplication, did you then imagine a 
procedure which would recover text also from late coming packets after 
the short time mentioned in the paragraph above? It would be possible, 
but I do not think it should be part of the general document, because it 
would possibly mean manipulating display buffers already presenting 
earlier received text.

I have created a paragraph for that, that can follow the first in 
3.16.2, but I do not think it adds any value to insert it. What do you 
think?

"   Advanced procedures for recovering data from packets received out of
    order later than the short time for jitter and reordering resolution
    mentioned above MAY be implemented but are out of scope for this 
document.
    Such procedures would need to manipulate data in receive buffers and
    possibly also in presentation areas. The procedures MUST avoid
    duplication of already received data."

> for the previous point, I do not insist on any change, though.

[GH] I have made a try to generalize the description. I think it can 
replace the current limited one. What do you think?

"
3.16.3.  Extracting text and handling recovery

    When applying the following procedures, the effects MUST be
    considered of possible timestamp wrap around and the RTP session
    possibly changing SSRC.

    the following way.

    The source SHALL be extracted from the CSRC-list if available,
    otherwise from the SSRC.

    If the received packet is the first packet received from the source,
    then all T140blocks in the packet SHALL be retrieved and assigned to
    a receive buffer for the source beginning with the oldest available
   redundant generation,  continuing with the younger redundant generations
   in age order and finally the primary.

    NOTE: The normal case is that in the first packet, only the primary
    data has contents.  The redundant data has contents in the first
    received packet from a source only after initial packet loss.

    If the packet is not the first packet from a source, then if redundant
    data is available, the process SHALL start with the oldest generation.
    The timestamp of that redundant data SHALL be
    created by subtracting its timestamp offset from the RTP timestamp.
    If the resulting timestamp is later than the latest retrieved data
    from the same source, then the redundant data SHALL be retrieved and
    appended to the receive buffer.  The process SHALL be continued in
    the same way for all younger generations of redundant data. After that,
    the timestamp of the packet SHALL be compared with the timestamp of
    the latest retrieved data from the same source and if it is later,
    then the primary data SHALL be retrieved from the packet and appended
    to the receive buffer for the source.

"

Regards

Gunnar