Re: [rtcweb] Resolving RTP/SDES question in Paris

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Fri, 23 March 2012 14:54 UTC

Return-Path: <andrew.hutton@siemens-enterprise.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 9D1CF21F851A for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 07:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level:
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599]
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 YGKfMdeTYOnK for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 07:54:34 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4E21F844C for <rtcweb@ietf.org>; Fri, 23 Mar 2012 07:54:34 -0700 (PDT)
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id ABA3C23F04CA; Fri, 23 Mar 2012 15:54:32 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 23 Mar 2012 15:54:32 +0100
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: Dan Wing <dwing@cisco.com>, 'Roman Shpount' <roman@telurix.com>, 'Harald Alvestrand' <harald@alvestrand.no>, 'Ted Hardie' <ted.ietf@gmail.com>
Date: Fri, 23 Mar 2012 15:54:31 +0100
Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris
Thread-Index: Ac0INr3Z1+RYf6xDTCirryldOl72eAARbPMAACGHm/A=
Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31296B58E75@MCHP058A.global-ad.net>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <CALiegfnkYVEpmPV-zSL_4wOY-HiFZN-qJCQCiioaS=5NaqhLZw@mail.gmail.com> <CAD5OKxvtOAxMBx6xDnyfTnEq76oDEm6uj1xL6wGjjrtKUAHy3g@mail.gmail.com> <CABcZeBNZiotPmCfT53uEo+O0xw4xv6tXW1M_G-3A5BHuncsduA@mail.gmail.com> <CAD5OKxvYOY5JZ2mYNGiH1poUBQkyOOycePFijH5H+SxtcdqujQ@mail.gmail.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com> <4F68A4CC.9090306@alvestrand.no> <CAD5OKxuiApLKRASc2YuBfkM_8h8wGDPPQ3TdOYGum2yauidA5A@mail.gmail.com> <4F6AECC6.8020004@alvestrand.no> <CAD5OKxsSUeMFYXZMZVqQFWdeEB=30HJuJ=mP9GaYkksBmp1mOA@mail.gmail.com> <03fa01cd087d$57899120$069cb360$@com>
In-Reply-To: <03fa01cd087d$57899120$069cb360$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
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: Fri, 23 Mar 2012 14:54:38 -0000

Hi Dan,

I don't think SIPREC has a solution to the particular problem that Roman is talking about and it would probably not be within scope of SIPREC to solve this even assuming that there is some SIP involved.

If the prison deployed its own RTCWeb application and restricted the prisoner to using only this application then of course there would be no problem with intercepting the media and a SIPREC type solution could be deployed with some kind of B2BUA which has access to both signaling and media initiating the media recording and of course informing the prisoner that they are being recorded.

However if the prisoner is allowed to access their lawyers RTCWeb application and download the JavaScript from there then SIPREC does not help the prison record the resulting media exchanged.

Regards
Andy 


> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Dan Wing
> Sent: 22 March 2012 22:44
> To: 'Roman Shpount'; 'Harald Alvestrand'; 'Ted Hardie'
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
> 
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > Behalf Of Roman Shpount
> > Sent: Thursday, March 22, 2012 7:19 AM
> > To: Harald Alvestrand
> > Cc: rtcweb@ietf.org
> > Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
> ...
> > Yes, I was worried about supporting the interceptor. This is all
> > related to my question of support of WebRTC applications in military,
> > prisons, or financial organizations. I think WebRTC would be
> completely
> > disabled in such locations unless web browser can be configured to
> > confirm to some sort of communications and monitoring policy. I do
> not
> > think enabling only certain applications is a sustainable solution,
> > since application can only be enabled based on its URL, but this in
> no
> > way implies that the actual protocol used for signaling exchange by
> > this application will stay the same. In the best case this will
> result
> > in tens of specialized monitoring rules that will need to be
> > maintained. In the worst case, WebRTC would be simply disabled. At
> this
> > point the only workable solution that I see is some sort of media
> proxy
> > protocol.
> 
> The SIPREC working group, formed in March 2010, has solutions for
> this problem.  The problem is not created by RTCWEB.  Disabling
> encryption is not necessary -- nor desirable.  "Jails" get brought up
> in this context often, so using that same example, consider a prisoner
> at a jail communicating with their lawyer.  The prisoner needs secure
> communications with their lawyer without the risk of the
> communications being leaked to the press by anyone along the media
> path.  For details see http://tools.ietf.org/wg/siprec/
> 
> We will have a brietf presentation on SIPREC during my session
> at RTCWEB, explaining how it can work with RTCWEB.
> 
> -d
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb