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

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

Hi James,

Den 2020-05-22 kl. 08:02, skrev James Hamlin:
>
> Hi Gunnar
>
>
> A few thoughts:-
>
>
> The draft defines the timestamp offset as indicating the time data was 
> received at the mixer, but surely it should aim to reflect the time 
> from the source so that it represents the time the text was typed? In 
> the rare event of long network delays, the timestamp from the sources 
> would be the only way at a receiver could detect the order in which 
> parts of the conversation were typed.
>
Yes, I hesitated between timestamping for origination at the source and 
timestamping for reception. You may have a point in that it would be 
better to have it be at the origin.
>
> The only way to allow all the sources’ timestamps to be signaled 
> separately from that of the timestamp of the RTP packet would be to 
> allow an extra header, for the time-offset of the final CSRC’s primary 
> text, which would leave the final header block redundant and 
> essentially providing a payload type for zero bytes at the packet end.
>
We can define the format in the way we want. I just started out as close 
as text/red as possible. The last header may be specified to contain a 
timestamp offset, and maybe a length to ease the work of the decoders.
>
> I realize that time offsets are limited to ~16secs, but this would 
> allow for some network delay plus a few redundant transmission times. 
> So it would be possible for the mixer to put in offsets for all 
> sources and generations, to represent the original time typed, 
> relative to the current packet timestamp.
>
Yes, hopefully. We also have the conditions when we are at risk of 
overrunning the reception capacity of a receiver, when we need to delay 
text. If we are sending to a TTY gateway (that is barely realistic) we 
would easily run into long delays over the 16 seconds. But I also 
thought that the 16 second limit should do.
>
>
> If the mixer is sending from its own source – as it will for the 
> initial BOM character I imagine − it has the choice of setting cc to 
> zero or adding itself as a contributing source. If there other sources 
> active then it must do the latter. I wonder whether we should be more 
> precise about when to do each? The current text says that only mixers 
> set cc > 0; should we also say that a mixer should never set cc==0, 
> meaning that it would always add it’s CSRC to the list when sending 
> from itself? I suppose there’s also the possibility that a sender 
> might add a new source mid session (perhaps adding a second keyboard). 
> Perhaps with text/rex it would be better to always add a source to the 
> list.
>
Yes, good point. I agree that the mixer should always use the CSRC list 
even if itself is the only transmitter at that moment.

And, yes, new sources may come along and be added to the conference. I 
the SIP conference model of RFC 4535 is properly used the mixer shall 
also announce new sources by a SIP NOTIFY. But that is not really 
required for the mixing to work. Each sent packet may have a new 
composition of the sources who have text to send for the moment.

>
> The draft says that a BOM char must be sent to new participants. I 
> don’t see the mention of BOM in RFC4103 but it does talk of empty 
> packets. Sending a BOM at the start, implies that the BOM will need to 
> be resent in redundant generations. Would an empty packet with cc=0 
> and only a primary data header, be a better initial opening packet and 
> keep alive during inactivity?
>
T.140 and Unicode in general requires BOM to be the first to be 
transmitted. It is good for opening transmission through routers etc. 
Nowadays ICE is probably used in most cases also for the same purpose. 
Then keep-alives by sending BOM is really not a good way. If it is lost, 
you get a false text loss indication. RFC 6263 instead says that you 
should send keep-alive by multiplexing RTP and RTCP on the same port.


Yes, these initial BOMs shall be sent with the same transmission 
mechanism as any other text, with redundancy and a good transmission 
interval.


Thanks, I make notes of your points as issues for coming versions.


Regards,

Gunnar

>
> Best regards
>
> James
>
> James Hamlin
> Contractor
> Purple, a Division of ZP Better Together, LLC
> purplevrs.com
>
> The information contained in this e-mail message is intended only for 
> the personal and confidential use of the recipient(s) named above. If 
> you have received this communication in error, please notify us 
> immediately by e-mail, and delete the original message.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

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