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
- [rtcweb] Do we still need PRANSWER? Roman Shpount
- Re: [rtcweb] Do we still need PRANSWER? Chenxin
- Re: [rtcweb] Do we still need PRANSWER? Iñaki Baz Castillo
- Re: [rtcweb] Do we still need PRANSWER? Olle E. Johansson
- Re: [rtcweb] Do we still need PRANSWER? Roman Shpount
- Re: [rtcweb] Do we still need PRANSWER? Roman Shpount
- Re: [rtcweb] Do we still need PRANSWER? Iñaki Baz Castillo
- Re: [rtcweb] Do we still need PRANSWER? Olle E. Johansson
- Re: [rtcweb] Do we still need PRANSWER? Martin Thomson
- Re: [rtcweb] Do we still need PRANSWER? Roman Shpount