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

Bernard Aboba <bernarda@microsoft.com> Tue, 10 November 2009 08:30 UTC

Return-Path: <bernarda@microsoft.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 9E0C628C10A for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 00:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.298
X-Spam-Level:
X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8]
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 5Mty88LNiILr for <dispatch@core3.amsl.com>; Tue, 10 Nov 2009 00:30:25 -0800 (PST)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 2C87528C0DC for <dispatch@ietf.org>; Tue, 10 Nov 2009 00:30:25 -0800 (PST)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 Nov 2009 00:31:09 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.20; Tue, 10 Nov 2009 00:30:51 -0800
Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.203]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 10 Nov 2009 00:30:50 -0800
From: Bernard Aboba <bernarda@microsoft.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: Re: [dispatch] Introducing ViPR: a new federation technology
Thread-Index: Acph4CDlLaLoX/4+Rs6gNCcqJ8Wlow==
Date: Tue, 10 Nov 2009 08:30:58 +0000
Message-ID: <F839FBA415E97B4DBD5BA437162E0603201E993A@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_F839FBA415E97B4DBD5BA437162E0603201E993ATK5EX14MBXW652w_"
MIME-Version: 1.0
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:30:33 -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.