Method for controllinig power characteristics in packet-oriented communication networks

Abstract

According to the invention, a power characteristic information concerning a power characteristic profile of a target terminal is transmitted to a base terminal, before transferring signaling of a connection set up from a base terminal to a target terminal. As a result of the connection set up signaling, a power characteristic request is transferred based on the power characteristic information.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application is the US National Stage of International Application No. PCT/DE02/03457, filed Sep. 16, 2002 and claims the benefit thereof The International Application claims the benefits of German application No. 10147151.3 DE filed Sep. 25, 2001, both of the applications are incorporated by reference herein in their entirety.

FIELD OF INVENTION

[0002] Increasingly in modern communication systems, realtime connections for voice, video, or multimedia communication, for example, are also being routed over packet-oriented communication networks such as, for instance, local area networks (LAN: Local Area Network) or wide area networks (WAN: Wide Area Network). What is termed internet telephony, frequently also referred to as VoIP (VoIP: Voice/Video-over-Internet Protocol) telephony, is an example of communication based on this technology.

BACKGROUND OF INVENTION

[0003] Modern packet-oriented communication systems, in particular those conforming to ITU-T recommendation H.323, make a large number of features available which are familiar from conventional, circuit-switched communication technology such as, for example; call forwarding, call offering, call override, and call waiting. Since connections to terminating devices of very different types are possible in packet-oriented communication systems of this kind, the problem may arise that a particular terminating device requests a feature which a connection partner of said terminating device is unable to provide. In this case the feature request will have a fruitless outcome, which in packet-oriented communication networks in particular will not be recognized until a relatively long period of time has particular will not be recognized until a relatively long period of time has elapsed. Such timeout effects, as they are called, result in disagreeable delays for the person using the terminating device. This problem has proved to be especially acute in the case of connections between packet-oriented communication systems which are mutually independent in terms of their configuration and administration.

SUMMARY OF INVENTION

[0004] The object of the present invention is to disclose a method for controlling features in packet-oriented communication systems enabling such delays to be avoided.

[0005] Said object is achieved by means of a method having the features of claim 1.

[0006] With the method according to the invention, feature information relating to a feature profile of the destination terminating device is transmitted in the direction of the originating terminating device before a connection setup signal is sent, with said signal being transmitted from an originating terminating device to a destination terminating device. A feature request is then transmitted with the connection setup signal as a function of the transmitted feature information.

[0007] The feature request can thus be adjusted to the feature profile of the destination terminating device. The requesting of a feature not supported by the destination terminating device with the connection setup signal can in this way be avoided. A futile feature request of that kind would result in a termination of the connection setup, or would at least delay it considerably.

[0008] Advantageous embodiments and developments of the invention are disclosed in the dependent claims.

[0009] According to an advantageous embodiment of the invention, transmission of the feature information can be prompted by a specific inquiry signal. The originating terminating device can, for instance, transmit a specific inquiry signal to the destination terminating device or to a connection control responsible for said destination terminating device before the connection setup signal is sent in order to interrogate the feature information. Alternatively, the feature information can also be transmitted without an inquiry or it can be exchanged between a domain of the originating terminating device and a domain of the destination terminating device.

[0010] Transmission of the feature information can furthermore also be prompted by means of a signal which is actually intended for other purposes. The advantage of this is that a specific inquiry signal does not have to be defined in the communication system.

[0011] According to a particularly advantageous embodiment of the invention, the feature information can be transmitted as part of an address resolving procedure. The feature information can in particular be transmitted as an additional information element within an address information signal. The advantage of combining the transmission of the feature information in this way with an address resolving procedure taking place before the actual connection setup is that it is not necessary to transmit any additional signal sequences. The actual connection setup will consequently not be additionally delayed by the transmission of the feature information.

[0012] According to a further advantageous embodiment of the invention, the feature information is transmitted as far as the originating terminating device, where the feature request subsequently being transmitted will be generated or modified as a function of the received feature information. The feature request can preferably be modified interactively with a user of the originating terminating device. For example, a feature request for the call override feature can be changed following receipt of the feature information into a feature request for the call waiting feature if the feature information indicates that the destination terminating device does not support the call override feature.

[0013] It is furthermore possible to embody a user interface of the originating terminating device as a function of the received feature information after said feature information has been transmitted to the originating terminating device. It is possible, for example, for the user interface of the originating terminating device only to offer the features which, according to the received feature information, are supported by the destination terminating device.

[0014] According to an advantageous development of the invention, the feature information is stored in a network interworking facility. The feature request being transmitted subsequently will then be forwarded and/or converted by the network interworking facility as a function of the stored feature information. This is highly advantageous particularly when the originating terminating device and the destination terminating device belong to different communication systems coupled by the network interworking facility. Based on the stored feature information, the network interworking facility can convert, terminate and/or acknowledge the feature request being transmitted subsequently depending on the feature profile of the destination terminating device or, as the case may be, of the communication network containing said device.

[0015] According to an advantageous embodiment of the invention, the connection setup signal can be transmitted via a communication system conforming to ITU-T recommendation H.323 or to the SIP (Session Initiation Protocol) standard of the IETF Forum.

BRIEF DESCRIPTION OF THE DRAWING

[0016] An exemplary embodiment of the invention is explained in more detail below with reference to the drawing.

[0017] The FIGURE is a schematic of two coupled packet-oriented communication systems.

DETAILED DESCRIPTION OF INVENTION

[0018] The FIGURE is a schematic of two packet-oriented communication systems KS1 and KS2 coupled via a network interworking facility embodied as a gateway GW. Communication systems KS1 and KS2 are embodied as internet-protocol-based VoIP (Voice/Video-over-Internet Protocol) systems for realtime communication connections for voice, video and/or multimedia communication. Said communication systems KS1 and KS2 are assumed in the present exemplary embodiment to have been implemented in conformity with ITU-T recommendation H.323. At least one of the communication systems KS1 and KS2 could alternatively conform to the SIP standard of the IETF Forum. Communication system KS1 can typically be a private enterprise network and communication system KS2 a carrier network or another external enterprise network.

[0019] Apart from the gateway GW, communication system KS1 also has what is termed a gatekeeper GK1 serving as a connection control according to recommendation H.323 and a terminating device EE1. Communication system KS2 for its part has two gatekeepers GK2 and GK3 according to recommendation H.323 and a terminating device EE2 to which a telephone number 1234 is assigned as a terminating device address. Gatekeepers GK1, GK2, and GK3 serve in the main to control and administer realtime communication connections and to perform access controlling and address resolving. Gatekeeper GK1 is here responsible for connections to the terminating device EE1, and gatekeeper GK2 is here responsible for connections to the terminating device EE2. Gatekeeper GK2 is further assigned an IP address (IP: Internet Protocol) IPGK2 as a network address.

[0020] Terminating devices EE1 and EE2 can be embodied as, for example, conventional communication terminals or as personal computers, application programs, or client applications.

[0021] As functional components, gateway GW has what is termed a signaling gateway SG for signaling across different communication systems and an address resolving facility BE1 for address resolving across different communication systems. Address resolving facility BE1 is embodied in the present exemplary embodiment as what is termed a border element according to ITU-T recommendation H.225.0 Annex G.

[0022] A further address resolving facility BE2 for address resolving across different communication systems is contained in communication system KS2.

[0023] Prior to an actual connection setup to a destination terminating device identified by means of a dialed destination address, address resolving has to be carried out in VoIP systems in order to derive from the destination address a network address on the basis of which communication data packets can be transported within the communication network. Said destination address can be, for example, a telephone number or what is termed a URI (Universal Resource Identifier). Address resolving of this type can be implemented for connections between different, what are termed, gatekeeper zones (Inter Zone), for connections between different administrative domains (Inter Domain), or for connections between different VoIP systems conforming, for example, to ITU-T recommendation H.225.0 Annex G.

[0024] A connection setup from terminating device EE1 of communication system KS1 to terminating device EE2 of communication system KS2 is considered in the following as part of the exemplary embodiment. The connection setup consists of ten call phases 1-10.

[0025] The connection setup is initiated by a subscriber at terminating device EE1 by keying in telephone number 1234 of destination terminating device EE2. In call phase 1, terminating device EE1 consequently transmits an admission request signal ARQ (Admission Request) according to ITU-T recommendations H.323 and H.225.0 to gatekeeper GK1. The admission request signal ARQ contains destination number 1234 which is to be resolved by gatekeeper GK1 into a network address. In the present exemplary embodiment, gatekeeper GK1 is unable to resolve destination number 1234, however, as the called terminating device EE2 is not located within gatekeeper GK1's area of responsibility. In call phase 2, gatekeeper GK1 therefore transmits an address resolving request AccessRequ (Access Request) in accordance, for example, with Annex G of recommendation H.225.0, together with destination number 1234 to address resolving facility BE1, which is able to exchange the address information with the other VoIP system KS2.

[0026] If address resolving facility BE1 has not already stored a network address via which the terminating device EE2 can be accessed and which is assigned to destination number 1234, then in call phase 3 address resolving facility BE1 will transmit the address resolving request AccessRequ, together with the destination number 1234, in accordance, for example, with Annex G of recommendation H.225.0, to address resolving facility BE2 of communication system KS2.

[0027] With the signals transmitted in call phases 1, 2, and 3 it is optionally possible to transmit feature information LM1 specifying a feature profile of features available to terminating device EE1. With the signals transmitted in call phases 1, 2, and 3 it is furthermore possible to transmit an inquiry signal cmnReguest (Common Information Request), in accordance, for example, with ITU-T recommendation H.450.12, in order to prompt communication system KS2 to transmit feature information LM2 into communication system KS1. Feature information LM2 here specifies a feature profile of features available to called terminating device EE2.

[0028] According to a variant method, provision can be made for communication system KS2 to be prompted to transmit feature information LM2 not by means of a specific inquiry signal but, instead, by means of the address resolving request itself.

[0029] In the present exemplary embodiment, address resolving facility BE2 is able to resolve destination number 1234 transmitted to it because terminating device EE2 identified thereby belongs to said address resolving facility BE2's area of responsibility. Destination number 1234 is resolved by address resolving facility BE2 into IP address IPGK2 of gatekeeper GK2 as the network address via which terminating device EE2 can be accessed. In call phase 4, address resolving facility BE2 therefore transmits IP address IPGK2 in an address information signal AccessConf (Access Confirmation), in accordance, for example, with Annex G of recommendation H.225.0, to address resolving facility BE1.

[0030] According to the invention, address information signal AccessConf here contains feature information LM2 as an additional information element. Address information signal AccessConf is forwarded in call phase 5 by address resolving facility BE1 to gatekeeper GK1. In call phase 6, said gatekeeper GK1 thereupon transmits IP address IPGK2 and feature information LM2 in a confirmation of admission signal A CF (Admission Confirm), for example according to recommendation H.225.0, to calling terminating device EE1.

[0031] Network address IPGK2 via which called terminating device EE2 can be accessed is known after phase 6 in terminating device EE1, in gatekeeper GK1, and in gateway GW. This means a connection setup signal SETUP, for example according to recommendation H.225.0, can be transmitted in call phases 7, 8, and 9 on a specifically targeted basis from terminating device EE1 via gatekeeper GK1 and signaling gateway SG to gatekeeper GK2.

[0032] From received feature information LM2 it is additionally known in terminating device EE1 which features are available to terminating device EE2. This can be taken into consideration in the case of a feature request LMA transmitted to gatekeeper GK2 with connection setup signal SETUP in call phases 7, 8, and 9. For example, a feature which is not supported by destination terminating device EE2 (or, where applicable, by a device serving as a proxy for said terminating device EE2) can be prevented from being included in feature request LMA. A feature request which has already been generated can be modified accordingly. As an instance of this, a call override feature originally requested by the user of terminating device EE1, for example according to ITU-T recommendation H.450.11, can already be rejected locally in terminating device EE1, with the user instead being offered the use of a feature with a similar function which is supported by destination terminating device EE2 such as, for example, call waiting. A feature not supported by destination terminating device EE2 can optionally be changed independently by calling terminating device EE1 into a feature with a similar function which is supported by destination terminating device EE2.

[0033] When feature request LMA generated or modified as a function of feature information LM2 has been transmitted to gatekeeper GK2, the connection setup signal SETUP is forwarded by said gatekeeper to called terminating device EE2 in call phase 10. The features requested with feature request LMA are hereby activated for terminating device EE2.

[0034] According to a variant of the method according to the invention, feature information LM2 transmitted to address resolving facility BE1 in call phase 4 is stored in address resolving facility BE1. Forwarding of feature information LM2 to gatekeeper GK1 or, as the case may be, to terminating device EE1 in call phases 5 and 6 can optionally be suppressed here. Feature request LMA transmitted in call phase 8 with the connection setup signal SETUP to gateway GW can then be forwarded, converted and/or terminated by gateway GW as a function of stored feature information LM2. If, for example, the reverse charging feature is requested with feature request LMA transmitted in call phase 8, gateway GW or, as the case may be, signaling gateway SG can terminate the connection setup attempt if stored feature information LM2 indicates that the reverse charging feature is unavailable to terminating device EE2.

[0035] Owing to the transmission of feature information LM2 and, where applicable, of feature information LM1 as part of an in any event necessary address resolving procedure which includes call phases 1 to 6, no additional signal sequences are required for carrying out the method according to the invention. The connection setup will consequently not be additionally delayed. By transmitting the feature profile of called terminating device EE2 in advance, it is furthermore possible to avoid any further delays due to the requesting of non-supported features.

[0036] The exemplary embodiment described above can readily be generalized to the effect that communication systems KS1 and KS2 are treated as being different administrative domains or different gatekeeper zones, as they are termed, within a single VoIP system. Communication systems KS1 and KS2 can furthermore also have different connection control protocols, KS1 having an H.323 protocol and KS2 having an SIP protocol, for example.

Claims

1-9. (canceled).

10. A method for controlling feature requests in packet-oriented communication systems, comprising: sending a connection setup signal from an originating terminating device to a destination terminating device, said destination terminating device being characterized by a feature profile; transmitting feature information to a profile receiving device, said feature information describing said feature profile; creating a preliminary feature request; comparing said preliminary feature request with said feature profile and generating a resultant feature request in accordance with said comparison; and transmitting said resultant feature request.

11. The method according to claim 10, wherein said resultant feature request and said preliminary feature request are substantially the same.

12. The method according to claim 10, wherein said resultant feature request and said preliminary feature request are substantially different.

13. The method according to claim 10, wherein said resultant feature request is transmitted with said connection setup signal.

14. The method according to claim 10, wherein transmission of the feature information is initiated by an information request signal.

15. The method according to claim 10, wherein transmission of the feature information is prompted by a multi-purpose signal.

16. The method according to claim 10, wherein the feature information is transmitted as part of an address resolving procedure.

17. The method according to claim 16, wherein the feature information is transmitted within an address information signal.

18. The method according to claim 10, wherein said resultant feature request is generated by said profile receiving device.

19. The method according to claim 18, wherein said profile receiving device is said originating terminating device.

20. The method according to claim 10, wherein said profile receiving device includes a user interface adapted to produce said resultant feature request.

21. The method according to claim 10, wherein profile receiving device is a network, and said resultant feature request is generated via said network.

22. The method according to claim 10, wherein a connection setup signal is transmitted via communication system)conforming to. ITU-T recommendation H.323 or to the SIP standard of the IETF Forum.