US20100002690A1 - Network telephony appliance and system for inter/intranet telephony - Google Patents

Network telephony appliance and system for inter/intranet telephony Download PDF

Info

Publication number
US20100002690A1
US20100002690A1 US12/560,821 US56082109A US2010002690A1 US 20100002690 A1 US20100002690 A1 US 20100002690A1 US 56082109 A US56082109 A US 56082109A US 2010002690 A1 US2010002690 A1 US 2010002690A1
Authority
US
United States
Prior art keywords
network
call
task
network appliance
sip
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
Application number
US12/560,821
Inventor
Henning Schulzrinne
Jianqi Yin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US12/560,821 priority Critical patent/US20100002690A1/en
Publication of US20100002690A1 publication Critical patent/US20100002690A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16Sound input; Sound output
    • G06F3/167Audio in a user interface, e.g. using voice commands for navigating, audio feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • H04L2012/6486Signalling Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • H04L69/085Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Definitions

  • the present invention relates in general to the field of Internet and intranet telephony. More particularly, the present invention relates to a network telecommunications appliance and system for Internet/intranet communications.
  • the Internet has evolved from a convenient additional means of communications to an essential communication tool in the business, technical and educational fields.
  • a growing segment of the Internet relates to Internet telephony which provides a number of advantages over conventional circuit-switched network controlled by a separate signaling network.
  • parties are allowed to more easily select and use encoding and other data compression techniques that are most appropriate for their quality needs. Parties may, for example, decide that for international calls, they would trade lower cost for full toll quality, while a reporter calling in her story to a radio station may go for full FM quality with little regard for price. Even without quality degradation.
  • H.323 protocol is a complex protocol which is difficult to use and implement.
  • different implementations of H.323 devices may be adversely affected by compatibility issues.
  • devices operating under the H.323 protocol cannot communicate directly with one another, calls must be processed and routed by a telephony server.
  • a primary object is to provide a packet-based voice communication system for use over the Internet and intranet telecommunications networks.
  • a network packet data telephone apparatus includes: a network controller, such as an Ethernet controller subsystem, coupled to a data network for providing and receiving data packets to and from the network.
  • a digital signal processing subsystem is coupled to the network controller subsystem and operates under a computer program for detecting incoming calls, initiating call sessions and implementing telephony features.
  • a signal conversion subsystem is coupled to the digital signal processing subsystem for converting digital packet information into analog signals and vice versa.
  • a user interface subsystem is coupled to both the signal conversion subsystem and the digital signal processing subsystem for providing user control and feedback to the apparatus.
  • This stand alone network telephony device is referred to herein as a network telephony appliance.
  • the computer program of the network telephony appliance implements the Session Initiation Protocol (SIP).
  • SIP Session Initiation Protocol
  • a unique SIP address is associated with the device and session initiation and control are performed in accordance with the SIP protocol.
  • the network telephony appliance preferably implements high level telephony functionality including a monitoring feature, call forwarding, streaming audio mode, caller log, callee log and the like.
  • the network telephony appliance includes sensor interface circuitry for receiving signals from remote sources, such as sensors.
  • the signals received from the remote sources are processed by the network telephony appliance and sent to an appropriate network destination.
  • a communication protocol for use in a packet-based telecommunication system, the communication protocol having: an Ethernet protocol layer; an Internet Protocol (IP) layer stacked on top of the Ethernet protocol layer for interfacing with the Ethernet protocol layer; an Address Resolution Protocol (ARP) layer stacked on top of the Ethernet protocol layer for interfacing with the Ethernet protocol layer and the IP layer, and for translating IP addresses into Media Access Control (MAC) addresses; a User Datagram Protocol (UDP) layer stacked on top of the ARP and IP layers for interfacing with the ARP and IP layers and for providing real-time transport of application data and controls within the telecommunication system; a Real-Time Transport Protocol (RTP) layer stacked on top of the UDP layer for interfacing with the UDP layer and for providing real-time audio data transport within the telecommunication system; one or more control protocol layers stacked on top of the UDP layer for interfacing with the UDP layer and for signaling and providing registration of the real-time audio data; and one or more application protocols stacked on top of the RTP
  • a network telephony system architecture includes at least two network telephony devices, such as a the present network telephony appliance and/or a general purpose personal computer (PC) with suitable interface circuitry and software to operate the PC as a network telephone.
  • a redirect server is also provided which is coupled to the data network along with the network telephony devices.
  • the network telephony devices can directly address one another to establish a real time audio connection.
  • the redirect server can be accessed by the network telephony devices in order to identify, locate, and initiate a call session with a called party.
  • the redirect server can also be used to implement high level telephony functions, such as call forwarding, multi-party calling, voice mail and the like.
  • FIG. 1 is a illustrative diagram of a telecommunications system featuring a conventional circuit-switched voice network operatively coupled to a voice packet network;
  • FIG. 2 is a block diagram of a packet data network telephone system
  • FIG. 3 is a diagram showing a protocol stack for telephony devices operating on the packet data network telephone system of FIG. 2 ;
  • FIG. 4 is a block diagram of a preferred hardware architecture of a network telephony appliance in accordance with the present invention.
  • FIG. 5 is a block diagram further illustrating the network telephony appliance of FIG. 4 ;
  • FIG. 6 is an exemplary memory map for the DSP of the network telephony appliance of FIG. 5 ;
  • FIG. 7 is a block diagram of a memory interface for the DSP of the network telephony appliance of FIG. 5 ;
  • FIG. 8 is a block diagram of a network controller interface for the DSP of the network telephony appliance FIG. 5 ;
  • FIG. 9 is a block diagram of a codec interface for the DSP of the network telephony appliance of FIG. 5 ;
  • FIG. 10 is an exemplary memory map for the DSP of FIG. 5 showing a mapping of the LCD control interface to DSP memory addresses;
  • FIG. 11 is a block diagram showing the software architecture for the network telephony appliance of FIG. 4 ;
  • FIG. 12 is a block diagram showing the scheduling mechanisms of the process level software of FIG. 11 ;
  • FIGS. 13A-F are tables illustrating exemplary task definitions for software operations of a preferred method of operating the Packet data network telephone in accordance with the hardware and software architectures of FIGS. 4 and 11 ;
  • FIG. 14 is a flow diagram of an ARP request output procedure in accordance with the hardware and software architectures of FIGS. 4 , 11 and 13 ;
  • FIG. 15 is a flow diagram of an ARP request input procedure in accordance with the hardware and software architectures of FIGS. 4 , 11 and 13 ;
  • FIG. 16 is a diagram showing the IP processing steps in accordance with the hardware and software architectures of FIGS. 4 , 11 and 13 ;
  • FIG. 17 is a list of exemplary Ethernet transmit data structures according to the software architecture of FIG. 11 ;
  • FIG. 18 is a data flow diagram of a packet sending procedure in accordance with the hardware and software architectures of FIGS. 4 , 11 and 13 ;
  • FIG. 19 is a data flow diagram of a packet receiving procedure in accordance with the hardware and software architectures of FIGS. 4 , 11 and 13 ;
  • FIGS. 20A and 20B show the A/D and D/A “ping-pong” buffer scheme used by the software of the present network telephony appliance
  • FIG. 21 is a state transition diagram of the Call_task process of the present network telephony appliance.
  • FIG. 22 is chart defining the key pad values for the preferred embodiment of the Packet data network telephone of FIG. 5 ;
  • FIG. 23 is a data structure illustrating key state definitions for the preferred embodiment of the present network telephony appliance of FIG. 5 ;
  • FIG. 24 is a mapping of the I/O parallel port of the network telephony appliance of FIG. 5 ;
  • FIG. 25 is a data structure defining the Ethernet controller states of the network telephony appliance of FIG. 5 ;
  • FIG. 26 is an exemplary RTP header structure for RTP packet processing used in the network telephony appliance network telephony appliance of FIG. 5 ;
  • FIG. 27 is a data structure for use with a tone generation function of the Packet data network telephone of FIG. 5 ;
  • FIG. 28 is a timing diagram for the tone generation function of the network telephony appliance of FIG. 5 ;
  • FIG. 29 is a list of data structures used for processing the SIP_task requests or responses in accordance with the network telephony appliance of FIG. 5 ;
  • FIG. 30 is a state transition diagram illustrating the network telephony appliance operating as a client (initiating a call) in accordance with FIG. 5 ;
  • FIG. 31 is list of SIP_task responses in accordance with the network telephony appliance of FIG. 5 ;
  • FIG. 32 is a state diagram illustrating the state transition diagram of a SIP UAS in accordance with the network telephony appliance of FIG. 5 ;
  • FIG. 33 is a block diagram which illustrates part of a packet data network telephony system including one or more network telephony appliances in accordance with the present invention.
  • FIG. 1 is a block diagram which shows a telecommunications system having conventional telephony and packet telephony components.
  • the system includes a circuit-switched voice network 20 coupled to a packet network 30 via a first gateway 12 .
  • the figure shows at least three possible interactions between Internet telephony and a conventional “plain old telephony service” (POTS) system: “end-to-end” packet delivery; “tail-end hop off” delivery; and local packet delivery.
  • POTS plain old telephony service
  • end systems such as network computers, dedicated Internet phones or personal computers (PCs) are used to packetize audio and deliver audio packets to one or more similar end systems for playback.
  • PCs personal computers
  • Tail-end hop off delivery, packet networks are used for long-haul voice transmission, while standard circuit-switched voice circuits are used for connecting customer premise equipment (CPE), i.e., standard analog telephones, to the packet telephony gateways.
  • CPE customer premise equipment
  • “Tail-end hop off” can be used both for individual voice circuits as well as for PBX interconnects, and allows for the bypassing of conventional long-distance services as well as the interconnection of POTS equipment to packet-based audio end systems.
  • voice data is generated by packet audio end systems, but carried as circuit-switched voice over leased or public facilities.
  • FIG. 2 shows a preferred embodiment of an packet data network telephone system 50 according to the present invention.
  • the packet data network telephone system includes: an Ethernet LAN 52 , Ethernet phones 54 , 56 , and 58 , a workstation 60 , a server 62 and a Ethernet gateway 64 .
  • the Ethernet phones are network devices, which can take the form of stand alone devices, such as a network appliance, or a personal computer system with audio input and output peripherals and operating under the control of an appropriate computer program. With such an packet data network approach, voice data traffic is packetized proximate the end user.
  • the packet data network telephony system of FIG. 2 for example, can include several dozen homes, offices or apartments that are connected to a plurality of Ethernet gateways (only one shown in FIG.
  • each network device includes a network address and each device can directly access every other network device via the network address. While a specialized server may be desirable to implement certain features, it is not required to establish a call session, i.e., point to point data communications between two or more network devices.
  • Packet data network LAN 52 is advantageous in that it is a relatively inexpensive solution where conventional PC interfaces and network hardware can be used.
  • the Packet data network LAN 52 can be operated over a variety of media and allows for the easy addition of more devices on a multiple-access LAN.
  • Gateway 64 can be a single DSP that acts as a simple packet voice module and that implements DTMF recognition for user-to-network signaling.
  • FIG. 3 is a block diagram which illustrates a packet data network protocol stack diagram for providing Internet telephony and other continuous-media (“streaming media”) services such as “Internet radio” and “Internet TV.”
  • a “protocol” is generally a set of rules for communicating between computers. As such, protocols govern format, timing, sequencing, and error control.
  • the term “stack” refers to the actual software that processes the protocols and thus allows the use of a specific set or sets of protocols.
  • the diagram shown in FIG. 3 shows how the various protocols are interrelated in accordance with the present invention.
  • the protocol stack 80 of FIG. 3 incorporates a number of layered protocols including: a base protocol 82 for providing basic Ethernet message format and timing information; an Address Resolution Protocol (ARP) 84 for interfacing with the base protocol 82 and for translating IP addresses into Media Access Control (MAC) addresses; an Internet Protocol (IP) network layer 86 for interfacing with the base protocol 82 ; a optional Dynamic Host Configuration Protocol (DHCP) 88 for interfacing with the base protocol 82 ; and a User Datagram Protocol (UDP) 90 for interfacing with the ARP 84 , IP 86 and DHCP 88 protocols and for real-time transport of application data and controls.
  • ARP Address Resolution Protocol
  • IP Internet Protocol
  • IP Internet Protocol
  • DHCP Dynamic Host Configuration Protocol
  • UDP User Datagram Protocol
  • the protocol stack 80 further includes the following application-specific protocols for coding speech information: a Real-Time Transport Protocol (RTP) protocol 92 for real-time audio data transport, wherein the RTP protocol 92 generally interfaces with the UDP 90 and modulation, speech codec and control applications 94 , 96 and 98 , respectively.
  • the application protocols 94 and 96 can take several forms, such as the G.711 pulse code modulation and the G.723 speech codec protocols, respectively.
  • the Real Time Streaming Protocol (RTSP) layer 97 can be included to provide enhanced performance in streaming media applications.
  • Control protocol 98 is used for session initiation and signaling and preferably takes the form the of the Session Initiation Protocol (SIP).
  • SIP Session Initiation Protocol
  • RTP is the preferred protocol for transporting real-time data across the Internet. See H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” Request for Comments (Proposed Standard, RFC 1889, Internet Engineering Task Force (January 1996) which is hereby incorporated by reference in its entirety.
  • RTP is a “thin” protocol providing support for applications with real-time properties, including timing reconstruction, loss detection, security and content identification.
  • RTP provides support for real-time conferencing for large groups within an intranet, including source identification and support for gateways, such as for audio and video bridges, and multicast-to-unicast translators.
  • RTP offers quality-of-service feedback from receivers to the multicast group as well as support for the synchronization of different media streams.
  • the combined stack of the IP, UDP and RTP protocols 88 , 90 and 92 add 40 bytes to every packet for low-speed links and highly compressed audio, and 20 bytes for 20 ms of 8 kb/sec. audio.
  • header compression is desirable.
  • the protocol stack 80 of FIG. 3 preferably employs the Session Initiation Protocol (SIP) for establishing multimedia exchanges with one or more parties.
  • SIP Session Initiation Protocol
  • addresses in the form user@domain or user@host This address, for example, can be identical to a person's e-mail address.
  • SIP provides the standard PBX or CLASS functionality, such as call forwarding, call waiting, caller M, call transfer, “camp-on,” “call park,” and “call pickup.”
  • “Camp-on” allows an attendant-originated or extended call to a busy single-line voice station to automatically wait at the called station until it becomes free while the attendant is free to handle other calls.
  • “Call park” allows a user to put a call on hold and then retrieve the call from another station within the system.
  • “Call pickup” allows stations to answer calls to other extension numbers within a user specified call pickup group. Many of these features actually require no signaling support at all, but can be implemented by end system software.
  • SIP is designed as a variant of HTTP/1.1, which allows easy reuse of HTTP security and authentication, content labeling and payment negotiation features.
  • SIP further employs a calendar-based call handler.
  • the call-processing software accesses a user's personal appointment calendar and answers the phone accordingly.
  • the user can define categories of callers and preset, based on the calendar entry, whether and where their calls are forwarded.
  • the information released to the caller if calls are not forwarded may range, for example, from “is currently not available” to “John Smith is in a meeting until 3 p.m. in Room 5621 with Jane Doe,” depending upon the caller's identity.
  • the call handler can also be integrated with a call processing language, a state-based scripting language that allows to construct voice-mail systems or automatic call handling systems in a few lines of code.
  • the call handler also manages the translation between ISDN calls and Internet telephony calls.
  • FIG. 4 is a high-level hardware block diagram showing a preferred embodiment of an packet data network telephone 100 according to the present invention.
  • the device 100 is a relatively low cost interface product to place voice and data onto a packet data network, such as Ethernet LAN's, intranets and the Internet. Therefore, the device 100 will generally be referred to as a network appliance to reflect the broad applicability of this stand alone device.
  • the network appliance 100 provides audio and video communications across a local area network (LAN), Internet or other Ethernet network, and generally includes: a network (e.g., Ethernet) controller subsystem 110 ; a digital signal processing subsystem 120 ; a signal conversion subsystem 130 ; and a user interface subsystem 160 coupled to both the signal conversion subsystem 130 and the digital signal processing subsystem 120 .
  • the telephone 100 further includes a power supply, ROM 142 and RAM 152 .
  • the user interface subsystem may include a speaker 161 , a microphone 162 and other user controls 169 as discussed below and with reference to FIG. 5 .
  • Interface circuitry 135 for data acquisition and control functions can also be coupled to the signal conversion subsystem 130 . Alternatively, such I/O circuitry can be directly coupled to DSP 120 .
  • the network controller subsystem 110 is interposed between the DSP 120 and the external data network and as such provides and receives data packets to and from the data (Ethernet) network.
  • the Ethernet controller subsystem 110 also instructs the digital processing subsystem 120 to accept data received from or to provide data to the Ethernet network.
  • the network controller subsystem can act as an initial gatekeeper by rejecting and discarding corrupted or unwanted data packets received from the Ethernet network.
  • FIG. 5 is a block diagram which illustrates the present network appliance in further detail.
  • a preferred embodiment of the network controller subsystem 110 includes an Ethernet controller 112 , a service filter 114 (10Base-T transformer) and at least one RJ-45 socket 116 .
  • the network controller subsystem 110 performs the following functions: interfacing the network appliance to the Ethernet network; sending and receiving Ethernet packets; informing the DSP subsystem 120 to accept the data when the data is available from the Ethernet; receiving the packets from the DSP subsystem 120 and sending same to the Ethernet; and rejecting and discarding unwanted packets from the Ethernet.
  • the Ethernet Controller 112 is preferably the AM79C940 Media Access Controller for Ethernet (MACE) available from Advanced Micro Device (AMD).
  • MACE Media Access Controller for Ethernet
  • AMD Advanced Micro Device
  • the MACE device is a slave register based peripheral. All transfers to and from the system are performed using simple memory or I/O read and write commands.
  • the MACE chip provides an IEEE 802.3 interface tailored to a specific application.
  • Individual transmit and receive FIFOs decrease system latency and support the following features: automatic retransmission with no FIFO reload; automatic receive stripping and transmit padding; automatic runt packet rejection; automatic deletion of collision frames; direct FIFO read/write access for simple interface to DMA controllers or I/O processors; arbitrary byte alignment and little/big/medium memory interface supported; and 5 MHZ-25 MHZ system clock speed.
  • the digital signal processing subsystem 120 includes a digital signal processor (DSP) 122 and related logical circuits, which include a read-only memory (ROM) 142 , a random access memory (RAM) 52 , and a erasable programmable logic device (EPLD) 124 .
  • DSP digital signal processor
  • the digital signal processing subsystem 120 provides the following functions: digital signal processing, such as speech compression; call progress tone generation, and ring signal generation; general “glue” logic to interconnect DSP, memory and I/O devices; network protocol processing; call flow control and finite-state-machine implementation; keypad activity detection and decoding; and display control.
  • the DSP 122 used in a preferred embodiment of the network appliance can be any suitable commercially available DSP, such as Texas Instruments' TMS320C32.
  • the TMS320C32 DSP has the following features: parallel multiply and arithmetic logic unit (ALU) operations on integer or floating-point data in a single cycle; general-purpose register file; program cache; dedicated auxiliary register arithmetic units (ARAU); internal dual-access memories (512 double words); two direct memory access (DMA) channels; one serial port; two timers; one external memory port; and a multiple-interrupt structure.
  • ALU parallel multiply and arithmetic logic unit
  • ARAU dedicated auxiliary register arithmetic units
  • DMA direct memory access
  • the TMS320C32 DSP includes four external interrupts and six internal interrupt resources.
  • the external interrupt can be triggered directly by the external pins.
  • the internal interrupt can be triggered by programming the individual peripherals, such as serial port, DMA controller, and timers.
  • all these interrupt sources can be programmed as the DMA channel interrupt via CPU/DMA enable register, IE.
  • the TMS320C32 DSP also includes a flexible boot loader which enables the main control program for the network appliance automatically loaded from one of three different external memory spaces or the serial port, whichever is appropriate as determined by the activity of the external interrupts of INT 0 to INT 3 when the DSP 122 is initialized, such as at powered on.
  • the DSP 122 is generally configured to include the following resource assignments.
  • External interrupts include: INT 0 : “System boot from 0x1000” indication. when the system is powered on and into is active, the DSP will boot the program from external memory space 0x1000; INT 1 : DMA 0 external interrupt signal, used for receiving packets from the network controller 112 ; INT 2 : DMA 1 external interrupt signal, used for sending packets to the network controller 112 ; INT 3 : AM79C940 packet state and error message interrupt.
  • a sample DSP memory map for use in an embodiment of the present network appliance is shown in FIG. 6 .
  • the present network appliance has the user interface subsystem 160 which includes: a key encoder 166 , a liquid crystal display (LCD) 164 and a hand set 163 , which includes a keypad 165 , a microphone 162 and a speaker 161 .
  • the user interface subsystem 160 components allow user interaction with the network appliance by providing the following functions: user interface for input (keypad) and output (LCD); voice interface; ring alert output through speaker; and handset or hands-free (microphone and speaker) communication alternative. Through this interface 160 user commands are entered and audio is sent and received to the user.
  • the LCD can have buttons adjacent to the display, such as on the side and below.
  • the function of these buttons can operate as “soft keys” the function of which depends on the current state of the system. For example, when not answering calls, the display can shown a quick dial list and the time of day. In addition, after calls have gone unanswered or been forwarded to voice mail, the display shows can show a list of received calls. During the call, any other incoming calls are displayed, allowing the subscriber to switch between calls or bridge the call into the existing call.
  • the user interface 160 of the present network appliance 100 can be configured with a small touch screen (not shown) to replace or supplement the LCD display and buttons.
  • the touch screen which graphically displays available functions and operations and responds to user contact on the display, provides an enhanced user interface, such as for the entry of alphanumeric network addresses and other telephony operations.
  • FIG. 5 also shows the signal processing system 130 , which includes PCM encoder and decoder that performs analog-to-digital (A/D) and digital-to-analog (D/A) conversion, and an audio amplifier 134 coupled to the handset and the corresponding speaker 161 and microphone 162 . Also provided is a power supply for providing positive and negative 5V voltage levels from a single AC or DC power supply adapter (“wall wart”). In the preferred embodiment of FIG. 5 , negative voltage levels are required by the LCD 164 and the PCM codec 132 .
  • FIG. 7 is a block diagram which illustrates a memory interface 700 suitable for use in the network appliance of FIG. 5 .
  • the memory interface 700 includes external memory modules 142 and 152 , which themselves include 128 Kbyte of read-only memory (ROM) 142 for program storage and at least 32 Kbytes of double word (32 bit) static random access memory (RAM) 702 , 704 , 706 and 708 . Due to the relatively slow speed of the ROM 142 , it is preferable that the network appliance initializes the main program from the ROM and stores this program in the relatively fast RAM for run time execution.
  • ROM read-only memory
  • RAM static random access memory
  • FIG. 8 is a block diagram that shows an exemplary interface between the DSP 122 and the Ethernet controller 124 in accordance with a preferred embodiment of the present invention.
  • the 32 registers of the Ethernet controller 124 are memory mapped at the 0x810000 memory space of the DSP 122 as shown in FIG. 6 .
  • the first two registers are receiving and transmitting “first in, first out” (FIFO) queues.
  • the DSP 122 exchanges the data with the Ethernet controller 124 via a 16 bit data bus 802 .
  • FIG. 9 is a schematic diagram which illustrates an interface between the DSP 122 and the PCM codec 132 in accordance with a preferred embodiment of the present invention.
  • the DSP 122 connects to the PCM codec 132 via an internal serial port 902 .
  • the serial port on the DSP 122 is an independent bidirectional serial port.
  • the DSP 122 is also operatively coupled to the LCD 164 .
  • the LCD control interface is mapped at the DSP addresses shown in FIG. 10 .
  • the LCD 164 is a 120 ⁇ 32 pixel LCD such as the MGLS-12032AD LCD, manufactured by Vazitronics. Since the access speed of the LCD is generally slow, data displayed by the LCD can be mapped into the STRB 0 (1X1000) memory space of the DSP 122 , which is the same memory space as ROM memory space.
  • the LCD timing logic is the same as the timing logic for the DSP 122 . However, when the LCD is composed of a left-half and a right-half, such as in the MGLS-12032, it is necessary to control and program for both of halves of the LCD when displaying an entire line message.
  • FIG. 11 is a block diagram showing the software architecture for the present network appliance. As shown in FIG. 11 , the processing architecture for the present network appliance is generally organized into three levels: the ISR (Interrupt Service Routine) level 1110 ; the operating system or Process level 1120 ; and the application or Task Level 1130 . An exemplary list of functions and tasks which can be performed at each of the software levels is provided in FIG. 13 .
  • ISR Interrupt Service Routine
  • the lowest level, the ISR level 1110 includes interrupt handlers and I/O interface functions.
  • the ISR level 1110 serves as the interface between the process level 1120 and the network appliance hardware shown in FIGS. 4 and 5 .
  • the process level 1120 or operating system, which is preferably a real-time multitasking micro-kernel, such as StarCom's CRTX Embedded Real-time micro-kernel.
  • the process level software 1120 (micro-kernel) performs memory management, process and task management, and disk management functions.
  • the micro-kernel supports three scheduling mechanisms: a Real-time Event Flag Manager 1222 ; a Delayed Task Manager 1224 ; and a Scheduling Manager 1226 .
  • the micro-kernel has three separate queues for the three different mechanisms above, respectively.
  • the Real-time Event Flag Manager 1222 is used to trigger the execution of real-time events by way of setting flags. If a flag is set to an “ON” condition, the task associated with the flag is immediately executed. For example, an interrupt service routine would set a particular flag when a certain event occurred. Flag events are entered on a flag queue with an associated task address.
  • the Delayed Task Manager 1224 is responsible for timed events.
  • a timed task such as a fail-safe or “watchdog” task, can be executed after a certain time delay. If a certain event does not occur within a certain time frame, the timer triggers the task causing it to be executed.
  • Another example is the repeated execution of a task controlled by a periodic timer. In an exemplary embodiment, there are 10 timer entries. Each timer is loaded with a tick count and is then decremented on every timer tick from the hardware's interval timer. When the count reaches zero, the task associated with the timer is scheduled on the task queue.
  • the Scheduling Manager 1226 scans the task schedule queue looking for scheduled tasks. Upon discovery of an entry in the queue, control is passed to a scheduled task.
  • FIGS. 13 a - f are tables which list exemplary software tasks and functions which can be part of the task level software ( FIGS. 13 a - c ), process level software ( FIG. 13 d ) and ISR level software ( FIGS. 13 e - f ).
  • the terms “task” and “function” as referred with respect to the software architecture are considered to be synonymous.
  • “tasks” are generally executed by the Scheduling Manager 1226
  • “functions” are generally called by tasks or other functions.
  • the application tasks such as the call processing (Call_task) and IP processing (IP_Send_task and Ercv_task, etc.) tasks, are scheduled by the Process level software 1120 .
  • the execution of such tasks is a result of a prior scheduling by an ISR, another task, or by the current task itself.
  • FIGS. 13 A-F illustrate exemplary function and procedure definitions called in an event driven operation performed by the present packet data network telephone software of FIG. 11 .
  • the functions which are called on the occurrence of various events, enable operation of the packet data network telephone/system and include gross operations such as: initializing the Packet data network telephone/system; processing ARP data; encoding voice data; processing message data; processing IP data; decoding voice data; transferring analog and digital data to and form corresponding buffers; and performing “watchdog” functions.
  • Initialization of the packet data network telephone appliance includes the steps of hardware initialization and task scheduling. After power on, the DSP 122 will automatically transfer the main program from the ROM 142 to the RAM 152 (boot operation). Hardware initialization occurs in a traditional manner, including the steps of: initializing the stack pointer, external bus interface control register, global control register of the DSP, interrupt vector for the ISR, and the like.
  • processing control is returned to the process level (micro-kernel) 1120 .
  • the CRTX micro kernel 1120 and the scheduled tasks then control further processing.
  • the task level software of the present network appliance includes Address Resolution Protocol (ARP) processing.
  • ARP is a known TCP/IP protocol used to convert an IP address into a physical address (called a Data Link Control (DLC) address), such as an Ethernet address.
  • DLC Data Link Control
  • a host computer wishing to obtain a physical address broadcasts an ARP request onto the TCP/IP network. The host computer on the network that has the IP address in the request then replies with its physical hardware address.
  • FIG. 14 is a flow diagram illustrating of an ARP request output procedure 1400 , ARP_Out( ).
  • ARP_Out( ) is a component of the task level software which receives an IP address to be resolved, and outputs a corresponding MAC address.
  • the ARP_Out( ) function first checks the requested IP address from a local ARP cache table, arptable (step 1404 ). If the corresponding entry is RESOLVED at step 1406 , then ARP_Out( ) copies the MAC address from arptable to the requested parameter and returns a ARPOK status flag (step 1408 ).
  • the procedure will allocate an entry in the arptable and schedules a ARP request (step 1410 ).
  • a MAC address, i.e., “handle,” of the arptable is returned to the main program (c_int 00 ( )).
  • the software checks the corresponding entry's ae_state.
  • FIG. 15 is a flow diagram of an exemplary ARP request input procedure 1500 , ARP_In_task( ), which is a component of the task level software listed in FIG. 13 A.
  • the ARP_In_task receives an ARP packet, and either modifies the arptable or queues an ARP reply if the incoming packet is an ARP request.
  • the software will check whether the packet's ARP hardware or protocol types match (step 1504 ). If the types do not match, control is returned to the main program (step 1506 ). If one or both of the types match, then the software checks if the destination host is the present host (step 1510 ). If the destination host is not the present host, then control is returned to the main program (step 1508 ).
  • the ARP_In_task next checks the ARP table to determine whether there is a corresponding ARP entry for the incoming packet (step 1512 ). If an entry is found (step 1514 ), then the new MAC address is copied into the existing entry and modifies the entry's “Time to Live” (TTL) to a new value (step 1516 ).
  • TTL is understood by those with skilled in the art to be a field in the Internet Protocol (IP) that specifies how many more hops a packet can travel before being discarded or returned to the sender.
  • IP Internet Protocol
  • the ARP_In_task adds a new MAC entry in the ARP table (step 1518 ). If the MAC entry is in a PENDING state (step 1520 ), it is then changed to a RESOLVED state and the MAC address is copied to the target entry (step 1522 ). If the incoming ARP packet is an ARP request from another host, an ARP reply packet is sent by queuing the IP_Send_task, steps 1524 and 1526 . Control is then returned to the main program (step 1528 ).
  • ARP processing at the task level includes an ARPTimer_task( ), which is a delayed loop task used to maintain the ARP entry table arpentry. Nominally, the ARPTimer_task( ) is generated once per second. The main purpose of the ARPTimer_task( ) is to decrease the “Time to Live” (TTL) of the ARP entry and to resend the ARP request during the pending state in case the previous ARP request is lost.
  • TTL Time to Live
  • Task level processing can also include processing operations associated with the coding and decoding of audio packets.
  • the Codec_task generally includes a SpeechEncode( ) function, which encodes speech data from the ADBuf buffer to the EncodeBuf according to the algorithm indicated by “type” parameter. The coded data is then sent out via the queue IP_Send_task, with the “RTP” parameter set.
  • Task level operations can also include Internet protocol (IP) processing.
  • IP processing includes the steps of: transmitting and receiving Ethernet packets, step 1602 ; multiplexing and de-multiplexing IP packets, step 1604 ; and packetizing and de-packetizing Ethernet, Internet Protcol (IP), User Datagram Protocol (UDP), Real-Time Transport Protocol (RTP) and Address Resolution Protocol (ARP) packets, step 1606 .
  • IP Internet Protcol
  • UDP User Datagram Protocol
  • RTP Real-Time Transport Protocol
  • ARP Address Resolution Protocol
  • Ethernet packet transmission can be performed using direct memory access (DMA) channels of the Ethernet controller 112 .
  • DMA is a technique for transferring data from main memory to a device without passing it through the CPU. Since DMA channels can transfer data to and from devices much more quickly than with conventional means, use of DMA channels are especially useful in real-time applications, such as the present network telephony system.
  • the network controller 110 preferably supports a plurality of DMA channels, such as the DMA 1 channel of the Ethernet controller 112 that can be used for packet transmission.
  • DMA 1 ( ) function an ISR level function, is called by setting the source address (Ethernet packet buffer, ESend), destination address (Ethernet controller's transmit FIFO), and a counter (the packet length). Examples of Ethernet transmit data structures are provided in FIG. 17 .
  • the DAM 1 ( ) function then starts the DMA 1 channel. When the counter reaches zero, the DMA 1 stops and waits for the next call.
  • FIG. 18 is a block diagram which shows the data flow between an audio input buffer 1802 , a UDP buffer 1804 and ARP table 1806 to the Ethernet interface (Ethernet Transmit FIFO) of the Ethernet network controller 112 .
  • data from the audio input buffer 1802 , the UDP buffer 1804 and the ARP table 1806 is sent to an IP output queue 1810 , and is arranged to indicate the protocol type, source pointer and data length.
  • the IP_Send_task is queued by process level software (micro-kernal) 1120 .
  • the protocol types supported by the IP_Send_task generally include UDP, RTP, ARP_REQUEST, ARP_REPLY.
  • IP_Send_task is used for packet transmission and Ethernet packetizing.
  • IP_Send_task is scheduled by other tasks or functions such as SIP_task, ARP_Out( ), SpeechEncode( ), etc.
  • SIP_task is scheduled by other tasks or functions such as SIP_task, ARP_Out( ), SpeechEncode( ), etc.
  • the IP_Send_task checks the protocol type of the data. This task then encapsulates the output data into the corresponding Ethernet packet in the ESend buffer. Finally, the packet is sent out via the assigned DMA channel (DMA 1 ).
  • DMA 1 DMA channel
  • FIG. 19 is a data flowchart further illustrating packet receiving and de-multiplexing operations.
  • the de-multiplexing is realized by scheduling different tasks for different protocols in the Ercv_task.
  • Ethernet packets are received in the receive data FIFO memory (step 1902 ) and are further processed by a DMA 0 channel controller (step 1904 ). Since the DSP 122 doesn't know when the packets will arrive, the DMA 0 channel is active all the time (i.e., it does not stop even the counter reaches zero). When a packet arrives, the DMA 0 channel will automatically copy it from the Ethernet controller's receiving FIFO to the Ethernet receiving buffer, Ercv (step 1906 ). The DMA 0 channel stops when there is no data available in the FIFO.
  • ERcv_task is a flag trigger task for Ethernet packet de-packetizing and IP packet de-multiplexing (step 1908 ).
  • the Ercv_task functions as follows: first, a PacketCheck( ) function is called to check the incoming packet. The PacketCheck( ) will return the protocol type of the packet, or NULL if the packet is invalid. Second, depending on the returned protocol type, the ERcv_task will trigger the different tasks to process the received packet, RTP_In_task for “RTP” packet (step 1910 ), ARP_In_task for “ARP” packet (step 1912 ) or UDP processing tasks (step 1912 ) for UDP packets, for example.
  • SpeechDecode( ) is a voice decoding function associated with the RTP processing of step 1910 .
  • a SpeechDecode( ) task checks if there are data available in the decoding buffer, DecodeBuf. If data is available, e.g., RcvFlag is SET, then SpeechDecode( ) decodes it according to the data type of receiving data, PCM (G.711), G.723, G.729, for example. The decoded data is sent into the D/A buffer, DABuf.
  • the A/D and D/A interrupt routine can be triggered by an internal interrupt source, e.g., Rint 0 ( ).
  • the A/D and D/A interrupt routine is triggered by an 8 kHz sampling frequency provided by the DSP. Since this routine is called frequently, Rint 0 ( ) is preferably written in assembly language.
  • the steps performed by Rint 0 ( ) include the steps of: reading a D/A sample from D/A buffer, DABuf; sending the sample to the serial D/A port; obtaining a sample from the serial A/D port; saving the A/D sample to an A/D buffer, ADBuf; and incrementing A/D and D/A buffer pointers, ADPnt and DAPnt, by one.
  • FIGS. 20A and 20B are block diagrams which show an A/D and D/A “ping-pong” buffer scheme used by the software of the present invention. Further, if the current A/D pointer value (ADPnt) exceeds a predetermined buffer threshold (ADTh) then a flag is set in the flag task queue indicating that service is required.
  • ADPnt current A/D pointer value
  • ADTh predetermined buffer threshold
  • the A/D and D/A buffers can be divided into two parts, the upper buffer 2002 a and lower buffer 2002 b , respectively. Both buffers can be designed as circular buffers. In this way, when the current pointer reaches the buffer bottom, it wraps around to its beginning. However, from the encoder and decoder point of view, it is used as a two-frame ping-pong buffer (defined as upper frame and lower frame) scheme. The operation of this process is shown in FIGS. 20A and 20B . For A/D conversion, when the upper (or lower) is full, the data in the upper (or lower) buffer will be passed through ping pong switch 2004 and copied to the speech encode buffer, EncodeBuf 2006 .
  • a new frame of data will be copied from the speech decode buffer, DecodeBuf, 2010 to the upper 2008 a (or lower 2008 b ) buffer.
  • This mechanism ensures that while the encoding (or decoding) algorithm reads(writes) from one part of the buffer, the A/D (or D/A) sampling ISR can write (read) the other part of the buffer without conflict.
  • FIG. 21 is a state transition diagram of a Call_task subroutine used in an exemplary embodiment of the present network appliance.
  • Call_task is a looped task which handles the call procedure.
  • the “Idle” state 2102 occurs when there is no call being made and there is no incoming call.
  • the Call_task loops in the “Idle” state 2102 .
  • the “DialTone” state 2104 exists when the receiver state is OFFHOOK, or the handset state indicates HANDSFREE, and thus the Call_task state will change from the “Idle” state 2102 to the “DialTone” state 2104 when a OFFHOOK or HANDSFREE condition exists.
  • the call state changes from the “DialTone” state 2104 to the “GetDigit” state 2106 .
  • the dial tone is stopped at the handset.
  • the Call_task will check if the input is valid. If the number is valid, a call entry is created by a function CreateSipCall( ) and the Call_task will go into a “SIP” state 2108 . Otherwise, if the input number is invalid, the number is requested again and the state remains at the “GetDigit” state 2106 .
  • the “SIP” state 2108 is a global variable, SIP status, which is modified by the SIP_task according to its state transition. If the “SIP” state 2108 changes into SIP_Ring, the Call_task will change to the “RingBack” state 2114 and the Codec_task will be configured as “ToneMode, RingBack” mode. When the Codec_task is in the “ToneMode, RingBack” mode, a ring back tone is sent to the handset.
  • the Call_task state changes to the “Talk” state 2116 .
  • the Codec_task will configured as SpeechEncode and SpeechDecode mode.
  • the Call_task state changes to the “Ring” state 2114 and the Codec_task will be configured as “ToneMode, RingTone.”
  • the Codec_task is configured as “ToneMode, RingTone”
  • a ring tone will be played on the loudspeaker.
  • the SIP state becomes SIP_Connected
  • the Call_task state will change into the “Talk” state 2116 . Otherwise, if the SIP state becomes SIP_Cancel, which happens if the caller gives up the call, the Call_task state returns to the “Idle” state 2108 .
  • the Call_task changes to the “Idle” state 2102 , regardless of what the previous state is (except the “Ring” state 2114 ).
  • the key pad of the telephone has 17 keys for providing user inputs and commands.
  • the telephone key pad includes 10 digit keys, two special keys and five function keys are defined as shown in FIG. 22 .
  • the Key_task is a loop delayed task which runs periodically, such as every 0.1 seconds.
  • Key_task first calls the key( ) function. If the return value is not “ ⁇ 1”, it means a key has been pressed. Then, the KeyMap( ) function maps the input binary key word to the ASCII key word. The Key_task then sets the corresponding member of the FuncKey structure. If the system is ready to accept the key input (the KeyRegEnable is indicated), the input key word is stored into the KeyBuf.
  • Key_task preferably supports four different input modes: digit input mode, IP address input mode, alphabet input mode, and list address input mode. Switching among the four modes can be done by pressing the ENTER button before dialing any number or alphabet when the handset is picked up and a dial tone is heard. After input is complete and the ENTER button is pressed, the input numbers will be transferred to the current task (Call_task or Setting_task) by a message pipe. If the Redial key is pushed, the task will copy the previous input from the backup buffer, KeyBackup, to the KeyBuf. Then the data will be transferred to Call_task.
  • the operating system of the present network appliance preferably supports a delayed task schedule scheme.
  • the delayed task is similar to the sleep( ) function in UNIX. However, a delayed task can also be a persistent task execution from a periodic timer when the task's repeating flag is set.
  • the process level software 1120 requires an interval timer to provide a system tick.
  • the system of FIG. 5 uses the TMS320C32's timer 1 , TCLK 1 , as the system timer base.
  • the Clock_task is a looped delayed task which performs real time clock and calendar functions. It serves as the general clock to calculate and display the current time, including the hour, minute and second. When a call is connected, it can display the call duration. When the phone is on hook, current year, month and date can also be displayed on the LCD.
  • the Network telephone software of the present invention includes several low-level functions that are included as part of the software ISR level. Some of these low-level functions are I/O related functions, which are used with the telephone's 8-bit I/O parallel port defined in FIG. 24 .
  • the low-level, I/O related functions include: the “Hook” state monitor, Hookst( ); the Key input availability check and read, Key( ); handset and hands-free control, HandSet( ); Ethernet controller reset, ENET_reset( ); volume control, AmpControl( ); and software reset of the system.
  • the audio interface chip 136 which preferably takes the form of an LM4830, can be used to control switching between the handset and the hands-free mode.
  • the HandSet( ) function can write a ‘0’ to the I/O port when “hands-free” mode is required or write a ‘1’ to the appropriate port when “handset” mode is required.
  • the low-level functions of the present invention also include the Ethernet controller interrupt ISR, c_int 03 ( ).
  • the global message structure for use with c_int 03 ( ) is defined for the state of the Ethernet controller as shown in FIG. 25 .
  • the Ethernet controller will interrupt the DSP 122 to indicate the interrupt.
  • the DSP 122 will read the transmission and receiving states from the Ethernet controller's register and then store the state into the above state structure. This information can be checked by other tasks. In addition, these messages are read after each packet transmission. Otherwise, the Ethernet controller will be blocked.
  • the present network appliance of the present invention uses the RTP protocol to transmit and receive speech packets in real time.
  • the RTP packet is encapsulated in an UDP packet.
  • the IP_Send_task and the RTP_In_task modules operate to create and parse RTP packets.
  • FIG. 26 shows an RTP header structure for RTP packet processing.
  • the IP_Send_task gets a request to send a RTP packet, it first generates an Ethernet and UDP header. Next, it adds the RTP header in the Ethernet packet transmission buffer. Finally, the RTP data is copied into the RTP data area and is sent over the data network.
  • FIG. 27 shows a data structure for use with a tone generation function, Tone_task( ). The parameters described in FIG. 27 are illustrated in the tone generation timing diagram of FIG. 28 .
  • Tone_task is a delayed task which can be executed about every 0.1 second. It is used to count the tone active and stop duration defined in the ToneType structure. Tone_task sets ToneState to ACTIVE during burst and STOP during silence. Different active and stop duration generates different tones. They are: Dial tone, continuous tone (no stop); Busy tone, burst 0.5 s and silence 0.5 sec; Ring back tone, burst 2 sec and silence 4 sec; Ring signal, burst 0.8 sec twice in two seconds, then silence 4 sec.
  • a ToneGenerate( ) module Preferably, a ToneGenerate( ) module generates a one frame 400 Hz tone or a 2400 Hz ring signal defined by “mode” parameter when ToneState is ACTIVE. Otherwise, one frame silence signal is provided.
  • the network appliance of the present invention uses UDP as its transport protocol for SIP.
  • SIP_task is a looped task that handles SIP signaling. Since the present network appliance can be used either as a caller or as a callee, SIP_task operates both as a UAC (User Agent Client) and a UAS (User Agent Server).
  • UAC User Agent Client
  • UAS User Agent Server
  • FIG. 29 is source code which shows data structures used for processing the SIP requests or responses in accordance with the SIP protocol.
  • Tstate is the state transition structure used in SIP_In_task and SIP_task for SIP state transition. Parsed SIP messages are in the data structure message_t.
  • the structure call is defined for each call and the total call entries are defined by msg[MaxSipEntry].
  • FIG. 30 shows a state transition diagram of the SIP_task operating as a client (e.g., a caller).
  • a call entry msg[CurrentIndex] is allocated when the phone is picked up and the flag of the call is SET;
  • CreateSipCall( ) creates a SIP packet according to current setting and dial inputs, wherein the SIP package is used as the reference of the call and the us_state is set to UAC;
  • SIPParse( ) generates the message structure (msg[CurrentIndex].m) for the call from above packet;
  • the SIP_task will check if there are any active calls—if there is a call (msg[i].flag is SET), SIP_task will create the corresponding request according to the SIP specification and the SIP states will be updated in SIP_task as shown in FIG. 30 .
  • FIG. 30 shows an exemplary state diagram for client (caller) operations, referred to as a UAC state transition diagram of SIP_task.
  • a Calling state is entered and a SIP_task retransmits a SIP INVITE request periodically (T 1 ) until a response is received (step 3004 ).
  • T 1 is 500 ms initially and doubles after each packet transmission.
  • T 2 is nominally 32 seconds. If the client receives no response, SIP_task ceases retransmission when T 2 timer expires and SIP state will be changed to Cancel (step 3008 ). If the response is provisional, the client continues to retransmit the request up to seven times.
  • the state When a final response is received, the state will change to Completed and a ACK will be generated (step 3010 ). When the caller gives up, the state will changed to Bye state (step 3012 ). BYE requests are also retransmitted during the interval of T 1 until T 2 expires for the purpose of reliable transmission.
  • the variable, SIP_Status will be changed according to the response received as shown in FIG. 31 . For example, if a 3xx response is received, SIP_task will initiate another call to the redirected address. Other final responses can be displayed on the LCD.
  • the SIP_task When the network appliance receives a call, the SIP_task functions as a SIP UAS (server).
  • the incoming packets are processed as follows: UDP_In_task accepts the incoming UDP packet and sends the packets to SIP_In_task along with its source IP address and port number.
  • SIP_In_task processes the packet according to the SIP specification and updates the states accordingly.
  • SIP_task will monitor the receiver state, set and decrease the T 1 and T 2 timer of each call and update the SIP states if necessary.
  • FIG. 32 illustrates an exemplary state transition diagram of a SIP UAS. While the SIP_task remains at an Initial state (step 3205 ), it listens to the incoming SIP packets. If an INVITE request is received, it generates a Ringing( 180 ) response and its state changes to Invite and the Sip task module would advance to a Proceeding step (step 3210 ). If a called party picks up the telephone, the status changes to Picks Up and the process advances to Success (step 3215 ), indicating a successful call session has been established. If the called party does not pick up, the status changes to Failure and the process advances to the Failure state (step 3220 ).
  • the client will acknowledge the current status and advance the process to the Confirmed state (step 3225 ).
  • the status changes to Onhook and the process advances to Bye (step 3230 ) indicating that the current session has been completed.
  • the network appliance is a stand alone device capable of initiating and receiving telephone calls on a packet data network. While the stand alone architecture described herein offers many attendant advantages, such as its relatively low cost to implement, similar software architecture and functional definitions described in connection with the stand alone appliance 100 can also be provided on a PC based telephone device. In such a case, a conventional personal computer having a microphone, speakers and suitable network interface card, is provided with software to operate consistently with the manner described above. Of course, obvious changes are effected in this embodiment, such as the user interface components and functions being performed by conventional elements of the PC, e.g., the keyboard, monitor, mouse and the like. A GUI interface to the telephone functionality is provided by the software to enable the desired telephony functions.
  • the network appliance of the present invention in addition to performing traditional telephony functions, can also provide a cost effective interface between the network and the environment. While equipping sensors with Ethernet interfaces is not feasible, due to the large number of ports required and the cost of the minimal hardware required, the network appliance of the present invention can become the gathering point for a number of digital and analog sensors. This is accomplished generally by coupling the external sensor to the network appliance via the conventional I/O circuitry 135 which is coupled to the DSP 122 .
  • the I/O circuitry can take the form of simple buffers, A/D converters, registers and the like. This feature is particularly useful in environments that have phones for security reasons, e.g., elevators, lobbies, shop floors, garages, etc.
  • PIR Passive infrared
  • the present network appliance provides a point of system integration.
  • the I/O circuitry can be compatible with local control protocols such as the X10 and CEbus protocols which are recognized standards for controlling line-powered devices such as lighting or appliances. Adding such and interface to the phone provides for network-based control of such devices.
  • FIG. 33 illustrates a system employing the present network appliance for establishing calls between two or more parties on the network.
  • the system generally includes one or more stand alone network appliances 100 , such as described above.
  • the system can also include PC based telephony devices 3320 , such as a network enabled PC operating suitable network telephony software which is protocol compliant with the network appliance 100 .
  • Each telephony endpoint can be referred to as a node and has a specific SIP address. By employing this specific address, any node acting as a calling party (client) can directly initiate a call session with any other node on the network (server).
  • the system preferably also includes a redirect server 3325 which can be accessed by the various nodes on the network to provide enhanced services, such as a directory service, call forwarding, call branching, call messaging and the like.
  • a calling party wishing to initiate a call to JOHN SMITH can enter the SIP address for that person if it is known, such as sip:john.smith@work.com. If, on the other hand, the calling party does not know the SIP address of the party, the calling party can contact the redirect server 3325 with a request to begin a session with JOHN SMITH.
  • the redirect server includes databases with registration information for various parties and can return the SIP address to the calling party or forward the call request to the proper SIP address.
  • the called party may have multiple sip addresses such as john.smith@home, john.smith@office, john.smith@lab and the like.
  • the redirect server can provide a session initiation signal to each of these addresses and establish a connection between the calling party and the first contacted node that responds to the initiation request.
  • parties can periodically register with the redirect server to indicate the current SIP address where they can be contacted (call forwarding feature).
  • the network appliance 3305 can be configured to interface to one or more sensors 3310 . Signals from the sensors are received by the network appliance 3305 and can be sent along the network to a desired network node. The signals from the sensors can be detected periodically by a timer in the network appliance and sent to a SIP address stored in memory. Alternatively, the sensor signals can be measured by the network appliance 100 based on a command received from another node (polled by a remote network node) or can be measured based on a received interrupt signal indicating a change of state of the sensor (interrupt driven). For example, the network appliance 100 can be used as a security system communication device which reports the status of various security sensor points to a central monitoring station.
  • the appliance can periodically check the status of the connected sensors, such as door sensors, fire sensors, passive infrared detectors and the like, and report to a central station node the current status.
  • the appliance 100 could generate a call session with the central station and report this condition as well.
  • the same appliance which is acting as an alarm communicator can also provide full telephony functions as well.
  • SCADA site control and data acquisition
  • the network appliance of the present invention can be equipped with a rechargeable battery, possibly integrated into a wall transformer.
  • the network appliance of the present invention should provide a two-port Ethernet hub, with an external RJ-45 interface. This provides for simultaneous operation of both the telephony device and network enabled computer.
  • the present network appliance can also receive and transport video data.
  • a video input interface either analog or through a USB (Universal Serial Bus) can be operatively coupled to DSP 122 to implement this feature.
  • USB Universal Serial Bus
  • the present network appliance 100 can also be coupled to a suitable wireless Ethernet interface to allow the equivalent of a cordless phone.
  • DHCP and RARP for automatic assignment of IP addresses
  • IGMP for subscribing to multicast groups
  • RTSP for retrieving voice mail and distinctive ringing signals
  • SAP for listening to announcements of multicast “radio” events
  • DNS for name resolution (subject to available program memory space).
  • the present network appliance can also provide high level telephony functions.
  • a “Do not disturb” feature can be provided that automatically forwards calls for a given duration to a designated location as specified by a SIP address input by the user.
  • a predetermined interval e.g. 15 minutes.
  • “Call logging” can also be provided wherein the SIP address and related information regarding incoming calls is logged by storing the information in memory, with the ability to call back the calling party by scrolling through the list and selecting the SIP address of the caller from the log by user interaction via the user interface subsystem 160 .
  • the network appliance can also include an “Automatic address book.” Through user input or via a server connected on the network, the network appliance can acquire a speed dial list or a list of names stored in its local memory which a user can scroll through (using the SIP “multiple choices” response);
  • An “Interface to voice mail system” feature can display all unanswered calls that have come in, including the time of call, the caller, the subject and urgency of the call and whether the caller left voice mail. Calls can be ordered chronologically or by urgency.
  • the call display preferably features five soft buttons: to delete the entry, to move forward and back through the list, to return the call and to retrieve the message.
  • “Distinctive ringing” is a feature wherein the appliance 100 is programmed to announce certain callers by a distinct sound clip, such as a distinctive ring, melody or the name of the caller.
  • a distinct sound clip such as a distinctive ring, melody or the name of the caller.
  • a small database associates a caller, or a class of callers (e.g., friend, customer, urgent) to a particular selected ring response.
  • the sound clip is played either from memory or retrieved from a server;
  • Call forwarding is a further feature which can be implemented in the appliance 100 .
  • calls are forwarded by the proxy redirect server.
  • the network appliance 100 can also perform simple forwarding itself, as described above for the “do not disturb” button.
  • the redirection may take the form of calling the phone from another phone with a REGISTER command, to implement follow-me calls.
  • automatic forwarding of calls from certain domains or during certain hours is readily implemented without use of a redirect server.
  • Intercom mode is a feature where incoming calls are “picked up” automatically, with the microphone disabled until a push-to-talk button is pressed or the receiver is lifted. This can also be used as part of a security public address system.
  • “Baby monitoring” features allow the network appliance to act as a remote audio monitoring device. For example, on receipt of an incoming call, the network appliance 100 is activated with the speaker disabled but with the microphone automatically enabled such that the calling party can listen to the environment where the called appliance is located. This feature can be selectively engaged, such as by a predetermined code or caller identity;
  • An “Internet radio” feature allows the network appliance 100 to automatically play radio stations supplied by a local RTP multicast server or other streaming media source when a call is not being received or initiated.
  • the appliance 100 can listen for SAP announcements and can display the station list on the display, with soft buttons. Any incoming phone call interrupts the current radio program.
  • the present network appliance can also maintain a “Callee list.” If a previous call was successful, the callee's address is automatically entered into a portion of memory used as a local guide-dial list. When this party is to be dialed again, the callee can be selected by the upward or downward key from the callee's list. This is generally a FIFO type memory structure which automatically purges old entries and replaces them with more current entries; and
  • Speech processing enhancement such as silence suppression, comfort noise generation, and echo cancellation can also be included in the present network appliance in a manner which is well known in the telephony art.
  • a network-based telephone that is a stand-alone “Internet appliance” that allows the user to make phone calls within a local area network (LAN) or across the Internet has been disclosed.
  • DSP digital signal processor
  • Its core is a single digital signal processor (DSP) (a microcontroller optimized for processing audio and video data). It provides services that are a superset of those of a regular telephone, but connects and Ethernet data network instead of to the PSTN (Public Switching Telephone Network). Since Ethernet running at 10 Mb/s can use the same twisted-pair wiring used for analog and digital phones, the Packet data network telephone does not require rewiring customer premises.
  • a minimal system consists of two Packet data network telephones connected by an Ethernet cross-over cable.
  • a multi-line basic PBX can be implemented consisting of any number of Packet data network telephone connected to an Ethernet hub or switch.
  • This “PBX” can scale to any number of phones, simply by adding Ethernet capacity and ports.
  • the Packet data network telephone shares the Ethernet with other LAN services. In almost all cases, voice traffic will be a small fraction of the network capacity. (A single voice call consumes about 16 kb/s of the 10 Mb/s capacity.)
  • the Packet data network telephone offers voice communications, implementing the customary features of PBXs.
  • the present network appliance may use a server located in the LAN or the Internet to provide additional functionality, such as user location and directory services, call forwarding, voice mail, attendant services.
  • a PBX based on the current network appliance can reach traditional phones through an Internet Telephony Gateway (ITG).
  • ITG Internet Telephony Gateway
  • Such a gateway connects to the PSTN using either analog lines, ISDN basic or primary rate interfaces or digital trunks (such as T1/E1).
  • ITGs have recently been introduced as commercial products, with capacities of one to about 240 lines.

Abstract

A network appliance (100) is provided having a network controller subsystem (110) for coupling the appliance (100) to a data network for providing and receiving data packets to and from a packet data network. A digital signal processing subsystem (120) is coupled to the network controller subsystem (110). A signal conversion subsystem (130) is coupled to the digital signal processing subsystem (120) and a user interface subsystem (160) is coupled to both the signal conversion subsystem (130) and the digital signal processing subsystem (120). The digital signal processing subsystem (120) operates under the control of a computer program which is capable of detecting incoming calls, initiating call sessions, and preferably, implementing advanced telephony features.

Description

    FIELD OF THE INVENTION
  • The present invention relates in general to the field of Internet and intranet telephony. More particularly, the present invention relates to a network telecommunications appliance and system for Internet/intranet communications.
  • BACKGROUND OF THE INVENTION
  • Over recent years, the Internet has evolved from a convenient additional means of communications to an essential communication tool in the business, technical and educational fields. In this regard, a growing segment of the Internet relates to Internet telephony which provides a number of advantages over conventional circuit-switched network controlled by a separate signaling network. For one thing, parties are allowed to more easily select and use encoding and other data compression techniques that are most appropriate for their quality needs. Parties may, for example, decide that for international calls, they would trade lower cost for full toll quality, while a reporter calling in her story to a radio station may go for full FM quality with little regard for price. Even without quality degradation. 5.3 kb/s (G.723.1) to 8 kb/s (G.729) are sufficient to support close to toll quality as opposed to 64 kb/s for conventional landline telephone networks. This flexibility also has the advantage that during severe network overload, e.g., after a natural catastrophe, telephone customers can still communicate at about 3 kb/s, thus increasing network capacity twenty-fold.
  • While it is logical to extend telephony services to existing data networks, such as the Internet, because of the intelligence required in the end systems, cost poses a major disadvantage. Previously, it has been difficult to build packet voice “telephones” requiring no external power that operate over low-grade twisted pair wires several miles long at the cost of a basic analog phone.
  • In addition, the majority of known Internet telephony products are designed to operate in accordance with the H.323 signaling and control protocol. The H.323 protocol is a complex protocol which is difficult to use and implement. As a result of this complexity, different implementations of H.323 devices may be adversely affected by compatibility issues. In addition, devices operating under the H.323 protocol cannot communicate directly with one another, calls must be processed and routed by a telephony server.
  • According, there remains a need for a network telephony appliance which is low cost, operates using a simple signaling protocol and offers a vast set of advanced telephony features.
  • SUMMARY OF THE INVENTION
  • The afore described limitations and inadequacies of conventional telephone systems and known Internet telephony systems are substantially overcome by the present invention, in which a primary object is to provide a packet-based voice communication system for use over the Internet and intranet telecommunications networks.
  • It is another object of the present invention to provide a packet data telephony appliance for use over a data network, such as an Ethernet network.
  • It is still another object of the present invention to provide a communication protocol for use in a packet-based telecommunication system.
  • It is yet another object of the present invention to provide an Internet protocol architecture which supports telephony and other continuous-media or streaming media services such as “Internet radio” and “Internet TV.”
  • It is yet another object of the present invention to provide a low cost, stand alone network telephony appliance capable of direct calling of another network telephone station or indirectly calling another network telephone station party, such as through a redirect server.
  • In accordance with a first embodiment of the present invention, a network packet data telephone apparatus is provided that includes: a network controller, such as an Ethernet controller subsystem, coupled to a data network for providing and receiving data packets to and from the network. A digital signal processing subsystem is coupled to the network controller subsystem and operates under a computer program for detecting incoming calls, initiating call sessions and implementing telephony features. A signal conversion subsystem is coupled to the digital signal processing subsystem for converting digital packet information into analog signals and vice versa. A user interface subsystem is coupled to both the signal conversion subsystem and the digital signal processing subsystem for providing user control and feedback to the apparatus. This stand alone network telephony device is referred to herein as a network telephony appliance.
  • Preferably, the computer program of the network telephony appliance implements the Session Initiation Protocol (SIP). In this case, a unique SIP address is associated with the device and session initiation and control are performed in accordance with the SIP protocol.
  • The network telephony appliance preferably implements high level telephony functionality including a monitoring feature, call forwarding, streaming audio mode, caller log, callee log and the like.
  • Preferably, the network telephony appliance includes sensor interface circuitry for receiving signals from remote sources, such as sensors. The signals received from the remote sources are processed by the network telephony appliance and sent to an appropriate network destination.
  • In another aspect of the present invention, a communication protocol is provided for use in a packet-based telecommunication system, the communication protocol having: an Ethernet protocol layer; an Internet Protocol (IP) layer stacked on top of the Ethernet protocol layer for interfacing with the Ethernet protocol layer; an Address Resolution Protocol (ARP) layer stacked on top of the Ethernet protocol layer for interfacing with the Ethernet protocol layer and the IP layer, and for translating IP addresses into Media Access Control (MAC) addresses; a User Datagram Protocol (UDP) layer stacked on top of the ARP and IP layers for interfacing with the ARP and IP layers and for providing real-time transport of application data and controls within the telecommunication system; a Real-Time Transport Protocol (RTP) layer stacked on top of the UDP layer for interfacing with the UDP layer and for providing real-time audio data transport within the telecommunication system; one or more control protocol layers stacked on top of the UDP layer for interfacing with the UDP layer and for signaling and providing registration of the real-time audio data; and one or more application protocols stacked on top of the RTP layer for interfacing with the RTP and for formatting the real-time audio data.
  • In another aspect of the present invention a network telephony system architecture is provided. The system includes at least two network telephony devices, such as a the present network telephony appliance and/or a general purpose personal computer (PC) with suitable interface circuitry and software to operate the PC as a network telephone. A redirect server is also provided which is coupled to the data network along with the network telephony devices. In the system, the network telephony devices can directly address one another to establish a real time audio connection. Alternatively, the redirect server can be accessed by the network telephony devices in order to identify, locate, and initiate a call session with a called party. The redirect server can also be used to implement high level telephony functions, such as call forwarding, multi-party calling, voice mail and the like.
  • Further objects, features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying figures showing illustrative embodiments of the invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:
  • FIG. 1 is a illustrative diagram of a telecommunications system featuring a conventional circuit-switched voice network operatively coupled to a voice packet network;
  • FIG. 2 is a block diagram of a packet data network telephone system;
  • FIG. 3 is a diagram showing a protocol stack for telephony devices operating on the packet data network telephone system of FIG. 2;
  • FIG. 4 is a block diagram of a preferred hardware architecture of a network telephony appliance in accordance with the present invention;
  • FIG. 5 is a block diagram further illustrating the network telephony appliance of FIG. 4;
  • FIG. 6 is an exemplary memory map for the DSP of the network telephony appliance of FIG. 5;
  • FIG. 7 is a block diagram of a memory interface for the DSP of the network telephony appliance of FIG. 5;
  • FIG. 8 is a block diagram of a network controller interface for the DSP of the network telephony appliance FIG. 5;
  • FIG. 9 is a block diagram of a codec interface for the DSP of the network telephony appliance of FIG. 5;
  • FIG. 10 is an exemplary memory map for the DSP of FIG. 5 showing a mapping of the LCD control interface to DSP memory addresses;
  • FIG. 11 is a block diagram showing the software architecture for the network telephony appliance of FIG. 4;
  • FIG. 12 is a block diagram showing the scheduling mechanisms of the process level software of FIG. 11;
  • FIGS. 13A-F are tables illustrating exemplary task definitions for software operations of a preferred method of operating the Packet data network telephone in accordance with the hardware and software architectures of FIGS. 4 and 11;
  • FIG. 14 is a flow diagram of an ARP request output procedure in accordance with the hardware and software architectures of FIGS. 4, 11 and 13;
  • FIG. 15 is a flow diagram of an ARP request input procedure in accordance with the hardware and software architectures of FIGS. 4, 11 and 13;
  • FIG. 16 is a diagram showing the IP processing steps in accordance with the hardware and software architectures of FIGS. 4, 11 and 13;
  • FIG. 17 is a list of exemplary Ethernet transmit data structures according to the software architecture of FIG. 11;
  • FIG. 18 is a data flow diagram of a packet sending procedure in accordance with the hardware and software architectures of FIGS. 4, 11 and 13;
  • FIG. 19 is a data flow diagram of a packet receiving procedure in accordance with the hardware and software architectures of FIGS. 4, 11 and 13;
  • FIGS. 20A and 20B show the A/D and D/A “ping-pong” buffer scheme used by the software of the present network telephony appliance;
  • FIG. 21 is a state transition diagram of the Call_task process of the present network telephony appliance;
  • FIG. 22 is chart defining the key pad values for the preferred embodiment of the Packet data network telephone of FIG. 5;
  • FIG. 23 is a data structure illustrating key state definitions for the preferred embodiment of the present network telephony appliance of FIG. 5;
  • FIG. 24 is a mapping of the I/O parallel port of the network telephony appliance of FIG. 5;
  • FIG. 25 is a data structure defining the Ethernet controller states of the network telephony appliance of FIG. 5;
  • FIG. 26 is an exemplary RTP header structure for RTP packet processing used in the network telephony appliance network telephony appliance of FIG. 5;
  • FIG. 27 is a data structure for use with a tone generation function of the Packet data network telephone of FIG. 5;
  • FIG. 28 is a timing diagram for the tone generation function of the network telephony appliance of FIG. 5;
  • FIG. 29 is a list of data structures used for processing the SIP_task requests or responses in accordance with the network telephony appliance of FIG. 5;
  • FIG. 30 is a state transition diagram illustrating the network telephony appliance operating as a client (initiating a call) in accordance with FIG. 5;
  • FIG. 31 is list of SIP_task responses in accordance with the network telephony appliance of FIG. 5;
  • FIG. 32 is a state diagram illustrating the state transition diagram of a SIP UAS in accordance with the network telephony appliance of FIG. 5; and
  • FIG. 33 is a block diagram which illustrates part of a packet data network telephony system including one or more network telephony appliances in accordance with the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • FIG. 1 is a block diagram which shows a telecommunications system having conventional telephony and packet telephony components. As shown in FIG. 1, the system includes a circuit-switched voice network 20 coupled to a packet network 30 via a first gateway 12. The figure shows at least three possible interactions between Internet telephony and a conventional “plain old telephony service” (POTS) system: “end-to-end” packet delivery; “tail-end hop off” delivery; and local packet delivery. With “end-to-end” packet delivery, end systems such as network computers, dedicated Internet phones or personal computers (PCs) are used to packetize audio and deliver audio packets to one or more similar end systems for playback. With “tail-end hop off” delivery, packet networks are used for long-haul voice transmission, while standard circuit-switched voice circuits are used for connecting customer premise equipment (CPE), i.e., standard analog telephones, to the packet telephony gateways. “Tail-end hop off” can be used both for individual voice circuits as well as for PBX interconnects, and allows for the bypassing of conventional long-distance services as well as the interconnection of POTS equipment to packet-based audio end systems. With local packet delivery, voice data is generated by packet audio end systems, but carried as circuit-switched voice over leased or public facilities.
  • FIG. 2 shows a preferred embodiment of an packet data network telephone system 50 according to the present invention. The packet data network telephone system includes: an Ethernet LAN 52, Ethernet phones 54, 56, and 58, a workstation 60, a server 62 and a Ethernet gateway 64. The Ethernet phones are network devices, which can take the form of stand alone devices, such as a network appliance, or a personal computer system with audio input and output peripherals and operating under the control of an appropriate computer program. With such an packet data network approach, voice data traffic is packetized proximate the end user. The packet data network telephony system of FIG. 2, for example, can include several dozen homes, offices or apartments that are connected to a plurality of Ethernet gateways (only one shown in FIG. 2), each of which is located within the CAT-3S cabling distance limit of 328 feet from the network termination unit. The gateways can, in turn, connect through optical fiber to the neighborhood switch (not shown), or connect directly to the Public Switched Telephone Network (PSTN) via lines 66 as shown in FIG. 2. This architecture has the advantage that a mix of low-bandwidth and high-bandwidth customers can be accommodated without running additional wires. Since switch costs are dominated by interface counts rather than bandwidth, this mechanism offers much higher per-user bandwidth (particularly peak bandwidth), yet switching costs are similar to today's telephone networks. In the architecture of FIG. 2, each network device includes a network address and each device can directly access every other network device via the network address. While a specialized server may be desirable to implement certain features, it is not required to establish a call session, i.e., point to point data communications between two or more network devices.
  • The use of a packet data network LAN 52 is advantageous in that it is a relatively inexpensive solution where conventional PC interfaces and network hardware can be used. The Packet data network LAN 52 can be operated over a variety of media and allows for the easy addition of more devices on a multiple-access LAN. Gateway 64 can be a single DSP that acts as a simple packet voice module and that implements DTMF recognition for user-to-network signaling.
  • FIG. 3 is a block diagram which illustrates a packet data network protocol stack diagram for providing Internet telephony and other continuous-media (“streaming media”) services such as “Internet radio” and “Internet TV.” As known and understood by those skilled in the art, a “protocol” is generally a set of rules for communicating between computers. As such, protocols govern format, timing, sequencing, and error control. The term “stack” refers to the actual software that processes the protocols and thus allows the use of a specific set or sets of protocols. The diagram shown in FIG. 3 shows how the various protocols are interrelated in accordance with the present invention.
  • The protocol stack 80 of FIG. 3 incorporates a number of layered protocols including: a base protocol 82 for providing basic Ethernet message format and timing information; an Address Resolution Protocol (ARP) 84 for interfacing with the base protocol 82 and for translating IP addresses into Media Access Control (MAC) addresses; an Internet Protocol (IP) network layer 86 for interfacing with the base protocol 82; a optional Dynamic Host Configuration Protocol (DHCP) 88 for interfacing with the base protocol 82; and a User Datagram Protocol (UDP) 90 for interfacing with the ARP 84, IP 86 and DHCP 88 protocols and for real-time transport of application data and controls. The protocol stack 80 further includes the following application-specific protocols for coding speech information: a Real-Time Transport Protocol (RTP) protocol 92 for real-time audio data transport, wherein the RTP protocol 92 generally interfaces with the UDP 90 and modulation, speech codec and control applications 94, 96 and 98, respectively. The application protocols 94 and 96 can take several forms, such as the G.711 pulse code modulation and the G.723 speech codec protocols, respectively. In addition, the Real Time Streaming Protocol (RTSP) layer 97 can be included to provide enhanced performance in streaming media applications. Control protocol 98 is used for session initiation and signaling and preferably takes the form the of the Session Initiation Protocol (SIP).
  • As shown in FIG. 3, RTP is the preferred protocol for transporting real-time data across the Internet. See H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” Request for Comments (Proposed Standard, RFC 1889, Internet Engineering Task Force (January 1996) which is hereby incorporated by reference in its entirety. RTP is a “thin” protocol providing support for applications with real-time properties, including timing reconstruction, loss detection, security and content identification. In addition, RTP provides support for real-time conferencing for large groups within an intranet, including source identification and support for gateways, such as for audio and video bridges, and multicast-to-unicast translators. RTP offers quality-of-service feedback from receivers to the multicast group as well as support for the synchronization of different media streams.
  • In FIG. 3, the combined stack of the IP, UDP and RTP protocols 88, 90 and 92 add 40 bytes to every packet for low-speed links and highly compressed audio, and 20 bytes for 20 ms of 8 kb/sec. audio. Thus, header compression is desirable.
  • As noted above, the protocol stack 80 of FIG. 3 preferably employs the Session Initiation Protocol (SIP) for establishing multimedia exchanges with one or more parties. Instead of using telephone numbers, SIP uses addresses in the form user@domain or user@host. This address, for example, can be identical to a person's e-mail address.
  • SIP provides the standard PBX or CLASS functionality, such as call forwarding, call waiting, caller M, call transfer, “camp-on,” “call park,” and “call pickup.” “Camp-on” allows an attendant-originated or extended call to a busy single-line voice station to automatically wait at the called station until it becomes free while the attendant is free to handle other calls. “Call park” allows a user to put a call on hold and then retrieve the call from another station within the system. “Call pickup” allows stations to answer calls to other extension numbers within a user specified call pickup group. Many of these features actually require no signaling support at all, but can be implemented by end system software. SIP is designed as a variant of HTTP/1.1, which allows easy reuse of HTTP security and authentication, content labeling and payment negotiation features.
  • SIP further employs a calendar-based call handler. The call-processing software accesses a user's personal appointment calendar and answers the phone accordingly. The user can define categories of callers and preset, based on the calendar entry, whether and where their calls are forwarded. The information released to the caller if calls are not forwarded may range, for example, from “is currently not available” to “John Smith is in a meeting until 3 p.m. in Room 5621 with Jane Doe,” depending upon the caller's identity. The call handler can also be integrated with a call processing language, a state-based scripting language that allows to construct voice-mail systems or automatic call handling systems in a few lines of code. The call handler also manages the translation between ISDN calls and Internet telephony calls.
  • FIG. 4 is a high-level hardware block diagram showing a preferred embodiment of an packet data network telephone 100 according to the present invention. As will become apparent throughout this disclosure, the device 100 is a relatively low cost interface product to place voice and data onto a packet data network, such as Ethernet LAN's, intranets and the Internet. Therefore, the device 100 will generally be referred to as a network appliance to reflect the broad applicability of this stand alone device.
  • The network appliance 100 provides audio and video communications across a local area network (LAN), Internet or other Ethernet network, and generally includes: a network (e.g., Ethernet) controller subsystem 110; a digital signal processing subsystem 120; a signal conversion subsystem 130; and a user interface subsystem 160 coupled to both the signal conversion subsystem 130 and the digital signal processing subsystem 120. The telephone 100 further includes a power supply, ROM 142 and RAM 152. The user interface subsystem may include a speaker 161, a microphone 162 and other user controls 169 as discussed below and with reference to FIG. 5. Interface circuitry 135 for data acquisition and control functions can also be coupled to the signal conversion subsystem 130. Alternatively, such I/O circuitry can be directly coupled to DSP 120.
  • The network controller subsystem 110 is interposed between the DSP 120 and the external data network and as such provides and receives data packets to and from the data (Ethernet) network. The Ethernet controller subsystem 110 also instructs the digital processing subsystem 120 to accept data received from or to provide data to the Ethernet network. In addition, the network controller subsystem can act as an initial gatekeeper by rejecting and discarding corrupted or unwanted data packets received from the Ethernet network.
  • FIG. 5 is a block diagram which illustrates the present network appliance in further detail. As shown in FIG. 5, a preferred embodiment of the network controller subsystem 110 includes an Ethernet controller 112, a service filter 114 (10Base-T transformer) and at least one RJ-45 socket 116. Among other things, the network controller subsystem 110 performs the following functions: interfacing the network appliance to the Ethernet network; sending and receiving Ethernet packets; informing the DSP subsystem 120 to accept the data when the data is available from the Ethernet; receiving the packets from the DSP subsystem 120 and sending same to the Ethernet; and rejecting and discarding unwanted packets from the Ethernet.
  • As shown in FIG. 5, the Ethernet Controller 112 is preferably the AM79C940 Media Access Controller for Ethernet (MACE) available from Advanced Micro Device (AMD). The MACE device is a slave register based peripheral. All transfers to and from the system are performed using simple memory or I/O read and write commands. In conjunction with a user defined DMA engine, the MACE chip provides an IEEE 802.3 interface tailored to a specific application.
  • Individual transmit and receive FIFOs decrease system latency and support the following features: automatic retransmission with no FIFO reload; automatic receive stripping and transmit padding; automatic runt packet rejection; automatic deletion of collision frames; direct FIFO read/write access for simple interface to DMA controllers or I/O processors; arbitrary byte alignment and little/big/medium memory interface supported; and 5 MHZ-25 MHZ system clock speed.
  • Referring again to FIG. 5, the digital signal processing subsystem 120 includes a digital signal processor (DSP) 122 and related logical circuits, which include a read-only memory (ROM) 142, a random access memory (RAM) 52, and a erasable programmable logic device (EPLD) 124. The digital signal processing subsystem 120 provides the following functions: digital signal processing, such as speech compression; call progress tone generation, and ring signal generation; general “glue” logic to interconnect DSP, memory and I/O devices; network protocol processing; call flow control and finite-state-machine implementation; keypad activity detection and decoding; and display control.
  • As shown in FIG. 5, the DSP 122 used in a preferred embodiment of the network appliance can be any suitable commercially available DSP, such as Texas Instruments' TMS320C32. The TMS320C32 DSP has the following features: parallel multiply and arithmetic logic unit (ALU) operations on integer or floating-point data in a single cycle; general-purpose register file; program cache; dedicated auxiliary register arithmetic units (ARAU); internal dual-access memories (512 double words); two direct memory access (DMA) channels; one serial port; two timers; one external memory port; and a multiple-interrupt structure.
  • In addition, the TMS320C32 DSP includes four external interrupts and six internal interrupt resources. The external interrupt can be triggered directly by the external pins. The internal interrupt can be triggered by programming the individual peripherals, such as serial port, DMA controller, and timers. In addition, all these interrupt sources can be programmed as the DMA channel interrupt via CPU/DMA enable register, IE. The TMS320C32 DSP also includes a flexible boot loader which enables the main control program for the network appliance automatically loaded from one of three different external memory spaces or the serial port, whichever is appropriate as determined by the activity of the external interrupts of INT0 to INT3 when the DSP 122 is initialized, such as at powered on.
  • The DSP 122 is generally configured to include the following resource assignments. External interrupts include: INT0: “System boot from 0x1000” indication. when the system is powered on and into is active, the DSP will boot the program from external memory space 0x1000; INT1: DMA0 external interrupt signal, used for receiving packets from the network controller 112; INT2: DMA1 external interrupt signal, used for sending packets to the network controller 112; INT3: AM79C940 packet state and error message interrupt. A sample DSP memory map for use in an embodiment of the present network appliance is shown in FIG. 6.
  • Referring again to FIG. 5, the present network appliance has the user interface subsystem 160 which includes: a key encoder 166, a liquid crystal display (LCD) 164 and a hand set 163, which includes a keypad 165, a microphone 162 and a speaker 161. The user interface subsystem 160 components allow user interaction with the network appliance by providing the following functions: user interface for input (keypad) and output (LCD); voice interface; ring alert output through speaker; and handset or hands-free (microphone and speaker) communication alternative. Through this interface 160 user commands are entered and audio is sent and received to the user.
  • In addition, the LCD can have buttons adjacent to the display, such as on the side and below. The function of these buttons can operate as “soft keys” the function of which depends on the current state of the system. For example, when not answering calls, the display can shown a quick dial list and the time of day. In addition, after calls have gone unanswered or been forwarded to voice mail, the display shows can show a list of received calls. During the call, any other incoming calls are displayed, allowing the subscriber to switch between calls or bridge the call into the existing call.
  • Alternatively, the user interface 160 of the present network appliance 100 can be configured with a small touch screen (not shown) to replace or supplement the LCD display and buttons. The touch screen, which graphically displays available functions and operations and responds to user contact on the display, provides an enhanced user interface, such as for the entry of alphanumeric network addresses and other telephony operations.
  • FIG. 5 also shows the signal processing system 130, which includes PCM encoder and decoder that performs analog-to-digital (A/D) and digital-to-analog (D/A) conversion, and an audio amplifier 134 coupled to the handset and the corresponding speaker 161 and microphone 162. Also provided is a power supply for providing positive and negative 5V voltage levels from a single AC or DC power supply adapter (“wall wart”). In the preferred embodiment of FIG. 5, negative voltage levels are required by the LCD 164 and the PCM codec 132.
  • FIG. 7 is a block diagram which illustrates a memory interface 700 suitable for use in the network appliance of FIG. 5. The memory interface 700 includes external memory modules 142 and 152, which themselves include 128 Kbyte of read-only memory (ROM) 142 for program storage and at least 32 Kbytes of double word (32 bit) static random access memory (RAM) 702, 704, 706 and 708. Due to the relatively slow speed of the ROM 142, it is preferable that the network appliance initializes the main program from the ROM and stores this program in the relatively fast RAM for run time execution.
  • FIG. 8 is a block diagram that shows an exemplary interface between the DSP 122 and the Ethernet controller 124 in accordance with a preferred embodiment of the present invention. The 32 registers of the Ethernet controller 124 are memory mapped at the 0x810000 memory space of the DSP 122 as shown in FIG. 6. Preferably, the first two registers are receiving and transmitting “first in, first out” (FIFO) queues. The DSP 122 exchanges the data with the Ethernet controller 124 via a 16 bit data bus 802.
  • FIG. 9 is a schematic diagram which illustrates an interface between the DSP 122 and the PCM codec 132 in accordance with a preferred embodiment of the present invention. As shown in FIG. 9, the DSP 122 connects to the PCM codec 132 via an internal serial port 902. The serial port on the DSP 122 is an independent bidirectional serial port.
  • As shown in FIG. 5, the DSP 122 is also operatively coupled to the LCD 164. The LCD control interface is mapped at the DSP addresses shown in FIG. 10. In one embodiment of the present invention, the LCD 164 is a 120×32 pixel LCD such as the MGLS-12032AD LCD, manufactured by Vazitronics. Since the access speed of the LCD is generally slow, data displayed by the LCD can be mapped into the STRB0 (1X1000) memory space of the DSP 122, which is the same memory space as ROM memory space. Preferably, the LCD timing logic is the same as the timing logic for the DSP 122. However, when the LCD is composed of a left-half and a right-half, such as in the MGLS-12032, it is necessary to control and program for both of halves of the LCD when displaying an entire line message.
  • FIG. 11 is a block diagram showing the software architecture for the present network appliance. As shown in FIG. 11, the processing architecture for the present network appliance is generally organized into three levels: the ISR (Interrupt Service Routine) level 1110; the operating system or Process level 1120; and the application or Task Level 1130. An exemplary list of functions and tasks which can be performed at each of the software levels is provided in FIG. 13.
  • The lowest level, the ISR level 1110, includes interrupt handlers and I/O interface functions. The ISR level 1110 serves as the interface between the process level 1120 and the network appliance hardware shown in FIGS. 4 and 5.
  • Above the ISR level 1110 is the process level 1120, or operating system, which is preferably a real-time multitasking micro-kernel, such as StarCom's CRTX Embedded Real-time micro-kernel. Generally, the process level software 1120 (micro-kernel) performs memory management, process and task management, and disk management functions. In a preferred embodiment of the present invention as shown in FIG. 12, the micro-kernel supports three scheduling mechanisms: a Real-time Event Flag Manager 1222; a Delayed Task Manager 1224; and a Scheduling Manager 1226. The micro-kernel has three separate queues for the three different mechanisms above, respectively.
  • The Real-time Event Flag Manager 1222 is used to trigger the execution of real-time events by way of setting flags. If a flag is set to an “ON” condition, the task associated with the flag is immediately executed. For example, an interrupt service routine would set a particular flag when a certain event occurred. Flag events are entered on a flag queue with an associated task address.
  • The Delayed Task Manager 1224 is responsible for timed events. A timed task, such as a fail-safe or “watchdog” task, can be executed after a certain time delay. If a certain event does not occur within a certain time frame, the timer triggers the task causing it to be executed. Another example is the repeated execution of a task controlled by a periodic timer. In an exemplary embodiment, there are 10 timer entries. Each timer is loaded with a tick count and is then decremented on every timer tick from the hardware's interval timer. When the count reaches zero, the task associated with the timer is scheduled on the task queue. The Scheduling Manager 1226 scans the task schedule queue looking for scheduled tasks. Upon discovery of an entry in the queue, control is passed to a scheduled task.
  • FIGS. 13 a-f are tables which list exemplary software tasks and functions which can be part of the task level software (FIGS. 13 a-c), process level software (FIG. 13 d) and ISR level software (FIGS. 13 e-f). For the purposes of the present invention, the terms “task” and “function” as referred with respect to the software architecture are considered to be synonymous. However, “tasks” are generally executed by the Scheduling Manager 1226, whereas “functions” are generally called by tasks or other functions. The application tasks, such as the call processing (Call_task) and IP processing (IP_Send_task and Ercv_task, etc.) tasks, are scheduled by the Process level software 1120. The execution of such tasks is a result of a prior scheduling by an ISR, another task, or by the current task itself.
  • FIGS. 13 A-F illustrate exemplary function and procedure definitions called in an event driven operation performed by the present packet data network telephone software of FIG. 11. The functions, which are called on the occurrence of various events, enable operation of the packet data network telephone/system and include gross operations such as: initializing the Packet data network telephone/system; processing ARP data; encoding voice data; processing message data; processing IP data; decoding voice data; transferring analog and digital data to and form corresponding buffers; and performing “watchdog” functions.
  • Initialization of the packet data network telephone appliance includes the steps of hardware initialization and task scheduling. After power on, the DSP 122 will automatically transfer the main program from the ROM 142 to the RAM 152 (boot operation). Hardware initialization occurs in a traditional manner, including the steps of: initializing the stack pointer, external bus interface control register, global control register of the DSP, interrupt vector for the ISR, and the like.
  • After completion of the hardware initialization and preliminary task scheduling, processing control is returned to the process level (micro-kernel) 1120. The CRTX micro kernel 1120 and the scheduled tasks then control further processing.
  • Referring again to FIG. 13 a, the task level software of the present network appliance includes Address Resolution Protocol (ARP) processing. ARP is a known TCP/IP protocol used to convert an IP address into a physical address (called a Data Link Control (DLC) address), such as an Ethernet address. A host computer wishing to obtain a physical address broadcasts an ARP request onto the TCP/IP network. The host computer on the network that has the IP address in the request then replies with its physical hardware address.
  • FIG. 14 is a flow diagram illustrating of an ARP request output procedure 1400, ARP_Out( ). As illustrated in FIG. 13 B, ARP_Out( ) is a component of the task level software which receives an IP address to be resolved, and outputs a corresponding MAC address. When a ARP request begins (step 1402) the ARP_Out( ) function first checks the requested IP address from a local ARP cache table, arptable (step 1404). If the corresponding entry is RESOLVED at step 1406, then ARP_Out( ) copies the MAC address from arptable to the requested parameter and returns a ARPOK status flag (step 1408). Otherwise, the procedure will allocate an entry in the arptable and schedules a ARP request (step 1410). As further shown by step 1410, a MAC address, i.e., “handle,” of the arptable is returned to the main program (c_int00( )). According to the handle, the software then checks the corresponding entry's ae_state.
  • FIG. 15 is a flow diagram of an exemplary ARP request input procedure 1500, ARP_In_task( ), which is a component of the task level software listed in FIG. 13 A. The ARP_In_task receives an ARP packet, and either modifies the arptable or queues an ARP reply if the incoming packet is an ARP request. When receiving an ARP packet (step 1502) the software will check whether the packet's ARP hardware or protocol types match (step 1504). If the types do not match, control is returned to the main program (step 1506). If one or both of the types match, then the software checks if the destination host is the present host (step 1510). If the destination host is not the present host, then control is returned to the main program (step 1508).
  • As further shown in FIG. 15, if the destination host is the current host, then the ARP_In_task next checks the ARP table to determine whether there is a corresponding ARP entry for the incoming packet (step 1512). If an entry is found (step 1514), then the new MAC address is copied into the existing entry and modifies the entry's “Time to Live” (TTL) to a new value (step 1516). A TTL is understood by those with skilled in the art to be a field in the Internet Protocol (IP) that specifies how many more hops a packet can travel before being discarded or returned to the sender. However, if there is no such MAC entry is found in accordance with step 1513, then the ARP_In_task adds a new MAC entry in the ARP table (step 1518). If the MAC entry is in a PENDING state (step 1520), it is then changed to a RESOLVED state and the MAC address is copied to the target entry (step 1522). If the incoming ARP packet is an ARP request from another host, an ARP reply packet is sent by queuing the IP_Send_task, steps 1524 and 1526. Control is then returned to the main program (step 1528).
  • In addition to the ARP input and output processes, ARP processing at the task level includes an ARPTimer_task( ), which is a delayed loop task used to maintain the ARP entry table arpentry. Nominally, the ARPTimer_task( ) is generated once per second. The main purpose of the ARPTimer_task( ) is to decrease the “Time to Live” (TTL) of the ARP entry and to resend the ARP request during the pending state in case the previous ARP request is lost.
  • Task level processing can also include processing operations associated with the coding and decoding of audio packets. The Codec_task generally includes a SpeechEncode( ) function, which encodes speech data from the ADBuf buffer to the EncodeBuf according to the algorithm indicated by “type” parameter. The coded data is then sent out via the queue IP_Send_task, with the “RTP” parameter set.
  • Task level operations can also include Internet protocol (IP) processing. The general IP processing operations are illustrated in the block diagram of FIG. 16. As shown in FIG. 16, IP processing includes the steps of: transmitting and receiving Ethernet packets, step 1602; multiplexing and de-multiplexing IP packets, step 1604; and packetizing and de-packetizing Ethernet, Internet Protcol (IP), User Datagram Protocol (UDP), Real-Time Transport Protocol (RTP) and Address Resolution Protocol (ARP) packets, step 1606.
  • In accordance with step 1602 of FIG. 16, Ethernet packet transmission can be performed using direct memory access (DMA) channels of the Ethernet controller 112. DMA is a technique for transferring data from main memory to a device without passing it through the CPU. Since DMA channels can transfer data to and from devices much more quickly than with conventional means, use of DMA channels are especially useful in real-time applications, such as the present network telephony system.
  • The network controller 110 preferably supports a plurality of DMA channels, such as the DMA1 channel of the Ethernet controller 112 that can be used for packet transmission. When an Ethernet packet is ready for transmission, the DMA1( ) function, an ISR level function, is called by setting the source address (Ethernet packet buffer, ESend), destination address (Ethernet controller's transmit FIFO), and a counter (the packet length). Examples of Ethernet transmit data structures are provided in FIG. 17. The DAM1( ) function then starts the DMA1 channel. When the counter reaches zero, the DMA1 stops and waits for the next call.
  • FIG. 18 is a block diagram which shows the data flow between an audio input buffer 1802, a UDP buffer 1804 and ARP table 1806 to the Ethernet interface (Ethernet Transmit FIFO) of the Ethernet network controller 112. As further shown in FIG. 18, data from the audio input buffer 1802, the UDP buffer 1804 and the ARP table 1806 is sent to an IP output queue 1810, and is arranged to indicate the protocol type, source pointer and data length. Instead of queuing the sending data, the IP_Send_task is queued by process level software (micro-kernal) 1120. The protocol types supported by the IP_Send_task generally include UDP, RTP, ARP_REQUEST, ARP_REPLY. IP_Send_task is used for packet transmission and Ethernet packetizing. Preferably, IP_Send_task is scheduled by other tasks or functions such as SIP_task, ARP_Out( ), SpeechEncode( ), etc. Once the IP_Send_task is run, it checks the protocol type of the data. This task then encapsulates the output data into the corresponding Ethernet packet in the ESend buffer. Finally, the packet is sent out via the assigned DMA channel (DMA1).
  • FIG. 19 is a data flowchart further illustrating packet receiving and de-multiplexing operations. The de-multiplexing is realized by scheduling different tasks for different protocols in the Ercv_task. In further accordance with step 1602 of FIG. 16, Ethernet packets are received in the receive data FIFO memory (step 1902) and are further processed by a DMA0 channel controller (step 1904). Since the DSP 122 doesn't know when the packets will arrive, the DMA0 channel is active all the time (i.e., it does not stop even the counter reaches zero). When a packet arrives, the DMA0 channel will automatically copy it from the Ethernet controller's receiving FIFO to the Ethernet receiving buffer, Ercv (step 1906). The DMA0 channel stops when there is no data available in the FIFO.
  • ERcv_task is a flag trigger task for Ethernet packet de-packetizing and IP packet de-multiplexing (step 1908). The Ercv_task functions as follows: first, a PacketCheck( ) function is called to check the incoming packet. The PacketCheck( ) will return the protocol type of the packet, or NULL if the packet is invalid. Second, depending on the returned protocol type, the ERcv_task will trigger the different tasks to process the received packet, RTP_In_task for “RTP” packet (step 1910), ARP_In_task for “ARP” packet (step 1912) or UDP processing tasks (step 1912) for UDP packets, for example.
  • Referring to FIG. 13 C, SpeechDecode( ) is a voice decoding function associated with the RTP processing of step 1910. First, a SpeechDecode( ) task checks if there are data available in the decoding buffer, DecodeBuf. If data is available, e.g., RcvFlag is SET, then SpeechDecode( ) decodes it according to the data type of receiving data, PCM (G.711), G.723, G.729, for example. The decoded data is sent into the D/A buffer, DABuf.
  • The A/D and D/A interrupt routine can be triggered by an internal interrupt source, e.g., Rint0( ). Preferably, the A/D and D/A interrupt routine is triggered by an 8 kHz sampling frequency provided by the DSP. Since this routine is called frequently, Rint0( ) is preferably written in assembly language. The steps performed by Rint0( ) include the steps of: reading a D/A sample from D/A buffer, DABuf; sending the sample to the serial D/A port; obtaining a sample from the serial A/D port; saving the A/D sample to an A/D buffer, ADBuf; and incrementing A/D and D/A buffer pointers, ADPnt and DAPnt, by one.
  • FIGS. 20A and 20B are block diagrams which show an A/D and D/A “ping-pong” buffer scheme used by the software of the present invention. Further, if the current A/D pointer value (ADPnt) exceeds a predetermined buffer threshold (ADTh) then a flag is set in the flag task queue indicating that service is required.
  • The A/D and D/A buffers can be divided into two parts, the upper buffer 2002 a and lower buffer 2002 b, respectively. Both buffers can be designed as circular buffers. In this way, when the current pointer reaches the buffer bottom, it wraps around to its beginning. However, from the encoder and decoder point of view, it is used as a two-frame ping-pong buffer (defined as upper frame and lower frame) scheme. The operation of this process is shown in FIGS. 20A and 20B. For A/D conversion, when the upper (or lower) is full, the data in the upper (or lower) buffer will be passed through ping pong switch 2004 and copied to the speech encode buffer, EncodeBuf 2006. For D/A conversion, if the upper (or lower) buffer is completed, a new frame of data will be copied from the speech decode buffer, DecodeBuf, 2010 to the upper 2008 a (or lower 2008 b) buffer. This mechanism ensures that while the encoding (or decoding) algorithm reads(writes) from one part of the buffer, the A/D (or D/A) sampling ISR can write (read) the other part of the buffer without conflict.
  • FIG. 21 is a state transition diagram of a Call_task subroutine used in an exemplary embodiment of the present network appliance. Call_task is a looped task which handles the call procedure. As shown in FIG. 21, the “Idle” state 2102 occurs when there is no call being made and there is no incoming call. When this condition exists, the Call_task loops in the “Idle” state 2102. The “DialTone” state 2104 exists when the receiver state is OFFHOOK, or the handset state indicates HANDSFREE, and thus the Call_task state will change from the “Idle” state 2102 to the “DialTone” state 2104 when a OFFHOOK or HANDSFREE condition exists. These states are generally entered by an input by a user through the user controls 160 indicating that a call is to be initiated. When the Call_task state is in the DialTone” state 2104, the Codec_task will be configured as “ToneMode, DialTone” and a dial tone is sent to the handset components of the user interface 160.
  • Referring again to FIG. 21, while in the “DialTone” state 2104, if any digit key (‘0 . . . ‘9’, ‘*’ and ‘#’) or the redial button is pressed, the call state changes from the “DialTone” state 2104 to the “GetDigit” state 2106. In the “GetDigit” state 2106, the dial tone is stopped at the handset.
  • After the callee's number has been input and an ENTER button has been pressed by the user to indicate that dialing is complete, the Call_task will check if the input is valid. If the number is valid, a call entry is created by a function CreateSipCall( ) and the Call_task will go into a “SIP” state 2108. Otherwise, if the input number is invalid, the number is requested again and the state remains at the “GetDigit” state 2106.
  • While waiting for SIP_task processing, several decisions may be made depending on the “SIP” state 2108. The “SIP” state 2108 is a global variable, SIP status, which is modified by the SIP_task according to its state transition. If the “SIP” state 2108 changes into SIP_Ring, the Call_task will change to the “RingBack” state 2114 and the Codec_task will be configured as “ToneMode, RingBack” mode. When the Codec_task is in the “ToneMode, RingBack” mode, a ring back tone is sent to the handset.
  • From the “SIP” state 2108, if the “SIP” state 2108 changes to SIP_busy, the Call_task and thus the call will change into “BusyTone” state 2120 and the busy tone will be played at the handset. It the “SIP” state 2108 changes to SIP_Refused, appropriate messages will be displayed on the LCD screen related to the SIP_Refused state.
  • From the “RingBack” state 2118, if the “SIP” state becomes SIP_Connected, the Call_task state changes to the “Talk” state 2116. When the Call_task state is in the “Talk” state 2116, the Codec_task will configured as SpeechEncode and SpeechDecode mode.
  • For incoming calls, while in the “Idle” state 2102, if the “SIP” state 2108 is SIP_Invite, the Call_task state changes to the “Ring” state 2114 and the Codec_task will be configured as “ToneMode, RingTone.” When the Codec_task is configured as “ToneMode, RingTone,” a ring tone will be played on the loudspeaker. After the SIP state becomes SIP_Connected, the Call_task state will change into the “Talk” state 2116. Otherwise, if the SIP state becomes SIP_Cancel, which happens if the caller gives up the call, the Call_task state returns to the “Idle” state 2108.
  • While at the “Idle” state 2102, if the ENTER button is depressed, the Call_task calls the Setting_task. When the parameter setting program is finished, it will return to Call_task.
  • During Call_task execution, if the hook state indicates the receiver is ONHOOK, or a system error is found, the Call_task changes to the “Idle” state 2102, regardless of what the previous state is (except the “Ring” state 2114).
  • In the preferred embodiment of the network appliance as shown in FIG. 5, the key pad of the telephone has 17 keys for providing user inputs and commands. The telephone key pad includes 10 digit keys, two special keys and five function keys are defined as shown in FIG. 22.
  • The Key_task is a loop delayed task which runs periodically, such as every 0.1 seconds. When started, Key_task first calls the key( ) function. If the return value is not “−1”, it means a key has been pressed. Then, the KeyMap( ) function maps the input binary key word to the ASCII key word. The Key_task then sets the corresponding member of the FuncKey structure. If the system is ready to accept the key input (the KeyRegEnable is indicated), the input key word is stored into the KeyBuf.
  • In addition, Key_task preferably supports four different input modes: digit input mode, IP address input mode, alphabet input mode, and list address input mode. Switching among the four modes can be done by pressing the ENTER button before dialing any number or alphabet when the handset is picked up and a dial tone is heard. After input is complete and the ENTER button is pressed, the input numbers will be transferred to the current task (Call_task or Setting_task) by a message pipe. If the Redial key is pushed, the task will copy the previous input from the backup buffer, KeyBackup, to the KeyBuf. Then the data will be transferred to Call_task.
  • The operating system of the present network appliance preferably supports a delayed task schedule scheme. The delayed task is similar to the sleep( ) function in UNIX. However, a delayed task can also be a persistent task execution from a periodic timer when the task's repeating flag is set. For delayed tasks, the process level software 1120 requires an interval timer to provide a system tick. The system of FIG. 5 uses the TMS320C32's timer1, TCLK1, as the system timer base.
  • The Clock_task is a looped delayed task which performs real time clock and calendar functions. It serves as the general clock to calculate and display the current time, including the hour, minute and second. When a call is connected, it can display the call duration. When the phone is on hook, current year, month and date can also be displayed on the LCD.
  • Referring again to FIG. 11, the Network telephone software of the present invention includes several low-level functions that are included as part of the software ISR level. Some of these low-level functions are I/O related functions, which are used with the telephone's 8-bit I/O parallel port defined in FIG. 24. The low-level, I/O related functions include: the “Hook” state monitor, Hookst( ); the Key input availability check and read, Key( ); handset and hands-free control, HandSet( ); Ethernet controller reset, ENET_reset( ); volume control, AmpControl( ); and software reset of the system.
  • The audio interface chip 136, which preferably takes the form of an LM4830, can be used to control switching between the handset and the hands-free mode. For example, the HandSet( ) function can write a ‘0’ to the I/O port when “hands-free” mode is required or write a ‘1’ to the appropriate port when “handset” mode is required.
  • The low-level functions of the present invention also include the Ethernet controller interrupt ISR, c_int03( ). The global message structure for use with c_int03( ) is defined for the state of the Ethernet controller as shown in FIG. 25. Whenever a packet has been sent, or a received packet is complete, the Ethernet controller will interrupt the DSP 122 to indicate the interrupt. The DSP 122 will read the transmission and receiving states from the Ethernet controller's register and then store the state into the above state structure. This information can be checked by other tasks. In addition, these messages are read after each packet transmission. Otherwise, the Ethernet controller will be blocked.
  • As noted above, it is preferred that the present network appliance of the present invention uses the RTP protocol to transmit and receive speech packets in real time. The RTP packet is encapsulated in an UDP packet. The IP_Send_task and the RTP_In_task modules operate to create and parse RTP packets. FIG. 26 shows an RTP header structure for RTP packet processing.
  • When the IP_Send_task gets a request to send a RTP packet, it first generates an Ethernet and UDP header. Next, it adds the RTP header in the Ethernet packet transmission buffer. Finally, the RTP data is copied into the RTP data area and is sent over the data network.
  • FIG. 27 shows a data structure for use with a tone generation function, Tone_task( ). The parameters described in FIG. 27 are illustrated in the tone generation timing diagram of FIG. 28.
  • Tone_task is a delayed task which can be executed about every 0.1 second. It is used to count the tone active and stop duration defined in the ToneType structure. Tone_task sets ToneState to ACTIVE during burst and STOP during silence. Different active and stop duration generates different tones. They are: Dial tone, continuous tone (no stop); Busy tone, burst 0.5 s and silence 0.5 sec; Ring back tone, burst 2 sec and silence 4 sec; Ring signal, burst 0.8 sec twice in two seconds, then silence 4 sec.
  • Preferably, a ToneGenerate( ) module generates a one frame 400 Hz tone or a 2400 Hz ring signal defined by “mode” parameter when ToneState is ACTIVE. Otherwise, one frame silence signal is provided.
  • The network appliance of the present invention uses UDP as its transport protocol for SIP. SIP_task is a looped task that handles SIP signaling. Since the present network appliance can be used either as a caller or as a callee, SIP_task operates both as a UAC (User Agent Client) and a UAS (User Agent Server).
  • FIG. 29 is source code which shows data structures used for processing the SIP requests or responses in accordance with the SIP protocol. Tstate is the state transition structure used in SIP_In_task and SIP_task for SIP state transition. Parsed SIP messages are in the data structure message_t. The structure call is defined for each call and the total call entries are defined by msg[MaxSipEntry].
  • FIG. 30 shows a state transition diagram of the SIP_task operating as a client (e.g., a caller). When the SIP phone starts a call, it works as a client. A call will be created via the following steps: a call entry msg[CurrentIndex] is allocated when the phone is picked up and the flag of the call is SET; CreateSipCall( ) creates a SIP packet according to current setting and dial inputs, wherein the SIP package is used as the reference of the call and the us_state is set to UAC; SIPParse( ) generates the message structure (msg[CurrentIndex].m) for the call from above packet; the SIP_task will check if there are any active calls—if there is a call (msg[i].flag is SET), SIP_task will create the corresponding request according to the SIP specification and the SIP states will be updated in SIP_task as shown in FIG. 30.
  • FIG. 30 shows an exemplary state diagram for client (caller) operations, referred to as a UAC state transition diagram of SIP_task. From an Initial state (step 3002) a Calling state is entered and a SIP_task retransmits a SIP INVITE request periodically (T1) until a response is received (step 3004). Nominally, T1 is 500 ms initially and doubles after each packet transmission. (Step 3006) T2 is nominally 32 seconds. If the client receives no response, SIP_task ceases retransmission when T2 timer expires and SIP state will be changed to Cancel (step 3008). If the response is provisional, the client continues to retransmit the request up to seven times. When a final response is received, the state will change to Completed and a ACK will be generated (step 3010). When the caller gives up, the state will changed to Bye state (step 3012). BYE requests are also retransmitted during the interval of T1 until T2 expires for the purpose of reliable transmission. The variable, SIP_Status, will be changed according to the response received as shown in FIG. 31. For example, if a 3xx response is received, SIP_task will initiate another call to the redirected address. Other final responses can be displayed on the LCD.
  • When the network appliance receives a call, the SIP_task functions as a SIP UAS (server). The incoming packets are processed as follows: UDP_In_task accepts the incoming UDP packet and sends the packets to SIP_In_task along with its source IP address and port number. SIP_In_task processes the packet according to the SIP specification and updates the states accordingly. SIP_task will monitor the receiver state, set and decrease the T1 and T2 timer of each call and update the SIP states if necessary.
  • FIG. 32 illustrates an exemplary state transition diagram of a SIP UAS. While the SIP_task remains at an Initial state (step 3205), it listens to the incoming SIP packets. If an INVITE request is received, it generates a Ringing(180) response and its state changes to Invite and the Sip task module would advance to a Proceeding step (step 3210). If a called party picks up the telephone, the status changes to Picks Up and the process advances to Success (step 3215), indicating a successful call session has been established. If the called party does not pick up, the status changes to Failure and the process advances to the Failure state (step 3220). After success or failure, the client will acknowledge the current status and advance the process to the Confirmed state (step 3225). When the calling party terminates the session, the status changes to Onhook and the process advances to Bye (step 3230) indicating that the current session has been completed.
  • As set forth herein, the network appliance is a stand alone device capable of initiating and receiving telephone calls on a packet data network. While the stand alone architecture described herein offers many attendant advantages, such as its relatively low cost to implement, similar software architecture and functional definitions described in connection with the stand alone appliance 100 can also be provided on a PC based telephone device. In such a case, a conventional personal computer having a microphone, speakers and suitable network interface card, is provided with software to operate consistently with the manner described above. Of course, obvious changes are effected in this embodiment, such as the user interface components and functions being performed by conventional elements of the PC, e.g., the keyboard, monitor, mouse and the like. A GUI interface to the telephone functionality is provided by the software to enable the desired telephony functions.
  • The network appliance of the present invention, in addition to performing traditional telephony functions, can also provide a cost effective interface between the network and the environment. While equipping sensors with Ethernet interfaces is not feasible, due to the large number of ports required and the cost of the minimal hardware required, the network appliance of the present invention can become the gathering point for a number of digital and analog sensors. This is accomplished generally by coupling the external sensor to the network appliance via the conventional I/O circuitry 135 which is coupled to the DSP 122. The I/O circuitry can take the form of simple buffers, A/D converters, registers and the like. This feature is particularly useful in environments that have phones for security reasons, e.g., elevators, lobbies, shop floors, garages, etc. Examples include: Passive infrared (PIR) digital sensor for detecting the presence of people—this can be used for automatically forwarding calls if nobody is in the office or as part of a security or energy management system; analog or digital light sensor to detect whether the office is occupied; analog temperature sensor; smoke, carbon monoxide and radiation detectors; and contact closures for security systems. Thus, the present network appliance provides a point of system integration.
  • To provide further enhanced I/O capability, the I/O circuitry can be compatible with local control protocols such as the X10 and CEbus protocols which are recognized standards for controlling line-powered devices such as lighting or appliances. Adding such and interface to the phone provides for network-based control of such devices.
  • FIG. 33 illustrates a system employing the present network appliance for establishing calls between two or more parties on the network. The system generally includes one or more stand alone network appliances 100, such as described above. In addition, the system can also include PC based telephony devices 3320, such as a network enabled PC operating suitable network telephony software which is protocol compliant with the network appliance 100. Each telephony endpoint can be referred to as a node and has a specific SIP address. By employing this specific address, any node acting as a calling party (client) can directly initiate a call session with any other node on the network (server).
  • The system preferably also includes a redirect server 3325 which can be accessed by the various nodes on the network to provide enhanced services, such as a directory service, call forwarding, call branching, call messaging and the like. For example, a calling party wishing to initiate a call to JOHN SMITH can enter the SIP address for that person if it is known, such as sip:john.smith@work.com. If, on the other hand, the calling party does not know the SIP address of the party, the calling party can contact the redirect server 3325 with a request to begin a session with JOHN SMITH. The redirect server includes databases with registration information for various parties and can return the SIP address to the calling party or forward the call request to the proper SIP address. In addition, the called party may have multiple sip addresses such as john.smith@home, john.smith@office, john.smith@lab and the like. The redirect server can provide a session initiation signal to each of these addresses and establish a connection between the calling party and the first contacted node that responds to the initiation request. Similarly, parties can periodically register with the redirect server to indicate the current SIP address where they can be contacted (call forwarding feature).
  • The network appliance 3305 can be configured to interface to one or more sensors 3310. Signals from the sensors are received by the network appliance 3305 and can be sent along the network to a desired network node. The signals from the sensors can be detected periodically by a timer in the network appliance and sent to a SIP address stored in memory. Alternatively, the sensor signals can be measured by the network appliance 100 based on a command received from another node (polled by a remote network node) or can be measured based on a received interrupt signal indicating a change of state of the sensor (interrupt driven). For example, the network appliance 100 can be used as a security system communication device which reports the status of various security sensor points to a central monitoring station. In such a case, the appliance can periodically check the status of the connected sensors, such as door sensors, fire sensors, passive infrared detectors and the like, and report to a central station node the current status. In the event of a status change that would indicate an alarm condition, the appliance 100 could generate a call session with the central station and report this condition as well. Of course, the same appliance which is acting as an alarm communicator can also provide full telephony functions as well. In addition, while a simple security application was described, it will also be appreciated that various other data collection and control applications generally known as SCADA (site control and data acquisition), can be implemented using the present network appliance 100.
  • To maintain lifeline service during power outages, the network appliance of the present invention can be equipped with a rechargeable battery, possibly integrated into a wall transformer.
  • As many locations are currently equipped with only one Ethernet interface, the network appliance of the present invention should provide a two-port Ethernet hub, with an external RJ-45 interface. This provides for simultaneous operation of both the telephony device and network enabled computer.
  • In addition to audio data, the present network appliance can also receive and transport video data. For example, a video input interface, either analog or through a USB (Universal Serial Bus) can be operatively coupled to DSP 122 to implement this feature.
  • The present network appliance 100 can also be coupled to a suitable wireless Ethernet interface to allow the equivalent of a cordless phone.
  • The following protocols can be added to the present network appliance 100 to provide expanded functionality: DHCP and RARP for automatic assignment of IP addresses; IGMP for subscribing to multicast groups; RTSP for retrieving voice mail and distinctive ringing signals; SAP for listening to announcements of multicast “radio” events; and DNS for name resolution (subject to available program memory space).
  • In addition to basic telephony operations, the present network appliance can also provide high level telephony functions. For example a “Do not disturb” feature can be provided that automatically forwards calls for a given duration to a designated location as specified by a SIP address input by the user. Each time the feature is selected, such as by depressing a button on the user interface, the time increases by a predetermined interval (e.g., 15 minutes).
  • “Call logging” can also be provided wherein the SIP address and related information regarding incoming calls is logged by storing the information in memory, with the ability to call back the calling party by scrolling through the list and selecting the SIP address of the caller from the log by user interaction via the user interface subsystem 160.
  • The network appliance can also include an “Automatic address book.” Through user input or via a server connected on the network, the network appliance can acquire a speed dial list or a list of names stored in its local memory which a user can scroll through (using the SIP “multiple choices” response);
  • An “Interface to voice mail system” feature can display all unanswered calls that have come in, including the time of call, the caller, the subject and urgency of the call and whether the caller left voice mail. Calls can be ordered chronologically or by urgency. The call display preferably features five soft buttons: to delete the entry, to move forward and back through the list, to return the call and to retrieve the message.
  • “Distinctive ringing” is a feature wherein the appliance 100 is programmed to announce certain callers by a distinct sound clip, such as a distinctive ring, melody or the name of the caller. In this case a small database associates a caller, or a class of callers (e.g., friend, customer, urgent) to a particular selected ring response. The sound clip is played either from memory or retrieved from a server;
  • “Call forwarding” is a further feature which can be implemented in the appliance 100. Typically, calls are forwarded by the proxy redirect server. However, the network appliance 100 can also perform simple forwarding itself, as described above for the “do not disturb” button. The redirection may take the form of calling the phone from another phone with a REGISTER command, to implement follow-me calls. Also, automatic forwarding of calls from certain domains or during certain hours is readily implemented without use of a redirect server.
  • “Intercom” mode is a feature where incoming calls are “picked up” automatically, with the microphone disabled until a push-to-talk button is pressed or the receiver is lifted. This can also be used as part of a security public address system.
  • “Baby monitoring” features allow the network appliance to act as a remote audio monitoring device. For example, on receipt of an incoming call, the network appliance 100 is activated with the speaker disabled but with the microphone automatically enabled such that the calling party can listen to the environment where the called appliance is located. This feature can be selectively engaged, such as by a predetermined code or caller identity;
  • An “Internet radio” feature allows the network appliance 100 to automatically play radio stations supplied by a local RTP multicast server or other streaming media source when a call is not being received or initiated. The appliance 100 can listen for SAP announcements and can display the station list on the display, with soft buttons. Any incoming phone call interrupts the current radio program.
  • The present network appliance can also maintain a “Callee list.” If a previous call was successful, the callee's address is automatically entered into a portion of memory used as a local guide-dial list. When this party is to be dialed again, the callee can be selected by the upward or downward key from the callee's list. This is generally a FIFO type memory structure which automatically purges old entries and replaces them with more current entries; and
  • “Redial,” which allows single key dialing of either the last number dialed or the last callee.
  • In addition, “Speech processing enhancement,” such as silence suppression, comfort noise generation, and echo cancellation can also be included in the present network appliance in a manner which is well known in the telephony art.
  • Thus, a network-based telephone that is a stand-alone “Internet appliance” that allows the user to make phone calls within a local area network (LAN) or across the Internet has been disclosed. Its core is a single digital signal processor (DSP) (a microcontroller optimized for processing audio and video data). It provides services that are a superset of those of a regular telephone, but connects and Ethernet data network instead of to the PSTN (Public Switching Telephone Network). Since Ethernet running at 10 Mb/s can use the same twisted-pair wiring used for analog and digital phones, the Packet data network telephone does not require rewiring customer premises. A minimal system consists of two Packet data network telephones connected by an Ethernet cross-over cable. A multi-line basic PBX can be implemented consisting of any number of Packet data network telephone connected to an Ethernet hub or switch. This “PBX” can scale to any number of phones, simply by adding Ethernet capacity and ports. The Packet data network telephone shares the Ethernet with other LAN services. In almost all cases, voice traffic will be a small fraction of the network capacity. (A single voice call consumes about 16 kb/s of the 10 Mb/s capacity.) The Packet data network telephone offers voice communications, implementing the customary features of PBXs. However, the present network appliance may use a server located in the LAN or the Internet to provide additional functionality, such as user location and directory services, call forwarding, voice mail, attendant services.
  • A PBX based on the current network appliance can reach traditional phones through an Internet Telephony Gateway (ITG). Such a gateway connects to the PSTN using either analog lines, ISDN basic or primary rate interfaces or digital trunks (such as T1/E1). ITGs have recently been introduced as commercial products, with capacities of one to about 240 lines.
  • Although the present invention has been described in connection with particular embodiments thereof, it is to be understood that various modifications, alterations and adaptions may be made by those skilled in the art without departing from the spirit and scope of the invention. It is intended that the invention be limited only by the appended claims.

Claims (20)

1. A network appliance for providing packetized data over a packet data network, comprising:
a network controller subsystem coupled to said packet data network;
a digital signal processing subsystem coupled to said network controller subsystem, the digital signal processing subsystem further comprising a computer program for detecting incoming calls and initiating call sessions;
a signal conversion subsystem coupled to said digital signal processing subsystem; and
a user interface subsystem coupled to both the signal conversion subsystem and said digital signal processing subsystem.
2. The network appliance according to claim 1, wherein said digital signal processing subsystem comprises a digital signal processor (DSP) and one or more memory devices coupled to said digital signal processor.
3. The network appliance according to claim 2, wherein said computer program implements the Session Initiation Protocol for detecting and initiating call sessions and performing call session control.
4. The network appliance according to claim 3, wherein a unique SIP address is associated with the appliance, said address being stored in at least one of said memory devices.
5. The network appliance according to claim 4, wherein the packetized data includes audio data and wherein the user interface subsystem comprises:
a handset comprising an input device, a microphone and a speaker; and
a display device.
6. The network appliance according to claim 5, wherein said computer program implements a monitor feature, wherein on detection of a call directed to the appliance from a caller, a call session is automatically initiated with said microphone enabled and said speaker disabled during the call session.
7. The network appliance of claim 6, wherein identifying criteria of at least one approved caller is stored in at least one of said memory devices and wherein said digital signal processor receives identifying criteria from the caller and activates the monitor feature only if the received identifying criteria matches at least one of the stored identifying criteria of said at least one predetermined approved caller.
8. The network appliance of claim 7, wherein said identifying criteria are selected from the group including name, SIP address and password.
9. The network appliance according to claim 3, wherein the computer program implements a call forwarding feature, wherein at least one forwarding SIP address is stored in at least one of said memory devices, at least one of said forwarding SIP addresses being selectable by a user via said user interface subsystem, and wherein on detection of a call directed to the appliance from a caller, said call is redirected to the selected forwarding SIP address.
10. The network appliance according to claim 9, wherein said call forwarding feature is activated for a predetermined time in response to an input from the user.
11. The network appliance according to claim 9, further comprising a sensor coupled to said appliance for detecting the absence of a human being, wherein said call forwarding feature is activated in response to a signal from said sensor.
12. The network appliance according to claim 1, wherein the user interface subsystem includes an output device and wherein the computer program implements a streaming media mode wherein streaming data is received from the network and is converted to perceptable signals provided to said output device.
13. The network appliance according to claim 12 wherein the output device includes a speaker and wherein when no call session is in progress streaming data is received from the network and is converted to audio signals provided to said speaker.
14. The network appliance according to claim 13 wherein the program reverts out of streaming media mode in the event a new call session is initiated.
15. The network appliance according to claim 12 wherein the output device includes a speaker and wherein streaming data is selectively received from the network and is converted to audio signals provided to said speaker.
16. The network appliance according to claim 12 wherein the streaming data is received from the network and is selectively forwarded to another device during a call session where the data is convertable to perceptable signals by said device.
17. The network appliance according to claim 12 wherein the output device includes a video display and wherein streaming data includes streaming video data which is selectively received from the network and is converted to video signals provided to said display.
18. The network appliance of claim 3, wherein the user interface subsystem includes a display device and wherein the digital signal processor detects the SIP address of callers and stores a plurality of caller SIP addresses in at least one of said memory devices, said plurality of caller SIP addresses being displayable on said display device and selectable in response to an input from the user interface subsystem.
19. The network appliance of claim 3, wherein the user interface subsystem includes a display device and wherein the digital signal processor stores a plurality of called SIP addresses in said memory device, said called SIP addresses corresponding to the address of successfully initiated call sessions and being displayable on said display device and selectable in response to an input from the user interface subsystem.
20. The network appliance according to claim 1, wherein said network controller subsystem comprises an Ethernet controller and a service filter.
US12/560,821 1999-06-08 2009-09-16 Network telephony appliance and system for inter/intranet telephony Abandoned US20100002690A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/560,821 US20100002690A1 (en) 1999-06-08 2009-09-16 Network telephony appliance and system for inter/intranet telephony

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13883299P 1999-06-08 1999-06-08
PCT/US2000/040175 WO2000076158A1 (en) 1999-06-08 2000-06-08 Network telephony appliance and system for inter/intranet telephony
US98088502A 2002-03-22 2002-03-22
US12/560,821 US20100002690A1 (en) 1999-06-08 2009-09-16 Network telephony appliance and system for inter/intranet telephony

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US98088502A Continuation 1999-06-08 2002-03-22

Publications (1)

Publication Number Publication Date
US20100002690A1 true US20100002690A1 (en) 2010-01-07

Family

ID=22483871

Family Applications (4)

Application Number Title Priority Date Filing Date
US09/980,885 Expired - Lifetime US7610384B1 (en) 1999-06-08 2000-06-08 Network telephony appliance and system for inter/intranet telephony
US12/468,707 Expired - Lifetime US8271660B2 (en) 1999-06-08 2009-05-19 Network telephony appliance and system for inter/intranet telephony
US12/560,821 Abandoned US20100002690A1 (en) 1999-06-08 2009-09-16 Network telephony appliance and system for inter/intranet telephony
US13/588,369 Expired - Lifetime US9413585B2 (en) 1999-06-08 2012-08-17 Network telephony appliance and system for inter/intranet telephony

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/980,885 Expired - Lifetime US7610384B1 (en) 1999-06-08 2000-06-08 Network telephony appliance and system for inter/intranet telephony
US12/468,707 Expired - Lifetime US8271660B2 (en) 1999-06-08 2009-05-19 Network telephony appliance and system for inter/intranet telephony

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/588,369 Expired - Lifetime US9413585B2 (en) 1999-06-08 2012-08-17 Network telephony appliance and system for inter/intranet telephony

Country Status (10)

Country Link
US (4) US7610384B1 (en)
EP (1) EP1186144B1 (en)
JP (1) JP4999244B2 (en)
KR (1) KR100670006B1 (en)
AU (1) AU6120900A (en)
CA (1) CA2376214A1 (en)
ES (1) ES2441203T3 (en)
IL (2) IL146885A0 (en)
MX (1) MXPA01012622A (en)
WO (1) WO2000076158A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070115926A1 (en) * 2005-10-27 2007-05-24 3Com Corporation System and method for receiving a user message at a packet-network telephone
US20090067350A1 (en) * 2006-05-05 2009-03-12 Marika Stalnacke Method and arrangement for virtual meeting
US20090100124A1 (en) * 2007-10-10 2009-04-16 Sony Ericsson Mobile Communications Ab Web feeds over sip
US20090290695A1 (en) * 1999-06-08 2009-11-26 Henning Schulzrinne Network Telephony Appliance and System for Inter/Intranet Telephony
US20120002663A1 (en) * 2010-06-30 2012-01-05 International Business Machines Corporation Controlling telephone call processing using global signaling codes
US8675832B2 (en) 2000-08-11 2014-03-18 The Trustees Of Columbia University In The City Of New York System and method for unified messaging in inter/intranet telephony
US8804513B2 (en) 2010-02-25 2014-08-12 The Trustees Of Columbia University In The City Of New York Methods and systems for controlling SIP overload

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7072308B2 (en) 1997-10-21 2006-07-04 Intel Corporation Apparatus and method for computer controlled call processing applications in packet switched telephone networks
US7126942B2 (en) 1997-10-21 2006-10-24 Intel Corporation Apparatus and method for integrated computer controlled call processing in packet switched telephone networks
US7068648B2 (en) 1997-10-21 2006-06-27 Intel Corporation Apparatus and method for computer controlled call processing and information provision
US6201805B1 (en) 1997-10-21 2001-03-13 Dialogic Corporation Apparatus and method for computer telephone integration in packet switched telephone networks
US6901068B1 (en) 1997-10-21 2005-05-31 Intel Corporation Apparatus and method for computer controlled call processing applications in packet switched telephone networks
US6876633B2 (en) * 1997-10-21 2005-04-05 Intel Corporation Apparatus and method for computer telephone integration in packet switched telephone networks
US6856618B2 (en) 1997-10-21 2005-02-15 Intel Corporation Apparatus and method for computer telephone integration in packet switched telephone networks
US20070121601A1 (en) * 1998-09-24 2007-05-31 Genesys Telecommunications Laboratories, Inc Integrating SIP Control Messaging into Existing Communication Center Routing Infrastructure
US6958994B2 (en) 1998-09-24 2005-10-25 Genesys Telecommunications Laboratories, Inc. Call transfer using session initiation protocol (SIP)
US7120141B2 (en) * 1998-09-24 2006-10-10 Genesys Telecommunications Laboratories, Inc. Integrating SIP control messaging into existing communication center routing infrastructure
US9607041B2 (en) * 1999-07-15 2017-03-28 Gula Consulting Limited Liability Company System and method for efficiently accessing internet resources
US20060121938A1 (en) * 1999-08-12 2006-06-08 Hawkins Jeffrey C Integrated handheld computing and telephony device
US7286521B1 (en) * 2000-07-21 2007-10-23 Tellme Networks, Inc. Localized voice over internet protocol communication
ATE453264T1 (en) * 2001-01-26 2010-01-15 American Power Conv Corp METHOD AND APPARATUS FOR NETWORK-CONNECTED DEVICES THAT CAN BE CONNECTED TO ACHIEVE IMPROVED COLLABORATION, SCALABILITY AND RELIABILITY
EP1368975A1 (en) 2001-03-09 2003-12-10 Ayman L.L.C. Universal point of contact identifier system and method
US7002987B2 (en) 2001-06-07 2006-02-21 Motorola, Inc. Common services and applications agent
US7746848B2 (en) 2002-12-05 2010-06-29 Resource Consortium Limited Virtual PBX based on feature server modules
WO2004057846A1 (en) * 2002-12-20 2004-07-08 Nimcat Networks Inc. Voice mail system for packet switched networks
DE10301262A1 (en) * 2003-01-15 2004-08-05 Siemens Ag Method and arrangement for establishing a communication link using a transmission network
US7751546B2 (en) * 2003-01-22 2010-07-06 Avaya Canada Corp. Call transfer system, method and network devices
US7394345B1 (en) * 2003-12-08 2008-07-01 At&T Corp. Arrangement for indicating presence of individual
HUP0400899A2 (en) * 2004-04-30 2006-02-28 Zoltan Kuthi Voice controlled call divert
US7881446B1 (en) 2004-09-03 2011-02-01 Confinement Telephony Technology, Llc Telephony system and method with enhanced validation
US7680256B2 (en) * 2005-08-18 2010-03-16 One Number Corporation Contact number encapsulation system
KR100772172B1 (en) * 2005-11-21 2007-10-31 한국전자통신연구원 Switching method and apparatus of real-time multicast packet stream, and ethernet switching system using the same
US20080259918A1 (en) 2007-04-19 2008-10-23 Craig Elliott Walker Method and apparatus for managing telephone calls
CN101755495B (en) 2007-05-15 2013-10-16 美国能量变换公司 Methods and systems for managing facility power and cooling
US8290133B2 (en) * 2007-05-31 2012-10-16 Centurylink Intellectual Property Llc System and method for remote home monitoring and intercom communication
US8290138B2 (en) * 2007-07-20 2012-10-16 Ipc Systems, Inc. Systems, methods, apparatus and computer program products for sharing resources between turret systems and PBXS using SIP
US8306509B2 (en) 2007-08-31 2012-11-06 At&T Mobility Ii Llc Enhanced messaging with language translation feature
US8411669B2 (en) * 2008-04-18 2013-04-02 Cisco Technology, Inc. Distributed transcoding on IP phones with idle DSP channels
US8868907B2 (en) 2009-03-18 2014-10-21 University Of Louisville Research Foundation, Inc. Device, method, and system for processing communications for secure operation of industrial control system field devices
US8402267B1 (en) 2009-03-18 2013-03-19 University Of Louisville Research Foundation, Inc. Security enhanced network device and method for secure operation of same
JP5453525B2 (en) * 2009-06-01 2014-03-26 テレフオンアクチーボラゲット エル エム エリクソン(パブル) Graphical user interface for a terminal having a visual display of call progress
DE102009042354C5 (en) * 2009-09-23 2017-07-13 Phoenix Contact Gmbh & Co. Kg Method and device for safety-related communication in the communication network of an automation system
US9824334B2 (en) 2011-07-11 2017-11-21 ClearCare, Inc. System for updating a calendar or task status in home care scheduling via telephony
US9015641B2 (en) 2011-01-06 2015-04-21 Blackberry Limited Electronic device and method of providing visual notification of a received communication
US9465440B2 (en) 2011-01-06 2016-10-11 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9423878B2 (en) 2011-01-06 2016-08-23 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9477311B2 (en) 2011-01-06 2016-10-25 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9471145B2 (en) 2011-01-06 2016-10-18 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9766718B2 (en) 2011-02-28 2017-09-19 Blackberry Limited Electronic device and method of displaying information in response to input
US9213421B2 (en) 2011-02-28 2015-12-15 Blackberry Limited Electronic device and method of displaying information in response to detecting a gesture
CN104137105B (en) 2011-12-22 2017-07-11 施耐德电气It公司 Impact analysis on temporal event to the temperature in data center
US9619038B2 (en) 2012-01-23 2017-04-11 Blackberry Limited Electronic device and method of displaying a cover image and an application image from a low power condition
US9058168B2 (en) 2012-01-23 2015-06-16 Blackberry Limited Electronic device and method of controlling a display
US9106673B2 (en) * 2012-12-28 2015-08-11 Vonage Network, Llc Systems and methods for connecting telephony communications
US9690476B2 (en) 2013-03-14 2017-06-27 Blackberry Limited Electronic device and method of displaying information in response to a gesture
US9507495B2 (en) 2013-04-03 2016-11-29 Blackberry Limited Electronic device and method of displaying information in response to a gesture
DE102013219543A1 (en) * 2013-09-27 2015-04-02 Siemens Aktiengesellschaft Communication device and method for communication between a communication device and a central device
US10078635B2 (en) * 2013-11-22 2018-09-18 Genband Us Llc Systems and methods for customizing SIP message processing
US9912783B2 (en) 2016-01-29 2018-03-06 Veritas Technologies Llc Securing internal services in a distributed environment
US11029998B2 (en) * 2016-06-03 2021-06-08 International Business Machines Corporation Grouping of tasks for distribution among processing entities
US11230495B2 (en) 2017-04-25 2022-01-25 Gcp Applied Technologies Inc. Agents for enhancing cement strength
GB2604566A (en) * 2019-12-05 2022-09-07 Cubic Corp Radio gateway transmission failure notification
US11425247B1 (en) * 2021-02-11 2022-08-23 Verizon Patent And Licensing Inc. Methods and systems for reducing resource usage for call originations

Citations (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572678A (en) * 1992-01-24 1996-11-05 Hitachi, Ltd. System for sending frames from sender to receiver using connectionless protocol and receiving acknowledging frame and retransmission request frame from receiver using connection oriented protocol
US5647002A (en) * 1995-09-01 1997-07-08 Lucent Technologies Inc. Synchronization of mailboxes of different types
US5675507A (en) * 1995-04-28 1997-10-07 Bobo, Ii; Charles R. Message storage and delivery system
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US5757798A (en) * 1994-07-21 1998-05-26 Hitachi, Ltd. Image information distribution system
US5778187A (en) * 1996-05-09 1998-07-07 Netcast Communications Corp. Multicasting method and apparatus
US5867495A (en) * 1996-11-18 1999-02-02 Mci Communications Corporations System, method and article of manufacture for communications utilizing calling, plans in a hybrid network
US5893091A (en) * 1997-04-11 1999-04-06 Immediata Corporation Multicasting with key words
US5892535A (en) * 1996-05-08 1999-04-06 Digital Video Systems, Inc. Flexible, configurable, hierarchical system for distributing programming
US5903559A (en) * 1996-12-20 1999-05-11 Nec Usa, Inc. Method for internet protocol switching over fast ATM cell transport
US5909183A (en) * 1996-12-26 1999-06-01 Motorola, Inc. Interactive appliance remote controller, system and method
US5990883A (en) * 1997-04-28 1999-11-23 Microsoft Corporation Unified presentation of programming from different physical sources
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
US6011579A (en) * 1996-12-10 2000-01-04 Motorola, Inc. Apparatus, method and system for wireline audio and video conferencing and telephony, with network interactivity
US6034621A (en) * 1997-11-18 2000-03-07 Lucent Technologies, Inc. Wireless remote synchronization of data between PC and PDA
US6075796A (en) * 1997-03-17 2000-06-13 At&T Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony
US6085101A (en) * 1996-05-17 2000-07-04 Telcordia Technologies, Inc. Communications network having a multicast capability
US6088659A (en) * 1997-09-11 2000-07-11 Abb Power T&D Company Inc. Automated meter reading system
US6101180A (en) * 1996-11-12 2000-08-08 Starguide Digital Networks, Inc. High bandwidth broadcast system having localized multicast access to broadcast content
US6108706A (en) * 1997-06-09 2000-08-22 Microsoft Corporation Transmission announcement system and method for announcing upcoming data transmissions over a broadcast network
US6119007A (en) * 1997-03-01 2000-09-12 Motorola, Inc. Method of transmitting call information
US6125113A (en) * 1996-04-18 2000-09-26 Bell Atlantic Network Services, Inc. Internet telephone service
US6199068B1 (en) * 1997-09-11 2001-03-06 Abb Power T&D Company Inc. Mapping interface for a distributed server to translate between dissimilar file formats
US6275574B1 (en) * 1998-12-22 2001-08-14 Cisco Technology, Inc. Dial plan mapper
US6337858B1 (en) * 1997-10-10 2002-01-08 Nortel Networks Limited Method and apparatus for originating voice calls from a data network
US20020049817A1 (en) * 2001-07-12 2002-04-25 Eatamar Drory Storageless system and method for unified messaging on existing mail accounts via standard internet mail protocols
US6434143B1 (en) * 1999-11-08 2002-08-13 Mci Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US20020123895A1 (en) * 2001-02-06 2002-09-05 Sergey Potekhin Control unit for multipoint multimedia/audio conference
US6493324B1 (en) * 1999-03-29 2002-12-10 Worldcom, Inc. Multimedia interface for IP telephony
US6529501B1 (en) * 1998-05-29 2003-03-04 3Com Corporation Method and apparatus for internet telephony
US20030055974A1 (en) * 1999-08-24 2003-03-20 Kevin Brophy Systems and methods for providing unified multimedia communication services
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
US6597686B1 (en) * 1997-04-22 2003-07-22 Telcordia Technologies, Inc. Apparatus and method for internet telephony routing
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
US6625258B1 (en) * 1999-12-27 2003-09-23 Nortel Networks Ltd System and method for providing unified communication services support
US6665727B2 (en) * 1992-11-25 2003-12-16 Hewlett-Packard Development Company, L.P. Dynamic assignment of multicast network addresses
US6671276B1 (en) * 1997-11-18 2003-12-30 Nec Corporation Switch based network architecture for IP multicast and integrated services
US6690663B1 (en) * 1998-01-15 2004-02-10 Mci Communications Corporation Internet telephony system with automated call answering
US20040044791A1 (en) * 2001-05-22 2004-03-04 Pouzzner Daniel G. Internationalized domain name system with iterative conversion
US20040042607A1 (en) * 1999-09-24 2004-03-04 Mci Worldcom, Inc. Method of and system for providing intelligent network control services in IP telephony
US6741575B1 (en) * 1999-02-26 2004-05-25 Hughes Electronics Corporation Apparatus and method for efficient delivery of multicast data over personal access communications system (PACS)
US6763020B1 (en) * 1998-06-24 2004-07-13 Innomedia, Inc. Call establishment method for dial-up internet telephony appliances
US6795444B1 (en) * 1999-10-26 2004-09-21 Telefonaktiebolaget L M Ericsson (Publ) System and method for providing wireless telephony over a packet-switched network
US20040194102A1 (en) * 2001-01-16 2004-09-30 Neerdaels Charles J Using virutal domain name service (dns) zones for enterprise content delivery
US20040246949A1 (en) * 1999-06-14 2004-12-09 Mci Worldcom. Inc. Internet protocol transport of PSTN-to-PSTN telephony services
US6839323B1 (en) * 2000-05-15 2005-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Method of monitoring calls in an internet protocol (IP)-based network
US6842505B1 (en) * 1999-04-05 2005-01-11 Estech Systems, Inc. Communications system enhanced with human presence sensing capabilities
US6850496B1 (en) * 2000-06-09 2005-02-01 Cisco Technology, Inc. Virtual conference room for voice conferencing
US20050025073A1 (en) * 2001-01-25 2005-02-03 Kwan Katherine Wang Efficient buffer allocation for current and predicted active speakers in voice conferencing systems
US6898188B1 (en) * 2001-04-19 2005-05-24 3Com Corporation Gatekeeper simulator in a LAN telephony system
US6912278B1 (en) * 2000-08-31 2005-06-28 Cisco Technology, Inc. Call management implemented using call routing engine
US6970909B2 (en) * 2001-10-11 2005-11-29 The Trustees Of Columbia University In The City Of New York Multi-protocol data communication system supporting wireless telephony and content delivery
US7016343B1 (en) * 2001-12-28 2006-03-21 Cisco Technology, Inc. PSTN call routing control features applied to a VoIP
US7066616B2 (en) * 2003-06-20 2006-06-27 Howell Jay E Modular temporary lighting assembly
US7216348B1 (en) * 1999-01-05 2007-05-08 Net2Phone, Inc. Method and apparatus for dynamically balancing call flow workloads in a telecommunications system
US7257201B2 (en) * 2000-08-11 2007-08-14 The Trustees Of Columbia University In The City Of New York System and method for unified messaging in inter/intranet telephony
US7266091B2 (en) * 2001-02-28 2007-09-04 The Trustees Of Columbia University In City Of New York System and method for conferencing in inter/intranet telephony
US7296091B1 (en) * 1999-06-18 2007-11-13 The Trustees Of Columbia University In The City Of New York System and method for receiving over a network a broadcast from a broadcast source
US7614384B2 (en) * 2007-11-02 2009-11-10 Gm Global Technology Operations, Inc. Engine torque control with desired state estimation

Family Cites Families (93)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6165555A (en) 1984-09-05 1986-04-04 Mitsubishi Electric Corp Home control system
JPH0754933B2 (en) * 1986-08-14 1995-06-07 日本電気株式会社 Circuit switching method and device in packet network
JPS63286044A (en) 1987-05-19 1988-11-22 Tamura Electric Works Ltd Functional telephone set
JPH0368063A (en) 1989-08-07 1991-03-25 Seiko Epson Corp Documentation device
JPH0521914A (en) 1991-07-17 1993-01-29 Tatsuta Electric Wire & Cable Co Ltd Flexible printed circuit board
JPH07283815A (en) 1994-04-08 1995-10-27 Hitachi Ltd Voice communication system
US6108704A (en) * 1995-09-25 2000-08-22 Netspeak Corporation Point-to-point internet protocol
JPH09168063A (en) 1995-12-18 1997-06-24 Sony Corp Terminal equipment for speech system
JP3254220B2 (en) * 1996-02-21 2002-02-04 インターナショナル・ビジネス・マシーンズ・コーポレーション Distributed architecture for services in telephony systems
GB2310970A (en) * 1996-03-05 1997-09-10 Ibm Voice mail on the Internet
AU4353097A (en) 1996-09-12 1998-04-02 Dialnet, Inc. Dedicated system and process for distributed communication on a packet-switched network
MXPA99004611A (en) * 1996-11-18 2005-01-25 Mci Worldcom Inc A communication system architecture.
JP3085216B2 (en) * 1996-11-28 2000-09-04 日本電気株式会社 Telephone communication terminal and communication method using the same
FR2756998A1 (en) 1996-12-06 1998-06-12 Philips Electronics Nv TELECOMMUNICATION DEVICE COMPRISING A BASE AND AT LEAST ONE MOBILE DEVICE PROVIDED WITH A PARTICULAR INTERCOM MODE, AND METHOD OF INITIALIZING THE MODE
US6144671A (en) * 1997-03-04 2000-11-07 Nortel Networks Corporation Call redirection methods in a packet based communications network
JPH113072A (en) 1997-06-12 1999-01-06 Sony Corp Information network system and communication terminal
JP3263339B2 (en) 1997-07-18 2002-03-04 日本電信電話株式会社 Internet / telephone network integrated utilization method and system
US6243376B1 (en) * 1997-08-13 2001-06-05 Mediaring.Com Ltd. Method and apparatus for making a phone call connection over the internet connection
JP3844026B2 (en) 1997-08-15 2006-11-08 ソニー株式会社 Information communication method, information communication system, communication terminal, and server apparatus
DE69836070T2 (en) * 1997-08-19 2007-01-11 Yugen Kaisha Ls Net METHOD FOR COMMUNICATING WITH SUBSCRIBER DEVICES THROUGH A GLOBAL COMMUNICATION NETWORK
JPH11112677A (en) * 1997-09-30 1999-04-23 Canon Inc Speech communication terminal
US6360265B1 (en) * 1998-07-08 2002-03-19 Lucent Technologies Inc. Arrangement of delivering internet protocol datagrams for multimedia services to the same server
US6707797B1 (en) * 1998-10-23 2004-03-16 Verizon Corporate Services Group Inc. Multi-line telephony via network gateways
US7006616B1 (en) * 1999-05-21 2006-02-28 Terayon Communication Systems, Inc. Teleconferencing bridge with EdgePoint mixing
US6614805B1 (en) 1999-05-27 2003-09-02 Nortel Networks Limited Method and apparatus for media access control for packet transmission over a buffer insertion ring
KR100670006B1 (en) * 1999-06-08 2007-01-18 더 트러스티스 오브 콜롬비아 유니버시티 인 더 시티 오브 뉴욕 Network telephony appliance and system for inter/intranet telephony
US6832254B1 (en) * 1999-08-23 2004-12-14 Nortel Networks Limited Method and apparatus for associating an end-to-end call identifier with a connection in a multimedia packet network
EP1102498B1 (en) * 1999-11-09 2004-02-25 Nortel Networks Corporation Telephony services in a communications network
US6701366B1 (en) * 1999-11-09 2004-03-02 Nortel Networks Corporation Providing communications services
US6826173B1 (en) * 1999-12-30 2004-11-30 At&T Corp. Enhanced subscriber IP alerting
US7069432B1 (en) * 2000-01-04 2006-06-27 Cisco Technology, Inc. System and method for providing security in a telecommunication network
US6678735B1 (en) * 2000-01-26 2004-01-13 Nortel Networks Limited Method and apparatus for a sip client manager
US7286521B1 (en) * 2000-07-21 2007-10-23 Tellme Networks, Inc. Localized voice over internet protocol communication
US7088720B1 (en) * 2000-08-07 2006-08-08 Sbc Technology Resources, Inc. Multiservice use of network connection capability under user-to-network interface signaling
US6934756B2 (en) * 2000-11-01 2005-08-23 International Business Machines Corporation Conversational networking via transport, coding and control conversational protocols
US7072303B2 (en) * 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
US6865681B2 (en) * 2000-12-29 2005-03-08 Nokia Mobile Phones Ltd. VoIP terminal security module, SIP stack with security manager, system and security methods
US20020103850A1 (en) * 2001-01-31 2002-08-01 Moyer Stanley L. System and method for out-sourcing the functionality of session initiation protocol (SIP) user agents to proxies
GB2370448B (en) * 2001-04-28 2003-03-26 Ericsson Telefon Ab L M Cost control in a SIP based network
US20040255039A1 (en) * 2001-05-10 2004-12-16 Bernard Honeisen Method, system and network element device for controlling sessions between terminals
US7640326B2 (en) * 2002-04-03 2009-12-29 Cisco Technology, Inc. Relaying of message waiting indications to support distributed telephony networks
US7139797B1 (en) * 2002-04-10 2006-11-21 Nortel Networks Limited Presence information based on media activity
US8255501B2 (en) * 2002-05-15 2012-08-28 Motorola Mobility Llc Establishing an IP session between a host using SIP and a device without an IP address
KR100453350B1 (en) * 2002-06-17 2004-10-15 엘지전자 주식회사 Routing Device and Method of Using BICC in the Next Generation Open Network
WO2004006475A2 (en) * 2002-07-04 2004-01-15 Nokia Corporation Managing a packet switched conference call
US7167912B1 (en) * 2002-08-09 2007-01-23 Cisco Technology, Inc. Method and apparatus for detecting failures in network components
US7826868B2 (en) * 2002-10-10 2010-11-02 Robbins Barry R Extension of a local area phone system to a wide area network
US20050041646A1 (en) * 2003-06-27 2005-02-24 Marconi Communications, Inc. Audio mixer and method
EP1507395A1 (en) * 2003-08-14 2005-02-16 Siemens Aktiengesellschaft Method for the setting up of call forwarding for a SIP telephone number of a SIP client in a mixed circuit switched / packet network
JP4728586B2 (en) * 2004-03-16 2011-07-20 Necインフロンティア株式会社 IP phone method
US7301938B2 (en) * 2004-04-14 2007-11-27 Lucent Technologies Inc. Method of transferring a packet switched to a circuit switched call
US8027335B2 (en) * 2004-05-05 2011-09-27 Prodea Systems, Inc. Multimedia access device and system employing the same
US7613170B1 (en) * 2004-06-29 2009-11-03 3Com Corporation Method and apparatus for PSTN-based IP active call recovery and re-routing
US8218457B2 (en) * 2004-06-29 2012-07-10 Stmicroelectronics Asia Pacific Pte. Ltd. Apparatus and method for providing communication services using multiple signaling protocols
US7840681B2 (en) * 2004-07-30 2010-11-23 International Business Machines Corporation Method and apparatus for integrating wearable devices within a SIP infrastructure
US7983245B2 (en) * 2004-09-13 2011-07-19 Tekelec Methods and systems for converting an internet protocol (IP)-based message containing subscriber content to a public switched telephone network (PSTN)-based message including subscriber content
US7593390B2 (en) * 2004-12-30 2009-09-22 Intel Corporation Distributed voice network
US8194640B2 (en) * 2004-12-31 2012-06-05 Genband Us Llc Voice over IP (VoIP) network infrastructure components and method
US7483416B2 (en) * 2005-04-01 2009-01-27 Cml Emergency Services Inc. Internet protocol radio dispatch system and method
JP4690767B2 (en) * 2005-05-11 2011-06-01 株式会社日立製作所 Network system, server device, and communication method
US8401004B2 (en) * 2005-06-21 2013-03-19 Lg Electronics Inc. Terminal, method and system for performing combination service using terminal capability version
US8019986B2 (en) * 2005-08-12 2011-09-13 Comcast Cable Holdings, Llc Method and system for booting, provisioning and activating hardware and software clients
US20070115919A1 (en) * 2005-10-14 2007-05-24 3Com Corporation Method and system for using a packet-network telephone to schedule a conference call
US7643472B2 (en) * 2005-10-19 2010-01-05 At&T Intellectual Property I, Lp Methods and apparatus for authorizing and allocating outdial communication services
JP4585480B2 (en) * 2006-03-30 2010-11-24 株式会社東芝 Telephone system and telephone exchange device
US9219686B2 (en) 2006-03-31 2015-12-22 Alcatel Lucent Network load balancing and overload control
US8837704B2 (en) * 2006-08-31 2014-09-16 Microsoft Corporation Client controlled dynamic call forwarding
US7620167B2 (en) * 2006-09-21 2009-11-17 Siemens Communications, Inc. Apparatus to override the redirect or reject feature at an SIP end point
US20080123627A1 (en) * 2006-09-26 2008-05-29 Moreman Charles S Media terminal adapter with session initiation protocol (sip) proxy
CA2666979C (en) * 2006-10-19 2013-02-19 Ascendent Telecommunications, Inc. Client device method and apparatus for routing a call
US20080130628A1 (en) * 2006-11-07 2008-06-05 Shiejye Geoffrey Lin Systems and methods for providing advanced call processing features to analog telephone subscribers
US8873405B2 (en) * 2006-12-15 2014-10-28 Verizon Patent And Licensing Inc. Automated session initiation protocol (SIP) device
CN1988546A (en) * 2006-12-15 2007-06-27 华为技术有限公司 Method and system for obtaining conversation start protocol news transmission path
JP2008153896A (en) * 2006-12-15 2008-07-03 Nec Corp Content distribution system, content server side user terminal, content client side user terminal and authentication method of content distribution system
US8189570B2 (en) * 2006-12-28 2012-05-29 Alcatel Lucent System and method for processing calls to VoIP devices using the called party's email address
EP2116002B1 (en) * 2007-01-16 2016-09-21 Telefonaktiebolaget LM Ericsson (publ) Evaluating initial filter criteria
KR101429712B1 (en) * 2007-01-19 2014-08-12 삼성전자주식회사 Blind transfer and attended transfer system and control method in network of SIP base
US8085742B2 (en) * 2007-01-31 2011-12-27 Research In Motion Limited Call forwarding methods and apparatus for mobile communication devices which operate in WWANS and WLANS
US20080219241A1 (en) * 2007-03-09 2008-09-11 Nokia Corporation Subscriber access authorization
US8223757B2 (en) * 2007-06-11 2012-07-17 At&T Intellectual Property I, L.P. Methods and apparatus to perform call screening in a voice over internet protocol (VOIP) network
US20100172342A1 (en) * 2007-10-31 2010-07-08 Christer Boberg Session Initiation Protocol Message Payload Compression
US8855103B2 (en) * 2008-01-17 2014-10-07 Blackberry Limited Personal network access control system and method
WO2009129487A2 (en) * 2008-04-17 2009-10-22 Tekelec Methods, systems, and computer readable media for session initiation protocol (sip) overload control
US8838819B2 (en) * 2009-04-17 2014-09-16 Empirix Inc. Method for embedding meta-commands in normal network packets
US8804513B2 (en) 2010-02-25 2014-08-12 The Trustees Of Columbia University In The City Of New York Methods and systems for controlling SIP overload
US20120014375A1 (en) * 2010-07-16 2012-01-19 Avaya Inc. Method for Telephone Connection Preservation
US8811393B2 (en) * 2010-10-04 2014-08-19 Cisco Technology, Inc. IP address version interworking in communication networks
US20140007083A1 (en) * 2010-12-21 2014-01-02 Telefonaktiebolaget L M Ericsson (Publ) Delivery and execution of logic in user terminal in ims session
US8890925B2 (en) * 2011-12-07 2014-11-18 Positron Telecommunication Systems, Inc. Systems and methods for mapping a URI to a plurality of endpoints for a SIP communication
EP2640030B1 (en) * 2012-03-12 2014-11-12 Telefonaktiebolaget LM Ericsson (publ) Capability update in a telecommunications network
US9294618B2 (en) * 2012-04-03 2016-03-22 Telefonaktiebolaget L M Ericsson (Publ) Call-back to a UE that has made an emergency call via a visited IMS network
US9407672B2 (en) * 2013-10-30 2016-08-02 Vonage America Inc. Systems and methods for reducing signalling in an internet protocol telephony system
US9178773B1 (en) * 2014-04-15 2015-11-03 Green Key Technologies Llc Computer-programmed telephone-enabled devices for processing and managing numerous simultaneous voice conversations conducted by an individual over a computer network and computer methods of implementing thereof

Patent Citations (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572678A (en) * 1992-01-24 1996-11-05 Hitachi, Ltd. System for sending frames from sender to receiver using connectionless protocol and receiving acknowledging frame and retransmission request frame from receiver using connection oriented protocol
US6665727B2 (en) * 1992-11-25 2003-12-16 Hewlett-Packard Development Company, L.P. Dynamic assignment of multicast network addresses
US5757798A (en) * 1994-07-21 1998-05-26 Hitachi, Ltd. Image information distribution system
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5675507A (en) * 1995-04-28 1997-10-07 Bobo, Ii; Charles R. Message storage and delivery system
US5647002A (en) * 1995-09-01 1997-07-08 Lucent Technologies Inc. Synchronization of mailboxes of different types
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
US6125113A (en) * 1996-04-18 2000-09-26 Bell Atlantic Network Services, Inc. Internet telephone service
US5892535A (en) * 1996-05-08 1999-04-06 Digital Video Systems, Inc. Flexible, configurable, hierarchical system for distributing programming
US5778187A (en) * 1996-05-09 1998-07-07 Netcast Communications Corp. Multicasting method and apparatus
US6085101A (en) * 1996-05-17 2000-07-04 Telcordia Technologies, Inc. Communications network having a multicast capability
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US6101180A (en) * 1996-11-12 2000-08-08 Starguide Digital Networks, Inc. High bandwidth broadcast system having localized multicast access to broadcast content
US6266339B1 (en) * 1996-11-12 2001-07-24 Starguide Digital Networks, Inc. High bandwidth broadcast system having localized multicast access to broadcast content
US5867495A (en) * 1996-11-18 1999-02-02 Mci Communications Corporations System, method and article of manufacture for communications utilizing calling, plans in a hybrid network
US6011579A (en) * 1996-12-10 2000-01-04 Motorola, Inc. Apparatus, method and system for wireline audio and video conferencing and telephony, with network interactivity
US5903559A (en) * 1996-12-20 1999-05-11 Nec Usa, Inc. Method for internet protocol switching over fast ATM cell transport
US5909183A (en) * 1996-12-26 1999-06-01 Motorola, Inc. Interactive appliance remote controller, system and method
US6119007A (en) * 1997-03-01 2000-09-12 Motorola, Inc. Method of transmitting call information
US6075796A (en) * 1997-03-17 2000-06-13 At&T Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony
US5893091A (en) * 1997-04-11 1999-04-06 Immediata Corporation Multicasting with key words
US6597686B1 (en) * 1997-04-22 2003-07-22 Telcordia Technologies, Inc. Apparatus and method for internet telephony routing
US5990883A (en) * 1997-04-28 1999-11-23 Microsoft Corporation Unified presentation of programming from different physical sources
US6108706A (en) * 1997-06-09 2000-08-22 Microsoft Corporation Transmission announcement system and method for announcing upcoming data transmissions over a broadcast network
US6088659A (en) * 1997-09-11 2000-07-11 Abb Power T&D Company Inc. Automated meter reading system
US6199068B1 (en) * 1997-09-11 2001-03-06 Abb Power T&D Company Inc. Mapping interface for a distributed server to translate between dissimilar file formats
US6608832B2 (en) * 1997-09-25 2003-08-19 Telefonaktiebolaget Lm Ericsson Common access between a mobile communications network and an external network with selectable packet-switched and circuit-switched and circuit-switched services
US6337858B1 (en) * 1997-10-10 2002-01-08 Nortel Networks Limited Method and apparatus for originating voice calls from a data network
US6671276B1 (en) * 1997-11-18 2003-12-30 Nec Corporation Switch based network architecture for IP multicast and integrated services
US6034621A (en) * 1997-11-18 2000-03-07 Lucent Technologies, Inc. Wireless remote synchronization of data between PC and PDA
US6690663B1 (en) * 1998-01-15 2004-02-10 Mci Communications Corporation Internet telephony system with automated call answering
US6529501B1 (en) * 1998-05-29 2003-03-04 3Com Corporation Method and apparatus for internet telephony
US6763020B1 (en) * 1998-06-24 2004-07-13 Innomedia, Inc. Call establishment method for dial-up internet telephony appliances
US6275574B1 (en) * 1998-12-22 2001-08-14 Cisco Technology, Inc. Dial plan mapper
US7216348B1 (en) * 1999-01-05 2007-05-08 Net2Phone, Inc. Method and apparatus for dynamically balancing call flow workloads in a telecommunications system
US6741575B1 (en) * 1999-02-26 2004-05-25 Hughes Electronics Corporation Apparatus and method for efficient delivery of multicast data over personal access communications system (PACS)
US6493324B1 (en) * 1999-03-29 2002-12-10 Worldcom, Inc. Multimedia interface for IP telephony
US6842505B1 (en) * 1999-04-05 2005-01-11 Estech Systems, Inc. Communications system enhanced with human presence sensing capabilities
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
US20040246949A1 (en) * 1999-06-14 2004-12-09 Mci Worldcom. Inc. Internet protocol transport of PSTN-to-PSTN telephony services
US7296091B1 (en) * 1999-06-18 2007-11-13 The Trustees Of Columbia University In The City Of New York System and method for receiving over a network a broadcast from a broadcast source
US20030055974A1 (en) * 1999-08-24 2003-03-20 Kevin Brophy Systems and methods for providing unified multimedia communication services
US20040042607A1 (en) * 1999-09-24 2004-03-04 Mci Worldcom, Inc. Method of and system for providing intelligent network control services in IP telephony
US6795444B1 (en) * 1999-10-26 2004-09-21 Telefonaktiebolaget L M Ericsson (Publ) System and method for providing wireless telephony over a packet-switched network
US6434143B1 (en) * 1999-11-08 2002-08-13 Mci Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US6625258B1 (en) * 1999-12-27 2003-09-23 Nortel Networks Ltd System and method for providing unified communication services support
US6839323B1 (en) * 2000-05-15 2005-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Method of monitoring calls in an internet protocol (IP)-based network
US6850496B1 (en) * 2000-06-09 2005-02-01 Cisco Technology, Inc. Virtual conference room for voice conferencing
US7257201B2 (en) * 2000-08-11 2007-08-14 The Trustees Of Columbia University In The City Of New York System and method for unified messaging in inter/intranet telephony
US6912278B1 (en) * 2000-08-31 2005-06-28 Cisco Technology, Inc. Call management implemented using call routing engine
US20040194102A1 (en) * 2001-01-16 2004-09-30 Neerdaels Charles J Using virutal domain name service (dns) zones for enterprise content delivery
US20050025073A1 (en) * 2001-01-25 2005-02-03 Kwan Katherine Wang Efficient buffer allocation for current and predicted active speakers in voice conferencing systems
US20020123895A1 (en) * 2001-02-06 2002-09-05 Sergey Potekhin Control unit for multipoint multimedia/audio conference
US7266091B2 (en) * 2001-02-28 2007-09-04 The Trustees Of Columbia University In City Of New York System and method for conferencing in inter/intranet telephony
US6898188B1 (en) * 2001-04-19 2005-05-24 3Com Corporation Gatekeeper simulator in a LAN telephony system
US20040044791A1 (en) * 2001-05-22 2004-03-04 Pouzzner Daniel G. Internationalized domain name system with iterative conversion
US20020049817A1 (en) * 2001-07-12 2002-04-25 Eatamar Drory Storageless system and method for unified messaging on existing mail accounts via standard internet mail protocols
US6970909B2 (en) * 2001-10-11 2005-11-29 The Trustees Of Columbia University In The City Of New York Multi-protocol data communication system supporting wireless telephony and content delivery
US7016343B1 (en) * 2001-12-28 2006-03-21 Cisco Technology, Inc. PSTN call routing control features applied to a VoIP
US7066616B2 (en) * 2003-06-20 2006-06-27 Howell Jay E Modular temporary lighting assembly
US7614384B2 (en) * 2007-11-02 2009-11-10 Gm Global Technology Operations, Inc. Engine torque control with desired state estimation

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9413585B2 (en) 1999-06-08 2016-08-09 The Trustees Of Columbia University In The City Of New York Network telephony appliance and system for inter/intranet telephony
US20090290695A1 (en) * 1999-06-08 2009-11-26 Henning Schulzrinne Network Telephony Appliance and System for Inter/Intranet Telephony
US8271660B2 (en) * 1999-06-08 2012-09-18 The Trustees Of Columbia University In The City Of New York Network telephony appliance and system for inter/intranet telephony
US8675832B2 (en) 2000-08-11 2014-03-18 The Trustees Of Columbia University In The City Of New York System and method for unified messaging in inter/intranet telephony
US20070115926A1 (en) * 2005-10-27 2007-05-24 3Com Corporation System and method for receiving a user message at a packet-network telephone
US8345580B2 (en) * 2006-05-05 2013-01-01 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for virtual meeting
US20090067350A1 (en) * 2006-05-05 2009-03-12 Marika Stalnacke Method and arrangement for virtual meeting
US8321557B2 (en) * 2007-10-10 2012-11-27 Sony Mobile Communications Ab Web feeds over SIP
US20090100124A1 (en) * 2007-10-10 2009-04-16 Sony Ericsson Mobile Communications Ab Web feeds over sip
US8804513B2 (en) 2010-02-25 2014-08-12 The Trustees Of Columbia University In The City Of New York Methods and systems for controlling SIP overload
US20120002663A1 (en) * 2010-06-30 2012-01-05 International Business Machines Corporation Controlling telephone call processing using global signaling codes
US9246952B2 (en) * 2010-06-30 2016-01-26 International Business Machines Corporation Controlling telephone call processing using global signaling codes
US20160057176A1 (en) * 2010-06-30 2016-02-25 International Business Machines Corporation Controlling telephone call processing using global signaling codes
US10135880B2 (en) * 2010-06-30 2018-11-20 International Business Machines Corporation Controlling telephone call processing using global signaling codes
US20190036984A1 (en) * 2010-06-30 2019-01-31 International Business Machines Corporation Controlling telephone call processing using global signaling codes

Also Published As

Publication number Publication date
MXPA01012622A (en) 2002-06-21
EP1186144A1 (en) 2002-03-13
CA2376214A1 (en) 2000-12-14
JP4999244B2 (en) 2012-08-15
WO2000076158A1 (en) 2000-12-14
AU6120900A (en) 2000-12-28
IL146885A (en) 2007-03-08
KR100670006B1 (en) 2007-01-18
US8271660B2 (en) 2012-09-18
EP1186144A4 (en) 2009-09-09
US7610384B1 (en) 2009-10-27
EP1186144B1 (en) 2013-10-23
US9413585B2 (en) 2016-08-09
US20090290695A1 (en) 2009-11-26
IL146885A0 (en) 2002-08-14
KR20020032431A (en) 2002-05-03
US20130016715A1 (en) 2013-01-17
ES2441203T3 (en) 2014-02-03
JP2004500744A (en) 2004-01-08

Similar Documents

Publication Publication Date Title
US9413585B2 (en) Network telephony appliance and system for inter/intranet telephony
US6970909B2 (en) Multi-protocol data communication system supporting wireless telephony and content delivery
US6131121A (en) Point-to-point computer network communication utility utilizing dynamically assigned network protocol addresses
US6009469A (en) Graphic user interface for internet telephony application
US6185184B1 (en) Directory server for providing dynamically assigned network protocol addresses
EP1240777B1 (en) A client-server network for managing internet protocol voice packets
US7660295B2 (en) Telephony and data network services at a telephone
JP2002519891A (en) Method and system for broadcasting call notifications
KR20020064889A (en) Distributed communication network including one or more telephony communication devices having programmable functionality
EP2391094B1 (en) Network telephony appliance and system supporting wireless internet telephony
KR100406964B1 (en) internet-phone having an user state displaying function and controlling method therefore
US20060259920A1 (en) Streaming voice over protocol
WO2001043380A1 (en) Psdn cordless telephone system

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION