Problema con negociación de codecs entre 2 centralitas Asterisk
243 views
Skip to first unread message
Miguel Alberto Sanz Pardo
Nov 17, 2017, 1:31:45 PM11/17/17
to asterisk-es
Hola buenas tardes,
Dispongo de un cliente contra el que tengo un trunk definido de esta manera desde mi Asterisk:
[trunk-to-client]
type=friend
host=dynamic
disallow=all
allow=g729
allow=alaw
...
Supuestamente el cliente tiene definido otro trunk de la misma manera
[trunk_to_provider]
type=friend
host=ip_proveedor
disallow=all
allow=g729
allow=alaw
...
Además dispone de un register --> ... para poder recibir llamadas entrantes
El caso es que la centralita de mi cliente no parece estar negociando de manera correcta el codec de audio que va a ser usado, ya que ocurre algo de este estilo:
1)Cuando hay una llamada entrante desde el DID del cliente en el INVITE(SIP/SDP) que se envía desde nuestra centralita se ofrece la posibilidad de usar en primera instancia el codec g729 y en segunda instancia el codec g711a.
2)Una vez se ha enviado el INVITE(SIP/SDP) la centralita del cliente responde con un 100 Triying y a continuación manda un 200 OK(SIP/SDP) en el cual tras negociar acepta el uso del codec g729.
3)Tras esto nuestra centralita envía un ACK y se establece la comunicación con la centralita del cliente.
4)Una vez establecida la comunicación la centralita del cliente comienza a enviar tráfico de voz (RTP) usando el codec g711a en vez de enviarlo en g729 tal y como se supone que se había acordado en el 200OK y nuestra centralita envía tráfico de voz (RTP) usando el codec g729, tal y como se había acordado.
¿Alguna idea de por qué pude estar ocurriendo esto cuando en principio se ha negociado por ambos lados que se va a usar el codec g729?
NOTA:
Si se trata de forzar el codec g729 en la pata del cliente (disallow=all, allow=g729) el problema persiste ya que en la pata del cliente se sigue usando el codec alaw al mandar tráfico RTP(¿?¿?) y en la mia se usa g729; lo cual no le veo que tenga mucho sentido. No tengo acceso a la centralita del cliente, por lo cual no puedo ver si realmente está usando esa config (disallow=all, allow=g729)
Si se fuerza el codec alaw en la pata del cliente el problema desaparece pero se envía el tráfico RTP usando el codec alaw en ambas patas.
Si se fuerza el codec g729 en ambas patas el problema desaparece y se envía tráfico RTP usando el codec g729 en ambas patas.
Os adjunto 3 capturas de pantalla con la traza que he capturado cuando aparecía el problema. ¿Alguna idea de qué puede estar pasando?
Dispongo de un cliente contra el que tengo un trunk definido de esta manera desde mi Asterisk:
[trunk-to-client]
type=friend
host=dynamic
disallow=all
allow=g729
allow=alaw
...
Supuestamente el cliente tiene definido otro trunk de la misma manera
[trunk_to_provider]
type=friend
host=ip_proveedor
disallow=all
allow=g729
allow=alaw
...
Además dispone de un register --> ... para poder recibir llamadas entrantes
El caso es que la centralita de mi cliente no parece estar negociando de manera correcta el codec de audio que va a ser usado, ya que ocurre algo de este estilo:
1)Cuando hay una llamada entrante desde el DID del cliente en el INVITE(SIP/SDP) que se envía desde nuestra centralita se ofrece la posibilidad de usar en primera instancia el codec g729 y en segunda instancia el codec g711a.
2)Una vez se ha enviado el INVITE(SIP/SDP) la centralita del cliente responde con un 100 Triying y a continuación manda un 200 OK(SIP/SDP) en el cual tras negociar acepta el uso del codec g729.
3)Tras esto nuestra centralita envía un ACK y se establece la comunicación con la centralita del cliente.
4)Una vez establecida la comunicación la centralita del cliente comienza a enviar tráfico de voz (RTP) usando el codec g711a en vez de enviarlo en g729 tal y como se supone que se había acordado en el 200OK y nuestra centralita envía tráfico de voz (RTP) usando el codec g729, tal y como se había acordado.
¿Alguna idea de por qué pude estar ocurriendo esto cuando en principio se ha negociado por ambos lados que se va a usar el codec g729?
NOTA:
Si se trata de forzar el codec g729 en la pata del cliente (disallow=all, allow=g729) el problema persiste ya que en la pata del cliente se sigue usando el codec alaw al mandar tráfico RTP(¿?¿?) y en la mia se usa g729; lo cual no le veo que tenga mucho sentido. No tengo acceso a la centralita del cliente, por lo cual no puedo ver si realmente está usando esa config (disallow=all, allow=g729)
Si se fuerza el codec alaw en la pata del cliente el problema desaparece pero se envía el tráfico RTP usando el codec alaw en ambas patas.
Si se fuerza el codec g729 en ambas patas el problema desaparece y se envía tráfico RTP usando el codec g729 en ambas patas.
Os adjunto 3 capturas de pantalla con la traza que he capturado cuando aparecía el problema. ¿Alguna idea de qué puede estar pasando?
Fernando Villares
Nov 17, 2017, 1:42:31 PM11/17/17
to aster...@googlegroups.com
Y si el cliente pone g729 y no tiene el códec en los módulos .so?
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
Miguel Alberto Sanz Pardo
Nov 18, 2017, 6:06:39 AM11/18/17
to asterisk-es
Hola Fernando,
El caso es que si tanto el cliente como yo forzamos el uso del codec g729 (disallow=all, allow=g729 en ambos trunks) la comunicación se establece y se envían paquetes RTP con g729 en ambos sentidos.
Si el cliente no tuviera cargado el codec en los módulos de asterisk (codec_g729.so) entiendo que tampoco debería de haber funcionado esa prueba.
El caso es que si tanto el cliente como yo forzamos el uso del codec g729 (disallow=all, allow=g729 en ambos trunks) la comunicación se establece y se envían paquetes RTP con g729 en ambos sentidos.
Si el cliente no tuviera cargado el codec en los módulos de asterisk (codec_g729.so) entiendo que tampoco debería de haber funcionado esa prueba.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Fernando Villares
Nov 18, 2017, 8:22:46 AM11/18/17
to aster...@googlegroups.com
Ok.. y las versiones de asterisk...será q el cliente está mintiendo un poquito en algo?
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es+unsubscribe@googlegroups.com.
Raúl Alexis Betancor Santana
Nov 19, 2017, 12:05:21 PM11/19/17
to aster...@googlegroups.com
Intuyo, me da en la napia ..., atufa a ... que el cliente tiene una versión de Asterisk < 1.8 ... todas ellas tenían el mismo fallo de negociación de codecs, te negocia un codec para el trunk ... y cuando negocia la pata para el terminal, si tiene otro 'order' de preferencia ... la casca la pata del trunk.
Se solventa poniendo EXACTAMENTE el mismo orden de codecs en el trunk, que en las extensiones. O actualizando a un Asterisk más moderno.
Sir Brain Colward
Nov 19, 2017, 12:08:39 PM11/19/17
to asterisk-es
O más bien suena a que a su vez el teléfono del cliente en su centralita tiene ambos códecs, pero en orden inverso:
disallow=all
allow=alaw
allow=g729
Y entonces sí, Asterisk hace su "magia" y la pifia de mala manera...
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.
--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)
Normas de la lista Asterisk-ES: http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es+unsubscribe@googlegroups.com.
Miguel Alberto Sanz Pardo
Nov 19, 2017, 5:06:44 PM11/19/17
to asterisk-es
Hola compañeros,
Muchas gracias por vuestras respuestas, pues según las trazas capturadas:
- Mi centralita usa: Asterisk: 1.8.28 cert.5
- La centralita del cliente usa: Asterisk 13.1-cert.2
Todo es posible Fernando, mientras no pueda ver la config. no puedo saber si el cliente me está dando datos erróneos o no :(
Umh, pues según vuestros comentarios y según las pruebas que he ido realizando, tiene toda la pinta que está ocurriendo lo que comentais ambos: Raúl y Cesar, que el cliente tiene el orden de los codecs cambiados en la definición de la extensión con respecto a la definición del trunk.
Lo compruebo en cuanto pueda y os confirmo.
un saludo y gracias por vuestros comentarios
Muchas gracias por vuestras respuestas, pues según las trazas capturadas:
- Mi centralita usa: Asterisk: 1.8.28 cert.5
- La centralita del cliente usa: Asterisk 13.1-cert.2
Todo es posible Fernando, mientras no pueda ver la config. no puedo saber si el cliente me está dando datos erróneos o no :(
Umh, pues según vuestros comentarios y según las pruebas que he ido realizando, tiene toda la pinta que está ocurriendo lo que comentais ambos: Raúl y Cesar, que el cliente tiene el orden de los codecs cambiados en la definición de la extensión con respecto a la definición del trunk.
Lo compruebo en cuanto pueda y os confirmo.
un saludo y gracias por vuestros comentarios
Raúl Alexis Betancor Santana
Nov 21, 2017, 2:08:53 PM11/21/17
to aster...@googlegroups.com
Puede funcionar aunque no esten cargados los codecs ... recuerda que existe el codec_passthrought ... osea ... que Asterisk no toca el tráfico RTP, solo hace de proxy RTP, y había un famoso bug, que en función de los valores de canreinvite y directmedia y toda la pesca ... asterisk negociaba un codec con el trunk, otro codec con el terminal, hacía de proxy RTP, cuando tendría que hacer transcoding.
De: "miguelsanzpardo" <miguels...@gmail.com>
Para: "asterisk-es" <aster...@googlegroups.com>
Enviados: Sábado, 18 de Noviembre 2017 11:06:39
Asunto: Re: [Asterisk-ES] Problema con negociación de codecs entre 2 centralitas Asterisk
Hola Fernando,
Reply all
Reply to author
Forward
0 new messages