From nobody Mon Nov 30 09:56:26 2020 Return-Path: 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 694813A1074 for ; Mon, 30 Nov 2020 09:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 bfVUI59dpYbp for ; Mon, 30 Nov 2020 09:56:22 -0800 (PST) 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 B91993A105B for ; Mon, 30 Nov 2020 09:56:19 -0800 (PST) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0AUHuE52065716 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 30 Nov 2020 11:56:15 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1606758976; bh=t0xFtF8hDvXzhyaecMCnSzzGrq8OguNFI7XjDN/HR2I=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=iXhyeZSWPHrOq2ZOqIhyrD6t2Yvbd9jdKOdS+4XjUeEgQvmP1O1zK+8thrz8xbsyT xiUcRL9rVJ/NOzDkOO+hI9LHgbHdbdqjjcEvTdCFmhdQrLijTyxEPpGlk2b6t4/ETm XPG6VH1endwAfRYtC0n874BJWfWt77Pw6lfx3m6U= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Ben Campbell , "dispatch@ietf.org" Cc: Alex Gouaillard References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> From: Adam Roach Message-ID: <06c5e46a-49b4-8e04-78ed-4f343268ce7a@nostrum.com> Date: Mon, 30 Nov 2020 11:56:09 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> Content-Type: multipart/alternative; boundary="------------39059C837EA2F45F44FEF870" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 17:56:25 -0000 This is a multi-part message in MIME format. --------------39059C837EA2F45F44FEF870 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Having read through the proposal and watched the corresponding segment of the DISPATCH meeting from two weeks ago, I think that having something like this standardized would be very useful, both for the handful of broadcasting tools that exist as well as for the various WebRTC broadcast networks that are being deployed. So I definitely think we should pursue this work in the IETF. It's a little less clear to me whether we want to slot this into something like MMUSIC or to create a short-lived working group. I'm leaning towards the second, for a couple of reasons. First, I found Ted's comments at the DISPATCH meeting to be kind of illuminating as far as the kinds of additional work that might be necessary (and I have my own list of things that might need some refinement, like negotiation of authentication mechanisms); and that nudges the effort into a "maybe a little larger than just one work item in a long-standing working group." More importantly, this work straddles the real-time media and web disciplines, and I'd like to make sure we have people from the latter group putting eyes on it. I seriously doubt we can get HTTP experts showing up at MMUSIC, but there's at least a fair chance that we might get them interested in a lower-volume mailing list such as a dedicated WHIP WG. I think this mirrors, for the most part, the tentative conclusion that came out of the DISPATCH discussion earlier this month. If we decide to take this path of creating a short-lived WG, I'm happy to help craft a charter and plan to be actively involved in the technical work. /a On 10/28/2020 3:10 PM, Ben Campbell wrote: > 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 >> > > 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://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://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 >> >> >> 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 > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------39059C837EA2F45F44FEF870 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Having read through the proposal and watched the corresponding segment of the DISPATCH meeting from two weeks ago, I think that having something like this standardized would be very useful, both for the handful of broadcasting tools that exist as well as for the various WebRTC broadcast networks that are being deployed.

So I definitely think we should pursue this work in the IETF.

It's a little less clear to me whether we want to slot this into something like MMUSIC or to create a short-lived working group. I'm leaning towards the second, for a couple of reasons. First, I found Ted's comments at the DISPATCH meeting to be kind of illuminating as far as the kinds of additional work that might be necessary (and I have my own list of things that might need some refinement, like negotiation of authentication mechanisms); and that nudges the effort into a "maybe a little larger than just one work item in a long-standing working group." More importantly, this work straddles the real-time media and web disciplines, and I'd like to make sure we have people from the latter group putting eyes on it. I seriously doubt we can get HTTP experts showing up at MMUSIC, but there's at least a fair chance that we might get them interested in a lower-volume mailing list such as a dedicated WHIP WG.

I think this mirrors, for the most part, the tentative conclusion that came out of the DISPATCH discussion earlier this month. If we decide to take this path of creating a short-lived WG, I'm happy to help craft a charter and plan to be actively involved in the technical work.

/a


On 10/28/2020 3:10 PM, Ben Campbell wrote:
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:


We have already implemented it on Janus and Medooze media servers:


And added support into a WebRTC version of OBS studio:


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


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--------------39059C837EA2F45F44FEF870--