Initial ProtoXEP submission.
&xep0166; defines Jingle session signalling, and &xep0353; defines message-based Jingle initiation. These protocols describe how a call is proposed and negotiated, but they do not define a compact, archiveable call-history entry for the user-visible conversation timeline.
+Many messaging clients show entries such as "missed video call", "voice call, 3:12", or "Total Conversation call, 12:44". Such entries need to synchronize across devices and may be archived by &xep0313;, but raw media streams do not belong in MAM.
+This specification defines a jingle-history element carried inside an ordinary XMPP message stanza. The element describes the outcome and metadata of a Jingle session. It does not store media streams, recordings, RTP packets, WebRTC data channel contents, or location history.
+This specification is designed to meet the following requirements.
+A user receives a video call but does not answer before the call times out. The caller or callee stores a message event that can be shown as "Missed video call".
+Two users complete a call containing audio, video and real-time text. The client stores one summary event with the Jingle session ID, media list, duration and transcript availability.
+A service deployment records calls only after explicit consent or policy-based rules. The call-history message records that a recording is available in cloud storage, while the file itself is described using a file-sharing protocol such as &xep0447;.
+A client may maintain a private local call log for failed or temporary calls. In that mode the client MUST NOT send the jingle-history message and MUST NOT rely on MAM to store the event.
+The primary element is jingle-history qualified by the namespace urn:xmpp:jingle-history:0. It is carried as a child of a normal XMPP message stanza.
+A client that does not understand this extension will still display the message body. A server that supports &xep0313; can archive the message as ordinary message history.
+An entity supporting this specification MUST advertise the following discovery feature using &xep0030;:
+Entities MAY advertise the following additional features when they implement the corresponding metadata profile:
+The jingle-history element has the following attributes.
+| Attribute | +Required | +Values | +Meaning | +
|---|---|---|---|
| sid | +yes | +Jingle session ID | +The session ID from the related Jingle session. | +
| direction | +yes | +incoming, outgoing | +Direction from the perspective of the archiving client. | +
| disposition | +yes | +completed, missed, declined, cancelled, failed, busy, timeout, replaced, emergency | +User-visible outcome of the session. | +
| media | +yes | +Space-separated tokens: audio, video, rtt, captions, screen, file, location | +Media or contextual modalities associated with the session. | +
| profile | +no | +audio, video, total-conversation, group-call, emergency, screen-share, custom | +High-level call profile. | +
| started | +no | +ISO 8601 timestamp | +When the relevant call attempt or session started. | +
| ended | +no | +ISO 8601 timestamp | +When the call attempt or session ended. | +
| duration | +no | +Non-negative integer seconds | +Call duration in seconds. | +
| recording | +no | +none, local, cloud, external, policy-based | +Whether a recording exists and where it is expected to be stored. | +
| transcript | +no | +none, local, cloud, external, policy-based | +Whether a transcript exists and where it is expected to be stored. | +
| encrypted | +no | +true, false | +Whether referenced recording or transcript material is known to be encrypted. | +
| consent | +no | +none, initiator, all-participants, policy-based | +Consent state for recording or transcript storage. | +
| retention | +no | +Token such as 30d, 1y or policy | +Known retention period or policy label. | +
Unknown attributes and child elements MUST be ignored by receivers. Implementations SHOULD preserve unknown attributes and child elements when rewriting or exporting history, where practical.
+The recording and transcript attributes are intentionally summary fields. They do not contain the recording, transcript or file bytes.
+A sender MAY include more detailed metadata using child elements in optional namespaces.
+If a recording or transcript file is shared with the user, the file metadata SHOULD be expressed using an existing file-sharing specification such as &xep0447; elsewhere in the same message or in a related message. This specification does not define a new file-transfer mechanism.
+In synchronized mode, the sender builds an ordinary message with a fallback body and a jingle-history element. The sender SHOULD include &xep0334; store when it wants the event to be archiveable.
+In local-only mode, a client MUST NOT send the call-history message. The event is stored only by that client and is outside the scope of &xep0313;.
+MAM stores event metadata only. It MUST NOT be used as a container for raw audio, raw video, RTP packets, WebRTC streams or full call recordings.
+Clients SHOULD render concise timeline summaries. Examples include:
+Clients SHOULD show recording, transcript, encryption, consent and retention indicators when they are known.
+For group calls, the jingle-history element MAY be sent in a groupchat message to the room. For this version, group-call support is limited to the room JID implied by the message route, sid, disposition, media, profile and duration.
+Emergency call history MAY be represented with profile='emergency' or disposition='emergency'. This specification is not an emergency-services routing or legal compliance protocol.
+Precise location MUST NOT be placed directly in jingle-history. If location is needed, it should be represented using a secure location protocol or a separate call-scoped location event.
+This specification is motivated by accessibility and Total Conversation use cases. Clients SHOULD expose the media list and profile to assistive technologies, including whether real-time text or captions were part of the call.
+Clients SHOULD avoid using color alone to represent missed, failed, emergency, recorded or transcript-available states.
+Remote jingle-history elements are untrusted input. Clients MUST validate required attributes, ignore invalid enum values and avoid allocating excessive memory for unusually large attributes.
+Recording URLs and transcript URLs, if any, are outside this specification. Clients MUST treat any related file references as untrusted until verified by the file-sharing and encryption layer.
+This specification does not provide end-to-end encryption. Deployments SHOULD use encrypted transport and end-to-end encryption where available.
+Call history can reveal sensitive social patterns, accessibility needs, emergency use, contact availability and communication habits. Clients SHOULD offer a local-only mode and retention controls.
+Default behavior SHOULD store call-log metadata only. Audio or video recording requires explicit consent unless a clearly visible legal, emergency or service policy applies.
+For group calls, implementations SHOULD support all-participant consent before recording or cloud transcript storage.
+This document requires no interaction with the Internet Assigned Numbers Authority.
+This specification requests registration of the following namespaces.
+This specification requests registration of the following service discovery features.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]]>
+ Update synchronized real-time text references after Jingle Synchronized Real-Time Text was accepted as XEP-0517.
Initial ProtoXEP submission.
Total Conversation is a user experience where real-time text, audio and video are available together as one conversation. XMPP already contains many of the necessary building blocks: &xep0301; for chat-oriented real-time text, &xep0166; and &xep0167; for Jingle calls, &xep0517; for Jingle synchronized real-time text, &xep0176; and &xep0215; for connectivity, and &xep0313; for archive retrieval.
+However, an implementation can support several of these pieces and still fail to provide a coherent Total Conversation. The user may see audio and video in one call surface, while real-time text is sent as unrelated chat messages. Captions may be indistinguishable from typed text. Location may be global presence instead of call-scoped consent. Archives may not show whether text was synchronized with the call or merely a fallback.
+This specification defines a profile claim and conformance model for XMPP Total Conversation clients. It composes existing XMPP RFCs and XEPs, uses &xep0517; for synchronized real-time text, and references Jingle extensions for call-scoped location.
+This specification is designed to meet the following requirements.
+This specification does not replace audio, video, message, archive, file-transfer or encryption specifications. It defines how those specifications fit together when the user-visible product claims Total Conversation support.
+| Protocol | +Role in this profile | +
|---|---|
| &xep0301; | +Live text and fallback RTT outside Jingle. | +
| &xep0517; | +Real-time text, captions, translation or interpreter text bound to the same Jingle session as audio/video. | +
| &xep0166; and &xep0167; | +Jingle signalling and RTP audio/video descriptions. | +
| &xep0176;, &xep0215; and &xep0343; | +Connectivity and WebRTC data channel signalling where applicable. | +
| &xep0353; | +Message-based Jingle proposal and ringing flow. | +
| &xep0313; | +Archive retrieval for messages, metadata and call-history events. | +
| &xep0363; and &xep0447; | +File upload and file metadata for attachments, voice messages, video messages or optional recordings. | +
| &xep0479; | +General XMPP client compliance baseline. | +
A client MUST NOT claim this profile as a replacement for the underlying protocol support. For example, advertising the profile without supporting Jingle does not imply audio/video calling.
+The profile defines progressive levels. A client MUST NOT advertise a level higher than it can negotiate and present to the user.
+| Level | +Name | +Required behavior | +
|---|---|---|
| tc-0 | +Core conversation | +Authenticated XMPP messaging, presence and service discovery. | +
| tc-1 | +Live text conversation | +tc-0 plus &xep0301; real-time text and readable message body fallback. | +
| tc-2 | +Audio/video conversation | +tc-1 plus Jingle call proposal and audio/video session signalling. | +
| tc-3 | +Synchronized Total Conversation | +tc-2 plus real-time text or captions negotiated as part of the same Jingle session using &xep0517; or a compatible future profile. | +
| tc-4 | +Assistive context | +tc-3 plus consent-gated call-scoped context such as location, fallback state, caption source and service metadata. | +
An entity supporting this profile MUST advertise the base profile feature using &xep0030;:
+The base feature says that the entity understands the profile family. Actual level and modalities SHOULD be carried in a service discovery extension form.
+If a client advertises urn:xmpp:total-conversation:0 but omits one of the underlying features, peers MUST treat that omitted part as unsupported.
+Call-scoped media and context MUST be bound by at least the peer JID, Jingle session ID and Jingle content name. A peer JID alone is not sufficient because a user can have multiple devices, browser sessions, simultaneous calls or fallback chat paths.
+If &xep0517; synchronized text is not negotiated but fallback &xep0301; is used, the user interface MUST show that the text is fallback text and not synchronized Jingle text.
+A deaf or hard-of-hearing user starts a call where sign-language video, audio and typed real-time text are visible together. The client advertises tc-3 because the text is part of the call session.
+A peer supports audio/video Jingle but not synchronized Jingle text. The client continues the call and uses &xep0301; for fallback RTT. The user interface shows fallback state.
+A user joins a call with a relay, captioner or interpreter service. The client identifies caption source and language when known and keeps the assistive text visibly associated with the call.
+A client can represent an emergency-oriented Total Conversation profile using audio, video, real-time text, captions and call-scoped location. This profile does not define PSAP routing or legal emergency-service requirements.
+Archives MUST NOT erase whether text was synchronized, call-bound or fallback. If an archive contains call-bound text or call summaries, clients SHOULD retain enough metadata to show the Jingle session ID, content name, text source and synchronization state.
+&xep0313; MAY store ordinary messages, real-time text fallback messages and archiveable call-history events. It MUST NOT be used to store raw RTP packets, WebRTC media streams, camera output or microphone output.
+Optional recordings, video messages, voice messages and transcript files are file/media objects and should use existing file-sharing or upload specifications with appropriate consent, encryption and retention metadata.
+A Total Conversation client MUST make the following states visible to the user and available to assistive technologies where applicable.
+Color alone MUST NOT be the only indicator for fallback, recording, emergency, muted, failed or caption-source state.
+This profile exists primarily because accessibility requires the conversation to be coherent. Deaf, hard-of-hearing, speech-impaired and mixed-hearing groups need to know whether text is typed by the other person, generated by ASR, entered by a captioner, translated, interpreted, delayed, synchronized to the call or fallback outside the call.
+Implementations SHOULD provide keyboard-operable call, text, media, file and location controls; accessible names for icon-only controls; focus order that follows the conversation flow; sufficient contrast; and visible fallback warnings that do not rely on color alone.
+This profile can combine sensitive media, text, files, location and service metadata. Implementations SHOULD use encrypted transport and end-to-end encryption where available.
+Downgrade attacks are important. If synchronized text falls back to ordinary &xep0301;, or call-scoped location falls back to global PEP location, the user MUST be informed.
+Received captions, ASR text, translations and location data MUST NOT be treated as verified facts unless additional trust and verification mechanisms exist.
+Total Conversation can expose partial text before a message is final, live speech through captions, contact availability, file metadata, location and call participation across multiple devices.
+Clients MUST ask for user consent before sending live location or enabling assistive services that involve third parties such as ASR, captioning, translation, relay or interpreter providers.
+Location sharing MUST stop when the call ends, when the user stops sharing, when permission is revoked, or when the source becomes stale.
+This document requires no interaction with the Internet Assigned Numbers Authority.
+This specification requests registration of the following service discovery feature:
+This specification requests registration of the following XEP-0128 form type:
+Initial form fields are:
+| Field | +Type | +Values | +Meaning | +
|---|---|---|---|
| tc#level | +list-single | +tc-0, tc-1, tc-2, tc-3, tc-4 | +Highest Total Conversation level the entity can honestly negotiate. | +
| tc#modalities | +list-multi | +chat, rtt, caption, audio, video, file, location, translation, interpreter | +Conversation modalities the entity can present or send. | +
| tc#fallbacks | +list-multi | +Protocol identifiers such as xep-0301, xep-0363 and xep-0080-pep | +Fallback paths the entity can use and expose to users. | +
This profile defines a discovery feature and XEP-0128 data form, but no standalone XML payload.
+