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

[Brian Rosen <[e-mail]>]

I’m okay with the new payload type.  All of this would be new code, so dealing with the new payload type wouldn’t be confusing or difficult. 
I’m not aware of any implementations of t140 without redundancy, but I’m also not bothered by including rtt-mix.

I’m also okay with James Hamlin’s proposal.  I like the effect enough that I’m not going to worry about bad implementations.  Again, supporting this is new code, so if your implementation of T140 and SDP in general is lacking, this would be a good time to fix that.

Brian


> On Apr 21, 2020, at 5:18 AM, Gunnar Hellström <[e-mail]> wrote:
> 
> 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 <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] <mailto:[e-mail]>_______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt