Re: [rtcweb] Do we still need PRANSWER?

Roman Shpount <roman@telurix.com> Thu, 05 July 2012 11:54 UTC

Return-Path: <roman@telurix.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 F048221F855B for <rtcweb@ietfa.amsl.com>; Thu, 5 Jul 2012 04:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.939
X-Spam-Level:
X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VRXS0FBEQhDr for <rtcweb@ietfa.amsl.com>; Thu, 5 Jul 2012 04:54:58 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 940A321F844B for <rtcweb@ietf.org>; Thu, 5 Jul 2012 04:54:58 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so8092439ghb.31 for <rtcweb@ietf.org>; Thu, 05 Jul 2012 04:55:11 -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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=U7TgQ/7sisqbAYv6fU/nwnvdqbdJqKGch+IDwZgiAe8=; b=bgm0qDNJwLzQczG6UhTImo6pEmFxyeFW0rtjqK176YEcoUPGDYHIQ7Z1qq5h8IjIcX BejWHdkGa4mcIk/hP+1e/phlNQP35eNY0mujv5GbTJpyeY33+Ss33ZkuUO2BxSDFAhbc oyt/uQRvIDg9VoPyAOlMWI8451GWBiGiW+VsPa3EEFaaSB+dJ308h6FaRaBNYboZtPJj kiP994MslMmsz3SkjMnI42XY0ne+GMLex8S81GR0HvcK5jWHkds2+RYKvByWcyJNrBSM 2DZBoCP0mthswZLj76HmSQ3TYDzFJwescncouBaZn4ixgDgdMhg7oRz6bP9yAnA/J88w tXNg==
Received: by 10.236.146.104 with SMTP id q68mr29382417yhj.28.1341489311645; Thu, 05 Jul 2012 04:55:11 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id a79sm11350758yhk.16.2012.07.05.04.55.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jul 2012 04:55:10 -0700 (PDT)
Received: by yenq13 with SMTP id q13so8067648yen.31 for <rtcweb@ietf.org>; Thu, 05 Jul 2012 04:55:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.72.163 with SMTP id e3mr15532834pav.42.1341489308408; Thu, 05 Jul 2012 04:55:08 -0700 (PDT)
Received: by 10.68.194.202 with HTTP; Thu, 5 Jul 2012 04:55:08 -0700 (PDT)
In-Reply-To: <A31099AA-3753-47AC-B1CC-F44B610AD45E@edvina.net>
References: <CAD5OKxui0XeYA8GOnNCkPin_XjOoNvEHeQq1OcmEJ1aYpbF3_A@mail.gmail.com> <A31099AA-3753-47AC-B1CC-F44B610AD45E@edvina.net>
Date: Thu, 05 Jul 2012 07:55:08 -0400
Message-ID: <CAD5OKxsmCJF3SbBd1idf5RoP1ktWF9=U=3nXXXYoJ7-tZ9_oCQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "Olle E. Johansson" <oej@edvina.net>
Content-Type: multipart/alternative; boundary="f46d042ef79db29c5f04c413d127"
X-Gm-Message-State: ALoCoQkAkAY9XNo+K2w7S/lOShu6hteLkKwzzrkAK3OwiTJCCutCOsoTSpLK8yaw1eBYQR0NRFPH
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Do we still need PRANSWER?
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, 05 Jul 2012 11:55:00 -0000

On Thu, Jul 5, 2012 at 5:12 AM, Olle E. Johansson <oej@edvina.net> wrote:

>
> 4 jul 2012 kl. 21:46 skrev Roman Shpount:
>
> > It looks like WebRTC-SIP interop without an application layer gateway
> would not be possible in the near future due to all the media transport
> requirements that were introduced. Given that SIP interop is no longer
> possible
>
> I think that's a bad conclusion, Roman.
>
> I talked about the installed base of SIP devices and their RTP stack. It
> doesn't mean that ALL SIP implementations won't be able to interop with
> WebRTC and that there never will be SIP connected to webrtc, either in a
> browser app or in a server implementation. I do expect that new SIP apps
> will arise and that the current ones will be upgrading.
>
> SIP interop is definitely possible in WebRTC regardless of the RTP layer.
>
> I still think there's value in interop with a large installed base of
> RTP-capable devices. Having media relays in the media path is known not to
> improve media quality.
>
>
If we care about interop with existing devices something needs to be done
about DTLS-SRTP and ICE.

As far as I can see DTLS-SRTP is the major problem since it overly complex.
It is probably not a problem for desktop/softphone applications that can
use something like openssl or gnu-tls with DTLS-SRTP extension, but if you
need to write this from scratch for an embedded platform, this protocol has
too many features for no good reason. We would have been better of
designing a new key negotiation mechanism that has the same qualities as
DTLS-SRTP (ie uses public/private key exchange for session keys and
protects from replay), but does not introduce the initial call setup delay
or has so many features and options. This would, obviously, still mean that
existing devices need to implement a new protocol to interop with WebRTC,
but at least it would be a simpler protocol to implement and test.

I know that the group still discusses the use of SDES-SRTP, but I do not
think it satisfies the security requirements (ie it is not secure over
HTTP, allows replay, not secure if JavaScript is compromised), so if we
care about security, it should not be allowed.

ICE on the other hand is an understandable requirement, but it is still
something that is very badly supported by existing devices. On the positive
note, it is at least claimed to be supported by some vendors, and they are
typically quicker to fix bugs then to add features.

The group is also talking about AVPF, RTP retransmissions and other RTP
extensions, that typically break interop with existing devices. I think
these extensions are fairly acceptable if some sort of media relay device
is assumed, but would need to considered very carefully if legacy interop
is needed.

I think if the group operates under assumption that vast majority of the
WebRTC calls would be between WebRTC end points, and only a small portion
with communicate with legacy devices, such as SIP or Jingle, and would
require a media gateway for it, then it should be spelled out. If interop
is a priority, or even a hard requirement, then some of the design
decisions should be different. Keep in mind, that support legacy interop
will have significant negative impact on WebRTC, since it will has to be
more complex (support more parameter negotiations, more RTP profiles, more
key exchange mechanisms), and probably less secure.
_____________
Roman Shpount