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

James Hamlin <> Fri, 22 May 2020 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60CD43A0C75 for <>; Thu, 21 May 2020 23:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Md_A0d9RQ_JD for <>; Thu, 21 May 2020 23:02:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D83553A0C81 for <>; Thu, 21 May 2020 23:02:17 -0700 (PDT)
Received: from ( []) by (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 22 May 2020 06:02:16 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 21 May 2020 23:02:15 -0700
Received: from ([fe80::e190:fa54:4b11:2dfb]) by ([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: "\"\"" <>
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: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
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-Outbound-Spam-Score: 0.20
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version [from] 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-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

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



[X]James Hamlin
Purple, a Division of ZP Better Together, LLC

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.