Clarified service discovery features; added support for zrtp-hash in the signalling channel.
&rfc3711; defines the Secure Real-time Transport Protocol, and &rfc4568; defines the SDP "crypto" attribute for signalling and negotiating the use of SRTP in the context of offer-answer protocols such as SIP. To enable the use of SRTP and gatewaying to non-XMPP technologies that make use of the "crypto" SDP attribute, we define a corresponding <crypto/> element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace.
-If the initiator wishes to use SRTP, the session-initiate stanza MUST include an <encryption/> element, which MUST contain at least one <crypto/> element and MAY include multiple instances of the <crypto/> element. The <encryption/> element MUST be a child of the <description/> element. If the initiator requires the session to be encrypted, the <encryption/> element MUST include a 'required' attribute whose logical value is TRUE and whose lexical value is "true" or "1" &BOOLEANNOTE;, where this attribute defaults to a logical value of FALSE (i.e., a lexical value of "false" or "0").
+If the initiator wishes to use SRTP, the session-initiate stanza shall include an <encryption/> element, which MUST contain at least one <crypto/> element and MAY include multiple instances of the <crypto/> element. The <encryption/> element MUST be a child of the <description/> element. If the initiator requires the session to be encrypted, the <encryption/> element MUST include a 'required' attribute whose logical value is TRUE and whose lexical value is "true" or "1" &BOOLEANNOTE;, where this attribute defaults to a logical value of FALSE (i.e., a lexical value of "false" or "0").
The <crypto/> element is defined as empty (i.e., not containing any child elements); the XML attributes of the <crypto/> element are as follows:
An alternative approach to end-to-end encryption of RTP traffic is provided by &zrtp;. Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message).
+The SDP format is shown below.
+
+a=zrtp-hash:zrtp-version zrtp-hash-value
+
+ An example follows.
+
+a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
+
+ This SDP attribute has been translated into Jingle as a <zrtp-hash/> element, as shown below.
+zrtp-hash-value
+ ]]>
+ An example follows.
+fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
+ ]]>
+ Therefore, if the initiator wishes to use ZRTP, the session-initiate stanza shall include an <encryption/> element, which MUST contain one and only one <zrtp-hash/> element. Note: The <encryption/> element MUST include only 1+ <crypto/> elements (for SRTP) or 1 <zrtp-hash/> element (for ZRTP), but not both.
+Informational messages can be sent by either party within the context of Jingle to communicate the status of a Jingle RTP session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:apps:rtp:info:1' namespace; the following payload elements are defined:
If an entity supports Jingle RTP session, it MUST advertise that fact by returning a feature of "urn:xmpp:jingle:apps:rtp:1" &VNOTE; in response to &xep0030; information requests.
+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:
+An example follows.
Thanks to Milton Chen, Paul Chitescu, Olivier Crête, Tim Julien, Steffen Larsen, Jeff Muller, Mike Ruprecht, Justin Uberti, and Paul Witty for their feedback.
+Thanks to Milton Chen, Paul Chitescu, Olivier Crête, Tim Julien, Steffen Larsen, Jeff Muller, Mike Ruprecht, Sjoerd Simons, Justin Uberti, and Paul Witty for their feedback.