moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

feedback from Justin Karneges

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3014 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-04-07 23:38:37 +00:00
parent 83decbbc79
commit fa594b187e
4 changed files with 18 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0166.xml
View File

@ -1125,12 +1125,12 @@ PENDING o-----------------------+ |
<td>REQUIRED</td>
</tr>
<tr>
<td>initiator</td>
<td>The full JID of the entity that has initiated the session flow. This can be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays); however, if the 'initiator' and 'from' values are different then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts the 'from' JID to authorize the 'initiator' JID to act on its behalf. For details, refer to &xep0251;.</td>
<td>initiator*</td>
<td>The full JID of the entity that has initiated the session flow. This can be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays); however, if the 'initiator' and 'from' values are different then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts the 'from' JID to authorize the 'initiator' JID to act on its behalf.</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>responder</td>
<td>responder*</td>
<td>The full JID of the entity that has replied to the initiation, which can be different from the 'to' address on the IQ-set.</td>
<td>RECOMMENDED</td>
</tr>
@ -1140,6 +1140,7 @@ PENDING o-----------------------+ |
<td>REQUIRED</td>
</tr>
</table>
<p class='box'>* Note: In the absence of explicit handling for the 'initiator' and 'responder' attributes (for example, as described in &xep0251;), a Jingle application MAY simply ignore these attributes if their values are different from the 'from' and 'to' attributes of the session-initiate message. For further descriptions of the 'initiator' and 'responder' attributes, see also the definitions of the <link url='#def-action-session-accept'>session-accept</link> and <link url='#def-action-session-accept'>session-accept</link> actions respectively.</p>
</section2>
<section2 topic='Action Attribute' anchor='def-action'>
<p>The value of the 'action' attribute MUST be one of the following. If an entity receives a value not defined here, it MUST ignore the attribute and MUST return a &badrequest; error to the sender. There is no default value for the 'action' attribute.</p>
@ -1165,13 +1166,16 @@ PENDING o-----------------------+ |
<p>The <strong>security-info</strong> action is used to send information related to establishment or maintenance of security preconditions.</p>
</section3>
<section3 topic='session-accept' anchor='def-action-session-accept'>
<p>The <strong>session-accept</strong> action is used to definitively accept a session negotiation (implicitly this action also serves as a content-accept). A session-accept action indicates a willingness to proceed with the session (which might necessitate further negotiation before media can be exchanged). The session-accept action indicates acceptance <em>only</em> of the content definition(s) whose disposition type is "session" (the default value of the &CONTENT; element's 'disposition' attribute), not any content definition(s) whose disposition type is something other than "session" (e.g., "early-session" for early media). In the session-accept stanza, the &JINGLE; element MUST contain one or more &lt;content/&gt; elements, each of which MUST contain one &lt;description/&gt; element and one &lt;transport/&gt; element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; after sending acknowledgement of the session-accept, the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute and note the new JID in the user interface.</p>
<p>The <strong>session-accept</strong> action is used to definitively accept a session negotiation (implicitly this action also serves as a content-accept). A session-accept action indicates a willingness to proceed with the session (which might necessitate further negotiation before media can be exchanged). The session-accept action indicates acceptance <em>only</em> of the content definition(s) whose disposition type is "session" (the default value of the &CONTENT; element's 'disposition' attribute), not any content definition(s) whose disposition type is something other than "session" (e.g., "early-session" for early media).</p>
<p>In the session-accept stanza, the &JINGLE; element MUST contain one or more &lt;content/&gt; elements, each of which MUST contain one &lt;description/&gt; element and one &lt;transport/&gt; element.</p>
<p>The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; after sending acknowledgement of the session-accept, the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute and note the new JID in the user interface.</p>
</section3>
<section3 topic='session-info' anchor='def-action-session-info'>
<p>The <strong>session-info</strong> action is used to send session-level information, such as a session ping or (for Jingle RTP sessions) a ringing message.</p>
</section3>
<section3 topic='session-initiate' anchor='def-action-session-initiate'>
<p>The <strong>session-initiate</strong> action is used to request negotiation of a new Jingle session. When sending a session-initiate, the value of the &CONTENT; element's 'disposition' attribute MUST be "session" (to be precise, if there are multiple &CONTENT; elements then at least one MUST have a disposition of "session"); if this rule is violated, the responder MUST return a &badrequest; error to the initiator.</p>
<p>The <strong>session-initiate</strong> action is used to request negotiation of a new Jingle session. When sending a session-initiate with one &CONTENT; element, the value of the &CONTENT; element's 'disposition' attribute MUST be "session" (if there are multiple &CONTENT; elements then at least one MUST have a disposition of "session"); if this rule is violated, the responder MUST return a &badrequest; error to the initiator.</p>
<p>The &JINGLE; element SHOULD possess an 'initiator' attribute that explicitly specifies the full JID of the initiating entity; after sending acknowledgement of the session-initiate message, the responder SHOULD send all future commmunications about this Jingle session to the JID provided in the 'initiator' attribute and note the new JID in the user interface.</p>
</section3>
<section3 topic='session-terminate' anchor='def-action-session-terminate'>
<p>The <strong>session-terminate</strong> action is used to end an existing session.</p>
@ -1484,7 +1488,7 @@ PENDING o-----------------------+ |
<p>Jingle communications can be enabled through gateways to non-XMPP networks, whose security characteristics can be quite different from those of XMPP networks. (For example, on some SIP networks authentication is optional and "from" addresses can be easily forged.) Care MUST be taken in communicating through such gateways.</p>
</section2>
<section2 topic='Information Exposure' anchor='security-info'>
<p>Mere negotiation of a Jingle session can expose sensitive information about the parties (e.g., IP addresses). Care MUST be taken in communicating such information, and end-to-end encryption SHOULD be used if the parties do not trust the intermediate servers or gateways.</p>
<p>Mere negotiation of a Jingle session can expose sensitive information about the parties (e.g., IP addresses, or even the full JID of the responder). Care MUST be taken in communicating such information, and end-to-end encryption SHOULD be used if the parties do not trust the intermediate servers or gateways.</p>
</section2>
<section2 topic='Redirection' anchor='security-redirect'>
<p>The 'initiator' and 'responder' attributes can be used to redirect a session from one JID to anther JID (i.e., the 'initiator' or 'responder' attribute might not match the 'from' or 'to' attribute of the sender). An application SHOULD NOT accept the redirection unless the bare JIDs match (i.e., the session is being redirected from one authorized resource to another authorized resource associated with the same account).</p>

11
xep-0167.xml
View File

@ -258,7 +258,7 @@
<li><p>The application format negotiation process is defined in the <link url='#negotiation'>Negotiating a Jingle RTP Session</link> section of this document.</p></li>
<li><p>The semantics of the &DESCRIPTION; element are defined in the <link url='#format'>Application Format</link> section of this document.</p></li>
<li><p>A mapping of Jingle semantics to the Session Description Protocol is provided in the <link url='#sdp'>Mapping to Session Description Protocol</link> section of this document.</p></li>
<li><p>A Jingle RTP session SHOULD use a datagram transport method (e.g. &xep0177; or the "ice-udp" method specified in &xep0176;), but MAY use a streaming transport if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a streaming transport for audio, but not for video).</p></li>
<li><p>A Jingle RTP session SHOULD use a datagram transport method (e.g. &xep0177; or the "ice-udp" method specified in &xep0176;), but MAY use a streaming transport if the end-to-end link has minimal latency and the media negotiated is not unduly heavy (e.g., it might be possible to use a streaming transport for audio, but not for video).</p></li>
<li><p>If multiple components are to be communicated over the chosen transport, the component numbered "1" shall be associated with RTP and the component numbered "2" shall be associated with the Real Time Control Protocol (RTCP).</p></li>
<li>
<p>Content is to be sent and received as follows:</p>
@ -343,7 +343,8 @@
<parameter name='foo' value='bar'/>
]]></code>
<p>The order of parameter elements MUST be ignored.</p>
<p>Parameter names MUST be treated as case-sensitive. However, parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see &lt;<link url='http://www.iana.org/assignments/sdp-parameters'>http://www.iana.org/assignments/sdp-parameters</link>&gt;).</p>
<p>Parameter names MUST be treated as case-sensitive.</p>
<p>Note: Parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see &lt;<link url='http://www.iana.org/assignments/sdp-parameters'>http://www.iana.org/assignments/sdp-parameters</link>&gt;).</p>
</section1>
<section1 topic='Negotiating a Jingle RTP Session' anchor='negotiation'>
@ -582,7 +583,7 @@ delivery-method=inline; configuration=somebase16string;
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32
session-params:KDR=1;UNENCRYPTED_SRTCP
]]></code>
<p>When the responder receives a session-initiate message containing an &lt;encryption/&gt; element, the responder MUST either (1) accept the offer by denoting one of the &lt;crypto/&gt; elements as acceptable (it does this by mirroring that &lt;crypto/&gt; element in its session acceptance) or (2) reject the offer by sending a session-terminate message with a Jingle reason of &lt;security-error/&gt; and an RTP-specific condition of &lt;invalid-crypto/&gt;.</p>
<p>When the responder receives a session-initiate message containing an &lt;encryption/&gt; element, the responder MUST either (1) accept the offer by denoting one of the &lt;crypto/&gt; elements as acceptable (it does this by mirroring that &lt;crypto/&gt; element in its session acceptance) or (2) reject the offer by sending a session-terminate message with a Jingle reason of &lt;security-error/&gt; (typically with an RTP-specific condition of &lt;invalid-crypto/&gt;).</p>
<example caption="Responder terminates session because of invalid crypto"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='nv71c396'
@ -678,7 +679,7 @@ delivery-method=inline; configuration=somebase16string;
]]></example>
</section2>
<section2 topic='Mute' anchor='info-mute'>
<p>The &lt;mute/&gt; payload indicates that the principal is temporarily not sending media to the other party but continuing to accept media from the other part. The &lt;mute/&gt; element MAY possess a 'name' attribute whose value specifies a particular session to be muted (e.g., muting the audio aspect but not the video aspect of a voice+video chat). If no 'name' attribute is included, the recipient MUST assume that all sessions are to be muted.</p>
<p>The &lt;mute/&gt; payload indicates that the principal is temporarily not sending media to the other party but continuing to accept media from the other party. The &lt;mute/&gt; element MAY possess a 'name' attribute whose value specifies a particular session to be muted (e.g., muting the audio aspect but not the video aspect of a voice+video chat). If no 'name' attribute is included, the recipient MUST assume that all sessions are to be muted.</p>
<example caption="Responder sends mute message"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='hg4891f5'
@ -741,7 +742,7 @@ delivery-method=inline; configuration=somebase16string;
<p>To advertise its support for Jingle RTP Sessions and specific media types for RTP, when replying to &xep0030; information requests an entity MUST return the following features:</p>
<ul>
<li>URNs for any version of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:apps:rtp:1" for this version and "urn:xmpp:jingle:apps:rtp:0" for the previous version &VNOTE;</li>
<li>URNs for all of the media types that the entity supports -- e.g., "urn:xmpp:jingle:apps:rtp:audio" for RTP audio and "urn:xmpp:jingle:apps:rtp:video" for RTP video</li>
<li>URNs for all of the media types that the entity supports -- e.g., "urn:xmpp:jingle:apps:rtp:audio" for RTP audio and "urn:xmpp:jingle:apps:rtp:video" for RTP video <note>Support for the "audio" or "video" media type does not necessarily mean that the application supports all sub-types associated with those media types.</note></li>
</ul>
<p>An example follows.</p>
<example caption="Service discovery information request"><![CDATA[

2
xep-0176.xml
View File

@ -536,7 +536,7 @@ INITIATOR NAT RESPONDER
</section2>
<section2 topic='Acceptance of Successful Candidate' anchor='protocol-acceptance'>
<p>If, based on STUN connectivity checks, the parties determine that they will be able to exchange media between a given pair of local candidates and remote candidates (i.e., the pair is "nominated" and ICE processing is "completed"), they can then begin using that candidate pair to exchange media.</p>
<p>Once the parties have connectivity and therefore the initiator has completed ICE as explained in &icecore;, the initiator MAY communicate the in-use candidate pair in the signalling channel by sending a transport-info message that contains a &lt;remote-candidate/&gt; element (this maps to the SDP "remote-candidates attribute as described in Section B.6 of &icecore;, i.e., remote candidates are "the actual candidates at R that were selected by the offerer", of which there will be only one at this stage of the ICE-UDP negotiation).</p>
<p>Once the parties have connectivity and therefore the initiator has completed ICE as explained in &icecore;, the initiator MAY communicate the in-use candidate pair in the signalling channel by sending a transport-info message that contains a &lt;remote-candidate/&gt; element (this maps to the SDP "remote-candidates" attribute as described in Section B.6 of &icecore;, i.e., remote candidates are "the actual candidates at R that were selected by the offerer", of which there will be only one at this stage of the ICE-UDP negotiation).</p>
<example caption="Initiator communicates in-use candidate"><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='pd81b49s'

2
xep-0177.xml
View File

@ -286,7 +286,7 @@ INITIATOR RESPONDER
</section2>
<section2 topic='Sending Media' anchor='media'>
<p>Upon sending the session-accept action, the responder MUST immediately send attempt to send media to the initiator. Upon receiving the session-accept action, the initiator MUST immediately attempt to send media to the responder.</p>
<p>Upon sending the session-accept action, the responder MUST immediately attempt to send media to the initiator. Upon receiving the session-accept action, the initiator MUST immediately attempt to send media to the responder.</p>
<p>An implementation SHOULD enforce a timeout on receipt of media, such that if no media is received from the other party within a reasonable period of time, the implementation will consider the session to have failed and therefore send to the other party a Jingle "session-terminate" action with a reason code of &lt;timeout/&gt;.</p>
<example caption="Responder terminates the session"><![CDATA[
<iq from='juliet@capulet.lit/balcony'