Re: [dispatch] IETF 116 - do you have something for DISPATCH?

Dapeng Liu <> Wed, 08 March 2023 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE0EBC14CF1D for <>; Tue, 7 Mar 2023 23:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 7WXmD0u0LV8a for <>; Tue, 7 Mar 2023 23:42:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 99F79C14CF18 for <>; Tue, 7 Mar 2023 23:42:09 -0800 (PST)
Received: by with SMTP id d8so302545pgm.3 for <>; Tue, 07 Mar 2023 23:42:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1678261328; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=npW6ZIhmmp6jhNkqlYx5cYs0840e3jXAG74SUG7Y15k=; b=DoJiWOJ8ZMxJU7xqX3QnA0H8LDPJIEo8AIKPthS3JTIfiffeGXN06ciCXIUYjvpx1n 4HCiAA1G7yr0tfdXFPTXFmzAO4+HJOCVktZI+1AetxW23l5K5Nf+W7f0LL8KtMHsZ+tM X44ZltZ0kEGChHnCYLor0/0ZAUsCzAfOr+gTw382//zVDNCrVHSKf1+F1HfyH9qwj1L7 naU5YXhCMS16fASsqH63oh4DyREHC+prI1DjJmaqLURZKQKrrV1jz91JOj4e4Q2l5zKj yQMuMCGHJrfLdumAjiLVyWVNeP2n2+m3hrsRX40N1l673l01wNZJOHUQgS3OHYDwnrfK SCOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1678261328; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=npW6ZIhmmp6jhNkqlYx5cYs0840e3jXAG74SUG7Y15k=; b=1lo0ULAQJqfpDVpvgZGb1875rj8epjjyWWu+G3jCPCsPberomHQEfrxgTeqgNBEzoG i3UoGemZh179wvUYPbfEw5c3ZbHRRWEtTf2fqIf5UpDtdk+pW1dq7GJTUPpYIra94t+p n6XI9hdSmSl6H7aqUlf7qProqwBzuTVOx3RTCny0PRc+deRTYSwpffwmY9d8s+XemUaA lq0ErpNYOqeYU8PcXupvgluRk2NMakXaHtkXMdhtEJziiW1568D6rkJcC5PU/iHDwv15 y60lyBhAQka17mjY8h4BkyWAoguCN708bRqyXIHxkg60idPwMelC5Kp6btKMyjzGBS1G 7I6g==
X-Gm-Message-State: AO0yUKV85XMPathxyLS4RfMoj6WtKk3tkDTsZO3O3a4vIu+lSBbLeDcs 1BRNvSkMl9MW0tcyQSnt7ZWUmCiX3hwHJdqk71tK3EwrpBLzlwf1
X-Google-Smtp-Source: AK7set8Yyw3XeHPOOZLXE2/q9jRcwgjwm8E3YsvkuimIwJlvuRWcfeH1HWPFJTJLJpSotj6T0L3WWsXD7JC4Mtkgvoo=
X-Received: by 2002:a62:d115:0:b0:593:af1e:15b with SMTP id z21-20020a62d115000000b00593af1e015bmr7144399pfg.4.1678261327685; Tue, 07 Mar 2023 23:42:07 -0800 (PST)
MIME-Version: 1.0
From: Dapeng Liu <>
Date: Wed, 08 Mar 2023 15:41:55 +0800
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000046edd905f65eaa46"
Archived-At: <>
Subject: Re: [dispatch] IETF 116 - do you have something for DISPATCH?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Mar 2023 07:42:12 -0000

On Tue, 21 Feb 2023 06:40:27 +0000 "Pengshuping (Peng Shuping)"
<> <;> wrote:

> It's that time again - we're calling for agenda topics for our next
> meeting at IETF 116 (25 - 31 Mar 2023). No matter how big or small, if you
> have something you'd like dispatching or that you think will be of interest
> to the ART AREA, get in touch and get involved.

Hello Shuping, Kirsty:

We have submitted a draft regarding the "Protocol for interactive
low-latency media transmission system".

The background is:
Interactive online broadcasting is getting popular with the growth of short
videos, online education, online gaming, and other similar applications.
Interactive online broadcasting service is flexible and much more
complicated compared with traditional media broadcasting service.

For interactive Online broadcasting applications, audiences may
occasionally request to set up bidirectional real-time communication with
the broadcaster and all the other audiences should be able to receive the
merged interactive media traffic containing the broadcaster and connected
audience. To meet this end, there is a need for a standardized signaling
protocol that can support media stream merging, switching, and pulling to
support those complicated scenarios.

For more detail:

May I request a time slot to present this draft to gather more input from
the group and discuss how to move forward?

Best Regards,
Dapeng(Max)  Liu