Re: Proposed XMPP Extension: Jingle Synchronized Real-Time Text
Edward Tie via Standards <[email protected]> Wed, 3 Jun 2026 14:55:49 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1641471885228522612== Content-Type: multipart/alternative; boundary="------------CAGSBSIeIknmU2PLw0lai0NW" Content-Language: en-US This is a multi-part message in MIME format. --------------CAGSBSIeIknmU2PLw0lai0NW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Today i have written my previous email als short response. I agree that these references should be added. The proposal is not=20 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 =C2=A0 real-time text. - RFC 8865 defines T.140 over WebRTC DataChannels. - XEP-0343 is relevant prior XMPP work for signalling WebRTC DataChannels= in =C2=A0 Jingle, although it is currently Deferred. The reason for this proposal is the application-level binding and semanti= cs, not generic DataChannel transport. In a browser implementation, the live text is eventually sent as data ove= r a WebRTC DataChannel. However, a generic DataChannel alone is not enough fo= r Total Conversation or for gateway interoperability. A Jingle-to-SIP gatew= ay must be able to know, without guessing, that this stream is real-time tex= t, that it belongs to the same active Jingle session as audio/video, and=20 whether it is typed RTT, captions, ASR, interpreter text, translation, or fallbac= k text. Without that semantic binding, a gateway can preserve bytes but still=20 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-compatib= le real-time text and is part of the same conversation as the audio/video=20 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=20 text to =C2=A0 the same call/session as audio/video for Total Conversation, incl= uding =C2=A0 synchronization level, source, language and visible fallback stat= e. I think the draft should reference RFC 8865, XEP-0343, RFC 4103 and RFC=20 9071, but avoid making XEP-0343 a hard dependency while it remains Deferred. A=20 good wording might be that the WebRTC DataChannel profile should align with RF= C 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=20 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 <[email protected]> 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 sessi= on > 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=20 > 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=20 > I thought they'd help others review. > > _______________________________________________ > Standards mailing list [email protected] > To unsubscribe send an email [email protected] --------------CAGSBSIeIknmU2PLw0lai0NW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF= -8"> </head> <body> <p><br> </p> <p>Today i have written my previous email als short response.=C2=A0</= p> <p><br> <br> I agree that these references should be added. The proposal is not intended to<br> redefine existing T.140 transport mechanisms.<br> <br> My current understanding is:<br> <br> - RFC 4103, updated by RFC 9071, defines RTP payload transport for T.140<br> =C2=A0 real-time text.<br> - RFC 8865 defines T.140 over WebRTC DataChannels.<br> - XEP-0343 is relevant prior XMPP work for signalling WebRTC DataChannels in<br> =C2=A0 Jingle, although it is currently Deferred.<br> <br> The reason for this proposal is the application-level binding and semantics,<br> not generic DataChannel transport.<br> <br> In a browser implementation, the live text is eventually sent as data over a<br> WebRTC DataChannel. However, a generic DataChannel alone is not enough for<br> Total Conversation or for gateway interoperability. A Jingle-to-SIP gateway<br> must be able to know, without guessing, that this stream is real-time text,<br> that it belongs to the same active Jingle session as audio/video, and whether<br> it is typed RTT, captions, ASR, interpreter text, translation, or fallback<br> text.<br> <br> Without that semantic binding, a gateway can preserve bytes but still lose the<br> meaning of the stream. In particular, mapping to SIP/RTP T.140 using RFC<br> 4103/RFC 9071 needs to know that the Jingle text stream is T.140-compatible<br> real-time text and is part of the same conversation as the audio/video media.<br> <br> So I see the split as:<br> <br> - RFC 4103/RFC 9071: RTP/T.140 transport.<br> - RFC 8865: T.140 over WebRTC DataChannels.<br> - XEP-0343 or a successor: Jingle signalling for WebRTC DataChannels.<br> - This proposal: the Jingle application semantics that bind real-time text to<br> =C2=A0 the same call/session as audio/video for Total Conversation, including<br> =C2=A0 synchronization level, source, language and visible fallback state.<br> <br> I think the draft should reference RFC 8865, XEP-0343, RFC 4103 and RFC 9071,<br> but avoid making XEP-0343 a hard dependency while it remains Deferred. A good<br> wording might be that the WebRTC DataChannel profile should align with RFC<br> 8865 and with XEP-0343 or any successor Jingle DataChannel signalling<br> specification.<br> <br> I can prepare a small follow-up patch to add these references and clarify this<br> transport-vs-semantics split.</p> <p><br> </p> <div class=3D"moz-cite-prefix">Op 2-6-2026 om 14:48 schreef Dave Cridland:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]= ail.com"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DU= TF-8"> <div dir=3D"ltr"> <div dir=3D"ltr"><br> </div> <br> <div class=3D"gmail_quote gmail_quote_container"> <div dir=3D"ltr" class=3D"gmail_attr">On Tue, 2 Jun 2026 at 10:= 57, Daniel Gultsch <<a href=3D"mailto:[email protected]" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">da= [email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex">Title: Jingle Synchronized Real-Time Text<br> Abstract:<br> This specification defines a Jingle application extension for<br> negotiating real-time text as part of the same conversational session<br> as audio and video.<br> <br> URL: <a href=3D"https://xmpp.org/extensions/inbox/jingle-rtt-sync.html" rel=3D"noreferrer" target=3D"_blank" moz-do-not-send=3D"tru= e" class=3D"moz-txt-link-freetext">https://xmpp.org/extensions= /inbox/jingle-rtt-sync.html</a></blockquote> <div><br> </div> <div>This generally looks reasonable, and I support publication, but I'm struggling to find the missing references.</div> <div><br> </div> <div>T.140 over datachannel appears to be RFC 8865.</div> <div><br> </div> <div>You'll also want XEP-0343 for WebRTC datachannel support in Jingle.</div> <div><br> </div> <div>Finally, RFC 4103 updated by RFC 9071 does T.140 over RTP.</div> <div><br> </div> <div>(In my view) these don't need to be in place prior to publication but I thought they'd help others review.</div> </div> </div> <br> <fieldset class=3D"moz-mime-attachment-header"></fieldset> <pre wrap=3D"" class=3D"moz-quote-pre">____________________________= ___________________ Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"m= ailto:[email protected]">[email protected]</a> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre= f=3D"mailto:[email protected]">[email protected]</a> </pre> </blockquote> </body> </html> --------------CAGSBSIeIknmU2PLw0lai0NW-- --===============1641471885228522612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============1641471885228522612==--