2 Jun
2026
2 Jun
'26
5:39 a.m.
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.
2 Jun
2 Jun
8:48 a.m.
On Tue, 2 Jun 2026 at 10:57, Daniel Gultsch <daniel(a)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.
3 Jun
3 Jun
8:55 a.m.
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(a)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(a)xmpp.org
To unsubscribe send an email tostandards-leave(a)xmpp.org
2 Jun
2 Jun
11:49 a.m.
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?
6:15 p.m.
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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
<signature.asc>
6:38 p.m.
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(a)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(a)singpolyma.net> het
volgende geschreven:
>
>
>>
>> URL: https://xmpp.org/extensions/inbox/jingle-rtt-sync.html
>
> 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(a)xmpp.org
> To unsubscribe send an email to standards-leave(a)xmpp.org
> <signature.asc>
3 Jun
3 Jun
2:29 a.m.
On Tue, 2026-06-02 at 19:41 -0500, Stephen Paul Weber wrote:
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
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?
15 Jun
15 Jun
3:03 a.m.
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:
On Tue, 2026-06-02 at 19:41 -0500, Stephen Paul Weber
wrote:
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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
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?
8
days inactive
21
days old
8 comments
5 participants
participants (5)
-
Daniel Gultsch -
Dave Cridland -
Edward Tie -
Marvin W. -
Stephen Paul Weber