Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Page Properties
/

Status

Document status

titleNot started
Status
colourYellow
titleIn progress
/

Impact

Status
colourGreenRed
titleComplete

Impact

Status
colourRed
titleHigh
/
Status
colourYellow
titleMedium
/
Status
colourGreen
titleLow

Driver

Approver

Contributors

Informed

Due date

Resources

\uD83D\uDCD8 Background

...

High

Driver

Approver

Document owner

John Shaheen

Resources

Target release

Parking Lot

Epic

\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 A

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.
With [IETF RFC 2198]-based redundancy, the RTP payload structure is as specified in [IETF RFC 2198]. With FEC that uses [IETF RFC 2198] encapsulation, the RTP payload structure is as specified in [IETF RFC 5109] and [IETF RFC 2198]

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

...