[asterisk-bugs] [JIRA] (ASTERISK-29198) allow=audio, video, text: First codec must be an audio codec.

[Alexander Traud (JIRA)]

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

Alexander Traud commented on ASTERISK-29198:
--------------------------------------------

bq. I did not analyze/understand all other occurrences. Therefore, it might be better to … c) go through the whole code \[of Asterisk\] and revise this.

One of the core modules, {{main/channel.c}}, is mis-using the list of capabilities. On the one hand side, that module assumes audio to be first. On the other hand, it puts audio last. Today, I found another, a third, scenario besides mis-configuration and wrong internal use: external trigger. Place a video-only call (or a call with video but with all audio formats rejected). In that case, {{main/channel.c}} prints for the echo test
bq. Unable to find a codec translation path: (list of installed sound formats via {{menu select}}) -> (h264)
However, {{main/channel.c}} has to print
bq. Unable to set format because channel %s supports no formats
The latter would happen with my attached patches. Great! Although the wording has to be improved. However, however, that is printed not with the severity of {{NOTICE}} but as {{ERROR}}. In that case, I only tested Asterisk 13.38.1 with chan_sip.

Anyway,
* because this can be triggered externally,
* because an error is logged in a ‘normal’ situation,

that tells me, we are in badlands. 

Somebody with a bird’s-eye view should have a look at the whole Asterisk code. Especially because so many modules might be affected. I just have a worm’s-eye view. This review could be done in the course of the upcoming Advanced Codec Negotiation (ACN; [mailing list|http://lists.digium.com/pipermail/asterisk-dev/2020-June/thread.html], [blog post|https://www.asterisk.org/asterisk-acn-advanced-codec-negotiation/], [wiki entry|https://wiki.asterisk.org/wiki/display/AST/PJSIP+Advanced+Codec+Negotiation]).

The two attached patches, you can use them. They fix a lot already. However, I fear they hide the issue just deeper. They do not fix the issue in general. Some code parts assume that the first format is audio. Some code parts put audio last. Some code parts go through the full capabilities, although they should go through the audio capabilities only. I hate to get worked up over this without providing a complete fix, and the issue looked easy at the first user report – however, from my point of view, this looks bigger. Therefore, case C.

> allow=audio,video,text: First codec must be an audio codec.
> -----------------------------------------------------------
>
>                 Key: ASTERISK-29198
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29198
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling, Core/General
>    Affects Versions: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>            Assignee: Alexander Traud
>            Severity: Minor
>              Labels: patch
>         Attachments: append_cap_except.patch, audio_not_first.patch, extensions.conf, sip.conf
>
>
> If the first codec in the list of allows is not an audio codec, not only the channel driver chan_sip but many more modules get crazy.
> *Steps to Reproduce*
> 1. configuration file {{sip.conf}} with {{allow=h264,ulaw}} in the \[general\] section
> 2. from one extension, dial another extension
> *Actual Results*
> {code}WARNING: channel.c: set_format: Unable to find a codec translation path: (h264) -> (ulaw)
> WARNING: channel.c: set_format: Unable to find a codec translation path: (ulaw) -> (h264){code}
> *Next Steps*
> A search with the Regular Expression {{ast_format_cap_get_format\(.+, 0\);}} revealed many channels and modules seem affected like {{app_mp3}}, {{core_unreal}}, and {{res_speech}}. However, I did not test those. Even {{chan_sip}} has one more place in source code, which looks affected: When the ptime / framing is negotiated.
> The attached patch fixes just the reported scenario, the bug in {{main/channel.c}}. There, the code assumes audio codecs only anyway; therefore I added a filter. After fixing that, I had to fix another bug in {{channels/chan_sip.c}} to get the scenario above working. I did not analyze/understand all other occurrences. Therefore, it might be better to
> a) place a note in the documentation rather than fixing this, or
> b) sort the codecs while importing the configuration,
> c) go through the _whole_ code and revise this.
> In any case, I am not sure if it helps anyone if I patch just the reported issue. From my point of view, that would not solve but hide the problem just deeper. What do you think?
> *Workaround*
> The first allowed codec must be an audio codec. Therefore it is best when you go for {{allow=audio,video,text}}.



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