Re: [AVT] RTP translator or mixer for multi-party real-time text

Colin Perkins <csp@csperkins.org> Tue, 18 August 2009 15:00 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC83B3A6E4C for <avt@core3.amsl.com>; Tue, 18 Aug 2009 08:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.632
X-Spam-Level:
X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T62RxbCd5E5p for <avt@core3.amsl.com>; Tue, 18 Aug 2009 08:00:07 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 4F03528C251 for <avt@ietf.org>; Tue, 18 Aug 2009 08:00:07 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1MdQAJ-0007ST-bw; Tue, 18 Aug 2009 14:59:59 +0000
Message-Id: <0193CD3B-9B4D-4D8F-99C7-7E1E3256DE27@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
In-Reply-To: <010701ca0a88$a21d7530$e800a8c0@GunnarH>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 18 Aug 2009 15:59:58 +0100
References: <010701ca0a88$a21d7530$e800a8c0@GunnarH>
X-Mailer: Apple Mail (2.936)
Cc: avt IETF <avt@ietf.org>
Subject: Re: [AVT] RTP translator or mixer for multi-party real-time text
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 18 Aug 2009 15:00:09 -0000

On 22 Jul 2009, at 05:55, Gunnar Hellstrom wrote:
> A new version of draft-hellstrom-text-conference is available at
> http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-01.txt
>
>
> It brings up the question if the RTP translator model or mixer model  
> shall be specified for multi-party real-time text.
>
> In its earlier version, only the translator model was mentioned,  
> using multiple SSRCs as source identification in one single RTP  
> session. That, in fact seemed not to require any additional  
> standardisation.
>
> However, two problems have been identified with the RTP translator  
> model:
>
> 1. Some RTP implementations do not implement support for multiple  
> SSRC:s in the same session. There is a risk that it will cause  
> failures.
>
> 2. When adding a new stream to the session, a new SSRC is started to  
> be used. There seems to be a habit in RTP to throw away some initial  
> packets until it is clearly evident that the new SSRC represents an  
> added source. This behaviour is very unfavourable for real-time  
> text, where information can be carried from the first packet.
>
> Because of these problems, the RTP mixer model has been briefly   
> introduced as an alternative, requireing an in-line source  
> identification in the text medium.
>
> It is of course not favourable to have two alternatives for one  
> task. Therefore I ask: were the comments on the translator model  
> valid, and can anything be done about them,

There are certainly poor-quality implementations that behaviour in the  
way you describe, but that's a limitation of the implementation,  
rather than the protocol. A draft giving guidance to implementers  
would be a good thing to have.

> or shall we move to only specifying the mixer model?


No, since there are some topologies where it's not suitable (an ASM  
multicast group, for example). Your draft could usefully go through  
each of the topologies describe in RFC 5117, and explain how real-time  
text can be used in each.


-- 
Colin Perkins
http://csperkins.org/