Technique for providing translation between the packet environment and the PSTN environment
Voice over Internet Protocol (VoIP) calls received in a Hybrid Fiber Coax (HFC) network (12) maintained by a provider of HFC VoIP telephony services are advantageously translated into a Time-Division Multiplex (TDM) format by an Internet Protocol Device Terminal (IPDT) (26) in the HFC network. Once translated into a TDM format, the call passes to the Public Switched Telephone Network (PSTN) (28) for call processing to afford the call features subscribed to by the called party, such as caller-ID and call waiting. Once processed, the PSTN routes the call to the destination. Likewise, a call destined for an HFC VoIP customer can be processed within the PSTN to afford the call features subscribed to by the HFC VoIP customer. In this way, the HFC VoIP telephony service can offer full-featured VoIP cable telephony without the need to perform call processing in its own network.
Latest AT&T Patents:
- CONGESTION-AWARE TRAFFIC MANAGEMENT USING HISTORICAL LOAD DATA AND REAL-TIME CELL MAPPING
- METHOD AND APPARATUS FOR EXTENDING WIRELESS COVERAGE WITH ONE OR MORE AUTONOMOUS DEVICES
- APPARATUSES AND METHODS FOR FACILITATING AN ADAPTIVE, APPLICATION AND SERVICE-AWARE HARQ
- SYSTEM AND METHOD FOR NEGOTIATION AND PERMANENCE MANAGEMENT OF METAVERSE MASHUPS
- SYSTEM AND METHOD OF SECURING ALLOCATION OF NETWORK FUNCTIONS FOR SESSION SLICES
This invention relates to a technique for translating information passing between a packet network and a Time-Division Multiplexed (TDM) network, such as a Public Switched Telephone Network (PSTN).
BACKGROUND ARTTraditionally, telephone subscribers received local service (i.e., dial tone) from a Local Exchange Carrier (LEC), typically operated by a Regional Bell Operating Company (RBOC) or an independent telephone carrier. In many geographic areas, telephone subscribers may now receive local telephone service from their provider of cable television services.
In order to attract subscribers, cable television service providers must offer telephony service comparable to that currently available from a LEC. In other words, the cable telephony service available from the cable television provider should offer a comparable array of features, such as Caller Identification, Call Waiting and Voice Mail, to name a few, that are available to subscribers of traditional local telephony service. In practice, LEC-based subscribers receive special-featured local telephony service via a central office switch programmed to provide such features, such as a Lucent 5ESS® switch manufactured by Lucent Inc, Murray Hill, N.J. Some cable television service providers also employ traditional central office telephone switches on their own premises to offer analog cable telephony with comparable features.
Currently, there is a trend by cable television service providers to offer Voice-over-Internet Protocol (VoIP) telephony service via the provider's Hybrid Fiber-Coax (HFC) network. In order to provide a full array of features to subscribers of these HFC VoIP telephony services, cable television service providers have had to provide the necessary call processing features in their own networks usually by way of an IP-Soft Switch, often at significant expense.
Thus, there is a need for a technique that affords a cable television service provider the ability to offer fully-featured VoIP telephony service yet avoids the need to perform the requisite call processing in the cable television service provider's own network.
BRIEF SUMMARY OF THE INVENTIONBriefly, in accordance with a preferred embodiment of the invention, a method is provided for offering full-featured Voice-over Internet Protocol (VoIP) telephony service. In accordance with the method, a first network, typically a Hybrid-Fiber Coax (HFC) network maintained by a provider of cable television services, receives an incoming packet-based VoIP call from a subscriber. Within the first network, the packet-based VoIP call is translated into a Time-Division-Multiplexed (TDM)-based call compatible with a TDM-based second network, such as the Public Switched Telephone Network (PSTN). In connection with such translation, signaling protocol support functions are performed in the first network, typically at an Internet Protocol Digital Terminal (IPDT), to enable the first network, and particularly, a Broadband Telephony Interface (BTI) in the first network that receives customer calls, to act as if the first (HFC) network were performing call processing features that would otherwise require an IP Soft switch or similar call processing mechanism. The first network routes the call to the second network (i.e., the PSTN), while at the same time, the first network maps IP signaling information into a format compatible with switching equipment within the second network to allow that network to perform call processing to afford the desired call features. Thereafter, the second network routes the call to its destination, which may lie within the first or second networks. If the call destination lies within the first network, the second network returns the call back to the first network for translation back to the VoIP format. Otherwise, if the destination lies within the second network, the call is routed with no further translation.
In the illustrated embodiment, the network 12 comprises a Hybrid Fiber-Coax (HFC) network of the type maintained by a provider of cable television service. An HFC plant 20 connects the BTI 18 to a Cable Modem Termination System/Edge Router (CMTS/ER) 22 such that the link between the BTI and the CMTS/ER complies with the Data Over Cable System Interface Specification (DOCSIS). The CMTS/ER 22 separates packet-based VoIP calls originated at the customer-premises from one of the telephone sets 161-16n at the customer premises 14, from data traffic originated from the data communications device 17. The CMTS/ER 22 routes the data traffic to an IP backbone network 24 for routing to a provider of data services (not shown), such as an Internet Services Provider (ISP).
In accordance with the invention, the CMTS/ER 22 routes VoIP calls originated at the BTI 18 to an Internet Protocol Digital Terminal (IPDT) 26 described in greater detail hereinafter with respect to
As discussed in greater detail in connection with the signaling flows depicted in
Within the PSTN 28 is at least one central office switch (Local Digital Switch or LDS), exemplified by switch 30, such as the Lucent 5ESS® central office switch. It is the central office switch 30 (or if necessary, a combination of central office switches if the ingress switch lacks the requisite call processing ability) that processes the call translated by the IPDT 26. Thus, call processing occurs within the PSTN 28 at the switch 30 rather than in the network 12.
Performing call processing in the PSTN 28, in accordance with the invention, rather than in the network 12 affords several advantages. First and foremost, utilizing the PSTN 28 to perform call processing avoids the need to provide the necessary call-processing infrastructure within the HFC network 12 itself, such as by way of an IP-Soft switch or similar call processing mechanism. Moreover, the switch 30 within the PSTN 28 will already possess the requisite hardware and software needed to perform a full array of calling features. Such switches will typically support a full set of CLASSSM (a service mark of Telcordia, Inc, Piscataway, N.J.), custom calling and Centrex features, such as Caller ID with Call Waiting for example, since this switch provides such features to present-day POTS customers served by the PSTN 28. In accordance with the present invention, the IPDT 26 translates a VoIP call to a TDM format, and performs the signaling protocol support functions and the required mapping to allow routing of the call to the PSTN 28 for processing. In this way, the network 12 can offer the same features on a VoIP call as are offered in the PSTN 28 for a POTS call, without the need for any IP-Soft switch or the like.
To best understand the manner in which calls are processed in accordance with the invention,
-
- 1. A customer at one of the telephone sets 161-16n lifts the handset to connect to an idle line.
- 2. The BTI 18 of
FIG. 1 senses the off-hook condition and thereafter notifies the IPDT 26 ofFIG. 1 of this event (via a NTFY message), indicating the IP address and port number (indicative of which of its lines is now off-hook) of the BTI 18. - 3. Upon receipt of this notification, the IPDT 26 sends an acknowledgement to the BTI 18 (via a 200 OK message).
- 4. The IPDT 26 then maps the received BTI IP address and line number into the IPDT Interface Group and Call Reference Value (IG/CRV) on the GR-303 interface to the switch 30 of
FIG. 1 within the PSTN 28. The IPDT 26 requests a connection to the switch 30 for this call, indicating the derived Call Reference Value, by sending a SETUP message on the specific Interface Group assigned to the BTI 18. - 5. On receipt of the SETUP message, the switch 30 of
FIG. 1 determines if it is able to process the call and whether an idle channel (DSO) is available on this Interface Group. - 6. If the switch 30 is able to handle the new call, it indicates to the IPDT 26 that it is ready to proceed, using GR-303 Time-slot Management Channel (TMC) signaling. The switch 30 of
FIG. 1 then selects an idle DS0 within the Interface Group and notifies the IPDT 26 which DS0 to use for this call (via a CONNECT message). - 7. If the switch 30 is unable to handle the new call, or if no DS0 is available, the switch notifies the IPDT 26 (via a RELEASE COMPLETE message). The IPDT 26 will notify the BTI 18 (via a 400 REJECT message) and release resources for this call. Upon receipt of the 400 REJECT message, the BTI 18 will play fast busy tone to the customer, ending the call.
- 8. Upon receipt of a CONNECT message, the IPDT 26 requests the BTI 18 to create a connection (via a CRCX message). Included in this request is an instruction for the BTI 18 to notify the IPDT 26 when the BTI subsequently detects either an off-hook or an on-hook event, along with the IPDT port number to be used for this call.
- 9. On receipt of the request from the IPDT 26 to create a connection, the BTI 18 requests the CMTS/ER 22 to provide resources (i.e., bandwidth) for this call (via the DOCSIS protocol).
- 10. If the requested bandwidth is granted by the CMTS/ER 22 (as allocated via a DOCSIS unsolicited grant), the BTI 18 informs the IPDT 26 which BTI port number will be used for this call (via a 200 OK message). A media path (Real Time Protocol (RTP) stream) is now established between the assigned ports on the BTI 18 and the IPDT 26.
- 11. If bandwidth is unavailable, the CMTS/ER 22 will reject the request and the BTI 18 will play fast busy to the customer, ending the call.
- 12. However, when the IPDT 26 knows that the BTI 18 has been allocated bandwidth for the call, the IPDT signals to the switch 30 of
FIG. 1 that the calling party is off-hook (using GR-303 TMC signaling) and acknowledges the DS0 assignment (via a CONNECT ACK message). Upon notification that the calling party is off-hook, the switch 30 ofFIG. 1 provides dial tone to indicate its readiness to handle the call. If the customer has subscribed to a voice mail service and has a message waiting, the switch 30 ofFIG. 1 will apply stutter dial tone. - 13. Upon hearing dial tone, the customer enters the telephone number of the desired called party.
- 14. Since an RTP bearer path has been established between the BTI 18 and the switch 30 of
FIG. 1 , the customer-entered digits are passed in-band to the switch, as they are entered, one-by-one. Note that all the local-switch-based capabilities are available to the caller at this point. - 15. The switch 30 of
FIG. 1 processes the dialed digits and proceeds to set up the call through the PSTN 28. - 16. Upon receipt of far-end answer supervision, the switch 30 of
FIG. 1 notifies the IPDT 26 that the called party has answered (using GR-303 TMC signaling). - 17. A two-way, end-to-end call path is now established and conversation can commence.
-
- 1. A call destined for one of the telephones 161-16n at the HFC VoIP customer's premises 14 arrives at the switch 30 of the PSTN 28 associated with that customer.
- 2. Upon receipt of the incoming call, the switch 30 of
FIG. 1 determines the Interface Group and Call Reference Value corresponding to the received Called Party Number. The switch 30 ofFIG. 1 then (1) notifies the IPDT 26 that it wishes to initiate a call over this Interface Group (using GR-303 TMC signaling); (2) selects an idle channel DS0; and (3) notifies the IPDT 26 which DS0 will be used for this call (via a SETUP message). - 3. On receipt of the SETUP message, the IPDT 26 determines whether its internal cache has a valid mapping for the received Call Reference Value for this Interface Group (IG/CRV). The IPDT 26 will not have a valid mapping if, for example, this BTI 18 has not previously received an incoming call, or if the lease on its assigned IP address has expired.
- 4. If the IPDT 26 has a valid mapping, the IPDT determines the IP address currently assigned to the called party's BTI 18.
- 5. If the IPDT 26 does not have the IG/CRV mapping in its cache, it maps the IG/CRV value to the called party's Fully Qualified Domain Name (FQDN). The association between an IG/CRV value and an FQDN/BTI port number is pre-provisioned in the IPDT 26.
- 6. The IPDT 26 then queries its Domain Name Server (DNS) (not shown), which returns the IP address and line number of the BTI 18 associated with the specified FQDN. The returned value will be stored in the IPDT 26's internal cache for future calls.
- 7. Upon determining the IP address of the BTI 18, the IPDT 26 requests the BTI to create a connection (via a CRCX message). Included in this request is the BTI 18 line number to which the call is destined.
- 8. On receipt of the request to create a connection, the BTI 18 requests the CMTS/ER 22 to provide resources (i.e., bandwidth) for this call (via the DOCSIS protocol).
- 9. If the requested bandwidth is granted by the CMTS, the BTI 18 informs the IPDT 26 which BTI port number will be used for this call (via a 200 OK message). A media path (RTP stream) is now established between the assigned ports on the IPDT 26 and the BTI 18.
- 10. If bandwidth is unavailable, the CMTS will reject the request. The BTI 18 will notify the IPDT 26, which in turn informs the switch 30 of
FIG. 1 via a RELEASE COMPLETE message. - 11. Once the IPDT 26 knows that the BTI 18 has been allocated bandwidth for the call, the IPDT signals to the switch 30 of
FIG. 1 that the called party is on-hook (using GR-303 TMC signaling) and conforms the DS0 assignment (via a CONNECT message). - 12. Upon notification that the called party is on-hook, the switch 30 of
FIG. 1 instructs the IPDT 26 to “ring” the called party's telephone line (using GR-303 TMC signaling). The switch 30 ofFIG. 1 will control the specific ringing pattern to be used. This enables the switch 30 ofFIG. 1 to apply, for example, the Distinctive Ringing feature. - 13. The IPDT 26 passes the ringing instruction (and ringing pattern) to the BTI 18 in-band.
- 14. On receipt of and for the duration of the ringing instruction, the BTI 18 applies power ringing on the line associated with the called number.
- 15. If the called party has subscribed to any of the Caller ID features, the switch 30 sends the calling party's telephone number and/or name in-band between the first and second ring cycle. Note that if the calling party's number/name is unavailable or if this information is marked private, an appropriate indication will be provided.
- 16. Upon hearing ringing, the called party answers the telephone.
- 17. Upon detection of the off-hook event, the BTI 18 stops power ringing and notifies the IPDT 26 by transmitting an off-hook signal in the RTP stream.
- 18. The IPDT 26 in turn will notify the switch 30 of
FIG. 1 (via GR-303 TMC signaling). - 19. A two-way, end-to-end call path is now established and conversation can commence.
-
- 1. The HFC VoIP Telephony customer hangs up the handset, or depresses the switch hook (with the intent of terminating the current call).
- 2. Upon detection of the on-hook event, the BTI 18 will notify the IPDT 26 by transmitting an on-hook signal in the RTP stream.
- 3. The IPDT 26 in turn will notify the switch 30 of
FIG. 1 (via GR-303 TMC signaling). - 4. After a brief time-out period (if applicable), the switch 30 of
FIG. 1 will interpret and process the on-hook event as a request to terminate the call. A brief timeout period is required for customers subscribed to a Call Waiting feature in order for the switch 30 ofFIG. 1 to distinguish between a flash-hook (an on-hook, off-hook sequence) from an actual on-hook event. For customers who are not subscribed to Call Waiting, this timeout period is not required. - 5. If the HFC VoIP customer didn't initiate the call (i.e., this customer is the called party), the switch 30 of
FIG. 1 will apply Timed Release Disconnect treatment. Timed Release Disconnect treatment allows a called party to hang up for a short period (typically a maximum of 12 seconds) and then pick up again, without disconnecting the call (provided the caller stays off-hook). This enables a called party to, for example, continue the call in a different room. - 6. Upon expiration of the Timed Release Disconnect interval, or immediately if this call was initiated by the HFC VoIP customer, the switch 30 sends a DISCONNECT message to the IPDT 26 (indicating a normal cause for termination). The switch 30 also sends an ISUP release (REL) message to any other PSTN switch involved in this call.
- 7. Upon receipt of the DISCONNECT message, the IPDT 26 requests the BTI 18 to delete the connection (via a DLCX message). Included in this request is an instruction for the BTI 18 to notify the IPDT 26 of any future off-hook event.
- 8. Upon receiving a delete connection request, the BTI 18 requests the CMTS/ER 22 to release resources for this call, via the DOCSIS protocol.
- 9. When the resources are released, the BTI 18 acknowledges the request from the IPDT 26 to delete the connection (via a 200 OK message).
- 10. Upon acknowledgement, the IPDT 26 sends a RELEASE message to the switch 30 of
FIG. 1 (indicating a normal cause for release). - 11. The switch 30 of
FIG. 1 in turn responds to the IPDT 26 with a RELEASE COMPLETE message, thereby completing the release of all the resources associated with this call.
-
- 1. The far-end customer hangs up the handset, or depresses the switch hook (with the intent of terminating the current call).
- 2. Upon detection of the on-hook event, the far-end customer's local switch (not shown) will send an ISUP release (REL) message across the PSTN 28 to the near-end switch (e.g., switch 30 of
FIG. 1 ) associated with the customer premises 14, either immediately if the far-end customer initiated this call, or after the Timed Release Disconnect interval if the far-end customer did not initiate the call. - 3. Upon receipt of the ISUP release message from the PSTN 28, the switch 30 of
FIG. 1 will inform the IPDT 26 via a DISCONNECT message (indicating a normal cause for release). - 4. Upon receipt of the DISCONNECT message, the IPDT 26 instructs the BTI 18 to delete the connection (via a DLCX message). The instruction includes a request for the BTI 18 to notify the IPDT 26 of any future off-hook event.
- 5. Upon receiving an instruction to delete the connection, the BTI 18 requests the CMTS to release resources for this call, via the DOCSIS protocol.
- 6. When the resources are released, the BTI 18 acknowledges the request of the IPDT 26's to delete the connection (via a 200 OK message).
- 7. Upon receipt of the acknowledgement from the BTI 18, the IPDT 26 sends a RELEASE message to the switch 30 of
FIG. 1 (indicating a normal cause for release). - 8. The switch 30 of
FIG. 1 , in turn, responds to the IPDT 26 with a RELEASE COMPLETE message, thereby completing the release of all the resources associated with this call. The switch 30 ofFIG. 1 also sends an ISUP release complete (RLC) message to any other PSTN switch involved in this call.
-
- 1. Upon receipt of an incoming call destined for the HFC VoIP customer, the switch 30 of
FIG. 1 transmits an in-band Subscriber Alerting Signal (SAS), also known as a. call waiting tone, followed by an in-band CPE Alerting Signal (CAS tone). - 2. Upon detection of the CAS tone, a Caller ID mechanism (not shown) associated with one of the telephones 161-16n of
FIG. 1 responds with an in-band acknowledgement, indicating its readiness to receive the Caller ID information. - 3. Upon receipt of this acknowledgement, the switch 30 of
FIG. 1 transmits the Caller ID information via in-band Frequency Shift Keying (FSK) signaling. - 4. If the customer wishes to talk with the new caller, the customer hangs up the handset or depresses the switch hook (with the intent of doing so only briefly, so as to indicate a flash-hook), or presses the “flash” key on the telephone. (Note that if the customer does not wish to talk to the new caller, the customer can ignore the Call Waiting tone and the new caller will continue to hear ringing (resulting in a “ring-no-answer” condition).
- 5. Upon detection of the on-hook event, the BTI 18 will notify the IPDT 26 by transmitting an on-hook signal in the RTP stream.
- 6. The IPDT 26 in turn will notify the switch 30 of
FIG. 1 of the on-hook event (via GR-303 TMC signaling). - 7. If the customer picks up the handset or releases the switch hook very quickly, before the switch 30 of
FIG. 1 has decided to release the call, or if the customer had pressed the flash key, the BTI 18 will notify the IPDT 26 by transmitting an off-hook signal in the RTP stream. - 8. The IPDT 26 in turn will notify the switch 30 of
FIG. 1 of the off-hook event (via GR-303 TMC signaling). - 9. The switch 30 of
FIG. 1 will interpret and process the on-hook/off-hook events as a flash-hook signal and invoke the appropriate feature (in this example, the Call Waiting feature). - 10. The customer continues to interact with the Call Waiting feature in the normal way.
- 1. Upon receipt of an incoming call destined for the HFC VoIP customer, the switch 30 of
-
- 1. The switch 30 of
FIG. 1 associated with the HFC VoIP customer receives notification from the voice mail platform (not shown) that the customer has a new voice mail message. - 2. Upon receipt of the notification, the switch 30 determines the Interface Group and Call Reference Value (IG/CRV) corresponding to the Called Party Number received from the voice mail platform. The switch 30 notifies the IPDT 26 that it wishes to initiate a call over this Interface Group (using GR-303 TMC signaling) selects an idle DS0 and notifies the IPDT 26, which DS0 will be used for this call (via a SETUP message).
- 3. On receipt of the SETUP message, the IPDT 26 determines whether its internal cache has a valid mapping for the received Call Reference Value for this Interface Group.
- 4. If the IPDT 26 has a valid mapping, the IPDT determines the IP address currently being used by the called party's BTI 18.
- 5. If the IPDT 26 does not have the IG/CRV mapping in its cache, it maps the IG/CRV value to the called party's FQDN. The IPDT 26 then queries its DNS server, which returns the IP address of the BTI 18 associated with the specified FQDN. The returned value will be stored in the internal cache of the IPDT 26 for future calls.
- 6. Upon determining the IP address of the BTI 18, the IPDT 26 requests the BTI to create a connection (via a CRCX message). The request includes the line number of the BTI 18 to which the call is destined.
- 7. If the requested bandwidth is granted by the CMTS/ER 22, the BTI 18 informs the IPDT 26 which BTI port number will be used for this call (via a 200 OK message). A media path (RTP stream) is now established between the assigned ports on the IPDT 26 and the BTI 18.
- 8. If bandwidth is unavailable, the CMTS/ER 22 will reject the request and the IPDT 26 will inform the switch 30 of
FIG. 1 via a RELEASE COMPLETE message, ending the signaling flow under this condition. The switch 30 ofFIG. 1 may re-attempt message delivery at a later time, as determined by the implementation of the voice mail feature. - 9. Once the IPDT 26 knows that the BTI 18 has been allocated bandwidth for the call, the IPDT signals to the switch 30 of
FIG. 1 that the called party is on-hook (using GR-303 TMC signaling) and confirms the DS0 assignment (via a CONNECT message). - 10. Upon notification that the called party is on-hook, the switch 30 of
FIG. 1 sends the message-waiting indicator to the BTI 18 via in-band FSK signaling. - 11. As soon as the message waiting indication has been sent, the “call” is torn down in the same manner as a PSTN-initiated call termination described with respect to
FIG. 6 .
- 1. The switch 30 of
-
- 1. A subscriber at one of the telephone sets 161-16n lifts the handset to connect to an idle line.
- 2. The BTI 18 of
FIG. 1 senses the off-hook condition and notifies the IPDT 26 of this event (via a NTFY message), indicating the address of the BTI 18 and which of its lines is now off-hook. - 3. Upon receipt of this notification, the IPDT 26 of
FIG. 1 sends an acknowledgement to the BTI 18 ofFIG. 1 (via a 200 OK message). - 4. If the IPDT 26 determines that it is unable to handle the call, then the IPDT signals the BTI 18, typically via an RQNT message. Thereafter, the BTI 18 sends a fast busy signal, or other suitable indication to the customer indicating the inability to complete a call. In response, the customer goes on-hook.
- 5.
As part of the above-described call signaling flows, the IP signaling information developed in the first network 12 includes on-hook and off-hook line status of the customer premises equipment (e.g., the telephone) that originated the call and the GR-303 format includes ABCD signaling bits, with the line status in the IP signaling information mapped to the equivalent line status in the ABCD signaling bits. Additionally, the IP signaling information may include a power ringing indication, and the GR-303 format includes the ABCD signaling bits, with the power ringing indication received via the ABCD signaling bits mapped to an equivalent power ringing indication in the IP signaling information.
The foregoing describes a technique for providing full-featured VoIP telephony service in an HFC network without the need for the network to employ switch resources to perform switch-based call processing.
The above-described embodiments merely illustrate the principles of the invention. Those skilled in the art may make various modifications and changes that will embody the principles of the invention and fall within the spirit and scope thereof.
Claims
1. A method for providing full-featured Voice-over Internet Protocol (VoIP) telephony service, comprising the steps of:
- receiving in a first network a packet-based VoIP call, wherein the first network is a Hybrid-Fiber Coax network;
- translating, within the first network, the VoIP call into a Time-Division Multiplexed (TDM) call compatible with a second network having a capability of processing TDM calls and providing at least one feature for the TDM call, the translating comprises sub-steps of (1) performing required signal processing protocols in the first network to allow the VoIP call to interact with the first network as if the first network was performing switch-based processing functions and (2) mapping IP signaling information developed in the first network into a format suitable for processing by the second network;
- routing the TDM call to the second network;
- processing the TDM call in the second network; and
- routing the TDM call to its intended destination.
2. The method according to claim 1 wherein the translating step includes translating the VoIP call into a bearer portion and a signaling portion.
3. The method according to claim 2 wherein the IP signaling information is mapped into a GR-303 format to include performance as well as functional call aspects to allow full-featured processing by the second network.
4. The method according to claim 3 wherein the IP signaling information includes on-hook and off-hook line status of customer premises equipment (CPE) on which the packet-based VoIP call originated, and the GR-303 format includes ABCD signaling bits, wherein the line status in the IP signaling information is mapped to an equivalent line status in the ABCD signaling bits.
5. The method according to claim 4 wherein the IP signaling information includes a power ringing indication, and the GR-303 format includes the ABCD signaling bits, wherein the power ringing indication received via the ABCD signaling bits is mapped to an equivalent power ringing indication in the IP signaling information.
6. The method according to claim 1 wherein the second network is a public switched telephone network.
7. The method according to claim 1 wherein the at least one feature includes at least one of: a CLASS feature, a custom calling feature, or a Centrex feature.
8. The method according to claim 1 wherein the routing step includes translating the TDM call back to a VoIP call if the destination lies in the first network.
9. A method for providing full-featured Voice-over Internet Protocol (VoIP) telephony service, comprising the steps of:
- receiving in a first network a packet-based VoIP call and a plurality of non-voice packets, wherein the first network is a Hybrid-Fiber Coax network;
- separating the non-voice packets from the VoIP call;
- routing the non-voice packets to a data network;
- translating, within the first network, the VoIP call into a Time-Division Multiplexed (TDM) call compatible with a second network having a capability of processing TDM calls and providing at least one feature for the TDM call, the translating comprises sub-steps of (1) performing required signal processing protocols in the first network to allow the VoIP call to interact with the first network as if the first network was performing switch-based processing functions and (2) mapping IP signaling information developed in the first network into a format suitable for processing by the second network;
- routing the TDM call to the second network;
- processing the TDM call in the second network; and
- routing the TDM call to its intended destination.
10. The method according to claim 9 wherein the translating step includes translating the VoIP call into a bearer portion and a signaling portion.
11. The method according to claim 9 wherein the IP signaling information includes a power ringing indication, and a GR-303 format that includes ABCD signaling bits, wherein the power ringing indication received via the ABCD signaling bits is mapped to an equivalent power ringing indication in the IP signaling information.
12. The method according to claim 9 wherein the IP signaling information includes on-hook and off-hook line status of customer premises equipment (CPE) on which the packet-based VoIP call originated, and the GR-303 format includes ABCD signaling bits, wherein the line status in the IP signaling information is mapped to an equivalent line status in the ABCD signaling bits.
13. The method according to claim 9 wherein the IP signaling information is mapped into a GR-303 format so as to include performance as well as functional call aspects to allow full-featured processing by the second network.
14. The method according to claim 9 wherein the second network is a public switched telephone network.
15. The method according to claim 9 wherein the at least one feature includes at least one of: a CLASS feature, a custom calling feature, or a Centrex feature.
16. The method according to claim 9 wherein the routing step includes translating the TDM call back to a VoIP format if the destination lies in the first network.
6661785 | December 9, 2003 | Zhang et al. |
6697357 | February 24, 2004 | Emerson, III |
6700884 | March 2, 2004 | Emerson, III |
6704305 | March 9, 2004 | Emerson, III |
6731649 | May 4, 2004 | Silverman |
6771953 | August 3, 2004 | Chow et al. |
6775269 | August 10, 2004 | Kaczmarczyk et al. |
6785301 | August 31, 2004 | Chapman et al. |
20020064152 | May 30, 2002 | Lemley et al. |
20030048772 | March 13, 2003 | Blum |
20030095542 | May 22, 2003 | Chang et al. |
20040213205 | October 28, 2004 | Li et al. |
- U.S. Appl. No. 60/253,691.
Type: Grant
Filed: Sep 28, 2001
Date of Patent: Dec 8, 2009
Assignee: AT&T Corp. (New York, NY)
Inventors: Ali Cherchali (Jackson, NJ), James Ehlinger (Colts Neck, NJ), Paul J Fellingham (Holmdel, NJ), Marius Jonas Gudelis (Matawan, NJ), Steven M Michelson (Freehold, NJ), James Yatsko (Raritan, NJ)
Primary Examiner: Jayanti K Patel
Assistant Examiner: Anthony Sol
Application Number: 09/966,492
International Classification: H04L 12/66 (20060101);