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

Alexander Traud (JIRA) noreply at issues.asterisk.org
Fri Jan 15 07:49:59 CST 2021


     [ https://issues.asterisk.org/jira/browse/ASTERISK-29198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-29198:
---------------------------------------

    Attachment: sip.conf
                extensions.conf

Argh. Found the puzzle piece which was missing in my issue description: {{disallow=all}}. Then {{sip show settings}} on the command-line interface shows {{h264,ulaw}} for ‘Codecs’. Now, the order is video,audio. And the warning is printed when both phones support H.264.

Without that, {{allow=}} just appends H.264 to the existing codecs. The order stayed audio,video.

Attached are my sip.conf and extensions.conf for chan_sip. Tested with the yesterday released Asterisk 18.2.0-rc1.

> 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: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>            Severity: Minor
>              Labels: patch
>         Attachments: 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)



More information about the asterisk-bugs mailing list