Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties

Document status

Status

...

titleNot started

colourYellow
titleIn progress

...

Impact

Status
colour

...

Red
titleHigh

Driver

...

Approver

...

Document owner

...

...

Resources

...

Target release

...

Resources

...

Target release

...

Parking Lot

...

Epic

...

FR

Related Labels
Include Page
isMissingRequiredParameterstrue

\uD83D\uDCD8 Background

...

Parking Lot

...

Status
colourYellow
titleMedium

...

Status
colourGreen
titleLow

...

Driver

...

Approver

...

Document owner

...

Informed

...

Due date

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

Option 1

Option 2

Description

Pros and cons

(plus)

(minus)

(plus)

(minus)

Estimated cost

Status
colourRed
titleLarge

Status
colourYellow
titleMedium

✅ Action items

  •  

\uD83C\uDF1F Outcome