Re: [dispatch] Introducing ViPR: a new federation technology

Klaus Darilion <klaus.mailinglists@pernau.at> Tue, 10 November 2009 15:02 UTC

Return-Path: <klaus.mailinglists@pernau.at>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C363A689F for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 07:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.244
X-Spam-Level:
X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 WRfFVHJeA37R for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 07:02:26 -0800 (PST)
Received: from ds3000.pernau.at (ds3000.pernau.at [88.198.53.113]) by core3.amsl.com (Postfix) with ESMTP id E41723A67F1 for <dispatch@ietf.org>; Tue, 10 Nov 2009 07:02:25 -0800 (PST)
Received: from [10.10.0.51] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTP id 3B98610805D6; Tue, 10 Nov 2009 16:02:52 +0100 (CET)
Message-ID: <4AF9809C.1040004@pernau.at>
Date: Tue, 10 Nov 2009 16:02:52 +0100
From: Klaus Darilion <klaus.mailinglists@pernau.at>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <mailman.5685.1257817361.4669.dispatch@ietf.org> <BLU137-DS3E4BCD0CD54026197E49893AB0@phx.gbl>
In-Reply-To: <BLU137-DS3E4BCD0CD54026197E49893AB0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Introducing ViPR: a new federation technology
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 15:02:26 -0000

Bernard Aboba schrieb:
> Also, if one buys the arguments, then one could conclude that all that is
> necessary for VOIP bypass is a PRI and an Internet connection.  Why bother
> with SIP trunking? However, that argument assumes that as the decline in the

It is not about PRI vs. SIP trunking, but about PSTN connectivity vs. 
adhoc SIP peering.

The trust is based on a phone call that happened on the PSTN (PSTN means 
telcos/carriers with interconnect and customers connected to those telcos).

It does not matter which technology the telcos use for interconnection 
or for connections of its customers. E.g. an enterprise which already 
uses a SIP trunk to a SIP service provider is also connected to the 
PSTN. That mean for routes which are not routable with ViPR the SIP 
trunk as used as the SIP trunk is part of the PSTN.

regards
klaus

> PSTN accelerates that SIP Trunking providers will utilize infrastructure
> ENUM to their advantage to route calls directly over the Internet without
> passing on the savings to customers. 
> 
> However, the evolution of Internet peering would indicate this not the most
> likely outcome.  Back in the mid-1990s, peering was a significant issue for
> second Tier ISPs and access cost much more than it does today.  Today recent
> measurements show that 50 percent of Internet traffic is originating in only
> 150 ASes, and that kind of consolidation also tends to go along with major
> declines in consumer costs and an lessening of importance of peering
> concerns.  
> 
> So my own guess is that as SIP trunking becomes a commodity that the
> industry will grow more and more competitive and that in a decade
> infrastructure ENUM will apply to a very large fraction of all calls, with
> the benefits being passed on to customers. 
> 
> In that kind of scenario, ViPR would be unnecessary. 
> 
>