UNIVERSIDAD NACIONAL AUTNOMA DE HONDURAS

U.N.A.H.




POSTGRADO FACULTAD DE CIENCIAS ECONMICAS

MAESTRA EN GESTIN DE LAS TELECOMUNICACIONES

CURSO: Redes de Nueva Generacin (MGT-304)

CATEDRTICO: Dr. Rafael Daz del Valle

TEMA: Protocolo SIP

Presentado por:
Ing. Paola L. Gmez
Ing. Leonel Zepeda








CIUDAD UNIVERSITARIA 31 DE JULIO DE 2014
PROTOCOLO SIP

2

Introduccin

Session Initiation Protocol o SIP (Protocolo de Iniciacin de Sesin), es un protocolo de
sealizacin definido por el Internet Engineering Task Force o IETF que permite el
establecimiento, la liberacin y la modificacin de sesiones multimedia (RFC3261). Este
protocolo hereda de ciertas funcionalidades de los protocolos Hyper Text Transport Protocol
ohttp, utilizados para navegar sobre el WEB y Simple Mail Transport Protocol o SMTP,
utilizados para transmitir mensajes electrnicos (e-mails). SIP se apoya sobre un modelo
transaccional cliente / servidor como http. El direccionamiento utiliza el concepto Uniform
Resource Locator o URL SIP parecido a una direccin E-mail. Cada participante en una red
SIP es entonces alcanzable va una direccin, por medio de una URL SIP.

Por otra parte, los requerimientos SIP son satisfechos por respuestas identificadas por un cdigo
digital. De hecho, la mayor parte de los cdigos de respuesta SIP han sido tomados del protocolo
http. Por ejemplo, cuando el destinatario no est ubicado, un cdigo de respuesta 404 Not
Found esta Devuelto. Un requerimiento SIP est constituido de headers o encabezamientos, al
igual que un mando SMTP. Por fin, SIP, al igual de SMPT es un protocolo textual.

SIP ha sido extendido con el fin de soportar numerosos servicios tales como la presencia, la
mensajera instantnea (similar al servicio SMS en las redes mviles), la transferencia de
llamada, la conferencia, los servicios complementarios de telefona, etc.

SIP ha sido elegido por el 3GPP para la arquitecturaIP Multimedia Subsystem o IMS como
protocolo para el control de sesin y el control de servicio. El reemplazara en el futuro, los
protocolos ISUP, utilizado para el control de llamada en la Red Telefnica Conmutada, y
INAP, utilizado para el control de servicio en la arquitectura Red Inteligente.

El protocolo SIP es solo un protocolo de sealizacin. Una vez la sesin establecida, los
participantes de la sesin intercambian directamente su trfico audio / video a travs del
protocolo Real-Time Transport Protocol o RTP. Por otra parte, SIP no es un protocolo de
PROTOCOLO SIP

3

reservacin de recursos, y en consecuencia, no puede asegurar la calidad de servicio. Se trata de
un protocolo de control de llamada y no de control del medio.
SIP tampoco es un protocolo de transferencia de fichero tal como http, usado con el fin de
transportar grandes volmenes de datos. Ha sido concebido para transmitir mensajes de
sealizacin cortos con el fin de establecer, mantener y liberar sesiones multimedia. Mensajes
cortos, no relativos a una llamada pueden sin embargo ser transportados por SIP al estilo de SMS.

Objetivos de SIP:

Ms integrado con las aplicaciones y servicios Internet.
Mayor flexibilidad para incorporar nuevas funciones.
Implementacin ms simple.
Diferencias entre SIP y H.323

Las diferencias en cuanto a servicios soportados se reducen a medida que se desarrollan
nuevas versiones.
Mucha propaganda cuando menos inexacta, incluso desde organizaciones aparentemente
rigurosas.
Errores frecuentes, por ejemplo: SIP es ms simple.
Los anlisis comparativos existentes son errneos o no estn actualizados.
Las comunidades existentes en torno a SIP y H.323 tienen tradiciones distintas.
H.323 especifica servicios, mientras que SIP es slo un protocolo de sealizacin para dar
base a servicios.
H.323 engloba un amplio conjunto de protocolos de implementacin obligatoria.

Negociacin de capacidades ms completa y compleja en H.323.
H.323 define mecanismos de gestin y administracin de la red.
En la arquitectura SIP, funciones y servicios como garanta de calidad, directorio o
descripcin de sesiones son ortogonales.
PROTOCOLO SIP

4

SIP est integrado en la infraestructura Web y proporciona servicios de mensajera
instantnea.
SIP tiene mejores mecanismos de deteccin de bucles, espirales y otros errores de
configuracin de la red.
El 3gpp ha adoptado SIP como protocolo de sealizacin.
Desde las primeras versiones, el inicio de llamadas es ms rpido con SIP.
Entidades SIP

SIP define dos tipos de entidades: los clientes y los servidores. De manera ms precisa, las
entidades definidas por SIP son (figura 1):
El Servidor Proxy (Proxy Server): el recibe solicitudes de clientes que el mismo trata o
encamina hacia otros servidores despus de haber eventualmente, realizado ciertas
modificaciones sobre estas solicitudes.
El Servidor de Redireccionamiento (Redirect Server): se trata de un servidor quien
acepta solicitudes SIP, traduce la direccin SIP de destino en una o varias direcciones de
red y las devuelve al cliente. De manera contraria al Proxy Server, el Redirect Server no
encamina las solicitudes SIP. En el caso de la devolucin de una llamada, el Proxy Server
tiene la capacidad de traducir el nmero del destinatario en el mensaje SIP recibido, en un
numero de reenvi de llamada y encaminar la llamada a este nuevo destino, y eso de
manera transparente para el cliente de origen; para el mismo servicio, el Redirect Server
devuelve el nuevo nmero (nmero de reenvi) al cliente de origen quien se encarga de
establecer una llamada hacia este nuevo destino.
El Agente Usuario (User Agent) o UA: se trata de una aplicacin sobre un equipo de
usuario que emite y recibe solicitudes SIP. Se materializa por un software instalado sobre
un User Equipment o UE: una PC, un telfono IP o una estacin mvil UMTS.
El Registrador (Registrar): se trata de un servidor quien acepta las solicitudes SIP
REGISTER. SIP dispone de la funcin de registro de los usuarios. El usuario indica por
un mensaje REGISTER emitido al Registrar, la direccin donde es localizable (direccin
IP). El Registrar actualiza entonces una base de dato de localizacin. El registrador es
PROTOCOLO SIP

5

una funcin asociada a un Proxy Server o a un Redirect Server. Un mismo usuario puede
registrarse sobre distintas UAs SIP, en este caso, la llamada le ser entregada sobre el
conjunto de estas UAs.







Mtodos y Respuestas SIP
3.1 Mtodos SIP

El RFC 3261 define seis solicitudes / requerimientos o mtodos SIP.
El mtodo INVITE es usado con el fin de establecer una sesin entre UAs. INVITE
corresponde al mensaje ISUP IAM o al mensaje Q.931 SET UP y contiene las informaciones
sobre el que genera la llamada y el destinatario as como sobre el tipo de flujos que sern
intercambiados (voz, video,...).
Cuando un UA que emiti el mtodo SIP INVITE recibe una respuesta final a la invitacin
(ejemplo: 200 OK), el confirma la recepcin de esta respuesta por medio de un mtodo ACK.
Una respuesta del tipo busy o answer es considerada como final mientras una respuesta tipo
ringing significando que el destinatario ha sido avisado es una respuesta provisoria.
PROTOCOLO SIP

6

El mtodo BYE permite la liberacin de una sesin anteriormente establecida. Corresponde al
mensaje RELEASE de los protocolos ISUP y Q.931. Un mensaje BYE puede ser emitido por el
que genera la llamada o el que la recibe.
El mtodo REGISTER es usado por una UA con el fin de indicar al Registrar la
correspondencia entre su Direccin SIP y su direccin de contacto (ejemplo: direccin IP).
El mtodo CANCEL es utilizado para pedir el abandono de la llamada en curso pero no tiene
ningn efecto sobre una llamada ya aceptada. De hecho, solo el mtodo BYE puede terminar
una llamada establecida.
El mtodo OPTIONS es utilizado para interrogar las capacidades y el estado de un User Agent
o de un servidor. La respuesta contiene sus capacidades (ejemplo: tipo de media siendo
soportado, idioma soportado) o el hecho de que el UA sea indisponible.

3.2 Respuestas SIP

Despus de haber recibido e interpretado un requerimiento SIP, el destinatario de este
requerimiento devuelve una respuesta SIP. Existen seis clases de respuestas:
Clase 1xx : Informacin, el requerimiento ha sido recibido y est en curso de tratamiento
Clase 2xx: xito, el requerimiento ha sido recibido, entendido y aceptado.
Clase 3xx: Reenrutamiento, la llamada requiere otros procesamientos antes de poder
determinar si puede ser realizada.
Clase 4xx: Error requerimiento cliente, el requerimiento no puede ser interpretado o
servido por el servidor. El requerimiento tiene que ser modificado antes de ser reenviado.
Clase 5xx: Error servidor, el servidor fracasa en el procesamiento de un requerimiento
aparentemente valido.
Clase 6xx: Fracaso global, el requerimiento no puede ser procesado por ningn servidor.

Funcionamiento del protocolo SIP
Protocolo de sealizacin
PROTOCOLO SIP

7

Como se ha establecido el protocolo SIP es un protocolo de sealizacin (figura 2), y con el
podemos establecer, modificar y finalizar llamadas/sesiones, registro y localizacin de
participantes, movilidad, gestin del conjunto de participantes y de los componentes del sistema,
descripcin de caractersticas de las sesiones y negociacin de capacidades de los participantes.


Figura 2. Protocolo de sealizacin SIP

Inscripcin a la red SIP
El mtodo REGISTER es utilizado por un USER AGENT con el fin de indicar a la funcin
Registrar (fsicamente implantada en un Proxy Server o un Redirect Server) la correspondencia
entre su direccin SIP (ejemplo: sip :mary.Taylor@orange.com) y su direccin IP (ejemplo:
sip:mary.Taylor@192.190.132.20). La direccin IP puede ser esttica u obtenida de modo
dinmico por DHCP. La funcin Registrar actualiza entonces una base de datos de localizacin.
Desde este momento, el User Agent puede recibir llamadas ya que se encuentra ubicado. Si un
usuario SIP desea reenviar sus llamadas de su dominio corriente hacia otro dominio, (ejemplo:
del dominio orange.com al dominio francetelecom.com), solo tendr que indicar a la funcin
Registrar de orange.com su direccin SIP en el dominio francetelecom.com. Cuando un mensaje
INVITE debe ser entregado por el Proxy Server del dominio orange.com a sip:
PROTOCOLO SIP

8

mary.Taylor@orange.com, la base de datos actualizada por la funcin Registrar indica al Proxy
Server que el mensaje tiene que ser relevado a sip:mary.Taylor@francetelecom.com. Entonces, el
Proxy Server efecta una bsqueda por el DNS de la direccin IP del Proxy Server del dominio
francetelecom.com con el fin de relevar el mensaje SIP a encaminar al destino apropiado
(sip:mary.Taylor@francetelecom.com).
En una red IP Multimedia Subsystem o IMS, el Proxy Server corresponde a una entidad CSCF
(Call State Control Function), mientras la base de datos de localizacin es representada por la
entidad Home Subscriber Server o HSS. El HSS en el IMS por los mviles es un HLR
conteniendo por otra parte el perfil del usuario para los servicios IMS suscritos.

Establecimiento y liberacin de sesin SIP

En el ejemplo siguiente, el que llama tiene como URL SIP sip mary.taylor@francetelecom.com,
mientras la URL SIP del destinatario de la llamada es sip: mark.rich@francetelecom.com.
Un mensaje de establecimiento de llamada SIP INVITE esta emitido por parte de la UA SIP del
que llama al Proxy Server. Este ltimo interroga la base de datos de localizacin para identificar
la localizacin del que esta llamado (direccin IP) y encamina la llamada a su destino. El mensaje
INVITE contiene distintos headers o encabezamientos obligatorios, entre los cuales la
direccin SIP de la persona que llama From, la direccin SIP de la persona que recibe la
llamada To, una identificacin de la llamada Call-ID, un numero de secuencia Cseq, un
nmero mximo de saltos max-forwards. El encabezamiento Va esta actualizado por todas
las entidades que participaron al enrutamiento del requerimiento INVITE. Eso asegura que la
respuesta seguir el mismo camino que el requerimiento.

Por otra parte, el requerimiento SIP INVITE contiene una sintaxis Session Description
Protocol o SDP. Esta estructura consiste en varias lneas que describen las caractersticas del
media que el que llama Mary necesita para la llamada.
Mary Taylor indica que la descripcin SDP utiliza la versin 0 del protocolo, que se trata de una
sesin telefnica (m = audio), que la voz constituida en paquetes le debe ser entregada a la
direccin de transporte (puerto UDP = 45450, direccin IP =192.23.34.45) con el protocolo RTP
PROTOCOLO SIP

9

y utilizando un formato de codificacin definido en el RFC Audio Video Profile o AVP y
pudiendo ser G. 711 -law o G.728.


INVITE sip:mark.rich@francetelecom.com SIP/2.0
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 1 INVITE
Contact: mary.taylor@192.190.132.20
Content-Type: application/sdp
Content-Length:162
v = 0
c = IN IP4 192.190.132.20
m = audio 45450 RTP/AVP 0 15

La respuesta 180 RINGING esta devuelta por el destinatario a la UA del que genera la llamada.
Cuando el destinatario acepta la sesin, la respuesta 200 OK esta emitida por su UA y
encaminada hacia la UA del que genera la llamada.

SIP/2.0 200 OK
Via : SIP/2.0/UDP ps1.francetelecom.com:5060
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 1 INVITE
Contact: mark.rich@192.190.132.27
Content-Type: application/sdp
Content-Length:162
v = 0
c = IN IP4 192.190.132.27
m = audio 22220 RTP/AVP 0

PROTOCOLO SIP

10

La UA del que genera la llamada devuelve un mtodo ACK al destinatario, relevada por la
entidad Proxy Server.
La entidad Proxy Server participa al encaminamiento de la sealizacin entre UAs mientras que
las UAs establecen directamente canales RTP para el transporte de la voz o del video en forma de
paquetes sin implicacin del Proxy Server en este transporte.

Cuando Mary cuelga, su UA enva un requerimiento BYE para terminar la sesin. Este
requerimiento esta entregado al Proxy Server quien lo encamina a la UA de Mark. Este ltimo,
devuelve la respuesta 200 OK.

BYE sip:mark.rich@francetelecom.com SIP/2.0
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 2 BYE
SIP/2.0 200 OK

Via : SIP/2.0/UDP ps1.francetelecom.com:5060
Via : SIP/2.0/UDP station1.francetelecom.com:5060
Max-Forwards : 20
To : Mark Rich <sip:mark.rich@francetelecom.com>
From : Mary Taylor <sip:mary.taylor@francetelecom.com>
Call-Id: 23456789@station1.francetelecom.com
CSeq: 2 BYE

Extensiones del protocolo SIP

Una entidad SIP puede suscribir a un evento con el fin de ser notificada de su ocurrencia. El
requerimiento SUBSCRIBE permite la suscripcin mientras el requerimiento NOTIFY es
utilizado con el fin de notificar (RFC 3265). El mtodo PUBLISH permite publicar su estado.

PROTOCOLO SIP

11

El mtodo REFER (RFC3515) reenva el receptor hacia un recurso identificado en el mtodo.
REFER permite emular distintos servicios o aplicaciones incluyendo la transferencia de llamada.
Contemplamos T1, la entidad que origino la transferencia, T2 la entidad transferida y T3, el
destinatario de la transferencia. La transferencia de llamada permite a T1 transformar una
llamada en curso entre T1 y T2 en una nueva llamada entre T2 y T3, elegida por T1. Si la
transferencia de llamada se lleva a cabo, T2 y T3 podrn comunicar mientras que T1 no podr
seguir dialogando con T2 o T3.

El mtodo MESSAGE (RFC 3428) ha sido propuesto como extensin al protocolo SIP con el fin
de permitir la transferencia de mensajes instantneos. La mensajera instantnea o Instant
Messaging o IM consiste en el intercambio de mensajes entre usuarios en seudo tiempo real.
Este nuevo mtodo hereda de todas las funciones ofrecidas por el protocolo SIP tales que el
enrutamiento y la seguridad. El requerimiento MESSAGE puede transportar varios tipos de
contenidos basndose sobre la codificacin MIME.

El mtodo INFO (RFC2976) permite transferir informaciones de sealizacin durante la llamada.
Entre los ejemplos de informacin se encuentran los dgitos DTMF, las informaciones relativas a
la tasacin de una llamada, las imgenes etc...

Las respuestas finales 2xx, 3xx, 4xx, 5xx y 6xx a un requerimiento INVITE son satisfechas por el
requerimiento ACK mientras las respuestas provisorias de tipo 1XX no son satisfechas.
Ciertas respuestas temporarias tales como el 180 Ringing son crticas y su recepcin es esencial
para la determinacin del estado de la llamada, entre otros durante el proceso de interconexin
con la RTCP. El mtodo PRACK (RFC3262) ha sido definido con el fin de satisfacer la
recepcin de respuestas temporarias de tipo 1XX.

El mtodo UPDATE (RFC3311) permite a un terminal SIP actualizar los parmetros de una
sesin multimedia (ejemplo: flujo media y sus codecs). El mtodo UPDATE puede ser enviado
antes de que la sesin sea establecida. UPDATE es entonces particularmente til cuando se trata
de poner al da los parmetros de sesin antes de su establecimiento, por ejemplo en puesta en
espera del destinatario.
PROTOCOLO SIP

12


Arquitectura de servicios SIP
La arquitectura de servicios SIP de base est constituida de servidores de aplicacin, de
servidores de media y de S-CSCF.

El servidor de aplicacin SIP ejecuta servicios (ejemplo: Push To Talk, Presence, Prepaid, Instant
messaging etc...) y pueden influenciar el desempeo de la sesin a pedido del servicio. El
servidor de aplicacin corresponde al SCP de la Red Inteligente.

El servidor de media SIP (llamado en las recomendaciones el Multimedia Resource Function o
MRF) establece conferencias multimedia, toca anuncios vocales o multimedia y colecta
informaciones de usuario. Se trata de la evolucin de la entidad Specialized Resource Point o
SRP en el mundo multimedia.

El servidor de llamada SIP (Proxy Server) tiene el papel de punto desde el cual un servicio puede
ser requerido. El dispone del perfil de servicio del abonado que le indica los servicios suscritos
por el abonado y bajo cuales condiciones invocar estos servicios. Corresponde al SSP de la
arquitectura Red Inteligente.

Servidor de aplicacin

Un servidor de aplicacin SIP provee un mbito de ejecucin para aplicaciones llamado Service
Logic Execution Environment o SLEE. El provee un conjunto de servicios que permite
simplificar las tareas de los desarrolladores de aplicaciones as como de los administradores. El
objetivo es de disponer de una plataforma que pone en obra todas las funcionalidades
permitiendo as al desarrollador enfocarse nicamente en la lgica profesional de la aplicacin.

Las funciones de un servidor de aplicacin son las siguientes:
PROTOCOLO SIP

13

La gestin de recursos: el servidor de aplicaciones controla la creacin y la utilizacin de
recursos tales como los threads, las conexiones de transporte, los componentes aplicativos
(ejemplo: scripts CPL, servlets SIP) as como las sesiones de aplicaciones.

La gestin de aplicaciones: la aplicacin puede ser asociada a un perfil de configuracin durante
su despliegue. Este perfil puede contener parmetros que pueden ser modificados a travs de la
interface administrativo durante el despliegue de la aplicacin o durante su ejecucin.

La composicin de aplicacin: el servidor de aplicacin debe permitir la ejecucin de varias
aplicaciones por un mismo requerimiento SIP. Eso provee una capacidad de modularizacin. De
hecho, elementos de servicio pueden ser desarrollados independientemente y pueden ser
combinados segn las necesidades de aplicacin. Eso permite por otra parte un mejor control de
las interacciones de servicio.

La integracin WEB: con el fin de proveer un GUI Web para la administracin y el
Interfuncionamiento con servidores WEB previendo servicios.

La programacin: el servidor de aplicacin provee un soporte para el desarrollo de aplicacin,
i.e. APIs (JAIN API, SIP Servlet API, etc.) as como lenguajes de script. Los scripts pueden ser
creados con el apoyo de mbitos de creacin de servicio.

El interfuncionamiento: el servidor de aplicacin comunica usando el protocolo SIP con el
servidor de media (IP media server) para las interacciones con el usuario y con el servidor de
llamada (CSCF) para el encaminamiento y la sealizacin.

La seguridad: el servidor de aplicacin debe proveer mecanismos de encriptacin, de
autentificacin y de autorizacin con el fin de asegurar un acceso seguro a los servicios.

Las capacidades no funcionales: alta disponibilidad, reparto de carga, tolerancia a los errores.
Estas caractersticas son similares a las caractersticas exigidas por un SCP en la arquitectura de
Red Inteligente.
PROTOCOLO SIP

14


El servidor de media SIP

El servidor media SIP es una plataforma poderosa y evolutiva para el desarrollo de servicios de
portales vocales y servicios vocales / video interactivos capaces de suportar centenares y hasta
millares de sesiones simultaneas en un amplio rango de configuraciones.

El servidor de media SIP es un equipo fsico y pone en obra la entidad funcional Multimedia
Resource Function o MRF definido por el IMS. El servidor de media SIP provee las
funciones permitiendo interacciones entre usuarios y aplicaciones a travs de recursos vocales /
video. Por ejemplo, l puede responder a una llamada y difundir un anuncio, o leer un mensaje
electrnico usando funciones de sntesis vocales o colectar una informacin del usuario (ejemplo:
clave, voto, numero) y devolverla a la aplicacin.

El servidor de media SIP pone en obra dos tipos de funciones:

Las funciones de recursos media tales como las funciones de deteccin de tonalidad, de
sntesis vocal, de reconocimiento vocal, de traduccin de media etc. Es la funcin
Multimedia Resource Function Processor o MRFP.
Las funciones de control del media que proveen a las aplicaciones los medios de controlar
recursos media tales como, tocar un mensaje, colectar un voto, gravar un mensaje etc. Y eso,
a travs del protocolo SIP. Es la funcin Multimedia Resource Function Controller o
MRFC.

La arquitectura distribuida del servidor de media SIP / servidor de aplicacin separa las
aplicaciones voz / video del control de medias, lo que permite a los operadores reducir los costos
de los recursos de red y albergar con costos menores las aplicaciones clientes. El servidor de
media IP soporta el protocolo de control SIP. Adems del servidor de media IP y del servidor de
aplicacin, las entidades siguientes pueden ser contempladas:

PROTOCOLO SIP

15

Browser Voice XML: este componente integrado en el servidor de media IP provee un ejemplo
de mbito de ejecucin de aplicaciones vocales. Las aplicaciones desarrolladas segn las
especificaciones Voice XML pueden ser interpretadas y ejecutadas por el Browser Voice XML.
Este Browser solo interpreta y determina las etapas atmicas del call flow. Es el servidor de
media IP que interacta con el usuario.

Servidor ASR: este componente provee el servicio Automatic Speech Recognition o ASR. El
flujo de audio del usuario es transportado sobre RTP del Media Gateway o del telfono IP del
usuario al servidor ASR. El Browser Voice XML contacta el servidor ASR cuando un
reconocimiento de palabra es necesario.

Servidor TTS: este componente provee el servicio Text-To-Speech o TTS. Una cadena de
caracteres esta emitida hacia este componente y est convertida en un aviso vocal que puede ser
emitido al usuario bajo la forma de flujo RTP. El browser Voice XML contacta el servidor TTS
cuando un texto debe ser traducido en un mensaje vocal y entregado al usuario.

Servidor WEB: este componente es un servidor estndar http. Esta utilizado con el fin de
albergar el contenido vocal. Este contenido consiste en escrito Voice XML, anuncios vocales /
video, mensajes de recepcin y gramticas de reconocimiento de la palabra. Los escritos Voice
XML definen la lgica de aplicacin. Mensajes de recepcin apoyan el usuario en su navegacin
dentro de una aplicacin. Las gramticas contienen las palabras autorizadas o las frases que un
usuario puede pronunciar cuando la aplicacin le pide ingresar sus informaciones.

Funcionalidades del servidor de media

Las funcionalidades del servidor de media SIP incluyen las funciones de control del media y de
recursos media:

Anuncios: la mayor parte de los servicios evolucionados utiliza formas de anuncios, bien sea un
mensaje de bienvenida durante el acceso a su buzn de mensajes unificado o de un mensaje de
PROTOCOLO SIP

16

introduccin a un portal local. La utilizacin de un servidor de media SIP para realizar servicios
de anuncios permite no tener que desplegar un nuevo servidor de anuncios.; reduciendo as el
nmero de elementos de red y simplificando la gestin de la red. Un equipo de almacenamiento
externo puede ser utilizado para almacenar anuncios creando as una solucin confiable y
escalable. El protocolo RTP esta utilizado para entregar el anuncio al usuario.

Automated Speech Recognition (ASR): el reconocimiento de la palabra es un componente de la
mayor parte de los servicios al usuario tales como mensajera vocal (voicemail), la mensajera
unificada, juegos interactivos y portales vocales.

Generacin de informacin de tasacin: una tasacin precisa y justa es una exigencia por los
operadores de servicio con el fin de ofrecer servicios de voz y datos con fuerte valor agregado. El
servidor de media SIP genera informaciones de tasacin.

I nteractive Voice Response (I VR): el servidor de media SIP debe soportar la deteccin de
tonalidades DTMF enviadas en la banda as como los dgitos recibidos va SIP INFO.

Grabacin: el servidor de media SIP tiene capacidades de grabacin y de restitucin (playback).
Numerosas aplicaciones tales como la mensajera vocal, la mensajera unificada, el pushto- talk y
la conferencia utilizan esta funcin i.e, grabacin de la llamada para que sea restituida
ulteriormente. El servidor de media SIP utiliza servidores de almacenamiento que existen donde
el operador de servicios.

Text-To-Speech: la tecnologa text-to-speech es estrechamente asociada a la funcionalidad
IVR. El text-to-speech es utilizado en aplicaciones tales como la mensajera unificada a fin de
leer E-mail o fax a travs del telfono. La traduccin puede ser realizada en varios idiomas.

Gestin del multipartes: el servidor de media SIP debe ser capaz de proveer todos los
mecanismos de control de las llamadas con varios participantes. Esta funcionalidad es utilizada
dentro de numerosas aplicaciones tales como conferencias o el Push-To-Talk.

PROTOCOLO SIP

17

Transcodificacin: la transcodificacin permite convertir un esquema de codificacin digital en
otro. En el caso de una conferencia donde los participantes no disponen de un mismo codificador
comn, el servidor de media SIP asegurara entonces las traducciones de media necesarias.

Puesta en obra de servicios

El mtodo de introduccin del servicio depende del tipo de servicio y de su complejidad. As
mismo, un servicio pude ser puesto en obra sobre el terminal SIP, el servidor de media SIP, el
servidor de aplicacin o el Proxy Server.

Ciertos servicios requieren interacciones complejas con el usuario (mensajera unificada, IVR,)
Para estos servicios vocales, una acercamiento centralizado es necesario con las entidades AS SIP
conteniendo la lgica de aplicacin y servidores de media SIP conteniendo el escrito vocal.
Algunos servicios requieren un a base de datos centralizada. Para estos servicios de traduccin de
nmero (servicios de numero abreviado, servicio prepago, servicio VPN), un AS SIP que
contiene la lgica de aplicacin es necesario.
Algunos servicios de enrutamiento flexible necesitan un escrito personalizado por abonado. El
lenguaje Call Processing Language o CPL puede ser usado para eso. Es posible ejecutar este
escrito por un AS SIP o par el proxy server.
Algunos servicios no se prestan bien a un tratamiento centralizado. La aparicin de terminales
SIP basados sobre una maquina Java, ha ofrecido la posibilidad de desarrollar servicios sobre los
terminales:

El servicio timbre diferenciado permite modificar el timbre del puesto llamado segn la
identidad del que llama. Este servicio bsico es tpicamente un servicio que conviene
desplegar sobre el aparato.
El servicio de filtro de llamada es una evolucin del servicio anterior en la cual la
identidad del llamado sirve para determinar si la llamada debe ser aceptada, reenviada o
bien rechazada.
PROTOCOLO SIP

18

El servicio de gua telefnica subraya el inters de una conexin directa del terminal con
una gua de empresa: permite al usuario consultar una gua LDAP desde el telfono, de
seleccionar un nmero entre los resultados de la consulta y generar una llamada hacia
dicho nmero.






Conclusin

SIP muestra su gran simplicidad en los siguientes aspectos:

Funcionalidad
Tipos de mensajes
Modo de operacin

SIP es un protocolo sencillo y extensible, adecuado para establecer sesiones multimedia.
Aunque hace reserva de recursos para ofrecer calidad de servicios (QoS), puede interoperar
con otros protocolos y esto ofrece gran flexibilidad para la creacin de servicios.

Escalabilidad, globalidad, interoperabilidad, independencia entre establecimiento de la sesin
y utilizacin de sta, ser una plataforma para la creacin de servicios.