Resumen

  • Algunas transiciones CAS exigían reacción en decenas de milisegundos. RFC 3064 puso el protocolo de bajo nivel, sus temporizadores y timeouts en la pasarela, mientras el Call Agent conservó el análisis de dígitos y la lógica superior.
  • rel y rlc liberaban el tramo telefónico y devolvían el troncal al inventario, pero no borraban conexiones de red. Para eso hacía falta DLCX y su propio resultado.

El controlador estaba demasiado lejos para cada transición

CAS expresaba toma, respuesta, suspensión y liberación sobre el circuito. Si una acción debía producirse en decenas de milisegundos, enviar cada cambio a un Call Agent remoto convertía la latencia del control en parte de la máquina telefónica.

RFC 3064, publicado en febrero de 2001, repartió la función. La pasarela de medios asumía los detalles CAS y los tiempos que solo podían cumplirse cerca del puerto. El Call Agent intervenía cuando había que interpretar dígitos, escoger destino o crear y modificar conexiones. La rapidez local no equivalía a autoridad sobre toda la llamada.

Los seis paquetes mostraban la variedad escondida detrás de la interfaz: MS para MF CAS básico, DT para DTMF y pulsos, BL para PBX/FXS, DO para FXO, MD para EANA/EAIN de Feature Group D y MO para servicios de operadora. IANA conserva los seis nombres de versión 0. Ese registro acredita nombres, no capacidades de una pasarela concreta ni uso actual.

Abstraer no era borrar la configuración

Un Call Agent podía reutilizar un flujo de llamada aunque un troncal usara wink start y otro immediate start. La pasarela resolvía la diferencia y emitía un evento común de inicio. Sin embargo, el tipo físico seguía aprovisionado fuera de MGCP, y el controlador necesitaba conocer paquete y dirección del troncal.

La RFC mantuvo también la dirección de cada acción. Una signal era una orden del Call Agent a la pasarela; un event era una observación de la pasarela notificada al Call Agent. 200 OK confirmaba la aceptación de una orden. El final del envío de dígitos llegaba después como operation complete. La supervisión de respuesta era otro hecho posterior.

Por eso un acuse correcto no demostraba que la marcación terminara, que contestara el otro extremo, que circulara audio útil o que dos personas hablaran. Los estados marcados con S podían auditarse, pero respondían preguntas estrechas: ¿empezó una llamada? ¿Está libre el tramo telefónico y puede usarse de nuevo? Una foto del estado no reconstruía toda la causa.

El cierre tenía dos superficies

rel significaba abandonar y liberar recursos del tramo telefónico, no simplemente observar un colgado. Podía ser una orden o un evento producido por el extremo remoto o por una condición anormal. rlc indicaba que el troncal ya estaba completamente liberado y disponible.

La especificación separó de forma explícita el otro objeto: rel no implicaba borrar conexiones. Para liberar la llamada completa, incluidas las conexiones de paquetes, el Call Agent tenía que ejecutar DLCX, junto con rel o además de él.

Un troncal libre y una conexión eliminada son hechos diferentes. El circuito puede quedar reutilizable mientras persiste una conexión en la pasarela. La conexión puede borrarse mientras el extremo telefónico aún no termina su liberación. Un sistema de operaciones que use rlc como sustituto de DLCX pierde precisamente el límite que la RFC conservó.

Los fallos lo hacen visible. Si ambos extremos toman a la vez un troncal bidireccional aparece glare. La pasarela podía aplicar una política aprovisionada por DS0 y emitir una liberación anormal. En ese caso rlc completaba el estado de recursos aunque no correspondiera literalmente a un colgado remoto. El evento describía el estado del troncal; no certificaba la intención de un usuario.

La política local era razonable porque la colisión ocurría cerca del circuito y bajo presión temporal. Aun así, el Call Agent tenía que recibir causa y resultado y terminar los demás objetos. Conservar solo el estado final «libre» ocultaría qué toma ganó y si las conexiones de red fueron reclamadas.

RFC 3064 era Informational, no un Internet Standard. La nota del IESG habló de despliegue contemporáneo en varios productos y señaló el trabajo sucesor de Megaco e ITU-T SG16. Las RFC posteriores explican la evolución, no demuestran adopción presente ni cambian retrospectivamente el contrato.

La enseñanza es una disciplina de alcance: ejecutar cerca lo que tiene un plazo corto, decidir globalmente donde existe la vista amplia y exigir un recibo por cada objeto que cambia. La pasarela controlaba los milisegundos. La llamada completa seguía necesitando más de una voz.

Fuentes