INTRODUCCION

Para poder entender que es la telefonía IP primero debemos tener en claro algunos puntos sobre la telefonía que usamos diariamente.

La telefonía es prestada por las empresas prestadoras denominadas genéricamente TELCOs.

La red de equipos y cables por donde nos prestan el servicio se denomina Red Publica, como las conexiones entre los usuarios no son fijas, si no que se establecen temporariamente entre distintos usuarios al momento de hacer cada llamada, se las denomina CONMUTADAS, y la conmutación puede ser MANUAL, por medio de una operadora o AUTOMATICA con equipos que las realizan por ellos mismos.

Al conjunto de cables y equipos que forman la red de telefonía con las que los prestadores nos brindan el servicio se lo denomina genéricamente PSTN de las ingles Public Switched Telephone Network, algo así como Red Publica de Telefonía Conmutada. De la misma forma como el servicio de telefonía se lo aplica a comunicaciones de voz se lo suele denominar "Telefonía Básica" y en otros textos hacen referencias generales a la RTB o Red de Telefonía Básica.

En el proceso de realización de una llamada existen dos elementos claramente distinguibles, uno es el proceso para establecer la llamada y el otro la comunicación en si misma, al conjunto de señales que permiten establecer, procesar, terminar y liberar los recursos usados en una llamada se lo denomina SEÑALIZACION.

Esta señalización ocurre en cada llamada, solo que nos parece tan natural que no le prestamos atención, por ejemplo en llamada telefónica.

Descolgamos el teléfono - allí estamos haciendo la petición de servicio, y la central se entera que cliente necesita atención.

Antes de ingresar el numero de destino esperamos que nos llegue el tono de discado - es decir esperamos recibir la invitación a discar. Que nos indica que todo esta preparado para poder llamar.

Discamos, es decir indicamos la llamada que queremos hacer.

La central busca al destinatario y trata de avisarle que tiene un llamada, una vez que lo encuentra le avisa, haciendo sonar su teléfono.

El destinatario atiende descolgando el teléfono y avisándole a la central que acepta la llamada (si no lo hace, después de un tiempo asume que el usuario no puede atender).

Si atienden, la central comienza a tasar la llamada los usuarios hablan uno de los dos cuelga y esto le avisa a la central que la llamada ha finalizado termina la transacción se liberan los circuitos, pero si algún usuario permanece en línea se le envía tono de no disponible (ocupado) para avisarle que la llamada finalizo, y que debe volver a colgar.

Así pues, todos los aparatos conectados a una red deben implementar la misma señalización para poder comunicarse dentro de esa red.

Las empresas también pueden tener en sus ámbitos privados sus propias redes, y a las centrales que manejan esa redes se las denomina PBX (Private Branch Excnage) o PABX (Private Automatic Branch Excange) si bien ambos términos se suelen usar en forma indistinta, la diferencia radica en que la PBX admite también un modo de conmutación MANUAL o dicho de otra forma permite intervención manual sobre el manejo de las llamadas, mientras que una PABX es solo automática.

Tecnologías para telefoníaLa telefonía puede separarse en dos grandes grupos según su tecnología de audio: ANALOGICA y DIGITAL.

Analógica es aquella donde el sonido viaja por los equipos y cables conservando la forma original en que fue generada, también se la suele denominar "Telefonía Convencional".

Digital es aquella donde el audio de la conversación es convertido a señales digitales codificadas que volverán a convertirse otra vez en audio analógico cuando lleguen al equipo receptor para que el oído humano pueda interpretarlas. A este proceso de CODIFICACION - DECODIFCIACION los realizan los CODECs, por ejemplo un codec muy popular en el manejo del AUDIO es el MP3, y aunque este no se aplica en las conversaciones de telefonía nos sirve como un ejemplo muy claro sobre el proceso de codificación del audio.

En tecnologías digitales hay muchas, pero la mas conocida en la telefonía por cables es la denominada RDSI conocida como Red Digital de Servicios Integrados (en ingles ISDN), cuyo nombre nos deja en claro que además de poder efectuar comunicaciones vocales puede realizar una comunicación de otro tipo entre los terminales de usuario, por ejemplo transmitir video, o un enlace de datos entre computadoras.

Normalmente en las empresas más grandes usan centrales privadas de este tipo ya que permiten funcionalidades mucho mas avanzadas. Los equipos que se conectan a ellas son especialmente diseñados para estas centrales, NO SON COMPATABILES con las líneas telefonía analógica, por eso para poder conectar los teléfonos convencionales se arman centrales híbridas que soportan simultáneamente las dos tecnologías permitiendo llamados entre un teléfono digital y otro analógico. A este Proceso de conectar o "Puentear" dos tecnologías distintas por un medio de conmutación se lo denomina BRDIGING, y normalmente requiere procesar el audio y convertirlo de un formato a otro, o incluso aun reprocesar la señalización.

Esta misma división en analógico y digital, también se presenta en la telefonía celular donde prácticamente ya no existen los servicios analógicos porque que fueron reemplazados por su par digital GSM, y que en forma similar a la red RDSI permiten realizar comunicaciones de Voz o de datos, así por ejemplo, podemos tener acceso a Internet por medio de GPRS o trasmitir la ubicación geográfica basada en GPS.

¿Que es la Telefonía IP?Es un sistema de Telefonía que permite hacer llamadas telefónicas pero con algunas diferencias respecto de los servicios de telefonía convencional que brindan las Prestadoras o TELCOs.

La primera diferencia es que la conexión entre la Central y el cliente no debe hacerse por una red dedicada a ello, sino que simplemente la llamada se CODFICA en formato digital, y se la empaqueta para ser transportada en una red de datos de tipo TCP/IP, como las que conectan las redes de computadoras tanto redes locales o LAN, extendidas o WAN y los accesos a Internet.

Al igual que todos los servicios prestados sobre una plataforma TCP/IP requiere de un PROTOCOLO, es decir de un conjunto de operaciones y comandos preestablecidos que permiten llevar a cabo el servicio requeridos.

Los protocolos mas conocidos por los usuarios dentro del mundo de Internet son el HTTP, que permite ver las paginas Web, el FTP que permite la transferencia de archivos, SMTP y POP que permiten hacer uso del mail etc,etc.

En la telefonía IP los protocolos pueden ser varios según el servicio a realizar, los que tiene que ver con la VOZ son el H323 y el SIP (Session Initiate Protolocol) o Protocolo de Inicio de Sesión. El H323 fue el mas usado inicialmente, de hecho algunos programas, como por ejemplo el Netmeeting de Microsoft, eran en realidad un cliente de comunicaciones que implementaba este protocolo y que pueden funcionar como un

"teléfono IP H323". Este protocolo era muy rígido respecto del manejo de los recursos de hardware y los puertos de red y al correr el tiempo el protocolo SIP prácticamente ocupó la totalidad de las comunicaciones Voip.

Normalmente las comunicaciones SIP pueden ser entre pares (peer to peer) o por medio de un servidor que lleva a cabo la "representación" de cada peer, a este servidor normalmente se le suele denominar SIP Proxy, y su función es la de REGISTRAR cada cliente SIP que se pone activo para poder localizarlo en la red, así pues cuando una central IP o el mismo Proxy necesitan ECONTRAR un Cliente SIP sabrán donde hallarlo, este es un proceso similar al que ocurre con las paginas WEBs y los servidores de DNS, donde la ubicación real de la pagina es una dirección IP formada por cuatro números de tres cifras, pero en los navegadores escribimos su nombre, y en base a éste el servidor de DNS le brinda la dirección ip a nuestro navegador (o podríamos decirle nuestro cliente HTTP) para que la encuentre. Esta analogía en sentido estricto es un ejemplo grafico para poder asimilar el proceso.

¿A quien puedo llamar usando Telefonía IP?A usuarios de la misma central, usuarios de otras centrales y también a clientes de las TELCOs y Celulares de todo el mundo, para ello la central IP con la que estoy conectado debe tener acceso a la PSTN y a Celulares. ¿Existen Centrales IP?Si, al igual que antes las hay de acceso público y privado. Normalmente se las identifica como Centrales VoIP, cuando son privadas se las denomina Voip PBX / VoIP PABX. Al proveedor del servicio de telefonia sobre internet se le denomina ITSP.

¿Como me conecto a una central IP?Usando un cliente IP y una conexión de red TCP/IP.

¿Que equipo necesito para conectarme a una central IP?Cualquier equipo que sirva como cliente ip :Un teléfono IP, un ATA, un Gateway IP, Un PABX/PBX IP, o un SoftPhone en una computadora de escritorio, notebook, o una handeheld, incluso teléfonos celulares que soporte WIFI / internet y la carga de aplicaciones de usuario.

Dentro de la variedad de teléfonos IP, incluso podemos encontrar una línea de equipos WIFI, que son de una apariencia externa similar a un celular GSM.

¿Que es SoftPhone?Es un programa que se puede instalar en una computadora de escritorio, laptop, notebook o incluso en algunos handheld, también en terminales 3g con acceso a Internet en los cuales se puedan agregar aplicaciones de usuario. Una vez instalados permiten tener servicio de telefonía transportado sobre una red TCP/IP, por ejemplo sobre Internet o una red privada LAN o una red privada WAN. Esta misma prestación la realizan los equipos denominados ATA y VoIP GATEWAYS que posibilitan convertir una llamada de un teléfono analógico convencional en llamada IP.

¿Que tipo de servicios puedo tener con un Softphone?Los mismos que con cualquier cliente IP, cada programa instalado en una computadora la convierte en un teléfono ip, y permite armar una red privada interna de la cantidad de usuarios que se necesiten sin depender rígidamente del hardware, como ocurre con las centrales analógicas convencionales, es decir esta plataforma es de alta escalabilidad. Cuando este programa se acompaña de la instalación de una centralita privada (PBX o PABX) para VoIP, se puede lograr que los internos se localicen en distintos ámbitos geográficos, incluso en distintas ciudades o países y que sus llamados internos sean GRATUITOS, además se les puede asociar un numero telefónico publico entrante de la red de telefonía de la PSTN (DID), o varios si hicieran falta, de forma tal que se puedan distribuir los llamados entrantes de desde las empresas telefónicas (PSTN) entre esos internos IP o de poder compartir esa línea entre todos ellos, tal como se hace

con una centralita convencional, con la ventaja de que no requiere del tendido de cables, ya que en el caso del VoIp solo es necesario transporte de datos por la red, incluso puede ser vía WI-FI.

¿Tengo que instalar una central IP propia?No es necesario, pero si resultaría muy útil y flexible, también se puede contratar el servicio de Central Privada Virtual a una empresa que preste ese servicio. ¿Que ventajas se consigue con la telefonía IP?Una de las grandes ventajas es la independencia del lugar de instalación, es decir, si se instala este programa tendrá servicio de telefonía en su computadora en cualquier lugar donde la misma tenga acceso a Internet, incluyendo zonas wifi o hotspots como en aeropuertos, countries, barrios cerrados, hoteles, etc. así pues, puede llevarse por el mundo el interno de su central, o recibir llamadas en su numero telefónico de su operador local, vaya donde vaya, o también tener comunicaciones entre su oficina, su casa y su casa de descanso y nadie podrá darse cuenta de donde se encuentra físicamente, sin necesidad de infraestructura adicional, es decir, en su oficina un cliente lo busca por un negocio muy importante y usted esta disfrutando de una tarde de relax y su secretaria podrá poner la llamada en espera, para luego transferirla donde quiera que usted se encuentre, o simplemente discar su interno, sin que la persona que lo busca halle diferencia alguna.

¿Y los costos?Son mucho mas económicos que aquellos que presentan las mismas prestaciones pero basadas en telefonía convencional. De la misma, forma si contrata un plan de llamadas de larga distancia con un servicio VoIP, obtendrá tarifas mas económicas que con su operador de telefonía convencional y podrá utilizar la misma cuenta desde su oficina, desde su casa, o cuando este de viaje ahorrando cientos de $$$ en comunicaciones, incluso podrá asignarle internos remotos a sus clientes mas importantes de forma de mantener una comunicación fluida y gratuita.

Arquitectura IAXEl protocolo IAX se corresponde con Inter-Asterisk eXchange protocol. Como indica su nombre fue diseñado como un protocolo de conexiones VoIP entre servidores Asterisk aunque hoy en día también sirve para conexiones entre clientes y servidores que soporten el protocolo.La versión actual es IAX2 ya que la primera versión de IAX ha quedado obsoleta Es un protocolo diseñado y pensado para su uso en conexiones de VoIP aunque puede soportar otro tipo de conexiones (por ejemplo video), Los objetivos de IAX son:

Minimizar el ancho de banda usado en las transmisiones de control y multimedia de VoIP. Evitar problemas de NAT (Network Address Translation). Soporte para transmitir planes de marcación.

Entre las medidas para reducir el ancho de banda cabe destacar que IAX o IAX2 es un protocolo binario en lugar de ser un protocolo de texto como SIP y que hace que los mensajes usen menos ancho de banda.Para evitar los problemas de NAT el protocolo IAX o IAX2 usa como protocolo de transporte UDP, normalmente sobre el puerto 4569,(el IAX1 usaba el puerto 5036), y tanto la información de señalización como los datos viajan conjuntamente (a diferencia de SIP) y por tanto lo hace menos proclive a problemas de NAT y le permite pasar los routers y firewalls de manera más sencilla.

Mensajes IAX Para poder entender el protocolo IAX vamos a ver un ejemplo del flujo de datos de una comunicación IAX2

Una llamada IAX o IAX2 tiene tres fases:

A) Establecimiento de la llamadaEl terminal A inicia una conexión y manda un mensaje "new". El terminal llamado responde con un "accept" y el llamante le responde con un "Ack". A continuación el terminal llamado da las señales de "ringing" y el llamante contesta con un "ack" para confirmar la recepción del mensaje. Por último, el llamado acepta la llamada con un "answer" y el llamante confirma ese mensaje.

B) Flujo de datos o flujo de audioSe mandan los frames M y F en ambos sentidos con la información vocal. Los frames M son mini-frames que contienen solo una cabecera de 4 bytes para reducir el uso en el ancho de banda. Los frames F son frames completos que incluyen información de sincronización. Es importante volver a resaltar que en IAX este flujo utiliza el mismo protocolo UDP que usan los mensajes de señalización evitando problemas de NAT.

C) Liberación de la llamada o desconexiónLa liberación de la conexión es tan sencilla como enviar un mensaje de "hangup" y confirmar dicho mensaje.

Frames o tipos de tramas Los mensajes o tramas que se envían en IAX2 son binarios y por tanto cada bit o conjunto de bits tiene un significado. Como hemos indicado anteriormente existen dos tipos de mensajes principalmente:

A) Tramas F o Full FramesLa particularidad de las tramas o mensajes F es que deben ser respondidas explícitamente. Es decir cuando un usuario manda a otro una trama F (full frame) el receptor debe contestar confirmando que ha recibido ese mensaje. Estas tramas son las únicas que deben ser respondidas explícitamente.

A continuación ponemos el formato binario de una trama F o full frame de IAX2.

El significado de cada uno de los campos es el siguiente:- F: Un bit que indica si la trama es F (full frame) o no. Para que sea F o full frame debe estar puesta a

1.- Source Call Number - Número de llamada de origen: 15 bits que identifican la conversación de

origen ya que puede haber varias comunicaciones multiplexados por la misma línea.- R: Bit de retransmisión. Se pone a uno cuando la trama es retransmitida.- Destination Call Number - Número de llamada destino: lo mismo que el de origen pero para

identificar el destino.- Timestamp o sello de tiempo - Para marcar el tiempo en cada paquete- OSeqno - sec. de salida : Número de secuencia de salida con 8 bits. Comienza en 0 y se va

incrementándose cada mensaje.- ISeqno - sec. De entrada: Lo mismo para la entrada.- Frame Type - tipo de trama: Indica la clase de trama de que se trata- C: Puesto a 0 indica que el campo subclase debe tomarse como 7 bits (un solo mensaje):

Puesto a 1 indica que el campo subclase se obtiene con 14 bits (dos mensajes consecutivos).- Subclass – subclase - Subclase del mensaje.- Data - Datos: datos que se envían en formato binario.

B) Tramas M o Mini FramesLas tramas M o mini frames para mandar la información con la menor información posible en la cabecera. Estas tramas no tienen porque ser respondidas y si alguna de ellas se pierde se descarta sin más.El formato binario de las tramas M o mini frames es el siguiente:

El significado de los campos es similar al de las tramas F o full frame. En este caso el bit F está puesto a 0 y el sello de tiempo o Timestamp está truncado y solo tiene 16 bits para aligerar la cabecera. Son los clientes los que deben encargarse de llevar un timestamp de 32 bits si lo desean y para sincronizarlo mandar una trama F.

Frames F o Full FrameEl campo Type Frame o tipo de trama de las tramas F junto con el campo subclase determinan la función del paquete que se está enviado o recibiendo y sirven por tanto como señalización de control.El campo Type Frame esta formado por 8 bits (1 byte) y los principales valores que puede tomar se muestran en la siguiente tabla:

Tabla 1. Posibles valores del campo "Type Frame" de las tramas F o Full FrameValor "type frame"

Descripción Detalles

00000001 DTMF Sirve para enviar dígitos DTMF

00000002 Datos de voz El campo subclase indica el tipo de codec de audio que se utiliza según la tabla 2

00000003 Datos de video El campo subclase indica el tipo de codec de video que se utiliza

00000004 ControlMensajes de control de sesión. Sirve para controlar el estado de los dispositivos finales. El campo subclase indica el tipo concreto de mensaje de control según tabla 3.

00000005 No usado

00000006 Control IAXMensajes de control del protocolo IAX. Gestiona las interacciones necesarias entre los dispositivos finales. El campo subclase indica el tipo concreto de mensaje de control según tabla 4.

00000007 Texto

00000008 Imagen

00000009 HTML

Tabla 2. Significado de los valores del campo subclase para Frame Type = "0x02" (datos de voz)

Valor subclase (Type Frame =0x02)

Descripción (codec que se utiliza en la conversación)

0x0001 G.723.1

0x0002 GSM

0x0004 G.711 u (u-law)

0x0008 G.711 a (a-law)

0x0080 LPC10

0x0100 G.729

0x0200 Speex

0x0400 iLBC

Tabla 3. Significado de los valores del campo subclase para Frame Type = "0x04" (control)

Valor subclase (Type Frame =0x04)

Descripción Detalles

0x01 Hangup La llamada se ha colgado

0x02 Ring El teléfono esta sonando

0x03 Ringing (ringback)

0x04 Answer Respuesta

0x05 Busy Condition El usuario está ocupado

0x08 Congestion Condition Existe congestión

0x0e Call Progress Progreso de la llamada

Tabla 4. Significado de los valores del campo subclase para Frame Type = "0x06" (control IAX)

Valor subclase (Type Frame =0x05)

Descripción Detalles

0x01 NEW Iniciar una nueva llamada 0x10 REGREJ Denegación de registro

0x02 PING Enviar un ping 0x11 REGREL Liberación de registro

0x03 PONG Responder un ping 0x12 VNAK Petición de retransmisión

0x04 ACK Respuesta afirmativa 0x13 DPREQ Petición de dialplan

0x05 HANGUP Inicio de desconexión 0x14 DPREP Respuesta de dialplan

0x06 REJECT Rechazo 0x15 DIAL Marcado

0x07 ACCEPT Aceptación 0x16 TXREQ Petición de transferencia

0x08 AUTHREQ Petición de autenticación 0x17 TXCNT Conexión de transferencia

0x09 AUTHREP Respuesta de autenticación 0x18 TXACC Aceptación de transferencia

0x0a INVAL Llamada no válida 0x19 TXREADY Transferencia preparad

0x0b LAGRQ Petición de Lag 0x1a TXREL Liberación de transferencia

0x0c LAGRP Respuesta de Lag 0x1b TXREJ Rechazo de transferencia

0x0d REGREQ Petición de registro 0x1c QUELCH Parar transmisión de audio

0x0e REGAUTH Autenticación de registro 0x1d UNQUELCHContinuar transmisión de audio

0x0f REGACK ACK de registro 0x20 MWIIndicador de mensaje en espera

0x21 UNSUPPORT Mensaje no soportado

Arquitectura SIP

El protocolo SIP (Session Initiation Protocol) fue desarrollado por el grupo MMUSIC (Multimedia Session Control) del IETF, definiendo una arquitectura de señalización y control para VoIP. Inicialmente fue publicado en febrero del 1996 en la RFC 2543, ahora obsoleta con la publicación de la nueva versión RFC 3261 que se publicó en junio del 2002.

El propósito de SIP es la comunicación entre dispositivos multimedia. SIP hace posible esta comunicación gracias a dos protocolos que son RTP/RTCP y SDP.

El protocolo RTP se usa para transportar los datos de voz en tiempo real (igual que para el protocolo H.323, mientras que el protocolo SDP se usa para la negociación de las capacidades de los participantes, tipo de codificación, etc.)

SIP fue diseñado de acuerdo al modelo de Internet. Es un protocolo de señalización extremo a extremo que implica que toda la lógica es almacenada en los dispositivos finales (salvo el rutado de los mensajes SIP). El estado de la conexión es también almacenado en los dispositivos finales. El precio a pagar por esta capacidad de distribución y su gran escalabilidad es una sobrecarga en la cabecera de los mensajes producto de tener que mandar toda la información entre los dispositivos finales.

SIP es un protocolo de señalización a nivel de aplicación para establecimiento y gestión de sesiones con múltiples participantes. Se basa en mensajes de petición y respuesta y reutiliza muchos conceptos de estándares anteriores como HTTP y SMTP.

Componentes SIP SIP soporta funcionalidades para el establecimiento y finalización de las sesiones multimedia: localización, disponibilidad, utilización de recursos, y características de negociación.

Para implementar estas funcionalidades, existen varios componentes distintos en SIP. Existen dos elementos fundamentales, los agentes de usuario (UA) y los servidores.

1. User Agent (UA): consisten en dos partes distintas, el User Agent Client (UAC) y el User Agent Server (UAS). Un UAC es una entidad lógica que genera peticiones SIP y recibe respuestas a esas peticiones. Un UAS es una entidad lógica que genera respuestas a las peticiones SIP.

Ambos se encuentran en todos los agentes de usuario, así permiten la comunicación entre diferentes agentes de usuario mediante comunicaciones de tipo cliente-servidor.

2. Los servidores SIP pueden ser de tres tipos:- Proxy Server: retransmiten solicitudes y deciden a qué otro servidor deben remitir, alterando los campos de la solicitud en caso necesario. Es una entidad intermedia que actúa como cliente y servidor con el propósito de establecer llamadas entre los usuarios. Este servidor tiene una funcionalidad semejante a la de un Proxy HTTP que tiene una tarea de encaminar las peticiones que recibe de otras entidades más próximas al destinatario.

Existen dos tipos de Proxy Servers: Statefull Proxy y Stateless Proxy. Statefull Proxy: mantienen el estado de las transacciones durante el procesamiento de las peticiones. Permite división de una petición en varias (forking), con la finalidad de la localización en paralelo de la llamada y obtener la mejor respuesta para enviarla al usuario que realizó la llamada. Stateless Proxy: no mantienen el estado de las transacciones durante el procesamiento de las peticiones, únicamente reenvían mensajes.

- Register Server: es un servidor que acepta peticiones de registro de los usuarios y guarda la información de estas peticiones para suministrar un servicio de localización y traducción de direcciones en el dominio que controla.

- Redirect Server: es un servidor que genera respuestas de redirección a las peticiones que recibe. Este servidor reencamina las peticiones hacia el próximo servidor.

La división de estos servidores es conceptual, cualquiera de ellos puede estar físicamente una única máquina, la división de éstos puede ser por motivos de escalabilidad y rendimiento.

Mensajes SIP SIP es un protocolo textual que usa una semántica semejante a la del protocolo HTTP. Los UAC realizan las peticiones y los UAS retornan respuestas a las peticiones de los clientes. SIP define la comunicación a través de dos tipos de mensajes. Las solicitudes (métodos) y las respuestas (códigos de estado) emplean el formato de mensaje genérico establecido en el RFC 2822 , que consiste en una línea inicial seguida de un o más campos de cabecera (headers), una línea vacía que indica el final de las cabeceras, y por último, el cuerpo del mensaje que es opcional.

- Métodos SIPLas peticiones SIP son caracterizadas por la línea inicial del mensaje, llamada Request-Line, que contiene el nombre del método, el identificador del destinatario de la petición (Request-URI) y la versión del protocolo SIP. Existen seis métodos básicos SIP (definidos en RFC 254) que describen las peticiones de los clientes:

- INVITE: Permite invitar un usuario o servicio para participar en una sesión o para modificar parámetros en una sesión ya existente.

- ACK: Confirma el establecimiento de una sesión.- OPTION: Solicita información sobre las capacidades de un servidor.- BYE: Indica la terminación de una sesión.- CANCEL: Cancela una petición pendiente.- REGISTER: Registrar al User Agent.

Sin embargo, existen otros métodos adicionales que pueden ser utilizados, publicados en otros RFCs como los métodos INFO, SUBSCRIBER,etc.

A continuación un ejemplo real de mensaje del método REGISTER:

Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03Content-Length: 0Contact: <sip:20000@192.168.0.100:5060>Call-ID: ED9A8038-A29D-40AB-95B1-0F5F5E905574@192.168.0.100CSeq: 36 REGISTERFrom: <sip:20000@192.168.0.101>;tag=910033437093Max-Forwards: 70To: <sip:20000@192.168.0.101>User-Agent: SJphone/1.60.289a (SJ Labs)Authorization:Digest username="20000",realm="192.168.0.101",nonce="43c52e9d29317c0bf1f885b9aaff1522d93c7692",uri="192.168.0.101",response="f69463b8d3efdb87c388efa9be1a1e63"

- Respuestas (Códigos de estado) SIP.Después de la recepción e interpretación del mensaje de solicitud SIP, el receptor del mismo responde con un mensaje. Este mensaje, es similar al anterior, difiriendo en la línea inicial, llamada Status-Line, que contiene la versión de SIP, el código de la respuesta (Status–Code) y una pequeña descripción (Reason-Phrase). El código de la respuesta está compuesto por tres dígitos que permiten clasificar los diferentes tipos existentes. El primer dígito define la clase de la respuesta.

Código Clases1xx - Mensajes provisionales.2xx - Respuestas de éxito.3xx - Respuestas de redirección.4xx - Respuestas de fallo de método.5xx - Respuestas de fallos de servidor.6xx - Respuestas de fallos globales.

A Continuación, se incluye un ejemplo de un código de respuesta.

Internet Protocol, Src Addr: 192.168.0.101 (192.168.0.101), Dst Addr:192.168.0.100 (192.168.0.100)User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)Session Initiation ProtocolStatus-Line: SIP/2.0 200 OKStatus-Code: 200Resent Packet: False

Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03Content-Length: 0Contact: <sip:20100@192.168.0.100:5060>Call-ID: ED9A8038-A29D-40AB-95B1-0F5F5E905574@100.100.100.16CSeq: 36 REGISTERFrom: <sip:20000@192.168.0.101>;tag=910033437093Max-Forwards: 70To: <sip:20000@192.168.0.101:5060>Authorization: Digest username="20100",realm="192.168.0.101",nonce="43c52e9d29317c0bf1f885b9aaff1522d93c7692",uri="sip:192.168.0.101", response="f69463b8d3efdb87c388efa9be1a1e63"

Cabecera SIP Las cabeceras se utilizan para transportar información necesaria a las entidades SIP. A continuación, se detallan los campos:

- Via: Indica el transporte usado para el envío e identifica la ruta del request, por ello cada proxy añade una línea a este campo.

- From: Indica la dirección del origen de la petición.- To: Indica la dirección del destinatario de la petición.- Call-Id: identificador único para cada llamada y contiene la dirección del host. Debe ser igual para todos

los mensajes dentro de una transacción.- Cseq: Se inicia con un número aleatorio e identifica de forma secuencial cada petición.- Contact : Contiene una (o más) dirección que pueden ser usada para contactar con el usuario.- User Agent: Contiene el cliente agente que realiza la comunicación.

Message HeaderVia: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG4bK646464100000007343c52679000020a600000e45Content-Length: 0Call-ID: 911D32E5-EEDF-4572-B0B2-61B294636E88@192.168.0.100CSeq: 1 ACKFrom: "Prueba"<sip:20000@miasterisk.com>;tag=8922404614682Max-Forwards: 70Route: <sip:20001@192.168.0.1>To: <sip:20001@miasterisk.com>;tag=as0a27b928User-Agent: SJphone/1.60.289a (SJ Labs)Contact: <sip:20100@192.168.0.100:5060>;expires=3600

Direccionamiento SIP Una de las funciones de los servidores SIP es la localización de los usuarios y resolución de nombres. Normalmente, el agente de usuario no conoce la dirección IP del destinatario de la llamada, sino su e-mail.Las entidades SIP identifican a un usuario con las SIP URI (Uniform Resource Identifiers) definido en el RFC 2396. Una SIP URI tiene un formato similar al del e-mail, consta de un usuario y un dominio delimitado por una @, como muestra los siguientes casos:

usuario@dominio, donde dominio es un nombre de dominio completo.usuario@equipo, donde equipo es el nombre de la máquina.usuario@dirección_ip, donde dirección_ip es la dirección IP del dispositivo.número_teléfono@gateway, donde el gateway permite acceder al número de teléfono a través de la red telefónica pública.

La solución de identificación de SIP, también puede ser basada en el DNS descrito en el RFC 3263, donde se describen los procedimientos DNS utilizados por los clientes para traducir una SIP URI en una dirección IP, puerta y protocolo de transporte utilizado, o por los servidores para retornar una respuesta al cliente en caso de que la petición falle.

Protocolo SDP - SIP El protocolo SDP (Session Description Protocol) RFC 2327 se utiliza para describir sesiones multicast en tiempo real, siendo útil para invitaciones, anuncios, y cualquier otra forma de inicio de sesiones.

La propuesta original de SDP fue diseñada para anunciar información necesaria para los participantes y para aplicaciones de multicast MBONE (Multicast Backbone). Actualmente, su uso está extendido para el anuncio y la negociación de las capacidades de una sesión multimedia en Internet.

Puesto que SDP es un protocolo de descripción, los mensajes SDP se pueden transportar mediante distintos protocolos con SIP, SAP, RTSP, correo electrónico con aplicaciones MIME o protocolos como HTTP. Como el SIP, el SDP utiliza la codificación del texto. Un mensaje del SDP se compone de una serie de líneas, denominados campos, dónde los nombres son abreviados por una sola letra, y está en una orden requerida para simplificar el análisis. El SDP no fue diseñado para ser fácilmente extensible.

La única manera de ampliar o de agregar nuevas capacidades al SDP es definir un nuevo atributo. Sin embargo, los atributos desconocidos pueden ser ignorados. En la tabla siguiente podemos observar todos los campos.

Tipo Descripción Obligatorio

V Versión del protocolo (obligatorio) o identificador (obligatorio)S Nombre de sesión (obligatorio)I Información de la sesión (obligatorio)U URI de la descripción e Dirección de correo p Número de teléfono C Información de conexión b Ancho de banda Z Tiempo de corrección K Clave de encriptación a Atributos T Tiempo de sesión(Start y stop) (obligatorio)R Tiempo de repetición m Información del protocolo de transporte(media) (obligatorio)

Session Description Protocol Version (v): 0Owner/Creator, Session Id (o): Cisco-SIPUA 26425 12433 IN IP4192.168.0.100Owner Username: Cisco-SIPUASession ID: 26425Session Version: 12433Owner Network Type: INOwner Address Type: IP4Owner Address: 192.168.0.100Session Name (s): SIP CallConnection Information (c): IN IP4 192.168.0.100Connection Network Type: IN

Connection Address Type: IP4Connection Address: 192.168.0.100Time Description, active time (t): 0 0Session Start Time: 0Session Stop Time: 0Media Description, name and address (m): audio 17338 RTP/AVP 0 8 18 101Media Type: audioMedia Port: 17338Media Proto: RTP/AVPMedia Format: ITU-T G.711 PCMUMedia Format: ITU-T G.711 PCMAFormat: ITU-T G.729Media Format: 101Media Attribute (a): rtpmap:0 PCMU/8000Media Attribute (a): rtpmap:8 PCMA/8000Media Attribute (a): rtpmap:18 G729/8000Media Attribute (a): rtpmap:101 telephone-event/8000Media Attribute (a): fmtp:101 0-15

Ejemplo Comunicación SIP A continuación se analizará detalladamente una llamada. En una llamada SIP hay varias transacciones SIP. Una transacción SIP se realiza mediante un intercambio de mensajes entre un cliente y un servidor. Consta de varias peticiones y respuestas y para agruparlas en la misma transacción esta el parámetro CSeq.

Usuario A Proxy SIP Usuario B

- Las dos primeras transacciones corresponden al registro de los usuarios. Los usuarios deben

registrarse para poder ser encontrados por otros usuarios. En este caso, los terminales envían una petición REGISTER, donde los campos from y to corresponden al usuario registrado. El servidor

Proxy, que actúa como Register, consulta si el usuario puede ser autenticado y envía un mensaje de OK en caso positivo.

- La siguiente transacción corresponde a un establecimiento de sesión. Esta sesión consiste en una petición INVITE del usuario al proxy. Inmediatamente, el proxy envía un TRYING 100 para parar las retransmisiones y reenvía la petición al usuario B. El usuario B envía un Ringing 180 cuando el teléfono empieza a sonar y también es reenviado por el proxy hacia el usuario A. Por ultimo, el OK 200 corresponde a aceptar la llamada (el usuario B descuelga).

- En este momento la llamada está establecida, pasa a funcionar el protocolo de transporte RTP con los parámetros (puertos, direcciones, codecs, etc.) establecidos en la negociación mediante el protocolo SDP.

- La última transacción corresponde a una finalización de sesión. Esta finalización se lleva a cabo con una única petición BYE enviada al Proxy, y posteriormente reenviada al usuario B. Este usuario contesta con un OK 200 para confirmar que se ha recibido el mensaje final correctamente.

Arquitectura H.323

H.323 fue diseñado con un objetivo principal: Proveer a los usuarios con tele-conferencias que tienen capacidades de voz, video y datos sobre redes de conmutación de paquetes.

Las continuas investigaciones y desarrollos de H.323 siguen con la misma finalidad y, como resultado, H.323 se convierte en el estándar óptimo para cubrir esta clase de aspectos. Además, H.323 y la convergencia de voz, video y datos permiten a los proveedores de servicios prestar esta clase de facilidades para los usuarios de tal forma que se reducen costos mientras mejora el desempeño para el usuario.

El estándar fue diseñado específicamente con los siguientes objetivos:- Basarse en los estándares existentes, incluyendo H.320, RTP y Q.931- Incorporar algunas de las ventajas que las redes de conmutación de paquetes ofrecen para

transportar datos en tiempo real.- Solucionar la problemática que plantea el envío de datos en tiempo real sobre redes de

conmutación de paquetes.

Los diseñadores de H.323 saben que los requisitos de la comunicación difieren de un lugar a otro, entre usuarios y entre compañías y obviamente con el tiempo los requisitos de la comunicación también cambian. Dados estos factores, los diseñadores de H.323 lo definieron de tal manera que las empresas que manufacturan los equipos pueden agregar sus propias especificaciones al protocolo y pueden definir otras estructuras de estándares que permiten a los dispositivos adquirir nuevas clases de características o capacidades.

Componentes H.323 H.323 establece los estándares para la compresión y descompresión de audio y vídeo, asegurando que los equipos de distintos fabricantes se intercomuniquen. Así, los usuarios no se tienen que preocupar de cómo el equipo receptor actúa, siempre y cuando cumpla este estándar. Por ejemplo, la gestión del ancho de banda disponible para evitar que la LAN se colapse con la comunicación de audio y vídeo también está contemplada en el estándar, esto se realiza limitando el número de conexiones simultáneas.

También la norma H.323 hace uso de los procedimientos de señalización de los canales lógicos contenidos en la norma H.245, en los que el contenido de cada uno de los canales se define cuando se abre. Estos procedimientos se proporcionan para fijar las prestaciones del emisor y receptor, el establecimiento de la llamada, intercambio de información, terminación de la llamada y como se codifica y decodifica. Por ejemplo, cuando se origina una llamada telefónica sobre Internet, los dos terminales deben negociar cual de

los dos ejerce el control, de manera tal que sólo uno de ellos origine los mensajes especiales de control. Un punto importante es que se deben determinar las capacidades de los sistemas, de forma que no se permita la transmisión de datos si no pueden ser gestionados por el receptor.

Como se ha visto, este estándar define un amplio conjunto de características y funciones, algunas son necesarias y otras opcionales. Pero el H.323 define mucho más que las funciones, este estándar define los siguientes componentes más relevantes:

• Terminal• GateWay• Gatekeeper• Unidad de Control Multipunto• Controlador Multipunto• Procesador Multipunto• Proxy H.323

1. TerminalUn terminal H.323 es un extremo de la red que proporciona comunicaciones bi direccionales en tiempo real con otro terminal H.323, gateway o unidad de control multipunto (MCU). Esta comunicación consta de señales de control, indicaciones, audio, imagen en color en movimiento y /o datos entre los dos terminales. Conforme a la especificación, un terminal H.323 puede proporcionar sólo voz, voz y datos, voz y vídeo, o voz, datos y vídeo.

Un terminal H.323 consta de las interfaces del equipo de usuario, el códec de video, el códec de audio, el equipo telemático, la capa H.225, las funciones de control del sistema y la interfaz con la red por paquetes.

a. Equipos de adquisición de información: Es un conjunto de cámaras, monitores, dispositivos de audio (micrófono y altavoces) y aplicaciones de datos, e interfaces de usuario asociados a cada uno de ellos.

b. Códec de audio: Todos los terminales deberán disponer de un códec de audio, para codificar y decodificar señales vocales (G.711), y ser capaces de transmitir y recibir ley A y ley μ. Un terminal puede, opcionalmente, ser capaz de codificar y decodificar señales vocales. El terminal H.323 puede, opcionalmente, enviar más de un canal de audio al mismo tiempo, por ejemplo, para hacer posible la difusión de 2 idiomas.

c. Códec de video: En los terminales H.323 es opcional.

d. Canal de datos: Uno o más canales de datos son opcionales. Pueden ser unidireccionales o bi direccionales.

e. Retardo en el trayecto de recepción: Incluye el retardo añadido a las tramas para mantener la sincronización, y tener en cuenta la fluctuación de las llegadas de paquetes. No suele usarse en la transmisión sino en recepción, para añadir el retardo necesario en el trayecto de audio para, por ejemplo, lograr la sincronización con el movimiento de los labios en una videoconferencia.

f. Unidad de control del sistema: Proporciona la señalización necesaria para el funcionamiento adecuado del terminal. Está formada por tres bloques principales: Función de control H.245, función de señalización de llamada H.225 y función de señalización RAS.

• Función de control H.245: Se utiliza el canal lógico de control H.245 para llevar mensajes de control extremo a extremo que rige el modo de funcionamiento de la entidad H.323. Se ocupa de negociar las capacidades (ancho de banda) intercambiadas, de la apertura y cierre de los canales lógicos y de los mensajes de control de flujo. En cada llamada, se puede transmitir cualquier número de canales lógicos

de cada tipo de medio (audio, video, datos) pero solo existirá un canal lógico de control, el canal lógico 0.

• Función de señalización de la llamada H.225: Utiliza un canal lógico de señalización para llevar mensajes de establecimiento y finalización de la llamada entre 2 puntos extremos H.323. El canal de señalización de llamada es independiente del canal de control H.245. Los procedimientos de apertura y cierre de canal lógico no se utilizan para establecer el canal de señalización. Se abre antes del establecimiento del canal de control H.245 y de cualquier otro canal lógico. Puede establecerse de terminal a terminal o de terminal a gatekeeper.

• Función de control RAS (Registro, Admisión, Situación): Utiliza un canal lógico de señalización RAS para llevar a cabo procedimientos de registro, admisión, situación y cambio de ancho de banda entre puntos extremos (terminales, gateway..) y el gatekeeper. Sólo se utiliza en zonas que tengan un gatekeeper. El canal de señalización RAS es independiente del canal de señalización de llamada, y del canal de control H.245. Los procedimientos de apertura de canal lógico H.245 no se utilizan para establecer el canal de señalización RAS. El canal de señalización RAS se abre antes de que se establezca cualquier otro canal entre puntos extremos H.323.

g. Capa H.225: Se encarga de dar formato a las tramas de video, audio, datos y control transmitidos en mensajes de salida hacia la interfaz de red y de recuperarlos de los mensajes que han sido introducidos desde la interfaz de red. Además lleva a cabo también la alineación de trama, la numeración secuencial y la detección/corrección de errores.

h. Interfaz de red de paquetes: Es específica en cada implementación. Debe proveer los servicios descritos en la recomendación H.225. Esto significa que el servicio extremo a extremo fiable (por ejemplo, TCP) es obligatorio para el canal de control H.245, los canales de datos y el canal de señalización de llamada.

El servicio de extremo a extremo no fiable (UDP, IPX) es obligatorio para los canales de audio, los canales de video y el canal de RAS. Estos servicios pueden ser dúplex o símplex y de unicast o multicast dependiendo de la aplicación, las capacidades de los terminales y la configuración de la red.

2. GatewayUn gateway H.323 es un extremo que proporciona comunicaciones bi direccionales en tiempo real entre terminales H.323 en la red IP y otros terminales o gateways en una red conmutada. En general, el propósito del gateway es reflejar transparentemente las características de un extremo en la red IP a otro en una red conmutada y viceversa.

3. GatekeeperEl gatekeeper es una entidad que proporciona la traducción de direcciones y el control de acceso a la red de los terminales H.323, gateways y MCUs. El gatekeeper puede también ofrecer otros servicios a los terminales, gateways y MCUs, tales como gestión del ancho de banda y localización de los gateways.

El Gatekeeper realiza dos funciones de control de llamadas que preservan la integridad de la red corporativa de datos. La primera es la traslación de direcciones de los terminales de la LAN a las correspondientes IP o IPX, tal y como se describe en la especificación RAS. La segunda es la gestión del ancho de banda, fijando el número de conferencias que pueden estar dándose simultáneamente en la LAN y rechazando las nuevas peticiones por encima del nivel establecido, de manera tal que se garantice ancho de banda suficiente para las aplicaciones de datos sobre la LAN.

El Gatekeeper proporciona todas las funciones anteriores para los terminales, Gateways y MCUs, que están registrados dentro de la denominada Zona de control H.323. Además de las funciones anteriores, el Gatekeeper realiza los siguientes servicios de control:

- Control de admisiones: El gatekeeper puede rechazar aquellas llamadas procedentes de un terminal por ausencia de autorización a terminales o gateways particulares de acceso restringido o en determinadas franjas horarias.

- Control y gestión de ancho de banda: Para controlar el número de terminales H.323 a los que se permite el acceso simultáneo a la red, así como el rechazo de llamadas tanto entrantes como salientes para las que no se disponga de suficiente ancho de banda.

- Gestión de la zona: Lleva a cabo el registro y la admisión de los terminales y gateways de su zona. Conoce en cada momento la situación de los gateways existentes en su zona que encaminan las conexiones hacia terminales RCC.

4. MCULa Unidad de Control Multipunto está diseñada para soportar la conferencia entre tres o más puntos, bajo el estándar H.323, llevando la negociación entre terminales para determinar las capacidades comunes para el proceso de audio y vídeo y controlar la multi difusión.

5. CONTROLADOR MULTIPUNTOUn controlador multipunto es un componente de H.323 que provee capacidad de negociación con todos los terminales para llevar a cabo niveles de comunicaciones. También puede controlar recursos de conferencia tales como multicasting de vídeo. El Controlador Multipunto no ejecuta mezcla o conmutación de audio, vídeo o datos.

6. PROCESADOR MULTIPUNTOUn procesador multipunto es un componente de H.323 de hardware y software especializado, mezcla, conmuta y procesa audio, vídeo y / o flujo de datos para los participantes de una conferencia multipunto de tal forma que los procesadores del terminal no sean pesadamente utilizados. El procesador multipunto puede procesar un flujo medio único o flujos medio múltiples dependiendo de la conferencia soportada.

7. PROXY H.323Un proxy H.323 es un servidor que provee a los usuarios acceso a redes seguras de unas a otras confiando en la información que conforma la recomendación H.323.El Proxy H.323 se comporta como dos puntos remotos H.323 que envían mensajes call – set up, e información en tiempo real a un destino del lado seguro del firewall.

Pila de protocolos H.323 A continuación se explican los protocolos más significativos para H.323:- RTP/RTCP (Real-Time Transport Protocol / Real-Time Transport Control Protocol) Protocolos de

transporte en tiempo real que proporcionan servicios de entrega punto a punto de datos.- RAS (Registration, Admission and Status): Sirve para registrar, control de admisión, control del

ancho de banda, estado y desconexión de los participantes.- H225.0: Protocolo de control de llamada que permite establecer una conexión y una desconexión.- H.245: Protocolo de control usado en el establecimiento y control de una llamada.

En concreto presenta las siguientes funcionalidades:1. Intercambio de capacidades: Los terminales definen los códecs de los que disponen y se lo comunican al

otro extremo de la comunicación.2. Apertura y cierre de canales lógicos: Los canales de audio y video H.323 son punto a punto y

unidireccionales. Por lo tanto, en función de las capacidades negociadas, se tendrán que crear como mínimo dos de estos canales. Esto es responsabilidad de H.245.

3. Control de flujo cuando ocurre algún tipo de problema.4. Multitud de otras pequeñas funciones.

- Q.931: (Digital Subscriber Signalling) Este protocolo se define para la señalización de accesos RDSI básico.

- RSVP (Resource ReSerVation Protocol): Protocolo de reserva de recursos en la red para cada flujo de información de usuario.

- T.120: La recomendación T.120 define un conjunto de protocolos para conferencia de datos.

Entre los codecs que recomienda usar la norma H.323 se encuentran principalmente:- G.711: De los múltiples códecs de audio que pueden implementar los terminales H.323, este es el único

obligatorio. Usa modulación por pulsos codificados (PCM) para conseguir tasas de bits de 56Kbps y 64Kbps.

- H.261y H.263: Los dos códecs de video que propone la recomendación H.323. Sin embargo, se pueden usar otros.

Señalización H.323 La función de señalización está basada en la recomendación H.225, que especifica el uso y soporte de mensajes de señalización Q.931/Q932. Las llamadas son enviadas sobre TCP por el puerto 1720. Sobre este puerto se inician los mensajes de control de llamada Q.931 entre dos terminales para la conexión, mantenimiento y desconexión de llamadas.Los mensajes más comunes de Q.931/Q.932 usados como mensajes de señalización H.323 son:- Setup. Es enviado para iniciar una llamada H.323 para establecer una conexión con una entidad H.323.

Entre la información que contiene el mensaje se encuentra la dirección IP, puerto y alias del llamante o la dirección IP y puerto del llamado.

- Call Proceeding. Enviado por el Gatekeeper a un terminal advirtiendo del intento de establecer una llamada una vez analizado el número llamado.

- Alerting. Indica el inicio de la fase de generación de tono.- Connect. Indica el comienzo de la conexión.- Release Complete. Enviado por el terminal para iniciar la desconexión.- Facility. Es un mensaje de la norma Q.932 usado como petición o reconocimiento de un servicio

suplementario.

Función de control H.245EL canal de control H.245 es un conjunto de mensajes ASN.1 usados para el establecimiento y control de una llamada. Unas de las características que se intercambian más relevantes son:- MasterSlaveDetermination (MSD). Este mensaje es usado para prevenir conflictos entre dos terminales

que quieren iniciar la comunicación. Decide quién actuará de Master y quién de Slave.- TerminalCapabilitySet (TCS). Mensaje de intercambio de capacidades soportadas por los terminales que

intervienen en una llamada.- OpenLogicalChannel (OLC). Mensaje para abrir el canal lógico de información contiene información para

permitir la recepción y codificación de los datos. Contiene la información del tipo de datos que serán transportados.

- CloseLogicalChannel (CLC). Mensaje para cerrar el canal lógico de información.

Ejemplo H.323 A continuación se analizará detalladamente una llamada. En una llamada H.323 hay varias fases como se indica en el siguiente gráfico y varios protocolos cada uno de un color.

Una llamada H.323 se caracteriza por las siguientes fases:

1. ESTABLECIMIENTO- En esta fase lo primero que se observa es que uno de los terminales se registra en el gatekeeper

utilizando el protocolo RAS (Registro, admisión y estado) con los mensajes ARQ y ACF.

- Posteriormente utilizando el protocolo H.225 (que se utiliza para establecimiento y liberación de la llamada) se manda un mensaje de SETUP para iniciar una llamada H.323. Entre la información que contiene el mensaje se encuentra la dirección IP, puerto y alias del llamante o la dirección IP y puerto del llamado.

- El terminal llamado contesta con un CALL PROCEEDING advirtiendo del intento de establecer una llamada.

- En este momento el segundo terminal tiene que registrarse con el gatekeeper utilizando el protocolo RAS de manera similar al primer terminal

- El mensaje ALERTING indica el inicio de la fase de generación de tono.- Y por último CONNECT indica el comienzo de la conexión.

2. SEÑALIZACIÓN DE CONTROL - En esta fase se abre una negociación mediante el protocolo H.245 (control de conferencia), el

intercambio de los mensajes (petición y respuesta) entre los dos terminales establecen quién será master y quién slave, las capacidades de los participantes y codecs de audio y video a utilizar. Como punto final de esta negociación se abre el canal de comunicación (direcciones IP, puerto). Los principales mensajes H.245 que se utilizan en esta fase son:

o TerminalCapabilitySet (TCS). Mensaje de intercambio de capacidades soportadas por los terminales que intervienen en una llamada.

o OpenLogicalChannel (OLC). Mensaje para abrir el canal lógico de información que contiene información para permitir la recepción y codificación de los datos. Contiene la información del tipo de datos que será transportado.

3. AUDIOLos terminales inician la comunicación y el intercambio de audio (o video) mediante el protocolo RTP/RTCP.

4. DESCONEXIÓN- En esta fase cualquiera de los participantes activos en la comunicación puede iniciar el proceso de

finalización de llamada mediante mensajes CloseLogicalChannel y EndSessionComand de H.245. - Posteriormente utilizando H.225 se cierra la conexión con el mensaje RELEASE COMPLETE- Por último se liberan los registros con el gatekeeper utilizando mensajes del protocolo RAS:

IAX vs. SIP - Comparación entre IAX y SIP

IAX fue creado por Mark Spencer (también creador de AsterisK) para paliar una serie de problemas o inconvenientes que se encontró al utilizar SIP en VoIP y que pensó que debía ser mejorado.

Las principales diferencias ente IAX y SIP son las siguientes:- Ancho de banda. IAX utiliza un menor ancho de banda que SIP ya que los mensajes son codificados de forma binaria mientras que en SIP son mensajes de texto. Asimismo, IAX intenta reducir al máximo la información de las cabeceras de los mensajes reduciendo también el ancho de banda.

- NATEn IAX la señalización y los datos viajan conjuntamente con lo cual se evitan los problemas de NAT que frecuentemente aparecen en SIP. En SIP la señalización y los datos viajan de manera separada y por eso aparecen problemas de NAT en el flujo de audio cuando este flujo debe superar los routers y firewalls. SIP suele necesitar un servidor STUN para estos problemas.

- Estandarización y usoSIP es un protocolo estandarizado por la IETF hace bastante tiempo y que es ampliamente implementado por todos los fabricantes de equipos y software. IAX está aun siendo estandarizado y es por ello que no se encuentra en muchos dispositivos existentes en el mercado.

- Utilización de puertosIAX utiliza un solo puerto (4569) para mandar la información de señalización y los datos de todas sus llamadas. Para ello utiliza un mecanismo de multiplexión o "trunking". SIP, sin embargo utiliza un puerto (5060) para señalización y 2 puertos RTP por cada conexión de audio (como mínimo 3 puertos). Por ejemplo para 100 llamadas simultáneas con SIP se usarían 200 puertos (RTP) más el puerto 5060 de señalización. IAX utilizaría sólo un puerto para todo (4569).

- Flujo de audio al utilizar un servidorEn SIP si utilizamos un servidor la señalización de control pasa siempre por el servidor pero la información de audio (flujo RTP) puede viajar extremo a extremo sin tener que pasar necesariamente por el servidor SIP. En IAX al viajar la señalización y los datos de forma conjunta todo el tráfico de audio debe pasar obligatoriamente por el servidor IAX. Esto produce una aumento en el uso del ancho de banda que deben soportar los servidores IAX sobretodo cuando hay muchas llamadas simultáneas.

- Otras funcionalidadesIAX es un protocolo pensado para VoIP y transmisión de video y presenta funcionalidades interesantes como la posibilidad de enviar o recibir planes de marcado (dialplans) que resultan muy interesante al usarlo conjuntamente con servidores Asterisk. SIP es un protocolo de propósito general y podría transmitir sin dificultad cualquier información y no sólo audio o video.

¿Que es Asterisk? - Introducción a AsteriskAsterisk es una centralita software (PBX) de código abierto. Como cualquier centralita PBX permite interconectar teléfonos y conectar dichos teléfonos a la red telefónica convencional (RTB - Red telefónica básica)- Su nombre viene del símbolo asterisco (*) en inglés.

El creador original de esta centralita es Mark Spencer de la compañía Digium que sigue siendo el principal desarrollador de las versiones estables. Pero al ser de código libre, existen multitud de desarrolladores que han aportado funciones y nuevas aplicaciones. Originalmente fue creada para sistemas Linux pero hoy en día funciona también en sistemas OpenBSD, FreeBSD, Mac OS X, Solaris Sun y Windows. Pero Linux sigue siendo la que mas soporte presenta.

El paquete básico de Asterisk incluye muchas características que antes sólo estaban disponibles en caros sistemas propietarios como creación de extensiones, envío de mensajes de voz a e-mail, llamadas en conferencia, menús de voz interactivos y distribución automática de llamadas. Además se pueden crear nuevas funcionalidades mediante el propio lenguaje de Asterisk o módulos escritos en C o mediante scripts AGI escritos en Perl o en otros lenguajes.

Para poder utilizar teléfonos convencionales en un servidor Linux corriendo Asterisk o para conectar a una línea de teléfono analógica se suele necesitar hardware especial (no vale con un modem ordinario). Digium y otras compañías venden tarjetas para este fin.

Pero quizás lo más interesante es que Asterisk soporta numerosos protocolos de VoIP como SIP y H.323. Asterisk puede operar con muchos teléfonos SIP, actuando como "registrar" o como "gateway" o entre teléfonos IP y la red telefónica convencional. Los desarrolladores de Asterisk han diseñado un nuevo protocolo llamado IAX para una correcta optimización de las conexiones entre centralitas Asterisk.

Al soportar una mezcla de la telefonía tradicional y los servicios de VoIP, Asterisk permite a los desarrolladores construir nuevos sistemas telefónicos de forma eficiente o migrar de forma gradual los sistemas existentes a las nuevas tecnologías. Algunos sitios usan Asterisk para reemplazar a antiguas centralitas propietarias, otros para proveer funcionalidades adicionales y algunas otras para reducir costos en llamadas a larga distancia utilizando Internet.

Asterisk para linux

La página de referencia es http://www.asterisk.org/Nos descargamos la versión 1.6.1.6 y lo descomprimimos1) # tar -zxvf asterisk-1.6.1.6.tar.gz# rm -f asterisk-1.6.1.6.tar.gz# cd asterisk-1.6.1.62) ejecutar "make"Suponiendo que todo ha ido correctamente3) ejecutar "make install"Si es la primera vez que instalas la centralita Asterisk es recomendable instalar los ejemplos con el comando4) "make samples"Pero recuerda que este comando sobrescribirá todos los ficheros de configuración que ya tengas. Finalmente puedes arrancar el Asterisk con el comando: # asterisk –vvvcVerás un montón de mensajes en la pantalla cuando Asterisk se inicializa. (las vvv pertenecen al modo " very very verbose" y la c a que nos mostrará al final una línea de comandos en forma consola)*CLI>A partir de este momento ya está Asterisk instalado y funcionando. Se puede utilizar el comando "help" para ayuda.

También puedes utilizar el comando "man asterisk" en la línea de comandos de linux para obtener detalles de como arrancar y parar el servidor Asterisk.Los ficheros de configuración de Asterisk se habrán instalado en el directorio /etc/asterisk donde podrás encontrar un montón de información.

Vamos a comprobar que funciona:Configuramos un softphone como el SJPhone (para más info consultar configuración del sjphone) para poder acceder a nuestro propio Asterisk. La configuración que hemos hecho trae dos usuarios por defecto que podemos utilizar:

A: usuario: 3000 password=cualquiera vale B: usuario: 3001 password=cualquiera vale

Una vez que lo tenemos configurado y el usuario se ha registrado correctamente en nuestro servidor podemos llamar a algunos números de prueba que vienen por defecto en el plan de numeración:

1000 - Menú principal 1234 - Pasar llamada a la consola (se verá en la consola la llamada) 1235 - Contestador automático de la consola1236 - Llamar a la consola 3000 - Llamar al usuario SIP 3000 3001 - Llamar al usuario SIP 3001500 - Llamar a Digium600 - Prueba de eco8500 - Menú del contestador 99990 Test AGI 99991 Test EAGI 99992 Dice la hora 99999 Suena música de manera infinita 700 Deja aparcada la llamada 701-720 Llamadas aparcadas

Una buena prueba en este momento es configurar 2 softphones en dos ordenadores diferentes; uno con el usuario 3000 y otro con el usuario 3001 e intentar hacer una llamada entre ambos. Si funciona podemos pasar a aprender a configurar Asterisk y crear nuevos usuarios y planes de numeración.

Asterisk para WindowsAsterisk puede ser instalado en Windows. Aunque es preferible para aplicaciones comerciales instalarlo bajo Linux o FreeBSD es una buena manera de conocer su funcionamiento y de probar numerosos comandos y opciones.

La página de referencia es http://www.asteriskwin32.com

Nos descargamos la versión Setup0.66.exe y ejecutamos el programa de instalación. En principio seleccionamos la "full instalation" que nos instalará ejemplos de los ficheros de configuración.

Una vez acabada la instalación debemos arrancar el servidor asterisk. Para ello podemos ejecutar C:\cygroot\bin\asteriskwin32.exe

Al principio nos saldrán unos cuantos errores o warnings pero no nos preocupamos demasiado (son debido a que no tenemos tarjetas RDSI o modems TAPI). En principio ya tenemos instalado y funcionando Asterisk. Vamos a comprobar que funciona.

Configuramos un softphone como el SJPhone (para más info consultar configuración del sjphone) para poder acceder a nuestro propio Asterisk. La configuración que hemos hecho trae dos usuarios por defecto que podemos utilizar:

A: usuario: 3000 password=cualquiera vale B: usuario: 3001 password=cualquiera vale

Una vez que lo tenemos configurado y el usuario se ha registrado correctamente en nuestro servidor podemos llamar a algunos números de prueba que vienen por defecto en el plan de numeración:

1000 - Menú principal 1234 - Pasar llamada a la consola (Veras en la consola la llamada) 1235 - Contestador automático de la consola1236 - Llamar a la consola 3000 - Llamar al usuario SIP 3000 3001 - Llamar al usuario SIP 3001500 - Llamar a Digium600 - Prueba de eco8500 - Menú del contestador 99990 Test AGI 99991 Test EAGI 99992 Dice la hora 99999 Suena música de manera infinita 700 Deja aparcada la llamada 701-720 Llamadas aparcadas

Una buena prueba en este momento es configurar 2 softphones en dos ordenadores diferentes; uno con el usuario 3000 y otro con el usuario 3001 e intentar hacer una llamada entre ambos. Si funciona podemos pasar a aprender a configurar Asterisk y crear nuevos usuarios y planes de numeración.

Primeros pasos con Asterisk

Una vez instalado Asterisk en Windows o Linux vamos con un ejemplo sencillo de las primeras cosas que podemos hacer. Este ejemplo consiste en crear dos nuevas extensiones con sus buzones de voz.

1. Vamos a crear dos usuarios SIP nuevos. Por ejemplo los usuarios "20000" y "20100" con contraseñas "a20000b" y "b20100a"Para ello vamos al fichero sip.conf y añadimos las siguientes líneas al final del fichero:

[20000]type=friendsecret=a20000bqualify=yes nat=no host=dynamic canreinvite=no context=miprimerejemplomailbox=20000@miprimerbuzon

[20100]type=friendsecret=b20100aqualify=yes nat=no host=dynamic canreinvite=no context=miprimerejemplomailbox=20100@miprimerbuzon

Para más información del ficherop sip.conf ir información sobre sip.conf.

2. Vamos a crear las extensiones para esos usuarios Vamos a crear las extensiones para esos usuarios en el fichero extensions.conf de manera que si marcamos el 20000 hablaremos con el usuario 20000 y si marcamos el 20100 hablaremos con el usuario 20100. También creamos el número del buzón de voz para consultar los mensajes para que sea el 30000.

Añadimos las siguientes líneas al final del fichero extensions.conf

[miprimerejemplo]exten => 20000,1,Dial(SIP/20000,30,Ttm) exten => 20000,2,Hangup exten => 20000,102,Voicemail(20000)exten => 20000,103,Hangup exten => 20100,1,Dial(SIP/20100,30,Ttm) exten => 20100,2,Hangup exten => 20100,102,Voicemail(20100)exten => 20100,103,Hangup

exten => 30000,1,VoicemailMain

Para más información del fichero extensions.conf ir información sobre extensions.conf.

3. Vamos a crear las buzones de voz para esos usuarios Vamos a crear los buzones de voz de ambos usuarios y asignarles una contraseña en el fichero voicemail.conf. Al buzón 20000 le vamos a dar la contraseña 1234 y al buzón 20100 la contraseña 4321

[miprimerbuzon]20000 => 1234,Pedro,pedro@midominio.com20100 => 4321,Juan,juan@midominio.com

Para más información del ficherop voicemail.conf ir información sobre voicemail.conf .

4. Reiniciamos el asterisk

5. Configuramos un softphoneConfiguramos uno o dos softphones y probamos a llamar entre ambos usuarios o a dejar mensajes en el contestador cuando no están disponibles. También podemos llamar al número 30000 para escuchar nuestros mensajes. Para más información de como configurar el sjphone ir configuración del sjphone Configuración del archivo sip.conf

El archivo sip.conf sirve para configurar todo lo relacionado con el protocolo SIP y añadir nuevos usuarios o conectar con proveedores SIP.

Aquí hay un ejemplo básico del archivo sip.conf:

[general]context=defaultport=5060 ; Puerto UDP en el que responderá el Asterisk bindaddr=0.0.0.0 ; Si queremos especificar que Asterisk esté en una IP (si un equipo tiene 3 IPs por Ej.) 0.0.0.0 vale para cualquiera srvlookup=yes ; Habilita servidor DNS SRV

[pedro]type=friendsecret=welcomequalify=yes ;Tiempo de latencia no superior a 2000 ms. nat=no ; El teléfono no usa NAT host=dynamic ; El dispositivo se registra con una IP variante canreinvite=no ; Asterisk por defecto trata de redirigir context=internal ; El contexto que controla todo esto

El fichero sip.conf comienza con una sección [general] que contiene la configuración por defecto de todos los usuarios y "peers" (proveedores). Se puede sobrescribir los valores por defecto en las configuraciones de cada usuario o peer.

- En general los servidores SIP escuchan en el puerto 5060 UDP. Por tanto configuramos port=5060 . En algunos casos, por ejemplo si utilizamos SER (Sip Express Router) con Asterisk debemos cambiar este puerto.

- DNS es una forma de configurar una dirección lógica para que pueda ser resuelta. Esto permite que las llamadas sean enviadas a diferentes lugares sin necesidad de cambiar la dirección lógica. Usando el DNS SRV se ganan las ventajas del DNS mientras que deshabilitándolo no es posible enrutar llamadas en base a nombre de dominios. Conviene tenerlo activado, por tanto se pone la directiva srvlookup=yes.

Cada extensión está definida por un user o usuario, un peer o proveedor o un friend o amigo y viene definida con un nombre entre corchetes [].

- El tipo (type) "user" se usa para autenticar llamadas entrantes, "peer" para llamadas salientes y "friend" para ambas. En nuestro caso hemos definido una extensión pedro como "friend". Puede realizar y recibir llamadas.

- Secret es la contraseña usada para la autenticación. En este caso será "welcome". - Se puede monitorizar la latencia entre el servidor Asterisk y el teléfono con qualify=yes para

determinar cuando el dispositivo puede ser alcanzado En este caso Asterisk considera por defecto que un dispositivo está presente si su latencia es menor de 2000 ms (2 segundos). Se puede cambiar este valor poniendo el número de milisegundos en vez de yes.

- Si una extensión está detrás de un dispositivo que realiza NAT (Network Address Translation) como un router o firewall se puede configurar nat=yes para forzar a Asterisk a ignorar el campo información de contacto y usar la dirección desde la que vienen los paquetes.

- Si ponemos host=dynamic quiere decir que el teléfono se podrá conectar desde cualquier dirección IP. Podemos limitar a que dicho usuario solo pueda acceder con una IP o con un nombre de dominio. Si ponemos host=static no haría falta que el usuario se registrará con la contraseña proporcionada en "secret".

- También se ha puesto canreinvite=no. En SIP los invites se utilizan para establecer llamadas y redirigir el audio o video. Cualquier invite después del invite inicial en la misma conversación se considera un reinvite. Cuando dos usuarios han establecido la comunicación con canreinvite= yes (por defecto) los paquetes RTP de audio podrían ser enviados extremo a extremo sin pasar por el servidor Asterisk. Esto, normalmente, no suele ser conveniente en casos en los que haya NAT en alguno de los clientes. (NAT=yes). Usando canreinvite=no se fuerza a Asterisk a estar en medio no permitiendo que los puntos finales intercambien mensajes RTP directamente. De todos modos, existen numerosas condiciones en que Asterisk no permite el reinvite a pesar de que no pongamos esta condición ya que necesita controlar el flujo RTP. Por ejemplo: Si los clientes usan codecs diferentes, si hay opciones de Music On hold o temporizadores en la llamada, etc ...

- Por último context=internal indica el contexto donde está las instrucciones para dicha extensión. Esto está relacionado con el contexto del archivo extensions.conf que marca el plan de numeración para ese contexto. Por tanto el contexto internal debe existir en el fichero extensions.conf o de lo contrario deberíamos crearlo. Varios extensiones pueden tener el mismo contexto.

Opciones avanzadas:

En las siguientes columnas tenemos las posibilidades de configuración para los tipos "user" y "peer". En el caso de "friend" valen las dos tablas ya que un "friend" es a la vez ambos. User Peer Explicación y opciones

context context Indica el contexto asociado en el dialplan para un usuario o peer

permit permit Permitir una IP

deny deny No permitir una IP

secret secret Contraseña para el registro

md5secret md5secret Contraseña encriptada con md5

dtmfmode dtmfmode El modo en el que se transmiten los tonos. Pueden ser "RFC2833" o "INFO"

canreinvite canreinviteCon "no" se fuerza a Asterisk a no permitir que los puntos finales intercambienmensajes RTP directamente.

nat nat Indica si el dispositivo está detrás de un NAT con "yes"

callgroup callgroup Define un grupo de llamadas

pickupgroup pickupgroup Define el grupo de llamadas validas para una aplicación pickup()

language languageDefine las señales para un país. Debe estar presente en el archivo indications.conf

allow allow permite habilitar un codec. Pueden ponerse varios en un mismo usuario Posibles Valores:

"allow=all" ,"allow=alaw", "allow=ulaw", "allow=g723.1" ; allow="g729" , "allow=ilbc" , "allow=gsm".

disallow disallow permite deshabilitar un codec. Puede tomar los mismos valores que allow

insecure insecureDefine como manejar las conexiones con peers Tiene los siguientes valores very|yes|no|invite|port Por defecto es "no" que quiere decir que hay que autenticarse siempre.

trustpid trustpid Si la cabecera Remote-Party-ID es de confianza. Por defecto "no"

progressinband progressinband Si se deben generar señales en banda siempre. Por defecto never

promiscredir promiscredir Permite soportar redirecciones 302. Por defecto "no"

callerid Define el identificador cuando no hay ninguna otra información disponible

accountcode Los usuarios pueden estar asociados con un accountcode . Se usa para facturación.

amaflags Se usa para guardar en los CDR y temas de facturación . Puede ser "default", "omit", "billing", o "documentation"

incominglimit Limite de llamadas simultaneas para un cliente

restrictcid Se usa para esconder el ID del llamante. Anticuada y en desuso

mailbox Extensión del contestador

usernameSi Asterisk actúa como cliente SIP este es el nombre de usuario que presenta en el servidor SIP al que llama

fromdomain Pone el campo From: de los mensajes SIP

regexten

fromuser Pone el nombre de usuario en el from por encima de lo que diga el callerID

host

dirección o host donde se encuentra el dispositivo remoto. Puede tomar valores:- Una IP o un host concreto- "dynamic" con lo que valdría cualquier IP pero necesita contraseña - "static" vale cualquier IP pero no es necesario contraseña

mask

port Puerto UDP en el que responderá el Asterisk

qualify Para determinar cuando el dispositivo puede ser alcanzado

defaultip IP por defecto del cliente host= cuando es especificado como "dynamic"

rtptimeout Termina la llamada cuando llega a ese timeout si no ha habido tráfico rtp

rtpholdtimeoutTermina la llamada cuando llega a ese timeout si no ha habido tráfico rtp "on hold"

Ejemplos:

[grandstream1]type=friend ; es peer y user a la vez context=micontexto ; nombre del contexto username=grandstream1 ; suele ser el mismo que el titulo de la sección fromuser=grandstream1 ; sobreescribe el callerid callerid=Jose Dos<1234> host=192.168.0.23 ; se tiene una IP privada dentro de una LAN nat=no ; no hay NAT canreinvite=yes ; dtmfmode=info ; puede ser RFC2833 o INFOmailbox=1234@default ; mailbox 1234 en el contexto "default" del fichero voicemail.confdisallow=all ; deshabilitamos todo allow=ulaw ; Permitimos el codec ulaw

; listed with allow= does NOT matter! ;allow=alaw ;allow=g723.1 ; Asterisk solo soporta g723.1 a través ;allow=g729 ; Licencia g729 solo a través

[xlite1] ;Se puede activar la supresión de silencio ;Xlite manda paquetes NAT keep-alive, por tanto qualify=yes no es necesario type=friend username=xlite1 callerid="juan Perez " <5678> host=dynamic ; el softphone xlite puede estar en cualquier IP nat=yes ; X-Lite está detrás de un dispositivo NAT canreinvite=no ; Se suele poner NO si está detrás de un dispositivo que hace NAT disallow=all allow=gsm ; GSM consume menos ancho de banda que alaw o ulawallow=ulaw allow=alaw

[user1_snomsip] type=friend secret=blah ; en este caso es la contraseña para registrarsehost=dynamic dtmfmode=inband ; las posibilidades son inband (en banda), rfc2833, o info defaultip=192.168.0.59 ; la IP del dispositivo mailbox=1234; Contestador para mensajes disallow=all allow=ulaw ; dado que se ha elegido en banda (inband) para el dtmf se debe seleccionar alaw o ulaw (G.711) allow=alaw [user2_pingtel] type=friend username=user2_pingtel secret=blah host=dynamic qualify=1000 ; Se considera caído si pasa más de 1 segundo sin contestarcallgroup=1,3-4 ; Es miembro de los grupos 1,3 y 4 pickupgroup=1,3-4 ; Se puede hacer un "pickup" para los grupos 1,2 y 4 defaultip=192.168.0.60 ;IPdisallow=all allow=ulaw allow=alaw allow=g729

[user3_cisco]type=friend username=user3_cisco secret=blah nat=yes ; El teléfono está nateado host=dynamic canreinvite=no ; qualify=200 ; Tiempo de 200 ms para recibir respuesta defaultip=192.168.0.4 disallow=all

allow=ulaw allow=alaw allow=g729

[user4_cisco1] type=friendusername=user4_cisco fromuser=pedro ; secret=blah defaultip=192.168.0.4 ; amaflags=default ; Las posibilidades son default, omit, billing o documentation accountcode=pedro ; Para propósitos de tarificación disallow=all allow=ulaw allow=alaw allow=g729 allow=g723.1

Configuración del archivo extensions.conf (DialPlan)

El archivo extensions.conf es el más importante del Asterisk y tiene como misión principal definir el dialplan o plan de numeración que seguirá la centralita para cada contexto y por tanto para cada usuario.

El fichero extensions.conf se compone de secciones o contextos entre corchetes []Hay dos contextos especiales que están siempre presentes que son [general] y [globals]

Contexto [general] El contexto [general] configura unas pocas opciones generales como son:

- static : Indica si se ha de hacer caso a un comando "save dialplan" desde la consola. Por defecto es "yes". Funciona en conjunto con "writeprotect"

- writeprotect : Si writeprotect=no y static=yes se permite ejecutar un comando "save dialplan" desde la consola. El valor por defecto es " no" .

- autofallthrough : Si está activado y una extensión se queda sin cosas que hacer termina la llamada con BUSY, CONGESTION o HANGUP Si no está activada se queda esperando otra extensión. Nunca debería suceder que una extensión se quede sin cosas que hacer como explicaremos posteriormente.

- clearglobalvars : Si está activado se liberan las variables globales cuando se recargan las extensiones o se reinicia Asterisk.

- priorityjumping : Si tiene valor 'yes', la aplicación soporta 'jumping' o salto a diferentes prioridades. En desuso

En general estas opciones no son muy importantes y se pueden dejar tal y como aparecen por defecto.

Contexto [globals]En este contexto se definen las variables globales que se van a poder utilizar en el resto de los contextos. Por ejemplo

CONSOLE=Console/dsp; indica que cuando hagamos referencia a la variable CONSOLE estamos llamando a /Console/dsp

Las variables suelen ponerse siempre en mayúsculas para diferenciarlas posteriormente.

Resto de Contextos []

Esto es lo más importante de este fichero. Vamos a indicar ahora como crear un contexto especifico y asignar un plan de numeración. Todas las líneas de un determinado contexto tienen el mismo formato:

exten => extensión , prioridad, Comando(parámetros)

La extensión hace referencia al número marcadoLa prioridad al orden en que se ejecutan las instrucciones. Primero se ejecuta la de prioridad 1, luego la 2 y sucesivamenteEl Comando hace referencia a la acción a ejecutar

Vamos a ir viendo unos ejemplos para ir aprendiendo los comandos

Ejemplo 1: Colgar la línea exten => 333,1,Hangup ; indica que cuando alguien llame al 333 saltará la prioridad 1 y el sistema colgará la llamada

Ejemplo 2 : Llamar a el usuario SIP 3000 y que salte el contestador si no contesta exten => 3000,1,Dial(SIP/3000,30,Ttm) ; intenta llamar al usuario 3000 de sip que tiene que estar definido en sip.conf con ese contexto exten => 3000,2,Hangup ; cuando acaba la llamada cuelga exten => 3000,102,Voicemail(3000) ; La prioridad 102 significa que el usuario no estaba conectado y salta el contestador al buzón 3000 exten => 3000,103,Hangup ; se cuelga después de dejar el mensaje

En este caso al llamar a la extensión 3000 usuamos el comando Dial (destino, tiempo de timeout, opciones)El destino es el usuario 3000 del archivo sip.conf, 30 segundos de timeout. El usuario 3000 debería existir en sip.conf las opciones hacen referencia a opciones del comando dial:

La "T" permite al usuario llamante transferir la llamada pulsando # La "t" permite al usuario llamado transferir la llamada pulsando #La "m" indica que vamos a oír una música especial mientras esperamos a que el otro conteste: Puedes probar a quitarla.

Si el usuario 3000 no está conectado salta a la prioridad +101 (en nuestro caso a la 102=1+101 ya que estábamos en la prioridad 1) y hacemos que salte el contestador para dejar un mensaje.

Es importante que por cada rama siempre se cierre el camino y se cuelgue la llamada con un Hangup

Ejemplo 3: Comprobación de latencia y eco exten => 600,1,Playback(demo-echotest) ; Se pone el sonido de que es una demo de eco exten => 600,2,Echo ; Se ejecuta el test de eco exten => 600,3,Playback(demo-echodone) ; Se repite lo que dijimos exten => 600,4,Hangup ; Se cuelga En este caso llamando al 600 nos va a repetir lo mismo que nosotros dijimos. Podremos comprobar la latencia del sistema.

Ejemplo 4: Extensión start exten => s,1,Wait,1 ; Esperamos un segundo exten => s,2,Answer ; respondemos. EL Asterisk coge la llamada exten => s,3,DigitTimeout,5 ; Ponemos Digit Timeout a 5 segundos exten => s,4,ResponseTimeout,10 ; Ponemos Response Timeout a 10 segundos exten => s,5,BackGround(demo-congrats) ; Ejecutamos un archivo de voz

exten => s,6,hangup ; Colgamos exten => 1000,1,Goto(micontexto,s,1) ; Al llamar al 1000 vamos a la extensión s con prioridad 1 del contexto "micontexto"

En este caso presentamos la extensión start s que es la que coge las llamadas cuando se esta en ese contexto pero no se sabe la extensión. También se puede entrar desde otra extensión como en este caso marcando la extensión 1000. Con Goto podemos ir al contexto, extensión y prioridad que queramos.

Ejemplo 5: Llamar a un proveedor de Voz IPexten => _340.,1,Dial(SIP/${EXTEN:3}@Proveedorsip,90,Tt) exten => _340.,2,hangup ; Colgamos exten => _20.,1,Dial(SIP/${EXTEN:2}@Proveedorsip,90,Tt) exten => _20.,2,hangup ; Colgamos

En este caso lo que hacemos es que siempre que marquemos el 340 seguido de cualquier numero (el 340 como prefijo) llamaremos a una extensión SIP. Por ejemplo en el primer caso si marcamos al 340600600 llamaremos al 600600 a la dirección IP del "proveedorsip" definido en sip.conf. (EXTEN:3 significa que quitamos los tres primeros números)

En el segundo caso si marcamos 2060600 también estaremos llamando al mismo número 600600 del "proveedorsip" (EXTEN:2)

En los casos anteriores el. Sustituye a cualquier carácter pero podíamos haber utilizado también X - Acepta un número de 0 al 9 Z - Acepta un número de 1 al 9 N - Acepta un número de 2 al 9 [1,5-7] - Acepta el 1, el 5, el 6 o el 7

exten => _20XX,1,Dial(SIP/${EXTEN:2}@Proveedorsip,90,Tt) ; Deberíamos marcar 20 y dos números (no valen caracteres) exten => _20ZZ.,1,Dial(SIP/${EXTEN:2}@Proveedorsip,90,Tt) ; Deberíamos marcar 20, dos números del 1 al 9 y cualquier cosaexten => _20[1-3]..,1,Dial(SIP/${EXTEN:2}@Proveedorsip,90,Tt) ; Deberíamos marcar 20, un numero del 1 al 3 y cualquier cosa

Configuración del archivo voicemail.conf (Contestador automático)El archivo voicemail.conf sirve para configurar el contestador automático y gestionar los buzones de los usuarios. El fichero extensions.conf se compone también de secciones o contextos entre corchetes []

Hay dos contextos especiales llamados [general] y [zonemessages] que siempre están presentes.

Contexto [general] El contexto [general] configura las opciones generales del buzón de voz:

Un ejemplo básico podría ser:

[general] ; Enviar archivos en las notificaciones de e-mail attach=yes ; Usar el formato wav para los mensajes de voz format=wav ; Limitar el tiempo máximo del mensaje de voz a 180 segundos

maxmessage=180 ; Limitar el tiempo mínimo del mensaje a 3 segundos minmessage=3 ; Anunciar el numero que llamó antes de repetir el mensaje saycid=yes ; Limitar el numero de intentos de registro a 3 maxlogins=3 ; Define los contextos internos para especificar que vienen de una extensión internacidinternalcontexts=house_local,house_toll,house_admin

Vamos a poner en forma de tabla las posibilidades más destacadas a utilizar de este contexto:

Comando Explicación y opciones

attachIndica si se envía un archivo en las notificaciones de email. Tiene dos valores "yes" o "no" Por defecto es "no"

delete Indica que el mensaje de voz será borrado del servidor si es enviado por e-mailmailcmd Sirve para fijar la ruta del servidor de e-mail

maxsilenceIndica los segundos de silencio que debe detectar el servidor para cortar la llamada al buzón. Por defecto es 0 que indica que equivale a un tiempo infinito y no hace caso a los silencios.

envelope Si lo activamos con "yes" indicará el día y la hora en que se recibió el mensajeexternnotify Sirve para ejecutar un programa externo cuando alguien deja un mensajeexternpass Sirve para ejecutar un programa externo cuando alguien cambia su contraseña del buzón.silencetreshold Funciona si maxsilence="yes" y sirve para fijar el umbral de silencioservermail Indica el origen de los mensajes de notificación de e-mail. Por ejemplo buzon@midominio.commaxmessage Indica el tiempo máximo de un mensajemaxmsg Indica el numero máximo de mensajes en un buzónminmessage Sirve para eliminar los mensajes que tienen menos duración que lo indicado por este comando.

formatIndica el formato en que se guardará los mensajes e voz. Hay las siguientes posibilidades: "wav49", "gsm", "wav"

maxgreet Fija el tiempo máximo del mensaje de bienvenida que pueden configurar los usuariosmaxlogins Numero máximo de intentos de logeocdinternalcontexts Distingue si los contextos son contextos internos o externospromiscredir Permite soportar redirecciones 302. Por defecto "no"

review Por defecto es "no". Si lo pusiéramos a "yes" el usuario que deja el mensaje podrá revisarlo antes de salvarlo y dejarlo en el buzón.

operator Permite marcar una extensión cuando ha saltado el buzón de voz saycid Si lo ponemos a "yes" anunciar el numero que llamó antes de repetir el mensaje fromstring Modifica el from del mensaje de aviso de correo emailsubject Modifica el asunto del mensaje de aviso de correo emailbody Modifica el cuerpo del mensaje de aviso de correo nextaftercmd Reproduce el siguiente mensaje automáticamente cuando se borra el anterior.

Contexto [zonemessages]Este contexto define zonas horarias. La hora para distintos usuarios no es la misma y para poder informarle sobre la hora en que recibió el mensaje es necesario fijar diferentes zonas horarias:

Un ejemplo podría ser

[zonemessages]madrid=Europe/Paris|'vm-received' Q 'digits/at' R paris=Europe/Paris|'vm-received' Q 'digits/at' Rsthlm=Europe/Stockholm|'vm-recieved' Q 'digits/at' R europa=Europe/Berlin|'vm-received' Q 'digits/at' kMitalia=Europe/Rome|'vm-received' Q 'digit/at' HMP

El formato de las líneas es el siguiente:

zona=Pais/Ciudad|Opciones --> El País y la ciudad deben ser válidos y son los del archivo /usr/share/zoneinfo de la instalación de Linux

Las diferentes Opciones son:Option Description 'fichero' Nombre del fichero de audio a reproducir ${VAR} Variable de sustitución A, a Día de la semana (sábado, domingo, etc...) B,b,h Mes (Enero, Febrero, ...) d,e día del mes numérico (primero, segundo,...) Y AñoI or i Hora, en formato 12 horas H ,k Hora, en formato 24 horas M MinutosP,p AM o PM Q "hoy","ayer"R tiempo 24 horas , incluidos minutos

Resto de Contextos []

En el resto de contextos se definen los buzones de los usuarios. Podemos tener todos los usuarios en un solo contexto por ejemplo [default] o tener más de un contexto.

El formato básico es el siguiente:

[default] extension => contraseña, nombre de usuario, email de usuario, email de notificación, opciones

La extensión hace referencia al número de teléfono llamado.- La contraseña hacer referencia a la contraseña para ese usuario de su buzón de voz. - El nombre de usuario es el nombre del cliente de la extensión - El email del usuario es el correo al que serán enviados los mensajes - El email de notificación es un email alternativo donde pueden ser enviadas las notificaciones para

administración o control.- Las opciones sirven para sobrescribir las del contexto [general] o especificar una zona horaria para

el usuario. Hay 9 especificas: attach, serveremail, tz, saycid, review, operator, callback, dialout and exitcontext. Son las mismas que las contexto [general] salvo tz. La opción tz se usa para sobrescribir la zona por defecto y debe estar presente en el contexto [zonemessages]

Ejemplos:

[default]1234 => 3456,Ejemplo1,mail@dominio.com4200 => 9855,PedroPerez,pedro@dominio.com,admin@dominio.com,attach=no|serveremail=info@ dominio.com | tz=Madrid4069=>6522,Juan,j@dominio.net,,attach=yes|saycid=yes|dialout=fromvm|callback=fromvm|review=yes|operator=yes|envelope=yes4073 => 1099,Javier Perez,perez@dominio.com,,delete=1

Fuente de Información.- http://www.voipforo.com/