Re: [dispatch] VIPR - proposed charter version 3

Adam Roach <adam@nostrum.com> Tue, 06 July 2010 15:39 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DF83A63C9; Tue, 6 Jul 2010 08:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ2lixciOyQq; Tue, 6 Jul 2010 08:39:36 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E16523A67E5; Tue, 6 Jul 2010 08:39:35 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o66FdZJL020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 10:39:35 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4C334E37.10200@nostrum.com>
Date: Tue, 06 Jul 2010 10:39:35 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Peter Musgrave <peter.musgrave@magorcorp.com>
Subject: Re: [dispatch] VIPR - proposed charter version 3
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F40FB@307622ANEX5.global.avaya.com> <AANLkTinCs4ooaP7qczjOf_CMJB2tZg9XR9Ro5H-WWHK6@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F4219@307622ANEX5.global.avaya.com> <001201cb1ade$4195f680$c4c1e380$@us> <AANLkTimGO9mf_q78EYJJ_UwuM834m3vJ0i4BiGqEB4KJ@mail.gmail.com> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> <AANLkTimfo4UVcjS9N2Es01_GOZnWcYH7Bc2iRmPRQTXZ@mail.gmail.com> <4C333D8E.6090505@nostrum.com> <AANLkTilIbT7hNvCwPeXxOoaQb2kD0x95o5LiPBry8e-D@mail.gmail.com>
In-Reply-To: <AANLkTilIbT7hNvCwPeXxOoaQb2kD0x95o5LiPBry8e-D@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH <dispatch@ietf.org>, Richard Shockey <richard@shockey.us>, IETF-Discussion list <ietf@ietf.org>, jonathan@rosen.net
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 15:39:37 -0000

  On 7/6/10 10:00 AM, Peter Musgrave wrote:
> Yeah. Sigh.
>
> I guess the issue then becomes whether this is enough of a step in 
> right direction that it can be built on - and whether it's worth the 
> effort.
>
> Cullen/Jonathan - can you speak to any of the operational issues 
> w.r.t. 'failure surprise' in the existing implementation?

Well, to be clear, with voice communications, you don't end up with 
"random failure surprise". You end up with "random quality surprise". 
Some of your voice communications go over whatever codec your device 
uses for VoIP, which is probably a nice broadband codec. But some calls 
will randomly use the PSTN, with an 8 kHz sampling frequency and a 
notch-pass filter at 2600 Hz.

While that's kind of an unpleasant property, it's not enough to 
disqualify it from normal business use.

My point was that it's not a reasonable multimedia solution. If all 
you're looking for is feature parity with the PSTN, it's a passable 
solution, even if just barely.

/a