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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 23 March 2015 03:36 UTC

Return-Path: <magnus.westerlund@ericsson.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 AFF2C1A87C1 for <avt@ietfa.amsl.com>; Sun, 22 Mar 2015 20:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 tjOmHoz_Endb for <avt@ietfa.amsl.com>; Sun, 22 Mar 2015 20:36:36 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C631A87BF for <avt@ietf.org>; Sun, 22 Mar 2015 20:36:35 -0700 (PDT)
X-AuditID: c1b4fb25-f79126d000004b89-26-550f8a42430c
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.4F.19337.24A8F055; Mon, 23 Mar 2015 04:36:34 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Mon, 23 Mar 2015 04:36:33 +0100
Message-ID: <550F8A3C.4060900@ericsson.com>
Date: Sun, 22 Mar 2015 22:36:28 -0500
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "David Benham (dbenham)" <dbenham@cisco.com>, Roni Even <ron.even.tlv@gmail.com>, 'IETF AVTCore WG' <avt@ietf.org>
References: <0683D6CB32AC424D8AF52C0F660E5DC56B9497A2@xmb-aln-x10.cisco.com>
In-Reply-To: <0683D6CB32AC424D8AF52C0F660E5DC56B9497A2@xmb-aln-x10.cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvja5TF3+owckFAhYve1ayW5z5NY/J 4m87swOzx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6MSc8XsxV8E6i4eLCbtYHx Gm8XIyeHhICJxNqmaWwQtpjEhXvrgWwuDiGBI4wSF9sus0A4yxkl1jz7zwhSxSugLbHhVBsz iM0ioCrxae5BsDibgIXEzR+NYJNEBYIlfrbvZoKoF5Q4OfMJC4gtIlAhMffNVLC4sICzxNNT F1hBbCEBH4lZXbfYQWxOAV+J5z+/AtVzcDALaEqs36UPEmYWkJdo3jqbGaJcW6KhqYN1AqPA LCQbZiF0zELSsYCReRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYJge3PJbdQfj5TeOhxgF OBiVeHg3NPKHCrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB 0fDYki2V354z9iyQ6O/tCVp9appnVtctXz8NRe5flz/HZr55wjl1Cs8Gm32cjV+bChuetT1+ 0bcy0X5h1dImc6tXs/5edli7YNrfcrvsjAl/rS6a3nrW5uEv/6NxRuv+1yKTEvNL33Dceqh9 yyvqWxL/h1eeKo0aeWoMayc7hmYIlduf8HzJpsRSnJFoqMVcVJwIANpPF5c0AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/MdWvFKo175Xzbk6PQ79vZHG0JJM>
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 03:36:37 -0000

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
----------------------------------------------------------------------