Chapter 2: Solution Architecture and Services

Table Of Contents

Solution Architecture and Services

Basic Wholesale Voice and Dial Network Architectures

Basic Wholesale Voice Network Architecture

Basic Wholesale Dial Network Architecture

Merging Voice and Dial Services: Service Scenarios

Dial and Wireless Data

PC to Phone

Prepaid VoIP

Phone to Phone

Unified Communications

TDM Switching

T.38 Fax Service

Solution Architecture and Services

This chapter introduces a variety of topologies that make up the architecture of the Cisco ASAP Solution. This provides a foundation for understanding the deployment of various services, and introduces a variety of issues that must be taken into consideration for each service or service mix.

This chapter presents the following major topics:

• Basic Wholesale Voice and Dial Network Architectures

• Merging Voice and Dial Services: Service Scenarios

Basic Wholesale Voice and Dial Network Architectures

The basic network architectures for wholesale voice (VoIP) and dial are not identical, assuming that each is specific to a single medium. As the utility of universal ports and universal gateways makes evident, such networks are becoming increasingly less practical for reasons of economics and management efficiency. Nevertheless, it is worthwhile to begin by discussing the differences.

Basic Wholesale Voice Network Architecture

Figure 2-1 illustrates the basic architecture of a wholesale voice network. Note the following characteristics:

•PSTN end offices (EOs), supporting the subscriber at both aggregation and termination (ingress and egress) ends

•Voice-enabled gateways

•Support for SS7 signaling

•Accounting and settlement applications as needed, to support billing

•Prompt servers (such as IVR servers) as needed

•RADIUS and AAA servers (not shown) as needed, to support authenticaion and accounting

•Compliance with the H.323 protocol

Note Initial releases of the Cisco ASAP Solution do not provide support for SIP and MGCP.

Note For a detailed discussion of wholesale voice architectures and their requirements and features, see the documents provided for the Cisco Wholesale Voice Solution, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/index.htm
Documentation for the Cisco ASAP Solution will refer to these documents as needed.

Figure 2-1 Basic Wholesale Voice Network Architecture

Basic Wholesale Dial Network Architecture

Figure 2-2 illustrates the basic architecture of a wholesale dial network. Note the following characteristics:

•A PSTN EO to support the subscriber at the aggregation end

•The absence of voice-enabled gateways

•RADIUS and AAA servers (not shown) as needed, to support authenticaion and accounting

•Port policy management (PPM) applications, to manage dial ports efficiently

•Support for SS7 signaling

Note In initial releases of the Cisco ASAP Solution, wholesale dial signaling is limited to SS7 functionality. However, SS7 signaling support is not always required.

Figure 2-2 Basic Wholesale Dial Network Architecture

Merging Voice and Dial Services: Service Scenarios

With the universal gateways (UGs), it is now possible to merge the voice and data worlds. An understanding of basic service scenarios, as well as their call flows, will make it easier to deploy a Cisco ASAP Solution successfully. Scenarios are presented below for the following services:

• Dial and Wireless Data

• PC to Phone

• Prepaid VoIP

• Phone to Phone

• Unified Communications

• TDM Switching

• T.38 Fax Service

Note the following with respect to these services:

•The call flows are generalized to illustrate functional steps of interest in a given service. Protocol exchanges are not detailed.

•The details of access into the ITSP network are not shown, as access can take a variety of forms.

•It is assumed that GWs are configured to provide H.323 RAS messaging.

•SS7 infrastructure and signaling are not shown.

•H.323 call proxy servers are optional components that hide the identity of the originating endpoints. Their H.323 functionality is the same as that of an H.323-capable GW.

Dial and Wireless Data

Network Diagram

Figure 2-3 illustrates an example network and call flows for a dial and wireless data service. The call flow is described following the figure.

Note To simplify the illustration template in the figures that follow, "PPM/AAA server" can be either a PPM server (such as RPMS) or an AAA server. They are not the same entity. The call flows explicitly state the type of server that is addressed.

Figure 2-3 Dial and Wireless Data

Dial and Wireless Call Flow

1. The subscriber's call arrives from the PSTN. This can be a traditional telephone call or wireless call, with the called number of a dial access service.

2. Before accepting the call, the GW sends a preauthentication request to the PPM server.

3. The PPM server checks the port policy for the retail ISP and returns information to the GW as to whether to accept or reject the call. The following step assumes the call is accepted on the PPM server.

4. The GW accepts the call and authenticates the user by sending an authentication request to the AAA server.

5. If the AAA server is performing a RADIUS proxy role, it will forward the authentication request to the retail ISP's AAA server.

6. The retail ISP's AAA server either accepts or denies the user, and returns this status to the RADIUS AAA proxy server. The following step assumes the call is accepted by the retail ISP's AAA server.

7. The RADIUS AAA server forwards the acceptance status to the originating GW.

8. The user's call enters the Internet.

PC to Phone

Network Diagram

Figure 2-4 illustrates an example network and call flows for a PC to phone service. The call flow is described following the figure.

Figure 2-4 PC to Phone

PC-to-Phone Call Flow

1. The subscriber at a PC with VoIP software "dials," sends an admission request to an H.323-based call proxy server, which functions as the OGW.

Note For an illustration of H.323 RAS messaging and further reference, refer to Chapter 2, "Provisioning the Gatekeeper Core," of the Cisco Wholesale Voice Design and Implementation Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm

The user is assumed to be "registered" on the call proxy server, which authenticates the subscriber.

2. Following a successful challenge, the call proxy server queries the local GK as to where to send the call.

In this example, the call terminates in another zone.

3. The zone (originating) GK forwards the location request to the ITSP DGK.

4. The ITSP DGK queries the DGK in the Cisco ASAP network.

5. The Cisco ASAP DGK sends a location request to its zone (terminating) GK to confirm that the requested E.164 address can be serviced.

6. If so, the terminating GK confirms this to the originating GK.

7. Following the successful confirmation, the originating GK sends a confirmation to the OGW.

8. The call is set up between the call proxy server and the TGW.

9. The TGW sends a request for admission to the terminating GK.

10. The terminating GK sends confirmation that the address can be serviced.

11. The call proceeds to a wireline or wireless network.

Prepaid VoIP

Network Diagram

Figure 2-5 illustrates an example network and call flows for a RADIUS-based prepaid phone service. Ingress trunks are SS7, and egress trunks are SS7, CAS, or PRI. This is similar to Dial and Wireless Data, except that (1) RADIUS is used exclusively, (2) there are no interconnections between different SPs, and (3) the RAS messaging is illustrated. In addition, no DGK-DGK transactions are required as in PC to Phone, as this example assumes a single zone. The call flow is described following the figure.

Figure 2-5 Prepaid VoIP

Note RADIUS-based prepaid calling, including some third-party applications used to realize it, is discussed extensively in Chapter 3, "Provisioning Shared Support Services," in the Cisco Wholesale Voice Solution Design and Implementation Guide, at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/access/sc/rel7/soln/wv_rel1/wvpg/index.htm

Prepaid VoIP Call Flow

1. Prompt scripts previously loaded to prompt/TFTP server are downloaded to originating (ingress) GW.

Such a server is ideal for holding large and multiple audio files, which can be downloaded dynamically as required.

2. The subscriber's call arrives from the PSTN. This can be a traditional telephone call, with the called number of a prepaid service.

On the OGW, the called number matches a dial peer with a call to an application of type, for example, "debit-card."

3. The appropriate IVR audio file is played. This welcomes the user and prompts the user for an account number.

4. The user enters an account number and the OGW collects the number (as DTMF tones) and passes it to a AAA server in the Cisco ASAP network for verification.

5. If the number matches the user's account number in the AAA database, the AAA server so notifies the OGW.

6. The appropriate IVR audio file on the OGW prompts the user to enter a PIN.

7. The OGW passes the PIN information to an AAA server for verification.

8. On a successful PIN match, the AAA server forwards confirmation to the OGW.

9. The appropriate audio file on the OGW prompts the user for a number to dial.

10. The OGW passes the called number to the AAA server.

11. The AAA server confirms or denies admission.

Note Only on a confirmation does the following take place.

12. The OGW forwards the request for admission to the Cisco ASAP DGK.

13. The Cisco ASAP DGK responds affirmatively to the OGW that the TGW can handle the call.

14. The call is set up between the OGW and the TGW.

15. The TGW sends a request for admission to the GK.

16. The GK sends confirmation to the TGW.

17. The call proceeds to wireline or wireless networks.

Phone to Phone

Network Diagram

Figure 2-6 illustrates an example network and call flows for a simple phone-to-phone service. No transactions other than RAS are involved. The call flow is described following the figure.

Note Long-Distance Toll Bypass, illustrates an application of phone-to-phone service for bulk use by ISPs; the implementation is the same.

Figure 2-6 Phone to Phone

Phone-to-Phone Call Flow

1. The subscriber's call arrives from the wireline or wireless PSTN.

No interactive prompts are involved.

2. The OGW forwards a request for admission to the Cisco ASAP GK.

3. The Cisco ASAP GK sends confirmation to the OGW.

4. The call is set up between the OGW and the TGW.

5. The TGW sends a request for admission to the Cisco ASAP GK.

6. The Cisco ASAP GK sends confirmation to the TGW.

7. The call proceeds to wireline or wireless networks.

Long-Distance Toll Bypass

Long-distance toll bypass is an application of phone-to-phone service that is well-suited to the bulk call-routing needs of certain ISPs. By leveraging their existing data infrastructure and subscriber bases, ISPs can deliver carrier-class long-distance voice services over low-cost IP networks. With universal GWs as VoIP GWs, the Cisco ASAP Solution allows ISPs to carry voice traffic over packet networks, offering carrier-class domestic and international phone calls. Subscribers make long-distance calls from a regular telephone at home or office, or from other locations by entering an account number or password. No server lookup or IVR is needed. Calls are forwarded from the PSTN through the ingress UG to the egress UG, simply on the basis of the dial peer configuration, in a manner similar to TDM switching (see TDM Switching). Ingress trunks are SS7, and egress trunks are SS7, CAS, or PRI. Figure 2-7 illustrates the toll-bypass feature.

Note This feature is also supported on Cisco VoIP-enabled GWs.

Figure 2-7 Long-Distance Toll Bypass

Unified Communications

Unified communications services are provided by third parties, and include such solutions as voice mail over IP, fax store and forward, single-number reach, and so on. In addition, refer to Cisco's Internet Communications Software at the following URL:

http://www.cisco.com/warp/public/180/

Network Diagram

Figure 2-8 illustrates an example network and call flows for a unified communications (UC) service. This view is quite simplified. Depending on the size of the network, UC servers can require substantial capabilities (they perform considerably more signaling and functionality than is shown here) and are often clustered in server farms. The call flow is described following the figure.

Note Initial releases of the Cisco ASAP Solution do not support T.37 (store-and-forward fax through e-mail, using SMTP and MIME).

Figure 2-8 Unified Communications

Unified Communications Call Flow

1. The subscriber's call arrives from the wireline or wireless PSTN.

2. The OGW sends a request for admission to the Cisco ASAP GK.

3. The Cisco ASAP GK sends confirmation to the OGW.

4. The call proceeds to the UC server, to be handled in a variety of possible ways.

Tip For detailed technical discussion of unified messaging and its capabilities, refer to Unified Messaging at the following URL:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/um_isd.htm

TDM Switching

TDM switching is the ability of Cisco UGs to switch information directly between two DS0 circuits without affecting the data. Figure 2-9 illustrates this feature. The two calls, one incoming and one outgoing, are connected through a time slot interchange (TSI) function in the DS1/DS3 trunk card.

Figure 2-9 TDM Switching

This feature allows legacy systems to be maintained while new services are added. As demonstrated in Figure 2-10, the SP can migrate gracefully to Cisco ASAP technology while redirecting calls (dotted lines) to legacy equipment or PSTN switches as needed. With support for PRI and CAS, legacy systems can continue to be used.

Figure 2-10 Migration from Legacy and PSTN Services

The following additional benefits can also be realized:

•Cisco UGs are well-suited to customers requiring PRI grooming in conjunction with VoIP, dial, and fax services.

•Interconnect costs are reduced. IMT (SS7) trunks are 40 to 70% cheaper than PRI trunks.

Note Initial releases of the Cisco ASAP Solution do not support SS7-to-SS7 switching with ISUP transparency.

•External test equipment is supported. TDM switching can be used to connect test-tone generating devices. Type 105 test tones in the Cisco UGs can be provided by connecting to external text equipment through TDM cross-connections.

Support for DS0 Cross-Connections

TDM switching is supported on T1, E1, and DS3 interface cards. In Cisco UGs, both trunk and DSP cards provide onboard TSI functionality. DS0 channels used in TDM-switched calls can come from the same T1/E1 interface or different T1/E1 interfaces in the GW. Once two DS0s are cross-connected, the TSI circuitry is responsible for transmitting and receiving PCM data to and from the two DS0s. The circuitry also makes it possible to include any type of bearer data. Any ingress (received) DS0 on any DS1 or DS3 can be switched to an egress (transmit) DS0 on the same or a different DS1 or DS3.

Special Issues

Note the following special issues with respect to the DSP resources used in TDM switching:

•Switching between SS7-CAS or PRI-CAS

When a CAS trunk is involved in TDM switching (on any Cisco GW), the DSP resource is required to set up the connection. This resource stays in the call path once the call is established. This is required to monitor the inband signaling (A, B, C, and D bits), so that the call can drop normally. With non-CAS calls, no DSP resources are used after the call connection is established.

•CAS-to-CAS Calls

If two CAS calls are involved in the TDM switching session, then each leg of the call uses one DSP resource. Once the call is established, both resources stay in the call path to monitor the inband signaling (A, B, C, and D bits), so that the call can drop normally.

•Interactive Voice Response

VoIP calls using interactive voice response (IVR) in any portion of the call legs will also use DSP resources. When an incoming call uses IVR functionality, the DSP resource is not released until the call is released.

Support for Call Types

Table 2-1 shows the types of calls supported by TDM switching in the Cisco ASAP Solution.

Table 2-1 Types of Calls Supported by TDM Switching

Origination/Termination

Comments

SS7/PRI

Incoming calls originate on IMTs (SS7 trunks), terminate on ISDN PRI trunks.

Incoming calls originate on ISDN PRI trunks, terminate on IMTs.

Both network-side and user-side PRI interfaces are supported.

Both E1 and T1 are supported.

SS7/SS7

Incoming calls originate and terminate on IMTs, using the same ISUP variant.

Note In initial releases of the Cisco ASAP Solution, SS7-to-SS7 TDM switching with ISUP transparency is not supported. In addition, for outgoing calls, the GW cannot select a specific group of IMTs, which may be connected to a specific switch, as the GW does not currently support multiple trunk groups.

Table 2-2 shows the support for ISUP in VoIP calls originating from the PSTN.

Table 2-2 Types of ISUP VoIP Calls Supported by TDM Switching

ISUP Interface

Comments

ISUP to ISUP

Voice calls originate in the PSTN with SS7 signaling, traverse the H.323 VoIP network, and terminate in the PSTN on IMTs.

ISUP to CAS

Voice calls originate in the PSTN on IMTs, traverse the H.323 VoIP network, and terminate in the PSTN on CAS trunks.

ISUP to PRI

Voice calls originate or terminate in the PSTN with SS7 signaling, traverse the VoIP network, and terminate or originate in the PSTN on PRI trunks.

T.38 Fax Service

The Cisco ASAP Solution supports Cisco T.38 Real-Time and Never-Busy Fax Service. For details, refer to Fax Services at the following URL:

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/fax_isd.htm

Origination/Termination	Comments
SS7/PRI	Incoming calls originate on IMTs (SS7 trunks), terminate on ISDN PRI trunks. Incoming calls originate on ISDN PRI trunks, terminate on IMTs. Both network-side and user-side PRI interfaces are supported. Both E1 and T1 are supported.
SS7/SS7	Incoming calls originate and terminate on IMTs, using the same ISUP variant.

ISUP Interface	Comments
ISUP to ISUP	Voice calls originate in the PSTN with SS7 signaling, traverse the H.323 VoIP network, and terminate in the PSTN on IMTs.
ISUP to CAS	Voice calls originate in the PSTN on IMTs, traverse the H.323 VoIP network, and terminate in the PSTN on CAS trunks.
ISUP to PRI	Voice calls originate or terminate in the PSTN with SS7 signaling, traverse the VoIP network, and terminate or originate in the PSTN on PRI trunks.