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

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

Thanks Brian,

Den 2020-04-21 kl. 20:56, skrev Brian Rosen:
> 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.
Right. And a lot from RFC 4103 is still valid with the new payload type, 
so that it can be an update to RFC 4103.
> I’m not aware of any implementations of t140 without redundancy, but 
> I’m also not bothered by including rtt-mix.
Right. No one using plain T.140 without redundancy currently.
>
> I’m also okay with James Hamlin’s proposal.  I like the effect enough 
> that I’m not going to worry about bad implementations.
I aim at including this new payload type in next version. I also intend 
to look at what sdp would look like if we include negotiation between 
RTP and SRTP.
> 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
>
Thanks,

Gunnar

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