Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Iñaki Baz Castillo <ibc@aliax.net> Thu, 22 September 2011 11:05 UTC

Return-Path: <ibc@aliax.net>
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 EA5C221F8CF9 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 04:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 C2NzVHUjShmk for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 04:05:51 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3E21F8CE0 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 04:05:51 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so463621vcb.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 04:08:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.180.6 with SMTP id bs6mr484764vcb.122.1316689701851; Thu, 22 Sep 2011 04:08:21 -0700 (PDT)
Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 04:08:21 -0700 (PDT)
In-Reply-To: <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com>
Date: Thu, 22 Sep 2011 13:08:21 +0200
Message-ID: <CALiegfmxjP5ojZeAoz6sYUkKwE7XOtTSGJAOydbX+sm23hrwjg@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
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, 22 Sep 2011 11:05:52 -0000

2011/9/22 Hadriel Kaplan <HKaplan@acmepacket.com>:
>> All of the above are clear barriers against legacy interoperability.
>
> Yup.  I don't doubt we'll need some form of media-plane gateway either in the web server or separate to interop with legacy - I'm just trying to keep it from becoming so expensive and complicated that it would be cheaper/easier/better to use SIP softclients or plugins instead.

I can understand that some requirements can be imposed to RTCweb
environments in the media plane, but try at least to make it
compatible with VoIP networks out there. For example, requiring SRTP o
ZRTP could make sense (anyhow I don't see why that should be a
requirement in a local intranet in which plain-RTP is already used for
SIP communication).

If WebRTC forces the creation of media gateways when
intercommunicating with other RTP worlds (SIP, XMPP) that's not good
at all. Adding requirements it's ok, making it impossible by design is
not.

Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>