XEP-xxxx: Jingle WebRTC Transport
**Note: **Please note that this XEP has been abandoned in preference to parsing the SDP to Jingle and vice versa. See https://github.com/mweibel/sdpToJingle for a draft implementation of an SDP/Jingle parsing library.
This specification defines a Jingle transport method to negotiate media between web browsers or other compatible devices that support WebRTC.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at http://www.xmpp.org/extensions/ and announced on the standards@xmpp.org mailing list.
Document Information
Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Informational
Version: 0.0.2
Last Updated: 2012-02-17
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0166
Supersedes: None
Superseded By: None
Short Name:
Author Information
Dele Olajide
Email: dele@olajide.net
Michael Weibel
Email: michael.weibel+xmpp@gmail.com
Legal Notice
This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSFâs Intellectual Property Rights Policy http://www.xmpp.org/extensions/ipr-policy.shtml. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.5/).
Discussion Venue
The preferred venue for discussion of this document is the Standards discussion list: http://mail.jabber.org/mailman/listinfo/standards.
Relation to XMPP
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
Conformance Terms
The following keywords as used in this document are to be interpreted as described in RFC 2119: âMUSTâ, âSHALLâ, âREQUIREDâ; âMUST NOTâ, âSHALL NOTâ; âSHOULDâ, âRECOMMENDEDâ; âSHOULD NOTâ, âNOT RECOMMENDEDâ; âMAYâ, âOPTIONALâ.
Table of Contents
-
Introduction
-
Requirements
-
Protocol Description
3.1. Transport Initiation
3.2. Target Entity Response
-
WebRTC Service Discovery
-
Deployment Notes
-
Security Considerations
-
IANA Considerations
-
XMPP Registrar Considerations
8.1. Protocol Namespaces
8.2. Jingle Transport Methods
- XML Schema
9.1. Transport method
9.2. Transport method
Notes
Revision History
1. Introduction
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 seperates 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.
2. Requirements
The Jingle transport method defined herein is designed to meet the following requirements:
- Make it possible to negotiate media between two XMPP entities contained in web browsers or compatible devices.
- Make it relatively easy for Jingle to take advantage of WebRTC when all call participants are web browsers.
- Provide web application developers a simple way of using Jingle with web browsers without having to understand SDP.
3. Protocol Description
3.1 Transport Initiation
In order for the initiating entity in a Jingle exchange to start the negotiation, it MUST send a Jingle âsession-initiateâ stanza as described in XEP-0166. This stanza MUST include at least one transport method. If the initiating entity wishes to negotiate the WebRTC transport, it MUST include a child element qualified by the 'urn:xmpp:jingle:transports:webrtc:1**â** namespace.
Example 1. Initiation Example
<iq from=âromeo@montague.net/orchardâ
to='juliet@capulet.com/balcony'
id='jingle1' type='set'>
<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'
action='session-initiate'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<content creator='romeo@montague.net' name='audio, video'>
<transport xmlns='urn:xmpp:jingle:transports:webrtc:1' />
</content>
3.2 Target Entity Response
As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:
Example 2. Target Entity Provisionally Accepts the Session Request
Once the initiating entity provisionally accepts the session, it:
- MUST initiate a WebRTC session
- MUST exchange the browser SDP session description messages with the target entity using Jingle session-info messages
The target entity MUST attempt a handshake with the initiating entity. it:
- MUST accept the session-info messages and pass the SDP session decription payload to its web browser
Example 3. Initiating and Target Entity exchange session decription payloads with Jingle session-info messages
<iq from=âromeo@montague.net/orchardâ
to='juliet@capulet.com/balcony'
id='jingle1' type='set'>
<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'
action='session-info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<webrtc xmlns='urn:xmpp:jingle:apps:rtp:1'>
SDP
{
"messageType" : "OFFER",
"offererSessionId" : "uMHcBZAa8LTylbwAM3RY7IP7LGUPPU1n",
"sdp" : "...................",
"seq" : 1,
"tieBreaker" : 431803714
}
</webrtc>
<iq from=âjuliet@capulet.com/balconyâ
to='romeo@montague.net/orchard'
id='jingle2' type='set'>
<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'
action='session-info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<webrtc xmlns='urn:xmpp:jingle:apps:rtp:1'>
SDP
{
"answererSessionId" : "kheolvKZYwzioZkCoK7Wxk+bDpp9TNWc",
"messageType" : "ANSWER",
"offererSessionId" : "bL9tAoEyH0NEijbYPJCHbFxAMKypUZJa",
"sdp" : "............",
"seq" : 1
}
</webrtc>
</jingle>
<iq from=âromeo@capulet.com/balconyâ
to='juliet@montague.net/orchard'
id='jingle2' type='set'>
<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'
action='session-info'
initiator='romeo@montague.net/orchard'
sid='a73sjjvkla37jfea'>
<webrtc xmlns='urn:xmpp:jingle:apps:rtp:1'>
SDP
{
"answererSessionId" : "bL9tAoEyH0NEijbYPJCHbFxAMKypUZJa",
"messageType" : "OK",
"offererSessionId" : "kheolvKZYwzioZkCoK7Wxk+bDpp9TNWc",
}
</webrtc>
</jingle>
When a WebRTC handshake occurs, the remote media becomes available in the web browser of both the initiating and target entities and an event is triggered in both web browsers.
To complete the Jingle call initiation, the target entity MUST send a Jingle element with an action of âsession-acceptâ, when it recieves this event.
.
Example 4. Target Entity Accepts the WebRTC Transport Method
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/orchard'
type='set' id='accept1'>
<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'
action='session-accept'
initiator='romeo@montague.net/orchalient'
sid='a73sjjvkla37jfea'>
<content creator='romeo@montague.net' name='webrtc session'>
<transport xmlns='urn:xmpp:jingle:transports:webrtc:1' />
</content>
</jingle>
</iq>
The initiating entity then acknowledges the target entity's acceptance:
Example 5. Initiating Entity Acknowledges Definitive Acceptance
<iq from='romeo@montague.net/orchard'
to='juliet@capulet.com/balcony'
type='result'
id='accept1'/>
4. WebRTC Service Discovery
If an entity supports WebRTC SDP offer / answer model and therefore prefers to receive WebRTC session decription payloads in session-info messages, it MUST advertise support for the âhttp://www.igniterealtime.org/webrtc/session-infoâ service discovery feature.
Example 6. Service discovery information request
<iq from=âromeo@montague.lit/orchardâ
id='ce81f5d6'
to='juliet@capulet.com/balcony'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#infoâ/>
Example 7. Service discovery information response
<iq from=âjuliet@capulet.com/balconyâ
id='ce81f5d6'
to='romeo@montague.lit/orchard'
type='result'>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:1'/>
<feature var='urn:xmpp:jingle:transports:webrtc:1'/>
5. Deployment Notes
This specification applies to both XMPP clients and servers. However, service administrators may wish to deploy an external gateway or internal plugin to a media server in order to simplify the channel or negotiation process. The specifics are outside the scope of this document.
6. Security Considerations
In order to secure the media streams, implementations SHOULD use SRTP protocol to tunnel their media streams through an encrypted session.
7. IANA Considerations
This document requires no interaction with IANA;.
8. XMPP Registrar Considerations
8.1 Protocol Namespaces
Until this specification advances to a status of Draft, its associated namespaces shall be âhttp://www.igniterealtime.org/webrtc/transportâ and âhttp://www.igniterealtime.org/webrtc/session-infoâ; upon advancement of this specification, the XMPP Registrar [7] shall issue more permanent namespaces in accordance with the process defined in Section 4 of XMPP Registrar Function [8].
8.2 Jingle Transport Methods
The XMPP Registrar shall include âhttp://www.igniterealtime.org/webrtc/transportâ (see Protocol Namespaces) in its registry of Jingle transport methods. The registry submission is as follows:
WebRTC
A method for exchanging media between WebRTC enabled web browsers or other compatible devices.
XEP-xxxx
9. XML Schema
9.1 Transport method
TODO
9.2 Transport method
TODO
Notes
-
XEP-0166: Jingle http://www.xmpp.org/extensions/xep-0166.html.
-
XEP-0167: Jingle Audio Content Description Format http://www.xmpp.org/extensions/xep-0167.html.
-
XEP-0180: Jingle Video Content Description Format http://www.xmpp.org/extensions/xep-0180.html.
-
XEP-0176: Jingle RTP-ICE Transport Method http://www.xmpp.org/extensions/xep-0176.html.
-
Internet Draft: Javascript Session Establishment Protocol (JSEP) <http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/att-0002/JavascriptSes sionEstablishmentProtocol.pdf>.
Revision History
Version 0.0.1 (2012-02-17)
First draft. (do)
END