Multiplex communications – Pathfinding or routing
Reexamination Certificate
1999-01-05
2003-06-24
Hsu, Alpus H. (Department: 2733)
Multiplex communications
Pathfinding or routing
C370S466000
Reexamination Certificate
active
06584093
ABSTRACT:
The present invention relates generally to call routing and, more particularly, to automatic routing between domains.
BACKGROUND OF THE INVENTION
Internet Telephony allows telephone calls to be carried over an Internet protocol (IP) network either end-to-end between two telephones or computers, or as one or more “hops” in an end-to-end telephone call. A major objective in creating an internet telephony system is to reduce the cost of voice calls while maintaining the same quality level currently provided in voice networks. To achieve this objective a voice call may have to be routed over multiple hops, with some of these hops being in the data network while others are in the voice network.
Internet telephony calls are created, managed, and torn down by signaling protocols. These signaling protocols, when combined with a method of routing the signaling messages and maintaining call state allow the actual media (i.e. voice) to flow in packets between the endpoints. The standards organizations are currently enolving two Internet Telephony signaling protocols: H.323 and SIP. A call routing scheme can be developed separately for each signaling protocol, but it is highly desirable to separate the routing function from other control functions of the Internet, as has been done for the routing of IP data packets.
The routing of telephone calls in the public switched telephone network (PSTN) is accomplished by a combination of common channel signaling (CCS), such as Signaling System #7 (SS7), a number of translation facilities in elements called Service Control Points (SCPs), and static routing tables in elements called Service Switching Points (SSPs). While the CCS routing architecture is a reasonable solution for the PSTN, this architecture has a number of serious limitations, not the least of which is the use of static routing tables in the SSPs. It also suffers from poor separation of the name→address translation function (e.g. 800 number→destination port) from the configuration of the routing machinery of the PSTN.
Initial deployments of Internet telephony have been designed to be similar to the PSTN and use static routing tables in network endpoints, gateways, or centralized call control elements called gatekeepers. An example of a simplified internet telephony system architecture
100
is shown in FIG.
1
.
In architecture
100
, terminal
12
is connected to intranet
10
which has a gatekeeper
14
which acts as a routing agent for intranet
10
. Terminal
22
is connected to intranet
20
which has a gatekeeper
24
which acts as a routing agent for intranet
20
. Intranets
10
and
20
are each connected to Internet
30
.
In the configuration
100
of
FIG. 1
, a call is routed from terminal
12
to terminal
14
using the routing tables in gatekeepers
14
and
24
. One problem with the conventional internet telephony system
100
has no distributed routing protocol to ease the maintenance and distribution of routing information among the elements of the system.
As mentioned above, two Internet Telephony protocols are presently evolving within the standards organizations: H.323 and SIP. The two protocols are discussed in the next two sections with emphasis on how they achieve multi-hop call routing. Then we describe how to achieve distributed multi-hop call routing. We also discuss the addressing formats used in Border Gateway Protocol (BGP) which is used for routing of IP data packets in the backbone of the Internet.
The H.323 Architecture
Recommendation H.323 is a standard architecture for multimedia conferencing (voice, video, and, data) in packet-based networks that was designed by the ITU-T. H.323 has been successfully applied as a suite of signaling protocols for Internet Telephony.
The main components involved in H.323 conferencing are:
Terminals: an H.323 terminal is an endpoint capable of generating audio, video, and data streams or any combination thereof.
Gatekeepers: a gatekeeper is an H.323 entity that provides address resolution and controls access for all types of H.323 endpoints. In addition, a gatekeeper may perform other services such as accounting and authentication.
Multipoint Control Units (MCU): an MCU is an H.323 endpoint which provides the capability for three or more terminals to participate in a multipoint conference.
Gateways: an H.323 gateway is an endpoint that translates from/to H.323 to/from another multimedia conferencing protocols such as H.320 (conferencing on ISDN), or SIP. The gateways with the most relevance to Internet telephony are the voice gateways which are H.323/PSTN gateways and which carry voice only.
Proxies: While not part of the H.323 standard, Cisco provides for an H.323 proxy. It behaves like an H.323/H.323 gateway. Useful features of the proxy include quality of service (QoS), Security, and Application Specific Routing (ASR). ASR involves forcing multimedia streams to follow specific routes path towards the destination).
The main signaling protocols required to implement the H.323 architecture are:
RAS: Registration, Admission, and Status. It is a UDP-based protocol used for communication between H.323 endpoints and the gatekeeper and also for inter-gatekeeper communication. It is part of the H.225 recommendation.
Q.931: is the signaling protocol used for connection establishment between two endpoints. It is part of the H.225 recommendation.
H.245 : is the signaling protocol responsible for call control between endpoints. It provides for capability exchange, channel and coder/decoder (codec) negotiation, and several other functions.
RTP: is the protocol used for carrying the real-time media streams over IP networks.
T.120: is the architecture used for sharing data between endpoints participating in a conference.
A gatekeeper administers one or more H.323 zones. Calls between endpoints in the same zone typically consist of a single hop. On the other hand, inter-zone calls will usually consist of multiple hops (called legs). Some examples will be described below which illustrate the operation of H.323 and the problems involved with multi-hop calls.
FIG. 2
illustrates an example
200
of H.323 call set-up. In
FIG. 2
, a call is established directly between the terminals
12
and
22
and therefore consists of only one hop.
However, the H.323 recommendation also defines a signaling model for gatekeeper routed calls. In the gatekeeper model, the Q.931 and H.245 signaling may flow through a gatekeeper while the RTP media streams still flow directly between the terminals, as in FIG.
2
. In this case, the signaling part of the call consists of two call legs: one call leg from terminal
12
to gatekeeper
14
; and one call leg from gatekeeper
14
to terminal
22
.
Routing calls to H.323 terminals, or other entities, outside the caller's local area system requires multi-hop routing. Several solutions have been proposed which involve: manual configuration of gatekeepers; inter-gatekeeper communication; and the use of directory servers. Most of these solutions consider only calls consisting of one call leg, and none of them scale well to large networks nor provide for dynamic update of call routes over time.
An Internet Service Provider (ISP) may also wish to enforce certain Quality of Service (QoS) and security policies on H.323 calls. To achieve this, the call may be directed through proxies
16
and
26
, as shown in the architecture
300
of FIG.
3
.
This call setup works as follows:
Terminal
12
requests admission from its gatekeeper
14
, to call Terminal
22
. Admission typically includes at least: authorizing of the call, resolution of the destination address; and accounting for the call.
Gatekeeper
14
directs Terminal
12
to connect to Proxy
16
.
Terminal
12
connects to Proxy
16
.
Proxy
16
receives the call and queries Gatekeeper
14
on how to forward the call.
Gatekeeper
14
instructs Proxy
16
to connect to Proxy
26
.
Proxy
16
connects to Proxy
26
.
Proxy
26
receives the call and queries Gatekeeper
24
on how to forward the call.
Gatekeeper
24
instructs Proxy
26
to connect to
Oran David R.
Salama Hussein Farouk
Shah Dhaval N.
Cisco Technology Inc.
Hsu Alpus H.
Marger & Johnson & McCollom, P.C.
Tran Thien
LandOfFree
Method and apparatus for automatic inter-domain routing of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for automatic inter-domain routing of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for automatic inter-domain routing of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3096347