This document was made to clarify the process of adopting a payload format for RTP. A better approach would be forking then merging. This is used by the author to keep track of what to be done
This package includes the T140 packet implementation from the RFC4103. It is based on some code from pion/rtp, but this is not a part of pion/rtp.
In this implementation, T140 packet refers to an RTP packet whose payload is in text/t140
format.
A T140 packet, similar to an RTP packet, includes 2 parts:
- T140 header = a "constrained" RTP header
- T140 payload = an RTP payload contains a T140block
NOTE In this implementation, even text/t140
is being considered as a type of "codec", this format does not require any further header and depends solely on the RTP header (specified in RFC3550 with the constraints in section 2.1). The structure of this implementation may differ from the implementation in pion/rtp/codecs for this reason. For example, the T140Packet
will be a special type embedded the Packet
and the payload of T140Packet
will be processed according to the PT
field in the header (with redundancy-RED
or an ordinary packet-T140
).
NOTE A T140 packet is an RTP packet, but an RTP packet is not guaranteed to satisfy T140 packet's standardization.
Examples for a packet:
Non-padding packet with valid byte-slice form on the right
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| T140 PT | sequence number |
|10 |0|0| 0000 |1| 1100100(100)| 27023 | -> 0x80, 0xe4, 0x69, 0x8f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (1000Hz) |
| 3653407706 | -> 0xd9, 0xc2, 0x93, 0xda
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 476325762 | -> 0x1c, 0x64, 0x27, 0x82
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T.140 encoded data |
| Hello | -> 0x48, 0x65, 0x6c, 0x6c, 0x6f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet with padding with valid byte-slice form on the right
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| T140 PT | sequence number |
|10 |1|0| 0000 |1| 1100100(100)| 27023 | -> 0xa0, 0xe5, 0x69, 0x8f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (1000Hz) |
| 3653407706 | -> 0xd9, 0xc2, 0x93, 0xda
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
| 476325762 | -> 0x1c, 0x64, 0x27, 0x82
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T.140 encoded data |
| Hello (+ padding bytes) | -> 0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x00, 0x00, 0x03
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A text/t140 packet with one redundant T140block
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC=0 |M| "RED" PT | sequence number of primary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp of primary encoding "P" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| T140 PT | timestamp offset of "R" | "R" block length |
|1| 1100100(100)| 16320 | 10 | -> 0xE4, 0xFF, 0x00, 0x0a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| T140 PT | "R" T.140 encoded redundant data | -> 0x64, ...
+-+-+-+-+-+-+-+-+ +---------------+
+ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+
| "P" T.140 encoded primary data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From the template of RTP header, the T140-specific setting can be listed as:
X
: is always set to0
which means no extension is allowedCC
: is always set to000
CSRC
: due toCC
=000
theCSRC
slice in the normal RTP has length 0PT
: is dynamic (range from 96 to 127) and agreed via other means (e.g. SIP). In this implementation,T140 PT
is chosen to be1100100
(100) andRED PT
(for redundancy) is chosen to be1100101
(101)
The T140block
T.140 text is UTF-8 coded, as specified in T.140, with no extra
framing. The T140block contains one or more T.140 code elements as
specified in [1]. Most T.140 code elements are single ISO 10646 [5]
characters, but some are multiple character sequences. Each
character is UTF-8 encoded [6] into one or more octets. Each block
MUST contain an integral number of UTF-8 encoded characters
regardless of the number of octets per character. Any composite
character sequence (CCS) SHOULD be placed within one block.
There is no further instruction for the payload. The payload length is variable between packets and is not determined by any means from the header.
Data (with or without redundancy) which is considered to be one sample, MUST fits into one packet to maintain the real-time characteristic. Therefore, in this implementation, the maximum value of a payload in a T140 packet is chosen to be 1024 bytes.
All components in this package is referenced from the pion/rtp and webrtc/pkg/media/:
-
t140Packet.go
-
t140Reader.go
→ usingpion/rtpio
-
t140Writer.go
→ usingpion/rtpio