0.11-pre2

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@148 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2006-10-31 22:16:10 +00:00
parent 0a71f4a6e1
commit ded00c0522
1 changed files with 16 additions and 6 deletions

View File

@ -10,7 +10,7 @@
<abstract>This document defines a framework for initiating and managing peer-to-peer sessions (e.g., voice and video exchanges) between Jabber/XMPP clients in a way that is interoperable with existing Internet standards.</abstract>
&LEGALNOTICE;
<number>0166</number>
<status>Experimental</status>
<status>Proposed</status>
<type>Standards Track</type>
<jig>Standards JIG</jig>
<approver>Council</approver>
@ -28,9 +28,9 @@
&robmcqueen;
<revision>
<version>0.11</version>
<date>2006-10-30</date>
<date>2006-10-31</date>
<initials>psa</initials>
<remark><p>Made small clarifications and corrections throughout; added section on Jingle Actions.</p></remark>
<remark><p>Completed clarifications and corrections throughout; added section on Jingle Actions.</p></remark>
</revision>
<revision>
<version>0.10</version>
@ -221,6 +221,16 @@
<li>Content transport methods (the "how")</li>
</ol>
<p>This document defines the semantics and syntax for overall session management. It also provides pluggable "slots" for content description formats and content transport methods, which are specified in separate documents; however, for the sake of completeness, this document also includes examples for all of the actions related to description formats and transport methods.</p>
<p>At the most basic level, the process for negotiating a Jingle session is as follows:</p>
<ol>
<li>One user (the "initator") sends to another user (the "receiver") a session request with one content type, which includes one content description and (say) two potential transport methods.</li>
<li>If the receiver wants to proceed, it provisionally accepts the request by sending an IQ result.</li>
<li>Both the initiator and receive start exchanging possible transport candidates as quickly as possible (these are sent in quick succession before further negotiation in order to minimize the time required before media data can flow).</li>
<li>These candidates are checked for connectivity.</li>
<li>As soon as the receiver finds a candidate over which media can flow, the receiver sends to the initiator a "session-accept" action.</li>
<li>The parties start sending media over the negotiated candidate.</li>
</ol>
<p>If the parties later discover a better candidate, they perform a "transport-modify" or "content-modify" negotiation and then switch to the better candidate. Naturally they can also modify various other parameters related to the session (e.g., adding video to a voice chat).</p>
<section2 topic='Overall Session Management' anchor='concepts-session'>
<p>The state machine for overall session management (i.e., the state per Session ID) is as follows:</p>
<code>
@ -664,14 +674,14 @@ PENDING o---------------------+ |
<p>Naturally, in this case there is nothing for the initiating entity to acknowledge.</p>
</section2>
<section2 topic='Informational Messages' anchor='protocol-info'>
<p>At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to change a content transport method or content description format parameter, inform the other party that a session initiation request is queued, that a device is ringing, or that a scheduled event has occurred or will occur. An information message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info", "description-info", or "transport-info"; the &JINGLE; element MUST further contain a payload child element (speciific to the session, content description format, or content transport method) that specifies the information being communicated. (A future version of this specification will define payloads related to the "session-info" action.)</p>
<p>At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to change a content transport method or content description format parameter, inform the other party that a session initiation request is queued, that a device is ringing, or that a scheduled event has occurred or will occur. An information message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info", "description-info", or "transport-info"; the &JINGLE; element MUST further contain a payload child element (speciific to the session, content description format, or content transport method) that specifies the information being communicated. If an empty "session-info" message is received for an active session, the receiving entity MUST send an empty IQ result. This way, an empty "session-info" message may be used as a "ping" to determine session vitality. (A future version of this specification will define payloads related to the "session-info" action.)</p>
</section2>
</section1>
<section1 topic='Jingle Actions' anchor='actions'>
<p>This section provides more detailed descriptions for each Jingle-related action.</p>
<section2 topic='content-accept' anchor='actions-content-accept'>
<p>This action enables a party to accept a content-add, content-modify, or content-remove action received from another party. Implicitly this action also serves as a description-accept and transport-accept.</p>
<p>This action enables a party to accept a content-add or content-remove action received from another party. Implicitly this action also serves as a description-accept and transport-accept.</p>
</section2>
<section2 topic='content-add' anchor='actions-content-add'>
<p>This action enables a party to add one or more new content types to the session. This action MUST NOT be sent while the session is in the PENDING state.</p>
@ -680,7 +690,7 @@ PENDING o---------------------+ |
<p>This action enables a party to reject a content-add or content-modify action received from another party.</p>
</section2>
<section2 topic='content-modify' anchor='actions-content-modify'>
<p>This action enables a party to change an existing content type. This is mainly used to modify the directionality of the session.</p>
<p>This action enables a party to change an existing content type. The recipient MUST NOT reply to a content-modify action with another content-modify action. The content-modify action is mainly used to modify the directionality of the session.</p>
</section2>
<section2 topic='content-remove' anchor='actions-content-remove'>
<p>This action enables a party to remove one or more content types from the session.</p>