\uD83D\uDCD8 Background
There are requests to make T.38 media secure. There are a couple of defined methods for securing T.38 media but none are in wide use.
Fax media can be secure when sending over audio G.711 using RTP with SRTP. T.38 over UDPTL is not encrypted data. Request to send T.38 over SRTP to provide an encrypted T.38 payload.
\uD83D\uDCDA Relevant data
Secure T.38 Modes
ITU Recommendation T.38 (11/15) - Section 9.2 IFT over UDP transport using RTP protocol: IFT/RTP/UDP by using negotiation defined in Annexes B and D.
RFC 7345/RFC 8842 - UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
Similarities and differences between RTP and UDPTL
From Table 7 ITU T.38
Feature | UDPTL mechanism | RTP mechanism | |
|---|---|---|---|
| 1 | Payload format | UDPTLPacket specified in Annex | Without redundancy and FEC, RTP payload is a single IFP packet. When FEC packets constitute a separate stream ([IETF RFC 5109]), the RTP payload is a single IFP packet. |
| 2 | Payload sequencing | UDPTL sequence number | RTP sequence number |
| 3 | Redundancy | Uses mechanism defined in clause 9.1.3.1 UDPTL FEC message format | [IETF RFC 2198] |
| 4 | FEC | Uses mechanism defined in Annex C The optional forward error correction scheme for UDPTL | [IETF RFC 5109], with or without [IETF RFC 2198] encapsulation |
Each RTP packet starts with a fixed RTP header. The following describes the payload specific fields of the RTP fixed header when the RTP packet encapsulates fax:
Payload type (PT): The payload type for fax is a dynamic payload type identified by the name "t38". If redundancy is used per [IETF RFC 2198], the payload type must indicate the payload format RED (as per [IETF RFC 2198]).
Marker (M) bit: The marker bit is not used for fax and MUST be set to zero. The Marker bit should be ignored by the receiver of the packet.
\uD83C\uDF08 Options considered
Option 1 | Option 2 | |
|---|---|---|
Description | ||
Pros and cons |
|
|
Estimated cost | LARGE | MEDIUM |
0 Comments