fig4 is a block diagram illustrating an exemplary topology aware resource manager entity rm within an ip telephony system 400 , according to a first embodiment of the present invention . the resource manager rm comprises topology aware resource manager functionality . it is comprised in an ip telephony system e . g . an h . 323 system . such a system is described fig1 , above under “ background of the invention ”. hence , in addition to the resource manager rm , the ip telephony system typically comprises ip telephony components such as one or many gatekeepers gk , gateways g , and terminals , as well as ip network elements such as routers r , edge routers er and local area network ( lan ) segments to which the terminals typically are connectable . the ip telephony system ( 400 ) is used to enables end - users to use an ip network as the transmission medium for multimedia . the resource manager rm interacts with the gatekeeper gk and handles all resource management issues for initiated and ongoing calls and admission control for call set - up requests . the interaction between the rm and the gk can be implemented in a number of ways , e . g . via a communication protocol , inter process communication , functional calls between integrated software modules , etc . topology awareness is the availability of correct routing and resource information , which is essential to a system which performs resource management and admission control . the resource manager rm retrieves routing information concerning the ip network , i . e . the topology of the ip network . in the case wherein the ip network is routed using link - state routing protocol , the resource manager rm participates in the routing and acts as a router , i . e . the rm peers with other routers , without advertising any routers of its own , to retrieve routing information of the ip network . the basic principle on which link - state protocols are built ensures that all routers have the complete routing information . when participating in the routing protocol , the resources manager rm receives the routing information as fast as any other router in the routing domain and can therefore detect changes in the topology instantly . in the case wherein the ip network is routed using a distance vector protocol , or static routing , the method of peering cannot be used . in this case , the routing information is retrieved by measurements such as trace route ( see kessler g ., a primer on internet and tcp / ip tools , ietf , rfc1739 ) and / or the use of simple network management protocol ( snmp ) auto discovery ( see kesbav et al , discovering internet topology , http ;// www . cs . cornell . edu / skesbav / papers / discovery . pdf , july 1998 ). snmp is a set of protocols for managing complex networks . when the resource manager rm has retrieved the routing information , it uses a network management protocol , such as snmp ( see case et al , introduction to version 3 of the internet - standards network management framework , ietf , rfc2570 ), to collect information on the routers and their interfaces ( e . g . the interface type and speeds ). the information is used by the rm to complement the gained routing information and make sure that it has an accurate routing topology . the resource manager rm combines the routing information and resource information it gets from call set - up requests from the gk to create a resource map . the resource map contains information of how much resources ( e . g . bandwidth ) that are available and reserved over time on a per link basis . the resource manager rm uses the resource map to assist the gatekeeper gk in the decision whether there are resources available or not , for a call that someone is initiating . in the case of gatekeeper - routed calls , the gatekeeper gk is responsible for approving or rejecting initiated calls from terminals . the gatekeeper gk interacts with the resource manager rm and asks the resource manager rm if there will be enough resources through the routed path between the source endpoint and the destination endpoint of an initiated call , to give the predictable quality . the resource manager rm answers the question by evaluating what network path the call will use and for each link along that path it calculates if there are sufficient resources to admit the call , i . e . the resource manager rm performs path - sensitive admission control on the resource request . the admission control is performed based on the information in the resource map . this will solve the above - mentioned problem addressed as the changes in user behaviour . no heuristic model can cope with changes in user behaviour , but the topology aware resource manager rm does that by being up to date about the resource utilisation . the same goes for the problem with denial of service . another problem addressed above is the changes in topology . the resource manager rm monitors on - going calls in the ip telephony system and recalculates the resource usage per link whenever any change occurs i . e . updates the resource map . if the updated resource map show that resources are too limited to be able to fulfil all on - going calls the resource manager rm will report this to the to the gatekeeper gk . if the resources are limited as just described , it is possible to let either the resource manager rm or the gatekeeper gk prioritise which calls that should be kept and which to terminate . by performing this prioritisation , degraded quality for everyone involved is avoided . this prioritisation also makes the number of lost calls minimised . another way to prioritise services whenever topology changes occur is to let video streams gets lower priority compared to the voice service . fig5 is a block diagram illustrating an exemplary topology aware resource manager entity rm within an ip telephony system 500 , according to a second embodiment of the present invention . in this second embodiment , the resource manager rm is used in a multipart conferencing scenario involving more than two endpoints . within a multipart conferencing there will always be a multipoint controller mc involved in the communication . the ip telephony system shown in fig5 is the same typically ip telephony system as the one in illustrated in fig4 except for that it additionally comprises a multi - point controller mc . the system may comprise more than one multi - point controller . the multi - point controller mc has knowledge about which endpoints that participates in the multipart conference and the mc will also control these endpoints . the resource manager rm provides the admission control to the multi - point controller mc , either directly or indirectly via the gatekeeper gk , in the same way as provided to the gk as describe above . the resource request may in this case contain more then two endpoints . in a multipart conferencing call , a task to add participants as resource efficiently as possible arises . in this case , the resource manager rm recommends the multi - point controller mc , by means of the resource map , which distribution method ( centralised / decentralised or an appropriate hybrid between these ) to use to make it possible for the added part to join the session in a resource efficient manner . the distribution method to use is depending on the resource map and hence , only the resource manager rm has the possibility to answer this . in case there are no resources available with predictable quality , different methods to handle this exists . the user can get service without priority or the user can be rejected to participate in the conference due to lack of resources . in case different priorities are used , there must be either two multicast sessions of which one is prioritised and the other is not , or a separate unicast session to the part that suffers from lack of resources . in the multicast case , the part with less predictable resources must listen to the session without priorities and the traffic will therefore never be distributed to that part of the network . in the unicast case , one part of the session can relay its traffic as unicast without priority to the part with lack of predictable resources . for both the unicast case and the multicast case , the bandwidth request is approved or rejected . from an end - user point of view it is more convenient to have a reject with conditions , which is possible when using the resource manager rm according to the present invention . for instance , the end - user requests for 64 kbit / s voice service and 128 kbit / s video service . the available resources are not sufficient to fulfil this request but only 128 kbit / s is available which is found out by the resource manager rm by means of the resource map . the answer from the resource manager rm could then be e . g . “ your request cannot be fulfilled , only 128 kbit / s can be reserved for you . please respond to this message within 5 minutes to reserve these 128 kbit / s .” a preliminary booking of resources is made by the resource manager rm , based on the original request from the gatekeeper gk or multi - point controller mc . this preliminary booking request is then cancelled unless there is a response to the message sent from the resource manager rm to the gatekeeper gk or mc . for the end - user , it is then possible to select which service to prioritise in favour of the other . i . e . that is in case there is a wish to put either of the services in favour of the other . the same goes if only one service is considered . the user wants e . g . to run high - quality voice , but due to lack of resources he accepts medium - quality voice with predictable quality rather than high - quality voice without possibilities to predict the quality . even though the state of the art describes h . 323 and the solution according to the present invention is adapted to that recommendation other similar ip telephony solutions are possible , e . g . there exists a competing ip telephony solution according to the ietf standard sip where the same solutions are applicable . the resource manager rm comprises means for performing the methods steps described above . the resource manager functionality is implemented by means of a computer program product comprising the software code means for performing functionality . the computer program is run on a standalone server interacting with gatekeepers , or is run on the same hardware as the gatekeeper functionality . it can be integrated with software that implements gatekeeper functionality , it may also run on routers or other network entities . the resource manager functionality may also be distributed to run on multiple nodes and / or distributed geographically over a network . the above is also applicable for interaction with other entities performing the same functionality as gatekeepers . the computer program is loaded directly or from a computer usable medium , such as a floppy disc , a cd , the internet etc . the present invention is not limited to the above - described preferred embodiments . various alternatives , modifications and equivalents may be used . therefore , the above embodiments should not be taken as limiting the scope of the invention , which is defined by the appending claims .