Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD43A0C75 for ; Thu, 21 May 2020 23:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md_A0d9RQ_JD for ; Thu, 21 May 2020 23:02:18 -0700 (PDT) Received: from outbound-ip25b.ess.barracuda.com (outbound-ip25b.ess.barracuda.com [209.222.82.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83553A0C81 for ; Thu, 21 May 2020 23:02:17 -0700 (PDT) Received: from smtp.purple.us (smtp02.purple.us.91.17.208.in-addr.arpa [208.17.91.144]) by mx2.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 22 May 2020 06:02:16 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 21 May 2020 23:02:15 -0700 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Thu, 21 May 2020 23:02:15 -0700 From: James Hamlin To: "\"avtcore@ietf.org\"" Thread-Topic: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-02.txt Thread-Index: AQHWL/2mHj9H+NCwiE6g/MydxQZGrg== Date: Fri, 22 May 2020 06:02:13 +0000 Message-ID: <1590127333702.59101@purple.us> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_159012733370259101purpleus_" MIME-Version: 1.0 X-BESS-ID: 1590127335-893003-402-28800-1 X-BESS-VER: 2019.1_20200521.2236 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.20 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.224284 [from cloudscan16-35.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.20 BSF_SC0_SA953 META: Custom Rule BSF_SC0_SA953 X-BESS-Outbound-Spam-Status: SCORE=0.20 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND, BSF_SC0_SA953 X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 06:02:21 -0000 --_000_159012733370259101purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gunnar A few thoughts:- The draft defines the timestamp offset as indicating the time data was rece= ived at the mixer, but surely it should aim to reflect the time from the so= urce so that it represents the time the text was typed? In the rare event o= f 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 we= re 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 a= n 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 p= ayload type for zero bytes at the packet end. I realize that time offsets a= re limited to ~16secs, but this would allow for some network delay plus a f= ew redundant transmission times. So it would be possible for the mixer to p= ut in offsets for all sources and generations, to represent the original ti= me typed, relative to the current packet timestamp. If the mixer is sending from its own source - as it will for the initial BO= M character I imagine ? it has the choice of setting cc to zero or adding i= tself 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=3D=3D0, 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 addin= g a second keyboard). Perhaps with text/rex it would be better to always ad= d a source to the list. The draft says that a BOM char must be sent to new participants. I don't se= e 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 redundan= t generations. Would an empty packet with cc=3D0 and only a primary data he= ader, 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 p= ersonal and confidential use of the recipient(s) named above. If you have r= eceived this communication in error, please notify us immediately by e-mail= , and delete the original message. --_000_159012733370259101purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Gunnar


A few thoughts:-


The draft defines the ti= mestamp offset as indicating the time data was received at the mixer, but s= urely it should aim to reflect the time from the source so that it represen= ts the time the text was typed? In the rare event of long network delays, the timestamp from the sources woul= d be the only way at a receiver could detect the order in which parts of th= e conversation were typed. The only way to allow all the sources’ tim= estamps 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 le= ave the final header block redundant and essentially providing a payload ty= pe 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 imag= ine − it has the choice of setting cc to zero or adding itself as a c= ontributing source. If there other sources active then it must do the latter. I wonder whether we should be more precise abo= ut when to do each? The current text says that only mixers set cc > 0; s= hould we also say that a mixer should never set cc=3D=3D0, meaning that it = would always add it’s CSRC to the list when sending from itself? I suppose there’s also the possibility tha= t a sender might add a new source mid session (perhaps adding a second keyb= oard). Perhaps with text/rex it would be better to always add a source to t= he list.


The draft says that a BO= M char must be sent to new participants. I don’t see the mention of B= OM 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=3D0 and only a pri= mary data header, be a better initial opening packet and keep alive during = inactivity?


Best regards

James

J= ames Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information cont= ained in this e-mail message is intended only for the personal and confiden= tial use of the recipient(s) named above. If you have received this communi= cation in error, please notify us immediately by e-mail, and delete the original message.

--_000_159012733370259101purpleus_--