Abstract:
A method for routing integrated traffic from a remote site to a voice over packet system is disclosed. The method comprises receiving control signals at a virtual voice port of the voice over packet system. The method also comprises translating the controls signals to internal signals of the voice over packet system. Additionally, the method comprises transmitting data from the remote site to the virtual voice port and transferring the transmitted data form the virtual voice port to the physical port.

Description:
FIELD OF THE INVENTION 
   The present invention relates to increasing the number of ports in a voice over packet system. More particularly, the present invention relates to using a virtual voice port to increase the number of available ports in a voice over packet system that supports both permanent virtual connections and switched virtual connections. 
   BACKGROUND 
   Developments in router technology have led to system designs that provide a general-purpose connection-oriented transfer mode for a wide range of services. These services include the simultaneous transfer of integrated traffic (data, voice, and video traffic) over the same network system. Prior art systems have typically relied on two connections types, a switched virtual connection and a permanent virtual connection, to support the transfer of different services over the same network. 
   The switched virtual connection (“SVC”) relies on control protocols initiated by a physical interface to establish connections across a network. Specifically, an originating device uses control protocols to request a network connection between the originating device and the destination device. Typically, in an SVC, intermediate nodes of the network use the physical (and logical) address of the originating device to create a virtual path between the originating device and the destination device. Once the call is terminated, however, the virtual path is removed. The removal of the virtual path allows for the creation of additional virtual paths, thus increasing transmission bandwidth across the network. 
   In contrast, a permanent virtual connection (“PVC”) uses initial network management to establish a permanent link between two nodes. The PVC provides a stable transmission path that ensures dedicated connectivity between two nodes. The PVC, however, reduces transmissions bandwidth because, unlike the SVC, the PVC assumes control of a subset of transmission links for an indefinite period of time. Additionally, the PVC reduces the availability of transmission ports in both the originating device and the destination device. 
   Examples of a PVC include analog private phone lines, digital private phone lines, a direct connection between two private branch exchanges (“PBXs”,) or Frame Relay Forum (“FRF”) protocols that deal exclusively with permanent calls—such as the FRF.11 protocol. Examples of a SVC include a telephone to telephone call predicated by a dialing sequence to request a connection and asynchronous transfer mode (“ATM”) networks that use a cell-based switching and multiplexing technology to provide services for both local area networks and wide area networks. Regardless of the connection service used (SVC or PVC), prior art network systems typically use a physical port and a routing system to connect to a transmission network. 
     FIG. 1  shows a prior art voice port coupled to a network. In particular, system  100  includes a voice port ( 105 ), also referred to as a physical port, coupled to a routing system ( 105   a ). As illustrated in  FIG. 1 , voice port  105  is coupled to phone  110  via physical interface (“PI”)  115 . PI  115  is responsible for multiplexing the control and audio signals of phone  110  to lines  115   a  and  115   b , respectively. 
   The control signals are routed to telephony protocol  120 . Using the phone  110  control signals, telephony protocol  120  negotiates with other voice ports through a call management control (not shown) to gain access to routing system  105   a . Provided voice port  105  has access to routing system  105   a , telephony protocol  120  transmits the control signals to routing system  105   a  via C 127 . Routing system  105 , in turn, uses the control signals to establish a connection with a remote physical device. For example, if phone  110  is used to generate a SVC to a remote phone. The on-hook and off-hook signals of phone  110  denote control signals used to initiate a SVC connection. Additionally, the numbers dialed by phone  110  are control signals used to select a termination point of the SVC. Furthermore, the ringing tone, or alternatively the busy tone, transferred back to telephony protocol  120  via network  145  denotes the remote phone&#39;s response to the connection attempts by phone  110 . 
   Following the previous example, once the control signals have established a connection with the remote device, the audio signals of phone  110  are routed to voice compression block  125 . Voice compression block includes a digital signal processor (“DSP”) device that converts the audio signals into a digitized voice payload. The digital voice payload, in turn, is transferred to routing system  105   a  via line V 126 . 
   Routing system  105   a  is used to format both the control signals and the digitized data generated by voice port  105 . The formatted data is subsequently transferred to a remote device via network  145 . Network  145  comprises an ATM or Frame Relay network. Accordingly, routing system  105   a  generates packet data for transmission along network  145 . In particular, packet routing  130  selects a digitized payload from either voice port  105  or other voice ports (not shown) coupled to routing system  105   a . The selected digitized payload is transferred to packet encapsulation  135 . In packet encapsulation  135 , based on the protocol of network  145 , packets are generated from the digitized payload. Additionally, in packet encapsulation  135  packet addressing information and packet headers are append to the generated packets. Subsequently, the packets are transferred to network interface (“NI”)  140  for transmission over network  145 . Typically, NI  140  includes a serial interface or ethernet connection to network  145 . 
   System  100  provides a basic system for connecting devices in a network that uses either a SVC or a PVC. System  100 , however, results in numerous disadvantages when used in a heterogeneous networking system that uses both PVC and SVC. One disadvantage results from the network requirements associated with a PVC. Specifically, in a PVC at least two physical ports are designated as PVC connections. Thus, the number of available resources for SVCs is reduced. For example, if voice port  105  is designated as the terminating point of a given PVC, voice port  105  is excluded from receiving SVCs from other remote devices. Isolating voice port  105  necessitates the addition of a second voice port to support SVCs. Another disadvantage results from the typical design of voice over packet (“VOP”) systems. VOP systems are designed to connect a limited number of voice ports to a single routing system. In a PVC/SVC networking system, however, a subset of the VOP voice ports are dedicated to PVCs. The dedicated PVCs result in a VOP with a reduced number of voice ports for SVCs. 
   SUMMARY OF THE INVENTION 
   It is therefore an object of the invention to provide a voice over packet (“VOP”) system that communicates with a multitude of remote sites, both through permanent calls and switch calls, without reducing the number of available physical ports. 
   It is a further object of the invention to provide a virtual port that emulates a physical port, thus providing a port that can initiate or terminate PVCs. 
   These and other objects of the invention are provided by a method for routing integrated traffic from a remote site to a voice over packet system. The method comprises receiving control signals at a virtual voice port of the voice over packet system. The control signals request a data transmission from the remote site to the voice over packet system. The method also comprises translating the controls signals to internal signals of the voice over packet system. The translated signals are operable to couple the virtual voice port to a physical port of the voice over packet system. Additionally, the method comprises transmitting data from the remote site to the virtual voice port and transferring the transmitted data form the virtual voice port to the physical port. 
   Other features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The features and advantages of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements and in which: 
       FIG. 1  shows a prior art voice port coupled to a network; 
       FIG. 2  illustrates one embodiment of a voice over packet system using a virtual voice port; 
       FIG. 3  illustrates one embodiment of a virtual voice port coupled to a routing system; 
       FIG. 4  illustrates one embodiment of a virtual voice port; 
       FIG. 5 , shows one embodiment of a flow chart illustrating a permanent call connected to a switched call; 
       FIG. 6 , shows one embodiment of a flow chart illustrating a switched call connected to a permanent call; and 
       FIG. 7 , illustrates one embodiment of a voice over packet system using two virtual voice ports to perform a data conversion between different permanent protocols. 
   

   DETAILED DESCRIPTION 
   A method for incorporating a virtual voice port into a voice over packet (“VOP”) system is disclosed. The virtual voice port emulates a terminating node (i.e. a physical voice port) for a permanent virtual connection (“PVC”) linked to the VOP system. Thus, the VOP system supports a PVC without reducing the number of physical voice ports included in the VOP system. For one embodiment, the physical voice ports are used to initiate switched virtual connections (“SVCs”). For an alternative embodiment, the virtual voice port is operable to accept switched calls from physical voice ports of the VOP system. Thus, the virtual voice port allows dialed access from the physical ports to the PVC link. 
   For another embodiment, a pair of virtual voice ports are used to provide a conversion mechanism between two different PVC protocols. Specifically, a VOP system with a first virtual voice port is used to receive data on a first PVC. Subsequently, the VOP system converts the incoming data to a different PVC protocol and transfers the output of the first virtual port to a second virtual voice port. For one embodiment, the second voice port is coupled to a second PVC. Thus, the VOP system provides a conversion mechanism between two different PVC protocols. 
   An intended advantage of an embodiment of the invention is to provide a VOP system that communicates with a multitude of remote sites, both through permanent calls and switched calls, without reducing the number of available physical ports. 
   Another intended advantage of an embodiment of the invention is to provide a virtual port that emulates a physical port, thus providing a port that can initiate or terminate PVCs. Yet another intended advantage of an embodiment of the invention is to provide a VOP system that can translate between different PVC protocols. 
     FIG. 2  illustrates one embodiment of a voice over packet system using a virtual voice port. In particular, system  200  includes a voice over packet system (“VOPS”)  220  coupled to network  230  via line  261 . Network  230 , in turn, is coupled to node  240  and node  250 . For one embodiment VOPS  220  supports both SVCs and PVCs. For alternative embodiments, network  230  comprises a cell-based multi-service network comprising Frame Relay, Asynchronous Transfer Mode (“ATM”), High-level Data Link Control (“HDLC”), Internet Protocol (“IP”), or Time Division Multiplexed (“TDM”) networks. For another embodiment, VOPS  220  comprises an intermediate node in network  230 . For yet another embodiment, line  261  comprises an input/output serial line or an input/output ethernet line used to transfer data. 
   As illustrated in  FIG. 2 , VOPS  220  includes phones  210 – 21 N coupled to physical ports  205   a – 205   n . For alternative embodiments, the physical ports  205   a – 205   n  are coupled to a video device, a facsimile device, or a modem. The physical ports  205   a – 205   n  are, in turn, coupled to call management  226  via line  270 . The physical ports  205   a – 205   n  are also coupled to routing system  225 . 
   VOPS  220  also includes a virtual voice port  260  coupled to call management  226  and routing system  225  via lines  272  and  273 , respectively. For one embodiment, virtual voice port  260  accepts control signals generated by physical ports  205   a – 205   n . Virtual voice port  260  converts the control signals into control signals used in a permanent call protocol. Thus, virtual voice port  260  provides VOPS  220  with a port for maintaining a PVC. For an alternative embodiment, virtual voice port  260  accepts voice packets generated by VOPS  220 . Virtual voice port  260  converts the voice packets into packets following a permanent call protocol. For another embodiment, virtual port  260  converts the control signals and voice packets to a FRF.11 protocol. For yet another embodiment, virtual port  260  converts the control signals and voice packets to real time protocols (“RTP”) including, but not limited to, a voice over Internet protocol (“VoIP”) using a H.323 protocol. 
   As previously described, call management  226  is coupled to physical ports  205   a – 205   n , virtual port  260 , and routing system  225 . Call management  226  provides configuration management for VOPS  220 . In particular, call management  226  generates the setup messages used in SVCs. Call management  226  also determines the access of physical port  205   a – 205   n  to routing system  225 . 
   For another embodiment, a pair of virtual voice ports is used to provide a conversion mechanism between two different PVC protocols. Specifically, a VOP system with a first virtual voice port is used to receive data on a first PVC. Subsequently, the VOP system converts the incoming data to a different PVC protocol and transfers the output of the first virtual port to a second virtual voice port. For one embodiment, the second voice port is coupled to a second PVC. Thus, the VOP system provides a conversion mechanism between two different PVC protocols. 
   For one embodiment, virtual voice port  260  provides VOPS  220  with multiple functions. These functions comprise maintaining a permanent call connection between VOPS  220  and a remote node, connecting a permanent call to a switched call, and—in the case of a second virtual voice port included in VOPS  220 —providing a data conversion mechanism between two different permanent call protocols. Virtual voice port  260  allows VOPS  220  to perform these functions without reducing the number of physical ports  205   a – 205   n  available for switched or permanent call connections. The functions are described below. 
   Maintaining a Permanent Call Connection 
   For one embodiment, a permanent call connection between VOPS  220  and a remote node is maintained through virtual voice port  260 . In particular, virtual voice port  260  is assigned a number and a permanent point-to-point call is configured between virtual voice port  260  and the remote node. For example, for one embodiment, a FRF.11 protocol is setup between virtual voice port  260  and node  240 . The FRF.11 protocol allows both node  240  and virtual voice port  260  to continuously transmit signaling state packets across network  230 . These packets include, but are not limited to, on-hook and off-hook signals. For one embodiment, the on-hook and off-hook signals are used to initiate a transmission across the permanent call connection. The permanent call connection also provides a compressed audio or data path between virtual voice port  260  and node  240 . For alternative embodiments, a VoIP H.323 protocol is setup between virtual voice port  260  and node  240 . 
   Following the previous example, the permanent call connection between virtual voice port  260  and node  240  provides a remote presence on VOPS  220 . Specifically, the continuous communication between virtual voice port  260  and node  240  emulates a system in which node  240  is existent on VOPS  220 . For one embodiment, node  240  comprises a PBX, a physical port, or a live operator. For an alternative embodiment, node  240  comprises a virtual voice port. Thus, virtual voice port  260  provides a permanent call connection between VOPS  220  and a secondary virtual voice port. 
   To maintain a permanent call connection, virtual voice port  260  is coupled to routing system  225 .  FIG. 3  illustrates one embodiment of a virtual voice port coupled to a routing system. In particular, system  300  comprises a virtual voice port (“VVP”)  310  coupled to network interface (“NI”)  340  via packet routing  320  and packet encapsulation  330 . For one embodiment, system  300  is used in system  200 . Accordingly, packet routing  320  selects a digitized payload from either VVP  310  or physical ports  205   a – 205   n . The selected digitized payload is transferred to packet encapsulation  330 . In packet encapsulation  330 , packets are generated from the digitized payload. Additionally, in packet encapsulation  330  packet addressing information and packet headers are appended to the generated packets. Subsequent to packet generation, the packets are transferred to network interface (“NI”)  340  for transmission over a network. For one embodiment, the network comprises an ATM network. Thus, packet encapsulation  330  generates packets based on the protocol of the ATM network. For another embodiment, the network comprises a Frame Relay network. Accordingly, packet encapsulation  330  generates packets based on the protocol of the Frame Relay network. 
   As illustrated in  FIG. 3 , VVP  310  is also directly coupled to NI  340 . The direct coupling allows VVP  310  to maintain a permanent call via NI  340 . For example, for one embodiment, NI  340  is coupled to both a PVC that uses a FRF.11 protocol and an ATM network. Thus, both packet routing  320  and packet encapsulation  330  are used to format switch call data for transmission from physical ports (not shown) to the ATM network. The direct coupling between VVP  310  and NI  340 , however, allows VVP  310  to emulate a destination end-point. Specifically, the direct coupling between VVP  310  and NI  340  allows VVP  310  to transmit and receive FRF.11 formatted data along the PVC while bypassing packet routing  320  and packet encapsulation  330 . For alternative embodiments, the direct coupling between VVP  310  and NI  340  allows VVP  310  to transmit and receive permanent call formatted data. 
     FIG. 4  illustrates one embodiment of a virtual voice port used to emulate a destination end-point. In particular, virtual voice port (“VVP”)  400  comprises a voice over packet encapsulation (“VOPE”)  405  coupled to translation block  406 . For one embodiment, VOPE  405  transmits and receives packets following a permanent call protocol. Specifically, VOPE  405 , adds packet addressing information and packet headers to the packets generated by translation block  406 . For another embodiment, translation block  406  emulates a physical interface capable of accepting a switched call. Specifically, translation block  406  accepts the switched call control signals and voice packets over lines  450  and  460 , respectively. Instead of effectuating the control signals or transmitting the voice packets, however, translation block  406  converts the switched call data to a permanent call protocol and transfers the data to VOPE  405 . Alternatively, translation block  406  receives permanent call data from VOPE  405  and generates switched call format control signals and voice packets via lines  450  and  460 , respectively. 
   For one embodiment, VVP  400  is used as the virtual voice port of VOPS  220 . Accordingly, signal line  470  correlates to line  273 . Signal line  450  correlates to line  272  and signal line  460  correlates to line  274 . Furthermore, as illustrated in  FIG. 3 , the virtual voice port is directly coupled to the network interface of routing system  225 . Thus, VOPE  405  is directly coupled to network  230  via line  273  and the network interface of routing system  225 . 
   The direct coupling to network  230  allows VOPE  405  to maintain a permanent call connection. Translation block  406 , however, provides VOPS  220  with a switched call interface to VVP  400 . Thus, VVP  400  allows VOPS  220  to maintain a permanent call connection on network  230  while allowing physical ports  205   a – 205   n  to maintain a switched call connection. 
   Connecting a Permanent Call to a Switched Call 
   Virtual voice port  260  allows VOPS  220  to connect a permanent call to a switched call. The connection between a permanent call and a switched call occurs in two forms, an incoming permanent call received by virtual voice port  260  and outgoing switched call generated by any one of phones  210 – 21 N. For one embodiment, to receive an incoming permanent call, virtual voice port  260  transfers the incoming permanent call to a preconfigured physical port. For another embodiment, the permanent call follows a FRF.11 Annex A dual tone multi-frequency (“DTMF”) digit-relay syntax. Accordingly, virtual voice port  260  examines the incoming permanent call data and determines a physical port based on the digits specified in the DTMF digit relay packets. For yet another embodiment, virtual voice port  260  is coupled to a DSP (not shown). Thus, virtual voice port  260  is operable to detect DTMF digits included in compressed voice packets. Accordingly, virtual voice port  260  determines a physical port based on the digits included in the compressed voice packet. 
     FIG. 5  shows one embodiment of a flow chart illustrating a permanent call connected to a switched call. In particular, flow chart  500  includes blocks  510  through  560 . For one embodiment, the blocks show the steps used by VVP  400  to connect a permanent call, initiated by node  240 , to a physical port of VOPS  220 . As illustrated in  FIG. 5 , operation begins in block  510 . At block  510 , node  240  initiates a permanent call by transmitting control packets to VOPE  405 . For one embodiment, node  240  transmits off-hook packets to initiate the permanent call. For another embodiment, node  240  transmits packets according to a FRF.11 protocol. For an alternative embodiment, node  240  transmits packets according to a VoIP protocol. 
   The control packets transmitted by node  240  are received in block  520 . At block  520 , however, the control packets have not been processed by VVP  400 . Thus, at block  520  VVP  400  transmits on-hook packets to node  240 . For one embodiment, translate  410  generates the off-hook packet. Subsequently, VOPE  405  transmits the off-hook packets every 20 milli-seconds (“ms”). For an alternative embodiment, VOPE  405  transmits packets according to a FRF.11 protocol. For another embodiment, VOPE  405  transmits packets according to a VoIP protocol. 
   At decision block  530 , VVP  400  processes the control packets transmitted by node  240 . Specifically, VVP  400  uses translate  410  and voice compression conversion sub-system (“VCCS”)  415  to determine a destination point for the permanent call initiated by node  240 . For example, for one embodiment, physical port  205   a  is a preconfigured destination point for the incoming permanent call. Thus, subsequent to receiving the control packets, VVP  400  initiates a call setup message requesting that call management  226  route the call from VVP  400  to physical port  205   a . In particular, translate  410  generates an off-hook signal. The off-hook signal is routed to call management  226  via telephony protocol  420 . Call management  226  responds to the off-hook signal with a dial tone indicating that routing system  225  is available to route the call. In response to the dial tone, translate  410  generates a sequence of digits mapped to physical port  205   a . Physical port  205   a , in turn, transmits a response to telephony protocol  420  that includes a ringing, busy, or connect signal. Provided a connect signal is received from physical port  205   a , block  540  is processed. If a busy or ringing signal is received from physical port  205   a , however, block  520  is re-processed. 
   For another embodiment, the control packets include specific packets that follow a DTMF digit-relay syntax. Accordingly, VCCS  415  examines the incoming permanent call data and identifies the DTMF digit-relay control packets. Using the DTMF digits in the DTMF digit-relay control packets, VVP  400  initiates a call setup message request with call management  226 . Specifically, VVP  400  uses the DTMF digits during the call setup to identify a physical port. Subsequently, call management  226  routes the call from VVP  400  to the identified physical port. Provided a connect signal is received from the physical port, block  540  is processed. If a busy or ringing signal is received from the physical port, however, block  520  is re-processed. 
   For yet another embodiment, the incoming permanent call comprises DTMF digits included in a compressed voice packet. VVP  400  uses a DSP (not shown) to decode the compressed voice packets, thus isolating the DTMF digits. Using the DTMF digits, VVP  400  initiates a call setup message requesting that call management  226  route the call from VVP  400  to the physical port corresponding to the DTMF digits. Provided a connect signal is received from the physical port, block  540  is processed. If a busy or ringing signal is received from the physical port, however, block  520  is re-processed. 
   At block  540 , VVP  400  generates an off-hook signal indicating that VOPS  220  is available to receive data. In particular, translate  410  generates off-hook packets that are transmitted to node  240  via VOPE  405  and line  470 . For one embodiment, VOPE  405  transmits off-hook packets every 20 milli-seconds (“ms”). For an alternative embodiment, VOPE  405  transmits packets according to a FRF.11 protocol. For another embodiment, VOPE  405  transmits packets according to a VoIP protocol. 
   At block  550 , VVP  400  receives the call data from node  240 . As previously described, node  240  transmits data following a permanent call protocol. Thus, at block  550 , VCCS  415  converts the permanent call data to a switched call format. For example, for one embodiment, the node  240  transmitted data comprises voice packets having a voice payload and transport specific headers including, but not limited to, frame relay (“FR”), ATM, or transmission control protocol/internet protocol (“TCP/IP”). VCCS  415  replaces the header information of the voice packets with a switched call header format used by VOPS  220 . Thus, allowing call management  220  to route data from VVP  400  to the physical port identified in decision block  530  using a switched call format. For another embodiment, the node  240  transmitted data comprises voice packets having a voice payload and voice protocol specific headers including, but not limited to, FRF.11, VoIP, or H.323. Accordingly, VCCS  415  replaces the header information of the voice packets with a switched call header format used by VOPS  220 . Thus, allowing call management  220  to route data from VVP  400  to the physical port identified in decision block  530 . 
   At decision block  560 , VVP  400  determines whether the permanent call from node  240  has been terminated. For one embodiment, the call is terminated by node  240  transmitting on-hook packets. For another embodiment, the call is terminated by VOPS  220 . For yet another embodiment, the call is terminated by the physical port identified in decision block  530 . Provided the call is terminated, block  520  is processed. If the call remains active, however, block  550  is re-processed. 
     FIG. 6 , shows one embodiment of a flow chart illustrating a switched call connected to a permanent call. In particular, flow chart  600  includes blocks  610  through  670 . For one embodiment, the blocks show the steps used by VOPS  220  to connect one of physical ports  205   a – 205   n  to VVP  400 . As previously described, VVP  400  is used to maintain a permanent call between VOPS  220  and a remote node. Thus, the connection of one of physical ports  205   a – 205   n  to VVP  400  results in one of physical ports  205   a – 205   n  placing a permanent call. 
   As illustrated in  FIG. 6 , operation begins in block  610 . At block  610 , a physical port of VOPS  220  initiates a switched call by transmitting an off-hook signal to call management  226 . The off-hook signal is routed to call management  226  via line  271 . At decision block  620 , call management  226  responds to the off-hook signal. In particular, if call management  226  is busy, call management  226  generates a busy signal and block  620  is re-processed. If call management  226  is available, however, block  630  is processed. 
   At block  630 , call management  226  generates a dial tone to indicate that routing system  225  is available to route the switched call. In response to the dial tone, at block  640 , the physical port initiates a call setup message requesting that call management  226  route the call from the physical port to VVP  400 . For one embodiment, the setup message comprises the physical port dialing a sequence of digits corresponding to VVP  400 . 
   At block  650 , VVP  400  responds to the call setup message from call management  226 . For one embodiment, VVP  400  is busy. Thus, at block  650 , telephony protocol  420  generates a busy signal and block  650  is re-processed. If VVP  400  is available, however, block  660  is processed. 
   At block  660 , VVP  400  translates the call management  226  setup message into a permanent call format. In particular, in response to the call management  226  off-hook signal, translate  410  generates off-hook packets for transmission by VOPE  405 . For one embodiment, VOPE  405  transmits packets indicating an off-hook every 20 milli-seconds (“ms”). For an alternative embodiment, VOPE  405  transmits packets according to a FRF.11 protocol. For another embodiment, VOPE  405  transmits packets according to a VoIP protocol. After the generation of the off-hook packets block  670  is processed. 
   At block  670 , VVP  400  transmits the call data received from the physical port of VOPS  220 . As previously described, VVP  400  transmits data following a permanent call protocol. Thus, at block  670 , VCCS  415  converts the switched call data to a permanent call format. Subsequently, the permanent call data is transmitted via VOPE  405  and line  470 . For one embodiment, VCCS  415  converts the switched call data to permanent call formats including, but not limited to, FRF.11, VoIP, or H.323. 
   Data Conversion Between Two Different Permanent Call Protocols 
   The virtual voice port may also be used to couple two different permanent call networks. In particular, a voice over packet system with two virtual voice ports may be used as a connection point between two different permanent call protocols. Thus, the voice over packet system provides a data conversion mechanism between two different protocols. 
     FIG. 7 , illustrates one embodiment of a voice over packet system using two virtual voice ports to perform a data conversion between different permanent protocols. In particular, system  700  comprises a network  715  coupled to VOPS  710  via VVP  720 . VOPS  710  is also coupled to network  745  via VVP  740 . Furthermore, VVP  720  and VVP  740  are coupled via call management  726 . 
   For one embodiment, data is transferred from network  715  to network  745 . Accordingly, VOPS  710  provides a communication media that transfers data between the two different networks. Specifically, the VCCS of VVP  720  replaces the header information of the voice packets transmitted by network  715  with a switched call header format. The conversion to the switched call header format allows call management  726  to route the voice packets from VVP  720  to VVP  740 . Subsequently, the VCCS of VVP  740  replaces the switched call header information of the voice packets with the header information used by network  745 . Subsequently, VVP  740  transmits the voice packets to network  745 . For one embodiment, network  715  operates using a FRF.11 protocol. For an alternative embodiment, network  745  operates using a VoIP protocol. 
   In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. For example, for one embodiment it is contemplated that virtual voice port  260  comprises a software algorithm that emulates a physical port on VOPS  220 . It will, however, be evident that various modifications and changes may be made thereof without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.