Basic foundation for providing voice/video chat between XMPP entities
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply acceptance or approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is NOT RECOMMENDED except in an exploratory fashion (e.g., in a proof of concept). Production systems SHOULD NOT deploy implementations of this protocol until it advances to a status of Draft.
Email: justin@affinix.com
JID: justin@andbit.net
Status: Experimental
Type: Standards Track
Number: 01xx
Version: 0.1
Last Updated: 2004-03-22
JIG: Standards JIG
Dependencies: JEP-0095, jep-rtsp
Supersedes: None
Superseded By: None
Short Name: media
This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined herein have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.
The preferred venue for discussion of this document is the Standards-JIG mailing list: <https://jabberstudio.org/mailman/listinfo/standards-jig>.
This specification defines a profile of Stream Initiation [1] for negotiating media streams, which are data channels of voice, video, or both, sent between XMPP entities. It is intended to be useful for nearly any kind of media requirement, including 'Web cams', VoIP, music broadcasting, etc.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
The transfer profile is in the "http://jabber.org/protocol/si/profile/media" namespace. The profile is fairly simple: it consists of a <media> element with the possibility of some child elements. Only the sender provides such elements.
At least one of the audio or video elements MUST be present in the sender request. If a two-way element is specified, but the receiver cannot provide at least one of the the same kind of offered content, then the receiver MUST reject the request.
Once the receiver accepts the stream initiation, the sender MUST start an RTSP (jep-rtsp) session with the receiver, using the "id" attribute transported on the <si/> element as the sid. If the two-way element is specified, the receiver MUST also start an RTSP session with the sender, but using the value contained in the two-way element as the sid. The receiver MUST at least offer one of the same kind of content as the sender.
While RTSP is capable of transmitting any kind of data (such as whiteboards), only audio and video streams are allowed with this specification. In order to enable seamless media stream use, implementations of this profile MUST offer the 'video/JPEG' codec (if offering video), and either 'audio/vorbis' or 'audio/speex' codecs (if offering audio, the latter for voice-only). Additionally, implementations MAY support other codecs.
Once an RTSP channel is formed, the client MUST issue a "SETUP" command followed by a "PLAY" command, on the offered RTSP resources.
Example 1. Voice Chat
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
id='a0'
profile='http://jabber.org/protocol/si/profile/media'>
<media xmlns='http://jabber.org/protocol/si/profile/media'>
<audio/>
<two-way>anotherSID</two-way>
</media>
</si>
</iq>
Example 2. Voice Chat Result
<iq type='result' to='sender@jabber.org/resource' id='offer1'/>
Example 3. Video Broadcast
<iq type='set' id='offer1' to='receiver@jabber.org/resource'>
<si xmlns='http://jabber.org/protocol/si'
id='a0'
profile='http://jabber.org/protocol/si/profile/media'>
<media xmlns='http://jabber.org/protocol/si/profile/media'>
<audio/>
<video/>
<desc>State of the Bulb</desc>
</media>
</si>
</iq>
Example 4. Video Broadcast Result
<iq type='result' to='sender@jabber.org/resource' id='offer1'/>
No interaction with the Internet Assigned Numbers Authority (IANA) [3] is required as a result of this JEP.
The profile described in this JEP will be registered with Jabber Registrar [4] as a valid Stream Initiation profile.
1. JEP-0095: Stream Initiation <http://www.jabber.org/jeps/jep-0095.html>.
2. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels <http://www.ietf.org/rfc/rfc2119.txt>.
3. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
4. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
Version 0.1 (2004-03-22)
Initial version. (jk)