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

[James Hamlin <[e-mail]>]

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. 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. 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.


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.


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?


Best regards

James

[X][X]

[X]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.