You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The media PT must be the payload type of the output of the media-format-specific packetization.
82
-
The frame index of the first fragment of each media frame MUST be 0.
83
-
The frame index of each subsequent fragment MUST be one more than the previous fragment.
84
-
The L bit MUST be 0 for all fragments except for the last one of the media frame.
85
-
The media frame ID must be unique enough that a depacketizer may be able to differentiate
86
-
the fragments of one media frame from another.
104
+
The first byte of the RTP payload is the SFrame RTP header.
105
+
106
+
The S bit of the SFrame RTP header MUST be 0 for all fragments except for the first one of the SFrame frame.
107
+
108
+
The E bit of the SFrame RTP header MUST be 0 for all fragments except for the last one of the SFrame frame.
109
+
110
+
The 6 remaining bits of the SFrame RTP header are reserved for future use.
111
+
112
+
The payload type (PT) identifies the format of the media encrypted with SFrame.
113
+
87
114
The SSRC, timestamp, marker bit, and CSRCs of the SFrame RTP packets MUST be the same
88
115
as those of the output of the media-format-specific packetization.
89
116
The header extensions of the SFrame RTP packets SHOULD be the same
90
117
as those of the output of the media-format-specific packetization, but some may be omitted
91
118
if it is known that the omitted header extensions do not need to be duplicated on each SFrame RTP packet.
92
-
The payload type of the SFrame RTP packets must be a payload type that indicates the payload
93
-
format defined in this document, and it must have a negotiated RTP clock rate that is the same as the
94
-
media-format-specific RTP packet.
119
+
120
+
# RTP Packetization of SFrame
121
+
122
+
SFrame packets can be generated either from RTP media packets or from media frames as defined by {{WebRTC_Encoded_Transform}}.
123
+
124
+
For per-packet SFrame, the following processing is done, with a media frame as input:
125
+
126
+
1. Generate a group of RTP media packets from the media frame using a media-format-specific packetizer.
127
+
The media-format-specific packetizer needs to be made aware of the SFrame overhead that happens to each RTP packet.
128
+
2. For each RTP packet of the group, encrypt its payload with SFrame.
129
+
3. Prepend to each RTP packet payload a SFrame RTP header with the S and E bits set to 1.
130
+
4. Send each RTP packet of the group.
131
+
132
+
For per-frame SFrame, the following processing is done, with a media frame as input:
133
+
134
+
1. Generate a SFrame ciphertext from the media frame data.
135
+
2. Fragment the SFrame ciphertext in a group of payloads so that RTP packets generated from them do not exceed the network maximum transmission unit size.
136
+
3. Prepend a zero byte as the SFrame RTP header to all payloads of the group.
137
+
4. Set the first bit S of the SFrame RTP header of the first packet to 1.
138
+
5. Set the second bit E of the SFrame RTP header of the last packet to 1.
139
+
6. Generate a group of RTP packets from the group of payloads, using the media frame to generate the RTP header, including RTP header extensions.
140
+
7. Send each RTP packet of the RTP packet group.
95
141
96
142
# RTP depacketization of SFrame
97
143
98
-
Depacketization is done by doing the packetization process in reverse:
144
+
Reception of SFrame packets is done as follows:
145
+
146
+
1. The fragments of a given SFrame ciphertext are grouped together in order of the RTP sequence number,
147
+
the first packet of the group having its S bit set to 1 and the last packet of the group havint its E bit set to 1.
148
+
All packets in between the first and last needs to be in the group.
149
+
2. Concatenate the payloads of all packets of the group to form the SFrame ciphertext.
150
+
3. Decrypt the SFrame ciphertext to obtain the media decrypted data.
151
+
4. If per-packet SFrame is being used, the following processing is done:
152
+
1. assert that the group of packets consist of a single packet.
153
+
2. Set the media decrypted data as the payload of the packet and send the packet to the media-format-specific RTP depacketizer.
154
+
3. If the depacketizer cannot generate a media frame yet, abort these steps. Otherwise, generate a media frame from the depacketizer.
155
+
5. If per-frame SFrame is being used, the following processing is done:
156
+
1. assert that the group of packets all have the same payload type.
157
+
2. Extract the media metadata from the group of packets.
158
+
3. Generate a media frame from the media decrypted data and the media metadata.
159
+
6. Send the media frame to the receiving pipeline.
160
+
161
+
# SFrame SDP negotiation
162
+
163
+
SFrame packetization is indicated via a new "a=sframe" SDP attribute defined in this specification.
164
+
This attribute is used at media level, it does not appear at session level.
165
+
166
+
The presence of the "a=sframe" attribute in a media section (in either an offer or an answer) indicates that the
167
+
endpoint is expecting to receive RTP packets encrypted with SFrame for that media section, as defined below.
99
168
100
-
1. The fragments of a given media frame ID are grouped together in order of fragment index and concatenated together, resulting in a media frame encrypted by SFrame.
169
+
Once each peer has verified that the other party expects to receive SFrame RTP packets, senders are expected to send SFrame encrypted RTP packets.
170
+
If one peer expects to use SFrame for a media section and identifies that the other peer does not support it, the peer
171
+
is expected to stop the transceiver associated to the media section, which will generate a zero port for that m-section.
101
172
102
-
2. The media frame is decrypted using SFrame, resulting in a media-format-specific RTP payload.
173
+
When SFrame is in use for that media section, it will apply to the relevant media encodings defined for that media section.
174
+
This includes RTP payload types bound to media packetizers and media depacketizers as defined in {{!RFC7656}}, typically audio formats such as Opus and RTP video formats such as H264.
175
+
This notably includes RTP payload types representing {{WebRTC_Encoded_Transform}} [encoded video frame formats](https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-data) and [encoded audio frame formats](https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-data).
103
176
104
-
3. The media-format-specific RTP payload is combined with the RTP headers of the RTP packet with fragment index 0, resulting in a media-format-specific RTP packet.
105
-
The "media PT" from the SFrame RTP payload header is used as the payload type of the media-format-specific RTP packet.
177
+
This does not include RTP-Based Redundancy mechanisms as defined in {!RFC7656}}.
178
+
For instance, RTX defined in {{!RFC4588}} will retransmit SFrame based packets.
179
+
Forward error correction formats as defined in {{!RFC5109}} will protect the encrypted content.
180
+
For Redundant Audio Data, known as RED, as defined in {{!RFC2198}}, a RED packetizer will take as input SFrame encrypted media data instead of unencrypted media data.
106
181
107
-
4. The media-format-specific RTP packet is passed into a media-format-specific RTP depacketizer, resulting in a media frame.
182
+
If BUNDLE is in use and the "a=sframe" attribute is present for a media section but not for another media section of the same BUNDLE,
183
+
payload types for media encodings that are relevant for SFrame MUST not be reused between the two media sections.
108
184
185
+
Questions:
109
186
110
-
# SFrame payload type negotiation
187
+
1. Should we precise how RTX/FEC works with SFrame packetization? No impact AFAIK since RTX/FEC would work on packets (whether SFramed or not).
188
+
2. Is RED current proposal (transmit SFrame ciphertext blocks) good enough? An alternative is to have SFrame being applied on the entire RED packet payload.
189
+
3. Should we allow `a=sframe` at session level to mean that all media sections want sframe?
111
190
112
-
Because the payload type of an RTP packet that results from SFrame-specific packetization must match the
113
-
clock rate of the payload type of the RTP packet that results from media-format-specific packetization,
114
-
it may be necessary to negotiate more than one SFrame payload type. For example, if one were to use SDP
115
-
to negotiate payload types, the following payload types could be negotiated with different clock rates:
191
+
Here is an example of SFrame being negotiated for audio (opus and CN) and for video (H264 and VP8):
0 commit comments