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