Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol

Ben Campbell <ben@nostrum.com> Wed, 28 October 2020 20:10 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B13A09AD for <dispatch@ietfa.amsl.com>; Wed, 28 Oct 2020 13:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.096
X-Spam-Level: *
X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, MAY_BE_FORGED=2.499, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 c2FFeTH8IwlF for <dispatch@ietfa.amsl.com>; Wed, 28 Oct 2020 13:10:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19793A09A8 for <dispatch@ietf.org>; Wed, 28 Oct 2020 13:10:15 -0700 (PDT)
Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 09SKAB25026965 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Oct 2020 15:10:12 -0500 (CDT) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1603915813; bh=m3s7ankboPAWPfqLhtFUwBkGvMmr74EHKhpsnORBhTw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lnpO40u5DRwD2x2mmZ0xCVukbbmAmbebWqdY+iXpU6O9u/QMNcvrLSED+zIe6zol1 qQ1YFTAyI8oHo27wmMqUQsspSFEHegIcB6HnlgaA0/aM5i3tt7j+0mHcRx3Fhd62d9 TRo3X0KRO4Q1YAPMDEOBcqJonNxK3Jv2DFMoyqmQ=
X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan
From: Ben Campbell <ben@nostrum.com>
Message-Id: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_28AE3F78-E33E-41BE-9B6C-44C4E5A11FDF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 28 Oct 2020 15:10:04 -0500
In-Reply-To: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com>
Cc: Alex Gouaillard <dralex@millicast.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, Patrick McManus <mcmanus@ducksong.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/u6_gAZ8AXvg4Sas9Hanq3-87UAc>
Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 20:10:18 -0000

Hi Everyone,

Did anyone have feedback or other thoughts on Sergio’s proposal?

Thanks!

Ben.

> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
> 
> Hi all!
> 
> 
> 
> While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.
> 
> These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.
> 
> The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.
> 
> We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:
> 
> https://tools.ietf.org/html/draft-murillo-whip-00 <https://tools.ietf.org/html/draft-murillo-whip-00>
> https://github.com/murillo128/webrtc-http-ingest-protocol/ <https://github.com/murillo128/webrtc-http-ingest-protocol/>
> 
> We have already implemented it on Janus and Medooze media servers:
> 
> https://www.meetecho.com/blog/whip-janus/ <https://www.meetecho.com/blog/whip-janus/>
> https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 <https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7>
> 
> And added support into a WebRTC version of OBS studio:
> 
> https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2 <https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2>
> 
> We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.
> 
> 
> 
> What would be the best way of moving this forward? Obviously, any feedback will be very welcome.
> 
> 
> 
> Best regards
> 
> Sergio
> 
> 
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch