|
|
The Content Transformation Engine Series is a network appliance that transforms and delivers applications to IP phones and a variety of mobile devices, including Wireless Application Protocol (WAP) phones and Personal Digital Assistants (PDAs). Your product license determines which devices are supported.
The following sections provide an overview to the CTE:
Improper configuration of the CTE can result in a security risk. Before you deploy the CTE, verify that the CTE does not have access to protected intranet sites. For more information, see the "Security" section.
The CTE is a 1U device that installs into any network infrastructure without requiring changes to the existing hardware or back-end software. The CTE sits in front of content servers and works with other networking products such as server load balancers, cache engines, web servers, firewalls, Virtual Private Network (VPN) solutions, routers, and IEEE 802.11 broadband wireless devices.
The CTE can display ScreenTop, which is a hierarchical services menu, on wireless devices and IP phones. ScreenTop provides users quick access to popular destinations such as news, sports, and travel information. You can make ScreenTop always available to IP phone users by using Call Manager to set a phone or phone group's idle URL to ScreenTop.com or to your CTE IP address if your site hosts a customized version of ScreenTop. ScreenTop appears on any device when the device connects to the CTE.
Design Studio is a PC-based application that you use to create transformation rules, modify the default ScreenTop, and upload your changes to a CTE.
The following sections summarize the features of the CTE:
The CTE content transformation features enable you to extend business applications to enterprise IP phone users as well as mobile device users without having to develop customized services for each device type. The CTE content transformation features include the following:
Mobile devices and IP phones use a variety of operating system platforms, presentation languages, and screen sizes and have different bandwidth constraints. The CTE manages these requirements on many devices automatically. The CTE supports content in the following formats:
By default, the CTE converts application and web content as follows:
The CTE data and session management features provide device users with secure, efficient, and reliable connections. Those features include the following:
Performance increases in a linear manner as you add more CTEs to a farm.
Many microbrowser devices, including IP phones, WAP phones, and 802.11 equipment, lack security and encryption features. The CTE, when used with secure web and application servers, can reduce the potential security issues associated with using such equipment.
Security features of the CTE include the following:
IP telephony is currently limited to HTTP, a non-secure protocol. The CTE SSL support allows you to deploy the CTE behind a firewall to provide a secure gateway to protect IP telephone connections beyond the firewall.
For more information, see the "Security" section.
The CTE uses rules supplied by Design Studio to fulfill requests for application content. When a device such as an IP phone requests application content, the CTE accepts the request from the device and requests the content from the back-end servers. Functioning as a reverse-proxy, the CTE acts like an application server to the client device and acts like a client device to the application servers.
The CTE is designed for flexible network deployment, allowing for both distributed and centralized installation. The CTE can be installed within a LAN environment at each customer location. Alternatively, CTEs can be centralized, close to web and application servers, to service users across an organization's WAN.
Regardless of the network deployment chosen, the only requirements that must be met to ensure correct operation are as follows:
To satisfy those requirements, you can specify gateways, static routing, and proxy servers during CTE configuration.
Figure 1-1 shows a CTE connected to an application server in an IP phone enterprise.
Figure 1-2 shows a CTE connected to a server load balancer in an IP phone enterprise.
 |
Note The numbers in Figure 1-2 refer to the following process. |
The path the user request takes is as follows:
1. An IP phone user requests application content. The IP phone PBX transmits the request to a server load balancer.
2. The server load balancer that receives the request evaluates the request header. The server load balancer directs requests from IP phones to the CTE.
3. The CTE terminates the request and then, acting as a proxy, sends a request to the server load balancer for the application content.
4. When the CTE receives the application content, it uses the rules in the configuration file to transform the content.
5. The CTE sends the transformed content to the server load balancer for forwarding to the IP phone.
Figure 1-3 shows the path that a wireless user request for application content takes when the CTE is connected to a server load balancer. This configuration is recommended for sites where most of the network traffic intercepted by the CTE uses application content supplied by servers directly connected to the server load balancer.
|
Note The numbers in Figure 1-3 refer to the following process. |
The path the wireless user request takes is as follows:
1. A wireless user requests a URL. A wireless carrier transmits the request to a communications tower, through the WAP carrier gateway, and to the Internet.
2. The server load balancer that receives the request evaluates the request header. The server load balancer directs HTML/XML requests to the server farm and directs requests from wireless devices to the CTE.
3. The CTE terminates the request and then, acting as a proxy, sends a request to the server load balancer for the HTML/XML page.
4. When the CTE receives the page, it uses the rules in the configuration file to transform the content.
5. The CTE sends the transformed page to the server load balancer for forwarding to the wireless device.
Another configuration is to direct requests from the CTE through a router that sits in front of the server load balancer, as shown in Figure 1-4. This configuration is recommended for sites where most of the network traffic intercepted by the CTE uses content supplied by servers at other locations. For example, a results page served by a search engine portal contains links to content that resides outside of the domain of the search site.
You can connect a CTE to an application server that routes traffic to the CTE or to servers based on browser detection, as shown in Figure 1-5.
You can also connect a CTE directly to an application server, as shown in Figure 1-6. In this case, all traffic goes through the CTE, which passes HTML/XML requests to the server and handles requests from wireless devices. This configuration is recommended when you designate specific IP addresses for wireless traffic.
Improper configuration of the CTE can result in a security risk. Before you deploy the CTE, verify that it does not have access to protected intranet sites.
By default, the CTE proxies all requested applications and web pages, whether or not they have corresponding transformation instructions. You can disable this unrestricted proxy so that the CTE proxies only the applications and web pages it has transformed to prevent access to protected servers that are on the same subnet as the CTE. To change the Unrestricted Proxy setting, go to the Advanced > General screen of the CTE Administration Tool.
|
Note If you use the default configuration so that the CTE proxies all applications and web pages, the CTE provides access to computers on the same subnet as the application servers that are configured to work with the CTE. For example, suppose a CTE has an external IP address of 24.221.1.1 and an internal IP address of 192.168.1.31. On the same subnet, you have an intranet server protected from outside access, with an IP address of 192.168.1.20. You can then access all ports on the protected intranet server through the CTE by using the URL http://24.221.1.1/http://192.168.1.20. |
Be aware of the following security considerations:
Because IP phones do not support Secure Sockets Layer (SSL), the connection between the IP phones and the CTE is not secure. We recommend that you locate the connection between an IP phone and the CTE behind a firewall.
When Design Studio is redirected to an SSL site from a non-SSL site (from HTTPS to HTTP), the connection between Design Studio and the CTE is not secure. We recommend that you locate the connection between Design Studio and the CTE behind a firewall.
Internet, extranet, and intranet sites require different levels of security, all supported by the CTE. As shown in Figure 1-7, those sites have the following characteristics:
The CTE supports Basic authentication and 407 Proxy authentication using NTLM and prompts device users for authentication credentials if they are required. In addition, the CTE provides authentication mechanisms for devices that do not natively support authentication (such as Palm devices).
The CTE terminates SSL sessions to provide an endpoint for a secure connection. Some PDAs support SSL connections from the device to the CTE. However, WAP phones and the Palm VII device do not support SSL. WAP phones use Wireless Transport Layer Security (WTLS), and Palm VII devices use Elliptical Curve Cryptography (ECC). Carrier gateways usually convert WTLS and ECC to SSL; during the conversion, text is not secure.
The following sections provide an overview to CTE operation:
The CTE includes FLEXlm licensing. All devices use floating (networked concurrent) licensing. Floating licensing limits the number of concurrent CTE users to the number of licenses purchased. Floating licensing requires no setup or administration.
You can upload a new license through the CTE Administration Tool, as described in the "Managing Licenses" section.
When a CTE transforms application content, the transformation performed includes default transformations, summarized in the "Back-End Content Transformation" section, and transformations controlled through user-editable files.
The user-editable files that control transformations are as follows:
A configuration file contains transformation rules, the instructions that the CTE uses to transform the original content of an application or web page into the content that you want delivered to a device. Design Studio converts transformation rules into XSL. The CTE uses XSLT to transform web pages according to the rules specified in XSL.
To put a configuration file into production, a Design Studio user publishes it to the CTE used for production. The new file replaces or merges with the configuration file previously in effect on the CTE. Only one configuration file can reside on a CTE at a time.
Rather than using Design Studio to create transformations, you can include CTE XHTML extensions in source HTML files to indicate transformations for a particular device. Typically, this method of specifying transformation rules is handled by an application developer during the initial implementation of an application or web page. An application developer includes XHTML extensions to indicate content that should be selected or clipped for a particular device. If different transformations are required for the various device types, sections of the application may need to be replicated for each device.
The CTE determines how to transcode a site for a particular device based on settings in a Device Definition File (DDF). For example, the CTE uses the specifications in a DDF to determine how to handle the images it sends to a device. You can use Design Studio to tune those specifications.
Figure 1-8 and the following procedure describe how application content requests from a requesting device are handled by the CTE and connected devices.
|
Note The numbers in Figure 1-8 refer to the steps in the following procedure. |
When a device sends a request to an application server, the traffic flow is as follows:
Step 2 The server load balancer that receives the request looks at the header.
Step 3 The server load balancer directs HTML/XML requests to the server farm.
Step 4 The server load balancer directs requests from devices to the CTE.
Step 5 The CTE sends the new request to the server load balancer for the application content. The CTE, acting as a proxy, sends a request to the server load balancer for the application content. The server load balancer obtains the content from a server and sends it to the CTE.
Step 6 The CTE uses the rules and device definitions created in Design Studio to transform the content and then sends the transformed content to the server load balancer. The server load balancer forwards the content to the requesting device.
As shown in Figure 1-9, you can also route requests based on a URL, so that requests from designated URLs (such as mobile.site.com) are passed directly to the CTE.
The CTE supports secure connections and session persistence (stickiness), acting as a proxy on behalf of clients to maintain sessions. Session persistence is important for applications such as SSL or where user authentication is necessary in order to retrieve content. In such cases, users must remain stuck to the original transformation device to which they connected in order to prevent data loss or a denial of request for the user transaction.
The CTE listens on all interfaces for connections. When a device user makes a first request through the CTE, the CTE creates a new session for that user. The CTE must store data for each session; therefore, the number of active sessions is limited by memory. The CTE holds an outgoing connection to the server open for further requests. It closes an incoming connection to the client after a request.
The CTE supports two configuration options to control the cache that stores session data: maximum and minimum session-timeout thresholds. Both of these settings (Session Timeout and Minimum Session Time) can be set through the Advanced > General screen in the CTE Administration Tool. For more information, see the "Configuring Session and Connection Settings" section.
Another variable affecting performance is the number of simultaneous connections. A connection is used for each request. A session can use several simultaneous connections. For example, when a user requests a web page and that page contains images, frames, and other elements, the user's browser makes one request for each element. If a page has ten elements, the initial request makes one connection to retrieve the main page, and the browser makes ten connections to retrieve the ten elements.
Posted: Mon Aug 18 15:34:40 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
