This invention relates to hybrid voice networks for example those consisting of TDM (carrying voice data) and Internet Protocol or other such systems, i.e. TDM Telephone systems where voice data is passed over the Internet, LANS etc, and includes IP phone calls to public ISDN. These are referred to hereinafter as hybrid VoIP systems. In a VoIP (hybrid) systems, inter-working protocols are used. One such is the Q- Interface signalling protocol (QSIG), a signalling standard for logical signalling between two private branch exchanges (PBX), and enables enterprises to run features across a heterogeneous telephony network comprising PBX' s or PINX' s (Private Integrated Network Exchange) from different vendors. CorNet-NQ is the Siemens implementation of QSIG. These inter-working protocols are used to optimise the payload path in case of supplementary services such as call transfer. Optimisation focuses mainly on the payload (i.e. routing the voice transmitted via the wire path), rather than the signalling path of the connection. In pure VoIP networks often use end to end payload control such as H.323 (A VoIP standard by ITU-T which defines a set of protocols for voice over IP). One of these is "third party pause", which controls the payload by a third party on the network. The third party pause and re-route is more a method or procedure provided by H.323 rather than a protocol itself. The problem with such hybrid networks is that any conversion from TDM to IP or vice versa comes along with increased latency, jitter etc. Another problem is the cost in terms of TDM gateway channels (for signals and data) which cannot be released because of ineffective payload paths. Such problems are inevitable and difficult to minimise where there are two VoIP systems connected over an ISDN line, e.g., the problem with the prior art is that such hybrids networks require conversion from TDM to IP and vice versa. In a network consisting of three VoIP systems a call may come in from public ISDN via a VoIP system acting as TDM gateway (1st conversion) and reaches the second VoIP system, where an analogue phone is connected (2nd conversion). These two conversions cannot be avoided, but if the analogue phone now consults to an IP phone at a third VoIP system and afterwards transfers the call from the 1st to the 3rd VoIP system you have perforce a third conversion in the second VoIP system. The invention overcomes this problem and involves optimising the payload path which means that the call from public ISDN is converted to IP only at the first VoIP system and travels directly to the third VoIP system without any other conversions.

The invention comprises, in a hybrid voice network a method of enhancing call transfer between three endpoints, comprising establishing a call connection between a first endpoint (A) and a second endpoint (B); establishing a call connection between said first endpoint and a third endpoint; communicating between said second and third endpoints; from the third endpoint, testing whether it is possible to establish a direct connection with said second endpoint; establishing said direct connection and terminating said connection between said first endpoint and either or both of said second and third endpoints. The endpoints may be connected via the Internet or a LAN. This is achieved by using the combination of classic TDM path replacement procedures together with the capability of VoIP end points to establish an end to end payload connection in order to optimise the resources in a hybrid system. These are resources which are needed are for example DSP channels on the gateway linecard, channels in the TDM switching matrix. Path replacement is the mechanism to optimise a connection in the TDM network, e.g., after a transfer. Imagine there is a phone A at a PBX A calling a phone B at PBX B. A consults to C in PBX C and transfers the call (B and C are now connected). Without path replacement the connection from phone B goes via PBX B, PBX A, PBX C to phone C. With path replacement the three PBX's try to optimize the connection, respectively from phone B via PBX B and PBX C to phone C (without involving PBX A) The statement "not involving PBX A" is correct after successful path replacement, during the path replacement the PBX A is involved in the procedure.In the following, the term "primary end" within a three party scenario is the "held" connection, e.g. A to B in the above example, and the term "secondary end" is the active (consultation) connection, e.g. A to C. The invention will now be described with reference to the following figures of which: Figures 1, 2 and 3 illustrate the operation an example of the invention. Figure 5 shows the connections before and after call transfer. Figures 6 and 7 illustrate the floe of data and control signals. In a pure TDM Network the path replacement procedures are terminated between the primary and secondary PBX. Because in TDM based PBX systems the intelligence is located in the PBX itself, the PBX acts on behalf of the endpoint or subscriber. Because the QSIG protocol defines a networking protocol (remember that this describes how to PBX' s are able to interwork), the PBX respectively the PINX are seen as terminating instances. Whatever the PBX / PINX takes to the connected phones or endpoints is not visible to the other PBX/PINX and therefore not scope of QSIG]. The optimisation of the allocated sources (b-channels, the channel in the ISDN/TDM network where the voice is transported) has to be done between the primary and secondary PBX. The mechanism is enhanced in the way that VoIP points are included in order to allow an end to end payload establishment on receipt of a path replacement proposal. In contrast to the TDM world, the endpoint VoBP itself has to re-route the payload, which has to be handled by the protocol. In other words, the PBX is not the terminating instance. After successful call transfer, the primary end invokes a path replacement procedure. This invocation causes the secondary end to setup a new connection using a payload proposal of endpoint C (i.e. OLC data including RTP/RTCP ports) (OLC - Open logical channel. A signalling command in the H.323 standard to open up a payload connection.) In order to provide the payload proposal to the primary end, the secondary PINX has to query this information from the endpoint C. On the primary end the payload proposal of endpoint C is given to endpoint B, whereas endpoint C is able to choose a payload setting and replies with its own payload settings. In the last step the PINX B connects to PINX C and the payload data is transferred towards the secondary end completing the backward establishment of the new signalling connection towards the primary end. Endpoint B and endpoint C are now able to exchange payload data. The term "backward establishment of the new signalling connection" is explained as follows: If phone A calls phone B and consults to C, both B and C have an incoming call. If A transfers B to C in the next step, C receives A-

a new partner on the existing connection. To perform a path replacement (to optimise the connection), the C side now tries to establish a new connection to B. Form Cs standpoint it is outgoing or "backward". On receipt of the path replacement invocation, the secondary PINX establishes a new signalling connection towards the primary end (using H.225 SETUP in the example of the figures) including the data of the new media session and the CorNet-NQ SETUP message. The primary PINX passes on the proposal for the new media session towards the end point B and if the end point B accepts the proposal, replies with a connect message towards the secondary end with a H.225 CONNECT in the example). A signalling message (H.323 FACILITY in the example) connects to endpoint C including endpoint B. Additionally existing media session towards PINX A respectively endpoint A is closed. On the secondary end the media data of endpoint B is passed on towards endpoint C. At this time a new signalling path between primary and secondary PENX and a new direct media session is set up for either voice, video or data between endpoints B and C is established. In the next step the old signalling path via PINX A is and the existing media session towards5 PINX A respectively endpoint A released. In one example the endpoints are involved into the path replacement procedure, because they are needed in order to provide their payload data. This is different to the TDM world, where the PBX / PINX are able to perform the path replacement by their own (without any communication to query the payload data towards the endpoints) In the drawings, the following terms are used: Gateway: in an IP world an entity providing access to the TDM world (conversion of signalling and payload), an IP/TDM Gateway. Gatekeeper: in the H.323 a central entity of control to route call signalling, address resolution, authorisation, policy handling etc. Call Processing: piece of SW sitting in a classic TDM PBX, handling the call establishment, policy management etc. Linecard: a piece of Hardware providing access to the switching matrix of a TDM PBX, e.g. an analogue linecard IP Cloud: a LAN/ Intranet/ Internet HP3/5K : a VoIP platform[RZ: A Siemens VoIP platform] h232CalUDl, CalllD2, CalllD3: are Call Identifier of aH.323 Call MOH: Music on Hold MediastreamB-A enabled: endpoint A and B have an established payload stream, e.g. A is able to speak to B and vice versa Transfer IND: indication of a transfer request fastStart: a H.323 data element providing payload paramenters between two endpoints in order to establish the payload stream (e.g. frame, UDP port number, etc.) Acceptance OLC: the partner accepts the received OLC command ProposalfastStart: one side proposes a payloadstream specifying the payload data NuIlOLC: an empty OLC command Tunnelled: tunnelling one protocol in another NQ-Facility: A CorNet-NQ facility message ctComplete.inv : a calltransferComplete.invocation message of the QSIG protocol NQ-Connect pRsetup.res a Cornet-NQ Connect message including a pathReplacement Result NQ disconnect a CorNet-NQ Disconnect message, a partner indicates that he ■ . wants to disconnect a connection NQ-RELEASE: a CorNet-NQ Release message, a receiver of a disconnect message replies with a release e.g. when he accepts the partners disconnect. NQ REL COM: a CorNet-NQ Release complete message, the sender of a disconnect replies with release complete when receiving a release.