Proposed XMPP Extension: Jingle Synchronized Real-Time Text
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Jingle Synchronized Real-Time Text Abstract: This specification defines a Jingle application extension for negotiating real-time text as part of the same conversational session as audio and video. URL: https://xmpp.org/extensions/inbox/jingle-rtt-sync.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
On Tue, 2 Jun 2026 at 10:57, Daniel Gultsch <daniel@gultsch.de> wrote:
Title: Jingle Synchronized Real-Time Text Abstract: This specification defines a Jingle application extension for negotiating real-time text as part of the same conversational session as audio and video.
This generally looks reasonable, and I support publication, but I'm struggling to find the missing references. T.140 over datachannel appears to be RFC 8865. You'll also want XEP-0343 for WebRTC datachannel support in Jingle. Finally, RFC 4103 updated by RFC 9071 does T.140 over RTP. (In my view) these don't need to be in place prior to publication but I thought they'd help others review.
Today i have written my previous email als short response. I agree that these references should be added. The proposal is not intended to redefine existing T.140 transport mechanisms. My current understanding is: - RFC 4103, updated by RFC 9071, defines RTP payload transport for T.140 real-time text. - RFC 8865 defines T.140 over WebRTC DataChannels. - XEP-0343 is relevant prior XMPP work for signalling WebRTC DataChannels in Jingle, although it is currently Deferred. The reason for this proposal is the application-level binding and semantics, not generic DataChannel transport. In a browser implementation, the live text is eventually sent as data over a WebRTC DataChannel. However, a generic DataChannel alone is not enough for Total Conversation or for gateway interoperability. A Jingle-to-SIP gateway must be able to know, without guessing, that this stream is real-time text, that it belongs to the same active Jingle session as audio/video, and whether it is typed RTT, captions, ASR, interpreter text, translation, or fallback text. Without that semantic binding, a gateway can preserve bytes but still lose the meaning of the stream. In particular, mapping to SIP/RTP T.140 using RFC 4103/RFC 9071 needs to know that the Jingle text stream is T.140-compatible real-time text and is part of the same conversation as the audio/video media. So I see the split as: - RFC 4103/RFC 9071: RTP/T.140 transport. - RFC 8865: T.140 over WebRTC DataChannels. - XEP-0343 or a successor: Jingle signalling for WebRTC DataChannels. - This proposal: the Jingle application semantics that bind real-time text to the same call/session as audio/video for Total Conversation, including synchronization level, source, language and visible fallback state. I think the draft should reference RFC 8865, XEP-0343, RFC 4103 and RFC 9071, but avoid making XEP-0343 a hard dependency while it remains Deferred. A good wording might be that the WebRTC DataChannel profile should align with RFC 8865 and with XEP-0343 or any successor Jingle DataChannel signalling specification. I can prepare a small follow-up patch to add these references and clarify this transport-vs-semantics split. Op 2-6-2026 om 14:48 schreef Dave Cridland:
On Tue, 2 Jun 2026 at 10:57, Daniel Gultsch <daniel@gultsch.de> wrote:
Title: Jingle Synchronized Real-Time Text Abstract: This specification defines a Jingle application extension for negotiating real-time text as part of the same conversational session as audio and video.
URL: https://xmpp.org/extensions/inbox/jingle-rtt-sync.html
This generally looks reasonable, and I support publication, but I'm struggling to find the missing references.
T.140 over datachannel appears to be RFC 8865.
You'll also want XEP-0343 for WebRTC datachannel support in Jingle.
Finally, RFC 4103 updated by RFC 9071 does T.140 over RTP.
(In my view) these don't need to be in place prior to publication but I thought they'd help others review.
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
Is there a reason this isn't using https://xmpp.org/extensions/xep-0247.html to put https://xmpp.org/extensions/xep-0301.html in a jingle session?
Reason that 911NG/112NG are using standaard T.140 via gateway SIP. It must be same data without delay. Verstuurd vanaf mijn iPhone
Op 2 jun 2026 om 18:31 heeft Stephen Paul Weber <singpolyma@singpolyma.net> het volgende geschreven:
Is there a reason this isn't using https://xmpp.org/extensions/xep-0247.html to put https://xmpp.org/extensions/xep-0301.html in a jingle session? _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org <signature.asc>
Because audio, video and text are only together using a channel in webrtc. It is total conversation. Verstuurd vanaf mijn iPhone
Op 3 jun 2026 om 00:15 heeft Edward Tie <famtie@freedom.nl> het volgende geschreven:
Reason that 911NG/112NG are using standaard T.140 via gateway SIP. It must be same data without delay. Verstuurd vanaf mijn iPhone
Op 2 jun 2026 om 18:31 heeft Stephen Paul Weber <singpolyma@singpolyma.net> het volgende geschreven:
Is there a reason this isn't using https://xmpp.org/extensions/xep-0247.html to put https://xmpp.org/extensions/xep-0301.html in a jingle session? _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org <signature.asc>
On Tue, 2026-06-02 at 19:41 -0500, Stephen Paul Weber wrote:
Reason that 911NG/112NG are using standaard T.140 via gateway SIP. It must be same data without delay.
Any gateway could easily convert the format though, no?
Only if the gateway is a MITM gateway, requiring server resources and increasing latency. Using the T.140 standard via standard RTP (RFC 4103) and WebRTC Data Channels (RFC 8865) seems sensible for better end-to-end real-time interop. XEP-0167 already supports RTP/T.140 out of the box, the only addition in this specification is the rtt-sync metadata element. It's thus important that the specification points out that other implementations may use RTP/T.140 without the rtt-sync element. RFC 8865 uses the dcmap and dcsa attributes from RFC 8864. We don't have a mapping for RFC 8864 at this point. Rather than only specifying the use of RFC 8865, it would be more sensible to add an RFC 8864 mapping, which implies compatibility with RFC 8865 in the same way as XEP-0167 supports RTP/T.140. The sync-group/-reference/-name rtt-sync attributes should use the existing XEP-0338 instead. The lang rtt-sync attribute should be transported using a mapping of RFC 8373 SDP, which we don't have yet, but would potentially also be useful for other Jingle media. As you already explained that SIP gateways are a target usecase, I am interested in seeing an example SDP as it would be on the SIP side, so we can together figure what is the best way to map these. I am not a subject matter expert of RTT over SIP, but I believe the SDP likely is to refer to IANA registered SDP attributes, which typically have RFC or other standard documents referred, which could be very useful to discover both the most reasonable SDP mapping for XMPP and for more specification of the meaning of certain attribute values. If the SDP does include attributes that are not well defined in any existing specification documents at applicable standards organizations (IETF, ITU, 3GPP), it may be useful to specify them with any of them first, so we can build our XMPP/Jingle on top of those. Marvin
Thanks Marvin, I agree with these points. I opened PR #1548 to address them. The update clarifies that XEP-0167 already supports RTP/T.140 without rtt-sync, moves grouping to XEP-0338, removes lang/sync-group/sync-reference from rtt-sync, adds RFC 8864/RFC 8373 as open mapping work, and includes an illustrative SIP/SDP RTP/T.140 example so we can discuss the mapping target more concretely. mvg, Edward Tie Op 3-6-2026 om 08:29 schreef Marvin W. via Standards:
Reason that 911NG/112NG are using standaard T.140 via gateway SIP. It must be same data without delay. Any gateway could easily convert the format though, no? Only if the gateway is a MITM gateway, requiring server resources and increasing latency. Using the T.140 standard via standard RTP (RFC
On Tue, 2026-06-02 at 19:41 -0500, Stephen Paul Weber wrote: 4103) and WebRTC Data Channels (RFC 8865) seems sensible for better end-to-end real-time interop.
XEP-0167 already supports RTP/T.140 out of the box, the only addition in this specification is the rtt-sync metadata element. It's thus important that the specification points out that other implementations may use RTP/T.140 without the rtt-sync element.
RFC 8865 uses the dcmap and dcsa attributes from RFC 8864. We don't have a mapping for RFC 8864 at this point. Rather than only specifying the use of RFC 8865, it would be more sensible to add an RFC 8864 mapping, which implies compatibility with RFC 8865 in the same way as XEP-0167 supports RTP/T.140.
The sync-group/-reference/-name rtt-sync attributes should use the existing XEP-0338 instead.
The lang rtt-sync attribute should be transported using a mapping of RFC 8373 SDP, which we don't have yet, but would potentially also be useful for other Jingle media.
As you already explained that SIP gateways are a target usecase, I am interested in seeing an example SDP as it would be on the SIP side, so we can together figure what is the best way to map these. I am not a subject matter expert of RTT over SIP, but I believe the SDP likely is to refer to IANA registered SDP attributes, which typically have RFC or other standard documents referred, which could be very useful to discover both the most reasonable SDP mapping for XMPP and for more specification of the meaning of certain attribute values. If the SDP does include attributes that are not well defined in any existing specification documents at applicable standards organizations (IETF, ITU, 3GPP), it may be useful to specify them with any of them first, so we can build our XMPP/Jingle on top of those.
Marvin _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (5)
-
Daniel Gultsch -
Dave Cridland -
Edward Tie -
Marvin W. -
Stephen Paul Weber