Jingle [1] defines a framework for negotiating and managing out-of-band multimedia sessions over XMPP. In order to provide a flexible framework, the base Jingle specification omits data transport methods and media session types, requiring separate specifications. Typical peer-to-peer session types include voice chat (see Jingle Audio Content Description Format [2]) and video chat (see Jingle Video Content Description Format [3]) which are based on the Real-time Transport Protocol (RTP) and will be suitable for WebRTC.
WebRTC uses a protocol called JavaScript Session Establishment Protocol (JSEP) [4] that pulls the media negotiation and signaling state machine out of the browser into JavaScript. JSEP like Jingle separates session descriptions from transports and exposes the media negotiation to the application developer making it very compatible with Jingle,.
In order to use WebRTC with the Jingle RTP-ICE Transport Method [5] requires the developer to translate between the web browser session descriptions and Jingle. This means understanding WebRTC SDP and correct translation into Jingle by the call initiator and back into SDP by the call target. The developer must also create correct RTP-ICE transport candidates at both call ends.
When both paticipants of an audio/video call are both web browsers supporting WebRTC, we already know that the web browsers will transport the media between each other, so it makes for a simpler and neater approach to simply forward the session description messages emitted from the web browser as Jingle session info payload messages instead of translating web browser SDP offer/answer media data into Jingle session descriptions and constructing redundant transport candidates.
This document defines a new Jingle transport method for establishing and managing WebRTC media streams.
For the full proposed specification, please go here