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

From: [email-masked]
Date: Thu, 04 Jun 2020 02:42:43 -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-05.txt
	Pages           : 38
	Date            : 2020-06-04

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 this
   document, 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 and an extended packet format "text/rex".

   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 the media subtype "text/rex".

   The document updates RFC 4102[RFC4102] and RFC 4103[RFC4103]

   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-05
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-multi-party-rtt-mix-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-05

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: Thu, 4 Jun 2020 11:49:38 +0200

A new version of the multi-party rtt mix draft is available with 
adjustments in terminoogy and editorial improvements.

Regards

Gunnar

Den 2020-06-04 kl. 11:42, 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, 8 Jun 2020 23:44:34 +0200

The problem we have with RFC 4103 for multi-party use is that the 
redundancy format text/red cannot switch CSRC rapidly.

I have found an already existing RFC that allows redundancy coding and 
yet change CSRC for every packet. That is RFC 5109 Generic FEC.

It also allows the redundancy to be sent at a suitable time after the 
original, so text loss by bursty packet loss can be kept low.

We have said that the requirement is to enable a mix of five 
simultaneous text sources with an introduced latency less than 500 ms.

That is what can be achieved with the text/t140 format from RFC 4103 
transmitted with up to 10 packets per second, packetized with 
text/ulpfec from RFC 5109. text/ulpfec allows transmission with 
redundancy according to RFC 2198, the same that RFC 4103 uses for 
redundancy, with the difference that text/ulpfec includes parts of the 
RTP header and CSRC in the redundancy data, so that the RTP packets can 
be completely recovered.

RFC 5109 has many options, but can be used for protecting all data with 
two retransmissions, e.g. sent about 600 and 1200 ms after the initial 
transmission. ( or other suitable times to avoid most packet loss burtst 
but not cause too long delays at loss)

There is still a fact that when there is unrecoverable loss of text, it 
is not possible to tell from which source it was lost.  I was drafting a 
proposal to overcome this problem with changes in the format specified 
in the current draft, when I realized that RFC 5109 could be used - but 
not solve just that problem. Still, I think it is a great benefit to be 
able to use already standardized formats.

  Introducing FEC coding is already allowable in RFC 4103.

Comments?

Regards

Gunnar