Skip navigation
Currently Being Moderated

XEP-xxxx: Jingle WebRTC Transport

VERSION 14  Click to view document history
Created on: Feb 17, 2012 4:21 AM by Dele Olajide - Last Modified:  Mar 8, 2012 5:01 AM by Dele Olajide

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

4. WebRTC Service Discovery

5. Deployment Notes

6. Security Considerations

7. IANA Considerations

8. XMPP Registrar Considerations

8.1. Protocol Namespaces

8.2. Jingle Transport Methods

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

  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 <transport/> 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

            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>

   </jingle>

</iq>

 

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

 

<iq from='juliet@capulet.com/balcony' to='romeo@montague.net/orchard' type='result' id='jingle1'/>    

 

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'

    to='juliet@capulet.com/balcony'

    id='jingle1' type='set'>

 

    <jingle xmlns='urn:xmpp:jingle:1

            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>

   </jingle>

</iq>

 

 

 

<iq from='juliet@capulet.com/balcony'

    to='romeo@montague.net/orchard'

    id='jingle2' type='set'>   

 

    <jingle xmlns='urn:xmpp:jingle:1'

            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>

 

<iq from='romeo@capulet.com/balcony'

    to='juliet@montague.net/orchard'

    id='jingle2' type='set'>   

 

    <jingle xmlns='urn:xmpp:jingle:1'

            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>

</iq>

 

 

 

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'

            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'/>

</iq>

 

 

Example 7. Service discovery information response

 

<iq from='juliet@capulet.com/balcony'

    id='ce81f5d6'

    to='romeo@montague.lit/orchard'

    type='result'>

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

    <feature var='urn:xmpp:jingle:1'/>

    <feature var='urn:xmpp:jingle:apps:rtp:1'/>

    <feature var='urn:xmpp:jingle:transports:webrtc:1'/>

  </query>

</iq>



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:

 

<transport>

  <name>WebRTC</name>

  <desc> A method for exchanging media between WebRTC enabled web browsers or other compatible devices.</desc>

  <doc>XEP-xxxx</doc>

</transport>

 

 

9. XML Schema

 

 

 

9.1 Transport method

 

 

 

TODO

 

 

9.2 Transport method

 

 

 

TODO

 

 


 

 

 

Notes

 

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)

 

 

 

 


 

 

END

Comments (19)