【正文】 會話開始 請求一個新 Jingle 會話協(xié)商。 內(nèi)容移除 從會話中移除一個或多個內(nèi)容類型。這個動作 不能 在會話的 阻塞 狀態(tài)時發(fā)出。 如果雙方隨后發(fā)現(xiàn)了更好的候選方法，他們會進(jìn)行 “內(nèi)容修改 ”協(xié)商，然后轉(zhuǎn)到這個更好的候選方法上。 （進(jìn)一步協(xié)商前的傳輸候選方法的快速發(fā)送，是為了縮短媒體數(shù)據(jù)可流動前的必要時間）。另有單獨(dú)的文檔，詳細(xì)說明了用于內(nèi)容描述和內(nèi)容傳輸方法的可插入式 “槽 (slots)”。 組件 組件是需要在端點(diǎn)間傳輸?shù)奶囟〞捝舷挛闹刑囟▋?nèi)容類型的編號的數(shù)據(jù)流 。這是關(guān)于會話 “怎樣 ”的部分。這是會話的（即，傳輸?shù)谋忍匚唬?“是什么 ”，象建立語音通話時可接 受的編碼器等。在一個會話的生命周期內(nèi)，可加入或刪除成對的內(nèi)容描述和內(nèi)容傳輸方法。 o 映射 Jingle 信號處理協(xié)議到現(xiàn)有現(xiàn)有信號處理標(biāo)準(zhǔn)的方法，象 IETF 的會話初始化協(xié)議 (SIP。 XMPP 實(shí)體通訊的時候，盡可能將復(fù)雜性推到 XMPP 網(wǎng)絡(luò)與非 XMPP 網(wǎng)絡(luò)間的服務(wù)器端網(wǎng)關(guān)上。 (XMPP)與數(shù)據(jù)通道（例如，在 RFC3550 中說明的實(shí)時傳輸協(xié)議 [7]）。 Jingle 的目的不是排擠或替代 SIP。 作為收到的 XEP0111 返饋的一個結(jié)果，文檔的原作者（ Joe Hildebrand 和 Peter SaintAndre）開始定義這樣的一個信號處理協(xié)議，代碼名為 Jingle。基本上，有兩中方法可以解決這個問題： (XMPP+SIP)解決方案。雖然，一些大的服務(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）的互操作性的需求。 警告：本標(biāo)準(zhǔn)跟蹤文檔是實(shí)驗(yàn)性的。作為 XMPP 擴(kuò)展協(xié)議發(fā)表，并不意味著 XMPP 標(biāo)準(zhǔn)基金會批準(zhǔn)了這個協(xié)議。這些網(wǎng)絡(luò)建立在 IETF 的 會話初始化協(xié)議(SIP) 上，在 RFC3261[注 1]及其各種擴(kuò)展中有詳細(xì)說明。 XMPP 信號處理的完整特征的協(xié)議。通過與 Google Talk小組 [4]成員交流，發(fā)現(xiàn)形成的 Jingle方法在概念上（甚至在句法上）都與在 Google Talk 程序中使用的信號處理協(xié)議非常相似。因?yàn)闃?gòu)建雙重 XMPP+SIP 客戶端非常困難，導(dǎo)致本質(zhì)上程序控制的兩個中心，所以，我們將 Jingle 設(shè)計(jì)成純的 XMPP 信號處理協(xié)議。 (例如，用于語音聊天的 )與內(nèi)容傳輸方法 (比如，在 RFC768[8]中說明的用戶數(shù)據(jù)報(bào)協(xié)議 )。 本文檔僅定義了信號處理協(xié)議。參見 RFC2361[14])， ITU 的 協(xié)議（見 [15]）；這些文檔即將完成。在某一時刻，一個會話至少有一個已協(xié)商的內(nèi)容類型。按照 Jingle XML 語法，內(nèi)容類型是元素 description/的命名空間。按照 Jingle XML 語法，這是元素 transport/的命名空間。協(xié)商每個組件的細(xì)節(jié)是由傳輸負(fù)責(zé)。基于完整性的考慮，本文檔也包含了與描述格式和傳輸方法有關(guān)的全部動作的示例。 。自然他們也會修改與會話相關(guān)的其他參數(shù)（如給語音聊天加入視頻）。當(dāng)一方發(fā)出內(nèi)容增加的時候，它 必須 忽略從另一方收到的任何動作，直到收到內(nèi)容增加的確認(rèn)。 會話接受 最終接受會話協(xié)商。 會話中止 結(jié)束現(xiàn)有會話。 很自然，用實(shí)體能力而不是向用戶花名冊中的每個聯(lián)系人發(fā)送服務(wù)發(fā)現(xiàn)請求效率更高。 如果聯(lián)系方有超過一種 XMPP 資源支持 Jingle 和想要的內(nèi)容描述格式， 建議 用 資源應(yīng)用優(yōu)先權(quán) [20]來確定哪種資源最適合初始化 Jingle 會話。 、 39。屬性（兩個字 符唯一區(qū)分會話）。如果任何一方想要對相同的內(nèi)容描述使用多種傳輸方法，則必須發(fā)送多個 content/元素。jingle139。 action=39。a73sjjvkla37jfea39。thisistheaudiocontent39。initiator39。 … /description transport xmlns=39。initiator39。 o ?reasoncode?屬性是 可選的 ，指定機(jī)器可讀的動作發(fā)送目的（如，用在會話中止動作的connectivityerror）。 o 39。地址不同 )。sid39。 o ?name?屬性是 必需的 ；它指明了內(nèi)容類型的獨(dú)特的名字或識別符（這個識別符是不透明的，沒有語義上的意義）。 注意：為了加速會話建立，發(fā)起方 可以 在發(fā)送 “sessioninitiate”消息后接到接收方響應(yīng)之前，立即發(fā)送傳輸候選方法（如，用于 ICE 傳輸?shù)膮f(xié)商），（也就是說，發(fā)起方 必須 認(rèn)定會話是存在的，即使還沒有收到響應(yīng)）。 /balcony39。/ 如果接收方響應(yīng)了發(fā)起請求，雙方都必須認(rèn)定會話處在 阻塞 狀態(tài)。 o 接收方不支持任何指定的內(nèi)容描述格式。 例 3. 發(fā)起方未知 iq type=39。 id=39。 serviceunavailable xmlns=39。error39。jingle139。urn:ietf:params:xml:ns:xmppstanzas39。 /balcony39。 error type=39。/ /error /iq 如果接收方不支持任何一種指定的內(nèi)容 描述格式，它 必須 返回一個 featurenotimplemented/錯誤，和具有 Jingle 特性的出錯條件的 unsupportedcontent。 /orchard39。cancel39。 /error /iq 如果接收方不支持任何一種指定的內(nèi)容傳輸方法，它 必須 返回一個 featurenotimplemented/錯誤，和具有 Jingle 特性的出錯條件的 unsupportedtransports。 /orchard39。cancel39。 /error /iq 如果發(fā)起請求的格式錯誤，接收方 必須 返回一個 badrequest/錯誤。 /orchard39。cancel39。 協(xié)商 一般情況下，雙方在達(dá)成可接受的一系列內(nèi)容類型、內(nèi)容描述格式和內(nèi)容傳輸方法前，協(xié)商是必要的。 /orchard39。set39。 /orchard39。initiator39。 /balcony39。result39。set39。accept139。 /orchard39。 content creator=39。 description xmlns=39。 然后發(fā)起方響應(yīng)接收方的確認(rèn)接受： 例 12. 發(fā)起方響應(yīng)確認(rèn)接受 iq type=39。 id=39。 修改活動會話 為修改一個活動會話，任一方都可向另一方發(fā)送 contentremove、 contentadd、 contentmodify, descriptionmodify、 transportmodify 動作。例如，設(shè)想一下朱麗葉的心情好了，現(xiàn)在想加入視頻。add139。 action=39。a73sjjvkla37jfea39。videoisback39。 /balcony39。result39。add239。 action=39。a73sjjvkla37jfea39。videoisback39。 例 16. 響應(yīng) iq /balcony39。 type=39。 id=39。set39。 /orchard39。a73sjjvkla37jfea39。 /orchard39。如果中止方在發(fā)送了 “會話中止 ”動作后收到了對方額外的 IQ 設(shè)置，它 必須 返回一個 unknownsession/錯誤。動作。 特別地，如果一方從對方收到的在線 (presence)類型是 未知 (unavailable)的話，則它 必須 認(rèn)定會話處于 結(jié)束 狀態(tài)。unavailable39。action39。） 6. 出錯處理 Jingle 專有的出錯條件如下。 7. 支持性檢測 如果一個實(shí)體支持 Jingle，它 必須 在響應(yīng) 服務(wù)發(fā)現(xiàn) [22]信息請求時，通過返回特性 “ 協(xié)議命名空間 ）將這一事實(shí)公布出去。 /balcony39。 /iq 例 21. 服務(wù)發(fā)現(xiàn)信息響應(yīng) iq /balcony39。 type=39。 … /query /iq 應(yīng)用類型 說明某種 Jingle 應(yīng)用類型的文檔（比如，經(jīng)由 RTP 的音頻） 必須 定義： Jingle，如何成功地進(jìn)行內(nèi)容協(xié)商。 。 （例如，對實(shí)時控制協(xié)議來說）。 通過網(wǎng)關(guān)通訊 Jingle 通訊可通過網(wǎng)關(guān)與非 XMPP 網(wǎng)絡(luò)完成，這些網(wǎng)絡(luò)的安全特性與 XMPP 有很大的不同。 11. XMPP注冊處事項(xiàng) 協(xié)議命名空間 在本規(guī)范成為草稿狀態(tài)之前，其相關(guān)的命名空間是 “ XMPP 注冊員 [24]將按照 XMPP 注冊處功能 [25]的第四節(jié)中定義的過程來發(fā)布永久命名空間。 為提交注冊的新值，注冊人須按下面的格式定義一個 XML 段，內(nèi)容包括相關(guān)的 XMPP 擴(kuò)展協(xié)議，或者將它發(fā)送到 。 為提交注冊的新值，注冊人須按下面的格式定義一個 XML 段，內(nèi)容