【正文】 容接受 接受從另一方受到的內容增加或內容移除。這個動作 不能 在會話的 阻塞 狀態(tài)時發(fā)出。 內容修改 改變現(xiàn)有的內容類型。 內容移除 從會話中移除一個或多個內容類型。表明這個動作也適合內容接受（進而適合描述接受和傳輸接收）。 會話開始 請求一個新 Jingle 會話協(xié)商。 傳輸信息 交換傳輸候選 方法；主要用在 XEP0176 中，也可以用在其他規(guī)范中。如果聯(lián)系方僅有一種 XMPP 資源，這一任務 必須 用服務發(fā)現(xiàn) [18]或用在實體能力 [19]中說明的基于現(xiàn)身(presencebased)的簡介 (profile)的服務發(fā)現(xiàn)來完成。由此，某個客戶版本對 Jingle 及各種 Jingle 內容描述格式和內容傳輸方法的支持等一般性信息（而不是每個的 JID 的）都能確定下來，這些信息 隨后被緩存。 如果聯(lián)系方有不止一種 XMPP 資源，可能僅有一種資源支持 Jingle 和想要的內容描述格式，在這種情況下，用戶 必須 用這一資源初始化 Jingle 信號處理。 初始化 一旦發(fā)起方發(fā)現(xiàn)了接收方哪種 XMPP 資源適合想要的內容描述格式，就向接收方發(fā)送一個會話初始化請求。action39。initiator39。sid39。初始化時， 39。屬性 必須 是sessioninitiate， jingle/元素 必須 包含一個或多個 content/元素，每個元素定義會話期間的要傳輸?shù)膬热蓊愋停幻總€ content/元素分別包含 description/子元素，指定想要的內容描述格式，transport/子元素，指定了可能的內容傳輸方法。 下面是一個 Jingle 會話初始化請求的例子，會話包含了音頻 和視頻： 例 1. 初始化示例 iq /orchard39。 id=39。 type=39。 jingle xmlns=39。sessioninitiate39。 sid=39。 content creator=39。 name=39。 description xmlns=39。 /content content creator=39。 name=39。 description xmlns=39。 /content /jingle /iq 注意：元素 description/和 transport/的語法、語義超出了本規(guī)范的范圍，它們在相關的規(guī)范中定義。 o 39。屬性是發(fā)起會話流的實體的完整 JID(可能與 IQ 集中地址 39。不同 )。 o 39。屬性是 可選的 ，指定人可讀的動作發(fā)送目的（如，用于會話中止動作的Sorry,gotta go）。responder39。to39。 o ?sid?屬性是由發(fā)起方產生的隨機的會話識別符；它 應該 符合 XML Nmtoken production[21]，這樣對 amp。（注意： 39。屬性可有效地映射到 SIP 的 ?CallID?參數(shù)） 元素 content/有如下屬性： o 39。屬性是 必需的 ；它指明了那一方最初產生的內容描述 (用于防止修改時的競態(tài)條件(race conditions)的發(fā)生 )。 o 39。屬性是 推薦的 ；對有些內容類型，它說明了所用的簡介（如，在實時傳輸協(xié)議上 下文中的 RTP/AVP） o ?senders?屬性是 推薦的 ；它說明了會話中那個實體將要產生內容；允許的值是 initiator，recipient或 both（缺省值是 both）。如果按順序傳輸?shù)脑?，接收方應在收?sessioninitiate消息后，應收到諸 如transportinfo之類的消息（如果沒收到，那么接收方返回 unknownsession/錯誤是恰當?shù)?，因為按照它的狀態(tài)機，會話并不存在）。result39。 /orchard39。jingle139。 有幾種原因接收 方會返回一個錯誤，而不是響應發(fā)起請求： o 對接收方來說發(fā)起方是未知的（比如，通過在線 (presence)訂閱），接收方不能與未知實體通訊。 o 接收方不支持 Jingle。 o 接收方不支持任何指定的內容傳輸方法。 如果對接收方來說發(fā)起方是未知的（比如，通過在線訂閱），并且接收方有不與未知實體經由 Jingle 通訊的策略，則接收方 應該 返回一個 serviceunavailable/錯誤。error39。 /orchard39。jingle139。cancel39。urn:ietf:params:xml:ns:xmppstanzas39。 例 4. 接收 方轉向 iq type=39。 /balcony39。 id=39。 error type=39。 redirect xmlns=39。xmpp:m/redirect /error /iq 如果接收方不支持 Jingle,則 必須 返回一個錯誤。error39。 /orchard39。jingle139。cancel39。urn:ietf:params:xml:ns:xmppstanzas39。 例 6. 接收方不支持任何內容描述格式 iq type=39。 /balcony39。 id=39。 error type=39。 featurenotimplemented xmlns=39。/ unsupportedcontent xmlns=39。 例 7. 接收方不支持任何內容傳輸方法 iq type=39。 /balcony39。 id=39。 error type=39。 featurenotimplemented xmlns=39。/ unsupportedtransports xmlns=39。 例 8. 發(fā)起請求的格式錯誤 iq type=39。 /balcony39。 id=39。 error type=39。 badrequest xmlns=39。/ /error /iq 拒絕 為拒絕會話發(fā)起請求，接收方 必須 響應收到的會話發(fā)起請求，然后按 中止 中描述的方法中止會話?？赡芤獏f(xié)商的這些參數(shù)的組合是很多的，這里并沒有列出全部（有些在各種內容描述格式和內容傳輸方法規(guī)范中列出）。例如，讓我們設想，有一天朱麗葉的心情很糟糕，她當然不想在和羅密歐的 Jingle 會話中包含視頻，所以她給羅密歐發(fā)送了一個 “內容移除 ”請求： 例 9. 內容類型移除 iq /balcony39。 id=39。 type=39。 jingle xmlns=39。contentremove39。 sid=39。 content creator=39。 name=39。/ /jingle /iq 實體收到了這個會話縮減請求，然后響應這個請求： 例 10. 響應 iq /orchard39。 id=39。 type=39。/ 如果縮減的結果是會話不再有任何內容類型，收到會話縮減的實體 應該 向另一方發(fā)送會話中止動作（因為沒有內容類型的會話是無效的）。 接受 協(xié)商過內容傳輸方法和內容描述格式后，如果接收方確定能夠建立連接，它將向發(fā)起方法送確定接受： 例 11. 接收方確定接受呼叫 iq type=39。 /balcony39。 id=39。 jingle xmlns=39。sessionaccept39。 /balcony39。a73sjjvkla37jfea39。initiator39。thisistheaudiocontent39。 … /description transport xmlns=39。 jingle/元素 應該 有 ?responder?屬性，以明確指明響應實體的完整 JID，有關當前 Jingle 會話的所有通訊，發(fā)起方應該向這個 JID 發(fā)送。result39。 /orchard39。accept139。 如果一方無法找到合適的內容傳輸方法，它 應該 下面描述的那樣中止會話。然后接收方發(fā)送恰當?shù)腶ccept或 decline動作，也可能首先發(fā)送一個 info動作。 修改活動會話的一個例子是增加一個會話內容。于是向羅密歐發(fā)送 contentadd請求： 例 13. 增加一個內容類型 iq /balcony39。 id=39。 type=39。 jingle xmlns=39。contentadd39。 sid=39。 content creator=39。 name=39。 description xmlns=39。 candidate .../ /transport /content /jingle /iq 實體接收到會話擴展請 求，響應這個請求，如果可接受，返回一個內容接受： The entity receiving the session extension request then acknowledges the request and, if it is acceptable, returns a contentaccept: 例 14. 響應 iq /orchard39。 id=39。 type=39。/