Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need

Roman Shpount <> Thu, 05 April 2012 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59A8A11E8073 for <>; Wed, 4 Apr 2012 19:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3z+2fb08VCFS for <>; Wed, 4 Apr 2012 19:14:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F76121F851D for <>; Wed, 4 Apr 2012 19:14:05 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so898701pbb.31 for <>; Wed, 04 Apr 2012 19:14:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5QqjEZV0EHx3dAUaUfS5SfpZiLNYRRe9G9OeH1GxH8s=; b=Ql1JgneA2rAIQzH+gVjFuxKKTbUvff5EWVXIYh1WV7L39ThfakTE3FYfczN7gvOlle Gxn1ytm8Sl7gWd7H3NWXB95HyGSwg3DyYWMKepcwhsjBhYMBMXk2/dLDwcklSE6t0jtw wXIDhoxgCKaXJTU6NbFJ+DHPH0lMdiV1jIYNpl/4sGzZBS7rjhy1qUsR1+T0bx5/B+cm 2mSyHNWoDzJR4H4t7Hp6S1Q+yG3ujP6SwTobPxyS+ZW7NFb5ZZOfuCkUQKP5D/b6XypT XATxs2xLZ6XXxvHzsKV5cYmqW/1+Ljcnw7GSK2j+zIoN4IEnH2c64pI0zPisBhLT9N3S gNaA==
Received: by with SMTP id im10mr2486973pbc.156.1333592045130; Wed, 04 Apr 2012 19:14:05 -0700 (PDT)
Received: from ( []) by with ESMTPS id d2sm1848659pbw.39.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 19:14:04 -0700 (PDT)
Received: by dady13 with SMTP id y13so1355238dad.27 for <>; Wed, 04 Apr 2012 19:14:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id tg10mr2398497pbc.57.1333592042656; Wed, 04 Apr 2012 19:14:02 -0700 (PDT)
Received: by with HTTP; Wed, 4 Apr 2012 19:14:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 04 Apr 2012 22:14:02 -0400
Message-ID: <>
From: Roman Shpount <>
To: jesse <>
Content-Type: multipart/alternative; boundary="047d7b339ccffa53d604bce51752"
X-Gm-Message-State: ALoCoQn9s13uS9LN/LshEO+np7BOfZpADF6UsYrkXvCQPhVyu/MNZ7jn+fvPAKR+bUKaSNOujjUz
Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
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: Thu, 05 Apr 2012 02:14:08 -0000

On Wed, Apr 4, 2012 at 8:42 PM, jesse <> wrote:

> On Apr 4, 2012 10:24 AM, "Roman Shpount" <> wrote:
> >
> > My assumption is that IP phones will migrate to WebRTC effectively
> eliminating SIP in end user devices.
> That is your academic assumption, why does IT department need to spend
> extra money to either desert or upgrade its existing SIP devices without
> substantial gain? After all, tons of users are still using window xp.
> Backward capability is a key to the success of new technology.
Please note the <sarcasm> tags.

On the more serious note, very few SIP end points offer working ICE
support. So, in a large sense, interop with them is not an option. Out of
the ones that do support ICE and SRTP, very few are actually connected
directly to a public internet. Most of them are connected to some sort of
PBX or an IP PBX type service. So, in reality you do not need to bridge
every IP phone with WebRTC. If a few PBX and hosted centrex vendors will
add support for WebRTC required features, we will get compatibility with
existing end points. To support the rest you will need to deploy some sort
of gateway.

In my personal opinion, tons of users use XP due to the fact that never MS
OS versions do not offer a significant reason to upgrade, while introducing
enough usability and operational issues to create a significant upgrade
hurdle (I am trying to be politically correct here). WebRTC enabled end
points, on the other hand, will offer significant benefits to traditional
SIP phones, since they will allow development of higher quality integrated
real time communications services. I hope this will drive a much quicker
standard adoption.
Roman Shpount