Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Iñaki Baz Castillo <ibc@aliax.net> Thu, 22 September 2011 18:18 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 9989221F8C5F for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 11:18:30 -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 3kQ9txcdsPkH for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 11:18:30 -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 BA9441F0C65 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 11:18:20 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so863945vcb.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 11:20:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.9.129 with SMTP id l1mr642864vcl.87.1316715652597; Thu, 22 Sep 2011 11:20:52 -0700 (PDT)
Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 11:20:52 -0700 (PDT)
In-Reply-To: <4E7B7272.7020204@alvestrand.no>
References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <ED2DB00E-A64B-405F-96AC-2269258F6FFC@cisco.com> <4E799ECC.8030306@ericsson.com> <DB6B2796-9762-47CA-9A45-62476146DF04@cisco.com> <4E7B7272.7020204@alvestrand.no>
Date: Thu, 22 Sep 2011 20:20:52 +0200
Message-ID: <CALiegfkWv9wPj8N3FLT2UpksHARp7qdSXTJVTSEyBpL7pdujcg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
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 18:18:30 -0000

2011/9/22 Harald Alvestrand <harald@alvestrand.no>no>:
> Magnus' analysis worries me a bit, because it seems to assume specific
> functionality in the gateway (tracking of state and ability to generate SIP
> messages depending on state).
> It seems reasonably simple to build a gateway, but we quickly get to the
> point where we have to write standards for the gateway function .... which
> could lead us down rather deep ratholes.

Are we assuming that a media gateway will be required for RTP/media
communication between a WebRTC client (web browser) and a SIP node?
If such decision is taken IMHO it's sad.

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