conexion ims.pdf

Recomendaciones Para el Desarrollo de Aplicaciones P2P
Utilizando el Protocolo SIP
ANEXO C
SEÑALIZACIÓN BASADA EN EL PROTOCOLO SIP EN
REDES DE 3G
Wilson Yecit Ortiz Sánchez
Director: Ing. Javier Alexander Hurtado
Universidad del Cauca
Facultad de Ingeniería Electrónica y Telecomunicaciones
Departamento de Telemática
Línea de Investigación en Ingeniería de Sistemas Telemáticos
Popayán, Enero de 2007

TABLA DE CONTENIDO
ANEXO C SEÑALIZACIÓN BASADA EN EL PROTOCOLO SIP EN REDES DE 3G... 1
C1 PROTOCOLO SIP............................................................................................... 1
ARQUITECTURA SIP................................................................................................ 4
C3 COMPONENTES DE LA ARQUITECTURA SIP................................................... 5
C3.1 Agente de Usuario SIP (UA).......................................................................... 5
C3.2 Servidor Proxy SIP ....................................................................................... 6
C3.3 Servidor de Redireccionamiento SIP ............................................................. 6
C3.4 Registro SIP .................................................................................................. 7
C3.5 Agente de Usuario Back to Back (B2BUA) ................................................... 7
C4 MENSAJES SIP .................................................................................................. 7
C4.1 Solicitudes SIP ............................................................................................. 8
C4.2 Respuestas SIP............................................................................................ 9
C4.3 Sintaxis de los Mensajes SIP ..................................................................... 10
C4.4 Cabeceras y Campos SIP ........................................................................... 10
C4.4.1 Línea de Inicio (Start Line)...........................................................................10
C4.4.2 Encabezamiento general (General Header) .................................................10
C4.4.3 Cuerpo del mensaje.....................................................................................13
C5 MODO DE OPERACIÓN SIP ............................................................................ 13
C6 INTERACCIÓN DE ENTIDADES....................................................................... 14
C6.1 Establecimiento de una Sesión y su Terminación........................................ 15
C6.2 Redirección de Llamada.............................................................................. 16
C6.3 Estableciendo una Sesión a Trabes de Servidores Proxy............................ 17
C7 PROTOCOLOS DE SOPORTE ......................................................................... 22
C7.1 Protocolo de Control de Pasarela de Medios (MGCP).................................. 23
C7.2 RTP y RTCP (Protocolo de Transporte en Tiempo real y Protocolo de Control
en Tiempo Real) ................................................................................................... 24
C7.3 Protocolo de Flujos en Tiempo Real (RTSP) .............................................. 24
C7.4 Protocolo de Reserva de Recursos (RSVP) ................................................ 24
C7.5 Protocolo de Descripción de Sesión (SDP) ................................................. 25
C7.6 Protocolo de Anuncio de Sesión (SAP) ....................................................... 26
C8 SUBSISTEMA MULTIMEDIA DE INTERNET (IMS)........................................... 26
C8.1 La Arquitectura IMS..................................................................................... 27
C8.2 Funciones de IMS....................................................................................... 28
C8.3 Lo esencial de IMS y SIP............................................................................ 29
C9 EJEMPLOS DE APLICACIONES SIP................................................................ 30

C9.1 Presione para Hablar................................................................................... 31
C9.2 Video Compartido........................................................................................ 31
C9.3 Compartir Contenidos.................................................................................. 31
C9.4 Presencia .................................................................................................... 31
C9.5 Mensajería .................................................................................................. 32
C9.6 Voz Sobre IP ............................................................................................... 32
C9.7 Llamada Rica .............................................................................................. 32
C9.8 Aplicaciones SIP Tripartidas........................................................................ 32
BIBLIOGRAFÍA ........................................................................................................... 33

LISTA DE FIGURAS
Figura 1. Arquitectura SIP. ............................................................................................ 5
Figura 2. Sintaxis general de las peticiones y respuestas SIP..................................... 13
Figura 3. Establecimiento y terminación de una sesión. .............................................. 15
Figura 4. Redirección de llamada utilizando un servidor de redirección....................... 16
Figura 5. Escenario de establecimiento de una sesión con un Proxy SIP.................... 18
Figura 6. Establecimiento de una sesión entre clientes del mismo dominio................. 20
Figura 7. Establecimiento de una sesión SIP entre clientes de diferentes dominios. ... 21
Figura 8. Arquitectura multimedia del IETF. ................................................................ 23
Figura 9. Arquitectura del sistema IMS........................................................................ 27
Figura 10. Establecimiento de una sesión con IMS. .................................................... 29

LISTA DE TABLAS
Tabla 1. Métodos SIP.................................................................................................... 8
Tabla 2. Clases y mensajes de respuesta SIP. ........................................................... 10

ANEXO C SEÑALIZACIÓN BASADA EN EL PROTOCOLO SIP EN REDES
DE 3G
C1 PROTOCOLO SIP
SIP es un protocolo de control de la capa de aplicación que puede establecer,
modificar y terminar sesiones multimedia con uno o más participantes. En estas
sesiones se pueden desarrollar comunicaciones de voz, conferencias multimedia,
intercambio de medios o contenidos y juegos (el establecimiento de una sesión de
comunicación con SIP también se le sigue denominando “llamada” por consiguiente en
este documento se utilizaran ambos términos indistintamente). SIP aumenta el control
de la comunicación al usuario, trasladando el control de la aplicación al punto terminal,
como lo hace HTTP, eliminando así la necesidad de funciones centrales de
conmutación, esto permite que una o más personas puedan adicionar un nuevo
individuo o cancelar una solicitud de adición a la sesión, al igual que las conferencias
multicast. Los medios pueden ser adicionados (o removidos) a la sesión existente
siempre y cuando exista el soporte en los equipos terminales. [1]
Además de los servicios tradicionales como la transmisión de voz, video y compartir
contenidos, SIP soporta nuevas características, nuevos tipos de servicios y la creación
de servicios a partir de los existentes. Entre los cuales aparece un tipo de "reenvío de
llamada" que permite a los usuarios especificar su ubicación actual y las llamadas
entrantes le serán reenviadas a ese destino pudiéndose elegir como destino el "correo
de voz" o cualquier máquina contestadota. Una nueva característica de servicio es la
posibilidad de responder a una llamada con un tipo de medio distinto; esto permite que
una secuencia de voz entrante sea respondida con una página Web. También existe la

posibilidad para un usuario estar disponible en varios equipos terminales y responder
desde el mas conveniente y acorde a sus necesidades y soporte tecnológico.
Asimismo SIP soporta transparentemente el mapeo de nombres y la redirección de
servicios lo cual permite la movilidad personal, los usuarios pueden mantener un solo
identificador de visibilidad externa sin tener en cuenta la red utilizada. Un servicio que
presenta un gran potencial es el de presencia el cual permite conocer el estado de un
usuario en particular, pudiendo presentarse como disponible, no disponible, ocupado,
etc. Este estado permite a un usuario elegir como desea ser visualizado por otros
usuarios, pudiendo ser de forma global (para todos los usuario) o de forma grupal
estando disponible solo para ciertos grupos de contactos elegidos.
Adicionalmente SIP utiliza MIME (Multipurpose Internet Mail Extensión, Extensión de
Correo de Internet Multipropósito) para la descripción de contenidos, lo que permite
transmitir datos y aplicaciones junto a la llamada de voz, haciendo fácil el envío de
tarjetas, fotos, archivos MP3, información codificada, etc. durante una sesión. [2] [3] [4]
SIP fue modelado a partir de protocolos de Internet basados en texto, como SMTP
(correo electrónico) y HTTP (páginas Web), su RFC es la 3261 y es un estándar del
IETF. SIP es únicamente un protocolo de señalización y no interviene en el transporte,
su ámbito de aplicación va mucho más allá de la VozIP, proporciona escalabilidad,
flexibilidad y facilita la creación de nuevos servicios y aplicaciones al incorporar los
beneficios de la arquitectura Web a la Telefonía IP.
Las características que presenta el protocolo SIP pueden ser resumidas en:
 Gestión de participantes: Durante una llamada, las partes pueden añadir nuevos
participantes a la llamada o comunicación, así como cancelar participantes de la
misma en cualquier momento.
 Cambio de parámetros durante la sesión: Se admite que los participantes de una
comunicación cambien los parámetros y características que fueron establecidos al

inicio de la misma, por ejemplo, el paso de una sesión de voz a una de audio y
texto o vídeo, durante la primera.
 Diferentes formatos de respuesta: SIP permite responder una invitación a una
sesión con un formato diferente al solicitado, por ejemplo, un usuario puede
responder una llamada de voz con una página Web con los números alternativos
de contacto.
 Direccionamiento de Internet: SIP utiliza el mismo formato de direcciones de
Internet, para los nombres y para las direcciones IP, por ejemplo,
sip:nombre_usuario@nombredominio.com
 Protocolo encapsulado en texto: La utilización de texto plano para la
implementación de los mensajes SIP, permite una integración en aplicaciones Web
más simples, facilidad de diagnóstico y control de errores.
 Terminales inteligentes multi-funcionales: SIP implementa en cada uno de los
dispositivos participantes una comunicación con un elevado grado de inteligencia.
Dicha implementación puede estar tanto en terminales telefónicos (llamados
teléfonos IP), ordenadores personales (PCs), asistentes personales inalámbricos
(wi-fi PDAs) u otros dispositivos de comunicación, como por ejemplo los teléfonos
3G (UMTS).
Para el establecimiento y terminación de comunicaciones multimedia SIP soporta cinco
elementos funcionales que son:
 Localización de usuarios. SIP encuentra al usuario llamado en el dispositivo
correspondiente de la red, y establece la conexión incluso cuando la identificación
del dispositivo (dirección IP) es dinámica o compartida.
 Intercambio / negociación de capacidades de los terminales. No sólo se encarga de
establecer la llamada en sí con el destinatario sino que además negocia las
funcionalidades (aplicaciones) que estarán disponibles durante la sesión entre los
terminales.

 Disponibilidad de usuarios. Determina si el destinatario de la llamada está
disponible y en caso afirmativo, si acepta o no la llamada. En caso de no
disponibilidad o aceptar, SIP admite la toma de acciones definidas por las
aplicaciones de control o de usuario.
 Establecimiento de llamada. Timbrado y establecimiento de los parámetros de la
llamada en ambos terminales de la comunicación.
 Mantenimiento de llamada. Transferencia y terminación de las llamadas
ARQUITECTURA SIP
La arquitectura de SIP es escalable, flexible, distribuida y muy similar a HTTP
(protocolo cliente / servidor). Las peticiones son generadas por el cliente o cliente del
agente de usuario (UAC) y enviadas al servidor o servidor del agente de usuario (UAS),
el servidor procesa las solicitudes y envía una respuesta al cliente. Las funcionalidades
tales como Proxy, redirección, locación y registro pueden residir en un único servidor o
en varios servidores distribuidos permitiendo incorporar nuevas funciones o procesos
sin afectar los demás componentes. El protocolo conserva información de estado en
los extremos, permitiendo recuperarse de fallas en alguno de los componentes. La
escalabilidad y redundancia se logra bajo el paradigma de N+1 lo que hace innecesario
un control. La movilidad del usuario se soporta a través de solicitudes de redirección o
vía Proxy a la localización actual del usuario. [2] [5] [6]
SIP provee confiabilidad que no depende de TCP si no del protocolo de Descripción de
Sesión (SDP) utilizado para transmitir la negociación de identificación de codificadores.

PSTN
Agente Usuario
Agente Usuario
Agente Usuario
Servidor Proxy
Servidor de Registro Servidor de Direccionamiento
Agente Usuario
Red SIP
Figura 1. Arquitectura SIP.
C3 COMPONENTES DE LA ARQUITECTURA SIP
La figura 1 muestra la arquitectura SIP, esta se compone de cinco tipos de entidades
lógicas. Cada entidad tiene una función especifica y participa en la comunicación ya
sea enviando solicitudes, respondiendo a solicitudes o ambas funciones. Un sistema
puede tener en funcionamiento la funcionalidad de varias entidades lógicas SIP. Por
ejemplo, un servidor de red puede estar trabajando como un servidor Proxy y al mismo
tiempo realizar la función de registro. [7]
C3.1 Agente de Usuario SIP (UA)
El Agente de Usuario es el software SIP en el punto terminal o estación terminal.
Funciona como cliente (UAC) cuando hace las peticiones de inicio de sesión, y también
actúa como un servidor (UAS) cuando responde a las peticiones de sesión. El Agente
de Usuario es “inteligente”, en el sentido que almacena y administra el estado de la
llamada. El Agente de Usuario establece las llamadas usando una dirección parecida a

las de correo electrónico, o un número telefónico. Por ejemplo:
SIP:usuario@servidor.universidad.edu. Esto hace que las URL de SIP sean fáciles de
asociar con la dirección de correo electrónico del usuario. Los Agentes de Usuario
pueden aceptar y recibir llamadas de otros Agentes de Usuario. Algunos dispositivos
que pueden tener la función de Agentes de Usuario en una red SIP son las estaciones
de trabajo (PC), teléfonos IP, pasarelas de telefonía, agentes de llamada y los servicios
de respuesta automatizada.
C3.2 Servidor Proxy SIP
Un tipo de servidor intermedio es el Servidor Proxy SIP. Los Servidores Proxy reenvían
peticiones desde el Agente de Usuario hacia el siguiente Servidor SIP, y retienen la
información por cuestiones de contabilidad o facturación. Adicionalmente, el Servidor
Proxy SIP puede operar en forma constante (como un circuito) o dependiente de la
conexión (vía TCP). El Servidor constante SIP puede dirigir las llamadas entrantes
hacia diversas extensiones que están activas a la vez y la primera en responder tomará
la llamada (a esto se le denomina dirección compartida). Esta capacidad significa que
se puede especificar el teléfono SIP en el escritorio, el teléfono móvil SIP y la
aplicación de videoconferencia en casa de tipo SIP y todos esos aparatos “sonarían”
cuando llegue una llamada que está tratando de localizar al usuario, de tal forma que al
contestar en cualquiera de esos medios se inicia la comunicación y los otros
dispositivos dejan de sonar. Los Servidores Proxy SIP pueden usar varios métodos
para intentar resolver la dirección destino solicitada, incluyendo búsquedas en el DNS,
en bases de datos o relevando la labor hacia el siguiente Servidor Proxy.[8]
C3.3 Servidor de Redireccionamiento SIP
La función de este servidor es responder a la resolución de nombres y la ubicación del
usuario. El Servidor de Redireccionamiento responde a las peticiones de los Agentes
de Usuario proporcionando la información acerca de la dirección del servidor requerido,
de tal forma que el cliente puede contactar la dirección puntualmente.

C3.4 Registro SIP
El Registro SIP da un servicio de información de ubicación; recibe información del
Agente de Usuario y la almacena para proporcionarla a otros Agentes de Usuario.
C3.5 Agente de Usuario Back to Back (B2BUA)
Un B2BUA es una entidad lógica que recibe una solicitud, la procesa como lo hace un
Servidor de Agente de Usuario y determina cómo debe contestarse a la solicitud,
actuando como un Cliente de Agente de Usuario. Un B2BUA debe mantener el estado
de la llamada y debe participar activamente enviando solicitudes y respuestas en
diálogos en los cuales se encuentre involucrado. El B2BUA tiene un control mas
relacionado con la llamada que un Proxy, por ejemplo: a diferencia de esta entidad, un
Proxy no puede desconectar una llamada o alterar mensajes.
Como resultado de esta arquitectura, la dirección SIP del usuario remoto siempre es la
misma (por ejemplo: sip:usuario@servidor.universidad.edu) pero en lugar de estar
vinculada a una dirección estática se comporta como una dinámica que refleja la
ubicación de usuario en la actualidad.
Otro resultado de la arquitectura SIP es la manera natural en la que se adapta a un
ambiente de colaboración ya que permite el uso de varios tipos de datos, aplicaciones,
multimedia, etc, con una o más personas. [9]
C4 MENSAJES SIP
SIP tiene dos tipos de mensajes: solicitudes (Request Messages) y respuestas
(Response Messages). El mensaje de solicitud es emitido desde el cliente al servidor y
las respuestas son emitidas en sentido contrario. Para elaborar los mensajes de
solicitud y respuesta se hace uso de métodos de solicitud y respuesta, los cuales viajan
en cabeceras definidas para la comunicación. Una solicitud y su respuesta conforman
una transacción. El diseño de SIP contempla la definición progresiva de nuevos tipos

de transacciones, complementarios a los tipos básicos definidos en la especificación
inicial, de modo que se pueden añadir nuevos servicios cuya gestión es transparente
para los servidores que no los implementan.
C4.1 Solicitudes SIP
SIP define un número de métodos de solicitud (también se les suele llamar peticiones)
con los cuales los agentes de usuario pueden solicitar acciones específicas a los
servidores. En la tabla 1 se especifican los métodos de solicitud SIP.
METODO DESCRIPCIÓN
INVITE Invita a un usuario a una sesión
BYE Termina una conexión entre dos terminales
ACK Confirmación, permite un intercambio confiable de mensajes.
OPTIONS
Permite solicitar información sobre las capacidades o características
de la llamada
REGISTER
Entrega información sobre la localización del usuario al servidor de
registro SIP
CANCEL Para terminar la búsqueda de un usuario en una invitación
INFO Transporte de información en llamada
PRACK Reconocimiento Provisional
COMET Notificación de precondición
REFER Transferencia a otra URL
SUSCRIBE Requerir notificación de Evento
UNSUSCRIBE Cancelar notificación de Evento
NOTIFY Notificación de Evento
MESSAGE Mensaje Instantáneo
Tabla 1. Métodos SIP
Los métodos INVITE y ACK manejados en SIP permiten abrir un canal confiable sobre
el cual los mensajes de control de la llamada pueden viajar.

C4.2 Respuestas SIP
Los mensajes de respuesta son códigos numéricos con los que un UA responde a una
solicitud recibida. Se encuentran clasificados en seis grupos: 1xx, 2xx, 3xx, 4xx, 5xx y
6xx, y cada grupo maneja un tipo de situaciones en particular. Igualmente las
respuestas pueden ser de dos tipos: provisionales o finales. Las provisionales son
usadas por un servidor para indicar progreso, es decir avisan en que punto va la
solicitud realizada por el Agente de Usuario. Estos mensajes de respuesta
corresponden a los mensajes de la clase 1xx. Los mensajes finales terminan las
transacciones SIP y corresponden a los mensajes de las clases 2xx, 3xx, 4xx, 5xx y
6xx. La tabla 2 especifica las clases de mensajes de respuesta SIP. [10]
RESPUESTA DESCRIPCIÓN EJEMPLOS
1XX Información provisional
100 Intentando
180 Timbrando
181 La llamada se está retransmitiendo
182 La llamada está en cola
2XX Éxito
200 Confirmación
201 Aceptación
3XX Redirección
300 Varias posibilidades
301 Traslado permanente
302 Traslado provisional
4XX Error de cliente
400 Solicitud incorrecta
401 no autorizado
402 Ampliación incorrecta
403 Prohibido
404 No encontrado
480 No disponible temporalmente
482 Bucle detectado
484 Dirección incompleta
5XX Falla de servidor
500 Error interno del servidor
501 No realizado
502 Pasarela no valida
503 Servicio no disponible
505 Versión no admitida
6XX Falla global
600 Ocupado
604 No existe
606 Inaceptable

Tabla 2. Clases y mensajes de respuesta SIP.
C4.3 Sintaxis de los Mensajes SIP
Los mensajes SIP de solicitud y respuesta comparten una sintaxis muy similar a la de
las peticiones y respuestas HTTP. Cada mensaje SIP contiene una línea de comienzo
(Start line), unas cabeceras y un cuerpo, los dos últimos separados por una línea en
blanco. El contenido del cuerpo es libre y, por definición, queda fuera del ámbito del
protocolo SIP. Los campos de cabecera con múltiples valores se pueden especificar en
una sola línea de valores separados por comas. Para todos los nombres de campos y
parte del resto de los elementos, la sintaxis no distingue mayúsculas y minúsculas. Se
puede incluir espacios libremente, excepto en la primera línea.
La primera línea de la cabecera indica el tipo de solicitud o respuesta. Las cinco
cabeceras Via, From, To, Call-ID, y CSeq están presentes en todos los mensajes e
identifican de forma unívoca cada mensaje dentro de cada llamada.
C4.4 Cabeceras y Campos SIP
Las cabeceras de los mensajes de solicitud y respuesta contienen campos similares,
campos también llamados atributos y que proporcionan información adicional acerca
del mensaje. Las cabeceras y campos se describen a continuación.
C4.4.1 Línea de Inicio (Start Line)
Cada mensaje SIP empieza con una Línea de inicio. Esta lleva el tipo de mensaje (tipo
de requerimiento en las peticiones, y código de respuesta en las respuestas) y la
versión de SIP.
Por ejemplo: <INVITE SP sip:pedro@teleinfo.com.ar SP SIP/2.0 CRLF>.
C4.4.2 Encabezamiento general (General Header)
Contiene los campos del encabezado SIP. Estos campos llevan los atributos del
mensaje que proporcionan información adicional sobre el mensaje. Son similares en

sintaxis y semántica a las cabeceras de http y siempre mantienen el siguiente formato:
<nombre>:<valor>.
Contiene los siguientes campos:
Call-ID: Se genera en cada llamada para identificar la misma. Actúa como identificador
único para agrupar una serie de mensajes. Debe ser el mismo para todas las
solicitudes y respuestas enviadas por un UA en un diálogo.
Cseq: Se inicia en un número aleatorio e identifica en forma secuencial a cada
solicitud. Por ejemplo: <Cseq: 1234 Invite>
From: Se encuentra presente en toda solicitud y respuesta. Es la dirección del origen
de la llamada. Por ejemplo: <From: “MyName” <sip:myaccount@company.com>>
To: Se encuentra presente en toda solicitud y respuesta. Es la dirección del destino de
la llamada. El “tag” es usado cuando el mismo destino designa a varios puntos finales.
Por ejemplo: <To: “Helpdesk” <sip:helpdesk@company.com;tag=287447>>
Via: Sirve para recordar la ruta del solicitante; por ello cada proxy en la ruta añade una
línea de vía. Por ejemplo: <Via:SIP/2.0/UDP PXY1.provider.com; received 10.0.03>
Encryption: Identifica un mensaje que ha sido encriptado para seguridad (proceso
descrito en SDP; es del tipo MD5). Por ejemplo: <Encryption: PGP versión=2.6.2,
encoding=ascii>.
Max-Forwards: Sirve para limitar el numero máximo de “saltos” que puede realizar una
solicitud antes de llegar a su destino. Este es básicamente un entero que se
decremento con cada salto realizado. Por lo general el valor escogido es el de 70. Este
número es suficientemente grande como para garantizar que una solicitud no se
dejaría caer en cualquier red SIP sin haber alcanzado su destino, pero no tan grande
como para mantenerse prolongadamente en la red consumiendo recursos.
Request-URI: indica la dirección del destinatario actual del mensaje.
Contact: El campo de cabecera de Contacto proporciona una SIP URI que puede
usarse para contactar esa instancia específica del Agente de Usuario en futuras
solicitudes.

Además del encabezado general se pueden transportar campos adicionales. Por
ejemplo: Expire que indica el tiempo de validez de un registro y Priority indica la
prioridad del mensaje.
Las cabeceras pueden ocupar múltiples líneas. Algunas cabeceras SIP como Via o
Contacto puede aparecer múltiples veces en un mensaje o, alternativamente, pueden
tomar múltiples valores separados por comas en una sola ocurrencia de la cabecera.
Una solicitud SIP valida debe por lo menos contener los campos To, From, Cseq, Call-
ID, Via y Max-Forwards ya que son necesarios para garantizar la comunicación.
Para el tratamiento de los mensajes SIP, los mensajes de solicitud contienen en el
campo Via la lista de equipos que componen la ruta seguida, del mismo modo que las
respuestas contienen la ruta de retorno. Por ello los servidores SIP no tienen por qué
mantener el estado durante las llamadas. Con este procedimiento, es además posible
que diferentes pares peticiones/respuestas de una misma llamada puedan tomar rutas
distintas, de modo que se puede recurrir a servidores de respaldo en caso de caída de
servidores principales. En la figura 2 se representa el formato de un mensaje SIP. [5]
MENSAJE DE PETICIÓN
INVITE sip:ivan@etsit.es SIP/2.0
Call-ID: dfg56748hb4b4b2@yahoo.com
From:<sip:mgonzalez@yahoo.com>
To:Ivan<sip:ldr@etsit.es>
Cseq:1 INVITE
Via:SIP/2.0/TCP 169.130.12.5
Content-Type:application/sdp
Content-Length:885
Linea en blanco (CRLF)
V=0
O=bell 53655765 2353687637 IN IP4
128.3.4.5
C=IN IP4 135.180.144.94
M=audio 3456 RTP/AVP 0 3 4 5
MENSAJE DE RESPUESTA
SIP/2.0 200 OK
Call-ID: dfg56748hb4b4b2@yahoo.com
From:<sip:mgonzalez@yahoo.com>
To:Ivan<sip:ldr@etsit.es>
Cseq:1 INVITE
Via:SIP/2.0/TCP 169.130.12.5
Content-Type:application/sdp
Content-Length:885
Linea en blanco (CRLF)
V=0
O=bell 53655765 2353687637 IN IP4
128.3.4.5
C=IN IP4 135.180.144.94
M=audio 3456 RTP/AVP 0 3 4 5
Cuerpo del
mensaje
Campos o
cabeceras
Línea de inicio

Figura 2. Sintaxis general de las peticiones y respuestas SIP.
C4.4.3 Cuerpo del mensaje
Se usa para describir la sesión a ser iniciada (por ejemplo, en una sesión multimedia
este puede incluir los tipos de codecs de audio y video y las tasas de muestreo), o
alternativamente puede usarse para contener datos textuales o binarios que se
relacionan de alguna manera con la sesión. El cuerpo del mensaje puede aparecer en
los mensajes de solicitud y de respuesta.
Los posibles tipos del cuerpo incluyen:
SDP: Protocolo de Descripción de Sesión (SDP)
Extensiones de Correo de Internet Multiproposito (MIME)
Otras que son definidas por el IETF y en implementaciones específicas.
C5 MODO DE OPERACIÓN SIP
Los Llamantes y los llamados son identificados por direcciones SIP. Cuando se hace
una llamada SIP, el que llama necesita primero localizar el servidor apropiado y le
envía una solicitud. El que llama puede alcanzar directamente al llamado o
indirectamente a través de servidores de redirección. Un campo en la cabecera (Call
ID) del mensaje SIP identifica las llamadas de esa comunicación. A continuación se
explica el modo de operación del estándar SIP.
Identificación de direcciones en SIP. Los servidores SIP son identificados por una URL
SIP que es de la forma sip:username@host. Una dirección SIP puede designar a un
individuo o a un grupo entero (dirección compartida).
Localización de un servidor IP. El cliente puede enviar su solicitud a un servidor Proxy
SIP o puede enviarla directamente a la dirección IP y puerto correspondientes al
identificador de solicitudes uniforme URI (Uniform Request Identifier).

Transacción SIP. Una vez que el solicitante identifica a un servidor SIP, puede enviar
las solicitudes a ese servidor. Las solicitudes pueden ser enviadas a través de los
protocolos TCP o UDP.
Invitación SIP. Una invitación satisfactoria consiste de dos peticiones: un INVITE
seguido de un ACK. La solicitud INVITE pregunta por el deseo de unirse a una
conferencia particular o establecer una conversación de dos participantes. Después de
que el usuario llamado haya aceptado participar en la llamada, al que llama se le
confirma esta aceptación recibiendo el mensaje ACK. La solicitud INVITE contiene una
descripción de sesión que provee a la parte llamada con suficiente información para
unirse a la sesión. Cuando el llamado aceptar la llamada, este responde a la invitación
retornando una descripción de sesión similar.
Localización de un Usuario. La persona llamada puede cambiar su localización con el
tiempo. Estas localizaciones pueden ser dinámicamente registradas con el servidor
SIP. Cuando el servidor SIP es consultado sobre la localización del que se desea
llamar, retorna una lista de las posibles localizaciones. Un servidor de localizaciones en
un sistema SIP realmente es el que genera la lista y se la pasa al servidor SIP.
Cambio de una Sesión Existente. Algunas veces se necesita cambiar los parámetros
de una sesión existente. Esto es hecho reenviando el mensaje INVITE con el mismo
Call ID pero con un nuevo cuerpo que contendrá la nueva información. [2]
C6 INTERACCIÓN DE ENTIDADES
A continuación se describe la interacción de las diferentes entidades SIP en diferentes
escenarios de inicio de sesión SIP.

C6.1 Establecimiento de una Sesión y su Terminación
La figura 3 muestra la interacción entre dos Agentes de Usuario durante el
establecimiento y terminación de una sesión.
Agente de Usuario
1
1: INVITE Usuario 2
2: 100/Intentando
3: 180/Timbrando
6: 200/OK
5: 182/Llamada en cola
4: 182/Llamada en cola
7: ACK
1: BYE
2: 200/OK
Agente de Usuario
2
Figura 3. Establecimiento y terminación de una sesión.
El flujo de mensajes que da lugar al establecimiento y terminación de esta sesión es el
siguiente:
Iniciando la sesión
 El Agente de Usuario 1 (UA1) envía un mensaje de invitación a la dirección:
sip:usuario2@dom.com. Este mensaje también contiene un paquete SDP que
describe las capacidades de los medios disponibles en el terminal llamante (UA1).
 El Agente de Usuario 2 (UA2) recibe la solicitud e inmediatamente responde con un
mensaje de respuesta 100 (intentando).
 UA2 inicia a “timbrar” para informar al usuario 2 de la nueva llamada.
Simultáneamente un mensaje 180 (timbrando) es enviado al UA1.
 UA2 envía un mensaje de estado de llamada 182 (La llamada está en cola) para
reportar que la llamada está en cola detrás de dos llamadas.

 UA2 envía un mensaje de estado de llamada 182 (La llamada está en cola) para
reportar que la llamada está en cola detrás de una llamada.
 El usuario 2 acepta la llamada y el UA2 envía un mensaje 200 (OK) al llamante UA.
Este mensaje también contiene un paquete SDP que describe las capacidades de
los medios de comunicación del equipo terminal del usuario 2.
 El UA1 envía una solicitud ACK para confirmar la respuesta 200 (OK) que fue
recibida.
Terminación de la sesión
 El llamante (UA1) decide finalizar la llamada y “cuelga”. Como resultado el UA1
envía una solicitud BYE al UA2.
 El UA2 responde con un mensaje 200 (OK) y notifica al usuario 2 que la sesión ha
terminado.
C6.2 Redirección de Llamada
La figura 4 muestra un escenario donde se presenta una redirección de llamada.
Agente de
Usuario 1
1: INVITE
usuario2@dom.com
2: usuario2@
dom.com?
3: 12345@
host.com
6: INVITE 12345@host.com
5: ACK
4: 302/
Contact:12345@
host.com
7: 200/OK
Agente de
Usuario 2
Servidor de
Redirección
Servidor de
Localización
8: ACK
tel.com host.com
sip.dom.com
Figura 4. Redirección de llamada utilizando un servidor de redirección.

 El UA1 envía un mensaje SIP INVITE a usuario2@dom.com, pero al intentar
encontrar la dirección, se encuentra con el servidor de redirección sip.dom.com en
su camino de señalización.
 El servidor de redirección busca la localización actual de UA2 en un Servidor de
Localización. Para esto utiliza un protocolo diferente a SIP (por ejemplo LDAP,
Lightweight Directory Access Protocol)
 El servidor de Localización retorna la localización actual de UA2, esta es:
12345@host.com.
 El servidor de Localización retorna la dirección de UA2 usando una respuesta 302
(Traslado provisional).
 El UA1 envía un mensaje de ACK al servidor de redirección.
 El UA1 continua la llamada enviando una nueva solicitud INVITE directamente a
12345@host.com.
 El UA2 notifica al usuario2 de la llamada y cuando este “acepta” la llamada. Una
respuesta 200 (OK) es enviada al UA1.
C6.3 Estableciendo una Sesión a Trabes de Servidores Proxy
La figura 5 muestra el establecimiento de una sesión entre dos Agentes de Usuario
mediante la asistencia de un Servidor Proxy que sirve de intermediario.

Agente de
Usuario 1
1: INVITE
usuario2@dom.com
2: 100/intentando
3: usuario2@dom.com
6: 100/intentando
5: INVITE
usuario2@
host.dom.com
4: usuario2@host.dom.com
7: 180/timbrando
Agente de
Usuario 2
Servidor
Proxy
Servidor de
Localización
8: 180/timbrando
tel.com host.dom.com
sip.dom.com
9: 200/OK
10: 200/OK
11: ACK usuario2@host.dom.com
Figura 5. Escenario de establecimiento de una sesión con un Proxy SIP.
 El UA1 envía un mensaje SIP INVITE a usuario2@dom.com, pero al intentar
encontrar la dirección, se encuentra con el Servidor Proxy sip.dom.com en su
camino de señalización.
 El servidor Proxy inmediatamente responde con una respuesta provisional 100
(intentando).
 El servidor Proxy busca la dirección actual del usuario 2 en un Servidor de
Localización.
 El servicio de localización retorna la localización actual del usuario 2, su dirección
es: usuario2@host.dom.com.
 El Servidor Proxy decide “manejar” la llamada y crea un nuevo mensaje INVITE
basado en el mensaje de invitación original, pero con la el campo Request-URI en

la línea de inicio cambiado por usuario2@host.dom.com. El servidor Proxy envía
esta solicitud a UA2.
 El UA2 responde primero con un mensaje 100 (intentando).
 Luego el UA2 responde con un mensaje 180 (timbrando).
 El servidor Proxy reenvía la respuesta 180 hacia el UA1.
 Cuando la llamada es aceptada por el usuario 2, el UA2 envía una respuesta 200
(OK). En este mensaje el UA2 inserta una cabecera de Contacto en la respuesta
con el valor de usuario2@host.dom.com. Luego de completarse el establecimiento
de la sesión, la comunicación se realizará directamente entre Agentes de Usuario y
no a trabes del Servidor Proxy.
 El Servidor Proxy reenvía la respuesta 200 (OK) al UA llamante.
 El UA llamante envía un ACK directamente al UA2 (según la cabecera de Contacto
encontrada en la respuesta 200). [4] [7]
En los casos en los cuales la señalización debe viajar por mas de un Servidor Proxy
para completar el establecimiento de una sesión, se realiza un proceso repetitivo
donde los nuevos mensajes de invitación creados y enviados por el primer Proxy
(numeral 5) no llegaran al UA llamado si no a un nuevo Proxy que repetirá los pasos de
búsqueda e invitación del UA2 (numerales 3, 4 y 5). Este proceso se podrá repetir
hasta que finalmente un Proxy podrá localizar al usuario 2 y así completar el
establecimiento (puntos del 5 al 11). Las figuras 6 y 7 permiten comparar los casos en
los cuales intervienen uno y dos Servidores Proxy.

Cliente SIP software
Teléfono SIP
Usuario B
Llamado
Usuario A
Llamante
Servidor Proxy
SIP del
Dominio A
Servidor de registro
y localización del
Dominio A
1
6
2
3
4
5
Dominio A.com
1. Usuario llamado B
2. Pregunta “donde está el usuario B?”
3. Respuesta “la dirección del Usuario B”
4. Llamando “desde el Proxy
5. Respuesta
6. Respuesta
7. Establecido el Canal Multimedia
Solicitudes no SIP
Señalización SIP
RTP
7
Figura 6. Establecimiento de una sesión entre clientes del mismo dominio.
La figura 6 ilustra el establecimiento de una sesión SIP entre dos usuarios subscritos al
mismo ISP y que usan el mismo dominio. El usuario A posee un teléfono SIP y el
usuario B tiene un PC que ejecuta a un cliente software que soporta voz y video.
Ambos usuarios registran su disponibilidad y su dirección IP con el servidor Proxy SIP
en la red del ISP. El usuario A, quién está comenzando esta llamada, envía una
invitación al usuario B a través del servidor Proxy SIP. El Proxy SIP pregunta al
servidor de registro por el usuario B, del cual recibe la IP. El servidor Proxy reenvía la
invitación del usuario A al usuario B, El usuario B informa al servidor Proxy que la
invitación es aceptada. El Servidor Proxy SIP informa de la aceptación al usuario A,
estableciéndose la sesión SIP. Los usuarios han establecido una conexión RTP punto
a punto que les permite interactuar mutuamente. [4]

Teléfono SIP
Servidor de
Localización y
Registro del
Dominio A
Servidor Proxy
SIP del
Dominio A
Agente de
Usuario SIP
10
6
2
3
4
5
Dominio A.com
Servidor
Proxy SIP del
Dominio B
Servidor
SIP de
Redirección
Servidor de
Localización y
Registro del
Dominio B
Agente de
Usuario SIP
1
7
9
8
Dominio B.com
1. Usuario llamado B
2. Pregunta “donde está el usuario B?”, en el otro Dominio?
3. Respuesta “la dirección del controlador del Dominio B”
4. Llamando al Proxy del Dominio B
5. Pregunta “donde está el usuario B?”
6. Dirección del usuario B
7. Llamando desde el Proxy
8. Respuesta
9. Respuesta
10. Respuesta
11. Se establece el canal multimedia
Solicitudes no SIP
Señalización SIP
RTP
PDA
11
Figura 7. Establecimiento de una sesión SIP entre clientes de diferentes dominios.
En el caso de la figura 7 cuando el usuario A invita al usuario B el Servidor Proxy SIP
del Dominio A advierte que el usuario B está fuera de su dominio y le pregunta al
Servidor de redirección acerca de la dirección del usuario B, el servidor de redirección
le informa de la ubicación en el dominio B por lo que el servidor Proxy del dominio A
reenvía la solicitud del usuario A hacia el servidor Proxy del dominio B. El servidor
Proxy del dominio B al recibir la solicitud la reenvía hacia el usuario B y si este acepta

devuelve la confirmación de aceptación al servidor Proxy A, quien a su vez la enviara
hacia el usuario A para que la comunicación quede establecida.
C7 PROTOCOLOS DE SOPORTE
Como se menciono anteriormente SIP solo es un protocolo de señalización, por lo
tanto trabaja en conjunto con una serie de protocolos existentes para llevar a cavo una
sesión multimedia. Trabaja con RSVP (Resource Reservation Protocol), RTP/RTCP
(Real time Transport Protocol), RTSP (Real time Streaming Protocol), SAP (Session
Announcement Protocol) y SDP (Session Description Protocol). RTP/RTCP es usado
para transporte de datos en tiempo real, RSVP para reservación de recursos, RTSP
para entregas controladas de flujos, SAP para sesiones de anuncio multimedia y SDP
para describir sesiones multimedia. Las actuales pasarelas de voz usualmente están
compuestas de dos partes: la pasarela de señalización y la pasarela de medios. La
pasarela de señalización se comunica con la pasarela de medios usando MGCP
(Media Gateway Control Protocol). MGCP puede interoperar tanto con SIP como con
H.323. La Figura 8 muestra los protocolos de señalización y transporte requeridos para
una sesión multimedia.

Megaco
SIP H.323
SAP
Solo
multicast
SDP
Señalización
Transporte
Calidad de servicio
RTP
RTCP
RTP
RTP
Nivel de
aplicación
Reserva Monitoriza.
RSVP
IP (v4 y v6)
Nivel de
transporte
Nivel
de red
UDP / UDP Lite SCTP
TCP
Figura 8. Arquitectura multimedia del IETF.
C7.1 Protocolo de Control de Pasarela de Medios (MGCP)
Este protocolo define la comunicación entre elementos de control de llamada (Agentes
de Control) y pasarelas de telefonía. Los agentes de llamadas son también conocidos
como Controladores de Pasarela de Medios. Este protocolo maestro / esclavo permite
a un Administrador central monitorear los eventos en teléfonos y pasarelas IP e
instruirlos para enviar los medios a direcciones específicas. MGCP ha introducido los
conceptos de conexiones y terminales para establecer caminos de voz entre dos
participantes, y los conceptos de eventos y señales para establecer y concluir
llamadas. Dado que el principal énfasis de MGCP es la simplicidad y confiabilidad,
permite que las dificultades de programación sean concentradas en los Agentes de
Llamadas. [11]

C7.2 RTP y RTCP (Protocolo de Transporte en Tiempo real y Protocolo de Control
en Tiempo Real)
RTP soporta la transferencia de medios en tiempo real (audio y video) sobre redes de
conmutación de paquetes. Este protocolo es usado por SIP y H.323. El protocolo de
transporte permite al receptor detectar pérdidas en paquetes y también provee
información de tiempos tal que el receptor puede correctamente compensar el retardo
de jitter (El jitter es la variación aleatoria de la latencia). La cabecera RTP contiene
información que usa el receptor para reconstruir los medios y también contiene
información que especifica como los flujos de bits codificados son divididos en
paquetes. RTP no reserva recursos en la red sino que provee información de tal modo
que el receptor se pueda recuperar en el momento de pérdidas y de retardo por jitter.
[12]
C7.3 Protocolo de Flujos en Tiempo Real (RTSP)
RTSP, es un protocolo cliente/servidor que provee control sobre la entrega de flujos de
medios en tiempo real. Provee funcionalidades para flujos de audio y video como
pausa, adelanto, retroceso y posicionamiento deseado. Provee los medios para
escoger los canales de distribución (como UDP y TCP), y mecanismos de distribución
basados en RTP. RTSP establece y controla flujos continuos de audio y video entre los
servidores de medios y los clientes.
C7.4 Protocolo de Reserva de Recursos (RSVP)
El retardo de red y la Calidad de Servicio QoS son los factores más críticos en la
convergencia de voz y datos. RSVP es la solución desarrollada por el IETF más
importante para este problema. Puede priorizar y garantizar latencia para flujos de
tráfico IP específicos. RSVP habilita una red conmutada de paquetes para emular a
una red más determinística como la red de circuitos conmutados. Con RSVP, se puede
realizar comunicaciones de voz con un retardo tolerable en una red de datos. RSVP
solicita recursos solamente en una dirección, por lo tanto trata lógicamente a un emisor
como distinto al receptor, aunque el mismo sistema esté actuando tanto como emisor y

receptor al mismo tiempo. RSVP no es en sí un protocolo de enrutamiento, está
diseñado para operar con protocolos unicast y multicast actuales y futuros. Para
manejar eficientemente requerimientos de grandes grupos, membresías grupales
dinámicas y requerimientos diversos de los receptores, RSVP hace responsables a los
receptores de solicitar una QoS específica.
C7.5 Protocolo de Descripción de Sesión (SDP)
SDP está destinado a describir las sesiones multimedia para propósito de anuncio de
una sesión e invitación de la sesión. El propósito de SDP es transportar información
sobre los flujos de medios en sesiones multimedia para permitir que los contenedores
de una descripción de sesión participen en la sesión. SDP incluye la siguiente
información:
 Nombre y propósito de la sesión
 Dirección y número de puerto
 Tiempos de inicio y parada
 Información para recibir dichos medios
 Información sobre el ancho de banda a ser usado por la conferencia.
 Información de Contacto de la persona responsable de la sesión.
Esta información es transportada en formato de texto simple. Cuando una llamada es
establecida usando SIP, el mensaje INVITE contiene un cuerpo SDP que describe los
parámetros de la sesión aceptables para el llamante. La respuesta desde el llamado
incluye un cuerpo SDP que describe las propias capacidades del llamado. En general,
SDP debe transportar suficiente información para habilitar una sesión y anunciar los
recursos a ser usados. La información de medios que SDP envía son: tipo de medio
(audio o video), protocolo de transporte (RTP, UDP, etc) y formato del medio (video
MPEG, video H.263, etc).

C7.6 Protocolo de Anuncio de Sesión (SAP)
Este protocolo es usado para hacer conocer las conferencias y otras sesiones
multicast. El anunciador SAP periódicamente envía un paquete de anuncio a una
dirección y puerto multicast conocidos (número de puerto 9875). Un oyente SAP se
entera del alcance multicast usando el protocolo MZAP (Multicast Scope Zone
Announcement Protocol) al escuchar en la dirección y puerto conocidos. No existe
mecanismo alguno de reunión, el anunciador SAP no se entera de la presencia o
ausencia de alguno de los oyentes SAP. Un anuncio SAP es difundido con el mismo
alcance que la sesión que se está anunciando, asegurando que los contenedores del
anuncio puedan ser también contenedores potenciales de la sesión que está siendo
difundida. SAP contiene mecanismos para asegurar la integridad de anuncio de
sesiones, para autenticación del emisor de un anuncio y para encriptación de tales
anuncios [2].
C8 SUBSISTEMA MULTIMEDIA DE INTERNET (IMS)
3GPP (3rd Generation Partnership Project) es el grupo encargado de la
estandarización de UMTS. Fue creado en Diciembre de 1998 con el principal objetivo
de desarrollar las especificaciones técnicas de las redes móviles de tercera generación
a partir del sistema existente y triunfante en ese momento: GSM. Este objetivo inicial
fue posteriormente ampliado para incluir el mantenimiento y mejoras de los sistemas
GSM, tales como GPRS o EDGE. La tercera edición de especificaciones UMTS trajo el
subsistema IMS (IP Multimedia Subsystem). Un subsistema que utiliza el protocolo SIP
para conseguir la transmisión eficiente de contenidos multimedia sobre IP en las redes
móviles.
El 3GPP ha definido IMS (subsistema multimedios IP) para redes de tercera
generación 3G incorporándole mecanismos para la gestión de la movilidad y el registro
de usuarios. Una importante ventaja de IMS es que es independiente de la tecnología
de acceso subyacente. En la actualidad se está adoptando IMS como modelo de
convergencia de facto para telefonía, móvil o fija. [13]

C8.1 La Arquitectura IMS
La arquitectura esta definida de tal manera que se pueden lanzar servicios multimedia
en una red móvil de una manera estandarizada con el objetivo de facilitar su adopción
mundial. Sin embargo, a diferencia de las funciones, los servicios en sí no están
estandarizados. Esta estrategia, no solo pretende promover la competencia entre los
proveedores sin no que también estimula la introducción acelerada de nuevos servicios
como mecanismo de diferenciación.
Red de paquetes
HLR
IMS
HSS
Base de
datos
(Suibsistema de
Medios IP)
AAA
AS
PDF
Red de
acceso
por radio
PDSN/
GCSN
Terminal de
Usuario
MRFC
MGW
MRFP
CSCF
MGCF
BGCF
Red de circuitos
Control
Transporte
1
2 3
4
5
6
7
Figura 9. Arquitectura del sistema IMS.
La figura 9 muestra los componentes del sistema IMS y a continuación se describe sus
diferentes funciones:

Call Session Control Function (CSCF): función principal responsable de aceptar y
controlar todas las sesiones. Actúa como un servidor proxy, registra y redirecciona en
el contexto del protocolo SIP.
Breakout Gateway Control Function (BGCF): si la sesión debe terminar en una red de
circuitos, se encarga de determinar en que red y punto de salida será entregada la
sesión.
Media Gateway Control Function (MGCF): encargado de controlar la pasarela de
Medios cuando uno es necesario en la sesión.
Media Resource Function Controller (MRFC): está a cargo de controlar el Media
Resource Function Processor (MRFP) Un MRFP provee funciones como la de duplicar
paquetes y modificar un medio (por ejemplo: el de convertir texto a audio).
Policy Decision Function (PDF): se encarga de negociar con la red de transporte los
recursos necesarios para proveer la clase de servicio requerida para cada sesión.
Home Subscriber Server (HSS): Base de datos central con la información que
pertenece al usuario y las funciones de autenticación, validación y administración
(AAA).
Application Server (AS): servidor especializado que se encarga de proveer la lógica y
las funciones relacionadas con cada servicio. La señalización se hace a través del
protocolo SIP con la excepción del manejo del MGW el cual es proporcionado por
H.248. El medio se transporta a través de una red IP. [14]
C8.2 Funciones de IMS
Las funciones principales de IMS para proporcionar un completo despliegue de
servicios incluye:
Autenticación y autorización de clientes SIP móviles y fijos
Control sobre sesiones para comunicación multimedia persona-a-persona, persona-a-
grupo y contenido-a-persona

Funcionalidad Charging que le permite al operador aplicar el cobro a los subscriptores
basado en tiempo, basado en evento o basado en contenido
La implementación de mecanismo de QoS pertinentes para los servicios IP a usarse en
las sesiones de comunicaciones
La funcionalidad para conectar a los usuarios roaming al dominio principal para los
servicios multimedia IP
Funciones de acceso y seguridad de dominio de red [15] [16]
C8.3 Lo esencial de IMS y SIP
El elemento más necesario para la renovación de una red principal que permita la
conectividad peer-to-peer basada en IP es IMS. Cuando un cliente SIP emite una
solicitud de búsqueda y conexión, IMS encuentra los terminales pertinentes y los
conecta vía IP, como se muestra en la figura 10.
IMS
Red de conmutación
de paquetes
SIP
SIP
Cualquier conección IP
(GPRS, EDGE, WCDMA,
WLAN, ADSL)
Posibles servicios
basados en IP
entre terminales
Encontrar
y conectar
Subsistema Multimedia IP
encuentra al otro terminal
y los conecta con IP
Terminales con
Capacidades SIP
Figura 10. Establecimiento de una sesión con IMS.
IMS proporciona una colección llena de capacidades de red para la autenticación de
clientes, las interfaces red-a-red y funciones administrativas como la tarificación. IMS

establece conexiones de datos de paquete entre los puntos finales en una clase
portadora y la tarificación. Una vez establecida una conexión IP puede usarse para
intercambiar todo tipo de medios de comunicación, incluyendo la voz, el video,
contenidos y más.
IMS soporta una interfase (ISC) de control de servicios IMS estandarizada que permite
una conectividad abierta hacia los servidores de aplicación SIP. Al igual que SIP, IMS
es de acceso independiente, trabajando con redes de voz y datos existentes en ambos
dominios fijo (por ejemplo PSTN, ISDN, WLAN e Internet) y móvil (por ejemplo GSM,
CDMA y WCDMA). Sin embargo, las aplicaciones SIP implementadas en las redes
móviles tienen algunas diferencias importantes comparadas con las del dominio fijo.
Las más esenciales se relacionan con la gestión de la movilidad, arquitectura de
seguridad y cuidado del cliente y la tarificación.
La arquitectura de seguridad de IMS consiste en seguridad de acceso y seguridad de
dominio de red. Para la seguridad de acceso, IMS soporta la autenticación IETF típica
para clientes SIP fijos, así como autenticación basada en SIM, que es la más
favorecida para los terminales móviles. La seguridad de dominio de red proporciona
seguridad entre los dominios de la red y los nodos dentro de un dominio.
SIP ya se ha implementado en redes 2G GPRS. Las redes 3G no son esenciales para
las sesiones basadas en SIP, aunque los mayores anchos de banda de tecnologías
como EDGE y 3G beneficiarán grandemente las aplicaciones de capacidad-intensiva
como el video compartido. [17]
C9 EJEMPLOS DE APLICACIONES SIP
Las aplicaciones mas importantes que surgen hasta el momento para el mundo IP-
convergido incluyen:

C9.1 Presione para Hablar
Ya implementado sobre redes GPRS, presione para hablar proporciona comunicación
de voz dirigida uno-a-uno o uno-a-muchos sobre la red móvil, emulando el servicio de
walkie-talkie tradicional. Las llamadas son iniciadas con la presión de un botón y la
conexión es directa, de esta manera se permite un servicio de voz interactivo. Las
llamadas presione para hablar tiene un medio dúplex mientras una persona habla, los
otros sólo pueden escuchar.
C9.2 Video Compartido
El video compartido permite a los usuarios móviles compartir video en un único sentido
en tiempo real después de que se encuentren activos en una sesión de voz.
C9.3 Compartir Contenidos
Una conexión peer-to-peer basada en SIP permitirá a dos o a más usuarios compartir
todos los tipos de contenido. Por ejemplo, un usuario podría enviar una fotografía en un
MMS (“contenido empujado”) y compartir el resto de las fotografías con sus amigos
(“contenido halado”) usando compartir contenidos. El compartir archivos directamente
no solo es posible entre terminales móviles sino también entre móviles y PCs o
cualquier otro dispositivo de conexión IP.
C9.4 Presencia
Habilita a los usuarios móviles para que permitan a sus terminales proporcionar
información dinámica de estado sobre los subscriptores, incluyendo en su llamada el
estado de conexión, identidad, capacidad de los terminales y disponibilidad. La
presencia es una aplicación en sí misma, pero también es un habilitador y realzador
para otras aplicaciones.

C9.5 Mensajería
La mensajería se desenvolverá construyéndose sobre el SMS existente, MMS y correo
electrónico. Para el usuario, los servicios de mensajería pueden converger en un solo
servicio de mensajería que use las diferentes tecnologías de mensajería permitidas por
la red. La mensajería será manejada por los servicios del usuario en lugar de las
tecnologías permitidas como es el caso hoy.
C9.6 Voz Sobre IP
Es usada ampliamente en redes fijas, usando teléfonos fijos que manejan VoIP o
clientes PC de VoIP. La disponibilidad de terminales móviles capaces de soportar
acceso celular y WLAN, permite a los terminales móviles usar una conexión basada en
IP para la voz dentro de una zona de acceso WLAN, esto incrementa la necesidad de
una solución VoIP para los operadores móviles. IMS es un elemento central en la
solución de VoIP de un operador, soportando clientes SIP móviles y fijos, al igual que
permite trabajar con la PSTN. [18]
C9.7 Llamada Rica
Una llamada rica integra voz, video y texto, soporte para compartir contenidos
(imágenes, datos, u otra información de valor agregado) en paralelo. SIP proporciona
elementos esenciales para realizar una llamada rica.
C9.8 Aplicaciones SIP Tripartidas
IMS y SIP permiten la creación de servicios abiertos, trayendo ventajas a los
diseñadores de aplicaciones y los operadores. Los diseñadores pueden crear
aplicaciones que se usen directamente en los terminales con capacidades SIP,
tomando ventaja de las capacidades peer to peer de IMS, y los operadores
permanecerán siempre al control. [19]

BIBLIOGRAFÍA
[1] Siemens Communications. SIP The Session Initiation Protocol For Enterprise SIP
Solutions. Octubre de 2004. https://developer.ubiquitysoftware.com/business/
whitepapers/ sip_in_nextgen_mobile_nets.pdf
[2] Landaure Enrique. Estándares relacionados a la tecnología Voz sobre IP (VoIP): Su
Clasificación. Diciembre de 2001. http://www.geocities.com/elandaure/voip.html
[consulta 3 de febrero de 2006]
[3] IETF. Session Initiation Protocol (sip). [en línea] http://www.ietf.org. [consulta: 10
junio de 2006].
[4] Avaya. Enterprising with SIP A Technology Overview. Febrero de 2004.
http://www.avaya.com/master-usa/en-us/resource/assets/whitepapers/lb1842.pdf
[5] Poyeaux Nelson. El Protocolo SIP: propuesta del IETF para la transmisión de VoIP
(parte 1). Revista electrónica Telem@tica. Octubre de 2004. año 3 No 14.
http://telematica.cicese.mx/revistatel/archivos/
[6] Poyeaux Nelson. El Protocolo SIP: propuesta del IETF para la transmisión de VoIP
(parte 2). Revista electrónica Telem@tica. Octubre de 2004. año 3 No 15.
http://telematica.cicese.mx/revistatel/archivos/
[7] RADVISION. Session Initiation Protocol (SIP). Abril de 2005. http://www.
sipforum.org/component/option,com_docman/task,doc_details/gid,11/Itemid,75/
[8] Vinod K. Bhat. Voice Over IP – The SIP Way. Abril de 2001. www VoiceOverIP–
TheSIPWay.pdf
[9] Video Development Initiative. Tecnologías Colaborativas Populares. [en línea]
http://www.videnet.gatech.edu/cookbook.es/list_topics.php?topic=3&sequence=0&
name=Tecnolog%EDas+Colaborativas+Popularesconsulta: 12 mayo de 2006].
[10] Acosta Diego. SIP SIP Session Initiation Protocol. Julio de 2002
http://greco.dit.upm.es/~david/TAR/trabajos2002/01-SIP-%20Diego-Acosta.pdf

[11] Manso Miguel. SIP: El protocolo para los servicios multimedia del futuro Resumen.
Abril de 2003. http://gauss.topografia.upm.es/~m.manso/docs/resumen-sip.pdf
[12] José Fabián Romo Zamudio Videoconferencia en las redes de datos, principales
problemas. Octubre de 2004. leido el 02 de febrero de 2006 de
http://www.enterate.unam.mx/Articulos/2004/octubre/videoconf.htm
[13] D. Attal. IMS: LA TELEFONIA EN LA ERA INTERNET. Abril de 2005.
www.alcatel.com/doctypes/articlepaperlibrary/pdf/ATR2005Q1/T0503-IMS-ES.pdf
[14] M. Moreno M. Alvarez-Campana, J. Vinyes,. Propuesta de utilización de SIP como
protocolo de señalización en la red de acceso radio de sistemas UMTS.
http://www.ahciet.net/comun/portales/1000/10002/10007/10299/docs/011-72-80.pdf
[15] Gonzales Javier. El Release 6 de UMTS. Febrero de 2005.
www.coit.es/publicaciones/bit/bit149/56-58.pdf
[16] Navarro Orlando, Urrutia Carlos. El siguiente paso en la evolución de las
comunicaciones. Diciembre de 2004. http://www.ahcietmovil.com/comun/ portales/
1003/10029/10083/10452/docs/42.pdf
[17] Nokia. IMS_white_paper.pdf IP multimedia – una nueva era en las
comunicaciones. Diciembre de 2004. www.forum.nokia.com/info/sw.nokia.com/id/
fa12d593-31b1-444c-bbc9-02f57cd8d4ea/ IMS_white_paper.pdf.html
[18] Almodóvar Daniel. Banda ancha en movilidad. Junio de 2004.
http://portal.astic.es/NR/rdonlyres/8262D0C0-3006-408E-AC61-
E53421A68849/0/mono10.pdf
[19] Ericsson. IMS – IP Multimedia Subsystem The value of using the IMS architecture.
Octubre de 2004. ww.ericsson.com/technology/whitepapers/
ims_ip_multimedia_subsystem.pdf

conexion ims.pdf

Más contenido relacionado

Similar a conexion ims.pdf (20)

Más de Harold Cabrera Meza (6)

Último (20)

conexion ims.pdf