TW200820682A - Content-based adaptive jitter handling - Google Patents

Abstract

A packet communication device is disclosed. The packet communication device may include a detector configured to detect a characterized content in incoming packets received by the packet communication device. The packet communication device may further include a play-out control configured to perform and adjustment of the incoming packets to produce adjusted packets and output the adjusted packets, if the detector has detected the characterized content in the incoming packets.

Description

200820682 IX. Description of the Invention [Technical Field of the Invention] The present invention relates to content-based adaptive jitter processing. [Prior Art] The conventional mobile communication platform includes cellular communication, for example, Global System for Mobile Communications (GSM). Other well-known platforms that support limited mobility include WiFi according to IEEE 802.1 1 standards. Both cellular and WiFi are well known and are established wireless communication platforms. The next-generation platform is designed to enable mobile users to move between cellular and WiFi networks and includes the Unlicensed Mobile Access (UMA) standard, which provides a switch controller to the carrier, allowing users to move beyond the cellular Between the WiFi standard and vice versa. However, the UMA standard has disadvantages including the carrier typically controlling the phone and deciding whether and when to exchange users between the networks.

Advanced mobile communication platforms are needed to provide enterprise-level communications, and to control users and the network, enabling enterprises (instead of carriers) to select networks and/or phones based on corporate drive standards rather than carrier-driven standards. In addition, in mobile/wireless communication, there are usually the following problems: (a) echo; (b) packet delay affecting quality of service (Q〇s), packet delay variation (packet jitter), and packet loss; (c) agreement Hardware or software platform dependencies; and (d) the security of enterprise resource access. These issues are described below as 200820682, (a) Echo - In the voice communications such as the traditional PS TN, conference phones, cellular phones, and Internet telephony, echo cancellation (EC) technology has been widely used to improve end-user services. Quality (QoS). There are usually two types of echo cancellers. One type of echo canceller is commonly referred to as a line or network echo canceller (LEC). LEC is typically used to remove electrical echoes caused by reflections of mixed components on a network occurring by 2-wire and/or 4-wire conversion. Another type of echo canceller is commonly referred to as an acoustic echo canceller (AEC). AEC is typically used to remove acoustic echoes resulting from acoustic sound feedback from a speaker to a microphone on a speakerphone, a mobile phone, or a conference phone. Compared with LEC, it is more difficult to implement AEC due to the following factors: Because the speed of sound is much slower than the speed of light (or electron velocity), the echo tail is longer, so the echo canceller must have more processing power and memory; because of the phone or The movement of the speaker and the changes in the environment, so the dynamics of the acoustic echo characteristics vary greatly, so the echo canceller must track and catch up with changes in the characteristics of the φ sound more quickly; and because of different objects from different distances and/or orientations Multiple echo paths caused by multiple reflections. Current acoustic echo cancellation techniques typically have limitations. Although acoustic echo cancellation technology has been invented and used for at least 4 years, the basic method of eliminating acoustic echo has not changed significantly. Typically, a typical AEC uses an adaptive filter to model one or more echo path transfer functions and attempt to produce a copy of the echo. The AEC can then subtract this copy from the incoming input signal to form the final anecho-free far-end signal output. To date, most of the developments in acoustic echo cancellation technology have utilized different types of filters, such as FIR or IIR filters, single or multi-band filters, wavers, or time or frequency domain filters. . In addition, different algorithms such as LMS, RLS, APA have been used to improve filter efficiency. Despite this, even with all these technological improvements, today's AEC design and implementation is still a very difficult job. Because of the complex and variability of acoustic echo, conventional filters present many limitations in dealing with acoustic echo. One of the restrictions is a bad two-end conversation (both near-end and far-end speakers are talking). The result of the conventional filter calculation is to replace the convergence between echo and copy with divergence during talks at both ends. (b) Packet delay affecting quality of service (QoS), packet delay variation (packet jitter), and packet loss In VoIP and network video communications, voice and/or video media content needs to be immediately transferred from the sender The receiver, however, 'the basic IP network was originally designed for non-instant messaging. Therefore, providing and maintaining the quality of service (QoS) of the end user φ becomes a very difficult task. End-to-end packet delay, packet delay variation (packet jitter), and packet loss can be viewed as three important QoS parameters that affect the quality and performance of voice and video communications over IP networks. The current bounce buffering technique has limitations. A bounce buffering scheme, also known as a debounce buffering scheme, is typically used on the receiver side to compensate or eliminate network packet bounce. Basically, the solution cannot implement the packet as soon as it receives the packet. Instead, the scheme can be evenly spaced into the packets and implementations that have been queued. In fact, before the implementation takes place, the packet queue indicates the insertion delay. The delay of insertion is often referred to as the implementation delay. There are at least two problems with the current design and implementation of the bounce buffer. The first question is related to how many implementation delays need to be inserted. There can be more or less implementation delays. In the case of large delays, packet loss is less. On the other hand, in terms of small delays, the interaction feels better. The first problem can be solved expediently by adaptive bounce buffering. In an adaptive jitter buffering scheme, the receiver can estimate the network packet jitter based on the timestamp of the incoming RTP header and the receiver's local time. The receiver then inserts a minimum delay just enough to compensate for network packet bounce. The second problem with the bounce buffer design is related to when the insertion delay is inserted. Ideally, an implementation delay can be inserted at the beginning of each speech. Therefore, although it is possible to implement each speech at equal intervals, only the silent period between the speeches is expanded or compressed. For example, if the transmitter utilizes a silent suppression technique, the packet entering the receiver desirably has a spacing between speeches, such that the device can be implemented to recognize each of the time stamps and sequence numbers of the RTP # header of the incoming packet. The beginning of the talk. However, in fact, only in limited circumstances can the insertion delay be reached at the beginning of the speech. Most current silent suppression techniques have limitations and can only perform well in pure cases such as a single speaker or low background noise. Current silent suppression techniques are not well performed in a number of other situations, such as multiple speakers in a conference or background noise such as mobile communications. Therefore, in order to preserve better audio quality, many applications are performed without utilizing or actuating silent suppression. As a result, the packets entering the receiver -8-200820682 can be continuous without any interruption. There are no clues on the timestamp and sequence number to see if the packet indicates silence or speech. Assuming that no silent clues are identified, the current bounce buffering technique performs poorly. One of the reasons for poor performance is that the current jitter buffer design usually only looks at the RTP header information of the packet, not the content on the RTP payload. (c) Hardware or software platform dependencies of the agreement

Hardware or software platform dependencies can create interoperability and/or configuration issues. For interactive user conversations in communications involving multimedia elements such as video, audio, chat, games, or virtual reality, there is a need, for example, to be able to effectively communicate information between the server and the user and to be independent of the hardware. A lightweight protocol for communication protocols such as the Session Initiation Protocol (SIP) operating outside the software platform, a control plane protocol used between the server and the user, and a basic transport layer or medium for server and user communication. There is a need for an agreement that is fast enough to support emergency immediate control messages and is flexible enough for bulk data transfer with minimal delay. However, conventional technology agreements such as UMA are often complex and difficult to establish interoperability. (d) Security when accessing corporate resources from mobile devices More and more companies are allowing their employees to use their own cellular/mobile phones to do business. With the use of local speed networks such as WiFi, Edge, UMTS, CD MAE VD, and mobile phones, different vendors have implemented VoIP (Internet Telephony) to mobile phones. Such an implementation requires an open enterprise firewall to enable V ο IP related protocols such as SIP, R T P, etc. to operate -9-200820682. In addition to VoIP, other enterprise data center applications can be extended to mobile phones. These applications can include one or more Presence/Instant Messaging, intranet web resources, CRM, Support database, and more. If a user uses a mobile phone to directly access enterprise resources for one or more of the above applications, the corporate firewall needs to be opened for multiple agreements, and an open corporate firewall may create security issues. SUMMARY OF THE INVENTION In one embodiment, the present invention is related to a packet communication device. The packet communication device includes a detector that is configured to detect the characterization content of the incoming packet received by the packet communication device. The packet communication device further includes an implementation controller configured to perform an adjustment of the incoming packet to generate an adjusted packet and an output adjusted packet if the detector has detected the feature content in the incoming packet. The above summary is only one or more of the many embodiments of the invention disclosed herein, and is not intended to limit the scope of the invention, and the scope of the invention is set forth in the claims. These and other features of the present invention will be described in more detail in the detailed description of the invention. [Embodiment] Table of Contents-10-200820682 Architecture Acoustic echo cancellation based on encoder/decoder Content-based jitter buffer design for IP voice/video communication Divitas Description Protocol (DDP) David He (Divitas) Agreement Agent (DPP) H. Conclusion The present invention will now be described in detail with reference to some preferred embodiments as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth. However, it will be apparent to those skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures are not described in detail in order not to obscure the invention. The features and advantages of the present invention will become more apparent from the understanding of the appended claims. The invention may be described with reference to particular apparatus and examples. Those skilled in the art will appreciate that the description is merely illustrative of and provides the best mode of φ for practicing the invention. It should not be construed as limiting the scope of the invention. For example, although reference is made to a particular communication protocol, the present invention contemplates other agreements. For example, although WiFi (IEEE 802.1 1 ) is described as a protocol for wireless communication, other protocols may be implemented by the present invention. The references to Divitas and the Mobility Server are equal here. Various embodiments are described below, including methods and techniques. It should be noted that the present invention also encompasses manufactured objects including computer readable media storing computer readable instructions for performing embodiments of the present invention. Computer readable media includes, for example, semiconductor, magnetic, magneto-optical, optical, -11 - 200820682 or other forms of computer readable media for storing computer readable codes. In addition, the present invention also encompasses an apparatus for carrying out embodiments of the present invention. Such apparatus includes circuitry (exclusive and/or programmable) that performs the operations of the embodiments of the present invention. Examples of such devices include versatile computers and/or proprietary computing devices when properly programmed, and include combinations of computer/computing devices and proprietary/programmable circuits for various operations related to embodiments of the present invention. .

1 is a diagram of a system network 100 in accordance with an embodiment of the present invention. Set up an Action Facility (ME) 102 that communicates with the network in many possible ways. The ME 102 can communicate with a cellular network 110 that includes a base transceiver station (BTS) 112, a BTS switching center (BSC) 114, and a mobile switching center (M SC) 116. The MSC is coupled to a media gateway 120 coupled to a public switched telephone network (PSTN) 122. Other conventional public and private telephones 124 are also coupled to the PSTN. The PBX 130 is coupled to the PSTN and, for example, by telephone 136, calls the enterprise φ and picks up the phone. The Mobility Server 150 is coupled to the PBX and other networks. For example, the mobility server 150 is coupled to the Internet Protocol Wide Area Network (WAN) 138 via router 1 32. The mobility server 150 is also coupled to the Internet 144 via the router 140 and firewall 142. Although a plurality of access points are also contemplated by the present invention, only one access point is depicted herein. Access point 1 60 enables a user with ME 102 to roam in the enterprise and maintain a connection with the PSTN via mobile server 150 and PBX 130. If the user is roaming beyond the boundaries of the LAN, as will be explained in more detail below, the user will be connected to another network (eg, a cellular network). Also depicted is coupled to -12-200820682 Internet Access Point 180, which is used for access to certain conditions as described herein. 2A-C are actuating servers in accordance with an embodiment of the present invention. Security Manager - The security definition when two or more are in positive communication includes the following: 1. Mutual authentication of the communicating entity

2. Privacy of communication channels 3. Integrity of exchanged messages 4. Authentication of messages In the Divitas mobility scenario, there are three distinct communication entities: Divitas users, Divitas servers, and external VoIP GWs. And there are two clear path types between these entities: SIP signaling path and media path. As described in the Architecture Manual [1], the following mechanisms are used to achieve the security and data paths between the user, the server, and the external gateway: 0. Between the user and the server SIP TLS conversation. 2. User authentication using SIP notification after SIP TLS establishment 3 • Authentication by the user of the server 4. SIP TLS session between the server and the external VoIP gateway. 5. Server authentication using external VoIP gateways 6. Secure media path 7. Derived demand user/device manager/action controller-device and mobility management-13- 200820682 (herein referred to as DMM) It is a module that has an ongoing telephone on the device to handle both device configuration and status and mobility. The following paragraphs record the functions and design specifications of the DMM and the common interface supported by the DMM. 1. The configuration of the device controlled by the enterprise administrator. 2. Report status of the device 3. Image management of the device

4. Maintain and implement action logic for handsets with ongoing calls - ie, handle WiFi to Cell and vice versa. 5. Processing device initialization and configuration requests from the user. Control Plane/Telephone Control - Telephone Control (CC) is the main control plane module responsible for the following functions: 1. Voice over IP telephony

2. SIP proxy server and B2BUA 3. PSTN Call management via PSTN GWs 4. P B X feature management via A s t e r i s k 5. Resource and connection management The telephone control module resides on the DN media switch. The telephone control module interfaces with the SIP stack and the Astarisk (or any other) PBX to provide the above functionality. 1. SIP stack (for UA, CCM, and Asterisk, etc.): SIP stack is mainly used as a protocol message decoding/encoding engine. The SIP stack performs basic protocol designation, such as standards-based message parsing and verification, retransmission, and proprietary message authentication. For most agents and B2BUA work, the SIP stack relies on the CC to make decisions. The interaction between CC and Asterisk and CC and -14-200820682 CCM is based on standard-based SIP messages. 2. Agent Engine/Configuration Manager (PA/CM): The Agent Engine acts on the Configuration Manager for all applications. After reading the disc DB at the time of supply or after the system is started, download the phone control information with the PA. The CC stores the data in RAM for local/faster access. The CC updates the P A of any dynamic information (eg, the call is in progress or interrupted), or requires information (eg, SNMP GET).

3. Resource Manager (RM): The Resource Manager provides a logical diagram of the entity/network resources. These resources include GE埠, DSP resources, sockets, UDP/TCP埠, etc., but do not include system resources such as memory, data buffers, timers, queues, and so on. Resources do not include outlets for internal IPC communication. CC uses RM as a resource for CAC, resource reservation, and communication. As part of the communication, RM tells the media switch to program the hardware to make the media flow. The Media Switching Application (MSA)-MSA will be designed to be partially implemented on Linux and the rest on the TMS320DM64x DSP processor. The application will perform the following functions: RTP packet processing. exchange. Code conversion. conference call. Adaptive bounce buffer. Packet loss is hidden. Includes post processing of VAD/CNG and AGC. -15- 200820682 MSA software needs to support encoding/decoding of different speech codecs/decoders. The type of algorithm and channel can be changed during execution, ie the design of multi-channel, multi-algorithm is required. Each codec/decoder algorithm needs to be reentrant coded, and the program and data need to be fully releasable. In order to support various encoders/decoders, the following considerations need to be considered:

a. Because DSPs have limitations on wafer data memory, not all data in a multi-channel, multi-algorithm application can be placed on the wafer. This requires the location of all data (text and tables) in each algorithm to be re-changed (between the wafer and the external memory) during the text exchange. This requires finding the memory, stack size, and MIPS requirements for each supported encoder/decoder. b. The mechanism for exchanging messages between the host and the DSP indicating the number of channels and the encoder/decoder type and any other characteristics. Channel Configuration Manager You need to open a channel that indicates the DSP of the desired type of function. A periodic message indicating the state of the DSP must be implemented.

The DSP processor enables the external host to access the DSP external memory. The DSP has a first-order program and data memory of 16 kilobytes. The program shares the second-order memory of 256k bytes with the data memory. 1 6 million bytes of external memory (SDRAM) is available. The shared memory between the two processors stores incoming and outgoing RTP data. Because the DSP needs to support the number of N channels, this memory will contain N receive and transmit buffers for each 320-bit tuple (in the case of video, these buffers need to be 1 500 bytes). The data structure used for information between the host and the DSP and the information required for each call is required to be defined. The following steps define the DSP -16-200820682 function: a. During startup, once the software is downloaded to the DSP (the host will be pointed out by downloading the predetermined location in the fixed memory location so that the DSP indicates the same). b. When the software is successfully downloaded, the DSP will execute the internal timer 10 m s e c. At this time, D S P polls the channel status to change to processing, and this processing is once the packet arrives and is set by the host.

c. Send a start or open channel command from the host indicating the encoder/decoder type, data ready, and phone type (initially only voice) to the RX and TX directions. d. Based on the open channel, the DSP takes the RTP data from the external buffer and performs DSP related functions on these. e. On the TX side, the DSP places the encoded data on an external buffer for TX to acquire. 3 is a diagram of a mobile device user in accordance with an embodiment of the present invention. Execute user software or phone software on a phone that is compatible with the Divitas server. Typically, these are dual mode handsets with an IP connection that provides a cellular connection (CDMA or GSM) and a LAN connection (wired LAN or wireless LAN). It can also be used as a software phone for desktop/laptop or PDAs with microphones and speakers. The user interface user interface provides the following functions: -17- 200820682 • Set boot configuration - DNS IP address, Divitas server URL, boot user status (IN VI SIB LE/A VAIL ABLE), security settings • Change User status (IN VISIBLE/A VAIL ABLE) • Add company “buddies” (partners) and get their presence information (IN VISIBLE/A VAIL ABLE/CALL-IN-PROGRESS) • Display of corporate “buddies” (partners) Availability status and connect to them

• User interface for corporate phone features • Telephone dialing • Telephone answering • Dialling in the call • Designated transfer • Call transfer • Multi-party conference call • Voicemail notification • Missed call notification • Received call notification • Pending call Notifications • Number inquiry and dialing with name • Manual control device using a cellular network instead of WiFi network • Display version mismatch • Upgrade request/status • Disabling/disabling user software An ISP application is used to make/receive Honeycomb Phone -18- 200820682 Telephone Control and Language Control • Telephone Control for VoIP Calls on the LAN Interface • Voice Engine for VoIP Calls on the LAN Interface Includes Codec/Decoder, Echo Cancellation, Bounce Control, Error Concealment • Telephone communication from cellular phones to VoIP phones • Telephone communication from VoIP phones to cellular phones 802.11

• Decide which IP networks and their signal strengths can be used to deliver the information to the server • AP users • 8 02.1 1 mini-connected power management - whenever the signal strength of 802.1 1 is below an acceptable threshold, Keep the network to sleep at rare intervals and poll the network to save power. • If the phone is in progress, wrap the signal strength and voice quality information into RTCP packets, or keep it active if the phone is not in progress# To communicate to the server. Whenever the signal strength drops to an acceptable threshold or the speech quality degrades, the server will decide to switch from VoIP to the cellular network. Platform Because there are many mobile phone vendors on the market and offer dual-mode phones, the software needs to be designed so that most of the code can be shared between phones. Therefore, the code must be divided into a platform dependent part and a platform independent part. In fact, almost all Divitas cores should be in the platform-independent part of the software, -19-200820682 so it can be easily carried from one platform to another. The platform-dependent part should have only the functional adaptation layer (especially the phone, LAN, 802.11, audio and display adaptation layers). Whenever you transfer code to a new platform, you only need to fix and rewrite these adaptation layers when you provide a unified API to the platform's separate JlL section. User software will be executed on multiple mobile platforms. The most common mobile platforms are Windows CE, Symbian, and Linux. In addition to dual-mode phones, user applications are designed to operate on 802.11 phones, PDAs, or laptop/desktop computers that do not have a cellular interface. On these platforms, a subset of features can be utilized to the user. Basically, it is impossible to VoIP from cellular to cellular. Theory of Operation At startup, the user application looks for resources available on the phone. The user application first checks for the presence of the wired network. If not, the user application checks for the presence of the 802.1 1 network. Depending on the corporate security policy φ wired or wireless media certification. Mobile phone users should support the security agencies that companies use. The most common security mechanism is WPA (WiFi Protected Access). Once the authentication is successful, the wireless user obtains the IP address of the IP interface using DHCP. The application retrieves the Divitas server URL and DNS IP address from the persistence database and attempts to register with the Divitas server. Application users can be executed on mobile phones within the corporate network. At that point, the user can reach the Divitas server without any additional security overlay. When the user is on a public network (for example, a cafe or airport with WiF.i Internet Access -20-200820682), the user typically sets up a VPN connection to the enterprise. The user can only reach the Divitas server after the VPN tunnel is established.

The user application software authenticates the server to the server by sending an encrypted digital visa (installed by the corporate IT). Once the phone is authenticated, the user obtains the login/password from the user or stored in the phone, encrypts the login/password and sends the encrypted login/password to the server as the user authentication. When successful authentication, the server answers by sending a corporate phone number. In response, the user sends a cellular phone number to the server. The server combines the two for all future messaging solutions. SIP/TLS for signaling and SRTP for media streaming are used to ensure signaling and media streaming. However, if the user is on a VPN link, the user does not need to add another level of encryption. Adding another level of encryption can result in reduced voice quality. In that example, SIP is used for signaling and RTP/RTCP is used for media streaming. Repeating the above-described processing of the steady-state operation each time the user restores the network connectivity to the server. By configuring the GUI and saving the configuration in the persistent database, the user can select INVISIBLE or AVAILABLE at startup. Invisible / available). The user updates the user presence information to the server.

Users can also frequently enter so-called partners in the company and save the configuration in a persistent database on the phone. Whether they are INVISIBLE 200820682, AVAILABLE, or C A L L · IN P RO G RE S S (in the phone), the user gets the presence information (huge amount) of these partners. When an event occurs, the server updates the presence information of these partners to the user. The periodic exchange of users and servers continues to be effective whenever they are not on the phone. The user periodically sends the network status to the server. If the user is shown on the 802.1 1 wireless network, the user sends the SSID, the φ signal strength and bandwidth of the associated access point (AP) to the server. If in the phone, the user sends the SSID as part of the RTCP packet in the band. If not on the phone, the user sends a persistent message out of band. The preferred mode of making and receiving calls to users is on the network interface whenever a network conversation is available from the user to the server. However, the user can choose to place a call on the cellular network regardless of the presence of the preferred mode. This selection is not passed to the server and does not affect incoming calls. This selection is also not stored in the persistent database. The user must explicitly choose when the user dials φ to make a call. The only way to make a phone-welded call is from the cellular interface whenever the network conversation is not available from the user to the server. Users do not have access to all corporate features. Whether the user software provides only a subset of service provider features, the user can make and receive calls using the user software UI. In order to use all the features of the cellular service provider network, the user must terminate (or disable) the user software and use the cellular service provider to dial the application. If the service provider application is being used to make and receive calls, the messaging described in 3.4.2 below will not be possible. -22- 200820682 As long as the user has a conversation that has been established to the server, the user has access to all enterprise features. User GUIs are used to provide access to these enterprise features to the user. voice

SIP signaling is used to establish a voice call between the user and the server. The speech from the audio receiver is encoded into one of the encoder/decoders supported by the GIPS Speech Engine (VE), which will be encapsulated into RTP packets, encrypted if necessary, and sent to the server on the ip interface. Similarly, if necessary, the RTP received from the server is decrypted and decoded and implemented using one of the encoder/decoder. Speed decoding, jitter control, and error concealment are performed by GIPS VE on the receiving side. In addition to encryption/decryption, speed encoding/decoding, the GIPS speech engine performs error concealment, jitter control, adaptive packet buffering, acoustic echo cancellation and suppression, noise cancellation and suppression, automatic gain control, voice activity detection, Comfort noise is generated. Roaming is not like a portable laptop. The mobile phone user is a mobile device. The communication in the WLAN. When the user is in the 802.1 1 network with telephone conversation and walking between buildings, AP communication may occur. That is to say, in addition to the AP of the previous mobile phone -23-200820682, the user's mobile phone is now combined with different APs. If the communication is on the same subnet or on another subnet, AP communication can occur without an IP address change. In this example, the IP address of the mobile phone changes. If the IP address changes, the user needs to register with the server again. At the same time, the established phone continues to flow using the old flow information until the voice engine (VE) is notified of the new IP address. When a wireless subscriber uses 802. IX authentication, a series of messages are sent between the wireless subscribers by wireless φ access point (AP) to exchange certificates. This message exchange causes a delay in connection processing. When a wireless user roams from one wireless AP to another, the delay in performing 802. IX authentication can result in significant disruption of the network connection, especially for time-dependent traffic such as voice or video-based data streams. To minimize the delay associated with roaming to another wireless AP, the wireless device can support PMK caching and pre-authentication. PMK cache

When a wireless user roams from one wireless AP to another, the wireless user must perform full 802. IX authentication with each wireless AP. WPA enables wireless users and wireless APs to cache the results of full 802. IX authentication so that if a user roams back to a previously authenticated wireless AP of a wireless subscriber, the wireless subscriber only needs to perform a 4-way handshake and decide on a new pairing transition key. . In the associated request frame, the wireless subscriber includes the PMK identification symbol determined during the initial authentication and stored by the wireless subscriber's PMK cache entry for the wireless AP. If it is combined with wireless users and wireless APs, will it? 1^1: The cache entry is stored for a limited amount of time. -24- 200820682 In order to make the transition of the wireless network infrastructure using the switch that is used as the 802.IX Authenticator faster, the WPA/WPS IE Update calculates the PMK identification symbol 値 so that when it is attached to the wireless AP of the same switch When roaming, re-use the PMK as determined by the switch 802. IX authentication. This implementation is considered an opportunistic PMK cache. Pre-certification

With pre-authentication, WPA wireless users are free to perform 8 0 2. IX authentication with other wireless APs within their range while connected to their current wireless AP. Wireless users send pre-authenticated traffic to additional wireless APs over their existing wireless connections. After pre-authenticating with the wireless AP and storing the PMK and its associated information in the PMK cache, the wireless user connected to the wireless AP that the wireless user has pre-authenticated only needs to perform a 4-way handshake. WPA users who support pre-authentication can only authenticate with wireless APs that publish their pre-authentication capabilities in the Beacon and Probe Response frames.

WiFi-Hive Communication When a user in an 802.1 1 network with a telephone conversation walks outside a building without 802.1 1 connectivity or deficiency, the call is sent to the cellular network. The decision of the user to make a communication call. The decision is based on 802.1 1 signal strength, channel load, and speech quality criticality. Once the decision is made, the decision is passed to the server that initiates the call to the user on the cellular network. Use -25- 200820682 to check the caller id (identification symbol) of the incoming call, compare it with the 802.1 1 caller id, and if there is a match, accept the cellular phone and discard the 8Q2.U phone call. On the server side, the server drops to the user's 8 02.1 1 phone pin and repairs it to the other party's 802·1 1 phone pin. Source When the mobile phone user is idle on the 802.11 network, the 802.1 1 mini φ port goes to sleep. Before going to sleep, the phone tells the AP that it wants to go to sleep by setting the source bits in the 802.1 1 header of each frame. The AP receives the frame and notifies the user of the desire to enter the mode source mode. While the user's 802.1 1 mini connection is asleep, the AP starts buffering packets for the user. The mini-connector has very low power consumption while asleep. The mini-connector periodically wakes up to receive periodic distress calls from the access point. The source user needs to be awake to receive help when transmitting for help. TSP (Sequence Synchronization) ensures that the AP and the section source user are synchronized. When the base station is asleep Φ, the TSP timer remains running. These distress identified the sleeping base stations with packets that the AP has buffered and are waiting to be shipped to their respective destinations. When there is no incoming call for a long period of time, the 802.11 mini connection goes to sleep. The mini-connector wakes up periodically to detect the AP's network connection. If it does not exist, the mini-connector returns to sleep. In this case, the mini-connector sleeps longer than the previous example. B. Acoustic Echo Cancellation Based on Encoder/Decoder One or more embodiments of the present invention are related to means for canceling signals. -26 - 200820682 The apparatus may include an identification code (ID code) generator that is assembled to generate a 1D code. The apparatus can also include an ID code injector configured to inject an ID code into at least one of the signal and the processed signal to produce a whirling signal. The processed signal is produced by the processing of the signal. The apparatus can additionally include an ID code detector configured to detect at least one of a transition of the whirling signal, the transformed signal, and the whirling signal, the transformed signal being resulting from a transformation of the whirling signal. The apparatus can additionally include an arithmetic function that is configured to remove at least one of the whirling signal and the transform φ signal. 4 depicts an encoder/decoder based acoustic echo cancellation method in accordance with one or more embodiments of the present invention. When both the near-end and far-end talkers are speaking, it is difficult to distinguish between the echo of the far-end speaker's voice and the near-endian's voice, since both exist in the near-end signal input with the same human speech characteristics. . In this application, a new method is proposed to deal with acoustic echo, which is quite different from the current AEC. An embodiment of the invention is a method for canceling echo during communication between a first node and a second node. The method includes injecting a password into the signal input of the first node. In accordance with one or more embodiments of the present invention, the first node is a network device used by a remote user and the second node is a network device used by a near end user. In accordance with one or more embodiments of the present invention, the first node is the network device used by the near end user and the second node is the network device used by the remote user. In accordance with one or more embodiments of the invention, a password is injected into the remote signal input. In this way, the signal carries a multi- -27-200820682 echo of the signal or far-end signal and arrives at the near-end signal input. The near-end signal in turn includes the near-end speaker voice. Because the password is only carried on the echo of the far-end signal rather than the voice of the near-end speaker, the password can be used as the echo itself and helps us distinguish between the near-end speaker voice. Some kinds of matched filters, such as association or other means, can be used to cryptographically recognize the echo of the far-end signal and the near-end speaker speech and remove them. A final echo-free signal will be generated at the far-end signal output.

There are two important implementation considerations for this new design effort. One of the considerations is how to choose and design a password, and another consideration is how to inject the password into the far-end input signal. Both considerations have the same consideration that the end-to-end listener should not be aware of the password. When someone speaks in front of the microphone, not only the voice of the person but also a certain amount of background noise will enter the microphone. However, because the speaker's voice obscures background noise, this background noise usually does not interfere with the listener. As long as the background noise remains low and the SNR (signal-to-noise ratio) remains above a certain critical level, background noise does not become an influential factor. In fact, background noise is always present in actual today's voice communications. Based on the above facts, first, the password can be converted into a virtual random noise called "password random noise". Next, the existing background noise is removed from the far-end signal input, and the cryptographic random noise is inserted into the far-end signal input. As long as the new SNR remains above a certain threshold, the near-end listener will not hear any difference. In accordance with one or more embodiments of the present invention, the injector of Figure 4 scrambles the cryptogram into virtual random noise, removes existing background noise from the far-end signal input, and then inserts a cryptographic random noise. -28- 200820682 Because the echo will only exist when the far-end speaker is speaking, the far-end signal detector will detect the presence of the far-end signal and trigger the password generator. The cryptographic pilot can include cryptographic timing and phase. The crypto pilot detector is used to detect the cryptographic pilot carried on the echo of the far-end signal and is also used to adjust the cipher delay to the matched filter because of the variable echo path. At the end of the crypto pilot detector, no scrambling will be required. The cipher and cipher pilots can be designed as cipher detectors and matched filters φ to easily recognize the echo of the far-end signal with this cipher and its pilot, and then remove these echoes. In addition, a nonlinear processor can be used after the matched filter to further reduce the residual echo and improve AEC performance. The features and advantages of the present invention will become more apparent from the description and appended claims. Echo is a big problem in communication. As discussed in the background of the invention, in the prior art, a filter (or echo canceller) can be used to model the attempt to provide a signal to eliminate the echo path of the echo.

FIG. 8A is a block diagram of an exemplary prior art communication device 800 (known art device 800) including a filter 814 (or echo canceller 814) for echo cancellation. As shown in the example of FIG. 8A, the prior art device 800 can include a signal receiver 802 for receiving a far-end signal (eg, signal y') from a remote (or far-end); and a signal transmitter for transmitting The signal (eg, signal z) is far away. The prior art device 800 in turn includes a speaker 806 for playing the received signal to a user (ie, local or near-end side) of the prior art device 800: and a microphone 810 for collecting the near-end signal (eg, Signal X, which may include -29-200820682 local voice and background noise). The prior art device 800 further includes a buffer 821 to buffer the signal received from the signal receiver 802; and a filter 814 for modeling the echo path 808 between the speaker 806 and the microphone 810, And used to process the signal buffered in the buffer 8 1 2 . The echo path 8000 may represent multiple paths of delay, attenuation, reverberation, etc., for example, converting the signal y ' to y 1 or the like. The prior art device 8 00 additionally includes a summation function 8 1 6 for subtracting the output of the filter 814 from the output of the microphone 860. The prior art device 800 additionally includes a signal feedback path for feeding the output of the summation function 8 16 back to the filter 8 1 4 . The signal (e.g., signal y') received by signal receiver 802 can be forwarded to speaker 806 and buffer 812. Filter 814 receives the signal from buffer 812, processes the signal using the model of echo path 808 to produce a cancellation signal (as a function of y '), and transmits the cancellation signal to sum function 8 16 . Next, the sum function 8 16 subtracts the cancellation signal received from the filter 8 1 4 from the signal received from the microphone 8 1 0 (eg, φ x 1 = x + y 1) (eg, x2==f (y')) to generate a subtraction signal (e.g., Z) and to transmit a subtraction signal to the signal transmitter 8 1 8 . The output of the sum function 8 16 is fed back to the filter 8 1 4 to update and improve the echo path model in the filter 8 1 4 . The new cancellation method implemented in the conventional configuration 800 is further described with reference to FIG. 8B. Figure 8B is a flow diagram of an exemplary prior art method for removing echo, such as the prior art device 800 (shown in Figure 8A). The method of Figure 8B shows that the method begins in step 850 with the receiver 822 (shown in Figure 8A) transmitting the -30-200820682 signal y'. Control is then moved to steps 852 and 854. At step 852, speaker 806 (shown in Figure 8A) receives signal y. In step 156, microphone 810 (shown in Figure 8A) receives signal yl plus the near-end signal X. The signal y 1 represents a deformation signal of the signal y' generated due to delay, attenuation, reverberation or the like. Delay, attenuation, reverberation, etc. are produced by an echo path 80 8 between the speaker 806 and the microphone 808 (shown in Figure 8A). Signal X includes the local voice plus the local ambient background φ noise picked up by the microphone 8 10 . Then, a signal x1 representing a combination of the signal yl and the signal X is sent to the sum function 816 (shown in Fig. 8A). In step 854, buffer 812 in turn receives signal y'. In step 858, filter 814 processes signal y' using the model of echo path 808 to produce signal x2, which is a function of y', such as f(y'), which is then sent to sum function 816 (Fig. 8A Show). In step 860, summation function 816 subtracts signal x2 from signal x1 to produce signal z. Ideally, if f(y') is equal to yl, then z will be equal to X, and φ is the near-end signal associated with the far side from which the echo (represented by yl) has been removed. However, the model of the echo path 808 implemented in the filter 814 may be inaccurate, typically z is not equal to z. In step 862, summation function 8 16 sends signal z to signal transmitter 8 1 8 that transmits z to the far side. In step 864, the 'sum function' 8 1 6 feeds the 丨g number z back to the sprinkler 8 1 4 to update and improve the echo path model utilized in step 859. The feedback of the signal z and the associated calculations and updates cause the filter 8 1 4 to require additional processing time or processing power. -31 - 200820682 The quality of the signal Z (ie the error of the signal z with respect to the signal X) depends on the echo path model and the algorithm implemented in the filter 8 1 4 and the memory and processing of the computing device implementing the filter 8 1 4 Depending on the power. With respect to prior art devices, configurations, and methods (as shown by the prior art device 800 of FIG. 8A and the method of FIG. 8B), the correction modeling of the echo path 808 (eg, the executor of the filter 814) is It is important to effectively eliminate echo. However, the echo path 808 is dynamic, so it is difficult to accurately model the various surrounding noises, the reverberation of the surrounding noise, and /φ or other factors. As a result, conventional techniques, arrangements, and methods do not effectively eliminate echo. The prior art devices, configurations, and methods additionally face bilateral conversations where the local (or near-end) and distant (or far-end) simultaneous speech. Since the local speech and the distant speech have similar vocal characteristics, the filter 814 cannot accurately identify which signal is to be input to the model of the echo path 808. As a result, the local speech portion may be eliminated, and the echo portion is not eliminated φ, and the error of the echo path model in the filter 814 may become divergent instead of convergence, resulting in undesirable communication quality. Thus, in the prior art, many resources have been invested to improve the algorithm of the modeled echo path 808. In addition, the filter 114 requires a large amount of data memory and CPUs that require high processing power. As a result, a high cost of implementing echo cancellation is generated. In contrast, one or more embodiments of the present invention include a device for canceling signals even if no filters are provided. In one or more embodiments, the signal represents a digital signal. The device includes an identification code (ID code) generator that is configured by the -32-200820682 to generate an ID code. The device in turn includes an iD code injector that is configured to inject an ID code into at least one of the signal and the processed signal to produce a whirling signal. The processed signal is produced by the processing of the signal, such as the removal of background noise. The apparatus additionally includes an ID code detector configured to detect at least one of a transition of the whirling signal, the transformed signal, and the whirling signal, wherein the transformed signal is produced by a transformation of the whirling signal. The transformation of the whirling signal can be caused by the configuration of the device and/or the environment. For example, the transformation of the whirling signal φ represents the delay produced by one or more echo paths between the speaker and the microphone of the device; the transformed signal represents the delayed signal that is delayed. The apparatus additionally includes an arithmetic function that is configured to remove at least one of the whirling signal and the transformed signal. Figure 9A is a block diagram of a communication device 900 (device 90 0) that cancels echo even if no filter is provided, in accordance with one or more embodiments of the present invention. The block diagram again shows a communication system or configuration having the components shown in Figure 9A implemented in one or more devices.

Apparatus 900 includes input/output components such as signal receiver 904 for receiving remote signals from a remote location, signal transmitter 93 2 (to transmit signals to a remote location), speaker 914, and microphone 916 (local microphone 916), etc. . There is an echo path 908 that travels from the speaker 914 to the microphone 91 6 . Device 900 can also include signal processing modules, such as background noise remover 906 and the like. Background noise remover 906 can be configured to remove background noise from signals received from signal receiver 904. The background noise remover 906 can be implemented using one or more well-known algorithms such as spectral subtraction for background noise removal. -33- 200820682 The device 900 can also include a module for canceling echo. The module may include an identification code generator 922 (ID code generator 922), an identification code injector 910 (ID code injector 910), an identification code detector 924 (ID code detector 924), and a buffer 926. The module may also include a transform module, such as a delay 92 8 , etc., for example to transform signals, introduce delays. The module may also include arithmetic functions such as, for example, a sum function 93 0 and the like. The ID code generator 922 can be configured to generate a controllable and removable ID φ code such that a portion of the signal can be identified. The partial signal is then removed, for example for echo cancellation purposes. The ID code can represent a virtual random code that can simulate background noise or mitigate noise. The ID code generator 922 can include a linear feedback shift register to generate the virtual random noise sequence to be used as the ID code. Additionally, the ID code can include high frequency or low frequency signals that are not detectable by the human ear. In one or more embodiments, the sampling rate of the microphone 916 can be grouped to process high frequency or low frequency signals, for example, via hardware and/or software (or drive φ) of the assembled microphone 916. In one or more embodiments, device 900 may not include background noise remover 906 by virtue of an ID code indicative of a signal that is not detectable by a human ear. The ID code injector 910 can be configured to inject the ID code generated by the ID code generator 922 into the signal. The ID code injector 9 1 0 can be implemented by a well-known algorithm such as a digital correlation method such as inserting an ID code into a signal, for example, by swirling an ID code and a signal to generate a whirling signal. The ID code detector 924 can be configured to detect an id code within the whirling signal, such as in a mix, overlay, and/or another -34-20820 outside whirling signal that includes one or more other signals. Alternatively, ID code detector 924 can be configured to detect transformed signals and/or ID codes resulting from the transformation of the gyro signal; for example, the configuration and/or environment of device 900 can produce a transform. Additionally, ID code detector 924 can be configured to detect transforms. The transform can include delay and signal level attenuation. ID code detector 924 can implement one or more well-known algorithms, such as digital correlation or matched filters for detecting IDs. Delay 928 can be configured to introduce delay into the signal. The delay φ can be used for analog transformations. The delay 928 can be implemented by introducing a simple delay line shift register for delay. Each of the noise remover 906, the ID code generator 922, the 10 code injector 910, the ID code detector 924, and the delay unit 92 8 are all included in a user device such as a telephone, a mobile phone, a teleconferencing device, and the like. In software such as for acoustic echo cancellation, and/or server devices (eg, for line or network echo cancellation). Figure 9B is a block diagram of an ID code generator 922 for device φ 900 (shown in Figure 9A) in accordance with one or more embodiments of the present invention. The ID code generator 922 may be included only in the code generator 921 that will directly generate a random code. In this example, code generator 92 1 is implemented, such as by a well-known algorithm such as a linear feedback shift register that carefully selects an appropriate feedback function. However, the ID code generator 922 may include a code generator 921 that is accompanied by a random function generator 923. In this example, first, the code generator 921 can generate an appropriate identification code without fear of randomization occurring. This identification code is then fed into the random function generator 923 to become a virtual random noise sequence that is the output of 922. The random function generator 923 can be implemented by the modified linear feedback shift register by the -35-200820682 of the feedback function controlled by the code generator 92 1 . Figure 9C is a flow diagram of a method for canceling echoes in, for example, device 900 (shown in Figure 9A), in accordance with one or more embodiments of the present invention. The method begins in step 952, in which signal receiver 904 (shown in Figure 9A) can receive signal y'(n) from a remote location.

In step 954, the noise remover 906 can remove background noise from y'(n), producing a signal y(n). In order to leave room for the ID code including random noise, background noise can be removed. Therefore, this place does not receive excessive noise. In step 958, ID code generator 922 (shown in Figure 9A) can generate an ID code c(n). The ID code c(n) can represent a known and controllable function. In step 956, ID code injector 910 (shown in Figure 9A) can inject ID code c(n) into signal y(n). As a result, a convolution of c(n) and y(n) can be produced. For example, the wrap of c(n) and y(n) may be the whirling signal c(n)*y(n). Control is then transferred to step 96 2 and step 98 0. In step 962, the speaker 914 (shown in Figure 9A) can receive the whirling signal φ number c(n)*y(n). In step 964, microphone 916 (shown in Figure 9A) can receive a delayed signal from speaker 914, i.e., signal c(n-d)*y(n-d). The microphone 9 16 can also pick up another input signal x(n) that includes local voice (e.g., in a bilateral call plan) and/or background noise surrounding the microphone 916. The microphone 916 can then output the combined signal x(n) + c(n-d)*y(n-d) to the ID code detector 924 (shown in Figure 9A) and the sum function 930 (shown in Figure 9A). In step 980, buffer 926 (shown in Figure 9A) may buffer a copy of the whirling signal C(n)*y(η) and output a copy of the whirling signal to the delay -36 - 200820682 928. In step 9 6 6 In the ID code detector 9 2 4 (Fig. 9 )), the ID code c(nd) in the combined signal x(n) + c(nd)*y(nd) can be detected, and assuming c ( n) is a known and controllable function, and the amount of delay d can be determined by comparing c(n) and c(nd) received from the ID code generator 922. The delay amount d can be fed to the delay 928 (shown in Figure 9A). In step 982, delay 928 (shown in Figure 9A) may introduce φ delay amount d from the output of buffer 926 (i.e., a copy of c(n)*y(n)) from step 980 to produce c(nd). A copy of *y(nd). In step 990, the sum function 930 (shown in Figure 9A) may subtract the output of step 982 (i.e., signal generation) from the output of step 964 (i.e., signal x(n) + c(n_d)*y(nd)). A copy of c(nd)*y(nd)). In other words, in step 990, the sum function 930 calculates the signal x(n) + c(nd)*y(nd)-c(nd)*y(nd) to obtain the signal X(n), which represents the absence of the signal y The echo of the '(n) (represented by the signal y(nd)) is the input signal picked up by the receiver microphone 916 (shown in Figure 9A). Signal x(n) may include speech such as local to the bilateral call plan, and/or background noise around microphone 9 16 . In step 992, speech including local voices such as in a bilateral call plan and/or background noise around the microphone 916 and a signal x(n) not containing echo may be transmitted to the signal transmitter 932. In this way, the echo in the single-call and bilateral call schemes can be effectively eliminated. It will be apparent from the foregoing that embodiments of the present invention can effectively eliminate echo without the need for a filter (or echo canceller) as required in conventional techniques, configurations, or methods. In the absence of filter-dependent echo path modeling, the embodiment of the present invention may provide more accurate echo cancellation and faster cancellation, thus achieving better quality of service. In addition, embodiments of the present invention can effectively eliminate echo in a bilateral talk scheme where conventional filters are often poorly implemented. Embodiments of the present invention may also advantageously eliminate the need for high CPU processing power and large data memory required by the filter, without actually relying on filters and associated complexity without echo path modeling, thereby reducing Real Φ The cost of echo cancellation. C. Content-Based Bounce Buffering Scheme for Video over IP Communications Without the filter and associated echo path modeling complexity, embodiments of the present invention advantageously remove the high CPU required for the filter The need to handle power and large data memory reduces the cost of implementing echo cancellation.

C. Content-Based Bounce Buffer Design for IP Voice/Video Communication One or more embodiments of the present invention provide a mechanism to handle excessive WLAN jitter using audio VAD and jitter compensation. One or more embodiments of the present invention also operate for video that is used with no or no movement and packet bounce. One or more embodiments of the invention are related to packet communication devices. The packet communication device can include a detector that is configured to detect the characterization content in the incoming packet received by the packet communication device. The packet communication device can additionally include an implementation controller configured to perform an adjustment of the incoming packet to produce an adjusted-38-200820682 packet and output adjusted if the detector has detected the characterization content in the incoming packet Packet. A new jitter buffer design called a content-based jitter buffer is proposed to address the current jitter buffering technique limitations. In accordance with one or more embodiments of the present invention, not only the RTP header information of incoming packets is noted, but also their RTP payload content is noted, thereby recognizing the silent and speechal presentations on incoming packets. A clue is then generated based on this silence and speech to determine when an implementation delay can be inserted to compensate for network packet bounce. With this new design, the jitter buffer on the receiver side will no longer rely on the silent suppression of the transmitter. Figure 5A-B shows the high-order summary of the jitter buffer architecture. The path of the packet will be tracked via the function block in the Voice Quality Engine (VQE). The purpose here is to introduce an adaptive debounce controller to make the implementation equal. A similar design can be used to handle video jitter. In one of the conventional technique bounce buffer designs, the medullary reception VAD (Voice Activity Detection) is used to prevent the bounce buffer from overflowing.

In other words, when a silent or speech cues reaches the maximum length, an unvoiced or spoken cues are used to embed the bounce buffer. Differences between new and conventional technology designs include silent or speech, which is now used to control when insertion delays can be inserted to compensate for network packet bounce. Thus, in accordance with one or more embodiments of the present invention, silent or speech detection will become an important part of the jitter buffer design. In some cases, when the bounce buffer becomes an overflow, it is too late to make any adjustments. Here's how to apply this content-based bounce buffer device and method to a working application. Both voice and video examples are explained below. -39- 200820682 Figure 5A is a block diagram of a speech hopping buffer in accordance with one or more embodiments of the present invention. The core jitter buffer includes one or more components for packet queues, packet implementation, jitter calculation, and jitter compensation. Here, the decoder and VAD will produce silent and speech indicators. The Silent or Speaking Indicator is then fed back to the Bounce Compensation section and used to determine when the insertion is silent to compensate for network packet bounce. Figure 5B is a block diagram of a video hopping buffer in accordance with one or more embodiments of the present invention. The core jitter buffer is similar to the core jitter buffer of speech except that when the video frame is not moved or the movement is extremely low, the insertion delay is implemented. Here, after the decoder, the motion estimation and motion compensation will produce the remaining frames. From this remaining frame, some specific thresholds can be added to form a no-movement indicator. The no-movement indicator is then fed back to the jitter compensation portion and used to detect when the insertion is silent to compensate for network packet bounce. In video, inserting a silent implementation actually stops the implementation of the new frame while repeating the previous video frame.

As mentioned above, issues such as packet delay (i.e., packet arrival late), packet delay variation, and packet loss have a negative impact on quality of service (Qo S) in packet communication. Packet delay and packet delay variation can also be considered as jitter. In order to solve these problems, in the prior art, a fixed debounce buffer is designed to compensate by periodically inserting a delay (ie, a silent packet or a comfort noise packet) when implementing a packet from a packet buffer. The late arrival of the packet. However, with a fixed debounce design, excessive insertion delays between voice packets can result in abrupt speech. In the prior art, a Transmitter Side Voice Activity Detector (VAD) may also be used for adaptive insertion delay' to compensate for packet delay and packet delay variation. However, some user devices do not support the transmitter side VAD. In addition, for example, when the transmitting party is performing music playback, since the music interruption is regarded as silent and inappropriate processing, if it is an existing VAD algorithm, the transmitter side VAD may generate unwanted noise or abrupt speech. In another example, when the transmitting party uses the G.729AB encoder/decoder to play some music with the open transmitter side VAD, the φ user in the receiver side will perceive the distorted music. Therefore, the packet communication service provider usually turns off the transmitter side VAD and cannot compensate for packet delay and packet delay variation. As a result, the fixed debounce buffer design is still used, and the quality of service is still not what the receiver wants. Additionally, in the prior art, a receiver side silent detector can be used to control the packet buffer overflow to prevent packet loss. However, according to the combination in the prior art, the voice packet is discarded, so that the packet buffer is lost when it is almost full or full, and the quality of the service is not what the receiver wants to participate in. Conversely, embodiments of the present invention may utilize receiver side silent detectors to compensate for delay and delay variations in a timely manner, and adaptively implement packets from the packet buffer. Advantageously, the transmitter side VAD is not required to provide the desired quality of service. Additionally, one or more embodiments of the present invention may utilize a receiver side video detector to adaptively handle jitter in video communications. In one or more embodiments, the present invention is directed to a packet communication device that can include a detector that is configured to detect characterization content in incoming packets received by the packet communication device. The characterization content can represent voice-41 - 200820682 silent in communication (eg, time period without received voice packets). Alternatively, the characterization content can represent at least one of a lower than critical movement or no movement. For example, the threshold for no moving or still images can be selected to be 10% to 15% of all moving images in the video communication (in terms of volume). The packet communication device may additionally include an implementation controller configured to perform an adjustment of the incoming φ packet to generate an adjusted packet and an output adjusted packet if the detector has detected the characterization content in the incoming packet . Adjustments include delayed insertions in the form of, for example, silent packets or comfort noise packets. Alternatively, the adjustment may include iteratively implementing a previously implemented packet. As a result, the delay and delay variations of the incoming packets received in the packet buffer can be compensated in a timely manner, and the adjusted packets are of acceptable quality to the recipient. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 1 〇 A is a block diagram of a first exemplary conventional voice packet communication configuration (first prior art configuration) with an adaptive jitter buffer design. As shown in the example of FIG. 10A, the first prior art configuration includes a transmitter side device 1091 and a receiver side device 1 092 connected via a network 1 003. Each of the transmitter side device 1091 and the receiver side device 1 092 can represent a telephone, a mobile phone, or a teleconference device. The transmitter side device 1091 may include the following components: a speed buffer 1 〇〇〇 , a voice activity detector 101 (VAD 1001), and a transmitter 1 〇〇 2. These components are described as follows: Speed buffer 1 〇〇〇 can be configured to receive a voice packet (-42-200820682 packet) from the microphone, buffer the packet, and then transmit the buffered packet to VAD 1001. The VAD 1001 can be configured to insert a silent descriptor (SID) when there is silence (i.e., a time period between voice packets) in the packet received from the speed buffer 1 000. Transmitter 1 002 can be configured to receive packets from VAD 1 000 and transmit packets to network 1 0 0 3 . Next, the network 1 003 can transmit the packet to the receiver side device 1 092.

The receiver side device 1 092 may include the following components: a packet buffer 1004, a packet implementation controller 1005, a delay insertion controller 1 006, a delay information module 1 007, a jitter computer 1 008, and a delay computer 1 009. These components are described as follows: Packet buffer 1004 can be configured to receive packets from network 1 003, buffer packets, then send packets to jitter computer 008, delay insertion controller 1 006, and packet implementation controller 1 005. The beat computer 1 08 can be assembled to calculate the jitter size in the packet. Bounce can indicate silence, that is, the time period between the arrival of two voice packets without data. The delay insertion controller 1006 can be configured to determine the insertion delay in accordance with the SID inserted in the packet in accordance with the VAD 1001 of the transmitter side device 1091. The delay insertion controller 1006 can receive the jitter size information from the jitter computer 008 and can receive the packet from the packet buffer 10. The implementation delay computer can be configured to receive jitter size information from the jitter computer 008. Based on the jitter size information, the implementation delay computer 1 009 calculates the delay size to be inserted into the packet. The delay information module 1007 can be configured to integrate information about the timing of the insertion delay from the delay insertion controller 1 006 and information about the size of the delay from the implementation of the delay computer 009. Therefore, the delay information module 1 007 can establish the integrated information into the data structure and send the data structure to the package implementation controller 1005. The packet enforcement controller 1 005 can be configured to receive packets from the packet buffer 1004 and φ insertion delays to packets based on the data structure received from the delay information module 1027. Figure 10B is a flow diagram of the transmitter side processing of the prior art jitter buffer design utilized in the first prior art configuration shown in the example of Figure 10A. Transmitter-side processing begins in step 1 060, in which a speed buffer 1 000 (shown in Figure 10A) can receive, for example, a packet from a microphone used by the transmitting party. The speed buffer 10 can then buffer the packet. In step 1062, the speed buffer 1 000 may set the flag bits of each packet to 以 by default. When each packet reaches the final step φ 1〇72, if the packet is the first speech packet that is spoken, the flag bit of the packet is set to 1. Otherwise, the sign bit can be kept at 0 〇 In step 1 064, the VAD 1001 can determine if the packet contains one or more silent periods (β卩, one or more periods of no data between packets). If the packet contains one or more silent periods, then control transfers to step 1 074; if not, control transfers to step 1 066. In step 1 〇 74, the VAD 1001 can determine if the SID has been set in the packet. The SID (Sound Descriptor) is grouped to indicate the beginning of the silent period -44- 200820682. If the SID has been set for the silent period in the packet, the control is directly shifted back to 1 0 72; if not, the control is moved to step 1 076 before moving to step 1 0 72. In step 1076, VAD 1001 may generate a SID for the packet. In step 1072, Transmitter 1 002 (shown in Figure 10A) can transmit the packet to Network 1 003. In step 1 066, VAD 1001 may determine whether the packet contains the first voice packet after the silent period. If the packet contains the first voice packet, then φ control moves to 1 068, in which VAD 1001 can set the flag bit of the first voice packet to one. If the packet does not contain the first voice packet, then control transfers to step 1 072, in which the transmitter 1002 can transmit the packet to 1003. FIG. 1C is a flow chart of a conventional technique delay calculation process. The delay calculation process may be part of the receiver side processing in the receiver side device 10092 for the first prior art configuration shown in Fig. 1A. The delay calculation process can be performed by the packet φ buffer 1 004 including the receiver side device 1 092 shown in the example of FIG. 10A, the delay insertion controller 1 006 bounces the computer 1 008, implements the delay computer 1009, and delays the information module 1 007. The delay calculation process can begin in step 1 022, in which packet buffer 1 004 can receive the packet from network 1 003 and buffer the packet. For example, the packet may represent a packet transmitted by Transmitter 1 002 (shown in Figure 10A) in step 1 072 (shown in Figure 10B). In step 1024, the beat computer 1〇〇8 calculates the average jitter j. In step 1026, the jitter computer 1〇〇8 can calculate the jitter deviation v. In step 1028, the implementation delay computer 1 9 can use j and v and -45-200820682 to calculate the implementation delay based on the network model represented by f(j, V) (ie, delay d = f(j, V)) In step 1 03 0, the delay insertion controller 1 〇 06 may determine whether the packet buffer 1004 is empty. If the packet buffer 1004 is empty, then control transfers to step 1 0 3 8; if not, then control transfers to step i 3 2 . In step 1032, the 'delayed insertion controller 1' 6 determines whether the flag bit of 値1 has been set. If the marker symbol of 値1 has been set, move control to step 1 〇3 8; if not, move control to 1 〇3 4 In step 1〇3 4, delay insertion control Device 1 006 can determine if there is an S ID in the packet. If there is an S ID, then control transfers to step 1 〇 3 8; if not, control transfers to step 1036. In step 1036, the delay insertion controller 1〇〇6 may determine whether the average jitter j is greater than a predetermined threshold. For example, the threshold here may be the length of the packet buffer 1 004.

If the average jitter j is greater than the preset threshold, then control transfers to step 1 〇 3 8 ; if not greater, then control transfers directly to step 1 040. In step 1 〇 3 8 , the delay information module 1 〇 〇 7 can integrate the size and timing information of the insertion delay, and then transfer control to step 1 040. In step 1040, information about the insertion delay can be output to the implementation controller 1005. Figure 10D is a flow chart of a conventional technology packet implementation control process. The packet implementation control process may be part of the receiver side processing in the receiver side device 1 092 for the first prior art configuration not shown in Fig. 10A. The packet implementation control process can be performed by the packet implementation controller 1 005 shown in FIG. 46-200820682 10A. The packet implementation control process begins in step 1 〇 42, in which the packet implementation controller 1〇〇5 can receive the packet from the packet buffer 1 004 (shown in FIG. 10A) and can be received from the delay information module 1 7 (shown in FIG. 10A) receives information about the insertion delay as a result of step 1 040 (shown in FIG. 10C).

In step 1 〇 4 4, the packet implementation controller 1 0 0 5 can determine if enough packets have been inserted. If sufficient packets have been inserted, control transfers to step 1 048; if sufficient packets are not inserted, control transfers to step 1 046. In step 1 046, the packet enforcement controller 1 005 can insert a delay (e.g., in the form of a silent packet or a comfort noise packet) to the packet received from the packet buffer 1 004. In step 1 048, the packet enforcement controller 1 005 can retrieve the packet from the packet buffer 1〇〇4. In step 1 050, the packet enforcement controller 1 004 can implement the packets generated from steps 1046 and 1048. Fig. 10E is a schematic diagram showing the flow of packets received by the packet buffer 1 〇〇 4 when the transmitter side VAD 1001 (shown in Fig. 10A) is turned on. As shown in the example of FIG. 10E, the received packet stream may include a voice packet 1080, a silent 1 084 behind the voice packet 1 〇 80, a voice packet 1086 following the silent 1 0 84, and a voice packet 1 086. The latter is silent 1 0 8 8 and so on. Silent 1 084 and Silent 1 0 8 8 represent the time period during which the packet implementation controller 1 005 did not receive the voice packet. Since the VAD 1001 is turned on, the VAD 1001 has set the flag bit of the first voice packet such as the packets l〇80a and 1 086a to 1. In step 1 032 shown in Figure 10C, the sign bit can be marked with -47-200820682 of 値1 to determine when to insert the delay.

In addition, the VAD 1001 inserts the SID 1082 at the beginning of the silent 1 084 and inserts the SID 1 090 at the beginning of the silent 1 08 8 . SID 1 082 and SID 10 90 can also be used in step 1034 shown in Figure 10C to determine when to insert a delay. The mouse 10F is a φ representation of the packet stream received in the packet buffer 1 〇〇 4 (shown in Fig. 10A) when the transmitter side VAD 1001 (shown in Fig. 10A) is turned off. Because existing algorithms utilized in VAD 1 〇〇1 generate unwanted noise or abrupt speech during music playback, VAD 1001 is typically turned off by the packet communication service provider and therefore cannot provide information about voice activity. . As shown in the example of FIG. 10F, the received packet stream includes a voice packet 1092, a silent packet 1 094 connected behind the voice packet 1092, a voice packet 1096 connected behind the silent packet 1094, and a voice packet 1096 behind the voice packet 1096. Silent packet 1 098 and so on. Because VAD 1001 is turned off, it is not

φ Silent Packet 1 094 and Silent Packet 1098 represent the silent period insertion SID. As a result, step 1 034 shown in FIG. 10C is not performed (ie, the SID is detected). In addition, although the voice packet 1092a has a marker symbol 値 of 1, all remaining received packets have a marker symbol 値 of zero. Therefore, the step 1〇32 shown in Fig. 10C is not executed (i.e., it is determined whether or not the flag bit 第一 of the first packet is set to 1). In addition, when the VAD 1001 on the transmitter side 1091 is turned off, the packet can continue to the packet buffer 1 004 on the receiver side 1 0 92 so that the packet buffer 1 004 is never empty. Therefore, depending on the visual design, step 1030 shown in Figure 10C is not executed (i.e., it is determined whether the packet buffer 1 004 is empty). Therefore, when the VAD 1001 is turned off, the delay insertion control 1006 cannot perform steps 1 03 0, 1 032, and 1 034 for the timing of determining the insertion delay. Although in step 1 036 shown in Fig. 10C, the delay insertion controller 1 006 can still obtain information as to whether the average jitter j(i) is greater than a preset threshold, the information is insufficient to determine the timing of the insertion delay. For example, when the average jitter φ j (i) is greater than the preset threshold, the insertion delay is too late. As a result, delays are inserted in inaccurate timings to produce abrupt speech in speech communications. Moreover, even if the existing VAD algorithm of the VAD 1001 is turned on, the VAD 1001 cannot be accurately inserted into the SID. As a result, the front end of the voice packet is clipped and/or the back end is clipped, and the voice quality is not desired by the recipient. 1A is a block diagram of a receiver side device 1 100 of a second conventional technique packet voice communication configuration (second prior art configuration) including an adaptive buffer overflow controller. As shown in the example of FIG. 11 A, the receiver side device 1100 # includes the components of the receiver side device 1 092 in the first prior art configuration shown in FIG. Further, the receiver side device 1100 includes an additional component 1180. The add-on 1 1 80 may include a decoder 1 1 18, a silent detector 1 1 16 , and a buffer overflow controller 1 1 1 4, as explained below: The silent detector 1 1 1 6 can be grouped The configuration is to detect the silence in the packet received from the decoder 1 1 1 8 . If there is no sound, the silent detector 1 1 16 can set the silent flag 1 to 1. If there is no silence, the silent detector 1 1 16 can set the silent flag 〇 to 〇. The buffer overflow controller 11 14 can be configured to monitor the state of the packet buffer -49 - 200820682 1102. Depending on the state of the packet buffer 1102, the buffer overflow controller 1 1 14 may decide whether to drop or hold the next packet received in the packet buffer 1 102. Fig. 1 1 B is a flow chart of the silent detection processing used by the receiver side device 1 00 shown in the example of Fig. 1 1 A. The silent detection process is started in step 1120, in which the decoder 1 1 18 (shown in FIG. 11A) can decompress the voice packets (packets) received from the packet implementation controller 1104 (shown in FIG. 11A).

In step 1124, the silent detector 1116 (shown in Figure 11A) can determine if there is silence in the receiving packet. If there is no sound, then control transfers to 1130, in which the silent detector 11 16 sets the silent flag 1 to one. If there is no silence, then control transfers to step 1 1 26, in which the silent detector 1 1 16 sets the silent flag 0 to zero. / In step 1128, the silent detector 1 1 16 can output a silent flag 値. Fig. 1 1 C is a flowchart of the buffer overflow control process utilized by φ in the receiver side device 1 00 shown in the example of Fig. 1 1A. The buffer overflow control process can be performed by the buffer overflow controller 1114 shown in Fig. 11A. The buffer overflow control process is started in step 1132, in which the buffer overflow controller 1 14 receives the silent flag from the silent detector 1 1 16 (shown in Figure 11A). In step 1134, buffer overflow control 1114 may determine whether packet buffer 1102 (shown in Figure 2A) has reached a first threshold, such as exactly 100%. If the packet buffer 1 102 has reached the first threshold, then control transfers to step 1 1 44; if not, control transfers to step 1 13 6 . -50-200820682 In step 1144, the buffer overflow controller 1114 can instruct the packet buffer 1102 to discard the most recently received packet, regardless of whether the most recently received packet indicates a voice packet. The buffer overflow controller 1114 can also command the packet buffer 1 102 to provide the packet to be implemented. In step 1136, the buffer overflow controller 11 14 may determine whether the packet buffer 1102 has reached a second threshold, such as exactly 80%, and the like. If the packet buffer 1 102 has reached the second threshold, then control transfers to step 1 140; if φ does not arrive, then control transfers to step 1 1 3 8 . In step 1140, the buffer overflow controller 1114 may determine whether the silent flag received from the silent detector 1 1 16 is 1. If the silent flag 1 is 1, control transfers to step 1 1 42; if not, control transfers to step 1 1 3 8 〇 In step 1142, buffer overflow control 1114 may command packet buffer 1 1 02 Discard the most recently received packet because the recently received packet indicates no silence. The buffer overflow controller 1 1 1 4 can also command the packet buffer 1 1 02 to provide φ the packet to be implemented. Control then moves to step 1 1 3 8 . In step 1 138, the packet buffer 1102 can receive and buffer the packet. The buffer overflow control process shown in the example of Fig. 1 1 C is ineffective for maintaining the service quality. For example, when the packet buffer 1 102 reaches the first threshold, such as exactly 100%, the voice packet can be discarded according to step 1144. Therefore, a mutant speech is generated. In addition, when the packet buffer 1 102 reaches a second threshold that is not the first critical, such as, but not exactly 100% of 100%, the packet buffer 1 102 still receives more than the remaining capacity of the packet buffer 1 102. The data packet of the voice packet. As a result, the overflow still occurs, and packets (including voice packets) that exceed the capacity of the packet buffer -51 - 200820682 11 02 will still be lost. As a result, the quality of service is not what the recipient wants. Figure 1 2A is a block diagram of a receiver side device 1200 of a packet voice communication system with adaptive jitter processing in accordance with one or more embodiments of the present invention. The receiver side device 1200 can represent a user device such as a telephone, a mobile phone, a teleconferencing device, an audio player, or a video phone. Alternatively, the receiver side device 1 200 can represent a servo φ device in the packet communication network. As shown in the example of FIG. 12A, generally, the receiver side device 1 200 may include one or more of the following components: a packet buffer 1202, a packet implementation controller 1208, a decoder 1 2 1 0, a delay insertion controller 1 2 1 4, The delay information module 1 2 1 6 , the jitter computer 1 204, and the implementation delay computer 1 206. The receiver side device 1 200 may additionally include a detector that is configured to detect the characterization content, such as detecting a silent silent detector 12 12 and the like. The silent detector 12 12 can be configured to receive the decompressed packet from the decoder 1 1 1 0 0 . The silent detector φ 1 2 1 2 may additionally be configured to process the decompressed packet and provide a silent flag (but not a decompressed packet) via link 1299 to the delay insertion controller 1214, which may be downloaded to The software within the receiver side device 1 200 includes one or more components. One or more components of the receiver side device 1200 can have capabilities similar to the components of the receiver side device 1100 shown in Figure 11A. However, contrary to the silent detector 1116 of the receiver side device 11, the silent detector 12 12 can be configured to determine when to insert a delay in processing the beat to replace the control buffer overflow of -52-200820682, Or add this function in addition to controlling the packet buffer overflow. Additionally, in contrast to the delay insertion controller 1108 of the receiver side device 1100, the delay insertion controller 1214 can receive information from the silent detector 1212 to replace the information received from the jitter computer 1204 in the prior art jitter buffer design. Delay insertion controller 12 14 can be directly coupled to silent φ detector 1212 via link 1299. Link 1 299 can represent a direct logical link or a physical link. The link 1 1 99 between the delay insertion controller 1108 and the hopping computer 1 1 〇 shown in the example of FIG. 11A is between the hopping computer 1 008 and the delay insertion controller 1006 shown in the example of FIG. The link 1 099, in contrast, has no direct logical or physical connection between the jitter calculation 1 2 04 and the delay insertion controller 1 2 1 4 . Fig. 1B is a diagram of a delay insertion control process for the adaptive jitter used in the receiver side device 1 200 shown in the example of Fig. 1A, in accordance with one or more embodiments of the present invention. The delay insertion control process begins in step 1 220, in which the delay insertion controller 1214 (shown in Figure 12A) determines when the packet buffer 1202 (shown in Figure 12A) is empty, i.e., does not contain an implemented packet. If packet buffer 1202 is empty, then control transfers to step 1228; if not, control transfers to 1222. In step 1 2 2 2, the delay insertion controller 1 2 1 4 may determine the flag bit to be set in the incoming packet received via the packet buffer 1202. If there is a SID, then control transfers to step 1228; if there is no SID, then control transfers to step 1226. -53- 200820682 In step 1226, the delay insertion controller 1214 may determine whether the silent flag received from the silent detector 1212 (shown in Figure 12A) is i. If the silent flag 1 is 1, control can be transferred to step 1 228; if not 1, control can be moved to step 1 2 3 0. In step 1228, the packet implementation controller 1 208 (shown in FIG. 12A) may be based on the delay information module 1 2 16 (the information insertion delay (eg, silent packet or comfort noise) as shown in FIG. The packet is sent to the incoming packet to produce a modulated packet. The delay information includes implementation of the size information provided by the delay computer 1206 (shown in Figure 3A) and the timing information provided by the delay insertion controller 1214. In step 1 23 0 The packet enforcement controller 1208 can implement the adjusted packet. The adjusted packet is decompressed by the decoder 1 1 1 0 and then implemented by the receiver side device 1200. As can be seen from Fig. 12B, in general, one or more according to the present invention In an embodiment, that is, any information received from the beating computer 1 204, the delay insertion control 12 14 can still determine the insertion based on the silent flag received from the silent detector 1212 (in step 1226). Figure 13 is a block diagram of a receiving side device 1300 of a packet video communication system utilizing an adaptive jittering process in accordance with one or more embodiments of the present invention. The receiving side device 1 300 can represent a telephone. At least one of a mobile phone, a teleconferencing device, a videophone, and a video player. Alternatively, the receiver-side device 1 300 can represent a server device in the packet communication network. Receiver-side device 1 3 00 A component that performs functions similar to the functions of the components of the receiver-side device 1200 shown in the example of FIG. 3A may be included. The transceiver-side device 1 300 may include a packet buffer 1302, a jitter computer 1304, and compensation. One or more of the controller 1314, the compensation computer 1306, the compensation information module 1316, the packet implementation controller 1308, the decoder 1310, and the video detector 1312. The difference is that the video detector 1 3 1 2 can be configured to detect no movement or low movement in the video packet to replace the silent. In addition, the compensation computer 1 3 06, the compensation controller 1 3 1 4, and the compensation information module 1 3 1 6 can be grouped. Compatible with calculations and φ integrated video compensation information to replace the information that is assembled into the calculation and integration delay insertion. Video compensation can include stopping the playback of the new video frame while repeating the video frame, and can be packaged The controller 1 3 08 executes. Similar to the configuration of the receiver side device 1200, the compensation controller 13 14 can be directly coupled to the video detector 1 3 12 via link 1 399 to determine the timing of the video compensation.

The video compensation control process for the jitter processing of the receiver side device 1 300 is similar to the delay insertion control process shown in the example of Fig. 12B. One or more embodiments of the present invention include a receiver side device that includes a configuration similar to the configuration of the receiver side device 1 300 and is configured to process multimedia communications including voice and video. Beating. Additionally, one or more embodiments of the present invention may include delay insertion control and video compensation control processing similar to the delay insertion control process illustrated in the example of Figure 12B. As can be appreciated from the above, embodiments of the present invention can effectively handle jitter in packet communications without relying on a transmitter side voice activity detector (VAD) or a fixed jitter buffer design. To delay insertion control instead of only -55-200820682 using a receiver-side silent detector for buffer overflow control, embodiments of the present invention can accurately insert delays without the need to insert delays into voice packets. Advantageously, the mutated speech can be reduced to ensure speech quality. Additionally, embodiments of the invention may be used for video communications and/or multimedia communications. D. Divitas Description Protocol (DDP) One or more embodiments of the present invention include a lightweight protocol over SIP, φ which will effectively transfer information between the server and the user, and will be unaffected by hardware and software platforms. Under work. DDP architecture; architecture DDP has been considered under the following factors: Not subject to server and user software and OS: Protocol (DDP) structure and format into DDP does not know the server or mobile hardware platform and in - two The operating system executed on the platform. Protocols in accordance with one or more embodiments of the present invention are architected and designed to perform on any server or mobile hardware platform and are also not subject to the Operating System/SW platform being executed. For example, DDP can be executed on Linux, Symbian, Windows Mobile 5.0, and so on. In summary, it is not necessary to design or develop a particular adapter layer each time a module is transferred to a new hardware or software platform. Decoupling from control plane protocols: DDP has been framed to work with any control plane technology used on a particular platform (ie SIP, H.323, etc.).

Not subject to the delivery protocol: designed to be valid when used by both UDP and TCP. If the best choice is through the transport layer, there is a random module to ensure reliability and performance levels (using ACK/NACK -56-200820682 and Windows). Especially in environments with high packet loss, this reliable module removes the burden of higher-level applications from worrying about shipping.

Smart and careless applications: DDP will be used for a wide range of applications ranging from critical control surface messages with strict on-demand requirements to applications that need to transfer large amounts of data between servers and users. The random module within the DDP enables the application to transfer files and buffers between the server and the user. The agreement also does not care about the type of application data, namely binary, this article. Service Priority Level: Ability to schedule and queue applications with different latency and service requirements. Encryption support: Random modules within the DDP enable the server and handset to establish a secure channel at boot time, and all further DDP exchanges are encrypted to provide a secure level for applications that require encryption. This will still allow the application to exchange unencrypted messages for such applications that do not require encryption. Built-in dialog management: Has specific control messages to initiate and maintain a dialogue between the server and the user. Not subject to media: The agreement is not subject to the media that connects users to the server. Dialogues are available via WiFi, cellular data channels, or wired Ethernet. 6A is a schematic diagram of a DDP architecture fabricated in accordance with one or more embodiments of the present invention. As shown in Fig. 6A, DDP is a dialog layer application executed through the SIP protocol. The transmission of encrypted application layer information between the user and the server is used to influence the messaging decision, providing dialog persistence to the application, such as email or SMTP, but is not limited thereto. Figure 6A is a high-order diagram of the different modules that make up the DDP. Different modules within a DDP in accordance with one or more embodiments of the present invention are described herein. i. DDP Message Processor: This consists of a parser and a message formatting module. The parser is responsible for checking the validity of the received DDP message and extracting various pieces of information before summoning the recycling processor. Ii. Dialogue Management: A φ built-in institution that evaluates the health of DDP conversations between two peers, and an organization that has notified the registered application if the conversation fails. Iii. DDP Scheduler: Provides DDP messages with different priority levels depending on the application requirements. Iv. Reliable DDP Module: Support for reliable delivery of DDP messages, depending on application requirements. v. DDX (Divitas Data Transfer) Module: A module that uses DDP to transfer files and data buffers between the same layer. DDX modules will operate without the constraints of the file format or buffer content, and have mechanisms for error detection and shipping confirmation. Vi. DDPS: A module in DDP that encrypts and decrypts DDP content before inserting DDP into the envelope. DDP has a protocol to establish a secure DDP tunnel between 2 Divitas peers. Figure 6B is an exchange diagram of DDP messages during user activation when a user logs into one of the devices in accordance with one or more embodiments of the present invention. In accordance with one or more embodiments of the invention, the DDP is a layer 4 or application layer protocol. DDP can use TCP, UDP, or TLS for transmission. Similar to SIP or SDP, DDP is a protocol for content encoding. In accordance with one or more embodiments of the invention-58-200820682, the DDP message includes an order of columns or fields, wherein the columns of the fields begin with a single lowercase letter indicating the type of information being shipped; the remaining columns or A field contains a fragment of information associated with a function or method. In accordance with one or more embodiments of the invention, there may be multiple columns or bins having the same starting name or type. In accordance with one or more embodiments of the present invention, depending on the particular type of DDP message being transmitted, each DDP message contains a set of command columns or blocks and any columns or blocks. If the command line is missing, φ then the parser will reject the DDP message. Skip any column that the parser does not understand. This allows for upward compatibility and interoperability between different software versions. Here is an example of a DDP message: ν = 0 · 0 · 0 · 1 o=server r = data 2 c=ext 4444 c = pref cell wifi gprs sms wka 5 cka 10 pwd 1200

Whys 2 0 chys 60 c = wifi rssilo 3 0 rssihi 6 0 chlo 30 chhi 50 c = qos delaylo 5 0 de 1 ayhi 10 0 1 oss 1 o losshi 10 jitterlo 30 jitterhi 50 c = srv intip 1 023414444 ext ip - 1 3 4 3 2 4 5 0 3 2 c = end Then add the DDP message as the message body in the SIP message with the message body type of "application/ddp" or "app 1 icati ο η / ddps". If desired, the DDP body can be easily sent with other transmission protocols. -59- 200820682 An exemplary application of the DDP in accordance with one or more embodiments of the present invention will be described below. Voice Mobility: Voice mobility depends on many factors... The main factor is the WiFi quality perceived by the user. The DDP is used to instantly send a WiFi report with information about the AP currently associated with the handset to make an action decision. The WiFi report can also optionally contain information about the neighboring AP φ so that the mobile server can use this information to make pre-emptive action decisions based on the movement of the predictive handset. In addition to automating updates based on WiFi conditions, DDP is also used by users to initiate action decisions. User/Device Management: Extend DDP to the user and user experience on managing mobile phones. There are several ways to manage DDP-based control and massive transfer messages used by users: a • Device configuration: Once the device/user has been authenticated, the device-specific configuration is sent during the start-up period φ to Device. b. Mobility Critical: Activates an active activity based on the WiFi threshold set by the administrator for the user. c·User Information: When the user logs in to one of the users, the server pushes the user-specific information (eg, extension, preference, etc.) through DDP. d·Device image management; using DDP's massive transfer capability can achieve the ability to upgrade mobile software via network connection. Download to your phone's voicemail/email: Divitas solution, one of the main differences is to download voicemail to your phone and see your ability to manage them. With the priority control message connected to the voice mail system, there is the ability to manage voice mail without IVR, and the same is true for the huge amount of transfer capability in the DDP that transfers voice mail to the mobile phone. A similar function can also be achieved for an email system that can establish an adapter module to interface with a selected email system. User attendance management: Deliver DDP messages with user preferences through voice and content from different media to the attendance management server. φ This is an important part of the ability to support attendance calls. The structure and design of the conference call is also based on enhanced attendance and user preferences...all communicated through DDP to provide service conference calls are designed to be provided. Instant messaging: Messages for IM through the DDP session. This allows the IM user on the handset to be unaware of the media/agreement that the device is operating on. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 14 is a diagram showing an example of a conventional technique for establishing a telephone connection between an application user and an application server. It is assumed that the user of the mobile phone wants to use the application user 1404 to connect to the software download 1406 via the web browser via HTTP (Hyper File Transfer Protocol) connection. Before the software download 14 06 occurs, an HTTP. connection must first be established between the application user 1404 and the application server 1402. In a first step 1 408, the application user 1404 can send a TCP (Transmission Control Protocol) SYN (synchronization) to the application server 1 402. In the next step 1410, the application server 1402 can send a TCP SYN-ACK (TCP synchronization response) back to the application user 1 404. In the next step 1 4 1 2, the application user 1404 can send a TCP ACK to the application server 1402. Once the HTTP connection has been established between the application user 1404 and the application server 1 402, then In a step 1414, the application user 1404 can send an HTTP Get to the application server 1402. In other words, in step 1414, the application user 1404 is sending a user request for software download 1 406 to the application server 1402.

Upon receiving HTTP Get, in a next step 1416, the application server 1 402 can perform a search to find the requested download. In the next step 1 4 18, once the software has been found, the application server 1 402 can begin sending the requested software as a data packet (e.g., TCP data segment) to the application user 1 404. When the requested software file is sent, the software file can be divided into multiple data packets to help send the software file via the network processing. In the next step 1420, when the TCP data section is received, the program user 1404 can send a TCP ACK to the application server 1402. All data packets of the requested software download can be sent by the application server 1 402. Repeat steps 1418 and 1 42 0 before the application user 1 404. Once all TCP data segments have been sent, in next step 1422, the application server 1402 can send an HTTP 200 OK to the application user 1 404. When the HTTP 200 OK is sent, the application server 1 402 notifies the application user 1404 that the data packet has been sent for the software download request. Once the application user 1 4 04 has received each data packet, the application user 1404 can send a notification 1424 to the user informing the user that the download has been completed. For each application user on the mobile phone, the method described in the telephone flow of Figure 1 must be performed by each application user. In this case, if the mobile phone includes multiple application users (eg, video application user, voice application user, instant message application user, game application user, virtual reality application user, etc.), then the application Before the interaction between the user and the application server begins, an independent channel must be established between each application user and its corresponding application server. Since multiple applications are executed on the user, communication between different applications cannot be guaranteed. As a result, an application executing on a particular user fails to notice that another application is being exchanged for data on the same user. In addition, the method illustrated in Figure 1 is a cumbersome method that requires proper integration of the various applications on the application to ensure that the application can successfully interact with its corresponding application on a given server within the enterprise. Since each application that communicates between the user and the server requires a separate network conversation, this approach creates a security risk and adds complexity. In one aspect of the present invention, the inventors herein are enabled to utilize hardware (eg, mobile phones) and software (eg, video application users, voice application users, instant messaging application users, game applications). The single agreement governed by program users, virtual reality application users, etc., integrates all application web conversations. In other words, the inventor implements the application -63- 200820682 users do not need to establish multiple network conversations with their corresponding application server. Instead, the existing control and transport protocol can be used to implement the agreement' and the agreement is independent of the software and hardware so that multiple application users can interact with their corresponding multiple application servers.

In accordance with an embodiment of the present invention, an active architecture configuration is provided by implementing a Divitas Description Protocol (DDP). In an embodiment, the DDP includes a DDP user and a DDP server. Embodiments of the present invention enable DDP to efficiently transfer data packets between a plurality of application users on a mobile phone and a plurality of application servers within the enterprise. Embodiments of the present invention in turn enable DDP to be implemented without being dominated by hardware and software platforms. In an embodiment of the invention, the DDP is not subject to the hardware platform. Thus, DDP can be implemented on dual mode handsets, personal digital assistants (PDAs), 802.1 1 phones, and the like. In an embodiment of the invention, the DDP is also not subject to the software platform. As a result, DDP can be executed on Linux® systems, Symbian® systems, and Window TM Mobile 5.0 systems. In the prior art, the establishment of multiple network conversations requires the creation of multiple channels between the user and the server. In other words, multiple “holes” must be “pierced” within the corporate firewall to enable multiple application users to interact with their corresponding application servers. In an embodiment of the invention, DDP can be implemented to establish a single secure channel that enables interaction between application users on the handset and application servers within the enterprise. The information downloaded to the phone can be managed by the application user with a single secure channel that exchanges multiple data traffic. As such, application users who need to utilize the downloaded information do not have to request to download the data again. Instead, -64-200820682 is that 'optical users with DDP can direct application users to the location where the requested data is stored. In an embodiment of the invention, the DDP may be unaffected by the network. In an example, the secure channel established by the 'DDP can be via a Wi-Fi network or a cellular data network, for example. This allows DDP to ensure that network conversations are delivered to separate networks when users on the user device roam. In an embodiment, the DDP is established at the upper layer of the control protocol and transport protocol. In an embodiment, the DDP can be implemented using any available control protocol (e.g., SIP, H.323, etc.). In another embodiment, the DDP can be implemented using any available transport protocol, such as User Data Element Agreement (UDP), Transmission Control Protocol (TCP), or Transport Layer Security Protocol (TLS). As such, DDP can efficiently route data packets and manage connectivity without having to worry about available control and/or transport protocols. In an embodiment of the invention, the DDP may include a reliability module (RDDP) that ensures the reliability level of the delivered data traffic. This module is used when φ φ uses a transport protocol such as UDP that does not provide reliability. As such, DDP provides a guarantee of successful transmission and relieves the burden of monitoring data traffic from application users. In an embodiment of the invention, DDP can be implemented for a plurality of applications (i.e., application users and their corresponding application servers). In an example, DDP can be utilized by a simple application that does not require instant exchange of data. In another example, DDP can be utilized by an application with instant data exchange requirements. Due to the adjustability of DDP, applications can be added or removed without affecting the power and diversity of DDP. -65-200820682 In an embodiment of the invention, the DDP includes a priority message scheduling module that can be configured to schedule and queue data traffic. DDP can use the priority message scheduling module to automate the download and upload of multiple applications required or required by multiple applications. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 15 is a simplified structural diagram of the DDP invention in the embodiment of the present invention

. In an embodiment of the invention, the DDP 1 53 6 is not subject to the hardware and/or software platform. In one example, the DDP 1536 can be implemented on a plurality of user devices, including dual mode handsets, PDAs, laptops, etc., but is not limited thereto. In another example, it can be combined with, for example, the Li n u X ® system,

DDP 1 5 3 6 is implemented together with different operating systems such as Symbian® system, Windo w Μ biobi 1 e 5 · 0 system. As a result, DDP 1 5 3 6 can be loaded onto different hardware and/or software platforms with minimal modifications. DDP 1 53 6 can be built on top of control agreements and transport protocols. In an example, different control protocol types (eg, SIp 1 53 2 and another control protocol 1 524) and different transport protocol types (eg, UDP 1 534, UDP 1 528, TCP 1 5 3 0, TCP) 1 526, etc.) Use DDP 1 5 3 6 together. The type of control protocol and/or transport protocol that can be utilized by DDP 1 5 3 6 to perform the functions of DDP 1 5 3 6 can be easily accommodated by the DDP. Thus, if the control agreement and/or the transport agreement changes, DDP 1 5 3 6 will be able to utilize any combination of available transport and control protocols as needed. It should be noted that the change of the control protocol and/or the transport protocol does not affect the application layer. The application layer includes the voice mobility control application user 1 506, the device management application-66-200820682 program 1 504, and the plan management application 1 502. , voice mail/email transmission application 1508, device image management application 1510, instant messaging application 15 12, etc., but are not limited thereto. Moreover, in an embodiment, DDP 153 can determine the preferred transmission protocol that provides the best performance and reliability. In this way, the responsibility for identifying the correct transport agreement can be centralized and moved from the complex application to DDP 1 5 3 6 . Since all data traffic between the DDP user and the server is now handled by φ DDP 1 5 36, DDP 1 5 3 6 can determine the optimal transport protocol for routing data traffic while minimizing data packet loss. In an embodiment, the DDP 1536 may include one or more modules, such as a DDP module with secure extension (DDPS module 1 522), a priority message scheduling module 1518, and a reliable DDP module (RDDP module). 1516), built-in dialog management module 1 520, and Divitas data exchange module (DDX module 1514) ° In an embodiment, DDPS module 1 522 can provide a security function to φ DDP 1 536. In one example, DDPS module 1 522 enables a secure channel to be established between the mobile user of the mobile phone and the mobile server within the enterprise. With a secure channel, all incoming and outgoing data traffic from multiple applications can be routed through a single secure channel. In some cases, individual authentication must occur before an application user can interact with their corresponding application server. Unlike conventional techniques, authentication processing can be automated. In one embodiment, DDPS module 1 522 can include a database that includes authentication data needed to establish a connection between an application user and an application server. -67- 200820682 In an embodiment of the present invention, the DDPS module 1 522 can provide an encryption/decryption function, thus enabling the DDP 153 to provide security to an application requiring the function in an example, from an email server. Route important emails from application users 1 5 8 to email application users on the phone. To ensure the security of the email, the DDPS module 1 522 can encrypt the data packet before sending the packet to the corresponding application server. In another example, the φ instant message between two IM users can be sent in a non-secure manner. In this way, DDP 1 53 6 can route instant messages without having to use DDPS module 1 522 to encrypt data packets sent between IM users. In an embodiment of the present invention, the DDP 1 5 3 6 may include a priority message scheduling module 1 5 1 8 , and the module 1 5 1 8 may be configured into a schedule and a queue data package. In other words, the priority message scheduling module 1518 is responsible for managing a plurality of different data packets served by the DDP 153. In one embodiment, the priority message scheduling module 1 158 can establish a policy for processing incoming and outgoing data packets. In one embodiment, the priority message scheduling module 1 518 depends on the originating φ application and may have different priority levels. In one example, application A (eg, email) does not require immediate delivery of a chess data packet. However, application B (eg, attendance management) is quite sensitive to time delays and requires immediate delivery of data packets. In an embodiment, the priority message scheduling module 151 8 can be any DDP module. In one example, if DDP 1 536 currently only processes data traffic for an application, DDP 1 5 3 6 does not have to use the priority message scheduling module 1 5 1 8 to process the schedule of the data packets. In an embodiment of the invention, the DDP 1 653 may include a reliable module (RDDP 1516) that provides a guarantee of the positioning of one of the plurality of data packets - 68-200820682. In one embodiment, to warrant shipment, RDDP 15 16 has a mechanism to retransmit packets that have not successfully reached their destination within a particular time interval. In an embodiment, if the data packet is not received within the preset time interval, the packet is retransmitted. The packet can be retransmitted a specific number of times before the transmission of the notification application packet has failed. With the RDDP 1516, the DDP 1536 provides the assurance that data packets are sent and/or received in the order required by the program.

In one embodiment, DDP 153 may include a DDX module 1514 that can be used to transfer large amounts of data (e.g., image files, log files, etc.) between the mobile user and the mobile server. In an embodiment, the DDX module 1 51 includes a mechanism for ensuring data integrity of data transmission between the mobile user and the mobile server. In another embodiment of the present invention, the DDX module 1514 may include a mechanism for confirming completion of data transfer to the application.

In the embodiment of the present invention, DDP #1 536 can be implemented for a plurality of applications, and the plurality of applications include a voice mobility control application 1 506, a device management application 15 04, a planning management application 15 02, and a voice mail/ The email transmission application 1 508, the device image management application 1510, the instant messaging application 15 12, etc., but are not limited thereto. In an embodiment of the invention, the plurality of applications can be divided into two groups. In the first group, multiple applications (eg, voicemail/email transmission application 158, device image management application 1510, instant messaging application 15 12, etc.) are applications that are easy to send large files. The DDP 153 6 can utilize the DDX module 15 14 to convert the file into smaller data packets that can utilize any other module within the DDP 1 5 36 including 1516, 1518, 1 522, and provide a successful transmission. The profile and inform the application of the guarantee of the completed transfer. In the second group, the plurality of applications (voice mobility control application 1 506, device management application 1 504, planning management application 1502, etc.) are generally applications that are easy to send smaller control messages. Usually, the application in the second group tends to control the application. In one example, the voice activity controller 1 506 can enable the mobile user and the mobility server to share an operative state that can be sent by a single DDP packet. Figure 16A is a diagram showing an example of how data within a mobile architecture configuration with DDP flows between an application user in a user device and an application server managed by the enterprise in one embodiment. Assume that the user on the user device wants to retrieve the voicemail from the voicemail server 1604 using the voicemail user 1 602. When a request from application user 1 602 is received, voicemail Φ server 1 604 can initiate a file transfer. Voicemail server 1 604 can send the file along path 1 65 0. When the file is received, the mobile server can prepare an active user to send the file to the user device via the secure channel. In one embodiment, the server DDX module 1 〇 8 within the mobile server can be used to convert the file into a format compatible with the control and transport protocols of the secure channel. In one example, the server DDX module 1 608 can convert a dual format file into a format that can be transmitted via a SIP protocol. Furthermore, the servo DDX module 1 608 can divide the file into multiple data packets to ensure the validity of routing the plurality of data packets via the secure channel. -70- 200820682 After completing the boot process, the server DDX module 16〇8 can send the first data packet to the server DDP 1 6 16 . In one embodiment, the server DDP 16 16 may include a DDPS module that is required by the application to encrypt the data packets. In one example, a simple data package (e.g., an instant message) can be sent without encryption. In another example, important data packets (e.g., confidential email) can be encrypted before being routed to the requester. From the server DDP 161 6 , the first data packet can be encapsulated as a φ SIP notification message (as shown in code example 3 70 of Figure 16B) and transmitted to the user device via the secure channel via the network 1 624. In one example, the first data packet can be sent via the secure channel by using the server SIP Control Protocol 1 620 and the Server UDP Transport Protocol 1 622. The first data packet is securely received by an active user of the user device that can receive the data packet via the user UDP transport protocol 1 626 and the user SIP control protocol 1 628. Within the mobile user, the user DDP 1 63 2 can receive the first data packet. User RDDP 1 634 can perform a similar check with φ performed by server RDDP 1614. Further, the user RDDP 1 634 can send a SIP notification message with a DDP answer to the server DDX module 1 608 via the security channel along path 1 652. By transmitting a DDP answer, the user RDDP 1 634 can send a guarantee from the mobile user to the mobile server that has received the data packet. Similarly, if the server RDDP module 1614 does not receive an RDDP answer, the server RDDP module 1614 will retransmit the data packet until the maximum number of packets has been successfully answered or the retry has been exhausted.

In an embodiment, the data packet will be sent and the next data packet will not be sent until a DDP response has been received. In one example, the server DDX module 1 608 does not send the second data packet until the -71 - 200820682 to DDP response has been received. In another embodiment, the number of fixed data packets can be sent, and no additional packets are sent until a response has been received for one or more of the initial data packets. In one example, the server D D X module 1 6 〇 8 can send a group of 1 〇 data packets and wait before receiving at least one response before being able to transmit additional data packets. Once the mobile user has sent a DDP response to the mobile server, φ encapsulates the routing data to the user DDX module 1636. In one example, the user DDX module 1 63 6 may retain the data packet before all data packets have been received. In one embodiment, the server DDX module 1 608 can send a message indicating that the data packet of the requested file has been sent and that there is no additional file data packet to the upcoming message. Once all data packets have been received, the user DDX module 1 63 6 will reorganize the file and notify the voice mail user 1 602 to utilize the voice mail profile. As can be seen from Figures 15 and 16, the DDP architecture provides a single secure channel for multiple application φ program users to interact with multiple application servers. By having data traffic through a single secure channel, the DDP architecture can provide control by ensuring that data packets are received, verified to be known to have received all data packets, and no loss of data packets. In an example, the DDP architecture allows large files to be divided into smaller data packets that can be sent with a guarantee that the receiving side receives the response. Figure 17 is a diagram showing an example of a telephone flow of how to establish a secure channel between a user device and a mobile server in an embodiment of the present invention. In the case of a real-72-200820682, in order to establish a secure channel, registration occurs. Assume that the user activates the user device for the first time. In a first step 1 724, a SIP registration must first be established. In an example, user SIP 1716 can send a SIP registration request via server UDP 1714. The SIP registration request can be received by the server SIP 1710 via the server UDP 1712. Upon receiving the SIP registration request, the server SIP 1710 can send a SIP registration response 1 726 to the user SIP 17 16 via the server UDP 171 2 and the user UDP 17 14. Once the SIP registration has been successfully completed, the steps to establish a secure DDP channel are initiated. In the next step 1728, the user DDPS module 1718 (the module of the user DDP 1720) will send a DDPS dialog request to the server DDPS module 1 708. In one example, the DDPS dialog request can be routed to the server DDPS module 1 708 via the user SIP 1716, user UDP 1714, server UDP 1712, server SIP 1710.

Upon receiving the DDPS dialog request, in a next step 1730, the server DDPS module 1 708 will send a DDPS dialog response through the server SIP 1710, the server UDP 17 12, the user UDP 1714, and the user SIP 171 6 Go to the user DDPS module 1718. Once a secure channel has been established, the user must register with the mobile server. In order to notify the user, the user 00?8 1718 can forward the 00?3 dialog response to the application user 1722. When receiving the notification, in the next step 1 732, the application user 1 722 sends a DDP registration request to the user. / Device Manager 1704. In the example of -73-200820682, the application user 1 72 22 can send registration information to the user DDP 1720. User DDP 1 720 can send registration via established secure channel (ie via user DDPS module 1718, user SIP 1716, user UDP 1714, server UDP 17 12, server SIP 1710, and server DDPS module 1 708). Information is passed to DDP 1 706, which then routes the registration information to the user/device manager 1704. When the registration information is received, in the next step 1 732, the user device manager 1 704 can send a DDP registration response to the application user. In one example, user device manager 1 704 sends a DDP registration response to server DDP 1 706. The server DDP 1 70 6 sends the registration information to the DDP 1 via the established secure channel (ie via the server DDPS 1 708, the server SIP 1710, the server UDP 1712, the user UDP 1714, the user SIP 1716, and the user DDPS 1718). 720, which then routes the DDP registration response to the user of application user 1 722. In an active architecture configuration with DDP, the registration can be a φ event. In one example, when the user device is first activated, the user device will register with the mobile server. Because the secure channel has been established at steps 428 and 430, the user of the user device can ensure that the transmitted sensitive registration information has been encrypted and passed through a secure channel. In one embodiment, no additional DDP registration is required as long as the secure channel between the user device and the mobile server is maintained. In one embodiment, the interaction between the application user on the user device and the application server managed by the enterprise can now be safely implemented via a single secure channel. Figures 18 and 19 illustrate an example of how DDP handles interaction between an application user on a user device and an application server managed by the enterprise. Figure 18 is a simplified telephone flow diagram of the case where a large file must be sent in one embodiment. Assume that the user device needs to download the latest software upgrade. In one example, the application user 181 4 sends a software upgrade request 1 8 1 6 to the image manager responsible for managing different software images on the server side 1 802 °

In a first step 1818, the application user 1814 sends a new image request to the image manager 1 802. In one example, a new image request is first sent from the user application 1 8 1 4 to the user DDP 1 8 1 0. After receiving a new image request, DDP 1 8 1 0 can send a request to server DDP 1 808 via the secure channel. Before being sent to the image manager 1 802, a new image request can be routed to the device/user manager 1 804 responsible for deciding which software to upgrade. After the device/user manager 1 804 has determined which software upgrade the user device requires, the device user/manager 1804 can route a new image request to the image manager 108. Upon receiving the request, the image manager 1 802 then sends the requested software upgrade (e.g., requested data 1802) to the server DDX module 1806. In one embodiment, the server DDX module 1 806 can convert the file into a format that can be transmitted via a secure channel established between the user device and the mobile server. In one embodiment, the server DDX module 1 80 6 divides the large file into multiple data packets for transport via a secure channel. In the next step 1 822, the server DDX module 1 806 can send the DDX file transfer start to the user DDX module 1 8 1 2 via the servo DDP 1 808 and the user DDP 1810. In one embodiment, the DDX file transfer start-75-200820682 means a notification between the server DDX and the user DDX that will send the file. The DDX file transfer start may include information such as the file name, the file size, and the number of data packets sent. Basic information about incoming files, such as applications that request files. In the next step 1824, the user DDP 1810 may send a DDX to begin responding to the server DDX 1 806. In an embodiment, the RDDP module within the DDP can send a DDX to start responding.

In the next step 1 826, the server DDX module 1 806 can send the first DDX data packet to the user DDX module 1812. As is generally illustrated in Figure 16, the DDX data message is first sent to the server DDP 1 808. In one embodiment, the DDX data message is encapsulated into a SIP notification message and sent over a secure channel via a SIP Control Protocol and a UDP Transport Agreement. On the user device, the DDX data message can be received by the user DDP 18 10, and then the user DDP 1810 can route the DDX data message to the user DDX module 1812 °. In the next step 1828, when the DDX data message is received, it will be sent by the user DDP 1810. DDP response. In one embodiment, the RDDP module within the user DDP 1810 will send a DDP response to inform the server that the DDX module 1 8 06 has successfully received the incoming DDX data message. Steps 1 826 and 1 828 are repeated steps that can be repeated until all DDX data packets and responses have been exchanged between the server and the user DDX module. Once the last DDX data message and the DDX response have been sent, in the next step 1 8 3 0, the server DDX module 1 806 will send the DDX file transfer to the application user 1 8 1 4 to notify the application user that the message has been sent. -76- 200820682 All DDX information messages. In one example, the DDX file transfer end can be sent from the server DDX module 1 806 to the server DDP 1 808 to the user device.

It can be received by the user £)?18 10 and the file transfer is over. In one embodiment, in a next step 1832, the RDDP of the user DDP 1810 can send a DDP response to the image manager 18〇2. At the same time, the user DDP 1810 can route the DDX file transfer to the φ user DDX module 1812, which will notify the application user 1814. As can be seen in Figure 18, it is not necessary to establish a new secure channel in order to request a software upgrade. Instead, the software server receives and processes requests for software upgrades without having to establish a new secure channel. It can also be seen that Figure 18 illustrates how the DDP architecture can be used to send data traffic in a secure and reliable manner, allowing the sender and requester to ensure that all data packets for the requested file have been successfully received. Figure 19 is a simplified telephone flow diagram of a case in which a small control message such as a sender of a control application φ can be transmitted in an embodiment of the present invention. In Figure 19, the interaction between the application user and the application server can occur without the DDX module. It is assumed that the user of the user device wants to share his or her user's presence (eg, available, busy, only phone, etc.). In a first step 1914, the user presence manager 19 10 on the user device can send the presence preference settings to the server presence manager 1 902. In an example, the user presence manager 1910 can send the presence preference (as a single DDP data packet) to the user DDP 1908, which then sends the presence preference to the server DDP 1 906 via the secure channel via -77-200820682. . When the attendance preference setting is received, in the next step 1978, the server DDP 1906 can send a DDP answer. In an embodiment, the RDDP module within the DDP can send a DDP response. At the same time, the server DDP 1 906 will notify the server presence manager 1902 via the device/applicator manager 1 904 regarding attendance preferences. Suppose the same user wants to find another instance of the attendance status of another user. In a first step 1 922, the user presence manager 1910 can send the presence enquiry 1920 to the user DDP 1908, which can send the presence enquiry to the server DDP 1 906 via the established secure channel. Upon receiving the presence inquiry, the server DDP 1 906 will forward a query via the device/user manager 1904 to the server presence manager 1 902, which can execute the requested query to retrieve the requested information. In the next step 1 92 8 , the server presence manager 1 902 can send the presence φ response (eg, the requested status profile) to the user presence manager 1910. In an example, the presence response can be sent from the server outreach manager 1902 to the server DDP 1 906 via the device/user manager 1 904. The presence response is then sent to the user DDP 1 908 via the secure channel, and the user DDP 1 908 then routes the presence response to the user presence manager 1910. As described above, Figures 18 and 19 illustrate how the DDP can be used to manage the user device. An example of the difference between the interaction between a plural data application and a plurality of application servers managed by the enterprise. Mobile Architecture with DDP -78- 200820682 Configure a single channel that allows each application user and application server to interact with each other. Furthermore, the DDP architecture delivers data traffic in a secure and reliable manner, enabling senders and requesters to ensure that all data packets for the requested file have been successfully received. Because the mobility architecture with DDP can now be the center of control, the mobility architecture with DDP now coordinates the various activities that users of the user's handset have previously managed individually. In one example, φ Figure 18 illustrates how the DDP can be used to manage the user experience on the user device, including software upgrades, device configuration, and user information management, but is not limited thereto. In another example, the DDP can manage the presence of the user by allowing the user to share their status (as shown in Figure 19), thus enabling the system to manage incoming traffic and allow others to see his or her status. . In another example, DDP can manage mobility by allowing users to roam from one data network to another, without having to worry about dialog management. As can be appreciated from the embodiments of the present invention, a mobile φ architecture configuration with DDP reduces the security risk by providing a single secure channel through which multiple applications on the user device can communicate with multiple applications on the enterprise server. A DDP is a diversity agreement that can be advantageously implemented regardless of hardware and/or software limitations. Furthermore, DDP is an adaptive protocol that can be controlled to utilize complex numerical control and/or transportation protocols. E. Divitas Protocol Agent (DPP) If the user of the application on the mobile phone directly accesses the enterprise resources, the enterprise firewall needs to be opened for multiple protocols. The method conceived in accordance with one or more embodiments of the present invention enables handset-based enterprise applications to use existing VoIP-related connections in a secure manner. The invention is implemented by conceiving a decentralized protocol agent. The decentralized protocol agent can be divided into two parts. Some of them are stationed on mobile phones along with VoIP users. The other part is stationed in the enterprise along with the VoIP server. As shown in Figures 7A-D, the handset-based VoIP user acts as a server for the different applications executed on the handset φ. This component uses existing VoIP-related connections (eg, SIP) to send application load across the enterprise. The server side agent component is responsible for disassembling the load and connecting to the actual enterprise server. The user and server side proxy components are further subdivided into multiple subcomponents. Each subcomponent is responsible for proxying an agreement. Figure 7A illustrates a network architecture in accordance with one or more embodiments of the present invention and each host includes two network interfaces. Two paths are provided via two separate networks, one from interface C0 to S0 and the other from C1 to S1. In SCTP, these two paths will be combined.

Divitas "weak users" use built-in power to monitor the combined path; when a path failure is detected, the agreement sends traffic through another path. The application does not have to know that a failed takeover restore has taken place. Failed takeovers can also be used to maintain network application connectivity. For example, assume a laptop that includes a wireless 802 interface and an Ethernet interface. A higher speed Ethernet interface is preferred when the knee-top computer is in its docking station; however, when the connection is interrupted (away from the docking station), the connection should be failed to take over to the wireless interface. When returning to the splicing station, the Ethernet connection should be detected and communication resumed via this interface -80-200820682. This is a strong and powerful institution that offers high availability and reliability. In accordance with one or more embodiments of the present invention, a multi-initiation plan is implemented to provide an application that is more usable than using a TCP person. Multiple start-up hosts have more than one network interface host, so they have more than one IP address that can address multiple start-up hosts. In TCP, a connection means a channel at both ends (in this example, a socket between two host interfaces). FIGS. 7B-D illustrate a weak interconnect with a server in accordance with one or more embodiments of the present invention. How the pairing of weak users can effectively establish a transport mechanism for transporting status information between the mobile phone and the server. Examples of e-mail applications (eg, SMTP) are illustrated using the SIP- NOTIFY method to tunnel application layer packets without knowing the SMTP application. The presence of the presentation layer encapsulation application on the user does not have to be changed to provide continuity of conversation.

Advantageously, mobile applications use the above approach to achieve enterprise security that is safer and easier to manage. This approach also enables VoIP vendors to extend their line of digital solutions to different enterprise applications. Features and advantages of the present invention will become more apparent from the following description and discussion. Figure 20 is a diagram showing an example of a conventional technique in which the various applications on the mobile phone are individually connected to the corresponding application server in the enterprise. The mobile phone 2000 may include a plurality of application users including Divitas User 2002, CRM (Customer Relationship Management) application user 2006 200820682, and mail application user 2008, but is not limited thereto. Applications Users can interact with each other independently or through an application protocol interface (API). In one example, application users 2006 and 2008 can interact with Divitas User 2002 through API 2010 and API 2012, respectively. Application users in Mobile Phone 2000 can interact with application servers in Enterprise 2090. The enterprise 2090 can include a plurality of application servers including, but not limited to, a Divitas server 2022, a CRM application φ program server 2026, and a mail application server 2028. Application servers can interact with each other independently or through APIs. In one example, application servers 202 6 and 2028 can interact with Divitas server 2022 via API 203 0 and API 2032, respectively. It is important to note that the purpose of the API is to enable applications to interact with each other. However, because the applications are independent of each other, the interaction through the API is arbitrary 假设 assuming that the stock broker on the mobile phone 2000 can communicate with its users via Divitas User #2002. Despite talking to their users, stockbrokers want to get their users' portfolios at their fingertips. In this case, the stock broker must establish two different conversations. Stockbrokers can establish a first conversation to enable them to talk to their users through Divitas users 2002. In order to mention the portfolio, stockbrokers can use CRM applications

The program user 2006 interacts with the CRM application server 2026 under the firewall 2040 located within the enterprise 2090 to establish a second conversation. In a typical Secure Sockets Layer (SSL) virtual private network (VPN) environment, network administrators must establish different configurations for each channel that has been established -82- 200820682. In order to establish two different conversations, two separate secure channels must be established. In one example, a new mail application user has been added to the phone. In order to communicate with a mail application server located within the corporate firewall, the network administrator must establish a new secure channel. Thus, in a typical SSL VPN environment, the user must establish multiple sessions that require multiple start communication commands and make the enterprise more vulnerable to security risks. The SSL VPN environment is not only inconvenient for users, but this environment type also requires more human resources to manage the security of the enterprise's network environment. To minimize the number of secure channels established, you can use the Internet Protocol (ίρ) Security Gateway instead of SSL. In an IP-secured VPN environment, one or more application users on the handset can interact with the application server through a secure channel across the IP security user 2014 and the IP security gateway 2030. In order to establish a secure channel, the user must first provide authentication information (eg, username, password, etc.). Once a secure channel has been established, the user is also responsible for the recognition of each time a different application user is utilized. In other words, each application user can be configured to communicate with its corresponding application server via a different IP address. In one example, the CRM application user 2006 wants to interact with the application server 202. If the secure channel 2084 has not been established, the user must first provide authentication information. Once the secure channel 2084 has been established, in order for the CRM application user 2006 to interact with the CRM application server 20 26, the user must provide additional authentication material. In addition, new secure channels and re-authentication must occur each time the session is interrupted. In an example, if the user is mobile during the conversation, then -83-200820682 If the connection is not visible, the user will be at risk of a sudden interruption from the conversation. For example, users connected via a Wi-Fi network will traverse the Wi-Fi network. The conversation will be interrupted and the user must establish another conversation, such as a cellular connection. As a result, the user is disturbed by the inconvenience of establishing a new conversation and is also frustrated by limited mobility. Providing a prior art Figure 2 1 illustrates how an application user interacts with an application server. 21 is a prior art flow diagram of a method for enabling an application user to communicate with an application server in an IP Secure VPN φ environment. Figure 2 1 discusses Figure 20. Assume that the user of the mobile phone 2000 wants to use the mail application user 2008 to send an email. In a first step 2 1 02, the email data traffic is sent to the application server. In one example, the mail application user 2 0 〇 8 can send an email data packet to the mail application server in the enterprise 2090 2028 ° -

In the next step 21 04, the electronic data traffic is received by an IP Security Client 2014 that can check to determine how to route traffic. In other words, the IP security user 20 14 can analyze the individual packets to determine if the packet is a packet that the enterprise 2090 wants. The IP Security User 2014 can identify the recipient of the packet by analyzing the IP address and the 璋 number in the packet. If the recipient of the email data traffic is not one of the plurality of application servers within the enterprise 2090, then in the next step 21 06, the IP security user 20 14 may discard traffic or may direct email traffic to the enterprise 2090. Inside the server. How to deal with applications that are not in the enterprise 2090 -84- 200820682 The server wants email traffic depending on how the IP security users 20丨4 group are configured to handle non-enterprise data traffic. If the IP security user 2014 determines that the data traffic is desired by the application server located within the enterprise 2090, then in the next step 2108, the IP security user 20 14 may encrypt the individual data packets before forwarding the data packet. Encrypting the processing of individual data packets requires that the mobile phone 2000 have sufficient CPU processing power. In addition, the requirement to encrypt individual data packets in an IP-secured VPN environment can create potential problems in voice communications such as voice over Internet Protocol (VoIP) communications. In other words, the speech quality during a voice communication session is severely degraded, resulting in poor voice communication experience (eg, echoes in the background, inaudible conversations, etc.). In the next step 2110, 1?86.111^7(:1丨6111: (1?secure user) 20 14 may send the encrypted traffic along the secure channel 20 84 to the desired application server. As described above, The secure channel must establish a secure channel each time a new application is utilized. In one example, IP security user 20 14 can send encrypted traffic to enterprise 2090's IP Security Gateway via network 2050 and firewall 2040 (IP security) The gateway device 2030. In the next step 2112, the IP security gateway 2030 performs a check to determine how to route traffic. Similar to the IP security user 20 14 , the IP security gateway 2030 analyzes each packet to determine if the packet is a business. If the received data packet is not an encrypted IP security packet, then in the next step 21 14 the IP security gateway 2030 discards the packet. If the data packet is an encrypted IP security packet, then the next packet is In step-85-200820682 21 16, the IP security gateway 20 30 can decrypt the traffic. Once the packet is unsealed, the IP security gateway 2030 analyzes the packet to identify the IP address of the received application server and In the next step 2118, the IP security gateway 2030 forwards the data packet to the appropriate application server (e.g., mail application server 202 8). Step 2 1 02 to 2 1 1 8 The method is continuous processing and is performed for each packet received by the application user.

There are several disadvantages to the prior art. In one example, different configurations must be performed for each new application user added to the user's handset. When new application users are added, the management of various application users and their corresponding application servers leads to a more complex relationship-building network environment, which is costly to maintain. Furthermore, the user must be responsible for performing multiple certifications, thus requiring the user to remember the multiple authentication materials. In addition, the benefits of operating within an IP-secured VPN environment are reduced due to the need to encrypt data traffic, resulting in increased hardware costs (eg, handsets must have sufficient CPU processing power) and increased latency. In addition, the user is frustrated by the limited mobility provided, and each time the conversation is interrupted, the user must re-establish the connection and re-authenticate. In one aspect of the present invention, the inventors herein implement a prior art architecture configuration that integrates multiple authentications and/or multiple secure channels to create an environment in which a single communication command is initiated. In other words, the inventors realized that by composing each application to direct its data traffic via a single application (eg, Divitas user) and a single server (such as 'Divitas server), the resources from multiple applications -86- 200820682 Material traffic can be sent through a single secure channel without requiring the user to perform multiple authentications. In addition, the loss of dialogue can be significantly reduced without sacrificing mobility. In accordance with an embodiment of the present invention, a mobile architecture configuration is provided by implementing a Divitas Protocol Proxy Servant (DPP). In an embodiment, the DPP includes a user DPP and a server DPP. In an embodiment of the invention, the handset may include an active user (eg, a φ Divitas user, which may include a user DPP to manage connectivity between the handset and the mobility server (eg, Divitas server). In the present invention In an embodiment, the mobility server may include a server DPP to manage connectivity between the mobility server and the handset. In an embodiment of the invention, the user and server DPP may include a plurality of sub-users/server DPPs. In the embodiment of the present invention, DPP can establish a single secure channel from each application user and its corresponding application server. Because φ each application is positive Routing their data traffic via a common DPP' so DPP can now manage connectivity between mobile phones and mobile servers. Connectivity information can include establishing a connection between a mobile phone and an active server via a control protocol such as SIP (Dialog Initiation Protocol) The safe channel can be used to determine when and how to connect the phone. In addition, the connectivity information can also include when Communication from one network to another (eg, from a Wi-Fi network to a cellular network) enables seamless transition between different networks. See the following diagram and discussion for a better understanding of this Features and advantages of the invention - 87 - 200820682 Figure 2 2 is a simplified block diagram of a mobile architecture configuration in an embodiment of the present invention. In the mobile architecture configuration 2200, the mobile phone 22 02 and the Divitas server in the enterprise 22 6 2218 (eg, an active server) interacts. The handset 2202 can include a Divitas user 2204 (eg, an active user) and a plurality of application users (2206 and 2208). In an embodiment of the invention, the Divitas user 2204 can include a user. DPP manages connectivity between mobile phones and mobile servers.

Unlike conventional techniques, application user 220 6 and application user 2208 are not configured to interact directly with their corresponding application servers (2220 and 2222). In one embodiment, instead, various different configurations for individual application users can be simplified to direct all data traffic to a single regional IP host 22 10 associated with Divitas User 2204 (eg, 127.0 · 0· 1 IP address). In other words, data traffic from application users 220 6 and 2208 can now be configured to be routed to Divitas User 2204 via APIs 2212 and 2214. From Divitas User 2204, all data traffic can then be routed through the network 2224 (e.g., the Internet) via the intranet 2216 Divitas Server 221. In an embodiment of the invention, Divitas server 2218 may include a server DPP to manage connectivity between the handset and the mobility server. Once the Divitas server 2218 has received the data traffic, the [j Divitas server 2218 can properly route traffic to the corresponding application server (2220 and 2222) via the API (2 23 2 and 22 3 4). The user wants to send an email by using the application user 2206. Since the application user 22 06 has been configured to send all data traffic to the regional host 22 1 0 by the group -88-200820682, the data traffic from the application user 2206 is sent to and through the API 2212.

Div it as user 22 04 associated zone IP host 221 0.

When receiving traffic from application user 2206, Divitas User 2204 can use Divitas Data Exchange (DDX) to encapsulate traffic within the SIP Notify Message. As discussed herein, DDX refers to a protocol used to transfer data packets between a handset and a server. When encapsulating a data packet, DDX adds a new tag that adds information about the application user who sent the data traffic. Unlike conventional techniques, all data packets are not encrypted. Instead, the data packet is encrypted depending on the preferences specified by the application user. In an embodiment of the invention, the newly added DDX is encrypted. Once the data packet has been encapsulated within the SIP Notify Message, the encapsulated data packet is now forwarded to the Divitas server 221 8 along the secure channel 2250 including the traversing network 22 24 . It should be noted that if the enterprise is protected by one or more security modules (eg, firewall 222 6), the data packet must also traverse one or more security modules. Once the data packet has been received by the Divitas server 2218, the Divitas server 2218 can utilize the DDX tag to retrieve the location of the application server. In an example, the DDX tag can include an identification number (eg, MAC address, 埠 address) that indicates which application server (eg, application server 2 2 2 0) in the enterprise is desired. Data Packet Recipient In one embodiment, the mobility architecture configuration manages connectivity between the handset and the mobility server. In an embodiment, the mobile architecture configuration may utilize control protocols utilized by general handsets such as SIP. In a mobile architecture configuration, in order to establish a secure channel, the user must only perform a manual authentication. In other words, once an AI female full channel has been established between the mobile phone and the mobile server, it is not necessary for each application user (22 06 and 220 8) to interact with the application server (2220 and 2222). Establish another secure channel.

In an embodiment, the mobile architecture configuration may also include a database that includes authentication material for each application user. Thus, each time a different application user is utilized, in one embodiment, the mobility architecture configuration can utilize the application specific credentials stored in the database to automatically authenticate the user. From the user's point of view, the mobility architecture configuration is essentially a single start communication command environment. Advantageously, the mobility architecture configuration generally makes time and effort efficient, and network managers must spend on assembling individual application users. Network administrators can largely eliminate this process by assembling individual application users to interact with the regional host, instead of adding a new application each time a user has to establish a new secure channel to the phone. In addition, with a single start communication command, network managers can substantially reduce the time and cost associated with managing security. The mobile architecture configuration can be implemented as a rich or weak user. Figure 23 is a block diagram showing the configuration of an active architecture as a rich user in an embodiment of the present invention. As discussed in this article, rich users mean that user DPP and server DPP not only manage a variety of different applications but also provide support to at least one or more application user functions (eg, voice application users, Mobile architecture configuration for instant messaging application users, email application users, etc.). Suppose, for example, the user of the mobile phone 23 02 wants to retrieve the mail application server 2326 from the enterprise 231 8 by using the mail application user 23 1 (eg, Microsoft® Outlook, etc.) (eg, Micir〇S〇ft® The case of the email of ExChaiige server, etc.). Along with Figure 24 - and Figure 23 will be discussed. φ Figure 24 is a simplified flow diagram illustrating an example of a method for configuring with an active architecture in an embodiment of the present invention. In a first step 2402, the application user sends data traffic to the regional host of the Divitas user. In the mobile architecture configuration, the application user 2310 has been configured to route its data traffic via the regional host 23 08 located within the Divitas user 2304. In one example, application user 2310 can send an SMTP (Simple Mail Transfer Protocol) data package 2312 to Divitas User 2304 over TCP-IP. The SMTP data packet 2 3 1 2 can be received by the SMTP proxy user 23 06 (e.g., sub-user DPP) located in the Divitas user 2304 φ. In an embodiment, the user DPP may include a plurality of sub-user DPPs. The type of proxy user used to process data traffic depends on the type of application user. In an embodiment of the invention, the data packet includes a UI number unique to the application user. In one example, the SMTP data packet 23 12 includes the following data 127.0.0.1/25. In this example, the number 127.0.0.1 is the IP address unique to the regional host 23 08, and the number 25_ indicates the 埠 number associated with the SMTP proxy user 236 in this example. -91 - 200820682 In the next step 2404, the data traffic can be encapsulated as a SIP Notify Message with a DDX tag. In other words, when receiving the data packet 23 12, the Di vitas user 23 04 reformats the SMTP data packet 23 3 0 into a SIP data packet 2330 (such as SIP Notify Message, etc.) that can be transmitted via a control protocol such as a SIP handset. In an embodiment of the invention, SIP data packet 233 includes a source data packet (e.g., data packet 2312) having a DDX header 233a and a SIP header 2330b. As above φ, the DDX header includes a unique identification number unique to the application server. In an embodiment of the invention, a unique identification number can be generated based on the 埠 number included in the SMTP data packet. In an embodiment of the invention, additional indicia may be included in the formatted data packet to identify how the formatted data packet is transported. In an example, the transport agreement tag 2330c can be a UDP-IP transport tag. In an embodiment of the invention, one or more portions of the SIP data packet 23 30 may be encrypted. In an embodiment, the DDX portion is encrypted even if the remaining portion φ of the data packet is not encrypted. In the next step 2406, the Divitas user can send a data packet to the Di vitas server. Once the data packet 23 12 has been reformatted into a SIP data packet 23 3 0 (eg, encapsulated as a SIP Notify Message), it can pass through the secure channel 2 3 5 0 via the network 2 314 and/or the firewall. 2316 sends a SIP data packet 2330 to the Divitas server 2320. In the next step 2408, the Divitas server can check to determine if the incoming data packet is a SIP Notify Message. If the incoming data packet is not a SIP Notify Message, then in the next step 2410, the data packet may be discarded at -92-200820682. However, if the incoming data packet is a SIP Notify Message, then in the next step 24 12, the Divitas server can check the expected proxy server by checking the DDX flag. In one embodiment, the Divitas server must decrypt the DDX packet to read the information stored in the DDX packet. In one example, the Divitas server 2320 knows the routing data packet 23 3 0 to the SMTP proxy server φ 2322 based on the unique identification number in the DDX tag. In an embodiment of the invention, the server DPP may comprise a complex sub-server DPP. In an embodiment of the invention, the type of proxy server that handles incoming traffic is dependent on the type of data traffic. In the next step 24 1 4, the data packet can be routed to the proxy server. Since the SIP data packet 23300 is an SMTP data packet, the formatted data packet (e.g., sub-server DPP) is processed by the SMTP proxy server 2322 located inside the Divitas server 2320. In the next step 24161, the data packet is routed to the intended application φ server. In an embodiment of the invention, the SMTP proxy server 23 22 can convert the SIP data packet 2330 into a format acceptable to the application server. In one example, SIP data packet 2330 can be converted from SIP Notify Message to SMTP data packet 2328. In addition, the DDX part can be discarded. In addition, the transport protocol can be changed from UDP-IP to TCP-IP, which is more conducive to deploying email data traffic to the respective application server via API 2332 (eg, mail application server 2326). The method steps are not shown in the encryption of the data packet and / or -93- 200820682 decryption. In an embodiment, the data packet can be sent without encryption. The requirements for encryption are arbitrary and can be determined by the user's requirements. In an embodiment, some or all of the data packets may be encrypted. In one embodiment, the DDX portion may be encrypted while leaving the remainder of the data packet unencrypted. Undesired encryption reduces the processing power to be utilized and reduces the underlying factors typically associated with encrypted data packets. As can be seen from Figures 23 and 24, in general, the rich mobility architecture configuration can be used as an mobility manager that enables mobile phone application users to interact with the application server within a single communication command environment. In addition, rich mobility architecture configurations can include data packets from various applications to be converted into data packets that can be transported by control protocols and transport agreements specific to established secure channels. In an embodiment of the invention, as shown in Figure 25, the mobility architecture configuration can be implemented as a weak user. In a weakly mobile architecture configuration, the user DPP and the server DPP can only be utilized as an mobility manager (eg, to manage the connectivity of the application) and provide no support for at least one or more application functions. . Suppose, for example, that a user of the mobile phone 2500 wants to call a friend. Users can make calls using the phone application user 2508 (eg, VoIP, etc.). In this example it is assumed that a secure channel 2550 has been established between the Divitas user 2502 and the Divitas server 2518 located within the enterprise 2530. To establish a telecommunications conversation, the telephony application user 2508 can send a data packet 2512 (e.g., SIP/UD-IP) to the regional host 25 10 within the Divitas user 2502. As mentioned above, multiple proxy users can reside in Divitas users -94-200820682 2502 to support a variety of different application users. In one example, SIP proxy user 2504 can be located within Divitas user 2502 to process data packets from telephony application user 258. Upon receiving the data packet 2512, the SIP proxy user 2504 can analyze the data packet to determine how to route the packet. As mentioned above, the data packets that can be sent to Divitas users can include the application server-specific 埠 number (eg, 5 060, etc.). Using this information, the &3 user 2502 can route the data packet 2512 to the Divitas server 2518 via the network φ 2514 and the firewall 2528. In an embodiment, if the data packet is already in a Divitas user routable format, then There is no need to convert the data packet. In one example, the data packet 2512 is shown in the 31?/11〇?-1 format, which is the format that the &3 user 2502 can use to route its data traffic. In an embodiment, the plurality of proxy servers can reside within the Divitas server. In an example, the SIP proxy server 2532 can reside in the Divitas server 25 18 to manage the data φ traffic coming in from the phone application user 258 because the data packet 25 12 has been sent from the phone application user 25 0 8 . Therefore, the data packet is processed by the SIP proxy server 25 32. When receiving the data packet 2512, the SIP proxy server 2532 can forward the data packet 25 12 to the destination telecommunications device (e.g., telephone, etc.) along the path 2522 via the telephone gateway 2520 (e.g., PSTN, GSM, CDMA, etc.). . Once a telecommunications conversation has been established between the handset 2500 and the destination telecommunications device, other data packets 2530 (e.g., RTP data packets, etc.) sent by the telephony application user can be sent to the Divitas servo along the path 2560 via the secure channel 2550. 2518 ' without having to go through D ivitas user 2 5 0 2 . -95- 200820682 In a weakly mobile architecture configuration, the purpose of establishing a telecommunications conversation with the help of Divitas users is to enable application users to take advantage of the mobility features of Divitas users. In other words, a control center has been established between the Divitas user and the Divitas server to monitor the connectivity of the application user. By establishing this relationship, the D i v i t a s user and the D i v i t a s server can share their connectivity status when the situation occurs, and can handle roaming seamlessly.

In the example, the users in the above case are currently connected via a Wi-Fi network. During a phone conversation, users can roam outside the Wi-Fi network. In the prior art, the connection may be interrupted and the user must redial. However, in a mobile architecture configuration, the connectivity status of the user's handset has been monitored, and Divitas users and Divitas servers can perform seamless network exchanges (eg, from Wi-) without the user being aware of the changes. Fi to the cellular network). Advantageously, companies that have invested a large amount of money into multiple applications and only need an mobility manager can implement a weakly mobile architecture configuration. In this way, organizations can leverage the mobility manager-configured mobility manager performance without having to re-engineer their telecommunications infrastructure. As can be appreciated from embodiments of the present invention, an active architecture configuration with DPP provides an mobility manager that enables a smooth telecommunications infrastructure. In other words, the mobile architecture configuration provides a single environment for starting communication commands. In the example, a single secure channel can be used to achieve the same functionality to replace multiple secure channels of the enterprise. With an environment that starts with a single communication command, the cost and effort of managing a telecommunications infrastructure can be significantly reduced. In addition, the mobility architecture -96-200820682 configuration can monitor and seamlessly handle connectivity without negatively impacting the user's telecommunications experience. F. CONCLUSION Although the invention has been described in terms of several preferred embodiments, modifications, changes, and equivalents are possible within the scope of the invention. It should also be noted that there are many other ways of implementing the methods and apparatus of the present invention. Moreover, 'φ can find the utility of the embodiments of the present invention in other applications. For the sake of convenience, this article provides abstract commemoration, which is limited to the convenience of reading and is not intended to limit the scope of patent application. Accordingly, the scope of the appended claims should be construed as including all such modifications, alterations, and equivalents of the true spirit and scope of the invention. BRIEF DESCRIPTION OF THE DRAWINGS The present invention is illustrated by way of example only, and not by way of limitation System network diagram. 2A-C are diagrams of actuating servos in accordance with one or more embodiments of the present invention. 3 is a mobile device user diagram in accordance with one or more embodiments of the present invention. 4 is a block diagram of an encoder/decoder based echo canceller in accordance with one or more embodiments of the present invention. FIG. 5A is a pictorial diagram of a speech hopping slow-97-200820682 in accordance with one or more embodiments of the present invention. Figure 5B is a diagram of a speech jitter buffer in accordance with one or more embodiments of the present invention. Figure 6A is a schematic diagram of a DDP architecture in accordance with one or more embodiments of the present invention. Figure 6B is a diagram of a DDP message exchange in accordance with one or more embodiments of the present invention.

7A is a network architecture diagram of each host including two network interfaces and fabricated in accordance with one or more embodiments of the present invention. Figure 7B is a diagram of a network architecture made in accordance with one or more embodiments of the present invention. Figure 7C is a diagram of a network architecture made in accordance with one or more embodiments of the present invention. Figure 7D is a diagram of a network architecture made in accordance with one or more embodiments of the present invention. Figure 8A is a block diagram of an exemplary prior art communication device including an echo cancellation filter. Figure 8B is a flow diagram of an exemplary conventional technique communication device for use in, for example, the exemplary prior art communication device illustrated in Figure 8A. Figure 9A is a block diagram of a communication device (or system or configuration) that cancels echoes without relying on a filter, in accordance with one or more embodiments of the present invention. Figure 9B is a block diagram of an ID code generator for the communication device (or system or configuration) of Figure 9A, in accordance with one or more embodiments of the present invention. Figure 9C is a flow diagram of a method for canceling echoes, such as the communication device (or system or configuration) of Figures 9A-98-200820682, in accordance with one or more embodiments of the present invention. Figure 10A is a block diagram of a first exemplary conventional technology packet voice communication system (first prior art configuration) with an adaptive jitter buffering scheme. Figure 10B is a flow diagram of transmitter side processing for a conventional technique bounce buffering scheme, such as the first prior art configuration shown in the example of Figure 10A.

FIG. 1C is a flow chart of a conventional technique delay calculation process. Figure 10D is a flow chart of a conventional technology packet implementation control process. Fig. 10E is a schematic diagram showing the flow of the received packet in the packet implementation control when the transmitter side voice activity detector (VAD) is turned on. Fig. 10F is a schematic diagram showing the flow of the received packet in the packet implementation control when the VAD on the transmitter side is turned off. Figure 11 A is a block diagram of a receiver-side device that includes adaptive buffer overflow control, a packet voice communication system (second prior art configuration). Fig. 11B is a flow chart for the silent detection processing of the receiver side device shown in the example of Fig. 11A. Fig. 1 1 C is a flowchart of a buffer overflow control process for the receiver side device shown in the example of Fig. 1 1 A. Figure 1 2A is a block diagram of a receiver side device having an adaptive jitter processing packet voice communication system in accordance with one or more embodiments of the present invention. Figure 12B is a diagram of a -99-200820682 delay insertion control process utilized for adaptive jitter processing of a receiving side device such as the one shown in the example of Figure 1 2A, in accordance with one or more embodiments of the present invention. Figure 13 is a block diagram of a receiver side device of a packet voice communication system with adaptive jitter processing in accordance with one or more embodiments of the present invention. Figure 14 is a diagram showing an example of a conventional technique for establishing a connection between an application user and an application server. Figure 15 is a simplified block diagram of the DDP invention of the embodiment of the present invention. Figure 1A is a diagram showing an example of how the data within the mobile architecture with DDP in the embodiment flows between application users located within the user device and application servers managed by the enterprise. Figure 16B is a diagram showing an example of a code of a packaged SIP notification message in the embodiment. Figure 17 is a diagram showing an example of a telephone flow illustrating how to establish a secure channel between a user device and a mobile server in the embodiment. Figure 18 is a simplified telephone flow diagram illustrating the case where a large file must be transmitted in the embodiment.

FIG. 19 is a flow chart of a simple telephone in which an example of a small control message such as a sender sent by a control application can be sent in an embodiment of the present invention. FIG. 20 is a diagram for individually connecting individual applications on a mobile phone to an enterprise. A diagram of a prior art example of an architectural configuration of an application server. Figure 21 is a prior art flow diagram of a method for enabling an application user to communicate with an application server in an IP Secure VPN environment. Figure 22 is a block diagram showing the configuration of the mobile architecture in the embodiment of the present invention - 100 - 200820682 Figure 23 is a block diagram showing the configuration of the mobile architecture in the embodiment of the present invention as a heavy load client. Figure 24 is a simplified flow diagram of an example of a method of configuring using an active architecture in an embodiment of the present invention. Figure 25 is a diagram of a mobile architecture configuration implemented as a lightly loaded client in an embodiment of the present invention. Φ [Description of main component symbols] 100: System network 102: Mobile equipment 1 1 〇: Honeycomb network 1 1 2: Base transceiver station 1 1 4 : BTS switching center 1 16 : Mobile switching center 120: Media gateway φ 122 : public switched telephone network 1 2 4 : conventional public and private telephone 130: private branch switch 132 : router 1 3 6 : telephone 137 : telephone 1 3 8 : internet protocol wide area network 140 : router 142 : firewall -101 - 200820682 144: Internet 150: Mobility Server 160: Access Point 1 800: Access Point 800: Conventional Communication Device 802: Signal Receiver 806: Speaker

8 0 8 : echo path 810 : microphone 8 1 2 : buffer 8 1 4 : filter 8 1 4 : echo canceller 8 1 6 : sum function 9 0 0 : communication device 904 : signal receiver 906 : background noise Remover 908: echo path 9 1 0 : identification code injector 914 : speaker 9 16 : microphone 922 : identification code generator 924 : identification code detector 926 : buffer 928 : retarder 200820682 930 : sum function 932 : signal Transmitter 1〇〇〇: Speed buffer 1001: Voice activity detector 1 002: Transmitter 1 003: Network 1 0 0 4: Packet buffer φ 1 005: Packet implementation controller 1 006: Delayed insertion controller 1 007 : Delay information module 1 008 : Bounce computer 1 009 : Implementation delay computer 1 080 : Voice packet 1 080a : Packet 1 082 : Silent descriptor φ 1084 : Silent 1 0 8 6: 苜 packet 1086a: packet 1 088 : Silent 1 090 : Silent Descriptor 1091 : Transmitter Side Device 1 092 : Receiver Side Device 1 092a : Voice Packet 1 094 : Silent Packet 200820682 1 096 : Voice Packet 1 098 : Silent Packet 1100 : Receiver Side Device 1 102 : Packet Buffer 1104: Packet Implementation Control Controller 1108: Delay Insertion Controller 1 1 1 〇: Bounce Computer φ 1 1 1 4 : Buffer Overflow Controller 1 1 1 6 : Silent Detector 1 1 1 8 : Decoder 1 1 8 0 : Add-on 1 199 : Link 1 200 : Receiver side device 1 202 : Packet buffer 1204 : Bounce computer φ 1206 : Implement delay computer 1 208 : Packet implementation controller 1 2 1 0 : Decoder 1 2 1 2 : Silent detection 1214: Delay Insertion Controller 1216: Delay Information Module 1 299: Link 1 300: Receive Side Device 1 3 02: Packet Buffer 200820682 1 304: Bounce Computer 1 3 06: Compensated Computer 1 3 0 8: Packet Implementation Controller 1 3 1 0 : Decoder 1 3 1 2 : Video Detector 1 3 1 4 : Compensation Controller 1 3 1 6 : Link Compensation Information Module

1 402 : Application Server 1 404 : Application User 1 406 : Software Download 1424 : Notification 1 5 02 : Planning Management Application i 504 : Device Management Application 1 5 06 : Voice Mobility Control Application User φ 1 508: Voicemail/Email Transfer Application 1 5 1 0 : Device Image Management App 1 5 1 2 : Instant Messaging App 1 5 1 4 : David Data Exchange Module 1 5 1 6 : Reliable David Description Protocol Module 1 5 1 8: Priority Message Scheduling Module 1 520: Built-in Dialogue Management Module 1 5 22: Davista Description Protocol Module with Security Extension 1 524: Control Protocol -105- 200820682 1 526: Transmission Control Protocol 1 528: User Data Meta-Constellation 1 5 3 0: Transmission Control Protocol 1 5 32: Session Initiation Agreement 1 534: User Data Meta-Consistency 1 5 3 6 : Davide describes Agreement 1 602: Voice Mail User φ 1 604: Voice Mail Server 1 608: Server Davis Data Exchange Module 1 6 1 4 : Server Reliable Davie He describes the protocol module 1 6 1 6 : Server David describes the agreement 1 620: Server Session Initiation Protocol Control Agreement 1 622: Servo Server User Data Meta-Consultation Transfer Protocol 1 624 · Network 1 626: User User Data Meta-Contract Transfer Protocol φ 1 62 8 : User Dialogue Startup Protocol Control Agreement 1 632: User Davide describes Agreement 1 634: User Reliable Davies Description Protocol 1 63 6: User Davis Data Exchange Module 1 650: Path 1 652: Path 1 700: Enterprise Server 1 702: User Device 1 704: User/Device Manager -106- 200820682 1706: David describes the agreement 1 708: decentralized data processing system 1 7 1 0: dialog initiation agreement 1712: user data meta-association 1 7 1 4: user data meta-association 1 7 1 6 : dialog initiation agreement 1 7 1 8 : Decentralized data processing system

1 720: David describes the agreement 1 722: Application User 1 802: Image Manager 1804: Device/User Manager 1 8 06: Server David Data Exchange Module 1 808: Server David describes it Agreement 1 8 1 0: User David describes the agreement 1 8 1 2: User David Data Exchange Module 1 8 1 4: Application User 1 8 1 6: Request 1 902: Server Attendance Manager 1 904: Device/User Manager 1 906: Server Dave He describes the agreement 1 9 0 8: User David describes the agreement 1 9 1 0: User attendance manager 1 920: Attendance inquiry 2000: Mobile-107 - 200820682 2002: David He User 2006: Customer Relationship Management Application User 2008: Mail Application User 2010: Application Agreement Interface 2012: Application Agreement Interface 2014: Internet Protocol Security User 2022: David Server

2026: Customer Relationship Management Application User 2028: Mail Application Server 2030: Internet Protocol Security Gateway 2030: Application Agreement Interface 2032: Application Agreement Interface 2040: Firewall 2050: Network 2 0 8 4: Security Channel 2090 · Enterprise 2200: Mobile Architecture Configuration 2202: Mobile 2204: David User 2206: Application User 2208: Application User 2210: Regional Internet Protocol Host 22 12: Application Protocol Interface 2214: Application Agreement Interface -108- 200820682 2216: Enterprise 2218: David Server 2220: Application Server 2222: Application Server 2224: Network 2226: Firewall 2232: Application Agreement Interface

2234: Application Protocol Interface 2250: Secure Channel 2302: Mobile 23 04: David He Seto 23 06: Simple Mail Transfer Protocol Proxy User 2 3 0 8: Zone Host 23 10: Mail App User 23 12: Simple Mail Transfer Protocol Data Packet 2314: Network 23 16: Firewall 2 3 1 8 · Enterprise 23 20: Dai also Serving the Moon 2 322: Simple Mail Transfer Protocol Proxy Server 2326: Mail Application Server 23 28: Simple Mail Delivery Agreement Data Packet 2330: Dialogue Startup Protocol Data Packet 23 30a: David Data Exchange Header -109- 200820682 2330b: Session Startup Protocol Header 23 3 0c: Transport Agreement Mark 23 32: Application Agreement Interface 23 5 0: Security Channel 2 5 0 0: Mobile 2502: David User 2504: Dialogue Startup Protocol Proxy User 0 2508: Telephony Application User 2 5 1 0: Zone Host 25 12: Data Packet 2514: Network 2518: David Server 2520: Telephone Gateway 2 5 2 2: Path 2528: Firewall φ 2 5 3 0: Enterprise 2532: Session Initiation Protocol Proxy Server 25 50: Secure Channel 25 52: Application Protocol Interface 2560: Road 2562: immediate agreement - X: signal y ': signal y 1: signal -110- 200820682 Z: Signal

-111 -

Claims (1)

200820682 X. Patent application scope 1. A packet communication device, comprising: a detector, configured to detect characteristic content in an incoming packet received by the packet communication device; and implementing a controller, configured to be If the detector has detected the characterization content in the incoming packet, performing an adjustment of the incoming packet to generate an adjusted packet and output the adjusted packet. 2. The packet communication device according to claim 1, wherein the characterization content indicates silence in voice communication. 3. The packet communication device according to claim 1, wherein the characterization content represents at least one of a critical amount of movement and no movement in the video communication. 4. The packet communication device of claim 1, wherein the adjustment of the incoming packet comprises inserting a delay into the incoming packet. 5. The packet communication device according to claim 1, wherein the adjustment of the φ incoming packet comprises stopping the implementation of the incoming packet while repeatedly performing the packet received by the packet communication device earlier than the incoming packet. The packet communication device according to claim 1, wherein the detector is additionally configured as a setting flag to indicate at least one of the presence and absence of the characterization content in the incoming packet, and the The implementation controller is additionally configured to perform the adjustment of the incoming packet if the flag indicates the presence of the characterization content in the incoming packet. 7. The packet communication device according to claim 1 of the patent application, further comprising a computer-112-200820682, which is configured to calculate the amount of the adjustment of the incoming packet, wherein the adjustment of the incoming packet is performed according to the amount . 8. The packet communication device according to claim 1 of the patent application, further comprising an adjustment controller configured to determine a timing of the adjustment of the incoming packet according to an output of the detector, wherein the timing is performed according to the timing This adjustment to the incoming packet. 9. The packet communication device according to claim 8 of the patent application, further comprising a direct link, which is configured to connect the adjustment controller and the detector. 10. The packet communication device according to claim 8 of the patent application scope, further comprising: a computer configured to calculate the amount of the adjustment of the incoming packet; and an information module configured to combine the timing and the quantity The adjustment information for the adjustment of the incoming packet, wherein the adjustment of the incoming packet is performed according to the adjustment information. 11. According to the packet communication device of claim 1 of the patent application, the package Φ includes a packet buffer, which is configured to buffer the incoming packet before the detector receives the incoming packet. 12. The packet communication device according to claim 1 of the patent application, further comprising a decoder configured to decompress the incoming packet before the detector receives the incoming packet. 13. The packet communication device of claim 12, wherein the decoder is additionally configured to decompress the adjusted packet. 14. The packet communication device according to claim 1 of the patent application, which represents a user device. -113- 200820682 1 5 - A packet communication device according to claim 1 of the patent application, which represents at least one of a telephone, a mobile phone, a teleconferencing device, a videophone, an audio player, and a video player. The packet communication device of claim 1, wherein at least one of the detector and the implementation controller is included in a software downloaded to the packet communication device. 17. A packet communication device according to claim 1 of the scope of the patent application, which represents a server device in a packet communication network. A method for performing packet communication, comprising: receiving a incoming packet using a communication device; using the communication device to test the characterization content in the incoming packet; and if the characterization content is detected in the incoming packet And using the communication device to adjust the incoming packet to generate an adjusted packet and output the adjusted packet. 1 9. The method according to claim 18, wherein the characterization content represents silence in voice communication. 20. The method according to claim 18, wherein the characterization content is lower than in the video communication. At least one of the critical amount of movement and no movement. 21. The method according to claim 18, wherein the adjustment comprises inserting a delay into the incoming packet ° 2 2 · according to the method of claim 18, wherein the adjustment is included in the repeated implementation than the incoming packet Stop receiving the incoming packet as soon as it is received. -114- 200820682 2 3. The method according to claim 18 of the patent application 'individually includes using the communication device setting flag to indicate at least one of the presence and absence of the characterized content in the incoming packet' Where the flag indicates the presence of the characterization content in the incoming packet, the adjustment is performed. 24. The method according to claim 18, wherein the method further comprises calculating the amount of the adjustment using the communication device, wherein the adjustment is performed according to the amount 25. The method of claim 18, further comprising determining the timing of the adjustment based on the result of the detecting, wherein the adjusting is performed based on the timing. 26. The method of claim 18, further comprising: calculating the adjustment; and synchronizing the timing and the amount into adjustment information for the adjustment, wherein the adjusting is performed based on the adjustment information. 27. According to the method of claim 18, the communication device is used to buffer the incoming packet before the detection of φ. 28. The method of claim 18, further comprising decompressing the incoming packet using the communication device prior to the detecting. 29. The method of claim 28, further comprising decompressing the adjusted package. The method of claim 18, wherein the communication device represents a user device. 3 1 . The method of claim 18, wherein the communication device represents at least one of a telephone, a mobile telephone, a teleconferencing device, a video telephone, an audio-115-200820682 player, and a video player. 32. The method of claim 1S, further comprising downloading, to the communication device, software that performs the detection and at least one of the adjustments. 33. The method of claim 18, wherein the communication device represents a server device in the packet communication network. -116-