PROTOCOLOS DE SEALIZACIN USADA ACTUALMENTE PARA

TERMINALES MVILES E IP








WILMER SANTAMARA GONZLEZ

GRUPO DE INVESTIGACIN PROMENTE
LNEA DE INVESTIGACIN EN TELECOMUNICACIONES










FUNDACIN UNIVERSITARIA KONRAD LORENZ
FACULTAD DE MATEMTICAS E INGENIERA
BOGOTA D.C.
2011




PROTOCOLOS DE SEALIZACIN USADA ACTUALMENTE PARA
TERMINALES MVILES E IP






WILMER SANTAMARA GONZLEZ



DIRECTORA
ING. LEIDY JOHANNA ORTIZ



GRUPO DE INVESTIGACIN PROMENTE
LNEA DE INVESTIGACIN EN TELECOMUNICACIONES












FUNDACIN UNIVERSITARIA KONRAD LORENZ
FACULTAD DE MATEMTICAS E INGENIERA
BOGOTA D.C.
2011



TABLA DE CONTENIDO
Introduccin ............................................................................................................. 6
1.Protocolo SIP ........................................................................................................ 7
1.1 Caractersticas Principales ......................................................................... 8
1.2 SIP URI ....................................................................................................... 9
1.3 Elementos de Red .................................................................................... 10
1.4 Agente de usuario ..................................................................................... 10
1.5 Servidores Proxy ...................................................................................... 12
1.6 Proxy sin Estado ....................................................................................... 12
1.7 Proxy con Estado ...................................................................................... 13
1.8 Servidor de Registro ................................................................................. 14
1.9 Agente De Usuario inverso (B2BUA) ........................................................ 14
1.10 Mensajes SIP ........................................................................................ 15
1.11 Solicitudes SIP ...................................................................................... 16
1.12 Respuestas SIP ..................................................................................... 17
1.13 Transacciones ....................................................................................... 19
1.14 Dilogos ................................................................................................ 19
2.1 Arquitectura .............................................................................................. 22
2.2 Terminal .................................................................................................... 23
2.3 Gateway .................................................................................................... 24
2.4 Destination lookup .................................................................................... 25
2.5 IP Connection Management ..................................................................... 25
2.6 Compression/Digitization .......................................................................... 25
2.7 Ip Packetization and Transport ................................................................. 26
2.8 Advcanced IP/PSTN Signaling ................................................................. 26
2.9 Authorization Access Accounting .............................................................. 27
2.10 Gatekeepers .......................................................................................... 28
2.11 Controlador Multipunto (MC) ................................................................. 30


2.12 Procesador Multipunto (MP) .................................................................. 31
3.MEGACO ............................................................................................................ 33
4.SS7 ..................................................................................................................... 34
4.1 (MTP) Parte de transferencia de mensajes .............................................. 37
4.2 Funcin a nivel de enlace de datos de sealizacin ................................ 37
4.3 Funcin a nivel de enlace de sealizacin ................................................ 38
4.4 Funcin de red de sealizacin ................................................................ 38
4.5 (SCCP) Parte de control de conexin de sealizacin ............................. 39
4.6 (TCAP) Parte de aplicacin de capacidades de transaccin .................... 40
4.7 (ISP) Parte intermedia de servicios........................................................... 40
4.8 (OMAP) La parte de operacin, mantenimiento y administracin ............. 41
4.9 Las partes del usuario ............................................................................... 41
5.Anlisis de Protocolos ......................................................................................... 43


















Tabla de Figuras


Ilustracin 1 Protocolos Sobre IP ............................................................................. 9
Ilustracin 2 Esquema de Agente de Usuario ........................................................ 11
Ilustracin 3 Agente de Usuario B2BUA ................................................................ 15
Ilustracin 4 Arquitectura de MEGACO ................................................................. 33

















INTRODUCCIN

La presente investigacin involucra algunos de los protocolos de sealizacin
teniendo en cuenta la evolucin y los estndares que estn implementados en la
actualidad, teniendo en cuenta que cada una de las fuentes primarias
correspondientes a cada protocolo, de esta manera la metodologa que se
pretende implementar para el desarrollo de la misma es de tipo cualitativo, debido
a que no se pretende plantear un nuevo esquema de sealizacin, sino que por el
contrario se busca profundizar las sealizaciones existentes y cual es futuro de las
mismas.

El ascenso de Internet como un rival a la red telefnica de conmutacin de
circuitos ha dado lugar a fuertes razones econmicas y tecnolgicas para la
convergencia de servicios y arquitecturas. Con el fin de asimilar los servicios de
telefona con la tecnologa omnipresente de la IP, es necesario un protocolo de
sealizacin para crear y finalizar las conexiones.
Diferentes grupos de investigacin proponen soluciones particulares enfocadas a
satisfacer sus propias prioridades e intereses y la comunidad de Internet desea
introducir servicios innovadores basados en las herramientas mejoradas de
edicin web como XML y ms protocolos abiertos, peer-to-peer y modelos de
llamada.












1. PROTOCOLO SIP

El protocolo de sealizacin SIP (Session Initiation Protocol) es utilizado para el
establecimiento de sesiones en una red IP. Una sesin puede ser una simple
llamada de telfono de dos vas o podra ser una colaboracin de sesin de
conferencia multimedia. La capacidad de establecer estas sesiones significa que
surge una gran cantidad de servicios innovadores, tales como voz enriquecida, el
comercio electrnico, pgina web, haga clic para marcar, la mensajera
instantnea con listas de amigos, y los servicios IP.


Durante los ltimos aos, la comunidad de voz sobre IP ha adoptado SIP como
protocolo de eleccin para la sealizacin. SIP es un estndar RFC (RFC 3261)
de Internet del grupo de investigacin IETF (Engineering Task Force), el cual es el
organismo responsable de administrar y desarrollar los mecanismos que
comprenden todo lo relacionado con Internet. SIP sigue evolucionando y se
extiende como la tecnologa madura y sus productos son socializados en el
mercado.


La ideologa del IETF es la simplicidad: slo se especifica lo que se necesita
especificar. Este protocolo es mucho ms que un modelo, ha sido desarrollado
exclusivamente como un mecanismo para establecer sesiones, las cuales no se
conoce acerca de los detalles de una sesin, slo inicia, termina y modifica
sesiones. Esta simplicidad significa que SIP tiene varias escalas, que es
extensible, y se acopla cmodamente en diferentes arquitecturas y escenarios de
implementacin.


SIP es un protocolo de peticin-respuesta que se asemeja a dos protocolos de
Internet, HTTP y SMTP (los protocolos Web y de correo electrnico) y, en
consecuencia, SIP se vincula cmodamente junto a las aplicaciones de Internet.
Usando la telefona sobre SIP, esta se convierte en otra aplicacin web y se
integra fcilmente en otros servicios de Internet. SIP es una herramienta simple
que los proveedores de servicios pueden utilizar para construir servicios
convergentes de voz y multimedia.
12


1
Entidades bsicas SIP [En Lnea] http://es.wikitel.info/wiki/Entidades_b%C3%A1sicas_SIP
[Citado en 10 de marzo de 2011]


1.1 Caractersticas Principales


SIP se describe como un protocolo de control para crear, modificar y terminar
sesiones con uno o ms participantes. Estas sesiones incluyen conferencias
multimedia de Internet, o de cualquier red IP, llamadas telefnicas y la distribucin
multimedia. Los miembros en una sesin pueden comunicarse a travs de
multicast o por medio de una malla de relaciones unidifusin, o mediante una
combinacin de stos. SIP soporta descripciones de la sesin que permitir a los
participantes a un acuerdo sobre un conjunto de tipos de medios compatibles.
Tambin es compatible con la movilidad del usuario, representando y redirigiendo
las peticiones a la localizacin actual del usuario. SIP no est ligado a ningn
protocolo de control de conferencia en particular.


Otra de las grandes tareas es garantizar que la llamada llegue a su destino. La
realizacin de cualquier asignacin de informacin descriptiva de la informacin de
ubicacin. Esto permite que el grupo involucrado en una llamada (puede ser una
llamada en conferencia) se pone de acuerdo sobre las funciones admitidas,
reconociendo que no todas las partes involucradas pueden soportar el mismo nivel
de caractersticas. Por ejemplo, el vdeo puede ser o no ser compatible.


En una llamada un participante puede gestionar la misma, esto quiere decir que
puede invitar a otros participantes en la llamada o puede cancelar las conexiones
a otros usuarios, adems de que los usuarios pueden ser transferidos o puestos
en espera.


Un usuario tiene la posibilidad de cambiar las caractersticas de llamada durante el
curso de la misma. Por ejemplo, una llamada puede haber sido creada con la
caracterstica de voz, pero en el transcurso de la llamada, los usuarios pueden
necesitar para habilitar una funcin de vdeo. Un tercero puede unirse a una
llamada puede y requerir diferentes caractersticas para estar habilitado y
participar en la convocatoria.


Para no definir un nuevo sistema de direccionamiento, en algunos casos las
direcciones de usuarios SIP estn asociadas al correo electrnico. Cada usuario
es identificado mediante una direccin URL jerrquica que se construye alrededor
de elementos como el nmero de telfono de un usuario, o el nombre del host por

2
Session Initiation Protocol [En Lnea] http://datatracker.ietf.org/wg/sip/charter/ [Citado en 22 de
abril de 2011]


ejemplo, (sip:usario@compaia.com). Esto significa que es ms sencillo para
redirigir a alguien a otro telfono, ya que es como redirigirse a una pgina web.
3


Ilustracin 1 Protocolos Sobre IP

1.2 SIP URI

Todas las entidades SIP son identificadas por medio de URI (Uniform Resource
Identifier), los URI contienen la suficiente informacin para iniciar y para mantener
una sesin de comunicacin con el recurso, utilizan una forma similar a la
direccin de correo, permitiendo as ver las especificaciones del encabezado,
haciendo posible especificar el destinario, el tipo de medio o la urgencia de la
sesin usando URI. La forma general de un SIP URI es:

Sip:usuario:contrasea@direccion_del_equipo;parmetros _URI

Las instancias estn enmarcadas por las siguientes caractersticas:

Usuario: El identificador de un recurso en particular es la direccin. El

trmino "usuario" en este contexto se refiere con frecuencia a un dominio.

3
RFC 3261 SIP: Session Initiation Protocol [En Lnea] http://tools.ietf.org/html/rfc3261#section-7
[Citado en 10 de marzo de 2011]


La informacin de un usuario de una URI consta de este campo de usuario,
el campo de contrasea, seguido del signo @. La parte de la informacin
del usuario de una URI es opcional y puede estar ausente cuando el
dispositivo de destino no tiene una nocin de usuarios o cuando el
dispositivo tiene otro recurso de identificacin. Si el signo @ est presente
en un SIP o URI SIPS, el campo de usuario no debe estar vaco.

Contrasea: La contrasea est asociada al usuario, mientras que la

sintaxis SIPS URI permite que este campo este presente, su uso no se
recomienda, debido a que el paso de informacin de autenticacin en texto
plano (como URI) ha demostrado ser un riesgo de seguridad en casi todos
los casos en que se ha utilizado.

Direccin del equipo: Es la direccin IP por medio de la cual es identificado

el dispositivo en la red, la cual debe estar bajo un nombre de dominio o
direccin en versin IP4 oIP6.

Puerto: numero del puerto donde la solicitud se debe enviar.

4


1.3 Elementos de Red

En un escenario de red SIP la configuracin ms sencilla utiliza solo dos agentes
que envan mensajes SIP de el uno al otro, pero en una red tpica tendr ms de
un entidad lgica, cada una de estas entidades intervienen en una conversacin
SIP como cliente o como servidor o ambas, entre estas estn: Elementos bsicos
como los son los agentes de usuario, servidores proxy, servidores de redireccin,
servidor registrador, agente de usuario inverso (B2BUA).
5


1.4 Agente de usuario


4
The IP Telecommunications Portal [En Lnea] http://www.iptel.org/ [Citado en 1 de abril de 2011]
5
VoIP foro Arquitectura SIP [En lnea] http://www.voipforo.com/SIP/SIPejemplo.php [citado en 10
de marzo de 2011]


Todas las terminales IP utilizan un agente de usuario, el cual por lo general est
instalado en la terminal en forma de aplicacin la cual siempre esta activa en tipo
(demonio), en otras palabras un agente de usuario es la entidad final o de extremo
encargada de dialogar con las otras entidades. Los agentes de usuario son los
que inician y terminan las sesiones por medio de mensajes que requieren un
servicio o que responden a solicitudes o requieren alguna respuesta.


La RFC 3261 define el Agente de Usuario como una aplicacin, que puede actuar
como un Agente de Usuario cliente y un Agente de Usuario servidor.
Debido a que un agente de usuario contiene UAC y UAS, por ende se dice que un
agente de usuario se comporta como un UAC o UAS. Por ejemplo, el agente de
usuario se comporta como UAC cuando se enva una solicitud INVITE y recibe
respuestas a la solicitud. Un agente de usuario se comporta como un UAS cuando
recibe la invitacin y enva las respuestas.

Ilustracin 2 Esquema de Agente de Usuario

Agente de usuario cliente (AUC) es una aplicacin cliente que inicia solicitudes
SIP hacia la red IP y un agente de usuario servidor (AUS) es una aplicacin que


recibe solicitudes SIP de la red IP la cual contacta al que enva la solicitud y enva
la respuesta al AUC.


Pero esta situacin cambia cuando el destinatario de la llamada decide enviar un
BYE y terminar la sesin. En este caso el agente del destinatario de la llamada
de usuario (el que envo el mensaje BYE) se comporta como el UAC y el agente
de la persona que llama el usuario se comporta como UAS.
6



1.5 Servidores Proxy

Adicin a esto SIP permite la creacin de una infraestructura de red de equipos
llamados servidores proxy. Los agentes de usuario pueden enviar mensajes a un
servidor proxy. Los servidores proxy son entidades muy importantes en la
infraestructura SIP, realizan el enrutamiento de una sesin de invitados de
acuerdo a su ubicacin actual, la autenticacin, contabilidad y muchas otras
funciones importantes.


La tarea ms importante de un servidor proxy es encontrar la ruta ms cerca al
destinatario de la llamada. La sesin de una invitacin usualmente atraviesa una
serie de proxys hasta encontrar uno que conoce la ubicacin real del destinatario
de la llamada. Este proxy enva la sesin invitacin directamente al destinatario de
la llamada y el destinatario de la llamada entonces acepta o rechaza la invitacin
de sesin.
7


Existen dos tipos de servidores proxy SIP: proxy sin estado y proxy con estado


1.6 Proxy sin Estado

Servidor sin estado es el encargado de reenviar los mensajes SIP. Ellos reenvan
los mensajes de forma independiente el uno del otro, aunque los mensajes

6
B2BUA Documentation [En Lnea] http://www.b2bua.org/wiki/B2BUADocumentation [Citado en 15
de abril es 2011]
7
The SIP center A portal for the commercial development of SIP [En Lnea]
http://www.sipcenter.com/sip.nsf/html/Whitepapers [Citado en 17 de marzo de 2011]


generalmente estn dentro de las transacciones, los servidores proxy sin estado
no tienen cuidado de las transacciones.


Proxy sin estado son simples, pero ms rpidos que los servidores proxy con
estado. Pueden ser utilizados como equilibradores de carga simple, traductores
mensaje y routers. Uno de los inconvenientes de la representacin sin estado es
que son incapaces de absorber la retransmisin de mensajes y realizar el
enrutamiento avanzado.


1.7 Proxy con Estado

Los Proxy con estado son ms complejos. En la recepcin de una solicitud, un
Proxy con estado puede crear un estado y mantener el estado hasta que finalice la
transaccin. Algunas transacciones, especialmente las creadas por INVITE,
pueden durar bastante tiempo (hasta el destinatario toma o rechaza la llamada).
Debido a que Proxy con estado debe mantener el estado por la duracin de las
transacciones, su rendimiento es limitado, pero pueden desempear tareas mucho
ms complejas; por ejemplo hacer retransmisiones como lo sera el caso del
servicio sgueme remitir un mismo mensaje SIP hacia dos proxy diferentes con
el fin de localizar a un usuario en especfico.


Proxy con estado puede absorber retransmisiones porque las conoce desde el
estado de la transaccin, si ya se ha recibido el mismo mensaje (Proxy sin estado
no puede hacer la verificacin porque no almacena ningn estado).


Este puede llevar a cabo los mtodos ms complicados para encontrar un usuario,
por ejemplo, cuando no es posible contactar a un usuario en el telfono de la
oficina entonces recoge la llamada y la redirige a su telfono celular. Proxy sin
estado no puede hacerlo porque no conoce como la transaccin llega a su
objetivo
8



8
Understanding SIP exchanges by experimentation [En Linea]http://4z.com/People/emin-
gabrielyan/public/070501-sip-docs/ [Citado en 8 de abril de 2011]



1.8 Servidor de Registro


SIP tiene la capacidad de localizar donde est el destinatario de la llamada. Si un
usuario desea iniciar una sesin con otro usuario, SIP localiza en que equipo est
el destinatario. En este proceso intervienen los Proxy y los servidores de
redireccin que al recibir la solicitud buscan donde est el usuario, para as
asignarle la llamada y conectar los medios (Voz, imgenes o mensajes) a
intercambiar. Para esto el servidor proxy realiza una consulta a un servicio de
localizacin que devolver una o varias direcciones URI.


Por tanto, las funciones del servidor de registro es satisfacer las solicitudes SIP
REGISTER y en consecuencia actualiza la base de datos de localizacin, con la
debida informacin del usuario que se registre. Este servidor en la mayora de las
ocasiones est ubicado junto al proxy, de manera que no es obligacin que
siempre este all. Su funcin reside en asociar una URI con una o varias
direcciones IP, que por lo general sern del tipo SIP: pero que tambin pueden ser
del tipo tel. La relacin se realiza mediante una tabla. Teniendo en cuenta que
cuando en la tabla de relaciones exista una URI con mltiples direcciones IP,
todas estas extensiones sonaran simultneamente.
9



1.9 Agente De Usuario inverso (B2BUA)

El agente de usuario inverso (B2BUA) es un componente SIP de control de
llamadas. A diferencia de un servidor proxy SIP, que slo mantiene una
transaccin de estado, el B2BUA mantiene el estado completo de la llamada y
participa en todas las solicitudes de llamada. En consecuencia, el B2BUA puede
llevar a cabo una serie de funciones que no son posibles de implementar con el
uso del servidor proxy SIP, como el tiempo de la llamada exacta, facturacin, la
conmutacin por error de enrutamiento de llamadas, y as sucesivamente.

B2BUA consiste en los siguientes componentes lgicos:

9
Characteristics About SIP [En Lnea] http://www.sipcenter.com/sip.nsf/html/Characteristics
[Citado en 13 de mayo de 2011]

Respuesta a un agente de usuario SIP

Control lgico de llamada

Origen del agente de usuario SIP

Ilustracin 3 Agente de Usuario B2BUA
Los componentes interactan entre s mediante eventos abstractos. Cada Agente
de Usuario (UA) representa un estado de mquina, el cual recibe mensajes SIP
desde el punto final y los convierte en eventos en base al tipo de mensaje y al
estado actual del agente. El control lgico de llamada acta como un
intermediario, en los acontecimientos que pasan entre los UA. Dependiendo de su
propio estado actual y los estados de la UA, el control lgico de llamada podra
bajar algunos eventos, e incluso convertir el tipo de transicin, o inyectar eventos
adicionales. Tambin puede eliminar uno de los agentes de usuario y sustituirlo
por otro en las diferentes etapas con un diferente estado de llamada, el cual
permite implementar caractersticas tales como conmutacin por error de
enrutamiento de llamadas, control de transferencia de llamadas entre otras.
10





1.10 Mensajes SIP


10
Tech invite SIP Protocol Structure [En Lnea] http://www.tech-invite.com/Ti-sip-archi.html [Citado
en 1 de abril de 2011]



La comunicacin por medio del protocolo SIP se compone de una serie de
mensajes, los cuales pueden ser transportados de forma independiente por la red.
Por lo general son transportados en un datagrama UDP cada uno por separado.
Cada mensaje tiene la siguiente estructura, lnea inicial, encabezado del mensaje,
y el cuerpo del mensaje. La primera lnea identifica el tipo del mensaje. Hay dos
tipos de mensajes - las solicitudes y respuestas. Las solicitudes se suelen utilizar
para iniciar alguna accin o informar a quien reciba la solicitud de algo. Las
respuestas se utilizan para confirmar que la solicitud fue recibida y procesada y
contiene el estado del proceso.

Los campos de cabecera de inicio son de y para quien indican el receptor y el
destinario de un mensaje de igual forma que en SMTP donde se identifique el
remitente y destinatario, en la cabecera contiene un parmetro de etiqueta que
sirve como identificador de dialogo en cual sern descritos los dilogos. El
encabezado del mensaje y el cuerpo del mensaje estn delimitados por una lnea
en blanco. El cuerpo del mensaje de la solicitud INVITE contiene una descripcin
del tipo de los medios de comunicacin aceptados por el remitente y esta
codificados en SDP

El encabezado Call-ID es un campo identificador de dilogo y su propsito es
identificar los mensajes que pertenecen a la misma llamada, estos mensajes
utilizan el mismo identificador de llamada ID, pero a su vez necesitan de otro
parmetro para mantener el orden de las solicitudes. Dado que las solicitudes se
pueden enviar a travs de un transporte poco fiable, los mensajes ser pueden
reordenar, siempre y cuando tengan un nmero de secuencia en los mensajes
para que destinatario pueda identificar a las retransmisiones y de solicitudes fuera
de pedido. En un campo de la cabecera contiene la direccin IP y el puerto en el
que el remitente se encuentra en espera para nuevas solicitudes por el
destinatario de la llamada.
11




1.11 Solicitudes SIP


11
A Hitchhiker's Guide to the Session Initiation Protocol [En Linea] http://tools.ietf.org/html/draft-ietf-
sip-hitchhikers-guide-06 [Citado en 24 de marzo de 2011]


Las solicitudes SIP tienen la caracterstica de tener una lnea de solicitudes para
establecer la comunicacin, esta lnea contiene informacin del nombre de
mtodo, una Solicitud-URI y la versin del protocolo separados por un espacio
simple de caracteres.

Esta especificacin define seis mtodos bsicos:

REGISTER: el propsito es dejar un registro de acerca de la ubicacin del

usuario actual, informacin tal como lo es direccin IP y el puerto por el cual
ha realizado el registro de mensajes.

INVITE: Indica que un cliente est siendo invitado a participar en una

llamada.

ACK: confirma la recepcin del mtodo INVITE el cual es el que indica que
se encuentra listo para establecer una comunicacin.

BYE: este tipo de mensajes son utilizados para finalizar las sesiones
multimedia, el UA que desee finalizar la conversacin enva un BYE.

CANCEL: se utiliza para cancelar una sesin que no se ha establecido en

su totalidad, es decir cuando el destinatario no ha confirmado una
respuesta definitiva.

OPTIONS: Consulta la informacin acerca de las capacidades de envo y

recepcin de telfonos SIP.


1.12 Respuestas SIP

Cuando un agente de usuario o el servidor proxy reciben una solicitud, enva una
respuesta. Cada solicitud debe ser respondida, excepto las solicitudes de ACK
que no devuelven algn tipo de respuesta.


El cdigo de respuesta es un nmero entero de 100 a 699 El cual indica el tipo de
la respuesta. Hay seis clases de respuestas:

1xx son Las respuestas provisionales. Una respuesta provisional es la

respuesta que le dice a su destinatario que la solicitud fue recibida, pero el
resultado del proceso no se conoce an. Las respuestas provisionales slo
se envan cuando el proceso no termina de inmediato

2xx Respuestas Exitosas. Estas respuestas son las ultimas que recibe el
autor de la solicitud, significa que las solicitudes son procesadas y
aceptadas.

3xx se utilizan para redirigir una llamada. Una respuesta de redireccin da

informacin sobre la nueva ubicacin del usuario o un servicio alternativo
que la persona que llama puede utilizar para satisfacer la llamada. Las
respuestas redireccin son generalmente enviadas por servidores proxy.
Cuando el proxy recibe una solicitud y no puede procesarla por cualquier
motivo, se enviar una respuesta de redireccin de llamada y se coloca
otra ubicacin en la respuesta de la persona que se est llamando. Puede
ser la ubicacin de otro proxy o la ubicacin actual del destinatario de la
llamada.

4xx Son las respuestas negativas. Una respuesta de tipo 4xx significa que
el problema est en el lado del emisor. La solicitud no pudo ser procesada
porque contiene sintaxis errnea o la solicitud no se puede realizar en ese
servidor.

5xx Significa que el problema est en el lado servidor. La solicitud es vlida,

pero al parecer el servidor no puede cumplirla. Los clientes por lo general
debe reintentar enviar nuevamente la solicitud.

6xx Significa que la solicitud no puede realizarse en ningn servidor. Esta

respuesta suele ser enviadas por un servidor que tiene informacin
definitiva acerca de un usuario en particular. Los agentes de usuario suelen
enviar una respuesta 603 para rechazar las sesiones que no desea
participar.

Adems de cada una de las clases anteriormente descritas en la primera lnea se
describe la razn del mensaje, es decir todo el proceso que se le dio al mismo.

La solicitud a la que pertenece una determinada respuesta se identifica con el
campo de la cabecera. Adems del nmero de secuencia de este campo de
encabezado contiene tambin el mtodo de la solicitud correspondiente
12



12
SIP.edu Cookbook [En Lnea] http://mit.edu/sip/sip.edu/links.shtml [Citado en 1 de abril de 2011]


1.13 Transacciones

Las transacciones SIP son secuencias de mensajes entre los elemento de una
red. Una transaccin corresponde a una peticin y todas las respuestas a esa
peticin. Esto quiere decir que una transaccin incluir cero o mas respuestas
provisionales y una o ms respuestas finales (en el caso de un mensaje INVITE,
recuerde que este puede ser dividido por un Proxy, por lo tanto tendr mltiples
respuesta finales. Las entidades SIP que almacenan el estado de las
transacciones son denominadas Stateful. Lo hacen por medio del registro de cada
transaccin a travs de un identificador contenido en el encabezado.

Los mensajes SIP se envan de forma independiente en la red, que se colocan
generalmente en las transacciones de los agentes de usuario y ciertos tipos de
servidores proxy. Por lo tanto SIP se dice que es un protocolo transaccional.
13



1.14 Dilogos

Un dilogo es una conversacin entre dos UA. Los dilogos son identificados
usando los campos Identificacin de llamada Call-ID, De From y Para To. Los
mensajes con estos campos iguales pertenecern al mismo dilogo. Uno de los
campos, es utilizado para ordenar los mensajes en un dilogo. De hecho el
tambin representa el nmero de transaccin. Finalmente se puede decir que un
dilogo es una secuencia de transacciones que pertenecen a la misma sesin o
llamada SIP.
14













13
H.323 versus SIP [En Lnea] http://www.packetizer.com/ipmc/h323_vs_sip/ [citado en 10 de
marzo de 2011]
14
Laboratorio de VoIP [En Lnea] http://www.voip.unam.mx/mediawiki/index.php/Protocolo_SIP
[Citado en 10 de marzo de 2011]


2. PROTOCOLO H323


La Recomendacin ITU-T H.323 describe terminales y otras entidades que
proporcionan servicios de comunicaciones multimedia sobre redes basadas en
paquetes (PBN), las cuales no puede garantizar calidad de servicio. H.323 puede
proporcionar audio y video en tiempo real, y / o comunicaciones de datos.


El soporte para audio es obligatorio, mientras que los datos y video son
opcionales, pero tambin tiene la habilidad de utilizar un modo especfico en
comn de operacin, para que todos los terminales que soporten ese mismo tipo
de medios puedan interactuar.


Al igual que con otros protocolos de comunicacin de nivel de operador, H.323 es
un estndar publicado por la Unin Internacional de Telecomunicaciones. Fue
aprobado por los gobiernos del mundo como el estndar internacional para voz,
vdeo y conferencia de datos, la definicin de cmo los dispositivos tales como
ordenadores, telfonos, telfonos mviles, PDAs, telfonos mviles, sistemas de
video conferencia, etc., los cuales traen una nueva experiencia de comunicacin
para el usuario.


H.323 toma prestado tanto de los protocolos PSTN tradicionales y las normas
relacionadas con Internet. Al aprovechar tanto de conmutacin de circuitos y
conmutacin de paquetes estndares de protocolo, H.323 es capaz de integrar sin
problemas con la PSTN, mientras que al mismo tiempo enviar las comunicaciones
multimedia a travs de medios como Internet.
15



H.323 se origin a mediados de los aos 90 como una extensin lgica de los
circuitos de conferencia multimedia, conmutacin de trabajo que se realiza dentro
de la UIT-T. Debido a este patrimonio, H.323 interacta bien con una base
instalada muy grande de equipos de videoconferencia. Sin embargo, H.323 fue

15
H.323 Forum [En linea] http://www.h323forum.org/standards/ [Citado en 1 de abril de 2011]


mucho ms all de ser una "extensin" de los protocolos anteriores. Esto trajo
consigo la capacidad de integrarse con Internet. Con H.323, los usuarios en
ubicaciones remotas son capaces de sostener una llamada de video y editar un
documento conjunto en tiempo real a travs de Internet que utilizan sus equipos
personales. No slo eso, sino H.323 permite a los usuarios personalizar sus
telfonos o servicios de telfono, los usuarios localizar, transferir una llamada, o
realizar cualquier nmero de otras tareas utilizando una interfaz HTTP entre el
cliente H.323 y un servidor en la red, abarcando plenamente el poder de Internet.


Desde el principio, los diseadores de H.323 queran crear un protocolo que
sirviera como el protocolo de red de prxima generacin. H.323 reduce
significativamente el costo de las comunicaciones y facilita la rpida creacin de
nuevos tipos de servicios que nunca antes fueron posibles. Adems, H.323
permite a los puntos finales realizar tareas que antes slo eran posibles de
realizar en los servidores centralizados, las Estancias H.323 estn lejos de la
tecnologa antigua, modela e introduce un extremo inteligente capaz de iniciar y
recibir llamadas sin la dependencia de los elementos de red. Sin embargo,
reconoce las exigencias de negocio para el control centralizado en el proveedor de
servicio y los mercados de las empresas, H.323 tambin permite un control
centralizado sobre el punto final. El nivel o grado en que una compaa o empresa
permita ejercer el control, ser propio dentro de la organizacin.

H.323 impulsa la funcionalidad de control de llamada hasta el punto final, sin dejar
de ofrecer el servicio, con la opcin de controlar cada aspecto de una llamada. En
la red tradicional de conmutacin de circuitos, centraliza los para realizar todas las
funciones de control de llamadas. En algunos casos todo el trafico transita sobre
una red troncal y no es necesario de los servidores, pero si se desea controlar
cuidadosamente el uso del telfono, o la habilitacin de algunos servicios
adicionales, realizar la interceptacin legal, deteccin de nmeros de telfono o
ocultar la identidad de la persona que llama, H.323 proporciona la flexibilidad de
un control centralizado y descentralizado.
16



16
H.323 Information Site [En Linea] http://www.packetizer.com/ipmc/h323/ [Citado en 8 de abril de
2011]


2.1 Arquitectura

Los sistemas basados en sealizacin H.323 giran en torno a cuatro tipos de
componentes principales: terminales, pasarelas, gatekeepers y unidades de
control multipunto.

H.323 establece los estndares para la compresin y descompresin de audio y
vdeo, asegurando que los equipos de distintos fabricantes se intercomuniquen.
As, los usuarios no se tienen que preocupar de cmo el equipo receptor acta,
siempre y cuando cumpla este estndar. Por ejemplo, la gestin del ancho de
banda disponible para evitar que la LAN se colapse con la comunicacin de audio
y vdeo tambin est contemplada en el estndar, esto se realiza limitando el
nmero de conexiones simultneas.


Tambin la norma H.323 hace uso de los procedimientos de sealizacin de los
canales lgicos 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 informacin, terminacin de la llamada y como se
codifica y decodifica. Por ejemplo, cuando se origina una llamada telefnica sobre
Internet, los dos terminales deben negociar cual de los dos ejerce el control, de
manera tal que slo 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 transmisin de datos si no pueden ser gestionados por
el receptor.
17



Como se ha visto, este estndar define un amplio conjunto de caractersticas y
funciones, algunas son necesarias y otras opcionales. Los mensajes H.323 siguen
un esquema de codificacin binaria, especificada mediante sintaxis ASN.1 y reglas
de codificacin de paquetes. Pero el H.323 define mucho ms que las funciones,
este estndar define los siguientes componentes ms relevantes:

17
VoIp foro H.323 Protocolo VoIp [En linea] http://www.voipforo.com/H323/H323objetivo.php
[citado en 15 de abril de 2011]

Terminal

Gateway

Gatekeeper

Unidad de Control Multipunto

Controlador Multipunto

Procesador Multipunto

Proxy H.323

2.2 Terminal

Una terminal H.323 es un dispositivo que se encuentra al extremo de la red, el
cual tiene la funcin de proporcionar comunicaciones bidireccionales en tiempo
real con otra terminal H.323, Gateway o unidad de control multipunto (MCU). La
comunicacin que existe entre estos consta de seales de control, indicaciones,
audio, imagen en color en movimiento y /o datos entre las dos terminales.
Conforme a la especificacin, un terminal H.323 puede proporcionar slo voz, voz
y datos, voz y vdeo, o voz, datos y vdeo.

Por lo general la terminal receptora se encarga de incluir el retardo necesario en
las tramas para obtener una buena sincronizacin. Por ejemplo en el caso cuando
se presenta un retardo en las tramas de audio para mantener la sincronizacin con
las tramas de vdeo. Una terminal H.323 tiene las siguientes caractersticas:
18

Interfaz de usuario: monitores, cmaras, micrfonos, aplicaciones de datos

Cdec de audio y los de vdeo pueden ser opcionales.

Canal de datos.

Unidad de control que es la encargada de gestionar los protocolos RAS,
H.245 y H.225.

Capa H.225 para definicin de mensajes.

Interfaz con la red por paquete

18
Protocolo H.323 [En Linea] http://voip.megawan.com.ar/doku.php/h323 [Citado en 22 de abril de
2011]


2.3 Gateway

Los Gateways o pasarelas, proporcionan la interconexin en ambos sentidos en
tiempo real de las terminales H.323 de la red de paquetes y otros terminales con la
Red Pblica de Telefona Conmutada (PSTN) Red Digital de Servicios
Integrados (ISDN) o bien sea con otro Gateway.

Si bien la integracin entre la red conmutada de telefona (PSTN) y la red de
conmutacin de paquetes es sencilla a niveles bsicos (conexiones va modem,
telefona entre equipo y equipo), no sucede lo mismo cuando se trata de
integracin a gran escala como lo son funcionalidades, servicios asociados, etc.

Para poder obtener la integracin anteriormente mencionada se deben modificar
varios componentes en ambas redes para que esta sea a gran escala. Por
ejemplo las redes IP e Internet deben adoptar una o varias maneras de que las
comunicaciones de VoIP sean un servicio confiable y de calidad adecuada,
mientras que la PSTN debe mejorar la forma en que permita el acceso a sus
servicios al protocolo IP. El punto esta donde comienza y termina la
responsabilidad de una u otra red, es donde se deben centralizar los mayores
esfuerzos para ajustar el mundo IP con el mundo PSTN y es el Gateway de
telefona IP, el dispositivo encargado de dicha integracin.


Por consiguiente la funcin del Gateway, es convertir la seal de voz del telfono
analgico convencional en datos digitales y enviarlos a travs de la red IP hacia
otro Gateway donde se reconstruir la seal analgica y ser enviada al telfono
del abonado de llamada.
19

Las principales funciones del Gateway son:

Destination lookup

Ip Connection Management

19
Packet based multimedia communications [En linea] http://www.itu.int/rec/T-REC-H.323/e
[Citado en 29 de abril de 2011]

Compression/Digitization

Ip Packetization and Transport

Advanced IP/PSTN Signaling

Authorization Access Accounting

2.4 Destination lookup

Tpicamente un Gateway recibe el nmero de telfono al cual se quiere llamar en
forma de tonos multifrecuentes (DTMF), generados por el aparato telefnico.
El Gateway debe ser capaz de asociar el nmero digitado con la direccin IP de
otro Gateway el cual est listo para terminar su parte del proceso en la llamada y
conectar con el nmero digitado a travs de la PSTN.


2.5 IP Connection Management


Despus que el Gateway almacena el extremo al cual se est llamando, el
Gateway debe realizar una conexin de VoIP con el Gateway destino sobre la cual
se transportaran los paquetes de voz. El Gateway en colaboracin con el
Gatekeeper si existe, podr utilizar diferentes protocolos para establecer,
mantener y finalizar la llamada.

La administracin de la conexin es mucho ms compleja debido a esto el
estndar H.323 como el SIP, se complementan con otros estndares para
completar la familia de funciones que deben brindar para poder realizar una
llamada. Dentro de estas funciones se encuentra el intercambio de capacidades,
negociacin de los esquemas de compresin y digitalizacin de la voz.

2.6 Compression/Digitization



Una de las funciones ms importantes de un Gateway es la conversin de la voz
de seal analgica o de la seal digital (PCM) a un flujo de bits de baja velocidad.
Para poder obtener flujos de datos entre 24 y 5.3 Kbps se requiere de mucha
capacidad de procesamiento por parte del procesador del Gateway. Esto se logra
gracias a la gran variedad de cdec de audio, basados en DSP (digital signal
processor).


2.7 IP Packetization and Transport


Despus de convertir la voz en un flujo de bits a baja velocidad, se debe transmitir
a travs de la red de tal forma que la calidad sea similar a la que se obtiene en la
PSTN.

Existen varios procedimientos y protocolos que permiten que la red de
conmutacin de paquetes mantenga un cierto nivel de calidad de la voz tal como
sucede en la red de conmutacin de circuitos.


El mtodo ms importante est asociado a la temporizacin. Tanto en el Gateway
H.323 como el SIP, emplean el Real-Time Protocol (RTP) de la IETF, para
permitirle al Gateway destino reconstruir el flujo de audio entrante con el Timing
intacto, compensando los retardos inherentes a la red de conmutacin de
paquetes.



2.8 Advcanced IP/PSTN Signaling

La PSTN ha tenido una evolucin a travs de los aos, desde una simple conexin
manual a una red de conmutacin de circuitos para el transporte de voz desde una
localidad a otra, y con esto un gran cantidad de servicios como lo es, nmeros
portables, transferencia de llamadas, llamada en espera, etc. Para poder brindar
estos servicios se ha dependido en gran parte de la construccin de redes de


sealizacin independientes integradas pero separadas de las redes del
transporte de voz (CAS, sealizacin de canal asociado). Esta se basa en l un
protocolo de alta confiabilidad basado en paquetes llamado sistema de
sealizacin 7 (SS7).
20



En una red completamente integrada, el Gateway origen debe ser capaz de usar
la red de sealizacin 7 como si el fuese un conmutador de la PSTN.


Se debate acerca de cul es la mejor forma de lograr una verdadera integracin
entre SS7 y los Gateway y Gatekeepers de VoIP. El foco de los debates se centra
en dos protocolos: el Media Gateway Control Protocol (MGCP) de la IETF y en
protocolo de la ITU-T conocido como H.GCP (GCP, Gateway Control Protocol).
Ambos protocolos apuntan a que los Gateway de VoIP se presenten para la red
SS7 como un conmutador de voz tradicional el cual transporte las directivas
recibidas de los puntos de los SCP (Service Control Points). MGCP es visto como
el protocolo a ser integrado en la mayora de los fabricantes de Gateway.

2.9 Authorization Access Accounting

Adems de brindar conectividad a los usuarios, los conmutadores de la PSTN son
responsables de la seguridad, control de acceso y contabilizacin.


Para alcanzar una completa integracin de la tecnologa de VoIP en el entorno de
los proveedores de servicio, se necesita que el servicio de VoIP sea facturable de
forma similar a los sistemas de facturacin aplicados en la PSTN. Es decir que el
cliente pueda recibir una factura con el detalle de cada llamada (da, hora,
duracin, nmero llamado, etc.). Actualmente existe el (CDR, call detail record) el
cual es el responsable de generar un registro de la llamada y enviarlo al centro de
facturacin donde es acumulado por un perodo de tiempo.



20
ITU-T Recomemmetations advanced [En Linea]
http://www.itu.int/itut/recommendations/rec.aspx?rec=H.323 [Citado en 6 de mayo de 2011]


Para realizar la actividad anteriormente descrita en una red de VoIP, el gateway
(router, servidores de acceso, gatekeeper el cual asiste al proceso de conexin)
debe ser capaz de brindar al proveedor de servicios de red, los mismos servicios
que los conmutadores de voz de la PSTN. La metodologa a utilizar depende del
modelo de facturacin utilizado por el proveedor de servicios, y la forma en que
decida ofrecer los mismos. Por ejemplo el servicio de voz sobre IP se puede
ofrecer en una modalidad de pre-pago o post-pago. El pre-pago se puede
implementar mediante la compra de tarjetas en locales comerciales o asignando
nuevos cmputos a travs de la web utilizando un browser e ingresando la tarjeta
de crdito. En la modalidad de post-pago se establece un vnculo contractual entre
el proveedor y el usuario, existiendo la posibilidad de realizar el pago
mensualmente a travs del sistema de dbito bancario, tarjeta de crdito va web o
en efectivo.

Un Gateway debe compartir ciertas caractersticas con otro Gateway, sin importar
el tamao de la red sus funciones son similares dentro de la red a la que prestan
sus servicios. Los componentes que hacen a un Gateway de VoIP son:

DSP (digital signal processors)

Puertos

Interfaces y ranuras para hardware

Configuracin de software

Sistema de reportes

Sistema operativo

Soporte de protocolos

Seguridad

2.10 Gatekeepers

Un Gatekeeper puede ser considerado el cerebro de la red H.323. Es el punto
focal para todas las llamadas dentro de la red H.323. A pesar de que estos no son
un requerimiento obligatorio dentro de una red con sistema H.323 pero en
sistemas de tamao significativo existe la necesidad de centralizar la
administracin del control de llamadas, debido que los Gatekeeper ofrecen
servicios importantes, como lo son la traduccin de direcciones, autorizacin y
autenticacin de terminales y puertas de enlace, gestin de ancho de banda,


contabilidad, facturacin y cobro. Los Gatekeepers tambin pueden proporcionar
servicios de enrutamiento de llamadas. Las funciones del Gatekeeper son:
21

Address translation.

Admissions control.

Bandwidth management.

Zone management`

Call signaling

Es primordial tener en cuenta que el gatekeeper es un componente optativo dentro
del sistema H.323, y que los procedimientos de sealizacin definidos en las
recomendaciones H.225 y H.245 han sido diseados para funcionar con y sin el
gatekeeper. Los sistemas que no tienen gatekeepers permiten a los puntos
extremos realizar la sealizacin ente ellos directamente, poniendo la
responsabilidad de las funciones de administracin y control que provee el
gatekeeper en los propios puntos extremos.


Para que un gatekeeper pueda administrar un terminal o Gateway, este como
primera medida se debe registrar en su propia base de datos y anotar su direccin
IP o alias, adicional de otro tipo de informacin, como por ejemplo los limites de
ancho de banda del canal y el espacio necesario para que el gatekeeper pueda
actuar por el punto extremo. Este registro se puede realizar en forma manual a
travs de archivos de configuracin de gatekeepers o mediante los procedimientos
H.323 de registro y descubrimiento de gatekeepers.




21
Audiovisual And Multimedia System [En Linea] http://www.itu.int/dms_pubrec/itu-t/rec/h/T-REC-
H.323-199909-S!!SUM-HTM-S.htm [Citado 13 de mayo de 2011]


2.11 Controlador Multipunto (MC)

Este controlador brinda funciones de control para respaldar conferencias entre tres
o ms puntos extremos de una conferencia multipunto. El MC realiza el
intercambio de capacidades con cada uno de los puntos extremos de una
conferencia multipunto y adicionalmente enva un conjunto de capacidades a los
puntos extremos de la conferencia evidenciando los modos de funcionamiento en
los que pueden transmitir. El MC logra revisar el conjunto de capacidades que
enva a los terminales como resultado de la incorporacin de terminales a la
conferencia o el abandono de terminales de la misma, por distintos motivos.

Asimismo, el MC establece el modo de comunicacin seleccionado SCM,
(selected communication mode) para la conferencia. El SCM puede ser general
para todos los puntos extremos de la conferencia o, de manera alterna, algunos de
ellos pueden tener un SCM distinto de los otros puntos extremos.

Como parte del establecimiento de una conferencia multipunto, un punto extremo
quedar conectado a un MC en su canal de control H.245. La conexin puede
producirse:

Va una conexin explcita con una MCU;

Va una conexin implcita al MC dentro de un Gatekeeper;

Va una conexin implcita al MC dentro de otro terminal o Gateway de la

conferencia multipunto;

Va una conexin implcita a travs de un Gatekeeper a una MCU.

El modo de conferencia por ejemplo, (descentralizada o centralizada) se origina
despus de la conexin con el MC mediante la sealizacin H.245. Dicha eleccin
puede verse limitada por la capacidad de los puntos extremos o del MC.



Un MC ubicado dentro de un terminal no se puede llamar. Puede ser incluido en la
llamada para procesar la sealizacin H.245 de soporte de las conferencias
multipunto. En este caso, existe la posibilidad que no haya ninguna diferencia
entre el MC y la funcin de control H.245 del terminal.
22


Un MC se encuentra ubicado junto con el Gatekeeper y existe la posibilidad que
pueda ser llamado, no obstante, una MCU ubicado junto con Gatekeeper s tiene
esta posibilidad. Una MCU ubicada con un Gatekeeper puede funcionar como una
MCU independiente. Un MC ubicado con un Gatekeeper puede ser utilizado para
mantener conferencias multipunto, cuando el Gatekeeper reciba los canales de
control H.245 desde los puntos extremos. Asimismo, el Gatekeeper puede
encaminar los canales de control H.245 al MC al comienzo de la llamada o cuando
la conferencia se convierta en conferencia multipunto.

Una MCU contiene siempre un MC. La MCU el cual se puede llamar y el MC
procesa el canal de control H.245 proveniente de todos los dems puntos
extremos.

Cuando dos o ms puntos extremos participen en una conferencia, utilizarn el
procedimiento de resolucin principal subordinado de la Recomendacin H.245
para determinar qu MC controlar la conferencia.

2.12 Procesador Multipunto (MP)

Este procesador es el encargado de recibir todas las hileras de audio, video y
datos de todos los dispositivos finales, que intervienen en una conferencia
multipunto y a su vez devolver estas mismas hileras a cada uno de los puntos
finales.


22
Audiovisual And Multimedia System [En Linea] http://www.itu.int/dms_pubrec/itu-t/rec/h/T-REC-
H.323-199909-S!!SUM-HTM-S.htm


Un MP el cual procese audio tendr la responsabilidad de disponer N salidas de
audio a partir de M entradas de audio conmutado, combinando o mezclando estas
dos cosas. Para realizar una mezcla de audio se necesita la decodificacin del
audio de entrada en seales lineales o analgicas, generando una combinacin
lineal de las seales y recodificando estas seales en formato de audio adecuado.
El MP puede eliminar o atenuar ciertas de las seales de entrada para reducir el
ruido y otras seales las cuales no se desean. Cada salida de audio consigue
tener otra mezcla de seales de entrada posibilita as las conversaciones
privadas.

Una propia MCU mantiene conferencias multipunto centralizadas, la cual est
constituida por un MC y un MP de audio, vdeo y datos. Una MCU tambin soporta
conferencias multipunto descentralizadas, que a su vez tambin est constituida
por un MC y un MP de datos.
2324













23
Audiovisual And Multimedia System [En Linea] http://www.itu.int/dms_pubrec/itu-t/rec/h/T-REC-
H.323-199909-S!!SUM-HTM-S.htm [Citado 13 de mayo de 2011]
24
ITU Work [En Lnea] http://www.itu.int/ITU-T/workprog/wp_item.aspx?isn=6161 [Citado en 20 de
mayo de 2011]



3. MEGACO

El protocolo Megaco o H.248, Media Gateway Control Protocol, est dedicado
para el control de elementos de una puerta de enlace fsico descompuesto
multimedia, que permite la separacin de control de llamadas de la conversin de
los medios de comunicacin. El Media Gateway Control Protocol (MEGACO) es el
resultado de los esfuerzos conjuntos de la IETF y el Estudio del UIT-T 16. Por lo
tanto, el IETF define Megaco es el mismo que H.248 Recomendacin UIT-T.
25



El modelo de conexin del protocolo MEGACO es un modelo orientado objetos. El
cual describe las entidades lgicas u objetos dentro del Media Gateway o MGW
que pueden ser controladas por el Media Gateway Controller o MGC. Los MSC-
Server y GMSC-Server corresponden a MGCs. El CS-MGW equivale a un MGW.
Las trascendentales abstracciones utilizadas en este modelo de conexin son las
terminaciones (termination) as como los contextos (context).
26







Ilustracin 4 Arquitectura de MEGACO


25
http://www.itu.int/rec/T-REC-H.248.1-200203-S/en
26
http://datatracker.ietf.org/wg/megaco/charter/


La descomposicin de la arquitectura Gateway est distribuida sobre la
funcionalidad del control de llamadas y la funcionalidad de procesamiento de
medios de comunicacin a travs de los diferentes elementos que intervienen en
la red. En consecuencia, surge la necesidad de un protocolo de control entre las
entidades, que permitan el control de llamadas para configurar las conexiones de
los medios de comunicacin y las propiedades basadas en los requerimientos de
la llamada.
2728



El modelo de conexin para el protocolo describe las entidades lgicas,
u objetos, en el Media Gateway que pueden ser controlados por el
Media Gateway Controller. Las abstracciones principales utilizados en la
modelo de conexin son las terminaciones y contextos.
2930



Un contexto es una asociacin entre un conjunto de terminaciones.
Existe un tipo especial de contexto, el contexto nulo, que contiene
Todas las terminaciones que no estn asociados a ninguna otra terminacin.
Para la instancia en un Gateway de acceso descompuesto, todas las lneas de
espera son representadas por las terminaciones en el contexto nulo.
3132














4. SS7

27
http://www.sipcenter.com/sip.nsf/html/SIP+and+MGCP+Megaco
28
http://www.networksorcery.com/enp/rfc/rfc3525.txt
29
http://www.faqs.org/rfcs/rfc3015.html
30
http://www.recursosvoip.com/protocolos/megaco.php
31
http://www.javvin.com/protocolMegaco.html
32
http://www.networksorcery.com/enp/rfc/rfc3525.txt



SS7 es un protocolo que tiene ventajas como lo son la Robustez, sealizacin
estandarizada, confiabilidad, flexibilidad, capacidad de interconexin y tambin
ofrece la posibilidad de evolucionar; dejando as el soporte para nuevos y
variados servicios. Este protocolo est basado en una capacidad comn para el
transporte de sealizacin, llamada la parte de transferencia de mensaje (MTP) y
la parte de usuario ISDN, MTP y la parte de control de sealizacin de conexin
(SCCP) forman la parte de los servicios de red (NSP), los cuales realizan las
funciones que corresponden a las 3 primeras capas del modelo OSI. El MTP
interpreta un sistema de transferencia de mensajes, el cual permite transmitir
informacin de sealizacin por medio de la red hacia el punto de destino.
33
Este
componente est constituido por tres niveles:

Nivel 1: enlace de datos de sealizacin

Nivel 2: enlace de sealizacin

Nivel 3: red de sealizacin.

SCCP fue agregado en el ao 1984, extendiendo as los servicios de la MTP para
poder alcanzar el equivalente funcional del modelo OSI en nivel tres y as
simplificar el transporte de mensaje orientado a conexin y el de sin conexin
(datagrama). La estructura de SSCP est conformada por cuatro bloques
funcionales: orientado a conexin, control sin conexin, de gestin y
enrutamiento. TCAP (Transaction Capabilities Application Part) proporciona un
mecanismo para aplicaciones orientadas a transacciones. Hace referencia al
conjunto de protocolos y funciones utilizadas por las aplicaciones distribuidas en
una misma red, este se compone de dos subcapas: la de componente (CSL) y la
de transaccin (TSL). La parte ISP representa el conjunto de funciones
suministradas por las capas de transporte, sesin y presentacin del modelo OSI e
incluye estos servicios para que sean solicitados en aplicaciones futuras. La parte
de operacin, mantenimiento y administracin (OMAP) proporciona los protocolos
de aplicacin para monitorear, coordinar y controlar los recursos de la red que
hacen posible las comunicaciones sobre SS7.
34
Los componentes fundamentales
del sistema de sealizacin SS7 son los puntos de sealizacin (SP) y de enlaces

33
Q.700: Introduction to CCITT Signalling System No. 7 [En Lnea] http://www.itu.int/rec/T-REC-
Q.700-199303-I/e [Citado el 10 de Julio de 2010]
34
SS7 (Signaling System 7) [En Lnea] http://www.tech-faq.com/ss7.html [Citado el 13 de Julio de
2011]


que unen a los puntos (SL). Con este sistema se pueden usar varios modos de
sealizacin: modo asociado y casi asociado.
35



El sistema SS7 se ha desarrollado para satisfacer las necesidades de datos como
de voz, admitiendo una extensa gama de conexiones, incluyendo el modo
paquete, el modo circuito, ATM y Frame Relay. Asimismo permite toda la gama de
servicios suplementarios.
36
Los canales dedicados a sealizacin de control hacen
ms factible la modificacin de las caractersticas de una llamada durante su fase
de comunicacin y permiten la separacin de la parte de conmutacin de la parte
de control. Resumidamente, SS7 es un protocolo que tiene beneficios
significativos representados por:

Sealizacin estndar por canal comn

Flexibilidad

Robustez y confiabilidad

Probabilidad de evolucin

Capacidad de interconexin

Soporte para nuevos servicios.

Por lo anterior se describir la arquitectura del SS7 y su relacin con el Modelo de
Referencia OSI, basado en una capacidad comn para el transporte de
sealizacin, llamada la parte de transferencia de mensaje MTP (Message
Transfer Part) y de las partes de usuarios, as como la parte de usuario ISDN.
MTP y la parte de control de sealizacin de conexin SCCP (Signalling
Connection Control Part) forman la parte de los servicios de red NSP (Network
Services Part), las cuales realizan las funciones correspondientes a las primeras 3
capas del modelo OSI.

35
SS7 Mobile in a Minute [En Lnea] http://www.mobilein.com/ss7.htm [Citado el 13 de Julio de
2011]
36
Protocolo de sealizacion numero 7 [En lnea] http://voip.megawan.com.ar/doku.php/ss7 [Citado
el 13 de julio de 2011]




4.1 (MTP) Parte de transferencia de mensajes

Un enlace de datos de sealizacin es un trayecto de transmisin bidireccional
para la sealizacin, el cual est conformado por dos canales de datos que
funcionan simultneamente en sentido opuesto de la transmisin de datos a la
misma velocidad. Esta parte constituye el nivel ms bajo en la jerarqua funcional
del protocolo de Sealizacin 7. Este representa un sistema de transferencia de
mensajes, el cual admite transmitir informacin de sealizacin por medio de la
red hacia el punto final. El objetivo global de MTP es facilitar la transferencia y la
entrega confiable de la informacin de sealizacin por medio de la red de
sealizacin, tomando as las acciones necesarias respondiendo a las fallas o a la
congestin que esta pueda presentar.
37


4.2 Funcin a nivel de enlace de datos de sealizacin


Un enlace de datos es una ruta de transmisin bidireccional para sealizacin, que
radica de dos canales de datos operando simultneamente en direcciones
inversas a la velocidad de transmisin. Esta funcin desempea a cabalidad la
definicin del modelo OSI en la capa fsica nivel uno y puede ser de tipo analgico
o digital. Los enlaces de tipo digital estn conformados por canales de transmisin
digital y los equipos terminales, que poseen una interfaz para terminales de
sealizacin. Los canales de transmisin digital se derivan de un flujo digital
mltiplex, el cual est constituido por una estructura de trama tipo PCM, o de
circuitos de datos. Los enlaces analgicos estn compuestos de canales de
transmisin analgicos a frecuencia vocal. Para los digitales la velocidad que se
recomienda de acuerdo a los estndares ANSI, es de 56 kb/s y de acuerdo a la
recomendacin de la CCITT, es de 64 kb/s. Para estos enlaces tambin se puede
recurrir a velocidades ms bajas, pero se tiene que tener en cuenta los requisitos
de retardo del mensaje relativo a las partes de usuario.




37
Signalling System #7 (SS7) [En Linea] http://www.telecomspace.com/ss7.html [Citado el 16 de
Julio de 2011]



4.3 Funcin a nivel de enlace de sealizacin


Las funciones que estn agrupadas en este nivel corresponden a la capa dos del
modelo OSI y son las encargadas de controlar la trasferencia segura de mensajes
de sealizacin en un enlace, sucede entre dos puntos que estn unidos
directamente. Los mensajes de este tipo son de longitud variable y son
denominados unidades de seal. Existen tres tipos de unidades, que se
diferencian debido a un campo indicador de la longitud del mensaje, designado
unidad de mensaje de sealizacin, seal de unidad de estado de enlace y la
unidad de llenado de seal. En el nivel de enlace las funciones tienen una gran
semejanza con protocolos de transmisin de datos orientados a bits, los cuales
son usados en las redes de computadores, pero existen algunas diferencias
significativas, debido a las necesidades propias de la sealizacin en las
telecomunicaciones (perdida de paquetes, mensajes fuera de secuencia, retardos
desproporcionados, etc.), lo cual se requiere que la red acuda prontamente a
eventos como lo son fallas del sistema y de componentes. Para abrir y cerrar las
unidades de seal se usa un Flag de 8 bits y para la deteccin de errores se usa el
control de redundancia cclico el cual se basa en el polinomio generador de 16
bits. No obstante, cuando no hay nada que transmitir, se envan unidades de
relleno, en cambio de un Flag, tal cual como se hace en otros protocolos, el motivo
de esto es facilitar un mtodo estable de monitoreo de errores, de tal manera que
los enlaces con fallas se detecten rpidamente y sean puestos fuera de servicio.
38


4.4 Funcin de red de sealizacin


Este conjunto de funciones corresponde al nivel tres de la capa del modelo OSI
se encarga de la transferencia de mensajes entre cada punto de sealizacin que
a su vez son nodos de la red de sealizacin. Este conjunto de funciones alcanzan
a ser divididas en dos categoras: gestin de la red de sealizacin y manejo de
mensajes de sealizacin. La primera admite la reconfiguracin de la red de
sealizacin si ocurren fallas de los puntos de sealizacin o de los enlaces,
realiza un control del trfico en caso de bloqueo o congestin. La segunda
generara el enrutamiento, la discriminacin, y la distribucin de los mensajes. La

38
SS7 Tutorial [En lnea] http://www.pt.com/page/tutorials/ss7-tutorial [Citado el 18 de julio de
2011]


finalidad es que, cuando suceda una falla, se genere la reconfiguracin de tal
forma que no exista perdida de los mensajes o se dupliquen o bien que sean
puestos en secuencia errada y los retardos de los mensajes no se forjen
excesivos.


4.5 (SCCP) Parte de control de conexin de sealizacin


Esta parte debera pertenecer al nivel cuatro debido a que est por encima de
MTP, pero en realidad hace parte de la capa tres, todo esto debido a que MTP por
si solo en ocasiones no logra proveer el completo conjunto de funciones y
servicios descritos en las capas inferiores. Lo anterior se debe a que MTP fue
desarrollado previamente a SSCP y fue creado para las exigencias en tiempo real
de aplicaciones telefnicas, pero consecutivamente se evidencio que haba otras
aplicaciones que requeran servicios adicionales, se necesitaban capacidades del
modelo OSI completo, como los eran: transferencia de mensajes orientados a
conexin y capacidad de direccionamiento aumentada. SCCP fue hecho para
suplir esta necesidad. La estructura que da como resultado de la divisin de las
funciones de red entre MPT a nivel 3 y SCCP, posee mejoras en el alcance que
los servicios SCCP se pueden utilizar slo cuando sea necesario, admitiendo que
el MTP atienda las necesidades de las aplicaciones que emplean la transferencia
de mensajes sin conexin con capacidad de almacenamiento limitada.
39



SCCP fue diseado con el propsito de ampliar los servicios de la MTP para lograr
alcanzar la funcionalidad de la capa de red del modelo OSI y asi facilitar el
transporte de mensajes orientados a conexin. La estructura de SSCP esta
conformado por cuatro bloques funcionales. El orientado a conexin regula el
establecimiento y finalizacin de circuitos de sealizacin adems de facilitar la
transferencia de los datos de conexin de sealizacin. El de control sin conexin
provee la transferencia de unidades de datos de tipo sin conexin. El de gestin
facilita contenidos por encima de MTP para administrar la congestin y fallas. Por
ltimo, el bloque de enrutamiento captura los mensajes recibidos de MTP y otros
bloques funcionales y los enva al MPT el cual est debajo del otro bloque
funcional. SCCP suministra capacidades extensas de direccionamiento para

39
SS7 Protocol Suite [En Lnea] http://www.protocols.com/pbook/ss7.htm [Citado el 20 de julio de
2011]


enrutar mensajes dentro de la red SS7 y su posterior distribucin dentro de un
nodo de la red. Una de estas capacidades es la funcin de traduccin que
convierte una direccin llamada Titulo Global, que es un nmero especial, en otra
direccin que la red de sealizacin utiliza para enrutar el mensaje.


4.6 (TCAP) Parte de aplicacin de capacidades de transaccin


TCAP fue implantada despus de la SCCP y provee un mecanismo para las
aplicaciones orientadas a transacciones en cambio de las orientadas a
transacciones. La capacidad de transacciones hace referencia al conjunto de
protocolos y funciones empleados por aplicaciones distribuidas en una red, con el
propsito de comunicar una con otra. TC (Transaction Capabilities) hace
referencia a los protocolos de aplicacin, adems de los servicios y protocolos que
los soportan. Para las aplicaciones desarrolladas en el momento, TCAP usa
directamente los servicios de SCCP, que a su vez usa los servicios de MTP,
mientras que las capas de nivel superior son nulas. Fundamentalmente TCAP
permite a un conjunto de herramientas, en un entorno sin conexin, para ser
utilizado en alguna aplicacin desde un nodo el cual invoca la ejecucin de un
procedimiento en otro nodo para intercambiar los resultados. Como tal, incluye
protocolos y servicios para efectuar operaciones remotas y est estrechamente
relacionado con el protocolo de operacin remota del modelo OSI. Las
aplicaciones distribuidas que utilizan TCAP pueden residir en las bases de datos
como en las centrales. El principal uso de TCAP en las redes sirve para activar
procedimientos remotos que poseen las redes inteligentes. TCAP proporciona
procedimientos para aplicaciones intensas que funcionan en tiempo real de la
forma interrogacin respuesta.
40



Las aplicaciones de TCAP pueden ser interactivas las cuales consisten en
transacciones transitorias donde el retardo se obliga a ser evitado, por lo que se
usa el modo sin conexin, o de lote que involucran el movimiento de grandes
volmenes de datos y usando el modo de conexin.
4.7 (ISP) Parte intermedia de servicios


40
Conmutacin de Paquetes protocolos IP [En lnea] http://www.zator.com/Internet/A3_1.htm
[Citado el 22 de julio de 2011]



La parte ISP no est ciertamente precisada, y como resultado, no est relacionada
en el SS7, pero habitualmente acepta que represente al conjunto de funciones
proporcionadas por las capas de transporte, sesin y presentacin del modelo OSI
la cual se incluye en el SS7 para el caso de que tales servicios sean necesitados a
futuro. Por consiguiente simplemente pretende disponer de un sitio reservado para
la insercin futura de protocolos apropiados, cuando los servicios las capas
anteriormente mencionadas sean necesarios para aplicaciones SCCP.


4.8 (OMAP) La parte de operacin, mantenimiento y administracin


Esta parte permite a los protocolos de aplicacin coordinar controlar y monitorear,
los recursos de la red que hacen viables las comunicaciones fundamentadas en el
SS7. OMAP es un ejemplo de un usuario de TCAP, esto es un ASE (Application
Service Element), a nivel de capas del modelo OSI, y suministra las funciones de
mantenimiento y administracin de la red SS7. Est cimentado en el modelo OSI,
pero por el momento sus estndares estn limitados a algunas funciones
especficas, tales como la prueba de verificacin de un vlido enrutamiento MTP a
travs de la prueba MRTV y de la validez de un circuito a travs de la prueba
CVT.
41



4.9 Las partes del usuario


Estas partes proporcionan las funciones necesarias para la utilizacin de las capas
bajas como lo es la MTP por parte de un usuario. La parte de usuario ISDN,
llamada ISDN-UP (ISDN-User Part), o ISUP, es un protocolo el cual est orientado
a mensaje, determinado para proporcionar el control de llamadas. Provee las
funciones de sealizacin que son ineludibles para acceder a los servicios de
soportes bsicos y los servicios suplementarios en el cual intervienen aplicaciones
en el ambiente ISDN. La parte de ISUP no mantiene la estructura de la capa de
aplicacin OSI. Este trmino est mal determinado debido a que no se refiere al

41
Conmutacin, Red Inteligente y Servicios Convergente SS7 [En lnea] http://www.pucp.edu.pe/
puntoedu/index.php?option=com_content&task=view&id=2466 [Citado el 22 de Julio de 2011]


usuario ISDN, sino que ISUP es un usuario de las capas bajas del protocolo SS7.
Otros usuarios de MTP son SCCP y TCAP.


Los posibles servicios con ISUP incluyen servicios portadores bsicos y una
variedad de servicios suplementarios. ISUP utiliza algunas de las ventajas de MTP
para el envi seguro de mensajes de sealizacin entre centrales. Adems toma
a SCCP para lo consiguiente con la sealizacin de extremo a extremo. Conforme
con el modelo OSI, para alcanzar el intercambio de informacin entre ISUP y MTP
este se lleva a cabo por el uso de parmetros transportados por primitivas de
servicio intercapa. En ISUP los mensajes poseen longitudes variables, hasta 272
octetos de bytes, los cuales tienen una etiqueta de enrutamiento que permite
saber cul es el origen y destino del mensaje, denominado cdigo de identificacin
del circuito
42



El servicio bsico ofrecido por ISDN-UP es el control de conexiones con
conmutacin de circuito entre las centrales de los subscritores. La sealizacin de
acceso del usuario de la red se realiza por medio del protocolo DSS1 (Q.931)
sobre el canal D. Los servicios suplementarios incluyen sealizacin de usuario a
usuario, grupo cerrado de usuarios, identificacin del usuario, redireccionamiento
de llamadas, etc. Los mensajes ISDN-UP para tales servicios se transfieren ya sea
por el mtodo de enlace a enlace basndose en MTP o por el mtodo de extremo
a extremo basndose en SCCP.
43









42
SS7 Protocol Overview [En Lnea] http://fengnet.com/book/voip/ch04lev1sec2.html [Citado el 22
de Julio de 2011]
43
SS7 Overview [En Linea] http://www.techfest.com/networking/wan/ss7.htm [Citado el 22 de Julio
de 2011]



5. ANLISIS DE LOS PROTOCOLOS

De acuerdo a las bases tericas evidenciadas en este documento se denota que
uno de los protocolos que se ajusta ms fcil a las organizaciones que inician la
incursin de esta tecnologa, afirmando a SIP como una infraestructura
tecnolgica que permitir abarcar comunicaciones unificadas basadas sobre el
protocolo IP. Esta infraestructura incorporar soluciones de localizacin y
movilidad. Estas funciones estn integradas con el proveedor de servicios,
proporcionando as un conjunto de herramientas que permite ampliar el alcance de
los servicios. Por lo anterior la integracin de estos componentes se beneficiar de
servicios de comunicaciones ms flexibles para aumentar la productividad, abrir
posibilidades de integracin de soluciones de comunicacin con aplicaciones
comerciales y permitir que el cliente indique por s mismo sus preferencias.
Cuando los clientes tengan puntos finales habilitados para SIP, los proveedores de
servicios podrn ofrecer a los clientes un amplio conjunto de aplicaciones que en
la actualidad el proveedor posee en sus redes.

Los operadores (de mvil y fijo) tambin estn implantando SIP dentro de su
estrategia de convergencia, aprovechando de este modo la escalabilidad y
interoperabilidad que nos proporciona el protocolo SIP.
A continuacin se describirn cada una de las principales caractersticas del
protocolo SIP teniendo en cuenta sus ventajas y desventajas frente a los dems
protocolos.

El protocolo SIP se comporta de manera transparente, admitiendo as el mapeo de
nombres y la redireccin de servicios permitiendo as la implementacin de las
redes inteligentes.
Para lograr la integracin de los servicios de una red inteligente el protocolo SIP
acondiciona distintas funciones las cuales se muestran a continuacin:

Caractersticas SIP
SIP proporciona soporte para la movilidad localizacin
Permite la negociacin de parmetros
Disponibilidad del usuario
Establecimiento y mantenimiento de sesiones




En conclusin, el protocolo SIP permite la interaccin entre cada uno de los
dispositivos, lo cual se obtiene con distintos tipos de mensajes propietarios del
protocolo. Estos mensajes suministran capacidades para realizar el registrar o
invitar un usuario a una sesin, negociando los parmetros de una sesin, para
lograr establecer una comunicacin entre dos a ms terminales y su respectiva
finalizacin.
Definitivamente, se denota que el protocolo SIP da tras da se vuelve ms
robusto, por consiguiente se muestran los aspectos ms importantes referentes a
dicho protocolo

El control de llamadas es sin estado, y proporciona escalabilidad entre los
dispositivos telefnicos y los servidores.

SIP no requiere muchos ciclos de CPU para generar mensajes de
sealizacin de manera que el servidor puede manejar transacciones.

Las llamadas SIP son independientes de la presencia de una conexin en
la capa de transporte.

SIP posee una autentificacin del que realiza la llamada y del que la recibe
mediante mecanismos HTTP.

Permite la autenticacin y encriptacin salto a salto por SSL/TSL pero
tambin puede usar la capa de transporte o un mecanismo de seguridad de
HTTP, como SSH o S-HTTP.

Los proxy SIP pueden reconocer la sealizacin de la llamada y puede
bifurcar a cualquier nmero de dispositivos paralelamente.







CONCLUSIONES


El protocolo H.323, propuesto por la ITU-T, como el protocolo SIP, propuesto por
el IETF, concretan mecanismos de sealizacin para establecer y finalizar
llamadas, as como funciones de control de conferencia, negociacin de
capacidades y los servicios adicionales que estos ofrecen sobre la red conmutada
de paquetes.


SIP se dise posteriormente con la pretensin de presentar dos ventajas frente a
H.323: Mayor flexibilidad para incorporar nuevas funciones y una ms fcil
Implementacin y depuracin.


El Protocolo SIP es un protocolo ligero similar a otros desarrollados previamente
por el IETF como HTTP el cual es amplia extensin, mientras que H.323 sigue un
esquema aproximado al sistema tradicional de conmutacin de circuitos,
basndose en la sealizacin de la red digital de servicios integrados, y otras
recomendaciones de la serie H.


Las estructura en las que se basan SIP y H.323 y Megaco son esencialmente
distintos no obstante, al realizar una comparacin de la evolucin de estos
estndares durante el trascurso de estos aos, se llega a la conclusin de que, a
medida que se definen nuevas desarrollos en el protocolo SIP y surgen nuevas
versiones de H.323 cada vez se diferencian menos en cuanto a las
funcionalidades y posibilidades que estos brindan, con respecto a Megaco
depende ms de la conexin y se integra con cualquiera de estos protocolos.


Un factor comn en estas arquitecturas es el protocolo que utilizan para el
transporte, para el intercambio de datos multimedia en el transcurso de las
sesiones, aunque no est precisado, se utiliza RTP, sin que haya ninguna
alternativa otra alternativa.




Las condiciones que debe tener una arquitectura en general para que pueda dar
soporte, al menos, a un sistema ntegro de telefona que se compenetre y
sustituya posteriormente a la red telefnica tradicional debe tener en cuenta los
siguientes aspectos: Escalabilidad de un gran nmero de usuarios en todo el
mundo, mantener llamadas activas en forma simultnea, permitir la gestin de la
red de tal modo que exista la posibilidad de aplicar polticas de control y
tarificacin, proveer mtodos para brindar una mejor calidad de servicio,
interoperabilidad entre los distintos fabricantes, protocolos y versiones de de cada
uno de estos y por ltimo facilidad de ampliacin.























BIBLIOGRAFA

A Hitchhiker's Guide to the Session Initiation Protocol [En Linea]
http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide-06 [Citado en 24 de marzo
de 2011]
Audiovisual And Multimedia System [En Linea] http://www.itu.int/dms_pubrec/itu-
t/rec/h/T-REC-H.323-199909-S!!SUM-HTM-S.htm [Citado 13 de mayo de 2011]
B2BUA Documentation [En Lnea]
http://www.b2bua.org/wiki/B2BUADocumentation [Citado en 15 de abril es 2011]
Central Telefnica IP de 3CX para Windows [En Lnea] http://www.3cx.es/ [Citado
en 6 de mayo 2011]

Characteristics About SIP [En Lnea]
http://www.sipcenter.com/sip.nsf/html/Characteristics [Citado en 13 de mayo de
2011]
Conmutacin de Paquetes protocolos IP [En lnea]
http://www.zator.com/Internet/A3_1.htm [Citado el 22 de julio de 2011]
Conmutacin, Red Inteligente y Servicios Convergente SS7 [En lnea]
http://www.pucp.edu.pe/
puntoedu/index.php?option=com_content&task=view&id=2466 [Citado el 22 de
Julio de 2011]
Entidades bsicas SIP [En Lnea]
http://es.wikitel.info/wiki/Entidades_b%C3%A1sicas_SIP [Citado en 10 de marzo
de 2011]
Gateway Control Protocol [En
linea]http://www.networksorcery.com/enp/rfc/rfc3525.txt[citado 12 de junio 2011]
H.248.1: Gateway control protocol [En linea] http://www.itu.int/rec/T-REC-H.248.1-
200203-S/en [citado 6 de mayo 2011]
H.323 Forum [En linea] http://www.h323forum.org/standards/ [Citado en 1 de
abril de 2011]


H.323 Information Site [En Linea] http://www.packetizer.com/ipmc/h323/ [Citado en
8 de abril de 2011]
H.323 versus SIP [En Lnea] http://www.packetizer.com/ipmc/h323_vs_sip/ [citado
en 10 de marzo de 2011]
ITU-T Recomemmetations advanced [En Linea]
http://www.itu.int/itut/recommendations/rec.aspx?rec=H.323 [Citado en 6 de mayo
de 2011]
ITU Work [En Lnea] http://www.itu.int/ITU-T/workprog/wp_item.aspx?isn=6161
[Citado en 20 de mayo de 2011]
Laboratorio de VoIP [En Lnea]
http://www.voip.unam.mx/mediawiki/index.php/Protocolo_SIP [Citado en 10 de
marzo de 2011]
Media Gateway Control (megaco) [En
lnea]http://datatracker.ietf.org/wg/megaco/charter/[citado 27 de 2011]
Megaco/H.248: Media Gateway Control Protocol [Enlinea
]http://www.javvin.com/protocol Megaco.html [citado 20 de mayo 2011]
MEGACO vs MGCP [Enlinea]
http://hive1.hive.packtizer.com/users/packetizer/papers/ipmc/MEGAC
OvsMGCP_v3.pdf [citado 6 de junio 2011]
Packet based multimedia communications [En linea] http://www.itu.int/rec/T-
REC-H.323/e [Citado en 29 de abril de 2011]
Protocolo de sealizacin numero 7 [En lnea]
http://voip.megawan.com.ar/doku.php/ss7 [Citado el 13 de julio de 2011]
Protocolo H.248 (MEGACO)[En
linea]http://www.recursosvoip.com/protocolos/megaco.php[citado 13 de mayo
2011]
Protocolo H.323 [En Linea] http://voip.megawan.com.ar/doku.php/h323 [Citado en
22 de abril de 2011]
Q.700: Introduction to CCITT Signalling System No. 7 [En Lnea]
http://www.itu.int/rec/T-REC-Q.700-199303-I/e [Citado el 10 de Julio de 2010]


RedIris video conferencia H.323 [En Lnea]
http://www.rediris.es/mmedia/H323Info.es.html [Citado en 13 de mayo de 2011]
RFC 3261 SIP: Session Initiation Protocol [En Lnea]
http://tools.ietf.org/html/rfc3261#section-7 [Citado en 10 de marzo de 2011]
RFC 3015 - Megaco Protocol Version [En linea]
http://www.faqs.org/rfcs/rfc3015.html [citado 10 de junio 2011]
Session Initiation Protocol [En Lnea] http://datatracker.ietf.org/wg/sip/charter/
[Citado en 22 de abril de 2011]
Signalling System #7 (SS7) [En Linea] http://www.telecomspace.com/ss7.html
[Citado el 16 de Julio de 2011]
Sip.edu and VoIP SIG Workshop [En Lnea] http://www.internet2.edu/sip.edu/
[Citado en 29 de abril de 2011]
SIP.edu Cookbook [En Lnea] http://mit.edu/sip/sip.edu/links.shtml [Citado en 1 de
abril de 2011]
SIP Forum Presentations on SIP [En Linea]
http://www.sipforum.org/component/option,com_
docman/task,cat_view/gid,60/Itemid,261/ [Citado en 6 de mayo de 2011]

SIP and MGCP/Megaco [En lnea]
http://www.sipcenter.com/sip.nsf/html/SIP+and+MGCP+Megaco [citado 8 de junio
2011]
SS7 Mobile in a Minute [En Lnea] http://www.mobilein.com/ss7.htm [Citado el 13
de Julio de 2011]
SS7 Protocol Suite [En Lnea] http://www.protocols.com/pbook/ss7.htm [Citado el
20 de julio de 2011]
SS7 (Signaling System 7) [En Lnea] http://www.tech-faq.com/ss7.html [Citado el
13 de Julio de 2011]
SS7 Tutorial [En lnea] http://www.pt.com/page/tutorials/ss7-tutorial [Citado el 18
de julio de 2011]
SS7 Protocol Overview [En Lnea] http://fengnet.com/book/voip/ch04lev1sec2.html
[Citado el 22 de Julio de 2011]


SS7 Overview [En Linea] http://www.techfest.com/networking/wan/ss7.htm [Citado
el 22 de Julio de 2011]
Tech invite SIP Protocol Structure [En Lnea] http://www.tech-invite.com/Ti-sip-
archi.html [Citado en 1 de abril de 2011]
The IP Telecommunications Portal [En Lnea] http://www.iptel.org/ [Citado en 1 de
abril de 2011]
The SIP center A portal for the commercial development of SIP [En Lnea]
http://www.sipcenter.com/sip.nsf/html/Whitepapers [Citado en 17 de marzo de
2011]
Understanding SIP exchanges by experimentation [En
Linea]http://4z.com/People/emin-gabrielyan/public/070501-sip-docs/ [Citado en 8
de abril de 2011]
VoIP foro Arquitectura SIP [En lnea] http://www.voipforo.com/SIP/SIPejemplo.php
[citado en 10 de marzo de 2011]
VoIp foro H.323 Protocolo VoIp [En lnea]
http://www.voipforo.com/H323/H323objetivo.php [citado en 15 de abril de 2011]