dissector evs codec
Hello,
I'm doing a tool to generate evs rtp packets from wave format.
To help me in the development (and verifications) I use the evs dissector of a recent wireshark version (to be precise version 3.6.7).
Using the dissector I found something strange when Header-Full format is used and the rtp contains one or more padding bytes inserted to avoid conflict with any of the protected sizes reserved for the compact format (see clause A.2.2.1.4.2 of 3GPP TS26.445)
May be that I'm wrong in either my tool or reading the specs but I have the doubt about the dissector too. So here the answer: Is the current EVS dissector able to manage this particular aspecto of rtp payload.
Thanks and regards
Massimiliano
Can you provide a packet capture on a public file share and update the question with a link to it?
here the link about a pcap example as created by the tool:
https://drive.google.com/file/d/1cHAK...
The file contains (in my intentions) a rtp flow (PT 96) about EVS-primary mode, rate 7.2kbit/s, packet size 20ms, full format (with a CMR byte = 0xff, that's NO_REQ, one a TOC byte). The payloadSize in this case should be the sum of: 18 bytes for the single frame EVS primary at 7.2 kbit/s + 1 byte for CMR info + 1 byte for TOC. So 20 bytes. This size is exactly the size of a single frame for EVS primary at 8.0 kbit/s.
To avoid the collision a padding byte (0x00) is queued and consequently introduced the padding count bytes (2 bytes). The padding flag is also set in the rtp header. So the new payload size move from 20 to 22 with padding bit set ...(more)
Looks like both file links are the same. Can you check the link to the first file?
Correction for a (my) mistrake. Here below the correct link for the "another" file example: https://drive.google.com/file/d/1ECKn...
It needs to be set to public access.