The present invention relates to an arrangement for distributing and dispatching traffic in a network, especially H.323 generated traffic, which arrangement comprises one or more gatekeepers, here designated as so-called external or real gatekeepers.

Today there does not exist any lightweight solution for distributing and dispatching H.323 generated traffic.

It is perfectly possible to distribute and dispatch H.323 by using a gatekeeper. It might however be costly to run a full fledge gatekeeper for distributing and dispatching H.323 generated traffic if the intention only is to distribute and dispatch H.323 generated traffic. A real gatekeeper is complex and has to know about lots of messages etc. described in H.323. An endpoint may be any kind of H.323 based equipment.

The topic of using inter-gatekeepers or distributed gatekeepers are discussed in among others: RADHIKA R. ROY: "Framework for H.323 Inter-Gatekeeper Communications" Telecommunication Standardisation Sector APC 1385, 8 - 11 June 1998, pages 1-8 Cannes, France and RADHIKA R. ROY "Distributed Gatekeeper Architecture for H.323-based Multimedia Telephony", IEEE Conference on Local Computer Networks, LCN'99, 1999, pages 73-76.

An object of the present invention is to provide an arrangement by which the distribution and despatch of H.323 generated traffic can be provided in a far more expedient and less costly manner.

Another object of the present invention is to provide an arrangement by which endpoints can be put in contact with so-called external or real gatekeepers without having to be reconfigured depending on which gatekeeper they want to communicate with.

A further object of the present invention is to provide an arrangement by which supplementary achievements, comprising for example load balancing, QoS (Quality of Service), information about cost, etc. can easily be implemented.

Still another object of the present invention is to provide an arrangement by which the messages associated with so-called external or real gatekeepers are utilised in a rational and effective manner.

How to achieve supplementary achievements as e.g. load balancing is also described in the text below. Some of the ways described here not only involves GRQ, GCF and GRJ.

Further features and advantages of the present invention will appear from the following description taken in conjunction with the enclosed drawings.

• Figure 1 is a sketch of a typical scenario in which the distributed gatekeeper system might be utilised with endpoints, internal (lightweight) gatekeeper located inside the domain or LAN and external (real) Gatekeepers located outside. The network components as e.g. routers etc. are not outlined.
• Figure 2 is a network scenario in which the distributed gatekeeper system may be applied. Not all of the components within the ISP domain are outlined, neither is network-related equipment as e.g. routers etc. outlined. An example of a LAN domain is sketched in Figure 1. The internal gatekeepers may be connected in any way and any number towards the external gatekeepers. An arbitrary number of external gatekeepers may be connected.
• Figure 3 shows the message exchange during start up of a real gatekeeper, when the real gatekeeper register a lightweight gatekeeper.
• Figure 4 shows the message transfer in communication between real and lightweight gatekeeper, as the lightweight gatekeeper collects information relating to e.g. the load situation of the real gatekeeper.
• Figure 5 gives a system overview.

An endpoint that wants to initiate a session towards another endpoint has first to register to a gatekeeper. An endpoint performs this by sending a GRQ (see Figure 1 GRQ₁) to the lightweight gatekeeper. The lightweight gatekeeper only understands and responds to GRQs. As the lightweight gatekeeper also has knowledge of real gatekeepers outside its own domain, it responds to the endpoint with a GCF (see Figure 1 GRQ₄) with the gatekeeper id of an appropriate full fledge gatekeeper outside its own domain. In advance the lightweight gatekeeper must have gained knowledge of valid gatekeepers outside its domain (information like IP address). The method for gaining and updating the knowledge of external gatekeepers is described in the text below, in connection with the discussion of Figure 4. In addition, each time an endpoint connects to the lightweight gatekeeper, the lightweight gatekeeper should use the same signals, i.e. GRQ (see Figure 1 GRQ₂) and GCF (see Figure 1 GRQ₃), towards the real gatekeepers e.g. to check which gatekeepers that allow the endpoint to be connected.

Figure 1 only indicates one possible scenario on how the lightweight gatekeeper communicates with the real gatekeepers. Alternatively the internal gatekeeper may directly provide the address of an external gatekeeper in the GCF towards the endpoint as a response to the GRQ. Figure 2 indicates how the arrangement is deployed when taking ISPs, LAN and Internet into account.

Several alternatives exist regarding how often the lightweight gatekeeper ought to communicate with the external gatekeepers and hence update the internal tables:

1. 1) The lightweight gatekeeper may update its internal tables statically, i.e. by management. An example of a static configuration setting may be that between 0800 and 1000 a certain external gatekeeper doesn't want to handle GRQs coming from the lightweight gatekeeper.
2. 2) The lightweight gatekeeper may update its internal tables partly dynamically, i.e. on each GCF and GRJ received from the real gatekeepers.
3. 3) The lightweight gatekeeper may frequently send GRQs to the real gatekeepers based on information on already registered endpoints. This interaction would be superfluous if it was not for that the response (GCF) should contain information on QoS etc. in the nonStandardData field. This approach ensures that the lightweight gatekeeper may update its internal tables not only each time an endpoint registers towards an external gatekeeper. Hence the lightweight gatekeeper, dependent of the frequency, has valid knowledge of the external gatekeeper's QoS etc.
4. 4) Other H.225 or H.245 messages might be utilised for such information exchange, e.g. the H.225's IRQ (InfoRequest) and IRR (InfoResponse)
5. 5) Other ways of exchanging such information also exist. Examples may be to use other protocols like TCP, UDP or such as Java/RMI, CORBA etc.

Any combination of the above mentioned approaches might be applied. Besides, information on a client's willingness to pay might be forwarded in the GRQ message, see next chapter.

Information that might flow from endpoints to the lightweight gatekeeper is e.g. willingness to pay information. Hence the lightweight gatekeeper, dependent of the frequency, has valid knowledge of the endpoints, e.g. willingness to pay.

The way in which this information might be exchanged is according to those mechanism described in previous chapter.

Another issue is which real gatekeeper the lightweight gatekeeper should put an endpoint in contact with. Alternatives may be:

1. 1) Forward the GRQ to a randomly picked real gatekeeper
2. 2) Forward the GRQ based on internal information. Examples of internal information might be QoS, load, cost, time of day etc.
3. 3) Forward the GRQ to a specific real gatekeeper on the basis of other criterias
4. 4) By forward is meant explicitly, i.e. plain forward of the GRQ to an external gatekeeper, or implicitly, i.e. the address of the external gatekeeper is directly provided in the internal gatekeeper's GCF towards the endpoint

Such an extremely lightweight gatekeeper is trivial to implement and only needs small amount of memory and CPU power. Due to these modestly demanding requirements it does not have to execute on dedicated hardware (PCs, workstations etc.) An advantage that is a consequence of the lightweight approach is that e.g. a small company that thinks it is too costly to put up an own local gatekeeper might initiate contracts with one or several gatekeeper providers.

Such a distributed approach is trivial to maintain due to the fact that all the endpoints only needs to know about one gatekeeper, i.e. the lightweight gatekeeper. If the endpoints communicate directly with the real gatekeepers, the endpoints have to be reconfigured depending on which gatekeepers they want to communicate with.

Information of the (current) cost of using the different full fledge gatekeepers might also be provided by the same approach as described for load balancing and QoS.

Several alternatives exist regarding how often the lightweight gatekeeper ought to communicate with the external gatekeepers and hence update the internal tables:

1. 1) The lightweight gatekeeper may update its internal tables statically, i.e. by management. An example of a static configuration setting may be that between 0800 and 1000 a certain external gatekeeper doesn't want to handle GRQs coming from the lightweight gatekeeper.
2. 2) The lightweight gatekeeper may update its internal tables partly dynamically, i.e. e.g. on GCF, GRJ and RAI received from the real gatekeepers.
3. 3) Other H.225 or H.245 messages might be utilised for such information exchange, e.g. the H.225's IRQ (InfoRequest) and IRR (InfoResponse)
4. 4) Other ways of exchanging such information also exist. Examples may be to use other protocols like TCP, UDP or such as Java/RMI, CORBA etc.

Any combination of the above mentioned approaches may be applied. Besides, information on a client's willingness to pay might be forwarded in the GRQ message, see next chapter.

Information that might flow from endpoints to the lightweight gatekeeper is e.g. willingness to pay information. Hence the lightweight gatekeeper, dependent of the frequency, has valid knowledge of the endpoints, e.g. willingness to pay.

The way in which this information might be exchanged is according to those mechanism described in previous chapter.

Another issue is which real gatekeeper the lightweight gatekeeper should put an endpoint in contact with. Alternatives may be:

1. 1) Forward the GRQ to a randomly picked real gatekeeper
2. 2) Forward the GRQ based on internal information. Examples of internal information might be QoS, load, cost, time of day etc.
3. 3) Forward the GRQ to a specific real gatekeeper on the basis of other criterias
4. 4) By forward is meant explicitly, i.e. plain forward of the GRQ to an external gatekeeper, or implicitly, i.e. the address of the external gatekeeper is directly provided in the internal gatekeeper's GCF towards the endpoint

Such an extremely lightweight gatekeeper is trivial to implement and only needs small amount of memory and CPU power. Due to these modestly demanding requirements it does not have to execute on dedicated hardware (PCs, workstations etc.) An advantage that is a consequence of the lightweight approach, is that e.g. a small company that thinks it is too costly to put up an own local gatekeeper might initiate contracts with one or several gatekeeper providers.

Such a distributed approach is trivial to maintain due to the fact that all the endpoints only needs to know about one gatekeeper, i.e. the lightweight gatekeeper. If the endpoints communicate directly with the real gatekeepers, the endpoints have to be reconfigured depending on which gatekeepers they want to communicate with.

This invention has the great advantage that it allows a system of multiple gatekeepers to distribute load evenly, thereby reducing call setup time and improving the total possible utilization compared to the statical endpoint-gatekeeper relationship.

Further the gatekeepers are able to recover automatically after a crash, without any external intervention.

Another advantage of the invention is the possibility of transferring registered endpoints from one gatekeeper to another.

1. [1] "Call Signaling Protocols and Media Stream Pack-etization for Packet Based Multimedia Communications Systems" , DRAFT ITU-T Recommendation H.225.0, Version 2