Steps to reproduce
We noticed in these days, that EDGE send padding (I think for probing) in the RTX channel.
The problem is that the last byte of the padding contains a wrong info about the length of the padding.
As per RFC, an RTX packet must contain the OSN field, which is 2 bytes.
Inspecting the incoming packets, for example this one:
LENGHT: 272 *************** RTP PACKET Header: version: 2 has padding: true has extention: true cc: 0 marker: true type: 96 sequence number: 29031 timestamp: 201402033 synchronization source: 3004 Extention: code: 0XBEDE length: 1 Extentions: id: 1 data: 00101100 11001010 00110110 RTX_OSN: 43845 Padding: bytes: 252
The packet is long 272 bytes, the last byte of the padding indicates that the padding is long 252.
This means we have 20 bytes left >12 for the header, 8 (4 extension header + 4 of extension (abs-send-time in this case)).
But we also have OSN that is other 2 bytes.
The padding length in the last byte should be 250.
In fact, if for whatever reason this packet contained an RTX with a vp8 fragment and padding, when parsing the frame would be corrupted since stripping the padding we would have deleted the last 2 bytes of the frame.
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Gurpreet V.”
Changed Status to “Site Outreach”
Seems that other browsers are behaving the same.
So it might be my misinterpretation of the RFC or the RFC not be so clear.
Thank you for contacting us about this issue! We have resolved this issue as “External” which means the problem is not due to an issue with Microsoft Edge. If you are still experiencing this problem then please feel free to reopen this issue and I will resume the investigation.