Re: [rtcweb] Same location media

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 20 October 2011 16:41 UTC

Return-Path: <bernard_aboba@hotmail.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 A6EDF21F8C13 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.397
X-Spam-Level:
X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l20p4S5LrNdx for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:41:48 -0700 (PDT)
Received: from blu0-omc1-s7.blu0.hotmail.com (blu0-omc1-s7.blu0.hotmail.com [65.55.116.18]) by ietfa.amsl.com (Postfix) with ESMTP id 070E921F8BBB for <rtcweb@ietf.org>; Thu, 20 Oct 2011 09:41:47 -0700 (PDT)
Received: from BLU152-W27 ([65.55.116.7]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:41:47 -0700
Message-ID: <BLU152-W274DC7DC92EF49307BC57D93EB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_a99b29c0-3f9e-4b58-8f2d-2e8b78c0ca8c_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: roman@telurix.com
Date: Thu, 20 Oct 2011 09:41:47 -0700
Importance: Normal
In-Reply-To: <CAD5OKxuJi_VS9fRc4P6GN-StWzMhMHAQ2MyO8zJVsMfEeQRftg@mail.gmail.com>
References: <CAD5OKxuJi_VS9fRc4P6GN-StWzMhMHAQ2MyO8zJVsMfEeQRftg@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2011 16:41:47.0818 (UTC) FILETIME=[28E0E8A0:01CC8F47]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Same location media
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, 20 Oct 2011 16:41:48 -0000

Roman said: 


"Few additional points related to this:

1. This is what Flash is doing now for streaming media. It does not need consent to send media to the same server that sent the flash app.

2. I am not sure we standardized that only IP addresses are allowed in media description. DNS names might still be allowed then this issue will become the issue of doing a literal match.


3. There is still a security issue with ICE: we validate that STUN request can be processed, but not that the media actually should be accepted from this application. In some sense, current Flash cross domain polices are stricter, since they not only validate that media is acceptable at this IP but that it is acceptable from the app served from particular server.


In general, I think this is a good thing if I can get readily available hardware components and connect RTC clients to my existing infrastructure (I do have an JavaScript/HTTP to SIP proxy solution already). If we are not breaking anything by doing this, there might be some benefit for allowing this. But on the other hand, I already got ICE/SRTP to non-ICE/RTP media proxy as well, so if this is not supported I will not suffer much :)."

[BA]  Good points.  

One of the requirements in the use case document is the ability to work across firewalls that do not permit UDP.  In practice, this constraint is encountered surprisingly often (as much as 15-25% of the time, in enterprise scenarios).   The implication is that ICE will require a fallback, such as sending media over HTTP.   In a fallback situation, requiring ICE would be silly, since it has typically failed in order for fallback to be considered.