【正文】 [13]。 本文檔僅定義了信號處理協(xié)議。 Jabber/XMPP 客戶端中的協(xié)議相對容易。 (例如，用于語音聊天的 )與內(nèi)容傳輸方法 (比如，在 RFC768[8]中說明的用戶數(shù)據(jù)報(bào)協(xié)議 )。 這里定義的協(xié)議的目標(biāo)是滿足如下需求： XMPP 內(nèi)多種點(diǎn)對點(diǎn)會(huì)話（不限于聲音和視頻）的管理成為可能 [6]。因?yàn)闃?gòu)建雙重 XMPP+SIP 客戶端非常困難，導(dǎo)致本質(zhì)上程序控制的兩個(gè)中心，所以，我們將 Jingle 設(shè)計(jì)成純的 XMPP 信號處理協(xié)議。因此，由本文詳細(xì)說明的信號處理協(xié)議基本上等同于現(xiàn)有的 Google Talk 協(xié)議，只是根據(jù)在 XMPP 標(biāo)準(zhǔn)基金會(huì)的標(biāo)準(zhǔn)化的實(shí)施及發(fā)表進(jìn)程中收到的反饋?zhàn)髁艘恍┱{(diào)整。通過與 Google Talk小組 [4]成員交流，發(fā)現(xiàn)形成的 Jingle方法在概念上（甚至在句法上）都與在 Google Talk 程序中使用的信號處理協(xié)議非常相似。因此，定義一個(gè) XMPP 信號處理協(xié)議似乎合情合理，這個(gè)協(xié)議能提供所需的信號處理語義，同時(shí)也使得與現(xiàn)有互聯(lián)網(wǎng)標(biāo)準(zhǔn)的互操作性相對簡單。 XMPP 信號處理的完整特征的協(xié)議。 其結(jié)果導(dǎo)致在 XMPP 社區(qū)里有關(guān)信號處理的協(xié)議支離破碎。這些網(wǎng)絡(luò)建立在 IETF 的 會(huì)話初始化協(xié)議(SIP) 上，在 RFC3261[注 1]及其各種擴(kuò)展中有詳細(xì)說明。 文檔信息 系列： XEP 序號： 0166 發(fā)布者： XMPP 標(biāo)準(zhǔn)基金會(huì) 狀態(tài)： 實(shí)驗(yàn)性的 類型： 標(biāo)準(zhǔn)跟蹤 版本： 最后更新： 20200417 批準(zhǔn)機(jī)構(gòu)： XMPP 委員會(huì) 依賴標(biāo)準(zhǔn)： XMPP 核心標(biāo)準(zhǔn) 被替代標(biāo)準(zhǔn)：無 縮略名：未指派 Wiki 頁： 作者信息 法律通告 討論地點(diǎn) 相關(guān)的 XMPP 術(shù)語 目錄 1. 緒論 2. 需求 3. 術(shù)語表 4. 概念和方法 總會(huì)話管理 5. 會(huì)話流 資源確定 初始化 接收方響應(yīng) 拒絕 協(xié)商 接受 修改活動(dòng)會(huì)話 中止 通知消息 6. 出錯(cuò)處理 7. 支持性檢測 8. 使用協(xié)議的一致性 . 應(yīng)用類型 . 傳輸方法 9. 安全性事項(xiàng) . 服務(wù)的拒絕 . 通過網(wǎng)關(guān)通訊 10. IANA 事項(xiàng) 11. XMPP 注冊處事項(xiàng) . 協(xié)議命名空間 . Jingle 內(nèi)容描述格式注冊 . Jingle 內(nèi)容傳輸方法注冊 . Jingle 原因代碼注冊 . 過程 . 初始注冊 12. XML Schemas . Jingle . Jingle 出錯(cuò)信息 13. 致謝 從 Jabber/XMPP 客戶內(nèi)部初始化和管理點(diǎn)到點(diǎn)（ p2p）互操作（象聲音、圖像、或文件共享交換）的未廣泛采用的標(biāo)準(zhǔn)已經(jīng)有了。作為 XMPP 擴(kuò)展協(xié)議發(fā)表，并不意味著 XMPP 標(biāo)準(zhǔn)基金會(huì)批準(zhǔn)了這個(gè)協(xié)議。本文的英文原文來自 XEP0166 XEP0166 JINGLE 本文檔定義了在 Jabber/XMPP 客戶間初始化及管理點(diǎn)對點(diǎn)的多媒體會(huì)話 (sessions)（比如，聲音和圖像的交換）框架，它在 一定程度上與現(xiàn)有的 Inter 標(biāo)準(zhǔn)具有互操作性。 警告：本標(biāo)準(zhǔn)跟蹤文檔是實(shí)驗(yàn)性的。我們鼓勵(lì)對本協(xié)議進(jìn)行探索性的實(shí)現(xiàn)，但在本協(xié)議的狀態(tài)發(fā)展為草稿之前，產(chǎn)品性的系統(tǒng)不應(yīng)實(shí)現(xiàn)本協(xié)議。雖然，一些大的服務(wù)提供商和 Jabber/XMPP 客戶已經(jīng)寫出和實(shí)現(xiàn)了他們自己獨(dú)有的用于點(diǎn)對點(diǎn)信號 處理的 XMPP 擴(kuò)展，但這些技術(shù)沒有公開，并且總是沒有考慮到與公共轉(zhuǎn)換電話網(wǎng)絡(luò)（ PSTN）或跨互聯(lián)網(wǎng)聲音協(xié)議（ VoIP）的互操作性的需求。 與此相反，唯一存在的開放協(xié) 議是 初始化及協(xié)商會(huì)話的傳輸 [注 2]，它使得初始化及管理點(diǎn)對點(diǎn)會(huì)話成為可能，卻沒有提供足夠多的在 Jabber/XMPP 客戶端中能輕松地實(shí)現(xiàn)的關(guān)鍵性的信號處理語義?；旧希袃芍蟹椒梢越鉀Q這個(gè)問題： (XMPP+SIP)解決方案。 實(shí)現(xiàn)經(jīng)驗(yàn)表明，雙重方法也許不會(huì)在所有的計(jì)算平臺(tái)上都可行 也許 Jabber 客戶端已經(jīng)寫完 了，或者雖然可行但并不值當(dāng)。 作為收到的 XEP0111 返饋的一個(gè)結(jié)果，文檔的原作者（ Joe Hildebrand 和 Peter SaintAndre）開始定義這樣的一個(gè)信號處理協(xié)議，代碼名為 Jingle。因此，為了保持 互操作性和適用性，我們決定協(xié)調(diào)這兩種方法。 Jingle 的目的不是排擠或替代 SIP。 Jingle 意欲與 SIP 相互作用，這樣數(shù)百萬已布置的 XMPP 客戶端能夠加到現(xiàn)有的開放的 VoIP 網(wǎng)絡(luò)之中，而不是將 XMPP 用戶限制在某個(gè)分離的獨(dú)特的 VoIP 網(wǎng)絡(luò)中。 (XMPP)與數(shù)據(jù)通道（例如，在 RFC3550 中說明的實(shí)時(shí)傳輸協(xié)議 [7]）。 、修改、刪除內(nèi)容類型成為可能。 XMPP 實(shí)體通訊的時(shí)候，盡可能將復(fù)雜性推到 XMPP 網(wǎng)絡(luò)與非 XMPP 網(wǎng)絡(luò)間的服務(wù)器端網(wǎng)關(guān)上。其他文檔詳細(xì)說明了如下內(nèi)容： o 各種內(nèi)容描述格式（音頻、視頻等），如有可能，將這些類型映射到會(huì)話描述協(xié)議（ SDP，參見 RFC4566[9]）中；示例包括經(jīng)由 RTP 的 Jingle 音頻 [10]及經(jīng)由 RTP 的視頻 [11]。 o 映射 Jingle 信號處理協(xié)議到現(xiàn)有現(xiàn)有信號處理標(biāo)準(zhǔn)的方法，象 IETF 的會(huì)話初始化協(xié)議 (SIP。 術(shù)語 定義 會(huì)話 連接兩個(gè)實(shí)體的許多對已協(xié)商的內(nèi)容傳輸方法和內(nèi)容描述格式。在一個(gè)會(huì)話的生命周期內(nèi)，可加入或刪除成對的內(nèi)容描述和內(nèi)容傳輸方法。 內(nèi)容類型 一個(gè)內(nèi)容描述和一個(gè)內(nèi)容傳輸方法的組合。這是會(huì)話的（即，傳輸?shù)谋忍匚唬?“是什么 ”，象建立語音通話時(shí)可接 受的編碼器等。 傳輸方法 實(shí)體間建立數(shù)據(jù)流的方法。這是關(guān)于會(huì)話 “怎樣 ”的部分。內(nèi)容傳輸方法定義了怎樣將比特位從一臺(tái)主機(jī)傳到另一臺(tái)。 組件 組件是需要在端點(diǎn)間傳輸?shù)奶囟〞?huì)話上下文中特定內(nèi)容類型的編號的數(shù)據(jù)流 。根據(jù)內(nèi)容類型和內(nèi)容描述，一個(gè)內(nèi)容描述可能需要多個(gè)組件來通訊（例如，音頻內(nèi)容類型也許用兩個(gè)組件：一個(gè)傳輸 RTP 流，另一個(gè)傳輸 RTCP 定時(shí)信息）。另有單獨(dú)的文檔，詳細(xì)說明了用于內(nèi)容描述和內(nèi)容傳輸方法的可插入式 “槽 (slots)”。 從最根本上 來說，協(xié)商 Jingle 會(huì)話的過程是這樣的： （ “發(fā)起方 ”）向另一個(gè)用戶（ “接收方 ”）發(fā)送一個(gè)帶內(nèi)容類型的會(huì)話請求，會(huì)話請求至少包含一個(gè)內(nèi)容類型。 （進(jìn)一步協(xié)商前的傳輸候選方法的快速發(fā)送，是為了縮短媒體數(shù)據(jù)可流動(dòng)前的必要時(shí)間）。 ，接收方會(huì)向初始方發(fā)出一個(gè) “會(huì)話接受 ”動(dòng)作。 如果雙方隨后發(fā)現(xiàn)了更好的候選方法，他們會(huì)進(jìn)行 “內(nèi)容修改 ”協(xié)商，然后轉(zhuǎn)到這個(gè)更好的候選方法上。 總會(huì)話管理 總會(huì)話管理的狀態(tài)機(jī) (也即每個(gè) Session ID 的狀態(tài) )如下： o | |會(huì)話開始 | | ++ |/ | 阻塞 o+ | | |內(nèi)容接受 | | | |內(nèi)容修改 | | | |內(nèi)容移除 | | | |會(huì)話信息 | | | |傳輸信息 | | | ++ | | | |會(huì)話接受 | | | 活動(dòng) o+ | | |內(nèi)容接受 | | | |內(nèi)容增加 | | | |內(nèi)容修改 | | | |內(nèi)容移除 | | | |會(huì)話信息 | | | |傳輸信息 | | | ++ | | | ++ | |會(huì)話中止 | o 結(jié)束 總會(huì)話狀態(tài)有三種： 與管理總體 Jingle 會(huì)話相關(guān)的動(dòng)作如下： 表 2： Jingle 動(dòng)作 動(dòng)作 描述 內(nèi)