Summary: | ASTERISK-22294: [patch] format_g729 - better handling of CNG | ||
Reporter: | Jaco Kroon (jkroon) | Labels: | patch |
Date Opened: | 2013-08-13 10:29:47 | Date Closed: | |
Priority: | Trivial | Regression? | No |
Status: | Open/New | Components: | Formats/format_g729 |
Versions: | 11.5.0 13.18.4 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | asterisk 11.5.0 | Attachments: | ( 0) asterisk_g729_vad_detection.patch |
Description: | In spite of asterisk passing all possible paramaters to kill VAD (annexb) some endpoints are hard-coded to send it, or simply ignore these settings. I've got two examples, the one is a Yealink phone with "silence suppression" switched on, the other is an upstream peer for one of my clients. To aggravate the issue they combine CNG with payload, and insist on a ptime=60, so I've seen 10*n+2 byte packets. The assumption here is that the first 50 bytes is payload followed by 2 bytes CNG parameter data.
I've written a patch that will in these cases take whatever payload it can and write it to the stream and silently (after generating a WARNING to the logs for each affected stream - I'd like to add the actual channel name to the warning but don't see an easy way) discard the CNG data. This results in 10-byte all-zero blocks, which I'll deal with externally. This results in a 100Hz hum-like noise when listening to the stream again. | ||
Comments: | By: Jaco Kroon (jkroon) 2013-08-13 10:34:18.733-0500 patch to detect incorrect G.729 streams on write and at a minimum get any present payload, also stop spamming the logs with pointless WARNINGS: format_g729.c: Invalid data length, 2, should be multiple of 10 on every single CNG frame. By: Jaco Kroon (jkroon) 2013-12-31 04:24:23.457-0600 Updated variant of the patch that fixes a spelling error and adds a missing \n. |