Subject: Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text"

From: Dan Mongrain <[email-masked]>
Date: Thu, 3 Dec 2020 10:38:17 -0500

I support advancing the document to Proposed Standard.

Thanx,
Dan

*Dan Mongrain, eng.*Principal Engineer, Standards
*Motorola Solutions*

*o*: +1.819.931.2129
*m*: +1.613.558.0764
e: [email-masked]
www.linkedin.com/in/DanMongrain

*[image:
https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*

On Wed, Nov 25, 2020 at 5:17 PM Bernard Aboba <[email-masked]>
wrote:

> This is an announcement of WG last call on "RTP-mixer formatting of
> multi-party Real-time text"
>
> The document is available for inspection here:
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Davtcore-2Dmulti-2Dparty-2Drtt-2Dmix&d=DwMFaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=tVmju8Ajppyzxkv8ox2TXjRfv_4pAM_-pNS3jqZI3q4&s=4VvLfBdjAn1imRBrby2IH51UVWCCkYscezqHUt4EzZ0&e=>
>
> WG Last Call will end on December 9, 2020.
>
> In response, please state one of the following:
>
> * I support advancing the document to Proposed Standard
> * I object to advancement to Proposed Standard, due to Issues described
> below <Issue description or link>.
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=q3cDpHe1hF8lXU5EFjNM_A&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=tVmju8Ajppyzxkv8ox2TXjRfv_4pAM_-pNS3jqZI3q4&s=ohs4DtnbMn2S-lWOqq9aH8De_BLmrjFwdOjnhH83rAA&e=
>

-- 

*For more information on how and why we collect your personal 
information, please visit our Privacy Policy 
<https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement>.*

---

From: Brian Rosen <[email-masked]>
Date: Fri, 4 Dec 2020 12:27:06 -0500

I have reviewed https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11

Although there are quite a few comments below, only the last one is possibly a normative change.  I would be fine with having these comments addressed in whatever the next revision to the document is, rather than hold up IETF last call. I support advancing this document to Proposed Standard.

1. I don’t think it’s necessary to say "Regional regulatory requirements specify provision of real-time text
   in multi-party calls” in the abstract.  It’s true, but the IETF usually doesn’t do things because governments make them a requirement.  Instead, I might say something like “Use of RTT is increasing, and specifically, use in emergency calls is increasing.  Emergency call use requires multiparty mixing”.  I’d just delete the reference to regulatory requirements in the Introduction section.

2. This is a run-on sentence:
   ...The presentation can
   then be arranged so that text from different sources can be presented
   in real-time and easily read while it is possible for a reading user
   to also perceive approximately when the text was created in real time
   by the different parties.
Perhaps “The presentation can then be arranged so that text from different sources can be presented
   in real-time and easily read.  It is also possible for the presentation to indicate approximately when the text was created in real time
   by the different parties.”

3. In 1.1. this text appears: "and in most applications also more than three parties in a call is rare”.  As anyone experiencing this past year can attest, that is not true :). The first part of the sentence is true, and I think this can just be deleted.

4. The heading "The presentation planned by the mixer for multi-party unaware endpoints” is not great English.  Could be “Mixer provides presentation of multiple parties”

5. In section 1.2 could we not say “as defined in” rather than “are explained in” for RFC3550?

6. <not a request to change> I had to look up the definition of “utterance” to see that in linguistics, it means “an uninterrupted chain of spoken or written language”, so it’s correctly used here.

7. In this subsection (Intended use), would it be good to mention the issue of backspace when dealing with multiple parties?  I always found that the best example of why it’s hard to to this centrally.

8. In 2.2 it says “does not itself implement any solution for multi-party handling of real-time text.”  It’s actually that it doesn’t meet this document's “multiparty-aware” specification: if you don’t negotiate the use of the mechanism specified here, then you use this multiparty unaware mechanism.  It could implement some other mechanism but if the mixer didn’t support it, it wouldn’t work.

9. 3.6 missing “the” in "It is RECOMMENDED to send next packet to..”  So “.. send the next packet”

10. In 3.7 it says “New and redundant text from one source SHALL be transmitted in the same packet”.  Is that explained in 4103?  It’s old redundant text and new text.  Not new text and a redundant copy of the new text.  Maybe could use a bit of explaining.

11. Minor English issues in 3.8.  Say “Text received by a mixer from a participant..”

12. Minor English in 3.12.  Say “the participant whose text is included”

13.  Think about expanding WHY you must consider integrity for RTCP (3.18).  Also ".. considerations SHALL be considered" isn’t great construction.

14. 3.19.1, if the receiver is a mixer, then CC=0 doesn’t mean point to point in the sense you intend here.  It’s text from a participant, as opposed to text from a mixer, in a multiparty call.

15. Are 13.19.2 and 13.19.3 just restating what 4103 says?  If they are, then consider deleting

16. Minor English, say “SHALL be regarded as lost”

17. In 3.19.4, you have a normative “a t140 block SHALL be created”, but then later you say “Implementations MAY apply more refined methods”.  Doesn’t that make that SHALL a SHOULD?  Also, minor English, say something like “SHOULD prefer marking possible loss rather than not marking when it is uncertain if there is loss”

18. In 3.21, you have two cross references to the same RFC in the same sentence.  One can be deleted.

19. 3.23, minor English: say “Packet 103 is assumed to be lost due to network problems”.

20. In 3.24 it says 'A value for "CPS" of 90 is the default for the "text/t140" stream in the  "text/red" format when multi-party real-time text is negotiated.’   Is that a restatement of what 4103 says, or a normative statement this document makes?  Please make it more clear.

21. In 4.1 normative MUST/MAY/SHOULD is used to describe user interface.  Is that appropriate? Same for 4.2

22.  On the other hand, in 4.2.1, there is a lower case “.. BOM characters … shall be deleted”.  That might want to be SHALL.

23. In the beginning of 4.2.2, is the “SHOULD be applied for each recipient of multi-part text” actually “...non multi-party aware recipient”?

24. (The only possibly normative change) 4.2.5 says the mixer should send primary data from one source per packet.  Why is that?  The mixer is creating a single stream that contains all the display for the mixed participants.  ISTM there is nothing gained by this restriction, and it means lots of extra packets.  

Brian

> On Nov 25, 2020, at 5:16 PM, Bernard Aboba <[email-masked]> wrote:
> 
> This is an announcement of WG last call on "RTP-mixer formatting of multi-party Real-time text"
> 
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix>
> 
> * I object to advancement to Proposed Standard, due to Issues described below <Issue description or link>. 
> https://www.ietf.org/mailman/listinfo/avt

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Dec 2020 14:54:00 -0800

Here are my comments.

Overall, I would suggest placing terminology and some overview material
earlier in the document.  Also,
some clarifications of desired behavior by SFUs might be helpful.

Abstract

   Enhancements for RFC 4103 real-time text mixing is provided in this

[BA] "is provided" -> "are provided"

   document, suitable for a centralized conference model that enables
   source identification and source switching.  The intended use is for

[BA] "source switching" is not clear in this context. The document
refers to the mixing model in which the conferencing server sends
a single SSRC to participants with contributors in the CSRC field.
But an SFU will just forward packets to a participant, who will see
multiple SSRCs (and no CSRCs). Since the SSRCs may be modified, this
can also be construed as "source switching".

   real-time text mixers and multi-party-aware participant endpoints.

[BA] It is not clear to me what "multi-party-aware" means here. Do you
mean that the endpoint can distinguish between sources based on SSRC, or
CSRC, or both?

   The specified mechanism build on the standard use of the CSRC list in

[BA] "build" -> "builds"

   the RTP packet for source identification.  The method makes use of
   the same "text/t140" and "text/red" formats as for two-party
   sessions.

   A capability exchange is specified so that it can be verified that a
   participant can handle the multi-party coded real-time text stream.
   The capability is indicated by use of a media attribute "rtt-mixer".

   The document updates RFC 4103[RFC4103]

   A specifications of how a mixer can format text for the case when the

[BA] "A specifications" -> "Specification"

1.  Introduction

   RFC 4103[RFC4103] specifies use of RFC 3550 RTP [RFC3550] for

[BA] A better citation format is "RTP Payload for Text Conversation"
[RFC4103]

   transmission of real-time text (RTT) and the "text/t140" format.  It
   also specifies a redundancy format "text/red" for increased
   robustness.  RFC 4102 [RFC4102] registers the "text/red" format.
   Regional regulatory requirements specify provision of real-time text
   in multi-party calls.

[BA] Reference?

   Another requirement is that the mixing procedure must not introduce
   delays in the text streams that are experienced disturbing the real-

[BA] "experienced" -> "experienced,"

   time experience of the receiving users.

   Real-time text mixers for multi-party sessions therefore need to
   insert the source of each transmitted group of text from a conference
   participant so that the text can be transmitted interleaved with text
   groups from different sources in the rate they are created.  This
   enables the text groups to be presented by endpoints in suitable
   grouping with other text from the same source.  The presentation can
   then be arranged so that text from different sources can be presented
   in real-time and easily read while it is possible for a reading user
   to also perceive approximately when 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 that presentation can be arranged in a
   layout decided by the endpoint.

[BA] By "insert the source" I assume that you mean "indicate the
contributing
SSRC within the CSRC field", correct?

   There are existing implementations of RFC 4103 without the updates
   from this document.  These will not be able to receive and present
   real-time text mixed for multi-party aware endpoints.

[BA] By "implementations", you mean "conferencing server implementations",
correct?
Presumably these implementations do not support mixing, so how do they
operate?

   A negotiation mechanism is therefore needed for verification if the
   parties are able to handle a multi-party coded stream and agreeing on
   using that method.

[BA] Can you clarify what "multi-party coded stream" means, exactly? Does
this imply a single SSRC with multiple CSRCs? Or would multiple SSRCs
without
CSRCs also qualify? It would perhaps help to have the terminology section
moved
up prior to

   A fall-back mixing procedure is also needed for cases when the
   negotiation result indicates that a receiving endpoint is not capable
   of handling the mixed format.  This method is called the mixing
   procedure for multi-party unaware endpoints.  The fall-back method is
   naturally not expected to meet all performance requirements placed on
   the mixing procedure for multi-party aware endpoints.

[BA] A clarification of the behavior of "multi-party unaware endpoints"
would
be helpful. Do these just ignore the SSRC and CSRC fields entirely?

   The document updates RFC 4103[RFC4103] by introducing an attribute
   for indicating capability for the multi-party mixing case and rules
   for source indications and source switching.

1.1.  Selected solution and considered alternative

[BA] I think you need to insert the terminology section before this
section.

   A number of alternatives were considered when searching an efficient
   and easily implemented multi-party method for real-time text.  This
   section explains a few of them briefly.

Hellstrom                  Expires 26 May 2021                  [Page 5]

Internet-Draft    RTP-mixer format for multi-party RTT     November 2020

   One RTP stream per source, sent in the same RTP session with
   "text/red" format.
      From some points of view, use of multiple RTP streams, one for
      each source, sent in the same RTP session, called the RTP
      translator model in [RFC3550], would be efficient, and use exactly

[BA] I would suggest referencing "RTP Topologies" [RFC7667]. BTW, a single
SSRC for each source could also be used in the Selective Forwarding
Middlebox topology (Section 3.7), not just the Translator topology,
described in RFC 7667 Section 3.5.

      the same packet format as [RFC4103], the same payload type and a
      simple SDP declaration.  However, the RTP implementation in both
      mixers and endpoints need to support multiple streams in the same
      RTP session in order to use this mechanism.  For best deployment
      opportunity, it should be possible to upgrade existing endpoint
      solutions to be multi-party aware with a reasonable effort.  There
      is currently a lack of support for multi-stream RTP in certain
      implementation technologies.  This fact made this solution not
      selected for inclusion in this document.

[BA] I would suggest that this limitation of existing implementations be
introduced earlier in the document, perhaps summarizing it in terminology.

Note that the use of a mixer, as opposed to an SFU, assumes that the
conferencing
unit has access to the payload (e.g. the payload is not E2E encrypted).

   RTT transport in WebRTC
      Transport of real-time text in the WebRTC technology is specified
      to use the WebRTC data channel in
      [I-D.ietf-mmusic-t140-usage-data-channel].  That spcification

[BA] "spcification" -> "specification"

      contains a section briefly describing its use in multi-party
      sessions.  The focus of this document is RTP transport.
      Therefore, even if the WebRTC transport provides good multi-party
      performance, it is just mentioned in this document in relation to
      providing gateways with multi-party capabilities between RTP and
      WebRTC technologies.

1.2.  Nomenclature

[BA] "Nomenclature" -> "Terminology"?

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The terms SDES, CNAME, NAME, SSRC, CSRC, CSRC list, CC, RTCP, RTP-
   mixer, RTP-translator are explained in [RFC3550]

   The term "T140block" is defined in RFC 4103 [RFC4103] to contain one
   or more T.140 code elements.

Hellstrom                  Expires 26 May 2021                  [Page 7]

Internet-Draft    RTP-mixer format for multi-party RTT     November 2020

   "TTY" stands for a text telephone type used in North America.

   "WebRTC" stands for web based communication specified by W3C and
   IETF.

   "DTLS-SRTP" stands for security specified in RFC 5764 [RFC5764].

   "multi-party aware" stands for an endpoint receiving real-time text
   from multiple sources through a common conference mixer being able to
   present the text in real-time separated by source and presented so
   that a user can get an impression of the approximate relative timing
   of text from different parties.

   "multi-party unaware" stands for an endpoint not itself being able to
   separate text from different sources when received through a common
   conference mixer.

[BA] I would suggest that this section be moved up earlier in the document,
such as Section 1.1.

1.3.  Intended application

2.  Overview over the two specified solutions
[BA] "over" -> "of"

[BA] Overall, this section feels like it should appear earlier in the
document, since it provides an introduction to what it contains. Perhaps
it should be placed just after terminology (suggested to be moved to 1.1)
and before the material currently in Section 1.1?

   This section contains a brief introduction of the two methods
   specified in this document.

3.1.  Offer/answer considerations

   RFC 4103[RFC4103] specifies use of RFC 3550 RTP[RFC3550], and a
   redundancy format "text/red" for increased robustness of real-time
   text transmission.  This document updates RFC 4103[RFC4103] by
   introducing a capability negotiation for handling multi-party real-
   time text, a way to indicate the source of transmitted text, and
   rules for efficient timing of the transmissions interleaved from
   different sources.

   The capability negotiation is based on use of the sdp media attribute
   "rtt-mixer".

   Both parties shall indicate their capability in a session setup or
   modification, and evaluate the capability of the counterpart.

   The syntax is as follows:
      "a=rtt-mixer"

[BA] Might be useful to explicitly state what happens if both offer and
answer don't include "a=rtt-mixer" and also
how an SFU that forwards but doesn't mix should Offer or Answer.

3.2.  Actions depending on capability negotiation result

   A transmitting party SHALL send text according to the multi-party
   format only when the negotiation for this method was successful and
   when the CC field in the RTP packet is set to 1.  In all other cases,
   the packets SHALL be populated and interpreted as for a two-party
   session.

   A party which has negotiated the "rtt-mixer" sdp media attribute MUST
   populate the CSRC-list and format the packets according to Section 3
   if it acts as an rtp-mixer and sends multi-party text.

[BA] Presumably "party" here only refers to the conferencing server, not
participants, correct?

   A party which has negotiated the "rtt-mixer" sdp media attribute MUST
   interpret the contents of the "CC" field the CSRC-list and the
   packets according to Section 3 in received rtp packets in the
   corresponding RTP stream.

   A party not performing as a mixer MUST not include the CSRC list.

[BA] "not performing as a mixer MUST not" -> "not acting as a mixer MUST
NOT"

3.5.  Keep-alive

   After that, the transmitter SHALL send keep-alive traffic to the
   receiver(s) at regular intervals when no other traffic has occurred
   during that interval, if that is decided for the actual connection.
   Recommendations for keep-alive can be found in [RFC6263].

[BA] Reading this paragraph, I'm unclear whether it is advocating an
alternative to the [RFC6263] recommendation (e.g. RTP/RTCP mux). Also
note that RFC 7675 consent checks can also help here.

3.8.  Do not send received text to the originating source

   Text received to a mixer from a participant SHOULD NOT be included in

[BA] "received to" -> "sent to"

   transmission from the mixer to that participant.

3.21.  Security for session control and media

   Security SHOULD be applied on both session control and media.  In

[BA] By "Security" I assume you mean SIP over TLS for signalling and
SRTP for media? It might be useful to say this explicitly (since E2E
security is also possible).

   applications where legacy endpoints without security may exist, a
   negotiation SHOULD be performed to decide if security by encryption
   will be applied.  If no other security solution is mandated for the
   application, then RFC 8643 OSRTP [RFC8643] SHOULD be applied to
   negotiate SRTP media security with DTLS.  Most SDP examples below are
   for simplicity expressed without the security additions.  The
   principles (but not all details) for applying DTLS-SRTP [RFC5764]
   security is shown in a couple of the following examples.

3.22.  SDP offer/answer examples

   This sections shows some examples of SDP for session negotiation of
   the real-time text media in SIP sessions.  Audio is usually provided
   in the same session, and sometimes also video.  The examples only
   show the part of importance for the real-time text media.

     Offer example for "text/red" format and multi-party support:

           m=text 11000 RTP/AVP 100 98
           a=rtpmap:98 t140/1000
           a=rtpmap:100 red/1000
           a=fmtp:100 98/98/98
           a=rtt-mixer

[BA] To be clear: an SFU that forwards but does not mix should Answer
without "a=rtt-mixer", even if the Offer indicates the ability to support
multiple streams per session?
Also, an SFU should not Offer "a=rtt-mixer" if it doesn't support mixing?

      Answer example  from a multi-party capable device
           m=text 14000 RTP/AVP 100 98
           a=rtpmap:98 t140/1000
           a=rtpmap:100 red/1000
           a=fmtp:100 98/98/98
           a=rtt-mixer

      Offer example for "text/red" format including multi-party
      and security:
            a=fingerprint: (fingerprint1)
            m=text 11000 RTP/AVP 100 98
            a=rtpmap:98 t140/1000
            a=rtpmap:100 red/1000
            a=fmtp:100 98/98/98
            a=rtt-mixer

   The "fingerprint" is sufficient to offer DTLS-SRTP, with the media
   line still indicating RTP/AVP.

   Note: For brevity, the entire value of the SDP fingerprint attribute
   is not shown in this and the following example.

---

From: James Craig <[email-masked]>
Date: Fri, 04 Dec 2020 16:13:55 -0800

It's an important step forward to allow multiple parties to use RTT simultaneously. Among other use cases, this capability is being requested by various regulatory bodies for coordination between emergency service dispatchers, first responders on the ground, and the individuals they are assisting. 

Thanks,
James Craig
Apple Accessibility Standards

> On Nov 25, 2020, at 2:16 PM, Bernard Aboba <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 5 Dec 2020 12:08:48 +0100

Brian, thanks for review and comments,

I start with responding #24.

Den 2020-12-04 kl. 18:27, skrev Brian Rosen:
> I have reviewed 
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11 
> <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11>
>
> Although there are quite a few comments below, only the last one is 
> possibly a normative change.
....
>
> 24. (The only possibly normative change) 4.2.5 says the mixer should 
> send primary data from one source per packet.  Why is that?  The mixer 
> is creating a single stream that contains all the display for the 
> mixed participants.  ISTM there is nothing gained by this restriction, 
> and it means lots of extra packets.
[GH] There are a few but not so strong reasons for this restriction.

a) Use of CSRC: The same section (4.2.5) says that the CSRC should 
indicate the source of the primary. This makes it possible to implement 
a pseudo-multi-party awareness by the endpoint, e.g. color-marking text 
from different sources. Having multiple sources and multiple CSRC-list 
members would destroy that possibility. This is a weak argument, because 
if you bother to implement anything regarding multi-party RTT in an 
endpoint, it should be the full multi-party awareness.

b) We are using RFC 2198 redundancy, and RFC 2198 has a reminder about 
the use of CSRC in its section 4, leading to a conclusion to use only 
one source per packet.

c) If there is unrecoverable loss of text, it causes most confusion if 
it happens at a source switch. A correctly placed mark for possible text 
loss will then help the reader to get less confusion. If we separate the 
logical ending of one participant's entry in one packet, and the 
beginning of text from next participant, with its label, in another 
packet, it is less likely that the source switch gets completely 
invisible if unrecoverable loss appears than if the switch was embedded 
within one packet. Quite often the source switch will be caused by one 
participant ending its entry by a Line Separator that will be included 
in the packet. Next packet will then start with the label of next 
participant. Completely losing just one of these and getting it replaced 
by a mark for possible loss will still make it possible for the reader 
to understand that a source switch happened.

d) You say that it causes "lots of extra packets". But I cannot see 
that. The restriction only causes an extra packet when simultaneous 
typing has occurred. That is quite rare. And when it occurs, a source 
switch only happens when the current transmitting source has indicated a 
suitable place for source switch; a comma, an end of sentence, a new 
line or a pause. That causes the source switches to be at least seconds 
apart. Only short expressions while one party is typing like "yes" or 
"no" or "wow" or an emoji will cause more rapid source switching, and 
will still not cause many extra packets.

Conclusion: My reasons for having the restriction are weak, and I see 
your reason for deleting it to be weak. I suggest to keep it, but I am 
willing to accept another decision.

Thanks,

Gunnar

>
>
> Brian
>
>
>> On Nov 25, 2020, at 5:16 PM, Bernard Aboba <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix>
>>
>> * I object to advancement to Proposed Standard, due to Issues 
>> described below <Issue description or link>.

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 6 Dec 2020 10:56:27 +0100

Brian,

Thanks for review and proposals.

I am preparing modifications as commented below.

Den 2020-12-04 kl. 18:27, skrev Brian Rosen:
> possibly a normative change.  I would be fine with having these 
> comments addressed in whatever the next revision to the document is, 
> rather than hold up IETF last call. I support advancing this document 
> to Proposed Standard.
>
> 1. I don’t think it’s necessary to say "Regional regulatory 
> requirements specify provision of real-time text
>    in multi-party calls” in the abstract.  It’s true, but the IETF 
> usually doesn’t do things because governments make them a requirement. 
>  Instead, I might say something like “Use of RTT is increasing, and 
> specifically, use in emergency calls is increasing.  Emergency call 
> use requires multiparty mixing”.  I’d just delete the reference to 
> regulatory requirements in the Introduction section.
>
[GH] I wait with a response on this one.
>    in real-time and easily read.  It is also possible for the 
> presentation to indicate approximately when the text was created in 
> real time

[GH]Accepted.  I suggest the second sentence to be: " At the same time 
it is possible for a reading user to perceive approximately when the 
text was created in real time by the different parties."

>
> 3. In 1.1. this text appears: "and in most applications also more than 
> three parties in a call is rare”.  As anyone experiencing this past 
> year can attest, that is not true :). The first part of the sentence 
> is true, and I think this can just be deleted.
[GH] Accepted.
>
> 4. The heading "The presentation planned by the mixer for multi-party 
> unaware endpoints” is not great English.  Could be “Mixer provides 
> presentation of multiple parties”
[GH] I suggest "Mixer prepares presentation of text from multiple parties"
> explained in” for RFC3550?
[GH] Accepted
>
> 6. <not a request to change> I had to look up the definition of 
> “utterance” to see that in linguistics, it means “an uninterrupted 
> chain of spoken or written language”, so it’s correctly used here.
;-)
>
> 7. In this subsection (Intended use), would it be good to mention the 
> issue of backspace when dealing with multiple parties?  I always found 
> that the best example of why it’s hard to to this centrally.
[GH] Would it help by inserting this paragraph after the second 
paragraph in 1.3?
"        Users expect that the text they send is presented in real-time 
in a readable way to the other participants even if they send 
simultaneously with other users and even when they make brief edit 
operations of their text by backspacing and correcting their text. "
>
> 8. In 2.2 it says “does not itself implement any solution for 
> multi-party handling of real-time text.”  It’s actually that it 
> doesn’t meet this document's “multiparty-aware” specification: if you 
> don’t negotiate the use of the mechanism specified here, then you use 
> this multiparty unaware mechanism.  It could implement some other 
> mechanism but if the mixer didn’t support it, it wouldn’t work.

[GH] I suggest to change the beginning of 2.2 to:

" A method is also specified in this document for cases when the 
endpoint participating in a multi-party call does not itself implement 
the solution for multi-party handling of real-time text specified in 
section 3. The method requires the mixer to insert text dividers and 
readable
     labels and only send text from one source at a time until a 
suitable point appears for source change."

>  So “.. send the next packet”
[GH] Accepted
>
> 10. In 3.7 it says “New and redundant text from one source SHALL be 
> transmitted in the same packet”.  Is that explained in 4103?  It’s old 
> redundant text and new text.  Not new text and a redundant copy of the 
> new text.  Maybe could use a bit of explaining.
>
[GH] I suggest to start the section with: "New text and redundant copies 
of earlier text from one source SHALL be transmitted in the same packet"

> 11. Minor English issues in 3.8.  Say “Text received by a mixer from a 
[GH] Accepted
> 12. Minor English in 3.12.  Say “the participant whose text is included”
[GH] Accepted
>
> 13.  Think about expanding WHY you must consider integrity for RTCP 
> (3.18).  Also ".. considerations SHALL be considered" isn’t great 
> construction.

[GH] This sentence was added after a discussion related to emergency 
services. A thought was that a bridge within an emergency service 
network would be required to send quite anonymous NAME information about 
the calltakers to the user in emergency, while the bridge would send 
more detailed NAME fields to other emergency service agents. This sounds 
too application specific to explain here. But I tried to add some 
wording resulting in this text: Maybe it is too much?

"Integrity 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. Similar considerations 
SHOULD be taken as for other media."
>
> 14. 3.19.1, if the receiver is a mixer, then CC=0 doesn’t mean point 
> to point in the sense you intend here.  It’s text from a participant, 
> as opposed to text from a mixer, in a multiparty call.
>
[GH] Right. I see that the use of CC and the source indication needs a 
bit more clarification. In a couple of places it is said that the mixer 
shall create data and send it with its own SSRC as source. That is when 
sending the initial BOM to a participant.

Therefore, I propose to change 3.19.1 to

"3.19.1.  Acting on the source of the packet contents

    If the "CC" field value of a received packet is 1, it indicates that
    the text is conveyed from a source indicated in the single member in 
the CSRC-list, and the receiver MUST act on the source according to its 
role. If the CC value is 0, the source is indicated in the SSRC field."

and 3.3 change from:

"3.3.  Use of fields in the RTP packets

    The CC field SHALL show the number of members in the CSRC list, which
    SHALL be one (1) in transmissions from a mixer involved in a multi-
    party session, and otherwise 0.

    When transmitted from a mixer during a multi-party session, a CSRC
    list SHALL be included in the packet.  The single member in the CSRC-
    list SHALL contain the SSRC of the source of the T140blocks in the
    packet."

To

"3.3.  Use of fields in the RTP packets

    The CC field SHALL show the number of members in the CSRC list, which
    SHALL be one (1) in transmissions from a mixer when conveying text from
other sources in a multi-party session, and otherwise 0.

    When text is conveyed by a mixer during a multi-party session, a CSRC
    list SHALL be included in the packet.  The single member in the CSRC-
    list SHALL contain the SSRC of the source of the T140blocks in the
    packet."

> are, then consider deleting
[GH] Yes, they are. Deleted.
> 16. Minor English, say “SHALL be regarded as lost”
[GH] Accepted
>
> 17. In 3.19.4, you have a normative “a t140 block SHALL be created”, 
> but then later you say “Implementations MAY apply more refined 
> methods”.  Doesn’t that make that SHALL a SHOULD?  Also, minor 
> English, say something like “SHOULD prefer marking possible loss 
> rather than not marking when it is uncertain if there is loss”
[GH] Accepted as proposed.
> sentence.  One can be deleted.
[GH] If you mean that "RFC 8643 OSRTP [RFC8643]" should be "OSRTP 
[RFC8643]" it is accepted.
> 19. 3.23, minor English: say “Packet 103 is assumed to be lost due to 
[GH] Accepted
> 20. In 3.24 it says 'A value for "CPS" of 90 is the default for the 
> "text/t140" stream in the  "text/red" format when multi-party 
> real-time text is negotiated.’   Is that a restatement of what 4103 
> says, or a normative statement this document makes?  Please make it 
> more clear.
[GH] It is new normative here. I propose to change "is the default" to 
"SHALL be the default"
>
> 21. In 4.1 normative MUST/MAY/SHOULD is used to describe user 
> interface.  Is that appropriate? Same for 4.2

[GH] I think the normative wording is appropriate for 4. and 4.1. 
Normative wording is used wherer it is essential to treat incoming data 
in a specific way to not cause garbling or other confusion and thereby 
be able to fulfill the intentions of T.140 cited in the second paragraph 
of 4. Total freedom is left for the user interface in other aspects.

For 4.2 you may be right that many of the normative words could be 
changed to non-normative (except some related to the stream contents as 
you point out in #22). 4.2 is a best-effort procedure, and other 
procedures may be specified.  As a start, I suggest to change the second 
SHALL of 4.2.1 (about the time) to SHOULD.

With that change, all normatives about the presentation procedure are 
SHOULDs. Together they form a recommended procedure. Would it be better 
to change all these to lower case "should" and rely on the introduction 
in 4.2 to recommend to follow the procedure when the capability 
negotiation fails?

>
> 22.  On the other hand, in 4.2.1, there is a lower case “.. BOM 
> characters … shall be deleted”.  That might want to be SHALL.
[GH]Accepted.

>
> 23. In the beginning of 4.2.2, is the “SHOULD be applied for each 
> recipient of multi-part text” actually “...non multi-party aware 
> recipient”?
[GH] Yes, I suggest to use "each multi-party unaware recipient" instead 
because that is used in other places.
> and it means lots of extra packets.

[GH] Handled in another response.

With that, I view #1 as not handled yet, and #21 needing another 
consideration for the SHOULDs in 4.2.x

Thanks

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 7 Dec 2020 15:55:03 +0100

Bernard, thanks for comments,

Den 2020-12-04 kl. 23:54, skrev Bernard Aboba:
> Here are my comments.
>
> Overall, I would suggest placing terminology and some overview 
> material earlier in the document.  Also,
[GH] Done and SFU briefly included as a possible option. I may need to 
check consistency after that.

111111111111111111111111111111111111111111111111111111111111

[GH] Accepted

222222222222222222222222222222222222222222222222222222222222222

> can also be construed as "source switching".

[GH] yes, "source switching" is used in a number of places to mean how 
rapidly the mixer can send on a packet received from one source when it 
is currently sending packets for another source. Various transmission 
mechanisms result in different time delay. RFC 4103 has requirements 
intended to limit the load on network and devices, by requiring that the 
packet interval should not be less than 300 ms. Three packets must also 
be sent with the last text from one source before a packet from another 
source can be sent. So, it would take 900 ms from receiving new text 
from another than the current source before it can be sent. The current 
draft reduces that time to 100 ms.

The 100 ms minimum packet interval is set in order to give a reasonable 
balance between  load and performance. Do you find that to be a suitable 
value? If it is, also an SFU would be specified to obey that limitation.

I propose to modify wording where "source switching" is used.

In the abstract,  I suggest changing

"but the mixer source switching performance is limited when using the 
default transmission ..."

to

"but the performance of the mixer when giving turns for the different 
sources to transmit is limited when using the default transmission..."

In next paragraph in the abstract, I suggest to change from

" enables
    source identification and source switching."

to

"enables source identification and rapidly interleaved transmission of 
text from different sources."

In last paragraph in 1., I suggest to change from

"rules for source indications and source switching."

to

"rules for source indications and interleaving of text from different 
sources."

In 1.1 I suggest to change from

"Source switching"

to

"Transmission of packets with text from different sources"

In 4.2, I suggest to change from

"the time for source switching is depending on"

to

"the time for switching from transmission of text from one source to 
transmission of text from another source is depending on"

By that all occurrencies of "source switching" are replaced.

3333333333333333333333333333333333333333333333333333

> mean that the endpoint can distinguish between sources based on SSRC, or

[GH] That first sentence does not require any specific technology. Next 
one gives a hint of the technology used in this draft. We need the term, 
so I will check that it is defined, but I suggest to replace it here, from

  "multi-party-aware participant endpoints."

to

"participant endpoints capable of providing an efficient presentation or 
other treatment of a multi-party real-time text session"

444444444444444444444444444444444444444444444444444444444444444

>    The specified mechanism build on the standard use of the CSRC list in

[GH]Accepted

55555555555555555555555555555555555555555555555555555555555555

> [BA] "A specifications" -> "Specification"
[GH]Accepted

6666666666666666666666666666666666666666666666666666666

> [BA] A better citation format is "RTP Payload for Text Conversation" 
[GH]Accepted

777777777777777777777777777777777777777777777777777777777

>    Regional regulatory requirements specify provision of real-time text

[GH] Brian asked me to delete the reference to regulatory requirements. 
I am checking with the origin of the sentence if I should accept to 
delete it before I create the references.

Standards corresponding to the references are e.g.

ETSI EN 301 549

and NENA STA 010

If you really want the references to the regulatory requirements behind 
these standards, I would need to reference the European Accessibility 
Act and the European Public Procurement directive and some more, but I 
think that is very unusual in IETF documents and should not be done.

8888888888888888888888888888888888888888888888888

> [BA] "experienced" -> "experienced,"

[GH] I suggest instead to change to  "experienced to be disturbing the 
real-time experience of the receiving users."
btw is "of" good, or should it be "for" ?

999999999999999999999999999999999999999999999999999999

> SSRC within the CSRC field", correct?

[GH]Yes, but I wanted to state the functional requirements first here 
before talking about how it is done.  But I see that the wording is a 
bit influenced by earlier versions of the draft. The "therefore" is 
confusing. I suggest changing from

"Real-time text mixers for multi-party sessions therefore need to insert the
source of each transmitted group of text from a conference participant 
so that the text can be transmitted interleaved with text groups from 
different sources .."

to

"Real-time text mixers for multi-party sessions need to include the
source with each transmitted group of text from a conference participant 
so that the text can be transmitted interleaved with text groups from 
different sources..."

1010101010101010101010101010101010101010101010

> [BA] By "implementations", you mean "conferencing server 
> implementations", correct?

[GH]No, I mean endpoint implementations.  The mixer and the endpoint 
both need to use the specification in the draft.

I suggest to change to:

"There are existing implementations of RFC 4103 in endpoints without the 
updates"

11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11

> CSRCs also qualify? It would perhaps help to have the terminology 
> section moved
> up prior to

[GH]At this point it is still a functional requirement. The selected 
solution comes in next section.

To be more clear, I suggest to change

from:

"   A negotiation mechanism is therefore needed for verification if the
    parties are able to handle a multi-party coded stream and agreeing on
    using that method."

to:

"A negotiation mechanism is therefore needed for verification if the 
parties are able to handle a common method for multi-party transmission 
and agreeing on using that method."

1212121212121212121212121212121212121212121212121212

> [BA] A clarification of the behavior of "multi-party unaware 
> endpoints" would

[GH] Yes, on presentation level they are not specified to distinguish 
between SSRC or CSRC values.  I suggest this explanation:

"Multi-party unaware endpoints may present all received text as if it 
came from the same source regardless of any accompanying source 
indication coded in fields in the packet.  The fall-back method is 
called the mixing procedure for multi-party unaware endpoints."

131313131313131313131313131313131313131313131313

> [BA] I think you need to insert the terminology section before this

[GH]Accepted

1414141414141414141414141414141414141414141

> described in RFC 7667 Section 3.5.

[GH] Yes, RFC 7667 is referenced in many places in 
draft-hellstrom-avtcore-multi-party-rtt-solutions when explaining 
different potential solutions. I include a reference also in this draft.

Proposed changed section in "selected solutions...."

"From some points of view, use of multiple RTP streams, one for each 
source, sent in the same RTP session would be efficient, and would use 
exactly the same packet format as [RFC4103] and the same payload type.
    A couple of relevant scenarios using multiple RTP-streams are 
specified in "RTP Topologies" [RFC7667]. One possibility is the 
RTP-translator model specified in RFC 7667 section 3.5 with the benefit 
of easily detected which source had unrecoverable loss. Another is the 
Selective Forwarding Middlebox topology specified in RFC 7667 section 
3.7 that could enable end to end encryption."

the conclusion in that section is also suggested to be changed to:

"This fact made this solution only briefly mentioned as an option in 
this document."

1515151515151515151515151515151515151515151515151515

> unit has access to the payload (e.g. the payload is not E2E encrypted).

[GH] It is urgent to implement the multi-party aware method. In earlier 
versions of the draft a method with one RTP stream per source has been 
specified, but investigations about the possibility to implement it has 
shown that a large part of the installed base of endpoints would require 
massive work to upgrade the RTP implementations to be able to support 
it. It is sad, because with the multi-stream solution the possibility to 
detect from which source loss of text occurred is better and as you 
point out, there may be a possibility to use end-to-end encryption. 
Another problem with the multi-stream solution is that it is not evident 
how it would be signaled with SDP in a simple way. The examples I have 
seen have used one m-section per possible stream. This is very different 
from the RTP-mixer solution, where one m-section is sufficient and new 
participants announced just by a conference notification.

However, it is important that RTT makes use of similar technologies as 
the other media, so if SFU is becoming popular with E2E encryption, it 
would be good to have specified how RTT can be implemented in that 
environment.

Do you know if SFU can be used in the SIP centralized conference model 
RFC 4353 et al? How would SDP look like for that case?

Since the discussions during the year have resulted in that we need the 
RTP-mixer based solution, I suggest that we continue on that track with 
the current draft, but just take a moment to consider if an SFU solution 
would need another negotiation by an SDP attribute. If so, we can change 
the SDP-attribute from a single one without values to an attribute with 
two values.

But maybe an SFU-capable endpoint can be recognized by some other 
characteristics. Will the middlebox make a re-Invite per added stream, 
and notice that the SFU-capable endpoint will answer positively on the 
addition of the stream? If so, no more negotiation is needed.

I think the abstract is a good place to tell that we concentrate on the 
RTP-mixer solution.

I suggest to add this in the abstract:

"Solutions using multiple RTP streams in the same RTP session were 
considered, as they could have some benefits over the RTP-mixer model, 
but the possibility to implement the solution in a wide range of 
existing RTP implementations made the RTP-mixer model be selected."

161616161616161616161616161616161616161616161616161616161

[GH] Accepted

17171717171717171717171717171717171717171717171717171717

> [BA] "Nomenclature" -> "Terminology"?

[GH] Accepted
181818181818181818181818181818181818181818181818181818181
> 19191919191919191919191919191919191919191919191

[GH]Accepted

20202020202020202020202020202020202020202020202020

> it should be placed just after terminology (suggested to be moved to 
> 1.1) and before the material currently in Section 1.1?

[GH] I think it has a good logical place where it is. The solutions are 
briefly mentioned in the abstract and the introduction, but here starts 
the real specification.

Possibly the "selected solutions and considered alternatives" could be 
shortened to get more rapidly to the technical core of the document.

No action at the moment.

21212121212121212121212121212121212121212121212

> [BA] Might be useful to explicitly state what happens if both offer 
> and answer don't include "a=rtt-mixer" and also

[GH] I have seen an example of sdp exchange for SFU in 3GPP TS 26.114 
Annex T. Do you regard that typical, with multiple m-sections for the 
number of streams to support?

This might need more discussion for how to handle the SFU option in 
general, but I propose to include the following paragraphs in 3.2

   "      A party which has not successfully completed the negotiation 
of the "rtt-mixer" sdp media attribute MUST NOT transmit packets 
interleaved from different sources in the same RTP stream as specified 
in section 3. If the party is a mixer and did declare the "rtt-mixer" 
sdp media attribute, it SHOULD perform the procedure for multi-party 
unaware endpoints. If the party is not a mixer, it SHOULD transmit 
according to [RFC4103].

       Capability for another real-time text multi-party method, e.g. 
based on the Selective Forwarding RTP topology specified in [RFC7667] 
section 3.7 MAY be signaled in SDP simultaneously with the "rtt-mixer" 
sdp media attribute. The answering party SHOULD select which method to 
use and answer accordingly.
       "

2222222222222222222222222222222222222222222222222222222222222222222222222222

> [BA] Presumably "party" here only refers to the conferencing server, not

[GH] No, it is intended to mean for both. It says "If acting as a mixer" 
or so before all statements.

2323232323232323232323232323232323232323232323232323232323

> [BA] "not performing as a mixer MUST not" -> "not acting as a mixer 
> MUST NOT"
>
[GH]Accepted

2424242424242424242424242424242424244242424424244242

> note that RFC 7675 consent checks can also help here.

[GH] It is not meant to be advocating an alternative to RFC 6263. Do you 
suggest a change to "SHOULD use the recommendation from RFC 6263"? But 
at the same time you propose mentioning the RFC 7675 consent checks.

I suggest to change the last sentence to "It is RECOMMENDED to use the 
keep-alive solution from [RFC6263].", but I can accept proposals for how 
to also mention the consent check alternative.

(Some RTT implementations use transmission of BOM characters as 
keep-alive but that is not recommended, because it can cause false 
character loss indications. The initial transmission of BOM mentioned in 
3.4 is however important for opening RTP and NAT paths.)

252525252525252525252525252525252525252525525252525525525252

> [BA] "received to" -> "sent to"
[GH] Already changed to "received by" as proposed by Brian
26262626262626262626262626262626262626262626626262662
> security is also possible).

[GH] I suggest to change the beginning of 3.21 to:

" Security SHOULD be applied by use of SIP over TLS by default according 
to "[RFC5630] section 3.1.3 on session control level and by default 
using DTLS-SRTP [RFC5764] on media level. "

2828282828282828282828282828282828282828282828282828

> without "a=rtt-mixer", even if the Offer indicates the ability to 
> support multiple streams per session?

[GH] I think we need to discuss the inclusion of the SFU based method 
more. How well shall we describe that method?  3GPP TS 26.114 Annex T 
seems to have good examples of sdp for SFU negotiation. Do you regard 
these example to be typical for SFU negotiation? How is the shift of 
source to use a stream in the SFU usually signaled?

As a start anyway, I suggest to include the following at the end of the 
first paragraph in 3.22.

"The examples relate to the single RTP stream mixing for multi-party 
aware endpoints and for multi-party unaware endpoints.

Multi-party RTT can also be provided through an Selective Forwarding 
Unit (SFU). In that case, the offer will have multiple m-sections for 
RTT, and an answer acknowledging the use of an SFU would accept a number 
of m-sections for RTT. The offer may contain also the "rtt-mixer" sdp 
media attribute for the main RTT media when the offeror has capability 
for both multi-party methods, while an answer, selecting to use SFU MUST 
not include the "rtt-mixer" sdp media attribute. "

292929292929292929292929292929292929292929292929292929

Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 7 Dec 2020 20:34:52 +0100

I had one comment from both of you left to deal with.

This is Brian's version in #1.

1. I don’t think it’s necessary to say "Regional regulatory requirements 
specify provision of real-time text
    in multi-party calls” in the abstract.  It’s true, but the IETF 
usually doesn’t do things because governments make them a requirement. 
  Instead, I might say something like “Use of RTT is increasing, and 
specifically, use in emergency calls is increasing.  Emergency call use 
requires multiparty mixing”.  I’d just delete the reference to 
regulatory requirements in the Introduction section.

---------------------------------------------------
I have checked, and I accept Brian's proposal as it is.

Regards,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 8 Dec 2020 00:03:03 +0100

Bernard, I indicated that I would like to discuss the SFU.

You said: "Also, some clarifications of desired behavior by SFUs might 
be helpful." and mentioned SFU in a qouple of other comments.

I like the idea to have a possibility to use E2E encryption. I also 
imagined that with separate RTP streams it would be possible to better 
detect if unrecoverable loss of text appears or not after some lost 
packets. But I get unsure if that is possible when I read section 3.7 of 
RFC 7667.

I need to understand the SFU description in RFC 7667 better to judge if 
it really can carry RFC 2198 coded text with maintained possibility to 
detect unrecoverable loss.

Before IETF 108, the draft had both an RTP multi-stream method and an 
RTP-single stream mixer method ( and also the method for multi-party 
unaware endpoints ). Then we decided to move on without the multi-stream 
method. It is a bit inconsistent to bring it in again, but I can see the 
possibility to arrange for E2E encryption to be a good reason. The 
earlier multi-stream method was based on the RTP-translator and required 
the mixer to recover from packet loss and insertion of marks for 
unrecoverable loss, and therefore could not be used for E2E encryption. 
Therefore it might be valid to rethink the earlier decision.

Questions:

1. Is 3GPP TS 26.114 Annex T an example of sdp for the kind of SFU 
described in RFC 7667 section 3.7, with one media section per stream in 
a lower number of streams than participants? If not, how does a normal 
sdp look for an SFU?

2. RFC 7667 section 3.7 seems to tell that the sequence number is 
regenerated in sequence by the middlebox. Is that right? That would make 
it not possible to detect if total loss of text occurred. Recovery can 
be done based on timestamp analysis, but not detection of unrecoverable 
loss.

3. How is the source conveyed? There is apparently an SSRC to SSRC 
mapping taking place. Is there a lower number of SSRCs used in 
transmission from the middlebox than the total number of participants? 
If so, how is switch of source indicated? By RTCP?

If we find that it is likely possible to use the SFU, then I would 
anyway think that we just include general hints of its use in this 
draft, and let further work detail it. Would that be an acceptable 
conclusion?

Regards

Gunnar

-- 

Gunnar Hellström
GHAccess

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Dec 2020 11:10:11 -0800

Gunnar asked:

"Questions:

[BA] Annex T appears to use payload multiplexing (one payload type per
stream) for simulcast, which is not commonly deployed.
It is more common to use SSRC multiplexing (one SSRC per stream), all on
the same payload type.  Here are examples of what simulcast SDP looks like
in various browsers:
A playground for Simulcast without an SFU - webrtcHacks
<https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/>

[BA] The sequence number needs to be regenerated when an SFU switches
between simulcast streams sent by a participant, sending only a single
stream onward to the viewer.  This is needed since each simulcast stream
has its own sequence number space, and endpoints typically do not support
receiving simulcast.

However an RTT sender would not send simulcast (e.g. multiple versions of
the same text stream).  So the SFU would potentially forward only a single
stream per participant, with no CSRCs. The question is whether a
"multi-party aware endpoint" would be prepared to receive multiple SSRCs
(and no CSRCs), with each SSRC representing a single RTT source.

[BA] I am suggesting a scenario where there would be one SSRC per source.
The SFU could perhaps replace the SSRC received from a participant with an
SSRC of its own, but each text stream would have a unique SSRC up to the
maximum participant limit.

[BA] My question was whether a "multi-party aware" endpoint could support
an SFU (SSRCs but no CSRCs), and how the negotiation would work (whether it
was supported or not).  If it can work and you can indicate how it would be
done (or how it would fail if it cannot be done), that would be fine with
me.
"

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 8 Dec 2020 23:45:39 +0100

Bernard, some proposed conclusions below:

Den 2020-12-08 kl. 20:10, skrev Bernard Aboba:
> It is more common to use SSRC multiplexing (one SSRC per stream), all 
> on the same payload type.  Here are examples of what simulcast SDP 
> looks like in various browsers:
[GH] Thanks. That example was with Bundle and WbRTC. If that is the 
environment you imagine, we will not be allowed to use RTP transport for 
RTT. Instead it is the data channel usage for RTT in RFC 8865. Only 
audio and video are using RTP.

But I assume that there could be use of the SFU technology also for 
traditional SIP. What we need to consider for the current draft is then 
if an sdp indicating capability for use of an SFU or some other form of 
multi-stream RTP will have something characteristic for that capability. 
E.g. an m-section for each stream.

I think it is quite likely that it must be visible in the sdp that a 
party has multi-stream RTP capability.

Then the "rtt-mix" attribute is sufficient to indicate capability for 
the RTP-mixer based multi-party solution, and we only need to tell that 
other solutions may be implemented.

I need to check wording so that the draft does not preclude other 
multi-party RTP based RTT solutions.

> stream onward to the viewer.  This is needed since each simulcast 
> stream has its own sequence number space, and endpoints typically do 
> not support receiving simulcast.

There are regulatory requirements to detect and mark cases of suspected 
text loss. So, if there is packet loss from a participant to the 
middlebox, that sequence gap must not be just ignored and resulting in 
an unbroken sequence number series after the SFU. Can the sequence 
number from the source be copied to the transmission from the SFU?

Does not video also have that need?

>
> However an RTT sender would not send simulcast (e.g. multiple versions 
> of the same text stream).  So the SFU would potentially forward only a 
> single stream per participant, with no CSRCs. The question is whether 
> a "multi-party aware endpoint" would be prepared to receive multiple 
> SSRCs (and no CSRCs), with each SSRC representing a single RTT source.
In order to have interoperability, the "rtt-mix" attribute must only 
mean the RTP-mixer based solution. Both mixers and endpoints could also 
have multi-stream capability, but the intention to open a multiparty 
session with multi-stream need to have its own characteristics.
> [BA] I am suggesting a scenario where there would be one SSRC per 
> source.  The SFU could perhaps replace the SSRC received from a 
> participant with an SSRC of its own, but each text stream would have a 
> unique SSRC up to the maximum participant limit.
>
RTT is specific in that no data flows when the user does not send any 
information. In the other media there is always contents.
> [BA] My question was whether a "multi-party aware" endpoint could 
> support an SFU (SSRCs but no CSRCs), and how the negotiation would 
> work (whether it was supported or not).  If it can work and you can 
> indicate how it would be done (or how it would fail if it cannot be 
> done), that would be fine with me.
> "

I need another example of sdp for an SFU session establishment in a 
traditional SIP environment to be able to answer.

Thanks,

Gunnar

>
> On Mon, Dec 7, 2020 at 3:03 PM Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 9 Dec 2020 12:39:05 +0100

On Wed, 25 Nov 2020 14:16:43 -0800

> described below <Issue description or link>.

Hi all,

apologies for this late reply, hopefully I'm still in time. I'll just
add a couple of considerations on section 6.2, which addresses
gatewaying to WebRTC, since I have an open source prototype
implementation of 1-1 WebRTC-to/from-SIP gatewaying already, which I'd
like to extend to support multi-party as well sooner or later.

The text is in general relatively clear to me, as are the assumptions on
how new labels will be used on the WebRTC side for new joins, but there
are a couple of areas where I believe there still is some ambiguity.

Forst of all, it's not clear whether new participants should trigger a
renegotiation, as the draft simply states:

	When a new participant has entered the session with RTP
	transport of rtt, a new t140 channel SHOULD be established to
	WebRTC users with the label parameter composed from the NAME
	field in RTCP on the RTP side.

In the current specification, data channel IDs/labels are negotiated in
the SDP in advance, via a dcmap attribute: does this mean new
participants should be advertised by new dcmap attributes as well? Or
should implementations simply be prepared to expect unadvertised data
channels opening, and then match them to specific participants out of
band? The former seems a bit overkill, considering data channels can be
opened at any time with no signalling needed, but if the latter is the
case, it seems to question why we'd need the dcmap attribute for the
first negotiation as well.

Another issue I don't see addressed in the draft is what to do when a
participant leaves instead: should the related data channel ID be
closed? I guess the answer is yes, here, but in case, should this be
addressed with a new offer/answer exchange, if adding users does?

Thanks,
Lorenzo

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 9 Dec 2020 16:02:44 +0100

Lorenzo,

Thanks for looking into the WbRTC gatewaying side of this topic.

See some answers below.

Den 2020-12-09 kl. 12:39, skrev Lorenzo Miniero:
> In the current specification,
[GH] Do you mean RFC-to-be 8865 ?
>   data channel IDs/labels are negotiated in

[GH] RFC-to-be 8865, section 1 says:

"

While this document defines how to establish a
    T.140 data channel using the SDP-based external negotiation method
    [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway
    considerations defined in Section 3, Section 5 and Section 6 of this
    document can also be applied when a T.140 data channel is established
    using another mechanism (e.g., the mechanism defined in
    [I-D.ietf-rtcweb-data-protocol]).  Section 5 of
    [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the
    SDP dcmap attribute parameters and the protocol parameters used in
    [I-D.ietf-rtcweb-data-protocol].

"

So, it should at least be possible to establish new T.140 channels with 
all required parameters without a renegotiation. Also the label can be 
established that way. The side taking the initiative to establish a 
channel would know best what label to assign to it.

This behavior would have similarities to introducing new participants in 
a conference on the traditional centralized SIP conference. They are 
just announced by conference notifications and then their SSRC is 
starting to appear in CSRC and RTCPs.

On the other hand, even if it is possible and mentioned in RFC-to-be 
8865, I do not know if it regarded to be good behavior of an entity to 
add channels in that way without renegotiation.

> addressed with a new offer/answer exchange, if adding users does?

[GH] Good point. I can insert a sentence about closing a channel in any 
way the application wants as a consequence of the cited sentences above 
from section 1 in RFC-to-be 8865.

Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 9 Dec 2020 16:40:09 +0100

Lorentzo, I suggest to add the following paragraphs last in section 6.2

"
   When a participant on the RTP side disappears, the corresponding 
T.140 data channel(s) SHOULD be closed.

   When a WebRTC user of T.140 data channels disconnects from the mixer, 
the corresponding RTP streams or sources in an RTP-mixed stream SHOULD 
be closed.

   T.140 data channels MAY be opened and closed by negotiation or 
renegotiation of the session or by any other valid means as specified in 
section 1 of ["I-D.ietf-mmusic-t140-usage-data-channel"].

Regards

Gunnar

Den 2020-12-09 kl. 16:02, skrev Gunnar Hellström:
>> Bernard Aboba<[email-masked]>  wrote:
>>
> So, it should at least be possible to establish new T.140 channels 
> with all required parameters without a renegotiation. Also the label 
> can be established that way. The side taking the initiative to 
> establish a channel would know best what label to assign to it.
>
> This behavior would have similarities to introducing new participants 
> in a conference on the traditional centralized SIP conference. They 
> are just announced by conference notifications and then their SSRC is 
> [GH] Good point. I can insert a sentence about closing a channel in 
> any way the application wants as a consequence of the cited sentences 
> above from section 1 in RFC-to-be 8865.
>
> Thanks,
>
> Gunnar
>
>> Thanks,
>> Lorenzo
>>
> -- 
> Gunnar Hellström
> GHAccess

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 9 Dec 2020 16:45:20 +0100

On Wed, 9 Dec 2020 16:40:09 +0100
Gunnar Hellström <[email-masked]> wrote:

>    When a WebRTC user of T.140 data channels disconnects from the
> mixer, the corresponding RTP streams or sources in an RTP-mixed
> stream SHOULD be closed.
> 
> 
> renegotiation of the session or by any other valid means as specified
> in section 1 of ["I-D.ietf-mmusic-t140-usage-data-channel"].
> 

Hi Gunnar,

the proposed text does indeed help making it much clearer, thanks for
addressing the feedback!

Lorenzo

> >> apologies for this late reply, hopefully I'm still in time. I'll
> >> just add a couple of considerations on section 6.2, which addresses
> >> implementation of 1-1 WebRTC-to/from-SIP gatewaying already, which
> >> I'd like to extend to support multi-party as well sooner or later.
> >>
> >> The text is in general relatively clear to me, as are the
> >> assumptions on how new labels will be used on the WebRTC side for
> >> new joins, but there are a couple of areas where I believe there
> >> still is some ambiguity.
> >>
> >> Forst of all, it's not clear whether new participants should
> >> trigger a renegotiation, as the draft simply states:
> >>
> >> 	transport of rtt, a new t140 channel SHOULD be established
> >> to WebRTC users with the label parameter composed from the NAME
> >> participants should be advertised by new dcmap attributes as well?
> >> Or should implementations simply be prepared to expect
> >> unadvertised data channels opening, and then match them to
> >> specific participants out of band? The former seems a bit
> >> overkill, considering data channels can be opened at any time with
> >> no signalling needed, but if the latter is the case, it seems to
> >> question why we'd need the dcmap attribute for the first
> >> negotiation as well.  
> >
> >     T.140 data channel using the SDP-based external negotiation
> > method [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and
> > gateway considerations defined in Section 3, Section 5 and Section
> > 6 of this document can also be applied when a T.140 data channel is
> > established using another mechanism (e.g., the mechanism defined in
> >     [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping
> > between the SDP dcmap attribute parameters and the protocol
> > parameters used in [I-D.ietf-rtcweb-data-protocol].
> >
> > "
> >
> > with all required parameters without a renegotiation. Also the
> > label can be established that way. The side taking the initiative
> > to establish a channel would know best what label to assign to it.
> >
> > This behavior would have similarities to introducing new
> > participants in a conference on the traditional centralized SIP
> > conference. They are just announced by conference notifications and
> > then their SSRC is starting to appear in CSRC and RTCPs.
> >
> > On the other hand, even if it is possible and mentioned in
> > RFC-to-be 8865, I do not know if it regarded to be good behavior of
> > an entity to add channels in that way without renegotiation.
> >  
> >> Another issue I don't see addressed in the draft is what to do
> >> when a participant leaves instead: should the related data channel
> >> ID be closed? I guess the answer is yes, here, but in case, should
> >> this be addressed with a new offer/answer exchange, if adding
> >> users does?  
> >
> > any way the application wants as a consequence of the cited
> > sentences above from section 1 in RFC-to-be 8865.
> >
> > Thanks,
> >
> > Gunnar
> >  
> >> Thanks,
> >> Lorenzo
> >>  
> > -- 
> > Gunnar Hellström
> > GHAccess

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 9 Dec 2020 20:48:13 +0100

Bernard,

I am editing the draft to include a specification of use of multiple RTP 
streams in one RTP session to each participant. There seems to be so 
many ways to negotiate and use such topology, so I do not think I should 
dictate to use one specific. Therefore I suggest that the sections about 
that topology is made general and need exact specification at 
implementation time.

The idea with the other methods (the RTP-mixer method and the method for 
multi-party unaware endpoints) are intended to be sufficiently specified 
to result in interoperability, e.g. between emergency services and 
mobile services.

I do not see the same possibility for the multi-stream method. It is 
likely that RTT will be included in an environment where the other media 
and the application calls for use of specific RTP topologies and 
specific ways to negotiate the use of it. Therefore I intend to write a 
short description with  general statements and references to which 
considerations from the RTP-mixer method should be valid also for the 
RTP multi-stream methods.

I intend to also check and adjust the use of terms as "multi-party 
aware" to make clear when it means one or both multi-party aware methods.

A couple of further notes inline. I got some help to understand more;

Den 2020-12-08 kl. 23:45, skrev Gunnar Hellström:
>> [BA] Annex T appears to use payload multiplexing (one payload type 
>> per stream) for simulcast, which is not commonly deployed.
> environment you imagine, we will not be allowed to use RTP transport 
> for RTT. Instead it is the data channel usage for RTT in RFC 8865. 
> Only audio and video are using RTP.
>
> traditional SIP. What we need to consider for the current draft is 
> then if an sdp indicating capability for use of an SFU or some other 
> form of multi-stream RTP will have something characteristic for that 
> capability. E.g. an m-section for each stream.
>
> the RTP-mixer based multi-party solution, and we only need to tell 
> that other solutions may be implemented.
>
[GH]I will just assume that it is visible in the sdp that a multi-party 
session with RTP multi-stream topology is offered, or a capability to 
use it. And that a party who is not capable of that method can indicate 
that fact in an offer or answer. I will not say how.
>> between simulcast streams sent by a participant, sending only a 
>> single stream onward to the viewer.  This is needed since each 
>> simulcast stream has its own sequence number space, and endpoints 
>> typically do not support receiving simulcast.
>
> There are regulatory requirements to detect and mark cases of 
> suspected text loss. So, if there is packet loss from a participant to 
> the middlebox, that sequence gap must not be just ignored and 
> resulting in an unbroken sequence number series after the SFU. Can the 
> sequence number from the source be copied to the transmission from the 
> SFU?
>
[GH]During active transmission from one source, the sequence number 
needs to step up at the same rate as the sequence numbers of incoming 
packets, so that gaps from the leg between the transmitter to the 
middlebox can be revealed and acted on by the receiving party. So, the 
offset adjustment is only intended to make the sequence look consequtive 
even if there was a pause in transmission of a source. Then it works for 
total loss detection for RTT.
>
>>
>> However an RTT sender would not send simulcast (e.g. multiple 
>> versions of the same text stream).  So the SFU would potentially 
>> forward only a single stream per participant, with no CSRCs. The 
>> question is whether a "multi-party aware endpoint" would be prepared 
>> to receive multiple SSRCs (and no CSRCs), with each SSRC representing 
>> a single RTT source.
> mean the RTP-mixer based solution. Both mixers and endpoints could 
> also have multi-stream capability, but the intention to open a 
> multiparty session with multi-stream need to have its own characteristics.
[GH]I will differentiate the terms. Most likely so that multi-party 
aware means any of the two methods RTP-mixer and multi-stream RTP. And 
then specific wording for each method when there is talk about only one 
method.
>> participant with an SSRC of its own, but each text stream would have 
>> a unique SSRC up to the maximum participant limit.
[GH]But the mapping between NAME and SSRC is lost when RTCP SDES is just 
sent along with replaced SSRC.  But I assume that there are methods to 
sort that out by some signaling that I dont know. So since I will not be 
specific I will not bother about such detail.
> information. In the other media there is always contents. 
[GH] So in a way it can be said to be "SFU by nature".   I might mention 
that. It eases switching. In the normal case no switching will be 
needed. All simultaneous senders can likely always be allowed to 
transmit on to the receivers.
>> draft, and let further work detail it. Would that be an acceptable
[GH]I am continuing on that line.
> traditional SIP environment to be able to answer.
[GH] I changed my mind. My general approach does not need any more sdp 
examples.
Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 10 Dec 2020 17:49:17 +0100

After looking a bit more on the multi-stream issue, I want to reduce the 
ambition I announced below.

We should not put too many varied methods in one draft. It will be too 
complicated to require or state compliance to them then.

So, I want to back off to mention the possible benefits of multi-stream 
RTP and SFU. I want to indicate that it would be possible to negotiate 
between the specified RTP-mixer method and other multi-party aware 
methods, but say that it is for further study to specify any such method 
in more detail.

This conclusion also matches the need from referencing from NENA 
specifications.

/Gunnar

Den 2020-12-09 kl. 20:48, skrev Gunnar Hellström:
>
> Bernard,
>
> I am editing the draft to include a specification of use of multiple 
> RTP streams in one RTP session to each participant. There seems to be 
> so many ways to negotiate and use such topology, so I do not think I 
> should dictate to use one specific. Therefore I suggest that the 
> sections about that topology is made general and need exact 
> specification at implementation time.
>
> The idea with the other methods (the RTP-mixer method and the method 
> for multi-party unaware endpoints) are intended to be sufficiently 
> specified to result in interoperability, e.g. between emergency 
> services and mobile services.
>
> likely that RTT will be included in an environment where the other 
> media and the application calls for use of specific RTP topologies and 
> specific ways to negotiate the use of it. Therefore I intend to write 
> a short description with  general statements and references to which 
>>> It is more common to use SSRC multiplexing (one SSRC per stream), 
>>> all on the same payload type.  Here are examples of what simulcast 
>>> SDP looks like in various browsers:
> [GH]I will just assume that it is visible in the sdp that a 
> multi-party session with RTP multi-stream topology is offered, or a 
> capability to use it. And that a party who is not capable of that 
> method can indicate that fact in an offer or answer. I will not say how.
>>
>>>
>>>
>>> [BA] The sequence number needs to be regenerated when an SFU 
>>> switches between simulcast streams sent by a participant, sending 
>>> only a single stream onward to the viewer.  This is needed since 
>>> each simulcast stream has its own sequence number space, and 
>>> endpoints typically do not support receiving simulcast.
>>
>> suspected text loss. So, if there is packet loss from a participant 
>> to the middlebox, that sequence gap must not be just ignored and 
>> resulting in an unbroken sequence number series after the SFU. Can 
>> the sequence number from the source be copied to the transmission 
>> from the SFU?
>>
> offset adjustment is only intended to make the sequence look 
> consequtive even if there was a pause in transmission of a source. 
> Then it works for total loss detection for RTT.
>>
>>>
>>> to receive multiple SSRCs (and no CSRCs), with each SSRC 
>>> representing a single RTT source.
> then specific wording for each method when there is talk about only 
> one method.
>>>
> [GH]But the mapping between NAME and SSRC is lost when RTCP SDES is 
> just sent along with replaced SSRC.  But I assume that there are 
> methods to sort that out by some signaling that I dont know. So since 
> I will not be specific I will not bother about such detail.
>>>
>>>
> [GH] So in a way it can be said to be "SFU by nature".   I might 
> mention that. It eases switching. In the normal case no switching will 
> be needed. All simultaneous senders can likely always be allowed to

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 11 Dec 2020 10:54:25 +0100

Bernard,

I have prepared modifications to satisfy your comments about Keep-alive 
and SFU.

For keep-alive, section 3.3 is proposed to be:
"3.3.  Keep-alive

    After that, the transmitter SHALL send keep-alive traffic to the
    receiver(s) at regular intervals when no other traffic has occurred
    during that interval, if that is decided for the actual connection.
    It is RECOMMENDED to use the keep-alive solution from [RFC6263].  The
    consent check of [RFC7675] is a possible alternative if it is used
    anyway for other reasons."

For SFU, I propose to have the section about considered solutions in 
section 1.2 on SFU to be:

"

    Multiple RTP streams, one per participant.
       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
       multiple RTP streams, one for each source, sent in the same RTP
       session would be efficient, and would use exactly the same packet
       format as [RFC4103] and the same payload type.  A couple of
       relevant scenarios using multiple RTP-streams are specified in
       "RTP Topologies" [RFC7667].  One possibility of special interest
       is the Selective Forwarding Middlebox (SFM) topology specified 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
       when the users actually transmit information.  Thus an SFM
       solution would not need to exclude any party from transmission
       under normal conditions.  In order to allow the mixer to convey
       the packets with the payload preserved and encrypted, an SFM
       solution would need to act on some specific characteristics of the
       "text/red" format.  The redundancy headers are part of the
       payload, so the receiver would need to just assume that the
       payload type number in the redundancy header is for "text/t140".
       The characters per second parameter (CPS) would need to act per
       stream.  The relation between the SSRC and the source would need
       to be conveyed in some specified way, e.g. in the CSRC. Recovery
       and loss detection would preferably be based on sequence number
       gap detection.  Thus sequence number gaps in the incoming stream
       to the mixer would need to be reflected in the stream to the
       participant and no new gaps created by the mixer.  However, the
       RTP implementation in both mixers and endpoints need to support
       multiple streams in the same RTP session in order to use this
       mechanism.  For best deployment opportunity, it should be possible
       to upgrade existing endpoint solutions to be multi-party aware
       with a reasonable effort.  There is currently a lack of support
       for multi-stream RTP in certain implementation technologies.  This
       fact made this solution only briefly mentioned in this document as
       an option for further study.

"

(I wonder if I should delete "in the same RTP session", because it seems 
that the SFM description in RFC 7667 does not specify that the streams 
to the participants must be in the same session.)   ????

In order for the specified negotiation to not preclude addition of other 
multi-party methods, e.g. an SFU based, I suggest to move the 
offer/answer section from section 3 to 2, and word it so that other 
multi-party methods are possible.

I also propose to change the name of the main method to be the 
"RTP-mixer based multi-party method"

With that, I hope that I have answered all WGLC comments to 
satisfaction, and I have a corresponding version -12 of the draft prepared.

Regards

Gunnar

Den 2020-12-10 kl. 17:49, skrev Gunnar Hellström:
>
> After looking a bit more on the multi-stream issue, I want to reduce 
> the ambition I announced below.
>
> So, I want to back off to mention the possible benefits of 
> multi-stream RTP and SFU. I want to indicate that it would be possible 
> to negotiate between the specified RTP-mixer method and other 
> multi-party aware methods, but say that it is for further study to 
> specify any such method in more detail.
>
>> media and the application calls for use of specific RTP topologies 
>> and specific ways to negotiate the use of it. Therefore I intend to 
>> write a short description with  general statements and references to 
>> which considerations from the RTP-mixer method should be valid also 
>> for the RTP multi-stream methods.
>>
>>> Then the "rtt-mix" attribute is sufficient to indicate capability 
>>> for the RTP-mixer based multi-party solution, and we only need to 
>>> tell that other solutions may be implemented.
>>>
>> middlebox can be revealed and acted on by the receiving party. So, 
>> the offset adjustment is only intended to make the sequence look 
>>>> question is whether a "multi-party aware endpoint" would be 
>>>> prepared to receive multiple SSRCs (and no CSRCs), with each SSRC 
>> aware means any of the two methods RTP-mixer and multi-stream RTP. 
>> And then specific wording for each method when there is talk about 
>> only one method.
>>>>
>>>> participant with an SSRC of its own, but each text stream would 
>>>> have a unique SSRC up to the maximum participant limit.
>>> RTT is specific in that no data flows when the user does not send 
>>> any information. In the other media there is always contents. 
>> mention that. It eases switching. In the normal case no switching 
>> will be needed. All simultaneous senders can likely always be allowed 
>> to transmit on to the receivers.
>>>
>>>>
>> [GH] I changed my mind. My general approach does not need any more 
>> sdp examples.
>>>
>> Thanks,
>>
>> Gunnar
>>
>>>
>>> Thanks,
>>>
>>> Gunnar
>>>
>>>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>