ES2468244T3 - Conmutador de telecomunicaciones VOIP - Google Patents

Conmutador de telecomunicaciones VOIP Download PDF

Info

Publication number
ES2468244T3
ES2468244T3 ES07841058.6T ES07841058T ES2468244T3 ES 2468244 T3 ES2468244 T3 ES 2468244T3 ES 07841058 T ES07841058 T ES 07841058T ES 2468244 T3 ES2468244 T3 ES 2468244T3
Authority
ES
Spain
Prior art keywords
port
state
class
state machine
finite state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES07841058.6T
Other languages
English (en)
Inventor
James W. Delmege
Paul A. Reynolds
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Redcom Laboratories Inc
Original Assignee
Redcom Laboratories Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Redcom Laboratories Inc filed Critical Redcom Laboratories Inc
Application granted granted Critical
Publication of ES2468244T3 publication Critical patent/ES2468244T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1046Call controllers; Call servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1053IP private branch exchange [PBX] functionality entities or arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/12Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034A/D conversion, code compression/expansion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1305Software aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389LAN, internet

Abstract

Un aparato para gestionar llamadas en un sistema de telefonía (5, 60, 40) usando una red IP (40), comprendiendo el aparato: al menos un controlador (10) configurado para establecer una conexión de comunicación entre: - un puerto de acceso conmutado (20) configurado para conectarse a un teléfono de acceso conmutado (21) respectivo; y - un puerto de VoIP; estando categorizada la conexión de comunicación en: - estados de llamada principales que incluyen: "espera", "marcando" y "llamando"; - estados de puerto de acceso conmutado asociados a la condición del puerto (20) de acceso conmutado; ejecutando dicho al menos un controlador (10) la primera y la segunda máquinas de estado finito, - modelando la primera máquina de estado finito (24) el comportamiento de los puertos de acceso conmutado (20) y organizados con: - un conjunto de clases de estado de puerto (70, 71), estando asociada cada clase de estado de puerto (70, 71) a un estado de llamada principal, - para cada clase de estado de puerto (70, 71), un número finito de estados discretos (72, 72a, 73), estando asociado cada estado discreto (72, 72a, 73) a un estado de puerto de acceso conmutado; - modelando la segunda máquina de estado finito (14) el comportamiento del puerto VoIP y organizada con el mismo conjunto de clases de estado de puerto (70, 71) que la primera máquina de estado finito (24) y sin estados discretos (72, 72a, 73, 73a); estando programado dicho al menos un controlador (10) con rutinas de transición (720, 740) configuradas: - mediante la ejecución de la primera máquina de estado finito (24): - para pasar el puerto de acceso conmutado (20) de un estado discreto (72, 72a) a otro estado discreto (72, 73a) en la misma clase de estado de puerto (70) o en una clase de estado de puerto (71) diferente; y - para generar mensajes (34) a usarse para la ejecución de la segunda máquina de estado finito (14) representativos de las transiciones (740) entre diferentes estados discretos (72a, 73a) en diferentes clases de estado de puerto (70, 71); - sin generar mensajes a usarse para la ejecución de la segunda máquina de estado finito (14) representativos de transiciones (720) entre diferentes estados discretos (72) en la misma clase de estado de puerto de la primera máquina de estado finito (24); - mediante la ejecución de la segunda máquina de estado finito (14), para pasar el puerto de VoIP de una clase de estado de puerto (70, 71) a otra clase de estado de puerto (70, 71) en respuesta a mensajes (34) generados mediante la ejecución de la primera máquina de estado finito (24).

Description

Conmutador de telecomunicaciones VOIP
Referencia cruzada a solicitudes relacionadas
Se hace referencia a y se reivindica la prioridad de la Solicitud Provisional de Patente de Estados Unidos con N� de Serie 60/838.208, presentada el 17 de Agosto de 2006.
Campo de la invención
La invención se refiere al procesamiento de llamadas telefónicas, y más específicamente al procesamiento de llamadas telefónicas a través de internet usando la tecnología y convenciones de VoIP (Voz sobre el Protocolo de Internet).
Antecedentes de la invención
Cualquier llamada telefónica progresa a través de una serie de etapas desde el principio hasta el final. Cada etapa se identifica con un estado o condición de la llamada, y el progreso de una etapa a la próxima en una llamada se denomina una transición. Por ejemplo, un abonado coge un microtel�fono del teléfono para realizar una llamada, y la llamada cambia de un estado de reposo a un estado de invitación a marcar (‘tono’). Cuando el abonado comienza a marcar o presionar un número, la llamada cambia del estado de tono un estado de marcación (’marcado’). Cuando la red de conmutación localiza a la línea llamada y comienza a enviar señales de llamada para el teléfono receptor, el estado de llamada cambia de ’marcado’ a ’llamando’. Este proceso continúa hasta que se finaliza la llamada y el estado vuelve a ‘reposo’. Estos cambios de estado a estado son las transiciones del estado de la llamada.
En tecnologías de procesamiento de llamada convencional, toda la inteligencia del sistema para procesar llamadas telefónicas ha residido en el elemento de conmutación central, por ejemplo, el Intercambio de Alta Densidad (HDX), una versión de alta densidad del sistema cubierto originalmente en la Patente de Estados Unidos N� 4.228.536, y en lo sucesivo denominada como la “patente ’536”. Los instrumentos de punto final en procesamiento de llamada convencional se han ‘atontado’, es decir, no contienen ningún elemento de procesamiento de llamada.
Los elementos de conmutación central en procesamiento de llamada convencional no est�n restringidos a únicos componentes físicos. Por ejemplo, en sistemas que usan la arquitectura Periférico de Conmutación Modular (MSP), también conocida en la industria como la Integración de Informática/Telefonía, o CTI, el MSP junto con el ordenador anfitrión constituyen el elemento de conmutación central. Aunque los teléfonos de ISDN (Red Digital de Servicios Integrados) tienen alguna inteligencia, el control de llamada reside todavía casi exclusivamente en el elemento de conmutación central.
VoIP transforma la arquitectura de conmutación convencional. Simplemente comprando algunos teléfonos de VoIP y conect�ndolos a una LAN Ethernet existente, un proveedor puede construir una red de telefonía de VoIP básica. El proveedor puede configurar los teléfonos manualmente o a través de una interfaz basada en Web sencilla. Como resultado, el proveedor puede suministrar un sistema de teléfono privado sin ningún software o hardware especial en cualquier lugar en la red, de modo que los teléfonos pueden marcar, llamar y hablar entre s�. En una arquitectura de este tipo, los teléfonos contienen toda la inteligencia necesaria para hacer que la red de VoIP funcione.
A medida que el sistema VoIP aumenta en tamaño, consigue ventajas de la reintroducci�n de un elemento de conmutación central para facilitar la administración de sistema y provisión de ciertas características. Pero a diferencia de llevarlo a la práctica en redes de telefonía convencionales, el elemento de conmutación central reintroducido, a menudo llamado Gestor de Llamada o LCC (Controlador de Llamada Local), funciona con los teléfonos de VoIP principalmente a un nivel punto a punto.
Integrar un sistema de VoIP con un sistema maduro, complejo y rico en características que utiliza procesamiento de llamada centralizado, tal como la plataforma HDX, presenta desafíos únicos. Conseguir integrar la lógica de procesamiento de llamada centralizada existente con el procesamiento de llamada de VoIP descentralizado hace el control de una llamada un problema entre el elemento de conmutación central y el propio teléfono.
El procesamiento de llamada se implementa usando una máquina de estado finito (FSM), una estructura de diseño bien conocida en la técnica, en la que una llamada est� siempre en uno de un número finito de estados discretos (por ejemplo, Marcando, Llamando, Hablando y otros), y un evento que ocurre en el sistema puede desencadenar una acción para producir que la llamada progrese de un estado a otro.
La FSM del procesamiento de llamada de HDX, también denominado Procesamiento de Evento de Puerto (PEP), actualmente tiene cientos de estados de llamada y miles de componentes de software usados para procesar los eventos que ocurren en cada uno de esos estados. La integración de VoIP con el HDX requeriría, bajo la aplicación del experto en la materia, que un fabricante de sistemas rehiciera la mayoría de los componentes de software que
comprenden la FSM (PEP).
La manera convencional para implementar una nueva característica en un procesamiento de llamada FSM es comenzar examinando cuidadosamente todos y cada uno de los estados de llamada, eventos y rutinas de transición. La “rutina de transición” es el nombre para el código real que se ejecuta cuando se recibe un evento dado para un puerto en un estado dado. Una rutina de transición realiza alguna acción apropiada para el evento y el estado actual, y su acción puede incluir una transición a un estado diferente.
La siguiente etapa en la implementación de característica convencional es el diseño e implementación de código para una o más rutinas de transición existentes, y posiblemente la adición de nuevos estados y eventos asimismo, junto con nuevas rutinas de transición para procesar los nuevos estados y eventos. Cada transición de estado en la FSM representa exposición añadida a errores de programación de software potenciales cada vez que se realiza una modificación incorrecta en el soporte de la nueva característica, o cada vez que un cambio requerido se pasa por alto erróneamente. El gran número de transiciones de estado por lo tanto hace a la implementación de la característica en la manera convencional una tarea altamente propensa a errores, elevando sus costes considerablemente. Evitar tal rehacimiento extensivo de software sería altamente ventajoso.
Adicionalmente, la integración PEP/HDX, hecha apropiadamente, ofrecería a los proveedores una ruta sin problemas, clara entre sistemas de procesamiento de llamada convencional potentes, bien establecidos pero menos flexibles y los sistemas de VoIP altamente flexibles que ofrecen todo el potencial de internet. Abriendo una ruta de este tipo concedería a los proveedores de sistemas de telefonía claras ventajas sobre la tecnología en solitario.
El documento US 6.363.424 B1 desvela un sistema en el que cada transición de software heredado de un estado a otro estado en un teléfono heredado debería realizarse un acuse de recibo mediante el cambio correspondiente en un módulo VoIP o de lo contrario. Se generan estados artificiales o ficticios en el software de VoIP para reflejar cada cambio de estado en el software heredado.
El documento WO 02/28047 A2 desvela un método para convertir protocolos de se�alizaci�n en un servidor de llamada genérico. Se desvela también una máquina de estado de control de llamada genérica.
El documento US 6.996.076 B1 desvela un sistema para redes de telecomunicación inalámbricas.
Sumario
La invención se define en las reivindicaciones independientes.
Puesto que la norma del Protocolo de Iniciación de Sesión (SIP) para el Protocolo de voz sobre Internet (VoIP) únicamente distingue estados de llamada principales, su máquina de estado finito (FSM) es relativamente sencilla. Por el contrario, el procesamiento de llamada convencional de FSM distingue hasta cientos de estados distintos para cualquier llamada. La presente invención aprovecha la clasificación apropiada de estados de procesamiento de llamada convencional en categorías correspondiendo cada una a los estados de llamada principales tales como “reposo”, “marcando”, “llamando” y “hablando”. Estos estados de llamada principales son similares pero no idénticos a los estados de llamada de la FSM de SIP. La invención proporciona una FSM separada para los estados de llamada categorizados para SIP, que se ejecutan en paralelo con una FSM de procesamiento de evento de puerto convencional (PEP) e implementa un LCC de VoIP pasando eventos entre la FSM de tipo SIP y la FSM de PEP únicamente en los puntos donde ocurre una transición entre categorías de estado de llamada principal.
Usando la invención, la FSM de SIP no requiere notificación de transiciones de la FSM de PEP que no afectan al estado de llamada de SIP. De manera similar, la FSM de PEP no requiere notificación de transiciones de la FSM de SIP que no afecten al estado de llamada de la FSM de PEP. Las transiciones entre estados principales ocurren mucho menos frecuentemente que las transiciones entre estados de la FSM de PEP en la misma categoría de estado de llamada principal como se clasifica mediante la invención. Por esta razón, ninguno de los códigos asociados a las transiciones entre estados de la FSM de PEP en la misma categoría de estado de llamada principal requiere ninguna modificación. En consecuencia la integración del procesamiento de llamada de VoIP y PEP puede hacerse usando la presente invención de manera más sencilla, y en costes reducidos espectacularmente en desarrollo, soporte y mantenimiento de software.
La invención permite conseguir un aparato para gestionar llamadas en un sistema de telefonía que tiene teléfonos de acceso conmutado y teléfonos de voz sobre internet (VoIP) que comprende: un controlador con una pluralidad de puertos, dichos puertos acoplados a los teléfonos de acceso conmutado y acoplados a una red de teléfonos VoIP, ejecutando dicho controlador la primera y segunda máquinas de estado finito, la primera máquina de estado finito para procesar todas las llamadas y organizada con un conjunto de clases de estado de puerto, estando asociada cada clase de estado de puerto a uno o más estados para cada estado principal, modelando la segunda máquina de estado finito el comportamiento de los puertos de VoIP y organizada con las mismas clases de estado de puerto que la primera máquina de estado finito; planificando el software de modo que un cambio en una clase de un teléfono modelado mediante una máquina se usa para la ejecución de la máquina de estado finito que modela el
comportamiento del otro teléfono. El controlador puede tener una o más unidades de interfaz de puerto, cada unidad de interfaz de puerto controlada mediante el controlador y conectada a líneas de abonado digitales o analógicas convencionales para controlar llamadas telefónicas a o desde una línea de abonado convencional. El controlador puede tener uno o más puertos de protocolo de internet para conectar a una red de infraestructura de internet. El controlador puede registrar uno o más teléfonos IP en la infraestructura IP para recibir mensajes periódicos desde los teléfonos IP para establecer de esta manera conexiones de comunicación lógica entre los teléfonos conectados a
o registrados con el controlador y los teléfonos IP mediante la infraestructura IP identificando y autenticando los teléfonos IP registrados. El controlador puede ejecutar transiciones de clase para todos los teléfonos y todas las transiciones de estado para los teléfonos convencionales.
Una unidad de conmutación modular para interconexión a otras unidades de conmutación modulares similares para proporcionar servicio de telefonía usando el protocolo de voz sobre internet (IP) y protocolos de telefonía digitales y analógicos convencionales puede comprender:
-
un controlador que comprende un procesador, memoria, sistema operativo y uno o más programas de aplicación que incluyen programas de máquina de estado;
-
una o más unidades de interfaz de puerto, cada unidad de interfaz de puerto controlada mediante el controlador y conectada a líneas de abonado digitales o analógicas convencionales para controlar llamadas telefónicas a o desde una línea de abonado convencional;
-uno o más puertos IP para conectar a una red de infraestructura de protocolo de internet; -una o más pasarelas de medios para conectar las unidades de interfaz de puerto al controlador; -ejecutando adicionalmente dicho controlador un primer programa de software de estado finito para procesar
clase de estado de puerto y transiciones de estado a y desde líneas de abonado convencionales conectadas a las interfaces de puerto y para ejecutar transiciones de clase a y desde teléfonos acoplados lógicamente a los puertos IP,
-
un segundo programa de software de estado finito para rastrear transiciones de clase en teléfonos IP conectados a los puertos IP, y -un programa de software de planificación para planificar y coordinar transiciones de clase entre teléfonos convencionales y teléfonos IP.
Un aparato para procesar llamadas entre teléfonos de protocolo de voz sobre internet (IP) y teléfonos de acceso conmutado convencionales puede comprender:
-
medios para conectar uno o más teléfonos de acceso conmutado convencionales a una unidad de conmutación
modular con un controlador para controlar comunicaciones a y desde los teléfonos convencionales; -medios para conectar el controlador a una infraestructura IP; -medios para registrar uno o más teléfonos IP en la infraestructura IP con el controlador; -medios para recibir mensajes periódicos desde los teléfonos IP en el controlador para establecer conexiones de
comunicaci�n lógica entre los teléfonos conectados a o registrados con el controlador y los teléfonos IP mediante la infraestructura IP identificando y autenticando los teléfonos IP registrados; -estableciendo dicho controlador una conexión de comunicación lógica entre un teléfono convencional y un teléfono IP; -ejecutando dicho controlador una primera máquina de estado finito para procesar todas las llamadas, estando organizada dicha primera máquina de estado finito con clases de estado de puerto para todos los teléfonos y uno
o más estados para teléfonos convencionales; -ejecutando dicho controlador una segunda máquina de estado finito para rastrear cambios de estado de teléfonos IP;
-
teniendo dicho controlador un programa planificador para enviar un mensaje generado mediante la ejecución de una máquina de estado finito a usarse para la ejecución de la otra máquina de estado finito cuando el teléfono IP
o el teléfono convencional cambia de estado;
-
y procesando dicho controlador la llamada entre los dos teléfonos haciendo funcionar las máquinas de estado finito de acuerdo con transiciones entre estados de todos los teléfonos.
El controlador puede ejecutar transiciones entre estados de dichos teléfonos convencionales. Un sistema de telecomunicaciones de conmutación para proporcionar servicio de telefonía usando tanto el protocolo de voz sobre internet como los protocolos de telefonía digital y analógica convencionales comprende:
-
una o más unidades de conmutación modulares para interconectar líneas de abonado telefónicas; -una o más unidades de interfaz de puerto, cada una para conectar una o más líneas de abonado digitales o analógicas convencionales cada una a una unidad de conmutación modular; -uno o más sistemas inform�ticos de unidad de controlador para conectar una o más líneas de voz sobre internet cada una a una unidad de conmutación modular; -una o más pasarelas de medios para conectar las unidades de interfaz de puerto a los sistemas inform�ticos de unidad de controlador; -una o más redes de telecomunicaciones digitales, usando cada una un conjunto de protocolos de internet, conectadas al ordenador de la unidad del controlador;
-
uno o más teléfonos de protocolo de internet, cada uno conectado a una o más de las redes de telecomunicaciones digitales;
-
uno o más teléfonos digitales o analógicos convencionales, cada uno conectado a una red de telefonía convencional;
-
un primer programa de software de estado finito para procesar transiciones de clase de llamada en llamadas telefónicas que implican teléfonos digitales o analógicos convencionales o internet
-
tel�fonos de protocolo y procesar transiciones de estado de llamada en teléfonos digitales o analógicos convencionales;
-
un segundo programa de software de estado finito para procesar transiciones de clase de llamada en el Protocolo de Internet asociado a dichos teléfonos de protocolo de internet;
-
un programa de software de planificación para planificar y coordinar el primer y segundo programas de software de estado finito basándose en las transiciones de estado de llamada en cada llamada telefónica;
-
una instancia del primer programa de software de estado finito que funciona en cada sistema inform�tico de unidad de controlador para procesar todas las clases de estado de puerto y transiciones de estado;
-
una instancia del segundo programa de software de estado finito que funciona en cada sistema inform�tico de unidad de controlador;
-
y una instancia del programa de software de planificación que funciona en cada sistema inform�tico de unidad de controlador.
El programa de software de planificación puede comprender adicionalmente:
-
un componente de software para detectar todas las transiciones de clase de llamada;
-
un componente de software para detectar transiciones de estado de llamada que requieren el uso del programa de software de primer estado;
-
un componente de software para invocar el primer programa de software de estado finito;
-
y un componente de software para invocar el segundo programa de software de estado finito,
Un método para procesar llamadas telefónicas que implican teléfonos de voz sobre internet y teléfonos convencionales comprende las etapas de:
-
clasificar las transiciones de estado de llamada para llamadas telefónicas convencionales en transiciones de estado que alteran el estado de llamada de una llamada telefónica y transiciones de estado que no alteran el estado de llamada de una llamada telefónica;
-
implementar un primer programa de software de estado finito para transiciones de estado para todas las llamadas y para implementar transiciones de estado para llamadas convencionales;
-
hacer funcionar el primer programa de software de estado finito para controlar y procesar todas las llamadas incluyendo procesar todos los estados y cambios de estado en teléfonos convencionales y cambios de estado en teléfonos de voz sobre internet;
-
implementar un segundo programa de software de estado finito para rastrear cambios de estado de llamadas que se conectan a una línea de abonado convencional con un teléfono de voz sobre internet;
-
intercambiar mensajes entre los dos programas de software de estado finito cuando el teléfono pasa de una clase de estado de puerto a otra clase de estado de puerto.
En este método, la etapa de procesar cualquier llamada telefónica que implica tanto teléfonos de voz sobre internet como teléfonos convencionales usando el primer y segundo programas de software de estado finito puede comprender adicionalmente las etapas de:
-
recibir un evento de llamada;
-
almacenar el estado actual del puerto de la llamada como una clase de estado de puerto de comienzo;
-
procesar el evento de llamada usando el primer programa de software de estado finito;
-
almacenar el estado actual del puerto de la llamada como una clase de estado de puerto final;
-
comparar la clase de estado del puerto de comienzo con la clase de estado del puerto final;
-
y únicamente cuando la clase de estado de puerto de comienzo no es la misma que la clase de estado de puerto final, publicar un evento para el segundo programa de software de estado finito.
Un método para procesar llamadas entre teléfonos de protocolo de voz sobre internet (IP) y teléfonos de acceso conmutado convencionales comprende:
-
conectar uno o más teléfonos de acceso conmutado a una unidad de conmutación modular con un controlador para controlar comunicaciones a y desde los teléfonos convencionales;
-
conectar el controlador a una infraestructura IP;
-
registrar uno o más teléfonos IP en la infraestructura IP con el controlador;
-
recibir mensajes periódicos desde los teléfonos IP en el controlador para establecer conexiones de comunicación lógica entre los teléfonos conectados a o registrados con el controlador y los teléfonos IP mediante la infraestructura IP identificando y autenticando los teléfonos IP registrados;
-
ejecutar una primera máquina de estado finito en el controlador para procesar todas las llamadas, estando
organizada dicha primera máquina de estado finito con un grupo de clases de estado de puerto para todas las
llamadas y grupo de estados que no alteran el estado de teléfonos convencionales; -ejecutar una segunda máquina de estado finito en el controlador para rastrear estado de puerto de transiciones
de estado de teléfonos IP que corresponden a las transiciones de estado de los teléfonos convencionales; -enviar un mensaje generado mediante la ejecución de una máquina estado finito a usarse por la ejecución de la
otra máquina de estado finito cuando el teléfono cambia un estado; -y ejecutar transiciones entre dichas clases de estado de puerto y estados para dichos teléfonos convencionales y
ejecutar transiciones entre clases cuando un teléfono convencional est� conectado lógicamente a un teléfono IP.
Breve descripción de los dibujos
La Figura 1 es un diagrama de bloques global de la realización preferida que muestra un sistema con varios estantes y un número de teléfonos analógicos e IP conectados.
La Figura 2 es una vista ampliada de una única MSU que muestra los elementos de software más destacados.
La Figura 3 muestra la agrupación de estados de puerto en clases separadas.
La Figura 4 es un diagrama de flujo de la lógica de la invención requerida para manejar una transición de estado de puerto.
La Figura 5 es una vista global de la máquina de estado finito de PEP.
La Figura 6 es una vista global de la máquina de estado finito de SIP.
Descripci�n detallada de la invención
La Figura 1 muestra una pluralidad de Unidades 5 de Conmutación Modular (MSU). La presente invención funciona con una MSU en configuraciones más pequeñas, y múltiples MSU en configuraciones más grandes. La MSU 5 funciona en general como se desvela en la patente ‘536, pero como se adapta para la presente invención las capacidades de capacidad de puerto y procesador de control (Controlador) se han mejorado significativamente. El Controlador 10 en la Figura 1 corresponde con la función MPU en la patente a continuación ‘536.
En la Figura 1, las líneas analógicas 15 se muestran conectadas a las interfaces de puerto multiplexado por división en el tiempo (TDM) 20. En el caso de líneas analógicas las interfaces de puerto 20 TDM corresponden a los circuitos de línea de la patente ‘536. Cada conexión de línea analógica es una conexión física de los dos conductores necesarios para un circuito telefónico analógico, denominado comúnmente como los conductores de ‘punta’ y ‘anillo’.
Tambi�n en la Figura 1, los teléfonos de protocolo de internet (IP) 30 se muestran conectados 35, 36, 37 a los diversos Controladores 10. En el caso de los teléfonos IP 30, no existe conexión física individual entre los diversos teléfonos IP 30 y los Controladores 10. En su lugar, existe una única conexión física que se extiende desde cada teléfono 30 y desde cada Controlador 10 a una infraestructura de enrutamiento IP tal como una red 40 de área local (LAN). Cada línea 35, 36, 37 mostrada en la Figura 1 que conecta un teléfono IP 30 con un controlador 10 indica una asociación lógica.
Cada teléfono IP 30 tiene a priori la dirección IP de un Controlador 10 específico al cual dirige periódicamente un mensaje SIP REGISTRO (REGISTER). Por medio de este mensaje REGISTRO (REGISTER) el controlador 10 puede identificar, autenticar y comunicarse con el teléfono IP 30, de modo que la conexión lógica equivale a una conexión física en cuanto a comunicación de mensajes SIP se refiere. El protocolo SIP es una norma expedida por el Grupo de Trabajo de Ingeniería de Internet (IETF) y se define en el documento Petición de Comentarios (RFC) 3261 del IETF. La infraestructura de enrutamiento IP es bien conocida en la técnica, y comprende el hardware y software de red, incluyendo enrutadores, concentradores y pasarelas y sus programas de soporte, necesarios para comunicación usando protocolos de internet. En la Figura 1, la infraestructura de enrutamiento IP comprende una red de área local que usa el protocolo Ethernet.
La presente invención conserva el soporte de llamadas que se originan en un teléfono IP y que terminan en un teléfono analógico, o que se originan en un teléfono analógico y que terminan en un teléfono IP. Tal soporte de llamada se proporciona mediante los Servidores de Medios 50 mostrados en la Figura 1. Los Servidores de Medios 50 se controlan mediante el Controlador 10 MSU de la misma manera que se controla cualquier otro circuito de puerto.
Los Servidores de Medios (también denominados pasarelas de Medios) realmente parecen otro tipo de interfaz de puerto, y se conectan directamente al sistema inform�tico de la unidad de controlador, al igual que otras interfaces de puerto. Las conexiones lógicas 35, 36, 37 existen entre teléfonos de VoIP 30 y controladores 10. Cuando una llamada est� en marcha NO requiere conversión de IP a TDM, no es necesaria interfaz de puerto. Pero cuando una llamada est� en marcha que implica tanto a un teléfono de VoIP 30 como un teléfono 21 analógico o digital
conectado a una interfaz de puerto 20, entonces existir� una conexión lógica adicional desde el teléfono de VoIP 30 a través de la red IP 40 a uno de los Servidores de Medios o pasarelas 50. Esta segunda conexión lógica maneja el Protocolo de Tiempo Real (los datos de voz reales) para la llamada, y el Servidor de Medios actúa como una interfaz de puerto en este caso.
Aunque no se muestra en la Figura 1, pueden también aparecer otros circuitos del tipo general desvelados en la patente ‘536 en la red mostrada.
La asociación o asignación de un teléfono IP a un Controlador específico es arbitraria y no limita de ninguna manera las capacidades del sistema. El objetivo principal es distribuir los teléfonos IP tan uniformemente como sea posible entre los Controladores para reducir el impacto de una interrupción del servicio resultante de la pérdida de una MSU.
La Figura 2 representa los elementos de software más destacados del Controlador. El Planificador de Sistema 12 dirige el procesador del controlador para ejecutar el proceso 14 de la FSM de SIP (SIPFSM) cuando se requiera, y el proceso 24 de la FSM de PEP (PEPFSM) cuando se requiera. La aparición de un evento que altera una o más condiciones que requieren procesamiento mediante una FSM específica produce que se planifique la FSM para ejecución.
La SIPFSM 14 recibe eventos de llamada desde las capas 15, 16 de UP y TCP del protocolo de internet. Dichos eventos representan principalmente mensajes SIP recibidos desde teléfonos IP 30 asociados al Controlador con el que se ha registrado el teléfono IP. La SLPFSM 14 también recibe eventos desde una segunda fuente, la PEPFSM 24, mediante la conexión 34 mostrada en la Figura 2. Finamente, la SIPFSM 14 recibe eventos desde una tercera fuente, los temporizadores en la propia SIPFSM, que marcan los finales de los intervalos de tiempo, o retardos.
De manera similar, la PEPFSM 24 recibe eventos desde la capa 25 del Distribuidor de Puerto. Estos representan principalmente mensajes relacionados con puerto recibidos desde las diversas interfaces de puerto asociadas al Controlador 10 en una MSU 5 particular. La PEPSFM 24 también recibe eventos desde una segunda fuente, la SIPFSM 14 mediante la conexión 44, como se muestra en la Figura 2. De la misma manera que para la SIPFSM, la PEPFSM recibe eventos desde una tercera fuente, los temporizadores en la propia PEPFSM, que marcan los finales de los intervalos de tiempo, o retardos.
En sistemas de única y múltiples MSU, la PEPSFM envía y recibe mensajes de interproceso (IPM). En sistemas de múltiples MSU, los IPM se llevan en el enlace 26 inter-MSU como se muestra en la Figura 2. Los eventos de señal de IPM entre instancias separadas de la PEPSFM en diferentes MSU.
Las instancias típicas de las clases de estado de puerto, como se determina mediante los eventos que ocurren durante una llamada, son: REPOSO (IDLE), HABLANDO (TALKING), LLAMANDO (RINGING), TONO (TONE) y RETENER (HOLD). Las clases de estado reales que existen en un sistema dado pueden variar dependiendo de las aplicaciones particulares para el que el sistema est� diseñado. Se presenta en este punto una lista de clases de estado de puerto como típicas -en cada clase estado de puerto, puede haber numerosos estados de puerto distintos.
DESCONOCIDO (UNKNOWN)
FUERA_DE_LÍNEA (OFF_LINE)
REPOSO (IDLE)
EN_USO (IN_USE)
TRANSICI�N (TRANSITION)
TOMA (SEIZE)
LIBERACI�N (RELEASE)
TONO (TONE)
HABLAR (TALK)
LLAMAR (RINGING)
MARCAR (DIAL)
RETENER (HOLD)
EQU_OCUPADO (EQU_BUSY)
DEVOLUCI�N_DE_LLAMADA (RING_BACK)
TONO_DE_OCUPADO (BUSY_TONE)
ESPERAR_ASIST (AWAIT_ATND)
MANIVELA_DE_MAGNETO (MAGNETO_CRANK)
La Figura 3 muestra un par de agrupaciones de estado de PEPFSM, comprendiendo cada agrupación de estado una clase de estado de puerto 70, 71. Cada clase de estado de puerto 70, 71 contiene uno o más estados de puerto. La clase de puerto 20 contiene los estados de puerto 72, 72a. La clase de estado de puerto 71 contiene los estados de puerto 73, 73a distintos de todos los estados de puerto 72, 72a de la clase de puerto 20. Una FSM del sistema tiene exactamente un estado de puerto, y por lo tanto exactamente una clase de estado de puerto, en un tiempo. Un evento de llamada particular que ocurre cuando la FSM est� en un primer estado de puerto 72 lleva aproximadamente una transición 720 del primer estado de puerto 72 a un segundo estado de puerto 72. Algunos eventos que ocurren cuando la FSM est� en un primer estado de puerto 72 lleva aproximadamente las transiciones 740 desde una primera clase de puerto 20 del primer estado 72a de puerto a una segunda clase de estado de puerto 71 y a un segundo estado de puerto 73a.
La primera clase de puerto 20 de la Figura 3 se muestra como “A”, que puede corresponder al estado HABLANDO, y la segunda clase de estado de puerto 71 de la Figura 3 se muestra como “B”, que puede corresponder al estado LLAMANDO, pero pueden definirse y usarse otras clases de puerto, conteniendo cada clase de estado de puerto una pluralidad de estados de puerto, de modo que la representación de la Figura 3 no debería tomarse en ningún sentido limitante.
La Figura 4 muestra el método de la presente invención. La PEPFSM se muestra como esperando (101) para procesar un evento. Cuando est� disponible un evento, el Planificador de Sistema 12 (Figura 2) produce que la PEPFSM continúe la ejecución en la etapa “Obtener próximo evento PEP” 103. En la etapa 105 la invención establece una variable “clase_de_comienzo” asociada al puerto actual para el estado de clase de puerto del estado de puerto actual (variable “estado_de_puerto_actual”). La variable “clase_de_comienzo” est� asociada al puerto actual, y est� localizada en el registro de puerto 27 de la llamada de la Figura 5. La conservación de la invención del estado de clase de puerto actual proporciona detección de transiciones entre los estados de clase de puerto cuando ocurren.
El evento se despacha (107) a continuación para transición. Despachar significa que la invención usa la combinación del tipo de evento que ocurre y el estado de puerto actual para invocar una rutina de transición (109) específica. El procesamiento que tiene lugar en la rutina de transición (109) puede cambiar el estado del puerto actual (variable “estado_de_puerto_actual”). Cuando la rutina de transición vuelve después de la compleción (111), la invención establece (113) una variable “clase_de_fin” asociada al puerto actual para el estado de clase de puerto del estado del puerto actual (variable “estado_de_puerto_actual”). La variable “clase_de_fin” est� asociada al puerto actual, y est� localizada en el registro de puerto 27 de la llamada de la Figura 5.
La invención a continuación compara (115) el valor “clase_de_comienzo” del puerto actual con el valor “clase_de_fin” del puerto actual. Si los dos valores son desiguales, la invención envía (117) el evento a la SIPFSM para iniciar el procesamiento SIPFSM del cambio del estado de puerto. Si los dos valores son iguales, la invención omite todo el procesamiento SIPFSM y espera el próximo evento PEP.
Los procesos de SIPFSM y PEPFSM son bastante similares en diseño y estructura. La Figura 5 ilustra el uso de registros de puerto (27) para almacenar estados de llamada para la PEPFSM, y la Figura 6 muestra el uso de registros de sesión (17) para almacenar clases de estado de llamada para la SIPFSM.
La comparación de clase de puertos de la invención, un único ensayo realizado en un lugar para todas las transiciones de estado de puerto, elimina el diseño, implementación, ensayo y funcionamiento de ensayos similares en cada rutina de transición PEPFSM. En este sentido se libera una multitud de rutinas de transición PEPFSM de la tarea de comunicarse con la SIPFSM.
La relajación del acoplamiento de la invención de la PEPFSM y la SIPFSM permite de esta manera tanto que las máquinas de estado funcionen más coherentemente, como simplifica el mantenimiento de software debido a la reducida probabilidad de introducir errores de programación en el protocolo SIP realizando cambios no relacionados con SIP a rutinas de transición PEP en cualquier clase de estado de puerto.
Aunque la invención se ha descrito con referencia a realizaciones preferidas, se entender� por los expertos en la materia que pueden realizarse diversos cambios y pueden sustituirse equivalentes para elementos de la misma para adaptarse a situaciones particulares sin alejarse del alcance de la invención. Por lo tanto, se pretende que la invención no est� limitada a las realizaciones particulares desveladas como el mejor modo contemplado para llevar a cabo esta invención, sino que la invención incluir� todas las realizaciones que caen dentro del alcance de las reivindicaciones adjuntas.

Claims (13)

  1. REIVINDICACIONES
    1. Un aparato para gestionar llamadas en un sistema de telefonía (5, 60, 40) usando una red IP (40), comprendiendo el aparato:
    al menos un controlador (10) configurado para establecer una conexión de comunicación entre:
    -un puerto de acceso conmutado (20) configurado para conectarse a un teléfono de acceso conmutado (21) respectivo; y -un puerto de VoIP;
    estando categorizada la conexión de comunicación en:
    -estados de llamada principales que incluyen: “espera”, “marcando” y “llamando”; -estados de puerto de acceso conmutado asociados a la condición del puerto (20) de acceso conmutado;
    ejecutando dicho al menos un controlador (10) la primera y la segunda máquinas de estado finito,
    -
    modelando la primera máquina de estado finito (24) el comportamiento de los puertos de acceso conmutado
    (20) y organizados con:
    un conjunto de clases de estado de puerto (70, 71), estando asociada cada clase de estado de puerto (70, 71) a un estado de llamada principal,
    para cada clase de estado de puerto (70, 71), un número finito de estados discretos (72, 72a, 73), estando asociado cada estado discreto (72, 72a, 73) a un estado de puerto de acceso conmutado;
    -
    modelando la segunda máquina de estado finito (14) el comportamiento del puerto VoIP y organizada con el mismo conjunto de clases de estado de puerto (70, 71) que la primera máquina de estado finito (24) y sin estados discretos (72, 72a, 73, 73a);
    estando programado dicho al menos un controlador (10) con rutinas de transición (720, 740) configuradas:
    -
    mediante la ejecución de la primera máquina de estado finito (24):
    para pasar el puerto de acceso conmutado (20) de un estado discreto (72, 72a) a otro estado discreto (72, 73a) en la misma clase de estado de puerto (70) o en una clase de estado de puerto (71) diferente; y
    para generar mensajes (34) a usarse para la ejecución de la segunda máquina de estado finito (14) representativos de las transiciones (740) entre diferentes estados discretos (72a, 73a) en diferentes clases de estado de puerto (70, 71);
    sin generar mensajes a usarse para la ejecución de la segunda máquina de estado finito (14) representativos de transiciones (720) entre diferentes estados discretos (72) en la misma clase de estado de puerto de la primera máquina de estado finito (24);
    -
    mediante la ejecución de la segunda máquina de estado finito (14), para pasar el puerto de VoIP de una clase de estado de puerto (70, 71) a otra clase de estado de puerto (70, 71) en respuesta a mensajes (34) generados mediante la ejecución de la primera máquina de estado finito (24).
  2. 2.
    El aparato de la reivindicación 1, en el que el controlador est� configurado para pasar, mediante la ejecución de la segunda máquina de estado finito (14), el puerto de acceso conmutado (20) de una clase de estado de puerto (70) a otra clase de estado de puerto (71) en respuesta a eventos de puerto o mensajes (44) generados mediante la ejecución de la primera máquina de estado finito (24).
  3. 3.
    El aparato de las reivindicaciones 1 o 2, en el que el puerto de VoIP es una conexión lógica (35, 36, 37) entre el controlador (10) y un teléfono de VoIP (30).
  4. 4.
    El aparato de acuerdo con cualquiera de las reivindicaciones anteriores, que comprende adicionalmente un software de planificación (12) configurado para implementar tanto la primera como la segunda máquinas de estado finito (14, 24).
  5. 5.
    El aparato de la reivindicación 4 implementado en una única unidad de conmutación modular (5).
  6. 6.
    El aparato de acuerdo con cualquiera de las reivindicaciones 1 a 4 implementado con múltiples unidades de conmutación modular (5).
  7. 7.
    El aparato de la reivindicación 6, que comprende adicionalmente un servidor de medios o pasarela (50).
  8. 8.
    El aparato de acuerdo con cualquiera de las reivindicaciones anteriores, en el que los estados de llamada principales incluyen “hablando” y/o “reteniendo”.
  9. 9.
    Un sistema de telefonía (5, 21, 60, 40) que tiene:
    -teléfonos de acceso conmutado (21) y -teléfonos de voz sobre internet VoIP (30) en una red IP (40), y -un aparato de acuerdo con cualquiera de las reivindicaciones anteriores.
  10. 10.
    El sistema de telefonía de la reivindicación 9, en el que la red IP (40) es una red de área local o una red de internet.
  11. 11.
    Un método para gestionar llamadas en un sistema de telefonía (5, 21, 60, 40), teniendo el sistema de telefonía:
    -teléfonos de acceso conmutado (21) y -teléfonos de voz sobre internet VoIP (30) en una red IP (40),
    comprendiendo el método:
    establecer una conexión de comunicación entre:
    -
    un puerto de acceso conmutado (20) conectado a un respectivo teléfono de acceso conmutado (21); y -un puerto de VoIP;
    estando categorizada la conexión de comunicación en:
    -estados de llamada principales que incluyen “espera”, “marcando” y “llamando”; -estados de puerto de acceso conmutados asociados a la condición del puerto de acceso conmutado (20);
    proporcionando el método una estructura de diseño de Máquina de Estado Finito con:
    -
    una primera máquina de estado finito (24) que modela el comportamiento del puerto de acceso conmutado (20) y organizada con:
    ○ un conjunto de clases de estado de puerto (70, 71), estando asociada cada clase de estado de puerto (70, 71) a un estado de llamada principal,
    ○ para cada clase de estado de puerto (70, 71), un número finito de estados discretos (72, 72a, 73), estando asociado cada estado discreto (72, 72a, 73) a un estado de puerto de acceso conmutado;
    -
    una segunda máquina de estado finito (14) que modela el comportamiento del puerto de VoIP y organizada con el mismo conjunto de clases de estado de puerto (70, 71) como la primera máquina de estado finito (24) y sin estados discretos (72, 72a, 73, 73a);
    proporcionando el método:
    -
    en la primera máquina de estado finito (24):
    pasar el puerto de acceso conmutado (20) de un estado discreto (72, 72a) a otro estado discreto (72, 73a) en la misma clase de estado de puerto (70) o en una clase de estado de puerto diferente (71); y
    generar mensajes (34) a usarse para la ejecución de la segunda máquina de estado finito (14) representativos de las transiciones (740) entre diferentes estados discretos (72a, 73a) en diferentes clases de estado de puerto (70; 71);
    no generar mensajes a usarse para la ejecución de la segunda máquina de estado finito (14) representativos de transiciones (720) entre diferentes estados discretos (72) en la misma clase de estado de puerto de la primera máquina de estado finito (24);
    -
    en la segunda máquina de estado finito (14), pasar el puerto de VoIP de una clase de estado de puerto (70, 71) a otra clase de estado de puerto (70, 71) en respuesta a mensajes (34) generados mediante la ejecución de la primera máquina de estado finito (34).
  12. 12.
    El método de la reivindicación 11 que usa el sistema de telefonía de las reivindicaciones 9 o 10.
  13. 13.
    Un método de acuerdo con la reivindicación 12 que comprende la etapa preliminar de integrar un sistema de teléfonos de acceso conmutado existente con los teléfonos de VoIP de internet (30) usando un aparato de acuerdo con cualquiera de las reivindicaciones 1 a 8.
ES07841058.6T 2006-08-17 2007-08-17 Conmutador de telecomunicaciones VOIP Active ES2468244T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US83820806P 2006-08-17 2006-08-17
US838208P 2006-08-17
PCT/US2007/076213 WO2008022315A2 (en) 2006-08-17 2007-08-17 Voip telecommunications switch

Publications (1)

Publication Number Publication Date
ES2468244T3 true ES2468244T3 (es) 2014-06-16

Family

ID=39083174

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07841058.6T Active ES2468244T3 (es) 2006-08-17 2007-08-17 Conmutador de telecomunicaciones VOIP

Country Status (10)

Country Link
US (1) US8125983B2 (es)
EP (1) EP2062157B1 (es)
CN (2) CN101506792B (es)
AU (1) AU2007285788B2 (es)
CA (1) CA2661029C (es)
DE (1) DE202007018941U1 (es)
ES (1) ES2468244T3 (es)
HK (2) HK1133934A1 (es)
TW (1) TWI435585B (es)
WO (1) WO2008022315A2 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736172B2 (en) 2007-09-12 2017-08-15 Avaya Inc. Signature-free intrusion detection
US9178898B2 (en) 2007-09-12 2015-11-03 Avaya Inc. Distributed stateful intrusion detection for voice over IP
US9438641B2 (en) 2007-09-12 2016-09-06 Avaya Inc. State machine profiling for voice over IP calls
US9100417B2 (en) * 2007-09-12 2015-08-04 Avaya Inc. Multi-node and multi-call state machine profiling for detecting SPIT

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4228536A (en) 1979-05-29 1980-10-14 Redcom Laboratories, Inc. Time division digital communication system
US6353610B1 (en) * 1998-06-19 2002-03-05 Lucent Technologies, Inc. Method and system for call signaling in telephone calls over a packet-switched network
US6445695B1 (en) * 1998-12-31 2002-09-03 Nortel Networks Limited System and method for supporting communications services on behalf of a communications device which cannot provide those services itself
US6950441B1 (en) * 1999-03-30 2005-09-27 Sonus Networks, Inc. System and method to internetwork telecommunication networks of different protocols
US6363424B1 (en) * 1999-09-01 2002-03-26 Lucent Technologies, Inc. Reuse of services between different domains using state machine mapping techniques
US7304984B2 (en) * 2000-02-11 2007-12-04 Convergent Networks, Inc. Methods and systems for creating, distributing and executing multimedia telecommunications applications over circuit and packet switched networks
US7103002B2 (en) * 2000-07-12 2006-09-05 Telefonktiebolaget Lm Ericsson (Publ) Communication management in networks having split control planes and user planes
US6721565B1 (en) * 2000-08-07 2004-04-13 Lucent Technologies Inc. Handover of wireless calls between systems supporting circuit and packet call models
US6917612B2 (en) * 2000-09-01 2005-07-12 Telefonaktiebolaged L M Ericsson System and method for address resolution in internet protocol (IP)-based networks
US6963583B1 (en) 2000-09-29 2005-11-08 Telefonaktiebolaget Lm Ericsson (Publ) Generic call server and method of converting signaling protocols
KR100462069B1 (ko) * 2000-12-21 2004-12-17 엘지전자 주식회사 인터넷 텔레포니 게이트웨이 시스템에서 상태 관리 방법
US6996076B1 (en) 2001-03-29 2006-02-07 Sonus Networks, Inc. System and method to internetwork wireless telecommunication networks
US7139263B2 (en) * 2001-10-19 2006-11-21 Sentito Networks, Inc. Voice over IP architecture
US7492873B2 (en) * 2002-04-25 2009-02-17 Azurn Networks, Inc. Voice/data session switching in a converged application delivery environment
US8549179B2 (en) * 2004-07-13 2013-10-01 Samsung Electronics Co., Ltd Collaborative state machine framework for use in a communication network
CN100531221C (zh) * 2004-07-27 2009-08-19 邓里文 一种用于因特网与准同步数字体系融合的适配方法
US9036619B2 (en) * 2005-05-16 2015-05-19 Mist Silicon Limited Liability Company Systems and methods for a session initiation protocol (SIP) translator

Also Published As

Publication number Publication date
CA2661029C (en) 2015-10-20
CN101506792A (zh) 2009-08-12
AU2007285788B2 (en) 2012-07-05
TW200830823A (en) 2008-07-16
TWI435585B (zh) 2014-04-21
CA2661029A1 (en) 2008-02-21
US20080043980A1 (en) 2008-02-21
CN101506792B (zh) 2013-06-05
DE202007018941U1 (de) 2010-02-18
US8125983B2 (en) 2012-02-28
EP2062157A4 (en) 2012-08-15
AU2007285788A1 (en) 2008-02-21
CN103354589B (zh) 2015-06-10
WO2008022315A2 (en) 2008-02-21
CN103354589A (zh) 2013-10-16
HK1133934A1 (en) 2010-04-09
EP2062157B1 (en) 2014-05-07
EP2062157A2 (en) 2009-05-27
HK1186888A1 (en) 2014-03-21
WO2008022315A3 (en) 2008-06-19

Similar Documents

Publication Publication Date Title
US7006614B2 (en) Systems and methods for voice and data communications including hybrid key system/PBX functionality
KR100487217B1 (ko) 공통 소프트웨어 플랫폼을 이용한 공통 호 처리 관리 방법및 장치
US7379455B2 (en) Systems and methods for providing configurable caller ID information
US7869424B2 (en) Systems and methods for voice and data communications including a scalable TDM switch/multiplexer
US20090059818A1 (en) Systems and methods for providing configurable caller id iformation
WO2008027715A2 (en) System and method for self-configuring sip-capable device
US20030007496A1 (en) System, apparatus and method for dynamically mapping virtual signaling system 7 circuit identification codes for use between voip gateways on IP-based networks
ES2468244T3 (es) Conmutador de telecomunicaciones VOIP
US7248565B1 (en) Arrangement for managing multiple gateway trunk groups for voice over IP networks
US6594685B1 (en) Universal application programming interface having generic message format
US20030097466A1 (en) Method for controlling incoming call directed to group in voice over internet protocol system
US20060259616A1 (en) Carrier and protocol indiscriminate edge device and method
US7751544B2 (en) Method and system for driving an indicating element on a terminal
CN101796805B (zh) 接入网关及其应用方法
Alexander et al. Cisco CallManager Fundamentals
Kaza et al. Cisco IP Telephony: Planning, Design, Implementation, Operation, and Optimization (paperback)
US6621814B1 (en) Method and apparatus for transmitting voice data in data packets with additional supplementary services
Krajnovic The design of a highly available enterprise IP telephony network for the power utility of Serbia company
US7515597B1 (en) Distributed switching platform and method of operating the same
US20090303886A1 (en) Method And System For Analyzing Gateways
WO2009148420A1 (en) Method and system for analyzing gateways