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

[Alexander Traud (JIRA)]

Alexander Traud created ASTERISK-29198:
------------------------------------------

             Summary: 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: . I did not set the category correctly., Channels/chan_sip/CodecHandling
    Affects Versions: 18.1.0, 16.15.0
            Reporter: Alexander Traud
            Severity: Minor


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)