fig1 provides a schematic representation of a system 50 . system 50 includes a small network 52 , used in , for example , a home , a small business or an enterprise branch office . network 52 is self - configuring according to , for example , the teachings of a framework for session initiation protocol user agent profile delivery at http :// tools . ieff . org / html / draft - ieff - sipping - config - framework - 12 by petrie et al . (“ petrie ”). due to the self - configuring nature of network 52 , a user u with little or no technical experience can set up devices on network 52 . network 52 comprises a combined firewall and network address translator (“ nat ”) 54 , although firewall and nat 54 need not be combined . network 52 also comprises a number of independent devices 58 - 1 , 58 - 2 , 58 - 3 that are functionally identical in respect to the setting up of voip collaborative sessions . ( for greater clarity , sessions refers to sip sessions or the like . sip provides for endpoints to negotiate arrangements ( sessions ) between themselves . among the parameters that can be negotiated in these sessions are the type of media and the amount of bandwidth authorized . these parameters can be and are typically renegotiated several times within a session .) collectively , devices 58 - 1 , 58 - 2 , 58 - 3 are referred to as devices 58 , and generically as device 58 . devices 58 all connect to firewall / nat 54 via a local area network (“ lan ”) 60 . in a present embodiment , device 58 - 1 is a desktop computer , while devices 58 - 2 are voip telephones . however , other types of devices are contemplated including personal digital assistants , entertainment devices , smart phones , whether wired or wireless . network 52 connects to a wide area network (“ wan ”) 62 via a shared link 66 . wan 62 can be , though need not be , the internet . of note is that all devices 58 that connect to wan 62 do so via shared link 66 . system 50 also includes an aggregator 70 connected to wan 62 , which will be discussed in greater detail below . as will be explained further below , system 50 is also configured to manage shared resources , as well as collection and reporting of aggregate statistics , diagnostics , fault detection and other data to higher - order entities in the overall system 50 . to illustrate more thoroughly , fig2 shows system 50 a which is an extension of system 50 in fig1 . system 50 a includes many of the same elements as system 50 and accordingly elements in system 50 a that correspond to elements in system 50 include the same reference except followed by the suffix “ a ”. like system 50 , system 50 a includes independent communication devices 58 . however in addition , system 50 a also includes other devices 74 a on network 52 a , which can be configured as shared resources for communications devices 58 a - 1 , 58 a - 2 and 58 - 3 to utilize . software or firmware ( not shown ) within devices 58 a - 1 , 58 a - 2 and 58 - 3 is configured to be aware of the possibility of the presence of devices 74 a and can be set up to use them if they are available . shared devices 74 a on network 52 a in this embodiment are an automatic speech recognizer (“ asr ”) 74 a - 1 and a conference unit (“ conf unit ”) 74 a - 2 . conference unit 74 a - 2 can also be referred to as conference server . many other types of shared resources could be envisioned here as well , such as media servers , local pstn gateways , voicemail servers , etc . additionally , there is a shared common link 66 a to wan 62 a which the communication devices 58 a will all share for voip calls and other collaborative applications . shared link 66 a and lan 60 a have limited capacity . the other shared resources exemplified by 74 a - 1 and 74 a - 2 also have limited capacity . hence coordinated arbitration for use is of these shared resources is provided . in the case of shared bandwidth over the link 66 a , it can be assumed that an estimate of the total available bandwidth on link 66 a has been provided to each of devices 58 a in their configuration . this configuration can make use of configuration files as described in petrie . this information can be obtained , for example , from user u during the time that he / she was registering for service with the service provider ( not shown ). user u can be asked for a broad classification of access speed ( e . g . dial up , t1 , dsl etc .). a rough estimate of capacity can be obtained from the response from user u , and would be added to the profile information at time of provisioning the new service to the user u ( or the entity which is associated with user u and / or network 52 a ). as will be discussed further below , it is also possible to dynamically estimate bandwidth capacity of link 66 a by monitoring of quality of service (“ qos ”) measures . similar configurations regarding capacity of other shared resources such as 74 a - 1 and 74 a - 2 can also be provided . however this information alone may only indicate total capacity of the resource , and is not sufficient on its own in certain circumstances to manage sharing of the resource by many devices 58 a . performance or bandwidth estimation is part of voip operation . before any call is accepted or created , sufficient remaining bandwidth to handle a call from that device 58 a must be managed . similar analogies can apply to a very broad range of shared resources , as in the example additional shared devices 74 a . for example in the case of asr device 74 a - 1 , it may be used as an interactive voice response (“ ivr ”) server for the rest of the communication devices 58 a , however due to limited capacity only a certain number of calls are allowable to use asr device 74 a - 1 at any given time . fig3 , is a representation of the internal structures within each device 58 a that relate to the management of bandwidth usage over link 66 a . thus , each device 58 a includes a performance manager 80 a . bandwidth estimation is performed as one task by performance manager 80 a . performance manager 80 a contains a current estimate of the amount of bandwidth that devices 58 a - 1 , 58 a - 2 and 58 a - 3 are using as well as an estimate of the maximum bandwidth that they are permitted to use . device 58 a will also contain one or more of codecs , represented in fig3 as codecs 84 a - 1 and 84 a - 2 . these codecs 84 a can be dynamically selected so as to reduce and / or minimize the amount of bandwidth used while still meeting the voice quality performance requirements requested by the user . performance manager 80 a will also have access to relevant data from a packet receiver 88 a . mis - estimation of bandwidth usage may result in congestion . congestion may result in lost or misordered packets , or in increased packet delays , which will manifest itself in levels of jitter buffers 92 a running low or empty . performance manager 80 a may optionally be configured to check the validity of its estimates by use of the measurements of buffers 92 a . under conditions of resource over - utilization , detected by either excess requested bandwidth for connections , or by detection of congestion conditions , the performance manager may , optionally , take remedial actions in adjusting its estimation algorithm for new connections , and / or by renegotiating the codec 84 a used for current connections , or the like . in one implementation , network 52 a can be operated with control of bandwidth effected locally at each device 58 a . in this implementation , each device 58 a devices 74 a on network 52 could be given an estimated portion of the total bandwidth available on link 66 a and could make its own decisions on the use of that bandwidth . efficient use of this bandwidth could result from over - subscription , whereby each device 58 a and each device 74 a would be given more bandwidth than a strict proportionate share of link 66 a would allow and an optimistic assumption would be made that the statistical properties of the total offered load of all devices would make congestion , and therefore performance impairments , occur at an acceptably low rate . in an alternative implementation , each device 58 a can be given an exclusive proportionate share , however this per - device estimation can result in under - utilization of the bandwidth of link 66 a , except when all devices 58 a make a call simultaneously , which is statistically rare . the same considerations also apply equally to any such shared resource . in a third implementation , performance can improved if decisions on connection admission are made with knowledge of the offered load of all devices 58 a using the link 66 a , not just one . currently available bandwidth across link 66 a could be allocated to devices 58 a , on a call - by - call basis , with certain and not just probabilistic knowledge . the third implementation is illustrated in fig2 and 4 . fig2 indicates that device 58 a - 3 is elected as the operating performance manager 80 a on behalf of all devices 58 a in network 52 a . this election process can be done in any desired manner . for example , each device 58 a can broadcast or multicast metrics indicating its capacity to perform the task . the device 58 a with the highest metric will detect that it is the most suitable and broadcast a message indicating its assumption of the role . in operation , the performance manager 80 a of the elected device 58 a - 3 creates an estimate of the total bandwidth used for voip on network 52 a and as well an indication as to whether or not network 52 a is congested . to do so , performance manager 80 a gathers information from all devices 52 a and 74 a . for example , using a session initiation protocol (“ sip ”) publish method or equivalent , all devices 52 a and 74 a will register the amount of bandwidth that they are using , over what path in the network ( lan - local vs across link 66 a ). similarly all devices 52 a and 74 a may provide indications from their jitter buffers 92 a as to the congestion that they are seeing on network 52 a , as measured by packet loss , delay , or other measures . each device 52 a and 74 a will also request notification of these values on a network - wide basis , for example using a sip subscription method or similar . all devices 52 a potentially using the link 66 a would subscribe to the elected performance manager 80 a to receive one or more notify messages of the status of link 66 a ( e . g . link 66 a is full , for example ), and all would use sip publish to send to the elected performance manager 80 a their usage of link 66 a . alternatively a subscribe / notify relationship could be used in both directions , or a non sip - based request response approach could be used in this interaction . at this point it should be clarified that the exemplary embodiment herein is discussed in relation to management of a shared resource in the form of link 66 a . however , the embodiments can be modified to manage other types of shared resources , other than or in addition to link 66 a , such as devices 74 a . the bandwidth on the lan 60 can also be estimated in this way . since each device 58 a will receive global estimates of bandwidth usage and congestion measurements from the current elected performance manager 80 a , then each device 58 a capable of operating as a performance manager will contain all knowledge required to function as the elected performance manager 80 a . each such device 58 a can therefore assume this role in the eventuality that a new performance manager 80 a is required , for example should the current one fail or become disconnected , or become overloaded for some reason . note , however , not all devices 58 a in network 52 a need be capable of operating as a performance manager 80 a . there is at least one such device 58 a capable of operating as the elected performance manager 80 a in the local network , however it is important that more than one such device 58 a is available , for resiliency reasons . fig4 shows the internal structures of each device 58 a that are included in fig3 . however , in fig4 , the presence of a local free resource estimate 96 a and a global resource estimate 98 a in associate with the overall free resource estimate 100 a itself . each device 58 a will utilize global resource estimate 98 a information as part of its connection admission process to network 52 a . fig4 indicates that each device 58 a maintains its own usage within local free resource estimate 96 a and have available the global usage within global resource estimate 98 a via its subscription to performance manager 80 a . after the admission or termination of every call , each device 58 a will update ( publish ) its usage of bandwidth used at performance manager 80 a . each device 58 a will optionally also update its performance metrics to the current performance manager 80 a from its jitter buffers 92 a ( error , missing and out of order packets , jitter buffer below a critical value etc .) at suitable intervals , and the end of calls , or upon the occurrence of an important event ( jitter buffer empty etc .). if a congestion condition occurs , each device 58 a can renegotiate connections to use codecs with lower bandwidth requirements , reduce the number of simultaneous connections allowed etc . this can be done with knowledge from all devices 58 a . so a device 58 a that is just newly - attempting to make connections can make its decisions based on surer knowledge of congestion conditions . an alternative to the above method would be for all connection decisions to be made by the elected performance manager 80 a . each device 58 a would request connection admission for each call that it makes , and also inform the elected performance manager 80 a when the calls have ended . the elected performance manager 80 a would make the decisions as to whether or not to accept any and all calls . it would maintain the same global estimates as before and use these in its decisions . the elected performance manager 80 a receives all requests for admission and accepts or rejects each of them . the elected performance manager 80 a would also maintain status on all calls . each device 58 a having its own performance manager 80 a on network 52 a will subscribe to this global information from elected performance manager 80 a . since each device 58 a has the same knowledge of the conditions as the elected performance manager 80 a , each device will be capable of assuming the role of the elected performance manager 80 a with no loss of service . a fourth implementation of this would be for all devices 58 a on network 52 a to periodically broadcast or multicast their usage of bandwidth and other performance information . all devices 58 a - 2 and 58 - 3 equipped with a performance manager on network 52 a would receive this information . they individually creates estimates of the total bandwidth used and can use this in making decisions about use of shared resources such as link 66 . each device 58 a - 2 and 58 - 3 in this case determines and maintains an individual list of the devices 58 a that are operating on network 52 a . this would include maintaining an estimate of the current bandwidth and performance usage of each device 58 a . a list would be maintained with individual entries for each device 58 a from which a performance message has been received . this list would be used as the basis for the global estimate in that the bandwidth used can be summed or otherwise processed to create the global estimate . if a message is received from a device 58 a not previously observed a new entry on the list would be created for it . timers may optionally be maintained on each entry . if no message from a device 58 a is received within a timeout period , the device will be removed from the list . on receiving a new message from a device , the estimate in that message will replace the previous estimate in the list . a network - based aggregator 70 a is shown in fig2 . the address of aggregator 70 a can be supplied by either the device manufacturer or service provider in the manner described in , for example , applicant &# 39 ; s co - pending application u . s . patent application ( unknown ) entitled “ configuration of ip telephony and other systems ” bearing the applicants canadian attorney docket number p1960us00 , the contents of which are incorporated herein by reference . (“ p1660us00 ”) as described for the elected configuration manager in p1960us00 , the elected performance manager 80 a may from time - to - time , register important information at aggregator 70 a . the site for aggregator 70 a can be the same or different from the configuration aggregator discussed in p1960us00 they are logically separate . as well there may be multiple aggregators 70 a in the overall system , each responsible for aggregation of different aspects of the gathered data ( e . g . qos stats , fault detection ). this information can be analyzed by software at aggregator 70 a to make recommendations on the performance of network 52 a and its elements . for example , this software at aggregator 70 a could analyze the frequency of congestion occurrences and recommend that link 66 a be replaced with a higher - bandwidth link if congestion on link 66 a is occurring frequently or a link 66 a be replaced with a lower - bandwidth link for economy if congestion on link 66 a is not being observed . fig2 also indicates other devices 74 a on network 52 a such as a conference circuit device 74 a - 1 and an automatic speech recognizer 74 a - 2 . the devices 58 a on network 52 a can be programmed to look for the existence of devices 74 a and to use their capabilities as they exist . these devices 74 a can be shared fairly in a manner similar to that used to manage the external bandwidth on link 66 a . thus performance manager 80 a can contain similar structures to facilitate sharing of these devices 74 a as well . this sharing can also include management of the larger lan bandwidth that exists on network 60 a . each device 58 a can also include self - diagnostic routines . the results of these diagnostics can also be registered with the elected performance manager 80 a and as well with aggregator 70 a . a device 58 a that is reregistering on network 52 a may receive its past self - diagnostic history . that device 58 a can then adjust its behavior based on better knowledge of its maintenance status . for example , a device 58 a that is continually resetting can know of this fact and enter a state in which will prevent , or reduce the likelihood of such resetting from recurring . the elected performance manager 80 a can also be aware of the self - diagnostic state of all devices and can use this to detect network wide causes . for example a fluctuating or noisy power supply carried over lan 69 a can cause many devices 58 a to reset at once . the elected performance manager 80 a can be equipped with an expert system or similar technology to make these sorts of diagnoses . similarly , such expert system could be resident in the aggregator 70 a , fault or other self - diagnostics data delivered to the aggregator 70 a as previously described , and diagnostics carried out at aggregator 70 a . the above - described embodiments concentrated on the sharing of a common resource by a group of devices 58 a that are situated on lan 60 a or the like , such as a virtual lan . such an arrangement can allow devices 58 a to find each other by use of broadcast messages . however there are situations in which the sharing of a common resource is required where devices 58 a are situated across a routed network such as an enterprise wan . an example of this sharing could be a group of ip pbxs in an enterprise networks . it is common for several pbxs to be concentrated in a local zone . there will usually be ample bandwidth in the zone for media paths to be set up without significant chance for congestion . however , these devices will likely be sharing one or more common external physical links that connect them the external network ( pstn , internet , other locations on the enterprise network ). the applicant &# 39 ; s co - pending application u . s . patent application ( unknown ) entitled “ network traffic management ” bearing the applicants &# 39 ; canadian attorney docket number p1955us00 , the contents of which are incorporated herein by reference . (“ p1950us00 ”) describes such a network . however p1950us00focuses on what could be called composition management , where there are a group of mangers each managing a resource . these managers cooperate to compose these resources into a larger whole ( a network of routes in that case ). this sharing will need to be supplemented by the sharing described in this case if a zone contains multiple pbxs that all need to share the common external bandwidth . the techniques described in this specification can be used to accomplish the management of devices 58 a which are situated across a routed network such as an enterprise wan . instead of a broadcast message , a multicast message can be used . the routers in the local zone can be programmed to provide a multicast route across the routed network for this purpose . each device 58 a will be provided with the address of the multicast route as part of its configuration process . this could be accomplished by use of dynamic host configuration protocol (“ dhcp ”), or domain name service (“ dns ”), for example . the technique described in this specification can be used to set up the sharing service among them with the broadcast messages being replaced by messages sent on the multicast route . the teachings herein can be utilized in combination with p1960us00 and / or p1950us00 .