Re: [Edm] Few comments on draft-edm-protocol-greasing-02

Cullen Jennings <fluffy@iii.ca> Mon, 06 November 2023 11:34 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491FCC09BB66 for <edm@ietfa.amsl.com>; Mon, 6 Nov 2023 03:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1e1XifDyDKD for <edm@ietfa.amsl.com>; Mon, 6 Nov 2023 03:34:42 -0800 (PST)
Received: from smtp111.iad3b.emailsrvr.com (smtp111.iad3b.emailsrvr.com [146.20.161.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477CDC18771C for <edm@iab.org>; Mon, 6 Nov 2023 03:34:42 -0800 (PST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp22.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 41D13600AE; Mon, 6 Nov 2023 06:34:40 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CALGR9oZQmSo_9u0Ekmt5pttO7Ai-AcGVKO7y3nTgtm4A+JEObg@mail.gmail.com>
Date: Mon, 06 Nov 2023 12:34:46 +0100
Cc: edm@iab.org, Tommy Pauly <tpauly@apple.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FBFA366-CCD8-430C-BEFC-8C5B8255ECC5@iii.ca>
References: <E601A23F-D22A-422E-9739-E04BF85EFB46@iii.ca> <CALGR9oZQmSo_9u0Ekmt5pttO7Ai-AcGVKO7y3nTgtm4A+JEObg@mail.gmail.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
X-Classification-ID: 1ef1fbe3-6246-472e-a2dd-22fa645b743f-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/NQ4eNwewWWkTK6nezv77m9kiwOA>
Subject: Re: [Edm] Few comments on draft-edm-protocol-greasing-02
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2023 11:34:44 -0000

On the questions of examples of

> 1) incorrect assumptions on ordering of options and/or,
> 2) incorrect assumptions that the bits will forever land in the same location in the packet. 
> 
> …snipp. 
> 
> Do you have some concrete examples of the issues (1) and (2)? 

Many SIP phones, some very widely deployed, look like they were implemented by reading wireshark traces, not the RFC. On theses some common problems seen include:

A. Assumptions the RTP header extensions would always be in the same order 

B. Assumptions that the CSRC list in RTP would always be of length 0 or 1. 

B. SDP allows some of it parameters to be at session level or media level. Some implementation assumed parameters are only allowed at one of those two levels. 

Many networks deploy middle boxes called Sessions Border Controllers (SBC) to rewrite the SIP and RTP from theses devices to fix it.