IP Convergence: Beyond VoIP, Beyond Cost Savings

Application Performance Monitoring is definitely need for web (and data base) based apps and Fluke does a great job of it, but VoIP (and telephony) is not just another application. A Facilities based Telecom Service Provider (wireless or wireline; CLEC or ILEC; local, national or international) needs to start with a really good probe based monitoring system with a full featured (but cost effective and modular) OSS and BSS on top of it to assure all parts of your network and interconnected networks are working as advertised. The probes need to be able to connect not only to VoIP, but also PSTN (SS7) and ATM and the software sitting on top needs to be able to correlate any call between any part of the network it traverses. These systems not only provide detailed performance monitoring, but also media quality, Fraud Detection and Revenue Assurance. They also need to be scalable and with a ROI that shows that they pay for themselves.
Many Service Providers that have old systems are looking to replace what they have because the old systems can't hack it and the companies they bought them from (Tek and Agilent are two examples) seem to be missing the real point. Service Providers who have none are realizing that these new systems can actually SAVE them money.
Polystar is one of the companies that can help. Please contact me if you have any questions.

Given how users are getting more & more dependent of IP infrastructure for e-mail, phones, etc, it would be nice (ok maybe I'm being naive) if global crossing would take a lead in providing planned & unplanned reporting to outages mailing list. Hopefully other service providers can take GBLX's lead.

The goal of outages mailing list is all about information sharing and keeping network operators & end users abreast on the situation as close to real-time information as possible in order to assess and respond to major outage such as routing voice/data via different carriers which may directly or indirectly impact us and our customers. Hence eliminating the need to open tons of trouble tickets during a major event.

The purpose of outages@isotf.org mailing is to empower users, network operator community (nanog, nsp-sec, isp-routing, sanog, janog, etc) and services providers to post planned and unplanned events so that everyone could benefit from it.

You can checkout http://isotf.org/mailman/listinfo/outages more information.

Any help and support will be greatly appreciated.

Feel free to ping me directly for any further questions.

regards,
/virendra (list moderator)

This might surprise you, but I agree with you.

Embedding "read only" intelligence in the network to be able to help determine what's going on is a good thing.  Indeed, it in no way contradicts the design principles that made the Internet itself successful: place functions in the right context, make as few assumptions as possible up front as to how the network will be used, and preserve its option value.  It's when you build an architecture like IMS that you start to get into trouble.

The "stupid network" is also somewhat of a simplification, since it is clearly very smart if you look at the right layers.  The "layers" model is also just that: a model.  It hides a great deal of complexity about the real world, and (over) simplifies some of the ways in which information (and "side channel data" like identity) bleeds between those layers.  For example, the geographical location where the user resides is something of considerable importance and interest, but isn't transmitted or modelled in any way in the Internet paradigm.

I recently sat down and brainstormed all the ways in which the IP/Internet model doesn't quite fit reality.  I came up with over 50 items!  Each is a possible route to making money and avoiding being "dumb piped".

But...

The dumb pipe clearly works most of the time, even for voice.  I travel the world, and at a fraction of the cost of what a big enterprise paid for communications services I generally get a richer and better experience as a solo practitioner.  Something is clearly wrong.  User-facing telcos that launch products that are implementable on a "fat, dumb pipe" and don't take advantage of the special position of the operator or it's non-network assets (cash collection, invoicing, distribution, retail etc.) deserve to get a whipping in the marketplace.

The good news is GX is one of the few telcos that really understands these phenomena well, and is a "carrier's carrier", so all the best!  In our Telco 2.0 model, you're definitely "Telco 2.0 compliant" in that you focus on one horizontal activity, and do it well.