Re: [rtcweb] Back-to-back RTP endpoint topology in RTCWeb

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 14 June 2012 07:15 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E821F866D for <rtcweb@ietfa.amsl.com>; Thu, 14 Jun 2012 00:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCz+odpa4F2K for <rtcweb@ietfa.amsl.com>; Thu, 14 Jun 2012 00:15:43 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E8DC021F8671 for <rtcweb@ietf.org>; Thu, 14 Jun 2012 00:15:42 -0700 (PDT)
X-AuditID: c1b4fb25-b7fbf6d000002e5d-9c-4fd98f981a43
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4E.A9.11869.89F89DF4; Thu, 14 Jun 2012 09:15:37 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Thu, 14 Jun 2012 09:15:35 +0200
Message-ID: <4FD98F97.6020506@ericsson.com>
Date: Thu, 14 Jun 2012 09:15:35 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
References: <387F9047F55E8C42850AD6B3A7A03C6C160497E6@inba-mail02.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160497E6@inba-mail02.sonusnet.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre7M/pv+Bv83s1ncOn2GxWLtv3Z2 ByaPJUt+Mnlc+vyfPYApissmJTUnsyy1SN8ugStj6rsVTAULRCrWbm9nbmBcItDFyMkhIWAi 8fHmNhYIW0ziwr31bCC2kMApRombb1W6GLmA7OWMElOenGQCSfAKaEu8fLWRGcRmEVCVWHjm HSOIzSZgIXHzRyNYs6hAsMSLPVdYIeoFJU7OfAK2QASo5vbSzWA1zALqEncWn2MHsYUFLCVW 9Zxih1jsL9F6pROsnlMgQOL80nesEMdJStxrXw3Vqycx5WoLI4QtL9G8dTYzRK+2RENTB+sE RqFZSFbPQtIyC0nLAkbmVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgSF8cMtv1R2Md86JHGKU 5mBREue13rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjq7ra4ox4QTm7dSds92//+Ov/ /8nuMx7a6bauUmsX35z0MtFPLrCo+1pac8SvpAkv+7wElJZyyX3qlju28I/H2v8yvzXfWQZp Cn1bWpsZyXO7/fratb6dPE2PdbjnsBpqlaqbb33Ec26Zxz6PmYauvCIBbwtW5JjEf7qX0eN1 s3bleqv9uUpKLMUZiYZazEXFiQA0oEb2LwIAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Back-to-back RTP endpoint topology in RTCWeb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2012 07:15:44 -0000

Hi Partha,

I think there is several different realizations of this.

If you goal is only to hide one end-points IP address to the other it
can be the relay topology, with an 1-1 participation. In fact you don't
really need to discuss this as an RTP topology at all as all operations
are on IP and Transport level. A TURN server will do perform this hiding
in one direction. A web service controlled relay node could do this for
both end-points.

If your goal is something additional I would claim that this falls in
the broad category of things gateways do. The problem is as soon as you
enable any RTP/RTCP level of modifications you end up as node needing to
be trusted and part of the security contexts.

I didn't bring up gateways as they are a bit undefined in their
operations as it depends on which aspect they need to change. My general
classification of gateways are that they are devices that lets the
combination of the peer end-point plus the gateway look like a node
expected or at least supported by the communicating party.

Cheers

Magnus


On 2012-06-13 12:46, Ravindran, Parthasarathi wrote:
> Hi Magnus & all,
> 
> I like the list of RTP topology mentioned in your interim
> presentation. I thought of asking for one more topology namely
> Back-to-back RTP endpoint topology in RTCWeb. The topology is as
> follows:
> 
> RTP endpoint-----Back-to-back RTP Endpoint-----RTP Endpoint
> 
> The reason for Back-to-back RTP Endpoint topology are
> 
> 1) WebRTC RTP Endpoint to legacy RTP Endpoint (RFC 3550) interop 2)
> IP address hiding in WebRTC session
> 
> Even though, Back-to-back RTP Endpoint *MUST* follow RTP Endpoint
> behavior, the requirement will be bit more than that as the linkage
> with identity, ICE consent, RTCP mandate, set of RTP draft mandates
> and other stuffs. Also, the guidelines document for back-to-back RTP
> Endpoint shall avoid the blame of intermediate devices always break
> the architecture.
> 
> I'm interested in hearing whether Back-to-back RTP endpoint topology
> is of interest in RTCWeb.
> 
> Thanks Partha


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------