In recent years, push-to-talk communications have become popular in the context of mobile or cellular type wireless communications. A conventional push-to-talk (PTT) communication utilizes two or more radio transceiver stations, all tuned to the same channel. When not transmitting, the transceivers receive any signal carried over the channel and supply any received audio to the users. A user wishing to speak pushes a button, which causes that user's transceiver to broadcast audio over the common channel to the other transceiver(s) that share the channel. However, many modern public cellular communication systems have migrated to digital communication technologies, and increasingly, such modern systems use packet-based communication to support push-to-talk communication.
A packet-switched network routes each packet individually through the network, although not necessarily through a common path; as opposed to the traditional circuit switched approach to telephone service and the like that provides a path through the network for the duration of the communication session. Packet switching uses a standard packet protocol, such as the Internet Protocol (IP). The routing decision regarding each packet's next hop through the packet switched network is made on a hop-by-hop basis (typically between neighboring switching or routing nodes). The wireless data services, for example, support a range of communication applications utilizing two-way packet-switched packetized data, such as browsing, instant messaging, e-mail and the like.
As the speeds of packet-switched communications equipment and the speed of processors have increased, a variety of applications have emerged that utilize IP packet transport as an alternative bearer for voice communications. Such applications are often referred to as “Voice over IP” (VoIP) services. VoIP services are now migrating onto the packet transport networks deployed for the wireless domain.
Of note for purposes of this discussion, a number of carriers are now offering push-to-talk services using VoIP and IP packet type data transport (see e.g. U.S. Patent Application Publication No. 2004/0196826 to Bao et al.). A VoIP implementation of a push-to-talk service utilizes separate packet links for the user devices and a dispatch application on a server. The sender station uses its link through the wireless packet data service to upload the sender's audio information to the server. Each destination station obtains the data from the server via its packet service link; and each receiving station converts the data back to audio for output. The destination station or stations may be similar mobile stations or data devices of various other types communicating with the server via the wireline packet data network.
The technology of mobile stations, and thus the communications they support, are rapidly advancing. A provider's customers may be using stations sold over a period of several years, and the capabilities or features supported by those stations may vary widely with model, brand and age. The carriers also are constantly upgrading the technology deployed in their mobile communication networks. Variations in capabilities raise compatibility issues for push-to-talk and similar types of VoIP wireless communications.
For example, an existing Push-to-talk service deployment uses Session Initiation Protocol (SIP) for set-up of VoIP communications over CDMA wireless links, with a half-rate (4 kbps) vocoder capability to package voice data frames over a 9.6 kbps bearer channel. The rest of the 9.6 kbps bandwidth is used for packet header data and other overhead. With a newly deployed network CDMA service option (SO) 60, it is possible to remove the header from packet data. This reduces overhead, and allows an increase in the voice quality of the VoIP service by increasing the vocoder rate to 8 kbps (“full-rate”). Some implementations also provide voice buffering at the mobile station and/or voice buffering at the push-to-talk server. With voice buffering, the user can instantaneously start speaking after pressing the push-to-talk button, before the network sets-up the SIP session(s) with the recipient(s). Voice packets are stored in the mobile station or at the server. Upon receiving positive acknowledgement from the terminating mobile station(s), these buffered voice packets will then be forwarded to the terminating mobile station(s).
When voice buffering is used, the voice packets are formed in the originating mobile station and stored in that station or in the server, without the knowledge of the capability of the terminating mobile station or other recipient client device. This creates an issue when trying to interoperate new mobile stations with SO60 capability (no header and capable of full-rate 8 kbps vocoder operation) with existing half-rate mobile stations. For example, the buffered voice data may be encoded at 8 kbps, even though the destination mobile station may only be expecting 4 kbps. In such a case, the legacy mobile station cannot process the higher rate data, and audio is lost unless and until the receiving station can advise the sending station to adjust its transmissions down to half-rate vocoding.
One solution might be to have a database listing of PTT subscribers' mobile stations, for example by electronic serial numbers (ESNs), at the push-to-talk server. The server could then instruct the mobile stations to utilize a compatible set of operating functions, e.g. to all use half-rate voice encoding and decoding to allow interoperation with older stations that only support half-rate vocoder functions. However, every time a user changed and upgraded her or his mobile station, the service provider would need to manually update the database, often by manual database provisioning. Such a process requires frequent and error prone changes to the database.
Hence a need exists for a more efficient and effective technique to inform stations of each others' capabilities and determine a capability (e.g. vocoder rate) that can be used on a particular session and will be compatible with all of the mobile stations involved in the VoIP session for push-to-talk or the like.
USPTO Backgrounds
USPTO Backgrounds