[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:all-tabpanel ]

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

    Attachment: append_cap_except.patch

While investigating another issue, just today, I noticed that this ‘audio-first’ assumption is violated even internally. With the Regular Expression {{ast_format_cap_remove_by_type\(.+, AST_MEDIA_TYPE_AUDIO\);}}, I found four places which sort ‘audio-last’ themselves:{code}chan_pjsip_read_stream
chan_sip.c:sip_new
chan_sip.c:sip_rtp_read
channel.c:request_channel{code}For the last one, the general Channel code, I attached an example patch again. Therefore, I do not go forward with case A or B because this would not fix internal ‘audio-last’ situations. And nobody knows if those format capabilities meet code which expect ‘audio-first’. Consequently, I have to ask for a general code review, 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)