The IETFs RTCWEB working group has decided to use &rfc4566; as the API surface for WebRTC. For XMPP this opened up a number of questions about the future of Jingle, XMPPs native signalling protocol, since Jingle does not use SDP. Various proposals have been made, including mappingSDP to Jingle and vice versa over to a dumb transport of SDP (called SoX) inside <message/> stanzas. This document proposes a way to transport SDP over Jingle which respects the established session model of Jingle.

1. MUST use the Jingle session model defined in XEP-0166.
2. MUST be able to transport a WebRTC SDP in a lossless way.
3. MUST retain the separation of transport.
4. MUST use one <content> element per m-line.

Take the following SDP offer

This SDP consists of a session level section and has two media description. It can easily be transformed to the following session-initiate by splitting it at "\r\nm=":

Note that the a=ice-ufrag, a=ice-pwd and a=fingerprint lines are removed from the SDP (either in session level or all of the mediadescriptions) and put into the transport element. The same rule applies to any a=candidate lines.FIXME: what about ice-options and rtcp-mux?

The receiver can reconstruct the SDP by first extracting the session section and then appending the media descriptions. When reconstructing the mediasections, the transport information can simply be appended to the raw SDP.

Sending individual ice candidates is done as described in &xep0176;:

The mapping of a=candidate lines to Jingle and vice versa is relatively simple and described in XEP-0176.

This section is actually where things get interesting. It should talk about adding or removing content which is a concept that has been known in Jingle for ages and is now coming to SDP with the "partial offer/partial answer" concept from Unified Plan. This is the reason why the individual m-lines are transported in separate <content/> elements.

The initiator starts with the offer SDP as described in the first section, but with audio only. Video is added later. Thus it sends the following session-initiate:

After the session is established, the initiator wants to add video from his webcam. It creates a new (full) SDP offer which will look like the one in example 1, but with candidates already added. It then calculates the difference between the new offer and the initial offerAt some point, the browser may do this. which may consist of more than one mediaparts.

When BUNDLE is used this will typically also contain a=candidate lines which are omitted for simplicity. This is transformed to a content-add. Note that the session-part must be resent if BUNDLE is used in the session since the BUNDLE group has changed:

The receiver extracts the new session part and the additional media description(s) and constructs the new SDP based on the previous oneat some point, the browser may be able to do this, too.

probably appropriate for showing webrtc stuff.

TBD. Nothing beyond considerations from 0166/0167.

This document requires no interaction with &IANA;.

TBD.

TBD.