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

[Jonathan Rosenberg <[e-mail]>]

inline:

Bernard Aboba wrote:
> 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. 

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.

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

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.

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

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?


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

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

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: [phone]
Skype
[e-mail]                              http://www.skype.com
[e-mail]                            http://www.jdrosen.net