Re: [AVTCORE] Multi-party real-time text Issue 4: Motivation for not using RTP translator

Gunnar Hellström <> Tue, 12 May 2020 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE1173A0885 for <>; Tue, 12 May 2020 12:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WGMEZr5aOAq7 for <>; Tue, 12 May 2020 12:12:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CDB23A0898 for <>; Tue, 12 May 2020 12:12:00 -0700 (PDT)
Received: from [] ( []) (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) (Authenticated sender: by (Postfix) with ESMTPSA id F33A420637; Tue, 12 May 2020 21:11:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1589310718; bh=W159JEq1N86RCNYGXAJTAnJcRl7SeY2fMGyUwDUZK+E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SOyNMujhvX1FQxGSb0Td5NvH8TERJ9grmqBCCFwZGawJvmEJ3ioRcieHULhEqP3EL dwfJp30c5P/wX5jAEPQH5jWfwpDMD4PmcVRdQZZbdRp+oMSnl3Bx3/lwLTKKe7Wv1X cuGJPdj+FoCDtZ7e7zvyStB1nL86ixleA4RnOIvs=
To: "Dale R. Worley" <>, Gunnar Hellström <>
References: <>
From: Gunnar Hellström <>
Message-ID: <>
Date: Tue, 12 May 2020 21:11:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Multi-party real-time text Issue 4: Motivation for not using RTP translator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2020 19:12:05 -0000


Assuming that we will stay with an RTP based solution, I made one more 
effort to create a motivation for not using the RTP translator model.

Den 2020-05-08 kl. 03:19, skrev Dale R. Worley:
> Gunnar Hellstrom <> 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

New proposed text in the introduction as solution to issue 4.

     1.1 Selected solution and considered alternative

    The mechanism specified in the present document makes use of the RTP
    mixer model specified in RFC3550.
    From some points of view, use of
    the RTP translator model specified in RFC 3550 would be more
    efficient, because then the text packets can pass the translator 
with only
    minor modification.  However, there may be a lack of support
    for the translator model in existing RTP implementations, and 
therefore the more common    RTP-mixer model was selected.



> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström