Architecture for Internet Telephony Service for Residential Customers

Bellcore

March 2,1999

Christian Huitema, Jane Cameron, Petros Mouchtaris, Darek Smyk

Abstract:

In this paper, we introduce a new architecture that can be used for offering Internet Telephony service to residential customers. The architecture proposed addresses scalability and availability requirements of mass-market deployment of carrier-grade services and supports interconnection with SS7 for Internet Telephony calls to the Public Switched Telephone Network (PSTN). The architecture is based on the concept of a gateway decomposition that separates the media transformation function of today’s H.323 gateways from the gateway control function of the gateways and centralizes the intelligence in a call agent. Media Gateway Control Protocol (MGCP) is introduced as the protocol between the call agent that assumes the gateway control function and the gateway that provides just the media transformation function. Interworking of the architecture and the PSTN, Session Initiation Protocol (SIP) and H.323 are also discussed.

1. Introduction

Recently, software for making telephone calls over the Internet has been introduced to the market place. This software allows people to make telephone calls over the Internet inexpensively. Solutions for providing Internet Telephony are based today either on Session Initiation Protocol (SIP) or H.323. Both SIP and H.323 were originally developed for establishing multimedia conferences over the Internet and assumed a PC as the client device. Internet Telephony requires a subset of the functionality provided by SIP and H.323. To set up calls between the Public Switched Telephone Network (PSTN) and the Internet, gateways have been introduced in the network.

H.323 gateways provide for media transformation. In the PSTN, voice conversation is carried as a 64Kbps stream using Pulse Code Modulation (PCM) encoding. However, voice conversation over the Internet is carried using Real-time Transport Protocol (RTP) [1] using various encoding schemes with or without compression and various bit rates. The gateway is responsible for converting between the PSTN and Internet Telephony voice format.

To establish an end-to-end call between the Internet and the PSTN, H.323 gateways terminate H.323 signaling on the Internet Telephony side and usually ISDN PRI on the PSTN side. The gateway is also responsible for setting up the voice path for each call within the gateway by controlling the gateway resources.

Internet Telephony has gained a lot of interest and attention in the telecommunications industry where several carriers are considering wide scale deployments of Internet Telephony service. In the short term carriers can take advantage of arbitrage opportunities. In the long term they can offer a wide array of services (internet access, telephony, multimedia conferencing) over a common IP based network. Wide scale carrier deployments pose strict requirements on Internet Telephony solutions that existing approaches cannot fully address:

• Scalability: Carriers require solutions that support a very large number of customers (eventually millions of customers). Existing gateways can only support a fairly small number of lines (up to a few thousands). The reason for the limitation is that gateways support both media transformation and media control and signaling.
• Seamless PSTN integration: Carriers require that their subscribers can set up calls the same way they do today in the PSTN. Two-stage dialing for PSTN calls that is required by existing gateways is not acceptable. Existing solutions require two-stage dialing.
• SS7 connectivity: Carriers require that services that are offered today in the PSTN using the SS7 network can also be offered to customers that use Internet Telephony. Existing solution do not support SS7 interconnection.
• Availability: Carriers require that services experience very limited down-time of the order of a few minutes per year. Existing solutions have limited mechanisms for failover and cannot meet this requirement.

In this paper, we propose a new architecture that addresses the limitations of the existing solutions for mass market deployments of Internet Telephony. This architecture was first proposed in an early version of [2] in early 1998. This architecture is based on the concept of a gateway decomposition that separates the media transformation function from the gateway control function. In existing architectures these functions are co-resident on gateways whereas the gateways in the proposed architecture are limited mostly to media transformation. The call establishment becomes the responsibility of a call agent that is located outside the gateway. This allows a more scalable solution. The gateway decomposition also increases availability because multiple call agents can be used to control a gateway. If one call agent fails, another call agent takes over without losing any calls. The call agent also terminates SS7 connectivity. This allows for seamless integration with the PSTN. No two-stage dialing is required in our architecture. SS7 connectivity also allows our architecture to offer all the services that are provided today by the PSTN.

The proposed architecture assumes that most of the intelligence is inside the network requiring Customer Premises Equipment (CPE) with limited functionality. Internet Telephony can be offered without requiring that a PSTN subscriber replace their existing CPE equipment or buy new expensive equipment. A regular telephone can be used. Keeping the intelligence centralized allows for the rapid introduction of new services. New services often don’t require any CPE upgrades but can be handled by simply upgrading the call agent software and can be made available to all customers that are willing to pay for the service without requiring that the customer download and install any new software. This prevents the problem of having CPEs that support incompatible applications and services.

The concept of centralizing intelligence deviates from today’s internet model that assumes that most of the intelligence is located at the CPE and that the network is mostly dumb. The reason for that deviation is that our architecture is trying to address the requirements of a very reliable and highly available Internet Telephony service. We believe that the requirements for such a service point to a more centralized architecture. We expect that there will also be very intelligent CPEs (i.e. PCs) connected to the network that may implement services that the call agent does not support either because it is not cost-effective to do so or because customers don’t require the reliability, availability or integration with the PSTN that the call agent offers. We expect that both the centralized architecture and a highly distributed architecture where most of the intelligence is at the CPE will co-exist at least for some time. Our architecture doesn’t preclude customers from implementing services at their intelligent CPEs. The market place will determine whether both approaches will be viable in the long term and which services should be implemented in a centralized fashion.

2. Architecture

The proposed architecture is described in the following figure:

Figure 1. Network Architecture

The main components of the architecture are the residential gateway (RGW), the trunking gateway (TGW) and the call agent. The Media Gateway Control Protocol (MGCP) is used by the call agent for controlling the residential and trunking gateways. The SS7 Gateway allows the call agent to interact with the signaling network of the Public Switched Telephone Network (PSTN) called SS7. The details of the architecture are provided in the following sections.

2.1 Residential Gateway (RGW)

The residential gateway (RGW) is responsible for capturing events associated with an IP telephony subscriber (e.g. going on hook) and interworking with the IP network to signal these events to the call agent. The RGW is also responsible for supporting the voice path over Real-time Transport Protocol (RTP) [1].

In a more general sense, a RGW may have additional capabilities depending on the needs of a customer. We expect that a RGW may support voice and video interfaces, may support home networking, applications such as remote access for energy control and other capabilities. There will be different market segments that will require RGWs to support different features.

Our architecture assumes that the RGW supports: at least one POTS line, MGCP for setting up calls and RTP for the voice communication. The phone shown in the figure can be connected to the RGW via an RJ-11 interface and allows customers to reuse their existing telephones. Subscribers of PSTN telephone service can switch to Internet Telephony service by just adding the RGW between their existing telephone and their existing telephone line (assuming the use of ADSL), and get the same services (i.e. call forwarding, call waiting, 800 service) without observing any differences in the services they subscribe to. We assume that the cost of the RGW is low because of the limited functionality that an RGW provides. Our architecture is based on the assumption that the gateway has very limited intelligence and supports a very limited number of transactions. The RGW takes instructions from the call agent on how to react on the different events. The intelligence resides in the call agent.

RGW can be connected to the IP backbone network through some type of an access network. The access network may be a Hybrid Fiber Coax (HFC) network or an ADSL network. ATM may also be used in the network below the IP layer.

2.2 Trunking Gateway (TGW)

The trunking gateway is responsible for bridging the Internet with the PSTN. Calls that originate in the PSTN go through the TGW so that the voice can be converted from the Time Division Multiplexing (TDM) format to RTP packets. Similarly, for calls that originate on the IP side and terminate on the PSTN side, the TGW needs to convert the RTP packets to the appropriate TDM format. The TGW also supports MGCP. MGCP allows the call agent to instruct the TGW on how to proceed with the calls.

The TGW needs to support functionality that is provided on various trunks in today’s PSTN. For example, PSTN switches perform checks called continuity checks periodically on TDM trunks for verifying that a trunk still works by playing tones over the trunks and ensuring that the trunks still propagate the tones correctly. The TGW needs to support the various tones that are required for continuity check on the TDM trunks. The TGW also needs to support Multi-Frequency (MF) trunks. These trunks are trunks that were deployed before TDM trunks were deployed and are analog trunks that provide signaling in band. Signaling for MF trunk needs to be detected at the TGW, and either processed or passed to the call agent for processing.

2.3 Call Agent

The call agent controls both residential gateways and trunking gateways via the Media Gateway Control Protocol (MGCP) as defined in [3]. Residential and trunking gateways report events to the call agent (e.g., phone going off-hook) and the call agent instructs the residential and trunking gateways on how to continue with call processing using MGCP messages.

The call agent is also responsible for handling the SS7 signaling for the trunks that interconnect the PSTN with the IP network. The call agent utilizes an SS7 gateway for sending and receiving the SS7 ISUP messages. The call agent also interacts with a Service Control Point (SCP) over TCAP for services that require those interactions.

The architectural framework defined in this document supports all the telephony services that are in use in the PSTN today and anticipates additional services that will be introduced in the Internet Telephony environment. The definition of the architectural framework takes into account that subscribers may be participating in more than one call at the same time. For example, the subscriber may have one call on hold and at the same time may be talking to somebody else.

The call agent supports a distributed architecture. The architecture assumes that there may be large number of call agents controlling gateways over the Internet. Each of the call agents may control several residential and trunking gateways. In general, a call agent may control both residential and trunking gateways.

2.3.1 Call Agent to Call Agent interface

In general, a call agent can support a large number of RGWs and TGWs. If the network that a provider wishes to deploy is large and includes a very large number of RGWsand TGWs, a single call agent may not be adequate Several call agents may need to be deployed. If the two RGWs in a two party call are controlled by different call agents, the two call agents will need to coordinate for setting up a call. This is very similar to two switches in the PSTN coordinating for setting up a call between two parties that belong to different switches.

ISUP is used in today’s telephony network for the coordination between switches for setting up calls. The same interface with minor modifications can potentially be used for setting up Internet Telephony calls across call agents. ISUP will need to be extended so that the SDP information for the originating and terminating party can be exchanged between the two call agents.

The limitation of using an extension of ISUP is that it may be possible to define a simpler protocol for calls that don’t enter the PSTN network. ISUP supports messages for supervising the status of circuits and is in general a complex protocol. It will also be fairly difficult to extend ISUP to support more complex services (i.e. video conferencing, multimedia services) as the Internet evolves and additional services need to be supported in conjunction with Internet Telephony. SIP is another protocol that is being considered for the call agent to call agent interface. SIP can encapsulate the ISUP parameters and carry that information between call agents together with the SDP parameters. SIP has the advantage that it was developed for handling multimedia calls over the Internet.

There are currently no efforts to standardize the Call Agent to Call Agent interface. It is actually not critical for initial deployments to have such a standardized interface because IP Telephony networks of different service providers will be isolated from each other and will interwork through the PSTN. Although that approach has limitations because of the additional delays that are added by going through at least two TGWs, this approach may be a viable short term solution especially since most calls initially will be between PSTN subscribers and Internet Telephony subscribers. As Internet Telephony networks become more widely deployed, the need for them to interwork will increase at which point the need to standardize the call agent to call agent interface will become critical.

2.3.2 Services

There have been very few discussions up to this point on how to implement enhanced services around Internet Telephony. The Advanced Intelligent Networks (AIN) paradigm can be adopted from the PSTN world. The call agent can potentially support AIN interfaces to SCPs similar to the way that it supports interfaces to ISUP. This will allow for support of AIN services like 1-800 (free phone) etc. Since the call agent has a signaling gateway to the SS7 network, the call agent can send queries to an SCP and perform he number translations that are required for 800 services, Local Number Portability etc. The same services that have been implemented using AIN can now be offered to Internet Telephony subscribers.

Services that are today supported within digital telephony switches can also be supported within the call agent in a similar fashion. Call waiting is one of those examplesThe call agent can also potentially support some of the IN CS-2 interfaces defined by ITU (i.e. Q.1221-4, Q.1228) that can support features like call waiting outside the switch where the call waiting service is implemented at a service function outside the switch (i.e. SCP).

It is clear the call agent will initially support some features within the call agent and utilize some of the existing telephony AIN/IN interfaces for some enhanced services. Current telephony interfaces cannot be easily adopted to allow for the introduction of the wide variety of services that an IP network can support in the future. This is an area that will become extremely important in the future. The long term viability of Internet Telephony products will depend on the list of services that can be supported as well as the flexibility and quickness of introducing new services.

3. MGCP

The Media Gateway Control Protocol (MGCP) is a new protocol that the call agent uses in our architecture for controlling the different residential gateways. MGCP (see [3]) has been introduced in IETF and was the result of the merge of Simple Gateway Control Protocol (SGCP) and Internet Protocol Device Control (IPDC) (see [2] and [4] respectively). There are currently extensive discussion going on in the IETF for standardizing the interface between the call agent and the gateway (see [5]). MGCP is one of the leading candidates.

This section provides a high level introduction of MGCP. The purpose of the document is not to provide a detailed specification of the protocol. The reader is referred to [3] for a complete specification of the document. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements, the call agent. MGCP assumes that the gateways have limited storage and functionality. MGCP introduces the concepts of connections and endpoints for establishing end to end voice paths. MGCP also introduces the concepts of events and signals for establishing and tearing down calls.

Connections and Endpoints

MGCP assumes a connection model based on endpoints and connections. Endpoints are sources or sinks of data. Examples of endpoints are:

• An interface on a gateway that terminates a trunk connected to a PSTN switch (e.g., Class 5, Class 4, etc.).
• An interface on a gateway that terminates an analog POTS connection to a phone, key system, PBX, etc.

Connections may be either point to point or multipoint. A point to point connection is an association between two endpoints for transmitting data between these endpoints. Once this association is established for both endpoints, data transfer between these endpoints can take place. A multipoint connection is an association among multiple endpoints for transmitting data among these endpoints.

Connections can be established over several types of bearer networks:

• Transmission of audio using RTP and UDP over a TCP/IP network.
• Transmission of audio over an ATM network.

Events and Signals

The concepts of events and signals are central to MGCP. A call agent may ask to be notified about certain events occurring in an endpoint, e.g. off-hook events, and a call agent may request certain signals to be applied to an endpoint, e.g. dial-tone.

Events and signals are grouped in packages. Packages are groupings of the events and signals supported by a particular type of endpoint. For instance, one package may support a certain group of events and signals for analog access lines, and another package may support another group of events and signals for MF trunks.

Digits, or letters, are supported in many packages. Digits include numbers between 0 and 9. Letters may include the asterisk "*", the pound sign "#" and others. The call agent can ask a gateway to detect a set of digits or letters either by individually describing those letters, or by using the "range" notation defined in the syntax of digit strings.

3.1 Usage of Session Description Protocol (SDP)

The call agent uses MGCP to provision the gateways with the description of connection parameters such as IP addresses, UDP port and RTP profiles. These descriptions follow the conventions delineated in the Session Description Protocol (SDP) which is now an IETF proposed standard, documented in RFC 2327 (see [6]). The use of SDP facilitates interoperability with the Session Initiation Protocol (SIP) as explained in later sections.

SDP allows for description of multimedia conferences. This version limits SDP usage to the setting of audio circuits and data access circuits. The initial session descriptions contain the description of exactly one media, of type " audio" for audio connections.

3.2 Gateway Control Functions

This section describes the commands of MGCP in detail. There are eight commands in the protocol: NotificationRequest, Notify, CreateConnection, ModifyConnection, DeleteConnection, AuditEndpoint, AuditConnection and RestartInProgress.

3.2.1 NotificationRequest

The NotificationRequest command is used by the call agent for requesting from a gateway to be notified upon the occurrence of specified events in an endpoint. For example, a notification may be requested for the event that a gateway detects that an endpoint is going off hook. A list of potential events includes: off hook transition, on hook transition, flash-hook, MF incoming seizure detected, continuity tone detected etc.

The call agent can also request that the gateway collect the dialed digits. The NotificationRequest allows the call agent to download a specific dialing plan to the gateway to be used for collecting the digits.

A call agent also includes a unique identifier in the NotificationRequest that will be included by the gateway in the gateway’s Notify message when the requested event actually occurs. This identifier is used for tying the NotificationRequest to the Notify message that will be sent by the gateway.

3.2.2 Notify

Notifications are sent by the gateway via the Notify command in response to a NotificationRequest sent by the call agent to the gateway. The gateway includes in the Notify command a list of the events it observed. The Notify command includes the unique identifier that was sent by the call agent to the gateway in the NotificationRequest command.

3.2.3 CreateConnection

The call agent uses the CreateConnection command for binding an endpoint to a specific IP address and UDP port. Another CreateConnection request for the remote endpoint is necessary for creating an end-to-end connection with two endpoints.

The CreateConnection request specifies a CallId that will be used for identifying the call or session to which this connection belongs. More than one connection may actually share the same CallId. The CreateConnection request also specifies the endpoint to be used for this connection and the parameters to be used for the connection. These parameters may include for example voice encoding, and compression parameters. The call agent also specifies the mode of the connection. The mode may be "send," "receive," send/receive," "conference," "inactive," "data," "loopback," continuity test," "network loopback" or "network continuity test."

The CreateConnection request from the call agent may include a description of the remote side of the connection on the IP network i.e. parameters of the connection like encoding, but also IP address UDP port. The remote connection description may be unspecified in some CreateConnection requests. This occurs because the call agent needs to send two CreateConnection requests for creating an end to end connection. When the first CreateConnection request is sent the call agent doesn’t yet know the remote connection descriptor. This information may be provided later via a ModifyConection request.

A CreateConnection request may also include the parameters normally included in a NotificationRequest. This allows the call agent to send a CreateConnection and a NotificationRequest combined in one CreateConnection message. This improves the performance of the protocol.

When the gateway acknowledges the CreateConnection request it also sends to the call agent a ConnectionId that uniquely identifies the connection with in an endpoint and local connection information about the IP address and UDP port it selected. The call agent can potentially select those but the gateway may be sharing those resources for other functions and it is preferable that the gateway does the selection.

3.2.4 ModifyConnection

The Call Agent uses the ModifyConnection command for changing the parameters associated with a previously established connection. The parameters in the ModifyConnection command are the same as in a CreateConnection request. The ConnectionId is provided by the call agent to the gateway in a ModifyConnection request.

The ModifyConnection can be used for:

• Providing information about the other end of the connection through the remote connection descriptor
• Activating or deactivating a connection
• Changing the parameters of a connection.

3.2.5 DeleteConnection

The call agent can use the DeleteConnection command to delete an existing connection. When the gateway acknowledges a DeleteConnection request, it includes a list of parameters about the status of the connection in the response. These parameters include: numbers of packets and octets sent, number of packets and octets received, number of packets lost, inter-arrival jitter and average transmission delay.

The DeleteConnection command may also be sent by a gateway to the call agent for indicating that a connection can no longer be sustained.

3.2.6 AuditEndpoint

The AuditEndpoint command can be used by the call agent for getting details about the status of an endpoint or a list of endpoints. The information that can be audited by the Call Agent includes: requested events, dialing plan and connection identifiers. The response of the gateway includes all the requested information.

3.2.7 AuditConection

The AuditConnection can be used by the call agent for retrieving information related to a specific connection of an endpoint identified by a ConnectionId. The information that can be retrieved includes: call id, local and remote connection descriptors, local connection parameters and the mode of the connection. The response of the gateway to the AuditConnection request includes all the requested information.

3.2.8 RestartInProgress

The RestartInProgress command is used by the gateway to signal that an endpoint, or a group of endpoints, is taken in or out of service. The parameters of the RestartInProgress message indicate the group of endpoints that the message applies to. The RestartInProgress method also includes a parameter that specifies the type of restart:

• Graceful restart indicates that the endpoints will be taken out of service after a specified delay
• Forced restart indicates that the endpoints are taken immediately out of service
• Restart indicates that the service will be restored after the specified delay

4. Interworking Architectures

In this section, we discuss how our MGCP based network can interwork with other networks. We initially discuss how calls can be established between an MGCP controlled gateway and the PSTN. We also discuss how our architecture supports calls with SIP and H.323 based terminals.

4.1 Interworking with the PSTN

Integration with the PSTN is critical for our architecture and we have ensured that it happens transparently to service subscribers. In the first years of deployment, we expect that most of the calls that originate in the IP network will terminate in the PSTN and similarly calls that terminate in the IP network will have originated from the PSTN. Our goal is to make the fact that calls are crossing the two different networks transparent to service subscribers. The following figure describes how our architecture accomplishes the integration with the PSTN.

Figure 2. Interworking with the PSTN

The following flow describes in detail how a call that originates in the IP network and is destined for the PSTN is established in our architecture.

Integration with PSTN call flow

MGCP is used by the call agent for controlling the residential gateway (RGW) of the caller and the trunking gateway (TGW) that interconnects the IP network with the PSTN. The call agent exchanges ISUP messages over the SS7 network for terminating the call in the PSTN.

When the caller goes off-hook, the RGW sends a Notify message to the call agent that an off-hook event has occurred. The call agent immediately acknowledges that notification and examines the services associated to an off-hook action. The call agent provides a dialing plan to the gateway, and requests that the gateway play a dialtone via a NotificationRequest message. The RGW immediately acknowledges that request.

The RGW starts accumulating digits according to that digit map. When it has noticed a sufficient set of digits, it sends the observed string to the call agent via Notify command. The call agent immediately acknowledges that notification. The call agent will then seize the incoming circuit by asking the RGW to bind the originating telephone line to an IP address and port with a CreateConnection message. The connection is created in receive only mode. The RGW immediately acknowledges the creation, sending back the identification of the newly created connection and the session description used to receive audio data that includes the IP address and UDP port to be used for the connection. The RGW also identifies the specific encoding scheme used for the audio.

The call agent, having seized the incoming line and completed a routing look up to identify the outgoing gateway, must now seize the outgoing trunk. It does so by asking the Trunking Gateway (TGW) to bind the outgoing trunk to an IP address and port with a CreateConnection. The CreateConnection command has the same parameters as the command sent to the RGW, with three differences:

• The endpoint identifier points towards the trunk that will be used for routing the call
• The message carries the session description returned by the RGW
• The connection is bi-directional

The TGW acknowledges the connection request, sending in the session description its own parameters such as address, ports and RTP profile. The call agent then relays the IP information to the RGW, using a ModifyConnection request. The gateway immediately acknowledges the modification. At this stage, the call agent established a half-duplex transmission path.

When the caller goes off-hook, the RGW notifies the call agent, plays dialtone and collects digits as was shown in the call flow in Section 4.1.The call agent then creates the connection on the originating side in receive only mode as was shown in Section 4.1 and must now route the call to the terminating side. It does so by sending a SIP invitation to the SIP agent of the called party. The invite message includes the IP address and UDP port of the caller. The SIP agent sends a response indicating that it is ringing the user. The Call Agent then sends a NotificationRequest to the RGW of the caller requesting that the RGW provides a ringing tone to the caller. The RGW acknowledges the message.