Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below

Justin Uberti <> Sat, 15 February 2020 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F84C120052 for <>; Fri, 14 Feb 2020 23:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hu76NqF76jMU for <>; Fri, 14 Feb 2020 23:55:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E72C6120274 for <>; Fri, 14 Feb 2020 23:55:06 -0800 (PST)
Received: by with SMTP id v141so7350283vsv.12 for <>; Fri, 14 Feb 2020 23:55:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YGc0EvLDPWS/2GFkmK9zjRTlPZTjbupTcjHV9YcVfmI=; b=FZckHrkUeuBOoKe08KWcTq7KVga0G+0lx79Uv1LUlu5Xr8+O70cOx1P4IrdyZ5Kj5n xAV4vokik4BMddXCa9qAFLzba8YNafdtpGDjKYm/OkyYOlvvQ+8AMNELz1ptcPfcMfFR J39jxGTx7+dgOgzvx2cOqgjegJKOgQqyEdnVAKfVGuXFwV71gICyYipRwmFOJOxC2pS9 ZFlNXOG8iam1SKG34xeBNYGoZ7aJabOEpk3LUA74DSBdw00fbbcZOFUVYZVpjgdvy3kw OGH5aRCq9mF7V+KpSMoTSOpwjQg9kWaxAOClSKWplH9sCo79tXj1g3ncgNQAhGggWOaP qCkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YGc0EvLDPWS/2GFkmK9zjRTlPZTjbupTcjHV9YcVfmI=; b=KiIVpK5d8oo8bjaOFMZOezbnH9JwEwtD/TyZaE3FfSliBCTDpSIiASkRuxQCfXGdHe FQNlFCOFN1BeyNLmzTe7FjJ+ryO50tztHeLZb6QTevcGRBmF96MyJCXRGpxZmqqH4qkI wkmm2ZzfzX8FeS9URisWvon08Z19O7NneAGl3jgw0kce4BnFmSedXwewNX4H0S69/LDQ aitkgmUu5PmOeK7AW7tb03D8uBcVSai3dkoWvT8qsKT6DYZJVNWEAq/m6sw/VFBEus+V hYAgRlk2vJCBo7SYUVv5b7YL0D1FgxKxkMXhL0C+paHSfyXGD7DUltsFrLKbnUGamsT2 5ang==
X-Gm-Message-State: APjAAAWrLYO3CZqMuZC1NCfpCvg23193K+12Z5GrjoqiCDAd7Vb+k7G7 dPXNYAhAv9oj6pP2uCQ8qdjdIoNjom295cWiNNHqSA==
X-Google-Smtp-Source: APXvYqxMdoXAEyLvFxUThbPQpmCCcrcu/otA3YkhRg8myK61K9o9iKm21th5Ir59fN0w1b8kz+tk2FA85zupRkM4iwc=
X-Received: by 2002:a67:8dc8:: with SMTP id p191mr3562312vsd.231.1581753305518; Fri, 14 Feb 2020 23:55:05 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Fri, 14 Feb 2020 23:54:53 -0800
Message-ID: <>
To: Ross Finlayson <>
Cc: "" <>, "Cullen Jennings (fluffy)" <>, Jonathan Rosenberg <>, Jonathan Rosenberg <>, Spencer Dawkins at IETF <>
Content-Type: multipart/alternative; boundary="000000000000e61bc1059e98a38f"
Archived-At: <>
Subject: Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Feb 2020 07:55:10 -0000

On Fri, Feb 14, 2020 at 10:00 PM Ross Finlayson <>

> On Feb 15, 2020, at 1:15 PM, Jonathan Rosenberg <>
> wrote:
> >
> > RTP is in scope, in that, RIPT replaces RTP (and SDP and SIP).
> >
> > Basically, the output of the codec is placed into something called a
> 'media chunk' which adds a few parameters which are similar to RTP (i.e.,
> timestamp) and then sent in a PUT request or GET response.
> Jonathan is ‘handwaving’ a bit here :-), as he understands (more than just
> about anyone) that replicating the functionality of RTP would involve a lot
> more than just adding a few parameters to PUT and GET.  For each media type
> being transported, you’d need to define how data is best framed within
> (QUIC) datagrams, how (optional) FEC could be used, what RTCP XR
> functionality will be retained (and how), how (the equivalent of) RTP
> header options would be defined/carried, etc. etc. etc.  Essentially, you’d
> be replicating all of the work that took place (over several years) within
> AVT to define a RTP payload format for each media type.  Therefore...
> > No doubt an issue of contention will be whether we should just
> encapsulate RTP vs. whats in the draft.
> If we want to get something standardized/working quickly, then this is a
> ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets directly
> in QUIC datagrams - in such a way that the existing RTP payload format
> defined for each media type could map directly (i.e., with no more
> media-specific IETF standardization work required).  Even if this means
> that there's some duplication of functionality between RTP and QUIC
> (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)

Yes, this is my preferred approach. There still will be a lot of work just
to get this up and running, figure out how congestion control works in this
world, and avoid ending up with a lot of bloat from the encapsulation.
Assuming this works, we get fairly straightforward gatewaying between the
old and new worlds.

> While - at some point in the future - it may be worthwhile defining a new
> version (v3?) of RTP that works more efficiently with QUIC, this should not
> be something that we require before we define/standardize a replacement for
> SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to show
> its age, but it’s not broken, and has lots of existing deployment that
> could, ideally, be leveraged quickly within a SIP replacement.
> Ross Finlayson
> Live Networks, Inc.
> --
> V3 mailing list