hangup cause reason Q850

[Ronney]

l problema que enfrento es el siguiente: mi empresa desea contratar un troncal SIP para ofrecer servicios de PBX en la nube. Mi proveedor de troncales me ha indicado que debo compatibilizar mi sistema (Kazoo) con la tecnología que utilizan, que es un IMS de Huawei. El inconveniente surge al momento de manejar las causas de las llamadas colgadas. El IMS trabaja con ISUP o Q.850, en lugar de utilizar las causas SIP que provocaron la desconexión.

Por ejemplo, cuando se realiza una llamada a un usuario que no responde, el sistema devuelve un 486 USER_BUSY en la causa SIP, pero siempre responde con Reason: Q.850;cause=16;text="NORMAL_CLEARING". Esto se repite en situaciones como llamadas rechazadas, usario no responde o usuarios ocupados. En todos estos casos, el proveedor me ha indicado que, debido a esta inconsistencia, no podian ofrecerme el troncal SIP. Esto se debe a que por ejmplo podia ofrcer un mal servicio a la red telefonica de la pstn `pr ejemplo si un número de la PSTN llama a un troncal asociado a un usuario en Kazoo que está ocupado, el IMS devuelve "NORMAL_CLEARING" (causa 16) en lugar de "USER_BUSY" (causa 17). Como resultado, el número que llama recibe una respuesta que indica que la llamada se ha colgado normalmente, en lugar de un mensaje que informe que el usuario está ocupado.

He intentado resolver esto de manera parcial y me va adar el tronco sip pero fue que lo engañe utilizando una modificación en FreeSWITCH, pero esto ha afectado el funcionamiento general de Kazoo. Modifiqué el archivo ecallmgr_fs_bridge.erl en el código fuente y cambié la función spec pre_exec(kz_term:proplist(), atom(), kz_term:ne_binary(), channel(), kz_json:object()) -> kz_term:proplist(). para establecer continue_on_fail en false pues lo tenia en true y añadí {"application", "set sip_ignore_remote_cause=true"}. Esto hace que, si el puente falla, no continúe el plan de marcado y se ignore la causa remota de la desconexión. Sin embargo, esto ha generado un problema: si el usuario  le activo el buzon de voz  el funcionamiento real deberia ser no hizo el puente continua plan de marcado y llega a su buzon de voz sin embargo como continue_on_fail en false  nunca se llega a la parte del puente, y no llega al buzon de voz. Aclara tambien que si el usuario  no tiene ningun dispositivo registrado siemre siempre devuelve SIP/2.0 480 Temporarily Unavailable con la causa Q.850;cause=16;text="NORMAL_CLEARING".

Cabe mencionar que otros errores, como "no route destination" o "incompatible destination", unallocated: number devuelven correctamente el Reason: Q.850 corres`pondiente

¿Podrías orientarme sobre cómo podría corregir esto para lograr una mejor compatibilidad y que Kazoo funcione adecuadamente? He observado en los logs de Kazoo y FreeSWITCH que el canal se cierra con exec: uuid_kill(UUID) y que, por defecto, esta API de FreeSWITCH siempre finaliza con causa 16 (normal clearing). Sin embargo, sé que si ejecutas exec: uuid_kill UUID, puedes especificar una causa, como 17, para cerrar el canal. No estoy seguro de cómo implementar esta opción y en qué parte podría mapear la causa para finalizar la llamada con la causa correcta.

Agradezco de antemano cualquier orientación que puedas brindarme