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

"Bernard Aboba" <> Tue, 10 November 2009 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D53413A6836 for <>; Mon, 9 Nov 2009 19:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.252
X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=1.347, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kr3q4LdlO0xF for <>; Mon, 9 Nov 2009 19:30:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B51DB3A635F for <>; Mon, 9 Nov 2009 19:30:47 -0800 (PST)
Received: from BLU137-DS3 ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 19:31:14 -0800
X-Originating-IP: []
X-Originating-Email: []
Message-ID: <BLU137-DS3E4BCD0CD54026197E49893AB0@phx.gbl>
From: Bernard Aboba <>
References: <>
In-Reply-To: <>
Date: Mon, 09 Nov 2009 19:17:21 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcphpykSUsCixUtqTVOlQEfXK0PdsQACLHQg
Content-Language: en-us
X-OriginalArrivalTime: 10 Nov 2009 03:31:14.0426 (UTC) FILETIME=[417EEDA0:01CA61B6]
Subject: Re: [dispatch] Introducing ViPR: a new federation technology
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2009 03:30:48 -0000

Kevin Fleming said:

" I came away with the same conclusion you did; it's really only applicable
to closely-aligned parties that want to federate, not for any  providers
that may provide SIP connectivity in between the parties that want to
federate. This would make it somewhat complex to deploy in a hosted PBX
scenario, unless the ViPR server was also virtualized to provide a separate
set of data for each hosted PBX that chose to use ViPR."

I'm not sure that it's only applicable to closely-aligned parties.  As
noted, the DHT approach does scale logarithmically.  Although one might
quibble with some of the dependencies (e.g. SRP/TLS is encumbered by
multiple IPR declarations, as is RELOAD), the overall approach does not
require pre-existing trust between the parties. 

There are existing approaches for moderate numbers of closely-aligned
parties (e.g. DUNDI works at that scale, and even the existing RFC 3261
model isn't that broken in for that case, since I'm aware of customers who
are federating with dozens of suppliers/customers using TLS with mutual

The bigger issue as I see it is the tying of SIP federation in non-VOIP
scenarios (e.g. Video, Web conferencing, IM&P) to PSTN and phone number
identifiers.  In those scenarios, the proposed introduction and verification
mechanisms aren't much better than existing "buddy list" techniques for
trust establishment.  Those techniques have been in use for a long time
(e.g. in XMPP federation) and have proven quite effective.  

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
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

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.