[AVTCORE] Question on multi-party RTT handling (draft-hellstrom-avtcore-multi-party-rtt-source-03)

[Yong Xin <[e-mail]>]

Dear Mr. Hellstrom,

I have a question about how to use RTT mixer (rtt-mix) method with "text/red" format for multi-party call handling, as defined in your IETF draft https://tools.ietf.org/html/draft-hellstrom-avtcore-multi-party-rtt-source-03.
  4. Use of fields in the RTP packets

   RFC 4103<https://tools.ietf.org/html/rfc4103>[RFC4103<https://tools.ietf.org/html/rfc4103>] specifies use of RFC 3550<https://tools.ietf.org/html/rfc3550> RTP[RFC3550], and a

   redundancy format "text/red" for increased robustness.  This

   specification updates RFC 4102<https://tools.ietf.org/html/rfc4102>[RFC4102<https://tools.ietf.org/html/rfc4102>] and RFC 4103<https://tools.ietf.org/html/rfc4103>[RFC4103<https://tools.ietf.org/html/rfc4103>] by

   introducing a rule for populating and using the CSRC-list in the RTP

   packet in order to enhance the performance in multi-party RTT

   sessions.



   When transmitted from a mixer, the first member in the CSRC-list

   SHALL contain the SSRC of the source of the primary T140block in the

   packet.  The second and further members in the CSRC-list SHALL

   contain the SSRC of the source of the first, second, etc redundant

   generations of T140blocks included in the packet. ( the recommended

   level of redundancy is to use one primary and two redundant

   generations of T140blocks.)  In some cases, a primary or redundant

   T140block is empty, but is still represented by a member in the

   redundancy header.  For such cases, the corresponding CSRC-list

   member MUST also be included.



   The CC field SHALL show the number of members in the CSRC list.



   Note: This specification departs from section 4 of RFC 2198<https://tools.ietf.org/html/rfc2198#section-4> [RFC2198<https://tools.ietf.org/html/rfc2198>]

   which associates the whole of the CSRC-list with the primary data and

   assumes that the same list applies to reconstructed redundant data.

   In the present specification a T140block is associated with exactly

   one CSRC list member as described above.  Also RFC 2198<https://tools.ietf.org/html/rfc2198> [RFC2198<https://tools.ietf.org/html/rfc2198>]

   anticipates infrequent change to CSRCs; implementers should be aware

   that the order of the CSRC-list according to this specification will

   vary during transitions between transmission from the mixer of text

   originated by different participants.



   The picture below shows a typical RTP packet with multi-party RTT

   contents and coding according to the present specification.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X| CC=3  |M|  "RED" PT   |   sequence number of primary  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               timestamp of primary encoding "P"               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |  CSRC list member 1 = SSRC of source of "P"                   |
      |  CSRC list member 2 = SSRC of source of "R1"                  |
      |  CSRC list member 3 = SSRC of source of "R2"                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|   T140 PT   |  timestamp offset of "R2" | "R2" block length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|   T140 PT   |  timestamp offset of "R1" | "R1" block length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|   T140 PT   | "R2" T.140 encoded redundant data             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+
      |   |  "R1" T.140 encoded redundant data        |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         +-+-+-+
      |              "P" T.140 encoded primary data             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: text/red packet with sources indicated in the CSRC-list.

At every transmission time, the mixer can use the primary data block to send new texts from one source, but new texts from other sources will have to wait in their queue for their turn. I assume it is a round-robin fashion to determine the next source. The default text transmission interval is 300ms, which means the texts from other sources have to wait in the queue for at least 300ms before they can be transmitted. I can see you have recommended to reduce the transmission interval from 300ms to 100ms to reduce this delay, but in the case of large conference and assuming every participant is typing the text simultaneously, the waiting time in the queue will become longer. For example, in a 10-party conference, even with 100ms transmission interval, the new texts from last participant will wait for 9x100ms = 900ms to send. This delay will be too long for some emergency service. Increasing the redundancy level will only help to recovery from more consecutive packet loss, but it does not help to reduce this delay. So it looks to me this method is not ideal for large conference, is my understanding correct? Has this issue been discussed in the IETF meeting before? Do you have any recommendation to solve this problem?

Thanks,
Yong