A conference named Bob 2.0

Quote from the Jingle proposed specification (XEP-0166): 

The purpose of Jingle is to enable one-to-one, peer-to-peer media sessions between XMPP entities, where the negotiation occurs over the XMPP ”channel” and the media is exchanged outside the XMPP channel using technologies such as the Real-time Transport Protocol (RTP; RFC 3550), the User Datagram Protocol (UDP; RFC 768 [2]), and Interactive Connectivity Establishment (ICE).One target application for Jingle is simple voice chat (see Jingle Audio via RTP). We stress the word “simple”. The purpose of Jingle is not to build a full-fledged telephony application that supports call waiting, call forwarding, call transfer, hold music, IVR systems, find-me-follow-me functionality, conference calls, and the like. These features are of interest to some user populations, but adding support for them to the core Jingle layer would introduce unnecessary complexity into a technology that is designed for basic multimedia interaction.The purpose of Jingle is not to supplant or replace technologies based on Session Initiation Protocol(SIP; RFC 3261). Because dual-stack XMPP+SIP clients are difficult to build, Jingle was designed as a pure XMPP signalling protocol. However, Jingle is at the same time designed to interwork with SIP so that the millions of deployed XMPP clients can be added onto existing Voice over Internet Protocol (VoIP) networks, rather than limiting XMPP users to a separate and distinct network.Jingle is designed in a modular way so that developers can easily add support for multimedia session types other than voice chat, such as video chat (see Jingle Video via RTP), application sharing, file sharing, collaborative editing, whiteboarding, and torrent broadcasting. The transport methods are also modular, so that Jingle implementations can use any appropriate media transport (including proprietary methods not standardized through the XMPP Standards Foundation).