]> git.ipfire.org Git - thirdparty/asterisk.git/commit
main/format_cap: Parse capabilities generated by ast_format_cap_get_names 47/847/2
authorMatt Jordan <mjordan@digium.com>
Wed, 8 Jul 2015 21:21:09 +0000 (16:21 -0500)
committerMatt Jordan <mjordan@digium.com>
Sun, 12 Jul 2015 22:54:48 +0000 (17:54 -0500)
commit5f13c2226a35f465ab70c8e25a885f1f3cdaa1c5
treea8d3e52f08b4d57daa1f7c6dbbf26ab2c3fb2014
parent5c491a629586ab7036107ae79935a39bcf793a0a
main/format_cap: Parse capabilities generated by ast_format_cap_get_names

We have a strange relationship between the parsing of format
capabilities from a string and their representation as a string. We
expect the format capabilities to be expressed as a string in the
following format:

allow = !all,ulaw,alaw
disallow = g722

While we would generate the string representation of those formats as:

allow = (ulaw|alaw)
disallow = (ulaw|alaw|g729...)

When the configuration framework needs to store values as a string, it
generates the format capabilities using the second representation; this
representation however cannot be parsed when the entry is rehydrated.
This patch fixes that by updating
ast_format_cap_update_by_allow_disallow to parse an entry as if it were
in the generated format if it has a leading '(' and a trailing ')'.

ASTERISK-25238

Change-Id: I904d43caf4cf45af06f6aee0c9e58556eb91d6ca
main/format_cap.c