| Summary: | ASTERISK-24812: ARI: Creating channels through /channels resource always uses SLIN, which results in unneeded transcoding | ||||
| Reporter: | Matt Jordan (mjordan) | Labels: | |||
| Date Opened: | 2015-02-19 15:11:27.000-0600 | Date Closed: | 2015-02-24 16:00:41.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Resources/res_ari Resources/res_ari_channels | ||
| Versions: | 13.2.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | When creating a channel using {{POST /channels}}, the created channels are currently always handed a format capability structure containing only {{SLIN}}. While this is good in the sense that just about everything transcodes with {{SLIN}}, it's bad as that will result in a lot of transcoding if the created channel is a Local channel.
Consider a situation where we want to: # Create a Local channel to the dialplan # Bridge one half in a Stasis application with a channel that speaks G722 (and that is already available) # Bridge the other half with a channel that speaks G722 In the most optimal scenario, we will end up transcoding from G722 => SLIN16 => SLIN8 in the write direction and again from SLIN8 => SLIN16 => G722; and in the opposite direction, we will do the same. That's 4 2-hop transcoding paths, where in reality, we didn't need transcode at all. Instead, ARI should do one of two things: # If there is a 'related' channel creating the outbound channel (which is how we do linkedid propagation), then the native format capabilities of that channel should be pushed down to the created channel. # If there is no 'related' channel, the created channel should have all audio formats assigned to it. The natural process of producing joint capabilities with the channel driver will result in the correct selection, as opposed to artificially constraining it to SLIN. | ||||
| Comments: | |||||