System and method for call transfer in packet switched local area networks

A telecommunications system and method is disclosed for providing call transfer services within H.323 networks, in which the transferring end-point that invokes call transfer relays the media packets received from the transferred end-point to the transferred-to end-point, and likewise relays media packets received from the transferred-to end-point to the transferred end-point. However, the transferring end-point is taken out of the call after transferring the call so that it can make/receive new calls.

BACKGROUND OF THE PRESENT INVENTION

1. Field of the Invention

The present invention relates generally to packet switched local area networks, and specifically to call transfer mechanisms within packet switched local area networks.

2. Background of the Present Invention

Different multi-media standards have been defined for different types of systems in which the underlying transport is a Packet Based Network implementing voice over Internet Protocol (IP). For example, for Integrated Services Digital Networks (ISDN), the H.320 and H.324I/M standards are utilized. In addition, H.324 standards apply to Public Switched Telephony Networks (PSTNs), whereas H.324M standards apply to Public Land Mobile Networks (PLMNs). Furthermore, for Local Area Networks (LANs), the H.323 standards are used.

Within H.323 systems, H.323 endpoints may be integrated into personal computers, implemented in stand-alone devices, such as wireline or wireless telephones or implemented in wireless telecommunications systems. H.323 endpoints advantageously provide real-time audio, video and/or data communications capabilities in point-to-point or multipoint conferences.

Each H.323 endpoint is registered with a Gatekeeper for the H.323 system. The Gatekeeper stores an IP to that H.323 endpoint is requested, the Gatekeeper knows how to route the connection. If the H.323 endpoint is a Mobile Station (MS), such as a cellular telephone, the IP address for the MS typically includes the IP address for a Mobile Switching Center (MSC) serving the MS for call signaling.

H.323 systems currently support call transfer services, which allows the transferring end-point, which is the party that has one held call and one active call, to connect the remote end-points of the two calls and disconnect itself. The protocol used by the H.323 network for the call transfer function is specified by H.450 standards. In the H.450 solution, after the transferring end-point invokes call transfer, the original two calls are released and a new call is established between the transferred end-point and the transferred-to end-point.

Once the transferring end-point transfers the call, if both the transferred end-point and transferred-to end-point are within the H.323 system, the speech and/or data (commonly referred to as the media stream or media packets) are routed directly between the transferred end-point and transferred-to end-point. This requires both the transferred end-point and the transferred-to end-point to change the address of sent packets from the transferring end-point's address to each other's address. In order to accomplish this, both the transferred end-point and the transferred-to end-point must have knowledge of the call transfer and have the ability to perform the address switch. Implementing part of the call transfer functionality within the H.323 end-points themselves is neither efficient, nor desirable.

In addition, the H.450 solution is extremely difficult to implement when either the transferred subscriber and/or the transferred-to subscriber are within another system, such as the PLMN/PSTN. Since the PLMN/PSTN does not support H.323 protocols, when the transferred and/or transferred-to subscriber belongs to the PLMN/PSTN, the H.450 standard will not be supported by these subscribers.

Therefore, in order to perform call transfer when one or both of the remote parties is within the PLMN/PSTN, the H.323 network must intercept the H.450 messages and simulate end-point behaviors in the Gateway that is responsible for PLMN/PSTN and H.323 interworking. For example, if the transferring subscriber (hereinafter referred to as the A subscriber) is within the H.323 network and both the transferred subscriber (hereinafter referred to as the B subscriber) and the transferred-to subscriber (hereinafter referred to as the C subscriber) are outside of the H.323 network, after subscriber A transfers the call, the speech and/or data from subscriber B is routed to the Gateway. The Gateway must have knowledge about the call transfer and must route the speech and/or data to subscriber C. Similarly, the speech and/or data from subscriber C is routed to the Gateway, and the Gateway must route the speech and/or data from subscriber C to subscriber B. Thus, with the current H.450 standard, the Gateway must include the end-point functionality for H.450 call transfer handling. It is neither desirable, nor efficient, to require Gateways to include part of the call transfer functionality.

It is, therefore, an object of the present invention to route the media packets through the transferring end-point after the call is transferred between the transferred and transferred-to end-points.

It is a further object of the present invention to enable the transferring end-point to be free to make other transactions after call transfer.

SUMMARY OF THE INVENTION

The present invention is directed to telecommunications systems and methods for providing call transfer services within H.323 networks. After invoking call transfer, the transferring end-point relays the media packets received from the transferred end-point to the transferred-to end-point, and likewise relays media packets received from the transferred-to end-point to the transferred end-point. However, the transferring end-point is taken out of the call after transferring the call so that it can make/receive new calls. Advantageously, inter-working with the PLMN/PSTN is easy to implement since no call transfer functionality needs to be included within the Gateway. In addition, no is additional functionality needs to be included within the transferred and/or transferred-to end-points since both end-points still route media packets to the transferring end-point.

Within H.323 systems, each H.323 end-point is registered with an H.323 Gatekeeper for the H.323 system. The Gatekeeper stores an Internet Protocol (IP) address for the H.323 end-point, and uses the IP address to route a connection to that H.323 end-point. If, as is shown in (MS)20, such as a cellular telephone, the IP address for the MS20for call signaling typically includes the IP address for a Mobile Switching Center (MSC)54serving the MS20. For media transfer (speech and/or data), the IP address includes the IP address of an A-bis Gateway (AGW)40connected to the MSC54, along with a specific port number for that MS20. The port number is associated with a specific media port for the MS20within the AGW40. Therefore, in the case of MS's20, the H.323 end-point from the Gatekeeper's perspective consists of at least both the AGW40and the MS20for media connections.

The AGW40is connected to an associated Base Transceiver Station (BTS)30, which operates as a transceiver for transmitting and receiving data and control messages to and from the MS20over an air interface25. Thus, the AGW40has both a signaling connection (shown by the dotted line80) and a media connection (shown by the solid line90) to it's associated BTS30. In addition, each AGW40may have a media connection90to other AGW's40depending on the call scenario.

The AGW40also has a signaling connection80to the MSC54and a Base Station Controller (BSC)52, which is responsible for controlling one or more BTS's30. It should be noted that the MSC54and BSC52nodes can be included together within a single node, referred to herein as an Access Node50. It should further be noted that within the GSM on the Net system, the MSC54is termed a Network Access Controller and the BSC52is termed a Radio Network Server. The AGW40converts between the circuit-switched signaling and data transport used by the BTS30and the packet-switched signaling and data transport used by the H.323 system10.

Calls between H.323 end-points20and subscribers outside of the H.323 system10, e.g., subscribers within another H.323 system, the Public Switched Telephone Network (PSTN) or the Public Land Mobile Network (PLMN), are routed through a Gateway70, which converts the speech and/or data between the IP format used by the H.323 system10and the PLMN/PSTN format. Calls coming into the H.323 system10from outside are routed through the Gateway70to the Gatekeeper60, and subsequently to the desired H.323 end-point20. Once a connection is established, media packets are transmitted directly between the H.323 end-point20and the Gateway70over the media connection90, and speech and/or data is transmitted between the Gateway70and the non-H.323 subscriber (not shown) via the non-H.323 subscriber's network (not shown).

With reference now toFIGS. 2A-2Dof the drawings, if an MS20within the H.323 system10(hereinafter referred to as subscriber A) makes or receives a call from another H.323 end-point85(hereinafter referred to as subscriber B), and at some point thereafter, puts subscriber B85on hold and either places a new call to another H.323 end-point95(hereinafter referred to as subscriber C) or receives a call from subscriber C95, and subscriber A20wants to connect subscriber B85with subscriber C95into a new call between themselves, subscriber A20can invoke the call transfer service. It should be noted that inFIGS. 2A-2D, subscriber's B and C can be any H.323 end-point, such as another MS, an IP phone, a PC phone or a PBX terminal within the H.323 system10.

In general, the call transfer service enables the controlling mobile subscriber (subscriber A) who has one active call (subscriber C) and one held call (subscriber B), each of which can be an incoming or outgoing call, to connect the remote parties of the two calls (subscribers B and C) and release the controlling subscriber's (subscriber A) own connection. The controlling subscriber (subscriber A) is then free to make or receive other calls. The call transfer service can be invoked using any man machine interface (MMI), such as pressing “4SEND” on the MS20.

As shown inFIG. 2A, before subscriber A20has invoked the call transfer service, the signaling connection80for the call between subscriber A20and subscriber B85goes from subscriber A (MS)20to the BTS30, AGW40, Access Node50, Gatekeeper60and finally to subscriber B85. Likewise, for the call between subscriber A20and subscriber C95, the signaling connection80goes from subscriber A20to the BTS30, AGW40, Access Node50, Gatekeeper60and finally to subscriber C95. It should be understood that if the MSC and BSC functionality (shown inFIG. 1) are within two separate nodes, the connection would go to both the BSC and the MSC.

As shown inFIG. 2C, before the call transfer has been invoked, the media connection90(speech and/or data) for the call between subscriber A20and subscriber B85normally goes from subscriber A20to the BTS30to the media port (MP)42in the AGW40for subscriber A20and then from the real time protocol (RTP) port44assigned to the call in the AGW40(hereinafter referred to as RTP (held)44) to subscriber B85. However, since between MP42and RTP (held)44is broken, so that media from subscriber A20cannot reach subscriber B85, and vice-versa.

For the call between subscriber A20and subscriber C95, the media connection90goes from subscriber A20to the BTS30, to the MP42in the AGW40and then directly from the RTP port46in the AGW40assigned to the call (hereinafter referred to as RTP (active)46) to subscriber C95.

With reference now toFIG. 3of the drawings, which will be described in connection withFIGS. 2A-2Dof the drawings, once subscriber A20invokes the call transfer service, subscriber A20sends a DTAP FACILITY message to the Access Node50(step300), which checks to make sure that subscriber A20is allowed to invoke the call transfer and has one active call (subscriber C95) and one held call (subscriber B85) (step310). Thereafter, the Access Node50sends a Media Port Disconnect Request (MPDR) message to the AGW40(step320), ordering the AGW40to break the link between the MP42for subscriber A20and RTP (active)46. In response, the AGW40stops relaying the media packets received at the AGW40for the active call to the BTS30(step330).

Thereafter, the Access Node50sends a Start Relay Request message to the AGW40(step340) that orders the AGW40to start relaying media packets received on RTP (active)46to the IP address of the held call (subscriber B85). The Access Node50also sends another Start Relay Request message to the AGW40(step350) ordering the AGW40to start relaying media packets received on RTP (held)44to the IP address of the active call (subscriber C95).

At this point, subscribers B and C are involved in a call between themselves, but the MS20(subscriber A) is not yet free to make and receive new calls. Therefore, in order to free subscriber A20, the Access Node50sends a Disconnect message to the MS20for the held call (A-B call) (step360). The held call is now disconnected from subscriber A20. Thereafter, the Access Node50sends a Disconnect message for the active call to the MS20(step370) to release the active call.

Finally, to clear the assigned radio resources for the MS20, the Access Node50sends a message to the BTS30(step380). Now, the MS20is free to make and receive new calls, and the MS20is not involved in the call connection between subscriber B85and subscriber C95. Thereafter, the Access Node50marks the call transferred between the transferred-to95and transferred85end-points (step390).

As shown inFIG. 2B, after the call transfer is completed, the signaling connection80for the transferred call goes from subscriber B85to the Gatekeeper60, to the Access Node50, to the AGW40, back to the Access Node50, back to the Gatekeeper60and finally to subscriber C95. As shown inFIG. 2D, the media connection90for the transferred call goes directly from subscriber B85, to RTP (held)44in the AGW40and finally to subscriber C95for media packets originated by subscriber B85, and directly from subscriber C95, to RTP (active)46in the AGW40and finally to subscriber C95for media packets originated by subscriber C95.

With reference now toFIGS. 4A-4Dof the drawings, as discussed hereinbefore, the advantage of implementing call transfer in the afore-described way is that there is no problem when inter-working with the PLMN/PSTN15. Therefore, when one of the remote parties (here subscriber B85) is outside of the H.323 system10, the call transfer service can be easily implemented without impacting the Gateway70. Thus, as shown inFIG. 4A, before call transfer, the signaling connection80for the call between subscriber A20and subscriber B85goes from subscriber A20to the BTS30, AGW40, Access Node50, Gatekeeper60, Gateway70and finally to subscriber B85. As discussed hereinbefore, for the call between subscriber A20and subscriber C95, the signaling connection80goes from subscriber A20to the BTS30, AGW40, Access Node50, Gatekeeper60and finally to subscriber C95.

As shown inFIG. 4C, before the call transfer has been invoked, the media connection90(speech and/or data) for the call between subscriber A20and subscriber B85normally goes from subscriber B85to the Gateway70, where the speech and/or data are converted from circuit-switched into packet-switched, to RTP (held)44in the AGW40and then to subscriber A20via the MP42in the AGW40for subscriber A20and the BTS30. However, since subscriber B85is the held call, the media connection90between MP42and RTP (held)44is broken so that media from subscriber A20cannot reach subscriber B85, and vice-versa. As discussed hereinbefore, for the call between subscriber A20and subscriber C95, the media connection90goes from subscriber A20to the BTS30, to the MP42in the AGW40for subscriber A20and then directly from RTP (active)46in the AGW40to subscriber C95.

After call transfer has been completed in accordance with the steps shown inFIG. 3of the drawings, as shown inFIG. 4B, the signaling connection80for the transferred call goes from subscriber B85to the Gateway70, to the Gatekeeper60, to the Access Node50, to the AGW40, back to the Access Node50, back to the Gatekeeper60and finally to subscriber C95. As shown inFIG. 4D, the media connection90for the transferred call goes from subscriber B85, to the Gateway70, to RTP (held)44in the AGW40, and then directly to subscriber C95for speech and/or data originated by subscriber B85, and from subscriber C95to RTP (active)46in the AGW40to the Gateway70and finally to subscriber B85for media packets originated by subscriber C95.

With reference now toFIGS. 5A-5Dof the drawings, when both remote parties (subscriber's B85and C95) are outside of the H.323 system10, here shown within the PLMN/PSTN15, the process is similar to that described in connection withFIGS. 4A-4Dof the drawings. However, it should be noted that more than one Gateway70may be involved if subscriber's B85and C95are within different networks served by different Gateways70. For example, if subscriber B85and subscriber C95are within two different countries, two Gateways70may be involved.

For convenience, only one Gateway70is shown inFIGS. 5A-5D. In this case, as shown inFIG. 5A, before call transfer, the signaling connection80for the call between subscriber A20and subscriber B85goes from subscriber A20to the BTS30, AGW40, Access Node50, Gatekeeper60, Gateway70and finally to subscriber B85. Likewise, for the call between subscriber A20and subscriber C95, the signaling connection80goes from subscriber A20to the BTS30, AGW40, Access Node50, Gatekeeper60, Gateway70and finally to subscriber C95.

As shown inFIG. 5C, before the call transfer has been invoked, the media connection90(speech and/or data) for the call between subscriber A20and subscriber B85is not active since subscriber B85is the held call, and therefore, the connection between MP42and RTP (held)44is broken. For the active call between subscriber A20and subscriber C95, the media connection90goes from subscriber A20to the BTS30, to the MP port42in the AGW40for subscriber A20, from RTP (active)46in the AGW40to the Gateway70and finally to subscriber C95.

After call transfer has been completed in accordance with the steps shown inFIG. 3of the drawings, as shown inFIG. 5B, the signaling connection80for the transferred call goes from subscriber B85to the Gateway70, to the Gatekeeper60, to the Access Node50, to the AGW40, back to the Access Node50, back to the Gatekeeper60, back to the Gateway70and finally to subscriber C95. As shown inFIG. 5D, the media connection90for the transferred call goes from subscriber B85to the Gateway70, to RTP (held)44in the AGW40, back to the Gateway70and finally to subscriber C95for speech and/or data originated by subscriber B85. For speech and/or data originated by subscriber C95, the media connection90goes from subscriber C95, to the Gateway70, to RTP (active)46in the AGW40, back to the Gateway70and finally to subscriber B85.

The situation is more complicated if subscriber A has performed an internal handover within the H.323 system when subscriber A invokes the call transfer service. An internal handover would normally occur when the MS has moved to a different cell served by a different BTS within the H.323 system. The media connection for the two calls (held call and active call) before the call transfer has been invoked is shown in FIG.6A. For convenience, both of the remote parties (subscribers B85and C95) are shown inside of the H.323 system10. However, it should be understood that subscribers B85and C95can be within any system, as discussed in connection withFIGS. 4 and 5.

As shown inFIG. 6A, before call transfer, the media connection90for the call between subscriber A20and subscriber B95is not active, and therefore, the connection between MP42and RTP (held)44is broken, so that media from subscriber A20cannot reach subscriber B, and vice-versa. Thus, the media connection90is shown going directly between subscriber B85to RTP (held)44in the anchor AGW40a, which is the AGW40athat subscriber A20has been handed over from.

For the active call between subscriber A20and subscriber C95, the media connection90is more complicated. For media packets sent to subscriber C95, the connection goes from subscriber A20to the BTS30, to the MP42for subscriber A20in the non-anchor AGW40b, which is the AGW40bthat subscriber A20has been handed over to, from the RTP port49for the call in the non-anchor AGW40bto RTP (active)46in the anchor AGW40aand finally to subscriber C95. For media packets sent to subscriber A20, the media connection goes from subscriber C95to RTP (active)46in the anchor AGW40a, to the RTP port49assigned to the call in the non-anchor AGW40b, to the BTS30via the MP42for subscriber A20in the non-anchor AGW40band finally to subscriber A20.

With reference now toFIG. 7of the drawings, which will be described in connection withFIGS. 6A and 6Bof the drawings, as in the typical case discussed above in connection withFIG. 3, to invoke the call transfer service, the MS20sends a DTAP FACILITY message to the Access Node50(step700). Thereafter, the Access Node50checks to make sure that subscriber A20has one active call (subscriber C95) and one held call (subscriber B85) (step710).

In order to perform call transfer when subscriber A has performed an internal handover, the Access Node50sends a Stop Relay Request message to the anchor AGW40ato order the anchor AGW40ato stop relaying packets between RTP (active)46in the anchor AGW40aand the RTP port49in the non-anchor AGW40b(step720). Thereafter, the Access Node50sends the Start Relay Request message to the anchor AGW40a, which orders the anchor AGW40ato start relaying media packets received on RTP (active)46to the IP address of the end-point associated with the held call (subscriber B85) (step730). The Access Node50also sends another Start Relay Request message to the anchor AGW40a, which orders the anchor AGW40ato start relaying media packets received on RTP (held)44(from subscriber B85) to the IP address of the end-point associated with the active call (subscriber C95) (step740).

At this point, subscribers B85and C95are involved in a call between themselves, but the MS (subscriber A20) is not yet free to make and receive new calls. Therefore, as discussed above in connection withFIG. 3, in order to free subscriber A20, the Access Node50sends a Disconnect message to the MS20for the held call (A-B call) (step750). The held call is now disconnected from subscriber A20. The same process occurs for the active call (Access Node50sends a Disconnect message (step760) for the active call to the MS20).

To clear the assigned radio resources for the MS20, the Access Node50sends a message to the BTS30(step770). Now, the MS20is free to make and receive new calls, and the MS20is not involved in the call connection between subscriber B85and subscriber C95. Finally, to release the assigned RTP port49in the non-anchor AGW40b, the Access Node50orders the non-anchor AGW40bto release the assigned RTP port49in the non-anchor AGW40b(step780). Thereafter, the Access Node50marks the call transferred between the transferred-to and transferred end-points (step790).

As shown inFIG. 6B, after call transfer, media packets originated by subscriber B85go from subscriber B85to RTP (held)44in the anchor AGW40aand then to subscriber C95. For media packets originated by subscriber C95, the media connection90goes from subscriber C95to RTP (active)46in the anchor AGW40ato subscriber B85.

A similar situation occurs when subscriber A has performed an external handover to a BTS outside of the H.323 system. As shown inFIG. 8A, when subscriber A20has roamed outside of the H.323 system10, e.g., within the PLMN15, the media connection90is close to that shown inFIG. 6A, except that there is not a non-anchor AGW. Instead, the media packets from subscriber C95for the active call are routed between RTP (active)46in the AGW40originally serving the MS20and an RTP port72for the MS20in the Gateway70. The Gateway70converts the media packets from packet-switched to circuit-switched and transmits the circuit-switched speech and/or data from the RTP port72for the MS20in the Gateway70to the PLMN15, which relays the speech and/or data to the MS20via a MSC54, BSC52and BTS30within the PLMN15serving the MS20. Likewise, speech and/or data received from the MS20at the RTP port72in the Gateway70are converted into media packets and routed to subscriber C95via RTP (active)46within the AGW40.

With reference now toFIG. 9, which will be discussed in connection withFIGS. 8A and 8Bof the drawings, the call transfer service can still be invoked even in this case. As discussed hereinbefore, to invoke the call transfer service, the MS20sends a DTAP FACILITY message to the Access Node50(step900). It should be understood that all messages sent between the Access Node50and the MS20(and MSC54, BSC52and BTS30) within the PLMN15go through the Gateway70. The Access Node50then checks to make sure that subscriber A20has one active call and one held call (step910).

Thereafter, the Access Node50sends the Stop Relay Request message to the AGW40, which orders the AGW40to stop relaying packets from RTP (active)46in the AGW40to the RTP port72for the MS20in the Gateway70(step920). Thereafter, the Access Node50sends the Start Relay Request message to the AGW40, which orders the AGW40to start relaying voice packets received on RTP (active)46to the IP address of the end-point for the held call (subscriber B85) (step930). The Access Node50also sends another Start Relay Request message to the AGW40that orders the AGW40to start relaying voice packets received on RTP (held)44to the IP address of the end-point for the active call (subscriber C95) (step940).

At this point, subscribers B85and C95are involved a call between themselves, but subscriber A20is not yet free to make and receive new calls. Therefore, in order to free subscriber A20, the Access Node50sends a Disconnect message (encapsulated in a MAP_Forward_Access_Signalling message) to the MS20for the held call (A-B call) (step950). The held call is now disconnected from subscriber A. The same process occurs for the active call (Access Node50sends an encapsulated Disconnect message (step960) for the active call to the MS20).

To clear the assigned radio resources for the MS20, the Access Node50sends a message (encapsulated in a MAP_Forward_Access_Signalling message) to the BTS30within the PLMN15(step970). Now, the MS20is free to make and receive new calls, and the MS20is not involved in the call connection between subscriber B85and subscriber C95. Finally, the Access Node50sends a message to release the handover call to the Gatekeeper60(step980). Thereafter, the Access Node50marks the call transferred between the active and held end-points (step990).

As shown inFIG. 8B, after call transfer, media packets originated by subscriber B85go from subscriber B85to RTP (held)44in the AGW40and then to subscriber C95. For media packets originated by subscriber C95, the media connection90goes from subscriber C95to RTP (active)46in the AGW40to subscriber B85.

With reference now toFIG. 10of the drawings, the steps for either subscriber B or subscriber C to disconnect the transferred call are shown. It should be noted that it makes no difference in the disconnect process where subscriber's B and C are located or whether there is one AGW, two AGWs or one AGW and one Gateway involved.

If, for example, subscriber B disconnects the call (hangs up), the Gatekeeper60transmits a Release Complete message to the Access Node50for the A-B call (step100). Thereafter, the Access Node50sends a Release Complete message to the Gatekeeper60for the A-C call (step110).

Subsequently, the Access Node50sends a release RTP message to the AGW40for releasing RTP (active) (step120). After the AGW40releases RTP (active), the AGW40sends an Acknowledgment message back to the Access Node50(step130). The Access Node50also sends a release RTP message to the AGW40for releasing RTP (held) (step140). After the AGW40releases RTP (held), the AGW40sends an Acknowledgment message back to the Access Node50(step150). Finally, the Access Node50releases all of it's resources for the A-B call and the A-C call (step160).

Advantageously, by routing the transferred call through the AGW, the same two charging records that were generated before call transfer (for A-B call and A-C call) keep gathering data and are not closed until B or C disconnects. In addition, neither the B nor C subscriber needs to have knowledge of the transfer (i.e. subscriber's B and C still route to subscriber A, so they do not need to change the IP address of the receiving end-point). Furthermore, inter-working with the PLMN/PSTN is easily implemented without impacting the Gateway.

With reference now toFIG. 11of the drawings, the above-described call transfer system and method can also be used when the transferring end-point is a regular (fixed) H.323 end-point, such as a PC, IP phone or PBX. In this case, as long as the transferring H.323 end-point has three RTP ports associated with it, one for the active call RTP (active)46, one for the held call RTP (held)44and one additional RTP port, denoted as RTP (extra)48, call transfer can be achieved.

Instead of the Access Node50instructing the AGW40to relay media90between subscribers B85and C95(as shown inFIGS. 2,4and5), the H.323 end-point40needs to perform similar actions. Thus, in this case, the controlling node for the call transfer service is the where the H.323 end-point includes an MS, the controlling node is the Access Node50. After call transfer, the H.323 end-point40is free to make and receive new calls on RTP (extra)48.

It should be understood that if subscriber B85and/or subscriber C95is outside of the H.323 system10, the signaling80and media connections90will be similar to those shown inFIGS. 4 and 5, except that the Access Node50and AGW40ofFIGS. 4 and 5are replaced by the transferring H.323 end-point40.