US20100220715A1 - Technique for providing translation between the packet environment and the pstn environment - Google Patents
Technique for providing translation between the packet environment and the pstn environment Download PDFInfo
- Publication number
- US20100220715A1 US20100220715A1 US12/632,728 US63272809A US2010220715A1 US 20100220715 A1 US20100220715 A1 US 20100220715A1 US 63272809 A US63272809 A US 63272809A US 2010220715 A1 US2010220715 A1 US 2010220715A1
- Authority
- US
- United States
- Prior art keywords
- network
- call
- voip
- signaling
- tdm
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
Definitions
- 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).
- TDM Time-Division Multiplexed
- PSTN Public Switched Telephone Network
- 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.
- LEC Local Exchange Carrier
- RBOC Regional Bell Operating Company
- telephone subscribers may now receive local telephone service from their provider of cable television services.
- LEC-based subscribers receive special-featured local telephony service via a central office switch programmed to provide such features as a Lucent 5ESS® switch manufactured by Lucent Inc, Murray Hill, N.J.
- Lucent 5ESS® switch manufactured by Lucent Inc, Murray Hill, N.J.
- VoIP Voice-over-Internet Protocol
- HFC Hybrid Fiber-Coax
- a method for offering full-featured Voice-over Internet Protocol (VoIP) telephony service.
- 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.
- 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).
- TDM Time-Division-Multiplexed
- 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.
- IPDT Internet Protocol Digital Terminal
- BTI Broadband Telephony Interface
- 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.
- IPDT Internet Protocol Digital Terminal
- BTI Broadband
- FIG. 1 depicts a block schematic diagram of a network architecture in accordance with a preferred embodiment of the invention for providing full-featured VoIP telephone service
- FIG. 2 depicts a block schematic diagram of an Internet Protocol Digital Terminal comprising part of the network architecture of FIG. 1 ;
- FIG. 3 depicts a signaling flow diagram for an outgoing call initiated from a Broadband Telephony Interface (BTI) comprising part of the architecture of FIG. 1 .
- BTI Broadband Telephony Interface
- FIG. 4 depicts a signaling flow diagram for an incoming call originated at a Public Switched Telephone Network and directed to Hybrid Fiber Coax (HFC) network both comprising part of the architecture of FIG. 1 ;
- HFC Hybrid Fiber Coax
- FIG. 5 depicts a signaling flow diagram associated with termination of a call at the BTI of FIG. 1 ;
- FIG. 6 depicts a signaling flow diagram associated with termination of a call at the PSTN of FIG. 1 ;
- FIG. 7 depicts a signaling flow diagram associated with providing Caller ID with Call Waiting service
- FIG. 8 depicts a signaling flow diagram associated with providing a message waiting indication
- FIG. 9 depicts a signaling flow diagram associated with an emergency (911) call
- FIG. 10 depicts a signaling flow diagram associated with a call attempt originated from the BTI of FIG. 1 when bandwidth in the HFC network is unavailable;
- FIG. 11 depicts a signaling flow diagram associated with a call attempt originated from the BTI of FIG. 1 when a network resource, other than the HFC network, is unavailable;
- FIG. 12 depicts a signaling flow diagram associated with a call attempt originated from the PSTN of FIG. 1 when bandwidth in the HFC network is unavailable;
- FIG. 13 depicts a signaling flow diagram associated with a first post-call permanent signal condition, such as when a customer does not hang up after the other party to the call has disconnected;
- FIG. 14 depicts a signaling flow diagram associated with a second post-call permanent condition, such as when a customer goes off-hook and does not enter any digits.
- FIG. 1 illustrates a network architecture 10 in accordance with a preferred embodiment of the invention for affording full-featured VoIP telephony service.
- the network architecture 10 includes a first network 12 for providing packet-based communications services to a customer premises 14 that includes one or more voice telephone sets, illustratively depicted by telephone sets 16 1 , 16 2 , 16 3 . . . 16 n where n is an integer greater than zero.
- the customer premises 14 may also include one or more data communications devices, such as a computer 17 .
- the network 12 includes a Broadband Telephony Interface (BTI) 18 typically situated at customer premises 14 .
- the BTI 18 enables each of the telephone sets 16 1 - 16 n to initiate VoIP calls to, and receive VoIP calls from the network 12 , provided that the customer subscribes to such service.
- BTI Broadband Telephony Interface
- the network 12 comprises a Hybrid Fiber-Coax (HFC) network of the type maintained by a provider of cable television service.
- 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).
- DOCSIS Data Over Cable System Interface Specification
- the CMTS/ER 22 separates packet-based VoIP calls originated at the customer-premises from one of the telephone sets 16 1 - 16 n 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).
- ISP Internet Services Provider
- the CMTS/ER routes VoIP calls originated at the BTI 18 to an Internet Protocol Digital Terminal (IPDT) 26 described in greater detail hereinafter with respect to FIG. 2 .
- IPDT Internet Protocol Digital Terminal
- the IPDT 26 advantageously translates the packet-based VoIP calls, which may include signaling information in a Media Gateway Control Protocol (MGCP) or in a Network-based Call Signaling (NCS) protocol, into a TDM-based bearer channel, and a signaling channel typically in the GR-303 format. Both the bearer and signaling channel are received at a TDM-based telecommunications network 28 , such as the Public Switched Telephone Network (PSTN).
- PSTN Public Switched Telephone Network
- the IPDT 26 performs signaling protocol support functions that allow the BTI 18 to interact with the HFC network 12 as if the HFC network performed the call processing itself via an IP-Soft switch or similar mechanism. Moreover, the IPDT 26 also maps IP signaling information from the CMTS/ER 22 associated with an originating call into a format useful for the PSTN 28 .
- LDS Local Digital Switch or LDS
- 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 .
- LDS Local Digital Switch
- switch 30 or if necessary, a combination of central office switches if the ingress switch lacks the requisite call processing ability
- 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.
- 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.
- 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 CLASS SM (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 .
- CLASS SM a service mark of Telcordia, Inc, Piscataway, N.J.
- 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.
- 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.
- FIG. 2 depicts a block schematic diagram of an illustrative embodiment of the IPDT 26 of FIG. 1 .
- the IPDT 26 includes a switching fabric 32 for routing traffic received via an IP interface 34 that supports a shared interface for voice and signaling traffic.
- the switching fabric 32 routes the traffic from the IP interface 34 onto a dual Ethernet Bus 36 for communication to a TDM switching module 38 .
- the TDM switching module 38 includes a TDM processor 40 that converts voice packets into TDM signals. Additionally, the TDM switching module 38 provides the necessary Digital Signal Processor (DSP) resources for compression if needed.
- DSP Digital Signal Processor
- a TDM bus 42 connects the TDM processor 40 to a TDM interface 42 that provides an external customer interface to the PSTN 28 of FIG. 1 through a PSTN interface 46 .
- a common control module 48 provides configuration, management control and monitoring of elements within the IPDT 26 through a Dual Peripheral Component Interconnect (PCI) bus 50 .
- PCI Dual Peripheral Component Inter
- FIGS. 3-14 depict exemplary signaling flows for various conditions.
- FIG. 3 there is shown the signaling flow for an outgoing call initiated from the BTI 18 .
- the signaling flow commences as follows:
- FIG. 4 illustrates the signaling flow for a call originating in the PSTN 28 that is dialed to one of the telephones 16 1 - 16 n .
- FIG. 5 depicts the signaling flow associated with termination of the call by the BTI 18 . This call termination flow applies regardless of which party initiated the call and applies to all calls except emergency (911) calls as discussed hereinafter.
- FIG. 6 illustrates the signaling flow associated with termination of a call by the PSTN 28 of FIG. 1 between a far-end customer (not shown) and the customer premises 14 of FIG. 1 . This call termination flow applies regardless of which party initiated the call.
- FIG. 7 illustrates the signaling flow associated with providing a HFC VoIP customer on an established call with notification of another incoming call along with the identity of the new caller (telephone number and/or name).
- the signaling flow only applies if the HFC VoIP customer has subscriber to the Caller ID with Call Waiting feature and commences when a new incoming call arrives at the switch 30 of FIG. 1 for a the HFC VoIP customer that is already on an established call.
- FIG. 8 depicts the signaling flow that occurs when a HFC VoIP Telephony customer subscribing to a voice mail service receives a notification of a new voice mail message, via the message-waiting indicator (not shown) on a suitably equipped device, such as one of the telephone sets 16 1 - 16 n .
- the message-waiting indicator only becomes activated when the caller is on-hook. If the customer is off-hook the indication will be delayed until after the customer has terminated the current call.
- the signaling flow is as follows:
- FIG. 9 depicts the signaling flow associated with delayed termination of an emergency call, such as a 911 call directed to an Emergency Services Application Platform (ESAP) (not shown) served by the PSTN 28 .
- An emergency (E-911) call is established just like any other call. Only the switch 30 of FIGS. 1 and E-911 ESAP are aware that a 911 call is in progress. The 911 call terminates in the same as any other BTI 18 -initiated call termination, as depicted in FIG. 5 , except for one important difference.
- the E-911 operator In order for the E-911 operator to gather sufficient information about the location of the caller, the call resources must remain “active” even after the caller hangs up. To keep the resources active, control of 911-calls is given to the E-911 operator.
- the switch 30 of FIG. 1 When the caller hangs up at the end of a normal (non-911) call, the switch 30 of FIG. 1 will automatically respond to the on-hook indication with a DISCONNECT message as described previously. However, on a 911 call, the switch 30 of FIG. 1 does not send back the DISCONNECT message until it receives an instruction to release from the E-911 operator.
- FIG. 10 depicts the signaling flow associated with an outgoing call attempt originated from a BTI, such as BTI 18 of FIG. 1 for which HFC bandwidth is unavailable.
- the first eight steps of the signaling flow is identical to the signaling flow depicted in FIG. 3 .
- the BTI 18 When insufficient bandwidth is detected, then, as illustrated in FIG. 10 , the BTI 18 notifies the IPDT 26 (typically via a 400 REJECT message) that insufficient bandwidth exists to make the call, and that the connection to the switch 30 of FIG. 1 can be released. In turn, the IPDT 26 notifies the switch 30 to complete a release. 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.
- IPDT 26 typically via a 400 REJECT message
- FIG. 11 depicts the signaling flow associated with an outgoing call attempt originated from a BTI, such as BTI 18 of FIG. 1 for which a resource other than HFC bandwidth, is unavailable.
- the signaling flow of FIG. 11 includes the steps of:
- FIG. 12 depicts the signaling flow associated with an incoming call attempt originated from the PSTN 28 for which bandwidth is unavailable in the HFC network 12 .
- the signaling flow of FIG. 12 includes the same steps as steps (1)-(7) described with respect to FIG. 4 .
- the BTI 18 upon determining insufficient bandwidth exists, notifies the IPDT 26 (typically via a 400 REJECT message) that insufficient bandwidth exists to make the call, and that the connection to the switch 30 of FIG. 1 can be released.
- the IPDT 26 notifies the switch 30 to complete a release.
- FIG. 13 depicts the signaling flow associated with a permanent signaling condition caused by the HFC VoIP customer failing to go on-hook (i.e., hang up) after the other party has gone on-hook.
- FIG. 13 includes substantially the same steps as the PSTN-initiated call termination signaling flow depicted in FIG. 6 , with the additional step of having the BTI generate an announcement and a howler tone (or other warning) to the customer to hang-up when the BTI detects that the customer has remained off-hook for more than a prescribed interval.
- FIG. 14 depicts the signaling flow associated with the permanent signaling condition occurring when the HFC VoIP customer goes off-hook, but fails to dial any digits.
- the signal flow of FIG. 14 includes the initial call set-up steps of (1)-(12) of FIG. 3 including the step of providing dial tone. If, after a prescribed time interval, the switch 30 of FIG. 1 fails to receive any dialed digits, then the switch sends a howler tone or other warning to the customer. Thereafter, the PSTN 28 terminates the call via steps depicted in the call signaling flow shown in FIG. 6 .
- 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.
Abstract
Description
- This application is a continuation of U.S. Ser. No. 09/966,492, filed Sep. 28, 2001, currently allowed and incorporated by reference in its entirety.
- 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).
- Traditionally, 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 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 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 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.
- Briefly, 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.
-
FIG. 1 depicts a block schematic diagram of a network architecture in accordance with a preferred embodiment of the invention for providing full-featured VoIP telephone service; -
FIG. 2 depicts a block schematic diagram of an Internet Protocol Digital Terminal comprising part of the network architecture ofFIG. 1 ; -
FIG. 3 depicts a signaling flow diagram for an outgoing call initiated from a Broadband Telephony Interface (BTI) comprising part of the architecture ofFIG. 1 . -
FIG. 4 depicts a signaling flow diagram for an incoming call originated at a Public Switched Telephone Network and directed to Hybrid Fiber Coax (HFC) network both comprising part of the architecture ofFIG. 1 ; -
FIG. 5 depicts a signaling flow diagram associated with termination of a call at the BTI ofFIG. 1 ; -
FIG. 6 depicts a signaling flow diagram associated with termination of a call at the PSTN ofFIG. 1 ; -
FIG. 7 depicts a signaling flow diagram associated with providing Caller ID with Call Waiting service; -
FIG. 8 depicts a signaling flow diagram associated with providing a message waiting indication; -
FIG. 9 depicts a signaling flow diagram associated with an emergency (911) call; -
FIG. 10 depicts a signaling flow diagram associated with a call attempt originated from the BTI ofFIG. 1 when bandwidth in the HFC network is unavailable; -
FIG. 11 depicts a signaling flow diagram associated with a call attempt originated from the BTI ofFIG. 1 when a network resource, other than the HFC network, is unavailable; -
FIG. 12 depicts a signaling flow diagram associated with a call attempt originated from the PSTN ofFIG. 1 when bandwidth in the HFC network is unavailable; -
FIG. 13 depicts a signaling flow diagram associated with a first post-call permanent signal condition, such as when a customer does not hang up after the other party to the call has disconnected; and -
FIG. 14 depicts a signaling flow diagram associated with a second post-call permanent condition, such as when a customer goes off-hook and does not enter any digits. -
FIG. 1 illustrates anetwork architecture 10 in accordance with a preferred embodiment of the invention for affording full-featured VoIP telephony service. Thenetwork architecture 10 includes afirst network 12 for providing packet-based communications services to acustomer premises 14 that includes one or more voice telephone sets, illustratively depicted by telephone sets 16 1, 16 2, 16 3. . . 16 n where n is an integer greater than zero. Thecustomer premises 14 may also include one or more data communications devices, such as acomputer 17. To interface with the telephone sets 16 1-16 n and thedata communications device 17, thenetwork 12 includes a Broadband Telephony Interface (BTI) 18 typically situated atcustomer premises 14. The BTI 18 enables each of the telephone sets 16 1-16 n to initiate VoIP calls to, and receive VoIP calls from thenetwork 12, provided that the customer subscribes to such service. - 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. AnHFC 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 16 1-16 n at thecustomer premises 14, from data traffic originated from thedata communications device 17. The CMTS/ER 22 routes the data traffic to anIP 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 routes VoIP calls originated at the BTI 18 to an Internet Protocol Digital Terminal (IPDT) 26 described in greater detail hereinafter with respect to
FIG. 2 . The IPDT 26 advantageously translates the packet-based VoIP calls, which may include signaling information in a Media Gateway Control Protocol (MGCP) or in a Network-based Call Signaling (NCS) protocol, into a TDM-based bearer channel, and a signaling channel typically in the GR-303 format. Both the bearer and signaling channel are received at a TDM-basedtelecommunications network 28, such as the Public Switched Telephone Network (PSTN). - As discussed in greater detail in connection with the signaling flows depicted in
FIGS. 3-14 , the IPDT 26 performs signaling protocol support functions that allow the BTI 18 to interact with theHFC network 12 as if the HFC network performed the call processing itself via an IP-Soft switch or similar mechanism. Moreover, the IPDT 26 also maps IP signaling information from the CMTS/ER 22 associated with an originating call into a format useful for thePSTN 28. - 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 thePSTN 28 at theswitch 30 rather than in thenetwork 12. - Performing call processing in the
PSTN 28, in accordance with the invention, rather than in thenetwork 12 affords several advantages. First and foremost, utilizing thePSTN 28 to perform call processing avoids the need to provide the necessary call-processing infrastructure within theHFC network 12 itself, such as by way of an IP-Soft switch or similar call processing mechanism. Moreover, theswitch 30 within thePSTN 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 thePSTN 28 for processing. In this way, thenetwork 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. -
FIG. 2 depicts a block schematic diagram of an illustrative embodiment of the IPDT 26 ofFIG. 1 . As illustrated inFIG. 2 , the IPDT 26 includes aswitching fabric 32 for routing traffic received via anIP interface 34 that supports a shared interface for voice and signaling traffic. The switchingfabric 32 routes the traffic from theIP interface 34 onto a dual EthernetBus 36 for communication to aTDM switching module 38. TheTDM switching module 38 includes aTDM processor 40 that converts voice packets into TDM signals. Additionally, theTDM switching module 38 provides the necessary Digital Signal Processor (DSP) resources for compression if needed. ATDM bus 42 connects theTDM processor 40 to aTDM interface 42 that provides an external customer interface to thePSTN 28 ofFIG. 1 through aPSTN interface 46. Acommon control module 48 provides configuration, management control and monitoring of elements within theIPDT 26 through a Dual Peripheral Component Interconnect (PCI)bus 50. - To best understand the manner in which calls are processed in accordance with the invention,
FIGS. 3-14 depict exemplary signaling flows for various conditions. Referring toFIG. 3 , there is shown the signaling flow for an outgoing call initiated from theBTI 18. The signaling flow commences as follows: -
- 1. A customer at one of the telephone sets 16 1-16 n lifts the handset to connect to an idle line.
- 2. The
BTI 18 ofFIG. 1 senses the off-hook condition and thereafter notifies theIPDT 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 theBTI 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 theswitch 30 ofFIG. 1 within thePSTN 28. TheIPDT 26 requests a connection to theswitch 30 for this call, indicating the derived Call Reference Value, by sending a SETUP message on the specific Interface Group assigned to theBTI 18. - 5. On receipt of the SETUP message, the
switch 30 ofFIG. 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 theIPDT 26 that it is ready to proceed, using GR-303 Time-slot Management Channel (TMC) signaling. Theswitch 30 ofFIG. 1 then selects an idle DSO within the Interface Group and notifies theIPDT 26 which DSO to use for this call (via a CONNECT message). - 7. If the
switch 30 is unable to handle the new call, or if no DSO is available, the switch notifies the IPDT 26 (via a RELEASE COMPLETE message). TheIPDT 26 will notify the BTI 18 (via a 400 REJECT message) and release resources for this call. Upon receipt of the 400 REJECT message, theBTI 18 will play fast busy tone to the customer, ending the call. - 8. Upon receipt of a CONNECT message, the
IPDT 26 requests theBTI 18 to create a connection (via a CRCX message). Included in this request is an instruction for theBTI 18 to notify theIPDT 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, theBTI 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 theIPDT 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 theBTI 18 and theIPDT 26. - 11. If bandwidth is unavailable, the CMTS/ER 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 theBTI 18 has been allocated bandwidth for the call, the IPDT signals to theswitch 30 ofFIG. 1 that the calling party is off-hook (using GR-303 TMC signaling) and acknowledges the DSO assignment (via a CONNECT ACK message). Upon notification that the calling party is off-hook, theswitch 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, theswitch 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 theswitch 30 ofFIG. 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 ofFIG. 1 processes the dialed digits and proceeds to set up the call through thePSTN 28. - 16. Upon receipt of far-end answer supervision, the
switch 30 ofFIG. 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.
-
FIG. 4 illustrates the signaling flow for a call originating in thePSTN 28 that is dialed to one of the telephones 16 1-16 n. -
- 1. A call destined for one of the telephones 16 1-16 n at the HFC VoIP customer's
premises 14 arrives at theswitch 30 of thePSTN 28 associated with that customer. - 2. Upon receipt of the incoming call, the
switch 30, ofFIG. 1 determines the Interface Group and Call Reference Value corresponding to the received Called Party Number. Theswitch 30 ofFIG. 1 then (1) notifies theIPDT 26 that it wishes to initiate a call over this Interface Group (using GR-303 TMC signaling); (2) selects and idle channel DSO; and (3) notifies theIPDT 26 which DSO 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). TheIPDT 26 will not have a valid mapping if, for example, thisBTI 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, IPDT determines the IP address currently assigned to the called party'sBTI 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 theIPDT 26. - 6. The
IPDT 26 then queries its Domain Name Server (DNS) (not shown), which returns the IP address and line number of theBTI 18 associated with the specified FQDN. The returned value will be stored in theIPDT 26's internal cache for future calls. - 7. Upon determining the IP address of the
BTI 18, theIPDT 26 requests the BTI to create a connection (via a CRCX message). Included in this request is theBTI 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 theIPDT 26 which BTI port number will be used for this call (via a 200 OK message). A media path (RIP stream) is now established between the assigned ports on theIPDT 26 and theBTI 18. - 10. If bandwidth is unavailable, the CMTS will reject the request. The
BTI 18 will notify theIPDT 26, which in turn informs theswitch 30 ofFIG. 1 via a RELEASE COMPLETE message. - 11. Once the IPDT knows that the
BTI 18 has been allocated bandwidth for the call, the IPDT signals to theswitch 30 ofFIG. 1 that the called party is on-hook (using GR-303 TMC signaling) and confirms the DSO assignment (via a CONNECT message). - 12. Upon notification that the called party is on-hook, the
switch 30 ofFIG. 1 instructs theIPDT 26 to “ring” the called party's telephone line (using GR-303 TMC signaling). Theswitch 30 ofFIG. 1 will control the specific ringing pattern to be used. This enables theswitch 30 ofFIG. 1 to apply, for example, the Distinctive Ringing feature. - 13. The
IPDT 26 passes the ringing instruction (and ringing pattern) to theBTI 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 theIPDT 26 by transmitting an off-hook signal in the RTP stream. - 18. The
IDPT 26 in turn will notify theswitch 30 ofFIG. 1 (via GR-303 TMC signaling). - 19. A two-way, end-to-end call path is now established and conversation can commence.
- 1. A call destined for one of the telephones 16 1-16 n at the HFC VoIP customer's
-
FIG. 5 depicts the signaling flow associated with termination of the call by theBTI 18. This call termination flow applies regardless of which party initiated the call and applies to all calls except emergency (911) calls as discussed hereinafter. -
- 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 theIPDT 26 by transmitting an on-hook signal in the RTP stream. - 3. The
IPDT 26 in turn will notify theswitch 30 ofFIG. 1 (via GR-303 TMC signaling). - 4. After a brief time-out period (if applicable), the
switch 30 ofFIG. 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 Call Waiting feature in order for theswitch 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 ofFIG. 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 enable 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). Theswitch 30 also sends an ISUP release (REL) message to any other PSTN switch involved in the call. - 7. Upon receipt of the DISCONNECT message, the
IPDT 26 requests theBTI 18 to delete the connection (via a DLCX message). Included in this request is an instruction for theBTI 18 to notify theIPDT 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 theIPDT 26 to delete the connection (via a 200 OK message). - 10. Upon acknowledgement, the
IPDT 26 sends a RELEASE message to theswitch 30 ofFIG. 1 (indicating a normal cause for release). - 11. The
switch 30 ofFIG. 1 in turn responds to theIPDT 26 with a RELEASE COMPLETE message, thereby completing the release of all the resources associated with this call.
-
FIG. 6 illustrates the signaling flow associated with termination of a call by thePSTN 28 ofFIG. 1 between a far-end customer (not shown) and thecustomer premises 14 ofFIG. 1 . This call termination flow applies regardless of which party initiated the 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 ofFIG. 1 ) associated with thecustomer 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, theswitch 30 ofFIG. 1 will inform theIPDT 26 via a DISCONNECT message (indicating a normal cause for release). - 4. Upon receipt for of the DISCONNECT message, the
IPDT 26 instructs theBTI 18 to delete the connection (via a DLCX message). The instruction includes a request for theBTI 18 to notify theIPDT 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 theIPDT 26's to delete the connection (via a 200 OK message). - 7. Upon receipt of the acknowledgement from the
BTI 18, theIPDT 26 sends a RELEASE message to theswitch 30 ofFIG. 1 (indicating a normal cause for release). - 8. The
switch 30 ofFIG. 1 , in turn, responds to theIPDT 26 with a RELEASE COMPLETE message, thereby completing the release of all the resources associated with this call. Theswitch 30 ofFIG. 1 also sends an ISUP release complete (RLC) message to any other PSTN switch involved in this call.
-
FIG. 7 illustrates the signaling flow associated with providing a HFC VoIP customer on an established call with notification of another incoming call along with the identity of the new caller (telephone number and/or name). The signaling flow only applies if the HFC VoIP customer has subscriber to the Caller ID with Call Waiting feature and commences when a new incoming call arrives at theswitch 30 ofFIG. 1 for a the HFC VoIP customer that is already on an established call. -
- 1. Upon receipt of an incoming call destined for the HFC VoIP customer, the
switch 30 ofFIG. 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, Caller ID mechanism (not shown) associated with one of the telephones 16 1-16 n 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 ofFIG. 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 theIPDT 26 by transmitting an on-hook signal in the RTP stream. - 6. The
IPDT 26 in turn will notify theswitch 30 ofFIG. 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 ofFIG. 1 has decided to release the call, or if the customer had pressed the flash key, theBTI 18 will notify theIPDT 26 by transmitting an off-hook signal in the RTP stream. - 8. The
IPDT 26 in turn will notify theswitch 30 ofFIG. 1 of the off-hook event (via GR-303 TMC signaling). - 9. The
switch 30 ofFIG. 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
-
FIG. 8 depicts the signaling flow that occurs when a HFC VoIP Telephony customer subscribing to a voice mail service receives a notification of a new voice mail message, via the message-waiting indicator (not shown) on a suitably equipped device, such as one of the telephone sets 16 1-16 n. The message-waiting indicator only becomes activated when the caller is on-hook. If the customer is off-hook the indication will be delayed until after the customer has terminated the current call. The signaling flow is as follows: -
- 1. The
switch 30 ofFIG. 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. Theswitch 30 notifies theIPDT 26 that it wishes to initiate a call over this Interface Group (using GR-303 TMC signaling) selects an idle DSO and notifies theIPDT 26, which DSO 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'sBTI 18. - 5. If the IPDT 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 theBTI 18 associated with the specified FQDN. The returned value will be stored in the internal cache of theIPDT 26 for future calls. - 6. Upon determining the IP address of the
BTI 18, theIPDT 26 requests the BTI to create a connection (via a CRCX message). The request includes the line number of theBTI 18 to which the call is destined. - 7. If the requested bandwidth is granted by the CMTS/
ER 22, theBTI 18 informs theIPDT 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 theIPDT 26 and theBTI 18. - 8. If the bandwidth is unavailable, the CMTS/
ER 22 will reject the request and theIPDT 26 will inform theswitch 30 ofFIG. 1 via a RELEASE COMPLETE message, ending the signaling flow under this condition. Theswitch 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 theBTI 18 has been allocated bandwidth for the call, the IPDT signals to switch 30 ofFIG. 1 that the called party is on-hook (using GR-303 TMS signaling) and confirms the DSO assignment (via a CONNECT message). - 10. Upon notification that the called party is on-hook, the
switch 30 ofFIG. 1 sends the message-waiting indicator to theBTI 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
-
FIG. 9 depicts the signaling flow associated with delayed termination of an emergency call, such as a 911 call directed to an Emergency Services Application Platform (ESAP) (not shown) served by thePSTN 28. An emergency (E-911) call is established just like any other call. Only theswitch 30 ofFIGS. 1 and E-911 ESAP are aware that a 911 call is in progress. The 911 call terminates in the same as any other BTI 18-initiated call termination, as depicted inFIG. 5 , except for one important difference. In order for the E-911 operator to gather sufficient information about the location of the caller, the call resources must remain “active” even after the caller hangs up. To keep the resources active, control of 911-calls is given to the E-911 operator. When the caller hangs up at the end of a normal (non-911) call, theswitch 30 ofFIG. 1 will automatically respond to the on-hook indication with a DISCONNECT message as described previously. However, on a 911 call, theswitch 30 ofFIG. 1 does not send back the DISCONNECT message until it receives an instruction to release from the E-911 operator. -
FIG. 10 depicts the signaling flow associated with an outgoing call attempt originated from a BTI, such asBTI 18 ofFIG. 1 for which HFC bandwidth is unavailable. As may be appreciated, the first eight steps of the signaling flow is identical to the signaling flow depicted inFIG. 3 . When insufficient bandwidth is detected, then, as illustrated inFIG. 10 , theBTI 18 notifies the IPDT 26 (typically via a 400 REJECT message) that insufficient bandwidth exists to make the call, and that the connection to theswitch 30 ofFIG. 1 can be released. In turn, theIPDT 26 notifies theswitch 30 to complete a release. Thereafter, theBTI 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. -
FIG. 11 depicts the signaling flow associated with an outgoing call attempt originated from a BTI, such asBTI 18 ofFIG. 1 for which a resource other than HFC bandwidth, is unavailable. Like the signaling flow ofFIG. 3 , the signaling flow ofFIG. 11 includes the steps of: -
- 1. A subscriber at one of the telephone sets 16 1-16 n lifts the handset to connect to an idle line.
- 2. The
BTI 18 ofFIG. 1 senses the off-hook condition and notifies theIPDT 26 of this event (via a NTFY message), indicating the address of the BTI and which of its lines is now off-hook. - 3. Upon receipt of this notification, the
IPDT 26 ofFIG. 1 sends an acknowledgement to theBTI 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 theBTI 18, typically via an RQNT message. Thereafter, theBTI 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.
-
FIG. 12 depicts the signaling flow associated with an incoming call attempt originated from thePSTN 28 for which bandwidth is unavailable in theHFC network 12. The signaling flow ofFIG. 12 includes the same steps as steps (1)-(7) described with respect toFIG. 4 . However, upon determining insufficient bandwidth exists, theBTI 18 notifies the IPDT 26 (typically via a 400 REJECT message) that insufficient bandwidth exists to make the call, and that the connection to theswitch 30 ofFIG. 1 can be released. In turn, theIPDT 26 notifies theswitch 30 to complete a release. -
FIG. 13 depicts the signaling flow associated with a permanent signaling condition caused by the HFC VoIP customer failing to go on-hook (i.e., hang up) after the other party has gone on-hook.FIG. 13 includes substantially the same steps as the PSTN-initiated call termination signaling flow depicted inFIG. 6 , with the additional step of having the BTI generate an announcement and a howler tone (or other warning) to the customer to hang-up when the BTI detects that the customer has remained off-hook for more than a prescribed interval. -
FIG. 14 depicts the signaling flow associated with the permanent signaling condition occurring when the HFC VoIP customer goes off-hook, but fails to dial any digits. The signal flow ofFIG. 14 includes the initial call set-up steps of (1)-(12) ofFIG. 3 including the step of providing dial tone. If, after a prescribed time interval, theswitch 30 ofFIG. 1 fails to receive any dialed digits, then the switch sends a howler tone or other warning to the customer. Thereafter, thePSTN 28 terminates the call via steps depicted in the call signaling flow shown inFIG. 6 . - 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 principle 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 (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/632,728 US20100220715A1 (en) | 2001-09-28 | 2009-12-07 | Technique for providing translation between the packet environment and the pstn environment |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/966,492 US7630359B1 (en) | 2001-09-28 | 2001-09-28 | Technique for providing translation between the packet environment and the PSTN environment |
US12/632,728 US20100220715A1 (en) | 2001-09-28 | 2009-12-07 | Technique for providing translation between the packet environment and the pstn environment |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/966,492 Continuation US7630359B1 (en) | 2001-09-28 | 2001-09-28 | Technique for providing translation between the packet environment and the PSTN environment |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100220715A1 true US20100220715A1 (en) | 2010-09-02 |
Family
ID=41394300
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/966,492 Expired - Lifetime US7630359B1 (en) | 2001-09-28 | 2001-09-28 | Technique for providing translation between the packet environment and the PSTN environment |
US12/632,728 Abandoned US20100220715A1 (en) | 2001-09-28 | 2009-12-07 | Technique for providing translation between the packet environment and the pstn environment |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/966,492 Expired - Lifetime US7630359B1 (en) | 2001-09-28 | 2001-09-28 | Technique for providing translation between the packet environment and the PSTN environment |
Country Status (1)
Country | Link |
---|---|
US (2) | US7630359B1 (en) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060209811A1 (en) * | 2005-03-21 | 2006-09-21 | Yangling Zhang | Computer telephony using a circuit-switched network |
US20070201663A1 (en) * | 2005-05-29 | 2007-08-30 | Huawei Technologies Co., Ltd. | Method for listening to signal tone from a called party by a calling party during network interworking |
US20080240381A1 (en) * | 2005-01-08 | 2008-10-02 | International Business Machines Corporation | Method and Apparatus for Providing Contextual Information with Telephone Calls |
US20080267064A1 (en) * | 2004-06-04 | 2008-10-30 | Ian Broadhurst | Communications System and Method for Load Management |
US20110038278A1 (en) * | 2007-05-28 | 2011-02-17 | Honeywell International Inc. | Systems and methods for configuring access control devices |
US20120195260A1 (en) * | 2010-11-12 | 2012-08-02 | Ulrich Dietz | Packet switched eCall connection |
US8787725B2 (en) | 2010-11-11 | 2014-07-22 | Honeywell International Inc. | Systems and methods for managing video data |
US8941464B2 (en) | 2005-10-21 | 2015-01-27 | Honeywell International Inc. | Authorization system and a method of authorization |
US9019070B2 (en) | 2009-03-19 | 2015-04-28 | Honeywell International Inc. | Systems and methods for managing access control devices |
US9280365B2 (en) | 2009-12-17 | 2016-03-08 | Honeywell International Inc. | Systems and methods for managing configuration data at disconnected remote devices |
US9344684B2 (en) | 2011-08-05 | 2016-05-17 | Honeywell International Inc. | Systems and methods configured to enable content sharing between client terminals of a digital video management system |
US9894261B2 (en) | 2011-06-24 | 2018-02-13 | Honeywell International Inc. | Systems and methods for presenting digital video management system information via a user-customizable hierarchical tree interface |
US10038872B2 (en) | 2011-08-05 | 2018-07-31 | Honeywell International Inc. | Systems and methods for managing video data |
US10362273B2 (en) | 2011-08-05 | 2019-07-23 | Honeywell International Inc. | Systems and methods for managing video data |
US10523903B2 (en) | 2013-10-30 | 2019-12-31 | Honeywell International Inc. | Computer implemented systems frameworks and methods configured for enabling review of incident data |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7630359B1 (en) * | 2001-09-28 | 2009-12-08 | At&T Corp. | Technique for providing translation between the packet environment and the PSTN environment |
ATE443308T1 (en) * | 2005-01-26 | 2009-10-15 | Alcatel Lucent | METHOD FOR MAKING AN EMERGENCY CALL IN A LOCAL INFORMATION NETWORK, TERMINAL DEVICE, NETWORK TRANSITIONS AND SERVER DEVICE FOR SUCH A METHOD |
TWI407763B (en) | 2008-05-13 | 2013-09-01 | Htc Corp | Electronic device, imcoming call answering and rejection method and digital data storage media |
US8611360B2 (en) * | 2010-12-15 | 2013-12-17 | At&T Intellectual Property I, L.P. | System for processing a call with a TDM network and routing the call with an IP network |
US11838262B1 (en) * | 2022-11-30 | 2023-12-05 | Cujo LLC | Discovery of FQDN for target website |
Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020064152A1 (en) * | 2000-11-28 | 2002-05-30 | Lemley Donald G. | Packet voice gateway |
US6466651B1 (en) * | 2000-07-12 | 2002-10-15 | Telefonaktiebolaget Lm Ericsson | Call agents and systems and methods for providing emergency call services on heterogeneous networks |
US20030002486A1 (en) * | 2001-06-28 | 2003-01-02 | Emerson Harry E. | Telephone central office switch interface with messaging channel for integrating the PSTN with the Internet |
US20030016661A1 (en) * | 2001-07-18 | 2003-01-23 | Emerson Harry E. | Telephone switching system for integrating the internet with the public switched telephone network |
US20030048772A1 (en) * | 2001-08-29 | 2003-03-13 | General Instrument Corporation | System for converting GR303 signals to NCS signals |
US20030095542A1 (en) * | 1997-07-25 | 2003-05-22 | Chang Gordon K. | Apparatus and method for integrated voice gateway |
US6661785B1 (en) * | 1999-10-12 | 2003-12-09 | Bellsouth Intellectual Property Corporation | Method and apparatus for providing internet call waiting with voice over internet protocol |
US6697357B2 (en) * | 2001-08-10 | 2004-02-24 | Emerson, Iii Harry E. | Call management messaging system for integrating the internet with the public switched telephone network |
US6700884B2 (en) * | 2001-06-28 | 2004-03-02 | Emerson, Iii Harry E. | Integrating the Internet with the public switched telephone network |
US6704305B2 (en) * | 2001-06-28 | 2004-03-09 | Emerson, Iii Harry E. | Integrated device for integrating the internet with the public switched telephone network |
US6731649B1 (en) * | 2000-07-26 | 2004-05-04 | Rad Data Communication Ltd. | TDM over IP (IP circuit emulation service) |
US20040085975A1 (en) * | 1996-11-22 | 2004-05-06 | Sprint Communications Company, L.P. | Broadband telecommunications system interface |
US6771953B1 (en) * | 1998-12-31 | 2004-08-03 | At&T Corp. | Wireless centrex call transfer |
US6775269B1 (en) * | 1999-03-30 | 2004-08-10 | Telecom Technologies, Inc. | Method and system for routing telephone calls between a public switched telephone network and an internet protocol network |
US6785301B1 (en) * | 2000-06-29 | 2004-08-31 | Cisco Technology, Inc. | Method and apparatus for conducting call waiting-caller identification in a packet switched network |
US20040213218A1 (en) * | 1999-09-08 | 2004-10-28 | Qwest Communications International Inc. | System and method for dynamic distributed communication |
US20040213205A1 (en) * | 2001-02-23 | 2004-10-28 | San-Qi Li | Voice packet switching system and method |
US6826174B1 (en) * | 2000-03-02 | 2004-11-30 | 3Com Corporation | Voice-over-IP interface for standard household telephone |
US6937594B2 (en) * | 2001-04-27 | 2005-08-30 | Lucent Technologies Inc. | Loop back testing for multi-protocol hybrid networks |
US6996510B1 (en) * | 2000-01-21 | 2006-02-07 | Metasolv Software, Inc. | System and method for modeling communication networks |
US20070147401A1 (en) * | 2000-11-28 | 2007-06-28 | Carew A J P | System and Method for Communicating Telecommunication Information between a Broadband Network and a Telecommunication Network |
US20090129566A1 (en) * | 2000-01-07 | 2009-05-21 | Feuer Donald S | Providing real-time voice communication between devices connected to an Internet Protocol network and devices connected to a public switched telephone network |
US7630359B1 (en) * | 2001-09-28 | 2009-12-08 | At&T Corp. | Technique for providing translation between the packet environment and the PSTN environment |
-
2001
- 2001-09-28 US US09/966,492 patent/US7630359B1/en not_active Expired - Lifetime
-
2009
- 2009-12-07 US US12/632,728 patent/US20100220715A1/en not_active Abandoned
Patent Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040085975A1 (en) * | 1996-11-22 | 2004-05-06 | Sprint Communications Company, L.P. | Broadband telecommunications system interface |
US20030095542A1 (en) * | 1997-07-25 | 2003-05-22 | Chang Gordon K. | Apparatus and method for integrated voice gateway |
US6771953B1 (en) * | 1998-12-31 | 2004-08-03 | At&T Corp. | Wireless centrex call transfer |
US6775269B1 (en) * | 1999-03-30 | 2004-08-10 | Telecom Technologies, Inc. | Method and system for routing telephone calls between a public switched telephone network and an internet protocol network |
US20040213218A1 (en) * | 1999-09-08 | 2004-10-28 | Qwest Communications International Inc. | System and method for dynamic distributed communication |
US6661785B1 (en) * | 1999-10-12 | 2003-12-09 | Bellsouth Intellectual Property Corporation | Method and apparatus for providing internet call waiting with voice over internet protocol |
US20090129566A1 (en) * | 2000-01-07 | 2009-05-21 | Feuer Donald S | Providing real-time voice communication between devices connected to an Internet Protocol network and devices connected to a public switched telephone network |
US6996510B1 (en) * | 2000-01-21 | 2006-02-07 | Metasolv Software, Inc. | System and method for modeling communication networks |
US6826174B1 (en) * | 2000-03-02 | 2004-11-30 | 3Com Corporation | Voice-over-IP interface for standard household telephone |
US6785301B1 (en) * | 2000-06-29 | 2004-08-31 | Cisco Technology, Inc. | Method and apparatus for conducting call waiting-caller identification in a packet switched network |
US6466651B1 (en) * | 2000-07-12 | 2002-10-15 | Telefonaktiebolaget Lm Ericsson | Call agents and systems and methods for providing emergency call services on heterogeneous networks |
US6731649B1 (en) * | 2000-07-26 | 2004-05-04 | Rad Data Communication Ltd. | TDM over IP (IP circuit emulation service) |
US20020064152A1 (en) * | 2000-11-28 | 2002-05-30 | Lemley Donald G. | Packet voice gateway |
US20070147401A1 (en) * | 2000-11-28 | 2007-06-28 | Carew A J P | System and Method for Communicating Telecommunication Information between a Broadband Network and a Telecommunication Network |
US20040213205A1 (en) * | 2001-02-23 | 2004-10-28 | San-Qi Li | Voice packet switching system and method |
US6937594B2 (en) * | 2001-04-27 | 2005-08-30 | Lucent Technologies Inc. | Loop back testing for multi-protocol hybrid networks |
US20030002486A1 (en) * | 2001-06-28 | 2003-01-02 | Emerson Harry E. | Telephone central office switch interface with messaging channel for integrating the PSTN with the Internet |
US6704305B2 (en) * | 2001-06-28 | 2004-03-09 | Emerson, Iii Harry E. | Integrated device for integrating the internet with the public switched telephone network |
US6700884B2 (en) * | 2001-06-28 | 2004-03-02 | Emerson, Iii Harry E. | Integrating the Internet with the public switched telephone network |
US20030016661A1 (en) * | 2001-07-18 | 2003-01-23 | Emerson Harry E. | Telephone switching system for integrating the internet with the public switched telephone network |
US6697357B2 (en) * | 2001-08-10 | 2004-02-24 | Emerson, Iii Harry E. | Call management messaging system for integrating the internet with the public switched telephone network |
US20030048772A1 (en) * | 2001-08-29 | 2003-03-13 | General Instrument Corporation | System for converting GR303 signals to NCS signals |
US7630359B1 (en) * | 2001-09-28 | 2009-12-08 | At&T Corp. | Technique for providing translation between the packet environment and the PSTN environment |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080267064A1 (en) * | 2004-06-04 | 2008-10-30 | Ian Broadhurst | Communications System and Method for Load Management |
US8817609B2 (en) * | 2004-06-04 | 2014-08-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Communications system and method for load management |
US8576835B2 (en) * | 2005-01-08 | 2013-11-05 | International Business Machines Corporation | Method and apparatus for providing contextual information with telephone calls |
US20080240381A1 (en) * | 2005-01-08 | 2008-10-02 | International Business Machines Corporation | Method and Apparatus for Providing Contextual Information with Telephone Calls |
US20060209811A1 (en) * | 2005-03-21 | 2006-09-21 | Yangling Zhang | Computer telephony using a circuit-switched network |
US8331357B2 (en) * | 2005-03-21 | 2012-12-11 | Alcatel Lucent | Computer telephony using a circuit-switched network |
US8335221B2 (en) * | 2005-05-29 | 2012-12-18 | Huawei Technologies Co., Ltd. | Method for listening to signal tone from a called party by a calling party during network interworking |
US20070201663A1 (en) * | 2005-05-29 | 2007-08-30 | Huawei Technologies Co., Ltd. | Method for listening to signal tone from a called party by a calling party during network interworking |
US8941464B2 (en) | 2005-10-21 | 2015-01-27 | Honeywell International Inc. | Authorization system and a method of authorization |
US20110038278A1 (en) * | 2007-05-28 | 2011-02-17 | Honeywell International Inc. | Systems and methods for configuring access control devices |
US8351350B2 (en) * | 2007-05-28 | 2013-01-08 | Honeywell International Inc. | Systems and methods for configuring access control devices |
US9019070B2 (en) | 2009-03-19 | 2015-04-28 | Honeywell International Inc. | Systems and methods for managing access control devices |
US9280365B2 (en) | 2009-12-17 | 2016-03-08 | Honeywell International Inc. | Systems and methods for managing configuration data at disconnected remote devices |
US8787725B2 (en) | 2010-11-11 | 2014-07-22 | Honeywell International Inc. | Systems and methods for managing video data |
US20120195260A1 (en) * | 2010-11-12 | 2012-08-02 | Ulrich Dietz | Packet switched eCall connection |
US9894261B2 (en) | 2011-06-24 | 2018-02-13 | Honeywell International Inc. | Systems and methods for presenting digital video management system information via a user-customizable hierarchical tree interface |
US9344684B2 (en) | 2011-08-05 | 2016-05-17 | Honeywell International Inc. | Systems and methods configured to enable content sharing between client terminals of a digital video management system |
US10038872B2 (en) | 2011-08-05 | 2018-07-31 | Honeywell International Inc. | Systems and methods for managing video data |
US10362273B2 (en) | 2011-08-05 | 2019-07-23 | Honeywell International Inc. | Systems and methods for managing video data |
US10863143B2 (en) | 2011-08-05 | 2020-12-08 | Honeywell International Inc. | Systems and methods for managing video data |
US10523903B2 (en) | 2013-10-30 | 2019-12-31 | Honeywell International Inc. | Computer implemented systems frameworks and methods configured for enabling review of incident data |
US11523088B2 (en) | 2013-10-30 | 2022-12-06 | Honeywell Interntional Inc. | Computer implemented systems frameworks and methods configured for enabling review of incident data |
Also Published As
Publication number | Publication date |
---|---|
US7630359B1 (en) | 2009-12-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20100220715A1 (en) | Technique for providing translation between the packet environment and the pstn environment | |
US6584094B2 (en) | Techniques for providing telephonic communications over the internet | |
US9118510B2 (en) | Voice over network (VoN)/voice over internet protocol (VoIP) architect having hotline and optional tie line | |
US7881449B2 (en) | Enhanced call notification service | |
EP0398183B1 (en) | Carrier independent network services | |
US7139380B2 (en) | System and method for performing signaling-plan-specific call progress analysis | |
US20070211698A1 (en) | System and device for integrating ip and analog telephone systems | |
KR20020059733A (en) | APPARATUS FOR A VOICE OVER IP(VoIP) TELEPHONY GATEWAY AND METHODS FOR USE THEREIN | |
AU7860498A (en) | A packet-switched network telephone system | |
US6603760B1 (en) | System and method for gradual transition of local phone services from PSTN to next generation network | |
WO2005086453A1 (en) | Method for establishing a call in a telecommunications network; telecommunications network; and controlling device for packet networks | |
US8107479B2 (en) | Method and system for telephony and high-speed data access on a broadband access network | |
US20060045076A1 (en) | Method and system for routing call in VoIP gateway | |
US20050069104A1 (en) | Call management service | |
US6633637B1 (en) | Suppressed ringing connectivity | |
Cisco | D | |
US6483904B1 (en) | Method and system for high-speed interface access to a computer network using a subscriber telephone line | |
EP1509033B1 (en) | Method and devices for connecting IP terminations and PSTN terminations | |
US7436851B1 (en) | Destination call routing apparatus and method | |
US20030228012A1 (en) | Method and apparatus for efficient use of voice trunks for accessing a service resource in the PSTN | |
WO2005011239A1 (en) | Gateway device, private branch exchange system, and private branch exchange method | |
EP1319258B1 (en) | Continuity testing in communication networks | |
JP2003143320A (en) | Method for reaching incoming call to ip terminal | |
US9042371B1 (en) | Integrating telephone lines with packet connections | |
US6728362B1 (en) | Continuity testing with call tone messaging in communication networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: AT&T CORP., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHERCHALI, ALI;EHLINGER, JAMES;FELLINGHAM, PAUL J.;AND OTHERS;SIGNING DATES FROM 20010912 TO 20020123;REEL/FRAME:025752/0842 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: AT&T PROPERTIES, LLC, NEVADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AT&T CORP.;REEL/FRAME:053437/0943 Effective date: 20200720 Owner name: AT&T INTELLECTUAL PROPERTY II, L.P., GEORGIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AT&T PROPERTIES, LLC;REEL/FRAME:053438/0007 Effective date: 20200720 |