[VOIPSEC] 4G Issue Map: signaling complexity - more

Tue Aug 29 13:54:38 CDT 2006

Some points:

1. Existing P2P approaches already address the above.  The carriers just
don't realize it yet.

2. Protection of service provider infrastructure and services is not needed
when the service that is provided is a dumb but good network.  Protection
of service provider revenue models is uninteresting in a truly competitive
environment. Most of IMS revolves around the artificial complexity needed to
preserve a value chain all the way down to the equipment vendor and carrier
solution provider.

3. Service provider infrastructure is not needed in a P2P model. Service
provider "services" are not needed either.  I can do my own call processing
and voice mail, thanks.  So can my customers. All that is needed is a good
dumb pipe.

4. In a competitive universe the service providers refuse to provide a good
dumb pipe someone else will.

5. Nation states that preserve obsolete industries only prolong the
inevitable while losing leadership positioning.

On 8/29/06, stuart jacobs <stu.jacobs at verizon.com> wrote:
>
> As soon as you have packets associated with a revenue generating
> service (containing signaling & control let alone OAM&P) crossing
> organizational boundaries, it becomes a far more complex task to
> manage trust relationships.  A peer-to-peer approach does not address
> the above nor allow a service provider to protect their
> infrastructure or the services offered over said infrastructure.
>
> stu
>
> On Aug 29, 2006, at 12:50 PM, Michael Slavitch wrote:
>
> > My employer builds such things, and it's not all in the endpoint,
> > but the
> > endpoint can be as invoved as needed given the application at hand.
> > It's not
> > in a monolithic IMS switch either. In such a design the proxy, IVR,
> > UM, UC,
> > personal agents, app servers (including PBX services) and queueing
> > systems
> > are in different agents that co-operate and learn of one another
> > using a
> > common authentication, directory and administrative regime. In such a
> > world the endpoint is just one part of a networked system of
> > distributed
> > peers, the difference being that some peers act for many entities
> > while
> > other peers act for just one entity,on but in reality they are all
> > peers in
> > an interconnected system.
> >
> > In such an environment five-nines becomes easy.  For us in our
> > market server
> > clusters, which are a part of the underlying server platform, automate
> > reliability.  A side benefit is that our customers can apply
> > patches and
> > upgrades during the day on the redundant systems.  A huge benefit
> > for us is
> > that we get such reliability for free.  We don't have to build that
> > infrastructure.  We only have to break things down into logical
> > chunks and
> > build a supportive installer. The rest is provided by Microsoft.
> >
> >  SIP is already peer to peer when it is in a common comprehensive
> > administrative domain.  Why not exploit this to the maximum? Why
> > not tear
> > down complex problems into digestible chunks especially when that
> > was the
> > whole purpose of the protocol in the first place?  Why not make things
> > tractable when everything that is needed to make things tractable are
> > already there?
> >
> > In such an environment the endpoint need not be dumb. It can be
> > dumb, and
> > things work fine enough if you assume a deterministic
> > system.  Where intelligent endpoints shine is that they offer
> > reality and
> > context that cannot be predicted and programmed into a database or a
> > system. They have immediate access to a human context, which is
> > overlooked
> > in the smart network world, and collectively the endpoints offer more
> > interesting immediate context than any server can possibly deliver.
> >
> > For example, endpoints offer presence and, if monitored, history,
> > which
> > allow for applications like queuing to work better as they have
> > access to
> > more complete and more realistic data.  It allows for systems
> > engineers to
> > solve real problems that cannot be assumed in advance.  If all the
> > presence
> > endpoints for a physical center said 'away' at the same time,
> > forming a
> > spike, it may indicate something more serious than a coffee break
> > or lazy
> > staff.
> >
> > In one consulting example from a few years ago I used an equivalent of
> > presence, network traffic, to solve a particularly sticky
> > unsolvable problem
> > regarding why a certain queueing system overloaded and failed
> > frequently and
> > unpredictably. After months of vendor finger pointing I was hired
> > to solve
> > the problem. Real data allowed me to prove that the problem
> > coincided with
> > overzealous fire-alarm testing.   My silly, if somewhat lucrative,
> > example
> > shows how intelligent clients offering history make such root-cause
> > analysis
> > possible. Such contracts, when you get them: always do them fixed-
> > price with
> > a bonus for early resolution.
> >
> > The term 'server' is also a misnomer when the endpoints perform
> > tasks like
> > conferencing, reducing the need for conference bridges in any core.
> > All
> > commodity SIP phones perform some level of low-performance
> > conferencing,
> > given the nature of servers vs. clients this means that monolithic
> > conference bridging is only needed for large-scale exceptions, again
> > reducing load and complexity.  In such an environment the user
> > entity is
> > paramount, which is why end-to-end administrative context is more
> > important
> > in our world than end-to-end connectivity.  Administrative
> > completeness
> > allows for scalability.  If the system can force the conference
> > onto the
> > endpoint it means less resources are needed in the core. The number
> > of free cycles at the edge dwarfs the capability of any data center,
> > including those monsters being built by Google and Microsoft.  As a
> > group
> > the peers are where the muscle is.
> >
> >  In a networked environment the number of agents, where and how
> > they are
> > deployed are a factor of packaging and logistics, and the choice of
> > where
> > tasks are performed, either in a 'server' peer or in an 'endpoint'
> > peer, are
> > a matter of data center policy.
> >
> > Done well, with automation, it is very pretty. :)
> >
> > M
> >
> >
> > On 8/25/06, Paul E. Jones <paulej at packetizer.com> wrote:
> >>
> >> Henry,
> >>
> >> Have you ever looked at the SIP call flows required to support a call
> >> center
> >> that has a proxy, an IVR, perhaps some other app servers, a queuing
> >> system,
> >> and an agent?
> >>
> >> It isn't "in the endpoint" (and cannot be, unless you want to
> >> build a very
> >> small call center) and it isn't pretty. :-)
> >>
> >> Paul
> >>
> >>> -----Original Message-----
> >>> From: Henry Sinnreich [mailto:hsinnrei at adobe.com]
> >>> Sent: Thursday, August 24, 2006 8:34 PM
> >>> To: Geoff Devine; Paul E. Jones; Brian Rosen;
> >> bill at flanagan-consulting.com
> >>> Cc: Voipsec at voipsa.org
> >>> Subject: RE: [VOIPSEC] 4G Issue Map: signaling complexity - more
> >>>
> >>> Geoff Divine writes:
> >>>
> >>>> I don´t see that the fully distributed call processing model
> >>>> is workable in the general case.
> >>>
> >>> This is an interesting point, since the most useful telephony
> >> applications
> >>> can be implemented with SIP call control in the endpoints:
> >>> - IVR
> >>> - Auto-attendant
> >>> - Receptionist workstation
> >>> - Contact center agent workstation.
> >>> So even for core telephony, all this maze of servers is not
> >>> required.
> >>>
> >>> What do you think?
> >>>
> >>> Henry
> >>>
> >>> -----Original Message-----
> >>> From: Geoff Devine [mailto:gdevine at cedarpointcom.com]
> >>> Sent: Thursday, August 24, 2006 6:25 PM
> >>> To: Henry Sinnreich; Paul E. Jones; Brian Rosen; bill at flanagan-
> >>> consulting.com
> >>> Cc: Voipsec at voipsa.org
> >>> Subject: RE: [VOIPSEC] 4G Issue Map: signaling complexity - more
> >>>
> >>> Henry Sinnreich writes:
> >>>> Such complexity is better placed in the endpoints, the only
> >>>> ones that understand the application and that can be
> >>>> developed in a controlled environment.
> >>>
> >>> Right.  ...and what that means is any time you need to add a
> >>> feature,
> >> you
> >>> need to extend the protocol. When you extend the protocol, you
> >>> need to
> >>> ensure interoperability with potentially dozens of different client
> >>> implementations and potentially dozens of different software
> >>> revisions
> >> of
> >>> each implementation.  Go look at what TISPAN or the PacketCable
> >>> Residential SIP Telephony Spec (after the IPR review period
> >>> expires next
> >>> month) have done.  Unless you vendor lock on one client
> >>> implementation,
> >> it
> >>> will be wildly difficult to ever make the network stable.  The cell
> >> phone
> >>> service providers can limit the damage by controlling the number of
> >>> implementations and testing the heck out of everything.  They´ve
> >>> also
> >>> adopted a model where as many features as possible are done by
> >>> the core
> >>> network.  I don´t see that the fully distributed call processing
> >>> model
> >> is
> >>> workable in the general case.
> >>>
> >>> Geoff
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Voipsec mailing list
> >> Voipsec at voipsa.org
> >> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >>
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
> ========================================================
> Stuart Jacobs, CISM, CISSP
> PMTS - Sr. Technologist
> Network Security
> Verizon Laboratories
> 40 Sylvan Road
> Waltham MA 02451-1128
> (781) 466-3076
>
>