The Shift Toward New VoIP System Models

1
(No Transcript)
2
The Shift Toward New VoIP System Models

• Jerry Knight CTO - AccessLine Communications

3
Introduction
One Operators Point Of View On Taking An
Un-licensed And In-house Developed Approach
To ITSP/CASP Platform Design

• My background in platform construction
• Influences on the latest construction exercise
• Outside stresses on in-house/unlicensed
• Bucking the trend, a commercial experiment

4
Trends In Telecommunications

• Embedded systems and closed-source software
  platforms are merely extensions of the
  established design philosophy for three purposes.
  
• Vendor/Telco independence
• Cost reduction (more automation)
• A few extra services
• Not about customer support
• All about maintaining Telco control
• BUT.we now have
• The Stupid Network (David Eisenberg)
• The Internet, Dumb cheap transport, Transparent,
  Ubiquitous
• Off the shelf low cost high power server and
  storage technology
• All traffic is one or another form of data
• Trends towards
• Cooperative of a multitude of loosely coupled
  operators.
• Reduced control

5
An In-House RD Approach

• An ITSP today can be entirely software-driven
• 4 building blocks (servers, storage, IP network
  technology, bandwidth)
• Gateways (DSPs) becoming obsolete (lifespan ?)
• Is an in-house development approach impractical
• Build it simple
• Leverage open source
• Abstract, abstract, abstract
• Where do you start?
• Simple SoftSwitch
• Routing, monitoring, accounting
• Internal CSUAC protocol (SIP plus)
• API to attach call control platforms (like
  asterix, etc)
• Simple SBC
• OSS tools (Billing, care, provisioning, process
  automation)
• Leverage opensource
• Standardize on linux

6
Operational Simplicity

• What is most important platform consideration for
  any service provider?
• In-house development approach allows maximum
  simplicity
• One homogenous system
• One set of concise semantics
• The system integration approach is
  anti-simplicity
• Is simplicity attainable with integration? Maybe,
  maybe not.
• Can the cost be born?
• Required skills
• Fundamental libraries for common functions
• CDR generation, Monitoring, diagnostics,
  watchdog, presence, messaging, etc.
• One operating system
• One hardware platform
• Common skills in operations and development
• Shorter/shallower learning curve
• Less breadth, greater depth

7
In-House Support

• VoIP is difficult !
• T.38 doesn't work
• Echo is a plague and out of the service
  providers control
• Modems cannot be relied upon to work
• Partner support profiles are patchy
• Diagnostics requires great skill and dedication
• Multiple third-party level three support groups
• Fixes need to be designed and implemented fast
• Integration approach may preclude certain types
  of critical diagnostic approaches
• Sandbox
• Internal RD has one customer

8
Junk Code

• Systems manufacturers / software houses need more
  than one customer
• Ticks in boxes to get selected in the first
  place
• Product design is abstract
• Each win brings another level of enhancements
• Tendency to generalize rather than specialize
• Service provider has to
• Pay for it
• Disable it
• Buy/provide cpu to cope with that which cant be
  disabled
• Train on it
• Account for it in diagnostics
• Assess its effect on availability
• Have critical MRs queue behind design, dev and
  test of MRs for competitors on the junk code.
• Service provider may need to run many times the
  code that is actually needed.

9
Patents

• Today there are over 2000 patents in VoIP and the
  litigation is heating up
• The process of RD tends to provide
• patent filing opportunities
• Source of secondary revenue
• Useful for defense
• Work-around opportunities

10
Cost Vendor Management

• Avoidance of license costs is a huge issue today
• Flexibility in a rapidly changing business
  landscape
• Competition
• Vendor Management
• Is a chore and a cost
• Success and failure both stress support quality
• Modest success is not stable
• Architectural Flexibility
• The lower the cost of a platform element the more
  freely it can be distributed.
• Full duplex real-time elements, Mixers, SBCs
• Critical components, S/Ss
• Sandbox
• Product Marketing Flexibility
• Increasingly aggressive competition
• Constant product/package/offer re-evaluation and
  modification
• System suppliers licensing models a huge
  constraint on marketing
• RD operating Costs
• Are fungible

11
Speed to Market/Flexibility

• Product flexibility/agility important
• Rapidly changing business environment
• New Entrants (Best Buy, etc)
• New demands (FMC, etc)
• Aggressive competition
• Cannot occur at the expense of simplicity
• No good to incrementally add foreign components
• Platform designed to address product flexibility
• Common database
• Common CDR formatting
• Management and Operation
• Training
• Sales training
• Interoperation with legacy

12
Standards (Standarditis)

• Standards can be
• Positive and optional
• A means to ensure interoperability
• A source of inspiration
• Negative and mandatory
• A constraint on innovation
• An unnecessary RD burden
• Internal RD minimizes mandatory Standards
• Those needed are implemented
• Those not needed but relevant are inspected and
  inform design
• Any standard can be implemented in a single dev
  cycle
• Standarditis

13
Development Efficiency

• The Systems manufacturer or S/W house has a
  development burden that increases with success.
• Regression testing becomes more complex
• More complex base
• Heightened consequences of branching
• Increased planning constraints, customer base
  commitments
• Multiple supported releases
• The internal RD department has a more linear
  effort curve
• Single supported release, network upgrades in
  lock step
• Minimum complexity and regression
• Customer and supplier working together to
  maximize efficiency

14
Unlicensed Platform Challenges

• Perceived dependence on key skilled personnel
• Patent infringement indemnity
• Tend to be more inward focused and isolated
• Need to be more self-sufficient
• Lacks the eco-system
• No-one else to blame

15
Conclusions

• Possibly will see more systems/software providers
  morphing into service providers.
• Not efficient to try to be both
• Open source coupled with in-house development has
  some very real advantages
• Open-source is not what it used to be
• Systems providers challenges
• Licensing constructs to maximize flexibility
• A building block approach
• A la carte ordering
• For integration into a foreign architecture
• ITSPs may tend to become CASPs over time
• CPE and network may reduce to anarchy
• ITSPs may need to be hyper-efficient to survive.