IETF Logo Mail Archive

Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type

worley@ariadne.com Fri, 08 May 2020 01:19 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336203A0A74 for <avt@ietfa.amsl.com>; Thu, 7 May 2020 18:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 sGAvRVziTr4u for <avt@ietfa.amsl.com>; Thu, 7 May 2020 18:19:40 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E29F3A0A4A for <avt@ietf.org>; Thu, 7 May 2020 18:19:39 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id WrMyj7vD44063WrfujG5tJ; Fri, 08 May 2020 01:19:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1588900778; bh=9bEMO7Cf1bBirZT8X1YQRekqCBlzTeVO/Huh19Dur3M=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Qt0FrV9bcSFH0yoynIqWXm521phJWevC0REnvLFra6x7lk2Bmc4yIXNLAhEluLxh6 YCdop43eHasE0UvVxShTDSPShG8FE2vzbRy6GBBDokH6HyIkm0CTkcDom/6uUeygIM 8TYVyHWUpCInDN/MZAl3qvyqi/zCbHyE5rxhPoWHARPwmfaFkv13Frgsg4jibXHLWp JUTXHLOqurJgVvSCMGhHQwC22M9ZXyR6JuM0PDkGrZIZEQ7jFfRONG1O/7clfQaXS+ vFFP5IYEgzZSKPfojeqqedDM1aw9fBmOnRimjN6uxNhaS5QA0GpmD/Ke0mAokCBIEb gpqyYKPH/xRVQ==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with ESMTPA id WrfsjGGDgIU0ZWrftjKsxE; Fri, 08 May 2020 01:19:38 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0481JZMR028164; Thu, 7 May 2020 21:19:36 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0481JYtP028152; Thu, 7 May 2020 21:19:34 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Cc: avt@ietf.org
In-Reply-To: <b14513ac-c8f2-7e54-75d9-d2c7f67c3f97@omnitor.se> (gunnar.hellstrom@omnitor.se)
Sender: worley@ariadne.com
Date: Thu, 07 May 2020 21:19:33 -0400
Message-ID: <878si39qai.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/-3ychPCeLNLLhGwrGICkl88TZXg>
Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 01:19:43 -0000

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> writes:
> Therefore I 
> also doubt that current RTP implementations are easy to request to watch 
> out for new SSRCs. I took a look into one RTP implementation, and yes, I 
> found some traces of a possibility to look for new SSRCs, but also other 
> places where the method documented in RTP to detect a shift of SSRC for 
> an existing stream by seeing 50 packets received with the new SSRC.

Yes, it sounds like that's the crux.  While it's easy enough to say that
the protocol has the fields to allow that the packets all have the same
encoding and need to be sorted into separate streams based on the SSRCs,
the usage has always been that SSRCs change infrequently, e.g. video
cuts.  And that means that the implementations likely all embed that
assumption.

Dale

v2.23.0 | Report a Bug | By Email