XEP-xxxx: Jingle Audio/Video Conferences

1. Introduction¶

Audio/Video calls are possible with a single destination via Jingle (XEP-0166) [1] and Jingle RTP Sessions (XEP-0167) [2], and associated XEPs. It may be desirable to have calls with multiple people at the same time. Three main strategies exist to achieve that:

• A mesh network where each peer contacts each other peer: this is straightforward to implement and doesn't require any extra service, but it is heavy on network bandwidth and doesn't scale.

• An MCU (Multipoint Conferencing Unit) which uses a central service that generally mixes the contents of participants: this is lighter on network bandwidth but heavy on computing resources and hard to scale.

• An SFU (Selective Forwarding Unit) which uses a service that redistributes streams of participants as efficiently as possible: this is lighter on computing resources, acceptable in terms of network bandwidth, and can scale.

The mesh strategy is covered by Multiparty Jingle (XEP-0272) [3]. There have been attempts to specify MCU and SFU strategies, notably with COnferences with LIghtweight BRIdging (COLIBRI) (XEP-0340) [4], but it is unmaintained and unused.

This specification proposes a simple way to implement an SFU strategy with a service called in a similar way to one-to-one calls.

2. Requirements¶

The design goals of this XEP are:

• Be as simple as possible to implement for clients that already implement one-to-one A/V calls.
• Be compatible with simulcast.
• Use a simple way to identify the originating XMPP entity of a stream.
• Use a simple way to configure the A/V conference room.

3. Glossary¶

• A/V: Audio/visual.
• SFU: Selective Forwarding Unit, a service that redistributes streams of participants as efficiently as possible.
• SFU service: An XMPP entity that services A/V conferences with an SFU.
• Room: A JID of an SFU service associated with a specific multiparty call.
• Joining entity: An XMPP entity that participates in an A/V conference room.
• Stream: A media (e.g. audio or video) exchanged in a conference, carried by a single content.
• Simulcast: Serving multiple versions of the same media content at different quality levels simultaneously, allowing the receiving end to select the most suitable version.

4. Overview¶

A/V conferences work by using a single Jingle session per participant. To join a conference, a client calls the JID of a conference room and sends its own streams. The conference service then delivers the streams of the other participants by adding and removing the corresponding contents of the session.

An <origin> element is used to associate a forwarded stream with the originating entity (see Origin of Forwarded Streams).

Ad-Hoc Commands (XEP-0050) [5] is used with a well-known node to configure the room.

5. Joining a Conference¶

To join a conference, a user calls the conference room JID using Jingle RTP Sessions (XEP-0167) [2] as for a one-to-one call. The calling entity sends its audio/video streams (typically from its microphone and its webcam) in an unidirectional way. It MUST have its content 'senders' attribute set to "initiator" as explained in Jingle (XEP-0166) [1] § 7.3.

A joining entity MAY send the same audio or video stream with different quality for simulcast purposes. It is up to the SFU service to then select which one to forward.

A participant leaves the conference by terminating the session.

6. Receiving Streams¶

The SFU service selects and delivers the streams of other participants by sending a content-add action on the participant's session, including one content per stream (e.g. one audio and one video content). The added contents MUST have their 'senders' attribute set to "responder". The action MUST include an <origin> element identifying the entity the streams originate from (see Origin of Forwarded Streams).

The contents of the streams of the same origin MUST share a single transport, declared with a BUNDLE group, as defined in Jingle Grouping Framework (XEP-0338) [6]. The service MAY use one BUNDLE group for the streams of an origin, or a single BUNDLE group for all the streams of the session.

The service MAY send content-add actions while the session is still in the PENDING state (as allowed by Jingle (XEP-0166) [1]), so that it can start delivering the streams of already joined participants right away.

The joining entity SHOULD content-accept each added content. If it does not want to receive the corresponding stream, it MAY content-reject it.

When a stream has to stop being delivered to a participant (e.g. because its origin left the conference, or because the service changed its selection), the service MUST remove the corresponding contents with a content-remove action.

7. Adding a Stream¶

A participant MAY add additional streams of its own to the session, e.g. to share its screen, by sending a content-add action with the corresponding contents (one content per stream, their 'senders' attribute set to "initiator"), as for its initial streams (see Joining a Conference). The participant MAY use a new BUNDLE group for the added streams, or add them to an existing BUNDLE group (see Receiving Streams). The service MAY then deliver the added streams to the other participants, with the participant as origin.

An entity MAY have several concurrent streams in a conference (e.g. streams from its camera and from its screen). Each stream is carried by a single content. How the streams of an entity are rendered (e.g. one tile per source, or combined) is up to the implementation.

8. Origin of Forwarded Streams¶

Each content-add action carrying streams forwarded by the SFU service MUST include an <origin> element, qualified by the 'urn:xmpp:jingle:av-conferences:0' namespace, as a child of the <jingle> element (i.e. a sibling of the <content> elements), as shown below. Its 'entity' attribute identifies the entity the streams originate from, as a URI (typically an "xmpp:" URL, in the form "xmpp:user@domain" or "xmpp:user@domain/resource").

A content-add action carries the streams of a single origin, so a single <origin> element identifies the origin of all the contents of the action.

<jingle action="content-add" ...>
  <group xmlns="urn:xmpp:jingle:apps:grouping:0" semantics="BUNDLE">
    <content name="0"/>
    <content name="1"/>
  </group>
  <content creator="responder" name="0" senders="responder">
    <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
      <!-- audio stream description -->
    </description>
    <transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"
      ufrag="ufrag_2"
      pwd="ice_pwd_2">
      <!-- transport child elements -->
    </transport>
  </content>
  <content creator="responder" name="1" senders="responder">
    <!-- video content -->
  </content>
  <origin xmlns="urn:xmpp:jingle:av-conferences:0"
    entity="xmpp:romeo@montague.lit"/>
</jingle>

A stream MAY originate from a non-XMPP entity (e.g. using the SFU's own user interface or with a gateway to another protocol). In that case, the 'entity' attribute MAY use another URI scheme.

9. Examples¶

    <iq id="av_iq_1" type="set" from="juliet@capulet.lit/balcony" to="ball@conferences.shakespeare.lit">
      <jingle xmlns="urn:xmpp:jingle:1"
        sid="av_jingle_session_1"
        action="session-initiate"
        initiator="juliet@capulet.lit/balcony">
      <group xmlns="urn:xmpp:jingle:apps:grouping:0" semantics="BUNDLE">
        <content name="video0"/>
        <content name="audio1"/>
      </group>
      <content creator="initiator" name="video0" senders="initiator">
        <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="video">
          <!-- video stream description -->
        </description>
        <transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"
          ufrag="ufrag_1"
          pwd="ice_pwd_1">
        <fingerprint xmlns="urn:xmpp:jingle:apps:dtls:0" hash="sha-256" setup="actpass">
          <!-- some fingerprint -->
        </fingerprint>
      </transport>
    </content>
    <content creator="initiator" name="audio1" senders="initiator">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <!-- audio stream description -->
      </description>
      <transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"
        ufrag="ufrag_1"
        pwd="ice_pwd_1">
        <!-- transport child elements -->
      </transport>
  </content>
</jingle>
</iq>

<iq to="juliet@capulet.lit/balcony" from="ball@conferences.shakespeare.lit" id="av_iq_1" type="result"/>

  

<iq id="room_iq_1" type="set" from="ball@conferences.shakespeare.lit" to="juliet@capulet.lit/balcony">
  <jingle xmlns="urn:xmpp:jingle:1"
    sid="av_jingle_session_1"
    action="session-accept"
    responder="ball@conferences.shakespeare.lit">
    <group xmlns="urn:xmpp:jingle:apps:grouping:0" semantics="BUNDLE">
      <content name="video0"/>
      <content name="audio1"/>
    </group>
    <content creator="initiator" name="video0">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="video">
        <!-- video stream description -->
      </description>
      <!-- transport element -->
    </content>
    <content creator="initiator" name="audio1">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <!-- audio stream description -->
      </description>
      <!-- transport element -->
    </content>
  </jingle>
</iq>
  

<iq id="room_iq_2" type="set" from="ball@conferences.shakespeare.lit" to="juliet@capulet.lit/balcony">
  <jingle xmlns="urn:xmpp:jingle:1"
    sid="av_jingle_session_1"
    action="content-add">
    <group xmlns="urn:xmpp:jingle:apps:grouping:0" semantics="BUNDLE">
      <content name="0"/>
      <content name="1"/>
    </group>
    <content creator="responder" name="0" senders="responder">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <!-- audio stream description -->
      </description>
      <transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"
        ufrag="ufrag_2"
        pwd="ice_pwd_2">
        <fingerprint xmlns="urn:xmpp:jingle:apps:dtls:0" hash="sha-256" setup="actpass">
          <!-- some fingerprint -->
        </fingerprint>
      </transport>
    </content>
    <content creator="responder" name="1" senders="responder">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="video">
        <!-- video stream description -->
      </description>
      <transport xmlns="urn:xmpp:jingle:transports:ice-udp:1"
        ufrag="ufrag_2"
        pwd="ice_pwd_2">
        <fingerprint xmlns="urn:xmpp:jingle:apps:dtls:0" hash="sha-256" setup="actpass">
          <!-- some fingerprint -->
        </fingerprint>
      </transport>
    </content>
    <origin xmlns="urn:xmpp:jingle:av-conferences:0" entity="xmpp:romeo@montague.lit"/>
  </jingle>
</iq>

<iq to="ball@conferences.shakespeare.lit" from="juliet@capulet.lit/balcony" id="room_iq_2" type="result"/>
  

<iq id="av_iq_2" type="set" from="juliet@capulet.lit/balcony" to="ball@conferences.shakespeare.lit">
  <jingle xmlns="urn:xmpp:jingle:1"
    sid="av_jingle_session_1"
    action="content-accept">
    <content creator="responder" name="0">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="audio">
        <!-- audio stream description -->
      </description>
      <!-- transport element -->
    </content>
    <content creator="responder" name="1">
      <description xmlns="urn:xmpp:jingle:apps:rtp:1" media="video">
        <!-- video stream description -->
      </description>
      <!-- transport element -->
    </content>
  </jingle>
</iq>

<iq to="juliet@capulet.lit/balcony" from="ball@conferences.shakespeare.lit" id="av_iq_2" type="result"/>
  

<iq id="room_iq_3" type="set" from="ball@conferences.shakespeare.lit" to="juliet@capulet.lit/balcony">
  <jingle xmlns="urn:xmpp:jingle:1"
    sid="av_jingle_session_1"
    action="content-remove">
    <content creator="responder" name="0"/>
    <content creator="responder" name="1"/>
  </jingle>
</iq>

<iq to="ball@conferences.shakespeare.lit" from="juliet@capulet.lit/balcony" id="room_iq_3" type="result"/>
  

10. Configuration¶

It may be desirable to have configuration options on the SFU service or on one of its rooms. For instance, a conference room may offer the option to record the session. While the definition of those options is beyond the scope of this specification, the configuration MUST be done via Ad-Hoc Commands (XEP-0050) [5] on the well-known node "urn:xmpp:av-conferences:config".

11. Business Rules¶

Only other peers' streams are sent to a joining entity. An SFU service MUST NOT send back a stream to the entity that initially sent it.

An SFU service MUST NOT initiate independent Jingle sessions to deliver streams to a joined entity: the streams are only delivered as contents of the entity's session, via content-add actions.

An SFU service MUST ensure that the names of the contents it adds do not collide with the existing contents of the session, as a BUNDLE group identifies its contents by name only.

12. Discovering Support¶

If a client or a service supports the protocol specified in this XEP, it MUST advertise it by including the 'urn:xmpp:jingle:av-conferences:0' discovery feature in response to a Service Discovery (XEP-0030) [7] information request.

<iq type='get'
    from='juliet@example.org/balcony'
    to='romeo@example.org/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='romeo@example.org/orchard'
    to='juliet@example.org/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:jingle:av-conferences:0'/>
    ...
  </query>
</iq>

If an entity is an A/V conferences service as specified by this XEP, it MUST have an identity with a category of "conference" and a value of "audio-video" in a response to a Service Discovery (XEP-0030) [7] information request.

<iq type='get'
    from='juliet@example.org/balcony'
    to='ball@conference.example.org'
    id='disco2'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='ball@conference.example.org'
    to='juliet@example.org/balcony'
    id='disco2'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <identity category='conference' type='audio-video'/>
    ...
    <feature var='urn:xmpp:jingle:av-conferences:0'/>
    ...
  </query>
</iq>

13. Security Considerations¶

Streams are sent to the SFU service for redistribution. Although it is technically possible to have the stream encrypted end-to-end, this specification assumes that streams are decoded at the SFU level and are therefore not end-to-end encrypted, unlike one-to-one calls. Future specifications may outline a method for maintaining end-to-end encryption, but this is beyond the scope of this XEP; developers and end-users MUST assume that streams are decrypted at the SFU service level.

The general security considerations for one-to-one calls apply, with the added risk that more parties are participating in the call. However, the IP address of a device sending a stream is only known by the SFU service, not by other peers, unlike in one-to-one or Multiparty Jingle (XEP-0272) [3] calls.

The <origin> element is not authenticated: it is provided by the SFU service, which is responsible for having established the identity of the entities that sent the streams (e.g. via the JID of their Jingle sessions). The service could however alter an <origin> or a stream, either intentionally or through a bug.

14. IANA Considerations¶

TODO

15. XMPP Registrar Considerations¶

TODO

16. XML Schema¶

TODO

17. Acknowledgements¶

Thanks to NLNet foundation/NGI Assure for funding the work on this specification.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.2

Last Updated

2026-10-13

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0001, XEP-0030, XEP-0050, XEP-0166, XEP-0167, XEP-0338

Supersedes

None

Superseded By

None

Short Name

av-conferences

This document in other formats: XML  PDF

Appendix B: Author Information¶

Jérôme Poisson

Email

goffi@goffi.org

JabberID

goffi@jabber.fr

URI

https://www.goffi.org

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.2 (2026-10-13)¶
   • hold a conference within a single Jingle session per participant, instead of one Jingle session per stream
   • add an <origin> element to identify the origin of a forwarded stream
   • use BUNDLE groups (XEP-0338) for the contents of streams
   • allow a participant to add an additional stream (e.g. for screen sharing)
   • remove the duplicated Overview section
   jp
2. Version 0.0.1 (2024-07-29)¶

   First draft.

   jp

Appendix I: Bib(La)TeX Entry

@report{poisson2024av-conferences,
  title = {Jingle Audio/Video Conferences},
  author = {Poisson, Jérôme},
  type = {XEP},
  number = {xxxx},
  version = {0.0.2},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2024-07-29/2026-10-13},
}

END