IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 20 March 2012 13:48 UTC

Return-Path: <ibc@aliax.net>
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 9419B21F8618 for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 06:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 jXmn2mzecVGO for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 06:48:54 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0709D21F858F for <rtcweb@ietf.org>; Tue, 20 Mar 2012 06:48:53 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so20748vbb.31 for <rtcweb@ietf.org>; Tue, 20 Mar 2012 06:48:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=P8k04JhPSNAImc2bx2ypLTUUWv6X9LXMQyKGFgc6JT8=; b=lVxLlojRYlXDwxAYj+sx/CGI7qdiWItmPqLUjCiTAPGB5t7kl1GwH8WASi9o8orlPK 6nKRoho9VWrWPPa1nbaL7gi0Lu8XpzMQlS/OuTrE9wNi8dqXNKFHtIEEtBSEMfaq+a1I gidROWw8uNFSd/NHIMtzs0/abECT8ngnnaAipGybwKeE9ExIGRHUXuUgnpUzs+gOyI+X 3iApBjXJEq5VMPuKxhlUcYA6dBkkPgb243QcUvVdVaT8tkJnObxXsgzqhHRKyybJxtRP iCfW+Q/RkIg4cE1Y/KhjyNV9iquVylwW/A6wZ1bRnDW1WFGkbVpnN8kOcThHW8s8Ehxl gUXA==
Received: by 10.52.27.1 with SMTP id p1mr7681150vdg.17.1332251333511; Tue, 20 Mar 2012 06:48:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 06:48:33 -0700 (PDT)
In-Reply-To: <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com>
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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Tue, 20 Mar 2012 14:48:33 +0100
Message-ID: <CALiegfnfoMvJ2EbAUoF5o_R_GNYSxMWAE1h+8Js1T8u5eKbc=Q@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmsoeW2IilKNqCoJIp2ewiZ6iE54FUfCfEiUaGuQSLVxpuKLUXBWtVaZWQU4hI1DXabqD7y
Cc: 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: Tue, 20 Mar 2012 13:48:54 -0000

2012/3/20 Roman Shpount <roman@telurix.com>:
> Once again, I understand how this helps in case of HTTPS, but how would this
> help in case of WebRTC? Media description is carried in some sort of
> application defined protocol (can even be transmitted over an encrypted SCTP
> data channel or encrypted in javaScript), so monitoring proxy cannot
> reliably modify it. I understand how it can be allowed to fake the signature
> on modified SDP by inserting a certificate in the browser, but how would the
> proxy get to the SDP in the first place?

That's up to the implementor, is not? This is: if a WebRTC provider
wants to monitor the media by modifying the SDP it should design some
system in which the SDP is carried by its systems (i.e. via HTTP(s) or
WebSocket).

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email