Can I make a few observations please. I’ve worked as a software and hardware engineer for 43 years. I’ve used Linux since v2.0 in 1998 and Asterisk since 2006.
monitoring and measurement code has no business touching or affecting RTP timestamps. Ever.
its “nice to have” and not core functionality, put it on its own module and don’t bloat RTP.
it badly breaks Asterisk. It should be fixed and tested properly before going into master branch.
Please please please attach stuff to the JIRA issue. It uses the same user account as the forum. The community forum isn’t made to be an issue tracker, including with attachments.
As for your observations:
George determined there were fundamental issues and problems with timestamps and other things in the RTP stack, they were broken (and actually showed up in RTCP previously - just not substantially enough to cause issues in most cases, but were substantial for MES). So MES uncovered an existing problem when implementing it. The resolution of this was done in MES, but could have also been done as a separate commit unrelated to MES initially.
It’s not possible because of the requirements in order to calculate MES. It would likely require rearchitecting the RTP stack and core RTP API to allow such a thing. That’s not feasible. We always try to do things in a modular way as described when possible, and to allow this when creating new things. PJSIP being an example of that.
Testing did occur before merging (including with George’s current fix), and previously the review was up for weeks allowing others to test if they wanted and provide feedback. We won’t be doing releases from the mainline branches for weeks, so the change will likely be reverted and either resolved before then or delayed. It won’t be allowed to reach a release of course.
I have attached to JIRA ASTERISK-30391
It’s still of course very broken (ie a lot more broken than it was before MES) and affects all calls for me as my handsets are G.722 and trunks generally ALAW. Glad it won’t make a release yet
