SIP and MGCP/Megaco
MGCP/Megaco and SIP are not peers; they can and will coexist in converged networks. There are, however, a number of issues surrounding implementations that will influence future directions and capabilities.
As discussed in the Architecture section, MGCP/Megaco does not constitute a complete system: a session initiation protocol is required between gateway controllers. SIP is eminently suitable and is a requisite where there is more than one softswitch.
A more contentious area of discussion, is the use of MGCP/Megaco to control end-points. A media gateway could be an IP phone but, due to the service limitations this imposes, this is likely to be unpopular. MGCP/Megaco would only be able to support basic IN-type services in a dumb black phone.
For advanced services (i.e. anything more sophisticated than IN services), SIP is required to reside both in the endpoints and above the signalling network, acting as the service intelligence. The issue that then arises is where should services reside?
Softswitch vendors would prefer the service intelligence to reside in the IP Central Office, tied in to the softswitch architecture. This perspective holds firm in the short-term where emphasis on convergence means that the interconnect point between a circuit-switched environment and an IP network will be a major focus. In this scenario,
SIP application servers reside with the softswitches in the IP Central Office with MGCP/Megaco controlling multiple media gateways across the network, delivering services to all endpoints. As the legacy circuit-switched network diminishes in importance, and focus shifts squarely onto the IP infrastructure, then this model will become increasingly imbalanced and irrelevant. The softswitch function will need to evolve away from the interconnect point.
In a pure IP environment, service creation would be distributed across the network. This is the model that has produced the startling innovations that we have seen on the Internet: anyone with a few dollars and a good idea has the opportunity to give it a try. The Application Service Provider model can be extended to offer voice-type services. ASPs, ISPs, or even the end-users themselves can create their own SIP services; after all, SIP's similarity to other Internet protocols makes it a familiar programming language to web developers. A SIP-centric implementation would use MGCP/Megaco only for internally controlling an IP telephony gateway. SIP application servers would distribute services throughout the network via SIP proxy servers.
Peer-to-peer signalling protocol
Can be used as a control protocol for delivering services across the network
A session initiation protocol required between separate softswitches*
Used for internally controlling an IP telephony gateway
"Pure" IP solution
An interim solution for co-existing
networks - "PSTN over IP"
Horizontal architecture that re-uses Internet elements
Mirrors the signalling and control architecture of IN
Assumes dumb end-points
Abstracts the signalling layer from the network
Pre-supposes the existence of hardware
"New world" approach Ð simple open and horizontal
"Old world" Ð centralised, controlled and vertical
* SIP and MGCP/Megaco are complementary in certain ways and mutually exclusive in others.