TW200820682A - Content-based adaptive jitter handling - Google Patents
Content-based adaptive jitter handling Download PDFInfo
- Publication number
- TW200820682A TW200820682A TW096121020A TW96121020A TW200820682A TW 200820682 A TW200820682 A TW 200820682A TW 096121020 A TW096121020 A TW 096121020A TW 96121020 A TW96121020 A TW 96121020A TW 200820682 A TW200820682 A TW 200820682A
- Authority
- TW
- Taiwan
- Prior art keywords
- packet
- user
- server
- communication device
- application
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M9/00—Arrangements for interconnection not involving centralised switching
- H04M9/08—Two-way loud-speaking telephone systems with means for conditioning the signal, e.g. for suppressing echoes for one or both directions of traffic
- H04M9/082—Two-way loud-speaking telephone systems with means for conditioning the signal, e.g. for suppressing echoes for one or both directions of traffic using echo cancellers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
200820682 九、發明說明 【發明所屬之技術領域】 本發明係關於以內容爲基的適應性跳動處理。 【先前技術】 習知行動通訊平台包括蜂巢式通訊,例如,全球行動 通訊系統(GSM)。其他支援有限行動性的習知平台包括依 φ 據IEEE 802.1 1標準的WiFi。蜂巢式和WiFi二者眾所皆 知且是已建立的無線通訊平台。 新一代平台被設計成使行動使用者能夠在蜂巢式和 WiFi網路之間移動,並且包括非授權行動存取(UMA)標 準,該標準提供交換控制器給載體,讓使用者能夠超越蜂 巢式和WiFi標準之間,反之亦然。然而,UMA標準具有 包括載體通常控制電話並且決定是否和何時在網路之間交 換使用者等不利點。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.
需要先進的行動通訊平台提供企業水平的通訊,並且 控制使用者和網路,使得企業(取代載體)能夠依據企業驅 策標準而非載體驅策標準選擇網路及/或電話。 另外,在行動/無線通訊中,通常具有下列問題:(a) 回音;(b)影響服務品質(Q〇s)的封包延遲、封包延遲變化( 封包跳動)、和封包損失;(c)協定的硬體或軟體平台相依 性;及(d)企業資源存取的安全性。將這些問題說明如下 200820682 , (a)回音 - 在諸如習知P S TN、會議電話、蜂巢式行動電話、及 網路電話等語音通訊中,已廣泛使用回音消除(EC)技術提 高終端用戶的服務品質(QoS)。通常有兩種回音消除器。 其中一種回音消除器通常稱作線路或網路回音消除器 (LEC)〇 LEC通常被用於去除由於2線及/或4線轉換發生的 網路上之混合成分的反射所導致之電回音。另一種回音消 φ 除器通常被稱作聲學回音消除器(AEC)。AEC通常被用於 去除由於從揚聲器到免持聽筒揚聲電話上的麥克風、行動 電話、或會議電話之聲學聲音反饋所產生的聲學回音。與 LEC比較,由於下面一些因素導致實施AEC較困難:因 爲音速比光速(或電子速度)慢很多,所以回音尾部較長, 因此回音消除器必須具有更大的處理功率和記憶體;因爲 電話或說話者的移動和環境的變化,所以聲學回音特性的 動態變化較大,因此回音消除器必須更快速追蹤和趕上回 φ 音特性的變化;及由於來自具有不同距離及/或取向的不 同物體之多重反射所導致的多重回音路徑。 目前的聲學回音消除技術通常具有限制。雖然聲學回 音消除技術迄今已經被發明和使用至少4 〇年,然而消除聲 學回音的基本方法並沒有明顯改變。通常,典型AEC利 用適應型濾波器模型化一或多個回音路徑轉移函數並且試 著產生回音的複製。然後,AEC可從進端輸入信號減掉此 複製以形成大槪最後的無回音遠端信號輸出。 迄今,大部分的聲學回音消除技術發展係利用不同種 -6- 200820682 , 類的濾波器,諸如FIR或IIR濾波器、單頻帶或多頻帶濾 , 波器、或時域或頻域濾波器等。另外’諸如LMS、RLS、 APA等不同演算法已用於提高濾波器效率。儘管如此’甚 至憑藉所有這些技術改良,在今日’ AEC設計和實施仍是 一件非常困難的工作。因爲聲學回音的複雜和變化性本質 ,所以習知濾波器在處理聲學回音上呈現許多限制。其中 一限制爲不良的兩端通話(近端和遠端說話者都在說話)性 φ 能。習知濾波器的計算結果是在兩端通話期間以發散取代 回音和複製之間的收斂。 (b)影響服務品質(QoS)的封包延遲、封包延遲變化(封包跳 動)、和封包損失 在網路電話和網路視頻通訊中,語音及/或視頻媒體 內容需要即時從發送器移轉到接收器,然而’基本IP網 路原本設計用於非即時通訊。因此,提供和維持終端用戶 φ 的服務品質(QoS)變成是一件非常困難的工作。端對端的 封包延遲、封包延遲變化(封包跳動)、及封包損失可被視 作影響IP網路的語音及視頻通訊之品質和性能的三個重 要QoS參數。 目前的跳動緩衝技術有限制。又稱作反跳動緩衝方案 的跳動緩衝方案通常用於接收器側以補償或消除網路封包 跳動。基本上,方案無法一接收到封包就馬上實施封包。 取而代之的是,方案可以均等間距佇列進來的封包和實施 已佇列封包。實際上,在實施發生之前,封包佇列表示插 -7- 200820682 入延遲。插入的延遲通常稱作實施延遲。 在目前的跳動緩衝設計和實施上至少有兩問題。第一 個問題係相關於需要插入多少實施延遲。在實施延遲數量 上可有多有少。就大延遲而言,封包損失較少。另一方面 ,就小延遲而言,互動感覺較佳。可由適應性跳動緩衝計 畫合宜地解決第一個問題。在適應性跳動緩衝計畫中,接 收器可依據進來封包的RTP標頭之時間戳記和接收器本 φ 地時間估算網路封包跳動。然後,接收器插入剛好足夠補 償網路封包跳動用的最小延遲。 跳動緩衝設計的第二個問題係相關於何時插入實施延 遲。理想上,可在各個說話乍現的一開始插入實施延遲。 因此,雖然可在均等間距實施各個說話乍現,但是只有·說 話乍現之間的無聲期間被擴大或壓縮。例如,若發送器利 用無聲抑制技術,則進入到接收器的封包理想上具有說話 乍現之間的間距,使得裝置可實施成依據進來封包的RTP # 標頭之時間戳記和順序號碼加以辨識各個說話乍現的一開 始。 然而,事實上,只有在有限情況下可達成在說話乍現 一開始插入延遲。大部分目前的無聲抑制技術具有限制並 且只在諸如單一說話者或低背景雜訊等一些純粹情況下能 夠執行良好。目前的無聲抑制技術在諸如會議中的多個說 話者或諸如行動通訊等筒背景雜訊等一些其他情況下就無 法執行良好。因此,爲了保留較好的聲頻品質,許多應用 在未利用或致動無聲抑制就執行。結果,進入到接收器中 -8- 200820682 的封包可以是連續的而無任何中斷。時間戳記和順序號碼 上沒有任何線索可得知是否封包表示無聲或說話乍現。假 設沒有辨識無聲的線索,則目前的跳動緩衝技術執行很差 。不良的性能原因之一即目前的跳動緩衝設計通常只看進 來封包的RTP標頭資訊,而不看RTP酬載上的內容。 (c)協定的硬體或軟體平台相依性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
.硬體或軟體平台相依性會產生可交互運作性及/或組 態問題。就包含諸如視頻、聲頻、聊天、遊戲、或虛擬實 境等多媒體元素之通訊中的互動使用者對話而言,需要有 諸如例如能夠在伺服器和用戶之間有效傳送資訊並且能夠 獨立於硬體和軟體平台之外運作的對話啓動協定(SIP)等 通訊協定之輕量協定,在伺服器和用戶之間所使用的控制 平面協定,及伺服器和用戶通訊的基本傳送層或媒體。有 需要足夠快到支援緊急即時控制訊息及對具有最小延遲的 大體積資料移轉而言足夠彈性之協定。然而,諸如UMA 等習知技術協定通常是複雜的且難以建立可交互運作性。 (d)當從行動裝置存取企業資源時的安全性 越來越多的企業允許它們的員工能夠使用自己的蜂巢 式/行動電話做生意。憑藉可利用諸如WiFi、Edge、 UMTS、CD MAE VD Ο等局速網路到行動電話,不同販售商 已實施VoIP(網路電話)到行動電話。此種實施需要開放的 企茱防火牆’使得諸如S IP、R T P等V ο IP相關協定能夠 -9- 200820682 操作。 除了 VoIP之外,也可將其他企業資料中心應用延伸 到行動電話。這些應用程式可包括一或多個Presence/Instant Messaging(出席/即時訊息)、企業內部網路網頁資源、 CRM、Support database(支援資料庫)等。若用戶利用行動 電話爲一或多個上述應用程式直接存取企業資源,則企業 防火牆需要爲多個協定打開,而開放的企業防火牆可能產 φ 生安全性問題。 【發明內容】 在一實施例中,本發明係相關於封包通訊裝置。封包 通訊裝置包括偵測器,其被組配成偵測封包通訊裝置所接 收到之進來封包中的特徵化內容。封包通訊裝置又包括實 施控制器,其被組配成若偵測器已偵測到進來封包中的特 徵化內容,則執行進來封包的調整,以產生經調整封包和 ^ 輸出經調整封包。 上述摘要係只相關於此處所揭示的本發明之許多實施 例的其中之一或多個,並不用於限制本發明的範圍,本發 明的範圍將在本文的申請專利範圍中陳述。下文中,連同 下面圖式將在本發明的詳細說明中更加詳細說明本發明的 這些和其他特徵。 【實施方式】 目錄 -10- 200820682 架構 以編碼/解碼器爲基的聲學回音消除 透過IP的語音/視頻通訊之以內容爲基的跳動緩衝設計 戴維他(Divitas)描述協定(DDP) 戴維他(Divitas)協定代理(DPP) H.結論 現在將參考如附圖所圖解說明的一些較佳實施例詳細 φ 說明本發明。在下面說明中,爲了能夠全面性瞭解本發明 陳述許多特定細節。然而,精於本技藝之人士應明白在沒 有一些或全部這些特定細節之下仍可實施本發明。在其他 例子中,爲了不混淆本發明將不詳細說明眾所皆知的處理 步驟及/或結構。參考圖式和下面討論將可更加明白本發 明的特徵和優點。 可參考特定設備和實施例說明本發明。精於本技藝之 人士將明白說明僅用於圖解說明和提供實施本發明的最佳 φ 模式。而不應解釋作限制本發明的範圍。例如,儘管參考 特定通訊協定,但是本發明也考慮到其他協定。例如,儘 管說明WiFi(IEEE 802.1 1 )當作無線通訊的協定,但是本 發明也可實施其他協定。此處對Divitas和行動性伺服器 所做的參考是相等的。 下面說明各種實施例,包括方法和技術。應注意本發 明也涵蓋製造的物體,其包括儲存完成本發明的實施例之 電腦可讀式指令的電腦可讀式媒體。電腦可讀式媒體包括 例如用以儲存電腦可讀碼之半導體、磁性、光磁、光學、 -11 - 200820682 或其他形式的電腦可讀式媒體。另外,本發明也涵蓋用以 實施本發明的實施例之設備。此種設備包括完成有關本發 明的實施例之操作的電路(專屬及/或可程式化)。此種設備 的例子包括當適當程式化時的萬用型電腦及/或專屬計算 裝置,並且包括用於有關本發明的實施例之各種操作的電 腦/計算裝置與專屬/可程式化電路之組合。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爲根據本發明的實施例之系統網路100圖。設置利 用許多可能方式與網路通訊之行動配備(ME)102。ME 102 可與包括基地收發站(BTS)112、BTS交換中心(BSC)114、 及行動交換中心(M SC) 116的蜂巢式網路110通訊。耦合 MSC到耦合到公用交換電話網路(PSTN)122的媒體閘道器 120。其他習知公用和專用電話124也被耦合到PSTN。將 PBX 130耦合到PSTN,及例如透過電話136爲企業打電話 φ 和接電話。將行動性伺服器1 50耦合到PBX與其他網路。 例如’透過路由器1 32將行動性伺服器1 50耦合到網際網路 協定廣域網路(WAN)138。也透過路由器140和防火牆142 將行動性伺服器150耦合到網際網路144。雖然本發明也預 想到多個存取點,但是本處只描繪一存取點。存取點1 60 使具有ME 102的使用者能夠在企業中漫遊並且經由行動 性伺服器150和PBX 130與PSTN維持連接。若使用者漫 遊超出LAN的邊界,則如下面將詳細說明一般,使用者 將連接到另一網路(如、蜂巢式網路)。另外又描繪耦合到 -12- 200820682 網際網路存取點1 80,其用於如本文所說明的特定條件之 下昀存取。 圖2A-C爲根據本發明的實施例之行動性伺服器。 安全性管理器-當兩或更多時體正通訊時的安全性定 義包含以下方面: 1. 通訊實體的相互認證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. 通訊通道的隱私權 3 .交換訊息的完整性 4.訊息的認證 在Divitas行動性情況中,具有三個明確的通訊實體 :Divitas用戶、Divitas伺服器、及外部VoIP GW。並且 在這些實體之間具有兩清楚的路徑類型:SIP發信路徑和 媒體路徑。 如架構說明書[1]所說明一般,下面機構被用於達成 用戶、伺服器、及外部閘道器之間的發信和資料路徑之上 0 述安全性方面: 1·用戶和伺服器之間的SIP TLS對話。 2·在SIP TLS建立之後使用SIP通知的用戶認證 3 ·利用伺服器的使用者之認證 4·伺服器和外部VoIP閘道器之間的SIP TLS對話。 5.利用外部VoIP閘道器的伺服器認證 6·安全媒體路徑 7.衍生的需求 使用者/裝置管理器/行動性控制器-裝置和行動性管理 -13- 200820682 器(特此稱作DMM)是在裝置上有進行中的電話同時處理 裝置組態和狀態與行動性方面之模組。下面各段落記錄 DMM之功能和設計規格與DMM支援的公用介面。 1. 企業管理人所控制的裝置組態。 2. 裝置的報告狀態 3. 裝置的影像管理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. 爲有進行中的電話之手機維持和實施行動性邏輯-即處理WiFi到Cell(蜂巢式)和反之亦然的傳訊。 5 .處理裝置初始化和來自用戶的組態請求。 控制平面/電話控制-電話控制(CC)是負責下面功能的 主要控制平面模組: 1.網路語音電話處理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代理伺服器和B2BUA 3.經由 PSTN GWs 的 PSTN Call 管理 4 .經由A s t e r i s k的P B X特徵管理 5. 資源和連接管理 電話控制模組駐在DN媒體交換器上。電話控制模組 與SIP堆疊和Astarisk(或任何其他)PBX接合以提供上述 功能。 1.SIP 堆疊(用於 UA,CCM,及 Asterisk 等):SIP 堆疊 主要被使用當作協定訊息解碼/編碼引擎。SIP堆疊又執行 基本的協定指定工作,諸如以標準爲基的訊息剖析和驗證 、重傳、專屬訊息驗證等。就大部分代理和B2BUA工作 而言,SIP堆疊依賴CC作決定。CC與Asterisk和CC與 -14- 200820682 CCM之間的互動係經由以標準爲基的SIP訊息。 2. 代理引擎/組態管理器(PA/CM):代理引擎充作用於 所有應用程式的組態管理器。在供應時或系統啓動後讀取 碟DB之後,以PA下載電話控制相關資訊。CC將資料儲 存在RAM做爲本地/較快速存取用。CC又更新任何動態 資訊的P A(如、電話進行中或中斷),或需要資訊(如、 SNMP GET)。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. 資源管理器(RM):資源管理器提供實體/網路資源 的邏輯圖。這些資源包括 GE埠、DSP資源、插座、 UDP/TCP埠等,但不包括系統資源,諸如記憶體、資料 緩衝器、計時器、佇列等。資源不包括用於內部IPC通訊 的插座。CC使用RM作爲資源CAC、資源保留和通訊用 。當作通訊的一部分,RM告訴媒體交換器程式化硬體以 使媒體能夠流動。 媒體交換應用程式(MSA)-MSA將被設計成部分在 Linux上而剩下的在TMS320DM64x DSP處理器上執行。 應用程式將執行下面功能: RTP封包處理。 交換。 代碼轉換。 會議電話。 適應性跳動緩衝。 封包損失隱藏。 包括VAD/CNG和AGC的後處理。 -15- 200820682 MSA軟體需要支援不同說話編碼/解碼器之編碼/解碼 。可在執行期間改變演算法和通道的類型,即需要支援多 通道、多演算法的設計。各個編碼/解碼器演算法需要是 可重入碼的,及程式與資料需要完全可釋放的。爲了支援 各種編碼/解碼器,需將下面列入考慮: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. 因爲DSP在晶片資料記憶體上有限制,所以在多通 道、多演算法應用程式中並非所有資料都能夠一直置放晶 片上。此需要在內文交換期間可重新改變(在晶片上和晶 片外記憶體之間)各個演算法中所有資料(內文和表格)的 位置。此需要找出各個支援的編碼/解碼器之記憶體、堆 疊尺寸、與MIPS需求。 b. 交換指出通道數目與編碼/解碼器類型和任何其他 特徵的主機和DSP之間的訊息之機構。通道組態管理器 需要打開指出所需的功能類型之DSP的通道。必須實施 指出DSP狀態的週期性訊息。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.
DSP處理器使外部主機能夠存取DSP外部記憶體。 DSP具有16千位元組的第一階程式和資料記憶體。程式與 資料記憶體共用256k位元組的第二階記憶體。可利用1 6 百萬位元組外部記憶體(SDRAM)。兩處理器之間的共用記 憶體儲存進來與出去的RTP資料。因爲DSP需要支援N 通道數量,所以此記憶體將包含每一個長度320位元組的 N接收與傳送緩衝(就視頻而言,這些緩衝需要是1 500位 元組的)。用於主機和D SP之間的資訊與每一通電話爲基 礎所需的資訊之資料結構需要被定義。下面步驟定義DSP -16- 200820682 功能: a. 在啓動中,一旦將軟體下載到DSP(將藉由在固定 記憶體位置寫入預定値以使DSP指出相同者,藉以指出 下載軟體的主機)。 b. 在成功下載軟體時,DSP將執行內部計時器10 m s e c。此時,D S P輪詢通道狀態以改變成處理,此處理係 一旦封包到達藉由主機所設定。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. 將指出編碼/解碼器類型、資料就緒、與電話類型( 最初只有語音)之來自主機的開始電話或打開通道命令發 送至RX與TX方向。 d. 依據所打開的通道,DSP從外部緩衝器取得RTP資 料並且對這些執行DSP相關功能。 e.在TX側上,DSP將編碼資料置放於外部緩衝器上 ,讓TX能夠取得。 圖3爲根據本發明的實施例之行動配備用戶圖。 在與Divitas伺服器相容的手機上執行用戶軟體或手 機軟體。典型上,這些是具有提供蜂巢式網路(CDMA或 GSM)的電話連接與LAN網路(有線LAN·或無線LAN)的 IP連接之雙模式手機。 也可爲具有麥克風和揚聲器的桌上型/膝上型或PDAs 編譯軟體來當作軟體電話。 使用者介面 用戶使用者介面提供下面功能: -17- 200820682 •設置開機組態-DNS IP位址、Divitas伺服器URL、 開機使用者狀態(IN VI SIB LE/A VAIL ABLE)、安全設定 •改變使用者狀態(IN VISIBLE/A VAIL ABLE) •增加企業“ buddies”(夥伴)和取得他們的出席資訊 (IN VISIBLE/A VAIL ABLE/CALL-IN-PROGRESS) •企業“ buddies”(夥伴)的顯示可利用性狀態並且連接 到他們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
•共有企業電話特徵的使用者介面 •電話撥打 •電話接聽 •話中插接 •指定轉接 •電話轉接 •多方會議電話 •語音郵件通知 •未接電話通知 •已接電話通知 •待接電話通知 · •號碼查詢和利用名字撥號 •使用蜂巢式網路取代WiFi網路的手動控制裝置 •顯示器版本失配 •升級請求/狀態 •失能/禁止用戶軟體一ISP應用程式被用於撥打/接收 蜂巢式電話 -18- 200820682 電話控制和語苜 •在LAN介面上撥打VoIP電話之電話控制 •在LAN介面上撥打VoIP電話之語音引擎一包括編 碼/解碼器、回音消除、跳動控制、錯誤隱藏 •從蜂巢式電話到VoIP電話的電話傳訊 •從VoIP電話到蜂巢式電話的電話傳訊 802.11• 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
•決定可利用哪一個IP網路和它們的信號強度和傳遞 那資訊給伺服器 •AP用戶 • 8 02.1 1迷你連接埠的功率管理一每當802.1 1的信號強 度低於可接受的臨界時,以罕見的間隔使網路進入睡眠狀 態並且輪詢網路以節省功率 •若電話在進行中,則將信號強度和語音品質資訊包 裝成RTCP封包,或若電話不在進行中,則保持持續有效 # 以通訊到伺服器。每當信號強度降至可接受的臨界下或語 音品質退化時,伺服器將決定從VoIP交換電話到蜂巢式 網路。 平台 因爲市面上有許多手機販售商且提供雙模式手機,所 以軟體需要被設計成大部分的碼能在手機之間共用。因此 ,必須將碼分成平台依賴部分和平台獨立部分。事實上, 幾乎所有的Divitas核心値都應在軟體的平台獨立部分, -19- 200820682 如此可容易從一平台攜帶到另一平台。平台依賴部分應只 有功能適應層(尤其是,電話、LAN、802.11、聲頻和顯示 適應層)。每當將碼轉移到新平台時,在提供統一 API給 平台獨JlL部分的问時’只需要修正和重寫這些適應層。 將於多個手機平台上執行用戶軟體。最普遍的手機平 台是 Windows CE、Symbian、及 Linux。 除了雙模式手機之外,用戶應用程式被設計成在不具 φ 有蜂巢式電話介面的802.11電話、PDA、或膝上型/桌上型 電腦上運作。在這些平台上,可利用一子組特徵到使用者 。基本上,從VoIP到蜂巢式的電話傳訊是不可能的。 操作理論 在起動時,用戶應用程式尋找手機上可利用的資源。 用戶應用程式首先檢查有線網路的存在。若不存在,則用 戶應用程式檢查802.1 1網路的存在。視企業安全政策進行 φ 有線或無線媒體認證。手機用戶應支援企業所利用的安全 機構。最普遍的安全機構是WPA(WiFi受保護存取)。一 旦成功進行認證,則無線用戶取得使用DHCP的IP介面 之IP位址。 應用程式從持續性資料庫取得Divitas伺服器URL和 DNS IP位址,並且嘗試向Divitas伺服器註冊。 可在企業網路內部的手機上執行應用程式用戶。在那 時,用戶可到達Divitas伺服器卻不需要任何其他安全覆 蓋層。在用戶示在公共網路時(例如具有WiF.i網際網路存 -20- 200820682 取的咖啡廳或機場),典型上使用者設定VPN連接到企業 。用戶只有在VPN通道建立之後才可到達Divitas伺服器• 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.
用戶應用程式軟體藉由發送加密數位簽證(企業IT所 安裝)給伺服器向伺服器認證手機。一旦認證手機,則用 戶取得來自使用者或儲存在手機中的登入/密碼,將登入/ 密碼加密並且將經加密登入/密碼發送到伺服器作爲使用 者認證。當成功認證時,伺服器藉由發送企業電話號碼加 以回答。在回答時,用戶發送蜂巢式電話號碼到伺服器。 伺服器爲所有未來的傳訊方案結合該二者。 使用用於發信的SIP/TLS和用於媒體流的SRTP以確 保發信和媒體流。然而,若使用者是在VPN鏈路上,則 用戶不需要添加另一位準的加密。添加另一位準的加密會 導致語音品質降低。在那例子中,SIP被用於發信而 RTP/RTCP被用於媒體流。 每當用戶恢復與伺服器的網路連接性時重複上述處理 恆穩態操作 藉由在GUI上組配並且在持續性資料庫中保存那組 態,使用者可在起動時選擇INVISIBLE或AVAILABLE( 看不見/可利用)。用戶對伺服器更新使用者出席資訊。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.
使用者亦可經常輸入企業內所謂的伙伴,並且在手機 上的持續性資料庫中保存那組態。無論它們是INVISIBLE 200820682 、AVAILABLE、或 C A L L · IN P RO G RE S S (電話中),用戶 取得這些伙伴的出席資訊(巨量)。當事件發生時,伺服器 對用戶更新這些伙伴的出席資訊。 每當不在電話中時,用戶和伺服器週期性交換持續有 效。 用戶週期性發送網路狀態到伺服器。若用戶示在 802.1 1無線網路上,用戶發送SSID、相關存取點(AP)的 φ 信號強度和頻寬給伺服器。若在電話中,用戶發送SSID 當作頻帶中的RTCP封包之一部分。若不在電話中,則用 戶發送頻帶外的持續有效訊息。 每當從用戶到伺服器可利用到網路對話時,對用戶之 撥打和接收電話的較佳模式是在網路介面上。然而,使用 者可選擇無視較佳模式的存在,在蜂巢式網路上撥打出去 的電話。此選擇不傳遞到伺服器且不影響進來的電話。此 選擇亦不儲存在持續性資料庫中。使用者必須在使用者撥 φ 打出去的電話時都明確地作選擇。 每當從用戶到伺服器無法利用到網路對話,則撥打電 話焊接電話的唯一方式是在蜂巢式介面上。使用者不具有 到所有企業特徵的存取。無論用戶軟體是否只提供一子組 服務供應商特徵,使用者可使用用戶軟體UI撥打和接收 電話。爲了使用蜂巢式服務供應商網路的所有特徵,使用 者必須終止(或禁止)用戶軟體並且使用蜂巢式服務供應商 撥接應用程式。若服務供應商應用程式正被用於撥打和接 電話,則在下面3.4.2段中所說明的傳訊將不可能。 -22- 200820682 只要用戶具有已建立到伺服器的對話,則使用者就具 有到所有企業特徵的存取。用戶GUI被用於提供到這些 企業特徵的存取給使用者。 語音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發信被用於建立用戶和伺服器之間的語音電話。 將來自聲頻接收器的語音編碼成GIPS語音引擎(VE)所支 援的編碼/解碼器之一,將被封裝成RTP封包,若需要的 話被加密,並且在ip介面上被發送到伺服器。同樣地, 若需要的話,解密從伺服器接收的RTP,使用編碼/解碼 器之一解碼並且實施。由接收側上的GIPS VE進行速度 解碼、跳動控制、及錯誤隱藏。 除了加密/解密、速度的編碼/解碼之外,GIPS語音引 擎還執行錯誤隱藏、跳動控制、適應性封包緩衝、聲學回 音消除和抑制、雜訊消除和抑制、自動增益控制、語音活 動偵測、舒適雜訊產生。 漫遊 不像可攜式膝上型電腦一般,手機用戶是行動性裝置 WLAN內的傳訊 當使用者是在具有電話交談的802.1 1網路中且行走於 建築物之間時,AP傳訊可能發生,即、除了手機先前結 -23- 200820682 合的AP之外,使用者的手機現在還與不同的AP結合。 若傳訊在同一子網路或到另一子網路,則不需要IP位址 變化就可發生AP傳訊,在該例子中,手機的IP位址改變 。若IP位址改變,則用戶需要再次向伺服器註冊。在同 時,已建立的電話使用舊的流動資訊繼續流動,直到語音 引擎(VE)被通知新的IP位址。 當無線用戶使用802. IX認證時,在無線用戶按無線 φ 存取點(AP)之間有一連串訊息發送以交換證書。此訊息交 換引起連接處理時的延遲。當無線用戶從一無線AP漫遊 到另一無線AP時,執行802. IX認證的延遲可能導致網路 連接的明顯中斷,尤其是諸如以語音或視頻爲基的資料流 等時間相依流量而言。爲了最小化與漫遊到另一無線AP 相關聯的延遲,無線設備可支援PMK快取和預先認證。 PMK快取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
當無線用戶從一無線AP漫遊到另一無線AP時,無 線用戶必須執行與各個無線AP的全面802. IX認證。WPA 使無線用戶和無線AP能夠快取全面802. IX認證的結果, 以便若用戶漫遊回到無線用戶先前已認證的無線AP,則 無線用戶只需要執行4方交握且決定新的配對過渡鑰匙。 在相關請求圖框中,無線用戶包括在最初認證期間所決定 且儲存有無線用戶按無線AP的PMK快取條目之PMK識 別符號。如在無線用戶和無線AP上組配一般,將?1^1: 快取條目儲存一段有限時間量。 -24- 200820682 爲了使使用充作802. IX認證器的開關之無線網路基 礎建設的過渡更快,WPA/WPS IE Update計算PMK識別 符號値,使得當在附加到同一開關的無線AP之間漫遊時 ,重新使用如與開關802. IX認證所決定的PMK。此實施 被視作投機取巧的PMK快取。 預先認證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
憑藉預先認證,在連接到其目前的無線AP同時, WPA無線用戶可隨意與其範圍內的其他無線AP執行 8 0 2. IX認證。無線用戶透過其現存的無線連接將預先認 證流量發送到額外的無線AP。在與無線AP預先認證且 在PMK快取記憶體中儲存PMK和其相關資訊之後,連接 到無線用戶已預先認證的無線AP之無線用戶只需要執行 4方交握。 支援預先認證的WPA用戶可只與公布其預先認證能 力在Beacon和Probe Response圖框中之無線AP認證。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-蜂巢式傳訊 當在具有電話交談的802.1 1網路中之使用者走到沒有 802.1 1連接性或不足的建築物外面時,將電話送交到蜂巢 式網路。 由用戶做出傳訊電話的決定。決定係依據802.1 1信號 強度、通道負載、與語音品質臨界。一旦做了決定,則將 決定傳遞到在蜂巢式網路上啓動電話到用戶之伺服器。用 -25- 200820682 戶檢查進來電話的撥打者id(識別符號),與802.1 1撥打者 id比較,若有匹配,則接受蜂巢式電話且丟掉8Q2.U電話 腳。在伺服器側上,伺服器丟掉到用戶的8 02.1 1電話腳, 修補到另一說話方的802· 1 1電話腳。 節源 當手機用戶在802.11網路上是閒置的時,802.1 1迷你 φ 連接埠進入睡眠。在進入睡眠之前,手機告知AP手機希 望藉由在每一圖框的802.1 1標頭中設定節源位元以進入睡 眠。AP接收圖框,及通知用戶的希望以進入節源模式。 在用戶的802.1 1迷你連接埠睡著的同時,AP開始爲用戶 緩衝封包。迷你連接埠在睡著時的功率消耗極低。迷你連 接埠週期性醒來以接收從存取點進來的定期性求救傳輸。 節源用戶需要在傳輸求救時剛好醒著以接收求救。TSP(時 序同步化功能)確保AP和節源用戶同步化。在基地台睡著 Φ 時,TSP計時器保持運行。這些求救辨識睡著的基地台是 否具有AP已緩衝的封包且等待運送到其各自的目的地。 當沒有進來的求救一段長時間週期時,802.11迷你連 接璋進入睡眠狀態。迷你連接璋週期性醒來,探測AP的 網路連接,若未存在,則迷你連接埠回到睡眠狀態。在此 例中,迷你連接埠睡得比前一例子更長的期間。 B.以編碼/解碼器爲基的聲學回音消除 本發明的一或多個實施例係相關於消除信號的裝置。 -26 - 200820682 裝置可包括辨識碼(ID碼)產生器,其被組配成產生1D碼 。裝置亦可包括ID碼注入器,其被組配成將ID碼注入到 信號和經處理信號的至少一者以產生迴旋信號。經處理信 號係由信號的處理所產生。裝置可另外包括ID碼偵測器 ,其被組配成偵測迴旋信號、變換信號、和迴旋信號之變 換的至少一者,變換信號係由迴旋信號的變換所產生。裝 置可另外包括算術函數,其被組配成去除迴旋信號和變換 φ 信號的至少一者。 圖4描畫根據本發明的一或多個實施例之以編碼/解碼 器爲基的聲學回音消除之方法。 當近端和遠端說話者二者都在說話時,難以區分遠端 說話者的語音之回音和近端說話者的語音,因爲二者都存 在於具有相同人類語音特徵的近端信號輸入中。在此應用 程式中’提出新方法處理聲學回音,該方法與目前習知 AEC相當不同。 本發明的一實施例是在第一節點和第二節點之間通訊 期間用以消除回音之方法。方法包括將密碼注入到第一節 點的信號輸入。根據本發明的一或多個實施例,第一節點 是遠端使用者所使用的網路裝置,第二節點是近端使用者 所使用的網路裝置。根據本發明的一或多個實施例,第一 節點是近端使用者所使用的網路裝置,第二節點是遠端使 用者所使用的網路裝置。 根據本發明的一或多個實施例,將密碼注入到遠端信 號輸入內。如此,在此密碼上攜帶信號或遠端信號的多重 -27- 200820682 回音並且到達近端信號輸入中。近端信號又包括近端說話 者語音。因爲只在遠端信號的回音上而非近端說話者的語 音上攜帶密碼,所以密碼可充作那些回音的本身,並且幫 助我們區分近端說話者語音。諸如關聯性或其他方式等某 些種類的匹配濾波器可被用於以密碼辨識遠端信號的回音 與近端說話者語音並且去除它們。在遠端信號輸出上將產 生最終無回音信號。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.
爲了進行此新的設計工作,有兩重要的實施考量。其 中一考量是如何選擇和設計密碼,而另一考量是如何將密 碼注入到遠端輸入信號內。兩種考量都有不應讓端對端收 聽者察覺到密碼的同一考慮。 當某人在麥克風前說話時,不僅此人的語音而且某程 度的背景雜訊也將進入麥克風。但是因爲說話者語音遮蓋 掉背景雜訊,所以通常此背景雜訊不干擾收聽者。只要背 景雜訊保持是低的,並且SNR(信號對雜訊比)保持在特定 臨界以上,背景雜訊不會變成會有影響的因素。事實上, 背景雜訊總是存在於實際今日語音通訊中。 . 依據上述事實,首先,可將密碼變換成稱作”密碼隨 機雜訊”的虛擬隨機雜訊。接著,從遠端信號輸入去除現 存的背景雜訊,及將密碼隨機雜訊插入到遠端信號輸入。 只要新的SNR保持在特定臨界以上,則近端收聽者不會 聽出任何差異。根據本發明的一或多個實施例,圖4所示 的注入器將密碼擾頻成虛擬隨機雜訊,去除遠端信號輸入 中的現存背景雜訊,然後插入密碼隨機雜訊。 -28- 200820682 因爲只有當遠端說話者正在講話時回音會存在,所以 遠端信號偵測器將偵測到遠端信號存在並且觸發密碼產生 器。密碼導頻可包括密碼時序和相位。密碼導頻偵測器被 用於偵測攜帶在遠端信號的回音上之密碼導頻,並且因爲 可變的回音路徑,所以亦被用於調整到匹配濾波器的密碼 延遲。在密碼導頻偵測器終將需要不擾頻處理。 密碼和密碼導頻可被設計成密碼偵測器和匹配濾波器 φ 容易辨識帶有此密碼和其導頻之遠端信號的回音,然後去 除這些回音。此外,可在匹配濾波器之後使用非線性處理 器進一步降低剩餘回音且提高AEC性能。 參考下面的圖式和討論將可更加明白本發明的特徵和 優點。 回音是通訊中的一大問題。如發明背景所討論一般, 在習知技術中,濾波器(或回音消除器)可被用於模型化嘗 試提供信號以消除回音之回音路徑。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.
圖8A爲包括回音消馀用的濾波器814(或回音消除器 8 14)之示範性習知技術通訊裝置800(習知技術裝置800)的 方塊圖。如圖8A的例子所示,習知技術裝置800可包括信 號接收器802,用以接收來自遠方(或遠端)的遠端信號(如 、信號y’);和信號發送器,用以發送信號(如、信號z)到 遠方。 習知技術裝置800又包括揚聲器806,用以播放接收到 的信號給習知技術裝置800的使用者(即、本地或近端方) :和麥克風8 1 0,用以收集近端信號(如、信號X,可包括 -29- 200820682 本地方的語音和背景雜訊)。 習知技術裝置8 00又包括緩衝器8 1 2,用以緩衝從信號 接收器802所接收到的信號;和濾波器814,用以模型化揚 聲器8 06與麥克風810之間的回音路徑808,且用以處理緩 衝器8 1 2中所緩衝的信號。回音路徑8 0 8可表示延遲、衰減 、混響等的多重路徑,例如,將信號y ’變換成y 1等。 習知技術裝置8 00另外包括總和函數8 1 6,用以從麥克 φ 風810的輸出減掉濾波器814的輸出。習知技術裝置800另 外包括信號反饋路徑,用以將總和函數8 1 6的輸出饋送回 到濾波器8 1 4。 信號接收器802所接收到的信號(如、信號y’)可轉寄 到揚聲器806和緩衝器812。濾波器814從緩衝器812接收信 號,利用回音路徑808的模型處理信號以產生消除信號(如 、,y ’的函數),及發送消除信號到總和函數8 1 6。接著 ,總和函數8 1 6從自麥克風8 1 0所接收的信號(如、 φ x 1 =x + y 1)減掉從濾波器8 1 4所接收到的消除信號(如、 x2==f(y’))以產生減法信號(如、Z)且發送減法信號到信號 發送器8 1 8。將總和函數8 1 6的輸出饋送回到濾波器8 1 4以 更新和改良濾波器8 1 4中的回音路徑模型。 進一步參考圖8B說明習知配置800中所實施的回新消 除方法。 圖8B爲例如習知技術裝置800(圖8A所示)用以消除回 音的示範性習知技術方法之流程圖。如圖8 B的例子所示 ’方法開始於步驟8 50,其中接收器8 02(圖8A所示)發送 -30- 200820682 信號y’。然後,將控制移至步驟852及854。 在步驟852,揚聲器806(圖8A所示)接收信號y,。在 步驟156中,麥克風810(圖8A所示)接收信號yl加上近端 信號X。信號y 1表示因爲延遲、衰減、混響等所產生之信 號y’的變形信號。延遲、衰減、混響等係由揚聲器806和 麥克風8 08 (圖8A所示)之間的回音路徑80 8所產生。信號X 包括本地方的語音加上麥克風8 1 0所拾取的本地周遭背景 φ 雜訊。然後,將表示信號yl和信號X的組合之信號xl發 送到總和函數816(圖8A所示)。 在步驟854中,緩衝器812又接收信號y’。在步驟858 中,濾波器814利用回音路徑808的模型處理信號y’以產 生信號x2,其爲y’的函數,如、f(y’),然後將此發送到 總和函數816(圖8A所示)。 在步驟860中,總和函數816從信號xl減掉信號x2以 產生信號z。理想上,若f(y’)等於yl,則z將等於X,其 φ 爲與已去除回音(由yl表示)的遠方有關之近端信號。然而 ,濾波器814中所實施之回音路徑808的模型可能不精確, 典型上z不等於z。 在步驟862中,總和函數8 16將信號z發送到將z傳送 到遠方的信號發送器8 1 8。 在步驟8 6 4中’總和函數8 1 6饋入丨g號z回到灑波器 8 1 4,用以更新和改良步驟8 5 8中所利用的回音路徑模型。 信號z的反饋和相關計算與更新使得濾波器8 1 4需要額外 的處理時間或處理功率。 -31 - 200820682 信號Z的品質(即有關信號X的信號z之錯誤)視濾波 器8 1 4中所實施之回音路徑模型和演算法與實施濾波器8 1 4 的計算裝置之記憶體和處理功率而定。 就習知技術裝置、配置、和方法(如圖8A的習知技術 裝置800和圖8B的方法所示者)而言,回音路徑808的校正 模型化(如、濾波器814所執行者)對有效消除回音是重要 的。然而,既定的各種周遭雜訊、周遭雜訊的混響、及/ φ 或其他因素,回音路徑808是動態的,因此難以準確地模 型化。結果,習知技術裝置、配置、及方法無法有效消除 回音。 習知技術裝置、配置、方法另外面臨本地方(或近端) 和遠方(或遠端)同時說話之雙邊通話情況。因爲本地方的 語音和遠方的語音具有類似的人聲特性,濾波器814無法 準確地辨識哪一個信號欲輸入到回音路徑808的模型。結 果,本地方的語音部分可能被消除,及回音部分不被消除 φ ,及濾波器814中的回音路徑模型之錯誤可能變成發散以 取代收斂,導致不理想的通訊品質。’ 因此,在習知技術中,已投入許多資源以改良模型化 回音路徑808的演算法。另外,濾波器114需要大量資料記 憶體和需要具有高處理功率的CPUs。結果,產生實施回 音消除的高成本。 對照之下,即使未設置濾波器,本發明的一或多個實 施例仍包含用以消除信號的設備。在一或多個實施例中, 信號表示數位信號。設備包括辨識碼(ID碼)產生器,其被 -32- 200820682 組配成產生ID碼。設備又包括iD碼注入器,其被組配成 將ID碼注入到信號和經處理信號的至少一者以產生迴旋 信號。經處理信號係由信號的處理所產生,諸如背景雜訊 的去除等。設備另外包括ID碼偵測器,其被組配成偵測 迴旋信號、變換信號、及迴旋信號之變換的至少一者,其 中變換信號係由迴旋信號的變換所產生。可因設備的組態 及/或環境產生迴旋信號的變換。例如,迴旋信號的變換 φ 表示設備的揚聲器和麥克風之間的一或多個回音路徑所產 生的延遲;變換信號表示延遲存在的延遲信號。設備另外 包括算術函數,其被組配成去除迴旋信號和變換信號的至 少一者。 圖9A爲根據本發明的一或多個實施例之即使未設置 濾波器仍可消除回音之通訊裝置900(裝置90 0)的方塊圖。 方塊圖又表示具有實施在一或多個裝置中之圖9A所示之 組件的通訊系統或配置。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.
裝置900包括輸入/輸出組件,諸如信號接收器904用 以接收來自遠方的遠端信號)、信號發送器93 2(用以發送 信號到遠方)、揚聲器914、及麥克風916(本地麥克風916) 等。存在從揚聲器914行進到麥克風91 6的回音路徑908。 裝置900亦可包括信號處理模組,諸如背景雜訊去除 器906等。背景雜訊去除器906可被組配成從接收自信號接 收器904的信號去除背景雜訊。可利用諸如去除背景雜訊 用的光譜減法等一或多個眾所皆知的演算法實施背景雜訊 去除器9 0 6。 -33- 200820682 裝置900亦可包括用以消除回音之模組。模組可包括 辨識碼產生器922(ID碼產生器922)、辨識碼注入器910(ID 碼注入器910)、辨識碼偵測器924(ID碼偵測器924)、及緩 衝器926。模組亦可包括變換模組,諸如延遲器92 8等,例 如用以變換信號、引入延遲。模組亦可包括算術函數,諸 如例如總和函數93 0等。 ID碼產生器922可被組配成產生可控制且可去除的ID φ 碼,使得能夠辨識一部分信號。然後例如爲了回音消除目 的則將該部分信號去除。ID碼可表示可模擬背景雜訊或 緩和雜訊之虛擬隨機碼。ID碼產生器922可包括線性反饋 移位暫存器,用以產生欲使用的虛擬隨機雜訊序列當作 ID碼。 另外,ID碼可包括人類耳朵無法察覺到的高頻或低 頻信號。在一或多個實施例中,麥克風916的抽樣率可被 組配成例如經由組配麥克風916的硬體及/或軟體(或驅動 φ 器)來處理高頻或低頻信號。在一或多個實施例中,憑藉 表示人類耳朵無法察覺到的信號之ID碼,裝置900可不包 括背景雜訊去除器906。 ID碼注入器910可被組配成將ID碼產生器922所產生 的ID碼注入到信號中。可藉由諸如將ID碼插入到信號內 的數位相關法,例如藉由將ID碼與信號迴旋以產生迴旋 信號等藉由一些眾所皆知的演算法實施ID碼注入器9 1 0。 ID碼偵測器924可被組配成偵測迴旋信號內的id碼 ,例如在包含一或多個其他信號的混合、疊置、及/或另 -34- 200820682 外迴旋信號中。另外,ID碼偵測器924可被組配成偵測由 迴旋信號的變換所產生之經變換信號及/或ID碼;例如裝 置900的組態及/或環境可產生變換。另外,ID碼偵測器 924可被組配成偵測變換。變換可包括延遲及信號位準衰 減。ID碼偵測器924可實施一或多個眾所皆知的演算法, 諸如數位相關法或偵測ID用的匹配濾波器等。 延遲器928可被組配成將延遲引入到信號中。延遲器 φ 可被用於模擬變換。可藉由引入延遲用的簡易延遲線移位 暫存器實施延遲器928。 各個雜訊去除器906、ID碼產生器922、10碼注入器 910、ID碼偵測器924、及延遲器92 8都包括在可下載到諸 如電話、行動電話、電訊會議裝置等使用者裝置(如、用 於聲學回音消除)、及/或伺服器裝置(如、用於線路或網路 回音消除)的軟體中。 圖9B爲根據本發明的一或多個實施例之用於裝置 φ 900(圖9A所示)的ID碼產生器922之方塊圖。ID碼產生器 922可只包括在將直接產生隨機碼之碼產生器921中。在此 例中,諸如藉由憑藉小心選擇適當反饋函數之線性反饋移 位暫存器等一些眾所皆知的演算法實施碼產生器92 1。 然而,ID碼產生器922可包括伴隨隨機函數發生器 923的碼產生器921。在此例中,首先,碼產生器921可產 生適當辨識碼而不用擔心隨機化發生。然後’將此辨識碼 饋入隨機函數發生器923中,以變成當作922的輸出之虛擬 隨機雜訊序列。可憑藉碼產生器92 1所控制的反饋函數之 -35- 200820682 經修正線性反饋移位暫存器實施隨機函數產生器923。 圖9C爲根據本發明的一或多個實施例之用以消除例 如裝置900(圖9A所示)中的回音之方法的流程圖。方法開 始於步驟952,在該步驟中,信號接收器904(圖9A所示) 可從遠方接收信號y’(η)。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.
在步驟954中,雜訊去除器906可從y’(n)去除背景雜 訊,產生信號y(n)。爲了爲包括隨機雜訊的ID碼留空間 ,可去除背景雜訊。因此,本地方不接收過度的雜訊。 在步驟95 8中,ID碼產生器922(圖9A所示)可產生ID 碼c(n)。ID碼c(n)可表示已知和可控制的函數。在步驟 956中,ID碼注入器910(圖9A所示)可將ID碼c(n)注入到 信號y(n)中。結果可產生c(n)及y(n)的迴旋。例如,c(n) 及y(n)的迴旋可以是迴旋信號c(n)*y(n)。然後,將控制 移轉到步驟96 2及步驟98 0。 在步驟962中,揚聲器914(圖9A所示)可接收迴旋信 φ 號c(n)*y(n)。在步驟964中,麥克風916(圖9A所示)可從 揚聲器914接收延遲信號,即信號c(n-d)*y(n-d)。麥克風 9 16亦可拾取另一輸入信號x(n),其包括本地方的語音(如 、在雙邊通話方案中)及/或環繞在麥克風916四周的背景 雜訊。然後,麥克風916可將組合信號x(n) + c(n-d)*y(n-d) 輸出到ID碼偵測器924(圖9A所示)和總和函數930(如圖 9 A所示)。 在步驟980中,緩衝器926(圖9A所示)可緩衝迴旋信 號C(n)*y(η)的複本並且將迴旋信號的複本輸出到延遲器 -36 - 200820682 928 〇 在步驟9 6 6中,ID碼偵測器9 2 4 (圖9 Α所不)可偵測到 組合信號x(n) + c(n-d)*y(n-d)中的ID碼c(n-d),並且假設 c(n)是已知且可控制的函數,則可藉由比較從ID碼產生 器922所接收到的c(n)與c(n-d)以決定延遲量d。可將延遲 量d饋入到延遲器928(圖9A所示)。 在步驟982中,延遲器928(圖9A所示)可從步驟9 80將 φ 延遲量d引入緩衝器926的輸出(即c(n)*y(n)的複本),產 生 c(n-d)*y(n-d)的複本。 在步驟990中,總和函數930(圖9A所示)可從步驟964 的輸出(即、信號x(n) + c(n_d)*y(n-d))減掉步驟982的輸出( 即、信號產生c(n-d)*y(n-d)的複本)。換言之,在步驟990 中,總和函數 930計算信號 x(n) + c(n-d)*y(n-d)-c(n-d)*y(n-d)以獲得信號X(n),其表示未存在信號y’(n)的回音(以信 號y(n-d)表示)之接收器麥克風916(圖9A所示)所拾取的輸 # 入信號。信號x(n)可包括諸如在雙邊通話方案中等本地方 的語音,及/或在麥克風9 16四周的背景雜訊。 在步驟992中,包括諸如在雙邊通話方案中等本地方 的語音及/或在麥克風916四周的背景雜訊及未包含回音之 信號x(n)可被發送到信號發送器932。如此,可有效消除 單邊通話和雙邊通話方案中的回音。 從上述可明白,本發明的實施例可有效消除回音,卻 不需要習知技術裝置、配置、或方法中需要的濾波器(或 回音消除器)。在免除濾波器依賴的回音路徑模型化中之 -37- 200820682 可能錯誤下,本發明的實施例可提供更準確的回音消除和 更快速的消除,因此,獲得更好的服務品質。另外,本發 明的實施例可有效地消除習知濾波器通常執行不良之雙邊 通話方案中的回音。 在實際上不依賴濾波器和沒有回音路徑模型化的相關 複雜性之下,本發明的實施例亦可有利地免掉濾波器所需 之高CPU處理功率和大資料記憶體的需要,藉以減少實 Φ 施回音消除的成本。 C.透過IP通訊的影音之以內容爲基的跳動緩衝計畫 在不依賴濾波器和相關的回音路徑模型化複雜性之下 ,本發明的實施例亦有利地去除濾波器所需之高CPU處 理功率和大資料記憶體的需要,藉以降低實施回音消除的 成本。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.透過IP的語音/視頻通訊之以內容爲基的跳動緩衝設計 本發明的一或多個實施例提供一機構以使用聲頻的 VAD和跳動補償來處理過多WLAN跳動。本發明的一或 多個實施例亦爲沒有移動或無移動與封包跳動一起使用之 視頻運作。 本發明的一或多個實施例係相關於封包通訊裝置。封 包通訊裝置可包括偵測器,其被組配成偵測封包通訊裝置 所接收到之進來封包中的特徵化內容。封包通訊裝置可另 外包括實施控制器,其被組配成若偵測器已偵測到進來封 包中的特徵化內容,則執行進來封包的調整以產生經調整 -38- 200820682 封包和輸出經調整封包。 提出被稱作以內容爲基的跳動緩衝之新跳動緩衝設計 以解決目前的跳動緩衝技術限制。根據本發明的一或多個 實施例,不僅注意到進來封包的RTP標頭資訊,而且也 注意到它們的RTP酬載內容,藉以辨識進來封包上的無 聲和說話乍現。然後依據此無聲和說話乍現線索以決定何 時能夠插入實施延遲以補償網路封包跳動。利用此新的設 0 計,接收器側上的跳動緩衝將不再依賴發送器的無聲抑制 圖5A-B爲跳動緩衝架構的高位階槪要圖。將經由語 音品質引擎(VQE)中的函數方塊追蹤封包的路徑。此處的 目的係引進適應性去跳動控制器以使實施相等。可利用類 似的設計處理視頻跳動。 在習知技術跳動緩衝設計之一中,髓爲接收測VAD( 語音活動偵測)被用於防止跳動緩衝器溢位。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.
換言之,當無聲或說話乍現線索到達最大長度時,無 聲或說話乍現線索被用於嵌平跳動緩衝。新規劃與習知技 術設計的不同處包括無聲或說話乍現現所被用於控制何時 可插入實施延遲以補償網路封包跳動。因此,根據本發明 的一或多個實施例,無聲或說話乍現偵測將變成跳動緩衝 設計的重要部分。在某些情況下,當跳動緩衝變成溢位時 ,進行任何調整都太遲。 此處是如何將此以內容爲基的跳動緩衝設備和方法應 用到工作中的應用程式。將語音和視頻例子都說明如下。 -39- 200820682 圖5A爲根據本發明的一或多個實施例之語音跳動緩 衝器的方塊圖。核心跳動緩衝器包括用於封包佇列、封包 實施、跳動計算、及跳動補償的一或多個組件。在此處, 解碼器和VAD將產生無聲和說話乍現指標。然後將無聲 或說話乍現指標饋回到跳動補償部分,且被用於決定何時 插入實施無聲以補償網路封包跳動。 圖5 B爲根據本發明的一或多個實施例之視頻跳動緩 φ 衝器的方塊圖。除了當視頻圖框上沒有移動或移動極低時 將插入實施延遲之外,核心跳動緩衝器類似於語音的核心 跳動緩衝器。在此處,於解碼器之後,移動估算和移動補 償將產生剩餘圖框。可從此剩餘圖框加上一些特定臨界形 成無移動指標。然後將無移動指標饋回到跳動補償部分, 且用於偵測何時插入實施無聲以補償網路封包跳動。在視 頻中,插入實施無聲實際上係在重複先前視頻圖框的同時 ,停止實施新的圖框。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.
如上述,諸如封包延遲(即、封包晚到)、封包延遲變 化、及封包損失等問題對封包通訊中的服務品質(Qo S)具 有負面影響。封包延遲和封包延遲變化亦可視作跳動。爲 了解決這些問題,在習知技術中,藉由當實施來自封包緩 衝器的封包時週期性插入延遲(即、無聲封包或舒適雜訊 封包的形式)以將固定式去跳動緩衝設計用於補償封包的 晚到。然而,利用固定式去跳動設計,在語音封包之間會 過度插入延遲,產生突變語音。 在習知技術中,發送器側語音活動偵測器(VAD)亦可 -40- 200820682 被用於適應性插入延遲’藉以補償封包延遲和封包延遲變 化。然而,一些使用者裝置不支援發送器側VAD。另外 ,例如,當傳輸方正執行音樂播放時,因爲音樂中斷被視 作無聲和不適當處理,所以如果是現存的VAD演算法, 則發送器側VAD會產生不想要的雜訊或突變語音。就另 一例子而言,當傳輸方與打開的發送器側VAD —起使用 G.729AB編碼/解碼器以播放一些音樂時,接收器側中的 φ 使用者會察覺到變形失真的音樂。因此,封包通訊服務供 應商通常會關掉發送器側VAD,而無法補償封包延遲和 封包延遲變化。結果,仍舊會利用固定式去跳動緩衝設計 ,服務品質仍然不是接收方想要的。 另外,在習知技術中,接收器側無聲偵測器可被用於 控制封包緩衝器溢位,以防止封包損失。然而,根據習知 技術中的組配,會丟棄語音封包,因此當封包緩衝器幾乎 是滿的或是滿的時會損失,此種服務品質並非接收方想要 參的。 相反地,本發明的實施例可利用接收器側無聲偵測器 適時補償延遲和延遲變化,且適應性實施來自封包緩衝器 的封包。有利的是,不需要發送器側VAD,可提供想要 的服務品質。另外,本發明的一或多個實施例可利用接收 器側視頻偵測器,藉以適應性處理視頻通訊中的跳動。 在一或多個實施例中,本發明係相關於封包通訊裝置 ,該裝置可包括偵測器,其被組配成偵測封包通訊裝置所 接收的進來封包中之特徵化內容。特徵化內容可表示語音 -41 - 200820682 通訊中的無聲(如、未具有所接收到的語音封包之時間週 期)。另一選擇是,特徵化內容可表示低於臨界之移動或 無移動的至少一者。例如,可將無移動或靜止圖像的臨界 選擇成視頻通訊中的全部活動圖像之10%到15 %(就資料體 積而言)。 封包通訊裝置可另外包括實施控制器,其被組配成若 偵測器已偵測到進來封包中的特徵化內容時,則執行進來 φ 封包的調整,以產生經調整封包和輸出經調整封包。調整 包括例如無聲封包或舒適雜訊封包的形式之延遲的插入。 另一選擇是,調整可包括重複實施先前已實施之封包。結 果,可適時補償封包緩衝器中所接收到的進來封包之延遲 和延遲變化,及經調整封包是接受方可接受的品質。 參考下面的圖式和討論可更加明白本發明的特徵和優 點。 圖1 〇 A爲具有適應性跳動緩衝設計的第一示範習知技 ^ 術封包語音通訊配置(第一習知技術配置)之方塊圖。如圖 1 0 A的例子所示一般,第一習知技術配置包括經由網路 1 003連接的發送器側裝置1091和接收器側裝置1 092。各個 發送器側裝置1091和接收器側裝置1 092可表示電話、行動 電話、或電訊會議裝置。 發送器側裝置1091可包括下面組件:速度緩衝器1〇〇〇 、語音活動偵測器l〇〇l(VAD 1001)、及發送器1〇〇2。將這 些組件說明如下: 速度緩衝器1 〇〇〇可被組配成從麥克風接收語音封包( -42- 200820682 封包)、緩衝封包、然後傳輸經緩衝封包到VAD 1001。 可VAD 1001可被組配成當從速度緩衝器1 000所接收 的封包中具有無聲(即、語音封包之間的時間週期)時插入 無聲描述符(SID)。 發送器1 002可被組配成從VAD 1 000接收封包且傳輸 封包到網路1 0 0 3。 接著,網路1 003可將封包傳輸到接收器側裝置1 092。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.
接收器側裝置1 092可包括下面組件:封包緩衝器1004 、封包實施控制器1005、延遲插入控制器1 006、延遲資訊 模組1 007、跳動計算機1 008、及實施延遲計算機1 009。將 這些組件說明如下: 封包緩衝器1004可被組配成從網路1 003接收封包、緩 衝封包、然後發送封包到跳動計算機1 008、延遲插入控制 器1 006、及封包實施控制器1 005。 跳動計算機1 0 08可被組配成計算封包中的跳動尺寸。 跳動可表示無聲,即沒有資料的兩語音封包到達之間的時 間週期。 延遲插入控制器1006可被組配成依據發送器側裝置 1091的VAD 1001插入在封包中的SID以決定何時插入延 遲。延遲插入控制器1006可接收來自跳動計算機1 008的跳 動尺寸資訊,且可接收來自封包緩衝器10 的封包。 實施延遲計算機可被組配成接收來自跳動計算機 1 008的跳動尺寸資訊。依據跳動尺寸資訊,實施延遲計算 機1 009可計算欲插入到封包的延遲尺寸。 -43- 200820682 延遲資訊模組1007可被組配成統合來自延遲插入控制 器1 006的有關插入延遲的時序之資訊和來自實施延遲計算 機1 009的有關延遲的尺寸之資訊。因此,延遲資訊模組 1 007可建立經統合資訊到資料結構內和發送資料結構到封 包實施控制器1 005。 封包實施控制器1 005可被組配成根據從延遲資訊_模組 1007所接收的資料結構接收來自封包緩衝器1004的封包及 φ 插入延遲到封包。 圖10B爲圖10A的例子中所示之第一習知技術配置中 所利用的習知技術跳動緩衝設計之發送器側處理的流程圖 。發送器側處理開始於步驟1 060,在該步驟中,速度緩衝 器1 000(圖10A所示)可接收例如來自傳輸方所使用的麥克 風之封包。然後,速度緩衝器10 〇〇可緩衝封包。 在步驟1062中,速度緩衝器1 000可將以預設將各個封 包的標示符號位元設定爲〇。當各個封包到達最後步驟 φ 1〇72時,若封包是說話乍現的第一語音封包,則將封包的 標示符號位元設定成1。否則,可將標示符號位元保持爲0 〇 在步驟1 064中,VAD 1001可決定封包是否包含一或 多個無聲週期(β卩、在封包之間沒有資料的一或多個週期) 。若封包包含一或多個無聲週期,則控制移轉到步驟1 074 ;若未包含,則控制移轉到步驟1 066。 在步驟1〇74中,VAD 1001可決定是否已在封包中設 定SID。SID(無聲描述符)被組配成標示無聲週期的開始 -44- 200820682 。若已爲封包中的無聲週期設定SID,則控制直接移轉回 到1 0 72 ;若尙未設定,則在開始移轉到步驟1 0 72前將控制 移轉到步驟1 076。在步驟1 076中,VAD 1001可爲封包產 生SID。在步驟1072中,發送器1 002(圖10A所示)可傳輸 封包到網路1 003。 在步驟1 066中,VAD 1001可決定在無聲週期之後封 包是否包含第一語音封包。若封包包含第一語音封包,則 φ 控制移轉到1 068,在該步驟中VAD 1001可將第一語音封 包的標示符號位元設定成1。若封包未包含第一語音封包 ,則控制移轉到步驟1 072,在該步驟中,發送器1002可傳 輸封包到1 003。 圖1 0C爲習知技術延遲計算處理的流程圖。延遲計算 處理可以是用於圖1 〇 A所示之第一習知技術配置的接收器 側裝置1 0 92中之接收器側處理的一部分。延遲計算處理可 被執行包含圖10A的例子所示之接收器側裝置1 092的封包 φ 緩衝器1 004,延遲插入控制器1 006跳動計算機1 008、實施 延遲計算機1009、及延遲資訊模組1 007。 延遲計算處理可開始於步驟1 022,在該步驟中,封包 緩衝器1 004可接收來自網路1 003的封包並且緩衝封包。例 如,封包可表示步驟1 072(圖10B所示)中發送器1 002(圖 1 0 A所示)所傳輸的封包。 在步驟1024中,跳動計算機1〇〇8可計算平均跳動j。 在步驟1026中,跳動計算機1〇〇8可計算跳動偏差v。 在步驟1028中,實施延遲計算機1〇〇9可使用j及v及 -45- 200820682 依據以f(j,V)所表示的網路模型以計算實施延遲(即、延 遲 d = f(j,V)) 〇 在步驟1 03 0中,延遲插入控制器1〇06可決定封包緩衝 器1004是否是空的。若封包緩衝器1004是空的,則控制移 轉到步驟1 0 3 8 ;若不是空的’則控制移轉到步驟i 3 2。 在步驟1032中’延遲插入控制器1〇〇6決定是否已設定 値1的標示符號位元。若已設定値1的標示符號位元,則可 ^ 將控制移轉到步驟1 〇 3 8 ;若未設定,則將控制移轉到1 〇 3 4 在步驟1〇3 4中,延遲插入控制器1 006可決定封包中是 否有S ID。若具有S ID,則控制移轉到步驟1 〇 3 8 ;若不具 有,則控制移轉到步驟1036。 在步驟1036中,延遲插入控制器1〇〇6可決定平均跳動 j是否大於預設臨界。例如,此處臨界可以是封包緩衝器 1 004的長度。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.
若平均跳動j大於預設臨界,則控制移轉到步驟1 〇 3 8 ;若未大於,則控制直接移轉到步驟1 040。 、在步驟1 〇 3 8中,延遲資訊模組1 〇 〇 7可統合插入延遲的 尺寸和時序資訊,然後將控制移轉到步驟1 040。 在步驟1040中,可將有關插入延遲的資訊輸出到實施 控制器1 005。 圖1 0D爲習知技術封包實施控制處理的流程圖。封包 實施控制處理可以是用於圖10A所不之第一習知技術配置 的接收器側裝置1 092中之接收器側處理的一部分。可由圖 -46 - 200820682 10A所示的封包實施控制器1 005執行封包實施控制處理。 封包實施控制處理開始於步驟1 〇42,在該步驟中,封 包實施控制器1〇〇5可從封包緩衝器1 004(圖10A所示)接收 封包,和可從延遲資訊模組1〇〇7(圖10A所示)接收有關插 入延遲的資訊當作步驟1 040的結果(圖10C所示)。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).
在步驟1 〇 4 4中,封包實施控制器1 0 0 5可決定是否已插 入足夠的封包。若已插入足夠封包,則控制移轉到步驟 1 048 ;若未插入足夠封包,則控制移轉到步驟1 046。 在步驟1 046中,封包實施控制器1 005可插入延遲(如 、以無聲封包或舒適雜訊封包的形式)到從封包緩衝器 1 004所接收到的封包。 在步驟1 048中,封包實施控制器1 005可檢索來自封包 緩衝器1〇〇4的封包。 在步驟1 050中,封包實施控制器1 004可實施從步驟 1046及1 048所產生的封包。 圖10E爲當打開發送器側VAD 1001 (圖10A所示)時之 封包緩衝器1 〇〇4所接收到的封包流之槪要表示圖。如圖 10E的例子所示,所接收到的封包流可包括語音封包1080 、在語音封包1〇 80後面的無聲1 084、接在無聲1 0 84後面的 語音封包1086、接在語音封包1 086後面的無聲1 0 8 8等。無 聲1 084和無聲1 0 8 8表示封包實施控制器1 005未接收到語音 封包期間的時間週期。因爲打開 VAD 1001,所以 VAD 1001已將諸如封包l〇80a及1 086a等第一語音封包的標示 符號位元設定成1。圖10C所示的步驟1 032中可利用値1的 -47- 200820682 標示符號位元以決定何時插入延遲。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.
另外,VAD 1001在無聲1 084的一開始插入SID 1082 ,及在無聲1 08 8的一開始插入SID 1 090。SID 1 082及SID 10 9 0亦可被用在圖10C所示的步驟1034中以決定何時插入 延遲。 鼠10F爲當關掉發送器側VAD 1001(圖10A所示)時之 封包緩衝器1〇〇4(圖10A所示)中所接收到的封包流之槪要 φ 表示圖。因爲VAD 1 〇〇 1中所利用的現存演算法例如在音 樂播放時產生不想要的雜訊或突變語音,所以 VAD 1001 一般會被封包通訊服務供應商關掉,因此無法提供有關語 音活動的資訊。 如圖1 0F的例子所示,所接收到的封包流包括語音封 包1092、接在語音封包1092後面的無聲封包1 094、接在無 聲封包1094後面的語音封包1096、接在語音封包1096後面 的無聲封包1 098等。因爲VAD 1001被關掉,所以不爲以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
φ 無聲封包1 094及無聲封包1098爲代表的無聲週期插入SID 。結果,不執行圖10C所示的步驟1 034(即、偵測SID)。 另外,雖然語音封包1092a具有1的標示符號位元値 ,但是所有剩下的已接收封包都具有0的標示符號位元値 。因此,不執行圖1 0C所示的步驟1〇32(即、決定第一封 包的標示位元値是否被設定成1 )。 另外,當關掉發送器側1091上的VAD 1001時,封包 可連續進來到接收器側1 0 92上的封包緩衝器1 004,使得封 包緩衝器1 004從不會是空的。因此,可視設計而定,不執 -48- 200820682 行圖10C所示的步驟1030(即、決定封包緩衝器1 004是否 是空的)。 因此,.當關掉VAD 1001時,延遲插入控制1006無法 爲決定插入延遲的時·序執行步驟1 03 0、1 032、及1 034。雖 然在圖10C所示的步驟1 036中,延遲插入控制器1 006仍能 夠獲得有關平均跳動j(i)是否大於預設臨界的資訊,但是 該資訊不足以決定插入延遲的時序。例如,當平均跳動 φ j (i)大於預設臨界時,對插入延遲已太遲。結果,在不準 確的時序中插入延遲,產生語音通訊中的突變語音。 而且,即使打開VAD 1001現存的VAD演算法也無法 使VAD 1001能夠精確插入SID。結果,發生語音封包的 前端剪掉及/或後端剪掉,語音品質非接收方想要。 圖1 1 A爲包括適應性緩衝器溢位控制器的第二習知技 術封包語音通訊配置(第二習知技術配置)之接收器側裝置 1 100的方塊圖。如圖1 1 A的例子所示,接收器側裝置1100 # 包括圖1 οA所'示的第一習知技術配置中之接收器側裝置 1 092的組件。此外,接收器側裝置1100包括附加組件1180 。附加組件1 1 80可包括解碼器1 1 1 8、-無聲偵測器1 1 1 6、及 緩衝器溢位控制器1 1 1 4,說明如下: 無聲偵測器1 1 1 6可被組配成偵測從解碼器1 1 1 8所接收 到的封包中之無聲。若具有無聲,則無聲偵測器1 1 1 6可將 無聲旗標値設定成1。若沒有無聲,則無聲偵測器1 1 16可 將無聲旗標値設定成〇。 緩衝器溢位控制器11 14可被組配成監視封包緩衝器 -49 - 200820682 1102的狀態。根據封包緩衝器1102的狀態’緩衝器溢位控 制器1 1 14可決定是否丟掉或保有在封包緩衝器1 102中所接 收的下一封包。 圖1 1 B爲圖1 1 A的例子中所示之接收器側裝置1 1 00所 利用的無聲偵測處理之流程圖。於步驟1 120開始無聲偵測 處理,在該步驟中,解碼器1 1 18(圖1 1A所示)可解壓縮從 封包實施控制器1104(圖11A所示)所接收之語音封包(封包φ 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).
在步驟1124中,無聲偵測器1116(圖11A所示)可決定 是否有無聲在接收封包中。若具有無聲,則控制移轉到 1130,在該步驟中,無聲偵測器11 16將無聲旗標値設定成 1。若沒有無聲,則控制移轉到步驟1 1 26,在該步驟中, 無聲偵測器1 1 1 6將無聲旗標値設定成0。 / 在步驟1128中,無聲偵測器1 1 16可輸出無聲旗標値。 圖1 1 C爲圖1 1 A的例子中所示之接收器側裝置1 1 00中 φ 所利用的緩衝器溢位控制處理之流程圖。可由圖1 1 A所示 的緩衝器溢位控制器1114執行緩衝器溢位控制處理。在步 驟1132開始緩衝器溢位控制處理,在該步驟中,緩衝器溢 位控制器1 1 14接收來自無聲偵測器1 1 16(圖1 1A所示)的無 聲旗標値。 在步驟1134中,緩衝器溢位控制1114可決定封包緩衝 器1102(圖2A所示)是否已到達第一臨界,諸如剛好100% .等。若封包緩衝器1 1 02已到達第一臨界,則控制移轉到步 驟1 1 44 ;若未到達,則控制移轉到步驟1 13 6。 -50- 200820682 在步驟1144中,緩衝器溢位控制器1114可命令封包緩 衝器1102丟棄最近接收到的封包,不管最近接收到的封包 是否表示語音封包。緩衝器溢位控制器1114亦可命令封包 緩衝器1 102提供欲實施的封包。 在步驟1136中,緩衝器溢位控制器11 14可決定封包緩 衝器1102是否已到達第二臨界,諸如剛好80%等。若封包 緩衝器1 102已到達第二臨界,則控制移轉到步驟1 140 ;若 φ 未到達,則控制移轉到步驟1 1 3 8。 在步驟1140中,緩衝器溢位控制器1114可決定從無聲 偵測器1 1 1 6接收到的無聲旗標値是否是1。若無聲旗標値 是1,則控制移轉到步驟1 1 42 ;若不是,則控制移轉到步 驟 1 1 3 8 〇 在步驟1142中,緩衝器溢位控制1114可命令封包緩衝 器1 1 02丟棄最近收到的封包,因爲最近收到的封包表示無 聲。緩衝器溢位控制器1 1 1 4亦可命令封包緩衝器1 1 02提供 φ 欲實施的封包。然後控制移轉到步驟1 1 3 8。 在步驟1 138中,封包緩衝器1102可接收和緩衝封包。 圖1 1 C的例子中所示之緩衝器溢位控制處理對維持服 務品質無效。例如,當封包緩衝器1 1 02到達第一臨界,如 、剛好100%時,可根據步驟1144丟棄語音封包。因此, 產生突變語音。另外,當封包緩衝器1 1 02到達非第一臨界 的第二臨界,如、非剛好100%的剛好80%時,封包緩衝器 1 102仍然接收比封包緩衝器1 102的剩下容量還大之語音封 包的資料組。結果,溢位仍舊發生,及超過封包緩衝器 -51 - 200820682 11 02的容量之封包(包括語音封包)仍舊會損失。結果,服 務品質非接收方所想要的。 圖1 2 A爲根據本發明的一或多個實施例之具有適應性 跳動處理的封包語音通訊系統之接收器側裝置1200的方塊 圖。接收器側裝置1200可表示諸如電話、行動電話、電訊 會議裝置、聲頻播放器、或視頻電話等使用者裝置。另一 選擇是,接收器側裝置1 200可表示封包通訊網路中的伺服 φ 器裝置。 圖12A的例子所示一般,接收器側裝置1 200可包括一 或多個下面組件:封包緩衝器1202、封包實施控制器1208 、解碼器1 2 1 0、延遲插入控制器1 2 1 4、延遲資訊模組1 2 1 6 、跳動計算機1 204、和實施延遲計算機1 206。接收器側裝 置1 200可另外包括被組配成偵測特徵化內容之偵測器,諸 如偵測無聲的無聲偵測器12 12等。無聲偵測器12 12可被組 配成接收來自解碼器1 2 1 0的經解壓縮封包。無聲偵測器 φ 1 2 1 2可另外被組配成處理經解壓縮封包,並且經由鏈路 1299提供無聲旗標(但是非經解壓縮封包)給延遲插入控制 器 1214 〇 可在被下載到接收器側裝置1 200內的軟體中包括一或 多個組件。 接收器側裝置1200的一或多個組件可具有類似於圖 11A所示的接收器側裝置1100之組件的能力。然而,與接 收器側裝置11 〇〇的無聲偵測器1116相反地,無聲偵測器 12 12可被組配成決定何時插入處理跳動的延遲以取代控制 -52- 200820682 封包緩衝器溢位,或除了控制封包緩衝器溢位之外還加上 此功能。 另外,與接收器側裝置1100的延遲插入控制器1108相 反地,延遲插入控制器1214可接收來自無聲偵測器1212的 資訊以取代習知技術跳動緩衝設計中之接收來自跳動計算 機1204的資訊。 延遲插入控制器12 14可經由鏈路1299直接耦合到無聲 φ 偵測器1212。鏈路1 299可表示直接邏輯鏈路或實體鏈路。 與圖11A的例子所示之延遲插入控制器1108和跳動計算機 1 1 1 〇之間的鏈路1 1 99與圖1 0 A的例子所示之跳動計算機 1 008和延遲插入控制器1006之間的鏈結1 099相反地,在跳 動計算1 2 04和延遲插入控制器1 2 1 4之間沒有直接邏輯或實 體連接。 圖1 2B爲根據本發明的一或多個實施例之用於圖1 2A 的例子所示之接收器側裝置1 200中所利用的適應性跳動處 φ 理所用之延遲插入控制處理圖。延遲插入控制處理開始於 步驟1 220,在該步驟中,延遲插入控制器1214(圖12A所 示)可決定封包緩衝器1202(圖12A所示)何時是空的,即沒 有包含實施的封包。若封包緩衝器1202是空的,則控制移 轉到步驟1228 ;若不是空的,則控制移轉到1222。 在步驟1 2 2 2中,延遲插入控制器1 2 1 4可決定在經由封 包緩衝器1202所接收到的進來封包中設定値〗的標示符號 位元。若具有SID,則控制移轉到步驟1228 ;若未具有 SID,則控制移轉到步驟1 226。 -53- 200820682 在步驟12 26中,延遲插入控制器1214可決定從無聲偵 測器1212(圖12A所示)所接收到的無聲旗標値是否是i。 若無聲旗標値是1,則可將控制移轉到步驟1 228 ;若不是1 ,則控制可移轉到步驟1 2 3 0。 在步驟1228中,封包實施控制器1 208(圖12A所示)可 根據延遲資訊模組1 2 1 6 (圖1 2 A所示所接收到的資訊插入 延遲(如、無聲封包或舒適雜訊封包等)到進來的封包以產 φ 生經調整封包。延遲資訊包括實施延遲計算機1206(圖3A 所示)所提供的尺寸資訊和延遲插入控制器1214所提供的 時序資訊。 在步驟1 23 0中,封包實施控制器1208可實施經調整封 包。由解碼器1 2 1 0解壓縮經調整封包,然後由接收器側裝 置1200實施。 如從圖12B可明白一般,根據本發明的一或多個實施 例,即爲從跳動計算機1 204接收到任何資訊,延遲插入控 φ 制器12 14仍可依據從無聲偵測器1212(在步驟1226中)所接 收到的無聲旗標値來決定插入延遲的時序。 圖1 3爲根據本發明的一或多個實施例之利用調整性跳 動處理之封包視頻通訊系統的接收側裝置1300之方塊圖。 接收側裝置1 3 00可表示電話、行動電話、電訊會議裝置、 視頻電話、及視頻播放器的至少一者。另一選擇是,接收 器側裝置1 3 00可表示封包通訊網路中的伺服器裝置。 接收器側裝置1 3 00可包括執行類似於圖3A的例子中 所示之接收器側裝置1200的組件之功能的功能之組件。接 -54- 200820682 收器側裝置1 300可包括封包緩衝器1302、跳動計算機1304 、補償控制器1314、補償計算機1306、補償資訊模組1316 、封包實施控制器1 3 08、解碼器13 10、及視頻偵測器13 12 中的一或多個。 不同的是視頻偵測器1 3 1 2可被組配成偵測視頻封包中 的無移動或低移動以取代無聲。另外,補償計算機1 3 06、 補償控制器1 3 1 4、及補償資訊模組1 3 1 6可被組配成計算和 φ 統合視頻補償的資訊以取代被組配成計算和統合延遲插入 的資訊。視頻補償可包括在重複視頻圖框的同時停止播放 新的視頻圖框,並且可由封包實施控制器1 3 08執行。 類似於接收器側裝置1200的組態,補償控制器13 14可 經由鏈路1 399直接耦合到視頻偵測器1 3 12以決定視頻補償 的時序。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.
用於接收器側裝置1 3 00之跳動處理的視頻補償控制處 理與圖1 2B的例子中所示之延遲插入控制處理類似。 本發明的一或多個實施例包含接收器側裝置,該接收 器側裝置包括類似於接收器側裝置1 300的組態之組態,並 且被組配成處理包括語音和視頻之多媒體通訊中的跳動。 另外,本發明的一或多個實施例可包含類似於圖1 2 B的例 子中所示之延遲插入控制處理的延遲插入控制和視頻補償 控制處理。 如從上述可明白一般,本發明的實施例可有效處理封 包通訊中的跳動,卻不必依賴發送器側語音活動偵測器 (VAD)或固定式跳動緩衝設計。爲延遲插入控制以取代只 -55- 200820682 爲緩衝器溢位控制使用接收器側無聲偵測器,本發明的實 施例可準確地插入延遲,卻不需要插入延遲到語音封包。 有利的是,可降低突變的語音,確保語音品質。另外,本 發明的實施例可用於視頻通訊及/或多媒體通訊。 D.Divitas 描述協定(DDP) 本發明的一或多個實施例包括透過SIP的輕量協定, φ 其將在伺服器和用戶之間有效傳送資訊,且將在不受硬體 和軟體平台支配之下運作。 DDP的架構;已在考量下面因素之下架構DDP: 不受伺服器和用戶軟體及OS的支配:協定(DDP)的 結構和格式係成DDP不知道伺服器或手機硬體平台與在 -兩平台上執行的作業系統。根據本發明的一或多個實施例 協定被架構和設計成在任何伺服器或手機硬體平台上執 φ 行,且也不受執行之Operating System/SW平台的支配。 例如,可在 Linux、Symbian、Windows Mobile 5.0等上執 行DDP。總之,每次以轉移此模組到新的硬體或軟體平台 上時都不必設計或發展特定的配接器層。 從控制面協定解耦:DDP已被架構成能夠與在特定平 台(即SIP、H.323等)上使用的任何控制面技術一起使用。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.).
不受傳送協定的支配:被設計成當透過UDP和TCP 二者使用時有效。若透過傳送層使用是最好的選擇,則具 有一隨意模組以保證可靠度和性能的位準(使用ACK/NACK -56- 200820682 和視窗機構)。尤其是具有高度封包遺失的環境中,此可 靠模組去除較高層應用程式擔心保證運送的負擔。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.
智慧型和不在意應用程式:DDP將被用於從具有嚴格 的即時要求之緊要控制面訊息到需要在伺服器和用戶之間 移轉大量資料的應用程式之廣泛的應用程式範圍。DDP內 的隨意模組使廬用程式能夠在伺服器和用戶之間移轉檔案 和緩衝區。協定亦不在意應用程式資料的類型一即二元、 本文。 服務優先權位準:能夠爲具有不同延遲和服務要求的 應用程式排程和佇列具有不伺優先權位準之訊息。 加密的支援:DDP內的隨意模組使伺服器和手機能夠 在啓動時建立安全通道,並且DDP的所有進一步交換都 被加密,以提供一安全位準給需要加密的應用程式。此將 仍舊讓應用程式能夠爲不需要加密的此種應用程式交換未 加密訊息。 內建對話管理:具有特定控制訊息以啓動和維持伺服 器和用戶之間的對話。 不受媒體支配:協定不受將用戶連接到伺服器之媒體 的支配。對話可透過WiFi、蜂巢式資料通道、或有線乙 太網路。 圖6A爲根據本發明的一或多個實施例所製造之DDP 架構的槪要圖。如圖6A所示,DDP是透過SIP協定所執 行的對話層應用程式。在用戶和伺服器之間傳輸加密的應 用層資訊被用於影響傳訊決定,提供對話持久性給資料應 -57- 200820682 用程式,諸如電子郵件或SMTP等,但並不侷限於此。圖 6A爲組成DDP的不同模組之高階圖。此處槪要說明根據 本發明的一或多個實施例之DDP內的不同模組。 i. DDP訊息處理器:此由剖析器和訊息格式化模組所 組成。剖析器負責檢查所接收到的DDP訊息之有效性, 並且在召喚回收處理器之前析取各種資訊片段。 ii. 對話管理:評估兩同層之間的DDP對話之健康的 φ 內建機構,及若對話失敗則告知已註冊應用程式的機構。 iii. DDP排程器:依據應用程式要求以提供不同優先 權位準給DDP訊息。 iv. 可靠的DDP模組:視應用程式要求而定保證可靠 運送DDP訊息之支援。 v. DDX(Divitas資料移轉)模組:使用 DDP以移轉同 層之間的檔案和資料緩衝區之模組。DDX模組將不受檔 案格式或緩衝內容的支配加以運作,並且具有用於錯誤檢 # 查和運送確認之機構。 vi. DDPS : DDP中的模組,其在發信封包中插入DDP 之前將DDP內容加密和解密。DDP具有用以在2 Divitas 同層之間建立安全DDP通道之協定。 圖6B爲根據本發明的一或多個實施例之當使用者登 入裝置之一時的用戶起動期間之DDP訊息的交換圖。 根據本發明的一或多個實施例,DDP是層4或應用程 式層協定。DDP可使用TCP、UDP、或TLS作爲傳送用。 類似於SIP或SDP,DDP是內容編碼的協定。根據本發明 -58- 200820682 的一或多個實施例,DDP訊息包含列或欄位的順序,其中 欄位的各列開始於表示正被運送的資訊類型之單一小寫字 母;剩下的列或欄位包含與功能或方法相關聯的資訊之片 段。根據本發明的一或多個實施例,可有多個具有相同開 始名稱或類型的列或攔位。根據本發明的一或多個實施例 ,視正發送的DDP訊息之特定類型而定,各個DDP訊息 包含一組命令列或攔位和任意列或攔位。若命令列遺失, φ 則剖析器將拒絕DDP訊息。跳過剖析器不明白的任意列 。如此允許不同軟體版本之間的向上相容性和可交互運作 性。此處是DDP訊息的例子: ν = 0 · 0 · 0 · 1 o=server r = data 2 c=ext 4444 c = pref cell wifi gprs sms wka 5 cka 10 pwd 1200Smart 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 = q o s delaylo 5 0 d e 1 a y h i 10 0 1 o s s 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 然後添加DDP訊息當作具有“application/ddp”或“ a p p 1 i c a t i ο η / d d p s ”的訊息本體類型之S IP訊息中的訊息本 體。若需要的話,DDP本體易可與其他發送協定一起發送 -59- 200820682 根據本發明的一或多個實施例之DDP的示範性應用 程式將說明如下。 語音行動性:語音行動性視許多因素而定…--主要的 因素是由用戶所感受到的WiFi品質。DDP被用於即時發 送具有有關手機目前所結合之AP的資訊之WiFi報告以 做出行動性決定。WiFi報告亦可任意地包含有關相鄰AP φ 的資訊,使得行動性伺服器可使用此資訊以依據該預測手 機的移動來進行先發制人的行動性決定。除了依據WiFi 條件自動化更新之外,DDP亦被用於使用者啓動行動性決 定。 用戶/裝置管理:將DDP延伸使用在管理手機上的用 戶和使用者經驗。此處有幾種管理用戶所使用之以DDP 爲基的控制和巨量轉移訊息之方法: a ·裝置組態:一旦已認證裝置/使用者,則在啓動期 φ 間發送裝置特定組態到裝置。 b.行動性臨界:依據管理者對用戶的設定之WiFi臨 界以啓動行動性活動。 c·使用者資訊:當使用者登入到用戶之一時,則伺服 器透過DDP推送使用者特定資訊(如、分機、偏好等)。 d·裝置影像管理;使用DDP巨量移轉能力能夠達成 透過網路連接升級手機軟體之能力。 下載到手機的語音郵件/電子郵件: Divitas解決方案 ,的主要差別處之一在於下載語音郵件到手機並且視你方便 -60- 200820682 時間管理它們之能力。藉由與語音郵件系統相接的優先權 控制訊息,可有管理沒有IVR的語音郵件之能力,移轉 語音郵件到手機之DDP中的巨量移轉能力也是一樣。亦 可爲能夠建立配接器模組以與選擇的電子郵件系統相接之 電子郵件系統達成類似的功能。 使用者出席管理:將具有透過不同媒體之語音和內容 的使用者偏好之DDP訊息傳遞到出席管理用的伺服器。 φ 這是能夠支援出席提醒電話的功能之重要部分。會議電話 的架構和設計亦依據增強的出席和使用者偏好一…全部都 透過DDP傳達以提供服務會議電話被設計以提供。 即時訊息:透過DDP對話通隧用於IM的訊息。此使 手機上的IM用戶能不察覺到裝置正在操作的媒體/協定。 可參考下面的圖式和討論更加明白本發明的特徵和優 點。 圖14爲在應用程式用戶與應用程式伺服器之間建立連 φ 接的電話流程之習知技術例子圖。假設手機的使用者想要 利用應用程式用戶1404以經由HTTP(超文件傳輸協定)連 接透過網頁瀏覽器請求軟體下載1406之情況。 在發生軟體下載14 06之前,首先必須在應用程式用戶 1404和應用程式伺服器1402之間建立HTTP.連接。在第一 步驟1 408中,應用程式用戶1404可發送TCP(傳輸控制協 定)SYN(同步化)到應用程式伺服器1 402。在下一步驟1410 中,應用程式伺服器1402可發送TCP SYN-ACK(TCP同步 化應答)回到應用程式用戶1 404。在下一步驟1 4 1 2中,應 -61 - 200820682 用程式用戶1404可發送TCP ACK到應用程式伺服器1402 一旦已在應用程式用戶1404與應用程式伺服器1 402之 間建立HTTP連接,則在下一步驟1414中,應用程式用戶 1404可發送HTTP Get到應用程式伺服器1402。換言之, 在步驟1414中,應用程式用戶1404正發送使用者對軟體下 載1 406的請求到應用程式伺服器1402。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.
當接收到HTTP Get時,在下一步驟1416中,應用程 式伺服器1 402可執行搜尋以找出所請求的下載。 在下一步驟1 4 1 8中,一旦已找出軟體,則應用程式伺 服器1 402可開始發送所請求的軟體當作資料封包(如、TCP 資料區段)到應用程式用戶1 404。在發送所請求的軟體檔 案時,可將軟體檔案分成複數資料封包,以幫助經由網路 處理發送軟體檔案。 在下一步驟1420中,當接收到TCP資料區段時,應 φ 用程式用戶1404可發送TCP ACK到應用程式伺服器1402 可在由應用程式伺服器1 402發送所請求的軟體下載之 所有資料封包到應用程式用戶1 404之前,重複步驟1418及 1 42 0。 一旦已發送所有TCP資料區段,則在下一步驟1422 中,應用程式伺服器1402可發送HTTP 200 OK到應用程 式用戶1 404。在發送HTTP 200 OK時,應用程式伺服器 1 402通知應用程式用戶1404已發送有關軟體下載請求的所 -62 - 200820682 有資料封包。 ' 一旦應用程式用戶1 4 04已接收到各個資料封包,則應 用程式用戶1404可發送通知1424給使用者,告知使用者已 完成下載。 就手機上的各個應用程式用戶而言,必須由各個應用 程式用戶執行圖1的電話流程中所說明之方法。如此,若 手機包括多個應用程式用戶(如、視頻應用程式用戶、語 ^ 音應甩程式用戶、即時訊息應用程式用戶、遊戲應用程式 用戶、虛擬實境應用程式用戶等),則在應用程式用戶與 應用程式伺服器之間的互動開始之前,必須在各個應用程 式用戶與其對應的應用程式伺服器之間建立獨立通道。由 於用戶上執行多個應用程式,所以無法保證不同應用程式 之間的通訊。結果,特定用戶上執行的應用程式未能注意 到在同一用戶上的另一應用程式正發生資料交換。 此外,圖1所說明的方法是種麻煩的方法,其需要用 ® 戶上的各個應用程式適當組配以確保應用程式能夠成功地 與企業內的指定伺服器上之其對應的應用程式互動。由於 在用戶和伺服器之間通訊的各個應用程式需要分開的網路 對話,所以此方法產生安全牲風險並且增加複雜性。 在本發明的一觀點中,在此處,本發明人實現可利用 不受硬體(如、手機)及軟體(如、視頻應用程式用戶、語 音應用程式用戶、即時訊息應用程式用戶、遊戲應用程式 用戶、虛擬實境應用程式用戶等)支配之單一協定統合所 有的應用程式網路對話。換言之,本發明人實現應用程式 -63- 200820682 用戶無須與其對應的應用程式伺服器建立多個網路對話。 取而代之的是,可利用現存的控制和傳輸協定實施協定’ 且協定是獨立於軟體和硬體之外,藉以使複數應用程式用 戶能夠與其對應的複數應用程式伺服器互動。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.
根據本發明的實施例,藉由實施Divitas描述協定 (DDP)提供行動性架構配置。在一實施例中,DDP包括 DDP用戶和DDP伺服器。本發明的實施例使DDP能夠在 手機上的複數應用程式用戶與企業內的複數應用程式伺服 器之間有效地傳輸資料封包。本發明的實施例又使DDP 能夠在不受硬體及軟體平台的支配之下加以實施。 在本發明的實施例中,DDP不受硬體平台时支配。如 此,可在雙模式手機、個人數位助理(PDAs)、802.1 1電話 等上實施DDP。在本發明的實施例中,DDP亦不受軟體 平台的支配。結果,可在Linux®系統、Symbian®系統、 Window TM Mobile 5.0 系統上執行 DDP。 在習知技術中,多個網路對話的建立需要在用戶和伺 服器之間建立多個通道。換言之,必須在企業的防火牆內 ”刺穿”複數個”洞”以使複數應用程式用戶能夠與其對應的 應用程式伺服器互動。在本發明的實施例中,可實施DDP 以建立可實施手機上的應用程式用戶與企業內的應用程式 伺服器之間的互動之單一安全通道。 憑藉可交換複數資料流量的單一安全通道,可由應用 程式用戶管理下載到手機上的資訊。如此,需要利用已下 載的資訊之應用程式用戶不必請求再次下載資料。取而代 -64- 200820682 之的是’具有DDP的行動性用戶能夠引導應用程式用戶 到所請求的資料之儲存位置。 在本發明的實施例中,DDP可不受網路支配。在一例 子中’ DDP所建立的安全通道可例如經由wi-Fi網路或蜂 巢式資料網路。當用戶裝置上的使用者漫遊時,此使DDP 能夠確保網路對話傳送到分開的網路。 在一實施例中,DDP建立在控制協定和傳輸協定的上 ^ 層。在一實施例中,可利用任何可用到的控制協定(如、 SIP、H. 323等)實施DDP。在另一實施例中,可利用諸如 使用者資料元協定(UDP)、傳輸控制協定(TCP)、或傳輸層 安全協定(TLS)等任何可利用到的傳輸協定實施DDP。如 此,DDP能夠有效地路由資料封包和管理連接性而不必關 心可利用的控制及/或傳輸協定。 在本發明的實施例中,DDP可包括可靠性模組 (RDDP),該模組確保遞送資料流量的可靠性位準。當利 φ 用不提供可靠性之諸如UDP等傳輸協定時使用此模組。 如此,DDP可提供成功傳輸的保證並且解除監視來自應用 程式用戶的資料流量之負擔。 在本發明的實施例中,可爲複數應用程式(即、應用 程式用戶和其對應的應用程式伺服器)實施DDP。在一例 子中,可由不需要即時交換資料的簡易應用程式利用DDP 。在另一例子中,可由具有即時資料交換要求之應用程式 利用DDP。由於DDP的可調整性,可添加或去除應用程 式卻不會影響DDP的能力和多樣性。 -65- 200820682 在本發明的實施例中,DDP包括可被組配成排程和佇 列資料流量之優先權訊息排程模組。DDP可利用該優先權 訊息排程模組將複數應用程式需要或要求的複數下載和上 載自動化。 參考下面的圖式和討論可更加明白本發明的特徵和優 點。 圖15爲本發明的實施例中之DDP發明的簡易架構圖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
。在本發明的實施例中,DDP 1 53 6不受硬體及/或軟體平 台的支配。在一例子中,可將DDP 1536實施在複數用戶 裝置上,包括雙模式手機、PDAs、膝上型電腦等,但並 不侷限於此。在另一例子中,可與諸如L i n u X ®系統、. 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,
Symbian®系統、Windo w ΤΜ Μobi 1 e 5 · 0系統等不同的操作 系統一起實施DDP 1 5 3 6。結果,利用最小的修改,可將 DDP 1 5 3 6載入到不同的硬體及/或軟體平台上。 DDP 1 53 6可建立在控制協定和傳輸協定的最上層。 在一例子中,可與不同控制協定類型(如、SIp 1 53 2和另 一控制協定1 524)和不同的傳輸協定類型(如、UDP 1 534、 UDP 1 528、TCP 1 5 3 0、TCP 1 526等)一起使用 DDP 1 5 3 6。 可爲了執行DDP 1 5 3 6的功能而由DDP 1 5 3 6利用之控制協 定及/或傳輸協定的類型可容易由DDP適應。如此,若控 制協定及/或傳輸協定改變,則DDP 1 5 3 6將視需要使本身 能夠利用可用到的傳輸和控制協定之任何組合。需注意的 是,控制協定及/或傳輸協定的改變不影響應用層,應用 層包括語音行動性控制應用程式用戶1 506、裝置管理應用 -66- 200820682 程式1 504、企畫管理應用程式1 502、語音郵件/電子郵件 傳輸應用程式1508、裝置影像管理應用程式1510、即時訊 息應用程式15 12等,但並不侷限於此。 此外,在一實施例中,DDP 1 53 6能夠決定提供最佳 的性能和可靠性之較佳的傳輸協定。如此,辨識正確的傳 輸協定責任可從複數應用程式集中和移動到DDP 1 5 3 6。 因爲DDP用戶和.伺服器之間的所有資料流量現在都由 φ DDP 1 5 36處理,所以DDP 1 5 3 6能夠在最小化資料封包損 失的同時決定路由資料流量的最佳傳輸協定。 在一實施例中,DDP 1536可包括一或多個模組,諸 如具有安全延伸的DDP模組(DDPS模組1 522)、優先權訊 息排程模組1518、可靠DDP模組(RDDP模組1516)、內建 對話管理模組1 520、及Divitas資料交換模組(DDX模組 1514) ° 在一實施例中,DDPS模組1 522可提供安全功能給 φ DDP 1 53 6。在一例子中,DDPS模組1 522可使安全通道能 夠建立在手機的行動性用戶和企業內的行動性伺服器之間 。憑藉安全通道,可經由單一安全通道路由來自複數應用 程式之所有進來和出去的資料流量。 在某些情況中,在應用程式用戶能夠與其對應的應用 程式伺服器互動之前必須發生個別認證。不像習知技術一 般,認證處理可以自動化。在一實施例中,DDPS模組 1 522可包括資料庫,該資料庫包括在應用程式用戶和應用 程式伺服器之間建立連接所需的認證資料。 -67- 200820682 在本發明的實施例中,DDPS模組1 522可提供加密/解 密功能,如此使DDP 1 53 6能夠提供安全給需要該功能的 應用程式在一例子中,從電子郵件伺服器路由來自應用程 式用戶1 50 8的重要電子郵件到手機上的電子郵件應用程式 用戶。爲了確保電子郵件的安全性,在發送封包到對應的 應用程式伺服器之前,DDPS模組1 522可將資料封包加密 。在另一例子中,可以非安全方法發送兩IM用戶之間的 φ 即時訊息。如此,DDP 1 53 6可路由即時訊息,卻不必利 用DDPS模組1 522加密發送於IM用戶之間的資料封包。 在本發明的實施例中,DDP 1 5 3 6可包括優先權訊息 排程模組1 5 1 8,該模組1 5 1 8可被組配成排程和佇列資料封 包。換言之,優先權訊息排程模組1518負責管理DDP 1 53 6所服務之複數不同的資料封包。在一實施例中,優先 權訊息排程模組1 5 1 8可建立處理進來和出去的資料封包之 政策。在一實施例中,優先權訊息排程模組1 5 1 8視發源的 φ 應用程式而定,可具有不同的優先權位準。在一例子中, 應用程式A(如、電子郵件)不要求即時遞送棋資料封包。 然而,應用程式B(如、出席管理)對時間延遲相當敏感, 需要即時遞送資料封包。在一實施例中,優先權訊息排程 模組151 8可以是任意的DDP模組。在一例子中,若DDP 1 53 6目前只爲一應用程式處理資料流量,則DDP 1 5 3 6不 必利用優先權訊息排程模組1 5 1 8處理資料封包的排程。 在本發明的實施例中,DDP 1 53 6可包括可靠模組 (RDDP 1516),其可提供運送複數資料封包之一定位準的 -68- 200820682 保證。在一實施例中,爲了擔保運送,RDDP 15 16具有重 傳在特定時間間隔內未成功到達它們的目的地之封包的機 構。在一實施例中,若在預設的時間間隔內未接收到資料 封包,則將重傳封包。在通知應用程式封包的傳輸已失敗 之前可重傳封包特定次數。憑藉RDDP 1516,DDP 1536 可提供以應甩程式需要的次序發送及/或接收資料封包之 保證。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.
在一實施例中,DDP 1 53 6可包括DDX模組1514,其 可被用於在行動性用戶和行動性伺服器之間傳輸大量資料 (如、影像檔案、日誌檔案等)。在實施例中,DDX模組 1 5 1 4包括確保行動性用戶和行動性伺服器之間的資料傳輸 之資料完整性的機構。在本發明的另一實施例中,DDX 模組1514可包括用以確認完成資料傳輸到應用程式之機構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.
在本發明的實施例中,可爲複數應用程式實施DDP # 1 536,複數應用程式包括語音行動性控制應用程式1 506、 裝置管理應用程式15 04、企畫管理應用程式15 02、語音郵 件/電子郵件傳輸應用程式1 508、裝置影像管理應用程式 1510、即時訊息應用程式15 12等,但並不侷限於此。在本 發明.的實施例中,複數應用程式可被分成兩群。 在第一群中,複數應用程式(如、語音郵件/電子郵件 傳輸應用程式1 5 08、裝置影像管理應用程式1510、即時訊 息應用程式15 12等)是容易發送較大檔案的應用程式,如 此DDP 153 6可利用DDX模組15 14將檔案轉換成能夠利用 -69 - 200820682 包括1516、1518、1 522之DDP 1 5 36內的任何其他模組之 較小的資料封包,並且提供已成功傳輸資料檔案並且通知 應用程式有關已完成的傳輸之保證。 在第二群中,複數應用程式(語音行動性控制應用程 式1 506、裝置管理應用程式1 504、企畫管理應用程式1502 等)通常是容易發送較小控制訊息的應用程式。通常,第 二群中的應用程式傾向是控制應用程式。在一例子中,語 φ 音行動性控制器1 506可使行動性用戶和行動性伺服器能夠 共用可以單一 DDP封包發送之行動性狀態。 圖16A爲在一實施例中之具有DDP的行動性架構配 置內之資料如何在在位在用戶裝置內的應用程式用戶與企 業所管理的應用程式伺服器之間流動的例子圖。假設用戶 裝置上的使用者想要利用語音郵件用戶1 602檢索來自語音 郵件伺服器1 604的語音郵件之情況。 當接收到來自應用程式用戶1 602的請求時,語音郵件 Φ 伺服器1 604可啓動檔案轉移。語音郵件伺服器1 604可沿著 路徑1 65 0發送檔案。當接收到檔案時,行動性伺服器可經 由安全通道準備欲發送檔案到用戶裝置上的行動性用戶。 在一實施例中,行動性伺服器內的伺服器DDX模組 1 6〇 8可被用於將檔案轉換成與安全通道的控制和傳輸協定 相容之格式。在一例子中,伺服器DDX模組1 608可將雙 格式的檔案轉換成透過SIP協定可傳輸的格式。再者,伺 服器DDX模組1 608可將檔案分成複數資料封包,以確保 經由安全通道路由複數資料封包之有效性。 -70- 200820682 在完成啓動處理之後,伺服器DDX模組16〇8可發送 第一資料封包到伺服器DDP 1 6 1 6。在一實施例中,伺服 器DDP 16 16可包括是應用程式所需將資料封包加密之 DDPS模組。在一例子中,無須加密即可發送簡易資料封 包(如、即時訊息)。在另一例子中,可在路由到請求者之 前將重要的資料封包(如、機密電子郵件)加密。 從伺服器DDP 161 6出來,第一資料封包可被封裝作 φ SIP通知訊息(如圖16B的碼例子3 70所示),並且經由網路 1 624透過安全通道發送到用戶裝置。在一例子中,可藉由 使用伺服器SIP控制協定1 620和伺服器UDP傳輸協.定 1 622且經由安全通道發送第一資料封包。由可經由用戶 UDP傳輸協定1 626和用戶SIP控制協定1 628接收到資料封 包之用戶裝置的行動性用戶安全地接收到第一資料封包。 在行動性用戶內,用戶DDP 1 63 2可接收第一資料封 包。用戶RDDP 1 634可執行與伺服器RDDP 1614所執行的 φ 類似檢查。再者,用戶RDDP 1 634可沿著路徑1 652經由安 全通道發送具有DDP應答的SIP通知訊息到伺服器DDX 模組1 608。藉由發送DDP應答,用戶RDDP 1 634可從行 動性用戶發送保證到已接收到資料封包的行動性伺服器。 同樣地,若伺服器RDDP模組1614未接收到RDDP應答, 則伺服器RDDP模組1614將重傳資料封包,直到已成功應 答封包或耗盡重試的最大數目爲止。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.
在一實施例中,將發送資料封包且在已接收到DDP 應答之前,不發送下一資料封包。在一例子中,在已接收 -71 - 200820682 到DDP應答之前,伺服器DDX模組1 608不發送第二資料 封包。在另一實施例中,可發送固定的資料封包數目,及 在已爲一或多個最初資料封包接收到應答之前,不發送額 外封包。在一例子中,伺服器D D X模組1 6 〇 8可發送一群 1 〇資料封包,及在能夠傳輸額外資料封包之前,在至少接 收到一應答前需要等待。 一旦行動性用戶已發送DDP應答到行動性伺服器, φ 則將路由資料封包到用戶DDX模組1636。在一例子中, 在已接收到所有資料封包之前,用戶DDX模組1 63 6可保 留資料封包。在一實施例中,伺服器DDX模組1 608可發 送指出已發送所請求的檔案之各個資料封包並且沒有額外 的檔案資料封包即將到來之訊息。一旦已接收到所有資料 封包,則用戶DDX模組1 63 6將重組檔案,且通知語音郵 件用戶1 602可利用語音郵件檔案。 如從圖15及16可見一般,DDP的架構可提供複數應用 φ 程式用戶與複數應用程式伺服器互動的單一安全通道。藉 由具有流經單一安全通道的資料流量,DDP的架構可藉由 保證接收到資料封包、已進行核實以便得知已接收到所有 資料封包、並且沒有損失的資料封包以提供控制。在一例 子中,DDP的架構可使大的檔案被分成較小的資料封包, 這些較小的資料封包可利用由接收側接收應答的保證加以 發送。 圖1 7爲在本發明的實施例中之如何在用戶裝置和行動 性伺服器之間建立安全通道的電話流程之例子圖。在一實 -72- 200820682 施例中,爲了建立安全通道,發生註冊。假設使用者第一 次啓動用戶裝置的情況。 在第一步驟1 724中,首先必須建立SIP註冊。在一例 子中,用戶SIP 1716可經由伺服器UDP 1714發送SIP註 冊請求。可經由伺服器UDP 1712以伺服器SIP 1710接收 SIP註冊請求。 當接收到SIP註冊請求時,伺服器SIP 1710可透過伺 φ 月艮器UDP 171 2和用戶UDP 17 14發送SIP註冊回應1 726到 用戶SIP 17 16。一旦已成功完成SIP註冊,則啓動建立安 全DDP通道的步驟。 在下一步驟1728中,用戶 DDPS模組1718(用戶 DDP 1720的模組)將發送DDPS對話請求到伺服器DDPS模組 1 708。在一例子中,可經由用戶 SIP 1716、用戶 UDP 1714、伺服器UDP 1712、伺服器SIP 1710將DDPS對話 請求路由到伺服器DDPS模組1 708。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.
當接收到DDPS對話請求時,在下一步驟1730中,伺 服器DDPS模組1 708將透過伺服器SIP 1710、伺服器UDP 17 12、用戶UDP 1714、及用戶SIP 171 6發送DDPS對話 回應1 73 0到用戶DDPS模組1718。一旦已建立安全通道, 則使用者必須向行動性伺服器註冊。爲了通知使用者,用 戶00?8 1718可將00?3對話回應轉寄到應用程式用戶 1722 ° 當接收到通知時,在下一步驟1 732中,應用程式用戶 1 722發送DDP註冊請求到使用者/裝置管理器1704。在一 -73- 200820682 例子中,應用程式用戶1 7 22可發送註冊資訊到用戶 DDP 1720。用戶DDP 1 720可經由已建立的安全通道(即經由用 戶 DDPS 模組 1718、用戶 SIP 1716、用戶 UDP 1714、伺 服器UDP 17 12、伺服器SIP 1710、及伺服器DDPS模組 1 708)發送註冊資訊到DDP 1 706,後者然後將註冊資訊路 由到使用者/裝置管理器1704。 當接收到註冊資訊時,在下一步驟1 732中,使用者裝 φ 置管理器1 704可發送DDP註冊回應到應用程式用戶。在 一例子中,使用者裝置管理器1 704發送DDP註冊回應到 伺服器DDP 1 706。伺服器DDP 1 70 6經由已建立的安全通 道(即經由伺服器DDPS 1 708、伺服器SIP 1710、伺服器 UDP 1712、用戶 UDP 1714、用戶 SIP 1716、及用戶 DDPS 1718)發送註冊資訊到DDP 1 720,後者然後將DDP 註冊回應路由到應用程式用戶1 722的使用者。 在具有DDP的行動性架構配置中,註冊可以是一次 φ 事件。在一例子中,當用戶裝置第一次啓動時,用戶裝置 將向行動性伺服器註冊。因爲在步驟428及430已建立安全 通道,所以用戶裝置的使用者可確保已將發送的敏感性註 冊資訊加密並且經由安全通道。在一實施例中,只要用戶 裝置和行動性伺服器之間的安全通道維持著就不需要再發 生額外的DDP註冊。在一實施例中,用戶裝置上的應用 程式用戶與企業所管理的應用程式伺服器之間的互動現在 可經由單一安全通道加以安全地實施。圖18及19圖示在一 實施例中,DDP如何處理用戶裝置上的應用程式用戶與企 -74- 200820682 業所管理的應用程式伺服器之間的互動之例子。 圖1 8爲在一實施例中的必須發送大檔案之情況的簡易 電話流程圖。假設用戶裝置需要下載最新的軟體升級之情 況。在一例子中,應用程式用戶181 4發送軟體升級的請求 1 8 1 6到負責管理伺服器側上的不同軟體影像之影像管理器 1 802 °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 °
在第一步驟1818中,應用程式用戶1814發送新的影像 請求到影像管理器1 802。在一例子中,首先將新的影像請 求從用戶應用程式1 8 1 4發送到用戶 DDP 1 8 1 0。在接收到 新的影像請求之後,DDP 1 8 1 0可經由安全通道發送請求 到伺服器DDP 1 808。在發送到影像管理器1 802之前,可 將新的影像請求路由到負責決定需要升級哪一軟體的裝置 /使用者管理器1 804。在裝置/使用者管理器1 804已決定用 戶裝置需要哪一軟體升級之後,裝置使用者/管理器1804 可路由新的影像請求到影像管理器1 8 02。 當接收到請求時,然後影像管理器1 802發送所請求的 軟體升級(如、所請求的資料1802)到伺服器DDX模組 1806。在一實施例中,伺服器DDX模組1 806可將檔案轉 換成能夠經由用戶裝置和行動性伺服器之間所建立的安全 通道加以發送之格式。在一實施例中,伺服器DDX模組 1 80 6將大檔案分成複數資料封包以便經由安全通道運輸。 在下一步驟1 822中,伺服器DDX模組1 806可透過伺 服器DDP 1 808和用戶DDP1810發送DDX檔案轉移開始到 用戶DDX模組1 8 1 2。在一實施例中,DDX檔案轉移開始 -75- 200820682 意指即將發送檔案的伺服器DDX與用戶DDX之間的通知 ° DDX檔案轉移開始可包括有關諸如檔案名稱、檔案大 小、發送的資料封包數量、請求檔案的應用程式等進來檔 案之基本資訊。 在下一步驟1824中,用戶DDP 1810可發送DDX開始 回應到伺服器DDX 1 806。在一實施例中,DDP內的 RDDP模組可發送DDX開始回應。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.
在下一步驟1 826中,伺服器DDX模組1 806可發送第 一 DDX資料封包到用戶DDX模組1812。如圖16所說明一 般,首先將DDX資料訊息發送到伺服器DDP 1 808。在一 實施例中,將DDX資料訊息封裝成SIP通知訊息,且透 過SIP控制協定和UDP運輸協定經由安全通道發送。在 用戶裝置上,可由用戶DDP 18 10接收DDX資料訊息,然 後用戶DDP 1810可路由DDX資料訊息到用戶DDX模組 1812 ° 在下一步驟1828中,當接收到DDX資料訊息時,將 由用戶 DDP 1810發送DDP應答。在一實施例中,用戶 DDP 1810內的RDDP模組將發送DDP應答以通知伺服器 DDX模組1 8 06已成功接收到進來的DDX資料訊息。 步驟1 826及1 828是反覆步驟,可以重複直到伺服器和 用戶DDX模組之間已交換所有DDX資料封包和應答。 一旦已發送最後的DDX資料訊息和DDX應答,則在 下一步驟1 8 3 0中,伺服器DDX模組1 806將發送DDX檔案 轉移結束到應用程式用戶1 8 1 4以通知應用程式用戶已發送 -76- 200820682 所有DDX資料訊息。在一例子中,可從伺服器DDX模組 1 806發送DDX檔案轉移結束到伺服器DDP 1 808到用戶裝 置。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.
可由用戶£)〇?18 10接收到〇〇又檔案轉移結束。在一 實施例中,在下一步驟1832中,用戶DDP 1810的RDDP 可發送DDP應答到影像管理器18〇2。 同時’用戶DDP 1810可路由DDX檔案轉移結束到用 φ 戶DDX模組1812,後者將通知應用程式用戶1814。 如同圖1 8可明白一般,不必爲了請求軟體升級而建立 新的安全通道。取而代之的是,在不必建立新的安全通道 之下’由應用程式伺服器接收和處理軟體升級的請求。也 可看出’圖18圖示如何利用DDP的架構以安全且可靠的 方式發送資料流量,讓發送者和請求者確保已成功接收所 請求檔案的所有資料封包。 圖1 9爲本發明的實施例中之可發送諸如控制應用程式 φ 所發送者等小控制訊息的情況之簡易電話流程圖。在圖1 9 中’可在沒有DDX模組之下發生應用程式用戶與應用程 式伺服器之間的互動。 假設用戶裝置的使用者想要共用他或她的使用者出席 (如、可利用、忙碌、只有電話等)之情況。 在第一步驟1914中,用戶裝置上的用戶出席管理器 19 10可將出席偏好設定發送到伺服器出席管理器1 902。在 一例子中,用戶出席管理器1910可將出席偏好設定(當作 單一 DDP資料封包)發送到用戶DDP 1908,然後後者經 -77- 200820682 由安全通道將出席偏好設定發送到伺服器DDP 1 906。 當接收到出席偏好設定時,在下一步驟1 9 1 8中,伺服 器DDP 1906可發送DDP應答。在一實施例中,DDP內的 RDDP模組可發送DDP應答。同時,伺服器DDP 1 906將 經由裝置/適用者管理器1 904通知伺服器出席管理器1902 有關出席偏好設定。 假設同一使用者想要發現另一使用者的出席狀態之另 φ 一情況。 在第一步驟1 922中,用戶出席管理器1910可將出席詢 問1920發送到用戶DDP 1908,後者可經由已建立安全通 道發送出席詢問到伺服器DDP 1 906。當接收到出席詢問 時,伺服器DDP 1 906將經由裝置/使用者管理器1904轉寄 詢問到伺服器出席管理器1 902,後者可執行所請求的詢問 以檢索所請求的資訊。 在下一步驟1 92 8中,伺服器出席管理器1 902可將出席 φ 回應(如、所請求的狀態資料)發送到用戶出席管理器1910 。在一例子中,可經由裝置/使用者管理器1 904將出席回 應從伺服器出協管理器1902發送到伺服器DDP 1 906。然 後,經由安全通道將出席回應發送到用戶DDP 1 908,而 用戶 DDP 1 908然後將出席回應路由到用戶出席管理器 1910 〇 如上述,圖18及19圖示如何將DDP用於管理用戶裝 置上的複數資料應用程式與企業所管理的複數應用程式伺 服器之間的互動之不同的例子。具有DDP的行動性架構 -78- 200820682 配置建立各個應用程式用戶和應用程式伺服器可彼此互動 之單一通道。再者,可利甩DDP的架構以安全和可靠的 方式發送資料流量,使發送者和請求者確保已成功接收所 請求檔案的所有資料封包。 因爲具有DDP的行動性架構配置現在可以是控制的 中心,所以具有DDP的行動性架構配置現在可協調用戶 手機的使用者事先已個別管理的各種活動。在一例子中, φ 圖1 8圖示如何利用DDP管理用戶裝置上之使用者的經驗 ,包括軟體升級、裝置組態、及使用者資訊管理等,但並 不侷限於此。在另一例子中,DDP可藉由讓使用者能夠共 用其狀態以管理使用者的出席(如見圖1 9),如此使系統能 夠管理進來的流量和讓其他人能夠看見他或她的狀態。在 另一例子中,DDP可藉由讓使用者從一資料網路漫遊到另 一資料網路以管理行動性,卻不必擔心對話管理。 如從本發明的實施例可明白一般,具有DDP的行動 φ 性架構配置藉由提供用戶裝置上的多個應用程式能夠與企 業伺服器上的複數應用程式通訊之單一安全通道以減少安 全風險。DDP是能夠不管硬體及/或軟體限制仍可有利地 實施之多樣性協定。再者,DDP是可被控制以利用複數控 制及/或運輸協定的適應性協定。 E· Divitas協定代理器(DPP) 若行動性手機上的應用程式之用戶直接存取企業資源 ,則需要爲多個協定打開企業防火牆。根據本發明的一或 -79- 200820682 多個實施例所構思之方法讓以手機爲基的企業應用程式能 夠以安全方式使用現存的VoIP相關連接。 藉由想出分散式協定代理器以實施本發明。分散式協 定代理器可被分成兩部分。一部分連同VoIP用戶一起駐 在行動性手機上。另一部分連同VoIP伺服器一起駐在企 耒內。 如圖7A-D所示,以手機爲基的VoIP用戶充作手機上 φ 所執行的不同應用程式之伺服器。此組件使用現存的 VoIP相關連接(如、SIP)以發送應用程式負載橫越到企業 。伺服器側代理組件負責拆卸負載且連接到實際的企業伺 服器。用戶和伺服器側代理組件進一步再細分成,多個子組 件。各個子組件負責代理一協定。 圖7A圖示根據本發明的一或多個實施例之網路架構 且每一主機包括兩網路介面。經由兩獨立網路提供兩路徑 ,一路徑來自介面C0到S0,而另一路徑來自 C1到S1。 在SCTP中,這兩路徑將結合。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”薄弱用戶”使用內建的動力監視結合的路徑; 當偵測到路徑故障時,協定透過另一路徑發送流量。應用 程式不必知道失敗接管復原已發生。 失敗接管亦可用於維持網路應用程式連接性。例如, 假設包括無線802· u介面和乙太介面的膝上型電腦。當膝 上型電腦在其璋接站時,較高速度的乙太介面較適合;但 是當連接中斷(離開埠接站)時,連接應被失敗接管到無線 介面。當回到埠接站時,應偵測到乙太連接且透過此介面 -80- 200820682 重新開始通訊。這是提供高可利用性和可靠性之一強而有 力的機構。 根據本發明的一或多個實施例,實施多起始處計畫以 提供比使用TCP者的可利用性更高之應用程式。多起始 處主機室具有一個以上的網路介面之主機,因此具有可定 址多起始處主機之一個以上的IP位址。在TCP中,連接 意指兩端點的通道(在此例中,兩主機的介面之間的插座) 圖7B-D圖示根據本發明的一或多個實施例之薄弱用 互連同伺服器上的薄弱用戶之配對如何在手機和伺服器之 間有效建立用以運輸狀態資訊之效率佳的運輸機構。電子 郵件應用程式的例子(如、SMTP)被圖示作使用 SIP- NOTIFY方法以在不知道SMTP應用程式之下隧穿應用程 式層封包。如此具有用戶上的表示層封包應用程式不必爲 了提供對話持續性而改變之優點。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.
有利的是,行動性應用程式使用上述方法,企業可達 成更安全和容易管理的企業行動性。此方法亦使VoIP販 售商能夠擴展其行數性解決方案到不同的企業應用程式。 參考下面的圖式和討論可更加明白本發明的特徵和優 點。 圖2 0爲手機上的各個應用程式個別連接到企業內的對 應應用程式伺服器之架構配置的習知技術例子圖。手機 2000可包括複數應用程式用戶,該複數應用程式用戶包括 Divitas用戶2002、CRM(客戶關係管理)應用程式用戶2006 200820682 、及郵件應用程式用戶2008,但並不侷限於此。應用程式 用戶可彼此獨立或透過應用程式協定介面(API)彼此互動 。在一例子中,應用程式用戶2006及2008可分別透過API 2010 及 API 2012 與 Divitas 用戶 2002 互動。 手機2000中的應用程式用戶可與企業2090內的應用程 式伺服器互動。企業2090可包括複數應用程式伺服器,該 複數應用程式伺服器包括Divitas伺服器2022、CRM應用 φ 程式伺服器2026、及郵件應用程式伺服器2028,但並不侷 限於此。應用程式伺服器可彼此獨立或透過API彼此互動 。在一例子中,應用程式伺服器202 6及2028可分別透過 API 203 0及API 2032與Divitas伺服器2022互動。需注意 的是,API的目的係使應用程式能夠彼此互動。然而,因 爲各個應用程式彼此獨立,所以透過API的互動是隨意的 〇 假設手機2000上的股票經紀人可透過Divitas用戶 # 2002與其用戶通訊的情況。儘管與其用戶交談,但是股票 經紀人想要隨手可得到其用戶的投資組合。在此例中,股 票經紀人必須建立兩種不同的對話。股票經紀人可建立第 一對話以使自己能夠透過Divitas用戶2002與其用戶交談 。爲了提及投資組合,股票經紀人可藉由利用CRM應用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
程式用戶2006與位在企業2090內的防火牆2040下之 CRM 應用程式伺服器2026互動以建立第二對話。 在典型安全插座層(SSL)虛擬私有網路(VPN)環境中, 就已建立的各個通道而言,網路管理者必須建立不同組態 -82- 200820682 。爲了建立兩種不同對話,必須建立兩種分開的安全通道 。在一例子中,已將新的郵件應用程式用戶添加到手機。 爲了與位在企業的防火牆內之郵件應用程式伺服器通訊, 網路管理者必須建立新的安全通道。如此,在典型SSL VPN環境中,使用者必須建立多個對話,其需要多個開始 通訊指令且使企業更容易遭受安全風險。SSL VPN環境不 僅對使用者不方便,而且此環境類型也需要更多的人力資 φ 源以管理企業的網路環境安全。 爲了最小化所建立的安全通道數目,可使用網際網路 協定(ίρ)安全閘道器取代SSL。在IP安全VPN環境中, 手機上的一或多個應用程式用戶可藉由橫貫過IP安全用 戶2014與IP安全閘道器2030透過一安全通道與應用程式 伺服器互動。爲了建立安全通道,使用者首先必須提供認 證資料(如、使用者名稱、密碼等)。一旦已建立安全通道 ,則使用者亦擔負有每次利用不同的應用程式用戶時之認 φ 證責任。換言之,可將各個應用程式用戶組配成透過不同 的IP位址與其對應的應用程式伺服器通訊。 在一例子中,CRM應用程式用戶2006想要與應用程 式伺服器202 6互動。若未曾建立安全通道2084,則使用者 首先必須提供認證資料。一旦已建立安全通道2084,則爲 了使CRM應用程式用戶2006能夠與CRM應用程式伺服器 20 26互動,使用者必須提供額外的認證資料。 此外,每一次中斷對話時都必須發生新的安全通道和 重新認證。在一例子中,若使用者在對話時是移動的’則 -83- 200820682 若連接不見,使用者會遭遇從對話中突然中斷的風險。例 如,透過Wi-Fi網路連接的使用者會橫貫到Wi-Fi網路外 。對話會中斷,使用者必須建立另一對話,諸如蜂巢式連 接等。結果,使用者受到建立新的對話之不便的干擾並且 也會受挫於有限的行動性。 提供習知技術圖2 1說明應用程式用戶如何與應用程式 伺服器互動。圖21爲使應用程式用戶能夠在IP安全VPN φ 環境中與應用程式伺服器通訊之方法的習知技術流程圖。 圖2 1討論有關圖2 0。 假設手機2000的使用者想要利用郵件應用程式用戶 2008發送電子郵件之情況。 在第一步驟2 1 02中,將電子郵件資料流量發送到應用 程式伺服器。在一例子中,郵件應用程式用戶2 0 〇 8可發送 電子郵件資料封包到企業2090內的郵件應用程式伺服器 2028 ° -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 ° -
在下一步驟21 04中,由可檢查以決定如何路由流量之 IP Security Client(IP安全用戶)2014接收電子資料流量。 換言之,IP安全用戶20 14可分析各個封包以決定封包是 否是企業2090想要的封包。IP安全用戶2014可藉由分析 位在封包內的IP位址和璋號碼以辨識封包的接收者。 若電子郵件資料流量的接收者不是企業2090內的複數 應用程式伺服器之一,則在下一步驟21 06中,IP安全用 戶20 1 4可丟棄流量或可引導電子郵件流量到不位在企業 2090內的伺服器。如何處理不是企業2090內的應用程式伺 -84- 200820682 服器想要的電子郵件流量視如何將IP安全用戶20丨4組配 成處理非企業資料流量而定。 若IP安全用戶2014決定資料流量是位在企業2090內 的應用程式伺服器想要的,則在下一步驟2108中,在薅寄 資料封包之前,IP安全用戶20 14可將各個資料封包加密 。加密各個資料封包的處理需要手機2000具有足夠的CPU 處理功率。另外,在IP安全VPN環境中加密各個資料封 φ 包的要求會產生諸如網路電話(VoIP)通信對話等語音通信 情況中的潛在因素問題。換言之,語音通訊對話期間的語 音品質嚴重惡化,導致不佳的語音通訊經驗(如、背景中 的回音、無法聽見的談話等)。 在下一步驟2110中,1?86。111^7(:1丨6111:(1?安全用戶 )20 14可沿著安全通道20 84發送經加密流量到想要的應用 程式伺服器。如上述,在每次利用新的應用程式時安全通 道必須建立安全通道。在一例子中,IP安全用戶20 1 4可 φ 經由網路2050及防火牆2040發送經加密流量到企業2090的 IP Security Gateway(IP 安全閘道器)2030。 在下一步驟2112中,IP安全閘道器2030執行檢查以 決定如何路由流量。與IP安全用戶20 14類似,IP安全閘 道器203 0分析各個封包以決定封包是否是企業2090想要的 〇 若偶而接收到資料封包不是經加密IP安全封包,則 在下一步驟21 14中,IP安全閘道器203 0丟棄該封包。 若資料封包是經加密IP安全封包,則在下一步驟 -85- 200820682 21 16中,IP安全閘道器20 3 0可將流量解密。 一旦已解密封包,則IP安全閘道器2030分析封包以 辨識接收的應用程式伺服器之IP位址和埠號碼。在下一 步驟2118中,IP安全閘道器2030將資料封包轉寄到適當 的應用程式伺服器(如、郵件應用程式伺服器202 8)。 步驟2 1 02到2 1 1 8所說明的方法是連續處理且爲應用程 式用戶所接收的各個封包加以執行。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.
習知技術有幾點不利點。在一例子中,必須爲添加到 使用者的手機之每一個新的應用程式用戶執行不同的組態 。當添加新的應用程式用戶時,各種不同的應用程式用戶 和其對應的應用程式伺服器之管理導致更複雜的建立關係 網路環境,如此維持代價變得很高。再者,使用者必須負 起執行多個認證的責任,如此需要使用者記住複數認證資 料。另外,由於需要加密資料流量,導致硬體成本增加( 如、手機必須具有足夠的CPU處理功率)和潛在因素增多 ,所以在IP安全VPN環境內操作所得到的益處減少。此 外,使用者會受挫於所提供的有限行動性,每一次對話中 斷,使用者就必須重新建立連接和重新認證。 在本發明的一觀點中,本發明人在本文實現統合多個 認證及/或多個安全通道的習知技術架構配置以建立單一 開始通信指令的環境。 換言之,本發明人實現藉由將各個應用程式組配成經 由單一應用程式(如、Divitas用戶)和單一伺服器(如' Divitas伺服器)引導其資料流量,來自複數應用程式的資 -86- 200820682 料流量可透過單一安全通道被發送而不需要使用者執行多 個認證。此外,在不必犧牲行動性之下也可大幅降低對話 損失。 根據本發明的實施例,藉由實施Divitas協定代理伺 服器(DPP)以提供行動性架構配置。在一實施例中,DPP 包括用戶DPP和伺服器DPP。 在本發明的實施例中,手機可包括行動性用戶(如、 φ Divitas用戶,其可包括用戶DPP以管理手機和行動性伺 服器(如、Divitas伺服器)之間的連接性。在本發明的實施 例中,行動性伺服器可包括伺服器DPP以管理行動性伺 服器和手機之間的連接性。在本發明的實施例中,用戶和 伺服器DPP可包括複數子用戶/伺服器DPP以管理不苘的 協定類型(如、SIP、SMTP等)。 在本發明的實施例中,DPP能夠從各個應用程式用戶 與其對應的應用程式伺服器互動建立單一安全通道。因爲 φ 各個應用程式正經由共同DPP路由其資料流量’所以 DPP現在可管理手機和行動性伺服器之間的連接性。連接 性資訊可包括透過諸如SIP(對話啓動協定)等控制協定建 立手機和行動性伺服器之間的安全通道°連丨安性貧訊可被 用於決定何時和如何連接手機。此外’連接性資訊亦可包 括何時執行從一網路到另一網路的傳訊(如、從Wi-Fi網 路到蜂巢式網路),藉以能夠在不同網路之間無縫變換。 參考下面的圖式和討論可更加明白本發明的特徵和優 點。 -87- 200820682 圖2 2爲本發明的實施例中之行動性架構配置的簡易方 塊圖。在行動性架構配置2200中,手機22 02與企業221 6內 的Divitas伺服器2218(如、行動性伺服器)互動。手機 2202可包括Divitas用戶2204(如、行動性用戶)和複數應 用程式用戶(2206及2208)。在本發明的實施例中,Divitas 用戶2204可包括用戶DPP以管理手機和行動性伺服器之 間的連接性。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.
不像習知技術一般,應用程式用戶220 6和應用程式用 戶2208不被組配成直接與它們的對應應用程式伺服器 (2220及2222)互動。在一實施例中,取而代之的是,用於 各個應用程式用戶的各種不同組態可被簡化成引導所有資 料流量到與Divitas用戶2204相關聯的單一區域IP主機 22 10(如、127.0 ·0·1的IP位址)。換言之,來自應用程式 用戶220 6及2208的資料流量現在可被組配成透過 API 2212及2214被路由到Divitas用戶2204。從Divitas用戶 2204,然後,可經由企業內2216的Divitas伺服器221 8透 過網路2224(如、網際網路)路由所有資料流量。在本發明 的實施例中,Divitas伺服器2218可包括伺服器DPP以管 理手機和行動性伺服器之間的連接性。一旦Divitas伺服 器2218已接收到資料流量,貝[j Divitas伺服器2218可透過 API(2 23 2及22 3 4)適當路由流量到對應的應用程式伺服器 (2220及 2222) ° 假設手機2202的使用者想要藉由利用應用程式用戶 22 0 6發送電子郵件之情況。因爲應用程式用戶22 06已被組 -88- 200820682 配成發送所有資料流量到區域欲主機22 1 0,所以來自應用 程式用戶2206的資料流量透過 API 2212被發送到與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用戶22 04相關聯的區域IP主機221 0。Div it as user 22 04 associated zone IP host 221 0.
當接收來自應用程式用戶2206的流量時,Divitas用 戶2204可使用Divitas資料交換(DDX)將流量封裝在SIP Notify Message內。如本文所討論一般,DDX意指用以在 手機和伺服器之間傳送資料封包的協定。在封裝資料封包 時,DDX添加新的標記,該標記添加有關發送資料流量 的應用程式用戶之資訊。 不像習知技術一般,並不加密所有的資料封包。取而 代之的是,資料封包是否被加密視應用程式用戶所指定的 偏好而定。在本發明的實施例中,新添加的DDX被加密 。一旦資料封包已經封裝在SIP Notify Message內,則已 封裝的資料封包現在沿著包括橫貫經過網路22 24之安全通 道2250被轉寄到由Divitas伺服器221 8接收。需注意的是 ,若由一或多個安全模組(如、防火牆222 6)保護企業,則 資料封包亦必須橫貫經過一或多個安全模組。 一旦已由 Divitas伺服器2218接收資料封包,則 Divitas伺服器2218可利用DDX標記檢索應用程式伺服器 的位置。在一例子中,DDX標記可包括辨識號碼(如、 MAC位址、埠位址),其可指出企業內哪一個應用程式伺 服器(如、應用程式伺服器2 2 2 0)是想要的資料封包接收者 在一實施例中,行動性架構配置可管理手機和行動性 -89 - 200820682 伺服器之間的連接性。在一實施例中,行動性架構配置可 利用諸如SIP等一般手機利用的控制協定。 在行動性架構配置中,爲了建立安全通道,使用者只 必須執行一次人工認證。換言之,一旦已在手機和行動性 伺服器之間建AI女全通道,則不必在每一次應用程式用戶 (22 06及220 8)想要與應用程式伺服器(2220及2222)互動時 都必須建立另一安全通道。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.
在一實施例中,行動性架構配置亦可包括資料庫,此 資料庫包括用於各個應用程式用戶的認證資料。如此,每 一次利用不同的應用程式用戶時,在一實施例中,行動性 架構配置可利用儲存在資料庫中之應用程式特有的認證資 料以自動認證使用者。從使用者的觀點看來,行動性架構 配置實質上是單一開始通信指令環境。 有利的是,行動性架構配置大體上使時間和努力有效 率,網路管理者必須花費在組配各個應用程式用戶。網路 管理者只要藉由組配各個應用程式用戶與區域主機互動就 可大體上消除此處理,藉以取代每一次添加新的應用程式 用戶到手機時都必須建立新的安全通道。另外,利用單一 開始通信指令,網路管理者能夠大體上減少與管理安全相 關聯的時間和成本。 行動性架構配置可被實施當作豐富或薄弱用戶。圖23 爲本發明的實施例中之當作豐富用戶的行動性架構配置之 方塊圖。如本文所討論一般,豐富用戶意指用戶DPP和 伺服器DPP不僅管理各種不同的應用程式而且也提供支 -90 - 200820682 援給至少一或多個應用程式用戶功能(如、語音應用程式 用戶、即時訊息應用程式用戶、電子郵件應用程式用戶等 )之行動性架構配置。 假設例如手機23 02的使用者想要利用郵件應用程式用 戶23 1 0(如、Microsoft® Outlook等)檢索來自位在企業231 8 內的郵件應用程式伺服器2326(如、Micir〇S〇ft®ExChaiige伺 服器等)之電子郵件的情況。將連同圖24—且討論圖23。 φ 圖24爲本發明的實施例中之圖解利用行動性架構配置的方 法之例子的簡易流程圖。 在第一步驟2402中,應用程式用戶發送資料流量到 Divitas用戶的區域主機。在行動性架構配置中,應用程 式用戶2310已被配置成經由位在Divitas用戶2304內的區 域主機23 08路由其資料流量。在一例子中,應用程式用戶 2310可透過TCP-IP發送SMTP(簡單郵遞傳輸協定)資料封 包2312到 Divitas用戶2304。可由位在 Divitas用戶2304 φ 中的SMTP代理用戶23 06(如、子用戶DPP)接收SMTP資 料封包2 3 1 2。 在一實施例中,用戶DPP可包括複數子用戶DPP。 用於處理資料流量的代理用戶類型可視應用程式用戶類型 而定。在本發明的實施例中,資料封包包括應用程式用戶 特有的璋號碼。在一例子中,SMTP資料封包23 12包括下 面的資料一 127.0.0.1/25。在此例中,號碼127.0.0.1是區 域主機23 08特有的IP位址,且號碼25_示在此例中與 SMTP代理用戶23 06相關聯的埠號碼。 -91 - 200820682 在下一步驟2404中,資料流量可被封裝當作具有 DDX標記的SIP Notify Message。換言之,當接收資料封 包23 12時,Di vitas用戶23 04將SMTP資料封包23 3 0重新 格式化成透過諸如SIP等手機的控制協定可傳輸之SIP資 料封包2330(諸如SIP Notify Message等)。在本發明的實 施例中,SIP資料封包233〇包括具有DDX標頭233 0a和 SIP標頭2330b之原始資料封包(如、資料封包2312)。如 φ 上述,DDX標頭包括應用程式伺服器特有的特有識別號 碼。在本發明的實施例,依據包括在SMTP資料封包中的 埠號碼可產生特有識別號碼。在本發明的實施例中,額外 的標記可包括在格式化資料封包中以辨識如何運輸格式化 資料封包。在例子中,運輸協定標記2330c可以是UDP-IP 運輸標記。 在本發明的實施例中,可將SIP資料封包23 3 0的一或 多個部分加密。在一實施例中,即使資料封包的剩餘部分 φ 不被加密,仍將DDX部分加密。 在下一步驟2406中,Divitas用戶可發送資料封包到 Di vitas伺服器。一旦已將資料封包23 12重新格式化成SIP 資料封包23 3 0(如、被封裝當作SIP Notify Message(通知 訊息)),則可透過安全通道2 3 5 0經由網路2 314及/或防火牆 2316發送SIP資料封包2330到Divitas伺服器2320。 在下一步驟2408中,Divitas伺服器可檢查以決定進 來的資料封包是否是SIP Notify Message。若進來的資料 封包不是SIP Notify Message,則在下一步驟2410中,可 -92- 200820682 丟棄資料封包。 然而,若進來的資料封包是SIP Notify Message,則 在下一步驟24 12中,Divitas伺服器可藉由檢查DDX標記 以檢查預期的代理伺服器。在一實施例中,Divitas伺服 器必須解密DDX封包以讀取儲存在DDX封包中的資訊。 在一例子中,依據DDX標記中的特有辨識號碼,Divitas 伺服器2320知道路由資料封包23 3 0到SMTP代理伺服器 φ 2322。在本發明的實施例中,伺服器DPP可包括複數子 伺服器DPP。在本發明的實施例中,處理進來流量的代理 伺服器類型是資料流量類型而定。 在下一步驟24 1 4中,可將資料封包路由到代理伺服器 。因爲SIP資料封包23 3 0是SMTP資料封包,所以由位在 Divitas伺服器2320內部的SMTP代理伺服器2322處理格 式化資料封包(如、子伺服器DPP)。 在下一步驟241 6中,將資料封包路由到預期的應用程 φ 式伺服器。在本發明的實施例中,SMTP代理伺服器23 22 可將SIP資料封包2330轉換成接受應用程式伺服器可接受 的格式。在一例子中,可將 SIP資料封包2330從 SIP Notify Message轉換成 SMTP資料封包2328。另外可將 DDX部分丟棄。另外,可將傳送協定從UDP-IP改成 TCP-IP,後者更有利於透過API 2332部署電子郵件資料 流量到各自的應用程式伺服器(如、郵件應用程式伺服器 2326) ° 圖24所說明的方法步驟不圖示資料封包的加密及/或 -93- 200820682 解密。在一實施例中,可在不加密之下發送資料封包。加 密的要求是隨意的,可視使用者的要求而定。在一實施例 中,可將部分或整個資料封包加密。在一實施例中,可將 DDX部分加密,而保持資料封包的剩下部分不加密。隨 意的加密使欲利用的處理功率變少且減少通常與經加密資 料封包相關聯的潛在因素。 如從圖23及24可看出一般,豐富行動性架構配置可充 φ 作使手機的應用程式用戶能夠在單一開始通信指令環境內 與應用程式伺服器戶動之行動性管理器。另外,豐富的行 動性架構配置可包括用以將來自各種應用程式的資料封包 轉換成能夠由已建立的安全通道所特有之控制協定和運輸 協定來運輸的資料封包。 在本發明的實施例中,如圖25所示,行動性架構配置 可被實施作薄弱用戶。在薄弱行動性架構配置中,用戶 DPP和伺服器DPP可只被利用當作行動性管理器(如、管 Φ 理應用程式的連接性),及不提供支援給至少一或更多應 用程式功能。 假設例如手機2500的使用者想要打電話給朋友的情況 。使用者可利用電話應用程式用戶2508(如、VoIP等)打電 話。在此例中假設已在Divitas用戶2502和位在企業2530 內的Divitas伺服器2518之間建立安全通道2550。 爲了建立電信對話,電話應用程式用戶2508可發送資 料封包2512(如、SIP/UD-IP)到Divitas用戶2502內的區域 主機25 10。如上述,複數代理用戶可駐在Divitas用戶 -94- 200820682 2502內以支援各種不同的應用程式用戶。在一例子中, SIP代理用戶2504可位在Divitas用戶2502內以處理來自 電話應用程式用戶25 0 8的資料封包。 在接收資料封包2512時,SIP代理用戶2504可分析資 料封包以決定如何路由封包。如上述,可發送到Divitas 用戶的資料封包可包括應用程式伺服器特有的埠號碼(如 、5 060等)。利用此資訊,〇^“&3用戶2502可經由網路 φ 2514和防火牆2528路由資料封包2512到Divitas伺服器 2518。在一實施例中,若資料封包已經在Divitas用戶可 路由的格式,則不必轉換資料封包。在一例子中,資料封 包2512示在31?/11〇?-1?格式,此格式是〇丨¥“&3用戶2502 可用來路由其資料流量之格式。 在一實施例中,複數代理伺服器可駐在Divitas伺服 器內。在例子中,SIP代理伺服器2532可駐在Divitas伺 服器25 18內,以管理從電話應用程式用戶25 0 8進來的資料 φ 流量◊因爲已從電話應用程式用戶25 0 8發送資料封包25 12 ,所以由SIP代理伺服器25 32處理資料封包。當接收資料 封包2512時,SIP代理伺服器2532可透過電話閘道器2520( 如、PSTN、GSM、CDMA等)沿著路徑2522轉寄資料封包 25 12到目的地電信裝置(如、電話等)。一旦已在手機2500 和目的地電信裝置之間建立電信對話,則由電話應用程式 用戶發送的其他資料封包2530(如、RTP資料封包等)可經 由安全通道25 50沿著路徑2560發送到Divitas伺服器2518 ’而不必經過D i v i t a s用戶2 5 0 2。 -95- 200820682 在薄弱行動性架構配置中,藉由Divitas用戶的幫助 建立電信交談的目的係使應用程式用戶能夠利用Divitas 用戶的行動性功能。換言之,已在Divitas用戶和Divitas 伺服器之間建立控制中心以監視應用程式用戶的連接性。 藉由建立此關係,當情況發生時,D i v i t a s用戶和D i v i t a s 伺服器能夠共用其連接性狀態,並且能夠無縫地處理漫遊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.
在例子中,上述情況中的使用者目前可經由Wi-Fi網 路連接。在電話交談期間,使用者可漫遊到Wi-Fi網路外 。在習知技術中,連接可能中斷而使用者必須重撥。然而 ,在行動性架構配置中,使用者的手機之連接性狀態已被 監視,並且Divitas用戶和Divitas伺服器可在使用者未 察覺變化之下,執行無縫網路交換(如、從Wi-Fi到蜂巢 式網路)。 有利地是,已投入大量金錢到複數應用程式和只需要 行動性管理器之企業可實施薄弱行動性架構配置。如此, 企業能夠利用行動性架構配置的行動性管理器性能而不必 重新建構其電信基礎建設。 如從本發明的實施例可明白一般,具有DPP的行動 性架構配置提供能夠使電信基礎建設流暢之行動性管理器 。換言之,行動性架構配置提供單一開始通訊指令的環境 。在例子中可利用單一安全通道達成相同功能以取代企業 的多個安全通道。利用單一開始通訊指令的環境,可大幅 降低管理電信基礎建設的成本和精力。另外,行動性架構 -96- 200820682 配置能夠監視且無縫地處理連接性,而不會負面地影響使 用者的電信經驗。 F.結論 儘管已利用幾個較佳實施例說明本發明,但是可有落 在本發明的範圍內之修改、變更、及同等物。亦應注意的 是,有許多實施本發明的方法和設備之其他方式。而且’ φ 可在其他應用中發現本發明的實施例之效用。爲了方便’ 本文提供抽象槪念,由於字數限制,因此僅爲了閱讀方便 而並非用於限制申請專利範圍的範疇。因此,下面附錄的 申請專利範圍應解釋作包括落在本發明的真正精神和範疇 之所有此種修改、變更、及同等物。 【圖式簡單說明】 經由例子圖解說明本發明,但是並非限制,在附圖的 φ 圖式中,相同參照號碼意指類似元件,其中: 圖1爲根據本發明的一或多個實施例之系統網路圖。 圖2A-C爲根據本發明的一或多個實施例之行動性伺 服器圖。 圖3爲根據本發明的一或多個實施例之行動性配備用 戶圖。 圖4爲根據本發明的一或多個實施例之以編碼/解碼器 爲基的回音消除器之方塊圖。 圖5A爲根據本發明的一或多個實施例之語音跳動緩 -97- 200820682 衝計畫圖。 圖5 B爲根據本發明的一或多個實施例之語音跳動緩 衝計畫圖。 圖6A爲根據本發明的一或多個實施例之DDP架構的 槪要圖。 圖6B爲根據本發明的一或多個實施例之DDP訊息交 換圖。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.
圖7 A爲每一主機包括兩網路介面且根據本發明的一 或多個實施例所製造之網路架構圖。 圖7B爲根據本發明的一或多個實施例所製造之網路 架構圖。 圖7C爲根據本發明的一或多個實施例所製造之網路 架構圖。 圖7D爲根據本發明的一或多個實施例所製造之網路 架構圖。 圖8A爲包括回音消除濾波器之示範性習知技術通訊 裝置的方塊圖。 圖8B爲用於例如圖8 A所示的示範性習知技術通訊裝 置作爲消除回音之示範性習知技術方法的流程圖。 圖9A爲根據本發明的一或多個實施例之在未依賴濾 波器之下取消回音的通訊裝置(或系統或配置)之方塊圖。 圖9B爲根據本發明的一或多個實施例之用於圖9A所 示的通訊裝置(或系統或配置)之ID碼產生器的方塊圖。 圖9C爲根據本發明的一或多個實施例之例如圖9A所 -98- 200820682 示的通訊裝置(或系統或配置)之用以消除回音的方法之流 程圖。 圖1 0 A爲具有適應性跳動緩衝計畫的第一示範性習知 技術封包語音通訊系統(第一習知技術配置)之方塊圖。 圖10B爲用於例如圖10A的例子中所示之第一習知技 術配置的習知技術跳動緩衝計畫之發送器側處理的流程圖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.
圖1 0C爲習知技術延遲計算處理的流程圖。 圖1 0D爲習知技術封包實施控制處理的流程圖。 圖10E爲當打開發送器側語音活動偵測器(VAD)時的 封包實施控制中之所接收封包流程的槪要表示圖。 圖1 0F爲關掉發送器側VAD時的封包實施控制中之 所接收封包流程的槪要表示圖。 圖1 1 A爲包括適應性緩衝器溢位控制之第二習知技術 封包語音通訊系統(第二習知技術配置)的接收器側裝置之 方塊圖。 圖11B爲用於例如圖11 A之例子所示的接收器側裝置 之無聲偵測處理的流程圖。 圖1 1 C爲用於例如圖1 1 A之例子所示的接收器側裝置 之緩衝器溢位控制處理的流程圖。 圖1 2 A爲根據本發明的一或多個實施例之具有適應性 跳動處理封包語音通訊系統的接收器側裝置之方塊圖。 圖12B爲根據本發明的一或多個實施例之用於例如圖 1 2 A之例子所示的接收側裝置之適應性跳動處理所利用的 -99- 200820682 延遲插入控制處理圖。 圖1 3爲根據本發明的一或多個實施例之具有適應性跳 動處理的封包語音通訊系統之接收器側裝置的方塊圖。 圖1 4爲在應用程式用戶與應用程式伺服器之間建立連 接的電話流程之習知技術例子圖。 圖15爲本發明的實施例之DDP發明的簡易架構圖。 圖1 6A爲實施例中之具有DDP的行動性架構配置內 φ 之資料如何在位於用戶裝置內的應用程式用戶與企業所管 理之應用程式伺服器之間流動的例子圖。 圖16B爲實施例中之封裝式SIP通知訊息的碼例子圖 圖1 7爲實施例中之圖解如何在用戶裝置與行動性伺服 器之間建立安全通道的電話流程之例子圖。 圖1 8爲實施例中之圖解必須發送大的檔案之情況的簡 易電話流程圖。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.
圖1 9爲本發明的實施例中之圖解可發送諸如由控制應 用程式所發送者等小的控制訊息之情況的簡易電話流程圖 圖20爲將手機上的各個應用程式個別連接到企業內的 對應應用程式伺服器之架構配置的習知技術例子圖。 圖2 1爲使應用程式用戶能夠在IP安全VPN環境中與 應用伺服器通訊之方法的習知技術流程圖。 圖22爲本發明的實施例中之行動性架構配置的簡易方 塊圖 -100- 200820682 圖23爲本發明的實施例中之行動架構配置當作重負載 用戶端的方塊圖。 圖24爲本發明的實施例中之利用行動性架構配置的方 法之例子的簡易流程圖。 圖25爲本發明的實施例中之行動性架構配置被實施當 作輕負載用戶端之圖。 φ 【主要元件符號說明】 100 :系統網路 102 :行動配備 1 1 〇 :蜂巢式網路 1 1 2 :基地收發站 1 1 4 : B T S交換中心 1 16 :行動交換中心 120 :媒體閘道器 φ 122 :公用交換電話網路 1 2 4 :習知公用和專用電話 130:專用分支交換機 132 :路由器 1 3 6 :電話 137 :電話 1 3 8 :網際網路協定廣域網路 140 :路由器 142 :防火牆 -101 - 200820682 144 :網際網路 150 :行動性伺服器 160 :存取點 1 8 0 :存取點 800 :習知技術通訊裝置 802 :信號接收器 806 :揚聲器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 :回音路徑 810 :麥克風 8 1 2 :緩衝器 8 1 4 :濾波器 8 1 4 :回音消除器 8 1 6 :總和函數 9 0 0 :通訊裝置 904 :信號接收器 906 :背景雜訊去除器 908 :回音路徑 9 1 0 :辨識碼注入器 914 :揚聲器 9 16 :麥克風 922 :辨識碼產生器 924 :辨識碼偵測器 926 :緩衝器 928 :延遲器 200820682 930 :總和函數 932 :信號發送器 1〇〇〇 :速度緩衝器 1001 :語音活動偵測器 1 002 :發送器 1 003 :網路 1 0 0 4 :封包緩衝器 φ 1 005 :封包實施控制器 1 006 :延遲插入控制器 1 007 :延遲資訊模組 1 008 :跳動計算機 1 009 :實施延遲計算機 1 080 :語音封包 1 080a :封包 1 082 :無聲描述符 φ 1084 :無聲 1 0 8 6:語苜封包 1086a :封包 1 088 :無聲 1 090 :無聲描述符 1091 :發送器側裝置 1 092 :接收器側裝置 1 092a :語音封包 1 094 :無聲封包 200820682 1 096 :語音封包 1 098 :無聲封包 1100 :接收器側裝置 1 102 :封包緩衝器 1104 :封包實施控制器 1108 :延遲插入控制器 1 1 1 〇 :跳動計算機 φ 1 1 1 4 :緩衝器溢位控制器 1 1 1 6 :無聲偵測器 1 1 1 8 :解碼器 1 1 8 0 :附加組件 1 199 :鏈路 1 200 :接收器側裝置 1 202 :封包緩衝器 1204 :跳動計算機 φ 1206 :實施延遲計算機 1 208 :封包實施控制器 1 2 1 0 :解碼器 1 2 1 2 :無聲偵測器 1214 :延遲插入控制器 1216 :延遲資訊模組 1 299 :鏈路 1 300 :接收側裝置 1 3 02 :封包緩衝器 200820682 1 304 :跳動計算機 1 3 06 :補償計算機 1 3 0 8 :封包實施控制器 1 3 1 0 :解碼器 1 3 1 2 :視頻偵測器 1 3 1 4 :補償控制器 1 3 1 6 :鏈路補償資訊模組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 :應用程式伺服器 1 404 :應用程式用戶 1 406 :軟體下載 1424 :通知 1 5 02 :企畫管理應用程式 i 504 :裝置管理應用程式 1 5 06 :語音行動性控制應用程式用戶 φ 1 508 :語音郵件/電子郵件傳輸應用程式 1 5 1 0 :裝置影像管理應用程式 1 5 1 2 :即時訊息應用程式 1 5 1 4 :戴維他資料交換模組 1 5 1 6 :可靠戴維他描述協定模組 1 5 1 8 :優先權訊息排程模組 1 520 :內建對話管理模組 1 5 22 :具有安全延伸的戴維他描述協定模組 1 524 :控制協定 -105- 200820682 1 526 :傳輸控制協定 1 528 :使用者資料元協定 1 5 3 0 :傳輸控制協定 1 5 32 :對話啓動協定 1 534 :使用者資料元協定 1 5 3 6 :戴維他描述協定 1 602 :語音郵件用戶 φ 1 604 :語音郵件伺服器 1 608 :伺服器戴維他資料交換模組 1 6 1 4 :伺服器可靠戴維他描述協定模組 1 6 1 6 :伺服器戴維他描述協定 1 620 :伺服器對話啓動協定控制協定 1 622 :伺服器使用者資料元協定傳輸協定 1 624 ··網路 1 626 :用戶使用者資料元協定傳輸協定 φ 1 62 8 :用戶對話啓動協定控制協定 1 632 :用戶戴維他描述協定 1 634 :用戶可靠戴維他描述協定 1 63 6 :用戶戴維他資料交換模組 1 650 :路徑 1 652 :路徑 1 700 :企業伺服器 1 702 :用戶裝置 1 704 :使用者/裝置管理器 -106- 200820682 1706 :戴維他描述協定 1 708 :分散式資料處理系統 1 7 1 0 :對話啓動協定 1712:使用者資料元協定 1 7 1 4 :使用者資料元協定 1 7 1 6 :對話啓動協定 1 7 1 8 :分散式資料處理系統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 :戴維他描述協定 1 722 :應用程式用戶 1 802 :影像管理器 1804 :裝置/使用者管理器 1 8 06 :伺服器戴維他資料交換模組 1 808 :伺服器戴維他描述協定 1 8 1 0 :用戶戴維他描述協定 1 8 1 2 :用戶戴維他資料交換模組 1 8 1 4 :應用程式用戶 1 8 1 6 :請求 1 902 :伺服器出席管理器 1 904 :裝置/使用者管理器 1 906 :伺服器戴維他描述協定 1 9 0 8 :用戶戴維他描述協定 1 9 1 0 :用戶出席管理器 1 920 :出席詢問 2000 :手機 -107 - 200820682 2002 :戴維他用戶 2006 :客戶關係管理應用程式用戶 2008 :郵件應用程式用戶 2010 :應用程式協定介面 2012 :應用程式協定介面 2014 :網際網路協定安全用戶 2022 :戴維他伺服器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 :客戶關係管理應用程式用戶 2028 :郵件應用程式伺服器 2030 :網際網路協定安全閘道器 2030 :應用程式協定介面 2032 :應用程式協定介面 2040 :防火牆 2050 :網路 2 0 8 4 :安全通道 2090 ··企業 2200 :行動性架構配置 2202 :手機 2204 :戴維他用戶 2206 :應用程式用戶 2208 :應用程式用戶 2210 :區域網際網路協定主機 22 12 :應用程式協定介面 2214:應用程式協定介面 -108- 200820682 2216 :企業 2218 :戴維他伺服器 2220 :應用程式伺服器 2222 :應用程式伺服器 2224 :網路 2226 :防火牆 2232 :應用程式協定介面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 :應用程式協定介面 2250 :安全通道 2302 :手機 23 04 :戴維他甩戶 23 06 :簡單郵遞傳輸協定代理用戶 2 3 0 8 :區域主機 23 10 :郵件應用程式用戶 23 12 :簡單郵遞傳輸協定資料封包 2314 :網路 23 16 :防火牆 2 3 1 8 ··企業 23 20 :戴也伺月艮器 2 322 :簡單郵遞傳輸協定代理伺服器 2326 :郵件應用程式伺服器 23 28 :簡單郵遞傳輸協定資料封包 2330 :對話啓動協定資料封包 23 30a :戴維他資料交換標頭 -109- 200820682 2330b :對話啓動協定標頭 23 3 0c :運輸協定標記 23 32 :應用程式協定介面 23 5 0 :安全通道 2 5 0 0 :手機 2502 :戴維他用戶 2504 :對話啓動協定代理用戶 0 2508 :電話應用程式用戶 2 5 1 0 :區域主機 25 12 :資料封包 2514 :網路 2518 :戴維他伺服器 2520 :電話閘道器 2 5 2 2:路徑 2528 :防火牆 φ 2 5 3 0 :企業 2532 :對話啓動協定代理伺服器 25 50 :安全通道 25 52 :應用程式協定介面 2560 :路徑 2562 :即時協定- X :信號 y ’ :信號 y 1 :信號 -110- 200820682 Z :信號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 --111 -
Claims (1)
Applications Claiming Priority (12)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US80480606P | 2006-06-14 | 2006-06-14 | |
US11/537,985 US7546125B2 (en) | 2005-10-03 | 2006-10-02 | Enhancing user experience during handoffs in wireless communication |
US11/537,980 US20070091848A1 (en) | 2005-10-03 | 2006-10-02 | Reducing data loss during handoffs in wireless communication |
US11/538,037 US20080119165A1 (en) | 2005-10-03 | 2006-10-02 | Call routing via recipient authentication |
US11/538,042 US20070094374A1 (en) | 2005-10-03 | 2006-10-02 | Enterprise-managed wireless communication |
US11/538,034 US20070264989A1 (en) | 2005-10-03 | 2006-10-02 | Rendezvous calling systems and methods therefor |
US11/537,990 US7688820B2 (en) | 2005-10-03 | 2006-10-02 | Classification for media stream packets in a media gateway |
US11/537,994 US20070091907A1 (en) | 2005-10-03 | 2006-10-02 | Secured media communication across enterprise gateway |
US11/755,727 US20090016333A1 (en) | 2006-06-14 | 2007-05-30 | Content-based adaptive jitter handling |
US11/755,702 US20080140767A1 (en) | 2006-06-14 | 2007-05-30 | Divitas description protocol and methods therefor |
US11/755,710 US20080317241A1 (en) | 2006-06-14 | 2007-05-30 | Code-based echo cancellation |
US11/755,704 US7480500B1 (en) | 2006-06-14 | 2007-05-30 | Divitas protocol proxy and methods therefor |
Publications (1)
Publication Number | Publication Date |
---|---|
TW200820682A true TW200820682A (en) | 2008-05-01 |
Family
ID=40328921
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
TW096121019A TW200814679A (en) | 2006-06-14 | 2007-06-11 | Code-based echo cancellation |
TW096121021A TW200818813A (en) | 2006-06-14 | 2007-06-11 | DiVitas description protocol and methods therefor |
TW096121020A TW200820682A (en) | 2006-06-14 | 2007-06-11 | Content-based adaptive jitter handling |
TW096121022A TW200816753A (en) | 2006-06-14 | 2007-06-11 | DiVitas protocol proxy and methods therefor |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
TW096121019A TW200814679A (en) | 2006-06-14 | 2007-06-11 | Code-based echo cancellation |
TW096121021A TW200818813A (en) | 2006-06-14 | 2007-06-11 | DiVitas description protocol and methods therefor |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
TW096121022A TW200816753A (en) | 2006-06-14 | 2007-06-11 | DiVitas protocol proxy and methods therefor |
Country Status (2)
Country | Link |
---|---|
KR (1) | KR20090085018A (en) |
TW (4) | TW200814679A (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI491226B (en) * | 2013-04-02 | 2015-07-01 | Hon Hai Prec Ind Co Ltd | Video playing device and controlling method |
TWI791691B (en) * | 2017-11-27 | 2023-02-11 | 南韓商三星電子股份有限公司 | Communication system, communication device, application processor and network address translation method of communication system |
TWI802487B (en) * | 2022-08-01 | 2023-05-11 | 大陸商鼎捷軟件股份有限公司 | Instant response system and instant response method |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101503009B1 (en) * | 2013-04-03 | 2015-03-18 | 주식회사 시큐아이 | Method and apparatus for identifying application based on data size |
-
2007
- 2007-06-11 TW TW096121019A patent/TW200814679A/en unknown
- 2007-06-11 TW TW096121021A patent/TW200818813A/en unknown
- 2007-06-11 TW TW096121020A patent/TW200820682A/en unknown
- 2007-06-11 TW TW096121022A patent/TW200816753A/en unknown
- 2007-06-14 KR KR1020097000794A patent/KR20090085018A/en not_active Application Discontinuation
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI491226B (en) * | 2013-04-02 | 2015-07-01 | Hon Hai Prec Ind Co Ltd | Video playing device and controlling method |
TWI791691B (en) * | 2017-11-27 | 2023-02-11 | 南韓商三星電子股份有限公司 | Communication system, communication device, application processor and network address translation method of communication system |
TWI802487B (en) * | 2022-08-01 | 2023-05-11 | 大陸商鼎捷軟件股份有限公司 | Instant response system and instant response method |
Also Published As
Publication number | Publication date |
---|---|
TW200818813A (en) | 2008-04-16 |
TW200814679A (en) | 2008-03-16 |
TW200816753A (en) | 2008-04-01 |
KR20090085018A (en) | 2009-08-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7480500B1 (en) | Divitas protocol proxy and methods therefor | |
US20080140767A1 (en) | Divitas description protocol and methods therefor | |
US20090016333A1 (en) | Content-based adaptive jitter handling | |
US20080317241A1 (en) | Code-based echo cancellation | |
US20090147772A1 (en) | Systems and methods for providing presence information in communication | |
US20070091907A1 (en) | Secured media communication across enterprise gateway | |
US9001182B2 (en) | Efficient and on demand convergence of audio and non-audio portions of a communication session for phones | |
EP2176987B1 (en) | Multi-point to multi-point intercom system | |
US8885807B2 (en) | Systems and methods for facilitating conference calls using security keys | |
US9900356B2 (en) | Method and apparatus for transferring active communication session streams between devices | |
WO2010075126A2 (en) | Systems and methods for enabling communication features utilizing various bearer media | |
JP2006222822A (en) | Handover system | |
KR101705440B1 (en) | Hybrid cloud media architecture for media communications | |
US9525710B2 (en) | Seamless switch over from centralized to decentralized media streaming | |
US20070121604A1 (en) | Lightweight Voice Over Internet Protocol Phone | |
US20040151158A1 (en) | Method and apparatus for exchanging voice over data channels in near real time | |
JP2007142786A (en) | Handover server, and mobile communication terminal communcable thereof | |
US8571189B2 (en) | Efficient transmission of audio and non-audio portions of a communication session for phones | |
TW200820682A (en) | Content-based adaptive jitter handling | |
EP2055018A2 (en) | Code-based echo cancellation | |
US8335209B2 (en) | Group paging synchronization for VoIP system | |
EP2033408A2 (en) | Divitas protocol proxy and methods therefor | |
US11962723B2 (en) | Packet telephony terminal apparatus and operating method thereof | |
WO2007147034A2 (en) | Content-based adaptive jitter handling | |
WO2007147036A2 (en) | Divitas description protocol and methods therefor |