XEP-xxxx: Jingle WebRTC Transport

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

  1. Introduction

  2. Requirements

  3. Protocol Description

3.1. Transport Initiation

3.2. Target Entity Response

  1. WebRTC Service Discovery

  2. Deployment Notes

  3. Security Considerations

  4. IANA Considerations

  5. XMPP Registrar Considerations

8.1. Protocol Namespaces

8.2. Jingle Transport Methods

  1. XML Schema

9.1. Transport method

9.2. Transport method


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:

  1. Make it possible to negotiate media between two XMPP entities contained in web browsers or compatible devices.
  2. Make it relatively easy for Jingle to take advantage of WebRTC when all call participants are web browsers.
  3. 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’


id='jingle1' type='set'>

<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)' 




    <content creator='romeo@montague.net' name='audio, video'>

        <transport xmlns='urn:xmpp:jingle:transports:webrtc:1' />


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:

  1. MUST initiate a WebRTC session
  2. 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:

  1. 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’


id='jingle1' type='set'>

<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)' 




        <webrtc xmlns='urn:xmpp:jingle:apps:rtp:1'>         



             "messageType" : "OFFER",

            "offererSessionId" : "uMHcBZAa8LTylbwAM3RY7IP7LGUPPU1n",

            "sdp" : "...................",

            "seq" : 1,

            "tieBreaker" : 431803714



<iq from=‘juliet@capulet.com/balcony’


id='jingle2' type='set'>   

<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'




        <webrtc xmlns='urn:xmpp:jingle:apps:rtp:1'>         



              "answererSessionId" : "kheolvKZYwzioZkCoK7Wxk+bDpp9TNWc",

              "messageType" : "ANSWER",

              "offererSessionId" : "bL9tAoEyH0NEijbYPJCHbFxAMKypUZJa",

              "sdp" : "............",

              "seq" : 1




<iq from=‘romeo@capulet.com/balcony’


id='jingle2' type='set'>   

<jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'




        <webrtc xmlns='urn:xmpp:jingle:apps:rtp:1'>         



              "answererSessionId" : "bL9tAoEyH0NEijbYPJCHbFxAMKypUZJa",

              "messageType" : "OK",

              "offererSessionId" : "kheolvKZYwzioZkCoK7Wxk+bDpp9TNWc",




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'


type='set' id='accept1'>

    <jingle xmlns='[urn:xmpp:jingle:1](http://www.xmpp.org/extensions/xep-0166.html#ns)'




        <content creator='romeo@montague.net' name='webrtc session'>     

          <transport xmlns='urn:xmpp:jingle:transports:webrtc:1' /> 




The initiating entity then acknowledges the target entity's acceptance:

Example 5. Initiating Entity Acknowledges Definitive Acceptance

<iq from='romeo@montague.net/orchard'

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’




<query xmlns='http://jabber.org/protocol/disco#info’/>

Example 7. Service discovery information response

<iq from=‘juliet@capulet.com/balcony’



<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:


A method for exchanging media between WebRTC enabled web browsers or other compatible devices.


9. XML Schema

9.1 Transport method


9.2 Transport method



  1. XEP-0166: Jingle http://www.xmpp.org/extensions/xep-0166.html.

  2. XEP-0167: Jingle Audio Content Description Format http://www.xmpp.org/extensions/xep-0167.html.

  3. XEP-0180: Jingle Video Content Description Format http://www.xmpp.org/extensions/xep-0180.html.

  4. XEP-0176: Jingle RTP-ICE Transport Method http://www.xmpp.org/extensions/xep-0176.html.

  5. 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)



Good idea, I hope I can implement this for Candy too

That would be so cool :wink:

I saw the Jingle plugin for Strophe you are trying to develop. I think this XEP would simplfy your implementation for Candy.

Yes definitively.

First I was doing a whole lot of parsing which would be unneeded with your XEP.

As soon as I have time, I’ll implement this.

I saw your emails to the jabber (jdev? not sure anymore) mailing list… I hope you can get it through the standardization process in order to gather more clients (also desktop clients) which implement this protocol additionally…

I am aiming to make push it all the way with the XMPP council. Just waiting for the JSEP version of Chrome to confirm before making the proposal formal. How are you planning to use Jingle with MUCs. There is a discussion about this in the WebRTC discussion group. Are you planning on using multi-party jingle (Muji) or something else?

Good question. I didn’t really think about this yet because I wanted to it first only for private chats.

Muji seems to be a good way… Would be good not to have it deferred though…

Found the reason for deferment here

As it is the only spec out there, I am going to implement it for the OfChat web client. I may also have to add a new section in the Jingle WebRTC Transport XEP for multi-party jingle presence stanzas.

Ah yeah, I remember seeing this email

I started implementing your spec this morning and I hope I can finish it soon

I noticed that you didn’t use the correct namespace of jingle, it should be “urn:xmpp:jingle:1”.

Thanks for spotting the wrong namespace. I also changed the WebRTC transport and session-info namespaces as well because of “xep-xxxx” in them and to make igniterealtime.org the sponsors of the protocol.

Would you be interested in being a co-auther for the Jingle WebRTC Transport XEP ?

I read the Muji spec again and realised, that WebRTC clients do not need the Muji preparation and session description exchange step. The xmpp entity joining the MUC should just initiate Jingle WebRTC sessions with all existing room occupants as recomended in the spec. I am going to implement this next to the OfChat web client.

Dele, just for your information. We (me and LG) are currently testing an option to hide messages with external links automatically (fighting the SEO spam). So this document may disappear time to time after you edit it (it contains links). Then i will remove it from the moderation queue and it will reappear again. Sorry for the possible inconvenience

No problem Thanks for letting me know

@Dele: Thanks for changing the ns. About the igniterealtime webrtc namespace: I’m not really sure if that’s the best way to do it. I remember reading that namespaces should all be in the form of urn:xmpp:something:…

Take a look at XEP-0053 for reference (Although I’m not really sure if my guess is correct).

Thanks for asking me to be a co-author. I’d like to do this although I’m not really sure if I have enough spare time.

I’ll do my best

Thanks for accepting. You already have been a great help with the namespaces

I will change it to “urn:xmpp:jingle:transports:webrtc:1” for transport and urn:xmpp:jingle:apps:rtp:1" for the WebRTC RTP session-info payload


I added my emailaddress to the doc.

For the sid attribute in jingle: Do you generate it on your own?

Yes, I use this algorithim

var sessionId = “webrtc” + Math.random().toString(36).substr(2,9);


I noticed in my test that the final “OK” message needs to be sent to the recipient as well and processed to the peerconnection.

I added another session-info although I’m not sure if we’d better use the session-accept for this.

Didn’t you have to do that?

  • Michael

I was not tracking the payloads and simply passing them on. In practice, the flow from my log files showed offer->answer->ok, we could use the session-accept for the final ok, but any future changes to the ROAP/JSEP SDP offer model will break our code.

In my implementation, I send the session-accept when the onaddstream callback of the PeerConnection object gets called after the remote stream is recieved by the OK SDP message.

Just saw this: http://www.ietf.org/id/draft-suzuki-web-jingle-00.txt

Posted to the jingle mailinglist.

Ok regarding the OK SDP. I’ll need to anyway polish my impl. it’s quite hacky atm

Thanks for posting that

It is an IETF proposal for RTCWeb (different from Google’s WebRTC). This proposal does not seem to be aware of ROAP (RTCWeb Offer and Answer Protocol) and the newer JSEP proposal from Google.

It looks more complicated than this proposal

Yeah, it seems a lot more complicated and involves parsing the SDP data…