reference is first made to fig1 , which illustrates a p2p communication system 100 . note that whilst this illustrative embodiment is described with reference to a p2p communication system , other types of communication system could also be used , such as non - p2p , voip systems . a first user of the p2p communication system ( denoted “ user a ” 102 ) operates a user terminal 104 , which is shown connected to a p2p network 106 . note that the p2p network 106 utilises a communication system such as the internet . the user terminal 104 may be , for example , a personal computer (“ pc ”), personal digital assistant (“ pda ”), a mobile phone , a gaming device or other embedded device able to connect to the p2p network 106 . the user device is arranged to receive information from and output information to a user of the device . in a preferred embodiment of the invention the user device comprises a display such as a screen and a keyboard and mouse . the user device 104 is connected to the p2p network 106 via a network interface 108 such as a modem , and the connection between the user terminal 104 and the network interface 108 may be via a cable ( wired ) connection or a wireless connection . the user terminal 104 is running a client 110 , provided by the p2p software provider . the client 110 is a software program executed on a local processor in the user terminal 104 . the user terminal 104 is also connected to a handset 112 , which comprises a speaker and microphone to enable the user to listen and speak in a voice call . the microphone and speaker does not necessarily have to be in the form of a traditional telephone handset , but can be in the form of a headphone or earphone with an integrated microphone , or as a separate loudspeaker and microphone independently connected to the user terminal 104 . an example of a user interface 200 of the client 110 executed on the user terminal 104 of user a 102 is shown illustrated in fig2 . the client user interface 200 displays the username 202 of user a 102 in the p2p system , and user a can set his own presence state ( that will be seen by other users ) using a drop down list by selecting icon 204 . the client user interface 200 comprises a tab 206 labelled “ contacts ”, and when this tab is selected the contacts stored by the user in a contact list are displayed . in the example user interface in fig2 , five contacts of other users of the p2p system ( user b to f ) are shown listed in contact list 208 . each of these contacts have authorised the user of the client 110 to view their contact details , presence state and mood message information . each contact in the contact list has a presence state chosen by the contact associated with it . for example , the presence status icon for user b 210 indicates that user b is “ online ”, the presence icon for user c 212 indicates that user c is “ not available ”, the presence icon for user d 214 indicates that user d &# 39 ; s state is “ do not disturb ”, the presence icon for user e 216 indicates user e is “ away ”, and the presence icon for user f 218 indicates that user f is “ offline ”. further presence indications can also be included . next to the names of the contacts in pane 208 are the mood messages 220 of the contacts . the contact list for the users ( e . g . the contact list 208 for user a ) is stored in a contact server ( not shown in fig1 ). when the client 110 first logs into the p2p system the contact server is contacted , and the contact list is downloaded to the user terminal 104 . this allows the user to log into the p2p system from any terminal and still access the same contact list . the contact server is also used to store the user &# 39 ; s own mood message ( e . g . the mood message of user a 102 ) and a picture selected to represent the user ( known as an avatar ). this information can be downloaded to the client 110 , and allows this information to be consistent for the user when logging on from different terminals . the client 110 also periodically communicates with the contact server in order to obtain any changes to the information on the contacts in the contact list , or to update the stored contact list with any new contacts that have been added . presence information is not stored centrally in the contact server . rather , the client 110 periodically requests the presence state for each of the contacts in the contact list 208 directly over the p2p system . similarly , the current mood message for each of the contacts , as well as a picture ( avatar ) that has been chosen to represent the contact , are also retrieved by the client 110 directly from the respective clients of each of the contacts over the p2p system . calls to the p2p users in the contact list may be initiated over the p2p system by selecting the contact and clicking on a “ call ” button 222 using a pointing device such as a mouse . alternatively , the call may be initiated by typing in the p2p identity of a contact in the field 224 . referring again to fig1 , the call set - up is performed using proprietary protocols , and the route over the network 106 between the calling user and called user is determined by the peer - to - peer system without the use of servers . for example , user 102 can call user b 114 . following authentication through the presentation of digital certificates ( to prove that the users are genuine subscribers of the p2p system — described in more detail in wo 2005 / 009019 ), the call can be made using voip . the client 110 performs the encoding and decoding of voip packets . voip packets from the user terminal 104 are transmitted into the network 106 via the network interface 108 , and routed to a computer terminal 116 of the called party , user b 114 , via a network interface 118 . a client 120 ( similar to the client 110 ) running on the user terminal 116 of user b 114 decodes the voip packets to produce an audio signal that can be heard by user b using the handset 122 . conversely , when user b 114 talks into handset 122 , the client 120 executed on user terminal 116 encodes the audio signals into voip packets and transmits them across the network 106 to the user terminal 104 . the client 110 executed on user terminal 104 decodes the voip packets from user b 114 , and produces an audio signal that can be heard by the user of the handset 112 . the voip packets for calls between p2p users ( such as 102 and 114 ) as described above are passed across the network 106 only , and the pstn network is not involved . furthermore , due to the p2p nature of the system , the actual voice calls between users of the p2p system can be made with no central servers being used . this has the advantages that the network scales easily and maintains a high voice quality , and the call can be made free to the users . additionally , calls can also be made from the client ( 110 , 120 ) using the p2p system to fixed - line or mobile telephones , by routing the call via a gateway 124 , to the pstn network 126 and to telephone equipment 128 . similarly , calls from fixed - line or mobile telephones ( 128 ) can be made to the p2p system via the pstn 126 and gateway 124 . fig3 illustrates a detailed view of the user terminal 104 on which is executed client 110 . the user terminal 104 comprises a central processing unit (“ cpu ”) 302 , to which is connected a display 304 such as a screen , an input device such as a keyboard 306 , a pointing device such as a mouse 308 , a speaker 310 and a microphone 312 . the speaker 310 and microphone 312 may be integrated into a handset 112 or headset , or may be separate . the cpu 302 is connected to a network interface 108 as shown in fig1 . fig3 also illustrates an operating system (“ os ”) 314 executed on the cpu 302 . running on top of the os 314 is a software stack 316 for the client 110 . the software stack shows a protocol layer 322 , a client engine layer 320 and a client user interface layer (“ ui ”) 318 . each layer is responsible for specific functions . because each layer usually communicates with two other layers , they are regarded as being arranged in a stack as shown in fig3 . the operating system 314 manages the hardware resources of the computer and handles data being transmitted to and from the network via the network interface 108 . the client protocol layer 322 of the client software communicates with the operating system 314 and manages the connections over the p2p system . processes requiring higher level processing are passed to the client engine layer 320 . the client engine 320 also communicates with the client user interface layer 318 . the client engine 320 may be arranged to control the client user interface layer 318 to present information to the user via the user interface of the client ( as shown in fig2 ) and to receive information from the user via the user interface . it is desirable for a user of the p2p system 100 to be able to transfer a call that he has received to another user of the p2p system . this is particularly the case for business use , where a single user , such as a receptionist , needs to transfer incoming calls to the most appropriate user . for example , user b 114 may wish to transfer a call from user a 102 to a third user , user c 130 . user c 130 operates a user terminal 132 connected to the network 106 via a network interface 134 . the user terminal 132 executes a client 136 similar to clients 110 and 120 . a handset 138 is connected to the user terminal 132 . fig4 illustrates the process by which a call from user a 102 can be transferred from user b 114 to user c 130 . note that fig4 illustrates the scenario in which a call is from user a to user b , and then transferred to user c . in this example , all the users are voip users . furthermore , there is only a single destination user , user c . in alternative embodiments , there may be multiple destination users . furthermore , the destination of the transfer can also be a pstn or mobile number . in step s 402 , the user a 102 uses the client 110 to establish a call with the client 120 of user b 114 . in step s 404 , user b 114 uses the client 120 to select to transfer the call to user c 130 . the user interface for selecting to transfer the call is illustrated in more detail in fig5 and 6 . the transfer process can be started by user b 114 either when the call from user a 102 is ringing ( i . e . connection established but not answered by user b ), or when a call between user a 102 and user b 114 is in progress . in particular , if the call between user a 102 and user b 114 is in progress , the call transfer can be initiated either immediately by user b 114 , or user a 102 can be put on hold before initiating the transfer ( this is known as a screening transfer ). when user b 114 selects the option to transfer the call , a “ transfer start ” command is sent from the client b 120 to client a 110 . this command includes the network identity of the user to which the call is being transferred . this can be in the form of user c &# 39 ; s p2p username , or , alternatively , a pstn telephone number can be specified . the “ transfer start ” command also includes a unique identifier for this transfer , and a digitally signed authentication token . the signed authentication token is digitally signed using a private cryptographic key held by user b 114 . this enables other users to validate that this token is indeed generated by user b 114 . the authentication token contains the username of user a 102 , the current time in the network , the unique identifier for this transfer , an optional text - based description of the reason for the transfer ( entered by user b 114 ), and the network identity of user c 130 . once the “ transfer start ” message of s 406 is sent to user a 102 , user b 114 can , if desired , go offline and transfer will continue on its own . however , for the purposes of the example in fig4 , user b 114 remains online . when user a 102 receives the “ transfer start ” message , the client 110 first validates that its signature is valid in step s 408 . then , in step s 410 , client 110 starts a call setup process to the user to which the call is being transferred , as specified in “ transfer start ” command . this uses the network identities from the “ transfer start ” message . s 410 is similar to a normal call setup , except an additional attribute is included in the call setup command . specifically , the signed authentication token and unique transfer identifier are included in the call setup message . when client c 136 receives the incoming call that includes the signed authentication token and transfer identifier , in step s 412 it validates the signature to make sure that transfer was indeed performed by user b 114 . client c 136 verifies that network time in the token is current , and checks if the transfer identifier in the token has not been seen before . this ensures that the token can be used only once , and prevents the same token being used over and over again . from the signed token , client c 136 also extracts user b &# 39 ; s network identity and before accepting the call , it performs an authorisation check as if the caller was user b 114 ( and not user a 102 ). thus user a 102 inherits the authorisation settings of user b 114 for this call . this is performed because the privacy settings of user c 130 may be such that user c 130 is only able to receive calls from users that are present in user c &# 39 ; s contact list , which he has authorised . user c 130 has authorised user b 114 to contact him ( as he is present in user b &# 39 ; s contact list ), but may not have previously authorised user a 102 ( or indeed may never have had any previous contact with user a ). therefore , a call between user a 102 and user c 130 could not normally be established . however , because this has been established though a trusted intermediary ( user b 114 ) the authorisation settings are overruled by user a 102 inheriting the authorisation settings of user b 114 , enabling the call to be established with user c 130 . during the transfer process , client a 110 sends several “ transfer status update ” messages to client b 120 , assuming that user b 114 is still online . these messages comprise the status of the call transfer between user a 102 and user c 130 . for example , these message state whether the transferred call is connecting , ringing , or in progress . if the transfer was made to multiple destinations also the actual destination that the transfer was answered on is included in this message . for example , whilst client c 136 is validating the signature in s 412 , client a 120 sends a “ connecting ” transfer status message to client b 120 in step s 414 . in step s 416 , the call is established between user a 102 and user c 130 . following the establishment of the call user a 102 and user c 130 , client a 110 transmits an “ in progress ” transfer status message to client b 120 . optionally , client b 120 can now drop any connections to client a 110 , as the transfer has completed , or client b 120 can continue to receive status updates until the call between user a 102 and user c 130 ends . if client a 110 is unable to establish connection to any of the transferred destinations ( e . g . if user c does not pick up ), client a 110 sends a “ transfer abort ” message to client b 120 , and the call will go to a ringing state again , such that user b 114 can either answer the call again , or attempt to transfer it to a different destination . this is not illustrated in fig4 . reference is now made to fig5 a to 5c which illustrate the user interfaces presented to the transferring party ( i . e . user b 114 in this example ) when performing a direct call transfer . in fig5 a , user b 114 receives an alert 502 on his user terminal that user a 102 is calling him , and answers the call using the answer button 504 . the call is then established between user a 102 and user b 114 , and displayed in the client ui as shown in fig5 b . to transfer the call , user b 114 selects the button labelled “ menu ” 506 , and selects the menu item labelled “ transfer the call to . . . ” 508 . this displays a list comprising the five most recent transfers or calls . user b 114 can select one of these contacts or use the “ someone else . . . ” option to select another contact . responsive to this , user b 114 is presented with the screen shown in fig5 c . this shows a list of the contacts 510 of user b 114 , to whom the call can be transferred . additionally , fig5 b shows a field for entering a pstn number 512 to which the call can be transferred . furthermore , a text entry field 514 allows user b 114 to enter a text message that will be displayed to the transferred user ( i . e . user c 130 ) which can be used to explain why the call is being transferred . this can be useful , as user c 130 can decide whether or not to accept the transfer before being connected to user a 102 . user b 114 can alternatively select a group of contacts to transfer the call to , by viewing the groups tab 516 . the transfer is initiated by user b 114 selecting the “ transfer ” button 518 . reference is now made to fig6 a to 6e , which illustrate the user interfaces presented to the transferring party ( i . e . user b 114 ) when performing a screening call transfer . in fig6 a , user b 114 receives an alert 602 on his user terminal that user a 102 is calling him , and answers the call using the answer button 604 . the call is then established between user a 102 and user b 114 , and displayed in the client ui as shown in fig6 b . user b 114 puts user a 102 on hold using the hold button 606 . in fig6 c , whilst user a 102 is on hold , user b 114 finds the contact 608 for the person to whom the call is to be transferred in the contact list ( i . e . user c 130 ), and initiates a call to this user with button 610 . in fig6 d , the call between user b 114 and user c 130 is connected , and displayed in the ui of the client . user b 114 can talk to user c 130 to explain why user a 102 is calling , and to warn user c that the call is about to be transferred . to transfer the call , user b 114 selects the button labelled “ menu ” 612 , and selects the menu item labelled “ transfer the call to . . . ” 614 . this displays a list comprising the five most recent transfers or calls . because user b 114 currently has user a 102 on hold , user a &# 39 ; s name and / or number is at the top of this list , and can be selected to initiate the transfer . alternatively , a different contact can be selected using the display in fig6 e , in a similar manner to that described with reference to fig5 c . while this invention has been particularly shown and described with reference to preferred embodiments , it will be understood to those skilled in the art that various changes in form and detail may be made without departing from the scope of the invention as defined by the appendant claims . for example , the call can be transferred to a pstn or mobile telephone number . this is achieved by the transferring user entering the number into the field 512 shown in fig5 c . if the call is to be transferred to a pstn or mobile number , then the process shown in fig4 is slightly different , as user b 114 sends a “ setup transfer ” message to the gateway 124 shown in fig1 with the destination telephone number ( s ) and receives a transfer identity back from the gateway 124 . this transfer identity is sent with the “ transfer start ” message to client a 110 along with the gateway address . client a 110 then connects to the gateway 124 , presents the transfer identity , and the call is connected to the destination telephone number ( s ). a signed token is not used in this case , as client b 120 has already told the gateway 124 that client a 110 will contact it . furthermore , the destination of the call transfer does not have to be a single endpoint . rather it can contain multiple destinations . additionally , this can be a mix of voip usernames and pstn numbers . in the case of multiple destinations , client a 110 will start connecting to all destinations at the same time and the transfer will go through to the destination which picks up the call first . while this invention has been particularly shown and described with references to example embodiments thereof , it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims .