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

James Hamlin <james.hamlin@purple.us> Wed, 02 September 2020 10:39 UTC

Return-Path: <james.hamlin@purple.us>
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 222ED3A0EA8 for <avt@ietfa.amsl.com>; Wed, 2 Sep 2020 03:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.482
X-Spam-Level:
X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 uUZVARQQ-hS6 for <avt@ietfa.amsl.com>; Wed, 2 Sep 2020 03:39:45 -0700 (PDT)
Received: from outbound-ip25a.ess.barracuda.com (outbound-ip25a.ess.barracuda.com [209.222.82.207]) (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 8E7203A0E9D for <avtcore@ietf.org>; Wed, 2 Sep 2020 03:39:17 -0700 (PDT)
Received: from smtp.purple.us (smtp01.purple.us.91.17.208.in-addr.arpa [208.17.91.143]) by mx4.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 02 Sep 2020 10:39:16 +0000
Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 2 Sep 2020 03:39: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; Wed, 2 Sep 2020 03:39:15 -0700
From: James Hamlin <james.hamlin@purple.us>
To: "avtcore@ietf.org" <avtcore@ietf.org>
Thread-Topic: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-08.txt
Thread-Index: AQHWgIE+Iqc1o+4hbUWoG96bzSqmqg==
Date: Wed, 2 Sep 2020 10:39:15 +0000
Message-ID: <1599043155397.98095@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_159904315539798095purpleus_"
MIME-Version: 1.0
X-BESS-ID: 1599043156-893006-7583-160377-1
X-BESS-VER: 2019.1_20200831.2045
X-BESS-Apparent-Source-IP: 208.17.91.143
X-BESS-Outbound-Spam-Score: 0.20
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.226610 [from cloudscan15-87.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.20 BSF_SC0_SA953 META: Custom Rule BSF_SC0_SA953 0.00 HTML_IMAGE_ONLY_28 BODY: HTML: images with 2400-2800 bytes of words 0.00 BSF_BESS_OUTBOUND META: BESS Outbound
X-BESS-Outbound-Spam-Status: SCORE=0.20 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_SC0_SA953, HTML_IMAGE_ONLY_28, BSF_BESS_OUTBOUND
X-BESS-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/dIimZuMHAExbIkPvAAlNCin8EWg>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-08.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 10:39:46 -0000

Gunnar


I think the compromise in V08 is a good one; we have considered quite a few options, and allowing just one sender per packet, with a fixed limit of 1 on the CC field is the only solution that can be achieved with only a small change to RFC4103. We have to acknowledge that SSRC switching time increases as the level of redundancy increases. It also increases with more participants typing at once but people typing over one another is generally the smaller part of the conversation. These two caveats have previously been acknowledged.


Because redundant generations from one SSRC have to be cleared before another SSRC can be sent, recovery of redundant data is fairly simple. But working out which SSRC has missing text, is more difficult. The current text has a clear example where it is possible to verify that nothing is missing but it would be useful to have a defined algorithm so that implementations don't get that wrong. That said, there are a lot of cases to consider, and some error cases where the sender has not followed the rules. Perhaps we just accept that implementers must work this out for themselves.



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.