Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

Hadriel Kaplan <> Mon, 12 September 2011 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E0E521F8EEC for <>; Mon, 12 Sep 2011 16:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aTGvuOZ8k+b0 for <>; Mon, 12 Sep 2011 16:15:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 57AE221F8EEA for <>; Mon, 12 Sep 2011 16:15:38 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 12 Sep 2011 19:17:35 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Mon, 12 Sep 2011 19:17:35 -0400
From: Hadriel Kaplan <>
To: Paul Kyzivat <>
Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
Thread-Index: AQHMcaInV9u+0Arv+EmqYITZjPuIBw==
Date: Mon, 12 Sep 2011 23:17:34 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan> <> <> <> <> <> <>, <> <>, <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<>" <>
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Sep 2011 23:15:39 -0000

On Sep 12, 2011, at 12:42 PM, Paul Kyzivat wrote:

> The harder point is knowing *what* is required in the interop case.
> If the goal is to avoid needing a media gateway in this case, then what is required will be determined as part of the O/A. Or it can contractually negotiated for each different federation target.
> Hadriel seems to be arguing that a media gateway will always be needed in the federation case. Making that assumption will certainly simplify rtcweb, but it also ensures a cost for federation. It is essentially the same cost that is incurred when sip users and service providers require the use of SBCs at their borders. So far that has been a cost that people have willingly paid.

I am not arguing a media gateway would always be needed for federation.  I said one would be needed to interface/federate with SIP in the PSTN.  Between two rtcweb domains, no media gateway would/should be required. (there may be one anyway, but hopefully not just to make the call work for interop)

> Then the discussion has been about people arguing for different partitionings - mostly extremes. Some that I am seeing:
> 1) (Cullen) everything should be negotiated by o/a in the browser.
>   (Presumably with some interaction with JS for ICE candidate
>   selection.) The logical conclusion of this (I'm not sure Cullen
>   is arguing for this) is that capneg must be included and used
>   to handle the security negotiation.

Only if SRTP is optional - if it's mandatory to use always, then obviously you don't need cap-neg for it.

> 2) (Hadriel?) The security mechanism, and use of ICE,
>   is fixed for rtcweb. ICE candidate selection and all the
>   rest of o/a is handled in JS.

Right - if the rtcweb application as a whole needs to use SDP offer/answer at all, it could do so in the JS or in the server.  The browser should stay the heck away from it.  Browsers should be as dumb as we can keep them.  That's the secret sauce to successful web apps, imho - the client browser is dumb, but the javascript its executing is smart.  The browser doesn't know I'm browsing emails in gmail.  It's just executing code issuing API calls for GUI elements.  If an Operating System came with an RTP library built into it, would you therefor expect the operating system to do SDP offer/answer?  Or would you expect it to expose an API of discrete RTP attributes/settings for the application to interface to and do with as it wished?