Nueva negociación de Codec en la próxima versión 18.2 de Asterisk

La negociación de Codec en Asterisk ha sido, desde que yo recuerde, un gran dolor de cabeza; la verdad, y no me da vergüenza decirlo, nunca he entendido bien como funcionada y como se podía aprovechar al máximo la posibilidad de escoger los codec con base a los usuarios involucrados en la llamada o con base si se trataba de una llamada entrante o saliente.

En FreeSWITCH la negociación de codec es muy buena, amplia y permite un buen abanico de soluciones. En la próxima entrada publicare el documento dedicado a la negociación de Codec en FS que es parte del curso disponible en el campus de VozToVoice.

Volviendo a Asterisk, los desarrolladores se han “inventado” el acrónimo ACN (Advanced Codec Negotation) para dar un nombre a los cambios que se implementarán a nivel de flujo media en la próxima versión 18.2 de Asterisk. Esta nuevo enfoque se basará en tres áreas de trabajo:

  • Control de proceso: será posible decidir como utilizar los codec configurados en el endpoint y los codec recibidos en el anexo SDP

  • Retroalimentación de la respuesta: lograr poder utilizar los codec indicados en la respuesta de forma de poder evitar el transcoding

  • Organización del código relacionado con la negociación de los Codec. Esto es más un tema de desarrollo que muy probablemente no interesará a los usuarios finales.

El punto de partida de la nueva configuración es el tipo de solicitud recibida/enviada que da lugar a cuatro tipos diferentes de situaciones relacionadas con dos grupos principales:

  • Oferta SDP

    • Justo antes que se envíe el canal entrante al dialplan

    • Justo después que el canal saliente reciba la llamada desde el dialplan

  • Respuesta SDP

    • Justo antes que el canal saliente pase la respuesta a la llamada al dialplan

    • Justo después que el canal entrante recibe la respuesta de la llamada desde el dialplan

La nueva configuración se basará en cuatro nuevos parámetros que se podrán configurar en un bloque de tipo endpoint; estos parámetros serán (en el orden indicado en la lista anterior):

  • codec_prefs_incoming_offer

  • codec_prefs_outgoing_offer

  • codec_prefs_outgoing_answer

  • codec_prefs_incoming_answer

y para cada uno de ellos se podrán configurar las siguientes opciones con sus respectivos valores, separadas por una coma:

  • prefer

  • operation

  • keep

  • transcode

Con la opción prefer será posible indicar si se dará prioridad a la lista de codec presente en el anexo SDP, pending o a la lista de codec presente en la configuración del Endpoint, configurated.

Con la opción operation será posible indicar como de utilizarán los codec presentes en las dos listas indicadas anteriormente (pending o configurated). Con intersect se utilizarán los codec comunes a las dos listas pero aquellos presentes en la opción prefer aparecerán primero; con merge se utilizarán todos los codec presentes en ambas listas pero aquellos presentes en la opción prefer aparecerán primero; preferred se utilizarán solamente los codec presentes en la opción prefer; con nopreferred se utilizarán solamente los codec presentes en la opción prefer.

Con la opción keep se decide que codec se utilizarán de la lista creada con la opción anterior, operation; con all se utilizarán todos los codes de la lista obtenida con la opción operation; con first se utilizará solamente el codec que aparecerá como primero en la lista y se eliminarán todos los demás.

Para terminar con la opción transcoding se indicará si esta operación estará permitida o no. Los posibles valores son: allow, permitido y prevent, evitar.

Como se puede ver por el numero de parámetros y opciones disponibles, se podrán crear todas una serie de escenarios que teóricamente deberían cubrir todas las necesidades de los usuarios; a seguir una configuración de los cuatros parámetros con sus respectivas opciones:

El diagrama de flujo de la nueva negociación de codec seguiría este orden:

  • tipo de canal entre los cuatros disponibles

  • para ese canal se preferirán los codec del anexo SDP o aquellos configurados en el endpoint

  • se utilizarán todos los codec presentes en las dos listas, solamente los codec comunes a las dos listas, solamente los codec presente en la lista preferida o solamente los codec presente en la lista no preferida

  • una vez creada la lista de codec se utilizará solamente el primero de la lista o todos

  • por ultimo se indicará si el transcoding está permitido o hay que evitarlo.

Todavía no se sabe si esta nueva funcionalidad se añadirá también a la versión 16 de Asterisk PBX.

En la próxima entrada, la negociación de Codec en FreeSWITCH

Vota el Articulo: 

Sin votos (todavía)
Evalúa la calidad del articulo
Suscribirse a Comentarios de "Nueva negociación de Codec en la próxima versión 18.2 de Asterisk" Suscribirse a VozToVoice - Todos los comentarios