US20100208634A1 - System and Method For Managing Multimedia Communications Across Convergent Networks - Google Patents

The present invention provides for bidirectional or duplex transmission of multimedia content such as live video and/or audio between access devices of a calling party and a called party in a convergent network. The quality of transmission is managed through a convergent communications platform, which periodically tests performance characteristics of network routes in operative communication with the platform, categorizes the network routes based on measured performance metrics, and selects network operators whose network characteristics meet the desired quality parameters of a particular multimedia content to be transmitted (e.g., real-time high definition video conference). The management of transmissions is transparent to the end users who will be able to communicate with others regardless of the type of devices or networks the called parties use or subscribe to.

BACKGROUND OF THE INVENTION

• 1. Cross Reference to Related Applications

• The present application is a continuation-in-part of U.S. patent application Ser. No. 11/042,597 filed on Jan. 24, 2005, which claims priority to an earlier filed U.S. Provisional Patent Application No. 60/538,320, filed on Jan. 22, 2004. U.S. patent application Ser. No. 11/042,597 is a Continuation-in-Part of U.S. patent application Ser. No. 10/671,315, filed on Sep. 25, 2003, which is a continuation-in-part of application Ser. No. 09/368,828, filed Aug. 5, 1999, which is a continuation-in-part of application Ser. No. 09/213,703 (now U.S. Pat. No. 6,144,727), filed Dec. 17, 1998, which is a continuation-in-part of application Ser. No. 09/129,413 (now U.S. Pat. No. 6,226,365) filed Aug. 5, 1998; and application Ser. No. 08/927,443, (now U.S. Pat. No. 6,005,926) filed Sep. 11, 1997, which is a continuation-in-part of U.S. patent application Ser. No. 08/920,567, filed Aug. 29, 1997, all of which are incorporated herein by reference.

• The present application is also a continuation-in-part of U.S. patent application Ser. No. 11/895,460, filed on Aug. 24, 2007, which is a continuation of U.S. patent application Ser. No. 10/941,471, filed Sep. 15, 2004, which is a continuation of U.S. patent application Ser. No. 09/551,189, filed Apr. 17, 2000, which is a continuation of U.S. patent application Ser. No. 08/727,681, filed Oct. 8, 1996, issued as U.S. Pat. No. 6,188,756, which is a continuation-in-part of U.S. patent application Ser. No. 08/320,269, filed Oct. 11, 1994, now abandoned.

• 2. Field of the Invention

• The present invention relates to the managing of communications through the IP network. In particular, the present invention relates to the optimization of the routing of multimedia communications among user devices across convergent networks.

• 3. Introduction

• Not so long ago, Voice over the Internet (VoIP) revolutionized the telecommunications world, and accelerated the obsolescence of the Public Switched Telephone Network (PSTN), which is defined herein as the hierarchical Time Division Multiplexing (TDM) network of mobile and fixed line switches and dedicated transmission links. The world of telecommunications is now approaching another inflection point. With computing devices rapidly evolving to include sophisticated communicating functions, consumers or end users are becoming more and more exposed to the possibilities of communicating with each other via audio and visual media. Voice calls no longer suffice as a means of communication. This phenomenon is what some may call telecommunications media convergence which transcends traditional telecom industries such as fixed, mobile, and IP service providers. Convergence is the combination of different media into one operating platform. Thus, a convergent network (as used herein) is a network comprising various protocol-specific networks such as circuit-switched, mobile, and IP networks which are interconnected with each other. It is the merger of telecom, data processing and imaging technologies. This convergence is shepherding in a new era of multimedia communication, wherein voice, data, images and video are merged and become part and parcel of any telecommunications services demanded by the end users.

• In this convergent world, the network operators must be capable of routing high quality multimedia contents between fixed or mobile devices such as, for example, smart phones, laptops, iPads, desktops, and audio-video equipment. To provide a quality user experience, network operators need to ensure their networks have the requisite or appropriate transmission characteristics such as bandwidth, latency, and jitter in the case of an IP network for the transmission of multimedia content. However, traditional network operators' ability to choose routes are confined to their own networks and typically do not have control over communications that transcend across multiple networks. Moreover, the transmission of multimedia content, especially broadcast quality high definition video, requires the networks to transport the content with high fidelity, i.e. with little or no loss of data. This is a difficult task in a world where the IP networks dominate and offer the least cost alternative for content transmission, but which are notorious for latency and packet loss. When the multimedia communications occur over the disparate networks of different technologies and protocols, the management of high quality multimedia communications can become insurmountable or very expensive.

• Accordingly, there is a need for a cost-effective system that can manage and selectively route multimedia communications among multiple parties, transparent and seamless to the users, through one or more service providers or network operators based on user requirements. Such requirements may be based on, for example, whether the content comprises high definition video or merely voice data coupled with low fidelity video or based on the hardware and/or client software characteristics of the access devices. In the case of internet service providers, and as explained below, the system can perform practical quality test measurements of each route available or offered by the internet service providers for routing subscriber communications traffic.

• Some insight into the workings of the Internet is in order. It is widely known that the Internet is a worldwide network of interconnected networks. Each individual host connected to the internet has an IP address. To send a data packet from one host to another, the data packet must be routed through the Internet. To accomplish this, each host includes a routing table the host uses to determine which physical interface address to use for sending the data. When a host receives a data packet, the data packet is either intended for that host or intended for another host. When the latter occurs, the host retransmits the packet using its own route table. Route tables are based on static rules or dynamic rules via routing protocols. Accordingly, the quality of the route depends on the quality of each host that the packet passes through and the network elements that connect the hosts. It would be useful to know the quality level of each particular host along a route so that packets requiring a higher quality could be routed using hosts having a high quality measurement score.

• Some individual quality indicators such as, for example, latency, availability, packet loss may be determined for certain routes on the Internet. However, depending on the type of multimedia content to be delivered, the best route for one application (e.g. near real-time broadcast) may be the route with the lowest latency characteristics, while the best route for another application (e.g. high definition video) may require the least packet loss characteristic.

SUMMARY OF THE INVENTION

• An object of the present invention is to provide a method and system for optimized routing of bidirectional or duplex multimedia communications among multiple parties in a convergent network.

• Another object of the invention is to facilitate communication between otherwise incompatible communication networks in a manner that is transparent to the calling and called parties. Preferably, the communication is routed based on the results from an evaluation of all available communication networks even though the calling party may have direct access to only one type of communication network. Control information in the form of an inquiry of the availability status of the party to be called may be sent through different networks by routing it through a control location or gateway of the inventive system that converts it into a compatible form. For instance, the called party may be using one type of network, such as a data network (e.g. IP network, GPRS or 3G), while the calling party is using another, such as a GSM cellular network (or circuit switched network). A system that delivers and converts telecommunications traffic across multiple networks including IP network(s) such as the Internet is disclosed in a parent application, U.S. patent application Ser. No. 11/895,460 (the '460 patent application), which is incorporated herein by reference in its entirety.

• Still another object of the invention is to enable a user device to communicate audio and/or video content on a one-to-one (i.e. unicast) or one-to-many (multicast) basis using optimized routes through the IP network.

• In one aspect of the invention, a convergent communications platform interconnects Internet Backbone Providers (IBPs), as sellers, and Internet Service Providers (ISPs) as buyers of IP capacity in the form of routes within networks owned by the sellers (on-net routes), routes in networks that are not owned by the seller (off-net routes), or routes which include both on-net and off-net portions. The platform routes traffic to the sellers based on the type of service required for transmitting the communications traffic between the calling (i.e. transmitting) and called (i.e. receiving) parties.

• In another aspect of the invention, the convergent communications platform includes (1) a control node for call signaling or session control of communications between user devices and the delivery of the multimedia content, and (2) a database for storing profiles and data related to the user devices. The control node is configured to include SIP servers for call session controls, media servers for the manipulation and delivery of content, and switches for switching communications traffic to selected seller networks. Gateways in operable communication with the control node convert signals and multimedia content between otherwise incompatible telecommunications networks. The user devices may be identified by MAC address, IMSI, TMSI, URI, IMEI, MSISDN, or a universal identifier selected by or assigned to the user and registered with the convergent communications platform for identifying all of his devices capable of accessing the various networks through the platform.

• In one embodiment, the platform facilitates bidirectional communications (e.g., video conferencing), or unicast and/or multicast by distributing the multimedia streams from a transmitting user device to one or more receiving user devices as designated by the users, and vice versa. Such functions would be desirable in a broadcast mode (i.e. one way transmission) or a video conferencing mode (i.e. bidirectional transmission). The user or transmitting device specifies the one or more receivers for receiving the communication and the control node contacts the receivers using signaling control systems such as SIP servers, SS7 networks, or their equivalents.

• In another embodiment, the platform, in a multicast mode, directs one or more receiving device to report the available bandwidth in its local network so as to enable the platform to select a receiving device (or node) to retransmit or uplink the multimedia content to another receiving device (in a manner that may be referred to as P2P or P4P). In this manner, the platform need not establish a one-to-one client-server relationship with each receiving device, thereby reducing the bandwidth requirement on the platform and shifting the bandwidth usage onto the local network of the user devices. An advantage of this streaming technique is to allow for real time scaling of a multicast audience without overwhelming the allocated channel capacities of the platform. Another advantage of such technique is to enable a service provider to optimize the local bandwidth usage of local networks.

• Secure bidirectional multimedia communication may be provided by creating a secure channel between the platform and the user devices through the use of secure web protocols similar to the HTTPS protocol. In this case, the platform serves as the hub for encrypting and decrypting the multimedia communications between the sending and receiving devices.

• The routing of communications traffic may be driven by an optimized routing application, which determines traffic distribution to participating sellers (i.e. IBPs selling IP routes) with the desired quality within certain pricing and quality parameters based on user defined preferences or otherwise required by user devices. The platform may generate an optimized routing table customized for each buyer to suit their unique combination of price and quality parameters.

• According to another aspect of the invention, the platform measures the quality of the IP routes of the sellers by testing the penultimate hop router or the last network device in accordance with the quality measuring system more described herein and in the parent application U.S. patent application Ser. No. 11/042,597 (the '597 patent application), which is incorporated herein by reference in its entirety.

• According to yet another aspect, there is provided a multi-modal access device capable of establishing a call session through a cellular, a circuit switched or an IP network. It is configured to include contact information of a called party that comprises a telephone number and a user identification for an IP based communication service provider (e.g. Google Voice™ or Skype™), the access device being responsive to a user selection of the called party for communication. The access device establishes a call session with the called party via the IP based communication service provider when the IP based communication service provider indicates the called party is available or via the cellular or circuit switched network when the IP based communication service provider indicates the called party is not available. The access device may have direct access to presence information database to determine availability of a called party. The presence information includes status information such as “on-line”, “away”, “mobile”, etc. of a user of services (e.g. instant messaging or chat) of an IP based communications service provider.

• Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims. It should be further understood that the drawings are not necessarily drawn to scale and that, unless otherwise indicated, they are merely intended to conceptually illustrate the structures and procedures described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

• In the drawings:

• FIG. 1

  is a schematic block diagram of the network architecture in which the present invention is applied;

• FIG. 2

  diagrammatically illustrates an embodiment of the session control layer of the inventive network;

• FIG. 3

  is an embodiment of a registry of subscribers registered with the central node or convergent communications platform;

• FIG. 4

  is a flow diagram of another embodiment wherein a multimodal access device automatically searches for a least cost routing solution for terminating a call;

• FIG. 5

  depicts the service delivery layer of the inventive network wherein multimedia communications are converted across disparate networks between access devices;

• FIG. 6

  is a schematic representation of a central local node interacting with networks disclosed in a parent application (the '460 patent application) in accordance with the invention;

• FIG. 7

  is a system for performing penultimate router testing;

• FIG. 8

  is a flow diagram of the basic steps of the quality measurement method;

• FIG. 9

  is a flow diagram of the steps for determining useful IP network prefixes;

• FIG. 10

  is a flow diagram of the steps for finding the penultimate hop router for each IP network prefix to be tested;

• FIG. 11

  is a flow diagram of the basic testing steps for each of the IP network prefixes;

• FIG. 12

  is a flow diagram of the steps for determining which routers to test;

• FIG. 13

  is a flow diagram of the steps for packet loss and latency testing;

• FIG. 14

  is a diagram showing the format of file for a member quality matrix;

• FIG. 15

  is a flow diagram showing the steps for augmenting quality metrics with externally collected performance information;

• FIG. 16

  illustrates the calling and called parties engaged in bidirectional multimedia communications; and

• FIG. 17

  diagrammatically illustrates the call setup procedure in accordance with the invention.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

• The present invention provides for bidirectional or duplex transmission of multimedia content between access devices of the calling and called parties in a convergent network. The quality of transmission is managed through a convergent communications platform, which periodically tests performance characteristics of network routes in operative communication with the platform, categorizes the network routes based on measured performance metrics, and selects network operator whose network characteristics meet the desired quality parameters of a particular multimedia content to be transmitted (e.g., real-time high definition video conference). The management of transmissions is transparent to the end users who will be able to communicate with others regardless of the type of devices or networks the called parties use or subscribe to.

• A. Convergent Network

• FIG. 1

  shows a convergent network that includes an IP network 60 (such as the Internet), a cellular network 62 (e.g. CDMA, GSM, and IMT-2000), GPRS or 3G network (including the Long Term Evolution (LTE) network) 64, a

  WiMAX network

  66, a circuit switched network 68 (e.g., TDM), and a satellite system 70 (e.g. Low or Medium Earth Orbit communication satellites with low latency).

  Access devices

  72 may be communicatively connected to each other through the convergent network via the

  IP network

  60 and managed by a convergent communications platform 74 (which is described in more details below and may include at least one control node). The

  access devices

  72 may be desktop PCs, smart phones (e.g., iPhone™ or Blackberry® phones), cell phones, fixed line phones, laptop computers, or any computing devices that have either built-in or add-on capability to establish a call session with

  other access devices

  72. The

  platform

  74 may include servers or modules for performing Subscriber Location Service (for locating network locations of subscribers), Subscriber Registry (for storing subscriber profiles), Subscription Management (for managing the subscription levels of the subscribers), Service Delivery Management (for managing delivery of multimedia content across networks), Call Session Control (for establishing call sessions), and QoS Management (for managing the quality of network performance).

  Gateways

  76 are provided to interface, convert signals and media as necessary between networks to resolve any incompatibilities due to different telecommunications protocols and codecs, etc. For example, a PSTN/IP signaling gateway may convert call control signals between IP protocols (i.e. SIP protocol) and SS7 protocols or optionally employ SIP-I protocol (i.e. SIP with encapsulated ISDN) for creating, modifying, and terminating communication session based on ISUP using SIP and IP networks. Multimedia content from the IP network may be transported over ISDN to a circuit switched

  network

  68. It is contemplated that the content (compressed or otherwise) may be encapsulated using ISDN for compatibility with the circuit switched network and which encapsulation may be subsequently stripped and the data packets representing the multimedia content may be processed by the appropriate client application installed on the access device. For another example, the

  satellite system

  70 may be operatively connected to the

  access device

  72 through an Internet Service Provider (ISP) 73 and to the

  platform

  74 via a

  gateway

  76. The

  platform

  74 may also create a peer-to-peer (P2P) network wherein the

  access devices

  72 are facilitated to communicate with each other and share the bandwidth of their local networks. In this scenario, the access devices have a P2P client application installed and the platform employs a hybrid P2P scheme such that the platform contains a registry of the active access devices 78 (i.e. P2P nodes) and directs certain access devices 78 (i.e. Super Nodes) to share network bandwidth based on the bandwidth availability reported by the registered access devices 78. Although the

  gateways

  76 are shown as connected between the

  IP Network

  60 and one of the

  other networks

  62, 64, 66, 68, and 70, a gateway may be connected between any two networks of dissimilar communications protocols such as between the

  cellular network

  62 and the circuit switched

  network

  68.

• • B. Convergent Communications Platform

• In a preferred embodiment as shown in

  FIG. 1

  , the

  convergent communications platform

  74 may include the following elements.

• • 1. Session Control Layer

• As shown in

  FIG. 2

  , the

  platform

  74 employs a Registrar Server, SIP servers and signaling gateways to manage media session control of the parties. Each

  multimodal access device

  80 may be configured as a SIP user agent so that it may communicate directly with the SIP Servers. Alternatively, the

  multi-modal access devices

  80 may be configured to only communicate with their subscribed or associated networks (e.g. cellular network), and in this case, the call setup messages will be converted by a

  signaling gateway

  82 to SIP messages for processing by the SIP servers on the

  platform

  74.

a. Registrar Server

• A Registrar Server is employed to perform subscription management as it receives and registers user profiles and their access devices so that the

  platform

  74 will grant only registered users access to the service. As shown in

  FIG. 3

  , it stores in a Subscriber Registry subscriber profiles including information such as their subscription levels (which define the subscribers' level of service, e.g., number of video conference calls allowed per month), their ENUM (i.e. E.164 Number Mapping) identifiers, their network operators or service providers and associated login identifications, if applicable. To register access devices, the users not only enter their registered usernames or their access devices' IDs (e.g., telephone numbers or Uniform Resource Identifiers (URIs)), but may also enter unique product description such as MAC addresses or product brand and/or model numbers of the devices such that the platform can look up or infer the multimedia capabilities and formatting requirements of such devices from published engineering data associated with the MAC addresses and other product description data provided by the users. Users with multiple access devices preferably enter a ranked list of access devices through which they may be contacted. For example, a user may prefer to be initially contacted via his mobile phone, Skype, and then fixed line phone by the platform. Using this information, the

  platform

  74 will contact the user via their access devices in the order specified by the users.

• The Registrar Server may also perform Subscriber Location Service if the platform has access to Subscriber Location data (e.g., from network operators) for locating the whereabouts of each registered access device. The Subscriber Location data may be, for example, GPS data in the case of mobile devices provided by the subscriber devices or location of home router or last network device location in the case of non-mobile devices such as desktop PCs or equivalents, or if there is a commercial arrangement with other network operators, direct access to the Subscriber Location service on their networks.

• • i. Least Cost Routing of a Call Based On Presence Information

• In one embodiment, a subscriber with a multimodal smart phone (or any computing device with telecommunications capability that can access a cellular network and an IP network through a WiFi router) enters contact information of friends and associates into the Registrar Server, either direct or via a supporting software application, which contact details would include their usernames or identifiers for an IP based communications service provider such as, for example, Skype ID, AOL ID, Google Voice ID etc. When the subscriber decides to initiate a call (or any future communications session) to one of the registered contacts by, for example, selecting the called party by telephone number or by name using smart phone tools such as, for example, voice recognition or keyboard, the Registrar Server receives the called party information including the relevant IP based communications service provider (e.g., AOL Instant Messenger, Skype, Google Voice ID, etc.) and accesses a database containing the called party's presence information or status (e.g., “online,” “away,” “idle,” “mobile,” etc.). If a called party is “on-line,” the platform instructs the smart phone to set up the call session to the distant IP client (i.e. the called party) through the Internet using an appropriate client application (from the IP based communications service provider) on the smart phone for the call session. This method bypasses the alternative PSTN call flow (e.g., avoiding a call termination by an expensive cellular network), thereby allowing reduced costs of transmission and a more advanced feature set to the subscriber because of the end to end IP nature of the session. The interface to the user preferably remains the same or consistent regardless of how the call is established. If no called party is “on-line” (as indicated by the presence information) the call is routed via their chosen or contracted telecommunications provider (e.g., a cellular network operator) associated with the multi-modal smart phone.

• • ii. Alternative Least Cost Routing of a Call Based on Presence Information

• Alternatively, as shown in

  FIG. 4

  , rather than using the Registrar Server, an end user with an access device such as a smart phone enters contact details of friends and associates into the directory or contacts list on the multi-modal smart phone. The contact details include a mobile phone number of the contact and a called party's identifiers for IP based communications network service provider such as, for example, Skype ID, AOL ID, Google Voice ID etc. When the user decides to initiate a call (or any similar point to point communications session) in

  Step

  90 to one of the registered contacts by, for example, identifying the called party by telephone number, or by name using normal smart phone tools (voice recognition or keyboard), the smart phone recognizes that multiple alternative communications protocols are available for the desired contact, checks via the relevant software client(s) (e.g., Skype, Google Voice, or AOL) the relevant presence information indicating availability of the called party in

  Step

  92. If the contact is on-line, the smart phone sets up a call or media session using the applicable client application provided by the IP based communications network service provider in

  Step

  96. This bypasses the alternative PSTN (e.g., cellular network or circuit switched network) call flow, allowing lower costs for the caller and potentially the called party if roaming is involved and permits a more advanced feature set because of the end to end IP nature of the session. Similar to the above implementation using the Registrar Server, the interface to the user is preferably consistent or the same regardless of how the call is established. If the called party is not on-line, the smart phone sets up a media session via it chosen or associated telephony provider (i.e., the mobile operator associated with the smart phone in this example) in Step 98.

• In another embodiment, a Private Branch Exchange (PBX), or a switch node for routing communications for an enterprise network, is connected to an IP network and a circuit-switched network and is capable of setting up media sessions with access devices regardless of whether they are in a cellular network, a circuit switched network, an IP network, or any other aforementioned network. The PBX may be configured with a client application to access the services of one or more IP based communication service provider such as Google Voice™ or Skype™ and has access to the login credentials (e.g., login IDs and passwords) of the enterprise users for using the services of such IP based communication service providers. Preferably, the enterprise users provide to the PBX contact details of their potential called parties (e.g., friends and associates) including their telephone numbers and usernames associated with the one or more IP based communication service providers. Advantageously, when an enterprise user selects a called party from his list of contacts, the PBX would first determine the availability of the called party by accessing the presence information (e.g., “online”, and “away”) provided by an applicable IP based communication service provider the calling party subscribes to. If the called party is available, the PBX proceeds to connect the call using the IP based communication service provider in a manner that is transparent to the calling party (i.e. the enterprise user). Advantageously, the enterprise would realize the cost saving provided by such implementation since any calls made over IP will avoid the termination costs imposed by a typical PSTN operator. If the presence information of all of the IP based communication service providers on the calling party's contact list indicates that the called party is not available, then the PBX proceeds to set up a call session using the telephone number listed by the enterprise caller.

• It is contemplated that this technique can be applied to simultaneous call session setups with multiple called parties.

• It is also contemplated that the Registrar Server may also maintain a secure on-line backup of all the contact details of a subscriber in case his access device is lost. With the on-line copy, the

  platform

  74 scans all available contacts and keeps an updated mapping of the on-line status of all contacts and all potential clients. When the user makes a call, the application on the smart phone sends a call setup message to the

  platform

  74, the

  platform

  74 then immediately identifies the correct called party to contact if such party is on-line. If no called party is “on-line” via data from an IP based communications service provider, then the

  platform

  74 seamlessly routes the call or multimedia content over a VoIP connection to the called party at the dialed number (using a lower cost retail route plan than the mobile operator) and connect the call.

• In yet another embodiment of the platform, a carrier or service provider can lower its cost of termination by querying the Registrar Server whenever it receives a call to a mobile number for termination. If the mobile number matches an available IP client and that client is “on-line,” the carrier may convert the call to an appropriate format for the available client and send the call attempt directly, over a quality IP connection, to the client application on the called party's smart phone. This not only sets up a direct IP path to the distant or called party, it also avoids the payment of the normal Mobile Termination Rate (MTR) by the carrier and potentially a roaming charge by the called customer, resulting in a lower cost of providing the service by the carrier which could translate into cost savings for the consumers.

• • b. Proxy Server

• The SIP proxy server handles call sessions initiated by registered users. It authenticates the registered users by looking up the subscriber registry of the Registrar Server and the characteristics of the calling party's

  access device

  72, directly or inferentially from a cross reference product database. It identifies the unique identifier (e.g., telephone number) of the called party and initially determines if it's in the Registry Server's database. Upon receipt of a call request, the proxy server looks up the list of registered users and list of URIs and proceeds to contact each of the URIs in an order that may be pre-selected by the subscriber and as indicated by the Subscriber Registry. If the proxy server contacts the receiving access devices in parallel (provided that is specified by the registered user), it will terminate the call signaling to all other devices when one is deemed available. If the called party is not a registered user or subscriber, the proxy server routes the call setup message directly to the associated network operator and have such operator routes or forwards the call setup signal to the called device.

• • c. Redirect Server

• A redirect server redirects a call session request to another SIP server in a different domain. The redirect server may, for example, be a public WiFi router that receives a call request from a dual mode cellular or smart phone and forwards the request to the proxy server for registered user authentication and call session control and setup. The redirect server may be deployed by an enterprise for handling call setups for devices on the enterprise network and for other functions such as media content conversion.

• • d. Signaling Gateway

• A Signaling Gateway 82 (see

  FIG. 2

  ) is provided to convert call control signals between different networks such as the conversion of SIP and SS7 messages for circuit switched and IP networks. In the event the platform needs to reach an access device in a different network such as PSTN, the call or media signals will be converted by the Signaling Gateway from SIP messages into SS7 signals and then sent to the access device to determine if it's ready for receiving calls.

• • e. Session Border Controller

• A Session Border Controller (SBC) may be provided to interface with enterprise networks, preferably at the premises of the enterprises and integrated with the enterprise network. In this case, the SBC may direct the SIP messages between the platform and the registered access device inside the enterprise network. The SBC may also perform media content formatting, if required, and media delivery.

• • 2. Service Delivery Layer
• FIG. 5

  diagrammatically depicts the Service Delivery Layer in accordance with an embodiment of the invention. The

  access devices

  72 may be connected to at least one of a circuit switched network 68 (e.g., TDM and C7), a cellular network 62 (e.g., GSM or CDMA), or a data network 64 (e.g., GPRS/3G network). These networks interface with the

  gateways

  76, which include an authorizer that performs authorization and authentication of the access devices, a converter that converts media content between incompatible formats, and a transcoder that transcodes media content from one compressed format to another. The converted media content is sent via an

  IP network

  60 provided by a public Internet or a private IP backbone of an

  ISP

  100, and routed to the

  platform

  74 for switching and routing to a selected optimized

  ISP network

  100 for delivery of the content. The

  platform

  74 may include an iEDP switch (i.e., a

  layer

  2 or

  layer

  3 switch) for switching IP traffic based on a route plan generated by a Route Optimizer (as more fully described below), and an Application Server for performing certain value-added services (e.g., using a high quality codec to compress the high definition video content while maintaining high fidelity of the content and streaming it to multiple parties) as desired by the subscribers. Additional

  downstream gateways

  76 may also be provided to convert the multimedia content to an appropriate format of the networks of the receiving

  access devices

  72 of the called parties. Since the system is capable of bidirectional communication (e.g. video conferencing), this process may be repeated in the upstream direction when users of the receiving

  access devices

  72 transmits multimedia content to other parties connected in this call session.

• A more detailed description of the servers on the

  platform

  74 is provided below.

• • a. Media Servers

• Once the

  platform

  74 determines that the intended

  access devices

  72 are available, the call or media session is set up, and the

  access device

  72 is directed to begin sending multimedia content to the receiving

  access devices

  72. If, according to the Registrar Server, the

  access device

  72 requires a different media format, a media server will be directed to reformat the media content from the transmitting

  access device

  72 and convert it into one that is compatible with the receiving

  access device

  72 and host network. It may be further instructed to take the stream from the originating party and direct it to all connected parties such that all receiving parties in a manner that may be referred to as multicast (except the platform creates a bidirectional streaming). The

  platform

  74, upon receipt of the multimedia stream from the transmitting

  access device

  72, will process and direct one or more streams to one or more of the

  access devices

  72. A bidirectional or duplex communication occurs when the receiving

  access device

  72 also transmits multimedia content to the original

  transmitting access device

  72 and any

  other access devices

  72 in the same call session. In effect, the

  platform

  74 has established a video-conference for the multiple devices.

• In the event the

  access device

  72 is connected to a circuit switched

  network

  68, the media application server converts between real-time transport protocol (RTP) in the

  IP network

  60 to the pulse code modulation (PCM) in the circuit-switched

  network

  68 and transcodes the media content when the codecs of the networks do not match or are otherwise incompatible.

• b. Route Optimizer

• The

  platform

  74 preferably includes a Route Optimizer that identifies the best-suited route to transport the multimedia content by, for example, pre-testing available routes offered by multiple internet service or backbone providers. The pre-testing may include penultimate hop router testing as described in detail below. Using the results from the route testing, the Route Optimizer constructs a route plan for routing traffic based on characteristics of the multimedia content to be transmitted corresponding to the access device registered in the subscriber registry. For example, a phone with video capabilities will send audio/video content encoded in a specific format and would require networks with low latency and low jitter and the Route Optimizer would find a network path from its Route Plan that provides, for example, less than 100 ms from starting point (i.e. the calling party) to end point (i.e. the called party) for this phone. For another example, a cell phone without video capabilities will not need as high quality as that required by a video phone. For yet another example, a Blackberry™ phone sending out an email or text message can make use of a low quality IP network for transmission of such content.

• FIG. 6

  illustrates an earlier communication system operating across multiple networks described in the parent application Ser. No. 11/895,460, and which is incorporated herein by reference in its entirety. There is shown in

  FIG. 6

  a central local node A interacting with a calling party access device interface and a global network of high capacity data networks. Access devices may communicate with central local nodes directly or through intercept devices which direct the communication to the central local node. Access devices are exemplified by telephones, pagers, cellular phones, laptops, facsimile machines, multimedia computer workstations, etc.

• The subscriber access device interface includes communication networks such as digital and analog telephone, paging and cellular, and data. The central local node includes an authorizer, converters for each communication network, a main processor and router, a main data base, compression and coding system and decompressing and decoding system. The global networks of high capacity data networks include the internet, frame relay and digital and analog voice lines.

• The authorizer is responsible for providing clearing transactions to provide authorization for making communication. The authorizer checks with a main data base within the central local node to determine whether the subscriber's credit is good and to what extent to ensure that service providers get paid. The data base may contain a history of the subscriber's usage and outstanding unpaid balance and other information relating to credit history. The main database's information may be updated from information in other nodal data bases and vice versa, including that of the central node, which should contain the most current information and whose global authorizer may be responsible for authorizing all transactions in advance. By the same process, the global authorizer can check on the creditworthiness of service providers if the service providers will be responsible for paying each other.

• • 3. Quality of Service—Penultimate Router Testing
• FIG. 7

  depicts a system for performing penultimate router testing in an

  IP Exchange System

  10 according to the present invention, which includes an IP Exchange Delivery Point (iEDP) switch 12 (i.e., a

  Layer

  2 or 3 switch) connected to a

  trading platform

  26 for receiving buy and sell orders from members of the exchange and a

  settlement platform

  28. The

  trading platform

  26 is connected to a buy/

  sell order database

  30 a and a

  quality database

  30 b. Primary and

  secondary route servers

  14 a, 14 b and primary and

  backup route registries

  16 a, 16 b are also connected to the

  iEDP switch

  12. An

  IP route optimizer

  18, IP

  route view server

  20, and

  IP route database

  22 are also connected to the

  iEDP switch

  12. The

  IP route optimizer

  18, IP

  route view server

  20, and

  IP route database

  22 comprise part of a route analyzer discussed in more detail below and may comprise different portions of a single element or may comprise three separate elements as shown in

  FIG. 7

  . A

  usage server

  24 is also connected to the

  iEDP switch

  12 to monitor usage of the traded routes. Each member includes at least one

  member router

  32 connected to the

  iEDP switch

  12 through which IP capacity routes are announced for sale by seller, or through which bids are transmitted for IP capacity by buyers.

• According to the invention, a quality analysis is performed to determine a quality score for connectivity to each IP network prefix announced for sale by a member, so that if a member announces 20,000 IP network prefixes to the exchange for trading, the system returns 20,000 quality scores for that member. This requires the quality measuring system to scan each IP network prefix for its quality. The inventors of the present invention have discovered that the penultimate hops, and not the end points of the Internet, may be tested to determine the quality level of an endpoint. To do this, the inventive system takes in a full view of the Internet (full routing table of all unique IP network prefixes announced into the Internet), in relation to the IP network prefixes announced to the exchange for trading. This can be achieved by receiving a view from a route-view on a public route server, or some private route server that contains all of the IP network prefixes announced publicly to the Internet for routing. Alternatively, a private peering session may be conducted with each member where their route announcements can be received and processed for further internal propagation. At this point the system will need to sort all of the IP network prefixes to find the smallest publicly announced components. Thereafter, as shown in

  FIG. 8

  , the system performs a traceroute to each IP network prefix of the smallest publicly announced components and records the penultimate hop for that traceroute,

  step

  201. Once a list is created of all the penultimate hops for each IP network prefix, the system will then quality test these devices,

  step

  202. The score resulting from the quality test as well as what IP network prefixes are associated with that device are compiled into a member quality matrix database for future reference,

  step

  203, and optimized routing tables are generated from the member quality matrix database,

  step

  204. The optimized routing tables are updated in real-time as BGP announcements and withdrawals are received from the members,

  step

  205. Steps 202-205 are repeated at predetermined time intervals, such as every hour, per member, step 206. Steps 201-206 may be performed by the IP

  route view server

  20 of the route analyzer.

• In order to reduce what is needed to be monitored for quality, the system will need to find the penultimate hop for each/24 (The/24 is the smallest publicly announced component of the public IPv4 Internet). This allows 2-3 billion testing points to be reduced to 100-400 k testing points. There are two ways to find these penultimate hops, once we have a full view of all IP network prefixes announced for the Internet. One would be to find the penultimate hops through each member, and another would be to use either a third party transit provider or another member that offers full transit. The reasoning for the first solution is that some end points may be multi-homed, and the system will miss different paths to those/24s. This could make a/24 look worse if the only path that is taken is the one least preferred by that end ISP controlling the IP network prefix.

• To do this makes for a more accurate quality measurement, but it also adds a large amount of complexity to the system. This would cause multiple penultimate hops for specific/24s, and force the system to try and test both paths and figure out a fair way to combine the scores to give a useful quality score. In the preferred embodiment, one or more transit providers, who may be members or third parties, will be used to find the penultimate hop for each IP network prefix. This process should be done periodically (e.g., once a day).

• Initially, a full route table consisting of the union of the route tables from all (or a subset) of the members is retrieved and filtered to determine the useful IP network prefixes for testing. This process is shown in

  FIG. 9

  . First, the full route table is acquired,

  step

  310. The IP network prefixes are then filtered for validity,

  step

  312. Each valid IP network prefix is then checked to see if it is exempt as part of a private network under RFC 1918 or under control of a military (.mil) IP address allocation or found on a list of blocks to exclude,

  step

  314. If it is not exempt, the IP network prefix is added to an IP network prefix testing table,

  step

  316. Steps 312-316 are repeated for all IP network prefixes in the full route table,

  step

  318. In step 320, the prefix testing table is complete, and the information can be represented in the following table format.

• TABLE 1
  Full Route Table Prefix List

  Member ID	Prefix/mask	AS Path
  1.1.1.1	10.0.0.0/8	701 18637 1

• The process of finding the penultimate hop is shown in

  FIG. 10

  . Preferably, multiple penultimate hop detections are run simultaneously in parallel. To find the penultimate hop for each prefix/mask on the IP network prefix testing table, the process runs a traceroute to the network address of each prefix/mask,

  step

  400. The network address of the prefix/mask is tested because this is considered acceptable Internet traffic and does not set off firewall alarms or intrusion detection alarms (IDS) alarms. Real-world testing has shown that the device which responds to the network address has a very high correlation to the device which would be derived from testing individual hosts (/32s). This will find the path to the network of the prefix/mask via the supplier of transit, and give an IP Address of each hop as it encounters them,

  step

  402. If some part of the path is filtered, doesn't allow traceroutes to access that router or further, or some part of the path is down, the traceroute will return with a failure to reach the next hop,

  step

  404. After a failure to reach a next hop, a timer is started which times out after a predetermined time period, i.e., two minutes,

  step

  405. If a response is received, the response is recorded in an array,

  step

  406. The process then determines whether the last hop is the network address that is being tracerouted,

  step

  408. If it is not, step 402 is repeated. If the last hop is the network address, the process determines whether a valid response was received from the final hop,

  step

  410. If no valid response was received from the last hop in

  step

  410, or if there is a valid hop in the last five hops,

  step

  414, the last valid hop is taken as the penultimate hop,

  step

  412. If there is no valid hop in the last five hops, the IP network prefix is entered into the database with an entry stating “no penultimate hop found”,

  step

  422. The process determines if the penultimate hop determined in

  step

  412 or 414 is already in the database,

  step

  416. If the penultimate hop is not already in the database, a new entry is made for this device,

  step

  418. The prefix/mask of the IP network prefix being tracerouted is then added to the list of prefix/masks covered by this penultimate hop,

  step

  420.

• Once all of the IP network prefixes in the table have been used to find their penultimate hop, the system may consolidate each router's list of/24s into the most efficient CIDR block to facilitate searching in later phases of the quality measurement system. Each entry is stored in a database in Table 2.

• TABLE 2
  Penultimate Hop Database Format

  	IP network prefixes under Penultimate
  Penultimate Hop	Hop
  205.198.3.2	{3.0.0.0/8, 204.157.0.0/16,
  	199.0.216.0/24}

• FIG. 11

  is a flow diagram showing the steps for testing the quality of the penultimate hops. The first step for testing the penultimate hops is to determine what IP network prefixes to measure, i.e., relevant to what endpoints are announced as for sale on the trading exchange,

  step

  500. The quality measurements to be measured consist of network parameters such as, for example, packet loss, latency, jitter, member availability and BGP stability. This splits the measuring process into three parts. At

  step

  510 the penultimate hop is tested for packet loss, latency, and jitter, at

  step

  520 the penultimate hop is tested for availability, and at

  step

  530 the penultimate hop is tested for BGP stability. The idea behind something other than just packet loss and latency is to get more granular and realistic information about on the actual or “real world” quality of that route. Jitter provides a metric for determining how stable the latency values are (high jitter can indicate queuing bottlenecks on the path). BGP stability is required to form a good understanding of what that announced IP capacity does. If the announced IP capacity is injected then recalled several times a day, there is a good chance the path the system hears that from is unstable. All of the above-described quality testing should be performed periodically (at least once per hour per member).

• Even though we have a list of all the end routes in the Internet, we require quality information only for those endpoints that have been announced to the trading exchange, i.e., only the endpoints that are on sale.

  FIG. 12

  is a flow diagram showing the steps for determining which routers to test. At

  step

  610 the member route announcements are retrieved from the Route server 14 (see

  FIG. 7

  ). Each IP network prefix in the member route announcements is checked to determine which penultimate hop to test,

  step

  612. Since the IP network prefixes are stored in their most efficient CIDR block, step 614 determines if there is a penultimate hop listed for the IP network prefix. If not, the IP network prefix is skipped and the system goes to the next prefix, step 616. If the IP network prefix is listed under its current form under a penultimate hop, the penultimate hop is retrieved at

  step

  620. The process determines whether the penultimate hop is already on the list of penultimate hops to test,

  step

  622, and adds the penultimate hop to the list if it is not already there,

  step

  624. Step 628 determines whether the last IP network prefix is tested. The completed list of penultimate hops is then sent to be tested in

  step

  630.

• FIG. 13

  shows the steps for testing packet loss, latency, and jitter. The system determines the list of penultimate hops to test,

  step

  700, and sends an ICMP or UDP ping packet to each penultimate hop in the list for that member,

  step

  710. As stated above, the testing is performed periodically, i.e., every hour, to allow visibility of the peaks and valleys in a member's traffic pattern. At

  step

  712, the process determines whether a response is received. The problem with a ping test is that some devices will filter it out. Even if TCP is used instead of UDP or ICMP, the penultimate hop may still fail to issue a response. This causes some IP network prefixes to indicate a false 100% loss or null information (if that data is discarded). If this persists, then this penultimate hop and the IP network prefixes it represents will need to be taken out of the equation when computing packet loss for any ASN that is traded from this member. If no response is received,

  step

  714 determines whether the penultimate hop device has been previously unresponsive. Step 716 determines whether it has been unresponsive for more than 24 times (i.e., 24 hours). If the penultimate hop device is unresponsive for 24 times or more, the device should be marked as an IGNORE in the Packet Loss, Latency, and Jitter columns in the table,

  step

  720. If unresponsive for less than 24 times, the failure is recorded in the table,

  step

  724. If a response was received in

  step

  712, the responses are recorded in the table,

  step

  722. If the penultimate hop is not the last penultimate hop in the list, a ping packet is sent to the next penultimate hop on the list,

  step

  710. The ping packet of

  step

  710 is sent several times (i.e., ten times) in quick succession to obtain more than a single snapshot view of the packet loss, latency, and jitter at that point in time. If the penultimate hop is the last penultimate hop on the list, the quality testing for the penultimate is completed as described below,

  step

  730. Table 3 shows the format that may be used to store the response to the ping packet.

• Packet loss is stored as a percentage. A “0%” indicates that there were no packets lost, and “100%” indicates that all of the packets were lost. Latency is the ms Round Trip Time (RTT) for the ping packet. Jitter is the difference between various measurements of latency, wherein a lower measurement indicates a more consistent latency.

• TABLE 3
  Member Packet loss and Latency format

  							# of Times
  						Member	Announcements
  Member		Prefixes under	Packet	Latency	Jitter	Port	were	Ti
  ID	End Router	End Router	Loss	(ms)	(ms)	Online	cycled	Sta

  1.1.1.1	205.198.3.2	{3.0.0.0/8,	0	40	5
  		204.157.0.0/16,
  		199.0.216.0/24}
  indicates data missing or illegible when filed

• Testing availability of a router may be achieved relatively easily. All that needs to be done is to check the port on the iEDP switch 12 (see

  FIG. 7

  ) via Simple Network Management Protocol (SNMP) to verify that the port is either up or down. The following is an example of a Management Information Base (MIB) required for this:

• .1.3.6.1.4.1.1991.1.1.3.3.1.1.9.

• Testing the availability of the router may be done as one large batch to get the current status of all members' ports and then add them to the quality table in the availability column. If the port is online, it may be designated as “1” in the database. If the port is down, it gets a “0” designation. Availability may also be derived from 100% packet loss for all pings to a member, as well as from accessing the port status by telnet or by other methods.

• Testing is also performed for the stability of an IP network prefix. If the IP network prefix is injected and removed many times an hour, then there may be some issue with it, or there may be some strange policies associated with it. This modifies the quality of the ASN you are getting if parts of those controlled IP network prefixes are unstable. To determine stability of a route, a log of all the IP network prefixes that this member has injected and removed from the route server is acquired. This is done by parsing the log file specifically for this task that the Route Server exports and appends each time a BGP route change happens. The easiest way for this to be done would be to run the following script per IP network prefix:

• cat <logfile> |grep <IP network prefix> |wc-I

• The results may be stored in the quality table in the BGP stability column.
• FIG. 15

  shows the steps for augmenting the quality measurements with complementary data received from external sources (for example, streamlining audio or video real-time quality information) and updating the packet loss, latency, and jitter. The system receives the additional quality information for a/32 endpoint IP address,

  step

  900. The system then determines the IP network prefixes which contain the/32 and determines the penultimate router,

  step

  910. It is then determined from the full route table which provider is providing the connectivity to the/32 end point IP address,

  step

  920. The full route table is available to the quality server, allowing it to determine what route the streaming video server is using to reach the endpoint IP address. The new quality information is added to the available quality information for the endpoint, and used to update the quality information for the IP network prefix.

• Once all of the testing for a router as shown in

  FIG. 8

  is completed, a member quality matrix table should be constructed or updated that lists the entire set of IP network prefix scores for each member. This will be used by the matching engine of the trading platform 26 (see

  FIG. 7

  ) to sort buy and sell trades by the quality of the ASN being traded. The member quality matrix table may be accessible from another machine within the LAN, but does not need to allow write permissions. The member quality matrix table may be output as a comma-delimited file that has all of a members IP network prefixes with the grades as exemplarily shown in

  FIG. 14

  . There would be a file for each member every hour. The file is downloadable by the matching engine of the trading platform for use and storage.

• From the member quality matrix table, one or more optimized routing tables may be built. The idea is to take, for each buyer, a full route view and compare it with all of the routes that are announced by any member who wishes to participate and meets the buyer's price bids and other qualifications. For each IP network prefix in the full route table, the system chooses the best quality IP network prefix route from the available routes from qualifying members. This is performed by the

  IP route optimizer

  18. It does this for each IP network prefix in the table, creating a new, optimized route table which is saved in the

  IP route database

  22. This new optimized route table is transmitted to the Route Server for use by one or more members. The table is created for each member, according to their bid options. The formula used for the quality comparison can be customized to the traffic type of the customer (VoIP vs. bulk data)

• The choice for quality by default follows this priority list, with ties going to the next step down:

• 1. Lowest score in packet loss,

• 2. Lowest score in latency,

• 3. Lowest score in jitter,

• 4. Highest score in availability

• 5. Highest score in BGP Stability,

• 6. Follow conventional BGP rules.

• Other formulas are possible and can be modularly updated.

• C. Operation

• FIG. 16

  shows a

  control node

  110 that manages the multimedia communications among the

  various access devices

  72. The

  control node

  110 optimizes the IP routes offered by the

  various ISPs

  100 and creates a route plan based on the measured performance characteristics of the IP routes. The route plan may categorize different routes suitable for certain multimedia content based on performance characteristics of the multimedia content and/or quality of service available to the subscribers based on their subscription plans stored in the Subscriber Registry. The route plan may be updated periodically as the IP routes may become unavailable or congested during different periods of times.

• The originating

  access device

  72 may be able to contact the

  control node

  110 directly if it is configured as a SIP user agent and connected to the Internet. Otherwise, the

  access device

  72 sends call setup messages through a non-IP network and a

  gateway

  76 and then via

  ISP

  101 to the

  control node

  110. If the

  access device

  72 is connected to a non-IP compatible network such as a GSM network, the

  access device

  72 may initiate call setup through, for example, a pre-installed client application on the

  access device

  72, to contact the

  control node

  110. In such case, the call setup message will be converted at a

  gateway

  76 and forwarded by a redirect/proxy server to the

  control node

  110. Once the

  control node

  110 sets up the call or media session with the desired subscribers, the service is delivered in the aforementioned manner.

• FIG. 17

  shows a flow chart of an exemplary operation of an embodiment of the present invention. In

  Step

  120, the

  control node

  110 receives a call setup request. In

  Step

  122, it performs authentication of the call request by verifying the status of the calling subscriber in the Subscriber Registry. Failure to authenticate will result in a failed call attempt. If authenticated, the

  control node

  110 looks up the Subscriber Registry for the called parties information in

  Step

  124. If the Subscriber Registry includes valid called parties information, the

  control node

  110 sends Call Setup Message(s) to the identified called parties based on their registered information (including sending call setup messages to the preferred access device and if unsuccessful to the other devices in a previously specified order) in

  Step

  126. The

  control node

  110 determines if the called parties respond in

  Step

  128. If the called parties' access devices respond, a call or media session is setup for the parties and service is delivered using the route plan generated by the

  control node

  122 in

  Step

  130. In

  Step

  132, if the called party's

  access devices

  72 do not acknowledge the call setup requests, the control node sends messages to the originating

  access device

  132 indicating call setup failure.

• Thus, while there have shown and described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.