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. > >
- [dispatch] Introducing ViPR: a new federation tec… Jonathan Rosenberg
- Re: [dispatch] Introducing ViPR: a new federation… Richard Shockey
- Re: [dispatch] Introducing ViPR: a new federation… Kevin P. Fleming
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Henry Sinnreich
- Re: [dispatch] Introducing ViPR: a new federation… Jonathan Rosenberg
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Bernard Aboba
- Re: [dispatch] Introducing ViPR: a new federation… Klaus Darilion
- Re: [dispatch] Introducing ViPR: a new federation… Klaus Darilion
- Re: [dispatch] Introducing ViPR: a new federation… Paul Kyzivat