Patent Application
20070121604
With the recent development and widespread availability of broadband internet connections, many new voice, video, and data services are being offered that take advantage of the additional bandwidth. One such voice service is the voice over internet protocol (VoIP), which enables the routing of voice conversations over internet protocol (IP) networks such as the internet. Bypassing the traditional packet switched telephone network (PSTN), consumers may make free VoIP-to-VoIP calls anywhere in the world with an internet connection and consumers may gain significant cost savings with PSTN-to-VoIP or VoIP-to-PSTN calls.
Typical home VoIP systems have one or more wireless IP phones (WIPP) that wirelessly connect to an IP network access point (AP). In these VoIP systems, the AP merely acts as a bridge to connect the wireless network and the IP network with all of the functionality for enabling a VoIP conversation resident on each WIPP in the system.
Disclosed herein is a central voice over internet protocol (VoIP) controller. The central VoIP controller comprises a communication driver configured to communicate raw digital audio data in accordance with a communication protocol and an audio processor configured to process digital audio data. The central VoIP controller further comprises an audio hub configured to append headers to the digital audio data and to route outgoing audio data over an internet protocol (IP) network and depacketize incoming audio data from the IP network. The central VoIP controller also comprises an IP network interface configured to communicate packetized digital audio data.
Also disclosed herein is an IP phone configured to communicate VoIP calls. The IP phone comprises a communication driver configured to send and receive raw digital audio data in accordance with a communication protocol, a digital-to-analog (D/A) converter for converting received raw digital audio data into audio signals, and a speaker for audibly outputting the audio signals converted by the D/A converter. The IP phone further comprises a microphone for detecting ambient audible sounds as audio signals and an analog-to-digital (A/D) converter for converting the ambient audio signals into the raw digital audio data that is sent by the communication driver.
Further disclosed herein is a VoIP communication method. The method comprises at least one IP phone communicating to send raw digital audio data and user input data and receive raw digital audio data and graphical user interface (GUI) data. The method also comprises a central VoIP controller communicating to receive the raw digital audio data and the user input data sent by the at least one IP phone and receive incoming digital audio data from an internet protocol (IP) network. The central VoIP controller processes the received raw digital audio data and the incoming digital audio data. The central VoIP controller sends the processed incoming digital audio data that is the received raw digital audio data on the at least one IP phone and sends the GUI data responsive to received user input data with the central VoIP controller. The central VoIP controller routes the processed raw audio data over the IP network.
These and other features and advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of the disclosure and the advantages thereof, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that although an illustrative implementation of one embodiment of the disclosure is illustrated below, the system may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
Previously, all of the functionality for enabling VoIP calls resides on each IP phone. As used herein, an IP phone may broadly refer to the category of devices that connect to an IP network for establishing VoIP calls via wired connections such as Ethernet or differential line connections, or via wireless connections such as WIFI or Bluetooth connections. An IP phone that connects to an IP network via a wireless connection may be referred to as a wireless IP phone (WIPP). Each IP phone includes one or more signal processors to provide echo cancellation, encode and decode audio signals with an audio codec, and other audio processing features. Also, each IP phone may include sufficient processing power and memory for executing a self-sustaining graphical user interface (GUI). The memory requirements for implementing a GUI on each IP phone may be extensive due to needing to store all of the GUI icons, images, screen layouts, process flows, supporting data, etc. Further, since all of the VoIP functionality is resident on each IP phone, then each IP phone is responsible for performing all of the signaling functions for establishing a VoIP call. When the IP phone is embodied as a WIPP, the communication overhead between the WIPP and a wireless access point (AP) may be large due to needing to communicate all of the real-time transport protocol (RTP), user datagram protocol (UDP), and IP headers required for routing the VoIP call.
Having all of the functionality required for a VoIP call resident on each IP phone results in an expensive system not only in terms of monetary cost for redundantly enabling processing and memory requirements on each IP phone, but also in terms of high power consumption. The high power consumption may result from executing the complex processing functions on each IP phone, sustaining the large memory with read, write, and refresh operations, and each IP phone maintaining high power states for long periods in order to perform signaling functions for establishing a VoIP call. When embodied as a WIPP, high power consumption may also result from long communication times between the WIPP and a corresponding AP due to the large communication overhead.
Disclosed herein is a voice over internet protocol (VoIP) communication system that offloads much of the processing from an IP phone to a centralized VoIP controller. The VoIP controller may be implemented as any of a voice enabled AP (VoAP), voice enable PC (VoPC), IP private branch exchange (IP-PBX), or any other central controller for providing a majority of processing for enabling VoIP calls. Reducing the processing taking place on an IP phone may reduce the number of components that need to be on the IP phone. When embodied as a WIPP reducing the processing taking place on the WIPP may also result in more efficient communication between the WIPP and an AP. More efficient communication may be achieved by the WIPP not needing to communicate VoIP routing data or perform some or all of the signaling functions for establishing a VoIP call. The increased communication efficiency and the reduced number of components implemented on the WIPP results in less power being used by the WIPP and effectively extends the battery life and possible communication duration. Further, since a number of redundant components have been centralized, each of the IP phones as well as the VoIP system as a whole may be less costly. Also, centralized control may provide greater functionality and versatility in the setup and configuration of a VoIP communication system that may not be limited by the feature set available through an RJ-11 interface.
In one embodiment, the VoAP 104 includes all of the functionality for enabling one or more VoIP calls and coordinating the calls with one or more WIPPs 102. The VoAP 104 includes a network interface 108, an audio hub 110, an audio processor 112, a processor 114, a wireless communication driver 116, one or more antennas 122, a GUI/Data server 118, and a memory 120.
Each of the components of the VoAP 104 are discussed in more detail below. The network interface 108 connects the VoAP 104 to the network 106. The network interface 108 may be implemented as an Ethernet port, a universal serial bus (USB) port, or any other wire line network interface. Alternatively, the network interface 108 may simply be implemented using the wireless communication capabilities of the VoAP 104 to connect to another wireless network as described above. The audio hub 110 enables the VoAP 104 to send and receive VoIP calls over the network 106. The audio processor 112 performs most or all of the audio processing functions such as encoding and decoding the audio data in accordance with a codec, performing echo cancellation, tone generation, and tone detection. The processor 114 provides a central control for sending and receiving audio data to a corresponding WIPP as well as coordinating graphical user interface (GUI) or data requests described in more detail below. The wireless communication driver 116 enables the wireless communication between the VoAP 104 and the WIPP 102 through any wireless communication protocol such as bluetooth or the 802.11x standards. 802.11x is a general designation of any one or a combination of the 802.11 standards. The GUI/Data server 118 acts as a web server or daemon browser to provide GUI functionality and data services to each of the WIPPs 102 connected to the VoAP 104. The memory 120 stores all of the data necessary to support the GUI/data server 118 as well as storing data in a central location that may be shared between each WIPP 102 connected to the VoAP 104.
In the embodiment illustrated in
Each of the components of the WIPP 102 are discussed in more detail below. The wireless communication driver 126 enables the wireless communication between the WIPP 102 and the VoAP 104. The processor 128 provides a central control for sending and receiving audio data to the VoAP 104 as well as coordinating GUI or data requests in accordance with user inputs. The D/A converter 130 enables received audio from a VoIP call to be output from the speaker 132 so that a user of the WIPP 102 may hear incoming audio. The A/D converter 120 converts ambient audio received from the user of the WIPP 102 through the microphone 122 into digital signals that may be sent to the VoAP 104 for processing and routing. Various user input may be provided to the WIPP through the input device 138 to initiate a VoIP call, accept/reject an incoming call, navigate a GUI on the display 142 or perform any other operations requiring user input. The GUI/Data client 140 acts as a web browser or HTTP client to display a GUI on the display 142 for interacting with a user to control the operations of the WIPP 102. The memory 144 is a small memory that may store data in support of the operation of the WIPP 102.
The GUI/data client 140 displays various GUI screens for controlling the operation of the WIPP 102 in accordance with user inputs on the input device 138. Upon receiving user inputs, the processor 128 may display the user inputs on the display 142 via the GUI/data client 140. For example, as a user enters in a telephone number, the number that the user is inputting may be displayed on the display 142. By displaying the user inputs as the input device 138 is manipulated, the user may have visual feedback of what they are entering.
Upon receiving user inputs, the processor 128 may also communicate the inputs to the VoAP 104 via the wireless communication driver 126. Upon receiving navigational user inputs, the processor 114 may pass them to the GUI/Data server 118 to be processed. For example, if a user manipulates the input device 138 to navigate to a different GUI screen, then the inputs may be communicated to the GUI/Data server 118. Upon receiving the user inputs, the GUI/Data server 118 may fetch the corresponding GUI screen and any supporting data from the memory 120 and communicate the fetched GUI screen and data to the WIPP 102 to be displayed on the display 142.
Upon receiving operational user inputs, the processor 114 may pass them to the audio hub 110. For example, a user may initiate a VoIP call by manipulating the input device 138. Upon receiving the user inputs, the processor 114 may pass the inputs to the audio hub 110 to initiate a VoIP call. Alternatively, when receiving a call, a caller ID or other visual feedback, in addition to audio and/or kinetic feedback may alert a user of the WIPP 102 of an incoming call. A user may provide inputs on the input device 138 to either accept or reject the call. Based on the inputs provided by the user, the audio hub 110 may either connect the call, forward to voicemail, or simply send a message back to the initiating device that the call is rejected, such as through a 480 message in session initiation protocol (SIP).
When making a VoIP call, a user of the WIPP 102 may initiate communication with the VoAP 104 and wait for the VoAP 104 to establish the call. The communication with the VoAP 104 may be initiated by the user manipulating the input device 138 to dial a telephone number, enter in a VoIP identification, or select a name from a call list displayed by the GUI/Data client 140. The processor 128 may interpret the inputs and send a request to initiate a VoIP call to the VoAP 104. Upon receiving the request to send a VoIP call, the VoAP 104 may perform all or most of the functions necessary for initiating a VoIP call. The audio hub 110 may initiate a VoIP call in accordance with the SIP, H.323 protocol, or any other appropriate VoIP communication protocol. For example, using SIP, the audio hub 110 may send the “invite” request to the desired recipient using the 100 trying and 180 ringing messages. Upon receiving an acknowledgment “ACK” from the recipient, using the 200 OK message, the voice communication may commence. Since the call initiation is handled by the VoAP 104 the WIPP 102 may enter a low power mode between sending the call request to the VoAP 104 until the 200 OK message is received. If the call request fails then the VoAP 104 may wake up the WIPP 102 for a short time to display a message on the WIPP 102 that the call has failed using the GUI/Data client 140.
Similar to sending a VoIP call, the VoAP 104 handles much of the processing necessary for receiving a VoIP call. For example, again using SIP, the audio hub 110 may receive an “invite” request from a caller and send a message to the WIPP 102 to begin ringing. After sending the message to the WIPP 102, the audio hub 110 may reply to the “invite” request with a 180 ringing message. Upon a user manipulating the input device 138 on the WIPP 102 to answer the call, the processor 128 may interpret the input and send an indication to answer the VoIP call to the VoAP 104. The audio hub 110 may then send the 200 OK message to the caller to commence the voice communication. Since the call initiation is handled by the VoAP 104 the WIPP 102 may stay in a low power mode unit it receives an indication to start ringing from the VoAP 104. After receiving the indication to start ringing, the WIPP 102 may be in a partially awake state to signal a user using audio, visual, and/or kinetic feedback that there is an incoming call. After receiving user inputs to accept the call the WIPP 102 may fully awaken.
Upon a VoIP call being established much of the audio processing is handled by the VoAP 104. The A/D converter 134 may sample and digitize any audio signals detected by the microphone 136, such as the voice of a user of the WIPP 102. The processor 128 may then communicate the raw digital audio to the VoAP 104 via the WLAN driver 126. As used herein, raw digital audio data refers to digital audio data that has not had a majority of processing applied or does not require a majority of decoding or processing prior to being converted into audio signals by a D/A converter and output by a speaker. In other words, the majority of the audio processing occurs on the VoAP 104 as described below. Upon the VoAP 104 receiving the raw digital audio from the WIPP 102, the audio processor 112 may processes the digital audio. The audio processor 112 may operate to process the received audio data as if it was directly input from the A/D converter 134. The audio processor 112 may encode the digital audio data in accordance with any appropriate codec, performing echo cancellation, and any other audio processing functions. In some embodiments, the WIPP 102 may perform some of the audio processing described above with the majority of audio processing occurring on the VoAP 104. The audio hub 110 may then append the encoded audio data with any necessary real-time transport protocol (RTP), user datagram protocol (UDP), and IP headers in order to properly route the audio data to the intended recipient. In some embodiments, the WIPP 102 may append the raw digital audio data with an IP header and possibly a UDP and RTP header prior to wirelessly communicating the raw digital audio data to the VoAP 104. For example, when communicating using the Bluetooth protocol, the raw digital audio data may be communicated by the WIPP 102 without any IP, RTP, or UDP headers. When communicating using a WIFI protocol, the raw digital audio data may be communicated by the WIPP 102 with an IP header and possibly a UDP and RTP header by the WIPP 102. When the digital audio data already has one or more headers then the audio hub 110 may append the audio data with any additional headers needed to properly route the audio data to the intended recipient.
Similar to sending audio, the audio hub 110 may receive audio communications. The received audio communication may be depacketized by the audio hub 110 and the resultant audio data may be decoded and processed by the audio processor 112. The processor 114 may then communicate the raw digital audio to the WIPP 102 via the wireless communication driver 116. Upon the WIPP 102 receiving the raw digital audio from the VoAP 104, the D/A converter 130 may convert the digital audio to an analog signal that may be projected by the speaker 132.
Since a majority of the audio processing and VoIP routing functions are performed by the VoAP 104 as described above, less processing is performed on the WIPP 102 which may cause a reduction in the amount of power used by the WIPP 102 as well as a reduction in its cost. Further, because a majority of the VoIP routing functions are performed by the VoAP 104, the wireless communication overhead between the VoAP 104 and the WIPP 102 may be reduced. The reduced communication overhead is due to the WIPP 102 not needing to communicate some or all of the RTP, UDP, and IP headers along with the audio data to the VoAP 104. The reduction in the communication overhead between the WIPP 102 and the VoAP 104 may translate into less time actively communicating data. If the WIPP 102 transitions to a low power state when it is not actively communicating, then the reduced communication overhead may result in the WIPP 102 using less power.
As stated above, the wireless communication between the WIPP 102 and the VoAP 104 may use any wireless communication protocol, such as Bluetooth or the 802.11 standards. In order to ensure quality of service (QoS), the communication protocol implemented by the wireless communication driver 116 may utilize a wireless multi-media scheduled access (WMM-SA) scheme. For example, the communication protocol may provide scheduled access through a prioritization scheme such as that defined in the 802.11e standard to give higher priority to voice communication. Alternatively, in order to ensure QoS, the communication protocol may provide scheduled access through a dedicated voice communication channel as is used in the Bluetooth standard. As another measure to ensure QoS, a jitter buffer may be used on the VoAP 104 to mitigate the effects of jitter in the communication between the WIPP 102 and the VoAP 104. Jitter refers to the variation in the delay between received packets of data and may result in audio packets being received out of order or with audibly noticeable delay. To mitigate the effects caused by jitter, the VoAP 104 may buffer incoming audio data packets in memory 120 or another memory (not shown) in order for the audio processor 112 to restructure the audio data for improved playback. In one embodiment, a jitter buffer may also be used on the WIPP 102 to mitigate any jitter occurring between the WIPP 102 and the VoAP 104.
Security of voice conversations may be enabled by the audio data being encrypted/decrypted by the audio processor 112 over the communication path between the VoAP 104 and a corresponding VoIP device. Alternatively, encryption/decryption may be handled by each WIPP 102 to ensure protected communication across the entire communication path. Also, security features within the wireless communication protocol, such as the 802.11i standard, may be used to ensure security between the WIPP 102 and the VoAP 104.
Having the memory 120 on the VoAP 104 provides many advantages over conventional VoIP systems. In general, the memory 120 may include any data that may otherwise be redundantly stored on each WIPP 102. The data stored in the memory 120 may include data that may be used to implement a GUI on the WIPP 102 such as GUI icons, images, screen layouts, process flows, as well as any supporting data for the GUI such as address book entries, instant messaging buddy lists, etc. Storing data in the central location of the memory 120 allows each of the WIPPs 102 that connect to the VoAP 104 to have shared access to all or a portion of the data in the memory 120.
Services may also be provided for keeping the data stored in the memory 120 up to date. For example, the data in the memory 120 may be synchronized with external applications that may be on the network 106. For example, if a personal computer (PC) was connected to the VoAP 104 through a LAN then the VoAP 104 may synchronize any address book entries in the memory 120 with an address book application running on the PC, such as MICROSOFT OUTLOOK. Another service may include the VoAP 104 manufacturer or a VoIP service provider performing automatic updates with the GUI data stored in the memory 120. The updates may include new images, layouts, or process flows to let the WIPP 102 take advantage of all the latest features available from the VoAP 104 manufacturer or a VoIP service provider. Updates may also be automatically provided to maintain an up-to-date appearance of the GUI by periodically updating the appearance of the GUI to coincide with current events or recent user activities.
The central memory 120 may also allocate individual space for each WIPP 102 or each VoIP user to allow for personalization and the creation of user profiles. For example, by manipulating the GUI on the WIPP 102, a VoIP user may log in to the VoAP 104 using their VoIP service provider user identification or any other identification. Based on the information entered, the GUI on the WIPP 102 may be displayed according to the customized preferences of the user. User customizations may include changing color schemes, fonts, screen layout, welcome messages, or any other feature of how data is displayed to the user. Each user may also store customized GUI support data such as custom address book entries or instant messaging buddy lists, for example. Having VoIP account based profiles as described above may also enable administrative functions such as parental controls to be applied to each user that connects through the VoAP 104. Administrative functions may include designating what calling features may be used through the VoAP 104, the categories of phone numbers that may be called (e.g., information 411, pay-by-minute 900 numbers, only VoIP users), limiting the amount of time each user is allowed for a given period of time (e.g., five hours per week), or controlling any other features of the WIPP 102 or the VoIP service.
The GUI/Data server 118 also provides many advantages over prior art VoIP systems. While the GUI/Data server 118 may host a GUI application to be shown on the display 142 for enabling a user to control the WIPP 102 as described above, the GUI/Data server 118 may also connect to the network 106 to provide additional services. For example, if the GUI/Data server 118 connects to the internet then the WIPP 102 may additionally be able to perform web browsing and instant messaging functions via the GUI/Data server 118.
Since the WIPP 102 is only limited by what is displayed by the GUI/Data server 118, the VoIP communication system 100 may have an increased feature set over the traditional features that are limited by signaling over an RJ-11 interface. As cellular phones are increasingly being designed to operate on both cellular and WLAN networks, one new feature may be to enable a call handover between the WIPP 102 to a cell phone or cell phone to the WIPP 102.
As described in some of the embodiments above, the IP phones 504 may be configured to communicate raw digital audio data with the IP-PBX 502. Upon receiving raw digital audio data from the IP-PBX 502, the IP phone 504 may directly produce audible sounds for a user to hear. Also, the IP phone 504 may sample ambient sounds produced by the user as raw digital audio data to be sent to the IP-PBX 502 for processing and routing over the IP network 106.
The dedicated communication link 506 and the shared communication link 508 may be implemented as differential lines such as a twisted pair line. As the communication between the IP-PBX 502 and each of the IP phones 504 may occur over differential lines, the IP-PBX 502 and the IP phones 504 may have differential drivers instead of a wireless communication driver 116 and wireless communication driver 126 respectively. The differential driver may implement a simple universal asynchronous receiver/transmitter (UART) interface, an RJ-11 interface, a wired Ethernet interface or any other such interface between the IP-PBX 502 and the IP phone 504.
In the embodiment shown in
While a particular configuration of the VoIP communication system 500 is shown in
Disclosed above are various embodiments of VoIP communication systems that utilize low cost IP phones that rely on a centralized VoIP controller for much of the processing. The VoIP controller may be implemented as any of a voice enabled AP (VoAP), voice enable PC (VoPC), IP private branch exchange (IP-PBX), or any other central controller for providing a majority of processing for enabling VoIP calls. Reducing the processing taking place on an IP phone may reduce the number of components that need to be on the IP phone which may result in a less expensive IP phone in terms of both cost and power. When the IP phone is embodied as a WIPP, reducing the processing taking place on the WIPP may also result in more efficient communication between the WIPP and an AP. The increased communication efficiency may result in less power being used by the WIPP and effectively extend the battery life and possible communication duration. Since a number of redundant components have been centralized, the VoIP system as a whole may be less costly. Also, centralized control may provide greater functionality and versatility in the setup and configuration of a VoIP communication system.
While many features and components were described above one skilled in the art will recognize that there may be many modifications to the VoIP communication systems described above without departing from the spirit or the scope of the disclosure. For example, the VoAP 104 and the WIPP 102 each have one antenna 122 for enabling communication with each other or any other wireless networks. In some embodiments the VoAP 104 and/or the WIPP 102 may alternatively have two or more antennas for improving the range, reliability, and throughput of wireless communications with the AP 104, for example, in accordance with the 802.11n specification. Also, while each of the audio hub 110, the audio processor 112, the processor 114, and the GUI/Data server 118 of the VoAP 104 were illustrated as separate components, all or some of these may be incorporated into a dedicated VoAP 104 processor. Similarly, the processor 128 and the GUI/Data client 140 on the WIPP 102 may be incorporated into a single processor. Further, while each of the features, services, and configurations of the VoIP communication systems were separately described, one skilled in the art will recognize that the features, services, and configurations may be grouped or combined in any way.
Each of the VoAP 104, VoAP 302, the VoPC 404, and the IP-PBX 502 described above may be implemented on any general-purpose computer with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.
The secondary storage 684 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 688 is not large enough to hold all working data. Secondary storage 684 may be used to store programs which are loaded into RAM 688 when such programs are selected for execution. The ROM 686 is used to store instructions and perhaps data which are read during program execution. ROM 686 is a non-volatile memory device which typically has a small memory capacity relative to the larger memory capacity of secondary storage. The RAM 688 is used to store volatile data and perhaps to store instructions. Access to both ROM 686 and RAM 688 is typically faster than to secondary storage 684.
I/O 690 devices may include printers, video monitors, liquid crystal displays (LCDs), touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices. The network connectivity devices 692 may take the form of modems, modem banks, ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards such as code division multiple access (CDMA) and/or global system for mobile communications (GSM) radio transceiver cards, and other well-known network devices. These network connectivity 692 devices may enable the processor 682 to communicate with an Internet or one or more intranets. With such a network connection, it is contemplated that the processor 682 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using processor 682, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave
Such information, which may include data or instructions to be executed using processor 682 for example, may be received from and outputted to the network, for example, in the form of a computer data baseband signal or signal embodied in a carrier wave. The baseband signal or signal embodied in the carrier wave generated by the network connectivity 692 devices may propagate in or on the surface of electrical conductors, in coaxial cables, in waveguides, in optical media, for example optical fiber, or in the air or free space. The information contained in the baseband signal or signal embedded in the carrier wave may be ordered according to different sequences, as may be desirable for either processing or generating the information or transmitting or receiving the information. The baseband signal or signal embedded in the carrier wave, or other types of signals currently used or hereafter developed, referred to herein as the transmission medium, may be generated according to several methods well known to one skilled in the art.
The processor 682 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 684), ROM 686, RAM 688, or the network connectivity devices 692.
While several embodiments have been provided in the disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the disclosure. The examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
Also, techniques, systems, subsystems and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the disclosure. Other items shown or discussed as directly coupled or communicating with each other may be coupled through some interface or device, such that the items may no longer be considered directly coupled to each other but may still be indirectly coupled and in communication, whether electrically, mechanically, or otherwise with one another. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.
This application claims priority to U.S. Provisional Application No. 60/730475, filed Oct. 26, 2005, entitled “Thin Client for Voice Over Wireless Local Area Networks”, Prophul Chandra et al., which is incorporated herein by reference for all purposes. Not applicable. Not applicable.
| Number | Date | Country | |
|---|---|---|---|
| 60730475 | Oct 2005 | US |
