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

"Bernard Aboba" <bernard_aboba@hotmail.com> Tue, 10 November 2009 08:32 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 778DB28C11A for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 00:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.975
X-Spam-Level:
X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6]
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 XO0fvQXOP-VH for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 00:32:01 -0800 (PST)
Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by core3.amsl.com (Postfix) with ESMTP id 5844728C121 for <dispatch@ietf.org>; Tue, 10 Nov 2009 00:31:55 -0800 (PST)
Received: from BLU137-DS7 ([65.55.111.137]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 00:32:22 -0800
X-Originating-IP: [24.19.160.219]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS77E1961DB2365B8E9DBD393AB0@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: dispatch@ietf.org
Date: Tue, 10 Nov 2009 00:32:30 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01CA619D.4A0BD690"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acph4CDlLaLoX/4+Rs6gNCcqJ8WlowAAC5gQ
Content-Language: en-us
X-OriginalArrivalTime: 10 Nov 2009 08:32:22.0285 (UTC) FILETIME=[52C76BD0:01CA61E0]
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 08:32:09 -0000

Jonathan Rosenberg said:

 

"Do you not agree that the majority of voice connections are still being
established to phone numbers today?"

 

[BA] Sure.  And I expect this will be the case for going forward too.  My
question was more about the application of ViPR to media *other* than voice.


 

"Firstly, ViPR is equally applicable to video, specifically for cases where
video endpoints aren't 'special' - they are the same endpoint I use for my
voip calling. When video is just a feature of my pstn-reachable voice
device, ViPR works well."

 

[BA] The question in my mind is whether video really is "special" (in the
IM&P sense) or not.  That is, today we accept the idea that anyone should be
able to complete a phone call to anyone else.  We also accept this for SMS.
However, we don't accept that idea for Instant Messaging (which typically
requires being in the buddy list). Do we accept that principle for video?
I'm not sure.  There are some inherent disadvantages to accepting video
calls from anywhere even if we have a verified phone number on the other
end.  

 

So even if video is a feature of a voice device, it still might be
sufficient to control the ability to complete a video call via a "buddy
list".  That's essentially the model for XMPP-based federation with Jingle.
Not good enough to provide telephony as we think of it today.  But this does
provide a degree of spam control while retaining something more akin to the
RFC 3261 federation model (though perhaps with some loosening).  

 

"I believe there will be infrastructure enum, absolutely. However, I believe
it will be used to create peering relationships amongst the carries which
are similar to the ones that exist today - with small regional operators
federating with larger international ones, which then federate again off to
more local ones. IP federation follows a similar model. These federation
agreements are likely in many cases to mirror the existing peering
relationships on the PSTN. This is because the peering agreements are likely
to include actual RTP transport to, along with the CAC/QoS features that are
the IP equivalents of what is done in the PSTN today. 

 

That means, in turn, that a call from company A to company B would go as
follows: 

 

a.com -> SP1 -> SP2 -> SP3 -> b.com

 

and, along the way, pass through the myriad of SBCs and SIP infrastructure
in each of these providers: 

 

a.com -> SP1-SBC-ingres -> SP1-SBC-egress -> SP2-SBC-ingress ->
SP2-SBC-egress -> SP3-SBC-ingress -> SP3-SBC-egress -> b.com 

 

That eliminates the trapezoidal model of SIP, which I still believe is
essential for feature transparency, feature velocity, and security, amongst
many other reasons. The feature velocity one is really important. The more
that we have intermediaries in the path, the less likely (exponentially so,
in fact) it is that any kind of new feature will ever work. There is a ton
of precedent for this. 

 

With ViPR, you get:

 

a.com -> b.com

 

"

 

[BA] This seems like the crux of the matter.  Even if the costs are equal to
the customer, a ViPR call could be more direct.  If all that's being
provided is basic telephony minutes, it might not be very noticeable.  But
if there are services involved, you end up with a more evolvable
infrastructure.   

 

"SIP trunking would still get you cost savings to non-vipr connected domains
and non-voip installations - all of the rest of the existing PSTN endpoints.
That'll continue to be useful for a really long time. 

 

ViPR + SIP trunking then further optimizes (and cost reduces) for the
domains that you can vipr federate with."

 

[BA] Infrastructure ENUM potentially can count in its camp phone numbers
from the major consumer VOIP providers, as well as phone numbers provided by
major SIP trunking providers (who are also presumably utilizing
infrastructure ENUM).  

 

While that seems like an advantage, if the SIP trunking provider still
charges on a per-minute basis, even for calls which may be carried entirely
over the Internet, then there will still be an incentive for a customer to
deploy a direct alternative (ViPR, DUNDI, etc.) since that will allow calls
made entirely over the Internet to be made for free.  Although we do see
cellular operators throwing in "in-networking calling", this is a far cry
from throwing in intra-domain or "out of network" calls as well.  This seems
a lot less likely.