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

Justin Uberti <> Wed, 19 February 2020 04:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40D6812089B for <>; Tue, 18 Feb 2020 20:01:23 -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 QvSMsfLnPW1X for <>; Tue, 18 Feb 2020 20:01:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE59312089E for <>; Tue, 18 Feb 2020 20:01:19 -0800 (PST)
Received: by with SMTP id o187so6228353vka.2 for <>; Tue, 18 Feb 2020 20:01:19 -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=qXcIj/Aw/KKwXRv7I3asEjQAGo/pWxjXMRsOgI5lkms=; b=bzBfNK8JhHV80i7sD+81HDmFLatLne31J/2uuuhBQtN7Z1jTu95bfDaBlRf0KrH3ts FvLf8eAw4uOFNyVcDOr5eRfUd5XTRBwkxmOmM17rvxnFtCnUf2GzclBaDbEBKm1qi74u opefeT/uWA1+R0rdgb2sxsqTrp3LUKaeoUF/KqrhzEstaRxmjVAC0Kf2f8D4VvY31KZN dkIc9UH+IFW+7ENvtu47abURVpsJXQBmRgsdzj5yf/zJfJmMCVmZuU6ZYimKpAz/qRLC EabD0A0/irIGvajiK/pZnmUhdUIy8lKnXhz6uOZBEzheyLrrau8uQ3X9Joz8z8T3EUIB S9zw==
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=qXcIj/Aw/KKwXRv7I3asEjQAGo/pWxjXMRsOgI5lkms=; b=QxwwAnS55BM7V2pnRzKOIXzXkZ9f4ihJQbtqV4VPJA2uZpdsrapAIvVjBSYmxm5uIT g9dA/JRZdO/jeW6FVmEQl7X69w7Pe3XpMcuFFsI5EfP9npBcZxjdaeZnhQrqq9xwcl3y 1031w10/j7/84ju8zzkp9YakM+dOewdH+WmNKu0VbNKTazGMzEz5MN7eqgY1aPlU88GE 2ZBZxhtOagIAV+Q5GKcYsWNfxh4vln2JxOcFk5xiKlDUb11epJSL/8XEPmnb6rs5fdx5 ipdbFjYK+xNKuBY3GubnxSXhdaRshzybcHP2eLfvqBxYplpKCNKYzkc0jOVhpUjelPu/ 058A==
X-Gm-Message-State: APjAAAW5TUNgYvCtKsMZol/KS437D5C4u2npuipLihYkM0P2MhQc3sIx hPjdzw9ifzCqR1IjXickTbaYzXnNC+S22I6nJ5tj4w==
X-Google-Smtp-Source: APXvYqwQYU5CD7GDmgkl0jOlCV1Gw+opkKU5Oc9behCvhDlHbPzFLxV9GoGRTkEOPz919bDG2yt4to1koRA69FPQf3U=
X-Received: by 2002:ac5:c1c7:: with SMTP id g7mr10291416vkk.97.1582084878433; Tue, 18 Feb 2020 20:01:18 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Tue, 18 Feb 2020 20:01:06 -0800
Message-ID: <>
To: Spencer Dawkins at IETF <>
Cc: Ross Finlayson <>, "Cullen Jennings (fluffy)" <>, Jonathan Rosenberg <>, Jonathan Rosenberg <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000002fbcd8059ee5d74e"
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: Wed, 19 Feb 2020 04:01:23 -0000

On Tue, Feb 18, 2020 at 2:47 PM Spencer Dawkins at IETF <> wrote:

> I am also hoping for clarity here, or at least clue.
> On Tue, Feb 18, 2020 at 2:02 PM Ross Finlayson <>
> wrote:
>> > On Feb 19, 2020, at 5:12 AM, Jonathan Rosenberg <>
>> wrote:
>> >
>> > Also to be clear - whilst I agree that RTP on QUIC is interesting - it
>> is not in scope because httpbis is our target, not quic. We want to allow
>> voice signaling and media to run over web infrastructure services, so http
>> is our 'waist of the hourglass' not quic.
>> So just to clarify here:  Is your goal (for this protocol) that media be
>> transferred only over streams (TCP or (reliable) QUIC), not datagrams?
>> Consequently, how important is end-to-end latency for audio/video calls
>> that would use this protocol?
>> And are peer-to-peer audio/video calls (that would not involve a web
>> server at all, except perhaps for initial end-user lookup/discovery) out of
>> scope for this protocol?
>> If that's the case, then you’re not really ‘replacing’ RTP, but rather
>> defining a new media transport protocol to be used in this one (restricted,
>> but important) environment: Transport using reliable protocols via web
>> server(s).  And if that’s the case, then I’m concerned that your SIP
>> replacement (i.e., replacement of the one thing that’s truly broken, and
>> needs replacing) might end up being too restrictive for more general media
>> transport (datagrams and/or peer-to-peer).
> I think I arrived at the same place as Ross, coming from the opposite
> direction. ("Thunk!")
> ISTM that the proposal floating through here for a new media transport
> protocol, if it is successful, would be useful for non-RIPT applications as
> well, and ISTM that other proposals for RTP over QUIC (or whatever we're
> all muttering about privately), if one of them is successful, might be
> useful for RIPT applications as well.
> So, the first suggestion I'd make at the BOF, if work on media transport
> of whatever flavor is still part of the proposed RIPT charter, is to split
> it off into a separate proposal, which I'd love to see go forward on its
> own, unless there are really strong reasons why RIPT signaling
> specification work and RIPT media transport work need to be coupled, need
> to fate-share, and need to compete for attention in the same working group.
> I can say more about that at a mike in Vancouver, but let me start with
> this, on a mailing list ...

Spencer -

I agree that the signaling and media transport aspects are separable, but
ultimately many applications will deploy them together, and perhaps
multiplex them over the same HTTP transport. As such, there's definitely
value in having a WG that considers the overall problem space and the
various interactions between the layers (I think there are actually 3
layers - signaling, session descriptions, and media transport).

Certainly worth discussing further though.

> Best,
> Spencer
>> Ross Finlayson
>> Live Networks, Inc.
>> --
> V3 mailing list