[AVTCORE] Multi-party real-time text requiring new RTP payload type

[Gunnar Hellström <[e-mail]>]

Hi,

I have got an off-list comment that the proposed use of the CSRC-list 
members to indicate source of the primary and the different redundancy 
generations of the T140blocks would require registration of a new 
payload type instead of saying that it is a refined use of text/red 
updated from RFC 4103.

( this is about 
https://www.ietf.org/id/draft-hellstrom-avtcore-multi-party-rtt-source-03.txt 
)

The purpose is to speed up the switch of source of text from the mixer 
so that every packet can have primary text from another source than the 
previous packet. Without the update, the mixer would need to send two 
packets with just redundant text before sending new text from another 
source.

I am not yet totally convinced that we need to introduce a new payload 
type, but find it possible.

Let us call it "text/rex" for "redundancy extended".

It would cause a quite straightforward sdp negotiation of parties 
supporting both the traditional text/red format from RFC 4103, and the 
updated text/rex.

Offer example :

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

  Answer example  from a multi-party capable device
       m=text 11000 RTP/AVP 101 98
       a=rtpmap:98 t140/1000
       a=rtpmap:101 rex/1000
       a=fmtp:101 98/98/98
       a=rtt-mix

Answer example from a multi-party unaware device:

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

  

It may look strange that the attribute a=rtt-mix is still there as an 
indication of multi-party capability when that already is implied in the 
"rex" payload type. But it is for the very rare case that the network 
conditions would allow use of bare t140 payload type without redundancy. 
Then there is a need to indicate multi-party awareness by a=rtt-mix .

If we accept this move, we could also open for discussion if the format 
proposed by James Hamlin earlier in this list, where the maximum number 
of 16 members in the CSRC list allows transport of text from up to 16 
sources in the same packet. That would make the mixing of real-time text 
as efficient and rapid as that of audio and video. A question is though 
if current implementations are well behaving and do not collapse by 
getting the combined sdp.

If we do not accept this move and instead base the multi-party mixing on 
the current text/red format with short transmission intervals, we can 
claim that simultaneous typing is quite rare and that the introduced 
delay of the first few characters of about 200 ms from a second source 
when one is already sending is acceptable, knowing that most text 
conversations are at speeds of under 12 characters per second and that 
the transmissions from each source anyway comes in 300 ms intervals.  
Some jerkiness and delay will be noticable when there is more than two 
simultaneous senders.

Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
[e-mail]