ProtoXEP jingle-ice: Updates to address Council feedback

This commit is contained in:
Matthew A. Miller 2016-01-05 10:10:22 -07:00
parent 93724e9aca
commit 7d839f60a4
1 changed files with 37 additions and 10 deletions

View File

@ -28,6 +28,17 @@
<supersededby/>
<shortname>jingle-ice</shortname>
&stpeter;
<revision>
<version>0.0.2</version>
<date>2015-12-30</date>
<initials>psa</initials>
<remark>
<ul>
<li>Added a 'tcptype' attribute to support ICE-TCP (RFC 6544) instead of overloading the existing 'type' attribute, with values of "active", "passive", and "so".</li>
<li>Modified the syntax of the end-of-candidates indication so that it is wrapped in a &lt;transport/&gt; element in the same namespace.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2015-12-16</date>
@ -248,23 +259,29 @@ INITIATOR RESPONDER
<tr>
<td>rel-addr</td>
<td>A related address as defined in RFC 5245.</td>
<td>raddr value in a=candidate line</td>
<td>Value of raddr attribute in a=candidate line</td>
<td>10.0.1.1</td>
</tr>
<tr>
<td>rel-port</td>
<td>A related port as defined in RFC 5245.</td>
<td>rport value in a=candidate line</td>
<td>Value of rport attribute in a=candidate line</td>
<td>8998</td>
</tr>
<tr>
<td>tcptype</td>
<td>A TCP candidate type as defined in RFC 6455. The allowable values are "active" for TCP active candidates, "passive" for TCP passive candidates, and "so" for TCP simultaneous-open candidates.</td>
<td>Value of tcptype attribute in a=candidate line</td>
<td>so</td>
</tr>
<tr>
<td>type</td>
<td>A Candidate Type as defined in RFC 5245 or RFC 6455. The allowable values are "host" for host candidates, "prflx" for peer reflexive candidates, "relay" for relayed candidates, "srflx" for server reflexive candidates, "tcp-active" for TCP active candidates, "tcp-passive" for TCP passive candidates, and "tcp-so" for TCP simultaneous-open candidates (the last three map to values from RFC 6455).</td>
<td>Typ field in a=candidate line</td>
<td>An ICE candidate type as defined in RFC 5245. The allowable values are "host" for host candidates, "prflx" for peer reflexive candidates, "relay" for relayed candidates, and "srflx" for server reflexive candidates. Note that TCP candidate types (RFC 6455) are handled via the 'tcptype' attribute.</td>
<td>Value of typ attribute in a=candidate line</td>
<td>srflx</td>
</tr>
</table>
<p>Note this specification does not provide an no equivalent of the "ice-options" attribute defined in Section 15.5 of RFC 5245, since it is not needed in XMPP given the existence of the Service Discovery extension (XEP-0030).</p>
<p>Note this specification does not provide an equivalent of the "ice-options" attribute defined in Section 15.5 of RFC 5245, since it is not needed in XMPP given the existence of the Service Discovery extension (XEP-0030).</p>
</section2>
<section2 topic='Response' anchor='protocol-response'>
<p>As described in <cite>XEP-0166</cite>, to acknowledge receipt of the session initiation request, the responder immediately returns an IQ-result.</p>
@ -391,7 +408,7 @@ INITIATOR NAT RESPONDER
<p>Note: Here the initiator (controlling agent) is using "aggressive nomination" as described in Section 8.1.1.2 of RFC 5245 and therefore includes the USE-CANDIDATE attribute in the STUN Binding Requests it sends.</p>
</section2>
<section2 topic='End-of-Candidates Indication' anchor='protocol-end'>
<p>As explained in the Trickle ICE specification, when a party has completed gathering of candidates it will send an "end-of-candidates indication" to the other party. In Jingle, this takes the form of an informational message as described under <link url='#info'>Informational Messages</link>. This specificaton defines only a standalone "end-of-candidates indication" (i.e., not a way to indicate ICE completion in an offer or answer).</p>
<p>As explained in the Trickle ICE specification, when a party has completed gathering of ICE candidates it will send an "end-of-candidates indication" to the other party. In Jingle, this takes the form of an informational message as described under <link url='#info'>Informational Messages</link>. This specificaton defines only a standalone "end-of-candidates indication" (i.e., not a way to indicate ICE completion in an offer or answer).</p>
</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>
@ -698,7 +715,9 @@ Romeo Gateway Juliet
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-the-audio-content'>
<ice-gathering-complete xmlns='urn:xmpp:jingle:transports:ice:info:0'/>
<transport xmlns='urn:xmpp:jingle:transports:ice:0'>
<gathering-complete/>
</transport>
</content>
</jingle>
</iq>
@ -890,6 +909,15 @@ Romeo Gateway Juliet
<xs:attribute name='protocol' type='xs:NCName' use='required'/>
<xs:attribute name='rel-addr' type='xs:string' use='optional'/>
<xs:attribute name='rel-port' type='xs:unsignedShort' use='optional'/>
<xs:attribute name='tcptype' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='active'/>
<xs:enumeration value='passive'/>
<xs:enumeration value='so'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
@ -897,9 +925,6 @@ Romeo Gateway Juliet
<xs:enumeration value='prflx'/>
<xs:enumeration value='relay'/>
<xs:enumeration value='srflx'/>
<xs:enumeration value='tcp-active'/>
<xs:enumeration value='tcp-passive'/>
<xs:enumeration value='tcp-so'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
@ -917,6 +942,8 @@ Romeo Gateway Juliet
</xs:simpleContent>
</xs:complexType>
<xs:element name='gathering-complete' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>