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ía

La 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 IAX
El 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 llamada
El 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 audio

Se 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ón

La 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 Frames

La 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 Frames
Las 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 Frame

El 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 Frame
Valor "type
Descripción Detalles
frame"
00000001 DTMF Sirve para enviar dígitos DTMF
El campo subclase indica el tipo de codec de audio que se utiliza
00000002 Datos de voz
según la tabla 2
Datos de
00000003 El campo subclase indica el tipo de codec de video que se utiliza
video
Mensajes de control de sesión. Sirve para controlar el estado de los
00000004 Control dispositivos finales. El campo subclase indica el tipo concreto de
mensaje de control según tabla 3.
00000005 No usado
Mensajes de control del protocolo IAX. Gestiona las interacciones
00000006 Control IAX 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 Descripción (codec que se utiliza en la conversación)
subclase
(Type Frame
=0x02)
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
Descripción Detalles
(Type Frame
=0x04)
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
Congestion
0x08 Existe congestión
Condition
0x0e Call Progress Progreso de la llamada
Tabla 4. Significado de los valores del campo subclase para Frame Type = "0x06"
(control IAX)
Valor
subclase
Descripción Detalles
(Type Frame
=0x05)
Iniciar una nueva
0x01 NEW 0x10 REGREJ Denegación de registro
llamada
0x02 PING Enviar un ping 0x11 REGREL Liberación de registro
Petición de
0x03 PONG Responder un ping 0x12 VNAK
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
Petición de
0x07 ACCEPT Aceptación 0x16 TXREQ
transferencia
Petición de Conexión de
0x08 AUTHREQ 0x17 TXCNT
autenticación transferencia
Respuesta de Aceptación de
0x09 AUTHREP 0x18 TXACC
autenticación transferencia
0x0a INVAL Llamada no válida 0x19 TXREADY Transferencia preparad
Liberación de
0x0b LAGRQ Petición de Lag 0x1a TXREL
transferencia
0x0c LAGRP Respuesta de Lag 0x1b TXREJ Rechazo de
 transferencia
Parar transmisión de
0x0d REGREQ Petición de registro 0x1c QUELCH
audio
Autenticación de Continuar transmisión
0x0e REGAUTH 0x1d UNQUELCH
registro de audio
Indicador de mensaje
0x0f REGACK ACK de registro 0x20 MWI
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 SIP
Las 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=z9hG4bK646464100000000b43c52d6c00000d1200
000f03
Content-Length: 0
Contact: <sip:20000@192.168.0.100:5060>
Call-ID: ED9A8038-A29D-40AB-95B1-0F5F5E905574@192.168.0.100
CSeq: 36 REGISTER
From: <sip:20000@192.168.0.101>;tag=910033437093
Max-Forwards: 70
To: <sip:20000@192.168.0.101>
User-Agent: SJphone/1.60.289a (SJ Labs)
Authorization:Digest
username="20000",realm="192.168.0.101",nonce="43c52e9d29317c0bf1f885b9aaff1
522d93c7692",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 Clases
1xx - 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 Protocol
Status-Line: SIP/2.0 200 OK
Status-Code: 200
Resent Packet: False
Via: SIP/2.0/UDP
192.168.0.100:5060;rport;branch=z9hG4bK646464100000000b43c52d6c00000d1200
000f03
Content-Length: 0
Contact: <sip:20100@192.168.0.100:5060>
Call-ID: ED9A8038-A29D-40AB-95B1-0F5F5E905574@100.100.100.16
CSeq: 36 REGISTER
From: <sip:20000@192.168.0.101>;tag=910033437093
Max-Forwards: 70
To: <sip:20000@192.168.0.101:5060>
Authorization: Digest
username="20100",realm="192.168.0.101",nonce="43c52e9d29317c0bf1f885b9aaff1
522d93c7692",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 Header
Via: SIP/2.0/UDP
192.168.0.100:5060;rport;branch=z9hG4bK646464100000007343c52679000020a600
000e45
Content-Length: 0
Call-ID: 911D32E5-EEDF-4572-B0B2-61B294636E88@192.168.0.100
CSeq: 1 ACK
From: "Prueba"<sip:20000@miasterisk.com>;tag=8922404614682
Max-Forwards: 70
Route: <sip:20001@192.168.0.1>
To: <sip:20001@miasterisk.com>;tag=as0a27b928
User-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): 0

Owner/Creator, Session Id (o): Cisco-SIPUA 26425 12433 IN IP4
192.168.0.100
Owner Username: Cisco-SIPUA
Session ID: 26425
Session Version: 12433
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.0.100
Session Name (s): SIP Call
Connection Information (c): IN IP4 192.168.0.100
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.0.100
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17338 RTP/AVP 0 8 18 101
Media Type: audio
Media Port: 17338
Media Proto: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.711 PCMA
Format: ITU-T G.729
Media Format: 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media 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. Terminal
Un 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. Gateway
Un 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. Gatekeeper
El 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. MCU
La 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 MULTIPUNTO
Un 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 MULTIPUNTO
Un 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.323
Un 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.245

EL 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. AUDIO
Los 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.

- NAT
En 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 uso
SIP 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 puertos
IAX 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 servidor

En 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 funcionalidades
IAX 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 Asterisk

Asterisk 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 descomprimimos
1)
# tar -zxvf asterisk-1.6.1.6.tar.gz
# rm -f asterisk-1.6.1.6.tar.gz
# cd asterisk-1.6.1.6
2) ejecutar "make"
Suponiendo que todo ha ido correctamente
3) ejecutar "make install"
Si es la primera vez que instalas la centralita Asterisk es recomendable instalar los
ejemplos con el comando
4) "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 –vvvc
Verá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 consola
1236 - Llamar a la consola
3000 - Llamar al usuario SIP 3000
3001 - Llamar al usuario SIP 3001
500 - Llamar a Digium
600 - Prueba de eco
8500 - 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 Windows

Asterisk 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 consola
1236 - Llamar a la consola
3000 - Llamar al usuario SIP 3000
3001 - Llamar al usuario SIP 3001
500 - Llamar a Digium
600 - Prueba de eco
8500 - 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=friend
secret=a20000b
qualify=yes
nat=no
host=dynamic
canreinvite=no
context=miprimerejemplo
mailbox=20000@miprimerbuzon

[20100]
type=friend
secret=b20100a
qualify=yes
nat=no
host=dynamic
canreinvite=no
context=miprimerejemplo
mailbox=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.com
20100 => 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 softphone
Configuramos 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=default
port=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=friend
secret=welcome
qualify=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
El modo en el que se transmiten los tonos. Pueden ser "RFC2833"
dtmfmode dtmfmode
o "INFO"
Con "no" se fuerza a Asterisk a no permitir que los puntos finales
canreinvite canreinvite intercambien
mensajes 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()
Define las señales para un país. Debe estar presente en el
language language
archivo indications.conf
permite habilitar un codec. Pueden ponerse varios en un mismo
usuario Posibles Valores:
allow allow
"allow=all" ,"allow=alaw", "allow=ulaw", "allow=g723.1" ;
allow="g729" , "allow=ilbc" , "allow=gsm".
permite deshabilitar un codec. Puede tomar los mismos valores
disallow disallow
que allow
Define como manejar las conexiones con peers Tiene los
insecure insecure 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"
Define el identificador cuando no hay ninguna otra información
callerid
disponible
Los usuarios pueden estar asociados con un accountcode . Se usa
accountcode
para facturación.
Se usa para guardar en los CDR y temas de facturación . Puede
amaflags
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
Si Asterisk actúa como cliente SIP este es el nombre de usuario
username
que presenta en el servidor SIP al que llama
fromdomain Pone el campo From: de los mensajes SIP
regexten
 Pone el nombre de usuario en el from por encima de lo que diga
fromuser
el callerID
dirección o host donde se encuentra el dispositivo remoto. Puede
tomar valores:
- Una IP o un host concreto
host
- "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
IP por defecto del cliente host= cuando es especificado como
defaultip
"dynamic"
Termina la llamada cuando llega a ese timeout si no ha habido
rtptimeout
tráfico rtp
Termina la llamada cuando llega a ese timeout si no ha habido
rtpholdtimeout
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 INFO
mailbox=1234@default ; mailbox 1234 en el contexto "default" del fichero
voicemail.conf
disallow=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 ulaw
allow=ulaw
allow=alaw

[user1_snomsip]
type=friend
secret=blah ; en este caso es la contraseña para registrarse
host=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 contestar
callgroup=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 ;IP
disallow=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 marcado

La prioridad al orden en que se ejecutan las instrucciones. Primero se ejecuta la de
prioridad 1, luego la 2 y sucesivamente
El 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 IP

exten => _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 cosa
exten => _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 interna
cidinternalcontexts=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

Indica si se envía un archivo en las notificaciones de email. Tiene dos valores
attach
"yes" o "no" Por defecto es "no"
delete Indica que el mensaje de voz será borrado del servidor si es enviado por e-mail
mailcmd Sirve para fijar la ruta del servidor de e-mail
Indica los segundos de silencio que debe detectar el servidor para cortar la
maxsilence 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 mensaje
externnotify Sirve para ejecutar un programa externo cuando alguien deja un mensaje
Sirve para ejecutar un programa externo cuando alguien cambia su contraseña
externpass
del buzón.
silencetreshold Funciona si maxsilence="yes" y sirve para fijar el umbral de silencio
Indica el origen de los mensajes de notificación de e-mail. Por ejemplo
servermail
buzon@midominio.com
maxmessage Indica el tiempo máximo de un mensaje
maxmsg Indica el numero máximo de mensajes en un buzón
Sirve para eliminar los mensajes que tienen menos duración que lo indicado
minmessage
por este comando.
Indica el formato en que se guardará los mensajes e voz. Hay las siguientes
format
posibilidades: "wav49", "gsm", "wav"
Fija el tiempo máximo del mensaje de bienvenida que pueden configurar los
maxgreet
usuarios
maxlogins Numero máximo de intentos de logeo
cdinternalcontext
Distingue si los contextos son contextos internos o externos
s
promiscredir Permite soportar redirecciones 302. Por defecto "no"
Por defecto es "no". Si lo pusiéramos a "yes" el usuario que deja el mensaje
review
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
Si lo ponemos a "yes" anunciar el numero que llamó antes de repetir el
saycid
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' R
sthlm=Europe/Stockholm|'vm-recieved' Q 'digits/at' R
europa=Europe/Berlin|'vm-received' Q 'digits/at' kM
italia=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:

Optio
Description
n
'ficher Nombre del fichero de audio a
o' reproducir
$
{VAR Variable de sustitución
}
Día de la semana (sábado,
A, a
domingo, etc...)
B,b,h Mes (Enero, Febrero, ...)
día del mes numérico (primero,
d,e
segundo,...)
Y Año
I or i Hora, en formato 12 horas
H ,k Hora, en formato 24 horas
M Minutos
P,p AM o PM
Q "hoy","ayer"
tiempo 24 horas , incluidos
R
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.com
4200 => 9855,PedroPerez,pedro@dominio.com,admin@dominio.com,attach=no|
serveremail=info@ dominio.com | tz=Madrid
4069=>6522,Juan,j@dominio.net,,attach=yes|saycid=yes|dialout=fromvm|
callback=fromvm|review=yes|operator=yes|envelope=yes
4073 => 1099,Javier Perez,perez@dominio.com,,delete=1
Fuente de Información.- http://www.voipforo.com/