Geof, thanks for opening this can of worms... something I had intended doing, but didn't think anyone would be interested in.
"but I don't see why there needs to be a dip charge"
I don't know what the rationale was for charging for a "dip" twelve years ago during the early days of IN, since the major players were all regulated and had to seek tariff approval for everything they did. For the benefit of the uninitiated, a "dip" loosely translates into: a database lookup and transaction execution. Sometimes multiple dips, each chargeable, are required during a single transaction profile.
One would assume that it would have had to been tied to costs in some way, due to the regulated nature of the industry. Even if we assume that dip charges had some relationship to actual costs of providing the services, the way those costs were stated were very likely high, resulting in artificially high pricing at the tariffs level, from the outset.
But we should also recall that in the early days of SS7/IN the service control points were large minis (ATT 2B2s, and DEC VAXes) that were housed in central offices. Today's SCPs, in contrast, are increasingly mircocomputer-based and unix-server based, linked by SS7 links to the cloud from just about anywhere, running on smaller sets of instructions which could be tailored to a specific provider's offerings.
They could be anywhere, such as in a CLEC CEO's basement (an historical fact, just as earlier DNS Root servers for the Internet have been known to reside in bedrooms, physics labs in universities and in utility closets of some of the early 'net pioneers), or in a remote office such as a carrier hotel, or colocation site or exchange point, as I suspect Otelnet's might be a candidate for.
Accordingly, the cost basis for charging per dip today has gone down by orders of magnitude, IMO, but the rates charged for their related services remain artificially high. In this sense there remains a bit of elasticity in the pricing structure of advanced services using IN software that has not been exercised yet, to speak of. Of course, elasticity implies that any decrease in pricing will result in more than enough revenue/traffic to make the decrease worth the provider's while.
But I'm not so sure that that will happen with advanced services where dips into SCP databases are concerned in the traditional PSTN space.
I'd be interested in yours, and others' views on this point, since convergence and an increasing dependency on IP-governed applications may enter the picture at such a time during the proofing of the elastacity algorithm, to prove it false. Not saying this will happen, just asking for opinions.
As for where the intelligence belongs - in the core, or in the endpoints - that, too, is an issue that is once again ripe for discussion. I say "once again" because it now appears that even IETF-sanctioned directions are looking to central repositories of information to govern the future of IP Telephony, multicasting, and other mainly-QoS-demanding applications, only they don't call it SCP or SS7 adjuncts, they call these places "directories," gatekeepers, domain name servers, which, collectively must work with an increasing number of other specialized servers within the cloud to make voice and video work the way we want and expect it to.
The preceding paragraph doesn't describe the views and desires of all who contribute to IETF discussions, "yet." There are still those holdouts (quite a few) in the crowd who see the network's role as being as stupid as possible, with maximum intelligence at the edges and end points.
[Upstream a bit, I posted the intro to the Cook Annual Report which touches on some of these same issues.]
So, my second question is, As the 'Net morphs into something resembling the characteristics of both the IP and PSTN domains, where should networking intelligence be placed? Opinions of lurkers and active members here, alike, are welcome.
FAC |
