Re: [AVTCORE] RTP Topology addition (was: Design choice comments..._

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 23 March 2015 12:32 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ABF1A88EA for <avt@ietfa.amsl.com>; Mon, 23 Mar 2015 05:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 hkddaUl9ijel for <avt@ietfa.amsl.com>; Mon, 23 Mar 2015 05:32:18 -0700 (PDT)
Received: from BLU004-OMC3S6.hotmail.com (blu004-omc3s6.hotmail.com [65.55.116.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACCF1A88EB for <avt@ietf.org>; Mon, 23 Mar 2015 05:32:18 -0700 (PDT)
Received: from BLU406-EAS165 ([65.55.116.73]) by BLU004-OMC3S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 23 Mar 2015 05:32:17 -0700
X-TMN: [heZp069uuquXLhvYAzBg+CLxZH6my7L+]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS165B4E21E5587735C8417B4930D0@phx.gbl>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
Date: Mon, 23 Mar 2015 07:32:16 -0500
References: <0683D6CB32AC424D8AF52C0F660E5DC56B9497A2@xmb-aln-x10.cisco.com> <550F8A3C.4060900@ericsson.com> <016101d0655e$383d5860$a8b80920$@gmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
In-Reply-To: <016101d0655e$383d5860$a8b80920$@gmail.com>
X-OriginalArrivalTime: 23 Mar 2015 12:32:17.0417 (UTC) FILETIME=[662E7F90:01D06565]
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/TiR2MwYnU0kWtg_B5FTR3alRLVI>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "David Benham (dbenham)" <dbenham@cisco.com>, IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] RTP Topology addition (was: Design choice comments..._
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Mon, 23 Mar 2015 12:32:21 -0000

In any case the issues go beyond switching - any MANE that modifies the sequence number or SSRC field will have a problem, regardless of whether supports switching or not.

> On Mar 23, 2015, at 6:41 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
> 
> Hi,
> My concerns were not about the term translator but like Magnus is saying lack of  a description of this entity you defining.
> I also think that the name "switched conferencing environment" is not correct you are only talking about switched media and not conference. Conference has more aspects than just media switching (e.g. conference control,..) which are as you say out of scope. 
> 
> Roni
> 
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
>> Sent: 23 March, 2015 5:36 AM
>> To: David Benham (dbenham); Roni Even; 'IETF AVTCore WG'
>> Subject: Re: RTP Topology addition (was: Design choice comments..._
>> 
>> On 2015-03-22 16:45, David Benham (dbenham) wrote:
>>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] To me when looking at
>>>> what is called switching conference server it seems that this is not
>>>> a conference server but maybe just an some sort of RTP translator or
>>>> maybe what we called a media server (RFC5576 section
>>>> 6)
>>> 
>>> First and foremost, we've been wanting to work on the security-centric
>>> requirements and not prematurely limit the RTP
>>> topologies.   To that end, and at the risk of pre-empting the
>>> discussion during agenda, we'll propose a design team meet to discuss
>>> ways to convey elements of cryptographic context that is as friendly
>>> to as many RTP topologies as possible.    Not unlike the design team
>>> focused on 'congestion management' issues and which meet back in Dec
>>> after IETF91.
>> 
>> Good.
>> 
>>> 
>>> That said, and to your RTP translator observation, wish to explore
>>> adding another RTP topology called "RTP Translator Forwarding Switch
>>> (RTFS).   Channeling Steve Wenger's post shortly before IETF 91,  '
>>> ..topologies document is never really done' or something like that.
>>> Can I get this started and in to the topologies doc update?
>> 
>> As one of the authors of the document. Currently passed working group last call
>> and updated and ready for publication request, I say maybe.
>> But, please understand that we thought we was currently done.
>> 
>> I think you need to start by actually describing in which way this RTFS is
>> different from the RTP mixer or the SFM. Is this really different from what is
>> already described, or simply a variant?
>> 
>> Thus, please provide text to describe this thing you want to add.
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt