An interesting issue was recently filed where dialing a Local channel resulted in the following:
[2021-03-28 22:41:35] ERROR[15773][C-00000030]: translate.c:1396 ast_translator_best_choice: Cannot determine best translation path since one capability supports no formats
[2021-03-28 22:41:35] WARNING[15773][C-00000030]: core_local.c:992 local_request_with_stream_topology: No translator path exists for channel type Local (native (codec2|g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin12|slin16|
slin24|slin32|slin44|slin48|slin96|slin192|lpc10|g729|speex|speex16|
speex32|ilbc|g722|siren7|siren14|testlaw|g719|opus|jpeg|png|h261|h263
|h263p|h264|h265|mpeg4|vp8|vp9|red|t140|t38|silk8|silk12|silk16|silk24)) to (nothing)
[2021-03-28 22:41:35] WARNING[15773][C-00000030]: app_dial.c:2596 dial_exec_full: Unable to create channel of type ‘Local’ (cause 0 - Unknown)
[2021-03-28 22:41:35] ERROR[15773][C-00000030]: translate.c:1396 ast_translator_best_choice: Cannot determine best translation path since one capability supports no formats
[2021-03-28 22:41:35] WARNING[15773][C-00000030]: core_local.c:992 local_request_with_stream_topology: No translator path exists for channel type Local (native (codec2|g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin12|slin16|
slin24|slin32|slin44|slin48|slin96|slin192|lpc10|g729|speex|speex16|
speex32|ilbc|g722|siren7|siren14|testlaw|g719|opus|jpeg|png|h261|h263|
h263p|h264|h265|mpeg4|vp8|vp9|red|t140|t38|silk8|silk12|silk16|silk24)) to (nothing)
[2021-03-28 22:41:35] WARNING[15773][C-00000030]: app_dial.c:2596 dial_exec_full: Unable to create channel of type ‘Local’ (cause 0 - Unknown)
– No devices or endpoints to dial (technology/resource)
That’s a large block of text, and a confusing one at that.
Let’s start with a bit of backstory on dialing. When a channel is dialed we provide to it either a list of requested formats or requested streams, which can then influence the outgoing side to provide a better experience. You call in with video and we want to call the outgoing side with video if possible, that kind of thing. The Local channel does this but for audio streams it also does some codec manipulation to ensure things don’t encounter a scenario where transcoding is not possible and the call drops.
This raises the question: How could it be possible for an audio stream to have no formats? After investigating further it became clear the answer was: SDP!
In SDP a media stream is never truly removed from the SDP. This is because the ordering of streams in SDP matters, and removing a stream could shift other streams. This means that streams in SDP remain but are changed to a declined/removed state. When this occurs there are no negotiated formats on the stream. This is precisely what was happening. The dialing channel had a negotiated perfectly fine audio stream, but there was a second audio stream that was declined/removed and had no formats. The Local channel was trying to figure out what formats to allow but since the declined/removed stream had no formats, it bailed.
This meant the fix was easy: In the Local channel if a stream is declined/removed then skip looking at it! This change has now been merged in and will be in the next set of releases (16.19.0, 18.5.0).
