[VOIPSEC] 4G Issue Map: signaling complexity - more
Paul E. Jones
paulej at packetizer.com
Tue Aug 29 14:31:17 CDT 2006
Michael,
Going forward, there will be multiple overlapping voice networks. There will be networks like Skype and there will be networks operated by big carriers (among which I believe I can safely include cable operators now). I think there will also be a lot of smaller players providing voice service, among those I include my own VoIP provider.
I believe there will be enterprises solely dependent on a service provider and some that just need a "pipe" and perhaps will interface with a peering service and/or use DNS as part of the address resolution.
Some residential customers will also rely heavily on a service provider. Why? Because they don't want to run their own service, don't want to go buy an ENUM number, etc. The vast majority of residential subscribers want somebody to provide the service and somebody to call when there is a problem. I would guess many on this list are quite opposite from the majority. :-)
Given that service providers will continue to play a vital role in providing voice services, then they do need standards defined that allow them to do that. IMS is, in my opinion, way more complicated than it ought to be. But, what is the alternative? Service providers need a system that works. They need to provide reliable, manageable services to subscribers. Does IMS do that? If so, complex or not, it will have a place in the market. Under the umbrella of NGN and IMS, there is a lot of complexity, a need to protect the network, etc. It will be a very closed system, with doors open only through controlled SBCs.
With all of that said, one does have to ask whether the whole IMS/NGN thing will implode on itself over a period of a few years. As alternative VoIP carriers continue to drive costs down, traditional carriers will continue to feel price pressure. So, will the return on investment over the costs of the expensive IMS gear? It certainly makes sense for the new carriers trying to gain a large market share and when the equipment costs are covered by an additional $5/mo or so OR when the addition of the voice service attracts a lot more subscribers to other services (e.g., what cable service providers are now able to do).
I've not been in the board rooms at traditional service providers, but I can only guess that this has troubled them to no end. What used to be the "bread and butter" of the company is now being commoditized like e-mail, instant messaging, and others kinds of service. Voice is, after all, just another application over IP, so one cannot expect to charge a huge premium any longer.
Now, that does not mean there isn't a profitable business model, but margins will be slim. As such, complexity must be reduced.
What has struck me as odd is why the traditional carriers do not view this changing market as an opportunity like everybody else. For the first time, traditional carriers will now be able to offer a whole range of services over IP, from IP-based radio, voice, video, news delivery, weather, conferencing, security systems, etc. Sure, competition is out there, but they have the wherewithal to grow into being huge multimedia corporations, not just serving as a "pipe". (Even being a "pipe" is a revenue-generating business all by itself. I've really wondered why some carriers have complained about the use of VoIP when they are collecting an additional $50/mo from users who were not paying that money before.... perhaps I need a business lesson.)
Paul
----- Original Message -----
From: Michael Slavitch
To: stuart jacobs
Cc: Paul E. Jones ; bill at flanagan-consulting.com ; Henry Sinnreich ; Voipsec at voipsa.org ; Geoff Devine
Sent: Tuesday, August 29, 2006 2:54 PM
Subject: Re: [VOIPSEC] 4G Issue Map: signaling complexity - more
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
More information about the Voipsec
mailing list