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

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 9 Nov 2009 19:17:21 -0800

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
authentication). 

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

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 9 Nov 2009 20:52:35 -0800

>In that kind of scenario, ViPR would be unnecessary.

100% agree for the reasons given below and several other that already well known and need not be repeated here.
I also don't remember reading anywhere in the Internet architecture about federations and cartels.

My two personal cents,

Henry

On 11/10/09 12:17 PM, "Bernard Aboba" <[email-masked]> wrote:

Kevin Fleming said:

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Nov 2009 00:59:28 +0200

inline:

> require pre-existing trust between the parties. 

Exactly. The whole idea is that no close alignment is needed; its 
any-to-any in the traditional Internet model.

ViPR applies to any domain that has endpoints that have been assigned 
numbers. That certainly includes enterprises, but is not at all limited 
to that. It has applicability to all kinds of service providers - 
wireless operators (lots of endpoints), application providers (Vonage, 
Skype), cable operators, traditional LEC, CLEC, etc.

> are federating with dozens of suppliers/customers using TLS with mutual

As the drafts point out, private federation is in use today and it works 
OK at small scales. Stuff like DUNDI can work there, though you run into 
trust issues quickly as numbers are not verified.

> (e.g. in XMPP federation) and have proven quite effective.  

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.

IM&P - which usually doesn't use phone numbers - can be federated with 
existing DNS mechanisms and buddy-list based trust. However, as I 
mention in the draft, the reality of the situation is that *most* folks 
doing voip are still using phone numbers, and that is the problem we're 
trying to address here. Do you not agree that the majority of voice 
connections are still being established to phone numbers today?

> with SIP trunking?

SIP trunking would still get you cost savings to non-vipr connected 
domains and non-voip installtions - 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.

  However, that argument assumes that as the decline in the
> the benefits being passed on to customers. 

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

And as a consequence, no inderdepdency on anything else for a new 
feature to work. Thats how the Internet was meant to be. Can you imagine 
what the web would be like if my HTTP traffic had to be handled by web 
proxies at each intermediate ISP?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    PHONE: +1 (732) 766-2496
Skype
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 10 Nov 2009 16:02:52 +0100

> 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