shkolakz.ru 1 ... 12 13 14 15

4.Diseño de la Metaseñalización


Como ya hemos comentado en varias ocasiones, la señalización intermedia ó metaseñalización constituye el tercer y último módulo del presente agente de usuario SIP. En principio, está compuesta por todos aquellos métodos necesarios para el transporte de información desde la pila hasta la interfaz y desde la interfaz a la pila. Se trata por lo tanto del “contrato” entre la pila, que será única y que forma la parte más importante del diseño, y la GUI, que aunque aquí hayamos diseñado una basada en ventanas, puede ser de cualquier tipo.


Mientras que conceptualmente la metaseñalización usa “métodos”, físicamente empleamos eventos Qt. Como ya se ha comentado, estos eventos son formas de notificar la ejecución de funciones de forma asíncrona y thread-safe: asíncrona porque el control de la función llamante retorna antes de que la función llamada haya finalizado y thread-safe porque ni el objeto llamante ni el llamado tienen porqué estar en el mismo hilo de ejecución. La forma en la que se implementa el retorno de los datos a la función llamante una vez que la llamada finalice es también a través de eventos: unos eventos que nosotros, de forma arbitraria, consideramos que son de respuesta.


Con esta sencilla introducción (y todos los comentarios relativos al paso de eventos vistos ya en el presente documento) estamos listos para estudiar los cuatro tipos de eventos que la metaseñalización pone a nuestra disposición:


4.1.Eventos de texto



Dentro de los eventos de texto consideramos a todos aquellos cuya función sea el transmitir cadenas de texto. Concretamente contamos con dos tipos (el número que aparece entre paréntesis es su indicativo de evento):


  • SUA_Text_Event (363636): este tipo de eventos, se usa casi exclusivamente para el transporte de cadenas de texto, junto con un tipo asociado, desde cualquier parte del agente hacia la ventana de depuración. El tipo asociado a la cadena indicará al objeto encargado de visualizar el texto el formato que se le deberá adjudicar, como ya vimos en el punto “2.3 Depuración” del presente documento.


  • SUA_String_Event (393939): se trata este tipo de un conjunto de eventos más genéricos, que transportan una cadena de texto plano junto a un puntero al emisor del evento. Concretamente se le han dado dos usos a estos eventos: por una parte, son los encargados del transporte de los mensajes SIP entrantes de la red desde el hilo generador hasta el hilo que represente a la sesión a la que pertenece el mensaje. Y por otra, son los que llevan la información SIP desde la pila hacia la GUI, por ejemplo al concluir positivamente una petición de propiedades ó durante el proceso de registro.



4.2.Eventos de gestión de hilos



Ya hemos comentado en varias ocasiones la necesidad de gestionar los hilos que vamos generando. Para ello usamos los eventos del tipo SUA_ThMan_Event (373737) que transportarán los siguientes campos:



  • Un código que indica su finalidad (lo vemos a continuación).

  • Un puntero a la ventana ó hilo emisor, de carácter obligatorio.

  • Un puntero a un hilo, opcional.

  • Un puntero a una ventana, también opcional.


En función de qué actuación queremos realizar de forma concreta, disponemos de hasta seis subtipos de eventos de gestión distintos:



  • TM_Kill_Sender (1): este evento es lanzado desde un hilo worker SIP que ha terminado su ejecución al hilo generador de eventos para que destruya todo rastro de dicho hilo; entre las tareas a realizar destacan la de eliminar la entrada que apunta al hilo en la lista global de hilos activos, liberar su identificador y destruir el objeto que encapsula el funcionamiento del hilo.
  • TM_Set_Confirm_Flag (2): este evento lo lanza el hilo generador ó la interfaz gráfica hacia un hilo worker, para que éste active un flag (presente en todos los hilos de este agente) de forma que al terminar la ejecución, y antes de mandar el 'TM_Kill_Sender', envíe un evento de gestión del tipo 'TM_Exit_Confirmation' al objeto especificado para que se conozca de primera mano cuándo ha terminado la sesión. Es una técnica muy útil para destruir ventanas que representan sesiones que ya no están activas: en lugar de posicionar un botón para que el usuario cierre la ventana, la pila puede indicar a la ventana cuándo ha terminado para que sea esta misma la que se cierre automáticamente.


  • TM_Exit_No_Conf (6): este evento es el contrario del anterior, limpia el flag que exige la confirmación de la finalización.

  • TM_Exit_Confirmation (3): este evento es, como ya hemos visto, la propia confirmación que envía un hilo hijo SIP si su flag de confirmación ha sido activado. Se enviará al objeto especificado en el evento que activa la solicitud de confirmación.

  • TM_Update_Th_Pointer (4): este tipo de eventos serán enviados desde los hilos worker SIP a la interfaz gráfica para informarle de quién está manejando su sesión, y de cómo acceder a dicho hilo a través de su puntero. Generalmente sólo es necesaria la emisión de un evento de este tipo cuando se crea el hilo que atiende a una determinada sesión.

  • TM_Update_Mw_Pointer (5): semejante al anterior, este evento viaja desde la GUI hacia la pila para enviar al hilo encargado de la sesión un puntero a la ventana que deberá recibir sus notificaciones. Debido a que durante la vida de una sesión en la pila pueden aparecer múltiples ventanas en la GUI, deberemos disponer de un método para dirigir hacia una concreta y en cada momento toda la señalización (concretamente se puede pensar en la cantidad de ventanas que intervienen en la creación de una llamada de audio).



4.3.Eventos de control de llamada



Los eventos de llamada, encarnados por la clase SUA_Call_Event (383838), constituyen el núcleo central de la metaseñalización, porque implementan una señalización intermedia que se asemeja mucho a la señalización de los terminales telefónicos tradicionales, ocultando así gran parte de la complejidad de SIP. Estos eventos son los que realmente dan sentido a la metaseñalización, porque permiten realizar a la GUI del soft-phone todo aquello que el usuario demanda de forma explícita.

Existen numerosos subtipos de eventos de llamada, divididos en dos grandes conjuntos: por una parte los eventos que viajan desde la GUI hacia la pila y por otra los que van en sentido contrario.



4.3.1.Eventos de llamada en sentido de la GUI hacia la pila



Tenemos los siguientes:


  • W_Accept_Call (1): indica a la pila que acepte la llamada entrante.

  • W_Reject_Call (2): expresa que el usuario no quiere aceptar la llamada.

  • W_Hang_Call (5): este evento se usa cuando es nuestro usuario quien desea cancelar la llamada, por lo que deberemos iniciar el proceso de cierre de la sesión como clientes.

  • W_Make_Call (6): se lanza este evento cuando el usuario quiere llamar a alguien. Lleva consigo una cadena de texto con la dirección SIP del extremo llamado.

  • W_Query_Options (41): se utiliza para comenzar una transacción de petición remota de características a través del método OPTIONS. Se deberá incluir la dirección SIP de destino.

  • W_Cancel_Options (45): este método cancela la petición comenzada con el evento anterior.

  • W_Register (50): inicia el proceso de registro contra nuestro proxy.

  • W_Cancel_Register_No_Conf (53): sirve para cancelar el proceso comenzado con el evento anterior.



4.3.2.Eventos de llamada en sentido de la pila hacia la GUI



Dentro de este segundo grupo existen a su vez tres subgrupos de eventos que viajan desde la pila hacia la interfaz gráfica: por una lado están los relacionados con una llamada entrante, por otro, aquellos que manejan llamadas salientes y por último los relacionados con el proceso de registro, que no se enmarcan en uno ni en otro.


4.3.2.1.Eventos relacionados con una llamada entrante



Son tres. En concreto:


  • S_Incoming_Call (0): este evento es notificado por la pila a la interfaz para que le indique al usuario que hay una llamada entrante que podría ser aceptada.


  • S_Sending_Bye (23): evento que indica a la interfaz del hecho de que una petición BYE está siendo enviada al extremo opuesto.

  • S_Finish_Bye_200 (28): este evento da la llamada por finalizada porque la petición de cierre de la sesión ha sido confirmada positivamente.



4.3.2.2.Eventos relacionados con una llamada saliente



Destacan los siguientes:



  • C_Running_Call (9): este evento lo mana la pila para indicar que los flujos multimedia ya están en marcha y que la comunicación ha comenzado.

  • C_Invite_No_Response (11): informa al usuario acerca del error ocurrido al no poder contactar con nadie en la dirección SIP de destino previamente especificada.

  • C_Finish_Bye_200 (30): similar al evento nº 28, pero funcionando con llamadas salientes.

  • C_Received_404 (37): se recibe este evento cuando con la dirección SIP proporcionada no se puede encontrar el usuario buscado en la máquina seleccionada.

  • C_No_Media_Mach (54): se genera este evento cuando no existe un códec común de audio entre aquellos propuestos por el cliente y por el servidor.



4.3.2.3.Eventos de registro



Destacan dos:



  • W_Register_Successfull (51): este evento indica a la GUI de que el registro ha concluido exitoso.

  • W_Register_unSuccessfull (52): este evento señaliza el fracaso del proceso de registro.



4.4.Eventos de volumen


Son aquellos eventos que lanza la GUI hacia el hilo de apoyo que gestiona su llamada para aumentar ó disminuir tanto el volumen de grabación como el de reproducción. Se basan en una clase SUA_Volume_Event (404040) a la que se le pasa tanto el dispositivo sobre el que queremos actuar (VE_DSP para el volumen de reproducción y VE_MIX para el de grabación) como el nivel que queremos establecer.



ESCUELA SUPERIOR DE INGENIEROS DE BILBAO

Proyecto

DE


Diseño e Implementación de un agente de usuario SIP



Parte nº 1 – Diseño de Alto Nivel

Alumno
Gotxi García, Ibon

Fecha Marzo 2002

Firma



Profesor Cátedra

Profesor Ponente

Curso Académico







2001/2002



<< предыдущая страница