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

Gunnar Hellström <> Sun, 06 September 2020 08:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D54163A07E0 for <>; Sun, 6 Sep 2020 01:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s9eVKpZE2UgO for <>; Sun, 6 Sep 2020 01:08:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 403663A07F6 for <>; Sun, 6 Sep 2020 01:08:57 -0700 (PDT)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 780D42016E; Sun, 6 Sep 2020 10:08:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1599379734; bh=VDSOevI3R8ir+dKcjJU1xC1XJIhswBSJyVrOULpX0lo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=O8QVnQrQm9MLjRgrn98PjLggYDsrDTfdw9UoPmrHsPZXDGxz2+bhzCRP4G6PKp4eV BezGh/WaokblHhqEOqUfXagEzie5X75Mzn2jRvfKddMCs6Wj5HJ7Dr2BFr4zpBVsjQ 4Wx9qNAVwCLGkt6QtWoQ+4T2IHpFwO5gPDjTiGaY=
To: James Hamlin <>, "" <>
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Sun, 6 Sep 2020 10:08:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------B34238F8A4D2C2100FDCE5BD"
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-08.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: Sun, 06 Sep 2020 08:09:03 -0000

James, thanks for the comment,

Den 2020-09-02 kl. 12:39, skrev James Hamlin:
> 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.
Or it can even be seen as a clarification on the use of RFC 4103 for the 
multi-party case. Plus the added capability negotiation.
>  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.
Yes, the packet sequence example in section 2.1.23 is from a sequence 
where 3 sequential packets were lost and yet no text lost. It is quite 
easy to add more clear information about which cases of loss of 4 
packets in sequence can be totally recovered, and which cases of loss of 
three packets in sequence can be totally recovered. When there is 
resulting loss, it can not be deducted exactly from which source it was 
lost. In some cases there may be a high likelihood for being from a 
specific source, but I do not think that the specification should go 
into discussing such possibilities, just as RFC 4103 mentions the 
possible use of the M-bit for some more advanced loss evaluations 
without specifying exactly how.

Thanks for reviewing this section. Because of that I found an error. 
"A1" in the text under packet 6 in section 2.1.23 should be "A3".

Having a sender that does not follow the rules for redundancy 
composition can of course cause unexpected results, just as any protocol 
error. We cannot specify what kind of protocol errors the receiver must 
be able to handle. As usual, the implementer needs to take care that 
protocol errors do not cause dramatic failure situations.

It is complex to test a good variation of packet loss scenarios and it 
is strongly recommended that implementers create test material with 
known packet loss sequences so that the mechanisms for recovery and 
indication of loss can be tested and verified. But that is beyond what 
is expected from this draft.



> Best regards
> James
> James Hamlin
> Contractor
> 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.
> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström