Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-00.txt

From: [email-masked]
Date: Fri, 08 May 2020 08:28:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : RTP-mixer formatting of multi-party Real-time text
        Author          : Gunnar Hellstrom
	Filename        : draft-ietf-avtcore-multi-party-rtt-mix-00.txt
	Pages           : 25
	Date            : 2020-05-07

Abstract:
   Real-time text mixers for multi-party sessions need to identify the
   source of each transmitted group of text so that the text can be
   presented by endpoints in suitable grouping with other text from the
   same source.

   Regional regulatory requirements specify provision of real-time text
   in multi-party calls.  RFC 4103 mixer implementations can use
   traditional RTP functions for source identification, but the mixer
   source switching performance is limited when using the default
   transmission with redundancy.

   An enhancement for RFC 4103 real-time text mixing is provided in the
   present specification, suitable for a centralized conference model
   that enables source identification and efficient source switching.
   The intended use is for real-time text mixers and multi-party-aware
   participant endpoints.  The mechanism builds on use of the CSRC list
   in the RTP packet.

   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 an sdp media attribute "rtt-mix".

   A brief description about how a mixer can format text for the case
   when the endpoint is not multi-party aware is also provided.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-00
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 8 May 2020 23:18:09 +0200

Thanks for the support,

draft-ietf-avtcore-multi-party-rtt-mix-00 has the same contents as 
draft-hellstrom-avtcore-multi-party-rtt-source-03.

I have notes of some issues that I want to act on now.

Some are related to questions that need rapid responses from the 
different areas where this draft is intended to be feasible to be 
applied:  NG9-1-1, NG112, 3GPP IMS MTSI, IETF RUM, and plain SIP 
multimedia calls.

1. Consider rapidly if there is any more reliable transport that is 
feasible to move to.
(e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC 
t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use of 
SAVPF with NAK and retransmission RFC 4588)

The answer on issue 1 influences many of the following issues, currently 
written with the assumption that we continue with RTP transport.

2. Add sdp examples

3. Add SRTP hints and OSRTP preference (RFC 8643).

4. Add a brief motivation for the solution and why not rtp-translator is 
used. (or review rapidly the decision to go with the RTP-mixer model, 
three commenters have wondered why we do not use the rtp-translator model.)

5 We have indications  that the format with the strict use of the CSRC 
list to indicate sources also of the redundant parts might not be called 
text/red. A new format (e.g. text/rex) may then need to be registered, 
and sdp negotiation made between text/red and text/rex for 
interoperability reasons. Shall we accept that and move on with text/rex 
and the CSRC list that gives switching performance for 5 participants 
within 500 milliseconds delay (as compared to 3 participants within 600 
milliseconds for the text/red format.

6. If we agree to change format to text/rex, then also consider to move 
to the format proposed by James Hamlin, with primary text from up to 16 
participants in each packet. Provides good switching performance 
increase to 16 simultaneous sources.

7. Describe limitations in the multi-party-unaware case that 
unrecoverable packet loss can hit the label at source switch and 
therefore give the impression that text is coming from another source 
than it is.

8. Make explicit wording about what is to be regarded as update to RFC 
4103. It is important from regulatory points of view in Europe and USA 
that the result can be seen as an update of RFC 4103.

9. Include brief gateway considerations to WebRTC t140 data channel.

Comments are welcome.

Regards

Gunnar

Den 2020-05-08 kl. 17:28, skrev [email-masked]:
> _______________________________________________
> 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: Mon, 11 May 2020 12:22:42 +0200

In a recent e-mail, I listed 9 issues to act on in 
draft-ietf-avtcore-multi-party-rtt-mix-00

I want to deal with them one by one or in small groups. Here is number 1:

> SAVPF with NAK and retransmission RFC 4588) 

It may look strange with this issue after many months as an individual 
draft. But I want to touch it anyway before we move on in one fixed 
direction.

T.140 and its RTP transport (RFC 2793 - later RFC 4103) were created 
1998 - 2000 as the third real-time medium for human conversations beside 
voice and video. The idea was to give equal opportunities to persons 
wanting to communicate by text as the ones who use voice or video. That 
means real-time transmission while text is created and accepting some 
rare dropouts just as we do with voice and video. However, users are 
nowadays used to text messaging where it is customary to accept a delay 
and get the text complete in most cases, rather than to have loss. That 
user experience might be expected from real-time text as well. I do not 
have any strong user indications that this is the case, it is just my 
own thinking.

The reason to bring this up now, is that we seem to need to introduce 
the multi-party mixed format at least as a new text media subtype, 
text/rex instead of text/red. Then we are anyway introducing signaling 
complexity of similar kind that another transport will do.

Are any of the initially mentioned more reliable transports realistic 
and easily implemented in the target implementation environments: NG 
emergency services, 3GPP IMS MTSI, IETF RUM, and plain SIP multimedia? 
Or are there any other not mentioned?

When considering this, we should have in mind that the proposed 
transport should be with security so that we do not need to introduce 
more options to negotiate between.

And we shall also keep in mind that NAT traversal needs to be supported 
as well as multi-party-signaling through the SIP central conferencing 
model RFC 4353.

Another complexity is that current regulation requires RFC 4103 and it 
would be best that the finaly specified multi-party solution can be 
perceived as an extension to RFC 4103.

What can be said about the options?

  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, so 
it is secured. Should use RFC 6544 ICE for TCP for NAT traversal. 
Requires specification of how to arrange the streams and code the 
sources in the multi-party environment. I do not know how well these 
RFCs are supported in the target environments. Seems to increase complexity.

2. draft-ietf-mmusic-t140-data-channel-usage. Has security, NAT 
traversal and possibility to code multi-party source. Has good 
opportunity for being supported in endpoint devices, because all of them 
are expected to support WebRTC. Maybe less supported in traditional SIP 
bridges.

3. SAVPF with NACK and RFC 4588 retransmission. I assume this can be 
combined with OSRTP RFC 8643 for security negotiation. When the 
immediate or early feedback option can be used, this method can likely 
be used without redundancy to achieve a reliability enhancement. That 
will not work well over networks with high latency. Further study needed 
if redundancy or FEC is needed as complement for high latency networks. 
Easy to achieve up to 5 simultaneously sending users.

4. (Not mentioned in the introduction above) Use RFC 4103 plus one of 
the RTP based methods for multi-party source indication but just 
increase redundancy to one original and three (instead of two) redundant 
generations. Can easily be done if reliability increase is really a 
concern. Has low overhead. Easily applicable to OSRTP security, SIP 
conferencing model and ICE NAT traversal.

5. Accept reliability that is quite good as it is with RTP with one 
original and two redundant generations in the RFC 2198 - style ( with 
one of the additional methods discussed for increasing switching 
performance)

Comments please so we can take a rapid decision and move on with one 
solution.

Regards

Gunnar

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 11 May 2020 22:14:45 -0400

Speaking to one aspect of one point:

Gunnar Hellstrom <[email-masked]> writes:
> That 
> user experience might be expected from real-time text as well.

I was attending IETF meetings around the time that "real-time text"
became an important project, and my understanding is that the
deaf/hard-of-hearing community is very insistent on the real-time nature
of it, as in seeing the pacing of how the sender is typing characters.
In particular, the SIP MESSAGE method, which resembles mobile phone text
messages, was considered quite inadequate.

The possibility of lost packets was compensated for by the RTP
redundancy mechanism.

Poking around, I find https://en.wikipedia.org/wiki/Real-time_text,
which points to the Real Time Text Task Force
http://www.realtimetext.org/, which has an FAQ
http://www.realtimetext.org/FAQ containing

    Why is Real-Time Text important to people who are deaf or hard of
    hearing?

    In addition to its many applications for fully hearing people, Real-Time
    Text is important as an equivalent alternative to voice communications
    for people who are deaf and hard of hearing. It allows a more natural,
    bi-directional flow of text based conversation to take place compared
    with the "type-enter-wait-read-response-reply" technology of IM(chat)
    and SMS.

    In fact: when Real-Time Text is fully mainstream, it will be solving one
    of the biggest accessibility problems of Internet communications for
    people who are deaf or hard of hearing!

While searching for that, I found that Verizon has a big page on how to
activate RTT on various phone models
https://www.verizon.com/about/accessibility/real-time-text

Dale

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 12 May 2020 06:46:12 +0200

Dale, thanks for good comments,

>> user experience might be expected from real-time text as well.
I see I did not express myself clearly. The introduction should have been:

That means real-time transmission while text is created and accepting 
some rare dropouts just as we do with voice and video. However, users 
are nowadays used to text messaging where it is customary to accept a_*n 
extra*_ delay_*in case of network errors *_and get the text complete in 
most cases, rather than to have loss. That user experience might be 
expected from real-time text as well.

>>      people who are deaf or hard of hearing!
Yes, and it is sad that real-time text has not yet become the way we 
normally communicate in text. If the big text chat services would send 
text while it is created, we would not sit waiting for next complete 
message, but could follow the thoughts of the other party as they are 
expressed in words and be ready to respond sooner. That would save 
stress and time.
>> https://www.verizon.com/about/accessibility/real-time-text
Yes, you can also find similar information from other operators and 
manufacturers. But usually in the Accessibility area.

>> Dale

Thanks,

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 14 May 2020 17:01:55 +0200

I have concluded that only two of the discussed transports are realistic.

Comments below

Den 2020-05-11 kl. 12:22, skrev Gunnar Hellström:
>> t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use 
>> of SAVPF with NAK and retransmission RFC 4588) 
>
> 1998 - 2000 as the third real-time medium for human conversations 
> beside voice and video. The idea was to give equal opportunities to 
> persons wanting to communicate by text as the ones who use voice or 
> video. That means real-time transmission while text is created and 
> accepting some rare dropouts just as we do with voice and video. 
> However, users are nowadays used to text messaging where it is 
> customary to accept a delay and get the text complete in most cases, 
> rather than to have loss. That user experience might be expected from 
> real-time text as well. I do not have any strong user indications that 
> this is the case, it is just my own thinking.
>
> And we shall also keep in mind that NAT traversal needs to be 
> supported as well as multi-party-signaling through the SIP central 
> conferencing model RFC 4353.
>
--Increases complexity - not selected
>
> 2. draft-ietf-mmusic-t140-usage-data-channel. Has security, NAT 
> opportunity for being supported in endpoint devices, because all of 
> them are expected to support WebRTC. Maybe less supported in 
> traditional SIP bridges.
--A realistic solution. The base is already approved and is for a 
popular environment. Multi-party is briefly mentioned but should 
probably be a bit further specified. Should however not be the only 
solution. The RTP based solution is also needed.
> will not work well over networks with high latency. Further study 
> needed if redundancy or FEC is needed as complement for high latency 
> networks. Easy to achieve up to 5 simultaneously sending users.
--Increases complexity - not selected
> increase redundancy to one original and three (instead of two) 
> redundant generations. Can easily be done if reliability increase is 
> really a concern. Has low overhead. Easily applicable to OSRTP 
> security, SIP conferencing model and ICE NAT traversal.
--Easily done by local recommendations if 3 generations redundancy 
(including the original) would not be felt sufficient somewhere.
> one of the additional methods discussed for increasing switching 
--Realistic and regarded sufficient. By move to a mixer method allowing 
300 ms transmission interval, the protection against burtsy packet loss 
is quite good. Continue on this track.

The conclusion is reflected in version -01 of the draft, just published.

Regards

Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Fri, 15 May 2020 11:03:35 -0400

I think we have to consider who has to do what.

If we are requiring all implementations to change because of other multi-party issues, then I think we should us an actual reliable protocol, and not just a “repeat enough times that the probability it gets there is high enough.  

If we aren’t asking all implementations to change for multi-party, but only the mixer, then I think that we’re sticking with T.140, 

We’re in the latter case, right?  The point of this work is don’t change the endpoints, only the conference bridge.

Brian

> On May 14, 2020, at 11:01 AM, Gunnar Hellström <[email-masked]> wrote:
> 
>> In a recent e-mail, I listed 9 issues to act on in draft-ietf-avtcore-multi-party-rtt-mix-00
>> 
>> 1. Consider rapidly if there is any more reliable transport that is feasible to move to.
>>> (e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use of SAVPF with NAK and retransmission RFC 4588) 
>> 
>> It may look strange with this issue after many months as an individual draft. But I want to touch it anyway before we move on in one fixed direction.
>> 
>> T.140 and its RTP transport (RFC 2793 - later RFC 4103) were created 1998 - 2000 as the third real-time medium for human conversations beside voice and video. The idea was to give equal opportunities to persons wanting to communicate by text as the ones who use voice or video. That means real-time transmission while text is created and accepting some rare dropouts just as we do with voice and video. However, users are nowadays used to text messaging where it is customary to accept a delay and get the text complete in most cases, rather than to have loss. That user experience might be expected from real-time text as well. I do not have any strong user indications that this is the case, it is just my own thinking.
>> 
>> The reason to bring this up now, is that we seem to need to introduce the multi-party mixed format at least as a new text media subtype, text/rex instead of text/red. Then we are anyway introducing signaling complexity of similar kind that another transport will do.
>> 
>> Are any of the initially mentioned more reliable transports realistic and easily implemented in the target implementation environments: NG emergency services, 3GPP IMS MTSI, IETF RUM, and plain SIP multimedia? Or are there any other not mentioned?
>> 
>> When considering this, we should have in mind that the proposed transport should be with security so that we do not need to introduce more options to negotiate between.
>> 
>> And we shall also keep in mind that NAT traversal needs to be supported as well as multi-party-signaling through the SIP central conferencing model RFC 4353.
>> 
>> Another complexity is that current regulation requires RFC 4103 and it would be best that the finaly specified multi-party solution can be perceived as an extension to RFC 4103.
>> 
>>  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, so it is secured. Should use RFC 6544 ICE for TCP for NAT traversal. Requires specification of how to arrange the streams and code the sources in the multi-party environment. I do not know how well these RFCs are supported in the target environments. Seems to increase complexity.
>> 2. draft-ietf-mmusic-t140-usage-data-channel. Has security, NAT traversal and possibility to code multi-party source. Has good opportunity for being supported in endpoint devices, because all of them are expected to support WebRTC. Maybe less supported in traditional SIP bridges.
> --A realistic solution. The base is already approved and is for a popular environment. Multi-party is briefly mentioned but should probably be a bit further specified. Should however not be the only solution. The RTP based solution is also needed.
>> 
>> 3. SAVPF with NACK and RFC 4588 retransmission. I assume this can be combined with OSRTP RFC 8643 for security negotiation. When the immediate or early feedback option can be used, this method can likely be used without redundancy to achieve a reliability enhancement. That will not work well over networks with high latency. Further study needed if redundancy or FEC is needed as complement for high latency networks. Easy to achieve up to 5 simultaneously sending users.
>> 4. (Not mentioned in the introduction above) Use RFC 4103 plus one of the RTP based methods for multi-party source indication but just increase redundancy to one original and three (instead of two) redundant generations. Can easily be done if reliability increase is really a concern. Has low overhead. Easily applicable to OSRTP security, SIP conferencing model and ICE NAT traversal.
> --Easily done by local recommendations if 3 generations redundancy (including the original) would not be felt sufficient somewhere.
>> 
>> 
>> 5. Accept reliability that is quite good as it is with RTP with one original and two redundant generations in the RFC 2198 - style ( with one of the additional methods discussed for increasing switching performance)
>> 
> --Realistic and regarded sufficient. By move to a mixer method allowing 300 ms transmission interval, the protection against burtsy packet loss is quite good. Continue on this track.
> 
> 
>> Comments please so we can take a rapid decision and move on with one solution.
>> 
>> Regards
>> 
>> 
>> Gunnar
>> 
>> 
>> 
>> 
> -- 
> Gunnar Hellström
> GHAccess
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 15 May 2020 20:29:03 +0200

Hi Brian,

Den 2020-05-15 kl. 17:03, skrev Brian Rosen:
> If we are requiring all implementations to change because of other 
> multi-party issues, then I think we should us an actual reliable 
> protocol, and not just a “repeat enough times that the probability it 
> gets there is high enough.
>
> If we aren’t asking all implementations to change for multi-party, but 
> only the mixer, then I think that we’re sticking with T.140,
>
> We’re in the latter case, right?  The point of this work is don’t 
> change the endpoints, only the conference bridge.

We are in both cases. And I hope you agree we should be.  And this is in 
general, not only for the transport. Both cases are there in the current 
draft draft-ietf-avtcore-multi-party-rtt-mix-01

1) A mechanism that the mixer can use when it is revealed that the 
endpoint does not support proper multi-party presentation. There are 
functional limitations, but it works reasonably well, especially for few 
parties taking turns in reasonably good order. It is specified in 
section 13.2 and is called "Multi-party mixing for multi-party unaware 
endpoints".  You can check the functional limitations at the end of that 
section and tell if you agree that we also need something better.

2) A mechanism to use when both the mixer and the endpoint can handle 
fully functional multi-party presentation of text. That requires active 
action by the endpoint to place received text in areas for each 
participant, and present them in a suitable way, both providing a good 
real-time impression, an impression of approximately when in time order 
the text entries were produced, and a collection of text from each 
participant in suitable chunks, phrases, sentences or messages, with 
source information attached. The latest draft has a format for 
multi-party transport that allows up to 16 sources per packet, and can 
by that provide text from about 32 simultaneously typing participants 
without introducing unacceptable delay. Earlier versions of the draft 
had different and much lower performance.  I am glad that the new format 
will not be the bottleneck for a good RTT multi-party experience.

It would have been possible to specify another transport for mechanism 
2), but my reasoning ended up in the same as before: RTP with 
RFC2198-type redundancy, with one original and two redundant 
transmissions, most often 300 ms apart. You can see the format as 
16-tuple-RFC-4103. Do you agree in this conclusion for case 2?

Thanks,

Gunnar

>
> Brian
>
>> On May 14, 2020, at 11:01 AM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>>>> (e.g. Comedia RFC 4145 and RFC 4572, or the recently approved 
>>>> WebRTC t140 data channel draft-ietf-mmusic-t140-data-channel-usage, 
>>>> or use of SAVPF with NAK and retransmission RFC 4588)
>>>
>>> It may look strange with this issue after many months as an 
>>> individual draft. But I want to touch it anyway before we move on in 
>>> one fixed direction.
>>>
>>> rather than to have loss. That user experience might be expected 
>>> from real-time text as well. I do not have any strong user 
>>> indications that this is the case, it is just my own thinking.
>>>
>>> The reason to bring this up now, is that we seem to need to 
>>> introduce the multi-party mixed format at least as a new text media 
>>> subtype, text/rex instead of text/red. Then we are anyway 
>>> introducing signaling complexity of similar kind that another 
>>> transport will do.
>>>
>>> Are any of the initially mentioned more reliable transports 
>>> realistic and easily implemented in the target implementation 
>>> environments: NG emergency services, 3GPP IMS MTSI, IETF RUM, and 
>>> plain SIP multimedia? Or are there any other not mentioned?
>>>
>>> transport should be with security so that we do not need to 
>>> introduce more options to negotiate between.
>>>
>>> Another complexity is that current regulation requires RFC 4103 and 
>>> it would be best that the finaly specified multi-party solution can 
>>> be perceived as an extension to RFC 4103.
>>>
>>>  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, 
>>> so it is secured. Should use RFC 6544 ICE for TCP for NAT traversal. 
>>> immediate or early feedback option can be used, this method can 
>>> likely be used without redundancy to achieve a reliability 
>>> enhancement. That will not work well over networks with high 
>>> latency. Further study needed if redundancy or FEC is needed as 
>>> complement for high latency networks. Easy to achieve up to 5 
>>> simultaneously sending users.
>>> 4. (Not mentioned in the introduction above) Use RFC 4103 plus one 
>>> of the RTP based methods for multi-party source indication but just 
>>> original and two redundant generations in the RFC 2198 - style ( 
>>> with one of the additional methods discussed for increasing 
>>> switching performance)
>>>
>> --Realistic and regarded sufficient. By move to a mixer method 
>> allowing 300 ms transmission interval, the protection against burtsy 
>> packet loss is quite good. Continue on this track.
>>
>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 15 May 2020 17:33:39 -0400

Ah,  two cases, multiparty aware and multi party unaware slipped my mind.

I would say if we’re defining multi-party aware UAs, which is by definition, new code, that we’re better off with a truly reliable transport.  Keeping “repeat it enough times that it ought to work” doesn’t strike me as the best choice given implementations must change.  That was a hack.  It’s an okay hack, but we have the problem that this is very high information density per bit, so it’s quite a bit worse to lose information with RTT than with audio or video.  Your mind can fill in some missing character blanks, but not as well as it can deal with missing audio and video packets.

Brian

> On May 15, 2020, at 2:29 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> Hi Brian,
> 
> We are in both cases. And I hope you agree we should be.  And this is in general, not only for the transport. Both cases are there in the current draft draft-ietf-avtcore-multi-party-rtt-mix-01
> 
> 1) A mechanism that the mixer can use when it is revealed that the endpoint does not support proper multi-party presentation. There are functional limitations, but it works reasonably well, especially for few parties taking turns in reasonably good order. It is specified in section 13.2 and is called "Multi-party mixing for multi-party unaware endpoints".  You can check the functional limitations at the end of that section and tell if you agree that we also need something better.
> 
> 2) A mechanism to use when both the mixer and the endpoint can handle fully functional multi-party presentation of text. That requires active action by the endpoint to place received text in areas for each participant, and present them in a suitable way, both providing a good real-time impression, an impression of approximately when in time order the text entries were produced, and a collection of text from each participant in suitable chunks, phrases, sentences or messages, with source information attached. The latest draft has a format for multi-party transport that allows up to 16 sources per packet, and can by that provide text from about 32 simultaneously typing participants without introducing unacceptable delay. Earlier versions of the draft had different and much lower performance.  I am glad that the new format will not be the bottleneck for a good RTT multi-party experience. 
> 
> It would have been possible to specify another transport for mechanism 2), but my reasoning ended up in the same as before: RTP with RFC2198-type redundancy, with one original and two redundant transmissions, most often 300 ms apart. You can see the format as 16-tuple-RFC-4103. Do you agree in this conclusion for case 2?
> 
> Thanks,
> 
> Gunnar
> 
>   
> 
> 
> 
> 
> 
>> 
>> Brian
>> 
>>> On May 14, 2020, at 11:01 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Dan Mongrain <[email-masked]>
Date: Fri, 15 May 2020 23:20:59 -0400

Please keep UDP-based RTT conveyance, even for conference-aware endpoints.
While I do not mind if we were to add a reliable conveyance protocol as an
option, we must keep the UDP-based option for RTT. The reason is that SBCs
out there currently treat RTT as voice traffic and allow it through. If we
were to insist that conference-aware endpoints only support a reliable
protocol then the SBCs will need to be updated in order for RTT to work.
This is not a trivial change, especially since the initial market for RTT
is Public Safety which is a small market for SBC vendors thus does not
react quickly to these types of changes.

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 Fri, May 15, 2020 at 5:34 PM Brian Rosen <[email-masked]> wrote:

> I would say if we’re defining multi-party aware UAs, which is by
> definition, new code, that we’re better off with a truly reliable
> transport.  Keeping “repeat it enough times that it ought to work” doesn’t
> strike me as the best choice given implementations must change.  That was a
> hack.  It’s an okay hack, but we have the problem that this is very high
> information density per bit, so it’s quite a bit worse to lose information
> with RTT than with audio or video.  Your mind can fill in some missing
> character blanks, but not as well as it can deal with missing audio and
> video packets.
>
> Brian
>
> multi-party issues, then I think we should us an actual reliable protocol,
> and not just a “repeat enough times that the probability it gets there is
> high enough.
>
> We’re in the latter case, right?  The point of this work is don’t change
> the endpoints, only the conference bridge.
>
> parties taking turns in reasonably good order. It is specified in section
> 13.2 and is called "Multi-party mixing for multi-party unaware endpoints".
> You can check the functional limitations at the end of that section and
> tell if you agree that we also need something better.
>
> real-time impression, an impression of approximately when in time order the
> text entries were produced, and a collection of text from each participant
> in suitable chunks, phrases, sentences or messages, with source information
> attached. The latest draft has a format for multi-party transport that
> allows up to 16 sources per packet, and can by that provide text from about
> 32 simultaneously typing participants without introducing unacceptable
> delay. Earlier versions of the draft had different and much lower
> performance.  I am glad that the new format will not be the bottleneck for
> a good RTT multi-party experience.
>
> It would have been possible to specify another transport for mechanism 2),
> but my reasoning ended up in the same as before: RTP with RFC2198-type
> redundancy, with one original and two redundant transmissions, most often
> 300 ms apart. You can see the format as 16-tuple-RFC-4103. Do you agree in
> this conclusion for case 2?
>
> Thanks,
>
> Gunnar
>
>
>
>
>
>
> Brian
>
> (e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC t140
> data channel draft-ietf-mmusic-t140-data-channel-usage, or use of SAVPF
> with NAK and retransmission RFC 4588)
>
>
> T.140 and its RTP transport (RFC 2793 - later RFC 4103) were created 1998
> - 2000 as the third real-time medium for human conversations beside voice
> and video. The idea was to give equal opportunities to persons wanting to
> communicate by text as the ones who use voice or video. That means
> real-time transmission while text is created and accepting some rare
> dropouts just as we do with voice and video. However, users are nowadays
> used to text messaging where it is customary to accept a delay and get the
> text complete in most cases, rather than to have loss. That user experience
> might be expected from real-time text as well. I do not have any strong
> user indications that this is the case, it is just my own thinking.
>
> The reason to bring this up now, is that we seem to need to introduce the
> multi-party mixed format at least as a new text media subtype, text/rex
> instead of text/red. Then we are anyway introducing signaling complexity of
> similar kind that another transport will do.
>
> Are any of the initially mentioned more reliable transports realistic and
> easily implemented in the target implementation environments: NG emergency
> services, 3GPP IMS MTSI, IETF RUM, and plain SIP multimedia? Or are there
> any other not mentioned?
>
> When considering this, we should have in mind that the proposed transport
> should be with security so that we do not need to introduce more options to
> negotiate between.
>
> And we shall also keep in mind that NAT traversal needs to be supported as
> well as multi-party-signaling through the SIP central conferencing model
> RFC 4353.
>
>  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, so it
> is secured. Should use RFC 6544 ICE for TCP for NAT traversal. Requires
> specification of how to arrange the streams and code the sources in the
> multi-party environment. I do not know how well these RFCs are supported in
> the target environments. Seems to increase complexity.
>
> 2. draft-ietf-mmusic-t140-usage-data-channel. Has security, NAT traversal
> and possibility to code multi-party source. Has good opportunity for being
> supported in endpoint devices, because all of them are expected to support
> WebRTC. Maybe less supported in traditional SIP bridges.
>
> --A realistic solution. The base is already approved and is for a popular
> environment. Multi-party is briefly mentioned but should probably be a bit
> further specified. Should however not be the only solution. The RTP based
> solution is also needed.
>
>
> combined with OSRTP RFC 8643 for security negotiation. When the immediate
> or early feedback option can be used, this method can likely be used
> without redundancy to achieve a reliability enhancement. That will not work
> well over networks with high latency. Further study needed if redundancy or
> FEC is needed as complement for high latency networks. Easy to achieve up
> to 5 simultaneously sending users.
>
> 4. (Not mentioned in the introduction above) Use RFC 4103 plus one of the
> RTP based methods for multi-party source indication but just increase
> redundancy to one original and three (instead of two) redundant
> original and two redundant generations in the RFC 2198 - style ( with one
> of the additional methods discussed for increasing switching performance)
>
> 300 ms transmission interval, the protection against burtsy packet loss is
> quite good. Continue on this track.
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwMFaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=Mh4BvC6JY0d6urYNkCGlGuI1Pgq7xekFGGo79VtP9m4&s=K1yT7vKc_oY0sbKk9iEk8eU7THJ6mwdS8Xy716izsdI&e=>
>
>
> --
> Gunnar Hellström
> [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=Mh4BvC6JY0d6urYNkCGlGuI1Pgq7xekFGGo79VtP9m4&s=K1yT7vKc_oY0sbKk9iEk8eU7THJ6mwdS8Xy716izsdI&e=
>

-- 

*Your privacy is important to us. That is why we have taken appropriate 
measures to ensure the data you provide to us is kept secure. To learn more 
about how we process your personal information, how we comply with 
applicable data protection laws, and care for the security and privacy of 
your personal data, please review our Privacy Policy. If you have any 
questions related to data protection and compliance with applicable laws, 
please contact us at our Security Operations Center at 1-800-674-4357.*

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 16 May 2020 09:07:17 +0200

Thanks, Brian and Dan for good points.

To Brian: Yes, text is more sensitive to dropouts than voice. That is 
why we  in RTP based RTT added two redundant transmissions with 300 ms 
interval. That provides an enormous increase in reliability compared to 
sending once. If you have an evenly distributed loss of 2% packets, then 
the loss of characters of text will be one per 100 000, which is far 
better than the sources you have for text communication: typing or voice 
to text. By having the packets sent with 300 ms intervals, the text will 
also survive all packet loss bursts of up to 599 ms and many up to 899 
ms. And if you get a text loss, you get an indication. So, it is longer 
burst loss that can cause real text loss that is noticable compared to 
human errors. And in such conditions, voice users might experience a gap 
that makes them say "sorry, there was a dropout, what did you say". So, 
I think the current method with RTP and redundancy meets the initial 
requirements well to serve as a human conversation media.

It is only if you have one of the following cases you will have problems:

1) you are so used to the reliability of text messaging that you will 
have problems accepting the relative reliability of this RTT transmission.

2) we let important protocol elements be transported with the same 
mechanism, so they can be lost in transmission. That is the case with 
the "multi-party unaware mixing" included as one option in the current 
draft if you are in contact with a legacy endpoint. One example is at 
source switch, when a line separator and a label is sent inline, before 
text from another source is sent. If any parts of these are lost, it 
causes much more confusion than text loss in human created text. That is 
one reason why the multi-party aware mixing is the primary one, and the 
multi-party unaware has a row of warnings about functional limitations 
attached.

However, text messaging also has its moments of confusion when something 
goes wrong.

We already have one reliable transport for RTT, in the recently approved 
draft-ietf-mmusic-t140-usage-data-channel. So, my conclusion was to not 
introduce more options by specifying yet another reliable transport, and 
instead move on with good multi-party support also for RTP based RTT 
transmission with redundancy.

Dan, good point about the need to get through SBC:s without much 
modifications.

Would the WebRTC data channel also get through? I is based on the 
SCTP/DTLS/UDP stack.

Regards

Gunnar

Den 2020-05-16 kl. 05:20, skrev Dan Mongrain:
> Please keep UDP-based RTT conveyance, even for conference-aware 
> endpoints. While I do not mind if we were to add a reliable conveyance 
> protocol as an option, we must keep the UDP-based option for RTT. The 
> reason is that SBCs out there currently treat RTT as voice traffic and 
> allow it through. If we were to insist that conference-aware endpoints 
> only support a reliable protocol then the SBCs will need to be updated 
> in order for RTT to work. This is not a trivial change, especially 
> since the initial market for RTT is Public Safety which is a small 
> market for SBC vendors thus does not react quickly to these types of 
> changes.
>
> Thanx,
> Dan
>
> *Dan Mongrain, eng.
> <mailto:[email-masked]>
> www.linkedin.com/in/DanMongrain <http://www.linkedin.com/in/DanMongrain>
>
> /https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png/
>
>
>
>
> On Fri, May 15, 2020 at 5:34 PM Brian Rosen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     transport.  Keeping “repeat it enough times that it ought to work”
>     doesn’t strike me as the best choice given implementations must
>     change.  That was a hack.  It’s an okay hack, but we have the
>     problem that this is very high information density per bit, so
>     it’s quite a bit worse to lose information with RTT than with
>     audio or video.  Your mind can fill in some missing character
>     blanks, but not as well as it can deal with missing audio and
>     video packets.
>
>     Brian
>
>>     On May 15, 2020, at 2:29 PM, Gunnar Hellström
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Hi Brian,
>>
>>>     If we are requiring all implementations to change because of
>>>     other multi-party issues, then I think we should us an actual
>>>     reliable protocol, and not just a “repeat enough times that the
>>>     probability it gets there is high enough.
>>>
>>>     If we aren’t asking all implementations to change for
>>>     multi-party, but only the mixer, then I think that we’re
>>>     sticking with T.140,
>>>
>>>     We’re in the latter case, right?  The point of this work is
>>>     don’t change the endpoints, only the conference bridge.
>>
>>     We are in both cases. And I hope you agree we should be.  And
>>     this is in general, not only for the transport. Both cases are
>>     there in the current draft draft-ietf-avtcore-multi-party-rtt-mix-01
>>
>>     1) A mechanism that the mixer can use when it is revealed that
>>     the endpoint does not support proper multi-party presentation.
>>     There are functional limitations, but it works reasonably well,
>>     especially for few parties taking turns in reasonably good order.
>>     It is specified in section 13.2 and is called "Multi-party mixing
>>     for multi-party unaware endpoints".  You can check the functional
>>     limitations at the end of that section and tell if you agree that
>>     we also need something better.
>>
>>     2) A mechanism to use when both the mixer and the endpoint can
>>     handle fully functional multi-party presentation of text. That
>>     requires active action by the endpoint to place received text in
>>     areas for each participant, and present them in a suitable way,
>>     both providing a good real-time impression, an impression of
>>     approximately when in time order the text entries were produced,
>>     and a collection of text from each participant in suitable
>>     chunks, phrases, sentences or messages, with source information
>>     attached. The latest draft has a format for multi-party transport
>>     that allows up to 16 sources per packet, and can by that provide
>>     text from about 32 simultaneously typing participants without
>>     introducing unacceptable delay. Earlier versions of the draft had
>>     different and much lower performance.  I am glad that the new
>>     format will not be the bottleneck for a good RTT multi-party
>>     experience.
>>
>>     It would have been possible to specify another transport for
>>     mechanism 2), but my reasoning ended up in the same as before:
>>     RTP with RFC2198-type redundancy, with one original and two
>>     redundant transmissions, most often 300 ms apart. You can see the
>>     format as 16-tuple-RFC-4103. Do you agree in this conclusion for
>>     case 2?
>>
>>     Thanks,
>>
>>     Gunnar
>>
>>
>>
>>
>>>
>>>     Brian
>>>
>>>>     <[email-masked]
>>>>     <mailto:[email-masked]>> wrote:
>>>>
>>>>>>     WebRTC t140 data channel
>>>>>>     draft-ietf-mmusic-t140-data-channel-usage, or use of SAVPF
>>>>>     individual draft. But I want to touch it anyway before we move
>>>>>     on in one fixed direction.
>>>>>
>>>>>     T.140 and its RTP transport (RFC 2793 - later RFC 4103) were
>>>>>     created 1998 - 2000 as the third real-time medium for human
>>>>>     conversations beside voice and video. The idea was to give
>>>>>     equal opportunities to persons wanting to communicate by text
>>>>>     as the ones who use voice or video. That means real-time
>>>>>     transmission while text is created and accepting some rare
>>>>>     dropouts just as we do with voice and video. However, users
>>>>>     are nowadays used to text messaging where it is customary to
>>>>>     accept a delay and get the text complete in most cases, rather
>>>>>     than to have loss. That user experience might be expected from
>>>>>     real-time text as well. I do not have any strong user
>>>>>     introduce the multi-party mixed format at least as a new text
>>>>>     media subtype, text/rex instead of text/red. Then we are
>>>>>     anyway introducing signaling complexity of similar kind that
>>>>>     another transport will do.
>>>>>
>>>>>     environments: NG emergency services, 3GPP IMS MTSI, IETF RUM,
>>>>>     and plain SIP multimedia? Or are there any other not mentioned?
>>>>>
>>>>>     When considering this, we should have in mind that the
>>>>>     proposed transport should be with security so that we do not
>>>>>     need to introduce more options to negotiate between.
>>>>>
>>>>>     supported as well as multi-party-signaling through the SIP
>>>>>     central conferencing model RFC 4353.
>>>>>
>>>>>     Another complexity is that current regulation requires RFC
>>>>>     4103 and it would be best that the finaly specified
>>>>>     multi-party solution can be perceived as an extension to RFC 4103.
>>>>>
>>>>>      1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for
>>>>>     transport, so it is secured. Should use RFC 6544 ICE for TCP
>>>>>     for NAT traversal. Requires specification of how to arrange
>>>>>     the streams and code the sources in the multi-party
>>>>>     environment. I do not know how well these RFCs are supported
>>>>>     in the target environments. Seems to increase complexity.
>>>>>     2. draft-ietf-mmusic-t140-usage-data-channel. Has security,
>>>>>     NAT traversal and possibility to code multi-party source. Has
>>>>>     good opportunity for being supported in endpoint devices,
>>>>>     because all of them are expected to support WebRTC. Maybe less
>>>>>     supported in traditional SIP bridges.
>>>>     --A realistic solution. The base is already approved and is for
>>>>     a popular environment. Multi-party is briefly mentioned but
>>>>     should probably be a bit further specified. Should however not
>>>>     be the only solution. The RTP based solution is also needed.
>>>>>
>>>>>     3. SAVPF with NACK and RFC 4588 retransmission. I assume this
>>>>>     can be combined with OSRTP RFC 8643 for security negotiation.
>>>>>     When the immediate or early feedback option can be used, this
>>>>>     method can likely be used without redundancy to achieve a
>>>>>     reliability enhancement. That will not work well over networks
>>>>>     with high latency. Further study needed if redundancy or FEC
>>>>>     is needed as complement for high latency networks. Easy to
>>>>>     achieve up to 5 simultaneously sending users.
>>>>>     4. (Not mentioned in the introduction above) Use RFC 4103 plus
>>>>>     one of the RTP based methods for multi-party source indication
>>>>>     but just increase redundancy to one original and three
>>>>>     (instead of two) redundant generations. Can easily be done if
>>>>>     reliability increase is really a concern. Has low overhead.
>>>>>     Easily applicable to OSRTP security, SIP conferencing model
>>>>>     and ICE NAT traversal.
>>>>     --Easily done by local recommendations if 3 generations
>>>>     redundancy (including the original) would not be felt
>>>>     sufficient somewhere.
>>>>>
>>>>>
>>>>>     5. Accept reliability that is quite good as it is with RTP
>>>>>     with one original and two redundant generations in the RFC
>>>>>     2198 - style ( with one of the additional methods discussed
>>>>>     for increasing switching performance)
>>>>>
>>>>     allowing 300 ms transmission interval, the protection against
>>>>     burtsy packet loss is quite good. Continue on this track.
>>>>
>>>>
> /Your privacy is important to us. That is why we have taken 
> appropriate measures to ensure the data you provide to us is kept 
> secure. To learn more about how we process your personal information, 
> how we comply with applicable data protection laws, and care for the 
> security and privacy of your personal data, please review our Privacy 
> Policy. If you have any questions related to data protection and 
> compliance with applicable laws, please contact us at our Security 
> Operations Center at 1-800-674-4357./
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 May 2020 10:41:24 -0400

On 5/15/20 5:33 PM, Brian Rosen wrote:
> doesn’t strike me as the best choice given implementations must change. 
>   That was a hack.  It’s an okay hack, but we have the problem that this 
> is very high information density per bit, so it’s quite a bit worse to 
> lose information with RTT than with audio or video.  Your mind can fill 
> in some missing character blanks, but not as well as it can deal with 
> missing audio and video packets.

I agree with you in theory. But going that way has some problems in 
practice. Notably, the multiparty aware and unaware implementations need 
to coexist in order to be deployed. If they use the same transport and 
the differences can be negotiated via O/A of SDP parameters then the 
coexistence is easy. But with differences in transport the O/A mechanism 
for discovering the best mechanism supported by both ends becomes messy.

	Thanks,
	Paul

>>> If we aren’t asking all implementations to change for multi-party, 
>>> but only the mixer, then I think that we’re sticking with T.140,
>>>
>> We are in both cases. And I hope you agree we should be.  And this is 
>> in general, not only for the transport. Both cases are there in the 
>> current draft draft-ietf-avtcore-multi-party-rtt-mix-01
>>
>> functional limitations, but it works reasonably well, especially for 
>> few parties taking turns in reasonably good order. It is specified in 
>> endpoints".  You can check the functional limitations at the end of 
>> that section and tell if you agree that we also need something better.
>>
>> fully functional multi-party presentation of text. That requires 
>> active action by the endpoint to place received text in areas for each 
>> real-time impression, an impression of approximately when in time 
>> order the text entries were produced, and a collection of text from 
>> each participant in suitable chunks, phrases, sentences or messages, 
>> with source information attached. The latest draft has a format for 
>> had different and much lower performance.  I am glad that the new 
>> format will not be the bottleneck for a good RTT multi-party experience.
>>
>>>>>> draft-ietf-mmusic-t140-data-channel-usage, or use of SAVPF with 
>>>>>> NAK and retransmission RFC 4588)
>>>>>
>>>>> individual draft. But I want to touch it anyway before we move on 
>>>>> in one fixed direction.
>>>>>
>>>>> conversations beside voice and video. The idea was to give equal 
>>>>> opportunities to persons wanting to communicate by text as the ones 
>>>>> who use voice or video. That means real-time transmission while 
>>>>> text is created and accepting some rare dropouts just as we do with 
>>>>> voice and video. However, users are nowadays used to text messaging 
>>>>> where it is customary to accept a delay and get the text complete 
>>>>> in most cases, rather than to have loss. That user experience might 
>>>>> be expected from real-time text as well. I do not have any strong 
>>>>> so it is secured. Should use RFC 6544 ICE for TCP for NAT 
>>>>> traversal. Requires specification of how to arrange the streams and 
>>>>> code the sources in the multi-party environment. I do not know how 
>>>>> well these RFCs are supported in the target environments. Seems to 
>>>>> increase complexity.
>>>>> 3. SAVPF with NACK and RFC 4588 retransmission. I assume this can 
>>>>> be combined with OSRTP RFC 8643 for security negotiation. When the 
>>>>> redundant generations. Can easily be done if reliability increase 
>>>>> is really a concern. Has low overhead. Easily applicable to OSRTP

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 16 May 2020 20:13:30 +0200

Den 2020-05-16 kl. 16:41, skrev Paul Kyzivat:
>> problem that this is very high information density per bit, so it’s 
>> quite a bit worse to lose information with RTT than with audio or 
>> video.  Your mind can fill in some missing character blanks, but not 
>> as well as it can deal with missing audio and video packets.
>
> practice. Notably, the multiparty aware and unaware implementations 
> need to coexist in order to be deployed. If they use the same 
> transport and the differences can be negotiated via O/A of SDP 
> parameters then the coexistence is easy. But with differences in 
> transport the O/A mechanism for discovering the best mechanism 
> supported by both ends becomes messy.

Yes, I agree. Initially I hoped that we could define the multi-party 
capability just with a media attribute and still call the format 
"text/red". But that resulted in a low source switching performance of 
about two sources per second. With the new media subtype "text/rex" that 
can be said to be up to 16 repetitions of the "text/red" format in each 
packet I am sure we have suffircient performance and still easily 
handled negotiation with just one more payload type in the same m-line.

Next thing to include is security negotiation. I have recommended OSRTP 
RFC 8643 to be the way to select between no security and SRTP with DTLS 
if the application has no reason to specify something else. I have not 
yet included an SDP example, but I imagine it is manageable, and more 
realistic than if I needed to combine negotiation between two different 
media lines for different transports and security or no security e.g. by 
means of sdp grouping and RFC 5939.

It would be interesting to have comments to that approach as well.

Thanks,

Gunnar

>>>> protocol, and not just a “repeat enough times that the probability 
>>>> it gets there is high enough.
>>>>
>>> We are in both cases. And I hope you agree we should be.  And this 
>>> is in general, not only for the transport. Both cases are there in 
>>> the current draft draft-ietf-avtcore-multi-party-rtt-mix-01
>>>
>>> few parties taking turns in reasonably good order. It is specified 
>>> in section 13.2 and is called "Multi-party mixing for multi-party 
>>> unaware endpoints".  You can check the functional limitations at the 
>>> end of that section and tell if you agree that we also need 
>>> something better.
>>>
>>> areas for each participant, and present them in a suitable way, both 
>>> providing a good real-time impression, an impression of 
>>> approximately when in time order the text entries were produced, and 
>>> a collection of text from each participant in suitable chunks, 
>>> phrases, sentences or messages, with source information attached. 
>>> The latest draft has a format for multi-party transport that allows 
>>> up to 16 sources per packet, and can by that provide text from about 
>>> 32 simultaneously typing participants without introducing 
>>> unacceptable delay. Earlier versions of the draft had different and 
>>> much lower performance.  I am glad that the new format will not be 
>>> the bottleneck for a good RTT multi-party experience.
>>>
>>> mechanism 2), but my reasoning ended up in the same as before: RTP 
>>> with RFC2198-type redundancy, with one original and two redundant 
>>>>>> opportunities to persons wanting to communicate by text as the 
>>>>>> ones who use voice or video. That means real-time transmission 
>>>>>> while text is created and accepting some rare dropouts just as we 
>>>>>> do with voice and video. However, users are nowadays used to text 
>>>>>> messaging where it is customary to accept a delay and get the 
>>>>>> text complete in most cases, rather than to have loss. That user 
>>>>>> experience might be expected from real-time text as well. I do 
>>>>>> not have any strong user indications that this is the case, it is 
>>>>>> just my own thinking.
>>>>>>
>>>>>> media subtype, text/rex instead of text/red. Then we are anyway 
>>>>>> Another complexity is that current regulation requires RFC 4103 
>>>>>> and it would be best that the finaly specified multi-party 
>>>>>> solution can be perceived as an extension to RFC 4103.
>>>>>>
>>>>>> transport, so it is secured. Should use RFC 6544 ICE for TCP for 
>>>>>> NAT traversal. Requires specification of how to arrange the 
>>>>>> streams and code the sources in the multi-party environment. I do 
>>>>>> not know how well these RFCs are supported in the target 
>>>>>> environments. Seems to increase complexity.
>>>>>> opportunity for being supported in endpoint devices, because all 
>>>>>> of them are expected to support WebRTC. Maybe less supported in 
>>>>>> traditional SIP bridges.
>>>>> probably be a bit further specified. Should however not be the 
>>>>> only solution. The RTP based solution is also needed.
>>>>>>
>>>>>> be combined with OSRTP RFC 8643 for security negotiation. When 
>>>>>> the immediate or early feedback option can be used, this method 
>>>>>> can likely be used without redundancy to achieve a reliability 
>>>>>> but just increase redundancy to one original and three (instead 
>>>>>> of two) redundant generations. Can easily be done if reliability 
>>>>>> increase is really a concern. Has low overhead. Easily applicable 
>>>>>> to OSRTP security, SIP conferencing model and ICE NAT traversal.
>>>>>> 5. Accept reliability that is quite good as it is with RTP with 
>>>>>> one original and two redundant generations in the RFC 2198 - 
>>>>>> style ( with one of the additional methods discussed for 
>>>>>> increasing switching performance)
>>>>>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 18 May 2020 08:48:46 -0400

Do the SBCs implement 8643?  WebRTC data channel?

I think the SDP issues are manageable but the SBC issues are not.  

Brian

> On May 16, 2020, at 2:13 PM, Gunnar Hellström <[email-masked]> wrote:
> 
>> I agree with you in theory. But going that way has some problems in practice. Notably, the multiparty aware and unaware implementations need to coexist in order to be deployed. If they use the same transport and the differences can be negotiated via O/A of SDP parameters then the coexistence is easy. But with differences in transport the O/A mechanism for discovering the best mechanism supported by both ends becomes messy.
> 
> Yes, I agree. Initially I hoped that we could define the multi-party capability just with a media attribute and still call the format "text/red". But that resulted in a low source switching performance of about two sources per second. With the new media subtype "text/rex" that can be said to be up to 16 repetitions of the "text/red" format in each packet I am sure we have suffircient performance and still easily handled negotiation with just one more payload type in the same m-line.
> 
> Next thing to include is security negotiation. I have recommended OSRTP RFC 8643 to be the way to select between no security and SRTP with DTLS if the application has no reason to specify something else. I have not yet included an SDP example, but I imagine it is manageable, and more realistic than if I needed to combine negotiation between two different media lines for different transports and security or no security e.g. by means of sdp grouping and RFC 5939.
> 
>>>> On May 15, 2020, at 2:29 PM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi Brian,
>>>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 18 May 2020 11:09:10 -0400

It occurs to me that the SBC may not pass text/rex.  Depends on how picky they are.  Text/red is basic T.140.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 May 2020 08:24:46 -0700

lOn May 18, 2020, at 8:09 AM, Brian Rosen <[email-masked]> wrote:
> 
> It occurs to me that the SBC may not pass text/red.  Depends on how picky they are.  Text/red is basic T.140.

[BA] Legacy SBCs are indeed an issue, and a basic obstacle to deployment of RTT. I am not aware of any SIP trunk providers that support text/red, because they would need to upgrade their SBCs to do so, which would be a large cost, with no corresponding revenue source.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 18 May 2020 11:35:08 -0400

I think this means we use the WebRTC data channel, which is HTTP based, right?  Totally bypasses the SBC.  Have to be careful to not cause the SBC to get confused with the SDP.

Middle box triumph, again.

Brian

> On May 18, 2020, at 11:24 AM, Bernard Aboba <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 May 2020 16:00:28 +0000

Hi,

> I think this means we use the WebRTC data channel, which is HTTP based, right?  Totally bypasses the SBC.  Have to be careful to not cause the SBC to get confused with the SDP.

The WebRTC data channel is not HTTP based. It is basically an SCTP stream.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 May 2020 16:10:45 +0000

Hi,

---

>1) A mechanism that the mixer can use when it is revealed that the endpoint does not support proper multi-party presentation. There are functional limitations, 
>but it works reasonably well, especially for few parties taking turns in reasonably good order. It is specified in section 13.2 and is called "Multi-party mixing for
>multi-party unaware endpoints". 

Why not simply call it "Multi-party mixing for single-party endpoints"?

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 18 May 2020 19:45:59 +0200

Hi,

> Why not simply call it "Multi-party mixing for single-party endpoints"?

Maybe.

I initially used "conference-unaware", in order to use the same term as 
in RFC 4353 and RFC 4579 SIP central conferencing. The most urgent 
applications claim that they use that framework.

But then I realized that for our case it was more important how the 
media format was composed than how the multi-party session was signaled, 
so I started to call it "multi-party aware" and "multi-party unaware".  
It still has similarities with the nomenclature of the conferencing 
framework.

If we were to change terms, I think it would be better with two-party 
endpoints, because they are made for two-party sessions. On the other 
hand, multi-party-aware endpoints can also handle two-party sessions.

So the difference is really that the endpoint is unaware of the 
charcteristics in the media format that tells about different parties.

What do you think?

Thanks,

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 May 2020 17:48:14 +0000

Hi,

---
    
    > charcteristics in the media format that tells about different parties.

    I am fine with whatever :)

    Regards,
  
    Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 18 May 2020 20:54:29 +0200

Hi,

> The WebRTC data channel is not HTTP based. It is basically an SCTP stream.

Yes, with UDP as the lowest layer.

So we are talking about two UDP based transports.

text/red and text/rex are RTP based, and may be SRTP encrypted. They are 
declared in the same m-line, and one selected and then will use one or 
two ports.

WebRTC data channels stack is UDP/DTLS/SCTP.

Both would normally use ICE to find their ways through networks.

Do we really have noticable differences in how hard it would be to get 
through the networks with any of these? And would there be any other 
transport that would be easier to get through?

Regards

Gunnar

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 May 2020 19:20:46 +0000

Hi,

    >>> I think this means we use the WebRTC data channel, which is HTTP based, right?  Totally bypasses the SBC.  Have to be careful
    >>> to not cause the SBC to get confused with the SDP.

    I really think we should aim for an RTP based solution. 4103 is already out there, and possible extensions are much easier to adopt than something completely new.

    In addition, we can for sure also define a WebRTC based solution, but that should not be the only solution.

    Regards,

    Christer