Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Roman Shpount <roman@telurix.com> Fri, 21 June 2013 15:58 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 E116821F9FB6 for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 08:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.704
X-Spam-Level:
X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 4NXW50sZCJgP for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 08:58:47 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5021E8133 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 08:58:42 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id e11so6533059wgh.6 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 08:58:42 -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=Pshpph95MQtGgt9ACIlqhz0W/nBwBvwG2itzLdERuns=; b=DMa9Sj6C9MtOS1vxr9gfPacXgtaB47EpHdy9qiJQpmJ3iHHaBfjNkTEhhNlyBH/Yt0 0iJNFYbFDfT8r77QESK9lS0kNYFDuKNk51UMAAyp/bx9GYz7hygUwXR9ouo9GzPinDpt YyFyLSNWmy27ZFJrReEcGPLg7UVmqgR7WV+bn9MZagEOElcLLNnS8nZmb6/O49KS6mus X06f/oa+M1fLFKUQfCTO3Y5mWJSh86f2RTqb3x8KijmN4idvvp6sWuthgXRcBGGCUre2 xodIxAyGzCIGwqFYsLWANdkb2EkqGOz4nnhcMH0Q6MdZGLvLOlE7ucyu0D57HnpV56c5 H5Gg==
X-Received: by 10.180.85.195 with SMTP id j3mr3255405wiz.26.1371830322049; Fri, 21 Jun 2013 08:58:42 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [2a00:1450:400c:c03::236]) by mx.google.com with ESMTPSA id o14sm23852506wiv.3.2013.06.21.08.58.40 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 08:58:40 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id p60so6649851wes.27 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 08:58:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.21.209 with SMTP id x17mr3170521wie.47.1371830319777; Fri, 21 Jun 2013 08:58:39 -0700 (PDT)
Received: by 10.216.221.202 with HTTP; Fri, 21 Jun 2013 08:58:39 -0700 (PDT)
In-Reply-To: <CALiegfmPV=E2qh_E-v_eBiSj9iK7Un2JLDtELF7xnYARHy5B3g@mail.gmail.com>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <CABkgnnWfV=5xBaRqAddqUURThs9J4T4+0HK4Ux07VA51r5oC3Q@mail.gmail.com> <CAJrXDUFNGKvWHw-yqeApEdTeuqMNPTDxvdKZ2DuzANmcR2y2CQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <CAJrXDUHCkQSLab2UuY_vWP3Gr8uh+++c9mDq5f4sCpuaK5aeLQ@mail.gmail.com> <51C1B907.8060508@hookflash.com> <CAJrXDUG06jvPvhfNwZ6Puzxj7E4XxELG_fU=S7B_c=tnC9eoNQ@mail.gmail.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <CAJrXDUGOYc_Z_qWD7J0ZzVdfwYOacH_p5PjZEg5aP1LUetffMA@mail.gmail.com> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <CABkgnnWw9anT+h_hnF14nBChS73qpTb31hSM=p2KnGrcRPGRJA@mail.gmail.com> <51C3209B.1030501@alvestrand.no> <CALiegfkEpwxNZL8TU0ofCzRB_Gza+NoSnZpGcM=tuYBOXmHsZQ@mail.gmail.com> <51C335F9.4000900@alvestrand.no> <CALiegfk_wwvdSixFYWpBBdUNfXxmcOwCnRsjyS6J3M9WG_dJCg@mail.gmail.com> <51C38356.3020402@jitsi.org> <CALiegfm1xYpAnmrg=4vx_06RZQTo_RS2nFJoidpoQtjg2kn=Vw@mail.gmail.com> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <CALiegfmPV=E2qh_E-v_eBiSj9iK7Un2JLDtELF7xnYARHy5B3g@mail.gmail.com>
Date: Fri, 21 Jun 2013 11:58:39 -0400
Message-ID: <CAD5OKxs52j95nw6fiP-rEE3kz08TLPZEr=+XHi2eQDc3-oZidg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=047d7b874000e70f8004dfac228f
X-Gm-Message-State: ALoCoQmwZeOvQurKJslF9w64oPqdZ1L6Z8LypSJKm+atvPmmJRgeihxK2F8X3zEhS5pzoGzUM+0B
Cc: "diopmamadou@doubango.org" <diopmamadou@doubango.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
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: Fri, 21 Jun 2013 15:58:48 -0000

On Fri, Jun 21, 2013 at 6:19 AM, Iñaki Baz Castillo <ibc@aliax.net>; wrote:

> Is there anyone not involved in SIP/PSTN business which feels
> comfortable with the SDP-based specs of WebRTC?
>

I am involved with SIP/PSTN and I am not comfortable with current WebRTC.

What is trivial to implement is a server based gateway that will terminate
and transcode media and signaling connection from WebRTC and connect WebRTC
to anything. For this you take the open source code which implements WebRTC
in Chrome, put it in your server and put a real SIP stack/media engine on
the other side. This way all the SDP negotiation and media decoding is done
using the same code as in the browser, and SIP/SDP negotiation on the
SIP/PSTN side is done using normal SIP stack. By normal SIP stack I mean
something that has been used with PSTN for significant period of time and
has all the interop issues resolved, and all the necessary configuration
parameters needed to work with SIP network implemented. Issues like hold do
not matter, since they are handled on the SIP side and not passed to WebRTC
side at all. Codec support, DTLS, ICE do not matter since they are handled
by the WebRTC engine in the server. If this is what you want you have
achieved your goal, but this is not a standard. There is no guarantee that
this will work in 5 years or even in 6 month, since SDP produced by WebRTC
can change. There is no guarantee that this will work with all the WebRTC
implementations, since the standard is loose enough that significant things
can be different while still being standard compliant. Finally, and most
importantly, this will not work if you want to pass SDP and media produced
by WebRTC to the outside world without transcoding it.

P.S. Not to offend anybody, but if you create a system any idiot can use,
only idiots will.
_____________
Roman Shpount