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:
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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org