When the remote track which caused to transit to the disconnected status is removed from the conference the current status received through the data channels should be used to avoid getting out of sync by missing "muted"/"unmuted" events sequence. Usually the track removed is replaced by the new one(in our use cases), but the new track is always added unmuted. Now if the connection gets restored in the meantime while the track is being signalled then the 'muted/unmuted' event sequence may be missed and the participant might be blocked in the "disconnected" state forever.dev1
|
|
||
| 40 |
|
40 |
|
| 41 |
|
41 |
|
| 42 |
|
42 |
|
|
43 |
|
|
|
44 |
|
|
|
45 |
|
|
|
46 |
|
|
|
47 |
|
|
|
48 |
|
|
|
49 |
|
|
| 43 |
|
50 |
|
| 44 |
|
51 |
|
| 45 |
|
52 |
|
|
|
||
| 128 |
|
135 |
|
| 129 |
|
136 |
|
| 130 |
|
137 |
|
|
138 |
|
|
|
139 |
|
|
|
140 |
|
|
| 131 |
|
141 |
|
| 132 |
|
142 |
|
| 133 |
|
143 |
|
|
|
||
| 145 |
|
155 |
|
| 146 |
|
156 |
|
| 147 |
|
157 |
|
|
158 |
|
|
|
159 |
|
|
|
160 |
|
|
|
161 |
|
|
|
162 |
|
|
|
163 |
|
|
| 148 |
|
164 |
|
| 149 |
|
165 |
|
| 150 |
|
166 |
|
|
|
||
| 253 |
|
269 |
|
| 254 |
|
270 |
|
| 255 |
|
271 |
|
| 256 |
|
|
|
|
272 |
|
|
|
273 |
|
|
|
274 |
|
|
|
275 |
|
|
|
276 |
|
|
|
277 |
|
|
|
278 |
|
|
|
279 |
|
|
|
280 |
|
|
|
281 |
|
|
|
282 |
|
|
|
283 |
|
|
|
284 |
|
|
|
285 |
|
|
|
286 |
|
|
|
287 |
|
|
|
288 |
|
|
|
289 |
|
|
|
290 |
|
|
|
291 |
|
|
|
292 |
|
|
|
293 |
|
|
|
294 |
|
|
|
295 |
|
|
|
296 |
|
|
|
297 |
|
|
|
298 |
|
|
|
299 |
|
|
|
300 |
|
|
|
301 |
|
|
|
302 |
|
|
|
303 |
|
|
|
304 |
|
|
|
305 |
|
|
|
306 |
|
|
|
307 |
|
|
|
308 |
|
|
|
309 |
|
|
|
310 |
|
|
|
311 |
|
|
|
312 |
|
|
|
313 |
|
|
|
314 |
|
|
|
315 |
|
|
|
316 |
|
|
|
317 |
|
|
|
318 |
|
|
|
319 |
|
|
|
320 |
|
|
|
321 |
|
|
|
322 |
|
|
|
323 |
|
|
|
324 |
|
|
|
325 |
|
|
|
326 |
|
|
|
327 |
|
|
|
328 |
|
|
|
329 |
|
|
| 257 |
|
330 |
|
| 258 |
|
331 |
|
| 259 |
|
332 |
|