[asterisk-bugs] [JIRA] (ASTERISK-25535) [patch] format creation on module load instead of cache

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228218#comment-228218 ] 

Asterisk Team commented on ASTERISK-25535:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> [patch] format creation on module load instead of cache
> -------------------------------------------------------
>
>                 Key: ASTERISK-25535
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25535
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Formats/General
>            Reporter: Alexander Traud
>            Severity: Minor
>         Attachments: capability_cached_format.patch
>
>
> Since Asterisk 13, formats are cached to speed up various comparisons. However still, each module does get its own struct, because of
> {{ast_format_cap_append_by_type}} and
> {{ast_format_cap_update_by_allow_disallow}}.
> I tested the module {{chan_sip}} and see no reason for this behaviour. Beside performance, the current behaviour does not indicate whether I deal with a cached format or one created because of {{ast_format_clone}} in a res/res_format_attr_* like the one for H.263, H.264, or Opus. Currently, around five or six new format structs are created per connection.
> Furthermore, this change is required to solve ASTERISK-25160 (with patch B): The format attribute modules are created *after* the channel modules. Therefore, the unique formats of each channel do not have a format attribute module attached. Therefore, they do not parse/compare/join the SIP/SDP line {{fmtp}}. This is required for transcoding modules not yet included in the Asterisk project like [iLBC 20|https://github.com/traud/asterisk-ilbc], [SILK|https://github.com/traud/asterisk-silk], [AMR|https://github.com/traud/asterisk-amr], and (one day) [Opus|https://github.com/traud/asterisk-opus].
> Question to the Asterisk team:
> The proposed patch does not avoid every new creation, for example those formats with the same name but different bitrates like sln16 and speex16. By the way, I played around with several bitrates in my AMR module and did not find any benefit (beside this drawback). Please, re-iterate which code section(s) do benefit from this.
> Although currently incomplete for pathologic cases (sln and speex do not have a res_format_attr) please, still consider this change for inclusion in Asterisk 13.



--
This message was sent by Atlassian JIRA
(v6.2#6252)